Entra ID-authenticatie Als Standaard

Deze instelling is essentieel voor het handhaven van een veilige omgeving en voorkomt bekende aanvalsvectoren door het afdwingen van beveiligingsbest practices. Door Entra ID (voorheen Azure Active Directory) als standaard authenticatiemethode in te stellen, verhoogt u de beveiliging aanzienlijk door individuele gebruikersaccountabiliteit, op rollen gebaseerd toegangsbeheer en ondersteuning voor voorwaardelijke toegang mogelijk te maken.

Implementatie

De instelling DefaultToOAuthAuthentication wordt ingesteld op waar. Dit zorgt ervoor dat Entra ID-authenticatie de voorkeur krijgt boven opslagaccounttoegangssleutels voor alle nieuwe aanvragen en verbindingen met Azure Storage-resources.

Vereisten

Voor het implementeren van Entra ID-authenticatie als standaardmethode voor Azure Storage zijn verschillende technische en organisatorische vereisten van toepassing. Deze vereisten zorgen ervoor dat de implementatie soepel verloopt en dat bestaande systemen en applicaties na de wijziging blijven functioneren. Het is van cruciaal belang om deze vereisten grondig te begrijpen en te implementeren voordat de configuratiewijziging wordt doorgevoerd, omdat onjuiste implementatie kan leiden tot verstoring van kritieke bedrijfsprocessen en toegangsproblemen voor gebruikers en applicaties.

De primaire technische vereiste is het bezit van een actief Azure Storage-account. Dit opslagaccount moet toegankelijk zijn via de Azure Portal of via Azure Resource Manager API's. Daarnaast is het essentieel dat de organisatie beschikt over een werkend Entra ID-tenant (voorheen Azure Active Directory) dat is gekoppeld aan het Azure-abonnement waarin het opslagaccount zich bevindt. De Entra ID-tenant moet correct zijn geconfigureerd met gebruikers, groepen en service-principals die toegang nodig hebben tot de opslagresources. Bovendien moet de tenant beschikken over de juiste licentieconfiguratie, waarbij Azure AD Premium licenties worden aanbevolen voor geavanceerde functies zoals Conditional Access en Identity Protection.

Een kritische organisatorische vereiste betreft de compatibiliteit van bestaande applicaties en services. Veel legacy-applicaties en geautomatiseerde scripts maken gebruik van gedeelde toegangssleutels (Shared Access Keys) voor authenticatie. Voordat u Entra ID-authenticatie als standaard instelt, moet u een grondige inventarisatie uitvoeren van alle systemen die toegang hebben tot het opslagaccount. Dit omvat applicaties, scripts, monitoringtools, backup-systemen en geïntegreerde services van derden. Deze inventarisatie moet niet alleen de systemen identificeren, maar ook documenteren welke specifieke operaties zij uitvoeren, hoe vaak zij toegang nodig hebben en wat de impact zou zijn als deze systemen tijdelijk geen toegang zouden hebben. Deze informatie is essentieel voor het plannen van een gefaseerde migratie en het minimaliseren van bedrijfsrisico's.

Voor elke geïdentificeerde toepassing moet worden beoordeeld of deze Entra ID-authenticatie ondersteunt. Moderne Azure SDK's en clientbibliotheken ondersteunen doorgaans Entra ID-authenticatie, maar oudere versies of aangepaste implementaties kunnen mogelijk alleen werken met toegangssleutels. In dergelijke gevallen moet een migratieplan worden opgesteld om deze systemen te upgraden of te vervangen voordat de standaard wordt gewijzigd. Het migratieplan moet gedetailleerde stappen bevatten voor het testen van elke applicatie in een testomgeving, het identificeren van benodigde code-aanpassingen, het plannen van implementatiewindows en het opstellen van rollback-procedures voor het geval er onverwachte problemen optreden. Bovendien moet worden overwogen of bepaalde systemen mogelijk uitzonderingen nodig hebben, waarbij toegangssleutels tijdelijk blijven functioneren terwijl wordt gewerkt aan een volledige migratie.

