Opslagaccount Shared Key Access Uitgeschakeld

Zonder deze beveiligingsmaatregel kunnen er aanzienlijke beveiligingsrisico's ontstaan die leiden tot gegevenscompromittering, nalevingsinbreuken en reputatieschade voor de organisatie. Gedeelde toegangssleutels vormen een kritieke zwakke plek in de beveiligingspostuur, omdat ze geen individuele verantwoordingsplicht bieden, niet voldoen aan moderne beveiligingsstandaarden en langdurige credentials vertegenwoordigen die moeilijk te roteren zijn.

Implementatie

Deze beveiligingsmaatregel implementeert beveiligingsbest practices via Azure Policy, ARM-sjablonen of Microsoft Intune om cloudresources en eindpunten te beschermen volgens actuele nalevingsframeworks. Door gedeelde sleutelauthenticatie uit te schakelen, dwingt de organisatie het gebruik af van Entra ID (voorheen Azure Active Directory) voor alle toegang tot opslagaccounts, wat individuele verantwoordingsplicht, voorwaardelijke toegang en geavanceerde beveiligingsfuncties mogelijk maakt.

Vereisten en Voorbereiding

Voordat u gedeelde sleutelauthenticatie uitschakelt voor uw Azure Storage-accounts, is het essentieel om een grondige voorbereiding uit te voeren. Deze migratie vereist een zorgvuldige planning omdat alle applicaties, scripts en services die momenteel gedeelde toegangssleutels gebruiken, moeten worden gemigreerd naar Entra ID-authenticatie voordat de functie wordt uitgeschakeld. Anders riskeert u dat kritieke bedrijfsprocessen worden onderbroken en dat applicaties geen toegang meer hebben tot hun opslagaccounts. Het uitschakelen van gedeelde sleutelauthenticatie zonder adequate voorbereiding kan leiden tot uitgebreide service-onderbrekingen die de bedrijfscontinuïteit ernstig kunnen beïnvloeden. Daarom moet deze migratie worden behandeld als een strategisch project met duidelijke fasen, verantwoordelijkheden en tijdlijnen.

De primaire vereiste is dat alle toepassingen die momenteel gedeelde toegangssleutels gebruiken, moeten worden geconfigureerd met beheerde identiteiten of Entra ID-authenticatie. Beheerde identiteiten vormen de aanbevolen aanpak voor Azure-services en virtuele machines, omdat ze automatische rotatie, beveiligingsbeheer en naadloze integratie met andere Azure-services bieden. Voor externe toepassingen of on-premises systemen moet u Entra ID-serviceprincipals of gebruikersidentiteiten configureren met de juiste rollen en machtigingen. Beheerde identiteiten elimineren de complexiteit van credential management en bieden een veiligere authenticatiemethode die volledig wordt beheerd door Azure. Dit vermindert niet alleen het beveiligingsrisico, maar vereenvoudigt ook het operationele beheer door automatische rotatie en gecentraliseerde toegangscontrole.

Technische vereisten omvatten ten eerste een volledige inventarisatie van alle applicaties, scripts, services en tools die momenteel toegang hebben tot Azure Storage-accounts via gedeelde sleutels. Dit omvat niet alleen interne applicaties, maar ook externe systemen, backup-oplossingen, monitoring tools en eventuele derde partij integraties. Voor elk van deze componenten moet u identificeren welke opslagaccounts worden gebruikt, welke toegangsniveaus vereist zijn en welke Azure Storage-API's worden aangeroepen. Deze inventarisatie moet uitgebreid zijn en alle mogelijke toegangspaden omvatten, inclusief legacy-systemen, geautomatiseerde scripts, ontwikkelomgevingen en productiesystemen. Het is cruciaal om geen enkele component over het hoofd te zien, omdat zelfs één gemiste applicatie kan leiden tot service-onderbrekingen wanneer gedeelde sleutelauthenticatie wordt uitgeschakeld.

Daarnaast moet u de juiste Entra ID-rollen toewijzen aan alle identiteiten die toegang nodig hebben. De aanbevolen rollen zijn Storage Blob Data Contributor voor schrijftoegang, Storage Blob Data Reader voor leestoegang en Storage Blob Data Owner voor volledige controle. Het is belangrijk om het principe van minimale bevoegdheden toe te passen en alleen de benodigde machtigingen te verlenen die nodig zijn voor de specifieke functie van elke applicatie of service. Deze rolgebaseerde toegangscontrole zorgt ervoor dat elke identiteit alleen toegang heeft tot de resources die nodig zijn voor haar specifieke functie, wat de beveiligingspostuur aanzienlijk verbetert. Bovendien maakt deze aanpak het mogelijk om toegang te traceren naar specifieke identiteiten, wat essentieel is voor compliance en auditdoeleinden.

