SolarWinds-hackers kregen toegang tot deel broncode van drie Microsoftproducten

Hackers achter de SolarWinds-aanval hebben toegang gekregen tot bronbestanden van Microsoft Azure, Exchange en Intune. Dat blijkt uit een intern onderzoek van Microsoft. Volgens het bedrijf ging het om een klein aantal bestanden.

Eerder maakte Microsoft al bekend dat de indringers bij broncode van het bedrijf konden komen. Nu blijkt dat het om drie specifieke producten gaat: de clouddienst Azure, de cloudmanagingdienst Intune en de mail- en agendadienst Exchange.

Microsoft concludeert dat in een inmiddels afgerond intern onderzoek. Daarin schrijft Microsoft ook dat er geen bewijs is gevonden dat de aanvallers toegang hadden tot gegevens van klanten en dat er geen aanwijzingen zijn dat systemen van Microsoft gebruikt zijn bij aanvallen op anderen.

De aanvallers hebben wel kunnen zoeken in enkele broncode-repositories. Binnen Microsoft kunnen alle medewerkers code van producten en diensten inzien, maar zij kunnen de code niet wijzigen. De aanvallers waren in de coderepositories op zoek naar bedrijfsgeheimen, maar volgens Microsoft is het niet toegestaan om bedrijfsgeheimen in code te schrijven en wordt daarop altijd gecontroleerd. Daardoor hebben de aanvallers geen bedrijfsgeheimen buit kunnen maken.

In december kwam Microsoft erachter dat aanvallers eind november een bronbestand hadden ingezien, waarna het onmiddellijk toegang tot de systemen ontzegde. Volgens Microsoft hebben de aanvallers tot begin januari opnieuw geprobeerd om toegang te krijgen tot de systemen, maar zijn ze daar niet in geslaagd. Het bedrijf zegt dat de aanvallers geen toegang hadden tot de volledige bronbestanden van Microsoftproducten terwijl ze in de repositories aan het zoeken waren, maar alleen tot een paar afzonderlijke bestanden.

Daarbij gaat het om een klein aantal bronbestanden van Azure, gericht op diensten, beveiliging en identiteit, en enkele bestanden van Intune en Exchange. Daarbij hebben de aanvallers geen inloggegevens kunnen vinden van accounts met bijvoorbeeld adminprivileges. Eerder meldde Microsoft dat de hackers verschillende interne accounts hadden overgenomen, waarvan er een is gebruikt om broncodes op te zoeken. Dat account had geen toestemming om de code aan te passen.

De omvangrijke SolarWinds-aanval kwam in december aan het licht. Volgens de Amerikaanse overheid zijn minimaal honderd bedrijven en negen overheden daardoor getroffen. Dat aantal is lager dan eerdere schattingen, maar kan nog oplopen.

Reacties (78)

[DDX]

Maar is de broncode dan geen bedrijfsgeheim ?
Ook gek dat alle medewerkers (lijkt me stug trouwens) broncode kunnen inzien.

[etiennebruines]

In het onderzoek gaat het specifiek om "secrets", zoals wachtwoorden en access tokens. Die horen inderdaad niet in broncode thuis.

De vertaling "bedrijfsgeheimen" is dan ook niet op zijn plaats.

[Verwijderd]

Ja en nee, de broncode van Microsoft producten is uiteraard bedrijfsgeheim zoals met de meeste gesloten software. Echter hebben ze een redelijk open beleid, wat ook wel moet met zoveel ontwikkelaars verdeeld over de wereld en hun meer 'open-source' benadering. Ik betwijfel ook de uitspraak in dit artikel 'Binnen Microsoft kunnen alle medewerkers code van producten en diensten inzien, maar zij kunnen de code niet wijzigen.'

Echt niet alle medewerkers zullen toegang hebben tot de source (die beschikbaar is in Github) maar enkel de medewerkers die bijvoorbeeld een technische functie. Zo kan men eenvoudig kennis delen over producten. Die medewerkers zullen ook gewoon een geheimhoudingsverklaring hebben afgegeven.