Bovendien vereist deze configuratie dat beheerders beschikken over de juiste Azure RBAC-rollen (Role-Based Access Control). Specifiek zijn de rollen 'Storage Account Contributor' of 'Owner' nodig om de configuratie-instellingen te kunnen wijzigen. Voor het configureren van Entra ID-authenticatie en het toewijzen van rollen aan gebruikers of service-principals zijn ook 'User Access Administrator' of 'Owner' rechten vereist. Het is belangrijk om te begrijpen dat deze rollen brede machtigingen verlenen en daarom alleen moeten worden toegewezen aan vertrouwde beheerders. Organisaties moeten het principe van least privilege toepassen door gebruikers en service-principals alleen de minimale rechten te verlenen die nodig zijn voor hun specifieke taken. Voor toegang tot opslagdata zijn specifieke data-rollen beschikbaar, zoals 'Storage Blob Data Contributor' voor schrijftoegang, 'Storage Blob Data Reader' voor leestoegang en 'Storage Blob Data Owner' voor volledige controle over data en toegangsrechten.

Ten slotte is het belangrijk dat de organisatie beschikt over een goed ingericht proces voor identiteits- en toegangsbeheer. Dit omvat het beheer van gebruikersaccounts, service-principals, beheerde identiteiten en de toewijzing van geschikte RBAC-rollen zoals 'Storage Blob Data Contributor', 'Storage Blob Data Reader' of 'Storage Blob Data Owner', afhankelijk van de benodigde toegangsniveaus. Het identiteitsbeheerproces moet regelmatige toegangsreviews omvatten om ervoor te zorgen dat gebruikers en service-principals alleen toegang hebben tot resources die zij daadwerkelijk nodig hebben. Bovendien moet het proces voorzien in het automatisch intrekken van toegang wanneer gebruikers de organisatie verlaten of wanneer hun rollen veranderen. Voor service-principals en beheerde identiteiten moet worden gedocumenteerd welke applicaties of services zij vertegenwoordigen en wat de bedrijfsrechtvaardiging is voor hun toegang tot opslagresources. Deze documentatie is essentieel voor compliance-doeleinden en voor het kunnen verantwoorden van toegangsrechten tijdens audits.

Monitoring

Gebruik PowerShell-script entra-authorization-default-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van de standaard authenticatiemethode voor Azure Storage is essentieel om te waarborgen dat de beveiligingsconfiguratie correct is ingesteld en blijft voldoen aan de organisatorische vereisten. Regelmatige controle voorkomt dat onbedoelde wijzigingen de beveiligingspostuur van de organisatie verzwakken. Monitoring vormt een fundamenteel onderdeel van een effectief beveiligingsprogramma en stelt organisaties in staat om proactief te reageren op configuratiewijzigingen, compliance-afwijkingen en potentiële beveiligingsrisico's. Zonder adequate monitoring kunnen organisaties onbewust blootgesteld worden aan beveiligingsrisico's zonder dat zij zich hiervan bewust zijn.

De primaire monitoringactiviteit betreft het controleren of de instelling DefaultToOAuthAuthentication daadwerkelijk is ingesteld op waar voor alle relevante opslagaccounts binnen de organisatie. Deze controle kan worden uitgevoerd via de Azure Portal, waar de configuratie zichtbaar is onder de sectie 'Configuration' van elk opslagaccount. In de Azure Portal kunt u direct zien of 'Allow Blob public access' is uitgeschakeld en of 'Default to Azure Active Directory authorization in the Azure portal' is ingeschakeld. Voor organisaties met een groot aantal opslagaccounts is handmatige controle via de portal echter niet praktisch. Daarom wordt aanbevolen om geautomatiseerde monitoringoplossingen te implementeren die regelmatig de configuratie van alle opslagaccounts controleren en afwijkingen rapporteren. Deze geautomatiseerde controles kunnen worden geïntegreerd in bestaande monitoring- en alertingsystemen om ervoor te zorgen dat beheerders onmiddellijk worden gewaarschuwd wanneer een opslagaccount niet voldoet aan de beveiligingsvereisten.

