最后审核时间:2026年5月
使用原生 Terraform 构建 SC-900 考试中的 AWS 服务——每次构建一个代码块,并紧扣考试领域。相同的代码可在 OpenTofu 上运行。
在本实验结束时,您将使用纯 Terraform 预配 SC-900 基础安全基线 — 一个 Microsoft Entra 安全组(身份基元)、一个具有 RBAC 授权的 Key Vault、在订阅范围内启用的 Microsoft Defender for Cloud 基础 CSPM,以及一个接收安全遥测数据的 Log Analytics 工作区。四个模块;这是最小且现实的 Microsoft 安全与身份面。
将这些片段放入一个 main.tf 文件中,运行 terraform init,然后逐步运行 terraform apply。
>= 1.5 或 OpenTofu >= 1.6。az login) — 您的登录身份必须具有创建 Entra 组的权限。azuread Terraform 提供程序(与 azurerm 分开)。它使用相同的 az login 会话向 Microsoft Entra ID (Microsoft Graph) 进行身份验证。在此范围内全部免费:
整个堆栈闲置时每月约 $0。SC-900 实验是本次学习中最便宜的,目标是培养概念流畅性,而非昂贵的基础设施。
SC-900 需要与 Microsoft Entra ID 进行交互 — 这与 Azure RBAC 不同,也需要不同的 Terraform 提供程序。我们同时固定 azurerm 和 azuread。后者管理 Entra 用户、组、应用注册和服务主体;前者管理 Azure 订阅和资源。
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 "azuread_client_config" "current" {}
locals {
tags = {
Project = "certlabpro-sc-900"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-sc-900-rg"
location = "eastus"
tags = local.tags
}Microsoft Entra ID(前身为 Azure AD)是每个 Microsoft 云产品都连接到的身份和访问服务。SC-900 的第一个领域 — 描述安全性、合规性和身份的概念 — 将 Entra ID 作为身份基础。
安全组是同时向许多用户授予 RBAC 角色的规范容器。考试将这种基于组的 RBAC 模式作为在数百个用户之间扩展权限的正确答案:将角色分配给组,而不是个人。
security_enabled = true 和 mail_enabled = false 的组合创建了一个仅用于安全用途的组(没有共享邮箱)。将当前用户添加为所有者意味着您可以在 terraform apply 之后通过 Entra 门户管理组成员身份。
resource "azuread_group" "security_admins" {
display_name = "certlabpro-sc-900-security-admins"
description = "Lab security admins group for the SC-900 walkthrough."
security_enabled = true
mail_enabled = false
owners = [
data.azuread_client_config.current.object_id,
]
}SC-900 考察了关注点分离模式:密钥存储在 Key Vault 中;访问权限授予 Entra 组(而非用户);组成员身份在身份层管理。我们预配一个具有 RBAC 授权的 Key Vault,然后将 Key Vault Secrets Officer 角色分配给步骤 2 中的安全组。
任何被添加到安全管理员组的人都会自动继承密钥管理权限。与旧的访问策略模型(其中每个用户都在密钥保管库上单独命名)进行比较 — SC-900 的识别 Microsoft Entra ID 的基本身份服务和身份类型领域将此作为 RBAC 优于策略的现代对比。
resource "azurerm_key_vault" "main" {
name = "kv-sc900-${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
tags = local.tags
lifecycle {
ignore_changes = [name] # name uses uuid() — keep the original on subsequent applies
}
}
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
}
resource "azurerm_role_assignment" "kv_secrets_group" {
scope = azurerm_key_vault.main.id
role_definition_name = "Key Vault Secrets Officer"
principal_id = azuread_group.security_admins.object_id
}Defender for Cloud 的基础 CSPM 层始终免费,并包含 Microsoft 云安全基准评估 — 针对 Microsoft 已移植到 Azure 的 CIS/NIST 控件进行自动化检查。SC-900 的描述 Microsoft 安全解决方案的功能领域指出这是第一天的态势可见性基元。
我们在订阅范围内启用它,并预配一个 Log Analytics 工作区,任何安全警报/建议都会在此处进行 KQL 查询。随着这四个基元(Entra 组、具有 RBAC 的 Key Vault、Defender CSPM、Log Analytics)到位,SC-900 基础堆栈就完成了 — 基于组的身份 → 密钥管理 → 态势监控 → 审计结构。
resource "azurerm_log_analytics_workspace" "main" {
name = "log-sc900"
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"
resource_type = "CloudPosture"
}terraform destroy 会销毁所有资源。Entra 组会立即销毁;任何引用它的 RBAC 分配必须在此之前被移除(Terraform 处理依赖关系图)。Key Vault 具有 7 天的软删除功能;提供程序功能中的 purge_soft_delete_on_destroy = true 会实际清除它。
SC-900 涵盖了许多 Microsoft 安全领域,本实验仅从概念上涉及这些领域 — 条件访问(SC-100 中涵盖)、特权身份管理 (PIM)、身份保护、多重身份验证强制策略、Microsoft Sentinel(SC-200 中涵盖)、Microsoft Defender XDR(跨 Defender for Identity / Endpoint / Office / Cloud Apps 的统一事件视图)、Microsoft Purview(数据治理 + 风险 + 合规性管理器)、内部风险管理、电子发现、通信合规性以及整个 Microsoft 365 合规性中心。
我们坚持使用 Entra 组 + Key Vault RBAC + Defender CSPM + Log Analytics 基元,因为它们是所有更高级的 Microsoft 安全服务的基础。Sentinel 从 Log Analytics 工作区读取数据。条件访问使用 Entra 组进行策略分配。Defender XDR 丰富了 Defender for Cloud 警报。PIM 提升了 Entra 组成员资格。
有关按服务的覆盖范围,请参阅此认证页面的 浏览、手册 和 Editorial 部分。