[field33P]

Het idee erachter is dat wanneer iemand bij het Office-team tegen een bug in Windows aanloopt die persoon gelijk een wijziging aan de code kan voorstellen in plaats van louter de bug melden.

[Verwijderd]

Uiteraard, het is niet enkel tot kennisdeling beperkt.

[TWyk]

De broncode van diverse windows producten is op speciaal inzichtelijk voor bepaalde overheden die een security review willen laten uitvoeren.
De Azure code zal wel privaat zijn.

[field33P]

Microsoft doet niet aan security through obscurity, ze doen aan security by design. Dat is iets anders dan de broncode zomaar online gooien.

Ow.. windows platform is wereldkampioen security fouten...

Dat is omdat ze het grootste platform zijn en daarmee logischerwijs het grootste doelwit zijn voor cybercriminelen. macOS-gebruikers waanden zichzelf jarenlang ten onrechte veiliger dan Windows-gebruikers, maar toen het marktaandeel van Apple toe begon te nemen gingen hackers zich ook steeds meer richten op de makkelijke doelwitten die Mac-gebruikers waren (immers hadden zij een onjuist veiligheidsgevoel dankzij de jarenlange 'Macs krijgen geen virussen'-marketingcampagnes van Apple), waardoor er best wel wat (soms ronduit slordige) beveiligingsfouten aan het licht kwamen.

[tweaknico]

De eerste 30 jaar van het bestaan van Microsoft was security zeker geen onderdeel van het design proces. Op z'n best in het patch proces. Daarna was er een jaar of 5 veel marketing om security.
NT 3.x was mogelijk de uitzondering in de eerste 30 jaar, maar de features van 4.0 en win32 maakten het een meer Bug compatible met de voorgangers.
Maar ik volg het al een jaar of 10 niet meer, voor mij is het minder relevant geworden.

[--Andre--]

In de NT reeks, tot en met windows xp had een gebruiker standaard administratorrechten, om maar iets te noemen. De reputatie van slechte beveiliging was misschien niet helemaal onterecht. En als is Windows veiliger geworden, de reputatie loopt achter de feiten aan.

[Jim80]

Ik ben toch blij met mijn VPS met full disk encryption waar zelfs de provider geen toegang tot heeft.

[True]

Lijkt mij sterk, hoe decrypt je je disken dan bij booten van je VPS? Waarschijnlijk via de console, wie heeft toegang tot de console?

[Jim80]

Dat is eenvoudig op te lossen. De install doe je inderdaad via de webconsole maar daar gebruik je een tijdelijk wachtwoord. Vervolgens log je in via SSH en wijzig je alle wachtwoorden.

Bij een reboot moet je dan wel terug via de webconsole je disk unlocken, maar dan opnieuw wijzig je terug via SSH

[DR.V]

De key is dan toch alsnog gewoon uit het RAM te dumpen?

[True]

Jij wijzigt je disk encryptie password na elke reboot via SSH?

[Jim80]

yes

[smiba]

Typisch voorbeeld van genoeg kennis hebben om schade te doen, niet genoeg kennis te hebben om te weten wat je daadwerkelijk doet.

Bij het veranderen van het wachtwoord past het enkel jou key aan die de master key unlocked. (tenslotte moet hij andere iedere keer de complete disk opnieuw encrypten) -- Het aanpassen van je wachtwoord na iedere reboot is enkel een extra stap, die eigenlijk weinig aan de beveiliging doet.
(Ik moet eerlijk zeggen ik heb mijn twijfels of je dit daadwerkelijk doet of gewoon wat lult )

Je master key is trouwens ten alle tijden in het ram geheugen ingeladen, anders kan die natuurlijk niet bij je data komen. Gezien het een VM is, is het dumpen van het geheugen terwijl deze aanstaat gelukkig peanuts.