Voor geautomatiseerde monitoring en compliance-controles biedt Azure verschillende mogelijkheden. Azure Policy kan worden gebruikt om te controleren of alle opslagaccounts de juiste configuratie hebben. Door een aangepast beleid te definiëren dat de eigenschap 'defaultToOAuthAuthentication' controleert, kunnen beheerders automatisch worden gewaarschuwd wanneer een opslagaccount niet voldoet aan de vereisten. Dit beleid kan worden toegepast op abonnements- of beheergroepniveau om ervoor te zorgen dat alle nieuwe en bestaande opslagaccounts worden gecontroleerd. Azure Policy biedt ook de mogelijkheid om automatisch corrigerende maatregelen te nemen, hoewel dit voor productieomgevingen met voorzichtigheid moet worden gebruikt. Daarnaast kunnen Azure Policy-initiatieven worden gebruikt om meerdere gerelateerde beleidsregels te combineren, waardoor een uitgebreide compliance-controle wordt gecreëerd die niet alleen de authenticatieconfiguratie controleert, maar ook andere beveiligingsinstellingen zoals netwerktoegang, versleuteling en logging.

Daarnaast biedt Azure Monitor de mogelijkheid om authenticatiepatronen te analyseren. Door activiteitenlogboeken en diagnostische logboeken in te schakelen voor opslagaccounts, kunnen beheerders inzicht krijgen in welke authenticatiemethoden daadwerkelijk worden gebruikt. Het monitoren van mislukte authenticatiepogingen kan helpen bij het identificeren van applicaties of services die nog steeds proberen gedeelde toegangssleutels te gebruiken, wat kan wijzen op configuratieproblemen of niet-geüpdatete systemen. Azure Monitor biedt geavanceerde query-mogelijkheden via Kusto Query Language (KQL), waarmee beheerders complexe analyses kunnen uitvoeren op authenticatielogboeken. Deze analyses kunnen patronen identificeren zoals ongebruikelijke toegangstijden, geografische afwijkingen of pogingen tot toegang vanaf niet-geautoriseerde locaties. Door deze patronen te monitoren, kunnen organisaties potentiële beveiligingsincidenten vroegtijdig detecteren en passende maatregelen nemen.

Voor organisaties die werken met meerdere Azure-abonnementen of beheergroepen is het raadzaam om regelmatig een inventarisatie uit te voeren van alle opslagaccounts en hun authenticatieconfiguratie. Dit kan worden geautomatiseerd met behulp van Azure Resource Graph queries, die een overzicht geven van alle resources binnen de organisatie en hun configuratiestatus. Door deze queries periodiek uit te voeren, bijvoorbeeld wekelijks of maandelijks, kunnen beheerders snel afwijkingen identificeren en corrigerende maatregelen nemen. Azure Resource Graph biedt krachtige query-mogelijkheden die het mogelijk maken om complexe filters toe te passen, zoals het identificeren van alle opslagaccounts binnen specifieke beheergroepen, abonnementen of regio's. Deze queries kunnen worden opgeslagen en geautomatiseerd uitgevoerd via Azure Automation of Azure Logic Apps, waardoor een continue monitoring wordt gecreëerd zonder handmatige interventie. De resultaten van deze queries kunnen worden geëxporteerd naar rapportagetools of worden geïntegreerd in dashboards voor executive reporting.

