Microsoft AZ-500: Schlüsselverwaltung, Kryptografie und Zertifikate — Lernleitfaden

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Teil des Microsoft Azure Security Engineer Associate AZ-500 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Die Schlüsselverwaltung in Azure konzentriert sich auf Azure Key Vault und Azure Managed HSM. Diese Dienste bieten eine sichere Speicherung von kryptografischem Material, konsistente APIs und überprüfbare Operationen, die die Verschlüsselung im Ruhezustand (at rest), während der Übertragung (in transit) und die Kryptografie auf Anwendungsebene untermauern. Das operative Ziel ist es, die Schlüsselverwahrung von der Anwendungslaufzeit zu trennen, den Explosionsradius (Blast Radius) durch bereichsbezogene Autorisierung und Netzwerkrichtlinien zu minimieren und die Wiederherstellbarkeit sowie Rotation zu erzwingen, um das Risiko langlebiger Geheimnisse zu reduzieren.

Azure Key Vault und Managed HSM: Architektur und Autorisierung

Azure Key Vault-Architektur

• Dienstzusammensetzung: mandantenfähige Front-Ends, regionale Partitionen für die Datenebene, mandantenbezogene Isolierung und eine durch Azure AD gestützte Authentifizierung. Schlüssel sind entweder softwaregeschützt (Standard-Tarif) oder HSM-geschützt (Premium-Tarif). Geheimnisse und Zertifikate sind immer softwaregeschützt.
• Tarife: Standard (Softwareschlüssel) für allgemeine Zwecke und Kosteneffizienz; Premium (HSM-gestützte Schlüssel), wenn ein Schutz, der FIPS 140-2 Level 2/3 entspricht, oder eine dedizierte HSM-Grenze für das Schlüsselmaterial erforderlich ist. Wählen Sie Premium bei regulatorischen Anforderungen oder bei der Verwendung von Schlüsseln mit „RSA-HSM“ oder „EC-HSM“.
• Vorläufiges Löschen und Bereinigungsschutz: Das vorläufige Löschen ist immer aktiviert, mit einer konfigurierbaren Aufbewahrungsfrist (7–90 Tage, üblicherweise 90). Der Bereinigungsschutz verhindert, wenn aktiviert, die endgültige Löschung des Tresors oder von Objekten bis zum Ablauf der Aufbewahrungsfrist, selbst durch hochprivilegierte Benutzer. Operative Begründung: Aktivieren Sie den Bereinigungsschutz für jeden Tresor, der kundenseitig verwaltete Schlüssel (CMK) sichert. Ohne diesen Schutz könnte eine versehentliche oder böswillige Bereinigung abhängige Daten (z. B. Speicher oder Datenbanken, die mit diesem Schlüssel verschlüsselt sind) unwiederherstellbar machen.
• Wiederherstellung: Gelöschte Tresorobjekte können aufgelistet und wiederhergestellt werden; eine Wiederherstellung auf Tresorebene wird unterstützt. Backups erzeugen verschlüsselte Blobs, die in kompatiblen Tresoren in derselben Azure-Region und -Cloud wiederhergestellt werden können. Begründung: Exportieren Sie regelmäßig Schlüssel-Backups, sichern Sie diese separat und testen Sie Wiederherstellungen, um die RTO zu validieren.

Autorisierungsmodell

• Berechtigungsmodelle: Tresorzugriffsrichtlinien (Vault access policies, veraltet) vs. Azure RBAC (empfohlen).
  • Zugriffsrichtlinien: Werden pro Tresor definiert; gewähren granulare Berechtigungen für Schlüssel, Geheimnisse und Zertifikate. Am besten geeignet, wenn Sie sehr eng gefasste, objekttypspezifische Laufzeitberechtigungen für eine kleine Anzahl von Prinzipalen benötigen.
  • Azure RBAC: Setzen Sie das Berechtigungsmodell des Tresors auf „Rollenbasierte Zugriffssteuerung in Azure“ (Azure role-based access control), um RBAC-Rollen für die Datenebene zu verwenden. Vorteile: Geltungsbereich auf Abonnement-/Ressourcengruppen-/Tresorebene; PIM-fähige Zuweisungen; zentralisierte Governance und Überprüfung. Empfohlen für neue Bereitstellungen und für administrative Operationen.
