Datenschutz

Der Datenschutz schützt vertrauliche Informationen vor unbefugtem Zugriff, Exfiltration und Missbrauch im gesamten Datenlebenszyklus. Implementieren Sie Ermittlung und Klassifizierung, um Dateninventar, Verschlüsselung zum Schutz von Daten während der Übertragung und ruhenden Daten sowie disziplinierte Schlüssel- und Zertifikatverwaltung zur Aufrechterhaltung der kryptografischen Integrität einzurichten. Dieser mehrschichtige Ansatz stimmt überein mit den Zero Trust-Prinzipien und den Tiefenverteidigungsstrategien.

Ohne umfassenden Datenschutz sehen sich Organisationen Datenschutzverletzungen, behördliche Sanktionen und Reputationsschäden durch Exfiltration vertraulicher Informationen an.

Hier sind die drei Kernpfeiler der Datenschutz-Sicherheitsdomäne.

Kennen und klassifizieren Sie Ihre Daten: Ermitteln Sie vertrauliche Informationen, und wenden Sie konsistente Bezeichnungen an, um risikobasierte Steuerelemente zu aktivieren.

Verwandte Steuerelemente:

• DP-1: Ermitteln, Klassifizieren und Bezeichnen vertraulicher Daten
• DP-2: Überwachen von Anomalien und Bedrohungen für vertrauliche Daten

Schützen von Daten mit Verschlüsselung: Implementieren Sie eine umfassende Verschlüsselung für Daten während der Übertragung und im Ruhezustand unter Nutzung moderner kryptografischer Standards.

Verwandte Steuerelemente:

• DP-3: Verschlüsseln vertraulicher Daten während der Übertragung
• DP-4: Standardmäßige Verschlüsselung ruhender Daten aktivieren
• DP-5: Verwenden Sie die kundenverwaltete Schlüsseloption bei der Verschlüsselung der ruhenden Daten, wenn erforderlich

Verwalten der kryptografischen Infrastruktur: Einrichten des disziplinierten Lebenszyklus-Managements für kryptografische Schlüssel und Zertifikate mit automatisierter Rotation und umfassender Audit-Protokollierung.

Verwandte Steuerelemente:

• DP-6: Verwenden eines Sicheren Schlüsselverwaltungsprozesses
• DP-7: Verwenden eines sicheren Zertifikatverwaltungsprozesses
• DP-8: Sicherstellen der Sicherheit des Schlüssel- und Zertifikat-Repositorys

DP-1: Ermitteln, Klassifizieren und Bezeichnen vertraulicher Daten

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-1.

Sicherheitsprinzip

Sie können ein umfassendes Inventar vertraulicher Daten einrichten und verwalten, indem Sie Daten in allen Repositorys ermitteln, klassifizieren und bezeichnen. Dies ermöglicht risikobasierte Zugriffssteuerungen, Verschlüsselungsrichtlinien und Überwachung, um vor unbefugtem Zugriff und Exfiltration zu schützen.

Risiko mindern

Bedrohungsakteure missbrauchen mangelnde Sichtbarkeit und inkonsistenter Umgang mit vertraulichen Daten, um hochwertige Informationen zu exfiltrieren oder zu missbrauchen. Wenn vertrauliche Daten nicht erkannt, klassifiziert oder bezeichnet werden:

• Nicht nachverfolgte regulierte Daten: (PCI, PHI, PII), die an nicht verwalteten Standorten (Schatten-IT) gespeichert sind, umgehen erforderliche Verschlüsselungs-, Aufbewahrungs- oder Überwachungssteuerelemente.
• Überprivilegierter Zugriff: Der weitreichende Benutzer-/Dienstzugriff bleibt bestehen, da Sensibilität und geschäftliche Auswirkungen nicht identifiziert werden.
• Replikatverbreitung: Die Datenreplikation in Analyse-, Test- oder Exportpipelines verteilt vertrauliche Inhalte in Umgebungen mit niedrigerer Vertrauensebene.
• Forensische Blindstellen: Incident-Responder können aufgrund fehlender oder falscher Empfindlichkeitsmetadaten den Explosionsradius nicht schnell erfassen.
• Automatisierungsfehler: Governance (DLP, bedingter Zugriff, Verschlüsselungsworkflows) wird ohne konsistente Kennzeichnung nicht ausgelöst.

Der Mangel an grundlegender Klassifikation erhöht die Verweilzeit, erweitert laterale Bewegungsmöglichkeiten und erhöht die regulatorische und reputationsbedingte Exposition.

MITRE ATT&CK

• Reconnaissance (TA0043): Sammeln von Opferidentitäten / Datenressourcen (T1596) durch Aufzählen von Speicherkonten, Schemakatalogen und Klassifizierungsmetadaten, um hochwertige Repositorys zu profilieren.
• Discovery (TA0007): Account & Permission Enumeration (T1087, T1069), um übermäßige Rollenbindungen aufzudecken, die eine horizontale oder vertikale Datenzugriffseskalation ermöglichen.
• Sammlung (TA0009):Daten aus Cloudspeicher (T1530) durch Extrahieren nicht bezeichneter BLOB-Container oder nicht verwalteter Exporte ohne Nachverfolgungstags.
• Exfiltration (TA0010): Exfiltration über Webdienste (T1567) über Ad-hoc-Exportendpunkte, bei denen Bezeichnungs-/Richtlinientore fehlen.
• Exfiltration (TA0010): Automatisierte Exfiltration (T1020) mit skriptierter Paginierung/Schleifen, um unauffällig falsch klassifizierte Datensätze zu ernten.

DP-1.1: Ermitteln, Klassifizieren und Bezeichnen vertraulicher Daten

Verwenden Sie Microsoft Purview, um eine umfassende Datenzuordnung zu erstellen, die vertrauliche Informationen automatisch erkennt, klassifiziert und bezeichnet. Erweitern Sie den Schutz über die Verschlüsselung auf Infrastrukturebene hinaus, indem Sie Microsoft Purview Information Protection implementieren, um verschlüsselungs- und Nutzungsrechte auf persistenter Dokumentebene anzuwenden, die Daten folgen, unabhängig davon, wo sie reisen. Diese grundlegende Funktion ermöglicht nachgeschaltete Sicherheitskontrollen wie Verhinderung von Datenverlust, bedingter Zugriff und Verschlüsselungsrichtlinien, die basierend auf der Datenempfindlichkeit und nicht auf dem Standort basieren.

Datenermittlung und -klassifizierung:

• Stellen Sie Microsoft Purview bereit, um vertrauliche Daten in Azure, lokalen, Microsoft 365- und Multi-Cloud-Umgebungen zu ermitteln, zu klassifizieren und zu kennzeichnen.
• Verwenden Sie Microsoft Purview Data Map, um Datenquellen wie Azure Storage, Azure SQL-Datenbank, Azure Synapse Analytics und andere unterstützte Dienste automatisch zu scannen und zu katalogisieren.
• Aktivieren Sie Vertraulichkeitsbezeichnungen in purview Data Map, um Klassifizierungsbezeichnungen (z. B. Vertraulich, Streng vertraulich, PII, PHI) basierend auf Dateninhaltsmustern und Organisationsrichtlinien automatisch anzuwenden.

Verschlüsselung und Schutz auf Dokumentebene:

• Stellen Sie Microsoft Purview Information Protection bereit, um dauerhafte Verschlüsselungs- und Nutzungsrechte auf Dokumente und E-Mails basierend auf Vertraulichkeitsbezeichnungen anzuwenden. Konfigurieren Sie Bezeichnungen, um Dateien automatisch zu verschlüsseln, Wasserzeichen anzuwenden, Weiterleitung einzuschränken, Ablaufdaten festzulegen und den Zugriff zu widerrufen, auch nachdem Daten Ihre Organisation verlassen haben.
• Aktivieren Sie Azure Rights Management Service (Azure RMS) als zugrunde liegende Schutztechnologie, die Dokumente und E-Mails mit Verwendungsrichtlinien verschlüsselt (schreibgeschützt, ohne Kopie, ohne Druck), die unabhängig davon bestehen, wo Daten gespeichert oder freigegeben werden.

Datenbankklassifizierung und -integration:

• Aktivieren Sie für Azure SQL Datenbanken SQL Data Discovery & Klassifizierung, um Spalten zu identifizieren, zu klassifizieren und zu bezeichnen, die vertrauliche Daten wie Kreditkartennummern, Sozialversicherungsnummern oder Gesundheitsdatensätze enthalten.
• Integrieren Von Klassifizierungsmetadaten in nachgeschaltete Steuerelemente: Konfigurieren von DLP-Richtlinien (Data Loss Prevention) in Microsoft Purview, Anwenden von Regeln für bedingten Zugriff in Entra ID und Erzwingen von Verschlüsselungsrichtlinien basierend auf Vertraulichkeitsbezeichnungen.
• Richten Sie einen regelmäßigen Scanzeitplan ein, um ständig neu erstellte oder geänderte vertrauliche Datenressourcen zu ermitteln, während sich Ihre Datenbestände entwickeln.

Beispiel für die Implementierung

Eine globale Finanzdienstleistungsorganisation hat Microsoft Purview Data Map bereitgestellt, um vertrauliche Daten über 200+ Azure Storage Konten, 50 SQL-Datenbanken und Synapse Analytics-Arbeitsbereiche automatisch zu ermitteln und zu klassifizieren.

Challenge: Die Organisation hat keinen Einblick in den Speicherort vertraulicher Daten in ihrem schnell wachsenden Azure Datenbestand. Die manuelle Datenklassifizierung war inkonsistent, verzögerte Governance-Erzwingung und führte zu Compliancelücken. Ohne automatisierte Ermittlung blieben regulierte Daten (PHI, PII, PCI) an ungeschützten, nicht verwalteten Orten und Richtlinien zur Verhinderung von Datenverlust konnten nicht ordnungsgemäß ausgelöst werden.

Lösungsansatz:

• Bereitstellen der Microsoft Purview-Datenkarte zur Datenentdeckung: Erstellen Sie ein Purview-Konto und registrieren Sie Datenquellen (Azure-Speicherkonten, SQL-Datenbanken, Synapse Analytics-Arbeitsbereiche). Konfigurieren Sie die Datenkarte, um Quellen mithilfe der Authentifizierung über verwaltete Identität zu scannen, gewähren Sie der Scan-Identität Leseberechtigungen (db_datareader-Rolle), um Katalogschemata zu erfassen und sensible Spalten zu erkennen.
• Konfigurieren der Klassifizierung und der Vertraulichkeitserkennung: Einrichten von Scanregeln zum Erkennen vertraulicher Muster (SSN, Kreditkartennummern, Krankenaktennummern, SWIFT-Codes), Definieren benutzerdefinierter Klassifizierungsregeln, die mit der Datenklassifizierungsrichtlinie ("Vertraulich - Intern" für geschäftsrelevante Daten, "Streng vertraulich - reguliert" für PHI/PCI/PII-Daten) abgestimmt sind, automatische Bezeichnungsschwellenwerte konfigurieren (wenden Sie "Streng vertraulich" an, wenn ≥3 PII-Muster in einzelnen Ressourcen erkannt werden), richten Sie Scanzeitpläne basierend auf der Kritikalität der Daten ein (wöchentlich für die Produktion, monatlich für Archive), konfigurieren Sie Warnungen, um Sicherheitsteams zu benachrichtigen, wenn neue Daten mit hoher Vertraulichkeit erkannt werden.
• Bereitstellung von Microsoft Purview Information Protection für die Verschlüsselung auf Dokumentebene: Erstellen von Vertraulichkeitsbezeichnungen im Purview-Complianceportal mit Schutzeinstellungen (Öffentlich: keine Verschlüsselung, nur visuelle Markierungen; Intern: Wasserzeichen, keine Weiterleitungseinschränkungen; Vertraulich: Mit Azure RMS verschlüsseln, nur Anzeigen/Bearbeiten durch Mitarbeiter zulassen, Weiterleiten/Drucken blockieren; Streng vertraulich – reguliert: Mit Azure RMS verschlüsseln, Nur-Lesezugriff, kein Kopieren/Drucken/Weiterleiten, 90-Tage-Ablauf, widerrufbarer Zugriff); Veröffentlichen von Vertraulichkeitsbezeichnungen für Benutzer über Bezeichnungsrichtlinien (Bereich: Finanz-, Rechts- und Exekutivabteilungen); Konfigurieren automatischer Bezeichnungsrichtlinien zur automatischen Anwendung von Bezeichnungen (≥10 SSNs → "Streng vertraulich - reguliert", ≥5 Kreditkartennummern → "Streng vertraulich - reguliert"); Aktivieren des Azure RMS-Schutzes für bezeichnete Dokumente, die in SharePoint, OneDrive und Azure Storage Konten gespeichert sind; Konfigurieren clientseitiger Bezeichnungen für Office-Anwendungen, um Benutzer aufzufordern, Dokumente vor dem Speichern/Senden zu klassifizieren.

Ergebnis: Purview Data Map automatische Überprüfung identifiziert über 15.000 Datenressourcen, die regulierte Daten innerhalb der ersten Woche enthalten, wodurch die Ermittlungszeit von Monaten auf Tage reduziert wird. Information Protection Auto-Labeling hat innerhalb von 72 Stunden Verschlüsselung auf 8.500 Dokumente angewendet. Vertraulichkeitsbezeichnungen ermöglichen kontinuierliche Sichtbarkeit der Datenstruktur und beständigen Schutz, auch wenn Daten auf nicht verwaltete Geräte verschoben werden.

Kritischitätsstufe

Unverzichtbar.

Steuerelementzuordnung

• CIS-Kontrollen 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: Überwachen von Anomalien und Bedrohungen für sensible Daten

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-2.

Sicherheitsprinzip

Überwachen sie vertrauliche Datenzugriffs- und Übertragungsaktivitäten auf Anomalien, die auf nicht autorisierte Exfiltration, Insiderbedrohungen oder kompromittierte Konten hinweisen. Verwenden Sie Verhaltensbaselines und Datenempfindlichkeitskontext, um ungewöhnliche Muster wie große Übertragungen, ungewöhnliche Zugriffszeiten oder unerwartete Datenbewegungen zu erkennen.

Risiko mindern

Angreifer und böswillige Insider versuchen, vertrauliche Daten mithilfe von unauffälligem oder schwach wahrnehmbarem Verhalten zu exfiltrieren, vorzubereiten oder zu untersuchen. Ohne kontinuierliche, kontextbezogene Anomalieüberwachung, die an die Vertraulichkeit von Daten gebunden ist:

