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.

Zu behebende Risiken

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-Export-Endpunkte, bei denen Kennzeichnung/Richtlinien-Gates nicht vorhanden sind.
• Exfiltration (TA0010): automatisierte Exfiltration (T1020) unter Verwendung von skriptgesteuerter Paginierung/Schleifenbildung, um unbemerkt falsch klassifizierte Datensätze zu sammeln.

DP-1.1: Ermitteln, Klassifizieren und Bezeichnen vertraulicher Daten

Verwenden Sie Microsoft Purview, um eine umfassende Datenzuordnung zu erstellen, die automatisch vertrauliche Informationen in Ihrem gesamten Datenbestand ermittelt, klassifiziert und kennzeichnet. 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.

Steuerungszuordnung

• 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.

Zu behebende Risiken

Angreifer und böswillige Insider versuchen, vertrauliche Daten zu exfiltrieren, zu staging oder zu proben, indem sie sich unauffällig oder mit geringen Signalen verhalten. Ohne kontinuierliche, kontextbezogene Anomalieüberwachung, die an die Vertraulichkeit von Daten gebunden ist:

• Stille Exfiltration: Bulk-Exporte, große Resultsets oder inkrementelles Siphoning bleiben aufgrund fehlender Baselines unentdeckt.
• Insider-Missbrauch: Legitime Anmeldeinformationen führen ungewöhnliche Sequenzen aus (Uhrzeit, Volumes, Gebietsschema), die die grobe Ü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-Administrationstools verbergen die Abfrage im normalen 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

• Collection (TA0009): Daten aus Cloud Storage (T1530) über anomale Bulk- oder Wide Fan-out-Lesevorgänge in vertraulichen Containern.
• Zugriff auf Anmeldeinformationen (TA0006): gültige Konten (T1078), die kompromittierte oder Insider-Anmeldeinformationen missbrauchen, um mit legitimen Datenverkehr-Baselines zu blenden.
• Exfiltration (TA0010): Automatisierte Exfiltration (T1020) mit skriptierten, gedrosselten Abfragen, die entwickelt wurden, um Warnungsschwellenwerte zu vermeiden.
• Exfiltration (TA0010): Exfiltration in Cloud-Storage (T1567.002) Staging von Daten in vom Angreifer kontrollierten Regionen oder Konten zum späteren Abruf.
• Command & Control / Exfiltration (TA0011/TA0010): Anwendungsschichtprotokoll (T1071) tunnelt sensible Zeilen über normale DB/API-Aufrufe.
• Ermittlung (TA0007): System-/Dienst-Ermittlung (T1082, T1046), bei der Endpunkte aufgelistet werden, um laterale Bewegungspfade zu höherwertigen Stores aufzuzeigen.

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 Perimeter-Verteidigungen haben Insiderbedrohungen und kompromittierte Dienstprinzipale, die Bulk-Downloads durchführen, übersehen. 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 zur Erkennung verhaltensbedingter Insiderrisiken: Aktivieren Sie das Insider-Risikomanagement und konfigurieren Sie Richtlinienvorlagen (Datendiebstahl durch ausscheidende Benutzer, die 30-90 Tage vor dem Ausscheiden ungewöhnliche Dateidownloads erkennen, allgemeine Datenlecks, die das Kopieren von USB-/Cloud-Storage überwachen, Datenlecks durch vorrangige Benutzer mit erweiterter Überwachung für Rollen mit hohen Privilegien), konfigurieren Sie Risikoindikatoren und Schwellenwerte (kumulative Dateidownloadvolumen-Warnungen, Zugriffsspitzen außerhalb der Geschäftszeiten, Sequenzerkennung, die mehrere risikobehaftete Signale kombiniert), Integration von Datenquellen (Azure-Aktivitätsprotokolle, Microsoft 365 Audit Logs, Defender for Cloud Apps, HR-Systeme, Endpunkt-DLP-Ereignisse), Konfiguration des Warnhinweis-Workflows zur Weiterleitung von Alarmen mittlerer/hoher Schwere an eine spezielle 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.

Steuerungszuordnung

• 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.

Zu behebende Risiken

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.
• Protokoll-Downgrade: Legacy Fallback (SSL/TLS < 1.2, Klartext HTTP/FTP) ermöglicht die Ausnutzung veralteter Verschlüsselungssuiten.
• 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.
• Intransparente laterale Pfade: Interner Datenverkehr im Klartext wird zu Aufklärungsmaterial, nachdem er Fuß gefasst hat.

Das Versäumnis, eine starke Verschlüsselung während der Übertragung durchzusetzen, vergrößert den Radius von Sicherheitsverletzungen, beschleunigt das Kompromittieren von Anmeldeinformationen und untergräbt die Zero-Trust-Annahme.

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.
• Collection (TA0009): Netzwerk-Sniffing (T1040) Abfangen von API Payloads und Secrets über schwache Verschlüsselungen oder Klartextpfade.
• Exfiltration (TA0010): Exfiltration über Webdienste (T1567) durch Streaming strukturierter Daten über legitime API-Endpunkte.
• Verteidigungsumgehung (TA0005): adversary-in-the-middle (T1557) erzwingt TLS-Downgrade oder fügt Abhör-Proxys ein, um Datenverkehr einzusehen/zu verändern.
• Command & Control (TA0011): Nicht-Anwendungsschicht-Protokoll (T1095), das auf veraltete oder weniger überprüfte Transporte zurückgreift, 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.

Steuerungszuordnung

• 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.

Zu behebende Risiken

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 Wiederherstellung: Disaster-Recovery-Images und Cold-Archive behalten vertrauliche Inhalte auf unbestimmte Zeit in wiederherstellbarem Klartext.

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.
• Verteidigungsumgehung (TA0005): Indikatorentfernung (T1070) Bearbeiten oder Löschen von Protokollen nach Offline-Medien-/Snapshot-Zugriff.
• 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. Die Infrastrukturverschlüsselung schützte technische Dateien mit zwei Schichten der Verschlüsselung. 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.

Steuerungszuordnung

• 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.

Zu behebende Risiken

Die ausschließliche Verwendung von Service Managed Keys, bei denen rechtliche, vertragliche oder Trennungsgarantien die Kontrolle durch den Mandanten erfordern, birgt Compliance- und Konzentrationsrisiken. Ohne ordnungsgemäß kontrollierte Customer-Managed Keys (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 Angriffsradius: Das Kompromittieren von mandantenübergreifenden Plattformschlüsseln kann sich auf breite Datasets auswirken, wenn die kryptografische Isolierung unzureichend ist.
• 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.
• Auswirkungen (TA0040): Daten, die für Auswirkungen (T1486) verschlüsselt wurden, missbrauchen CMK-Rotation/Widerruf, 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): Orchestrierung von schlüsselfähigen Bulk-Exporten in großen Volumina unter normalen Diensten.

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:

• Bereitstellung von Azure Key Vault Managed HSM: Erstellen von Managed HSM (FIPS 140-3 Level 3 validiert) mit mindestens 3 HSM-Partitionen für Hochverfügbarkeit, Aktivieren von Managed HSM durch Exportieren der Sicherheitsdomäne mit Quorum-Schlüsseln (aufgeteilt in Schlüsselfragmente, die in geografisch verteilten Offline-Tresoren gespeichert sind), Generieren von Verschlüsselungsschlüsseln (RSA-4096 namens KEK-Prod-2024) mit Schlüsseloperationen: Wrap Key, Unwrap Key, Encrypt, Decrypt.
• Konfigurieren von Customer-Managed Keys für Azure Services: Für Azure Storage konfigurieren Sie das Speicherkonto für die Verwendung des CMK-Verschlüsselungstyps, wählen Sie Key Vault Managed HSM als Schlüsselquelle aus, aktivieren Sie die dem Benutzer zugewiesene verwaltete Identität mit der Rolle Managed HSM Crypto Service Encryption User; für Azure SQL-Datenbank konfigurieren Sie die SQL Database für die Verwendung des Customer-Managed Key als TDE-Protector, wählen Sie den Key von Managed HSM aus, aktivieren Sie die automatische Rotation; für Azure Cosmos DB aktivieren Sie die Customer-Managed Keys für das Cosmos DB-Konto, wählen Sie den Managed HSM Key aus, gewähren Sie der Cosmos DB den Zugriff auf die verwaltete Identität.
• 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

Das sollte so sein.

Steuerungszuordnung

• 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.

Zu behebende Risiken

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:

• Key Sprawl & orphaning: Unverfolgte Schlüssel bleiben über die Anforderungen von Unternehmen hinaus bestehen und behalten unbeabsichtigte Entschlüsselungsbefugnisse.
• Veraltete Kryptografie: Unregelmäßiges Rotieren erhöht die Anfälligkeit für algorithmische Downgrades, Brute-Force- oder Side-Channel-Angriffe.
• 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 Kennwort-Stores (T1555), die inkorrekt gespeichertes oder zwischenspeicherndes Schlüsselmaterial extrahieren, oder gültige Konten (T1078), die breite RBAC-Rollen für die Schlüsselverwaltung ausnutzen, um unrechtmäßig auf Schlüssel zuzugreifen oder diese zu rotieren.
• 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)
  • Managed HSM: FIPS 140-3 Level 3 validiert (dedizierter HSM-Pool für einen Mandanten)
• 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 von DEKs auf Servicelevel, die durch KEKs verschlüsselt werden, um den Explosionsradius der Schlüsselrotation zu minimieren.
  • Das Rotieren von KEKs erfordert nur das erneute Verschlüsseln von DEKs (nicht von ganzen Datasets), was eine effiziente Schlüsselrotation ohne Ausfallzeiten ermöglicht.
• 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 georeplizierte Key Vaults 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).
  • Administrative Änderungen außerhalb der Geschäftszeiten (Löschen oder Rotieren von Schlüsseln außerhalb der Geschäftszeiten).
• 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 Aufgabentrennung sah sich die Organisation mit ausgedehnten Fenstern für das Kompromittieren von Schlüsseln und der Nichteinhaltung von Compliance-Vorschriften 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.
• Implementierung automatischer Richtlinien zur Schlüsselrotation: Konfigurieren Sie die Richtlinie zur Rotation mit einer 180-tägigen Rotationshäufigkeit, aktivieren Sie die automatische Rotation und legen Sie eine Warnung 30 Tage vor Ablauf fest, erstellen Sie Azure Monitor Aktionsgruppen, um das Security Operations Team zu benachrichtigen, wenn sich die Schlüssel dem Ablauf nähern, konfigurieren Sie die Rotationsaktion, 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. Soft Delete 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.

Steuerungszuordnung

• 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.

Zu behebende Risiken

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.
• Unentdeckte Kompromitierung: Gestohlene private Schlüssel lassen eine transparente Man-in-the-Middle- oder Datenverkehrs-Entschlüsselung bis zum Rotieren zu.
• Schattenzertifikate: Die nicht genehmigte Ausstellung außerhalb genehmigter CAs fragmentiert die Governance und vergrößert blinde Flecken beim Widerruf.
• Fehler bei der manuellen Verlängerung: Inkonsistente Sequenzen bei der Ersetzung führen zu Diskrepanzen in der Vertrauenskette und teilweiser Abweichung von der Umgebung.

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

• Verteidigungsumgehung (TA0005): Umgehen von Vertrauenskontrollen (T1553), Ausstellen oder Einführen betrügerischer Zertifikate zur Umgehung der Validierung.
• Ressourcenentwicklung (TA0042): Entwickeln von Funktionen (T1587) zum Schmieden von Zertifikaten oder Tools für zukünftige Angriffsphasen.
• Verteidigungsumgehung (TA0005): Schwächung der Verschlüsselung (T1600) durch fortgesetzte Verwendung veralteter Signaturalgorithmen, die die Überprüfungssicherheit verringern.
• Zugriffsberechtigung auf Anmeldeinformationen (TA0006): Nicht geschützte Anmeldeinformationen (T1552) mit Extraktion privater Schlüssel aus unsicheren Dateispeichern oder dem Prozessspeicher.
• Persistenz (TA0003): Modifizierung des Authentifizierungsprozesses (T1556) durch Umschreiben von zertifikatsbasierten Auth Flows zur Einbettung von dauerhaftem 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.
  • Platzhalter-Zertifikate: Ein breiter Bereich erhöht das Risiko bei einer Kompromittierung; verwenden Sie stattdessen Subject Alternative Name (SAN)-Zertifikate mit expliziten 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 dem Ablaufen von Zertifikaten zu warnen, bevor die automatische Verlängerung ausgelöst wird.

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

Kontinuierliche Visibility des Zustands von Zertifikaten durch automatisierte Überwachung, Abfragen des Bestands und Dashboards, die Oberflächen von Zertifikaten aufdecken, deren Gültigkeit bald abläuft, die veraltete Kryptografie verwenden oder keine angemessene Governance aufweisen. 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:
  • Zeitrahmen für den Ablauf von Zertifikaten nach Zeitrahmen.
  • 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).
  • Führen Sie Runbooks für die Reaktion auf Vorfälle bei kompromittierten Zertifikaten.
  • Überwachen Sie Branchenhinweise auf kompromittierte Stamm- oder Zwischenzertifikate und blockieren Sie diese 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 der automatischen Zertifikatsbindung für Azure-Dienste: Für Azure App Service importieren Sie das Zertifikat aus Key Vault, weisen Sie dem Benutzer eine verwaltete Identität mit der Rolle Key Vault Secrets User zu, aktivieren Sie automatische Zertifikatsaktualisierungen (App Service bindet die neue Zertifikatsversion innerhalb von 24 Stunden, wenn sie erneuert wird, kein Neustart erforderlich); für Azure Application Gateway konfigurieren Sie den Listener, um das Zertifikat aus Key Vault abzurufen, weisen Sie dem Benutzer eine verwaltete Identität mit den Rollen Key Vault Secrets User und Certificates User zu, Application Gateway ruft automatisch das aktualisierte Zertifikat ab, wenn Key Vault es 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: Automatische Auslöser für die Verlängerung von Zertifikaten bei 80 % Lebensdauer. 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 Platzhalter-Zertifikate und verringern so den Radius der Kompromittierung.

Kritischitätsstufe

Unverzichtbar.

Steuerungszuordnung

• 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 Key Vault Dienste durch Defense-in-Depth-Kontrollen: Zugriff mit geringsten Privilegien, Netzwerkisolierung, umfassende Protokollierung und Überwachung, Sicherungs- und Wiederherstellungsfunktionalitäten sowie HSM-gestützter Schutz, wo erforderlich. Schlüsseltresor sind wichtige Infrastruktur, die kryptografische Schlüssel und Zertifikate schützt, die für Verschlüsselung und Authentifizierung verwendet werden.

Zu behebende Risiken

Eine Kompromittierung des Schlüssel- und Zertifikat-Repositorys macht die vorgelagerten Verschlüsselungs-, Signier- und Identitätsgarantien zunichte. 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: Schädlicher Schlüsselersatz ermöglicht transparenten Man-in-the-Middle 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.
• Unsegmentierter Mandat: Vermischte Anwendungsschlüssel erweitern den seitlichen Bewegungsradius nach einem einzigen kompromittierenden Identitätswechsel.

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.
• Verteidigungsumgehung (TA0005): adversary-in-the-middle (T1557) fängt Datenverkehr im Vault ab, um Schlüssel/Zertifikate abzufangen, oder schwächt die Verschlüsselung (T1600) und ersetzt starke Schlüssel durch vom Angreifer kontrolliertes Material.
• Privilegieneskalation (TA0004): Gültige Konten (T1078), die zu weit gefasste Vault-Betreiberrollen ausnutzen, um Secrets aufzulisten und zu verä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 Microsoft Entra Privileged Identity Management (PIM) für den Just-in-Time-Administratorzugriff 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

Implementierung von Defense-in-Depth-Schutzmaßnahmen, die irreversible kryptografische Datenverluste durch Soft Delete und Purge-Schutz verhindern, während HSM-gestützte Schlüssel für Produktions-Workloads 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 unter Verwendung integrierter Richtlinien: „Schlüsselspeicher sollten Soft Delete aktiviert haben“ und Schlüsselspeicher sollten einen Bereinigungsschutz 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 geschützt sind (gemeinsam genutzte Multi-Mandanten).
  • Azure Key Vault Managed HSM: RSA-HSM- und EC-HSM-Schlüssel, geschützt durch FIPS 140-3 Level 3 validierte HSMs (dedizierte Pools für einzelne Mandanten).
• 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.
• Implementieren Sie Just-In-Time Administratorzugriff mit Microsoft Entra PIM: Konfigurieren Sie die berechtigten Zuweisungen für die Key Vault-Administratorrolle (fügen Sie Mitglieder des Sicherheitsteams als berechtigte, nicht permanente Zuweisungen hinzu, verlangen Sie eine Begründung und MFA für die Aktivierung, legen Sie die maximale Aktivierungsdauer auf 8 Stunden fest, erfordern Sie die Genehmigung durch einen leitenden Sicherheitsarchitekten), führen Sie vierteljährliche Zugriffsüberprüfungen für alle Zuweisungen der Key Vault-Administratorrolle durch; widerrufen Sie unnötigen Zugriff.

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.

Steuerungszuordnung

• 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