• Integrierte Tresorrollen (Beispiele): Key Vault Administrator (vollständige Verwaltung), Key Vault Crypto Officer (Schlüsselverwaltung, aber keine Zugriffsrichtlinien), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Operative Anleitung:
  • Verwenden Sie RBAC (z. B. Key Vault Administrator) bei der Delegierung der Konfiguration von Zugriffsmodellen und Netzwerk-ACLs.
  • Verwenden Sie eine Zugriffsrichtlinie oder eine RBAC-Rolle für die Datenebene wie Key Vault Certificates Officer für das Einfügen/Löschen von Zertifikaten mit den geringsten Rechten (Least Privilege) in einem einzelnen Tresor.
• Design des Geltungsbereichs: Bevorzugen Sie die Zuweisung von RBAC auf Tresorebene, um eine übermäßige Rechtevergabe zu vermeiden. Verwenden Sie den Geltungsbereich der Ressourcengruppe nur, wenn sich mehrere Tresore identische Betreiberteams teilen; vermeiden Sie Zuweisungen auf Abonnementebene für den Laufzeitzugriff.

Managed HSM

• Architektur und Sicherheitsdomänen: Managed HSM ist ein mandantenexklusiver, FIPS 140-2 Level 3 validierter HSM-Cluster pro Kunde. Eine Sicherheitsdomäne schützt die Portabilität des Schlüsselmaterials des Clusters; Backup/Restore über Cluster hinweg erfordert ein Quorum der privaten Schlüssel der Sicherheitsdomäne. Begründung: Generieren und hinterlegen Sie Domänenschlüssel bei unterschiedlichen Verwahrern; testen Sie die Wiederherstellung auf einem DR-HSM.
• Rollenmodell: Integriert mit Azure RBAC. Zu den Rollen gehören Managed HSM Administrator, Crypto Officer, Crypto User und Reader. Funktionstrennung: Administratoren verwalten den Cluster; Crypto Officers verwalten Schlüssel; Crypto Users verwenden Schlüssel für Operationen.
• Hochverfügbarkeit: Regional redundant mit mehreren HSM-Partitionen und einem SLA-gestützten Dienst; Zonenredundanz ist in unterstützten Regionen verfügbar. Für die Notfallwiederherstellung (Disaster Recovery) über Regionen hinweg sollten Sie sich auf Backups und die Sicherheitsdomäne verlassen.
• Anwendungsfälle: Zahlungsabwicklung, Code Signing, Key Wrapping für Envelope Encryption und regulierte Workloads, die Level 3 HSM-Grenzen erfordern.

Objekte und Lebenszyklus: Schlüssel, Geheimnisse, Zertifikate und Rotation

Schlüssel, Geheimnisse, Zertifikate

• Schlüssel: Für kryptografische Operationen (Signieren, Verifizieren, Umschließen/Entschlüsseln, Verschlüsseln/Entschlüsseln). Wählen Sie Schlüsseltyp/-größe basierend auf Algorithmusstärke und Leistung (z. B. RSA 3072/4096 für Compliance oder ECC P-256/P-384 für Leistung).
• Geheimnisse: Beliebige Bytes/Strings wie Passwörter, Verbindungszeichenfolgen und API-Token. Werden nicht für kryptografische Operationen verwendet.
• Zertifikate: X.509 mit privaten Schlüsseln. Gespeichert sowohl als Zertifikatobjekt als auch als entsprechendes Geheimnis (PFX/PEM). Nützlich für TLS/MTLS- und Codesignatur-Lebenszyklen.

Lebenszyklusoperationen und Rotation