Organisatorische vereisten omvatten de coördinatie met verschillende teams, waaronder ontwikkelaars, systeembeheerders, security officers en compliance-managers. Elke groep heeft specifieke verantwoordelijkheden in het migratieproces. Ontwikkelaars moeten hun applicaties bijwerken om Entra ID-authenticatie te gebruiken, systeembeheerders moeten beheerde identiteiten configureren en beveiligingsteams moeten de toegangscontroles en compliance vereisten valideren. Deze cross-functionele samenwerking is essentieel voor een succesvolle migratie en vereist duidelijke communicatie, gedefinieerde verantwoordelijkheden en regelmatige statusupdates. Het is aan te raden om een projectteam samen te stellen met vertegenwoordigers van elk betrokken team om ervoor te zorgen dat alle aspecten van de migratie worden aangepakt en dat er geen kritieke stappen worden gemist.

Een andere kritieke vereiste is het uitvoeren van een grondige impactanalyse voordat u de wijziging doorvoert. Dit omvat het testen van alle applicaties in een testomgeving, het valideren van alle scripts en automatiseringen, en het verifiëren dat alle backup- en monitoringprocessen blijven functioneren. U moet ook een rollbackplan voorbereiden voor het geval dat er onvoorziene problemen optreden tijdens de productie-implementatie. Deze impactanalyse moet alle mogelijke scenario's omvatten, inclusief edge cases en onverwachte gebruikspatronen. Het testen in een geïsoleerde omgeving die de productieomgeving nauwkeurig weerspiegelt, is cruciaal om problemen te identificeren voordat ze de productie beïnvloeden. Het rollbackplan moet gedetailleerde stappen bevatten voor het snel herstellen van de oorspronkelijke configuratie indien nodig.

Ten slotte is het belangrijk om te begrijpen dat deze wijziging niet kan worden teruggedraaid zonder geavanceerde PowerShell-commando's en speciale machtigingen. Zodra gedeelde sleutelauthenticatie is uitgeschakeld voor een opslagaccount, kunnen alleen identiteiten met Entra ID-authenticatie nog toegang krijgen. Daarom is een gefaseerde aanpak met eerst een testaccount, daarna niet-kritieke accounts en uiteindelijk productieaccounts aanbevolen om risico's te minimaliseren en leerervaringen op te bouwen tijdens het proces. Deze gefaseerde aanpak stelt organisaties in staat om het migratieproces te valideren, eventuele problemen te identificeren en op te lossen, en vertrouwen op te bouwen voordat kritieke productiesystemen worden beïnvloed. Elke fase moet worden geëvalueerd en goedgekeurd voordat wordt overgegaan naar de volgende fase, wat zorgt voor een gecontroleerde en veilige migratie.

Monitoring en Validatie

Het monitoren van de status van gedeelde sleutelauthenticatie voor Azure Storage-accounts is een cruciale beveiligingsactiviteit die regelmatig moet worden uitgevoerd om ervoor te zorgen dat alle opslagaccounts voldoen aan de beveiligingsstandaarden. Monitoring omvat niet alleen het controleren van de huidige status, maar ook het detecteren van wijzigingen, het identificeren van accounts die nog steeds gedeelde sleutels toestaan en het valideren dat alle toegang correct via Entra ID wordt geauthenticeerd. Effectieve monitoring vormt de basis voor een robuuste beveiligingspostuur en stelt organisaties in staat om proactief te reageren op potentiële beveiligingsrisico's voordat ze escaleren tot incidenten. Het implementeren van een geautomatiseerd monitoringproces vermindert niet alleen de operationele last, maar zorgt ook voor consistente naleving van beveiligingsbeleid over alle Azure-abonnementen en resourcegroepen heen.