Maak je ook "snapshots" of backups van je VM terwijl deze aanstaat? Grote kans dat je je master key al herhaaldelijk hebt gedumpt dan

[Reactie gewijzigd door smiba op 25 juli 2024 22:59]

[mjz2cool]

Dus je wacht elke keer uren tot de encryptie volledig opnieuw is gedaan? (afhankelijk van de diskgrootte natuurlijk)

[Gomez12]

Tja, we hadden een uptime van 99,9. Maar nu hebben we een uptime van 80, want Bigjim80 heeft full disk encryptie op zijn manier aangezet...

[mjz2cool]

Nouja in principe kan het wel, want je wachtwoord is niet hetgeen wat je disk decrypt. Je wachtwoord decrypt de encryption key, en die wordt weer gebruikt om de disk te decrypten. Als je je wachtwoord verandert hoef het systeem dus alleen die key opnieuw encrypten.

[FreshMaker]

* FreshMaker twijfelt of@Jim80 uberhaupt wel een vps heeft

[Gomez12]

Half,half als ik luks goed voor de geest heb.

Je hebt afaik 1 master-password en dat is waarop je disk ge-encrypt is.
En daarnaast heb je een account-systeem waar je meerdere "accounts" kan maken waarmee je de disk kan benaderen.

Echter als je zegt alle wachtwoorden te wijzigen, dan moet je ze ook allemaal doen en dus ook je master en dan krijg je alsnog wel een re-encyptie.
Of je laat je master-wachtwoord voor eeuwig hetzelfde en hoopt dat niemand er ooit bijkomt en wijzigt alleen je account-wachtwoorden.

Het enige wat ik niet voor de geest heb is de huidige status / werking. Ik zou me best kunnen voorstellen dat men uit gebruikersvriendelijkheid gewoon het master-password niet meer laat ingeven, maar dit genereert en ergens dumpt zodat de beheerder het kan opslaan. Waardoor de user geen idee heeft dat er nog een master-password is.
Puur omdat in het begin het grootste probleem simpelweg zat bij een te makkelijk door de user ingegeven master-password. Waardoor het hele systeem omviel

[tweaknico]

Dat is enkele seconden. De binary encryption key wordt niet aangepast, alleen de manier waarop die bij boot beschikbaar gesteld wordt.

Zolang de VPS up is, is de data makkelijk beschikbaar vanuit het systeem (die kan wel overal bij).
En de hoster kan het RAM image afdumpen etc. etc.

[mjz2cool]

Dat heb ik in een nieuwe reactie inderdaad ook verduidelijkt, de encryption key zelf wordt niet aangepast, waardoor opnieuw encrypten niet nodig is.

[GertMenkel]

Klinkt erg inefficiënt. Ik zou DropbearSSH in je initramfs zetten, dan kun je ook gewoon over SSH de sleutel opgeven. Je public key in de dropbear config en je bent klaar. Zo hoef je ook niet de webconsole van je VPS-provider in na een reboot.

[SunnieNL]

dus zolang jij de disk unlocked hebt is de data toegankelijk?
Dan kan het toch nog steeds gestolen worden? Een hacker gaat het systeem echt niet rebooten. Als die binnen is kan die dus gewoon bij de data?

[DDX]

En wie heeft er toegang tot het geheugen van de machine ?

[JackBol]

Dit. Die key staat gewoon in RAM.

[23m3]

De key kan prima in versleutelde vorm in het geheugen staan. Maar beter nog: helemaal niet in het geheugen staan. De sleutel kan bijvoorbeeld in een versleuteld bestand staan, wanneer nodig uitgelezen worden en vervolgens direct uit het geheugen verwijderd (overschreven) worden.

[JackBol]

Als die sleutel versleuteld in het RAM staat, waar staat dan de sleutel waarmee die sleutel versleuteld is? Ook in het RAM. En als die versleuteld op disk staat, idem.

