安全与隐私

一句话

你以为数据安全靠的是更强的技术——更好的加密、更贵的防火墙，其实大多数泄露来自人和流程：写进代码的凭证、人人都有的管理员权限、一个设成公开的存储桶。本章要建立三条认知：安全是数据工程的底层关注点，贯穿生命周期每一站；防线按人 → 流程 → 技术三层搭，最弱的一环通常是人；做法上要的是日常习惯而不是合规表演，核心是最小权限、少采集敏感数据、及时打补丁、留好备份。

Glossary · 术语表

坐标

Part III「安全、隐私与未来」的第一章。前面九章走完了生命周期（生成 → 存储 → 采集 → 转换 → 服务），第 2 章把安全列为六大底层关注点（undercurrents）之首；本章把这条横切线单独拎出来讲透，下接第 11 章「数据工程的未来」。现实里对应数仓权限设计、密钥管理、云账号治理与 GDPR 一类合规。

这章要解决什么

设想一家年 GMV 百亿级的电商：数仓里有 2 亿用户的订单、手机号和收货地址；40 个分析师和数据科学家，为了省事全都是数仓管理员；Airflow 任务和 Notebook 里明文写着数据库密码；一个装导出文件的存储桶为了方便合作方下载，设成了公开读；备份？「云厂商应该有吧」。这套系统平时运转良好，直到某天：

• 一次钓鱼就全盘失守。任何一个人的账号被骗走，攻击者拿到的就是整个数仓。
• 一段代码就是一把钥匙。仓库被公开或被 fork，密码随之外泄。
• 一个配置就是一次泄露。公开的桶会被自动化扫描器找到，不需要任何「黑客技术」。
• 一次勒索就是一次停业。没有独立备份，只能在付赎金和丢数据之间选。

除了直接损失，还有法规：欧盟 GDPR 对严重违规的罚款上限是全球年营业额的 4% 或 2000 万欧元（取高者），美国加州有 CCPA，医疗数据有 HIPAA。作者的提醒是：数据工程师经手的正是这些法规要保护的数据，你不能假设「安全是别人的事」。

核心内容，讲透

作者把本章按人、流程、技术三层组织。顺序本身就是观点：技术防线再厚，也挡不住一个把密码告诉陌生人的员工。

一、人：消极思维的力量，保持多疑

往坏处想（the power of negative thinking）。作者主张在设计每条管道时先演一遍「出事」：这份数据泄露了会怎样？谁能拿到？由此得出本章最实用的一句判据：保护敏感数据的最好办法，是一开始就不采集它。分析留存率用不到身份证号，就在采集端把它挡掉或脱敏，而不是先收进来再想办法藏。

保持多疑（always be paranoid）。有人通过邮件、电话或聊天要凭证、要导出数据，哪怕看起来来自高管，也通过另一条可信渠道核实。社会工程学（social engineering，利用人的信任而非系统漏洞骗取访问）之所以有效，正因为它绕过了所有技术防线。

二、流程：安全剧场 vs 安全习惯，主动安全

安全剧场（security theater）是作者批评的反面：为合规审计准备漂亮的文档、每年签一次安全承诺书、勾完检查表就算完事，而真实做法毫无变化。安全习惯（security habit）则是把安全写进日常：代码评审里看权限、上线前查配置、定期复盘。

主动安全（active security）：不照搬一份静态清单，而是持续研究「针对你们组织的威胁」——你们用什么系统、员工常在哪里被钓鱼、最近同类公司出了什么事，再据此调整。

三、流程：最小权限

最小权限原则（principle of least privilege）：每个人和每个系统只拿完成当下工作所需的权限，用完就收回。作者特别指出两个常见反例：图省事直接给管理员角色、日常用 root 身份操作。它同样适用于数据：分析师能查订单汇总，不代表能看手机号明细；可以只开放某几列、某几行，或给出脱敏后的视图。

真要临时看敏感数据怎么办？书里给的思路是「破窗」流程（break-glass）：像击碎玻璃取消防斧——提出申请、经过审批、限定时长、全程留痕，到期自动收回。

四、流程：云上共担责任、永远备份

共担责任模型（shared responsibility model）：云厂商负责「云本身」的安全（机房、硬件、虚拟化层），你负责「云里面」的安全（账号权限、网络规则、存储桶是否公开、数据是否加密）。作者强调，许多云上数据泄露都源于用户自己的配置错误，而不是云厂商被攻破。

