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:

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

Gerelateerde besturingselementen:

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

Gerelateerde besturingselementen:

DP-1: Gevoelige gegevens detecteren, classificeren en labelen

Azure Policy: Zie Azure ingebouwde 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, geclassificatied en gelabeld in uw hele gegevensomgeving. Breid de beveiliging uit buiten versleuteling op infrastructuurniveau door Microsoft Purview Informatiebeveiliging te implementeren om permanente versleuteling en gebruiksrechten toe te passen die gegevens volgen, ongeacht waar ze worden verzonden. 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 gegevensbronnen automatisch 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 Informatiebeveiliging 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 onderliggende beveiligingstechnologie waarmee documenten en e-mailberichten worden versleuteld met gebruiksbeleid (alleen-weergeven, no-copy, no-print) die behouden blijven, ongeacht waar gegevens worden opgeslagen of gedeeld.

Database-classificatie en -integratie:

  • Voor Azure SQL-databases schakelt u SQL Gegevensontdekking en Classificatie in om kolommen te identificeren, classificeren en labelen die gevoelige gegevens bevatten, zoals creditcardnummers, BSN-nummers of gezondheidsgegevens.
  • Integreer metagegevens van classificatie met downstreambesturingselementen: DLP-beleid (Preventie van gegevensverlies) 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.

Challenge: 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:

  • Implementeer de Microsoft Purview Data Map voor gegevensdetectie: Maak een Purview-account en registreer gegevensbronnen zoals Azure Storage-accounts, SQL-databases en Synapse Analytics-werkruimten. Configureer de Data Map om bronnen te scannen met behulp van beheerde identiteitsverificatie, verleen de leesmachtigingen aan de scanidentiteit (rol "db_datareader") om catalogusschema's te catalogiseren 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.
  • Implementeer Microsoft Purview Informatiebeveiliging voor documentniveau-encryptie: Maak gevoeligheidslabels in de Purview-complianceportal met beveiligingsinstellingen (Openbaar: geen encryptie, alleen visuele markeringen; Intern: watermerk, geen beperkingen voor doorsturen; Vertrouwelijk: versleutelen met Azure RMS, alleen weergave/bewerking toestaan voor werknemers, doorsturen/afdrukken blokkeren; Zeer vertrouwelijk - Regulated: versleutelen met Azure RMS, alleen-weergave toegang, geen kopiëren/afdrukken/doorsturen, verlooptijd van 90 dagen, herroepbare toegang), publiceer gevoeligheidslabels voor gebruikers via labelbeleid (scope: Finance, Juridische, Executive-afdelingen), configureer beleid voor automatisch labelen om automatisch labels toe te passen (≥10 BSN’s → "Zeer vertrouwelijk - Regulated", ≥5 creditcardnummers → "Zeer vertrouwelijk - Regulated"), Azure RMS-beveiliging inschakelen voor gelabelde documenten die zijn opgeslagen in SharePoint, OneDrive en Azure Storage-accounts, configureer client-side labeling 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. Information Protection paste automatische labeling toe en versleutelde 8500 documenten binnen 72 uur. 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 Azure ingebouwde 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 in voor Storage 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 in voor SQL om verdachte databaseactiviteiten te detecteren, waaronder SQL-injectiepogingen, afwijkende querypatronen, ongebruikelijke gegevensexportbewerkingen en toegang vanaf onbekende locaties.
  • Schakel Microsoft Defender in voor Azure Cosmos DB om afwijkende databasetoegangspatronen, mogelijke gegevensexfiltratie en verdachte operationele activiteiten te detecteren.
  • Voor opensource-databases (PostgreSQL, MySQL) 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 Microsoft Purview-preventie van gegevensverlies (DLP)-beleid 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 Beheer van insider-risico's 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 potentiële diefstal van gegevens of beleidsschendingen te identificeren.

Bewaking en reactie configureren:

  • Configureer diagnostische logboeken voor gegevensservices en route 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 patronen voor gegevenstoegang, 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.

Opmerking: Voor hostgebaseerde DLP-vereisten implementeer je Microsoft Purview Endpoint DLP-mogelijkheden ofwel oplossingen van derden uit de Azure Marketplace om gegevensbeschermingscontroles op eindpuntniveau af te dwingen.