En hoe moet die disk driver zonder key elk block decrypten als deze van de schijf leest?

[Reactie gewijzigd door JackBol op 25 juli 2024 22:59]

[23m3]

Wat dacht je van in een TPM? Maar goed, het principe is natuurlijk dat als je eenmaal fysiek toegang tot een machine hebt, je niet meer tegen bent te houden. De vraag is alleen hoeveel moeite je nog moet doen.

[JackBol]

Dat is het hele punt. All bets are off bij fysieke toegang. Het encrypten van de VPS omdat je de cloudpartij niet vertrouwd is zinloos.

Daarnaast is het veel makkelijker om de hypervisor aan te passen en de host de indruk te laten wekken dat de encryptie succesvol is. Of als je zelf je VPS encryptie schrijft, de pRNG van de hypervisor wijzigen zodat je de RNG kan predicten en eenvoudig de N kan factoriseren.

En ook voor die TPM moet je door de hypervisor heen, welke een vTPM aanbiedt aan de VM. Daar kan een malicious cloud provider makkelijk tussen gaan zitten.

[Reactie gewijzigd door JackBol op 25 juli 2024 22:59]

[RGAT]

En die fysieke TPM werkt hoe goed in een VPS?
Ja het kan een vTPM zijn maar binnen de context van de Solarwinds hack (best wel stukje kwaliteits-hackers) kan je die niet zo vertrouwen...

[Sixie]

more like... wie heeft het key

[DarrylvdP]

Dat ligt er wel aan wat voor maatregelen de provider heeft genomen, Hyper-V kent bijvoorbeeld "Shielded VMs". Zie:
https://techcommunity.microsoft.com/t5/data-center-security/what-are-shielded-vms-in-windows-server-2016-hyper-v/ba-p/372179

Hiermee voorkom je dat degene die jouw virtuele machine draait, of dat nou intern of extern is, bij de data kan komen. Ik denk inderdaad zoals jij aangeeft dat vele zich erin vergissen dat een kopie van de VHDX of VMDK betekent dat diegene die overal kan draaien en kan brute-forcen totdat ze een ons wegen zonder dat iemand dat ziet.

[EraYaN]

Zelfs dan als degene die je niet kunt vertrouwen je hypervisor en de hardware voor je beheert? Dan doen ook Shielded-VMs niets, al helemaal niet vanaf de host (die die VMs toch echt gewoon in memory heeft draaien).

[smiba]

Volgens mij zijn Shielded VMs meer voor als je je buren op de Hypervisor absoluut niet vertrouwt.

De hosting provider moet je altijd vertrouwen, zelfs al zou je een dedicated server hebben is er enig vertrouwen nodig. Tenslotte heeft je provider fysieke toegang

[dec0de]

De V in VPS staat voor "niet echt"

Het is gewoon niet jouw eigendom, dus je moet maar hopen dat de VPS provider betrouwbaar is.
Realistisch gezien is er natuurlijk niet zo veel aan de hand

[Reactie gewijzigd door dec0de op 25 juli 2024 22:59]

[Jim80]

VPS provider mag dan nog betrouwbaar zijn, als die provider gehacked wordt ben je alsnog kwetsbaar.
Vandaar full disk encryption, dan kan enkel jij aan je data (als je overige beveiliging tenminste op orde is)

[dec0de]

je weet dat de EFI partitie nooit encrypted is, en dus die dus aangepast kan worden en zo de disk encryptie password kan afleiden? (bij boot een log bestandje aanmaken op de EFI partitie waar het encryptie wachtwoord opstaat, en de GRUB bootloader aanpassen).

een slimme hacker logt al van alles en nogwat voor dat ze bekend maken dat er gehackt is.

[Jim80]