De primaire parameter die moet worden gecontroleerd is de AllowSharedKeyAccess-eigenschap van elk opslagaccount. Deze eigenschap bepaalt of gedeelde toegangssleutels kunnen worden gebruikt voor authenticatie. Wanneer deze eigenschap is ingesteld op False, worden alle authenticatiepogingen met gedeelde sleutels geweigerd, wat dwingt dat alleen Entra ID-authenticatie wordt gebruikt. Regelmatige controles zijn essentieel omdat deze instelling mogelijk per ongeluk wordt gewijzigd of omdat nieuwe opslagaccounts worden gemaakt met standaardinstellingen die gedeelde sleutels toestaan. Het is belangrijk om te begrijpen dat deze eigenschap op accountniveau wordt geconfigureerd en van invloed is op alle services binnen dat opslagaccount, inclusief Blob Storage, File Storage, Queue Storage en Table Storage. Daarom moet monitoring alle opslagaccounts in de organisatie omvatten, ongeacht hun gebruik of kritiekheid.

Gebruik PowerShell-script storage-account-key-access-disabled.ps1 (functie Invoke-Monitoring) – Automatische controle van AllowSharedKeyAccess status voor alle opslagaccounts.

Het monitoringproces moet meerdere aspecten omvatten. Ten eerste moet u regelmatig alle opslagaccounts in uw Azure-abonnementen scannen om te controleren of AllowSharedKeyAccess is ingesteld op False. Dit kan worden geautomatiseerd met behulp van Azure Policy om ervoor te zorgen dat nieuwe accounts automatisch worden geconfigureerd met de juiste instellingen, en met behulp van monitoring scripts om bestaande accounts te controleren. Azure Policy biedt een krachtige manier om compliance te handhaven door automatisch te controleren of resources voldoen aan gedefinieerde beleidsregels en, indien geconfigureerd, automatisch herstelacties uit te voeren. Het gebruik van geautomatiseerde monitoring scripts stelt organisaties in staat om regelmatig alle opslagaccounts te scannen en rapporten te genereren die de compliance-status weergeven, wat essentieel is voor auditdoeleinden en continue verbetering van de beveiligingspostuur.

Daarnaast is het belangrijk om te monitoren op authenticatiepogingen die nog steeds gedeelde sleutels proberen te gebruiken. Azure Storage biedt logging en monitoring via Azure Monitor en Storage Analytics, waarmee u kunt detecteren wanneer er nog steeds pogingen worden gedaan om gedeelde sleutels te gebruiken. Deze pogingen kunnen wijzen op applicaties of services die nog niet volledig zijn gemigreerd, wat een beveiligingsrisico en potentiële service-onderbrekingen kan veroorzaken wanneer de functie wordt uitgeschakeld. Het monitoren van deze authenticatiepogingen biedt waardevolle inzichten in het migratieproces en helpt bij het identificeren van applicaties die mogelijk zijn gemist tijdens de initiële inventarisatie. Door deze pogingen te analyseren, kunnen organisaties proactief problemen aanpakken voordat ze kritiek worden en kunnen ze ervoor zorgen dat alle toegangspaden correct zijn geconfigureerd voordat gedeelde sleutelauthenticatie wordt uitgeschakeld.

Een ander belangrijk monitoringaspect is het valideren van de Entra ID-configuratie voor alle toegangspaden. Dit omvat het controleren of beheerde identiteiten correct zijn geconfigureerd, of serviceprincipals de juiste rollen hebben ontvangen en of voorwaardelijke toegangsbeleid correct worden toegepast. U moet ook monitoren op mislukte authenticatiepogingen die kunnen wijzen op configuratieproblemen of onjuiste machtigingen. Deze validatie is cruciaal omdat een onjuiste configuratie kan leiden tot toegangsproblemen die de bedrijfscontinuïteit kunnen beïnvloeden. Regelmatige validatie van de Entra ID-configuratie zorgt ervoor dat alle toegangspaden correct functioneren en dat er geen onverwachte toegangsproblemen optreden. Het monitoren van mislukte authenticatiepogingen kan ook helpen bij het identificeren van potentiële beveiligingsbedreigingen of pogingen tot ongeautoriseerde toegang.

Voor organisaties die nalevingsvereisten hebben, zoals BIO-normen of CIS-benchmarks, moet monitoring ook bewijs verzamelen voor auditdoeleinden. Dit omvat het documenteren van de status van elk opslagaccount, het vastleggen van wanneer wijzigingen zijn doorgevoerd, het bijhouden van toegangscontroles en het genereren van rapporten die aantonen dat de organisatie voldoet aan de beveiligingsvereisten. Automatische rapportage kan dit proces aanzienlijk vereenvoudigen en zorgen voor consistente documentatie. Deze auditdocumentatie is essentieel voor het aantonen van compliance tijdens externe audits en certificeringsprocessen. Het is belangrijk dat deze documentatie volledig, accuraat en tijdig is, en dat deze wordt bewaard voor de vereiste bewaarperiode zoals gespecificeerd in de relevante compliance-frameworks. Geautomatiseerde rapportage elimineert menselijke fouten en zorgt voor consistente documentatie die voldoet aan auditvereisten.