Het is ook belangrijk om te monitoren of er nog applicaties of services zijn die gebruikmaken van gedeelde toegangssleutels, zelfs nadat Entra ID-authenticatie als standaard is ingesteld. Hoewel de standaardinstelling nieuwe verbindingen naar Entra ID-authenticatie leidt, kunnen bestaande verbindingen die gebruikmaken van toegangssleutels nog steeds functioneren. Door authenticatielogboeken te analyseren, kunnen beheerders deze legacy-verbindingen identificeren en een migratieplan opstellen om deze over te zetten naar Entra ID-authenticatie voor volledige compliance. Deze monitoring moet niet alleen identificeren welke systemen nog steeds toegangssleutels gebruiken, maar ook analyseren hoe vaak deze systemen toegang nodig hebben, welke operaties zij uitvoeren en wat de bedrijfsimpact zou zijn van het uitschakelen van toegangssleutel-authenticatie. Deze informatie is essentieel voor het plannen van een gefaseerde migratie die de bedrijfscontinuïteit niet verstoort.

Ten slotte moet de monitoringactiviteit worden gedocumenteerd en gerapporteerd aan relevante stakeholders, zoals de CISO, security officers en compliance-teams. Regelmatige rapportage over de status van authenticatieconfiguraties helpt bij het handhaven van een sterke beveiligingspostuur en het voldoen aan compliance-vereisten zoals de BIO-normen en ISO 27001. Deze rapportage moet niet alleen de huidige status weergeven, maar ook trends over de tijd, geïdentificeerde risico's en aanbevolen corrigerende maatregelen. Door regelmatige rapportage te implementeren, kunnen organisaties aantonen dat zij proactief werken aan het handhaven van beveiligingsstandaarden en kunnen zij snel reageren op veranderende bedreigingen of compliance-vereisten. Bovendien helpt deze documentatie bij het voorbereiden van externe audits en het verantwoorden van beveiligingsbeslissingen aan management en toezichthouders.

Compliance en Audit

Het instellen van Entra ID-authenticatie als standaardmethode voor Azure Storage draagt significant bij aan het voldoen aan verschillende compliance-vereisten die van toepassing zijn op Nederlandse overheidsorganisaties. Deze configuratie ondersteunt met name de BIO-normen (Baseline Informatiebeveiliging Overheid) en de internationale ISO 27001:2022 standaard. Compliance is niet alleen een juridische verplichting voor overheidsorganisaties, maar vormt ook een fundamenteel onderdeel van een effectief beveiligingsprogramma. Door te voldoen aan deze normen demonstreren organisaties dat zij serieus omgaan met de bescherming van gevoelige gegevens en dat zij de verantwoordelijkheid nemen voor het beveiligen van informatie die is toevertrouwd aan hun zorg. Bovendien helpt compliance bij het opbouwen van vertrouwen bij burgers, partners en toezichthouders door aan te tonen dat de organisatie voldoet aan erkende beveiligingsstandaarden.

BIO-norm 09.01 richt zich op toegangscontrole en authenticatie. Deze norm vereist dat organisaties passende maatregelen treffen om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben tot informatie en informatiesystemen. Door Entra ID-authenticatie als standaard in te stellen, voldoen organisaties aan deze vereiste door individuele gebruikersaccountabiliteit te waarborgen. In tegenstelling tot gedeelde toegangssleutels, waarbij meerdere gebruikers dezelfde credentials delen en individuele acties niet kunnen worden getraceerd, maakt Entra ID-authenticatie het mogelijk om elke toegangspoging te koppelen aan een specifieke gebruiker of service-principal. Deze individuele accountabiliteit is van cruciaal belang voor het kunnen verantwoorden van acties en het kunnen traceren van toegang tot gevoelige gegevens. Bovendien stelt deze accountabiliteit organisaties in staat om snel te reageren op beveiligingsincidenten door precies te kunnen identificeren welke gebruikers of systemen betrokken waren bij specifieke acties.