Dat gelogd wachtwoord is dan toch ongeldig.... want dat wordt bij elke reboot gewijzigd via SSH omdat je de disk enkel kan unlocken via de webconsole. Dus dat eerste wachtwoord is sowieso 'burned'

[dec0de]

dit moet jij mij even uitleggen, je hebt full disk encryption, maar met elke boot veranderd het wachtwoord?

van wat ik van jouw sitiuatie begrijp: je boot de server, dan unlock je hem, en zodra je hem reboot verander je eerst het encryptie wachtwoord?

dan zijn er 2 opties:
1: het duurt elke keer uren lang om de gehele disk te her encrypten (elke bit word opnieuw geschreven)
2: bij het enrypten van de disk heb jij nooit het echte wachtwoord gezien, er word 1 hele lange random string gegenereerd, en die zin word gebruikt om de gehele disk te encrypten, en vervolgens word die string in een los bestand op de EFI partitie opgeslagen, en die word geencrypt met jouw wachtwoord (want dat duurt enkele miliseconden). dus dan kunnen zij met dat burner wachtwoord de het echte encryptie wachtwoord ontdekken

edit: Kan iemand mij uitleggen hoe mobiele encryptie écht werkt? zie dit voor betere uitleg van anderen

[Reactie gewijzigd door dec0de op 25 juli 2024 22:59]

[Jim80]

Bij het wijzigen van het wachtwoord hoeft niet de hele disk opnieuw ge-re-encrypt te worden. Althans niet bij LUKS. Het wachtwoord geeft slechts toegang tot een master key (die niet op de boot partitie staat).

Je moet dan wel zorgen dat je niet gehackt wordt tussen de enkele minuten tijd van het booten en het wijzigen van het wachtwoord.

Een geinfecteerde boot partitie biedt misschien inderdaad wel mogelijkheden, maar dat gaat ook al ver.

[Reactie gewijzigd door Jim80 op 25 juli 2024 22:59]

[Gomez12]

Let op dat jij dan dus niet het master-wachtwoord wijzigt, je wijzigt alleen het acces-wachtwoord.

Je master-wachtwoord blijft de hele tijd gelijk (want om die te wijzigen heb je wel re-encryptie nodig)

[tweaknico]

Als het goed is is de Master-key (niet het wachtwoord) een key van veel bits die uit een RNG komt.

[OruBLMsFrl]

Deze hele discussie draait om de vraag of je nog veilig bent als de VPS provider gehacked wordt. Antwoord is nee, want ze kunnen de Master-key, ook al is het een key van veel bits die uit een RNG komt, domweg uit je VM memory dumpen. Zolang die VM draait is de master key in memory, anders kan die de eigen opslag niet meer benaderen. Eenmaal de master-key in bezit, kun je de disk clonen en decrypten. Het reguliere wachtwoord komt daar niet meer aan te pas. Een vTPM is ook weer te faken.

Conclusie: je moet écht de VPS aanbieder kunnen vertrouwen en die mag niet gehacked worden...

[tweaknico]

Daar ben ik het mee eens. @rest biedt het wel beveiliging.

[Kewne]

Dat wachtwoord is gewoon geldig op de snapshots die ze bij elke VPS provider zeker kunnen maken, zoniet al standaard hebben. En anders kunnen ze gewoon de key loggen, tenzij je via cryptsetup reencrypt de hele disk opnieuw versleuteld zal die altijd geldig blijven.

[GertMenkel]

Bij een VPS kun je er nooit van uit gaan, maar als het om fysieke hardware gaat, is dit dé reden om secure boot in te stellen.

Zelf een key genereren, alle andere keys eruit, en zorgen dat je bootloader alles goed valideert, en er is hardwareinterventie nodig om bij de sleutels te kunnen. Tenzij er een exploit in GRUB zit, natuurlijk, maar als je die regelmatig updatet is dat risico minimaal.