• Stille Exfiltration: Massenexporte, große Resultsets oder schrittweises Abschöpfen erfolgen unbemerkt aufgrund fehlender Referenzwerte.
• Insider-Missbrauch: Legitime Anmeldeinformationen führen ungewöhnliche Sequenzen (Uhrzeit, Umfang, Standort) aus, die die oberflächliche Überwachung umgehen.
• Staging und Aufzählung: Angreifer mappen Schemastrukturen und Labels, um wertvolle Ziele vor der Massenextraktion zu priorisieren.
• Living-off-the-Land-Abfragen: Standard-Verwaltungstools maskieren Aufklärung in normalem Betriebsrauschen.
• Speicherübergreifende Ausweichung: Der verteilte Zugriff über mehrere Dienste hinweg vermeidet Schwellenwerte und Korrelationen mit einem Speicher.

Unzureichende Anomalieerkennung erodiert die Wirksamkeit der Reaktion auf Vorfälle und ermöglicht eine Eskalation von Aufklärung bis hin zur vollständigen Exfiltration mit minimaler Reibung.

MITRE ATT&CK

• Sammlung (TA0009): Daten aus Cloudspeicher (T1530) mittels anomaler Massen- oder breitgefächerter Lesevorgänge in sensiblen Container.
• Zugriffsberechtigung für Anmeldeinformationen (TA0006):Gültige Konten (T1078) missbrauchen kompromittierte oder Insider-Anmeldeinformationen, um sich mit legitimen Datenverkehrsgrundlagen zu verbinden.
• Exfiltration (TA0010): Automatisierte Exfiltration (T1020) mit skriptierten, gedrosselten Abfragen, die entwickelt wurden, um Warnungsschwellenwerte zu vermeiden.
• Exfiltration (TA0010): Exfiltration zu Cloud-Speichern (T1567.002), Datenaufbereitung in von Angreifern kontrollierten Regionen oder Konten für den späteren Abruf.
• Command & Control / Exfiltration (TA0011/TA0010): Anwendungsschichtprotokoll (T1071) tunnelt sensible Zeilen über normale DB/API-Aufrufe.
• Discovery (TA0007):System- und Dienstermittlung (T1082, T1046) Endpunkte auflisten, um laterale Bewegungspfade zu Speicherorten mit höherem Wert zu identifizieren.

DP-2.1: Aktivieren der Bedrohungserkennung für Datendienste

Stellen Sie Microsoft Defender Dienste bereit, um bedrohungserkennung und Anomalieüberwachung auf Ihren Datenspeicher- und Datenbankplattformen bereitzustellen. Diese Dienste verwenden Verhaltensanalysen und Bedrohungsintelligenz, um verdächtige Aktivitäten wie SQL-Einfügeversuche, anomale Abfragemuster, ungewöhnliche Datenzugriffsvolumes und potenzielle Exfiltrationsindikatoren zu identifizieren, die herkömmliche Zugriffssteuerungen nicht erkennen können.

Aktivieren der Bedrohungserkennung für Datendienste:

• Aktivieren Sie Microsoft Defender für Speicher mit Schadsoftwareüberprüfung und der Erkennung vertraulicher Daten, um anomale Zugriffsmuster, ungewöhnliche Upload-/Downloadvolumes und potenzielle Datenexfiltrationsversuche über Azure Storage Konten hinweg zu überwachen.
• Aktivieren Sie Microsoft Defender für SQL, um verdächtige Datenbankaktivitäten wie SQL-Einfügungsversuche, anomaliele Abfragemuster, ungewöhnliche Datenexportvorgänge und Zugriff von unbekannten Speicherorten zu erkennen.
• Aktivieren Sie Microsoft Defender für Azure Cosmos DB, um anomale Datenbankzugriffsmuster, potenzielle Datenexfiltration und verdächtige operative Aktivitäten zu erkennen.
• Aktivieren Sie für Open-Source-Datenbanken (PostgreSQL, MySQL) Microsoft Defender für relationale Open Source-Datenbanken, um Brute-Force-Angriffe, verdächtige Zugriffsmuster und anomale administrative Vorgänge zu erkennen.

DP-2.2: Überwachen und Verhindern der Datenexfiltration

Implementieren Sie proaktive Kontrollen zur Verhinderung von Datenverlust und Verhaltensüberwachung, um nicht autorisierte Datenübertragungen zu erkennen und zu blockieren, bevor sie erfolgreich sind. Kombinieren Sie richtlinienbasierte DLP mit Insider-Risikomanagement, SIEM-Korrelation und automatisierter Reaktion, um einen umfassenden Verteidigungsansatz zu erstellen, der Exfiltrationsversuche über mehrere Kanäle stoppt und forensische Beweise für die Untersuchung von Vorfällen bereitstellt.

Bereitstellung von DLP- und Insider-Risikokontrollen:

• Verwenden Sie Microsoft Purview Data Loss Prevention (DLP) Richtlinien, um vertrauliche Datenexfiltration zu verhindern, indem Sie nicht autorisierte Übertragungen von klassifizierten Daten über Azure Dienste, Microsoft 365 und Endpunkte hinweg überwachen und blockieren.
• Stellen Sie Microsoft Purview Insider Risk Management bereit, um riskante Benutzerverhalten mithilfe von maschinellem Lernen und Verhaltensanalysen zu erkennen. Überwachen Sie Indikatoren, einschließlich ungewöhnlicher Datendownloads, Kopieren von Dateien in USB-/persönlichen Cloudspeicher, Zugreifen auf sensible Ressourcen außerhalb der normalen Arbeitszeiten oder Datenzugriffsspitzen vor Rücktrittsterminen. Das Insider-Risikomanagement korreliert Signale von Microsoft 365, Azure, HR-Systemen und Sicherheitstools, um potenzielle Datendiebstahl oder Richtlinienverletzungen zu identifizieren.

Konfigurieren von Überwachung und Reaktion:

• Konfigurieren Sie diagnostische Protokolle für Datendienste, und leiten Sie sie an Azure Monitor oder Microsoft Sentinel weiter, um Verhaltensbasispläne einzurichten und Abweichungen von normalen Zugriffsmustern zu erkennen.
• Integrieren Sie Datendienstprotokolle in Microsoft Sentinel, um Analyseregeln zum Erkennen anomales Datenzugriffsmuster wie Massendownloads, Off-Hours-Zugriff oder verdächtige Abfrageverhalten zu erstellen.
• Implementieren Sie automatisierte Workflows zur Reaktion auf Vorfälle mithilfe von Azure Logic Apps oder Microsoft Sentinel Playbooks, um kompromittierte Identitäten zu isolieren, Den Zugriff zu widerrufen und Sicherheitsteams zu benachrichtigen, wenn Datenexfiltrationsversuche erkannt werden.

Note: Stellen Sie für hostbasierte DLP-Anforderungen Microsoft Purview Endpunkt-DLPfunktionen oder Lösungen von Drittanbietern aus Azure Marketplace bereit, um Datenschutzsteuerelemente auf Endpunktebene zu erzwingen.

Beispiel für die Implementierung

Ein Gesundheitswesenanbieter hat Microsoft Defender für Speicher und Defender für SQL aktiviert, um Anomalien und Bedrohungen zu überwachen, die auf Patientendaten in Azure Storage Konten und SQL-Datenbanken abzielen.

Herausforderung: Die Organisation erlebte blinde Flecken bei der Erkennung nicht autorisierter Datenzugriffs- und Exfiltrationsversuche. Herkömmliche Umkreisschutzmaßnahmen erkannten Insider-Bedrohungen nicht und ermöglichten es den Dienstprinzipalen, Massendownloads durchzuführen. Ohne Verhaltensanalysen und Anomalieerkennung blieben verdächtige Zugriffsmuster über längere Zeiträume unbemerkt, wodurch das Risiko von Sicherheitsverletzungen und die Verweilzeit erhöht wurden.

Lösungsansatz:

• Aktivieren Sie Microsoft Defender für Storage: Aktivieren Sie Defender für Speicherkonten auf Abonnementebene für Speicherkonten mit vertraulichen Daten, konfigurieren Sie die Schadsoftwareüberprüfung, um bösartige Dateien im BLOB-Speicher zu erkennen und zu isolieren, aktivieren Sie die Erkennung vertraulicher Daten mithilfe der Purview-Typen für sensible Informationstypen zur Identifizierung von PHI/PII-Mustern, legen Sie Grenzwerte pro Transaktion oder monatliche Obergrenzen fest, um die Kosten zu kontrollieren, und wenden Sie Schutz auf Ressourcengruppen an, die Produktionsspeicherkonten enthalten und medizinische Bildgebung und EHR-Exporte hosten.
• Microsoft Defender für SQL aktivieren: Aktivieren Sie Defender für SQL auf Abonnementebene für Azure SQL-Datenbank und SQL Managed Instance, konfigurieren Sie die Sicherheitsrisikobewertung mit wiederkehrenden Scans und legen Sie ein Speicherkonto für die Scanergebnisse fest. Richten Sie E-Mail-Benachrichtigungen ein, um das Sicherheitsteam über identifizierte Risiken zu informieren. Aktivieren Sie den erweiterten Bedrohungsschutz, um SQL-Injektionsversuche, ungewöhnliche Abfragemuster, anomalen Zugriff aus ungewohnten Regionen und potenzielle Datenextraktion zu erkennen.
• Integration mit Microsoft Sentinel: Verbinden Sie Microsoft Defender for Cloud mithilfe eines Datenkonnektors mit Microsoft Sentinel, konfigurieren Sie die Diagnostikeinstellungen (aktivieren Sie Diagnoselogs für Speicheroperationen und SQL-Prüfungsprotokolle, leiten Sie diese in den Log Analytics-Arbeitsbereich weiter), erstellen Sie Sentinel-Analytics-Regeln, um Anomalien zu erkennen (Warnungen für Massendownloads bei Downloads >10 GB innerhalb von 1 Stunde, Datenbankzugriff außerhalb der regulären Arbeitszeiten, verdächtige Abfragemuster), konfigurieren Sie automatisierte Reaktions-Playbooks, um kompromittierte Identitäten zu isolieren, den Speicherzugriff zu widerrufen und Sicherheitsteams zu benachrichtigen.
• Bereitstellen von Microsoft Purview Insider Risk Management für die Erkennung verhaltensbezogener Bedrohungen: Aktivieren Sie das Insider-Risikomanagement und konfigurieren Sie Richtlinienvorlagen, um Datendiebstahl durch ausscheidende Benutzer zu erkennen, wie z.B. ungewöhnliche Dateidownloads 30-90 Tage vor einem Rücktritt, überwachen Sie allgemeine Datenlecks, wie z.B. Kopien auf USB-/Cloud-Speicher, und Datenlecks bei Prioritätsbenutzern mit erhöhter Überwachung für Rollen mit hohen Berechtigungen. Konfigurieren Sie Risikoindikatoren und Schwellenwerte, um kumulative Downloadvolumenwarnungen für Dateien, Zugriffsspitzen außerhalb der Geschäftszeiten und die Sequenzerkennung, die mehrere riskante Signale kombiniert, zu berücksichtigen. Integrieren Sie Datenquellen wie Azure-Aktivitätsprotokolle, Microsoft 365-Überwachungsprotokolle, Defender for Cloud Apps, HR-Systeme und Endpunkt-DLP-Ereignisse, und konfigurieren Sie die Weiterleitung von Workflows basierend auf Warnungen mit mittlerem/hohem Schweregrad zu einer dedizierten Untersuchungswarteschlange.

Outcome: Defender for Storage hat anomale Massendownloadaktivitäten von einem kompromittierten Dienstprinzipal innerhalb von 48 Stunden erkannt. Die automatisierte Reaktion isolierte die Identität und benachrichtigte die SOC innerhalb weniger Minuten, wodurch die Erkennungszeit von Tagen auf unter 15 Minuten reduziert wird. Das Insider-Risikomanagement hat einen ausscheidenden Mitarbeiter gekennzeichnet, der Forschungsdaten deutlich mehr als seine übliche Nutzung auf persönlichen Cloud-Speicher heruntergeladen hat, was eine schnelle Intervention ermöglicht hat.

Kritischitätsstufe

Unverzichtbar.

Steuerelementzuordnung

• CIS-Kontrollen 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: Verschlüsseln Sie vertrauliche Daten während der Übertragung

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-3.

Sicherheitsprinzip

Schützen Sie Daten während der Übertragung mithilfe einer starken Verschlüsselung (z. B. TLS 1.2 oder höher), um Abfangen, Manipulationen und unbefugten Zugriff zu verhindern. Definieren Sie Netzwerkgrenzen und Dienstbereiche, bei denen Die Verschlüsselung obligatorisch ist, und priorisieren Sie den externen und öffentlichen Netzwerkdatenverkehr, während Sie den internen Netzwerkschutz basierend auf der Datenempfindlichkeit berücksichtigen.

Risiko mindern

Unverschlüsselte oder schwach geschützte Netzwerkkanäle setzen vertrauliche Daten der Gefahr des Abfangens, der Manipulation und des Herabstufungsmissbrauchs aus. Keine erzwungene moderne Transportverschlüsselung (TLS 1.2+):

• Passives Abfangen: Netzwerkbeobachter erfassen Anmeldeinformationen, Token, API-Nutzlasten oder regulierte Daten in Klartext.
• Man-in-the-Middle: Angreifer ändern Abfragen, fügen Nutzlasten ein oder greifen Sitzungsmaterial ab.
• Protokolldowngrade: Legacy-Fallback (SSL/TLS < 1.2, Plaintext HTTP/FTP) ermöglicht die Nutzung veralteter Verschlüsselungssammlungen.
• Session Hijacking: Fehlende Kanalintegrität ermöglicht die Token-Wiedergabe oder den Cookie-Diebstahl für seitliche Bewegungen.
• Integritätsmanipulation: Das Manipulieren verfälscht Analysen oder veranlasst betrügerische Transaktionen.
• Undurchsichtige laterale Pfade: Interner Klartextverkehr wird zu Aufklärungsmaterial nach erfolgreichem Einschleusen.

Wenn Sie keine starke Verschlüsselung während der Übertragung erzwingen, wird der Explosionsradius von Sicherheitsverletzungen vergrößert, die Kompromittierung von Anmeldedaten beschleunigt und die Annahmen des Zero-Trust-Modells werden untergraben.

MITRE ATT&CK