Deze individuele accountabiliteit is essentieel voor auditdoeleinden en compliance-verificatie. Wanneer alle toegang tot opslagresources wordt geauthenticeerd via Entra ID, kunnen beheerders precies zien wie toegang heeft gehad tot welke gegevens en wanneer. Dit auditlogboek is cruciaal voor het voldoen aan BIO-vereisten en voor het kunnen verantwoorden van toegang tot gevoelige overheidsgegevens tijdens audits of incidentonderzoeken. De auditlogboeken die worden gegenereerd door Entra ID-authenticatie bevatten gedetailleerde informatie over elke toegangspoging, inclusief de identiteit van de gebruiker of service-principal, het tijdstip van toegang, de gebruikte authenticatiemethode en de uitgevoerde operaties. Deze informatie kan worden gebruikt voor forensische analyses na beveiligingsincidenten, voor het identificeren van ongebruikelijke toegangspatronen en voor het verifiëren van compliance tijdens externe audits. Bovendien kunnen deze logboeken worden geïntegreerd met Security Information and Event Management (SIEM) systemen voor geavanceerde beveiligingsanalyses en real-time threat detection.

ISO 27001:2022 controle A.5.15 behandelt toegangscontrole en vereist dat organisaties toegang tot informatie en andere geassocieerde assets beheren. Deze controle benadrukt het belang van het gebruik van sterke authenticatiemechanismen en het voorkomen van gedeelde credentials. Entra ID-authenticatie voldoet aan deze vereiste door gebruik te maken van moderne OAuth 2.0 en OpenID Connect protocollen, die als industrie-standaard worden beschouwd voor veilige authenticatie. Bovendien ondersteunt Entra ID multi-factor authenticatie (MFA), wat een extra beveiligingslaag toevoegt die wordt aanbevolen door ISO 27001. MFA vereist dat gebruikers naast hun wachtwoord ook een tweede authenticatiefactor gebruiken, zoals een mobiele app, een hardware-token of biometrische verificatie. Deze extra laag van beveiliging maakt het aanzienlijk moeilijker voor aanvallers om toegang te krijgen tot accounts, zelfs als zij in het bezit zijn van gestolen credentials. ISO 27001 vereist ook dat organisaties regelmatig toegangsrechten controleren en dat zij een proces hebben voor het intrekken van toegang wanneer dit niet meer nodig is, wat goed wordt ondersteund door Entra ID's toegangsbeheerfuncties.

Naast deze specifieke normen draagt de configuratie ook bij aan het Zero Trust-beveiligingsmodel, dat steeds belangrijker wordt in moderne cybersecurity-strategieën. Zero Trust vereist dat elke toegangspoging wordt geverifieerd, ongeacht de locatie of het netwerk van de gebruiker. Entra ID-authenticatie, in combinatie met Azure RBAC en Conditional Access policies, maakt dit mogelijk door voor elke aanvraag de identiteit te verifiëren en de toegangsrechten te evalueren op basis van contextuele factoren zoals gebruikerslocatie, apparaatstatus en risicoscore. Het Zero Trust-model gaat uit van het principe dat geen enkele gebruiker of apparaat automatisch vertrouwd moet worden, zelfs niet als zij zich binnen het bedrijfsnetwerk bevinden. Dit model is bijzonder relevant voor moderne organisaties die werken met cloudservices, mobiele werknemers en externe partners, omdat traditionele netwerkperimeters steeds minder relevant worden. Door Entra ID-authenticatie te gebruiken in combinatie met Conditional Access policies kunnen organisaties dynamische toegangsbeslissingen nemen op basis van risicobeoordelingen, waardoor de beveiliging wordt verbeterd zonder de gebruikerservaring onnodig te verstoren.

