1.1. 安全在数据工程的执行层面至关重要

1.1.1. 安全需要成为一种思想和行动的习惯

1.1.2. 安全是隐私立足的根本

1.2. 数据安全是数据工程师在其工作和数据工程生命周期的每个阶段需要考虑的首要问题

1.2.1. 数据工程师的安全和隐私职责在不同的组织中会有很大的不同

1.2.2. 对待数据应当像对待钱包或智能手机那样

1.2.3. 虽然你不可能负责你公司的安全，但了解基本的安全措施并将安全放在首位，将有助于减少你的组织发生数据安全漏洞的风险

1.3. 一个安全漏洞或数据泄露就会使业务陷入困境

1.4. 隐私对于企业信息技术领域的可信任度一直都很重要

1.4.1. 包括财务信息、私人通信数据（电子邮件、短信、电话）、医疗记录、教育记录和工作经历

1.5. 隐私逐渐成为具有重要法律意义的问题

1.5.1. 由于数据系统与教育、医疗和商业的结构交织在一起，数据工程师处理的很多敏感数据与这些法律相关

2.1. 安全和隐私中最薄弱的环节是操作者本身

2.2. 安全防线往往在人面前失效，所以要从盯防自己开始

2.3. 恶意的程序或人类会时刻试图渗透你的敏感证书和信息，这就是雷打不动的现实

2.4. 在线上和线下的一切操作都要多加小心，并坚持发挥逆向思维的力量

2.5. 逆向思维的力量

2.5.1. 正向思维会使我们对恐怖袭击或紧急救护情况准备不足

2.5.2. 逆向思维使我们能够考虑灾难的发生，并采取相应行动

2.5.3. 保护私人和敏感数据的最好方法就是避免获取它们

2.5.4. 在决定安全策略时要确保策略能真正保证安全，而不仅是看起来安全

2.6. 永远多想一步

2.6.1. 当被索要凭证时，一定要谨慎

2.6.1.1. 对索要凭证的行为应该持充分怀疑态度并询问同事和朋友的意见

2.6.1.2. 当被索要凭证、敏感数据或机密信息时，不要轻易相信任何人

2.6.2. 要确保工作内容既合法又符合道德

2.6.2.1. 作为尊重隐私和道德的第一道防线，如果你对所负责收集的敏感数据感到不舒服，对项目中处理数据的方式有道德上的疑问，那就向同事和领导提出你的担忧

3.1. 当人们遵循常规的安全流程时，工作内容就变得更安全

3.1.1. 让安全成为一种习惯，多进行真正的安全实践，遵守最小特权原则，并理解云的责任共担模式

3.2. 企业客户普遍关注合规性（内部规则、法律、标准机构的建议），但对潜在的不利因素关注不够

3.3. 表演式的安全

3.3.1. 按照合规性（SOC-2、ISO 27001等）的剧本表演，根本没有落实责任

3.4. 安全需要足够简单有效，从而能够在整个组织持续推行

3.4.1. 要追求真正的和习惯性的安全精神，将安全思想融入文化中

3.4.2. 安全不需要太复杂

3.4.3. 践行安全，人人有责，责任重于泰山

3.5. 主动安全

3.5.1. 运用逆向思维，实施主动安全需要在动态和不断变化的世界中思考和研究安全威胁

3.5.2. 研究成功的网络钓鱼攻击来反思组织内的安全漏洞，而不是简单地进行打好招呼的模拟网络钓鱼攻击

3.5.3. 积极排查组织内部的漏洞，研究潜在的员工泄露或滥用私人信息诱因，而不是简单地填写死板的合规性检查表

3.6. 最小特权原则

3.6.1. 意味着人或系统应该只有必要的权限和数据

3.6.2. 只需要少量的IAM角色就足够了

3.6.2.1. 只为用户（或他们所属的组）提供需要的IAM角色，不需要这些角色时就收回

3.6.3. 只在需要的时候给予必要的权限和数据

3.6.4. 最小特权原则对隐私也很关键

3.6.4.1. 他们的敏感数据只在必要的时候才能访问到

3.6.4.2. 对敏感数据实施列、行和单元格级别的访问控制

3.6.4.3. 创建只包含查看者需要访问的信息的视图