• Zugriff auf Anmeldeinformationen (TA0006): Ungeschützte Anmeldeinformationen (T1552) wurden während Klartext- oder herabgestufter TLS-Sitzungen abgefangen, wodurch Token/Sitzungsmaterial offengelegt werden.
• Sammlung (TA0009): Netzwerk-Sniffing (T1040) zum Abfangen von API-Nutzlasten und geheimen Schlüsseln, die schwache Chiffrier- oder Klartextpfade durchlaufen.
• Exfiltration (TA0010): Exfiltration über Webdienste (T1567) ist das Streamen strukturierter Daten durch legitime API-Endpunkte.
• Defense Evasion (TA0005): Angreifer in der Mitte (T1557) erzwingen TLS-Downgrade oder Einfügen von Abfangen-Proxys zum Anzeigen/Ändern des Datenverkehrs.
• Command & Control (TA0011): Nicht-Anwendungsschichtprotokoll (T1095) wird auf ältere oder weniger überprüfte Übertragungsmethoden zurückgesetzt, um die Überwachung zu umgehen.

DP-3.1: Erzwingen der TLS-Verschlüsselung für Datendienste und Anwendungen

Richten Sie moderne Sicherheitsstandards für Transportebenen für alle kundenorientierten Dienste und Datenplattformen ein, um vor Abfangen, Manipulationen und Man-in-the-Middle-Angriffen zu schützen. Erzwingen Sie mindestens TLS 1.2 oder 1.3 zwischen Speicher, Webanwendungen, Datenbanken und API-Gateways, während Ältere Protokolle und schwache Verschlüsselungssammlungen deaktiviert werden, die Daten kryptografischen Downgradeangriffen zur Verfügung stellen.

Erzwingen von TLS für Datendienste und Anwendungen:

• Erzwingen Sie secure transfer (nur HTTPS) für Azure Storage-Konten, um sicherzustellen, dass alle Clientverbindungen TLS 1.2 oder höher für Blob-, Datei-, Warteschlangen- und Tabellenvorgänge verwenden.
• Aktivieren Sie für Webanwendungen, die auf Azure App Service gehostet werden, die Einstellung "NUR HTTPS", und konfigurieren Sie minimum TLS-Version auf 1.2 oder 1.3, um Downgradeangriffe zu verhindern und moderne kryptografische Standards sicherzustellen.
• Konfigurieren Sie Azure Application Gateway so, dass tls 1.2/1.3-Mindestversion sowohl für Front-End-Listener als auch für die Back-End-Verbindungsverschlüsselung (End-to-End TLS) erzwungen wird.
• Stellen Sie für Azure SQL-Datenbank und andere PaaS-Datendienste sicher, dass "Sichere Verbindungen erforderlich" oder gleichwertige Einstellungen verschlüsselte Verbindungen erzwingen; Nur-Text-Verbindungen ablehnen.
• Konfigurieren Sie für API-Verwaltung, Azure Front Door und andere Gatewaydienste mindeste TLS-Versionsrichtlinien, um TLS 1.2 oder höher zu erzwingen und schwache Verschlüsselungssammlungen zu deaktivieren.

Note: Azure verschlüsselt automatisch den gesamten Datenverkehr zwischen Azure Rechenzentren mithilfe von MACsec (Layer 2) und TLS (Layer 7). Die meisten Azure PaaS-Dienste aktivieren TLS 1.2+ standardmäßig, überprüfen jedoch mindesteinstellungen für TLS-Versionen für Dienste mit vom Kunden konfigurierbaren Richtlinien (Speicher, App Service, Anwendungsgateway, API-Verwaltung, Front Door).

DP-3.2: Sicheres Remotezugriffs- und Dateiübertragungsprotokoll

Vermeiden Sie Nur-Text-Verwaltungszugriff und ältere Dateiübertragungsprotokolle, die Anmeldeinformationen und vertrauliche Daten während der operativen Aktivitäten verfügbar machen. Ersetzen Sie unsichere Protokolle (FTP, unverschlüsselte RDP/SSH) durch moderne, verschlüsselte Alternativen und leiten Sie privilegierten Zugriff durch zentrale Bastionen, um die direkte Internetverbindung von Verwaltungsschnittstellen zu beseitigen.

Sichere Remoteverwaltungsprotokolle:

• Verwenden Sie für die Remoteverwaltung von Azure virtuellen Computern ausschließlich sichere Protokolle:
  • Linux-VMs: Verwenden Sie SSH (Port 22) mit schlüsselbasierter Authentifizierung; Kennwortauthentifizierung deaktivieren.
  • Windows VMs: Verwenden Sie RDP über TLS (Port 3389) mit aktivierter NLA(Network Level Authentication).
  • Privileged access: Leiten Sie administrative Verbindungen über Azure Bastion weiter, um die öffentliche IP-Exposition zu beseitigen und browserbasierten oder systemeigenen Clientzugriff über TLS bereitzustellen.

Sichere Dateiübertragungsprotokolle:

• Verwenden Sie für Dateiübertragungsvorgänge sichere Protokolle, und deaktivieren Sie Legacyalternativen:
  • Verwenden Sie die SFTP-Unterstützung in Azure Blob Storage (erfordert hierarchischen Namespace).
  • Verwenden Sie FTPS in Azure App Service und Azure Functions.
  • Altes FTP-Protokoll deaktivieren (Nur-Text).
• Verwenden Sie Azure Policy, um Richtlinien für sichere Übertragungen in Ihrer Umgebung zu erzwingen und die Compliance für TLS-Versionsanforderungen zu überwachen.

Beispiel für die Implementierung

Eine E-Commerce-Plattform hat TLS 1.3-Mindestversion für alle kundenorientierten Dienste erzwungen, um PCI-DSS 4.0-Anforderungen zu erfüllen.

Herausforderung: Ältere TLS 1.0/1.1-Protokolle und schwache Verschlüsselungssuiten setzten Kundenzahlungsdaten Abfangangriffen aus. Inkonsistente TLS-Erzwingung über Anwendungsebenen hinweg hat Sicherheitslücken geschaffen, bei denen Angreifer Verbindungen herabstufen könnten. Ohne zentralisierte TLS-Richtliniendurchsetzung führte manuelle Konfigurationsabweichung dazu, dass unsichere Protokolle in der Produktion bestehen blieben.

Lösungsansatz:

• Configure-Azure App Service für TLS 1.3: Mindest-TLS-Version auf 1.3 für kundenorientierte Webanwendungen und APIs festlegen, aktivieren Sie den HTTPS-modus, um den gesamten HTTP-Datenverkehr automatisch an HTTPS umzuleiten, überprüfen Sie, ob verwaltete Zertifikate oder benutzerdefinierte Zertifikate starke Verschlüsselungssammlungen verwenden.
• Azure Application Gateway für End-to-End-TLS konfigurieren: Konfigurieren Sie den Frontend-HTTPS-Listener mit der SSL-Richtlinie AppGwSslPolicy20220101 (mindestens TLS 1.3 mit CustomV2-Richtlinie), laden Sie das TLS-Zertifikat hoch oder integrieren Sie es in den Key Vault für die Zertifikatverwaltung, konfigurieren Sie die Back-End-Einstellungen für HTTPS-Verbindungen (setzen Sie das Back-End-Protokoll auf HTTPS bei Port 443, aktivieren Sie die Verwendung eines bekannten CA-Zertifikats, wenn Back-End-App-Dienste Azure-verwaltete Zertifikate verwenden, stellen Sie die minimale TLS-Version auf 1.2 für Back-End-Verbindungen ein), und erstellen Sie Routingregeln, die die HTTPS-Listener mit Back-End-Pools mit TLS-aktivierten Einstellungen verknüpfen.
• Sicherer Transfer für Azure Storage erzwingen: Aktivieren Sie die Einstellung „Sicherer Transfer erforderlich“, um HTTPS-only für Blob-, Datei-, Warteschlangen- und Tabellenvorgänge zu erzwingen, setzen Sie die minimale TLS-Version für alle Speicherverbindungen auf 1.2, und prüfen Sie, dass alle SAS-Tokens und geteilten Schlüssel nur über HTTPS-Verbindungen funktionieren.
• Configure Azure Bastion für den sicheren Remotezugriff: Stellen Sie Azure Bastion im Hub-VNet bereit, um browserbasierten RDP/SSH-Zugriff über TLS 1.2 bereitzustellen, öffentliche IPs von VMs zu entfernen und den gesamten administrativen Zugriff ausschließlich über Bastion weiterzuleiten.

Outcome: Azure Storage Konten lehnen HTTP-Verbindungen an der Dienstgrenze ab, das Anwendungsgateway erzwingt TLS 1.3 für Front-End-Verbindungen mit TLS 1.2-Back-End-Verschlüsselung und Azure Bastion die öffentliche IP-Gefährdung für die VM-Verwaltung beseitigt.

Kritischitätsstufe

Unverzichtbar.

Steuerelementzuordnung

• CIS-Kontrollen 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: Aktivieren einer standardmäßigen Verschlüsselung für ruhende Daten

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-4.

Sicherheitsprinzip

Aktivieren Sie die ruhende Verschlüsselung standardmäßig, um Daten vor unbefugtem Zugriff durch zugrunde liegende Speicher, physischen Mediendiebstahl, Snapshot-Belichtung oder kompromittierten Infrastrukturzugriff zu schützen. Die Verschlüsselung ergänzt Zugriffskontrollen, indem sichergestellt wird, dass Die Daten auch dann geschützt bleiben, wenn die Sicherheit auf Speicherebene umgangen wird.

Risiko mindern

Unverschlüsselte oder selektiv verschlüsselte Speicherebenen ermöglichen Angreifern mit Out-of-Band-Zugriff (Infrastrukturkompromittierung, gestohlene Medien, Snapshot-Missbrauch), sensible Daten im großen Maßstab zu ernten. Ohne Standardverschlüsselung:

• Datengewinnung aus Rohmedien: Gestohlene Datenträger, Sicherungen oder nicht verwaltete Momentaufnahmen machen vollständige Nur-Text-Datasets verfügbar.
• Rechtebegrenzungserosion: Plattformadministratoren oder kompromittierte Host-Agents können Mandantendaten ohne kryptografische Trennung lesen.
• Stille Kopie und Exfiltration: Unverschlüsselte Replikate (Test, Analysen, Export) werden zu reibungsarmen Exfiltrationskanälen.
• Integritätsmanipulation: Angreifer ändern ruhende Daten (bösartige DLLs, Konfiguration oder Referenzdaten), um eine spätere Kompromittierung auszulösen.
• Nichteinhaltung gesetzlicher Vorschriften: Fehlende systemische Verschlüsselung untergräbt die für viele Branchenzertifizierungen erforderlichen Zusicherungen.
• Schlüssellose Wiederherstellungsexposition: Notfallwiederherstellungsimages und kalte Archive bewahren vertrauliche Inhalte dauerhaft in wiederherstellbarem Klartext auf.

Das Nichteinhalten der universellen Verschlüsselung im Ruhezustand vergrößert das Ausmaß von Sicherheitsverletzungen, erschwert die Definition des forensischen Untersuchungsumfangs und erhöht die nachfolgenden betrieblichen und rechtlichen Risiken.

MITRE ATT&CK

• Sammlung (TA0009):Daten aus Cloudspeicher (T1530) durch Extrahieren unverschlüsselter Momentaufnahmen, Replikate oder getrennter Datenträger.
• Defense Evasion (TA0005): Entfernung von Indikatoren (T1070) zur Bearbeitung oder Löschung von Protokollen nach dem Zugriff auf Offline-Medien oder Schnappschüsse.
• Auswirkung (TA0040): Die Datenvernichtung (T1485) beschädigt unverschlüsselte ruhende Ressourcen, um nachgelagerte Prozesse zu unterbrechen.
• Auswirkung (TA0040): Verhindern der Systemwiederherstellung (T1490) beim Löschen oder Ändern unverschlüsselter Sicherungen und Wiederherstellungskataloge.
• Auswirkung (TA0040): Datenmanipulation (T1565) ändert subtil gespeicherte Referenz- oder Konfigurationsdaten so, dass spätere Logikfehler verursacht werden.

DP-4.1: Standardmäßige Verschlüsselung ruhender Daten aktivieren

Stellen Sie sicher, dass alle in Azure gespeicherten Daten im Ruhezustand verschlüsselt sind, um vor unbefugtem Zugriff vor Infrastrukturkompromittierung, gestohlenen Medien oder nicht autorisierten Momentaufnahmen zu schützen. Während die meisten Azure Dienste die Verschlüsselung standardmäßig aktivieren, überprüfen Sie die Abdeckung über virtuelle Computer, Speicherkonten und Datenbanken hinweg, und aktivieren Sie zusätzliche Verschlüsselungsebenen (Verschlüsselung auf Host, Infrastrukturverschlüsselung, vertrauliches Computing und Verschlüsselung auf Spaltenebene) für streng vertrauliche Workloads, um behördliche und datenhoheitsanforderungen zu erfüllen.

Aktivieren der Verschlüsselung für VMs und Speicher:

• Aktivieren Sie encryption-at-host, damit Azure Virtual Machines temporäre Datenträger, Betriebssystemdatenspeicher, Datenträgercache und kurzlebige Betriebssystemdatenträger verschlüsseln können, bevor Daten Azure Storage erreichen. Registrieren Sie das EncryptionAtHost-Feature auf Abonnementebene, und stellen Sie VMs mithilfe unterstützter VM-Größen bereit (z. B. DSv3, Easv4, Dadsv5-Serie).
• Aktivieren Sie Infrastrukturverschlüsselung (doppelte Verschlüsselung) für Azure Storage Konten, die zusätzliche Verschlüsselungsebenen erfordern. Dies bietet zwei Ebenen der AES-256-Verschlüsselung mit unterschiedlichen Schlüsseln auf Dienst- und Infrastrukturebene– konfigurieren Sie während der Erstellung des Speicherkontos, da sie nach der Erstellung nicht aktiviert werden kann.

Vertrauliches Rechnen und Verschlüsselung auf Spaltenebene bereitstellen:

