Praxislabor — SC-100 Microsoft Cybersecurity Architect

Übersicht

Voraussetzungen

Schritte

1. 1.Provider, Ressourcengruppe, Benennung

   Standard Azure-Eröffnung + der azuread-Provider für Conditional Access.

   Kopieren

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
       azuread = { source = "hashicorp/azuread", version = "~> 3.0" }
     }
   }
   
   provider "azurerm" {
     features {
       key_vault {
         purge_soft_delete_on_destroy = true
       }
     }
   }
   
   provider "azuread" {}
   
   data "azurerm_client_config" "current" {}
   data "azurerm_subscription" "current" {}
   
   locals {
     tags = {
       Project   = "certlabpro-sc-100"
       ManagedBy = "terraform"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-sc-100-rg"
     location = "eastus"
     tags     = local.tags
   }

2. 2.Einen Conditional Access Policy-Stub erstellen (Zero Trust Identitäts-Gateway)

   Ressourcen:

   • Microsoft Entra ID

   Conditional Access ist das SC-100 Zero Trust Identitäts-Grundprinzip: explizit verifizieren – jede Zugriffsanforderung wird anhand des Kontexts (Benutzer, Gerät, Standort, App, Risiko) bewertet, bevor sie gewährt wird. Wir erstellen eine Richtlinie im reinen Berichtsmodus, die besagt: „Für alle Benutzer, die auf alle Cloud-Apps zugreifen, ist MFA erforderlich“. Der reine Berichtsmodus bedeutet, dass die Richtlinie protokolliert, was passieren würde, wenn sie erzwungen würde – der von SC-100 empfohlene Pfad, bevor eine CA-Richtlinie auf aktiviert gesetzt wird.

   Echte Zero Trust-Architekturen stapeln viele CA-Richtlinien – risikobasiert, standortbasiert, gerätekonformitätsbasiert, sitzungsgesteuert. Dieser Stub ist die Form; der SC-100-Bereich Eine Strategie zur Absicherung des privilegierten Zugriffs entwerfen testet die Zusammensetzung der geschichteten Richtlinien.

   Kopieren

   resource "azuread_conditional_access_policy" "require_mfa_report" {
     display_name = "certlabpro-sc-100-require-mfa-report-only"
     state        = "enabledForReportingButNotEnforced"
   
     conditions {
       client_app_types = ["all"]
   
       users {
         included_users = ["All"]
       }
   
       applications {
         included_applications = ["All"]
       }
     }
   
     grant_controls {
       operator          = "OR"
       built_in_controls = ["mfa"]
     }
   }

3. 3.Defender for Cloud Foundational CSPM + Microsoft Sentinel einbinden

   Ressourcen:

   • Microsoft Defender for Cloud
   • Microsoft Sentinel

   SC-100 Technische Strategien für Governance, Risiko und Compliance (GRC) bewerten prüft den doppelten Zweck dieser beiden Dienste: Defender for Cloud ist die Posture-Schicht (kontinuierliche Compliance-Bewertung, Sicherheitsempfehlungen); Sentinel ist die Erkennungs-Schicht (KQL-Hunting, Incident Response). Zusammen bilden sie die Microsoft-Antwort auf die Frage: „Wie gestalte ich die Sicherheitsbeobachtbarkeit für eine Zero Trust-Umgebung?‟.

   Wir binden beide in einen einzigen Log Analytics Workspace ein – die SC-100-Referenzarchitektur für Kosteneffizienz (Daten landen einmal, beide Dienste lesen aus demselben Speicher).

   Kopieren

   resource "azurerm_log_analytics_workspace" "main" {
     name                = "log-sc100"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     sku                 = "PerGB2018"
     retention_in_days   = 30
   
     tags = local.tags
   }
   
   resource "azurerm_security_center_subscription_pricing" "cspm" {
     tier          = "Free" # Foundational CSPM
     resource_type = "CloudPosture"
   }
   
   resource "azurerm_sentinel_log_analytics_workspace_onboarding" "main" {
     workspace_id = azurerm_log_analytics_workspace.main.id
   }

4. 4.Eine Azure Policy zuweisen, die 'Speicher erfordert HTTPS' auf Abonnementebene durchsetzt

   Ressourcen:

   • Azure Policy

   Azure Policy ist das SC-100 Entwerfen einer Strategie für Governance und Compliance-Grundprinzip – es erzwingt Regeln für jede Ressource in einem Bereich. Wir weisen die integrierte Richtlinie Sichere Übertragung zu Speicherkonten sollte aktiviert sein auf Abonnementebene mit effect = Deny zu, was die Erstellung jedes neuen Speicherkontos verhindert, das HTTP zulässt. Die Prüfung testet diese Unterscheidung DenyAssignment vs Audit: Deny verhindert, dass die schlechte Konfiguration überhaupt erst zustande kommt; Audit markiert sie nur im Nachhinein.

   Das Zero Trust-Prinzip, das hier durchgesetzt wird, ist standardmäßig während der Übertragung verschlüsseln – eines der wiederkehrenden SC-100-Prüfungsthemen. Echte Zero Trust-Implementierungen verwenden Richtlinieninitiativen (Gruppen von Richtlinien), um Dutzende von Kontrollen gleichzeitig durchzusetzen; dies ist die kleinste demonstrierbare Form.

   Kopieren

   # Look up the built-in policy definition by name.
   data "azurerm_policy_definition" "storage_https" {
     display_name = "Secure transfer to storage accounts should be enabled"
   }
   
   resource "azurerm_subscription_policy_assignment" "storage_https" {
     name                 = "certlabpro-sc-100-storage-https"
     display_name         = "Storage accounts must require HTTPS"
     description          = "Enforces secure transfer (HTTPS-only) on all storage accounts in the subscription."
     policy_definition_id = data.azurerm_policy_definition.storage_https.id
     subscription_id      = data.azurerm_subscription.current.id
   
     # The built-in policy defaults to Audit; force Deny for Zero Trust enforcement.
     parameters = jsonencode({
       effect = {
         value = "Deny"
       }
     })
   }

5. 5.Einen Key Vault als Geheimnisschicht der Architektur bereitstellen

   Ressourcen:

   • Azure Key Vault

   Zero Trust-Architekturen zentralisieren Geheimnisse in einem gehärteten Tresor – nur RBAC, keine Admin-Key-Verknüpfungen, Soft-Delete + Purge-Schutz aktiviert. Wir stellen den Tresor mit deaktiviertem Purge-Schutz bereit, um die Bereinigung des Labs zu erleichtern; in der Produktion hat jeder von SC-100 empfohlene Tresor purge_protection_enabled = true, um die standardmäßigen Compliance-Anforderungen für „unwiederbringliche Löschung erforderlich“ zu erfüllen.

   Mit den fünf Blöcken (Conditional Access für Identität, Defender + Sentinel für Posture und Erkennung, Azure Policy für Guardrails, Key Vault für Geheimnisse) ist das SC-100 Zero Trust-Gerüst geformt. Jedes weitere SC-100-Architekturmuster (Privileged Identity Management für Just-in-Time-Erhöhung, Microsoft Purview für Datenklassifizierung, Defender XDR für vereinheitlichten Bedrohungsschutz) baut auf dieser Basis auf.

   Kopieren

   resource "azurerm_key_vault" "main" {
     name                       = "kv-sc100-${substr(replace(uuid(), "-", ""), 0, 6)}"
     resource_group_name        = azurerm_resource_group.main.name
     location                   = azurerm_resource_group.main.location
     tenant_id                  = data.azurerm_client_config.current.tenant_id
     sku_name                   = "standard"
     enable_rbac_authorization  = true
     soft_delete_retention_days = 7
     purge_protection_enabled   = false # set true in production for compliance
   
     tags = local.tags
   
     lifecycle {
       ignore_changes = [name]
     }
   }
   
   resource "azurerm_role_assignment" "kv_admin_self" {
     scope                = azurerm_key_vault.main.id
     role_definition_name = "Key Vault Administrator"
     principal_id         = data.azurerm_client_config.current.object_id
   }

Bereinigung