Ten slotte moet het monitoringproces proactief zijn en waarschuwingen genereren wanneer er afwijkingen worden gedetecteerd. Dit omvat waarschuwingen voor nieuwe opslagaccounts die nog gedeelde sleutels toestaan, waarschuwingen voor pogingen om de AllowSharedKeyAccess-instelling te wijzigen en waarschuwingen voor onverwachte authenticatiepatronen. Door deze waarschuwingen te integreren in uw Security Information and Event Management (SIEM) of Security Operations Center (SOC), kunt u snel reageren op potentiële beveiligingsincidenten of configuratiefouten. Proactieve waarschuwingen stellen beveiligingsteams in staat om snel te reageren op potentiële problemen voordat ze escaleren tot beveiligingsincidenten. De integratie met SIEM- en SOC-systemen zorgt ervoor dat waarschuwingen worden gecentraliseerd en dat er consistente responsprocessen worden toegepast voor alle beveiligingsgebeurtenissen.

De aanbevolen frequentie voor monitoring is wekelijks voor kritieke omgevingen en maandelijks voor minder kritieke omgevingen. Echter, voor organisaties met strikte compliance-vereisten of die bezig zijn met een migratieproject, wordt dagelijkse monitoring aanbevolen om snel problemen te identificeren en op te lossen voordat ze escaleren tot beveiligingsincidenten of service-onderbrekingen. De monitoringfrequentie moet worden afgestemd op de specifieke behoeften en risicoprofiel van de organisatie, waarbij rekening wordt gehouden met factoren zoals de kritiekheid van de data, het aantal opslagaccounts, de complexiteit van de omgeving en de compliance-vereisten. Regelmatige evaluatie van de monitoringfrequentie en -effectiviteit is belangrijk om ervoor te zorgen dat het monitoringproces optimaal blijft functioneren en dat alle relevante aspecten worden gedekt.

Remediatie en Implementatie

Het uitvoeren van remediatie voor het uitschakelen van gedeelde sleutelauthenticatie is een proces dat zorgvuldige planning en gefaseerde uitvoering vereist. Remediatie betekent niet alleen het wijzigen van een instelling, maar omvat een complete migratie van alle toegangspaden naar moderne authenticatiemethoden. Het proces moet worden uitgevoerd in een gecontroleerde en systematische manier om service-onderbrekingen te voorkomen en beveiligingsrisico's te minimaliseren. Deze migratie vertegenwoordigt een fundamentele verschuiving in de authenticatie-architectuur en vereist daarom een gestructureerde aanpak met duidelijke fasen, successcriteria en rollbackmogelijkheden. Het succes van het remediatieproces hangt af van grondige voorbereiding, uitgebreide testing en zorgvuldige uitvoering, waarbij elke stap wordt gevalideerd voordat wordt overgegaan naar de volgende fase.

De eerste en belangrijkste stap in het remediatieproces is het identificeren en migreren van alle applicaties die momenteel gedeelde toegangssleutels gebruiken. Dit is een kritieke stap omdat het uitschakelen van gedeelde sleutelauthenticatie voordat alle applicaties zijn gemigreerd, zal resulteren in service-onderbrekingen en het verlies van toegang tot opslagaccounts. Begin met een grondige inventarisatie van alle applicaties, scripts, services en tools die toegang hebben tot Azure Storage-accounts. Deze inventarisatie moet uitgebreid zijn en alle mogelijke toegangspaden omvatten, inclusief applicaties die mogelijk indirect toegang hebben via andere services of tools. Het is belangrijk om niet alleen te kijken naar expliciete gebruikers van gedeelde sleutels, maar ook naar applicaties die mogelijk via libraries of frameworks toegang hebben tot opslagaccounts. Een volledige inventarisatie vormt de basis voor een succesvolle migratie en voorkomt dat applicaties worden gemist die later problemen kunnen veroorzaken.