• Stellen Sie Azure Vertrauliche VMs mit vertraulicher Datenträgerverschlüsselung für streng regulierte Workloads bereit, die exportgesteuerte oder vertrauliche Daten verarbeiten. Verwenden Sie DCasv5/DCadsv5-Serie (AMD SEV-SNP) oder ECasv5/ECadsv5-Series (Intel TDX) mit vTPM-gebundenen Datenträgerverschlüsselungsschlüsseln, um sicherzustellen, dass Daten während der Verarbeitung verschlüsselt bleiben.
• Implementieren Sie für Azure SQL-Datenbank Always Encrypted, um clientseitige Verschlüsselung auf Spaltenebene für streng vertrauliche Daten (SSN, Kreditkartennummern, Medizinische Datensätze) bereitzustellen, bei denen Daten auch von Datenbankadministratoren, Cloudoperatoren und nicht autorisierten Benutzern verschlüsselt bleiben. Verwenden Sie Always Encrypted mit sicheren Enklaven (Intel SGX), um umfangreichere Abfragen für verschlüsselte Spalten zu ermöglichen.

Überwachen und Erzwingen der Verschlüsselungscompliance:

• Erzwingen Sie die Verschlüsselungscompliance mithilfe von Azure Policy durch Zuweisen integrierter Richtlinien wie "Virtuelle Computer sollten verschlüsselung auf Host aktivieren", "Speicherkonten sollten über Infrastrukturverschlüsselung verfügen" und "Transparent Data Encryption in SQL-Datenbanken sollte aktiviert werden" im Abonnement- oder Verwaltungsgruppenbereich.
• Verwenden Sie Azure Resource Graph, um Verschlüsselungskonfigurationen in Ihrer Umgebung abzufragen und zu inventarisieren. Dabei können Sie VMs ohne Verschlüsselung am Host, Speicherkonten ohne Infrastrukturverschlüsselung und Datenbanken ohne aktiviertes TDE identifizieren.

Note: Viele Azure-Dienste (Azure Storage, Azure SQL-Datenbank, Azure Cosmos DB) verfügen standardmäßig über die Verschlüsselung ruhender Daten auf Infrastrukturebene mithilfe von dienstverwalteten Schlüsseln, die alle zwei Jahre automatisch gedreht werden. Wenn die Verschlüsselung standardmäßig nicht aktiviert ist, aktivieren Sie sie auf Speicher-, Datei- oder Datenbankebene basierend auf technischen Machbarkeits- und Workloadanforderungen.

Beispiel für die Implementierung

Ein multinationales Produktionsunternehmen hat die Verschlüsselung ruhender Daten in seiner Azure-Umgebung standardisiert, um ERP-Daten, Supply-Chain-Anwendungen und technische Geheimnisse zu schützen.

Herausforderung: Inkonsistente Verschlüsselungsabdeckung hat sensible Daten anfällig für Infrastrukturkompromittierung und Snapshotdiebstahl. Temporäre Datenträgerdaten und kurzlebiger Speicher blieben unverschlüsselt, wodurch Compliancelücken entstehen. Ohne systematische Verschlüsselungserzwingung könnten technische Geschäftsgeheimnisse und Lieferkettendaten über gestohlene Datenträger, nicht autorisierte Momentaufnahmen oder kompromittierte Host-Agents verfügbar gemacht werden.

Lösungsansatz:

• Aktivieren Sie die Verschlüsselung auf Hostebene für Azure-VMs: Registrieren Sie die EncryptionAtHost-Funktion auf Abonnementebene. Aktivieren Sie die Verschlüsselung auf Hostebene für VMs mithilfe unterstützter VM-Größen (DSv3, Easv4, Dadsv5-Serien). Die Verschlüsselung umfasst temporäre Datenträger, den Cache der Betriebssystem-Datenträger, den Cache der Datenträger und flüchtige Betriebssystem-Datenträger.
• Infrastrukturverschlüsselung (doppelte Verschlüsselung) für Azure Storage aktivieren: Stellen Sie sicher, dass die Azure Storage Service Encryption (SSE) aktiviert ist (standardmäßig eingeschaltet—AES-256-Verschlüsselung), für sensible Storage-Konten aktivieren Sie die Infrastrukturverschlüsselung während der Erstellung des Storage-Kontos (kann nach der Erstellung nicht mehr aktiviert werden), Ergebnis: zwei Schichten von AES-256-Verschlüsselung mit unterschiedlichen Schlüsseln.
• Bereitstellung von Azure vertraulichen VMs für streng regulierte Workloads: Wählen Sie die entsprechende Serie vertraulicher VMs (DCasv5/DCadsv5-Serie für AMD SEV-SNP oder ECasv5/ECadsv5-Serie für Intel TDX), aktivieren Sie die Verschlüsselung vertraulicher Datenträger mit einem plattformverwalteten Schlüssel (bindet die Datenträgerverschlüsselungsschlüssel an das virtuelle TPM der VM), aktivieren Sie Secure Boot und vTPM zur Beglaubigung, und bereitstellen für Workloads, die exportkontrollierte technische Daten oder streng regulierte PII verarbeiten, bei denen Daten während der Verarbeitung verschlüsselt bleiben müssen.
• Implementieren Sie Always Encrypted für sensible Datenbanksäulen: Identifizieren Sie stark sensible Spalten in der Azure SQL-Datenbank, die eine Verschlüsselung auf Spaltenebene erfordern (z. B. SSN, Kreditkartennummer, Krankenaktennummer). Generieren Sie Spaltenverschlüsselungsschlüssel (CEK) und Spaltenmaster-Schlüssel (CMK), wobei der CMK im Azure Key Vault gespeichert wird. Der CEK verschlüsselt die Datenspalten, und der CMK verschlüsselt den CEK. Aktivieren Sie Always Encrypted mit sicheren Enklaven (Intel SGX), um umfangreichere Abfragen zu verschlüsselten Daten zu ermöglichen. Verschlüsseln Sie sensitive Spalten mit deterministischer Verschlüsselung (für Gleichheitsabfragen) oder mit randomisierter Verschlüsselung (für maximale Sicherheit). Konfigurieren Sie die Anwendungsverbindungszeichenfolgen, indem Sie die Spaltenverschlüsselungseinstellung=Aktiviert festlegen, um eine transparente Verschlüsselung/Entschlüsselung zu gewährleisten.
• Inventory-Verschlüsselungskonfigurationen mit Azure Resource Graph: Abfrage des Verschlüsselungsstatus für VMs ohne Verschlüsselung am Host und Speicherkonten ohne Infrastrukturverschlüsselung, Exportieren von Ergebnissen in CSV und Zuweisen von Korrekturaufgaben an Ressourcenbesitzer.

Ergebnis: Verschlüsselung am Host hat Compliance-Lücken behoben, bei denen temporäre Daten auf dem Datenträger zuvor unverschlüsselt waren. Engineering-Dateien, die durch Infrastrukturverschlüsselung mit zwei Verschlüsselungsebenen geschützt sind. Vertrauliche VMs stellten sicher, dass exportgesteuerte Daten auch von Cloudadministratoren verschlüsselt blieben. Always Encrypted-geschützte vertrauliche Datenbankspalten – Datenbankadministratoren bestätigten, dass sie nicht in der Lage sind, Klartext aus verschlüsselten Spalten zu lesen, wodurch die Compliance-Anforderungen erfüllt werden.

Kritischitätsstufe

Unverzichtbar.

Steuerelementzuordnung

• CIS-Kontrollen 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: Bei Bedarf die Option eines kundenseitig verwalteten Schlüssels für die Verschlüsselung ruhender Daten verwenden.

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-5.

Sicherheitsprinzip

Verwenden Sie von Kunden verwaltete Schlüssel, wenn regulatorische Compliance-Anforderungen, Vertragsanforderungen oder die Empfindlichkeit der Daten eine direkte Kontrolle über den Lebenszyklus von Verschlüsselungsschlüsseln erfordern, einschließlich Schlüsselgenerierung, Rotation und Widerrufsbefugnis. Stellen Sie sicher, dass die richtigen Schlüsselverwaltungsprozesse vorhanden sind, um den Betriebsaufwand zu bewältigen.

Risiko mindern

Die ausschließliche Verwendung von dienstverwalteten Schlüsseln, bei denen Regulierung, vertragliche oder Trennungsversicherungen die Mandantensteuerung erfordern, führt zu Compliance- und Konzentrationsrisiken. Ohne ordnungsgemäß geregelte vom Kunden verwaltete Schlüssel (CMK):

• Unzureichende regulierungsrechtliche Sicherheit: Prüfer können Nachweise für kryptografische Kontrolle ablehnen, wenn die Schlüsselverwahrung, Drehungsrhythmus oder Widerrufsbehörde nicht nachgewiesen werden kann.
• Sperrlatenz: Die Unfähigkeit, kompromittierte Plattformschlüssel schnell zu widerrufen oder zu rotieren, verlängert den Gefährdungszeitraum nach Vorfällen bei Anmeldedaten oder in der Lieferkette.
• Jurisdiktionsexposition: Datenhoheitsmandanten können mandantengesteuerte oder HSM-gesicherte Schlüssel erfordern – das Fehlen beeinträchtigt die regionale Bereitstellungsfähigkeit.
• Mandantenübergreifender Strahlradius: Die Kompromittierung von Mehrinstanzenplattform-Schlüsseln kann sich auf umfassende Datasets auswirken, wenn die kryptografische Isolierung nicht ausreicht.
• Schattenverbreitung: Ad-hoc-Bereitstellungen von CMKs ohne Lebenszyklus-Governance führen zu veralteten, verwaisten oder schwachen Schlüsseln.
• Operative Fragilität: Fehler bei der Automatisierung der Rotation oder fehlende Zuordnung von Abhängigkeiten verursacht Anwendungsausfälle während des Schlüsselwechsels.

Die nicht ordnungsgemäße oder ausgelassene CMK-Verwendung schwächt die kryptografische Zuverlässigkeit und untergräbt die strategische Compliancepositionierung für sensible Workloads.

MITRE ATT&CK

• Zugriff auf Anmeldeinformationen (TA0006): Ungeschützte Anmeldeinformationen (T1552), die durch schwach gesicherte oder nicht ordnungsgemäß segmentierte Plattformschlüssel verfügbar gemacht werden.
• Auswirkung (TA0040): Daten, die zur Beeinflussung verschlüsselt wurden (T1486), indem die CMK-Rotation/Rücknahme missbraucht wird, um Daten unzugänglich zu machen.
• Auswirkung (TA0040): Datenmanipulation (T1565) durch Ändern der Verschlüsselungsstatusmetadaten, um Schutzebenen zu desynchronisieren.
• Exfiltration (TA0010):: Übertragen von Daten in ein Cloudkonto (T1537) zum erneuten Verschlüsseln und Exportieren von Datasets in den vom Angreifer kontrollierten Speicher.
• Exfiltration (TA0010): Exfiltration über Webdienste (T1567) orchestrieren hochvolumige, schlüsselfähige Massenexporte unter normalen Dienstmustern.

DP-5.1: Verwenden Sie die vom Kunden verwaltete Schlüsseloption für die Verschlüsselung ruhender Daten, wenn erforderlich.

Implementieren von vom Kunden verwalteten Schlüsseln, wenn behördliche Vorschriften, Datenhoheitsmandate oder vertragliche Verpflichtungen eine direkte Kontrolle über die Verwahrung von Verschlüsselungsschlüsseln, Rotationszeitpläne und Widerrufsbehörde erfordern. Implementieren Sie für Workloads, die höchste Kontrolle erfordern, bei der selbst Microsoft keine Daten entschlüsseln kann, die Doppelschlüsselverschlüsselung (DKE), indem Ihre Organisation einen zweiten Verschlüsselungsschlüssel außerhalb von Azure verwaltet. Verwenden Sie Azure Key Vault oder verwaltete HSM, um kryptografische Kontrolle aufrechtzuerhalten und gleichzeitig die operative Komplexität des Schlüssellebenszyklusmanagements, die Notfallwiederherstellungsplanung und potenzielle Auswirkungen auf die Dienstverfügbarkeit durch Schlüsselverwaltungsfehler abzuwägen.

Bewerten sie CMK-Anforderungen und stellen Sie schlüsselinfrastruktur bereit:

• Bewerten Sie behördliche, Compliance- oder Geschäftsanforderungen, um zu bestimmen, welche Workloads vom Kunden verwaltete Schlüssel (CMK) anstelle von plattformverwalteten Schlüsseln benötigen. Häufige Faktoren sind Datenhoheit, Prüfanforderungen oder vertragliche Verpflichtungen für die direkte Schlüsselverwahrung.
• Stellen Sie Azure Key Vault (Standard oder Premium) oder Azure Key Vault Managed HSM bereit, um vom Kunden verwaltete Verschlüsselungsschlüssel zu speichern und zu verwalten. Verwenden Sie verwaltetes HSM für Workloads, die FIPS 140-3 Level 3-validierten Hardwareschutz erfordern.
• Generieren Sie Verschlüsselungsschlüssel in Azure Key Vault mithilfe der Key-Generation-Funktionen, oder importieren Sie Schlüssel aus lokalen HSMs mithilfe von Bring Your Own Key (BYOK) für maximale Portabilität und Kontrolle.

Konfigurieren Sie CMK, und richten Sie die Schlüsselhierarchie ein:

• Implementieren Sie für extreme Kontrollanforderungen Double Key Encryption (DKE) bei denen vertrauliche Dokumente zwei Schlüssel für die Entschlüsselung benötigen: eine, die von Microsoft (Azure RMS) verwaltet wird, und einen zweiten Schlüssel, der ausschließlich von Ihrer Organisation lokal oder in Ihrem eigenen externen Schlüsselverwaltungsdienst verwaltet wird. Mit DKE können Microsoft Ihre Daten nicht entschlüsseln, auch wenn sie durch einen rechtlichen Prozess gezwungen wurden, während Sie den zweiten schlüssel steuern, der für die Entschlüsselung erforderlich ist.
• Konfigurieren Sie Azure Dienste (Azure Storage, Azure SQL-Datenbank, Azure Cosmos DB, Azure Disk Encryption usw.), um CMK zu verwenden, indem Sie auf den Key Vault Schlüssel-URI verweisen. Aktivieren Sie automatische Schlüsseldrehungsrichtlinien , um den manuellen Betriebsaufwand zu verringern.
• Richten Sie eine Schlüsselverschlüsselungshierarchie mit einem Schlüsselverschlüsselungsschlüssel (KEK) und einem Datenverschlüsselungsschlüssel (DEK) ein, bei der der KEK (gespeichert in Key Vault) den DEK (von Diensten verwendet) verschlüsselt, um die Auswirkungen der Schlüsselrotation auf die Verfügbarkeit der Dienste zu minimieren.
• Dokumentieren Sie wichtige Lebenszyklusprozesse, einschließlich Schlüsselrotationsplänen, Sperrabläufen für kompromittierte Schlüssel, Schlüsselstilllegungs-Workflows und Notfallwiederherstellungsverfahren. Integrieren Sie die Schlüsselverwaltung in Ihre Organisationsänderungsmanagementprozesse.