Bij een VPS zou ik er eigenlijk ook altijd van uitgaan dat de serviceprovider en lokale overheid bij je RAM en daarmee bij je schijfversleutelingskey kunnen komen. Ze kunnen zo het RAM dumpen en de key uitlezen zonder dat je er iets van merkt. Als je geen controle over de hardware hebt, kun je daar met software weinig tegen doen.

Dat wil ook weer niet zeggen dat schijfversleuteling niets toevoegt, als je de schijf versleutelt en de boel daarna uitschakelt, kun je er in ieder geval van uit gaan dat een nieuwe aanval tegen je data lastig is. Ook helpt het bij aanvallen op bijvoorbeeld het opslagmedium van een VPS host, stel dat je het voor elkaar krijgt om via een exploit andermans image aan jouw VPS te mounten, kun je er met versleuteling alsnog weinig mee. Daarnaast is het versleutelen van data at rest natuurlijk een vereiste van veel dataverwerkingscontracten en moet je een vorm van dataversleuteling toepassen op persoonlijke gegevens wil je aan de GDPR voldoen. Schijfversleuteling is dan een makkelijke manier om een keer extra voor de zekerheid nog de versleuteling er overheen te gooien.

[dec0de]

daar zeg je met wat, secureboot! het is natuurlijk compleet nutteloos zoals het nu is, maar als je idd alle andere keys er uit gooit, heb je waarschijnlijk een *zeer* veilige machine! even kijken of dat kan op mijn dell XPS!

thanks!

[Nibelnoya2]

Leuk,

maar bij een hack op de socket of andere low/root-level terwijl die encrypted disk accessible is, heb je niets aan die beveiliging. Dat is hetzelfde als een kluis hebben maar als een overval plaatsvindt terwijl de kluis net open stond, heb je er niets aan.

[Jim80]

Is waar, maar dan moet je al via de hypervisor aan de RAM kunnen van die VM. Of via een andere VPS een vulnerability gebruiken zoals meltdown of spectre.

Het is dus nog niet helemaal waterdicht, maar disk encryption maakt het al vele malen moeilijker. Backups of harde schijven uit de servers mogen dan al gerust op straat belanden.

[Nibelnoya2]

Dat is hardware, maar ook OS, drivers en de gebruiker zijn aanvalsvectoren. Spectre en meltdown zijn het eenvoudigst te verhelpen omdat het alleen maar hardware is en gekende aanvalsvectoren/bugs. Microcode van mainboards, het OS, drivers en dan ook nog eens de gebruiker.

Dus ja het zo'n diskencryptie helpt, maar het is net als een airbag in een auto. Het is een deel van d maatregelen niet de gedroomde totaaloplossing welke marketing ons zo graag doet geloven.

[nvaert1986]

Full Disk Encryption klinkt leuk, maar is alleen praktisch bij fysieke diefstal of als de desbetreffende virtuele machine uitstaat / de desbetreffende storage niet gekoppeld (mounted) is en als je de desbetreffende sleutel niet automatisch bij het opstarten meegeeft. Als deze opslag namelijk gekoppeld (mounted) is en er draait een applicatie met een lek waardoor je op de server kan komen, kun je in principe gewoon bij alle data die daar opstaat en staat deze niet meer versleuteld. Je hebt de sleutel namelijk al ingevoerd om de desbetreffende opslag te ontsleutelen.

Bij PC's / laptops heb je daar een oplossing voor genaamd TPM (Trusted Platform Module) met een herstelsleutel in combinatie met Microsoft Bitlocker in Microsoft Windows, maar ook dit is niet heilig (denk bijvoorbeeld aan falen van de TPM chip / herstelsleutel die niet altijd werkt / sommige UEFI / BIOS implementaties resetten de TPM instellingen bij een UEFI / BIOS update etc. etc. (ik ben eerdergenoemde voorbeelden in de praktijk al allemaal tegengekomen).