Voor elke applicatie die is geïdentificeerd, moet u de authenticatiemethode migreren naar Entra ID. Voor Azure-services en virtuele machines is de aanbevolen aanpak het gebruik van beheerde identiteiten. Beheerde identiteiten elimineren de noodzaak om credentials op te slaan en te beheren, bieden automatische rotatie en integreren naadloos met andere Azure-services. Configureer een systeemtoegewezen of gebruikerstoegewezen beheerde identiteit en wijs de juiste Azure Storage-rollen toe. Systeemtoegewezen beheerde identiteiten zijn gekoppeld aan een specifieke Azure-resource en worden automatisch verwijderd wanneer de resource wordt verwijderd, terwijl gebruikerstoegewezen beheerde identiteiten onafhankelijk bestaan en kunnen worden gedeeld tussen meerdere resources. De keuze tussen deze twee typen hangt af van de specifieke architectuur en vereisten van uw omgeving. Beheerde identiteiten bieden de hoogste beveiliging omdat credentials nooit in code of configuratiebestanden worden opgeslagen, wat het risico op credential-diefstal aanzienlijk vermindert.

Voor externe applicaties of on-premises systemen moet u Entra ID-serviceprincipals gebruiken. Maak een serviceprincipal aan in Entra ID, wijs de juiste rollen toe aan het opslagaccount (zoals Storage Blob Data Contributor of Storage Blob Data Reader), en configureer de applicatie om te authenticeren met behulp van OAuth 2.0 of client credentials flow. Update de applicatiecode om de nieuwe authenticatiemethode te gebruiken en test grondig in een testomgeving voordat u naar productie gaat. Serviceprincipals bieden een veilige manier om niet-interactieve toegang te verlenen aan applicaties en services, en ondersteunen geavanceerde beveiligingsfuncties zoals certificaatgebaseerde authenticatie en voorwaardelijke toegang. Het is belangrijk om voor elke serviceprincipal het principe van minimale bevoegdheden toe te passen en alleen de benodigde rollen toe te wijzen. Regelmatige revisie van serviceprincipal-machtigingen is essentieel om ervoor te zorgen dat toegang wordt beperkt tot wat strikt noodzakelijk is.

Na het migreren van alle applicaties, kunt u beginnen met het uitschakelen van gedeelde sleutelauthenticatie. Begin met niet-kritieke opslagaccounts in een testomgeving om het proces te valideren en eventuele problemen te identificeren. Controleer zorgvuldig of alle applicaties correct werken met de nieuwe authenticatiemethode voordat u doorgaat naar productieaccounts. Deze gefaseerde aanpak stelt u in staat om het proces te valideren, eventuele problemen te identificeren en op te lossen, en vertrouwen op te bouwen voordat kritieke systemen worden beïnvloed. Het is belangrijk om na het uitschakelen van gedeelde sleutelauthenticatie voor een testaccount een observatieperiode in te lassen waarin u monitort op eventuele problemen of onverwachte gedragingen. Deze observatieperiode moet lang genoeg zijn om alle gebruiks patronen te dekken, inclusief periodieke taken en batchprocessen die mogelijk niet dagelijks worden uitgevoerd.

Gebruik PowerShell-script storage-account-key-access-disabled.ps1 (functie Invoke-Remediation) – Automatische remediatie: schakel AllowSharedKeyAccess uit voor opslagaccounts.

Het daadwerkelijk uitschakelen van gedeelde sleutelauthenticatie wordt uitgevoerd met behulp van PowerShell of Azure CLI. Het PowerShell-commando Set-AzStorageAccount met de parameter -AllowSharedKeyAccess $false wijzigt de instelling voor het opgegeven opslagaccount. Het is belangrijk om eerst te controleren of alle applicaties zijn gemigreerd door het uitvoeren van monitoring en validatie voordat u dit commando uitvoert. Een alternatieve methode is het gebruik van Azure Portal, waar u naar het opslagaccount gaat, de sectie Configuratie opent en de instelling Toegang met gedeelde sleutel toestaan uitschakelt. Ongeacht welke methode wordt gebruikt, is het cruciaal om ervoor te zorgen dat alle voorbereidende stappen zijn voltooid en dat er een duidelijk rollbackplan is voor het geval dat er onverwachte problemen optreden. Het is ook aan te raden om deze wijziging uit te voeren tijdens een geplande onderhoudsperiode om de impact op bedrijfsprocessen te minimaliseren.

