Atelier pratique — SC-100 Microsoft Cybersecurity Architect

Présentation

Prérequis

Étapes

1. 1.Fournisseur, Groupe de ressources, dénomination

   Ouverture Azure standard + le fournisseur azuread pour l'Accès Conditionnel.

   Copier

   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.Créer un modèle de stratégie d'Accès Conditionnel (passerelle d'identité Zero Trust)

   Déploie :

   • Microsoft Entra ID

   L'Accès Conditionnel est la primitive d'identité Zero Trust du SC-100 : vérifier explicitement — chaque demande d'accès est évaluée en fonction du contexte (utilisateur, appareil, emplacement, application, risque) avant d'être accordée. Nous créons une stratégie en mode rapport uniquement qui stipule « pour tous les utilisateurs accédant à toutes les applications cloud, exiger la MFA ». Le mode rapport uniquement signifie que la stratégie enregistre ce qui se produirait si elle était appliquée — le chemin recommandé par le SC-100 avant de basculer une stratégie d'Accès Conditionnel en mode activé.

   Les architectures Zero Trust réelles empilent de nombreuses stratégies d'Accès Conditionnel — basées sur les risques, basées sur l'emplacement, basées sur la conformité des appareils, avec contrôle de session. Ce modèle en est la forme ; le domaine SC-100 Concevoir une stratégie pour sécuriser l'accès privilégié teste la composition des stratégies en couches.

   Copier

   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.Intégrer Defender for Cloud CSPM Fondamental + Microsoft Sentinel

   Déploie :

   • Microsoft Defender for Cloud
   • Microsoft Sentinel

   SC-100 Évaluer les stratégies techniques de Gouvernance, Risque et Conformité (GRC) teste la double finalité de ces deux services : Defender for Cloud est la couche de posture (évaluation continue de la conformité, recommandations de sécurité) ; Sentinel est la couche de détection (recherche KQL, réponse aux incidents). Ensemble, ils constituent la réponse de Microsoft à la question « comment concevoir l'observabilité de la sécurité pour un environnement Zero Trust ? ».

   Nous intégrons les deux à un seul espace de travail Log Analytics — l'architecture de référence SC-100 pour l'efficacité des coûts (les données atterrissent une fois, les deux services lisent à partir du même magasin).

   Copier

   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.Attribuer une Azure Policy imposant 'le stockage requiert HTTPS' au niveau de l'abonnement

   Déploie :

   • Azure Policy

   Azure Policy est la primitive SC-100 Concevoir une stratégie de gouvernance et de conformité — elle applique des règles à chaque ressource dans une portée. Nous attribuons la stratégie intégrée Secure transfer to storage accounts should be enabled au niveau de l'abonnement avec effect = Deny, ce qui empêche la création de tout nouveau compte de stockage autorisant le HTTP. L'examen teste cette distinction Refuser (DenyAssignment) vs Auditer (Audit) : Refuser empêche la mauvaise configuration de se produire ; Auditer ne la signale qu'après coup.

   Le principe Zero Trust que cela impose est chiffrer en transit par défaut — l'un des thèmes récurrents de l'examen SC-100. Les déploiements Zero Trust réels utilisent des initiatives de stratégie (groupes de stratégies) pour imposer des dizaines de contrôles à la fois ; c'est la forme la plus petite et démontrable.

   Copier

   # 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.Provisionner un Key Vault comme couche de secrets de l'architecture

   Déploie :

   • Azure Key Vault

   Les architectures Zero Trust centralisent les secrets dans un coffre-fort renforcé — RBAC uniquement, pas de raccourcis de clé d'administrateur, suppression logicielle + protection contre la purge activées. Nous provisionnons le coffre-fort avec la protection contre la purge désactivée pour faciliter le nettoyage du labo ; en production, chaque coffre-fort recommandé par le SC-100 a purge_protection_enabled = true pour répondre aux exigences de conformité standard de 'suppression irrécupérable requise'.

   Avec les cinq blocs en place (Accès Conditionnel pour l'identité, Defender + Sentinel pour la posture et la détection, Azure Policy pour les garde-fous, Key Vault pour les secrets), l'échafaudage Zero Trust SC-100 est constitué. Chaque modèle architectural SC-100 supplémentaire (Privileged Identity Management pour l'élévation juste-à-temps, Microsoft Purview pour la classification des données, Defender XDR pour la protection unifiée contre les menaces) s'appuie sur cette base.

   Copier

   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
   }

Nettoyage