Ik gebruik zelf altijd een LUKS2 encrypted disk, waar ik altijd m'n passphrase (sleutel) voor moet ingeven (Linux). Dit is gewoon het beste mechanisme naar mijn mening en heeft mij nog nooit in de steek gelaten.

[roelboel]

Je kunt vast bij ze solliciteren en uitleggen hoe uitleggen jouw oplossing relevant is voor hun bedrijfsgrootte en -voering.

[Jim80]

Leg mij dan eens uit waarom eender welk groot bedrijf zijn broncode toegankelijk zou moeten maken voor bedrijven zoals Microsoft?

[Verwijderd]

Denk je dat Microsoft geen full disk encryption voeren? Ze hebben zoals @DarrylvdP hier al vertelt zelf gehele producten hiervoor ontwikkeld. (Data) encryptie is echter voornamelijk nuttig voor data 'at rest'.

Bijvoorbeeld voor de USB stick van een callcenter/GGD medewerker welke alle BSN en overige persoonsgegevens van Nederland heeft geëxporteerd en nu een geheime uitwisseling maakt op een parkeerplaats besproken via het 'darkweb'. De USB stick wordt overhandigt maar pas wanneer het geld veilig op zijn rekening staat zal hij daadwerkelijk de sleutel tot de data overhandigen.... Tegen die tijd zit hij al lang op een exotisch strand en als de politie hem voor die tijd pakt, dan weet hij van niets..

Full disk encryption zou je in deze aanval niets helpen. MFA brengt de grootste barrière voor deze 'staatshackers' maar zelfs dat zal waarschijnlijk niet genoeg zijn. Dit is een hoogst professionele actie geweest.

[Jim80]

Dat mag ik hopen.... maar de sleutel voor mijn data heb ik graag zelf in handen en niet in handen van Microsoft

[klakkie.57th]

zo zou het ook altijd moeten zijn , helaas ondersteunen de meeste paas en saas opties dit niet.

[Verwijderd]

De meeste (grote) paas omgevingen ondersteunen dit wel:
https://docs.microsoft.co...-keys-configure-key-vault
https://cloud.google.com/...tomer-supplied-encryption

[klakkie.57th]

Dat haalt niets uit dat is BYOK wat je wilt is HYOK waarbij de key NIET bij de cloudprovider opgeslagen staat maar onprem

[Verwijderd]

On-prem zal waarschijnlijk wel mogelijk zijn. Thales heeft hier ook al een dienst voor ontwikkeld:
https://www.thalesgroup.c...r-breakthrough-capability
Zo te zien zijn er genoeg aanbieders die extra encryptie lagen of sleutelbeheer aanbieden:
https://www.stratokey.com/casb/gsuite-encryption
https://www.ciphercloud.com/google-suite/
https://cpl.thalesgroup.com/encryption/microsoft-azure
https://cloud.netapp.com/...azure-key-vault-explained

Geen snelle hits voor on-prem encryptie maar ik denk wel dat het kan (voor GCP in ieder geval).

Maar nu ik er verder over denk is mijn vraag echter: Waarom zou je dit willen? Wanneer je naar een cloud provider gaat wil je juist ontzorgd worden. Je gaat een bindend contract aan waarin (bv) Microsoft zegt dat deze voor versleuteling zorgt. Je belegt deze verantwoordelijkheid bij een ander en betaald daar ook voor. Als je dat niet wilt kun je veel beter eigen hardware neerzetten in een datacenter om de hoek.

Het zou dus ook kunnen dat hier gewoon geen businesscase voor te maken valt.

[klakkie.57th]

Als (Microsoft - Google - Amazon - Alibaba) de sleutels beheren , dan kunnen ze bij de data zo simpel is dat. Een oplossing zoals die van Thales werkt enkel als de cloudprovider dit ook ondersteunt.
En laat dat nu net mijn punt zijn.
Cloud gaat in sneltempo over op PAAS en SAAS. Veel software/oplossingen zijn al lang niet meer verkrijgbaar om zelf te beheren, dus het datacenter om de hoek is geen oplossing.