Voor organisaties met meerdere opslagaccounts en abonnementen wordt het gebruik van Azure Policy sterk aanbevolen. Met Azure Policy kunt u een beleidsregel definiëren die automatisch controleert of nieuwe opslagaccounts zijn geconfigureerd met AllowSharedKeyAccess ingesteld op False, en eventueel automatisch herstelacties uitvoert. Dit zorgt ervoor dat alle nieuwe resources automatisch voldoen aan de beveiligingsstandaarden zonder handmatige interventie. Azure Policy biedt ook de mogelijkheid om bestaande resources te evalueren en rapporten te genereren die de compliance-status weergeven. Het implementeren van Azure Policy voor deze beveiligingsmaatregel zorgt voor consistente naleving over alle abonnementen en resourcegroepen heen, en elimineert het risico dat nieuwe opslagaccounts per ongeluk worden geconfigureerd met gedeelde sleutelauthenticatie ingeschakeld. Dit is vooral belangrijk voor grote organisaties met honderden of duizenden opslagaccounts waar handmatige controle niet praktisch is.

Na het uitschakelen van gedeelde sleutelauthenticatie, is het belangrijk om voortdurend te monitoren op eventuele pogingen om nog steeds gedeelde sleutels te gebruiken. Deze pogingen zullen worden geweigerd, maar het monitoren ervan kan helpen om applicaties te identificeren die mogelijk zijn gemist tijdens de migratie of die zijn geconfigureerd met oude credentials. Reageer snel op deze waarschuwingen om ervoor te zorgen dat alle toegang correct wordt geauthenticeerd. Deze monitoring moet worden gecontinueerd gedurende een periode na de migratie om ervoor te zorgen dat alle toegangspaden correct zijn geconfigureerd en dat er geen applicaties zijn gemist. Het identificeren en oplossen van deze problemen is essentieel voor het handhaven van de beveiligingspostuur en het voorkomen van toekomstige toegangsproblemen. Regelmatige analyse van deze monitoringdata kan ook inzichten opleveren in gebruiks patronen en helpen bij het optimaliseren van de toegangsconfiguratie.

Het gehele remediatieproces moet worden gedocumenteerd voor audit- en compliance-doeleinden. Documenteer welke accounts zijn gewijzigd, wanneer de wijzigingen zijn doorgevoerd, welke applicaties zijn gemigreerd, en eventuele problemen of uitdagingen die zijn ondervonden. Deze documentatie is essentieel voor het aantonen van naleving van beveiligingsstandaarden en voor het ondersteunen van toekomstige audits of certificeringen. De documentatie moet volledig en accuraat zijn, en moet alle relevante details bevatten, inclusief de gebruikte methoden, de betrokken teams, de getroffen resources en de resultaten van tests en validaties. Deze documentatie vormt niet alleen bewijs voor compliance, maar kan ook waardevol zijn voor toekomstige migratieprojecten en als referentie voor het oplossen van vergelijkbare problemen. Het is belangrijk om deze documentatie te bewaren voor de vereiste bewaarperiode zoals gespecificeerd in de relevante compliance-frameworks en organisatiebeleid.

Compliance en Naleving

Het uitschakelen van gedeelde sleutelauthenticatie voor Azure Storage-accounts is een kritieke beveiligingsmaatregel die direct bijdraagt aan het voldoen aan verschillende belangrijke beveiligings- en complianceframeworks. Deze maatregel ondersteunt het Zero Trust-beveiligingsmodel, dat ervan uitgaat dat geen enkele gebruiker, apparaat of applicatie standaard vertrouwd mag worden, en dat alle toegang moet worden geverifieerd en geautoriseerd voordat toegang wordt verleend. Door gedeelde sleutels uit te schakelen en Entra ID-authenticatie te dwingen, implementeert de organisatie een fundamenteel principe van moderne cybersecurity. Zero Trust is gebaseerd op het principe van 'never trust, always verify' en vereist dat alle toegang wordt geverifieerd, ongeacht de locatie of het netwerk. Het uitschakelen van gedeelde sleutelauthenticatie is een concrete implementatie van dit principe en draagt bij aan een algehele verbetering van de beveiligingspostuur door individuele verantwoordingsplicht en geavanceerde toegangscontroles mogelijk te maken.

