Azure wordt geleverd met ingebouwde ISO/IEC 27001-initiatiefdefiniities die veel technische controls koppelen aan beleidsdefinities, maar dit is een baseline, geen eindpunt. Behandel ze als startpunt: koppel uw vereiste controls aan het initiatief, vind de hiaten, sluit ze met aangepaste beleidsregels of handmatig bewijs, en test alles via policy-as-code voordat u het afdwingt.
Samenvatting:
- Gebruik het tabblad Controls om de verantwoordelijkheden van Microsoft, de klant en gedeelde verantwoordelijkheden te scheiden, maar behandel compliante resultaten als beleidsevaluaties, niet als certificering of volledige auditdekking.
- Koppel elke vereiste ISO-control aan MCSB-ID's, markeer niet-gedekte controls, voeg vervolgens aangepaste beleidsregels toe voor technische hiaten en gedateerd handmatig bewijs voor procesgaten.
- Wijs beleidsregels toe in een niet-productieomgeving met handhaving uitgeschakeld, valideer resultaten via Azure Resource Graph of de Azure Policy SDK, schakel handhaving daarna geleidelijk in.
- Geef prioriteit aan identiteit, cryptografie en logging wanneer middelen beperkt zijn, en bewaar versioned beleidsbestanden, toewijzingssnapshots, herstellogboeken en gedateerde exports voor audits.
Inhoudsopgave
- Waar u het initiatief vindt en hoe het tabblad Controls werkt
- Wie verantwoordelijk is voor elke control: Microsoft, u of beiden
- Wat te doen als ingebouwde beleidsregels een control niet dekken
- De mapping operationeel maken met policy-as-code
- Een checklist voor het beoordelen van resources en het voorbereiden van bewijs
- Waar ik beperkte tijd aan zou besteden
- Zet uw mapping om in een gebudgetteerd ISO 27001-plan
- FAQ
Waar u het initiatief vindt en hoe het tabblad Controls werkt
Begin in Azure Policy, onder Definities, en filter op de categorie Wettelijke naleving. Het ISO/IEC 27001-initiatief is een ingebouwde set beleidsdefinities gegroepeerd in controls en nalevingsdomeinen. Microsoft publiceert de lijst met ingebouwde initiatieven inclusief een GitHub-commitgeschiedenis, dus houd het Azure Policy-repository in de gaten voor wijzigingen en noteer welke initiatiefversie u hebt toegewezen.
Na toewijzing voegen initiatieven voor wettelijke naleving een tabblad Controls toe aan de nalevingsweergave. Dit toont de nalevingsstatus van elke control, de eigenaar en de beleidsdefinities die eraan bijdragen. Als u verder inzoomt, krijgt u drie weergaven:
- Overzicht: de status en eigendomssamenvatting van de control.
- Beleidsregels: de lijst met beleidsdefinities die bijdragen aan die control.
- Resourcenaleving: een weergave per resource die laat zien welke resources slagen of falen.
Lees de status zorgvuldig. De status "Compliant" in Azure Policy weerspiegelt de evaluatie van de onderliggende beleidsdefinities, niet een ISO 27001-certificering; gebruik deze dashboards dus om de technische implementatie te beoordelen en niet als definitief auditrapport.
Wie verantwoordelijk is voor elke control: Microsoft, u of beiden
Het tabblad Controls toont eigendomsinformatie voor controls. Gebruik dit als startpunt om te bepalen welk bewijs u mogelijk moet verzamelen.
- Controls waarvoor Microsoft verantwoordelijk is steunen doorgaans op externe attesten. Haal de details op uit het ISO/IEC 27001-nalevingsaanbod van Azure en voeg ze toe aan uw bewijspakket.
- Controls waarvoor de klant verantwoordelijk is vereisen bewijs uit uw eigen omgeving: configuraties, logboeken, procedures en registraties.
- Gedeelde controls vereisen beide, dus documenteer de verdeling.
De koppeling is niet één-op-één. Meerdere beleidsdefinities kunnen bijdragen aan één ISO-control, en één beleidsregel kan meerdere controls ondersteunen. Het Azure Government ISO 27001-voorbeeld waarschuwt dat de koppelingen gedeeltelijk zijn: sommige controls zijn handmatig of uitgeschakeld, en "Compliant" impliceert geen volledige dekking.
De eigen richtlijnen van Azure zijn duidelijk: Azure Policy-dashboards geven slechts een gedeeltelijk beeld van de ISO 27001-status, dus interne audits moeten nog steeds niet-technische controls omvatten. Plan dit vanaf dag één in plaats van het te ontdekken tijdens de audit.
Voor een diepere blik op het verdelen van verantwoordelijkheden, zie onze gids over gedeelde verantwoordelijkheid in ISO 27001 en Annex A-koppelingen.
Wat te doen als ingebouwde beleidsregels een control niet dekken
Hiaten zijn normaal. Veelvoorkomende voorbeelden zijn niet-technische controls zoals screening van medewerkers en fysieke beveiliging, controls die het Microsoft Cloud Security Benchmark (MCSB) niet adresseert, en controls die afhangen van omgevingsspecifieke parameters. Een hiaatanalyse, zoals die in deze walkthrough voor nalevingshiaatanalyse, houdt het werk overzichtelijk.
Volg deze volgorde, gebaseerd op de controle-koppelingsrichtlijnen van het Cloud Adoption Framework:
- Koppel elke vereiste ISO-control aan MCSB-control-ID's.
- Markeer elke control die MCSB of het initiatief niet dekt.
- Schrijf voor technische hiaten aangepaste beleidsdefinities of voeg ze toe aan een aangepast initiatief.
- Documenteer voor procesgaten handmatig bewijs: beleidsdocumenten, trainingsregistraties, notulen van beoordelingen.
- Leg de beslissing per control vast zodat de redenering bewaard blijft bij personeelswisselingen.
Praktische mitigaties omvatten Guest Configuration-beleidsregels voor instellingen binnen virtuele machines, beleidsregels die retentie van back-ups valideren, en gedateerd procesbewijs voor procedures en trainingen.
Pro Tip: Geef elke control waarvoor handmatig bewijs nodig is een benoemde eigenaar en een reviewdatum in uw register, zodat een auditor een levend proces ziet in plaats van een eenmalige upload.
Ons artikel over soorten bewijs voor ISO 27001-audits laat zien wat auditors doorgaans accepteren.
De mapping operationeel maken met policy-as-code
Policy-as-code maakt uw mapping herhaalbaar en controleerbaar. De workflowrichtlijnen van Microsoft bevelen een bestandsstructuur aan van policy-v#.json, policyset-v#.json en parameterbestanden, allemaal bewaard in versiebeheer zodat elke wijziging een pull request en een auteur heeft.
Een toewijzing bestaat uit een aantal velden:
- policyDefinitionId: de definitie of het initiatief dat wordt toegewezen.
- scope: de beheergroep, het abonnement of de resourcegroep.
- enforcementMode: of het beleid resources daadwerkelijk blokkeert of wijzigt.
- parameters: waarden specifiek voor de omgeving, waarvan de nalevingsaanbodpagina waarschuwt dat ze correct moeten worden ingesteld.
- resourceSelectors en exemptions: de uitrol beperken en goedgekeurde uitzonderingen vastleggen.
Test eerst in een niet-productieomgeving met enforcementMode uitgeschakeld. Valideer resultaten met de Azure Policy SDK of Azure Resource Graph-query's, voer hersteltaken uit en schakel handhaving stap voor stap in — ga pas naar productie over na validatie. De commitgeschiedenis, toewijzingssnapshots en herstellogboeken dienen tevens als auditbewijs.
Een checklist voor het beoordelen van resources en het voorbereiden van bewijs
Werk deze stappen op volgorde af en bewaar elke uitvoer:
- Inventariseer uw ISO-controls en koppel elke aan initiatiefcontrols en MCSB-ID's.
- Exporteer de initiatiefdefiniities die u hebt toegewezen.
- Sla snapshots van toewijzingsparameters op voor elke scope.
- Exporteer resourcenalevingsresultaten op een vaste datum.
- Bewaar herstellogboeken en uitzonderingsregistraties.
- Koppel handmatig bewijs aan elke control waarvoor de klant verantwoordelijk is.
| Bewijsitem | Herkomst | Controleigenaar |
|---|---|---|
| Export initiatiefdefiniitie | Azure Policy-definities | Klant |
| Snapshot toewijzingsparameters | Azure Policy-toewijzingen | Klant |
| Export resourcenaleving | Naleving, tabblad Resourcenaleving | Klant |
| Extern auditrapport | Azure-nalevingsaanbod | Microsoft |
Koppelingsgegeven per control is eenvoudiger te beheren wanneer u het structureert zoals deze datakoppelingsaanpak: één record per item, met een bron en een eigenaar.
Waar ik beperkte tijd aan zou besteden
Als tijd of budget krap is, begin dan met de controls die zijn gekoppeld aan het hoogste bedrijfsrisico: identiteit, cryptografie en logging. Een hoog nalevingspercentage voor laagrisico-controls maakt geen indruk als beheerderstoegang onvoldoende is beveiligd. Gebruik Azure Policy om af te dwingen en te monitoren, maar laat het nooit in de plaats treden van organisatorische processen of het handmatige bewijs dat zij voortbrengen. En bewaar versioned beleidsbestanden en toewijzingssnapshots als bewust onderdeel van uw bewijspakket, want een auditor die vraagt "wat was er in maart toegewezen?" verdient een snel, gedateerd antwoord.
— Martin
Zet uw mapping om in een gebudgetteerd ISO 27001-plan
Zodra uw mapping de hiaten in kaart brengt, is de volgende vraag wat het kost om ze te sluiten en hoe lang dat duurt. Onze ISO 27001-kostencalculator helpt u kosten te verkennen op basis van uw bedrijfsomvang, branche en beveiligingsvolwassenheid.
Als u eerst een snelle momentopname wilt, doe dan onze gratis check. Voor een gestructureerde ISO 27001-gereedheidsanalyse gebruikt u onze ISO 27001 Gereedheidsanalyse. Beide helpen u uw ISO 27001-gereedheid en planningsbehoeften te beoordelen.
FAQ
Betekent de status "Compliant" in Azure Policy dat wij ISO 27001-gecertificeerd zijn?
Nee. "Compliant" betekent dat de onderliggende beleidsdefinities als geslaagd zijn beoordeeld, niet dat uw organisatie gecertificeerd is. Microsoft stelt dit expliciet, dus behandel het dashboard als een technisch beoordelingsinstrument.
Dekken de ingebouwde initiatieven alle ISO 27001-controls?
Nee. Veel controls vereisen een combinatie van geautomatiseerde beleidsregels en handmatig bewijs, en sommige controls zijn handmatig of uitgeschakeld in het initiatief. Plan om aangepaste beleidsregels te schrijven of procesbewijs te documenteren waar de ingebouwde regels ophouden.
Hoe testen we een nieuw beleidsinitiatief veilig?
Wijs het toe in een niet-productieomgeving met enforcementMode uitgeschakeld en valideer resultaten vervolgens met Azure Resource Graph-query's of de Azure Policy SDK. Schakel handhaving stap voor stap in nadat het herstel er correct uitziet.
Wie levert bewijs voor controls waarvoor Microsoft verantwoordelijk is?
Microsoft doet dit via zijn auditrapporten en nalevingsdocumentatie voor Azure. U heeft nog steeds uw eigen bewijs nodig voor controls waarvoor de klant verantwoordelijk is en voor gedeelde controls.