Laboratório prático — SC-100 Microsoft Cybersecurity Architect

Visão geral

Pré-requisitos

Passos

1. 1.Provedor, Grupo de Recursos, nomenclatura

   Abertura padrão do Azure + o provedor azuread para Acesso Condicional.

   Copiar

   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.Criar um stub de política de Acesso Condicional (portão de identidade Zero Trust)

   Provisiona:

   • Microsoft Entra ID

   Acesso Condicional é a primitiva de identidade Zero Trust do SC-100: verificar explicitamente — cada solicitação de acesso é avaliada contra o contexto (usuário, dispositivo, localização, aplicativo, risco) antes de ser concedida. Criamos uma política em modo somente relatório que diz "para todos os usuários acessando todos os aplicativos de nuvem, exigir MFA". Somente relatório significa que a política registra o que aconteceria se fosse aplicada — o caminho recomendado pelo SC-100 antes de mudar uma política de CA para habilitada.

   Arquiteturas Zero Trust reais empilham muitas políticas de CA — baseadas em risco, localização, conformidade de dispositivo, controle de sessão. Este stub é a forma; o domínio Projetar uma estratégia para proteger acesso privilegiado do SC-100 testa a composição de políticas em camadas.

   Copiar

   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.Integrar Defender para Nuvem CSPM Fundamental + Microsoft Sentinel

   Provisiona:

   • Microsoft Defender for Cloud
   • Microsoft Sentinel

   O SC-100 Avaliar estratégias técnicas de Governança, Risco e Conformidade (GRC) testa o duplo propósito desses dois serviços: o Defender para Nuvem é a camada de postura (avaliação contínua de conformidade, recomendações de segurança); o Sentinel é a camada de detecção (KQL hunting, resposta a incidentes). Juntos, eles são a resposta da Microsoft para "como arquitetar a observabilidade de segurança para um ambiente Zero Trust?".

   Integramos ambos em um único workspace do Log Analytics — a arquitetura de referência do SC-100 para eficiência de custos (os dados chegam uma vez, ambos os serviços leem do mesmo armazenamento).

   Copiar

   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.Atribuir uma Política do Azure que impõe 'armazenamento requer HTTPS' no escopo da assinatura

   Provisiona:

   • Azure Policy

   A Política do Azure é a primitiva Projetar uma estratégia para governança e conformidade do SC-100 — ela impõe regras em todos os recursos em um escopo. Atribuímos a política interna Secure transfer to storage accounts should be enabled no escopo da assinatura com effect = Deny, o que impede a criação de qualquer nova conta de armazenamento que permita HTTP. O exame testa essa distinção Atribuição de Negação vs Auditoria: Negar impede que a configuração incorreta aconteça; Auditar apenas a sinaliza após o fato.

   O princípio Zero Trust que isso impõe é criptografar em trânsito por padrão — um dos temas recorrentes do exame SC-100. Implementações reais de Zero Trust usam Iniciativas de Política (grupos de políticas) para aplicar dezenas de controles de uma vez; esta é a menor forma demonstrável.

   Copiar

   # 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.Provisionar um Key Vault como a camada de segredos da arquitetura

   Provisiona:

   • Azure Key Vault

   Arquiteturas Zero Trust centralizam segredos em um vault endurecido — somente RBAC, sem atalhos de chave de administrador, soft-delete + proteção contra purga ativados. Provisionamos o vault com proteção contra purga desativada para conveniência da limpeza do laboratório; em produção, todo vault recomendado pelo SC-100 tem purge_protection_enabled = true para atender aos requisitos de conformidade padrão 'excluir de forma irrecuperável'.

   Com os cinco blocos em vigor (Acesso Condicional para identidade, Defender + Sentinel para postura e detecção, Política do Azure para guardrails, Key Vault para segredos), o arcabouço Zero Trust do SC-100 está formado. Cada padrão arquitetônico SC-100 adicional (Privileged Identity Management para elevação just-in-time, Microsoft Purview para classificação de dados, Defender XDR para proteção unificada contra ameaças) se sobrepõe a esta base.

   Copiar

   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
   }

Limpeza