Gegevensbeveiliging

Gegevensbescherming beschermt gevoelige informatie tegen onbevoegde toegang, exfiltratie en misbruik gedurende de volledige levenscyclus van gegevens. Implementeer detectie en classificatie om gegevensinventaris, versleuteling tot stand te brengen om gegevens in transit en at rest te beveiligen, en gedisciplineerd sleutel- en certificaatbeheer om cryptografische integriteit te behouden. Deze gelaagde benadering is afgestemd op Zero Trust-principes en diepgaande verdedigingsstrategieën.

Zonder uitgebreide gegevensbescherming hebben organisaties te maken met schendingen van gegevens, wettelijke sancties en reputatieschade door exfiltratie van gevoelige informatie.

Hier volgen de drie kernpijlers van het domein Gegevensbescherming.

Uw gegevens kennen en classificeren: Ontdek gevoelige informatie en pas consistente labels toe om controles op basis van risico's in te schakelen.

Gerelateerde besturingselementen:

• DP-1: Gevoelige gegevens detecteren, classificeren en labelen
• DP-2: Afwijkingen en bedreigingen bewaken die gericht zijn op gevoelige gegevens

Gegevens beveiligen met versleuteling: Implementeer uitgebreide versleuteling voor gegevens in beweging en in rust met behulp van moderne cryptografische standaarden.

Gerelateerde besturingselementen:

• DP-3: Gevoelige gegevens versleutelen tijdens overdracht
• DP-4: Gegevens-at-rest-versleuteling standaard inschakelen
• DP-5: De door de klant beheerde sleuteloptie gebruiken in data-at-rest-versleuteling wanneer dat nodig is

Cryptografische infrastructuur beheren: Beheer van gedisciplineerde levenscyclus voor cryptografische sleutels en certificaten met geautomatiseerde rotatie en uitgebreide auditlogboekregistratie.

Gerelateerde besturingselementen:

• DP-6: Een beveiligd sleutelbeheerproces gebruiken
• DP-7: Een beveiligd certificaatbeheerproces gebruiken
• DP-8: Beveiliging van sleutel- en certificaatopslagplaats garanderen

DP-1: Gevoelige gegevens detecteren, classificeren en labelen

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-1.

Beveiligingsprincipe

Een uitgebreide inventarisatie van gevoelige gegevens tot stand brengen en onderhouden door gegevens in alle opslagplaatsen te detecteren, classificeren en labelen. Hierdoor kunnen op risico's gebaseerde toegangsbeheer, versleutelingsbeleid en bewaking worden beschermd tegen onbevoegde toegang en exfiltratie.

Risico om te beperken

Bedreigingsactoren misbruiken gebrek aan zichtbaarheid en inconsistente verwerking van gevoelige gegevens om informatie met hoge waarde te exfiltreren of misbruiken. Wanneer gevoelige gegevens niet worden gedetecteerd, geclassificeerd of gelabeld:

• Niet-bijgehouden gereglementeerde gegevens: (PCI, PHI, PII) die zijn opgeslagen op niet-beheerde locaties (schaduw-IT) omzeilt vereiste versleuteling, retentie of bewakingsbeheer.
• Overprivilegieerde toegang: Brede toegang tot gebruikers/services blijft bestaan omdat gevoeligheid en bedrijfsimpact niet worden geïdentificeerd.
• Replicaproliferatie: Gegevensreplicatie naar analyse-, test- of exportpijplijnen verspreidt gevoelige inhoud naar omgevingen met een lagere vertrouwensrelatie.
• Forensische blinde vlekken: Incidentresponders kunnen de impactradius niet snel bepalen vanwege ontbrekende of onjuiste gevoeligheidsmetagegevens.
• Automatiseringsfout: Governance (DLP, voorwaardelijke toegang, versleutelingswerkstromen) wordt niet geactiveerd zonder consistente labeling.

Het ontbreken van basisclassificatie verhoogt de verblijftijd, verbreedt de mogelijkheden voor laterale beweging en verhoogt de blootstelling aan regelgeving en reputatierisico.

MITRE ATT&CK

• Reconnaissance (TA0043): het verzamelen van identiteiten van slachtoffers / data-assets (T1596) door opslagaccounts, schemacatalogussen en classificatiemetagegevens in kaart te brengen om databronnen van hoge waarde te profileren.
• Detectie (TA0007): opsomming van accounts en machtigingen (T1087, T1069) om overmatige rolbindingen weer te geven die horizontale of verticale escalatie van gegevenstoegang mogelijk maken.
• Verzameling (TA0009): gegevens uit cloudopslag (T1530) door niet-gelabelde blobcontainers of onbeheerde exports te extraheren zonder traceringstags.
• Exfiltratie (TA0010): exfiltratie via webservices (T1567) via ad-hoc exporteindpunten waar labeling/beleidspoorten ontbreken.
• Exfiltratie (TA0010): geautomatiseerde exfiltratie (T1020) met behulp van gescripte paginering/lussen om onjuist geclassificeerde gegevenssets stilletjes te verzamelen.

DP-1.1: Gevoelige gegevens detecteren, classificeren en labelen

Gebruik Microsoft Purview om een uitgebreide gegevenskaart te maken waarmee gevoelige informatie automatisch wordt gedetecteerd, classificeert en gelabeld in uw hele gegevensomgeving. Breid de beveiliging uit buiten versleuteling op infrastructuurniveau door Microsoft Purview Information Protection te implementeren om permanente versleuteling op documentniveau en gebruiksrechten toe te passen die gegevens volgen waar deze zich ook bevinden. Met deze basismogelijkheid kunnen downstreambeveiligingscontroles, zoals preventie van gegevensverlies, voorwaardelijke toegang en versleutelingsbeleid, worden uitgevoerd op basis van de vertrouwelijkheid van gegevens in plaats van alleen de locatie.

Gegevensdetectie en -classificatie:

• Implementeer Microsoft Purview om gevoelige gegevens te detecteren, classificeren en labelen in Azure, on-premises, Microsoft 365 en omgevingen met meerdere clouds.
• Gebruik Microsoft Purview Data Map om automatisch gegevensbronnen te scannen en catalogiseren, waaronder Azure Storage, Azure SQL Database, Azure Synapse Analytics en andere ondersteunde services.
• Schakel vertrouwelijkheidslabels in Purview Data Map in om automatisch classificatielabels toe te passen (bijvoorbeeld Vertrouwelijk, Zeer vertrouwelijk, PII, PHI) op basis van gegevensinhoudspatronen en organisatiebeleid.

Versleuteling en beveiliging op documentniveau:

• Implementeer Microsoft Purview Information Protection om permanente versleuteling en gebruiksrechten toe te passen op documenten en e-mailberichten op basis van vertrouwelijkheidslabels. Configureer labels om bestanden automatisch te versleutelen, watermerken toe te passen, doorsturen te beperken, vervaldatums in te stellen en toegang in te trekken, zelfs nadat gegevens uw organisatie verlaten.
• Schakel Azure Rights Management Service (Azure RMS) in als de onderliggende beveiligingstechnologie waarmee documenten en e-mailberichten worden versleuteld met gebruiksbeleid (alleen weergeven, geen kopie, geen afdruk) die behouden blijven, ongeacht waar gegevens worden opgeslagen of gedeeld.

Database-classificatie en -integratie:

• Voor Azure SQL-databases kunt u SQL Data Discovery & Classification inschakelen om kolommen te identificeren, classificeren en labelen die gevoelige gegevens bevatten, zoals creditcardnummers, burgerservicenummers of statusrecords.
• Integreer metagegevens van classificatie met downstreambesturingselementen: beleid voor preventie van gegevensverlies (DLP) configureren in Microsoft Purview, regels voor voorwaardelijke toegang toepassen in Entra-id en versleutelingsbeleid afdwingen op basis van vertrouwelijkheidslabels.
• Stel een regelmatig scanschema in om voortdurend nieuw gemaakte of gewijzigde gevoelige gegevensassets te ontdekken naarmate uw gegevensomgeving zich verder ontwikkelt.

Voorbeeld van implementatie

Een wereldwijde organisatie voor financiële dienstverlening heeft Microsoft Purview Data Map geïmplementeerd om gevoelige gegevens automatisch te detecteren en te classificeren in meer dan 200 Azure Storage-accounts, 50 SQL-databases en Synapse Analytics-werkruimten.

Uitdaging: De organisatie had geen inzicht in waar gevoelige gegevens zich in hun snel groeiende Azure-gegevensdomein bevinden. Handmatige gegevensclassificatie was inconsistent, vertraagde afdwinging van governance en maakte nalevings hiaten. Zonder geautomatiseerde detectie bleven gereguleerde gegevens (PHI, PII, PCI) onbeveiligd op niet-beheerde locaties en kon beleid ter preventie van gegevensverlies niet op de juiste wijze worden geactiveerd.

Oplossingsbenadering:

• Microsoft Purview-gegevenstoewijzing implementeren voor gegevensdetectie: Maak een Purview-account en registreer gegevensbronnen (Azure Storage-accounts, SQL-databases, Synapse Analytics-werkruimten), configureer Data Map om bronnen te scannen met behulp van verificatie van beheerde identiteiten, scanidentiteit leesmachtigingen (db_datareader rol) te verlenen aan catalogusschema's en gevoelige kolommen te detecteren.
• Classificatie- en gevoeligheidsdetectie configureren: Scanregels instellen om gevoelige patronen (SSN, creditcardnummers, medische recordnummers, SWIFT-codes) te detecteren, aangepaste classificatieregels te definiëren die zijn afgestemd op het beleid voor gegevensclassificatie ('Vertrouwelijk - Intern' voor zakelijke gegevens, 'Zeer vertrouwelijk - gereglementeerd' voor PHI/PCI/PII-gegevens), automatische labeldrempels configureren (pas "Zeer vertrouwelijk" toe wanneer ≥3 PII-patronen gedetecteerd in één asset), scanschema's instellen op basis van gegevenskritiek (wekelijks voor productie, maandelijks voor archieven) configureert u waarschuwingen om beveiligingsteams op de hoogte te stellen wanneer nieuwe gegevens met een hoge gevoeligheid worden gedetecteerd.
• Microsoft Purview Information Protection implementeren voor versleuteling op documentniveau: Maak vertrouwelijkheidslabels in de Purview-nalevingsportal met beveiligingsinstellingen (openbaar: geen versleuteling, alleen visuele markeringen; Intern: watermerk, geen doorstuurbeperkingen; Vertrouwelijk: versleutelen met Azure RMS, alleen weergeven/bewerken toestaan voor werknemers, doorsturen/afdrukken blokkeren; Zeer vertrouwelijk : gereglementeerd: versleutelen met Azure RMS, alleen-weergeven toegang, geen kopie/afdrukken/doorsturen, verlooptijd van 90 dagen, herroepbare toegang), vertrouwelijkheidslabels publiceren naar gebruikers via labelbeleid (bereik: Financiën, Juridisch, Executive-afdelingen), beleid voor automatisch labelen configureren om automatisch labels toe te passen (≥10 SSN's → 'Zeer vertrouwelijk - gereglementeerd', ≥5 creditcardnummers → 'Zeer vertrouwelijk - gereglementeerd'), Azure RMS-beveiliging inschakelen voor gelabelde documenten die zijn opgeslagen in SharePoint, OneDrive- en Azure Storage-accounts configureren labeling aan de clientzijde voor Office-toepassingen om gebruikers te vragen documenten te classificeren voordat ze worden opgeslagen/verzonden.

Resultaat: Purview Data Map identificeerde met automatische scanning meer dan 15.000 gegevensassets die gereguleerde gegevens bevatten binnen de eerste week, waardoor de detectietijd van maanden tot dagen werd teruggebracht. Automatisch labelen van Information Protection heeft binnen 72 uur versleuteling toegepast op 8500 documenten. Vertrouwelijkheidslabels zorgen voor continue zichtbaarheid van gegevens en permanente beveiliging, zelfs wanneer gegevens worden verplaatst naar onbeheerde apparaten.

Kritieksniveau

Moet hebben.

Controletoewijzing

• CIS Controls v8.1: 3.2, 3.7, 3.13
• NIST SP 800-53 Rev.5: RA-2, SC-28
• PCI-DSS v4: 3.2.1, 12.3.1
• NIST CSF v2.0: PR. DS-1, PR. DS-5
• ISO 27001:2022: A.8.11
• SOC 2: CC6.1

DP-2: Afwijkingen en bedreigingen bewaken die gericht zijn op gevoelige gegevens

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-2.

Beveiligingsprincipe

Bewaak gevoelige gegevenstoegang en overdrachtsactiviteiten voor afwijkingen die wijzen op niet-geautoriseerde exfiltratie, bedreigingen van insiders of gecompromitteerde accounts. Gebruik gedragsbasislijnen en context voor gegevensgevoeligheid om ongebruikelijke patronen te detecteren, zoals grote overdrachten, abnormale toegangstijden of onverwachte gegevensverplaatsing.

Risico om te beperken

Kwaadwillende actoren en insiders proberen gevoelige gegevens te exfiltreren, voor te bereiden of te testen met behulp van verborgen of onopvallend gedrag. Zonder continue contextbewuste anomaliebewaking die is gekoppeld aan de vertrouwelijkheid van gegevens:

• Stille exfiltratie: Bulksgewijs exporteren, grote resultatensets of incrementeel sifoneren worden niet gedetecteerd vanwege een gebrek aan basislijnen.
• Insider-misbruik: Legitieme inloggegevens voeren ongebruikelijke reeksen (tijdstip, volume, locatie) uit die grove monitoring omzeilen.
• Fasering en opsomming: Aanvallers wijzen schema's/labels toe om prioriteit te geven aan doelen met een hoge waarde vóór massa-extractie.
• Living-off-the-land queries: Standaardbeheerhulpprogramma's maskeren verkenning in normale operationele ruis.
• Cross-store-ontduiking: Gedistribueerde toegang over meerdere services voorkomt drempelwaarden en correlatie van specifieke winkels.

Ontoereikende anomaliedetectie erodes incidentrespons werkzaamheid en maakt escalatie van reconnaissance tot volledige exfiltratie mogelijk met minimale wrijving.

MITRE ATT&CK

• Verzameling (TA0009): gegevens uit cloudopslag (T1530) via afwijkende bulk- of fan-out-leesacties in gevoelige opslagcontainers.
• Referentietoegang (TA0006):geldige accounts (T1078) misbruiken van verdachte of insider-referenties om te combineren met legitieme verkeersbasislijnen.
• Exfiltratie (TA0010): geautomatiseerde exfiltratie (T1020) met behulp van gescripte, geratelimiterde query's die zijn ontworpen om onder waarschuwingsdrempels te blijven.
• Exfiltratie (TA0010): exfiltratie naar cloudopslag (T1567.002) gegevens klaarmaken in door aanvallers beheerde regio's of accounts voor later gebruik.
• Command & Control/Exfiltratie (TA0011/TA0010): applicatielaagprotocol (T1071) tunnelen van gevoelige gegevensrijen via normale database/API-aanroepen.
• Detectie (TA0007): systeem-/servicedetectie (T1082, T1046) die eindpunten opsommen om laterale verplaatsingspaden naar opslag met een hogere waarde in kaart te brengen.

DP-2.1: Detectie van bedreigingen inschakelen voor gegevensservices

Implementeer Microsoft Defender-services om realtime bedreigingsdetectie en anomaliebewaking te bieden in uw gegevensopslag- en databaseplatforms. Deze services gebruiken gedragsanalyses en bedreigingsinformatie om verdachte activiteiten te identificeren, zoals SQL-injectiepogingen, afwijkende querypatronen, ongebruikelijke gegevenstoegangsvolumes en mogelijke exfiltratie-indicatoren die traditionele toegangsbeheer niet kunnen detecteren.

Detectie van bedreigingen inschakelen voor gegevensservices:

• Schakel Microsoft Defender for Storage in met malwarescans en detectie van gevoelige gegevensbedreigingen om afwijkende toegangspatronen, ongebruikelijke upload-/downloadvolumes en mogelijke pogingen tot gegevensexfiltratie in Azure Storage-accounts te bewaken.
• Schakel Microsoft Defender voor SQL in om verdachte databaseactiviteiten te detecteren, waaronder SQL-injectiepogingen, afwijkende querypatronen, ongebruikelijke gegevensexportbewerkingen en toegang vanaf onbekende locaties.
• Schakel Microsoft Defender voor Azure Cosmos DB in om afwijkende databasetoegangspatronen, mogelijke gegevensexfiltratie en verdachte operationele activiteiten te detecteren.
• Voor opensource-databases (PostgreSQL, MySQL, MariaDB) schakelt u Microsoft Defender in voor opensource relationele databases om beveiligingsaanvallen, verdachte toegangspatronen en afwijkende administratieve bewerkingen te detecteren.

DP-2.2: Gegevensexfiltratie bewaken en voorkomen

Implementeer proactieve controles voor preventie van gegevensverlies en gedragsbewaking om niet-geautoriseerde gegevensoverdrachten te detecteren en te blokkeren voordat ze slagen. Combineer op beleid gebaseerde DLP met intern risicobeheer, SIEM-correlatie en geautomatiseerde reacties om een diepgaande verdedigingsbenadering te maken die exfiltratiepogingen via meerdere kanalen stopt en forensisch bewijs levert voor incidentonderzoek.

DLP- en interne risicocontroles implementeren:

• Gebruik DLP-beleid (Preventie van gegevensverlies) van Microsoft Purview om exfiltratie van gevoelige gegevens te voorkomen door onbevoegde overdrachten van geclassificeerde gegevens in Azure-services, Microsoft 365 en eindpunten te bewaken en te blokkeren.
• Implementeer Microsoft Purview Insider Risk Management om riskante gebruikersgedrag te detecteren met behulp van machine learning en gedragsanalyses. Monitor indicatoren van verdachte activiteiten, waaronder ongebruikelijke gegevensdownloads, het kopiëren van bestanden naar USB-/persoonlijke cloudopslag, het openen van gevoelige resources buiten de normale werkuren, of pieken in gegevenstoegang voordat er ontslag wordt genomen. Insider Risk Management correleert signalen van Microsoft 365-, Azure-, HR-systemen en beveiligingshulpprogramma's om mogelijke diefstal van gegevens of beleidsschendingen te identificeren.

Bewaking en reactie configureren:

• Configureer diagnostische logboeken voor gegevensservices en routeer ze naar Azure Monitor of Microsoft Sentinel om gedragsbasislijnen vast te stellen en afwijkingen van normale toegangspatronen te detecteren.
• Integreer gegevensservicelogboeken met Microsoft Sentinel om analyseregels te maken voor het detecteren van afwijkende gegevenstoegangspatronen, zoals bulkdownloads, toegang buiten kantooruren of verdacht querygedrag.
• Implementeer geautomatiseerde werkstromen voor incidentrespons met behulp van Azure Logic Apps of Microsoft Sentinel-playbooks om gecompromitteerde identiteiten te isoleren, toegang in te trekken en beveiligingsteams op de hoogte te stellen wanneer pogingen tot gegevensexfiltratie worden gedetecteerd.

Notitie: Voor DLP-vereisten op basis van een host implementeert u DLP-mogelijkheden van Microsoft Purview Endpoint of oplossingen van derden van Azure Marketplace om besturingselementen voor gegevensbeveiliging op eindpuntniveau af te dwingen.

Voorbeeld van implementatie

Een gezondheidszorgprovider heeft Microsoft Defender voor Storage en Defender voor SQL ingeschakeld om afwijkingen en bedreigingen te bewaken die gericht zijn op patiëntgegevens in Azure Storage-accounts en SQL-databases.

Uitdaging: De organisatie heeft blinde vlekken ervaren bij het detecteren van onbevoegde gegevenstoegang en exfiltratiepogingen. Traditionele perimeterbeveiliging hadden geen oog voor interne bedreigingen en gecompromitteerde service-principals die bulkdownloads uitvoerden. Zonder gedragsanalyse en anomaliedetectie bleven verdachte toegangspatronen gedurende langere perioden onopgemerkt, waardoor het risico op inbreuken toeneemt en de verblijftijd langer wordt.

Oplossingsbenadering:

• Microsoft Defender for Storage inschakelen: Schakel Defender for Storage op abonnementsniveau in voor opslagaccounts met gevoelige gegevens, configureer malwarescans om schadelijke bestanden in blobopslag te detecteren en in quarantaine te plaatsen, detectie van gevoelige gegevens in te schakelen met Purview Gevoelige informatietypen om PHI/PII-patronen te identificeren, scanlimieten per transactie of maandelijks kapitaal in te stellen om kosten te beheren, beveiliging toe te passen op resourcegroepen met productieopslagaccounts die medische imaging en EHR-exports hosten.
• Microsoft Defender voor SQL inschakelen: Schakel Defender voor SQL in op abonnementsniveau voor Azure SQL Database en SQL Managed Instance, configureer Evaluatie van beveiligingsproblemen met terugkerende scans en wijs opslagaccount aan voor scanresultaten, stel e-mailmeldingen in om beveiligingsteam van geïdentificeerde beveiligingsproblemen te waarschuwen, Advanced Threat Protection in staat te stellen SQL-injectiepogingen, ongebruikelijke querypatronen, afwijkende toegang vanuit onbekende regio's te detecteren, en mogelijke gegevensexfiltratie.
• Integreren met Microsoft Sentinel: Microsoft Defender for Cloud verbinden met Microsoft Sentinel met behulp van gegevensconnector, diagnostische instellingen configureren (diagnostische logboeken inschakelen voor opslagbewerkingen en SQL-controlelogboeken, routeren naar Log Analytics-werkruimte), Sentinel Analytics-regels maken om afwijkingen te detecteren (bulksgewijs downloaden waarschuwingen voor downloads >van 10 GB binnen 1 uur, externe databasetoegang, verdachte querypatronen), geautomatiseerde antwoordplaybooks configureren om aangetaste identiteiten te isoleren, opslagtoegang intrekken en beveiligingsteams waarschuwen.
• Implementeer Microsoft Purview Insider Risk Management voor detectie van gedragsrisico's: Intern risicobeheer inschakelen en beleidssjablonen configureren (gegevensdiefstal door vertrekkende gebruikers detecteren ongebruikelijke bestandsdownloads 30-90 dagen voordat ze worden ontslag genomen, algemene gegevenslekken bewaken usb-/cloudopslag kopiëren, gegevenslekken door prioriteitsgebruikers met verbeterde bewaking voor rollen met hoge bevoegdheden), risicoindicatoren en drempelwaarden configureren (cumulatieve waarschuwingen voor bestandsdownloadvolumes, pieken in toegang buiten kantooruren, reeksdetectie waarbij meerdere riskante signalen worden gecombineerd), integreer gegevensbronnen (Azure-activiteitenlogboeken, Microsoft 365-auditlogboeken, Defender for Cloud Apps, HR-systemen, DLP-eindpuntgebeurtenissen), configureer waarschuwingen voor het routeren van werkstromen met gemiddelde/hoge urgentie voor toegewezen onderzoekswachtrij.

Resultaat: Defender for Storage heeft binnen 48 uur afwijkende bulkdownloadactiviteiten van een gecompromitteerde service-principal gedetecteerd. De identiteit werd door een geautomatiseerde respons geïsoleerd en waarschuwde de SOC binnen enkele minuten, waardoor de detectietijd werd verkort van dagen tot minder dan 15 minuten. Insider Risk Management heeft een vertrekkende werknemer gemarkeerd die onderzoeksgegevens downloadt die aanzienlijk hoger is dan de persoonlijke basislijn naar persoonlijke cloudopslag, waardoor snelle interventie mogelijk is.

Kritieksniveau

Moet hebben.

Controletoewijzing

• CIS-controlemaatregelen v8.1: 3.13
• NIST SP 800-53 Rev.5: AC-4, SI-4
• PCI-DSS v4: 3.2.1, 10.4.1
• NIST CSF v2.0: DE. CM-1, PR. DS-5
• ISO 27001:2022: A.8.11, A.8.16
• SOC 2: CC6.1, CC7.2

DP-3: Gevoelige gegevens versleutelen tijdens overdracht

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-3.

Beveiligingsprincipe

Beveilig gegevens die onderweg zijn met sterke versleuteling (zoals TLS 1.2 of hoger) om onderschepping, manipulatie en onbevoegde toegang te voorkomen. Definieer netwerkgrenzen en servicebereiken waarbij versleuteling verplicht is, waarbij extern en openbaar netwerkverkeer wordt prioriteren terwijl interne netwerkbeveiliging wordt overwogen op basis van gegevensgevoeligheid.

Risico om te beperken

Niet-versleutelde of zwak beveiligde netwerkkanalen stellen gevoelige gegevens bloot aan onderschepping, manipulatie en downgrade-aanvallen. Afwezige moderne transportversleuteling (TLS 1.2+):

• Passieve interceptie: Netwerkobservatoren leggen referenties, tokens, API-belastingen of gereglementeerde gegevens vast in platte tekst.
• Man-in-the-middle: Aanvallers wijzigen query's, injecteren payloads of verzamelen sessiemateriaal.
• Protocol downgrade: Lagere versie ter ondersteuning (SSL/TLS < 1.2, plaintext HTTP/FTP) maakt exploitatie mogelijk van verouderde coderingssuites.
• Sessiekaaping: Gebrek aan kanaalintegriteit maakt token-replay of cookiediefstal mogelijk voor zijwaartse beweging.
• Integriteitsmanipulatie: Knoeien beschadigt analyses of veroorzaakt frauduleuze transacties.
• Ondoorzichtige zijpaden: Intern platte tekst verkeer wordt recon materiaal na het verkrijgen van een voet aan de grond.

Het niet afdwingen van sterke versleuteling tijdens transit vergroot de impact van een datalek, versnelt de compromittering van referenties en ondermijnt de aannames van zero trust.

MITRE ATT&CK

• Toegang tot referenties (TA0006): onbeveiligde referenties (T1552) onderschept in plaintext of gedowngradeerde TLS-sessies waarbij tokens of sessiemateriaal worden blootgesteld.
• Verzameling (TA0009): netwerksniffing (T1040) waarbij API-payloads en geheimen worden onderschept die zwakke coderings- of cleartextpaden volgen.
• Exfiltratie (TA0010): exfiltratie via webservices (T1567) waarbij gestructureerde gegevens worden gestreamd via legitieme API-eindpunten.
• Defense Evasion (TA0005): man-in-the-middle-aanval (T1557) die een TLS-downgrade forceert of interceptieproxies inzet om verkeer te bekijken/te wijzigen.
• Command & Control (TA0011): niet-applicatielaagprotocol (T1095) dat terugkeert naar verouderde of minder geïnspecteerde transporten om bewaking te ontwijken.

DP-3.1: TLS-versleuteling afdwingen voor gegevensservices en toepassingen

Stel moderne beveiligingsstandaarden voor transportlagen vast voor alle klantgerichte services en gegevensplatformen om te beschermen tegen onderschepping, manipulatie en man-in-the-middle-aanvallen. Dwing minimaal TLS 1.2 of 1.3 af voor opslag, webtoepassingen, databases en API-gateways, terwijl verouderde protocollen en zwakke coderingssuites worden uitgeschakeld die gegevens blootstellen aan cryptografische downgradeaanvallen.

TLS afdwingen voor gegevensservices en toepassingen:

• Dwing beveiligde overdracht (alleen HTTPS) af voor Azure Storage-accounts om ervoor te zorgen dat alle clientverbindingen TLS 1.2 of hoger gebruiken voor blob-, bestands-, wachtrij- en tabelbewerkingen.
• Voor webtoepassingen die worden gehost in Azure App Service, schakelt u de instelling 'Alleen HTTPS' in en configureert u de minimale TLS-versie op 1.2 of 1.3 om downgradeaanvallen te voorkomen en moderne cryptografische standaarden te garanderen.
• Configureer Azure Application Gateway om tls 1.2/1.3 minimale versie af te dwingen voor zowel front-endlisteners als back-endverbindingsversleuteling (end-to-end TLS).
• Controleer voor Azure SQL Database en andere PaaS-gegevensservices of 'Beveiligde verbindingen vereisen' of gelijkwaardige instellingen versleutelde verbindingen afdwingen; niet-opgemaakte tekstverbindingen weigeren.
• Configureer voor API Management, Azure Front Door en andere gatewayservices minimale TLS-versiebeleid om TLS 1.2 of hoger af te dwingen en zwakke coderingssuites uit te schakelen.

Notitie: Azure versleutelt automatisch al het verkeer tussen Azure-datacenters met MACsec (laag 2) en TLS (laag 7). Voor de meeste Azure PaaS-services is TLS 1.2+ standaard ingeschakeld, maar controleert u de minimale TLS-versie-instellingen voor services met door de klant configureerbare beleidsregels (Opslag, App Service, Application Gateway, API Management, Front Door).

DP-3.2: Veilige protocollen voor externe toegang en bestandsoverdracht

Elimineer platte tekst beheertoegang en verouderde protocollen voor bestandsoverdracht die referenties en gevoelige gegevens onthullen tijdens operationele processen. Vervang onveilige protocollen (FTP, niet-versleutelde RDP/SSH) door moderne, versleutelde alternatieven en routegeprivilegieerde toegang via gecentraliseerde bastions om directe internetblootstelling van beheerinterfaces te elimineren.

Protocollen voor extern beheer beveiligen:

• Gebruik voor extern beheer van virtuele Azure-machines uitsluitend beveiligde protocollen:
  • Linux-VM's: SSH (poort 22) gebruiken met verificatie op basis van sleutels; wachtwoordverificatie uitschakelen.
  • Windows-VM's: Gebruik RDP via TLS (poort 3389) met netwerkverificatie (NLA) ingeschakeld.
  • Bevoegde toegang: Routeer beheerverbindingen via Azure Bastion om openbare IP-blootstelling te elimineren en browsergebaseerde of systeemeigen clienttoegang via TLS te bieden.

Protocollen voor bestandsoverdracht beveiligen:

• Voor bestandsoverdrachtsbewerkingen gebruikt u beveiligde protocollen en schakelt u verouderde alternatieven uit:
  • Gebruik SFTP-ondersteuning in Azure Blob Storage (vereist hiërarchische naamruimte).
  • FTPS gebruiken in Azure App Service en Azure Functions.
  • Verouderd FTP-protocol uitschakelen (plaintext).
• Gebruik Azure Policy om veilig overdrachtsbeleid af te dwingen in uw omgeving en naleving te bewaken voor TLS-versievereisten.

Voorbeeld van implementatie

Een e-commerceplatform dwingt TLS 1.3-minimumversie af voor alle klantgerichte services om te voldoen aan PCI-DSS 4.0-vereisten.

Uitdaging: Verouderde TLS 1.0/1.1-protocollen en zwakke coderingssuites hebben klantbetalingsgegevens blootgesteld aan onderscheppingsaanvallen. Inconsistente TLS-afdwinging in toepassingslagen heeft beveiligingslacunes gecreëerd waarbij aanvallers verbindingen konden downgraden. Zonder gecentraliseerde afdwinging van TLS-beleid heeft handmatige configuratiedrift onveilige protocollen toegestaan om in productie te blijven.

Oplossingsbenadering:

• Azure App Service configureren voor TLS 1.3: Stel minimale TLS-versie in op 1.3 voor klantgerichte webtoepassingen en API's, schakel de modus ALLEEN-HTTPS in om automatisch alle HTTP-verkeer om te leiden naar HTTPS, controleer of beheerde certificaten of aangepaste certificaten gebruikmaken van sterke coderingssuites.
• Azure Application Gateway configureren voor end-to-end TLS: Configureer front-end HTTPS-listener met SSL-beleid AppGwSslPolicy2020101 (TLS 1.3 minimum met AangepastEV2-beleid), upload TLS-certificaat of integreer met Key Vault voor certificaatbeheer, configureer back-endinstellingen voor HTTPS-verbindingen (stel back-endprotocol in op HTTPS op poort 443, schakel 'Bekende CA-certificaat gebruiken' in als back-end-App Services gebruikmaken van door Azure beheerde certificaten, minimale TLS-versie instellen op 1.2 voor back-endverbindingen), routeringsregels maken die HTTPS-listeners koppelen aan back-endpools met instellingen voor TLS.
• Veilige overdracht afdwingen voor Azure Storage: Schakel de instelling Veilige overdracht vereist in om alleen-HTTPS af te dwingen voor blob-, bestands-, wachtrij- en tabelbewerkingen, minimale TLS-versie in te stellen op 1.2 voor alle opslagverbindingen. Controleer of alle SAS-tokens en gedeelde sleutels alleen via HTTPS-verbindingen werken.
• Azure Bastion configureren voor beveiligde externe toegang: Implementeer Azure Bastion in hub-VNet om rdp-/SSH-toegang via TLS 1.2 in de browser te bieden, openbare IP-adressen van VM's te verwijderen en alle beheerderstoegang exclusief via Bastion te routeren.

Resultaat: Azure Storage-accounts weigeren HTTP-verbindingen aan de servicegrens, Application Gateway dwingt TLS 1.3 af voor front-endverbindingen met TLS 1.2-back-endversleuteling en Azure Bastion elimineert openbare IP-blootstelling voor VM-beheer.

Kritieksniveau

Moet hebben.

Controletoewijzing

• CIS Controls v8.1: 3.10
• NIST SP 800-53 Rev.5: SC-8
• PCI-DSS v4: 4.2.1, 4.2.2
• NIST CSF v2.0: PR. DS-2
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1, CC6.7

DP-4: Gegevens-at-rest-versleuteling standaard inschakelen

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-4.

Beveiligingsprincipe

Schakel versleuteling in rust standaard in om gegevens te beschermen tegen onbevoegde toegang via onderliggende opslag, fysieke mediadiefstal, blootstelling aan momentopnamen of gecompromitteerde toegang tot de infrastructuur. Versleuteling vormt een aanvulling op toegangsbeheer door ervoor te zorgen dat gegevens beveiligd blijven, zelfs wanneer beveiliging op opslagniveau wordt overgeslagen.

Risico om te beperken

Met niet-versleutelde of selectief versleutelde opslaglagen kunnen aanvallers met out-of-band-toegang (infrastructuurcompromittatie, gestolen media, misbruik van momentopnamen) gevoelige gegevens op schaal verzamelen. Zonder standaardversleuteling:

• Gegevens die worden opgehaald uit onbewerkte media: Gestolen schijven, back-ups of onbeheerde momentopnamen maken volledige gegevenssets met tekst zonder opmaak beschikbaar.
• Erosie van bevoegdheden: Platformbeheerders of gecompromitteerde hostagents kunnen tenantgegevens lezen zonder cryptografische scheiding.
• Stille kopie en exfiltratie: Niet-versleutelde replica's (test, analyse, export) worden exfiltratiekanalen met lage wrijving.
• Integriteitsknoeien: Aanvallers wijzigen inactieve gegevens (schadelijke DLL's, configuratie of referentiegegevens) om een latere fase van een inbreuk te veroorzaken.
• Niet-naleving van regelgeving: Gebrek aan systemische versleuteling ondermijnt de garanties die vereist zijn voor veel branchecertificeringen.
• Sleutelloze herstelblootstelling: Afbeeldingen voor herstel na noodgevallen en koude archieven bewaren gevoelige inhoud voor onbepaalde tijd in herstelbare tekst zonder opmaak.

Het niet afdwingen van universele encryptie-at-rest vergroot de omvang van inbreuken, compliceert de forensische scope en verhoogt operationele en juridische downstream risico's.

MITRE ATT&CK

• Verzameling (TA0009): gegevens uit cloudopslag (T1530) door niet-versleutelde momentopnamen, replica's of losgekoppelde schijven te extraheren.
• Defense Evasion (TA0005): verwijderen van indicatoren (T1070) bewerken of opschonen van logboeken na toegang tot offlinemedia of momentopnamen.
• Impact (TA0040): gegevensvernietiging (T1485) die ongecodeerde inactieve activa corrumperen om downstreamprocessen te verstoren.
• Impact (TA0040): systeemherstel (T1490) inhiberen door het verwijderen of wijzigen van niet-versleutelde back-ups en herstelcatalogussen.
• Impact (TA0040): gegevensmanipulatie (T1565) waarbij opgeslagen verwijzings- of configuratiegegevens subtiel worden gewijzigd om later stadium logische fouten te veroorzaken.

DP-4.1: Gegevens-at-rest-versleuteling standaard inschakelen

Zorg ervoor dat alle gegevens die in Azure zijn opgeslagen, in rust worden versleuteld om te beschermen tegen ongeoorloofde toegang door inbreuk op de infrastructuur, gestolen media of niet-geautoriseerde momentopnamen. Hoewel de meeste Azure-services standaard versleuteling inschakelen, controleert u de dekking van virtuele machines, opslagaccounts en databases en schakelt u extra versleutelingslagen (versleuteling op host, infrastructuurversleuteling, vertrouwelijke computing en versleuteling op kolomniveau) in voor zeer gevoelige workloads om te voldoen aan vereisten voor regelgeving en gegevenssoevereine.

Versleuteling inschakelen voor VM's en opslag:

• Schakel versleuteling op host in voor Virtuele Azure-machines om tijdelijke schijven, cache van besturingssysteemschijven, gegevensschijfcache en tijdelijke besturingssysteemschijven te versleutelen voordat gegevens Azure Storage bereiken. Registreer de functie EncryptionAtHost op abonnementsniveau en implementeer VM's met ondersteunde VM-grootten (bijvoorbeeld DSv3, Easv4, Dadsv5-serie).
• Schakel infrastructuurversleuteling (dubbele versleuteling) in voor Azure Storage-accounts waarvoor extra versleutelingslagen zijn vereist. Dit biedt twee lagen AES-256-versleuteling met verschillende sleutels op service- en infrastructuurniveau: configureer tijdens het maken van het opslagaccount omdat deze niet kan worden ingeschakeld na het maken.

Confidential Computing en versleuteling op kolomniveau implementeren:

• Implementeer Azure Confidential-VM's met vertrouwelijke schijfversleuteling voor sterk gereglementeerde workloads die exportgestuurde of gevoelige gegevens verwerken. Gebruik DCasv5/DCadsv5-serie (AMD SEV-SNP) of ECasv5/ECadsv5-serie (Intel TDX) met vTPM-gebonden schijfversleutelingssleutels om ervoor te zorgen dat gegevens tijdens de verwerking versleuteld blijven.
• Voor Azure SQL Database implementeert u Always Encrypted om versleuteling op kolomniveau aan de clientzijde te bieden voor uiterst gevoelige gegevens (SSN, creditcardnummers, medische records) waar gegevens versleuteld blijven, zelfs van databasebeheerders, cloudoperators en onbevoegde gebruikers. Gebruik Always Encrypted met beveiligde enclaves (Intel SGX) om uitgebreidere query's op versleutelde kolommen mogelijk te maken.

Versleutelingscompatibiliteit bewaken en afdwingen:

• Versleutelingsnaleving afdwingen met behulp van Azure Policy door ingebouwde beleidsregels toe te wijzen, zoals 'Virtuele machines moeten versleuteling op host inschakelen', 'Opslagaccounts moeten infrastructuurversleuteling hebben' en 'Transparent Data Encryption op SQL-databases moet zijn ingeschakeld' op abonnements- of beheergroepbereik.
• Gebruik Azure Resource Graph om configuraties voor versleuteling in uw omgeving op te vragen en inventariseren, vm's te identificeren zonder versleuteling op host, opslagaccounts zonder infrastructuurversleuteling of databases waarvoor TDE is ingeschakeld.

Notitie: Veel Azure-services (Azure Storage, Azure SQL Database, Azure Cosmos DB) hebben standaard data-at-rest-versleuteling ingeschakeld op de infrastructuurlaag met behulp van door de service beheerde sleutels die automatisch om de twee jaar draaien. Als versleuteling niet standaard is ingeschakeld, schakelt u deze in op opslag-, bestand- of databaseniveau op basis van technische haalbaarheids- en workloadvereisten.

Voorbeeld van implementatie

Een multinationaal productiebedrijf gestandaardiseerde versleuteling-at-rest in hun Azure-omgeving om ERP-gegevens, supply chain-toepassingen en technische handelsgeheimen te beschermen.

Uitdaging: Inconsistente versleutelingsdekking heeft gevoelige gegevens kwetsbaar gemaakt voor inbreuk op de infrastructuur en diefstal van momentopnamen. Tijdelijke schijfgegevens en tijdelijke opslag bleven niet-versleuteld, waardoor er hiaten in de naleving ontstaan. Zonder systematische afdwinging van versleuteling kunnen technische handelsgeheimen en toeleveringsketengegevens worden weergegeven via gestolen schijven, niet-geautoriseerde momentopnamen of gecompromitteerde hostagents.

Oplossingsbenadering:

• Versleuteling op host inschakelen voor virtuele Azure-machines: Registreer de functie EncryptionAtHost op abonnementsniveau, schakel versleuteling op host in voor VM's met ondersteunde VM-grootten (DSv3, Easv4, Dadsv5-serie), versleuteling omvat tijdelijke schijven, besturingssysteemschijfcache, gegevensschijfcache en tijdelijke besturingssysteemschijven.
• Infrastructuurversleuteling (dubbele versleuteling) inschakelen voor Azure Storage: Controleer of Azure Storage Service Encryption (SSE) is ingeschakeld (standaard AES-256-versleuteling), voor gevoelige opslagaccounts: infrastructuurversleuteling inschakelen tijdens het maken van het opslagaccount (kan niet worden ingeschakeld na het maken), resultaat: twee lagen AES-256-versleuteling met verschillende sleutels.
• Azure Confidential-VM's implementeren voor sterk gereglementeerde workloads: Selecteer de juiste Confidential VM-serie (DCasv5/DCadsv5-serie voor AMD SEV-SNP of ECasv5/ECadsv5-serie voor Intel TDX), schakel vertrouwelijke schijfversleuteling in met platform beheerde sleutel (koppelt schijfversleutelingssleutels aan de virtuele TPM van de VIRTUELE MACHINE), schakel Beveiligd opstarten en vTPM in voor attestation, implementeer voor workloads die exportgestuurde technische gegevens of sterk gereglementeerde PII verwerken, waarbij gegevens versleuteld moeten blijven tijdens de verwerking.
• Always Encrypted implementeren voor gevoelige databasekolommen: Identificeer zeer gevoelige kolommen in Azure SQL Database waarvoor versleuteling op kolomniveau is vereist (SSN, CreditCardNumber, MedicalRecordNumber), genereer sleutels voor kolomversleuteling (CEK) en kolomhoofdsleutels (CMK) die CMK opslaan in Azure Key Vault met CEK-versleuteling van gegevenskolommen en CMK versleutelen CEK, schakel Always Encrypted in met beveiligde enclaves (Intel SGX) om uitgebreidere query's op versleutelde gegevens toe te staan, gevoelige kolommen te versleutelen met behulp van deterministische versleuteling (voor gelijkheidszoekacties) of willekeurige versleuteling (maximale beveiliging), configureer toepassingsverbindingsreeksen met Kolomversleutelingsinstelling=Ingeschakeld voor transparante versleuteling/ontsleuteling.
• Inventarisversleutelingsconfiguraties met Azure Resource Graph: Query's uitvoeren op versleutelingsstatus voor VM's zonder versleuteling op host- en opslagaccounts zonder infrastructuurversleuteling, resultaten exporteren naar CSV en hersteltaken toewijzen aan resource-eigenaren.

Resultaat: Encryptie-at-host heeft nalevingsproblemen aangepakt waarbij tijdelijke schijfgegevens voorheen niet waren versleuteld. Technische bestanden zijn met infrastructuurversleuteling beveiligd door middel van twee lagen van encryptie. Vertrouwelijke VM's zorgen ervoor dat exportgestuurde gegevens versleuteld blijven, zelfs van cloudbeheerders. Always Encrypted beveiligde gevoelige databasekolommen: databasebeheerders hebben bevestigd dat platte tekst uit versleutelde kolommen niet kan worden gelezen en voldoen daarmee aan de nalevingsvereisten.

Kritieksniveau

Moet hebben.

Controletoewijzing

• CIS-controls v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-28
• PCI-DSS v4: 3.5.1, 3.6.1
• NIST CSF v2.0: PR. DS-1
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-5: De door de klant beheerde sleuteloptie gebruiken in data-at-rest-versleuteling wanneer dat nodig is

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-5.

Beveiligingsprincipe

Gebruik door de klant beheerde sleutels wanneer naleving van regelgeving, contractuele vereisten of gegevensgevoeligheid directe controle vereisen over de levenscyclus van versleutelingssleutels, waaronder sleutelgeneratie, rotatie en intrekkingsinstantie. Zorg ervoor dat de juiste processen voor sleutelbeheer worden uitgevoerd om de operationele overhead af te handelen.

Risico om te beperken

Het uitsluitend vertrouwen op door de service beheerde sleutels wanneer wettelijke, contractuele of scheidingsgaranties beheerscontrole door de gebruikers eisen, introduceert nalevings- en risico's omtrent concentratie. Zonder goed beheerde door klanten beheerde sleutels (CMK):

• Ontoereikende regelgevingsgarantie: Auditors kunnen bewijs van cryptografische controle afwijzen als sleutelbewaarneming, rotatiefrequentie of intrekkingsinstantie niet kan worden gedemonstreerd.
• Intrekkingslatentie: Het onvermogen om gecompromitteerde platformsleutels snel in te trekken of te roteren, vergroot het blootstellingsvenster na authenticatie- of supply chain-evenementen.
• Jurisdictieblootstelling: Voor mandaten voor gegevenssoevereiniteit zijn mogelijk door tenants beheerde sleutels of sleutels met HSM-ondersteuning vereist. Afwezigheid vermindert de levensvatbaarheid van regionale implementatie.
• Straal tussen tenants: Inbreuk op platformsleutels met meerdere tenants kan van invloed zijn op brede gegevenssets wanneer cryptografische isolatie onvoldoende is.
• Schaduwproliferatie: Ad-hoc CMK-implementaties zonder levenscyclusbeheer leiden tot verouderde, zwevende of zwakke sleutels.
• Operationele fragiliteit: Slechte rotatieautomatisering of ontbrekende afhankelijkheidstoewijzing zorgt ervoor dat toepassingsstoringen optreden tijdens de sleutelrollover.

Onjuist of weggelaten CMK-gebruik verzwakt cryptografische zekerheid en ondermijnt strategische nalevingspositie voor gevoelige workloads.

MITRE ATT&CK

• Referentietoegang (TA0006):onbeschermde referenties (T1552) blootgesteld door zwak beveiligde of onjuist gesegmenteerde platformsleutels.
• Impact (TA0040): gegevens die zijn versleuteld om het effect te maximaliseren (T1486) door misbruik te maken van CMK-rotatie en intrekking om gegevens ontoegankelijk te maken.
• Impact (TA0040): gegevensmanipulatie (T1565) waarbij metagegevens van de versleutelingsstatus worden gewijzigd om beveiligingslagen te desynchroniseren.
• Exfiltratie (TA0010): gegevens overdragen naar een cloudaccount (T1537) waarbij gegevenssets opnieuw worden versleuteld en geëxporteerd naar door aanvaller beheerde opslag.
• Exfiltratie (TA0010): exfiltratie via webservices (T1567) voor het organiseren van bulkexports met hoge volumes, met sleutels ingeschakelde bulkexports onder normale servicepatronen.

DP-5.1: Gebruik door de klant beheerde sleuteloptie in data-at-rest-versleuteling indien nodig

Implementeer door de klant beheerde sleutels wanneer naleving van regelgeving, mandaten voor gegevenssoevereiniteit of contractuele verplichtingen directe controle vereisen over het bewaren van versleutelingssleutels, rotatieschema's en intrekkingsinstantie. Voor workloads waarvoor zelfs Microsoft geen gegevens kan ontsleutelen, implementeert u DKE (Double Key Encryption) waar uw organisatie een tweede versleutelingssleutel buiten Azure onderhoudt. Gebruik Azure Key Vault of Beheerde HSM om cryptografische controle te behouden terwijl u de operationele complexiteit van sleutellevenscyclusbeheer, planning voor herstel na noodgevallen en mogelijke gevolgen voor de beschikbaarheid van services van belangrijke beheerfouten in balans houdt.

CMK-vereisten evalueren en sleutelinfrastructuur inrichten:

• Evalueer wettelijke, nalevings- of bedrijfsvereisten om te bepalen welke workloads door de klant beheerde sleutels (CMK) nodig hebben in plaats van door het platform beheerde sleutels. Veelvoorkomende drijfveren zijn gegevenssoevereiniteit, auditvereisten en contractuele verplichtingen voor directe bewaring van sleutelbeheer.
• Provisioneer Azure Key Vault (Standard of Premium) of Azure Key Vault Managed HSM om door de klant beheerde versleutelingssleutels op te slaan en te beheren. Gebruik Beheerde HSM voor workloads waarvoor door FIPS 140-3 niveau 3 gevalideerde hardwarebeveiliging is vereist.
• Genereer versleutelingssleutels in Azure Key Vault met behulp van mogelijkheden voor het genereren van sleutels of importeer sleutels uit on-premises HSM's met BYOK (Bring Your Own Key) voor maximale draagbaarheid en controle.

CMK configureren en sleutelhiërarchie tot stand brengen:

• Voor extreme controlevereisten implementeert u Double Key Encryption (DKE) waarbij voor gevoelige documenten twee sleutels nodig zijn voor ontsleuteling: één beheerd door Microsoft (Azure RMS) en een tweede sleutel die exclusief wordt beheerd door uw organisatie on-premises of in uw eigen externe sleutelbeheerservice. Met DKE kan Microsoft uw gegevens niet ontsleutelen, zelfs niet als dit wordt gedwongen door juridische processen, omdat u de tweede sleutel bepaalt die nodig is voor ontsleuteling.
• Configureer Azure-services (Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Disk Encryption, enzovoort) om CMK te gebruiken door te verwijzen naar de Key Vault-sleutel-URI. Schakel beleid voor automatische sleutelrotatie in om handmatige operationele lasten te verminderen.
• Stel een KEK-hiërarchie (Key Encryption Key) en DEK-hiërarchie (Data Encryption Key Key) in, waarbij de KEK (opgeslagen in Key Vault) de DEK (gebruikt door services) versleutelt, waardoor de impact van sleutelrotatie op de beschikbaarheid van de service wordt geminimaliseerd.
• Documenteer de levenscyclusprocedures voor sleutels, waaronder schema's voor sleutelrotatie, intrekkingsprocessen voor gecompromitteerde sleutels, werkstromen voor het buiten gebruik stellen van sleutels, en procedures voor herstel bij noodsituaties. Integreer sleutelbeheer in de processen voor wijzigingsbeheer van uw organisatie.

Notitie: Door de klant beheerde sleutels vereisen doorlopende operationele investeringen, waaronder sleutellevenscyclusbeheer, beheer van toegangsbeheer, bewaking en planning voor herstel na noodgevallen. Zorg voor operationele gereedheid voordat u CMK gaat gebruiken, omdat onjuist sleutelbeheer kan leiden tot onbeschikbaarheid of verlies van gegevens.

Voorbeeld van implementatie

Een gereglementeerde financiële instelling heeft door de klant beheerde sleutels (CMK) geïmplementeerd in Azure-services om te voldoen aan wettelijke vereisten voor directe cryptografische controle over handelsgegevens en financiële records van klanten.

Uitdaging: Regelgevende auditors hebben cryptografische controle vereist, waaronder sleutelbewaarneming, roulatie-instantie en intrekkingsmogelijkheid. Sleutels beheerd door de service kunnen geen bewijs leveren van de door de huurder beheerde sleutellevenscyclus. Zonder door de klant beheerde sleutels had de organisatie niet de mogelijkheid om de toegang snel in te trekken tijdens beveiligingsincidenten en kon deze niet voldoen aan de vereisten voor gegevenssoevereiniteit voor regionale implementaties.

Oplossingsbenadering:

• Beheerde HSM van Azure Key Vault inrichten: Beheerde HSM maken (FIPS 140-3 Niveau 3 gevalideerd) met minimaal 3 HSM-partities voor hoge beschikbaarheid, activeer beheerde HSM door beveiligingsdomein te exporteren met quorumsleutels (gesplitst in sleutelfragmenten die zijn opgeslagen in geografisch gedistribueerde offlinekluizen), versleutelingssleutels (RSA-4096 met de naam KEK-Prod-2024) te genereren met sleutelbewerkingen: Sleutel verpakken, Sleutel uitpakken, Versleutelen, Ontsleutelen.
• Door de klant beheerde sleutels configureren voor Azure-services: Voor Azure Storage configureert u het opslagaccount voor het gebruik van het CMK-versleutelingstype, selecteert u Key Vault Managed HSM als sleutelbron, schakelt u door de gebruiker toegewezen beheerde identiteit in met de gebruikersrol Managed HSM Crypto Service Encryption; voor Azure SQL Database SQL Database configureren voor het gebruik van door de klant beheerde sleutel als TDE-beveiliging, selecteer sleutel uit beheerde HSM, schakel automatische rotatie in; voor Azure Cosmos DB door de klant beheerde sleutels inschakelen voor een Cosmos DB-account, beheerde HSM-sleutel selecteren en cosmos DB beheerde identiteit toegang verlenen.
• Geautomatiseerde sleutelrotatie implementeren: Configureer rotatiebeleid met een rotatiefrequentie van 90 dagen, schakel automatische rotatie in, configureer de verloopmelding (waarschuwing 7 dagen vóór de vervaldatum), maak een Azure Monitor-waarschuwing voor metrische gegevens over sleutel bijna verlopen om beveiligingsteam op de hoogte te stellen.
• Auditlogboekregistratie inschakelen voor naleving: Schakel diagnostische logboekregistratie in voor beheerde HSM -logboeken (AuditEvent-logboeken), verzend logboeken naar de Log Analytics-werkruimte met onveranderbare opslag (retentie van 90 dagen voor controletrails voor manipulatiecontrole), toegangslogboeken voor querysleutels voor het bewaken van versleutelings-, ontsleutelings-, WrapKey- en UnwrapKey-bewerkingen.
• Levenscyclusprocedures voor documentsleutels: Maak noodintrekkingsrunbooks (belangrijke intrekkingsstappen, contactpersonen voor incidentrespons, herstelprocedures met behulp van quorumsleutels voor beveiligingsdomeinen), test runbooks elk kwartaal via tabletop-oefeningen, integreer CMK-bewerkingen in de goedkeuringswerkstroom voor IT Service Management-wijzigingen.

Resultaat: RSA-4096-KEKs in beheerde HSM versleutelen serviceniveauDEK's voor Azure Storage, SQL Database en Cosmos DB. Driemaandelijkse geautomatiseerde rotatie minimaliseert downtime door alleen DEK's opnieuw te versleutelen. Het quorum van het beveiligingsdomein zorgt voor herstel na noodgevallen, zelfs met een volledige regionale fout.

Kritieksniveau

Had moeten.

Controletoewijzing

• CIS-controls v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-12, SC-28
• PCI-DSS v4: 3.5.1, 3.6.1, 12.3.2
• NIST CSF v2.0: PR. DS-1, ID.AM-3
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-6: Een beveiligd sleutelbeheerproces gebruiken

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-6.

Beveiligingsprincipe

Implementeer veilige processen voor sleutelbeheer die de volledige levenscyclus van de sleutel bepalen: genereren, distribueren, opslag, rotatie en intrekking. Gebruik toegewezen sleutelkluisservices met sterke toegangsbeheer, onderhoud cryptografische standaarden, dwing scheiding van taken af en zorg ervoor dat sleutels regelmatig worden geroteerd en onmiddellijk worden ingetrokken wanneer er inbreuk wordt gemaakt.

Risico om te beperken

Zwakke of onbeheerde cryptografische sleutellevenscycli verminderen de zekerheid die wordt geboden door versleuteling en kunnen systemische inbreuk mogelijk maken. Zonder gestructureerde sleutelgeneratie, rotatie, beveiliging en intrekking:

• Sleutelsprawl en wezenvorming: Niet-bijgehouden sleutels blijven bestaan zonder zakelijke noodzaak, waardoor ze onbedoeld decryptiebevoegdheid behouden.
• Verouderde cryptografie: Infrequente rotatie verhoogt de blootstelling aan downgrades van algoritmes, brute-force aanvallen of side-channel aanvallen.
• Bevoegdheidsoverschrijding: Door een gebrek aan rolscheiding kunnen beheerders sleutels beheren en gebruiken, waardoor misbruik van insiders mogelijk is.
• Ongedetecteerde inbreuk: Er is geen integriteitscontrole of herkomstversiebeheer dat verduidelijkt of sleutels mogelijk kwaadwillig zijn vervangen.
• Intrekking is mislukt: Reactie op incidenten kan geen cryptografische toegang tot gegevens bevatten na een vermoedelijke schending.
• Inconsistente hiërarchie: Ontbrekende KEK/DEK-lagen vermenigvuldigen de explosiestraal en verhogen de operationele uitvaltijd.

Onvoldoende sleutelbeheer verandert versleuteling in een momentopname in plaats van een voortdurende mitigatie tegen veranderende bedreigingen.

MITRE ATT&CK

• Wachtwoordtoegang (TA0006): referenties uit wachtwoordopslag (T1555) door het extraheren van onjuist opgeslagen of in de cache opgeslagen sleutelmateriaal, of geldige accounts (T1078) door gebruik te maken van brede RBAC-rollen voor sleutelbeheer om op onrechtmatige wijze toegang te krijgen tot sleutels of deze te wijzigen.
• Defense Evasion (TA0005): versleuteling verzwakken (T1600) door het gebruik van verouderde algoritmen of onvoldoende sleutelgroottes om de cryptografische sterkte te verminderen.
• Impact (TA0040): gegevensvernietiging (T1485) waarbij destructieve opschoonacties worden uitgevoerd of intrekkingsgebeurtenissen verkeerd worden verwerkt.
• Impact (TA0040): gegevensmanipulatie (T1565) waarbij sleutelversies worden vervangen of gewijzigd om versleutelingsstromen om te leiden of uit te schakelen.

DP-6.1: Beleid en infrastructuur voor sleutelbeheer instellen

Bouw een governancebasis voor cryptografisch sleutelbeheer door gecentraliseerde sleutelopslag tot stand te brengen, cryptografische standaarden te definiëren en de juiste beveiligingsniveaus te selecteren op basis van de gevoeligheid van de werkbelasting. Implementeer Azure Key Vault als de enige bron van waarheid voor sleutelbewerkingen terwijl uitgebreide auditlogboekregistratie wordt geïmplementeerd om alle belangrijke toegang en administratieve wijzigingen bij te houden voor naleving en forensische doeleinden.

Gecentraliseerde infrastructuur voor sleutelbeheer tot stand brengen:

• Gebruik Azure Key Vault als gecentraliseerde service voor cryptografisch sleutelbeheer om de volledige levenscyclus van de sleutel te beheren: genereren, distribueren, opslag, rotatie en intrekking.
• Definieer en handhaaf belangrijke beleidsregels die minimumnormen voor cryptografie specificeren:
  • Sleuteltype: RSA (aanbevolen: minimaal 4096-bit of 3072-bit) of EC (P-256, P-384, P-521-curves).
  • Belangrijke bewerkingen: Beperk toegestane bewerkingen (versleutelen, ontsleutelen, ondertekenen, verifiëren, verpakken, uitpakken) op basis van principes met minimale bevoegdheden.
  • Geldigheidsduur: Stel activerings- en vervaldatums in om tijdgebonden sleutelgebruik af te dwingen.

Kies de juiste sleutelkluislaag:

• Kies de juiste Key Vault-laag op basis van de beveiligings- en nalevingsvereisten van uw workload:
  • Met software beveiligde sleutels (Standard & Premium-SKU's): FIPS 140-2 Niveau 1 gevalideerd
  • Met HSM beveiligde sleutels (Premium SKU): FIPS 140-2 Level 2 gevalideerd (gedeelde HSM-back-end met meerdere tenants)
  • Beheerde HSM: FIPS 140-3 Level 3 gevalideerd (toegewezen HSM-pool met één tenant)
• Voor verbeterde beveiliging gebruikt u Azure Key Vault Managed HSM voor beveiliging met één tenant, met FIPS 140-3 niveau 3 gevalideerde HSM-beveiliging. Beheerde HSM ondersteunt cryptografisch domein voor back-up en herstel na noodgevallen.
• Configureer logboekregistratie en routelogboeken van Azure Key Vault naar Azure Monitor of Microsoft Sentinel om alle sleuteltoegang, rotatiegebeurtenissen en beheerbewerkingen bij te houden voor controle- en nalevingsdoeleinden.

DP-6.2: Belangrijke levenscyclusautomatisering implementeren

Automatiseer sleutelrotatie en stel sleutelhiërarchieën in om operationele lasten te verminderen, menselijke fouten te minimaliseren en snelle sleutelvervanging mogelijk te maken zonder serviceonderbreking. Implementeer KEK/DEK-patronen die efficiënte rotatie mogelijk maken door kleine sleutelbundels opnieuw te versleutelen in plaats van volledige gegevenssets, en integreer procedures voor herstel na noodgevallen om de beschikbaarheid van sleutels bij regionale storingen of catastrofale gebeurtenissen te behouden.

Geautomatiseerde sleutelrotatie implementeren:

• Beleid voor geautomatiseerde sleutelrotatie implementeren in Azure Key Vault:
  • Configureer de rotatiefrequentie op basis van nalevingsvereisten (algemene intervallen: 90 dagen, 180 dagen of jaarlijks).
  • Schakel rotatiemeldingen in om operationele teams te waarschuwen voordat de sleutel verloopt.
  • Configureer automatische rotatie om nieuwe sleutelversies te genereren zonder handmatige tussenkomst.

Sleutelhiërarchie en BYOK tot stand brengen:

• Een sleutelhiërarchie instellen die Sleutelversleutelingssleutels (KEK) en Gegevensversleutelingssleutels (DEK) scheidt:
  • Sla KEKs op in Azure Key Vault met beperkte toegangscontrole.
  • Genereer SERVICE LEVEL DEK's, versleuteld door KEKs, waardoor de straalstraal van sleutelrotatie wordt geminimaliseerd.
  • Het roteren van KEK vereist alleen het opnieuw versleutelen van DEK's (niet hele gegevenssets), waardoor efficiënte sleutelrotatie zonder downtime mogelijk is.
• Voor BYOK-scenario's (Bring Your Own Key) genereert u sleutels in on-premises FIPS 140-2 Level 2+ HSM's en gebruikt u het BYOK-overdrachtssleutelmechanisme om sleutels veilig te importeren in Azure Key Vault of beheerde HSM, met behoud van cryptografisch bewijs van de oorsprong en bewaring van sleutels.

Procedures voor herstel na noodgevallen implementeren:

• Geo-gerepliceerde Key Vaults maken in secundaire regio's.
• Maak een back-up van sleutels en herstel deze om de beschikbaarheid van sleutels in verschillende regio's te behouden.
• Documenteer en test procedures voor herstel na noodgevallen met gedefinieerde RTO-/RPO-doelen.

DP-6.3: Scheiding van taken afdwingen voor sleuteltoegang

Voorkom bedreigingen van insiders en misbruik van bevoegdheden door sleutelbeheerrollen te scheiden van cryptografische bewerkingsrollen, zodat er geen enkele identiteit sleutels kan maken en deze kan gebruiken voor gegevensversleuteling of -ontsleuteling. Implementeer continue bewaking om afwijkende sleuteltoegangspatronen te detecteren en uitgebreide sleutelinventarisaties te onderhouden die snelle impactbeoordeling mogelijk maken tijdens beveiligingsincidenten of nalevingscontroles.

Scheiding van taken afdwingen:

• Implementeer op rollen gebaseerd toegangsbeheer (RBAC) of toegangsbeleid om scheiding van taken af te dwingen:
  • Afzonderlijke rollen voor sleutelbeheerders (die sleutels kunnen maken/roteren/verwijderen, maar geen cryptografische bewerkingen kunnen uitvoeren).
  • Afzonderlijke rollen voor belangrijke gebruikers (die versleutelings-/ontsleutelingsbewerkingen kunnen uitvoeren, maar die geen sleutels kunnen beheren).
  • Voorbeeldrollen: Key Vault Crypto Officer (beheerders), Key Vault Crypto User (toepassingen/gebruikers).
• Controleer of er geen enkele identiteit zowel beheerders- als operationele sleuteltoegang heeft om misbruik van bevoegdheden te voorkomen.

Toegang tot sleutels bewaken en inventaris onderhouden:

• Integreer sleuteltoegangsbewaking met Microsoft Sentinel om afwijkingen te detecteren:
  • Ongebruikelijke sleuteltoegangspatronen (toegang vanuit onbekende IP-adressen of regio's).
  • Bulksleutelbewerkingen (overmatige bewerkingen binnen korte tijdsperioden).
  • Beheerwijzigingen buiten kantooruren (sleutelverwijdering of rotatie buiten kantooruren).
• Onderhoud een sleutelinventaris waarin de sleutelnaam, het doel, de rotatieplanning en afhankelijke services worden bijgehouden. Inventaris regelmatig controleren tijdens beveiligingsbeoordelingen.

Voorbeeld van implementatie

Een SaaS-provider voor gezondheidszorg centraliseerde cryptografisch sleutelbeheer met behulp van Azure Key Vault Premium SKU met HSM-beveiligde sleutels voor de versleuteling van persoonlijke gezondheidsinformatie op hun multi-tenant platform.

Uitdaging: Gefragmenteerd sleutelbeheer in ontwikkelteams leidde tot sleutelsprawl, inconsistente rotatieprocedures en problemen bij het bijhouden van sleutelgebruik tijdens beveiligingsincidenten. Met overbrede RBAC-machtigingen kunnen beheerders sleutels beheren en gebruiken, waardoor intern risico ontstaat. Zonder geautomatiseerde rotatie en scheiding van taken kreeg de organisatie te maken met uitgebreide belangrijke inbreukvensters en nalevingsfouten.

Oplossingsbenadering:

• Azure Key Vault Premium inrichten met met HSM beveiligde sleutels: Maak Azure Key Vault met Premium-laag ter ondersteuning van met HSM beveiligde sleutels, schakel beveiliging tegen opschonen in om permanente verwijdering tijdens de bewaarperiode te voorkomen, schakel voorlopig verwijderen in met 90 dagen retentie om herstel van per ongeluk verwijderde sleutels mogelijk te maken, RSA-3072 HSM-beveiligde versleutelingssleutels (KEK-PHI-Prod) met een sleuteltype met hardwareondersteuning te genereren.
• Beleid voor geautomatiseerde sleutelrotatie implementeren: Configureer rotatiebeleid met rotatiefrequentie van 180 dagen, schakel automatische rotatie in en stel een melding in om 30 dagen vóór de vervaldatum te waarschuwen, maak Azure Monitor-actiegroepen om het beveiligingsteam op de hoogte te stellen wanneer sleutels verlopen, rotatieactie configureren om automatisch nieuwe sleutelversies te genereren.
• RBAC-scheiding van taken configureren: Wijs de rol van Key Vault Crypto Officer toe aan leden van het beveiligingsteam (machtigingen: de levenscyclus van sleutels beheren, maar kunnen geen versleutelings-/ontsleutelingsbewerkingen uitvoeren), wijs de Key Vault Crypto User rol toe aan toepassingsbeheerde identiteiten (machtigingen: alleen versleutelings-/ontsleutelingsbewerkingen uitvoeren zonder sleutelbeheermachtigingen), controleer de scheiding van taken door ervoor te zorgen dat geen enkele identiteit zowel de Crypto Officer als de Crypto User rol heeft.
• Stel KEK/DEK-hiërarchie in voor snelle sleutelrotatie: Genereer op toepassingsniveau gegevensversleutelingssleutels (DEKs) binnen de toepassingscode (AES-256-sleutels) voor het versleutelen van patiëntgegevens. Sla de versleutelde DEKs samen met de versleutelde gegevens op. Gebruik de Key Vault KEK om DEKs te wikkelen/versleutelen via de WrapKey-bewerking, en haal de DEK op en decodeer deze met de UnwrapKey-bewerking bij het ontsleutelen van patiëntgegevens. Voordeel: het roteren van de KEK vereist alleen het opnieuw versleutelen van de DEKs in plaats van de gehele patiëntendatabase.
• Key Vault-logboeken integreren met Microsoft Sentinel: Schakel diagnostische instellingen in voor Key Vault en verzend logboeken naar de Log Analytics-werkruimte, maak Sentinel-analyseregels om ongebruikelijke sleuteltoegangspatronen, bulksleutelbewerkingen, beheerwijzigingen buiten kantooruren te detecteren.
• BYOK-overdracht (Bring Your Own Key) van on-premises HSM: Download de BYOK-overdrachtssleutel uit Key Vault, exporteer de sleutel van de on-premises HSM, verpakt met de openbare BYOK-overdrachtssleutel van Key Vault, onderhoud het cryptografische bewijs van de herkomst van de sleutel, importeer de verpakte sleutel naar Key Vault waar deze HSM beschermd is zonder blootstelling van platte tekst.

Resultaat: RSA-3072-sleutels draaien elke 180 dagen met geautomatiseerde meldingen. RBAC-scheiding voorkomt misbruik van bevoegdheden. KEK/DEK-hiërarchie maakt snelle rotatie mogelijk door alleen DEK's opnieuw te versleutelen. Met zachte verwijdering kunnen per ongeluk verwijderde sleutels worden hersteld. Microsoft Sentinel detecteert afwijkingen zoals onbekende IP-toegang of wijzigingen buiten kantooruren.

Kritieksniveau

Moet hebben.

Controletoewijzing

• CIS-besturingselementen v8.1: N.V.T.
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-28
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, PR. DS-1
• ISO 27001:2022: A.8.24, A.8.3
• SOC 2: CC6.1, CC6.2

DP-7: Een beveiligd certificaatbeheerproces gebruiken

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-7.

Beveiligingsprincipe

Beheer certificaatlevenscycli via gecentraliseerde processen die inventaris, geautomatiseerde vernieuwing, sterke cryptografische standaarden en tijdige intrekking omvatten. Zorg ervoor dat certificaten voor kritieke services worden bijgehouden, bewaakt en vernieuwd vóór de vervaldatum om serviceonderbrekingen te voorkomen en beveiligde versleutelde communicatie te onderhouden.

Risico om te beperken

Slecht beheerde certificaatlevenscycli veroorzaken servicestoringen, verzwakken versleutelde kanalen en imitatie toestaan. Zonder gecentraliseerde inventarisatie, beleidsafdwinging en automatische verlenging:

• Onverwachte vervaldatums: Verlopen certificaten leiden tot productiestoringen, uitval van API's, identiteitsfederatie of clientvertrouwenspaden.
• Zwakke cryptografiepersistentie: Verouderde sleutelgrootten/handtekeningalgoritmen (bijvoorbeeld SHA-1, RSA < 2048) blijven in gebruik na afschaffing.
• Wildcard en zelfondertekend misbruik: Breedschalige of onbeheerde zelfondertekende certificaten maken laterale imitatie en TLS-downgrade risico mogelijk.
• Niet-gedetecteerde inbreuk: Gestolen persoonlijke sleutels maken transparante man-in-the-middle of verkeersontsleuteling tot rotatie mogelijk.
• Schaduwcertificaten: Niet-goedgekeurde uitgifte buiten goedgekeurde certificaatautoriteiten versplintert het beheer en vergroot de blinde vlekken bij intrekking.
• Fouten bij handmatig verlengen: Inconsistente vervangingsvolgorde leidt tot vertrouwensketenmismatches en partiële omgevingsdrift.

Onvoldoende certificaatbeheer verslechtert versleutelde zekerheid en introduceert zowel betrouwbaarheid als beveiligingsinstabiliteit in kritieke services.

MITRE ATT&CK

• Defense Evasion (TA0005): om validatie te omzeilen, trust controls (T1553) ondermijnen door frauduleuze of kwaadaardige certificaten uit te geven of te introduceren.
• Resourceontwikkeling (TA0042): ontwikkel capaciteiten (T1587) door het vervaardigen van certificaten of tools voor toekomstige inbraakfasen.
• Defense Evasion (TA0005): versleuteling verzwakken (T1600) door het doorlopende gebruik van verouderde handtekeningalgoritmen, wat leidt tot een vermindering van de verificatiezekerheid.
• Referentietoegang (TA0006): niet-beveiligde referenties (T1552) die persoonlijke sleutels uit onveilige bestandsarchieven of procesgeheugen extraheren.
• Persistentie (TA0003):wijzig het verificatieproces (T1556) dat verificatiestromen op basis van certificaten herschrijft om langdurige toegang in te sluiten.

DP-7.1: Certificaatbeleid en CA-integratie instellen

Definieer standaarden voor certificaatbeheer en integreer vertrouwde certificeringsinstanties om een consistente cryptografische kwaliteit en geautomatiseerde uitgifte in uw infrastructuur te garanderen. Stel beleidsregels in die moderne sleutelgrootten, handtekeningalgoritmen en geldigheidsperioden afdwingen, terwijl riskante procedures zoals zelfondertekende certificaten en jokertekencertificaten worden geëlimineerd die aanvallen uitbreiden wanneer persoonlijke sleutels worden aangetast.

Infrastructuur voor certificaatbeheer instellen:

• Gebruik Azure Key Vault om de volledige levenscyclus van het certificaat centraal te beheren: maken, importeren, vernieuwen, rouleren, intrekken en veilig verwijderen.
• Certificaatbeleid definiëren in Azure Key Vault om beveiligingsstandaarden voor organisaties af te dwingen:
  • Sleuteltype en -grootte: RSA 2048-bits minimum (aanbevolen: 3072-bits of 4096-bits voor certificaten met een lange levensduur); EC P-256 of hoger voor elliptische curvecertificaten.
  • Handtekening-algoritme: SHA-256 of sterker (verbied SHA-1 en MD5).
  • Geldigheidsduur: Maximaal 397 dagen voor openbare TLS-certificaten (basisvereisten voor CA/browserforum); kortere duur (90 dagen) aanbevolen voor verminderde blootstelling.
  • Certificeringsinstantie: Gebruik alleen goedgekeurde, geïntegreerde CA's (DigiCert, GlobalSign) of de privé-CA van uw organisatie.

Certificeringsinstanties integreren:

• Gebruik partnercertificeringsinstanties die zijn geïntegreerd met Azure Key Vault voor openbare TLS/SSL-certificaten:
  • DigiCert: Door organisatie gevalideerde (OV) TLS/SSL-certificaten
  • GlobalSign: Door organisatie gevalideerde (OV) TLS/SSL-certificaten
• Voor privé-/interne services integreert u de interne certificeringsinstantie van uw organisatie (bijvoorbeeld Active Directory Certificate Services - ADCS) met Azure Key Vault voor geautomatiseerde certificaatuitgifte.
• Vermijd zelfondertekende certificaten en jokertekencertificaten in productieomgevingen:
  • Zelfondertekende certificaten: Geen validatie van derden, kan niet worden ingetrokken via openbare CRL/OCSP en worden geweigerd door moderne browsers/clients.
  • Wildcard-certificaten: Een brede scope verhoogt het risico als ze gecompromitteerd zijn; gebruik in plaats daarvan SAN-certificaten met expliciete volledig gekwalificeerde domeinnamen (FQDN's).

Notitie: Voor eenvoudige scenario's kunt u beheerde Azure App Service-certificaten (gratis, automatisch verlengde certificaten voor aangepaste domeinen) gebruiken.

DP-7.2: Automatische certificaatvernieuwing implementeren

Elimineren servicestoringen die worden veroorzaakt door verlopen certificaten door vernieuwingswerkstromen te automatiseren die ruim vóór de vervaldatum worden geactiveerd en certificaten naadloos bijwerken voor afhankelijke services zonder handmatige tussenkomst. Configureer Azure-services om automatisch vernieuwde certificaten op te halen uit Key Vault met behulp van beheerde identiteiten, waardoor operationele toil wordt verminderd en het risico op vergeten handmatige verlengingen tijdens vakantie- of personeelsovergangen wordt geëlimineerd.

Automatische verlenging configureren:

• Schakel automatische certificaatvernieuwing in Azure Key Vault in door levensduuracties te configureren voor het activeren van verlenging met een opgegeven percentage van de levensduur van het certificaat:
  • Aanbevolen trigger: 80-90% geldigheidsperiode (bijvoorbeeld ~ 318 dagen voor certificaat van 397 dagen).
  • Actie: Automatisch verlengen (Key Vault vraagt verlenging van CA aan zonder handmatige tussenkomst).
• Meldingscontactpersonen configureren om beheerders te waarschuwen over het aanstaande verlopen van certificaten voordat automatische verlengingen worden geactiveerd.

Automatische certificaatbinding inschakelen:

• Voor Azure-services die ondersteuning bieden voor automatische certificaatrotatie (Azure App Service, Azure Application Gateway, Azure Front Door), configureert u deze services om automatisch bijgewerkte certificaten op te halen uit Key Vault met behulp van beheerde identiteiten of service-principals met het juiste Key Vault-toegangsbeleid:
  • Azure-services binden automatisch nieuwe certificaatversies wanneer ze worden vernieuwd (doorgaans binnen 24 uur, er is geen service opnieuw opgestart).
• Voor toepassingen die key Vault-certificaten niet automatisch kunnen gebruiken, implementeert u handmatige werkstromen voor certificaatrotatie met operationele runbooks en bewakingswaarschuwingen om verloopgerelateerde storingen te voorkomen.
• Onderhoud een inventaris van alle certificaten in Azure Key Vault, met daarin de certificaatnaam, het doel, de vervaldatum, de afhankelijke services en de verlengingsstatus.

DP-7.3: Levenscyclus van certificaten bewaken en intrekking afhandelen

Behoud continue zichtbaarheid van de status van certificaten door middel van geautomatiseerde monitoring, inventarisvragen, en dashboards die certificaten tonen die bijna verlopen, verouderde cryptografie gebruiken of met ontbrekende of onvolledige governance. Stel snelle intrekkingsprocedures in voor gecompromitteerde certificaten en integreer met bedreigingsinformatie in de branche om certificaten die zijn uitgegeven door gecompromitteerde certificeringsinstanties proactief te blokkeren voordat ze man-in-the-middle-aanvallen mogelijk maken.

Bewaking en waarschuwingen configureren:

• Configureer Azure Monitor-waarschuwingen voor verlopen van certificaten:
  • Waarschuwingen maken op 30 dagen voor de vervaldatum (waarschuwingsmelding).
  • Maak waarschuwingen op 7 dagen vóór de vervaldatum (kritieke waarschuwing met escalatie naar beveiligingsteam).

Certificaatinventaris en dashboards onderhouden:

• Azure Resource Graph gebruiken om een query uit te voeren op certificaatinventaris:
  • Query's uitvoeren op certificaten die bijna verlopen (binnen 30/60/90 dagen).
  • Zelfondertekende certificaten opvragen.
  • Query's uitvoeren op certificaten met behulp van afgeschafte algoritmen (bijvoorbeeld SHA-1).
• Dashboards voor certificaatcontrole maken (bijvoorbeeld Power BI) met visualisaties:
  • Tijdlijn voor verlopen van certificaat per tijdsbucket.
  • Zelfondertekend certificaataantal per resourcegroep.
  • Certificaten die gebruikmaken van afgeschafte cryptografische standaarden.
• Controleer regelmatig dashboards voor certificaatcontrole tijdens vergaderingen voor beveiligingsbeoordeling (aanbevolen: elk kwartaal).

Intrekkingsprocedures vaststellen:

• Certificaatintrekkingsprocedures instellen voor gecompromitteerde of buiten gebruik gestelde certificaten:
  • Documentintrekkingsproces (certificaat uitschakelen in Key Vault, afhankelijke services waarschuwen).
  • Onderhoud runbooks voor incidentrespons voor scenario's met certificaatcompromittering.
  • Bewaak brancheadviezen voor gecompromitteerde basis- of tussenliggende CA-certificaten en blokkeer ze onmiddellijk.

Voorbeeld van implementatie

Een onderneming met meer dan 200 openbare webtoepassingen gecentraliseerd levenscyclusbeheer van certificaten met behulp van Azure Key Vault geïntegreerd met DigiCert als certificeringsinstantie.

Uitdaging: Handmatige processen voor certificaatvernieuwing hebben meerdere productiestoringen veroorzaakt wanneer certificaten onverwacht zijn verlopen. Wildcard-certificaten hebben een onnodig groot risico gecreëerd wanneer privésleutels werden gecompromitteerd. Gefragmenteerd certificaatbeheer in teams resulteerde in schaduwcertificaten, inconsistente cryptografische standaarden en vertraagde intrekking tijdens beveiligingsincidenten. Zonder geautomatiseerde vernieuwing en gecentraliseerde inventarisatie heeft de organisatie te maken gehad met nalevingsfouten en serviceonderbrekingen.

Oplossingsbenadering:

• Integratie van certificeringsinstanties configureren met Azure Key Vault: Voeg DigiCert (of een andere partnercertificeringsinstantie) toe aan Key Vault met API-referenties voor geautomatiseerde certificaataanvragen.
• Certificaatbeleid maken voor het afdwingen van beveiligingsstandaarden: Certificaatbeleid definiëren met certificaatnaam (www-contoso-com-2024), uitgever (DigiCert), onderwerp (CN=www.contoso.com), DNS-namen (SAN: www.contoso.com, api.contoso.com, portal.contoso.com : vermijd certificaten met jokertekens), sleuteltype (RSA 4096 bits), handtekeningalgoritme (SHA-256), geldigheidsperiode (maximaal 397 dagen per basislijn voor CA/Browser Forum), configureer de levensduuractie voor automatisch verlengen (trigger ingesteld op 80% van certificaatlevensduur ongeveer 318 dagen voor certificaatcertificaat van 397 dagen), actie: automatisch verlengen (Key Vault vraagt verlenging van DigiCert aan zonder handmatige tussenkomst).
• Automatische certificaatbinding configureren voor Azure-services: Voor azure App Service-importcertificaat uit Key Vault wijst u door de gebruiker toegewezen beheerde identiteit toe met de rol Key Vault Secrets User, schakelt u automatische certificaatupdates in (App Service verbindt nieuwe certificaatversie binnen 24 uur wanneer deze wordt vernieuwd, hoeft u niet opnieuw op te starten); voor Azure Application Gateway listener configureren voor het ophalen van certificaat uit Key Vault, wijst u door de gebruiker toegewezen beheerde identiteit toe met de rollen Key Vault Secrets User and Certificates User, Application Gateway haalt automatisch het bijgewerkte certificaat op wanneer Key Vault het verlengt.
• Waarschuwingen voor verlopen van certificaten configureren: Maak twee waarschuwingsregels in Azure Monitor: een verloopwaarschuwing van 30 dagen (meldingen verzenden naar het Slack-kanaal voor platformengineering), een kritieke waarschuwing van 7 dagen (open een Jira-ticket voor handmatige controle en verzend e-mail naar het beveiligingsteam).
• Verwijder jokertekencertificaten ten gunste van SAN-certificaten: Controleer bestaande jokertekencertificaten (*.contoso.com) in Key Vault, vervang door SAN-certificaten met expliciete DNS-namen (www.contoso.com, api.contoso.com), voordeel: als er inbreuk is gemaakt op de persoonlijke sleutel, worden alleen vermelde FQDN's beïnvloed (niet alle subdomeinen).
• Vervaldatum van certificaat bewaken: Gebruik Azure Resource Graph om een query uit te voeren op de certificaatinventaris en certificaten te identificeren die bijna verlopen (binnen 30 dagen), zelfondertekende certificaten of certificaten met behulp van afgeschaft SHA-1-handtekeningalgoritme. Controleer het dashboard elk kwartaal tijdens vergaderingen met beveiligingsbeoordeling.

Resultaat: Automatische triggers voor certificaatvernieuwing bij 80% levensduur. Azure App Service en Application Gateway halen bijgewerkte certificaten binnen 24 uur op via beheerde identiteiten (niet opnieuw opstarten vereist). Azure Monitor-waarschuwingen melden platformengineering vóór de vervaldatum. SAN-certificaten vervangen wildcard-certificaten, waardoor het impactgebied van een inbreuk wordt verminderd.

Kritieksniveau

Moet hebben.

Controletoewijzing

• CIS-besturingselementen v8.1: N.V.T.
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, ID.AM-3
• ISO 27001:2022: A.8.3
• SOC 2: CC6.1, CC6.2

DP-8: Beveiliging van sleutel- en certificaatopslagplaats garanderen

Azure Policy: Zie ingebouwde Azure-beleidsdefinities: DP-8.

Beveiligingsprincipe

Beveilig key vault-services via diepgaande beveiligingsmaatregelen: toegang met minimale bevoegdheden, netwerkisolatie, uitgebreide logboekregistratie en bewaking, mogelijkheden voor back-up en herstel, en beveiliging met HSM-ondersteuning, indien nodig. Sleutelkluizen zijn essentiële infrastructuur die cryptografische sleutels en certificaten beveiligt die worden gebruikt voor versleuteling en verificatie.

Risico om te beperken

Inbreuk op de sleutel- en certificaatopslagplaats maakt upstream-versleuteling, -ondertekening en identiteitsgaranties ongeldig. Zonder versterkte kluis toegang, bewakingsmogelijkheden en isolatie:

• Sleutelexfiltratie: Gestolen KEKs/HSM-materiaal maakt bulkontsleuteling van opgeslagen gegevens en verkeersonderschepping mogelijk.
• Verborgen beheertoegang: Onbepaalde RBAC of onjuiste configuratie van beleid maakt illegale sleutelexport, verwijderen of versie terugzetten mogelijk.
• Stille manipulatie: Schadelijke sleutelvervanging maakt transparante man-in-the-middle of vervalste code/handtekeningen mogelijk.
• Netwerkblootstelling: Misbruik van openbare eindpunten (inloggegevens stuffing, API-verkenning) vergroot het aanvaloppervlak voor brute-force-aanvallen of token-replay.
• Onbedoelde destructieve acties: Ontbrekende beveiliging tegen voorlopig verwijderen/opschonen leidt tot onherstelbaar cryptografisch gegevensverlies.
• Onvoldoende audit-herkomst: Het ontbreken van onveranderlijke logboeken beïnvloedt de incidentrespons en voldoet niet aan de vereisten voor bewijsvoering van de regelgeving.
• Niet-gesegmenteerde tenancy: Met vermengde toepassingssleutels wordt de laterale bewegingsbaan verbreed na een identiteitscompromis.

Zwakheden in het repository verspreiden zich snel naar systemische problemen met vertrouwelijkheid, integriteit en beschikbaarheid binnen afhankelijke workloads.

MITRE ATT&CK

• Referentietoegang (TA0006):niet-beveiligde referenties/referentiearchieven (T1552/T1555) verkregen via onjuist geconfigureerde kluisrol of netwerkbeleid.
• Defense Evasion (TA0005): man-in-the-middle-aanval (T1557) die verkeer dat naar de kluis wordt gestuurd vastlegt voor sleutel-/certificaatonderschepping, of versleuteling verzwakken (T1600) door sterke sleutels te vervangen door door aanvallers beheerd materiaal.
• Escalatie van bevoegdheden (TA0004): geldige accounts (T1078) die misbruik maken van te ruime rollen van kasbeheerder om gegevens op te sommen en te wijzigen.
• Impact (TA0040): gegevensvernietiging / remt herstel (T1485 / T1490) die destructieve opschoningsreeksen uitvoeren die herstel voorkomen.

DP-8.1: Toegangsbeheer voor Key Vault implementeren

Beveilig de cryptografische basis van uw infrastructuur door strikte toegangsbeheer op basis van identiteit af te dwingen die onbevoegde toegang tot sleutels voorkomen, beheerbevoegdheden beperken tot uitgevulde tijdvensters en referentieopslag via beheerde identiteiten elimineren. Implementeer scheiding van taken tussen belangrijke beheerders en belangrijke gebruikers om te voorkomen dat één gecompromitteerde identiteit zowel cryptografisch materiaal beheert als exploiteert.

RBAC en scheiding van taken implementeren:

• Implementeer Azure RBAC voor Key Vault om toegangsbeheer met minimale bevoegdheden af te dwingen:
  • Voor Managed HSM van Azure Key Vault: gebruik lokale RBAC op het niveau van de afzonderlijke sleutel, geheime en certificaat met ingebouwde rollen (Managed HSM Crypto Officer, Crypto User, Crypto Auditor).
  • Voor Azure Key Vault Standard/Premium: maak toegewezen kluizen per toepassing of omgeving om logische scheiding af te dwingen en RBAC-rollen (Key Vault-beheerder, Geheimen Officer, Certificate Officer) met toepassingsspecifiek bereik toe te wijzen.
• Scheiding van taken afdwingen: Afzonderlijke rollen voor sleutelbeheer (die sleutels kunnen maken/draaien) van cryptografische bewerkingen (die sleutels kunnen gebruiken voor versleutelen/ontsleutelen).

Beheerde identiteiten en JIT-toegang gebruiken:

• Gebruik beheerde identiteiten voor Azure-resources (App Services, VM's, Azure Functions, enzovoort) om toegang te krijgen tot Key Vault in plaats van referenties op te slaan in toepassingscode of configuratiebestanden. Beheerde identiteiten elimineren de complexiteit van referentieopslag en rotatie.
• Implementeer Azure AD Privileged Identity Management (PIM) voor Just-In-Time-beheerderstoegang tot Key Vault:
  • Configureer in aanmerking komende toewijzingen voor de rol Key Vault-beheerder (niet permanente toewijzingen).
  • Rechtvaardiging, MFA en goedkeuring vereisen voor activering.
  • Stel de maximale activeringsduur in (bijvoorbeeld 8 uur).
  • Voer regelmatig toegangsbeoordelingen uit om onnodige permanente bevoegdheden in te trekken.

DP-8.2: Netwerkbeveiliging van Key Vault versterken

Elimineer internetgerichte aanvalsoppervlakten door alle Key Vault-toegang te routeren via privé-eindpunten binnen uw virtuele netwerken, waardoor credential stuffing, brute-force pogingen en verkenning door externe bedreigingsactoren worden voorkomen. Wanneer openbare toegang onvermijdelijk is voor CI/CD-scenario's, implementeert u strikte IP-acceptatielijsten en firewallregels om het kleinste mogelijke blootstellingsvenster te maken.

Private Link implementeren en firewall configureren:

• Beveilig netwerktoegang tot Azure Key Vault met behulp van Azure Private Link om privéconnectiviteit van VNets tot stand te brengen zonder Key Vault beschikbaar te maken voor het openbare internet.
• Configureer de Key Vault-firewall om de toegang tot specifieke IP-bereiken of VNets te beperken voor scenario's waarbij Private Link niet haalbaar is:
  • Schakel waar mogelijk openbare toegang uit (Key Vault is alleen toegankelijk via een privé-eindpunt).
  • Als openbare toegang is vereist (bijvoorbeeld voor CI/CD-pijplijnen), staat u alleen toegang toe vanuit geselecteerde netwerken met beperkte IP-acceptatielijsten.
• Privé-DNS-zones (bijvoorbeeld privatelink.vaultcore.azure.net) maken en koppelen aan VNets om de juiste DNS-resolutie voor privé-eindpunten te garanderen.

DP-8.3: Key Vault-beveiliging en -bewaking inschakelen

Implementeer diepgaande verdedigingsbeveiligingen die onherstelbaar cryptografisch gegevensverlies voorkomen door middel van voorlopig verwijderen en opschonen, terwijl met HSM ondersteunde sleutels worden gebruikt voor productieworkloads waarvoor fips-gevalideerde beveiliging is vereist. Implementeer uitgebreide bewaking met Microsoft Defender voor Key Vault en Microsoft Sentinel om afwijkende toegangspatronen, ongebruikelijke sleutelbewerkingen en administratieve afwijkingen te detecteren die duiden op inbreuk, bedreigingen van insiders of verkenningsactiviteiten die gericht zijn op uw cryptografische infrastructuur.

Zachte verwijdering en bescherming tegen volledig verwijderen inschakelen:

• Schakel voorlopig verwijderen en opschonen van alle Azure Key Vaults in om onbedoelde of schadelijke verwijdering van sleutels, geheimen en certificaten te voorkomen:
  • Voorlopig verwijderen staat herstel toe binnen een bewaarperiode (standaard: 90 dagen).
  • Verwijderingsbeveiliging voorkomt permanente verwijdering tijdens de bewaarperiode.
  • Dwing deze instellingen af met Azure Policy met behulp van ingebouwde beleidsregels: 'Sleutelkluizen moeten soft delete ingeschakeld hebben' en 'Sleutelkluizen moeten purge protection ingeschakeld hebben' (deployIfNotExists-effect).
• Implementeer sleutellevenscyclusbeleid om cryptografische verwijdering van gegevens te voorkomen:
  • Controleer voordat u versleutelde gegevens opschoont of versleutelingssleutels worden bewaard voor de vereiste gegevensretentieperiode.
  • Gebruik bij het buiten gebruik stellen van sleutels de bewerking uitschakelen in plaats van te verwijderen om onbedoeld gegevensverlies te voorkomen terwijl sleutelmetagegevens worden onderhouden voor controledoeleinden.
  • Back-upprocedures voor Key Vault maken en testen voor scenario's voor herstel na noodgevallen.

Gebruik sleutels met HSM-ondersteuning en BYOK:

• Gebruik met HSM-ondersteunde sleutels voor productieworkloads waarvoor sterke cryptografische beveiliging is vereist:
  • Azure Key Vault Premium: RSA-HSM en EC-HSM sleutels die worden beveiligd door FIPS 140-2 Level 2 gevalideerde HSM's (gedeeld met meerdere tenants).
  • Beheerde HSM van Azure Key Vault: RSA-HSM en EC-HSM sleutels die worden beveiligd door met FIPS 140-3 niveau 3 gevalideerde HSM's (toegewezen pools met één tenant).
• Voor BYOK-scenario's (Bring Your Own Key) genereert u sleutels in on-premises FIPS 140-2 Level 2+ HSM's en gebruikt u het BYOK-overdrachtssleutelmechanisme om sleutels veilig te importeren in Azure Key Vault, met behoud van cryptografisch bewijs van de oorsprong en bewaring van sleutels.

Bewaking en detectie van bedreigingen inschakelen:

• Schakel diagnostische logboekregistratie in voor Azure Key Vault en routelogboeken naar Azure Monitor, Log Analytics of Microsoft Sentinel om alle bewerkingen van het beheervlak en gegevensvlak vast te leggen. Controleer op verdachte activiteiten, waaronder ongebruikelijke sleuteltoegangspatronen, mislukte verificatiepogingen en beheerwijzigingen.
• Schakel Microsoft Defender voor Key Vault in om afwijkende toegangspatronen, ongebruikelijke sleutelbewerkingen en mogelijke bedreigingen te detecteren, zoals misbruik van referenties, verdachte sleutel ophalen of administratieve afwijkingen. Integreer Defender voor Key Vault-waarschuwingen met werkstromen voor incidentrespons.
• Integreer Key Vault-logboeken met Microsoft Sentinel om analyseregels te maken voor het detecteren van afwijkingen, zoals ongebruikelijke regionale toegang, mogelijke beveiligingspogingen of verdachte beheerbewerkingen. Implementeer geautomatiseerde antwoordplaybooks om gecompromitteerde identiteiten te isoleren en beveiligingsteams op de hoogte te stellen.

Notitie: Alle Key Vault-SKU's voorkomen standaard sleutelexport; cryptografische bewerkingen worden uitgevoerd binnen de beveiligde HSM-grens. Exporteer nooit sleutels in platte tekst buiten Azure Key Vault of sla deze op.

Voorbeeld van implementatie

Een multinational heeft diepgaande beveiliging geïmplementeerd voor hun Azure Key Vault-infrastructuur voor het beveiligen van versleutelingssleutels, API-geheimen en TLS-certificaten voor meer dan 500 microservices.

Uitdaging: Te brede RBAC-machtigingen bieden ontwikkelaars directe toegang tot productiesleutelkluizen, wat leidt tot interne risico's en nalevingsschendingen. Blootstelling aan het openbare internet heeft inloggegevens-stuffing-aanvallen en verkenningspogingen ingeschakeld. Zonder uitgebreide bewaking en geautomatiseerde reacties zijn verdachte toegangspatronen voor sleutels niet gedetecteerd. Het gebrek aan zachte verwijdering en verwijderbeveiliging leidde tot een risico op permanent cryptografisch gegevensverlies tijdens incidenten.

Oplossingsbenadering:

• Toegewezen sleutelkluizen implementeren voor logische segmentatie: Maak Key Vault per omgeving en bedrijfseenheid met naamconventie kv-{businessunit}-{environment}-{region} (bijvoorbeeld kv-finance-prod-eastus2, kv-finance-dev-eastus2), implementeren in afzonderlijke resourcegroepen per omgeving om isolatie af te dwingen (aangetaste dev-service-principal heeft geen toegang tot productiesleutels).
• RBAC configureren voor toegang met minimale bevoegdheden: Voor niet-productie key vaults (dev/staging) wijst u Key Vault Secrets User (alleen-lezen) toe aan beveiligingsgroepen voor ontwikkelaars. Ontwikkelaars kunnen geheimen lezen in dev/staging, maar hebben geen toegang tot productiesleutelkluizen; Voor productiesleutelkluizen wordt key vault-geheimengebruiker toegewezen aan CI/CD-service-principals (door Azure DevOps-pijplijn beheerde identiteiten), beperkt u het bereik tot specifieke benoemde geheimen, geen interactieve ontwikkelaarstoegang tot productiesleutels.
• Netwerkbeveiliging beveiligen met Azure Private Link: Implementeer privé-eindpunten voor Key Vault (selecteer VNet en subnet, maak privé-DNS-zone privatelink.vaultcore.azure.net en koppel aan VNet), configureer Key Vault-firewall (schakel openbare toegang uit met Key Vault alleen toegankelijk via een privé-eindpunt, als openbare toegang vereist is voor CI/CD toegang vanaf geselecteerde netwerken alleen met goedgekeurde Azure VNet-subnetten en IP-adresbereiken van CI/CD-agent).
• Microsoft Defender voor Key Vault inschakelen: Schakel Microsoft Defender voor Key Vault in op abonnementsniveau, Defender bewaakt afwijkingen, waaronder ongebruikelijke geografische toegang, verdachte inventarisatie (snelle lijstbewerkingen die reconnaissance aangeven), abnormale administratieve bewerkingen (bulkgeheimverwijderingen).
• Integreren met Microsoft Sentinel voor geautomatiseerd antwoord: Voeg Microsoft Defender voor Cloud-gegevensconnector toe aan Sentinel, maak Sentinel Analytics-regels voor ongebruikelijke regionale toegang, mogelijke beveiligingsaanvallen, verdachte beheerbewerkingen, configureer geautomatiseerde antwoordplaybooks om verdachte identiteiten uit te schakelen en beveiligingsteams op de hoogte te stellen.
• Diagnostische logboeken streamen naar Log Analytics: Schakel diagnostische logboekregistratie in voor Key Vault met AuditEvent (alle bewerkingen voor sleutel/geheim/certificaat), AllMetrics (gebruiksfrequentie, latentie), verzend naar Log Analytics-werkruimte met 2 jaar retentie, maak aangepaste KQL-query's voor anomaliedetectie, inclusief mogelijke beveiligingsdetectie (10+ niet-geautoriseerde pogingen in 5 minuten), uitgeschakelde bewerkingen voor voorlopig verwijderen (sabotageindicator).
• Just-In-Time-beheerderstoegang implementeren met Azure AD PIM: Configureer in aanmerking komende toewijzingen voor de rol Key Vault-beheerder (voeg beveiligingsteamleden toe als In aanmerking komende niet-permanente toewijzing, vereist reden en MFA voor activering, stel de maximale activeringsduur 8 uur in, vereist goedkeuring van senior beveiligingsarchitect), voer driemaandelijkse toegangsbeoordelingen uit voor alle roltoewijzingen van Key Vault-beheerders; onnodige toegang intrekken.

Resultaat: Toegewezen sleutelkluizen per omgeving dwingen segmentatie af. RBAC beperkt ontwikkelaars tot alleen-lezen toegang tot niet-productieomgeving. Private Link elimineert blootstelling aan openbaar internet. Microsoft Defender detecteert afwijkingen. Sentinel-playbooks schakelen automatisch verdachte identiteiten uit. PIM maakt Just-In-Time-beheerderstoegang mogelijk, waardoor de statusbevoegdheden aanzienlijk worden verminderd.

Kritieksniveau

Moet hebben.

Controletoewijzing

• CIS-besturingselementen v8.1: N.V.T.
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, PR. DS-1
• ISO 27001:2022: A.8.3, A.8.24
• SOC 2: CC6.1, CC6.2