• Versionierung: Jedes Setzen oder Importieren erzeugt eine unveränderliche Version. Anwendungen sollten je nach Anforderungen des Änderungsmanagements auf versionierte Geheimnisse für deterministisches Verhalten oder auf versionslose URIs für die automatische Übernahme der neuesten Version verweisen.
• Rotationsstrategien:
  • Schlüssel: Bevorzugen Sie versionslose Schlüssel-URIs für Azure-Dienste, die diese unterstützen (z. B. Storage, SQL TDE, von AKV verwaltete Geheimnisse). Rotieren Sie durch Hinzufügen einer neuen Version; Dienste binden sich bei Unterstützung automatisch neu. Wenn ein Dienst eine fixierte Version erfordert, automatisieren Sie einen Rekonfigurationsschritt. Erzwingen Sie die Rotation mit AKV-Rotationsrichtlinien und Benachrichtigungen.
  • Geheimnisse: Rotieren Sie über Azure Automation, Functions oder Logic Apps, ausgelöst durch Event Grid-Benachrichtigungen, oder nutzen Sie die anbietereigene Rotation (z. B. Rotation von SAS oder Datenbankpasswörtern). Vermeiden Sie langlebige statische Geheimnisse, indem Sie sie wo immer möglich durch verwaltete Identitäten ersetzen.
  • Zertifikate: Definieren Sie Zertifikatsrichtlinien mit „Lebensdaueraktionen“ (lifetime actions) zur automatischen Erneuerung vor Ablauf; nutzen Sie integrierte Aussteller für eine automatische Erneuerung ohne manuellen Eingriff.

Zertifikatsverwaltung

• Import/Generierung: Importieren Sie bestehende PFX/PEM (mit privatem Schlüssel) oder generieren Sie eine CSR und lassen Sie die Ausstellung durch Key Vault mit einer konfigurierten CA abschließen.
• Automatische Erneuerung und Aussteller: Konfigurieren Sie Aussteller wie DigiCert, GlobalSign oder eine unternehmenseigene Microsoft CA über Key Vault. Aktivieren Sie die automatische Erneuerung mit Benachrichtigungs- und Erneuerungsschwellenwerten.
• Anwendungsintegration:
  • App Service und Functions: Verwenden Sie Key Vault-Referenzen mit verwalteter Identität; die Plattform synchronisiert rotierte Geheimnisse automatisch.
  • Application Gateway/WAF: Referenzieren Sie die Zertifikats-Geheimnis-ID aus Key Vault; das Gateway übernimmt neue Versionen automatisch.
  • AKS: Binden Sie Zertifikate über den Secrets Store CSI-Treiber und den Azure Key Vault-Provider ein.

Beispiel für eine RBAC-Zuweisung für Zertifikatsoperationen mit den geringsten Rechten:

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Netzwerksicherheit und Dienstintegration

Key Vault-Netzwerkkonfiguration

• Firewall-Regeln: Auf „Ausgewählte Netzwerke“ (Selected networks) setzen, um auf genehmigte Quellen zu beschränken. Begründung: Verhindert Datenverkehr aus dem Internet, selbst mit gültigen Token.
• Dienstendpunkte für virtuelle Netzwerke: Erlauben Sie Datenverkehr von bestimmten Subnetzen ohne private IPs. Einfach zu aktivieren und reduziert die Angriffsfläche. Verwenden, wenn eine schnelle Isolierung ohne DNS-Änderungen erforderlich ist.
• Private Endpunkte: Weisen Sie dem Tresor in Ihrem VNet eine private IP für echte private Konnektivität zu. Blockieren Sie den öffentlichen Netzwerkzugriff. Begründung: Stärkste Kontrolle gegen Datenexfiltration, erforderlich in Hochsicherheitsumgebungen und bei eingeschränktem ausgehendem Internetverkehr.
• Vertrauenswürdige Dienste: „Vertrauenswürdigen Microsoft-Diensten erlauben“ (Allow trusted Microsoft services) ermöglicht bestimmten Azure-Diensten den Zugriff auf den Tresor trotz Netzwerkbeschränkungen. Erforderlich für Szenarien wie das Scannen von Verschlüsselungsschlüsseln von Storage während der Rotation. Aktivieren Sie dies nur gezielt und dokumentieren Sie die Abhängigkeiten.

Vom Kunden verwaltete Schlüssel (CMK) und Schlüssel-URIs