Voor auditingdoeleinden is het belangrijk dat organisaties documenteren hoe de Entra ID-authenticatie is geconfigureerd en welke RBAC-rollen zijn toegewezen aan gebruikers en service-principals. Deze documentatie moet regelmatig worden gecontroleerd en bijgewerkt om ervoor te zorgen dat toegangsrechten nog steeds geschikt zijn en dat het principe van 'least privilege' wordt gevolgd. Tijdens externe audits kunnen auditors deze configuratie en documentatie controleren om te verifiëren dat de organisatie voldoet aan de relevante compliance-vereisten. De documentatie moet niet alleen de huidige configuratie beschrijven, maar ook de bedrijfsrechtvaardiging voor elke roltoewijzing, de procedures voor het beheren van toegangsrechten en de processen voor het regelmatig controleren en bijwerken van toegangsrechten. Bovendien moet de documentatie worden geïntegreerd met het algemene beveiligingsbeleid van de organisatie en moet deze regelmatig worden gecontroleerd door security officers en compliance-teams om ervoor te zorgen dat deze up-to-date blijft en voldoet aan de huidige compliance-vereisten.

Het is ook belangrijk op te merken dat de overstap naar Entra ID-authenticatie organisaties beter voorbereidt op toekomstige compliance-vereisten. Naarmate beveiligingsstandaarden evolueren en strenger worden, zal het gebruik van moderne authenticatiemethoden steeds belangrijker worden. Door nu al deze configuratie te implementeren, positioneren organisaties zich goed voor toekomstige audits en compliance-verificaties. Bovendien helpt deze proactieve aanpak organisaties om sneller te kunnen reageren op nieuwe compliance-vereisten zonder dat zij grote infrastructurele wijzigingen hoeven door te voeren. Organisaties die nu al moderne authenticatiemethoden gebruiken, zullen minder moeite hebben om te voldoen aan toekomstige normen die waarschijnlijk nog strengere eisen zullen stellen aan authenticatie en toegangscontrole. Deze investering in moderne beveiligingsinfrastructuur betaalt zich op de lange termijn terug door het verminderen van compliance-risico's en het verbeteren van de algehele beveiligingspostuur van de organisatie.

Remediatie

Gebruik PowerShell-script entra-authorization-default-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer een opslagaccount niet is geconfigureerd met Entra ID-authenticatie als standaardmethode, is het belangrijk om een gestructureerde aanpak te volgen voor remediatie. Deze aanpak zorgt ervoor dat de wijziging veilig wordt doorgevoerd zonder de beschikbaarheid van kritieke systemen en applicaties te verstoren. Remediatie is niet alleen een technische oefening, maar vereist ook zorgvuldige planning, coördinatie tussen verschillende teams en uitgebreide testing om ervoor te zorgen dat bedrijfsprocessen niet worden verstoord. Een goed uitgevoerd remediatieproces minimaliseert risico's, vermindert downtime en zorgt voor een soepele overgang naar de nieuwe authenticatiemethode. Het is belangrijk om te benadrukken dat haastige of ondoordachte remediatie kan leiden tot verstoring van kritieke systemen, wat kan resulteren in bedrijfsverlies, compliance-problemen en beschadiging van de reputatie van de organisatie.

De eerste stap in het remediatieproces is het uitvoeren van een grondige impactanalyse. Dit omvat het identificeren van alle applicaties, scripts, services en geïntegreerde systemen die momenteel toegang hebben tot het betreffende opslagaccount. Voor elk van deze systemen moet worden bepaald of deze Entra ID-authenticatie ondersteunt. Moderne Azure SDK's en clientbibliotheken, zoals de Azure Storage SDK voor .NET, Python, Java en andere talen, ondersteunen doorgaans Entra ID-authenticatie via de DefaultAzureCredential klasse of vergelijkbare mechanismen. De impactanalyse moet niet alleen de technische aspecten omvatten, maar ook de bedrijfsimpact beoordelen. Dit betekent dat voor elk systeem moet worden bepaald wat de gevolgen zouden zijn als dit systeem tijdelijk geen toegang zou hebben, welke bedrijfsprocessen afhankelijk zijn van dit systeem en wat de acceptabele downtime zou zijn voor dit systeem. Deze informatie is essentieel voor het plannen van een gefaseerde migratie die de bedrijfscontinuïteit waarborgt.

Voor systemen die Entra ID-authenticatie ondersteunen, kan de configuratie relatief eenvoudig worden bijgewerkt. Dit vereist meestal het wijzigen van de authenticatiecode om gebruik te maken van Entra ID-credentials in plaats van toegangssleutels. Voor applicaties die draaien op Azure-resources, zoals Azure Virtual Machines, Azure App Service of Azure Functions, kan gebruik worden gemaakt van beheerde identiteiten. Beheerde identiteiten elimineren de noodzaak om credentials op te slaan in code of configuratiebestanden, wat de beveiliging verder verbetert. Beheerde identiteiten zijn bijzonder waardevol omdat zij automatisch worden beheerd door Azure, waardoor de operationele overhead wordt verminderd en het risico op credential-lekken wordt geëlimineerd. Voor on-premises applicaties of applicaties die draaien op andere cloudplatforms, kunnen service-principals worden gebruikt voor authenticatie. Service-principals zijn identiteiten die worden gebruikt door applicaties en services om toegang te krijgen tot Azure-resources. Zij kunnen worden geconfigureerd met specifieke rechten en kunnen worden beheerd via Entra ID, waardoor een gecentraliseerd toegangsbeheer wordt gecreëerd.

Voor systemen die nog geen Entra ID-authenticatie ondersteunen, moet een migratieplan worden opgesteld. Dit kan betekenen dat applicaties moeten worden geüpdatet naar nieuwere versies van clientbibliotheken die Entra ID ondersteunen, of dat aangepaste authenticatiecode moet worden herschreven. In sommige gevallen kan het nodig zijn om alternatieve oplossingen te overwegen, zoals het gebruik van Azure Key Vault voor het veilig opslaan en ophalen van toegangssleutels als tijdelijke maatregel, terwijl wordt gewerkt aan een volledige migratie naar Entra ID-authenticatie. Het migratieplan moet gedetailleerde stappen bevatten voor elke applicatie, inclusief de benodigde code-aanpassingen, testprocedures en rollback-plannen. Het plan moet ook rekening houden met de beschikbaarheid van ontwikkelingsresources, testomgevingen en implementatiewindows. Voor kritieke systemen kan het nodig zijn om eerst een proof-of-concept uit te voeren in een testomgeving om te verifiëren dat de migratie succesvol kan worden uitgevoerd zonder de productieomgeving te verstoren.

Zodra alle systemen zijn voorbereid of gemigreerd, kan de daadwerkelijke configuratiewijziging worden doorgevoerd. In de Azure Portal kan dit worden gedaan door naar het opslagaccount te navigeren, de sectie 'Configuration' te openen en de optie 'Default to Azure Active Directory authorization in the Azure portal' in te schakelen. Via Azure PowerShell kan dit worden bereikt met de Set-AzStorageAccount cmdlet, waarbij de parameter -DefaultToOAuthAuthentication wordt ingesteld op $true. Via Azure CLI kan de az storage account update opdracht worden gebruikt met de --default-to-oauth-authentication flag. Ongeacht welke methode wordt gebruikt, is het belangrijk om de wijziging eerst uit te voeren in een testomgeving om te verifiëren dat alles correct werkt. Bovendien moet de wijziging worden uitgevoerd tijdens een gepland onderhoudsvenster om de impact op gebruikers te minimaliseren. Het is ook aanbevolen om een rollback-plan klaar te hebben voor het geval er onverwachte problemen optreden na de wijziging.