Anmerkung: Kundenverwaltete Schlüssel erfordern fortlaufende operative Investitionen, einschließlich Schlüssellebenszyklusverwaltung, Zugriffssteuerungsverwaltung, Überwachung und Notfallwiederherstellungsplanung. Stellen Sie vor der Einführung von CMK eine betriebsbereite Bereitschaft sicher, da die fehlerhafte Schlüsselverwaltung zu einer nicht verfügbaren Daten oder zu Verlusten führen kann.

Beispiel für die Implementierung

Ein reguliertes Finanzinstitut hat kundenverwaltete Schlüssel (CMK) über Azure Dienste hinweg bereitgestellt, um regulatorische Anforderungen für die direkte kryptografische Kontrolle über Handelsdaten und Kundenfinanzdaten zu erfüllen.

Herausforderung: Regulatorische Prüfer verlangten den Nachweis über kryptografische Kontrollmaßnahmen, einschließlich Schlüsselverwaltung, Rotationsberechtigung und Widerrufsfähigkeit. Vom Dienst verwaltete Schlüssel lieferten keine Nachweise für den von Mandanten gesteuerten Schlüssellebenszyklus. Ohne vom Kunden verwaltete Schlüssel fehlte es der Organisation, den Zugriff während Sicherheitsvorfällen schnell zu widerrufen und die Anforderungen an die Datenhoheit für regionale Bereitstellungen nicht zu erfüllen.

Lösungsansatz:

• Provisionieren Sie ein verwaltetes Azure Key Vault HSM: Erstellen Sie ein verwaltetes HSM (FIPS 140-3 Level 3 validiert) mit mindestens 3 HSM-Partitionen für hohe Verfügbarkeit, Aktivieren Sie das verwaltete HSM, indem Sie die Sicherheitsdomäne mit Quorumschlüsseln exportieren (aufgeteilt in Schlüsselfragmente, die in geografisch verteilten Offlinetresoren gespeichert sind), Generieren Sie Verschlüsselungsschlüssel (RSA-4096 mit dem Namen KEK-Prod-2024) mit Schlüsseloperationen: Schlüssel umwickeln, Schlüssel abwickeln, Verschlüsseln, Entschlüsseln.
• Configure vom Kunden verwaltete Schlüssel für Azure Services: Wenn Sie Azure Storage Speicherkonto für die Verwendung des CMK-Verschlüsselungstyps konfigurieren möchten, wählen Sie Key Vault Managed HSM als Schlüsselquelle aus, aktivieren Sie die vom Benutzer zugewiesene verwaltete Identität mit Managed HSM Crypto Service Encryption User role; für Azure SQL-Datenbank konfigurieren Sie die SQL-Datenbank so, dass der vom Kunden verwaltete Schlüssel als TDE-Schutz verwendet wird, wählen Sie Schlüssel aus verwaltetem HSM aus, aktivieren Sie die automatische Schlüsselrotation; für Azure Cosmos DB kundenverwaltete Schlüssel für das Cosmos DB-Konto aktivieren, verwalteten HSM-Schlüssel auswählen, der Cosmos DB verwalteten Identitätszugriff gewähren.
• Implementieren Sie die automatisierte Schlüsselrotation: Konfigurieren Sie die Rotationsrichtlinie mit einer Rotationsfrequenz von 90 Tagen, aktivieren Sie die automatische Rotation, konfigurieren Sie die Ablaufbenachrichtigung (Warnung 7 Tage vor Ablauf), und erstellen Sie eine Azure Monitor-Warnung für die Metrik "Key Near Expiry", um das Sicherheitsteam zu benachrichtigen.
• Aktivieren Sie die Audit-Protokollierung zur Einhaltung der Vorschriften: Aktivieren Sie die Diagnoseprotokollierung für Managed HSM (AuditEvent-Protokolle), senden Sie Protokolle an den Log Analytics-Arbeitsbereich mit unveränderbarem Speicher (90-tägige Aufbewahrung für manipulationssichere Audit-Trails), um Schlüsselzugriffsprotokolle zu überwachen und Vorgänge wie Verschlüsselung, Entschlüsselung, Schlüsselverpackung und Schlüsselentpackung zu überwachen.
• Verfahren für den Dokumentschlüssellebenszyklus: Erstellen Sie Runbooks für notfallsperren (Schlüsselsperrschritte, Kontakte zur Reaktion auf Vorfälle, Wiederherstellungsverfahren mithilfe von Quorumschlüsseln der Sicherheitsdomäne), testen Sie Runbooks vierteljährlich über Tabletop-Übungen, integrieren Sie CMK-Vorgänge in den Genehmigungsworkflow für IT-Dienstverwaltung.

Outcome: RSA-4096 KEKs in Managed HSM verschlüsseln Service-Level-DEKs für Azure Storage, SQL-Datenbank und Cosmos DB. Die vierteljährliche automatische Rotation minimiert Ausfallzeiten, indem nur DEKs neu verschlüsselt werden. Das Quorum der Sicherheitsdomäne stellt die Notfallwiederherstellung auch bei einem vollständigen regionalen Ausfall sicher.

Kritischitätsstufe

Sollte vorhanden sein

Steuerelementzuordnung

• CIS-Kontrollen 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: Verwenden eines Sicheren Schlüsselverwaltungsprozesses

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-6.

Sicherheitsprinzip

Implementieren Sie sichere Schlüsselverwaltungsprozesse, die den vollständigen Schlüssellebenszyklus steuern: Erzeugung, Verteilung, Speicherung, Rotation und Widerruf. Verwenden Sie dedizierte Schlüsseltresordienste mit starken Zugriffskontrollen, verwalten Sie Kryptografiestandards, erzwingen Sie die Trennung von Aufgaben, und stellen Sie sicher, dass Schlüssel regelmäßig rotiert und bei Kompromittierung umgehend widerrufen werden.

Risiko mindern

Schwache oder nicht verwaltete Kryptografieschlüssellebenszyklus beeinträchtigen die durch Verschlüsselung bereitgestellte Sicherheit und können systemische Kompromittierungen ermöglichen. Ohne strukturierte Schlüsselgenerierung, Rotation, Schutz und Widerruf:

• Schlüsselverteilung & Verwaisung: Nicht nachverfolgte Schlüssel bleiben über den geschäftlichen Bedarf hinaus bestehen und behalten eine unbeabsichtigte Entschlüsselungsautorität.
• Veraltete Kryptografie: Seltene Erneuerung erhöht die Exposition gegenüber algorithmischer Herabstufung, Brute-Force- oder Side-Channel-Fortschritten.
• Berechtigungsüberschreibung: Wenn keine Rollentrennung besteht, können Administratoren Schlüssel sowohl verwalten als auch verwenden, wodurch Insider-Missbrauch ermöglicht wird.
• Nicht erkannte Kompromittierung: Keine Integritätsüberwachung oder Versionslinie verdeckt, ob Schlüssel böswillig ersetzt wurden.
• Fehlgeschlagener Widerruf: Die Reaktion auf Vorfälle kann nach einem vermuteten Sicherheitsverstoß den Datenzugriff kryptografisch nicht einschränken.
• Inkonsistente Hierarchie: Fehlende KEK/DEK-Schichtung multipliziert drehungsstrahlradius und erhöht betriebsbedingte Ausfallzeiten.

Die fehlerhafte Schlüsselverwaltung wandelt die Verschlüsselung in eine Punkt-in-Time-Kontrolle um, anstatt eine nachhaltige Risikominderung gegen sich entwickelnde Bedrohungen zu gewährleisten.

MITRE ATT&CK

• Zugriff auf Anmeldeinformationen (TA0006): Anmeldeinformationen aus Kennwortspeichern (T1555), Extraktion von unsachgemäß gespeicherten oder zwischengespeicherten Schlüsselmaterien, oder die Ausnutzung von gültigen Konten (T1078), indem RBAC-Rollen der umfassenden Schlüsselverwaltung ausgenutzt werden, um unberechtigt auf Schlüssel zuzugreifen oder sie zu ändern.
• Defense Evasion (TA0005): Schwächung der Verschlüsselung (T1600) durch Beibehaltung nicht mehr empfohlener Algorithmen und unzureichender Schlüsselgrößen, um die kryptografische Stärke zu verringern.
• Auswirkung (TA0040): Datenverlust (T1485) durch Auslösen zerstörerischer Löschvorgänge oder fehlerhaft behandelte Widerrufsereignisse.
• Auswirkung (TA0040): Datenmanipulation (T1565) ersetzt oder ändert Schlüsselversionen, um Verschlüsselungsflüsse umzuleiten oder zu deaktivieren.

DP-6.1: Einrichten von Schlüsselverwaltungsrichtlinien und -infrastruktur

Erstellen Sie eine Governance-Grundlage für die Verwaltung kryptografischer Schlüssel, indem Sie den zentralen Schlüsselspeicher einrichten, kryptografische Standards definieren und geeignete Schutzstufen basierend auf der Workloadempfindlichkeit auswählen. Stellen Sie Azure Key Vault als einzige Wahrheitsquelle für wichtige Vorgänge bereit, während Sie umfassende Überwachungsprotokollierung implementieren, um alle wichtigen Zugriffs- und Verwaltungsänderungen für Compliance- und forensische Zwecke nachzuverfolgen.

Zentrale Schlüsselverwaltungsinfrastruktur einrichten:

• Verwenden Sie Azure Key Vault als zentralen Kryptografieschlüsselverwaltungsdienst, um den vollständigen Schlüssellebenszyklus zu steuern: Generierung, Verteilung, Speicherung, Rotation und Sperrung.
• Definieren und Erzwingen von Schlüsselrichtlinien , die die mindesten kryptografischen Standards angeben:
  • Schlüsseltyp: RSA (empfohlen: mindestens 4096-Bit oder 3072-Bit) oder EC (P-256, P-384, P-521-Kurven).
  • Wichtige Vorgänge: Beschränken Sie zulässige Vorgänge (Verschlüsseln, Entschlüsseln, Signieren, Verifizieren, Verpacken, Entpacken) basierend auf dem Prinzip der minimalen Rechte.
  • Gültigkeitsdauer: Legen Sie Aktivierungs- und Ablaufdaten fest, um die zeitgebundene Schlüsselverwendung zu erzwingen.

Wählen Sie die entsprechende Key Vault-Ebene aus:

• Wählen Sie die entsprechende Key Vault Ebene basierend auf den Sicherheits- und Complianceanforderungen Ihrer Workload aus:
  • Softwaregeschützte Schlüssel (Standard & Premium SKUs): FIPS 140-2 Level 1 überprüft
  • HSM-geschützte Schlüssel (Premium-SKU): FIPS 140-2 Level 2 überprüft (gemeinsam genutztes HSM-Back-End mit mehreren Mandanten)
  • Verwaltetes HSM: FIPS 140-3 Level 3 validiert (dedizierter Einzelmandant-HSM-Pool)
• Verwenden Sie für erhöhte Sicherheit Azure Key Vault Managed HSM für single-tenant, FIPS 140-3 Level 3 validierten HSM-Schutz. Verwaltetes HSM unterstützt kryptografische Domäne für Sicherung und Notfallwiederherstellung.
• Konfigurieren Sie Azure Key Vault Protokollierung und leiten Sie Protokolle an Azure Monitor oder Microsoft Sentinel weiter, um alle wichtigen Zugriffs-, Rotationsereignisse und administrativen Vorgänge für Überwachungs- und Compliancezwecke nachzuverfolgen.

DP-6.2: Implementieren der Schlüssellebenszyklusautomatisierung

Automatisieren Sie die Schlüsseldrehung, und richten Sie Schlüsselhierarchien ein, um den Betriebsaufwand zu reduzieren, menschliche Fehler zu minimieren und den schnellen Austausch von Schlüsseln ohne Dienstunterbrechung zu ermöglichen. Implementieren Sie KEK/DEK-Muster, die eine effiziente Rotation ermöglichen, indem sie kleine Schlüsselbündel statt ganzer Datensätze erneut verschlüsseln, und integrieren Sie Verfahren zur Notfallwiederherstellung, um die Schlüsselverfügbarkeit bei regionalen Ausfällen oder katastrophalen Ereignissen aufrechtzuerhalten.

Implementieren der automatisierten Schlüsseldrehung:

• Implementieren Sie automatierte Schlüsseldrehungrichtlinien in Azure Key Vault:
  • Konfigurieren Sie die Drehfrequenz basierend auf Complianceanforderungen (allgemeine Intervalle: 90 Tage, 180 Tage oder jährlich).
  • Aktivieren Sie Rotationsbenachrichtigungen, um die Operationsteams vor Ablauf des Schlüssels zu benachrichtigen.
  • Konfigurieren Sie die automatische Drehung, um neue Schlüsselversionen ohne manuelle Eingriffe zu generieren.

Einrichten der Schlüsselhierarchie und BYOK:

• Einrichten einer Schlüsselhierarchie , die Schlüsselverschlüsselungsschlüssel (KEY Encryption Keys, KEK) und Datenverschlüsselungsschlüssel (DATA Encryption Keys, DEK) trennt:
  • Speichern Sie KEKs in Azure Key Vault mit eingeschränkten Zugriffssteuerungen.
  • Generieren Sie Dienstebene-DEKs, die durch KEKs verschlüsselt sind, und minimieren Sie so den Wirkungskreis der Schlüsselrotation.
  • Die Rotation des KEK erfordert nur die erneute Verschlüsselung von DEKs (nicht ganzer Datasets), wodurch eine effiziente Schlüsseldrehung ohne Ausfallzeiten ermöglicht wird.
• Generieren Sie für Bring Your Own Key (BYOK) Szenarien Schlüssel in lokalen FIPS 140-2 Level 2+ HSMs und verwenden sie den BYOK-Übertragungsschlüsselmechanismus, um Schlüssel sicher in Azure Key Vault oder verwaltetes HSM zu importieren, wobei kryptografische Nachweise für Schlüsselursprung und -verwahrung beibehalten werden.

Implementieren von Notfallwiederherstellungsverfahren:

• Erstellen Sie geo-replizierte Schlüsseltresore in sekundären Regionen.
• Sichern und Wiederherstellen von Schlüsseln, um die Schlüsselverfügbarkeit in allen Regionen aufrechtzuerhalten.
• Dokumentieren und testen Sie Notfallwiederherstellungsverfahren mit definierten RTO/RPO-Zielen.

