📚 课程目录第1章 Azure数据安全全景

1. Azure数据安全全景

在Azure上做数据安全，第一件必须厘清的事不是“开哪个功能”，而是“这块责任到底归谁”。很多团队把数据放进Azure SQL Database或Storage Account后，默认认为微软已经替自己把安全做完了，结果在审计时才发现：加密、备份、网络隔离这些底层能力确实由微软提供，但“谁可以访问、访问什么数据、访问后留下什么痕迹”几乎全部由租户自己负责。这就是责任共担模型（Shared Responsibility Model）要解决的核心认知问题。

责任共担模型：边界在哪里

责任共担模型把云安全责任划分为三层：云提供方始终负责的物理安全、主机、网络、数据中心；租户始终负责的信息与数据、账户与身份、终端设备；而随服务模型变化的中间层，则取决于IaaS、PaaS还是SaaS。以三种典型服务为例：

IaaS（如虚拟机）：客户负责操作系统、运行时、中间件、应用和数据；微软只负责虚拟化层以下。
PaaS（如Azure SQL Database、Azure Storage）：微软负责OS、运行时、数据库引擎本身；客户负责数据分类、身份、权限、网络访问规则和审计。
SaaS（如Microsoft 365）：微软负责应用逻辑与基础设施；客户仍负责账号治理、数据分类、共享策略和合规配置。

关键结论是：无论哪种模型，数据本身、身份和数据访问权限始终属于客户责任。这意味着“数据安全”在Azure上不是买一个服务，而是围绕数据、身份、网络、审计四条线持续运营。

数据安全生命周期：从创建到销毁的六个阶段

数据安全生命周期通常划分为六个阶段：创建（Create）→ 存储（Store）→ 使用（Use）→ 共享（Share）→ 归档（Archive）→ 销毁（Destroy）。每个阶段都有对应的Azure控制点：

阶段	典型风险	Azure控制点示例
创建	敏感数据未分类即入库	Microsoft Purview敏感信息类型、数据分类标签
存储	静态数据明文、密钥管理混乱	Storage Service Encryption、Azure Key Vault、CMK
使用	过度权限、越权查询	Azure RBAC、Microsoft Entra ID条件访问
共享	匿名链接、外部租户访问	共享访问签名（SAS）、私有终结点、B2B协作策略
归档	冷数据被遗忘、保留策略缺失	Blob访问层、不可变存储、保留锁
销毁	软删除残留、备份未清理	软删除、清除保护、生命周期管理策略

生命周期视角的价值在于：它把“安全”从单点配置变成一条链。任何一环缺失，都会让前面的投入失效。例如，即使启用了CMK加密，如果共享阶段生成了长期有效的匿名SAS，数据仍可能被外部读取。

访问控制基本概念：认证、授权、审计

访问控制可以拆成三个连续动作：认证（Authentication）→ 授权（Authorization）→ 审计（Auditing）。认证回答“你是谁”，授权回答“你能做什么”，审计回答“你做过什么”。在Azure中，这三者分别对应：

认证：Microsoft Entra ID（原Azure AD）负责身份验证，支持MFA、条件访问、无密码登录。
授权：Azure RBAC在管理平面控制“能否管理资源”，数据平面则用服务自身权限模型（如Storage的SAS、SQL的数据库角色）。
审计：Azure Monitor、Activity Log、诊断设置、Microsoft Defender for Cloud提供日志与告警。

这里最容易混淆的是管理平面与数据平面的区别。管理平面指通过Azure Resource Manager操作资源本身（如创建存储账户、修改配置）；数据平面指直接读写数据（如上传Blob、查询表）。一个用户拥有“存储账户参与者”角色，只能管理账户配置，默认不能读取Blob数据；反之，一个SAS令牌可以读Blob，却不能修改账户配置。理解这条边界，是设计最小权限的前提。

实战环境搭建：最小可用实验环境

为了后续章节能直接动手，这里搭建一个最小实验环境。假设使用一个测试订阅，区域选择“东亚”，资源组命名为rg-datasec-lab。以下命令使用Azure CLI，示例参数均为教学假设值，实际执行时请替换为你的订阅ID和唯一名称。

# 登录并设置订阅
az login
az account set --subscription "<你的订阅ID>"

# 创建资源组
az group create --name rg-datasec-lab --location eastasia

# 创建存储账户（名称全局唯一，仅小写字母和数字）
az storage account create \
  --name stdataseclab001 \
  --resource-group rg-datasec-lab \
  --location eastasia \
  --sku Standard_LRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

# 创建Azure SQL Server与示例数据库
az sql server create \
  --name sql-datasec-lab-001 \
  --resource-group rg-datasec-lab \
  --location eastasia \
  --admin-user sqladmin \
  --admin-password "<强密码>"

az sql db create \
  --resource-group rg-datasec-lab \
  --server sql-datasec-lab-001 \
  --name db-lab \
  --service-objective Basic

创建完成后，建议立即做三件事验证环境是否符合安全基线：第一，在存储账户“配置”中确认“允许Blob公共访问”为“已禁用”；第二，在SQL Server“安全性→防火墙和虚拟网络”中确认没有0.0.0.0-255.255.255.255这类全开放规则；第三，在“Microsoft Entra ID→属性”中确认已启用安全默认值或条件访问策略。这三项检查分别对应网络暴露面、数据公开面和身份基线，是后续所有实验的起点。