• Unterstützte Dienste: Azure Storage, SQL Database (TDE), Synapse, Databricks, Verschlüsselung von AKS-Geheimnissen im Ruhezustand (at rest), App Configuration, Event Hubs, Service Bus und Managed Disks über Disk Encryption Set.
• Schlüssel-URI-Strategie:
  • Versionslose URIs: Bevorzugen, wenn der Dienst die automatische Neubindung an neue Schlüsselversionen unterstützt; ermöglicht eine nahtlose Rotation ohne Dienst-Updates.
  • Versionierte URIs: Von einigen Diensten erforderlich; automatisieren Sie ein Update der Dienstkonfiguration, das an Rotationsereignisse gekoppelt ist.
• Rotationsmuster:
  • Gestaffelte Rotation: Neue Schlüsselversion erstellen; validieren, dass der Dienst darauf zugreifen kann; Fehler überwachen; dann optional ältere Versionen nach einer sicheren Zeitspanne deaktivieren.
  • Ereignisgesteuert: Verwenden Sie Event Grid bei „key-new-version“-Ereignissen, um Validierungs- oder Dienst-Rekonfigurations-Workflows auszulösen.

Integration der Umschlagverschlüsselung

• Azure-Dienste verwenden lokal einen Data Encryption Key (DEK) (z. B. AES-256) und einen Key Encryption Key (KEK) in Key Vault/HSM, um den DEK zu umschließen. Stellen Sie im Betrieb die Verfügbarkeit des KEK und den Netzwerkzugriff sicher, da ein Verlust oder blockierter Zugriff den Dienstbetrieb zum Erliegen bringen kann.

Beispiel: Umschließen eines DEK mit einem AKV-Schlüssel

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Kryptografie, Optionen für Daten im Ruhezustand und Geheimnis-Hygiene

Kryptografische Kernkonzepte

• Symmetrische Verschlüsselung: Ein Schlüssel wird zum Ver- und Entschlüsseln verwendet (z. B. AES-GCM/CTR). Schnell; ideal für große Datenmengen.
• Asymmetrische Verschlüsselung: Öffentlich/private Schlüsselpaare (RSA/ECC) werden für den Schlüsselaustausch und Signaturen verwendet. Langsamer; ideal zum Herstellen von Vertrauen und zum Umschließen von DEKs.
• Hashing: Einweg-Digest (z. B. SHA-256). Für Integrität; keine Verschlüsselung.
• Signieren: Privater Schlüssel erzeugt Signatur; öffentlicher Schlüssel verifiziert. Nichtabstreitbarkeit und Integrität.
• Envelope-Verschlüsselung: Kombiniert asymmetrischen KEK mit symmetrischem DEK für Leistung und Trennung der Schlüsselverwahrung.

Azure Disk Encryption und Speicherverschlüsselung

• Standardverschlüsselung für Managed Disks: Serverseitige Verschlüsselung (SSE) mit plattformverwalteten Schlüsseln (PMK). Minimaler Betriebsaufwand.
• CMK mit Disk Encryption Set (DES): Verwenden Sie ein DES, das auf einen Key Vault- oder Managed HSM-Schlüssel verweist, für Datenträger, Snapshots und Images. Begründung: zentrale Kontrolle über den Lebenszyklus und den Widerruf von Schlüsseln; erfüllt Compliance-Anforderungen für die Kundenkontrolle.
• ADE (Azure Disk Encryption): In-Guest BitLocker (Windows) oder dm-crypt (Linux). Zu verwenden, wenn Sie eine Verschlüsselung auf Betriebssystemebene, an die Domäne gebundene Schlüsselschutzmechanismen auf Datenträgerebene oder bestehende Compliance-Vorgaben benötigen. Operativer Kompromiss: höhere Komplexität, Verwaltung von Erweiterungen und potenzielle Auswirkungen auf die VM-Bereitstellung.
• Doppelte Verschlüsselung:
  • Datenträger: Kombinieren Sie SSE mit PMK auf der Infrastrukturebene plus CMK über DES, um zwei unabhängige Verschlüsselungsebenen zu erreichen.
  • Speicherkonten: Verwenden Sie Verschlüsselungsbereiche (Encryption Scopes) mit separaten CMKs pro Container/Workload; kombinieren Sie dies mit der Infrastrukturverschlüsselung, wo verfügbar, um zwei Ebenen zu erhalten.