DP-6.3: Erzwingen der Trennung von Aufgaben für den Schlüsselzugriff

Verhindern Sie Insider-Bedrohungen und Berechtigungsmissbrauch, indem Sie Schlüsselverwaltungsrollen von kryptografischen Vorgangsrollen trennen und sicherstellen, dass keine einzelne Identität Schlüssel erstellen und für die Datenverschlüsselung oder Entschlüsselung verwenden kann. Implementieren Sie kontinuierliche Überwachung, um anomale Schlüsselzugriffsmuster zu erkennen und umfassende Schlüsselinventaren aufrechtzuerhalten, die eine schnelle Folgenabschätzung bei Sicherheitsvorfällen oder Compliance-Audits ermöglichen.

Erzwingen der Aufgabentrennung:

• Implementieren Sie rollenbasierte Zugriffssteuerung (RBAC) oder Zugriffsrichtlinien, um die Trennung von Aufgaben zu erzwingen:
  • Separate Rollen für Schlüsseladministratoren (die Schlüssel erstellen/drehen/löschen können, aber keine kryptografischen Vorgänge ausführen können ).
  • Separate Rollen für Schlüsselbenutzer (die Verschlüsselungs-/Entschlüsselungsvorgänge ausführen können, aber keine Schlüssel verwalten können ).
  • Beispielrollen: Key Vault Crypto Officer (Administratoren), Key Vault Crypto User (Anwendungen/Benutzer).
• Vergewissern Sie sich, dass keine einzelne Identität sowohl über Administrator- als auch Überbetriebsschlüsselzugriff verfügt, um Rechtemissbrauch zu verhindern.

Überwachen des Schlüsselzugriffs und Verwalten des Inventars:

• Integrieren Sie die Schlüsselzugriffsüberwachung in Microsoft Sentinel, um Anomalien zu erkennen:
  • Ungewöhnliche Zugriffsmuster (Zugriff von unbekannten IP-Adressen oder Regionen).
  • Massen-Schlüsseloperationen (übermäßige Operationen in kurzen Zeiträumen).
  • Änderungen an Verwaltungseinstellungen außerhalb der Geschäftszeiten (z. B. Löschen oder Rotieren von Schlüsseln).
• Verwalten Sie ein Schlüsselinventar, das den Schlüsselnamen, den Zweck, den Rotationszeitplan und die abhängigen Services umfasst. Überprüfen Sie das Inventar regelmäßig während Sicherheitsüberprüfungen.

Beispiel für die Implementierung

Ein SaaS-Anbieter im Gesundheitswesen zentralisierte die Verwaltung der kryptografischen Schlüssel mithilfe von Azure Key Vault Premium SKU mit HSM-geschützten Schlüsseln zur Verschlüsselung von medizinischen Daten (PHI) auf ihrer Multi-Tenancy-Plattform.

Herausforderung: Fragmentierte Schlüsselverwaltung unter den Entwicklungsteams führte zu Schlüsselausbreitung, inkonsistenter Rotation und Schwierigkeiten beim Nachverfolgen der Nutzung von Schlüsseln während Sicherheitsvorfällen. Zu weit gefasste RBAC-Berechtigungen ermöglichten Administratoren sowohl das Verwalten als auch das Verwenden von Schlüsseln, und führten zu einem Insider-Risiko. Ohne automatisierte Rotation und Trennung von Aufgaben sah sich die Organisation mit verlängerten Zeiträumen der Schlüsselkompromittierung und Compliance-Fehlern konfrontiert.

Lösungsansatz:

• Provision Azure Key Vault Premium mit HSM-geschützten Schlüsseln: Erstellen Sie einen Azure Key Vault mit Premium-Stufe, um HSM-geschützte Schlüssel zu unterstützen. Aktivieren Sie den Löschschutz, um die dauerhafte Löschung während des Aufbewahrungszeitraums zu verhindern, und aktivieren Sie "Soft Delete" mit einer 90-tägigen Aufbewahrungsfrist, um die Wiederherstellung von versehentlich gelöschten Schlüsseln zu ermöglichen. Generieren Sie RSA-3072 HSM-geschützte Verschlüsselungsschlüssel (KEK-PHI-Prod) mit hardwaregesichertem Schlüsseltyp.
• Implement automatisierte Schlüsseldrehungsrichtlinien: Drehungsrichtlinie mit 180-Tage-Drehungshäufigkeit konfigurieren, automatische Drehung aktivieren und Benachrichtigungen festlegen, um 30 Tage vor Ablauf zu benachrichtigen, erstellen Sie Azure Monitor Aktionsgruppen, um das Sicherheitsbetriebsteam zu benachrichtigen, wenn der Ablauf von Schlüsseln erfolgt, konfigurieren Sie die Drehungsaktion, um automatisch neue Schlüsselversionen zu generieren.
• Konfigurieren Sie die RBAC-Trennung von Aufgaben: Weisen Sie der Key Vault Crypto Officer-Rolle Mitglieder des Sicherheitsteams zu (Berechtigungen: Verwalten des Schlüssellebenszyklus, kann jedoch keine Verschlüsselungs-/Entschlüsselungsvorgänge ausführen), weisen Sie die Key Vault Krypto-Benutzerrolle anwendungsverwalteten Identitäten zu (Berechtigungen: nur Verschlüsselungs-/Entschlüsselungsvorgänge ohne Schlüsselverwaltungsberechtigungen), stellen Sie sicher, dass die Trennung der Aufgaben gewährleistet ist, indem Sie sicherstellen, dass keine Identität sowohl über die Rolle des Crypto Officers als auch des Crypto Users verfügt.
• Establishment einer KEK/DEK-Hierarchie für schnelle Schlüsselrotation: Generierung von Data Encryption Keys (DEKs) auf Anwendungsebene innerhalb des Anwendungscodes (AES-256-Schlüssel) zur Verschlüsselung von Patientendaten. Verschlüsselte DEKs werden neben den verschlüsselten Daten gespeichert. Key Vault KEK wird verwendet, um DEKs über die WrapKey-Operation zu verschließen/verschlüsseln. DEKs werden mithilfe der UnwrapKey-Operation abgerufen und entpackt, wenn Patientendaten entschlüsselt werden. Vorteil: Das Rotieren des KEK erfordert nur das erneute Verschlüsseln der DEKs anstelle der gesamten Patientendatenbank.
• Integrieren Key Vault Protokolle mit Microsoft Sentinel: Diagnoseeinstellungen für Key Vault aktivieren und Protokolle an Log Analytics Arbeitsbereich senden, Sentinel-Analyseregeln erstellen, um ungewöhnliche Zugriffsmuster, Massenschlüsselvorgänge, Administrative Änderungen außerhalb der Stunden zu erkennen.
• Bring Your Own Key (BYOK)-Übertragung vom lokalen HSM: Laden Sie den BYOK-Übertragungsschlüssel aus dem Key Vault herunter, exportieren Sie den Schlüssel vom lokalen HSM, der mit dem öffentlichen BYOK-Übertragungsschlüssel des Key Vaults ummantelt ist, bewahren Sie den kryptografischen Nachweis der Schlüsselherkunft auf und importieren Sie den ummantelten Schlüssel in das Key Vault, wo er HSM-geschützt ohne Offenlegung im Klartext ankommt.

Ergebnis: RSA-3072-Schlüssel werden alle 180 Tage gewechselt mit automatisierten Benachrichtigungen. RBAC-Trennung verhindert Berechtigungsmissbrauch. KEK/DEK-Hierarchie ermöglicht eine schnelle Umschlüsselung, indem nur DEKs neu verschlüsselt werden. Vorläufiges Löschen stellt versehentlich gelöschte Schlüssel wieder her. Microsoft Sentinel erkennt Anomalien wie unbekannten IP-Zugriff oder Änderungen außerhalb der Stunden.

Kritischitätsstufe

Unverzichtbar.

Steuerelementzuordnung

• CIS-Kontrollen v8.1: N/A
• 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: Verwenden eines sicheren Zertifikatverwaltungsprozesses

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-7.

Sicherheitsprinzip

Verwalten Sie Zertifikatlebenszyklus über zentralisierte Prozesse, die Bestands-, automatisierte Erneuerungs-, starke kryptografische Standards und einen zeitnahen Widerruf umfassen. Stellen Sie sicher, dass Zertifikate für kritische Dienste vor ablauf nachverfolgt, überwacht und erneuert werden, um Dienstunterbrechungen zu verhindern und sichere verschlüsselte Kommunikation aufrechtzuerhalten.

Risiko mindern

Schlecht geregelte Zertifikatlebenszyklus verursachen Dienstausfälle, schwächt verschlüsselte Kanäle und erlauben den Identitätswechsel. Ohne zentralisiertes Inventar, Richtlinienerzwingung und automatisierte Erneuerung:

• Unerwartete Ablaufzeiten: Abgelaufene Zertifikate lösen Produktionsausfälle aus, unterbrechen APIs, Identitätsverbund oder Clientvertrauenspfade.
• Schwache Kryptografiepersistenz: Ältere Schlüsselgrößen/Signaturalgorithmen (z. B. SHA-1, RSA < 2048) bleiben über die Veraltetkeit hinaus in Gebrauch.
• Wildcard- und selbstsignierter Missbrauch: Breit gefächerte oder nicht verwaltete selbstsignierte Zertifikate ermöglichen laterale Nachahmung und ein Risiko für TLS-Downgrade.
• Nicht erkannte Kompromittierung: Gestohlene private Schlüssel ermöglichen eine unbemerkte Man-in-the-Middle-Angriff oder Datenverkehrsentschlüsselung bis zur Rotation.
• Schattenzertifikate: Nicht genehmigte Ausstellung außerhalb genehmigter CAs fragmentiert die Governance und erhöht die Anzahl der unbeachteten Sperrstellen.
• Manuelle Verlängerungsfehler: Inkonsistente Ersatzsequenzierung führt zu Vertrauenskettenkonflikten und teilweisen Umgebungsabweichungen.

Die fehlerhafte Zertifikatverwaltung beeinträchtigt verschlüsselte Sicherheit und führt sowohl zu Zuverlässigkeit als auch zu Sicherheitsinstabilität in kritischen Diensten.

MITRE ATT&CK

• Defense Evasion (TA0005): Vertrauensteuerungen untergraben (T1553) durch die Ausstellung oder Einführung von betrügerischen oder manipulativen Zertifikaten zur Umgehung der Validierung.
• Ressourcenentwicklung (TA0042): Entwickeln von Funktionen (T1587) zum Schmieden von Zertifikaten oder Tools für zukünftige Angriffsphasen.
• Verteidigungshinterziehung (TA0005): Schwächung der Verschlüsselung (T1600) durch die fortgesetzte Verwendung veralteter Signaturalgorithmen, wodurch die Prüfungssicherheit reduziert wird.
• Zugriffsberechtigung auf Anmeldeinformationen (TA0006): Nicht geschützte Anmeldeinformationen (T1552) mit Extraktion privater Schlüssel aus unsicheren Dateispeichern oder dem Prozessspeicher.
• Persistenz (TA0003): Ändern des Authentifizierungsprozesses (T1556) zum Umschreiben zertifikatbasierter Authentifizierungsflüsse zum Einbetten von langlebigem Zugriff.

DP-7.1: Einrichten von Zertifikatrichtlinien und Zertifizierungsstellenintegration

Definieren Sie Governance-Standards für Zertifikate und integrieren Sie vertrauenswürdige Zertifizierungsstellen, um eine konsistente kryptografische Qualität und automatisierte Ausstellung in Ihrer Infrastruktur sicherzustellen. Richten Sie Richtlinien ein, die moderne Schlüsselgrößen, Signaturalgorithmen und Gültigkeitszeiträume erzwingen und riskante Praktiken wie selbstsignierte Zertifikate und Wildcardzertifikate beseitigen, die Angriffsflächen erweitern, wenn private Schlüssel kompromittiert werden.

Einrichten der Zertifikatverwaltungsinfrastruktur:

• Verwenden Sie Azure Key Vault, um den vollständigen Zertifikatlebenszyklus zentral zu verwalten: Erstellung, Import, Erneuerung, Rotation, Sperrung und sichere Löschung.
• Definieren Sie certificate policies in Azure Key Vault, um Die Sicherheitsstandards der Organisation zu erzwingen:
  • Schlüsseltyp und -größe: RSA 2048-Bit-Mindestwert (empfohlen: 3072-Bit oder 4096-Bit für langlebige Zertifikate); EC P-256 oder höher für elliptische Kurvenzertifikate.
  • Signaturalgorithmus: SHA-256 oder stärker (verbieten SHA-1 und MD5).
  • Gültigkeitsdauer: Maximal 397 Tage für öffentliche TLS-Zertifikate (pro Ca/Browser Forum Basisanforderungen); kürzere Dauer (90 Tage) empfohlen für reduzierte Exposition.
  • Zertifizierungsstelle: Verwenden Sie nur genehmigte, integrierte CAs (DigiCert, GlobalSign) oder die private Zertifizierungsstelle Ihrer Organisation.

Integrieren von Zertifizierungsstellen:

• Verwenden Sie partnerbasierte Zertifizierungsstellen, die in Azure Key Vault für öffentliche TLS/SSL-Zertifikate integriert sind:
  • DigiCert: Durch die Organisation überprüfte TLS/SSL-Zertifikate (OV)
  • GlobalSign: Durch die Organisation überprüfte TLS/SSL-Zertifikate (OV)
• Integrieren Sie für private/interne Dienste die interne Zertifizierungsstelle Ihrer Organisation (z. B. Active Directory Zertifikatdienste – ADCS) in Azure Key Vault für die automatisierte Zertifikatausstellung.
• Vermeiden Sie selbstsignierte Zertifikate und Wildcardzertifikate in Produktionsumgebungen:
  • Selbstsignierte Zertifikate: Fehlende Überprüfung durch Drittanbieter, kann nicht über öffentliche CRL/OCSP widerrufen werden und werden von modernen Browsern/Clients abgelehnt.
  • Wildcardzertifikate: Ein breiter Umfang erhöht das Risiko, falls sie kompromittiert werden; Verwenden Sie stattdessen Subject Alternative Name (SAN) Zertifikate mit explizit angegebenen FQDNs.