De CIS Microsoft Azure Foundations Benchmark, versie 1.5.0, bevat specifiek controle 3.15 die vereist dat toegang met gedeelde sleutel wordt uitgeschakeld voor opslagaccounts. Deze controle valt onder de categorie Storage Accounts en heeft een impactniveau van Level 2, wat betekent dat het wordt aanbevolen voor omgevingen die extra beveiliging vereisen. De controle beschrijft dat gedeelde toegangssleutels geen individuele verantwoordingsplicht bieden en dat het gebruik ervan moet worden vermeden ten gunste van Entra ID-authenticatie, die ondersteuning biedt voor identiteitsgebaseerde toegangscontrole en geavanceerde beveiligingsfuncties. De CIS Benchmarks worden wereldwijd erkend als best practices voor cloudbeveiliging en worden vaak gebruikt als basis voor compliance-vereisten. Het voldoen aan deze controle demonstreert dat de organisatie zich inzet voor het implementeren van bewezen beveiligingspraktijken en helpt bij het verminderen van het risico op beveiligingsincidenten. Organisaties die de CIS Benchmarks volgen, kunnen deze controle gebruiken als onderdeel van hun algehele beveiligingsstrategie en als bewijs van naleving tijdens audits.

Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van bijzonder belang. Artikel 09.01 van de BIO richt zich op toegangscontrole en vereist dat organisaties passende maatregelen treffen om toegang tot informatie en informatiesystemen te beheren en te controleren. Het uitschakelen van gedeelde sleutelauthenticatie draagt direct bij aan het voldoen aan deze vereiste door individuele verantwoordingsplicht te bieden, toegang te baseren op identiteit in plaats van gedeelde credentials, en geavanceerde toegangscontroles mogelijk te maken zoals voorwaardelijke toegang, multifactorauthenticatie en op rollen gebaseerde toegangscontrole. De BIO is specifiek ontwikkeld voor Nederlandse overheidsorganisaties en biedt een praktisch kader voor het implementeren van informatiebeveiliging. Artikel 09.01 benadrukt het belang van effectieve toegangscontrole als fundamenteel onderdeel van informatiebeveiliging. Door gedeelde sleutelauthenticatie uit te schakelen en over te gaan op identiteitsgebaseerde authenticatie, kunnen overheidsorganisaties beter voldoen aan deze vereiste en een hoger niveau van beveiliging en verantwoordingsplicht bereiken.

Daarnaast ondersteunt deze maatregel naleving van de Algemene Verordening Gegevensbescherming (AVG) door individuele verantwoordingsplicht mogelijk te maken en door te helpen bij het vastleggen van wie toegang heeft tot welke gegevens. Wanneer Entra ID-authenticatie wordt gebruikt, kunnen alle toegangspogingen worden getraceerd naar specifieke gebruikers of serviceprincipals, wat essentieel is voor het kunnen reageren op verzoeken van betrokkenen over wie toegang heeft gehad tot hun persoonsgegevens. De AVG vereist dat organisaties passende technische en organisatorische maatregelen treffen om persoonsgegevens te beschermen, en individuele verantwoordingsplicht is een belangrijk onderdeel hiervan. Het kunnen traceren van toegang tot persoonsgegevens is niet alleen belangrijk voor het voldoen aan AVG-vereisten, maar ook voor het kunnen reageren op verzoeken van betrokkenen over wie toegang heeft gehad tot hun gegevens. Dit is met name relevant voor organisaties die persoonsgegevens opslaan in Azure Storage-accounts, zoals klantgegevens, medewerkersgegevens of andere gevoelige informatie.