Na het doorvoeren van de wijziging is het cruciaal om uitgebreide tests uit te voeren om te verifiëren dat alle systemen nog steeds correct functioneren. Dit omvat functionele tests van alle applicaties die toegang hebben tot het opslagaccount, evenals het controleren van geautomatiseerde processen zoals backups, monitoring en data synchronisatie. Eventuele problemen die tijdens deze tests worden geïdentificeerd, moeten onmiddellijk worden aangepakt voordat de wijziging als voltooid wordt beschouwd. De tests moeten niet alleen de basisfunctionaliteit controleren, maar ook edge cases en foutscenario's testen. Dit omvat het testen van verschillende authenticatiemethoden, het controleren van toegangsrechten voor verschillende gebruikers en rollen, en het verifiëren dat alle geautomatiseerde processen nog steeds correct werken. Bovendien moeten de tests worden uitgevoerd over een langere periode om te verifiëren dat er geen latentieproblemen zijn die pas na verloop van tijd zichtbaar worden.

Het is ook belangrijk om te documenteren welke systemen zijn gemigreerd en welke eventuele uitzonderingen of tijdelijke maatregelen zijn genomen. Deze documentatie is essentieel voor toekomstige audits en helpt bij het plannen van verdere verbeteringen aan de beveiligingsconfiguratie. Bovendien moet het remediatieproces worden gedocumenteerd in het change management systeem van de organisatie, inclusief de reden voor de wijziging, de uitgevoerde stappen en de verificatieresultaten. De documentatie moet ook informatie bevatten over eventuele problemen die zijn opgetreden tijdens de migratie, hoe deze zijn opgelost en welke lessen zijn geleerd. Deze informatie kan waardevol zijn voor toekomstige migraties en kan helpen bij het verbeteren van het remediatieproces. Bovendien moet de documentatie worden gedeeld met relevante stakeholders, zoals security officers, compliance-teams en IT-beheerders, om ervoor te zorgen dat iedereen op de hoogte is van de wijzigingen en de impact daarvan.

Voor organisaties met meerdere opslagaccounts is het raadzaam om een gefaseerde aanpak te volgen, waarbij eerst niet-kritieke accounts worden geconfigureerd om ervaring op te doen en eventuele problemen te identificeren voordat kritieke productieaccounts worden aangepast. Deze aanpak minimaliseert risico's en zorgt voor een soepele overgang naar de nieuwe authenticatiemethode. De gefaseerde aanpak moet beginnen met accounts die worden gebruikt voor ontwikkeling en testen, gevolgd door accounts voor niet-kritieke productieomgevingen, en uiteindelijk de meest kritieke productieaccounts. Tussen elke fase moet voldoende tijd worden genomen om de resultaten te evalueren, eventuele problemen op te lossen en het proces te verfijnen. Deze aanpak stelt organisaties in staat om geleidelijk expertise op te bouwen en vertrouwen te krijgen in het remediatieproces voordat zij de meest kritieke systemen aanpassen. Bovendien maakt deze aanpak het mogelijk om lessons learned uit eerdere fases toe te passen op latere fases, waardoor het algehele succespercentage van de remediatie wordt verbeterd.

Compliance & Frameworks

• BIO: 09.01 - Toegangscontrole en authenticatie
• ISO 27001:2022: A.5.15 - Toegangscontrole en authenticatie

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

Entra ID-authenticatie als standaard: Geef voorkeur aan Entra ID (voorheen Azure AD) authenticatie boven gedeelde toegangssleutels. Dit biedt individuele gebruikersaccountabiliteit, RBAC-ondersteuning en mogelijkheden voor voorwaardelijke toegang. Activatie gebeurt via Storage Account → Configuration → Default to Entra ID authorization. Deze configuratie is kosteloos en wordt aanbevolen voor Zero Trust-implementaties. De implementatie duurt ongeveer 2-3 uur, voornamelijk voor het controleren van clientcompatibiliteit. Dit vertegenwoordigt een moderne authenticatiebenadering die voldoet aan huidige beveiligingsstandaarden.

• Implementatietijd: 3 uur
• FTE required: 0.03 FTE