3.6.4.4. 把数据放在紧急情况才能启用的程序之下，用户只有在紧急审批后才能访问这些数据，以解决问题或者查询关键的历史信息等

3.6.4.4.1. 一旦工作完成，权限就会立即收回

3.7. 云服务的责任共担

3.7.1. 安全是云中的共同责任

3.7.2. 云供应商负责确保其数据中心和硬件的物理层面的安全

3.7.3. 开发者也要对云中建立和维护的应用程序和系统的安全负责

3.7.4. 漏洞发生的原因可能是无意间的错误配置、失误、疏忽和马虎

3.8. 始终备份数据

3.8.1. 数据是会消失的

3.8.1.1. 坏盘或者服务器宕机

3.8.1.2. 误删除数据库或对象存储桶

3.8.1.3. 恶意入侵者锁住数据

3.8.1.3.1. 保险公司正在减少对这类事件的赔付，使你既要恢复数据，又要付赎金

3.8.2. 要定期备份数据，为了灾备，也是为了业务连续性，防止某个版本的数据在勒索软件攻击中被破坏

3.8.2.1. 定期测试数据备份的恢复情况

3.8.3. 严格意义上讲数据备份并不属于安全和隐私实践，它属于灾难预防这一更大的主题

3.9. 安全政策实践

3.9.1. 保护你的凭证

3.9.1.1. 不惜一切代价保护你的凭证

3.9.1.2. 一切都使用单点登录

3.9.1.2.1. 尽可能避免使用密码，并将SSO作为默认设置

3.9.1.3. 尽可能避免使用密码，并将SSO作为默认设置

3.9.1.4. 不要共享密码或凭证，包括客户的密码和凭证

3.9.1.5. 小心网络钓鱼和诈骗电话，永远不要透露密码

3.9.1.6. 禁用或删除旧的凭证，最好删除

3.9.1.7. 不要把你的凭证放在代码中

3.9.1.8. 始终坚持最小特权原则

3.9.2. 保护设备

3.9.2.1. 管理所有员工使用的设备

3.9.2.1.1. 如果有员工离开公司或丢失设备，可以远程擦除设备

3.9.2.2. 对所有设备使用多因素认证

3.9.2.3. 使用你的公司电子邮件凭证登录到设备

3.9.2.4. 所有涉及凭证和行为的政策都适用于你的设备

3.9.2.5. 把你的设备当作你自己的延伸

3.9.2.5.1. 不要让你指定的设备离开你的视线

3.9.2.6. 在屏幕共享时，要注意你到底在共享什么，以保护敏感信息和通信

3.9.2.6.1. 只共享单个文件、浏览器标签或窗口，避免共享你的整个桌面

3.9.2.6.2. 只分享传达你的观点所需的内容

3.9.2.7. 在视频通话时使用勿扰模式

3.9.2.7.1. 防止在通话或录音中出现弹框、提示音等打扰

3.9.3. 软件更新策略

3.9.3.1. 当你看到更新提示时，重新启动浏览器

3.9.3.2. 在公司和个人设备上运行小型操作系统更新

3.9.3.3. 让公司来确定关键的主要操作系统更新并提供指导

3.9.3.4. 不要使用操作系统的测试版

3.9.3.5. 在操作系统重大版本发布后等待1～2个星期再用

4.1. 系统补丁和更新

4.1.1. 软件会变得陈旧，安全漏洞也不断会被发现

4.1.2. 为了避免暴露所使用工具的旧版本的安全漏洞，当有新的更新时，一定要给操作系统与软件打补丁和更新

4.1.3. 要更新代码和依赖关系，可以自动构建或者设置版本发布和漏洞警报，以便提示手动执行更新

4.2. 加密

4.2.1. 加密不是万能的，当人为的安全漏洞暴露了凭证时它就失效了

4.2.2. 加密是所有重视安全和隐私的组织的基本要求

4.2.2.1. 可以防止基本的攻击，如网络流量拦截

4.2.3. 静态加密

4.2.3.1. 确保数据在静态（在存储设备上）时被加密

4.2.3.2. 公司笔记本计算机应该启用全盘加密，可以在设备被盗时保护数据