Voorbeeld van implementatie

Een gezondheidszorgprovider heeft Microsoft Defender ingeschakeld voor Storage en Defender voor SQL 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:

  • Enable Microsoft Defender voor Storage: Schakel Defender in voor Opslag op abonnementsniveau 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, limieten voor scannen per transactie of maandlimieten in te stellen op beheerkosten, pas beveiliging toe op resourcegroepen met productieopslagaccounts die als host fungeren voor medische imaging en EHR-exports.
  • Enable Microsoft Defender voor SQL: Schakel Defender in voor SQL 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 op waarschuwingsbeveiligingsteam van geïdentificeerde beveiligingsproblemen, Advanced Threat Protection in staat stellen om SQL-injectiepogingen, ongebruikelijke querypatronen, afwijkende toegang vanuit onbekende regio's en mogelijke gegevensexfiltratie te detecteren.
  • Integreren met Microsoft Sentinel: Verbind Microsoft Defender voor Cloud met Microsoft Sentinel met behulp van een gegevensconnector, configureer diagnostische instellingen (schakel diagnostische logboeken in voor opslagactiviteiten en SQL-auditlogboeken, leid door naar Log Analytics-werkruimte), creëer Sentinel Analytics-regels om afwijkingen te detecteren (waarschuwingen voor bulkdownloads van meer dan >10 GB binnen 1 uur, database toegang buiten kantooruren, verdachte querypatronen), configureer geautomatiseerde responsplaybooks om gecompromitteerde identiteiten te isoleren, opslagtoegang in te trekken en beveiligingsteams op de hoogte te stellen.
  • Implementeer Microsoft Purview Beheer van insider-risico's voor detectie van gedragsbedreigingen: Schakel Insider Risk Management in en configureer beleidssjablonen (detectie van gegevensdiefstal door vertrekkende gebruikers die ongebruikelijke bestandsdownloads maken 30-90 dagen voordat ze vertrekken, algemene gegevenslekken monitoren via het kopiëren naar USB/cloudopslag, gegevenslekken door prioriteitsgebruikers met verbeterde monitoring voor rollen met hoge bevoegdheden), configureer risico-indicatoren en drempelwaarden (cumulatieve volumewaarschuwingen voor het downloaden van bestanden, pieken buiten kantooruren, detectie van reeksen waarbij meerdere risicovolle signalen worden gecombineerd), integreer gegevensbronnen (Azure activiteitlogboeken, Microsoft 365 auditlogboeken, Defender voor Cloud Apps, HR-systemen, DLP-gebeurtenissen voor eindpunten), configureer het werkstroombewerking voor het routeren van gemiddelde/hoge ernst-waarschuwingen naar een toegewezen onderzoekswachtrij.