[Verwijderd]

Veel software/oplossingen zijn al lang niet meer verkrijgbaar om zelf te beheren
Ik ben benieuwd welke software je bedoelt? Ik snap dat sommige leveranciers geen on-premise software meer aanbieden maar er toch altijd nog wel een on-premise alternatief te verkrijgen?

Ik zag laatst nog een ziekenhuis waarbij het EPD on-prem draaide maar beheerd werd door de leverancier.
Geen idee of je dat bedoelt?

[klakkie.57th]

ik bedoel eerder zoiets:
https://azure.microsoft.c...vices/cognitive-services/
het zijn "maar" API calls

[Verwijderd]

Yep, dat is lastig. Nieuwe technieken zoals Speech AI zijn 'geboren' in de cloud. Maar mogelijk is er wel een alternatief te maken afhankelijk van wat je wilt bereiken (misschien Tenserflow?).

Vaak zie je ook dat de markt zelf een (opensource) alternatief creëert als de service populair is. Dat heeft wel een tijd nodig.

[Verwijderd]

Je kan ook je eigen sleutels beheren maar deze staan uiteraard ook nog bij Microsoft. Dat is natuurlijk ook niet anders mogelijk tenzij je de sleutel iedere keer zelf opnieuw wilt invoeren. Wat weer onwerkbaar zou zijn in de meeste omgevingen.
https://docs.microsoft.co...-keys-configure-key-vault

[mrfreeze12345]

Binnen Microsoft kunnen alle medewerkers code van producten en diensten inzien, maar zij kunnen de code niet wijzigen.

Inclusief de receptioniste? Kan me haast niet voorstellen.

[sojab0on]

word heel veel intern ge flight en getest
en denk dat ze daarom wel inzicht geven aan medewerkers , maar de meesten hebben niet de kennis om echt goed te snappen wat er staat.

broncode is leuk maar je moet er wel iets mee/van kunnen snappen.

[Schway]

*Officemanager
Die mensen doen veel meer tegenwoordig dan alleen stil zitten en mooi zijn.

En waarom niet? Misschien valt ze iets op, of wakkert het een interesse aan om te leren programmeren?
Kijken mag. Of er gebruik van wordt gemaakt is een tweede.

[sojab0on]

Intern hebben ze voorzover ik weet van mensen die ik ken ook toegang tot alle software licenties en kortingen op van alles en nog wat.

[Schway]

Korting en gratis gebruik van de producten van je werkgever lijkt mij niet zo heel gek
Gratis naar de film als je in de bioscoop werk.
Korting op schoenen in de schoenenwinkel.

[Gomez12]

Let op dat er niet staat dat alle medewerkers toegang hebben tot alle code.

Bepaalde dingen van MS zijn gewoon OS en staan op github etc, dus die kan je ook gewoon aan de receptioniste tonen. Het zal meer beheerwerk zijn om het bij de receptioniste niet te tonen, dan om het wel gewoon te tonen als het toch openbaar en voor iedereen is.

[vinkjb]

Misschien was hun windows niet up to date.

[Verwijderd]

Tijd om al je Exchange servers te updaten dus.

[well0549]

Vreselijk listig dit, met name dat ze ook maar een paar "Kleine" dingetjes bekeken hebben die totaal niet belangrijk zijn.

Zoals Authenticatie en beveiliging in Azure....

m.a.w. Ze hebben bewust naar die code gezocht.

Dat heeft extra inzichten opgeleverd.....

Hoelang is Azure nog veilig dan......

[powerboat]

terug naar onprem ?

[Bulkzooi]

Intune kan worden geïntegreerd met Azure AD (Active Directory) om te bepalen wie toegang heeft en waartoe ze toegang hebben. Intune integrates with Azure Active Directory (Azure AD) to control who has access, and what they can access.

Over een supply chainhack gesproken..