• Verschlüsselungsbereiche (Encryption Scopes) (Azure Storage): Definieren Sie Bereiche pro Container oder pro Blob mit unterschiedlichen CMKs, um das Mandanten-/Workload-Risiko zu isolieren und eine gezielte Rotation ohne weitreichende Auswirkungen zu ermöglichen.

Geheimnis-Hygiene und operative Praktiken

• Verwaltete Identitäten (Managed Identities): Verwenden Sie system- oder benutzerseitig zugewiesene verwaltete Identitäten für Azure-Ressourcen, um Token für Key Vault und andere Dienste zu erhalten und so eingebettete Anmeldeinformationen zu vermeiden. Definieren Sie den Geltungsbereich von RBAC oder Zugriffsrichtlinien eng.
• Scannen nach Geheimnissen (Secret Scanning): Aktivieren Sie Microsoft Defender for DevOps, GitHub Advanced Security Secret Scanning und Repository-Schutzmaßnahmen. Integrieren Sie dies in Pull Requests, um bekannte Muster von Anmeldeinformationen zu blockieren.
• Pipelines und IaC: Nutzen Sie Key Vault-Task-Integrationen in Azure Pipelines und OIDC-basierte föderierte Anmeldeinformationen in GitHub Actions, um persistente Geheimnisse zu vermeiden. Geben Sie keine Geheimnisse in Protokollen aus; maskieren Sie Ausgaben. Rotieren Sie jegliches durchgesickerte Material sofort.
• App-Design: Bevorzugen Sie versionslose Referenzen, wo dies sicher ist; cachen Sie minimal und behandeln Sie 401/403-Fehler durch erneutes Abrufen von Token und Geheimnissen, um Rotationsereignisse zu unterstützen.

Vertiefung ins Zertifikatsmanagement

• Richtliniengesteuerte Ausstellung: Definieren Sie Antragsteller (Subject), SANs, Schlüsselverwendung, EKUs, Schlüsseltyp/-größe und Einstellungen zur Wiederverwendung von Schlüsseln in einer Key Vault-Zertifikatsrichtlinie. Begründung: konsistente TLS-Konfiguration über alle Umgebungen hinweg.
• Integration von Ausstellern: Konfigurieren Sie ein CA-Profil in Key Vault. Für eine private PKI integrieren Sie Microsoft ADCS über einen benutzerdefinierten Aussteller oder verwenden Sie den Certificate Connector von Azure Key Vault. Öffentliche CAs ermöglichen eine automatisierte Erneuerung, ohne private Schlüssel außerhalb von AKV preiszugeben.
• Automatisierte Erneuerungsvorgänge: Verwenden Sie Lebenszyklusaktionen (z. B. Erneuerung 60 Tage vor Ablauf; Benachrichtigung 90 Tage vorher). Stimmen Sie operativ die Erneuerungsfenster mit Change Freezes ab und stellen Sie sicher, dass abhängige Dienste automatisch synchronisiert werden.
• Nutzung durch Anwendungen: Als Secret (PFX/PEM) abrufen oder per Referenz in Plattformdiensten einbinden. Bevorzugen Sie plattformnative Einbindungen (App Service, Application Gateway) für ein unterbrechungsfreies Rollover auf neue Versionen. Für Kubernetes über CSI einbinden, um bei einer Rotation rollierende Neustarts auszulösen.

Praktisches Problemszenario

Die Siemens AG muss IoT-Telemetriedaten in Azure schützen, eine strenge Schlüsselverwahrung für Data-at-Rest durchsetzen und die Zertifikats- und Secret-Rotation über eine global verteilte Flotte automatisieren.

1. Vaults und HSM-Grenzen festlegen

• Erstellen Sie regionale Premium Key Vaults für Anwendungs-Secrets/Zertifikate und ein Managed HSM für KEK-Operationen.
• Begründung: Premium Vaults ermöglichen bei Bedarf HSM-gestützte Schlüssel; Managed HSM bietet eine Level-3-Sicherheitsstufe und eine unabhängige Schlüsselverwahrung für Wrapping-Vorgänge.

2. Wiederherstellbarkeit und Leitplanken durchsetzen