Outcome: Defender voor Storage heeft binnen 48 uur afwijkende bulkdownloadactiviteit gedetecteerd van een gecompromitteerde service-principal. 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 Azure ingebouwde 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 secure transfer (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.
  • Schakel voor webtoepassingen die worden gehost op Azure App Service de instelling 'Alleen HTTPS' in en configureer minimum TLS-versie naar 1.2 of 1.3 om downgradeaanvallen te voorkomen en moderne cryptografische standaarden te garanderen.
  • Configureer Azure Application Gateway om de minimumversie van TLS 1.2/1.3 af te dwingen voor zowel front-end-listeners als back-endverbindingsversleuteling (end-to-end TLS).
  • Voor Azure SQL Database en andere PaaS-gegevensservices controleert u of de instelling 'Beveiligde verbindingen vereist' of gelijkwaardige instellingen versleutelde verbindingen afdwingen en niet-versleutelde verbindingen worden geweigerd.
  • 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.

Note: Azure versleutelt automatisch al het verkeer tussen Azure datacenters met MACsec (laag 2) en TLS (laag 7). De meeste Azure PaaS-services schakelen TLS 1.2+ standaard in, maar controleer de minimale TLS-versie-instellingen voor services met door de klant configureerbare beleidsregels (Storage, 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 Azure virtuele machines uitsluitend beveiligde protocollen:
    • Linux-VM's: SSH (poort 22) gebruiken met verificatie op basis van sleutels; wachtwoordverificatie uitschakelen.
    • Windows VM's: RDP via TLS (poort 3389) gebruiken waarvoor NLA (Network Level Authentication) is ingeschakeld.
    • Bevoorrechte toegang: Leid administratieve verbindingen via Azure Bastion om blootstelling aan openbare IP-adressen te voorkomen en om browser-gebaseerde of native client-toegang via TLS te bieden.

Protocollen voor bestandsoverdracht beveiligen:

  • Voor bestandsoverdrachtsbewerkingen gebruikt u beveiligde protocollen en schakelt u verouderde alternatieven uit:
  • Gebruik Azure Policy om beleid voor veilige overdracht in uw omgeving af te dwingen en naleving voor TLS-versievereisten te controleren.

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:

  • Configureer Azure App Service voor TLS 1.3: Stel de minimale TLS-versie in op 1.3 voor klantgerichte webapplicaties en API's, schakel de HTTPS-alleen-modus in om automatisch al het HTTP-verkeer naar HTTPS om te leiden, controleer dat beheerde certificaten of aangepaste certificaten sterke ciphersuites gebruiken.
  • Configure Azure Application Gateway voor end-to-end TLS: Configureer de front-end HTTPS luisteraar met de SSL-policy AppGwSslPolicy20220101 (TLS 1.3 minimum met CustomV2 policy), upload het TLS-certificaat of integreer met Key Vault voor certificaatbeheer. Configureer de back-endinstellingen voor HTTPS-verbindingen (stel het back-endprotocol in op HTTPS op poort 443; schakel 'Gebruik maken van een bekende CA-certificaat' in als de back-end App Services Azure-beheerde certificaten gebruiken, stel de minimale TLS-versie in op 1.2 voor back-endverbindingen). Maak routeringsregels die HTTPS-luisteraars verbinden met back-endpools met TLS-ingeschakelde instellingen.
  • Veilig overzetten voor Azure Storage afdwingen: Schakel de instelling "Veilig overzetten verplicht" in om HTTPS-only af te dwingen voor blob-, bestand-, wachtrij- en tabelbewerkingen. Stel de minimale TLS-versie in op 1.2 voor alle opslagverbindingen en controleer of alle SAS-tokens en gedeelde sleutels alleen werken via HTTPS-verbindingen.
  • Configure Azure Bastion voor veilige externe toegang: Implementeer Azure Bastion in hub-VNet om browsergebaseerde RDP-/SSH-toegang via TLS 1.2 te bieden, openbare IP-adressen van VM's te verwijderen en alle beheertoegang exclusief via Bastion te routeren.

Outcome: 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 Azure ingebouwde 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 zijn opgeslagen in Azure in rust zijn versleuteld om te beschermen tegen onbevoegde toegang tegen inbreuk op de infrastructuur, gestolen media of niet-geautoriseerde momentopnamen. Hoewel de meeste Azure services standaard versleuteling inschakelen, controleert u de dekking voor virtuele machines, opslagaccounts en databases en schakelt u extra versleutelingslagen in (versleuteling op host, infrastructuurversleuteling, vertrouwelijke computing en versleuteling op kolomniveau) voor zeer gevoelige workloads om te voldoen aan vereisten voor regelgeving en gegevenssoevereine.

Versleuteling inschakelen voor VM's en opslag:

  • Schakel cryption-at-host in voor Azure Virtuele Machines om tijdelijke schijven, besturingssysteemschijfcache, gegevensschijfcache en kortstondige 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 infrastructure-versleuteling (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 Vertrouwelijke 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 op clientniveau te bieden voor zeer 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:

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

Note: Veel Azure-services (Azure Storage, Azure SQL Database, Azure Cosmos DB) zijn standaard ingeschakeld voor versleuteling van data-at-rest 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 gestandaardiseerd versleuteling-at-rest in hun Azure omgeving om ERP-gegevens, toeleveringsketentoepassingen 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:

  • Enable encryption-at-host voor Azure Virtuele Machines: Register EncryptionAtHost-functie op abonnementsniveau, versleuteling op host voor VM's inschakelen met ondersteunde VM-grootten (DSv3, Easv4, Dadsv5-serie), versleuteling omvat tijdelijke schijven, besturingssysteemschijfcache, gegevensschijfcache en tijdelijke besturingssysteemschijven.
  • Versleuteling van infrastructuur (dubbele versleuteling) voor Azure Storage: Controleer of Azure Storage Service Encryption (SSE) is ingeschakeld (standaard AES-256-versleuteling), voor gevoelige opslagaccounts is infrastructuurversleuteling ingeschakeld (kan niet worden ingeschakeld na het maken), resultaat: twee lagen AES-256-versleuteling met verschillende sleutels.
  • Deploy Azure Confidential VMs voor sterk gereglementeerde workloads: Selecteer de juiste reeks vertrouwelijke VM's (DCasv5/DCadsv5-serie voor AMD SEV-SNP of ECasv5/ECadsv5-serie voor Intel TDX), schakel vertrouwelijke schijfversleuteling in met een platformbeheerde sleutel (waarbij schijfversleutelingssleutels aan de virtuele TPM van de VM worden gekoppeld), schakel Beveiligd opstarten en vTPM in voor attestation, implementeren voor workloads die geëxporteerde technische gegevens of sterk gereglementeerde PII verwerken, waarbij gegevens tijdens de verwerking versleuteld moeten blijven.
  • Implement Always Encrypted voor gevoelige databasekolommen: Identificeer zeer gevoelige kolommen zoals SSN, CreditCardNumber, en MedicalRecordNumber in Azure SQL Database die versleuteling op kolomniveau vereisen. Genereer kolomversleutelingssleutels (CEK) en kolomhoofdsleutels (CMK), waarbij de CMK wordt opgeslagen in Azure Key Vault en de CEK de gegevenskolommen versleutelt terwijl de CMK de CEK versleutelt. Schakel Always Encrypted in met beveiligde enclaves (Intel SGX) om completere query's op versleutelde gegevens te kunnen uitvoeren. Versleutel gevoelige kolommen met behulp van deterministische versleuteling (voor zoekacties op gelijkheid) of gerandomiseerde versleuteling (voor maximale beveiliging). Configureer toepassingsverbindingsreeksen met Kolomversleutelingsinstelling=Ingeschakeld voor transparante versleuteling/ontsleuteling.
  • Inventory-versleutelingsconfiguraties met Azure Resource Graph: Query-versleutelingsstatus voor VM's zonder versleuteling op host- en opslagaccounts zonder infrastructuurversleuteling, exporteer resultaten naar CSV en wijs hersteltaken toe 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 Azure ingebouwde 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 kunnen 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 servicebeschikbaarheid 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.
  • Richt Azure Key Vault (Standard of Premium) of Azure Key Vault Managed HSM in om klantbeheerde 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 binnen Azure Key Vault met behulp van key generation of importeer sleutels uit on-premises HSM's met behulp van Bring Your Own Key (BYOK) voor maximale draagbaarheid en beheer.

CMK configureren en sleutelhiërarchie tot stand brengen:

  • Implementeer voor extreme controlevereisten Double Key Encryption (DKE) waarbij gevoelige documenten twee sleutels nodig hebben voor ontsleuteling: één die wordt 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 ze worden 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 URI van de Key Vault-sleutel. Schakel beleid voor automatische sleutelrotatie in om handmatige operationele lasten te verminderen.
  • Stel een sleutelversleutelingssleutel (KEK) en DEK-hiërarchie (Data Encryption 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 gereguleerde 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:

  • Provision Azure Key Vault Managed HSM: Maak Managed HSM aan (FIPS 140-3 Niveau 3 gevalideerd) met minimaal 3 HSM-partities voor hoge beschikbaarheid, activeer beheerde HSM door het beheerde beveiligingsdomein te exporteren met quorumsleutels (gesplitst in sleutelfragmenten die zijn opgeslagen in geografisch gedistribueerde offlinekluizen), encryptiesleutels (RSA-4096 met de naam KEK-Prod-2024) te genereren met sleutelbewerkingen: Omsluiten, Desleutelen, Versleutelen, Ontsleutelen.
  • Configureer door de klant beheerde sleutels voor Azure-services: Configureer Azure Storage om het opslagaccount het CMK-versleutelingstype te laten gebruiken, selecteer Key Vault Managed HSM als sleutelbron, en schakel door de gebruiker toegewezen beheerde identiteit in met de rol Managed HSM Crypto Service Encryption User; Configureer voor Azure SQL Database de SQL Database om door de klant beheerde sleutel te gebruiken als TDE-beschermer, selecteer de sleutel uit Managed HSM, en schakel automatische rotatie in; Schakel voor Azure Cosmos DB door de klant beheerde sleutels in voor een Cosmos DB-account, selecteer de Managed HSM-sleutel en verleen de Cosmos DB beheerde identiteit toegang.
  • Implementeren van geautomatiseerde sleutelrotatie: Configureer een rotatiebeleid met een rotatiefrequentie van 90 dagen, schakel automatische rotatie in, configureer vervalnotificaties (alert 7 dagen voor verval), creëer een Azure Monitor-alert voor de Key Near Expiry-metriek om het beveiligingsteam te waarschuwen.
  • Schakel auditlogging in voor naleving: Schakel diagnostische logging in voor Managed HSM (AuditEvent-logboeken), stuur logboeken naar Log Analytics-werkruimte met onveranderlijke opslag (opslagduur van 90 dagen voor manipulatiebestendige auditsporen), raadpleeg toegangslogboeken voor sleutels om Encrypt-, Decrypt-, WrapKey- en UnwrapKey-bewerkingen te monitoren.
  • 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.

Uitkomst: RSA-4096-KEKs in beheerde HSM's hebben serviceniveau-DEK's versleuteld 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 Azure ingebouwde 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 belangrijke bewerkingen en implementeer uitgebreide auditlogboekregistratie om alle belangrijke toegang en administratieve wijzigingen bij te houden voor nalevings- en forensische doeleinden.

Gecentraliseerde infrastructuur voor sleutelbeheer tot stand brengen:

  • Gebruik Azure Key Vault als gecentraliseerde cryptografische sleutelbeheerservice om de volledige levenscyclus van sleutels te beheren: genereren, distribueren, opslaan, draaien en intrekken.
  • 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)
  • Gebruik Azure Key Vault Managed HSM voor bescherming voor één tenant, gevalideerd volgens FIPS 140-3 Niveau 3 voor HSM-bescherming. Beheerde HSM ondersteunt cryptografisch domein voor back-up en herstel na noodgevallen.
  • Configureer Azure Key Vault logboekregistratie en routelogboeken naar Azure Monitor of Microsoft Sentinel voor het bijhouden van alle belangrijke toegang, rotatiegebeurtenissen en beheerbewerkingen 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:

  • Implementeer automated sleutelrotatiebeleid in de 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 toegangsbeheersing.
    • 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 Bring Your Own Key (BYOK) scenario's 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, waarbij cryptografisch bewijs van de oorsprong en bewaring van sleutels wordt onderhouden.

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-gebruiker (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 heeft gecentraliseerd cryptografisch sleutelbeheer met behulp van Azure Key Vault Premium SKU met HSM-beschermde sleutels voor PHI-versleuteling 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:

  • Voorzien Azure Key Vault Premium met HSM-beschermde sleutels: Creëer een Azure Key Vault met de Premium laag om HSM-beschermde sleutels te ondersteunen, inschakel opschoningsbeveiliging ter voorkoming van permanente verwijdering tijdens de bewaarperiode, inschakelen van soft delete met een bewaartermijn van 90 dagen om het herstel van per ongeluk verwijderde sleutels mogelijk te maken, genereer RSA-3072 HSM-beschermde versleutelingssleutels (KEK-PHI-Prod) met een door hardware ondersteund sleuteltype.
  • Implementeer geautomatiseerde sleutelrotatiebeleid: Configureer het rotatiebeleid met een rotatiefrequentie van 180 dagen, schakel automatische rotatie in en stel een melding in om 30 dagen voor vervaldatum te waarschuwen, creëer Azure Monitor-actiegroepen om het beveiligingsteam te informeren wanneer sleutels bijna verlopen, configureer de rotatieactie 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: sleutellevenscyclus beheren, maar kunnen geen versleutelings- of ontsleutelingsbewerkingen uitvoeren), wijs de rol van Key Vault Crypto User toe aan door de toepassing beheerde identiteiten (machtigingen: alleen versleutelings- en ontsleutelingsbewerkingen uitvoeren zonder sleutelbeheermachtigingen), controleer de scheiding van taken door ervoor te zorgen dat geen enkele identiteit zowel de rol van Crypto Officer als die van Crypto User heeft.
  • Etablish KEK/DEK-hiërarchie voor snelle sleutelrotatie: Gegevensversleutelingssleutels (DEK's) op toepassingsniveau genereren in toepassingscode (AES-256-sleutels) voor het versleutelen van patiëntgegevens, sla versleutelde DEK naast versleutelde gegevens op, gebruik Key Vault KEK om DEK te verpakken/versleutelen via WrapKey-bewerking, DEK ophalen en uitpakken met behulp van UnwrapKey-bewerking bij het ontsleutelen van patiëntgegevens, voordeel: het roteren van KEK vereist alleen het opnieuw versleutelen van DEK's in plaats van de volledige patiëntendatabase.
  • Integreer Key Vault-logboeken met Microsoft Sentinel: Schakel diagnostische instellingen voor Key Vault in en verzend logboeken naar de Log Analytics-werkruimte, creëer Sentinel-analyseregels om ongebruikelijke toegangspatronen van sleutels, bulk sleutelbewerkingen, administratieve wijzigingen buiten kantooruren te detecteren.
  • Bring Your Own Key (BYOK)-overdracht van on-premises HSM: Download de BYOK-overdrachtssleutel van Key Vault, exporteer de sleutel van de on-premises HSM verpakt met de openbare BYOK-overdrachtssleutel van Key Vault, onderhoud cryptografisch bewijs van de sleutelherkomst, importeer de verpakte sleutel naar Key Vault waar deze HSM-beveiligd aankomt 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 Azure ingebouwde 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, draaien, intrekken en veilig verwijderen.
  • Definieer certificate-beleid 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).

Note: Voor eenvoudige scenario's kunt u Azure App Service beheerde 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 levensduurbewerkingen te configureren om verlenging te activeren bij een opgegeven percentage van de certificaatlevensduur.
    • Aanbevolen trigger: 80-90% geldigheidsperiode (bijvoorbeeld ~ 318 dagen voor certificaat van 397 dagen).
    • Actie: Automatisch verlengen (Key Vault vraagt verlenging van de CA 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 beheerde identiteiten of service-principals gebruiken met het juiste Key Vault toegangsbeleid:
    • Azure services binden automatisch nieuwe certificaatversies wanneer deze worden vernieuwd (doorgaans binnen 24 uur, is er geen service opnieuw opgestart vereist).
  • Voor toepassingen die niet automatisch Key Vault certificaten kunnen gebruiken, implementeert u manual certificaatrotatiewerkstromen met operationele runbooks en bewakingswaarschuwingen om verloopgerelateerde storingen te voorkomen.
  • Onderhoud een inventaris van alle certificaten in Azure Key Vault door certificaatnaam, doel, vervaldatum, afhankelijke services en verlengingsstatus bij te houden.

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:

  • Gebruik Azure Resource Graph 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 melden).
    • 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:

  • Configureer de integratie van de certificaatautoriteit met Azure Key Vault: Voeg DigiCert (of een andere geautoriseerde certificaatautoriteit) toe aan Key Vault met API-referenties voor geautomatiseerde certificaataanvragen.
  • Certificaatbeleid afdwingen van beveiligingsstandaarden: Definieer certificaatbeleid 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 jokertekencertificaten), sleuteltype (RSA 4096 bits), handtekeningalgoritme (SHA-256), geldigheidsperiode (maximaal 397 dagen volgens de baseline van het CA/Browser Forum), configureer levensduuractie voor automatisch verlengen (trigger ingesteld op 80% van de levensduur van het certificaat, ongeveer 318 dagen voor een certificaat van 397 dagen), actie: automatisch verlengen (Key Vault vraagt verlenging aan van DigiCert zonder handmatige tussenkomst).
  • Configureer automatische certificaatbinding voor Azure-services: Voor Azure App Service, importeer certificaat van Key Vault, wijs een gebruikers-toegewezen beheerde identiteit toe met de rol Key Vault Secrets User, schakel automatische certificaatupdates in (App Service bindt de nieuwe versie van het certificaat binnen 24 uur na vernieuwing, geen herstart vereist); voor Azure Application Gateway configureert u de listener om het certificaat van Key Vault op te halen, wijs een gebruikers-toegewezen beheerde identiteit toe met de Key Vault Secrets User en de Certificates User rollen, Application Gateway haalt automatisch het bijgewerkte certificaat op wanneer Key Vault het bijwerkt.
  • Verloopwaarschuwingen voor certificaten configureren: Maak twee waarschuwingsregels in Azure Monitor: een 30-dagen waarschuwing (verzend een melding naar het Slack-kanaal voor platformengineering) en een kritieke waarschuwing voor 7 dagen (open een Jira-ticket voor handmatige controle en stuur een e-mail naar het beveiligingsteam).
  • Imineer jokertekencertificaten ten gunste van SAN-certificaten: Bestaande jokertekencertificaten (*.contoso.com) controleren in Key Vault, vervangen door SAN-certificaten met expliciete DNS-namen (www.contoso.com, api.contoso.com), voordeel: als persoonlijke sleutel wordt aangetast, worden alleen vermelde FQDN's beïnvloed (niet alle subdomeinen).
  • Certificaatverloop monitoren: Gebruik Azure Resource Graph om een query uit te voeren op de certificaatinventaris en identificeer certificaten die bijna verlopen (binnen 30 dagen), zelfondertekende certificaten of certificaten die gebruikmaken van het verouderde SHA-1-handtekeningalgoritme. Controleer het dashboard elk kwartaal tijdens vergaderingen voor 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 Azure ingebouwde 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 implementeren voor Key Vault

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 Azure Key Vault Beheerde HSM: Gebruik lokale RBAC op het niveau van afzonderlijke sleutels, geheimen en certificaten met ingebouwde rollen (Beheerde HSM Crypto-officier, 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 toe te wijzen (Key Vault Administrator, Secrets Officer, Certificate Officer) met toepassingsspecifiek bereik.
  • 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 Microsoft Entra Privileged Identity Management (PIM) voor Just-In-Time-beheerderstoegang tot Key Vault:
    • Configureer in aanmerking komende toewijzingen voor Key Vault beheerdersrol (geen 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: Versterk de netwerkbeveiliging van Key Vault

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

Implementeer Private Link en configureer firewall:

  • Beveilig netwerktoegang tot Azure Key Vault met behulp van Azure Private Link om privéconnectiviteit van VNets tot stand te brengen zonder Key Vault bloot te stellen aan het openbare internet.
  • Configureer Key Vault firewall om de toegang tot specifieke IP-bereiken of VNets te beperken voor scenario's waarin Private Link niet haalbaar is:
    • Schakel waar mogelijk openbare toegang uit (Key Vault 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 wijzen op inbreuk, bedreigingen van insiders of verkenningsactiviteiten die gericht zijn op uw cryptografische infrastructuur.

Zachte verwijdering en bescherming tegen volledig verwijderen inschakelen:

  • Schakel soft delete en purge protection in op alle Azure Key Vaults 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 zachte verwijdering hebben ingeschakeld" en "Sleutelkluizen moeten beveiliging tegen zuivering hebben ingeschakeld" (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.
    • Maak en test Key Vault back-up procedures 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 met FIPS 140-2 niveau 2 gevalideerde HSM's (gedeelde multitenant).
    • Azure Key Vault Beheerde HSM: 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 Bring Your Own Key (BYOK) scenario's genereert u sleutels in on-premises FIPS 140-2 Level 2+ HSM's en gebruikt u het BYOK-overdrachtssleutelmechanisme om sleutels veilig in Azure Key Vault te importeren, waarbij cryptografisch bewijs van de oorsprong en bewaring van de sleutel behouden blijft.

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 beheervlak- en gegevensvlakbewerkingen vast te leggen. Controleer op verdachte activiteiten, waaronder ongebruikelijke sleuteltoegangspatronen, mislukte verificatiepogingen en beheerwijzigingen.
  • Schakel Microsoft Defender in voor Key Vault om afwijkende toegangspatronen, ongebruikelijke sleutelbewerkingen en mogelijke bedreigingen te detecteren, zoals misbruik van referenties, verdachte sleutelherstel 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 administratieve bewerkingen. Implementeer geautomatiseerde antwoordplaybooks om gecompromitteerde identiteiten te isoleren en beveiligingsteams op de hoogte te stellen.

Note: Alle Key Vault-SKU's voorkomen dat sleutels standaard worden geëxporteerd; cryptografische bewerkingen worden uitgevoerd binnen de beveiligde HSM-grens. Exporteer of sla sleutels nooit onversleuteld op buiten Azure Key Vault.

Voorbeeld van implementatie

Een multinationaal technologiebedrijf 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:

  • Implementeer dedicated Key Vaults voor logische segmentatie: Maak een Key Vault per omgeving en businessunit met de naamgevingsconventie kv-{businessunit}-{omgeving}-{regio} (bijvoorbeeld kv-finance-prod-eastus2, kv-finance-dev-eastus2), implementeer in afzonderlijke resourcegroepen per omgeving om isolatie af te dwingen, zodat een gecompromitteerde dev-service-principal geen toegang heeft tot productiesleutels.
  • RBAC configureren voor toegang met minimale bevoegdheden: Voor niet-productiesleutelkluizen (ontwikkel/staging) wijst u Key Vault Secrets User (alleen-lezen) toe aan beveiligingsgroepen voor ontwikkelaars. Ontwikkelaars kunnen geheimen lezen in ontwikkel/staging, maar hebben geen toegang tot productiesleutelkluizen; voor productiesleutelkluizen wijst u Key Vault Secrets User toe aan CI/CD-service-principals (via de Azure DevOps-pijplijn beheerde identiteiten), beperkt het bereik tot specifieke geheimen met naam, geen interactieve ontwikkelaarstoegang tot productiesleutels.
  • Harden-netwerkbeveiliging met Azure Private Link: Privé-eindpunten implementeren voor Key Vault (selecteer VNet en subnet, maak privé-DNS-zone privatelink.vaultcore.azure. net en koppeling naar 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 alleen toegang vanaf geselecteerde netwerken met goedgekeurde Azure VNet-subnetten en IP-adresbereiken van CI/CD-agent).
  • Enable Microsoft Defender voor Key Vault: Schakel Microsoft Defender in voor Key Vault op abonnementsniveau, Defender bewaakt afwijkingen, waaronder ongebruikelijke geografische toegang, verdachte opsomming (snelle lijstbewerkingen die reconnaissance aangeven), abnormale administratieve bewerkingen en bulkverwijderingen van geheimen.
  • Integreer met Microsoft Sentinel voor geautomatiseerde respons: Voeg de Microsoft Defender voor Cloud-gegevensconnector toe aan Sentinel, maak Sentinel Analytics-regels voor ongebruikelijke regionale toegang, potentiële brute kracht, verdachte beheerhandelingen, configureer geautomatiseerde respons-playbooks om verdachte identiteiten uit te schakelen en beveiligingsteams te informeren.
  • Stroom diagnostische logs naar Log Analytics: Schakel diagnostische logging in voor Key Vault met AuditEvent (alle sleutel-/geheim-/certificaatbewerkingen), AllMetrics (gebruik frequentie, latentie), verstuur naar Log Analytics-werkruimte met een retentieperiode van 2 jaar, en maak aangepaste KQL-queries voor afwijkingsdetectie inclusief potentiële brute force-detectie (10+ niet-geautoriseerde pogingen in 5 minuten), zachte verwijderingsbewerkingen uitgeschakeld (sabotage-indicator).
  • Implement Just-In-Time-beheerderstoegang met Microsoft Entra PIM: Configureer in aanmerking komende toewijzingen voor Key Vault Administrator-rol (voeg beveiligingsteamleden toe als In aanmerking komende niet-permanente toewijzing, vereist rechtvaardiging en MFA voor activering, stel maximale activeringsduur 8 uur in, vereist goedkeuring van senior beveiligingsarchitect), voer driemaandelijkse toegangsbeoordelingen uit voor alle Key Vault beheerdersroltoewijzingen; trek onnodige toegang in.

Resultaat: Toegewezen sleutelkluizen per omgeving dwingen segmentatie af. RBAC beperkt ontwikkelaars tot alleen-lezen toegang tot niet-productieomgeving. Private Link elimineert blootstelling aan het openbare internet. Microsoft Defender afwijkingen detecteert. 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