1. 课程导入与全景认知

当企业把数据仓库、数据湖、实时分析、机器学习特征库逐步迁移到 AWS 之后，安全团队最常遇到的一个尴尬是：云上的资源可以几分钟内创建出来，但“谁可以读哪张表、哪条数据能不能出境、审计日志能不能支撑一次监管检查”这些问题，往往在半年后才被真正追问。数据平台的安全治理不是给 S3 桶加一个加密开关，而是围绕身份、数据、边界、审计、合规证据五条主线，在持续变化的云环境中建立可验证、可追溯、可收敛的控制体系。

一、企业数据平台安全治理的真实挑战

与传统 IDC 相比，云上数据平台的安全边界发生了三个根本变化。第一，边界从网络设备转移到身份与策略。一个 S3 桶是否公开，取决于 Bucket Policy、IAM Policy、Access Point、Block Public Access 四层叠加后的最终结果，而不是某台防火墙的规则。第二，数据流动路径变长。一条数据可能从 Kinesis 进入 S3，被 Glue 爬取后写入 Redshift，再被 Athena 查询、被 SageMaker 读取，每一跳都涉及不同的权限主体与加密上下文。第三，合规证据必须持续生成。监管检查不会只看某一天的截图，而要求证明“过去 12 个月内，所有对敏感数据的访问都被记录且不可篡改”。

由此衍生出四类高频问题：权限过度授予（如开发角色长期持有 s3:*）、敏感数据未分类导致加密与脱敏策略无法精准落地、跨账号与跨区域访问缺少统一审计视图、以及合规要求（如等保、GDPR、PCI DSS）与云原生控制项之间缺少映射关系。这些问题共同指向一个结论：数据平台安全治理必须从“资源加固”升级为“治理框架 + 持续运营”。

二、AWS 责任共担模型在数据平台中的具体切分

AWS 责任共担模型常被简化为“AWS 负责云的安全，客户负责云中的安全”，但在数据平台场景中，这条分界线需要落到具体组件上才具有指导意义。以 Amazon S3 为例：AWS 负责物理机房、存储介质销毁、S3 服务自身的高可用与加密算法实现；客户负责 Bucket Policy 编写、对象级 ACL 管理、版本控制与生命周期策略、以及是否启用 SSE-KMS 并管理 KMS 密钥策略。以 Amazon RDS 为例：AWS 负责数据库引擎补丁的底层宿主维护与多可用区故障切换；客户负责数据库账号权限、参数组中的 rds.force_ssl、快照共享范围以及审计日志是否开启。

理解这一模型的关键在于：责任共担不是责任转移。即使 AWS 提供了 Macie 自动发现敏感数据，客户仍需决定哪些发现结果触发阻断、哪些仅记录告警。下图展示了数据平台典型组件在责任共担模型中的控制归属，帮助在后续章节中快速定位“这项控制该由谁配置、由谁验证”。

三、合规落地的核心框架：从控制项到证据链

合规落地最容易失败的方式，是拿一份监管条款清单逐条“打勾”。更有效的做法是建立三层映射：监管要求 → AWS 控制项 → 可验证证据。例如 PCI DSS 要求“对持卡人数据的访问进行记录与监控”，对应到 AWS 控制项是 CloudTrail 数据事件 + S3 访问日志 + GuardDuty 异常检测，可验证证据则是“CloudTrail 日志已开启对象级记录、日志存储桶启用了 Object Lock、过去 90 天无未授权访问告警”。

在这个框架下，数据平台的安全治理通常收敛为五个可运营的域：身份与权限治理（IAM 角色、权限边界、SCP）、数据保护（分类分级、KMS 加密、脱敏与令牌化）、网络与边界（VPC 端点、PrivateLink、安全组）、检测与响应（GuardDuty、Security Hub、Config 规则）、审计与合规证据（CloudTrail、Config 快照、审计报告自动化）。这五个域不是并列的，而是以身份为入口、以数据为中心、以审计为闭环。

四、学习路径与本章定位

本课程后续 29 章将沿着上述五个域展开，但不会按“先讲 IAM 再讲 S3”的平铺方式推进，而是以真实治理任务为线索：先建立身份与权限的最小权限基线，再处理敏感数据发现与加密，接着打通跨账号审计，最后把控制项映射为可持续输出的合规证据。每一章都会给出可操作的配置片段、判断依据与验证方法。

作为导入章，本节需要你先建立一个全景认知：数据平台安全治理的难点不在单点技术，而在“控制项之间的依赖关系”和“证据的持续生成”。例如，若未先完成数据分类，加密策略就只能全桶统一加密，无法对高敏感数据启用更严格的 KMS 密钥策略；若未先统一 CloudTrail 到集中账号，后续的跨账号访问审计就缺少数据源。理解这些依赖顺序，比记住某个 API 名称更重要。