永远备份（always back up your data）：数据会因误删、硬件故障丢失，也会被勒索软件加密。作者的要求是定期备份，并且定期演练恢复——没恢复过的备份，不能算备份。

五、流程：一份示例安全策略

书里给了一份可直接照抄的最小策略，分三块。保护凭证：尽量用单点登录（SSO）和多因素认证（MFA，登录时除了密码还要手机验证码等第二样东西）；用云的 IAM 角色代替长期密钥；凭证放进密钥管理服务（secret manager），绝不写进代码。保护设备：统一设备管理、能远程擦除丢失的电脑、自动锁屏。软件更新：浏览器、操作系统和依赖及时更新。

六、技术：补丁、加密、监控、网络

打补丁与更新。操作系统、数据库、开源依赖都会爆出漏洞，拖着不升级，就是把已知的门开着。

加密不是银弹。静态加密与传输加密如今是基线，云服务大多默认开启；但作者提醒，它只防「磁盘被拿走、链路被窃听」，挡不住拿着合法凭证登录的人——员工账号被盗时，数据会被正常地解密给攻击者看。

日志、监控与告警，作者点了四类信号：访问（谁在什么时候从哪里登录、查了什么）；资源（磁盘、CPU、内存异常飙升，可能是被挖矿或在拖库）；账单（云账单突然暴涨，常是入侵的第一个信号）；过度权限（长期不用的权限和账号应主动回收）。

网络访问。数据库不要直接暴露在公网；用 IP 白名单、私有网络和防火墙规则把访问面收到最小；SSH 等管理端口只对特定来源开放。

底层安全与内部研究。工程师常比安全团队更早看到系统的薄弱处，作者鼓励营造一种文化：发现可疑的配置或漏洞就上报，而不是默默绕开。

七、隐私：不止是不被偷

隐私关心的是数据该不该被这样用。除了少采集，结合书中前几章的要求：对 PII 做脱敏或令牌化（tokenization，用无意义的替代值换掉真实值），并为「删除某个用户的数据」这类法规请求预留能力——数据散在原始层、清洗层、备份与下游副本里时，删干净远比想象难。

关键权衡与选型

表 1 · 安全剧场 vs 安全习惯

表 2 · 常见手段各挡什么、挡不住什么

没有哪一项单独够用，组合起来才是纵深防御。粒度上也有取舍：库级授权最省事但最粗；列级、行级与动态脱敏最贴合最小权限，代价是策略数量膨胀、需要专人维护。经验做法是按数据敏感级别分层：公开、内部、机密、受监管（PII / 支付 / 医疗），越往上管得越细。

为什么重要 / 落到真实系统

面试里「设计一个存用户行为与 PII 的数据平台」，好答案会这样落地：采集端识别并令牌化手机号与身份证号；数仓按敏感级别分区，分析师默认只拿脱敏视图，明细走限时提权；任务用 IAM 角色而非长期密钥，密码进 secret manager，CI 里扫描提交防止密钥入库；存储桶默认私有、数据库只在私网；告警盯异常登录、异常大的导出与账单突增；备份放在独立账号、每季度演练恢复。主流平台都有对应能力：Snowflake 与 BigQuery 支持列级访问控制与动态脱敏，AWS Lake Formation 提供表、列、行级授权。

易错点与争议

• 「上了云，安全是云厂商的事」。共担责任模型下，配置、权限和数据都归你。
• 「开了加密就安全了」。加密挡不住拿合法凭证登录的人，它是基线不是终点。
• 「先都收进来，以后再说」。多收一列 PII 就多一份泄露面和合规义务；不采集是最便宜的保护。
• 「最小权限会拖慢团队」。有道理，所以要配破窗流程和自助申请，而不是退回人人管理员。
• 「通过审计就是安全」。合规是下限；清单齐全而习惯缺失，正是安全剧场。
• 「有备份就行」。没演练过恢复的备份不可信；和生产同账号的备份可能一起被勒索。
• 局限。本章刻意写得概括，更像一份数据工程师视角的清单，没有深入威胁建模或密码学；书出版于 2022 年，之后零信任网络、数据安全态势管理（DSPM）等做法更普及，但「人 → 流程 → 技术」的判断并未过时。

要点