"Big Microsoft data breach – 250 million records exposed"

14 évnyi adat volt szabadon hozzáférhető majdnem egy hónapig. Részletek itt. A Microsoft bejelentése itt.

Hozzászólások

Van valami statisztika arrol, hogy miss configuration
vagy valami software bug vezete -e tobb incidenzhez manapsag ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mekkora szuperség a felhő, rohanok előfizetek még valamire.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Ennek semmi köze ahhoz hogy felhő vagy nem felhő. Elkúrták a biztonsági beállításokat (a security group nem tudom azure-ban micsoda, aws-ben kvázi a tűzfal szabályokat jelenti). Ugyanezt meg lehet tenni onpremises esetén is.

"Our investigation has determined that a change made to the database’s network security group on December 5, 2019 contained misconfigured security rules that enabled exposure of the data."

De van köze a felhőhöz. Ez az eset is felhívja a figyelmet a centralizált, hatalmas adatbázisok veszélyére. Engem kísértetiesen emlékeztet a biokertészkedésre. A homogén ugyanolyan növénnyel beültettet területet egy fajta kártevő letarolja és bukta minden, a heterogén mindenféle növénnyel teleültettet területen csak sokkal kisebb lesz a kár. A biodiverzitást használják védelemnek a vegyszerek helyett. Szvsz az "itdiverzitás" sokkal életképesebb lenne, legalább is biztonsági szempontból.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Na ez mondjuk nekem is fura, mert AFAIK az Elastic kér, bár hozzáteszem, egyáltalán nem ismerem.

Másrészről meg microservice-s világban simán el tudom képzelni, hogy egy adott (backend) service nem kér autentikációt, mert úgy is valamilyen API gateway mögött van normál esetben az egész és az adott backend service gyakorlatilag csak egy belső része egy nagyobb rendszernek. Ki se látszana a resource groupon belül, azon belül az adott backend service meg  és kb. olyan lenne, mintha teszem azt a Word a táblázat beszúró funkció hívásánál kérne autentikációt.

Azureban is van egy halom ilyen SaaS-ben. Nálunk is van valamire Elastic, bár én csak azokat a serviceket nyomkodom, amiről tudom, hogy használják, mélyebben nem érdekelt/kellett a dolog eddig, így nem néztem utána :)

Pl. mi is kidobtunk egy kézzel tákolt HA PostgreSQL-t, mert annyira mégsem sikeredett HA-ra (akik csinálták, viszonylag kevés tapasztalatuk volt a PostgreSQL-lel), másrészt erőforrás sem volt azt tutujgatni, úgyhogy a Hajbi féle Nagyon Hatékony Kiscéges módszer szerint feladtuk a saját Pg-t.

Lehet, hogy valamivel lassabb, lehet, hogy 2x annyi, mint egy sima VM (bár ugye úgy is kettő gép kellett, szóval effektíve ugyanannyi), cserébe nem kell vele foglalkozni, SLA van, frissül automatikusan, stb., ha erősebb gép kell, Octopusban egy érték meg egy deploy gomb megnyomása. (Lehetne Azure Portalon is persze, de gondolom nem kell részletezni, hogy az miért szar megoldás.)

Édesmindegy, hogy egy cloud szolgáltatónál van centralizálva, vagy nálad van centralizálva a pincében. Ha elkúrja valaki a tűzfalon a konfigot, akkor mindkét esetben ugyanott vagy.

Amiről te beszélsz, az meg nem a centralizáltság, hanem a homogenitás. Ha valamilyen konfiguráció management és deployment megoldásokkal te nem egy helyen, hanem több telephelyen tartod az adataid és elrontod annak listáját, hogy ki mihez férhet hozzá, ugyanott vagy. Ha nem használsz konfig managementet, akkor meg még extra módon szopatod magad azzal, hogy vajon hol maradt ki valamilyen beállítás. Stb. Arról nem is beszélve, hogy valószínűleg ilyen jellegű auditot sem fogsz tudni, hogy megnézd, hogy ki állította be azt és mikor, hanem csak ott lesz egy random text fájlban valami beállítás.

Szóval, továbbra sem az a probléma, hogy cloud, hanem az, hogy elcsesztek egy konfigot.

Nem, nem qrhatták el. A MS komoly cég, komoly anyagi háttérrel, komoly szakemberekkel, akiknek komoly végzettségeik és minősítéseik vannak. Ők nem olyan nevetséges hobbista amatőrök, meg igénytelen free licences hippik, mint a linuxosok, BSD-sek, meg hasonló népség, és ezt meg is mutatják a világnak. Aha.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Na ha valaki vissza akarja keresni a beszélgetését a Microsoft supporttal, akkor itt a lehetőség. Nekem volt szerencsém az indiai supporthoz még a software assurance elején, valamint a hibás magyar kódfelolvasóhoz is.. egy élmény a Microsoftot hívni.

Mikor nyitod a support ticket-et, ki kell választani a kommunikáció nyelvét. Ott jó eséllyel kell lennie magyar-nak is. Ha szerencséd van, még nem sok indiait tréningeltek magyar nyelvre :). De amúgy nem tudom milyen support agreement kellhet hozzá, nem én nyitogatom a jegyeket csak a kolléga mutatta a múltkor hogy lehet így nem-angol nyelven is folytatni a diskurzust. El tudod képzelni az államigazgatásban hány perc után törne ki a parasztlázadás, ha valamelyik sóhivatalban az informatikai főosztályvezetőnek angolul kéne megszólalnia, vagy valamit elolvasnia/leírnia.

Jo, csak azt irtad, hogy kerhetsz roman, lengyel support engineert.

En nem tudok lengyelul. De remeltem hogy egy lengyel mernokkel beszelhetek angolul. Akkor ez ugy nem igaz.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> egy élmény a Microsoftot hívni

Kb. mindegyiket. Ertem hogy x penz sporolas, de ez kb. apropenz ilyen nagy cegeknek. Megeri a sok morgo ugyfel par filler haszonert? Olyan penny wise, pound foolish hozzaallasnak latom en ezt.
(Nem hoborges volt. Bocs ha offtopic.)

echo crash > /dev/kmem

> mély technikai tudással rendelkező illető,

Néha én is  a béka segge alatt érzem magam, de eszembe nem jutna bányamernököt hívni.

Egyébként tudnám miért van szükség bányamernökre az AWShez...

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Majd ha találkozol olyan esettel hogy a szolgáltatás nem úgy viselkedik ahogy le van írva, vagy reprodukálható bugot azonosítasz, amiről ők is tudnak, és a felajánlott workaround még rosszabbul viselkedik, amit szintén visszaigazolnak és azt javasolják hogy _ne_ használd a szolgáltatás által provisionolt cuccost, akkor majd felhívod őket.

Keveset AWS-ezel vagy sosem találkoztál hibával? :)