Note: Für einfache Szenarien können Sie Azure App Service verwaltete Zertifikate (kostenlose, automatisch erneuerte Zertifikate für benutzerdefinierte Domänen) verwenden.

DP-7.2: Implementieren der automatisierten Zertifikatverlängerung

Vermeiden Sie Dienstausfälle, die durch abgelaufene Zertifikate verursacht werden, indem Sie Erneuerungsworkflows automatisieren, die lange vor dem Ablauf ausgelöst werden und Zertifikate nahtlos in abhängigen Diensten aktualisieren, ohne manuellen Eingriff. Konfigurieren Sie Azure Dienste so, dass automatisch erneuerte Zertifikate aus Key Vault mithilfe von verwalteten Identitäten abgerufen werden, wodurch die Betriebsbereitschaft reduziert und das Risiko vergessener manueller Erneuerungen während feiertagen oder Mitarbeiterübergängen beseitigt wird.

Konfigurieren der automatischen Erneuerung:

• Aktivieren Sie automatierte Zertifikaterneuerung in Azure Key Vault, indem Sie Lebensdaueraktionen konfigurieren, um die Verlängerung in einem bestimmten Prozentsatz der Zertifikatlebensdauer auszulösen:
  • Empfohlener Auslöser: 80-90% der Gültigkeitsdauer (z. B. ~318 Tage für 397-Tage-Zertifikat).
  • Aktion: Automatische Verlängerung (Key Vault fordert Verlängerung von der Zertifizierungsstelle ohne manuelle Intervention).
• Konfigurieren Sie Benachrichtigungskontakte, um Administratoren vor automatischen Verlängerungsauslösern vor bevorstehenden Zertifikatablaufen zu benachrichtigen.

Automatische Zertifikatbindung aktivieren:

• Konfigurieren Sie Azure-Dienste, die die automatische Zertifikatrotation unterstützen (Azure App Service, Azure Application Gateway, Azure Front Door), so, dass sie aktualisierte Zertifikate automatisch aus dem Key Vault mithilfe von verwalteten Identitäten oder Diensteprinzipalen und den entsprechenden Key Vault-Zugriffsrichtlinien abrufen.
  • Azure Dienste binden automatisch neue Zertifikatversionen, wenn sie erneuert werden (in der Regel innerhalb von 24 Stunden, kein Dienstneustart erforderlich).
• Implementieren Sie für Anwendungen, die Key Vault Zertifikate nicht automatisch nutzen können, manuelle Zertifikat-Rotationsworkflows mit betrieblichen Runbooks und Überwachungswarnungen, um durch Ablauf verursachte Ausfälle zu verhindern.
• Führen Sie eine Bestandsaufnahme aller Zertifikate in Azure Key Vault, indem Sie den Zertifikatsnamen, Zweck, das Ablaufdatum, die abhängigen Dienste und den Erneuerungsstatus nachverfolgen.

DP-7.3: Überwachen des Zertifikatlebenszyklus und Umgang mit dem Widerruf

Halten Sie kontinuierlichen Einblick in die Gesundheit der Zertifikate durch automatisierte Überwachung, Bestandsabfragen und Dashboards, die Zertifikate nahe ihrem Ablauf anzeigen, veraltete Kryptografie verwenden oder ohne ordnungsgemäße Governance sind. Richten Sie schnelle Sperrverfahren für kompromittierte Zertifikate ein und integrieren Sie sie in die Branchenbedrohungserkennung, um Zertifikate, die von kompromittierten Zertifizierungsstellen ausgestellt wurden, proaktiv zu blockieren, bevor sie Man-in-the-Middle-Angriffe ermöglichen.

Konfigurieren der Überwachung und Warnung:

• Konfigurieren sie Azure Monitor-Warnungen für Ablaufereignisse des Zertifikats:
  • Erstellen Sie Warnungen 30 Tage vor Ablauf (Warnbenachrichtigung).
  • Erstellen Sie Benachrichtigungen sieben Tage vor dem Ablauf (kritische Benachrichtigung mit Eskalation zum Sicherheitsteam).

Verwalten des Zertifikatbestands und der Dashboards:

• Verwenden Sie Azure Resource Graph, um den Zertifikatbestand abzufragen:
  • Zertifikate abfragen, die bald ablaufen (in 30/60/90 Tagen).
  • Selbstsignierte Zertifikate abfragen.
  • Abfragen von Zertifikaten mithilfe veralteter Algorithmen (z. B. SHA-1).
• Erstellen Von Zertifikatüberwachungsdashboards (z. B. Power BI) mit Visualisierungen:
  • Zeitplan für den Zertifikatsablauf je nach Zeitkategorie.
  • Selbstsignierte Zertifikate-Anzahl nach Ressourcengruppe.
  • Zertifikate, die veraltete kryptografische Standards verwenden.
• Überprüfen Sie Zertifikatsüberwachungs-Dashboards regelmäßig während der Sicherheitsüberprüfungsbesprechungen (empfohlen: vierteljährlich).

Einrichten von Widerrufsverfahren:

• Einrichten von Zertifikatsperrverfahren für kompromittierte oder eingestellte Zertifikate:
  • Dokumentsperrprozess (Zertifikat in Key Vault deaktivieren, abhängige Dienste benachrichtigen).
  • Verwalten Sie Runbooks für die Reaktion auf Vorfälle für Zertifikatkompromittierungsszenarien.
  • Überwachen Sie Industriehinweise auf kompromittierte Stamm- oder Zwischenzertifikate, und blockieren Sie sie umgehend.

Beispiel für die Implementierung

Ein Unternehmen mit 200+ öffentlich zugänglichen Webanwendungen zentralisierte Zertifikatlebenszyklus-Verwaltung unter Verwendung Azure Key Vault, das in DigiCert als Zertifizierungsstelle integriert ist.

Herausforderung: Manuelle Zertifikaterneuerungsprozesse verursachten mehrere Produktionsausfälle, wenn Zertifikate unerwartet abgelaufen sind. Wildcardzertifikate erzeugten einen übermäßigen Explosionsradius, wenn private Schlüssel kompromittiert wurden. Die fragmentierte Zertifikatverwaltung in allen Teams führte zu Schattenzertifikaten, inkonsistenten kryptografischen Standards und verzögerter Sperrung während Sicherheitsvorfällen. Ohne automatisierte Erneuerung und zentralisiertes Inventar ist die Organisation mit Compliancefehlern und Dienstunterbrechungen konfrontiert.

Lösungsansatz:

• Integrieren Sie eine Zertifizierungsstelle (Certificate Authority) mit Azure Key Vault: Fügen Sie DigiCert (oder eine andere Partner-Zertifizierungsstelle) dem Key Vault mit API-Zugangsdaten für automatisierte Zertifikatanforderungen hinzu.
• Zertifikatsrichtlinie erstellen, die Sicherheitsstandards erzwingt: Definieren Sie die Zertifikatsrichtlinie mit Zertifikatname (www-contoso-com-2024), Aussteller (DigiCert), Betreff (CN=www.contoso.com), DNS-Namen (SAN: www.contoso.com, api.contoso.com, portal.contoso.com – Vermeiden Sie Wildcardzertifikate), Schlüsseltyp (RSA 4096-Bits), Signaturalgorithmus (SHA-256), Gültigkeitsdauer (maximal 397 Tage gemäß CA/Browser Forum Baseline), Lebensdaueraktion für die automatische Verlängerung konfigurieren (Trigger bei 80% der Zertifikatslebensdauer setzen, ca. 318 Tage für ein 397-Tage-Zertifikat), Aktion: automatisch verlängern (Key Vault fordert Verlängerung von DigiCert ohne manuelle Intervention an).
• Konfigurieren Sie die automatische Zertifikatsbindung für Azure-Dienste: Für Azure App Service: Importieren Sie das Zertifikat aus dem Key Vault, weisen Sie eine vom Benutzer zugewiesene verwaltete Identität mit der Rolle "Key Vault Secrets Benutzer" zu, aktivieren Sie die automatischen Zertifikataktualisierungen (der App Service bindet die neue Zertifikatversion innerhalb von 24 Stunden nach der Erneuerung, ein Neustart ist nicht erforderlich); beim Azure Application Gateway den Listener so konfigurieren, dass das Zertifikat aus dem Key Vault abgerufen werden kann, die vom Benutzer zugewiesene verwaltete Identität mit den Rollen "Key Vault Secrets Benutzer" und "Zertifikatbenutzer" zuweisen, wobei das Anwendungsgateway automatisch aktualisierte Zertifikate abruft, wenn Key Vault diese erneuert.
• Zertifikatablaufwarnungen konfigurieren: Erstellen Sie zwei Warnungsregeln in Azure Monitor – 30-Tage-Ablaufwarnung (Benachrichtigung an den Plattform-Engineering-Slack-Kanal senden), 7-tägige kritische Ablaufwarnung (Jira-Ticket für die manuelle Überprüfung öffnen und E-Mails an das Sicherheitsteam senden).
• Wildcardzertifikate zugunsten von SAN-Zertifikaten beseitigen: Vorhandene Wildcardzertifikate (*.contoso.com) in Key Vault überprüfen, ersetzen durch SAN-Zertifikate, die explizite DNS-Namen enthalten (www.contoso.com, api.contoso.com). Der Vorteil ist, dass wenn der private Schlüssel kompromittiert wird, nur die aufgeführten FQDNs betroffen sind (und nicht alle Unterdomänen).
• Monitor-Zertifikatablauf: Verwenden Sie Azure Resource Graph, um das Zertifikatinventar abzufragen und Zertifikate zu identifizieren, die ablaufen (innerhalb von 30 Tagen), selbstsignierte Zertifikate oder Zertifikate mit veralteten SHA-1-Signaturalgorithmus, vierteljährliches Überprüfen des Dashboards während Sicherheitsüberprüfungsbesprechungen.

Ergebnis: Die automatische Zertifikaterneuerung löst bei 80% der Laufzeit aus. Azure App Service und Das Anwendungsgateway rufen aktualisierte Zertifikate innerhalb von 24 Stunden über verwaltete Identitäten ab (kein Neustart erforderlich). Azure Monitor Warnungen benachrichtigen das Plattform-Engineering-Team vor Ablauf. SAN-Zertifikate ersetzen Wildcard-Zertifikate und verringern den Umfang möglicher Kompromittierungen.

Kritischitätsstufe

Unverzichtbar.

Steuerelementzuordnung

• CIS-Kontrollen v8.1: N/A
• 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: Sicherstellen der Sicherheit des Schlüssel- und Zertifikat-Repositorys

Azure Policy: Siehe Azure integrierte Richtliniendefinitionen: DP-8.

Sicherheitsprinzip

Sichern Sie Schlüsseltresordienste über umfassende Sicherheitskontrollen: Zugriff auf geringste Rechte, Netzwerkisolation, umfassende Protokollierungs- und Überwachungsfunktionen, Sicherungs- und Wiederherstellungsfunktionen und HSM-gesicherter Schutz, sofern erforderlich. Schlüsseltresor sind wichtige Infrastruktur, die kryptografische Schlüssel und Zertifikate schützt, die für Verschlüsselung und Authentifizierung verwendet werden.

Risiko mindern

Die Kompromittierung des Schlüssel- und Zertifikatspeichers hebt Verschlüsselung, Signatur und Identitätsgarantien auf. Ohne gesicherten Tresorzugang, Überwachung und Isolierung:

• Schlüsselexfiltration: Das gestohlene KEKs / HSM-Material erlaubt die Massenentschlüsselung gespeicherter Daten und das Abfangen des Datenverkehrs.
• Administrativer Schattenzugriff: Eine zu breite RBAC- oder Fehlkonfiguration von Richtlinien ermöglicht einen unerlaubten Schlüsselexport, -löschung oder -Versionsrollback.
• Stille Manipulation: Der Ersatz bösartiger Schlüssel ermöglicht einen transparenten Man-in-the-Middle-Angriff oder gefälschten Code/Signaturen.
• Netzwerkexposition: Der Missbrauch öffentlicher Endpunkte (Credential Stuffing, API-Probing) erweitert die Angriffsfläche für Brute-Force- oder Token-Replay.
• Versehentliche destruktive Aktionen: Fehlender Schutz der weichen Löschung / Bereinigung führt zu unwiderruflichem kryptografischem Datenverlust.
• Unzureichende Überwachungslinie: Mangel an unveränderlichen Protokollen beeinträchtigt die Reaktion auf Vorfälle und behördliche Beweisanforderungen.
• Nicht segmentierte Mandantschaft: Gemeinsame Anwendungsschlüssel erweitern den Strahlradius der lateralen Bewegung nach einer einzigen Identitätskompromittierung.

Repository-Schwachstellen verbreiten sich schnell in systemische Vertraulichkeits-, Integritäts- und Verfügbarkeitsfehler über abhängige Workloads hinweg.

MITRE ATT&CK

• Zugriff auf Anmeldeinformationen (TA0006):Ungeschützte Anmeldeinformationen / Anmeldeinformationsspeicher (T1552 / T1555), die über falsch konfigurierte Tresorrolle oder Netzwerkrichtlinien abgerufen wurden.
• Defense Evasion (TA0005): Angreifer in der Mitte (T1557) erfassen tresorgebundenen Datenverkehr für die Abfangen von Schlüssel-/Zertifikaten oder die Schwächung der Verschlüsselung (T1600) durch starke Schlüssel durch vom Angreifer kontrolliertes Material.
• Berechtigungseskalation (TA0004): Gültige Konten (T1078) nutzen zu umfassende Tresoroperatorrollen aus, um Geheimnisse aufzulisten und zu ändern.
• Auswirkung (TA0040): Datenvernichtung / Hemmung der Wiederherstellung (T1485 / T1490) durch destruktive Bereinigungssequenzen, die die Wiederherstellung verhindern.

DP-8.1: Implementieren von Zugriffssteuerungen für Key Vault

Schützen Sie die kryptografische Grundlage Ihrer Infrastruktur, indem Sie strenge identitätsbasierte Zugriffskontrollen erzwingen, die nicht autorisierten Schlüsselzugriff verhindern, Administratorrechte auf gerechtfertigte Zeitfenster beschränken und die Speicherung von Anmeldeinformationen durch verwaltete Identitäten beseitigen. Implementieren Sie die Trennung von Aufgaben zwischen Schlüsseladministratoren und Schlüsselbenutzern, um zu verhindern, dass eine einzelne kompromittierte Identität sowohl die Verwaltung als auch die Ausnutzung kryptografischen Materials ermöglicht.

Implementieren Sie RBAC und Aufgabentrennung:

• Implementieren Sie Azure RBAC für Key Vault zum Erzwingen der Zugriffssteuerung mit den geringsten Rechten:
  • Für den Azure Key Vault Managed HSM: Verwenden Sie lokales RBAC auf der Ebene einzelner Schlüssel, Geheimnisse und Zertifikate mit integrierten Rollen (Managed HSM Crypto-Officer, Crypto-User, Crypto-Auditor).
  • Für Azure Key Vault Standard/Premium: Erstellen Sie dedizierte Tresore pro Anwendung oder Umgebung, um logische Trennung zu erzwingen, und weisen Sie RBAC-Rollen (Key Vault Administrator, Secrets Officer, Certificate Officer) mit anwendungsspezifischem Bereich zu.
• Erzwingen der Trennung von Aufgaben: Separate Rollen für die Schlüsselverwaltung (wer Schlüssel erstellen/drehen kann) aus kryptografischen Vorgängen (wer Schlüssel zum Verschlüsseln/Entschlüsseln verwenden kann).

Verwenden von verwalteten Identitäten und JIT-Zugriff:

• Verwenden Sie managed-Identitäten für Azure Ressourcen (App Services, VMs, Azure Functions usw.), um auf Key Vault zuzugreifen, anstatt Anmeldeinformationen in Anwendungscode- oder Konfigurationsdateien zu speichern. Verwaltete Identitäten beseitigen die Komplexität bei der Speicherung und Rotation von Anmeldeinformationen.
• Implementieren Sie Azure AD Privileged Identity Management (PIM) für just-in-time-Administrativen Zugriff auf Key Vault:
  • Konfigurieren von berechtigten Zuweisungen für Key Vault Administratorrolle (keine dauerhaften Zuweisungen).
  • Begründung, MFA und Genehmigung für die Aktivierung erforderlich.
  • Festlegen der maximalen Aktivierungsdauer (z. B. 8 Stunden).
  • Führen Sie regelmäßige Zugriffsüberprüfungen durch, um unnötige ständige Berechtigungen zu widerrufen.

DP-8.2: Absicherung der Key Vault Netzwerksicherheit

Beseitigen Sie internet-anfällige Angriffsflächen, indem Sie alle Zugriffe auf den Key Vault über private Endpunkte innerhalb Ihrer virtuellen Netzwerke leiten. Dadurch werden Anmeldeinformationen-Stuffing, Brute-Force-Versuche und Auskundschaften durch externe Bedrohungsakteure verhindert. Wenn der öffentliche Zugriff für CI/CD-Szenarien unvermeidbar ist, implementieren Sie strenge IP-Zulassungslisten und Firewallregeln, um das kleinste mögliche Belichtungsfenster zu erstellen.

Deploy Private Link und konfigurieren Sie firewall:

• Sichern Sie den Netzwerkzugriff auf Azure Key Vault mithilfe von Azure Private Link, um private Verbindungen über VNets herzustellen, ohne Key Vault für das öffentliche Internet verfügbar zu machen.
• Konfigurieren Sie Key Vault Firewall, um den Zugriff auf bestimmte IP-Bereiche oder VNets für Szenarien einzuschränken, in denen Private Link nicht machbar ist:
  • Deaktivieren Sie den öffentlichen Zugriff nach Möglichkeit (Key Vault nur über privaten Endpunkt zugänglich).
  • Wenn der öffentliche Zugriff erforderlich ist (z. B. für CI/CD-Pipelines), erlauben Sie den Zugriff von ausgewählten Netzwerken nur mit engen IP-Zulassungslisten.
• Erstellen und verknüpfen Sie private DNS-Zonen (z. B. ) mit VNets, privatelink.vaultcore.azure.netum die richtige DNS-Auflösung für private Endpunkte sicherzustellen.

DP-8.3: Aktivieren des Key Vault-Schutzes und der Überwachung

Implementieren Sie Tiefenverteidigungsmaßnahmen, die unwiderrufliche kryptografische Datenverluste durch Weiches Löschen und Schutz vor endgültigem Löschen verhindern, wobei HSM-gestützte Schlüssel für Produktionsworkloads verwendet werden, die FIPS-validierte Sicherheit erfordern. Stellen Sie umfassende Überwachung mit Microsoft Defender für Key Vault und Microsoft Sentinel bereit, um anomale Zugriffsmuster, ungewöhnliche Schlüsselvorgänge und administrative Anomalien zu erkennen, die Kompromittierung, Insider-Bedrohungen oder Aufklärungsaktivitäten für Ihre kryptografische Infrastruktur angeben.

Soft Delete und Schutz vor endgültigem Löschen aktivieren:

• Aktivieren Sie soft delete und purge protection auf allen Azure Key Vaults, um das versehentliche oder böswillige Löschen von Schlüsseln, Geheimschlüsseln und Zertifikaten zu verhindern:
  • Das vorläufige Löschen ermöglicht die Wiederherstellung innerhalb eines Aufbewahrungszeitraums (Standard: 90 Tage).
  • Der Löschschutz verhindert die dauerhafte Löschung während des Aufbewahrungszeitraums.
  • Erzwingen Sie diese Einstellungen mit Azure Policy mithilfe von integrierten Richtlinien: "Schlüsseltresore sollten Soft Delete aktiviert haben" und "Schlüsseltresore sollten Purge Protection aktiviert haben" (deployIfNotExists-Effekt).
• Implementieren Sie wichtige Lebenszyklusrichtlinien, um kryptografische Löschungen von Daten zu vermeiden:
  • Stellen Sie vor dem Löschen verschlüsselter Daten sicher, dass Verschlüsselungsschlüssel für den erforderlichen Datenaufbewahrungszeitraum aufbewahrt werden.
  • Verwenden Sie beim Außerbetriebsetzen von Schlüsseln den Vorgang "Deaktivieren" anstelle von "Löschen ", um versehentlichen Datenverlust zu verhindern, während wichtige Metadaten zu Überwachungszwecken beibehalten werden.
  • Erstellen und Testen Key Vault Backup Verfahren für Notfallwiederherstellungsszenarien.

Verwenden Sie HSM-gesicherte Schlüssel und BYOK:

• Verwenden Sie HSM-gesicherte Schlüssel für Produktionsworkloads, die einen starken kryptografischen Schutz erfordern:
  • Azure Key Vault Premium: RSA-HSM und EC-HSM Schlüssel, die durch FIPS 140-2 Level 2 validierte HSMs (gemeinsam genutzte mehrinstanzenfähige HSMs) geschützt sind.
  • Azure Key Vault Managed HSM: RSA-HSM und EC-HSM Schlüssel, die durch FIPS 140-3 Level 3 validierte HSMs (dedizierte Einzelmandantenpools) geschützt sind.
• Generieren Sie für Bring Your Own Key (BYOK) Szenarien Schlüssel in lokalen FIPS 140-2 Level 2+ HSMs und verwenden sie den BYOK-Übertragungsschlüsselmechanismus, um Schlüssel sicher in Azure Key Vault zu importieren, kryptografische Nachweise für den Schlüsselursprung und die Verwahrung von Schlüsseln beizubehalten.

Überwachung und Bedrohungserkennung aktivieren:

• Aktivieren Sie diagnostische Protokollierung für Azure Key Vault und leiten Sie Protokolle an Azure Monitor, Log Analytics oder Microsoft Sentinel weiter, um alle Managementvorgänge und Datenvorgänge zu erfassen. Überwachen Sie verdächtige Aktivitäten, einschließlich ungewöhnlicher Zugriffsmuster, fehlgeschlagener Authentifizierungsversuche und administrativer Änderungen.
• Aktivieren Sie Microsoft Defender für Key Vault, um anomale Zugriffsmuster, ungewöhnliche Schlüsselvorgänge und potenzielle Bedrohungen wie Missbrauch von Anmeldeinformationen, verdächtige Schlüsselabrufe oder administrative Anomalien zu erkennen. Integrieren Sie Defender für Key Vault Warnungen in Workflows zur Reaktion auf Vorfälle.
• Integrieren Sie Key Vault Protokolle in Microsoft Sentinel, um Analyseregeln zum Erkennen von Anomalien wie ungewöhnlichem regionalem Zugriff, potenziellen Brute-Force-Versuchen oder verdächtigen administrativen Vorgängen zu erstellen. Implementieren Sie automatisierte Antwort-Playbooks, um kompromittierte Identitäten zu isolieren und Sicherheitsteams zu benachrichtigen.

Note: Alle Key Vault SKUs verhindern den Schlüsselexport nach Entwurf; kryptografische Vorgänge werden innerhalb der sicheren HSM-Grenze ausgeführt. Exportieren oder speichern Sie Schlüssel niemals im Klartext außerhalb des Azure Key Vault.

Beispiel für die Implementierung

Ein multinationales Technologieunternehmen implementierte eine umfassende Sicherheit für ihre Azure Key Vault Infrastruktur zum Schutz von Verschlüsselungsschlüsseln, API-Geheimnissen und TLS-Zertifikaten für 500 Mikroservices.

Herausforderung: Überweite RBAC-Berechtigungen erlaubten Entwicklern direkten Zugriff auf Production Key Vaults, wodurch Insider-Risiken und Complianceverletzungen entstehen. Die öffentliche Internetexponierung ermöglichte Credential Stuffing-Angriffe und Erkundungsversuche. Ohne umfassende Überwachung und automatisierte Reaktion wurden verdächtige Zugriffsmuster nicht erkannt. Fehlender Schutz vor vorläufigem und vollständigem Löschen gefährdete einen dauerhaften Verlust kryptografischer Daten während Vorfällen.

Lösungsansatz:

• Dedizierte Key Vaults für logische Segmentierung bereitstellen: Erstellen Sie für jede Umgebung und Geschäftseinheit einen Key Vault mit der Namenskonvention kv-{businessunit}-{environment}-{region} (z. B. kv-finance-prod-eastus2, kv-finance-dev-eastus2), in separaten Ressourcengruppen pro Umgebung bereitstellen, um Isolation zu gewährleisten (ein kompromittierter Dev-Serviceprincipal kann nicht auf Produktionsschlüssel zugreifen).
• Konfigurieren Sie RBAC für den Zugriff mit geringsten Rechten: Für Nichtproduktions-Key Vaults (dev/staging) weisen Sie Entwickler-Sicherheitsgruppen den Key Vault Secrets User (schreibgeschützt) zu. Entwickler können Secrets in Dev/Staging lesen, haben jedoch keinen Zugriff auf Produktions-Key Vaults. Für Produktions-Key Vaults weisen Sie den Key Vault Secrets User den CI/CD-Dienstprinzipalen (von Azure DevOps verwaltete Pipelineidentitäten) zu und beschränken den Zugriff auf bestimmte benannte Secrets, ohne interaktiven Entwicklerzugriff auf Produktionskeys.
• Härten Sie die Netzwerksicherheit mit Azure Private Link: Stellen Sie private Endpunkte für Key Vault bereit (wählen Sie VNet und Subnetz aus, erstellen Sie die private DNS-Zone privatelink.vaultcore.azure.net und verknüpfen Sie sie mit dem VNet), konfigurieren Sie die Key Vault-Firewall (deaktivieren Sie den öffentlichen Zugriff, sodass Key Vault nur über den privaten Endpunkt zugänglich ist; wenn öffentlicher Zugriff für CI/CD erforderlich ist, erlauben Sie den Zugriff nur von ausgewählten Netzwerken mit genehmigten Azure VNet-Subnetzen und CI/CD-Agent-IP-Adressbereichen).
• Enable Microsoft Defender für Key Vault: Aktivieren Sie Microsoft Defender für Key Vault auf Abonnementebene. Defender überwacht Anomalien, einschließlich ungewöhnlichem geografischem Zugriff, verdächtigen Aufzählungsvorgängen (schnelle Listenvorgänge, die auf Erkundungsaktivitäten hinweisen), und ungewöhnlichen administrativen Vorgängen (Massenlöschung von Geheimnissen).
• Integrieren Sie sich mit Microsoft Sentinel für eine automatisierte Antwort: Fügen Sie den Microsoft Defender for Cloud-Datenconnector zu Sentinel hinzu, erstellen Sie Sentinel-Analyse-Regeln für ungewöhnliche regionale Zugriffe, potenziellen Brute-Force-Angriff, verdächtige administrative Vorgänge, konfigurieren Sie automatisierte Antwort-Playbooks, um verdächtige Identitäten zu deaktivieren und Sicherheits-Teams zu benachrichtigen.
• Streamen von Diagnoseprotokollen zu Log Analytics: Aktivieren Sie die Diagnoseprotokollierung für Key Vault mit AuditEvent (alle Schlüssel-, Geheimnis- und Zertifikatvorgänge) und AllMetrics (Verwendungshäufigkeit, Antwortzeiten). Senden Sie diese an den Log Analytics-Arbeitsbereich mit einer Aufbewahrungsdauer von 2 Jahren. Erstellen Sie benutzerdefinierte KQL-Abfragen zur Anomalieerkennung, einschließlich potenzieller Brute-Force-Erkennung bei mehr als 10 unautorisierten Versuchen innerhalb von 5 Minuten. Deaktivierte "Soft Delete"-Vorgänge dienen als Hinweis auf mögliche Sabotage.
• Implement Just-In-Time Administratorzugriff mit Azure AD PIM: Konfigurieren berechtigter Zuweisungen für Key Vault Administratorrolle (Hinzufügen von Sicherheitsteammitgliedern als berechtigte nicht permanente Zuweisung, Erfordern einer Begründung und MFA für die Aktivierung, festlegen der maximalen Aktivierungsdauer 8 Stunden, Genehmigung von Senior Security Architect), vierteljährliche Zugriffsüberprüfungen für alle Key Vault Administratorrollenzuweisungen; den unnötigen Zugriff widerrufen.

Ergebnis: Dedizierte Schlüsseltresore pro Umgebung erzwingen Segmentierung. RBAC beschränkt Entwickler auf lediglich lesenden Zugriff auf nicht-produktive Systeme. Private Link beseitigt die Exposition gegenüber dem öffentlichen Internet. Microsoft Defender erkennt Anomalien. Sentinel-Playbooks deaktivieren automatisch verdächtige Identitäten. PIM ermöglicht den Just-in-Time-Administratorzugriff, wodurch die ständigen Berechtigungen erheblich reduziert werden.

Kritischitätsstufe

Unverzichtbar.

Steuerelementzuordnung

• CIS-Kontrollen v8.1: N/A
• 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