ハンズオンラボ — SC-100 Microsoft Cybersecurity Architect

概要

前提条件

ステップ

1. 1.プロバイダー、リソースグループ、命名

   標準的なAzureのオープナーと、条件付きアクセスのためのazureadプロバイダー。

   コピー

   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.条件付きアクセス ポリシーのスタブを作成する (ゼロトラストIDゲート)

   プロビジョニング対象:

   • Microsoft Entra ID

   条件付きアクセスは、SC-100のゼロトラストのIDプリミティブです。明示的に検証する、つまり、すべてのアクセス要求は、許可される前にコンテキスト（ユーザー、デバイス、場所、アプリ、リスク）に対して評価されます。ここでは、レポート専用モードでポリシーを作成し、「すべてのクラウドアプリにアクセスするすべてのユーザーに対してMFAを要求する」とします。レポート専用モードとは、ポリシーが強制された場合に何が起こるかをログに記録することを意味します。これは、CAポリシーを有効にする前にSC-100が推奨するパスです。

   実際のゼロトラストアーキテクチャでは、リスクベース、場所ベース、デバイスコンプライアンスベース、セッションコントロールなど、多くのCAポリシーを重ねて適用します。このスタブはその形を示し、SC-100の「特権アクセスの保護戦略を設計する」ドメインでは、階層型ポリシーの構成がテストされます。

   コピー

   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をオンボードする

   プロビジョニング対象:

   • Microsoft Defender for Cloud
   • Microsoft Sentinel

   SC-100の「ガバナンス、リスク、コンプライアンス（GRC）の技術戦略を評価する」では、これら2つのサービスの二重目的がテストされます。Defender for Cloudは態勢層（継続的なコンプライアンス評価、セキュリティ推奨事項）であり、Sentinelは検出層（KQLハンティング、インシデント対応）です。両者を合わせることで、「ゼロトラスト環境のセキュリティ監視をどのようにアーキテクトするか？」というマイクロソフトの答えとなります。

   ここでは、両方を単一のLog Analyticsワークスペースにオンボードします。これは、コスト効率のためのSC-100リファレンスアーキテクチャであり、データは一度着地し、両方のサービスが同じストアから読み取ります。

   コピー

   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.サブスクリプションスコープで「ストレージにはHTTPSが必要」を強制するAzure Policyを割り当てる

   プロビジョニング対象:

   • Azure Policy

   Azure Policyは、SC-100の「ガバナンスとコンプライアンスの戦略を設計する」プリミティブであり、スコープ内のすべてのリソースに対してルールを強制します。ここでは、組み込みポリシーであるSecure transfer to storage accounts should be enabledをサブスクリプションスコープでeffect = Denyとして割り当てます。これにより、HTTPを許可する新しいストレージアカウントの作成が阻止されます。この試験では、このDenyAssignmentとAuditの区別がテストされます。Denyは不正な構成の発生を防ぎますが、Auditは事後にそれを警告するだけです。

   これが強制するゼロトラストの原則は、既定で転送中に暗号化するであり、SC-100試験の繰り返しテーマの1つです。実際のゼロトラスト展開では、ポリシーイニシアティブ（ポリシーのグループ）を使用して、一度に数十のコントロールを強制します。これは、実証可能な最小の形です。

   コピー

   # 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.アーキテクチャのシークレット層としてKey Vaultをプロビジョニングする

   プロビジョニング対象:

   • Azure Key Vault

   ゼロトラストアーキテクチャでは、シークレットを要塞化されたボールトに一元化します。これはRBACのみで、管理者キーのショートカットはなく、論理削除とパージ保護が有効になっています。ラボのクリーンアップを容易にするため、ここではパージ保護を無効にしてボールトをプロビジョニングします。本番環境では、SC-100が推奨するすべてのボールトでpurge_protection_enabled = trueを設定し、標準の「回復不能な削除が必要」というコンプライアンス要件を満たします。

   5つのブロック（ID用の条件付きアクセス、態勢と検出用のDefender + Sentinel、ガードレール用のAzure Policy、シークレット用のKey Vault）が揃い、SC-100のゼロトラストの足場が形成されます。追加のSC-100アーキテクチャパターン（ジャストインタイム昇格のためのPrivileged Identity Management、データ分類のためのMicrosoft Purview、統合脅威保護のためのDefender XDR）はすべて、この基盤の上に階層化されます。

   コピー

   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
   }

クリーンアップ