• Aktivieren Sie den Schutz vor endgültigem Löschen (Purge Protection) für alle Vaults und das Managed HSM; setzen Sie die Aufbewahrungsfrist für vorläufiges Löschen auf 90 Tage. Wenden Sie Azure Policy an, um Vaults ohne Purge Protection zu prüfen/verweigern.
• Begründung: Verhindert katastrophalen Datenverlust durch endgültiges Löschen; Richtlinien stellen sicher, dass keine Abweichungen (Drift) auftreten können.

3. Autorisierung mittels RBAC zentralisieren

• Stellen Sie die Vaults auf das Azure RBAC-Berechtigungsmodell um. Weisen Sie die Rolle „Key Vault-Administrator“ einem kleinen Plattformteam über PIM zu; weisen Sie „Key Vault Secrets Officer“ den Anwendungsteams auf dem Geltungsbereich des Vaults zu; weisen Sie „Managed HSM Crypto Officer“ den Sicherheitsingenieuren zu.
• Begründung: RBAC + PIM führt zu geringsten Rechten (Least Privilege), zeitlich begrenzter Rechteerweiterung und konsistenter Überwachung. Funktionstrennung verhindert, dass Administratoren Schlüssel verwenden können.

4. Netzwerk mit Private Endpoints absichern

• Erstellen Sie Private Endpoints in Hub-VNets; deaktivieren Sie den öffentlichen Netzwerkzugriff. Aktivieren Sie „vertrauenswürdige Dienste“ nur für Storage-Konten, die CMK verwenden.
• Begründung: Private Endpoints eliminieren die öffentliche Verfügbarkeit und blockieren Pfade zur Datenexfiltration, während notwendige Service-zu-Vault-Datenflüsse erhalten bleiben.

5. CMK und Verschlüsselungsstrategie implementieren

• Definieren Sie für Storage Verschlüsselungsbereiche (Encryption Scopes) pro Workload mit versionslosen KEK-URIs im Premium Vault; verwenden Sie für Managed Disks Disk Encryption Sets mit CMK aus dem HSM. Aktivieren Sie die Verschlüsselung auf Infrastrukturebene für eine doppelte Verschlüsselung.
• Begründung: Schlüssel pro Workload reduzieren den potenziellen Schadensradius (Blast Radius); versionslose URIs ermöglichen eine nahtlose Rotation; doppelte Verschlüsselung erfüllt strenge Compliance-Anforderungen.

6. Schlüssel- und Secret-Rotation automatisieren

• Konfigurieren Sie AKV-Schlüsselrotationsrichtlinien (z. B. jährlicher Ablauf, Rotation nach 9 Monaten) und Event Grid-Benachrichtigungen, die Validierungsaufträge auslösen. Verwenden Sie Managed Identities in Diensten; entfernen Sie statische Anmeldeinformationen.
• Begründung: Vorhersehbare, automatisierte Rotation reduziert das Risiko von langlebigen Schlüsseln und Secrets; Managed Identities ersetzen fehleranfällige Shared Secrets.

7. Zertifikate operationalisieren

• Verwenden Sie Key Vault-Zertifikatsrichtlinien mit DigiCert-Ausstellerintegration; stellen Sie die automatische Erneuerung auf 60 Tage vor Ablauf ein. Binden Sie Zertifikate per Referenz in Application Gateway und App Service ein.
• Begründung: Automatisierte Erneuerung verhindert Ausfälle und vermeidet manuelle Schlüsselhandhabung; plattformnative Einbindungen übernehmen neue Versionen ohne Neuauslieferung (Redeployment).

8. Validieren und überwachen

• Aktivieren Sie Diagnoseprotokolle von Key Vault und Managed HSM für Log Analytics; richten Sie Warnungen für unbefugte Zugriffsversuche, Firewall-Ablehnungen und bald ablaufende Ereignisse ein. Führen Sie vierteljährliche Wiederherstellungstests für Vault- und HSM-Backups unter Verwendung des Security Domain Quorums durch.
• Begründung: Kontinuierliche Überwachung erkennt Fehlkonfigurationen oder Angriffe umgehend; Wiederherstellungstests stellen die Wiederherstellbarkeit unter Last sicher.

← Daten- · Alle Domänen · Security Posture Management und Governance →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →