BMW maakt Azure-server met private keys per ongeluk openbaar

Door een verkeerde configuratie van zijn Microsoft Azure-server heeft autofabrikant BMW gevoelige bedrijfsinformatie gelekt. Hoelang de server heeft opengestaan, is niet bekend. BMW zegt dat die inmiddels weer privé is gemaakt.

Het lek werd ontdekt door beveiligingsonderzoeker Can Yoleri, schrijft TechCrunch. Hij kwam de openstaande server tegen tijdens een routinescan. Yoleri zegt tegen de site dat de door Microsoft Azure gehoste opslagserver, die tevens een ‘bucket’ wordt genoemd, in de ontwikkelomgeving van BMW ‘per ongeluk openbaar was gemaakt in plaats van privé door een verkeerde configuratie’.

Volgens de onderzoeker bevatte de bucket onder meer keys die toegang bieden tot privébucketadressen en details over andere cloudservices. De keys geven toegang tot de clouddiensten van BMW in China, Europa en de Verenigde Staten, concludeert TechCrunch op basis van de door Yoleri aangeleverde screenshots. Ook waren er inloggegevens te zien voor de productie- en ontwikkelingsdatabases van BMW.

Een woordvoerder van BMW bevestigt aan TechCrunch dat er sprake was van een lek en dat deze 'begin 2024' is opgelost. Er zouden geen klantgegevens zijn gelekt. Of andere partijen toegang hebben gehad tot de gegevens en hoe lang de bucket openbaar was, wil de autofabrikant niet zeggen. Yoleri beweert dat hoewel de server weer privé is gemaakt, de gegevens en keys niet zijn ingetrokken of gewijzigd. Hij zegt dat hij hierover contact probeerde op te nemen met BMW, maar geen antwoord heeft ontvangen.

BMW is de tweede autofabrikant die in korte tijd per ongeluk gevoelige gegevens online lekte. In januari lekte Mercedes-Benz zijn eigen broncode via GitHub. Dit kwam doordat het GitHub-token van een medewerker per abuis in een publieke repository terecht was gekomen.

Reacties (128)

[Raymond Deen]

OMG!

Dit is gewoon exact het zelfde als bij MB gebeurd is. En dan hebben ze het over een routinescan die daar achter kwam... De scripts om dit soort infra te regelen, moeten dat gewoon standaard aan hebben staan en anders moet het in de routine ingebakken zitten dat je een resource controleert direct na aanmaak ervan.

Edit:
Ik snap niet goed waarom er bij dit soort zaken geprobeerd wordt om te bagatelliseren, of het onder het kleedje proberen te vegen. Speel open kaart en los alle problemen gedegen op zoals eventueel gelekte sleutels intrekken, enz.

[Reactie gewijzigd door Raymond Deen op 22 juli 2024 18:47]

[asing]

Het gebeurt overal. Zo is bij Microsoft afgelopen zomer een belangrijke private key gestolen die het mogelijk maakte mails van Exchange Online te lezen.

[MiesvanderLippe]

Aangevallen worden door een statelijke actor ter formaat China is wel iets anders dan gewoon je Bucket open zetten hoor.

[gwijsman]

Toch lijkt het de trend dat het dev/test environments betreft.
Developers zijn zich domweg niet bewust van de waarde van de private keys
(Of willen zich dat niet zijn?!?)

[Christoxz]

Dit is gewoon exact het zelfde als bij MB gebeurd is.

En Toyota, althans niet exact, maar zeer vergelijkbaar.

nieuws: Toyota-database met data van 2 miljoen klanten stond 10 jaar openbaar...

[Gr4mpyC3t]

Dat kan prima georganiseerd worden met Azure Policy. Het simpelweg verbieden van publieke endpoints op dit soort resources wordt dan geblokkeerd. Als een ontwikkelaar toch besluit om niet toegestane configuratie uit te rollen dan is dat niet eens mogelijk.

De cloud is een groene weide waar standaard een hoop openstaat. Je hebt ontzettend goede security frameworks voor de cloud (ISO 27001, NIST, CIS) die houvast bieden. Maar ja, die moeten dan wel geïmplementeerd worden.

[TheDudez]

Hier zouden dan ook boetes op moeten komen. Want dit zou inderdaad standaard moeten zijn.

[Frame164]

Als je boetes gaat instellen voor fouten die worden gemaakt op plekken waar mensen werken dan gaat niemand meer iets doen. Dan durft ook niemand meer een vloer schoon te maken. Je zou eens kunnen uitglijden.

[david-v]

Boetes worden alleen maar aan mensen/bedrijven opgelegd. Een schoonmaak bedrijf die bij het dweilen geen pionen gebruikt om aan te geven dat het glad is zou bijvoorbeeld ook een boete kunnen krijgen.

Als je nalatig bent, je processen niet goed hebt ingericht, security niet op orde waardoor datalekken ontstaan...dan krijg je boetes. Dat is bij vrijwel alle beroepen zo.

[TheDudez]

Inderdaad dit precies. Fouten zijn menselijke die maak ik ook. Maar een goed security proces had er voor kunnen zorgen dat dit veel korter fout had kunnen gaan.

[Skiddie]

Wat een belachelijke opmerking.
Volgen we jouw redenatie dan vraag ik me af waarom er nog dokters zijn. Voetballers. Buschauffeurs. etc.

Indien je er vanuit jezelf niet voor kan zorgen, dan moet je op andere manieren gemotiveerd worden. Bekijk het als een vorm van free market vs regularisatie. Dagelijks wordt er aangetoond dat de free market variant niet werkt. (as expected) Dan moeten we maar gaan regulariseren. Kan je je er niet in vinden om regels opgelegd te krijgen en deze te volgen, er zijn redelijk veel commune's waar je welkom bent.

[cariolive23]

Hoeveel fouten heb jij dit jaar gemaakt? Geef dan het goede voorbeeld en ga voor elke fout dan even een boete aftikken, een vrijwillige bijdrage aan de overheid.

Iets zegt me dat je dit niet gaat doen...

[Azenomei]

Als een medewerker van ons bedrijf een serieuze fout maakt, dan stellen klanten ons gewoon keihard aansprakelijk voor de geleden schade. Daarom hebben we ook een bedrijfsaansprakelijkheids verzekering die giga omhoog gaat als er fout op fout gemaakt wordt.

[cariolive23]

Oh, dus jij gaat géén boete betalen, je wentelt dit af op de verzekering. Wat is dan het nut van een boete?

[Azenomei]

Ehm, welkom in de echte wereld? En aansprakelijk gesteld worden voor je fouten =/= boetes.

[cariolive23]

Ik reageerde op “boete”, niet op aansprakelijkheid. Dat zijn verschillende dingen, het ene is een straf de ander de schade.

[Skiddie]

Krijg je levenslang voor het papiertje dat je op straat gooit?

Gelieve wat minder met je knie te jerken aub.

[c-nan]

Hoezo? Het is een commercieel bedrijf, hun bedrijfsgegevens is mogelijk gelekt, maar geen klantdata of klantgegevens. Hoezo dan een boete? Je kan ook doorslaan zeg.

[The Zep Man]

Edit:
Ik snap niet goed waarom er bij dit soort zaken geprobeerd wordt om te bagatelliseren, of het onder het kleedje proberen te vegen.

Dat is de cultuur in de auto-industrie, en is niets nieuws. Pas als doodzwijgen duurder wordt dan aanpakken zal men niet meer doodzwijgen, tot het moment dat doodzwijgen weer goedkoper is. Qua dat heeft de auto-industrie wat narcistische trekjes:

That didn't happen.
And if it did, it wasn't that bad.
And if it was, that's not a big deal.
And if it is, that's not my fault.
And if it was, I didn't mean it.
And if I did, you deserved it.

Dayna Craig, The Narcissist's Prayer

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:47]

[familyman]

Er moet nog iets bij als,
If i did, it was allowed
If it wasn't, the rules were unclear
If they weren't, they were too recent

[Goldwing1973]

it was just for a minute or so...

[Raymond Deen]

Het is toch al wel vaker bewezen dat deze struisvogelpolitiek niet werkt?

Zoals in een ander comment wordt genoemd, kun je hier policies voor instellen en de architectuur zo opzetten dat er niet met één configuratie-oepsmomentje je "hele" bedrijf op het www te grabbel ligt.

[The Zep Man]

Het is toch al wel vaker bewezen dat deze struisvogelpolitiek niet werkt?

Vertel dat maar aan het groepje MBA's die dit soort strategieën bedenkt en uitzet.

[Raymond Deen]

Nog steeds hoop dat dit soort commentaar uiteindelijk een keertje naar die echelons zal doorsijpelen...

Maar je zou toch denken dat ze slim genoeg zijn om zelf tot dit soort conclusies te komen.

[Tassadar32]

Er zijn een boel verschillende manieren om slim te zijn. Vriend van me is MBA en echt niet dom maar mist het perspectief van iemand op de werkvloer.

[Raymond Deen]

Je hebt dus 0,0 perspectief van iemand op de werkvloer nodig om te bedenken dat:
- mensen fouten maken;
- fouten kunnen leiden tot publiek toegankelijk worden van je bedrijfsdata;
- er wellicht oplossingen zijn die geïmplementeerd kunnen maken om bovenstaande 2 punten zoveel mogelijk uit te sluiten.

Als het missen van perspectief het gebruikte uitvlucht is dan vind ik persoonlijk dat hij die drie letters niet waard is, want het raakt namelijk de core van de middelste van die drie letters...

[The Zep Man]

Je hebt dus 0,0 perspectief van iemand op de werkvloer nodig om te bedenken dat:
(...)

MBA:
"I stopped listening halfway through whatever you were saying. Line goes up!"

Zolang voorkomen binnen het huidige kwartaal duurder is dan het risico dat in hetzelfde kwartaal een incident opgelost moet worden, dan gaat men niet voorkomen.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:47]

[Raymond Deen]

Dan wijs ik je naar het gezegde: "Voorkomen is beter dan genezen".
Als het ze om de kosten gaat dan hadden ze allang aan de bel getrokken, want hoe langer dit soort problemen door sudderen, hoe meer het gaat kosten om op te lossen.
Daarvoor bestaat zo'n mooie grafiek die je bij volgens mij elke it opleiding, maar vast ook wel op zo'n dure MBA-opleiding, te zien krijgt: kosten van een oplossing vs. tijd die er overheen gaat voordat het probleem opgepakt wordt. Dat is geen lineaire grafiek.

[The Zep Man]

Dan wijs ik je naar het gezegde: "Voorkomen is beter dan genezen".
Als het ze om de kosten gaat dan hadden ze allang aan de bel getrokken, want hoe langer dit soort problemen door sudderen, hoe meer het gaat kosten om op te lossen.

"Dat is voor het volgend kwartaal (en aan mijn opvolger) om uit te zoeken."

Let op dat we spreken over een risico, dus over mogelijke kosten. Tot nu toe is het niet bekend dat er daadwerkelijk (significante) kosten vloeien uit dit lek.

Daarvoor bestaat zo'n mooie grafiek die je bij volgens mij elke it opleiding, maar vast ook wel op zo'n dure MBA-opleiding, te zien krijgt: kosten van een oplossing vs. tijd die er overheen gaat voordat het probleem opgepakt wordt. Dat is geen lineaire grafiek.

Je bedoelt technical debt? Een schuld kan je aangaan en pas veel later terugbetalen. Daar hebben grote bedrijven in het 'nu' altijd weinig tijd en aandacht voor. Die 'hot potato' wordt doorgeschoven naar iemand die zich daarover druk mag maken in de toekomst.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:47]

[Zoop]

In mijn ervaring heb je hier gewoon met een hoop ego te maken. Zitten vast een paar mensen tussen die verantwoordelijkheid waren voor deze fukup die er zo min mogelijk aandacht aan willen besteden, liefste zolang mogelijk negeren tot het "weggaat". Die ego staat boven eventuele gevolgen van de fukup, erger nog, hoger dan gevolgen van het negeren van de fukup. En gek genoeg kom je dit soort volk juist meer tegen bij grote partijen (een kleine partij zou zoiets waarschijnlijk niet eens kunnen maken zonder er onderuit aan te gaan).

Dat er regelmatig mensen te vinden zijn op posities waar ze totaal niet voor gekwalificeerd zijn moet toch ook geen verassing zijn.

[Frame164]

En zijn IT-ers dan zo amateuristisch dat ze domweg uitvoeren wat anderen vertellen. IT-ers zijn toch ook allemaal hoogopgeleide mensen die toch een zekere professionaliteit zouden moeten hebben.

[grlk]

A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped inside. Now, should we initiate a recall? Take the number of vehicles in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one.

Fight club

[Baklap-XD]

Naast de scripts moet er ook policy in Azure aan staan die het gelijk corrigeerd zodra devs of scripts iets ongewenst doen.

Dit is vrij makkelijk te voorkomen. Het is gewoon niet goed te praten.

[blinchik]

En dat is waarvoor zo'n dingen in een publieke cloud in een bucket bewaren gewoon van de pot gerukt is. Zoiets moet gewoon in een DMZ of private VLAN staan die niet van buitenaf bereikbaar is. En dan bedoel ik daarom nog niet op private gehoste servers, in de cloud kan je ook private netwerken aanmaken.

Helaas is door de cloud evolutie meer en meer het idee gekomen dat systeembeheerders niet nodig zijn, want alles wordt automatisch en veilig opgezet, dus de programmeurs zullen dit wel beheren. En dan krijg je, leuk, zo kunnen we er van buitenaf aan zonder lastige VPN-client.

Hoeveel leaks hebben we nu de laatste jaren al niet gezien via per ongeluk opengezette publieke buckets?

[Reactie gewijzigd door blinchik op 22 juli 2024 18:47]

[Verwijderd]

Waarom zou data niet encrypted zijn dan, moet je minstens 3 systemen hebben, complex etc.
En dan ook zo regelen dat elk record zijn eigen sleutel heeft. Wellicht moet prive en publiek binnen dezelfde tool geen optie zijn.

Zo kunnen we nog wel ff doorbouwen. Kom over 20 jaar nog eens terug met je adviezen

[blinchik]

Ik snap eigenlijk niets van je bericht of je punt dat je probeert te maken. Wat is er complex aan netwerksegmentatie? Het is nog steeds een van de meest betrouwbare en aan te raden line of defences.

Zaken die intern horen te staan, in een externe S3 bucket plaatsen, is gewoon not-done. Dat is bij deze weer bewezen. Dat is een advies dat nu telt, en dat inderdaad binnen 20 jaar nog zal gelden.

[Verwijderd]

Dat de data juist encrypted moet worden, wat volgens mij ook niet gebeurt.

Publieke toegang niet mogelijk maken in de repository/ bucket. Als je publieke toegang wil moet je de boel verhuizen naar een ander systeem.

Soms wil je een online backup hebben. Dan is een private repository een goedkope optie, zelfde geld voor zo'n bucket.

Ik denk dat de boel over 20 jaar beter beveiligd is dan nu, houtje touwtje. Data unecrypted in de cloud lijkt me dan ook niet meer van de tijd.

[blinchik]

Euh, data encrypten haalt in dit geval 0,0% uit. Waar en wat wil je encrypten? Op het filesysteem (zorgt er voor dat men niet zomaar bestanden van het filesysteem kan kopieren bij een hack) ? Of de onderliggende block storage (zorgt er voor dat je niets met de fysieke storage bent als je die uit het datacenter zou stelen) ? Of bedoel je de netwerk traffiek (zorgt er voor dat je geen traffiek kan onderscheppen en op die manier stelen) ?

Waarschijnlijk zijn/waren al deze zaken geëncrypteerd. Het ging hier over een foute configuratie bij een permissie van een bucket. Die bucket (api) leest bestanden, de storage zal de data decrypten een aanbieden, eventueel decrypt die de files van het filesysteem, en de api biedt die via een geencrypteerde netwerklaag netjes aan aan de persoon die daar geen toegang mag toe hebben.

Zo'n configuratiefout is enorm makkelijk te maken. Toegangen mogen van daar wel, van daar niet, die user wel, die user niet. Daar kom je dus bij "publieke toegang niet mogelijk maken". Gewoon een domme rule is foutgevoelig, zoals hieruit blijkt.

Nee, private keys rechtstreeks in een WAN vlan duwen, is niet alleen onnodig, maar ook not done.

En over 20 jaar beter beveiligd - of je het nu on-prem, hosting, cloud, AI of wie-weet-welke marketing termen er nog aankomen - dezelfde principes van security zullen steeds blijven gelden.

[Verwijderd]

je moet je eigen files encrypten met je eigen systeem ongeacht er andere systemen met encrptie werken. jij kan die andere partij wel vertrouwen, ikke niet en als het goed is de avg ook niet, en omdat jijzelf de data encrypt kan de andere partij, welke dan ook zonder jou keys niets beginnen. Dan maakt het niet uit of die publiekelijk is, de data is encrypted.

overigens heb ik het artikel gelezen

zo zijn databases bij default ook niet encrpyted als je erin zit, dan kan tegenwoordig heel mooi encrypt worden met de keys op een andere server dan de database server...

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:47]

[blinchik]

Je bedoelt end-to-end encryption. Het gaat hier over een S3 bucket, een soort van API, niet over iets wat je aan 1 persoon wil aanbieden! Een heel team moet met BMW China kunnen communiceren en daarvoor hadden ze die private keys nodig. Als je die keys gaat encrypten met een private key (zodat ze enkel door een bepaalde persoon kunnen gedecrypt worden), hoe ga je dan die zaken aan meerdere mensen aanbieden? Ga je dan die private keys om dit te decrypten aan iedereen van je team geven? Dat kan uiteraard niet, je stuurt niet zomaar private keys door.

En dan nog - stel dat iedereen op zijn computer een decryptiekey heeft - wat doe je als iemand van je team het bedrijf verlaat? Die mag niet meer aan de data. Alle files terug op die S3 bucket opnieuw encrypteren?

Dit is dus absoluut niet werkzaam in dit geval. Je schermt het af in een apart netwerk, waar je mensen van teams toegang toe kan geven.

[Verwijderd]

ik bedoel zodra in jou pand de bestanden verlaten zullen ze encrypted moeten worden opgeslagen en getransporteerd. de keys heb je inpandig, als er dus een verzoek komt, dan zorg je met publieke sleutels de toegang tot zo'n bestand, gaat er een weg, trek je de sleutel in. kijk maar hoe github dat doet bijvoorbeeld

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:47]

[Verwijderd]

je denkt toch niet handmatig de boel te gaan encrypten ? dan moeten processen worden... en inderdaad als er iemand weg gaat dienen de sleutels van alle bestanden eigenlijk opnieuw laten we zeggen in ieder geval verdeelt te worden.
Dus toegang geven tot bestanden moet tijdelijk zijn net zoals die op het internet tijdelijk zijn.

[ctrl-tab]

buckets en blob stores kan je gewoon private maken. daar heb je geen oldschool netwerk voor nodig.
wat je erin stopt is nog een tweede.

Je hebt wel mensen nodig die snappen wat ze doen. En daar gaat het vaak mis. junior beheerders of devs die er 'even iets in klikken' , want dat is zo makkelijk.Totaal geen besef of awareness , dat is het probleem.

[Aldy]

Wat ik uit het verhaal begrijp is dat het vooral BMW is, die het slachtoffer is als er van die gegevens misbruik wordt gemaakt. Een heel grote reden om gelijk alle keys te wijzigen of in te trekken.

[Svrooij86]

Of ze betalen niet genoeg of ze hebben de beveiliging niet goed staan, maar GitHub biedt tegenwoordig “Advanced Security” aan en dat scant je code onder andere op secrets en zorgt er zelfs voor dat je dan die code niet kan pushen.

Als er andere automakers (of andere serieuze bedrijven) zijn, ga maandag even allemaal kijken of dit bij jullie wel goed is geconfigureerd.

En verder, dit verbaasd me helemaal niks, het is niet voor niks dat GitHub hier tegenwoordig automatische checks voor heeft…

Meer details: https://docs.github.com/e...-github-advanced-security

[Zyppora]

Yoleri beweert dat hoewel de server weer privé is gemaakt, de gegevens en keys niet zijn ingetrokken of gewijzigd. Hij zegt dat hij hierover contact probeerde op te nemen met BMW, maar geen antwoord heeft ontvangen.

Ben ik de enige die dit nog veel erger vind dan het feit dat er een bucket wagenwijd openstond? Dat er ergens een configuratiefoutje gemaakt wordt kan gebeuren, we zijn ten slotte allemaal mensen, maar vervolgens iemand die dat aanmeldt glashard negeren is een bewuste keuze die mijns inziens niet goed te praten is.

[Reactie gewijzigd door Zyppora op 22 juli 2024 18:47]

[The-Source]

En vooral dan ook de manier van werken, bucket op prive zetten is niet genoeg. Wat ook in het artikel staat is dat er geen nieuwe keys zijn aangemaakt en de oude ingetrokken.
Een kwaadwillende heeft alleen de keys nodig en niet meer de storage waar deze stonden

[penthadix]

Dat zal waarschijnlijk wel gewoon gebeurd zijn op de achtergrond, maar niet gemeld in het artikel

[morphje]

En dit is nou exact waarom de NIS2 zo hard nodig is. Persoonlijke bestuurlijke aansprakelijkheid bij (extreme) nalatigheid.

En dit is zeer duidelijk nalatigheid en het wordt ook hoog tijd dat er flinke boetes worden uitgekeerd op plekken waar het pijn doet.

[michielRB]

[mierenneuk mode] Boetes worden opgelegd en niet uitgekeerd [/mierenneuk mode]

[Lisadr]

Mits er handhaving is. Zoals het nu lijkt vinden de meeste landen het niet belangrijk genoeg om budget beschikbaar te maken voor handhaving.

[cobis taba]

Kun je dan eventueel naar het hof om handhaving af te dwingen? En als de overheid op een klein deel van de zaken echt handhaaft heeft zelfs dat een stevig effect. Niet zoveel als iedereen zou willen misschien, maar zeker niet nul.

[Lisadr]

Nee. Neem AVG als voorbeeld. Autoriteit Persoonsgegevens heeft sinds de invoering in 2018 slechts 39x een boete uitgedeeld. Pakkkans is vrijerl nihil

AP mag een boete uitdelen van maximaal 4% van de wereldwijde omzet. In 2021 had Booking.com een omzet van 10,4 miljard euro en kreeg een boete van 475 duizend euro. Dat is een boete van 0,0046%.

[morphje]

Het Franse equivalent van de AP is anders wel zeer capabel. Geen idee hoeveel boetes die uitgedeeld heeft, maar ze staan wel bekend als een van de sterkste handhavers van de GDPR in Europa. En ik geef toe dat ze tamelijk tam zijn hier in nederland.

Daarnaast zijn boetes niet een correcte metric om naar te kijken. Ik kijk liever naar de totale resultaten en boetes zijn juist een uiterst machtsmiddel. Daarnaast is de GDPR een van de meest gelobbyde wetten van de EU, het is een wet die deels onmogelijk gemaakt is. Die boete van booking was vanwege het te laat melden, niet vanwege het datalek zelf. Dat is ook deels onderdeel van het probleem. Je doet een melding, een mea culpa en klaar. Wat dat betreft is de AVG inderdaad een zwakke wet (zie lobby argument) en is het erg lastig om nalatigheid te bewijzen als AP.

De NIS2 daarentegen is flink sterker op dat soort punten. In de eerste plaats is de ISO27001/2 de basisimplementatie en dat is bewijsbaar door goede audits (daar worden ook eisen aan gesteld). Door pentests (ook onderdeel van de NIS2) kan je ook een hoop vaststellen. Bestuurders die zich verschuilen achter hun medewerkers is (in theorie) ook niet meer mogelijk vanwege de verplichte training. Ik hoop ook dat er een handhaver op gezet wordt die ietsje steviger is.

[morphje]

In nederland zal er handhaving zijn, maar de vraag is hoeveel. Ze lopen al achter op de implementatie en ik vraag me serieus af hoeveel effect dat zal hebben voor de beoogde datum.

Maar wat is je bron voor het niet beschikbaar willen stellen van budget door verschillende landen? Ik vind dat nogal een stevige aanname die je doet.

[Lisadr]

Het is geen aanname maar gebaseerd op data van de afgelopen jaren bij verschillende toezichthouders in Europa. Er is geen centrale bron, maar mijn eigen analyse.

Neem AP, die vanaf 2018 al roept dat ze veel te weinig budget hebben om effectief te kunnen zijn.
Van 2018 t/m 2022 zijn er 114.260 datalekken gemeld bij de AP (veel organisaties melden geen datalekken) en 96.884 klachten. AP heeft capaciteit gehad om maar 210 van de gecombineerde lekken en klachten te onderzoeken en om 36 keer een boete uit te delen.

https://autoriteitpersoon...egevens/feiten-en-cijfers

[morphje]

Fair point en op basis van dit soort gegevens heb ik zelf ook een kleine vrees hier en daar. Dat gezegd hebbende is de nieuwe handhaver van deze wet nog niet bekend en worden er ook significant meer eisen gesteld aan de overheidszijde in deze wet.

Ik heb zelf ook te maken met datalekken vanuit mijn eigen functie en heel veel van die datalekken zijn in feite betekenisloos. Bijvoorbeeld het doorleveren van data van gemeente X aan gemeente Y vanwege een configuratiefoutje of foute datalevering. 9 van de 10 keer hebben we het zelf eerder door dan de klant en is er alleen sprake van een theoretisch lek. Anyway, heel veel van die gerapporteerde lekken zijn niet interessant, maar bieden wel inzicht in de volwassenheid van organisaties. Dat alleen al is waardevolle informatie.

Oke, dan de NIS2. Binnen de NIS2 moeten er 13 CSIRTs opgericht worden plus de toezichthouder. Dat biedt al direct meer capaciteit, omdat er per sector een expertgroep op zit en de toezichthouder alleen de onderzoeksresultaten hoeft te beoordelen. Je moet jezelf aanmelden als bedrijf en al je diensten registreren, waardoor elke CSIRT ook nog eens een volledige inzage krijgt in alle diensten voor hun sector (die ze dan weer proactief kunnen scannen). Elke sector heeft zijn eigen unieke kwaliteiten en elke CSIRT dus ook. Ook geeft de NIS veel meer controle mogelijkheden zoals compliancy audits en verplichte boardroomtraining waardoor er niet meer verscholen kan worden achter medewerkers. In theorie in ieder geval een veel sterkere basis.

[Verwijderd]

Wat moet er met dat boetegeld gebeuren dan?

Dus jij vind, dat een programmeur de gevangenis in moet gaan, omdat ie werkt met zijn eigen verantwoordelijkheid, maar niet capabel blijkt en een doodde met gevolg?

Kun je toch veel beter een krantenbezorger worden ?

Mogen mensen geen fouten maken?
Had hem toch die cursus Azure gedaan, is de fout van management, niet van de programmeur. Daarnaast controleren programmeurs elkaar als het goed is, is dit wel toegepast ? Systeembeheer heeft zitten slapen want die zou dit in ieder geval uit de logs moeten halen.
Zo kan ik nog wel ff doorgaan en wat blijkt, de directeur is ook niet kapabel. Ook maar een boete ?

[morphje]

Ho ho, juist het bestuur, niet de programmeur is aansprakelijk. Een medewerker heeft misschien een fout gemaakt en dat heet een datalek. Dat meld je en er wordt onderzoek gedaan. Dat is stap een.

Het probleem hier is dat de keys onveranderd actief blijven. Specifiek dat punt doel ik op. Daar is het management voor verantwoordelijk. Zodra het lek bekend is, dient het bestuur op de hoogte te worden gebracht, implicaties beschreven en acties opgesteld. Dat is stap twee. Er is hier bewust gekozen om niet de keys te veranderen. Waarom? Gebrek aan opleiding, andere belangen of misschien zelfs een angstcultuur? De reden is onbelangrijk, het bestuur heeft verwijtbaar gehandeld.

Niet capabel zijn is geen excuus. En dat is juist ook de reden dat onder de NIS2 het bestuur verplicht regelmatig een cybersecurity training ondergaan, juist om dit soort incompetentie te voorkomen. Je verdient als CEO bakken met geld, dat komt met een bepaald risico.

Ik weet niet waar je dat gedeelte vandaan haalt over doden, maar als een programmeur door nalatigheid direct en verwijtbaar doden tot gevolg heeft, dan ja dan verdient dat boetes. Ik noem maar een voorbeeld... Boeing 737 MAX? In het geval van Boeing is de bedrijfscultuur fout en specifiek het bestuur dat in alle redelijkheid direct verwijtbaar heeft gehandeld. Vele tientallen engineers hebben fouten proberen aan te kaarten.

[Kevinp]

Zo lang we bestuurders niet vervolgen voor deze keuze'e (zie ook het topic over de (illlegale) cookiewall van de eigenaren van tweakers) dan blijven mensen dit doen.

[mjtdevries]

En zou het dan eerlijk zijn een bestuurder van een autofabrikant te vervolgen voor een beleid dat de IT afdeling maakt en een blunder van een developer en een gemis aan monitoring door de IT afdeling?

Zou het dan eerlijker zijn de developer te gaan vervolgen?

Of komt het dan te dichtbij?

[Kevinp]

De manager die deze keuze maakt jazeker.

Laat het duidelijk zijn fouten maken is geen probleem. Maar als je bewust fouten open laat staan daarna dan is het wel een probleem. En in dit geval is het aangegeven.

Een straf kan ook voorwaardelijk zijn. Hoe je straft maakt mij niet zoveel uit, maar er moet iets gebeuren.

[mjtdevries]

De managers die deze keuzes maken zijn niet de bestuurders.

Het is belangrijk om duidelijk te zijn wie je dan wilt vervolgen.
En de echte veroorzaker is hier dus niet een manager, maar die developer.

[Kevinp]

Ja klopt, maar ik verwacht dat de developer zegt:

Foutje we moeten dit veranderen.

Manger: Wat kost dat

Developer: xxx.xx met vrij hoog risico op problemen

Manger dan doen we het niet.

Deze keuzes worden zelden door developers gemaakt. Maar ja als deze daar liggen ook developers. Het gaat niet perse om zware straffen (tenzij je herhaaldelijk in gebreken blijkt.

Nu gebeurd er simpel weg niks, zelfs bij grote schandalen waar gewoon bewust keuzes gemaakt worden om de wet te overtreden gebeurd er niks. En soms wordt een bestuurder ontslagen, maar dan heeft hij/zij vaak zo een nieuwe baan. (kijk bv naar Overmars).

[kodak]

Het artikel vermeld niet waneer de security researcher het heeft proberen te melden dat de keys nog niet ingetrokken zijn. En omdat het artikel ook niet duidelijk toont daar navraag naar gedaan te hebben lijkt het er op dat dit nog niet heel lang bekend was. Het zou bijvoorbeeld prima kunnen dat de security researcher pas onlangs, zoals na het interview met het bedrijf, gecontroleerd heeft of de keys ingetrokken waren en dus nog maar kort contact probeert te krijgen.

[Reactie gewijzigd door kodak op 22 juli 2024 18:47]

[maartenvdezz]

Ben het niet met je eens dat dit een configuratiefoutje is die "kan gebeuren": een volwassen cloudomgeving zou genoeg policies (organizational policies/azure policies/policy engine in de CI/CD pijplijn) moeten hebben om te voorkomen dat resources uberhaupt via het publieke internet benaderbaar zijn.

[Reactie gewijzigd door maartenvdezz op 22 juli 2024 18:47]

[mjtdevries]

Waarom waren on-premise omgevingen wel volwassener zodat dit niet om de haverklap gebeurdde?

[CEx]

Dat waren ze niet.
Je moest alleen eerst de voordeur door komen voordat je zag dat de kluis openstond.

[mjtdevries]

Is het in de cloud niet mogelijk een zelfde voordeur te maken?
Volgens mij wel, maar de verleiding is waarschijnlijk te groot om dat niet te doen, terwijl het on-prem vanzelfsprekend was om het wel te doen.

[TheMak]

Toen moest je maar gokken op welke server de gitserver stond. En of ze er een hadden draaien. En dan nog een gebruikersnaam gokken. Nu kan je bij azure gewoon alle bedrijven afgaan.

[_PieterZ]

Vorig jaar kregen wij in het team een nieuwe manager. Het eerste wat hij deed was verschillende Azure policies instellen op onze productieomgeving, die dit soort menselijke fouten voorkomen bij het daadwerkelijk niet toestaan van de handeling. Het was een flinke klus, maar uiteindelijk zorgt het wel voor een veilige omgeving.

[Raymond Deen]

Kudos voor de manager.
Pijn zo vroeg mogelijk pakken als het niet vanaf het begin zo is geïmplementeerd.

[rvt1]

En bizar dat een manager dat doet en dat dit niet al is ingeregeld door een team dat de IT binnen een omgeving regelt.

Ik moet ook zeggen dat dit soort omgevingen bij de cloud diensten blijkbaar vaak zo staan ingesteld dat je snel kan spelen en iets bouwen, maar dat er te kort wordt nagedacht over de fouten die mensen eventueel kunnen maken voor het in bedrijf stellen van dit soort omgevingen.

[StackMySwitchUp]

Aan de ene kant bizar dat een manager het doet, aan de andere kant, IT'ers weten vaak het belang wel van dit soort implementaties, maar als je management niet meekrijgt voor uren/kostenbudget dan kun je op je kop gaan staan maar het blijft lekker open staan.

[_PieterZ]

Zeker jammer dat het niet vanaf het begin is opgepakt door het team. Maar niet alle bedrijven kunnen vanaf het begin een schaalbare en veilige Azure/Cloud omgeving optuigen. Dit is veelal bijvoorbeeld nog niet nodig, omdat er toch maar enkele servertjes en applicaties draaien, of omdat er je het management niet mee krijgt zoals @StackMySwitchUp aangeeft. Dit is waarschijnlijk ook het geval geweest bij BMW. In de loop der jaren groeit het bedrijf zodanig dat het opeens wel een probleem wordt, en dan worden er mensen aangenomen om dit op te pakken.

Ik moet wel eerlijk toegeven, Microsoft mag wel wat meer hun Azure gebruikers opvoeden met best-practices.

[StackMySwitchUp]

Dit doen ze wel maar Azure is een teringzooi.. je hebt enorm veel valkuilen die niet zonder meer duidelijk zijn.
Wat inmiddels wel meer en meer begint te komen is dat de default settings tegenwoordig restrictiever zijn, zo ook azure storage. Als je een nieuw storage account aanmaakt zonder de instellingen aan te passen is deze by default private, waar dit vroeger altijd standaard open stond. Ook wordt bij instellingen die niet secure zijn geadviseerd om er iets mee te doen (uiteraard met extra diensten van Microsoft)

[TheVivaldi]

Liever dat een manager dat doet dan dat helemaal niemand het doet, zo kun je het ook bekijken.

[roelboel]

‘per ongeluk openbaar was gemaakt in plaats van privé door een verkeerde configuratie’.

Dat vind ik niet het grootste probleem. Het opslaan van geheimen in zo'n "bucket", daar gaat het al fout.

[david-v]

Volledig mee eens. Wat doen private Keys in een storage/bucket, daar heb je (key)vaults voor.

Edit:typo

[Reactie gewijzigd door david-v op 22 juli 2024 18:47]

[Rob Coops]

Ja en nee... Als je er van verzekert bent dat de bucket prive is en alleen toegankelijk voor een klein aantal mensen die de key mogen gebruiken dan is het niet geheel onredelijk om de key in die bucket te plaatsen. Zeker als er op dat moment voor zo ver jij weet geen betere methode zijn om de keys te delen.

Als security team is dit erg slecht, een prive bucket zou niet zo maar open moeten kunnen staan. Een bucket met een key of andere gevoelige data er in zou opgemerkt moeten worden, mensen binnen de organisatie ongeacht hun niveau zouden toegang moeten hebben tot veilige tools om dit soort gevoelige data te delen en zouden ook moeten weten hoe en dat ze dit tools moeten gebruiken.

Ik kan het de persoon die de keys in de bucket gooide moeilijk kwalijk nemen, ondanks dat ze beter zouden moeten weten is, en ik dank dat we dat allemaal wel weten als we voor een groot bedrijf gewerkt hebben, het geheel denkbaar dat dit de beste methode was die ze voorhanden hadden.

Het had nooit mogen gebeuren maar het zal altijd gebeuren zeker in grote organisaties waar duizenden mensen werken is er altijd wel iemand die een fout maakt. Maar er zijn wel erg veel steken die men heeft laten vallen om dit lek mogelijk te maken, en dat is toch echt de schuld van de organisatie en niet van het een persoon.

[david-v]

Als je er van verzekert bent dat de bucket prive is en alleen toegankelijk voor een klein aantal mensen die de key mogen gebruiken dan is het niet geheel onredelijk om de key in die bucket te plaatsen. Zeker als er op dat moment voor zo ver jij weet geen betere methode zijn om de keys te delen.

Nee, het is nooit goed om keys op een storage te plaatsen. Daar heb je andere services voor. Dit is hetzelfde als het opslaan van keys in een excel op het intranet waar je mensen rechten toe geeft. Dat doe je niet zo, daar zijn al heel lang betere oplossingen voor.

Een keyvault in azure wordt al bij een introductie cursus van Azure voor managers al uitgelegd. Dus als je niet eens weet dat zoiets bestaat dan heb je echt heel weinig kennis. De consequentie zie je nu dus....de "excel" was ineens in te zien door een foutje in de configuratie. Heel kwalijk.

Maar eerlijk gezegd verbaasd het me niet. Ik heb al eerder met een autobouwer te maken gehad...de legacy systemen die ze daar hadden....daar schrik je echt van. Security was ver te zoeken.

[Rob Coops]

Ik ben het geheel met je eens er zijn betere methode om keys op te slaan maar die moeten wel beschikbaar zijn en als loonslaaf moet je er wel van op de hoogte zijn dat ze beschikbaar zijn.

Nogmaals ik kan helemaal begrijpen dat je er voor kiest om het dan maar zo te doen als je geen andere optie denkt te hebben binnen het bedrijf. Je kan nog zo veel weten over hoe het zou moeten maar dat wil niet zeggen dat een bedrijf je ook de mogelijkheid geeft er gebruik van te maken.
Werkent voor een bedrijf dat met zo wel AWS als Azure en Google cloud werkt als partner waar dus elke developer met minimaal een cloud per dag aan de slag is kan ik je er van verzekeren dat iedereen weet hoe het zou moeten. Maar dat wil niet zeggen dat iedereen altijd de noodzaak ziet of op de hoogte is van welke tool men zou moeten gebruiken en dus er voor kiest dan maar even zo te doen want haast haast haast.
Het is niet alleen een automaker, banken zijn net zo slecht en overheden minimaal zo slecht. Gezondheidszorg en security laat me niet lagen, transport en logistiek als ze eindelijk de jaren '80 eens achter zich zouden laten dan zouden we misschien ooit ergens kunnen komen. Verzekeringsmaatschappijen wow laat me niet lachen en dan de gehele FMCG wereld die hebben er echt geen kaas van gegeten. Pharmaceuticals ja ze piepen er vaak over maar als puntje bij paaltje komt is het toch echt niet anders dan de rest van de bende.

Nogmaals ik zie dit niet als een fout van een persoon maar eerder een falen van het bedrijf. Er zijn flink wat punten waarop dit probleem voorkomen had kunnen worden en dat is natuurlijk ook op het individuele niveau maar voornamelijk op het niveau van de organisatie waar men ernstig heeft gefaald. Je moet er als organisatie simpel weg van uitgaan dat er altijd iemand is die iets doms doet. Zeker als je duizenden mensen in dient hebt zit er altijd een kneusje tussen. Dus hoe meer mensen je in dienst hebt hoe belangrijker het is dat je die controle goed uitoefent en voorkomt dat menselijke fouten tot grote schade leiden.

[gimbal]

Dat is het verschil. Mensen beredeneren altijd vanuit de ideale situatie. Tuurlijk "moet" je een vault gebruiken, daar is het voor gemaakt! En dat doe je ook in code die je zou schrijven als je een prive project aan het draaien bent of bij een startup lekker greenfield bezig bent.

Maar "echte" applicaties, degene die je in het wild tegen komt... zelden maak ik de ideale situatie mee. Er zit altijd een laag plakkerige stinkolie overheen vanwege budget, gebrek aan FTEs, legacy, etc.

[Reactie gewijzigd door gimbal op 22 juli 2024 18:47]

[Ray_]

...in de ontwikkelomgeving van BMW...

Lees ik het nou goed dat behalve deze flater ook private keys van productie in een ontwikkelomgeving worden gebruikt?

[Alcmaria]

Toevallig net deze week mijn nieuwe auto opgehaald.. en het viel me wederom op dat een auto ondertussen een rijdende computer is geworden met continue verbinding met het internet om allerlei diensten aan te kunnen bieden. Bijvoorbeeld op afstand starten, verkeersinfo ophalen of je zien of je deuren op slot zijn. Probleem lijkt een beetje te zijn dat, vooral de wat meer established merken, nog een beetje achterlopen met hun infrastructuur. Het werkt wel.. maar ..tja.. er is nog flink wat ruimte voor verbetering aan de voorkant, maar dus ook aan de achterkant, zoals al meerdere keren is gebleken.

Hun corebusiness was natuurlijk altijd auto's bouwen met goede motoren die lang mee moesten gaan.
Nu zijn ze halve ruimteschepen aan het bouwen en die transitie gaat niet altijd smooth.

[Pannekoek17]

De meest automerken mogen zeker werken aan hun digitale capaciteiten, al zou je je ook af kunnen vragen hoe noodzakelijk het is of je op afstand weet of je deuren open staan. Misschien is dat ook de reden dat veel van die functies nu ineens uit de grond gestampt moeten worden? Fabrikant dacht niet dat het waarde toevoegt, consument heeft er geen vraag naar. Tot de Tesla hype ervoor zorgde dat de auto een hippe gadget moet zijn. Beetje kort door de bocht (pun intended) maar in de kern is dat denk ik wel een groot deel van de reden.

Al vraag ik me wel af waarom die autofabrikanten er zo'n moeite mee hebben dit te maken. De functies verkeersinfo ophalen en zien welke deuren er open staan, dat kan mijn auto van 14 jaar oud ook, alleen niet op afstand starten (maargoed dat is vrij nutteloos als je niet ook op afstand kan rijden). Die bestaande opties in een digitale (cloud)omgeving samenvoegen moet dan toch kunnen in al die jaren?

[Yalopa]

Is het nu een Server of een Storage Account? Op Azure steek je keys in een Key Vault, was het dat?

Zeer onduidelijk artikel

[GrooV]

Het was dus een Azure Storage bucket die public stond, maakt wel een verschil. "Azure server" impliceert een compute instance die niet goed geconfigureerd was. Hier was niks mis met de server, BMW had hem alleen publeiekelijke gezet ipv private. Dit is in 1 druk op de knop te fixen

Ja ik weet het, alles op het internet is een server maar laten we de cloud diensten wel even goed bij hun naam noemen

[Reactie gewijzigd door GrooV op 22 juli 2024 18:47]

[_Thanatos_]

Dus het was een server, maar geen Server

[theduke1989]

Azure omgeving met Bucket naam erin.

Die hebben het niet goed voor elkaar, die willen vast over op AWS. dus doen ze alsof Azure hier de foute is.

[4tro]

Je moet er ALTIJD naar streven om zo eenvoudig mogelijk over te kunnen stappen van cloud naar cloud.

[pe0mot]

Dus geen Azure Key Vault?
Waar laat je de keys op een cloud naar cloud oplossing?

[4tro]

Meerdere opties:
- KMS encrypted data in je git repo met SOPS.
- Hashicorp vault

[DigitalImplant]

Ik denk niet dat je altijd moet streven naar een cloud agnostische oplossing. Dat ligt ook aan je business case en in hoeverre je bereidt bent bepaalde risico's te accepteren. Multi-cloud heeft een prijskaartje.

Wat betreft Hashicorp: dit is ook niet echt open source meer te noemen met de recente licenses veranderingen naar Business Source License.

[4tro]

Je moet altijd streven, maar inderdaad is het vaak te duur en zul je concessies moeten doen.

[neevedr]

Er horen geen sleutels in je Git repo te staan, ook niet encrypted.

[directjohan]

Dit was ook mijn mening tijdens een discussie bij mij huidige werkgever. Maar uiteindelijk had ik er, na ik zelf ook moest toegeven, er te weinig argumenten voor.

Wat zijn jouw argumenten hiervoor? Het voelt fout, maar veel verder dan dat kwam ik niet.

Wij werken nu met bitbami sealed secrets

[4tro]

Wij zijn bezig met SOPS, het grote voordeel is dat je gitops vele malen makkelijker wordt als je gebruik maakt van encrypted wachtwoorden in je repository.

Stel bijvoorbeeld dat je een wachtwoord wijzigt in bijvoorbeeld vault, hoe gaat je gitops pipeline snappen dat er een redeploy gedaan moet worden

[Reactie gewijzigd door 4tro op 22 juli 2024 18:47]

[Mr. Jinx]

Die hebben het niet goed voor elkaar, die willen vast over op AWS. dus doen ze alsof Azure hier de foute is.

Dat is herkenbaar zeg. Ik heb ook in een omgeving gewerkt waar de ontwikkelaars graag met AWS wilde werken, maar vanuit het bedrijf was bepaald om alles in Azure te doen.

Wat je dan krijgt is dat mensen dan gaan muiten. Telkens als er iets niet werkt is het de schuld van Microsoft. Voor elk wissewasje wordt een incident aangemeld bij Microsoft, maar keer op keer bleken het gewoon fouten te zijn in de deployment zelf, gebrek aan kennis, laksheid, onkunde, etc.

[_PieterZ]

Vreemd dat je dan bij dat bedrijf aan het werkt gaat. Mij lijkt het vrij logisch om alleen te solliciteren bij bedrijven waarbij ik ook zin heb om met de technologie aan de slag te gaan. Als ik gespecialiseerd ben in Azure, zou ik niet snel interesse hebben in een bedrijf wat alles in AWS heeft zitten.

[mastair]

Misschien was van hogerhand wel bepaald dat ze over moesten naar Azure?

[0c2]

Gaat het hier niet om een Azure storage container? Bucket lijkt me meer een AWS term?

[4tro]

Het boeit niet, het is allemaal hetzelfde, object based storage.
Vasthouden aan de naamgeving van je favoriete cloud provider is vrij nutteloos. Iedereen weet wel ongeveer wat er bedoeld wordt met een bucket. (vooral aangezien AWS en Google cloud het allebei hebben over een bucket)

Je zal altijd zoveel mogelijk Cloud agnostisch moeten ontwikkelen, zodat je niet jezelf in 1 vendor opsluit

[david-v]

En een bucket is cloud agnostisch? Ik ken het alleen van AWS dus voor mij was het ook even verwarrend

[david-v]

Je zal altijd zoveel mogelijk Cloud agnostisch moeten ontwikkelen, zodat je niet jezelf in 1 vendor opsluit

Dat kan , maar uiteindelijk heb je alsnog een stuk code die wel aansluit op wat de cloudservice te bieden heeft.

Ik heb ook eerlijk gezegd nog nooit een cloud wissel gezien bij een bedrijf. Je maakt een keuze voor een bepaalde technologie en daar ga je ook voor. Wel kan je verschillende diensten gebruiken uit meerdere cloud aanbieders. Dat zie ik wel vaker. Maar in het geheel wisselen? Nog niet meegemaakt.

Edit:typo

[Reactie gewijzigd door david-v op 22 juli 2024 18:47]

[pe0mot]

Yep, wij proberen opensource software op verschillende hosting aan te passen.
Docker, AWS, AKS, K8S allemaal bedienen met dezelfde source is een ramp.

[DigitalImplant]

Lijkt me inderdaad dat het hier om Azure Blob Storage gaat. Bron spreekt ook over een bucket maar dat is terminologie die niet gebruikt wordt in de context van Azure.

[latka]

Als we nou gewoon stoppen met dingen een moeilijke naam geven... het was gewoon een harde schijf van iemand anders met jouw data erop. Hoe het heet is irrelevant.

[Yalopa]

Dit is tweakers, je mag verwachten dat over tech onderwerpen correct en met kennis van zaken geschreven wordt, of niet geschreven wordt.

In cloud is er een verschil tussen disk storage en object storage, dat is niet moeilijk, dat is absolute basiskennis in cloud.

[latka]

Maar voor het lekken maakt het niet uit. Dat is mijn punt in deze.

[DigitalImplant]

Ik zal de laatste zijn die Microsofts productnamen gaat verdedigen, maar dingen een naam geven is moeilijk, zeker als het gaat om (technische) producten.

Blob Storage een harde schijf noemen van iemand anders is iets te kort door de bocht. Uiteindelijk zal er een harde schijf onder zitten, maar Blob Storage is veel meer dan dat. Het kan zowel een snelle ssd zijn, of een tape, of een data lake voor analytics. Er is automatische data retentie en archivering, immutable storage, uitgebreide access control, regio gebaseerde data redundancy, etc. Het is een dienst op zich, rondom het opslaan van data.

[Reactie gewijzigd door DigitalImplant op 22 juli 2024 18:47]

[latka]

2 dingen: bij cloud maakt het niet uit wat eronder zit: je neemt een dienst af met bepaalde kenmerken. En 2 tweede: het maakt helemaal niks uit wat het is, als jouw data op andermans apparaat zit moet je je afvragen wat je precies aan het doen bent. Leuk dat er retentie en backups zijn, maar dat bekent ook dat, als het goed is, je een foutje (private key bijv) niet direkt kunt wissen, want retentie...

[david-v]

En dus moet je het wel noemen zoals het hoort, zodat je weet wat voor eigenschappen het heeft. Een bucket is ook geen generieke naam en is dan ook verwarrend in dit artikel.

[Mimiix]

Bucket is Google.

Gaat inderdaad om een container