4.2.3.3. 对存储在服务器、文件系统、数据库和云中对象存储中的所有数据实施服务器端加密

4.2.3.4. 所有用于存档的数据备份也应该加密

4.2.3.5. 在应用程序层面也进行加密

4.2.4. 传输加密

4.2.4.1. 传输加密是目前各种协议的默认配置

4.2.4.2. HTTPS通常是现代云API的要求

4.2.4.3. 不当的密钥使用是数据泄露的重要原因

4.2.4.3.1. 如果存储桶的权限对公网开放，则HTTPS对保护数据毫无帮助，这也是过去十年中几起数据泄露丑闻发生的原因

4.2.4.4. FTP在公共网络上根本不安全

4.2.4.4.1. 最好的办法是直接避免使用FTP

4.2.4.5. 要确保传输加密的全覆盖，传统协议也不例外

4.2.4.5.1. 如果不确定是否做到了加密，就使用那些带有加密功能的稳定技术

4.3. 日志、监控和警报

4.3.1. 黑客和入侵者通常不会宣布他们正在渗透你的系统

4.3.1.1. 大多数公司在事后才发现安全事故

4.3.2. 观测、检测和警告事件是DataOps的组成部分

4.3.2.1. 设置自动监控、日志和警报，以便能够及时发现系统中的异常事件

4.3.3. 监控要点

4.3.3.1. 访问

4.3.3.1.1. 谁在访问什么，什么时候，从哪里访问？

4.3.3.1.2. 有哪些新的访问权限被授予？

4.3.3.1.3. 现有用户的异常行为模式可能表明他们的账户被入侵了

4.3.3.2. 资源使用

4.3.3.2.1. 监控磁盘、CPU、内存和I/O，看看是否有不正常的使用模式

4.3.3.2.2. 资源使用是否有重大变动？

4.3.3.2.2.1. 如果是的话，则很可能存在安全漏洞

4.3.3.3. 计费

4.3.3.3.1. 对于SaaS和云托管服务，需要监督成本

4.3.3.3.2. 设置预算警报来确保不超支

4.3.3.3.3. 如果账单中突然出现了计划外的大笔花费，则可能有人或程序在窃取资源进行恶意操作

4.3.3.4. 过宽松的权限

4.3.3.4.1. 越来越多的供应商提供工具来监控用户或服务账户在一段时间内未使用的权限

4.3.3.4.2. 最好在监控中结合这些方面的内容以获得你的资源、访问和计费概况的全景图

4.3.3.4.3. 要定期演练，有备无患

4.4. 网络访问控制

4.4.1. 原则上，网络安全应该由公司的安全专家来负责

4.4.2. 在实践中，数据工程师可能需要在小公司里承担网络安全的责任

4.4.3. 数据工程师经常会用到数据库、对象存储和服务器，因此至少应该了解一些简单的措施确保符合网络访问控制的安全实践

4.4.3.1. 要鼓励每个数据工程师积极参与安全工作，当他们在系统中发现潜在的安全风险时应该思考解决措施，并积极参与部署这些措施

4.4.4. 仅允许访问这些端口的系统和用户传入IP地址（又称白名单IP），并避免在任何情况下广泛地开放连接

4.4.5. 当访问云或SaaS工具时使用加密的连接

4.4.6. 云通常更接近于零信任安全

4.4.6.1. 每个操作都需要身份验证

4.4.6.2. 对于大多数组织来说，云是一个更安全的选择，因为它实践了零信任，让公司享受公有云的安全工程师团队的服务

4.4.7. 有时强化边界安全仍然是有意义的

4.4.7.1. 内网服务器是强化边界安全的最终例子

4.4.7.2. 即使是本地部署，内网服务器同样容易受到人为安全事故的影响

4.5. 数据工程底层系统的安全

4.5.1. 每一个元素的安全影响是至关重要的

4.5.1.1. 不能放松链条上的任何一个环节

4.5.2. 任何软件库、存储系统或计算节点都是潜在的安全漏洞

4.5.2.1. 一个不明显的日志库的缺陷可能允许攻击者绕过访问控制或加密

4.5.2.2. CPU架构和微代码也是潜在的漏洞

4.5.2.3. 敏感数据在内存或CPU缓存中静止时也可能受到攻击