De ISO/IEC 27001 norm voor informatiebeveiligingsmanagement bevat verschillende controles die relevant zijn voor deze maatregel, met name A.9.2 (Toegang tot netwerken en netwerkdiensten), A.9.4 (Controle van toegang tot programma's en gegevens), en A.9.5 (Toegangsrechten beheren). Door gedeelde sleutelauthenticatie uit te schakelen en over te gaan op identiteitsgebaseerde authenticatie, kunnen organisaties beter voldoen aan deze controles door het implementeren van robuuste toegangscontroles, individuele verantwoordingsplicht en regelmatige toegangsrevisies. ISO/IEC 27001 is een internationaal erkende norm voor informatiebeveiligingsmanagement en wordt vaak gebruikt als basis voor certificering. De controles in deze norm zijn ontworpen om organisaties te helpen bij het implementeren van effectieve beveiligingsmaatregelen. Het voldoen aan deze controles door het uitschakelen van gedeelde sleutelauthenticatie helpt organisaties bij het bereiken en behouden van ISO/IEC 27001-certificering en demonstreert een commitment aan informatiebeveiliging.

Voor auditdoeleinden is het belangrijk om te documenteren dat de AllowSharedKeyAccess-instelling is ingesteld op False voor alle opslagaccounts. Dit bewijs kan worden verzameld via monitoring scripts, Azure Policy compliance-rapporten, of handmatige verificatie. De documentatie moet ook bevatten wanneer de wijziging is doorgevoerd, welke accounts zijn beïnvloed, welke applicaties zijn gemigreerd, en eventuele uitzonderingen of tijdelijke afwijkingen die zijn toegestaan met een duidelijk plan voor afhandeling. Deze auditdocumentatie is essentieel voor het aantonen van compliance tijdens externe audits en certificeringsprocessen. Het is belangrijk dat deze documentatie volledig, accuraat en tijdig is, en dat deze wordt bewaard voor de vereiste bewaarperiode zoals gespecificeerd in de relevante compliance-frameworks. Geautomatiseerde rapportage kan dit proces aanzienlijk vereenvoudigen en zorgen voor consistente documentatie die voldoet aan auditvereisten. Regelmatige updates van deze documentatie zijn belangrijk om ervoor te zorgen dat deze altijd actueel is en alle relevante wijzigingen weerspiegelt.

Het implementeren van deze beveiligingsmaatregel draagt ook bij aan het voldoen aan cloud security frameworks zoals de Cloud Security Alliance (CSA) Cloud Controls Matrix en de NIST Cybersecurity Framework. Deze frameworks benadrukken het belang van sterke authenticatie, identiteits- en toegangsbeheer, en het vermijden van gedeelde credentials. Door deze maatregel te implementeren, demonstreert de organisatie een proactieve benadering van cloudbeveiliging en compliance. De CSA Cloud Controls Matrix biedt een uitgebreid framework voor cloudbeveiliging en bevat specifieke controles voor authenticatie en toegangsbeheer. Het NIST Cybersecurity Framework biedt een gestructureerde aanpak voor het beheren van cybersecurity-risico's en benadrukt het belang van identiteitsbeheer en toegangscontrole. Het voldoen aan deze frameworks helpt organisaties bij het implementeren van een alomvattende cloudbeveiligingsstrategie en demonstreert een commitment aan best practices in cloudbeveiliging.

Ten slotte is het belangrijk om te erkennen dat compliance een continu proces is en niet een eenmalige oefening. Regelmatige audits en controles moeten worden uitgevoerd om ervoor te zorgen dat alle nieuwe opslagaccounts automatisch worden geconfigureerd met gedeelde sleutelauthenticatie uitgeschakeld, en dat eventuele wijzigingen in bestaande accounts worden gedetecteerd en aangepakt. Het gebruik van Azure Policy en geautomatiseerde monitoring kan dit proces aanzienlijk vereenvoudigen en zorgen voor consistente naleving van beveiligingsstandaarden in de loop van de tijd. Compliance is geen statisch doel, maar een continu proces dat regelmatige aandacht en onderhoud vereist. Het implementeren van geautomatiseerde controles en monitoring helpt bij het handhaven van compliance zonder excessieve operationele last. Regelmatige evaluatie en verbetering van het complianceproces is belangrijk om ervoor te zorgen dat het effectief blijft en dat nieuwe risico's en vereisten worden aangepakt. Door compliance te behandelen als een continu proces, kunnen organisaties proactief reageren op veranderende beveiligingsbedreigingen en compliance-vereisten.

Compliance & Frameworks

• CIS M365: Control 3.15 (L2) - Schakel gedeelde sleutelauthenticatie uit voor opslagaccounts
• BIO: 09.01 - Toegangscontrole op basis van identiteit

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Opslagaccount Gedeelde Sleutel Toegang Uitgeschakeld: Schakel gedeelde sleutelauthenticatie uit (dwing Entra ID/SAS alleen af). Biedt individuele verantwoordingsplicht en ondersteuning voor voorwaardelijke toegang. Vereist: Applicatiemigratie (8-12 uur inspanning). Activatie: Opslagaccount → Configuratie → Gedeelde sleuteltoegang toestaan: Uitgeschakeld. Geen kosten. Aanbevolen door CIS 3.15, Zero Trust. Implementatietijd: 8-12 uur. Belangrijke migratie - uitstellen voor de meeste scenario's, prioriteit voor nieuwe workloads.

• Implementatietijd: 12 uur
• FTE required: 0.2 FTE