如果你有一些有价值的东西，你几乎可以保证有人会想围绕它进行未经授权的活动，而云工作负载与传统架构一样面临着许多安全风险。但风险是不同的，防御措施也是不同的。
云环境中的安全与我们所习惯的东西非常不同。云给你带来了更少的担心，但也带来了更少的控制--大多数东西都是高阶抽象，更容易管理，但这意味着你在这些高阶抽象上有更多的工作要做。这反过来又影响了你的应用程序和支持性的基础设施配置，至少在你能控制的范围内是这样的。
建立现代12因素的云应用程序与传统的软件工程不同一样，云安全需要非常不同的思维。对 "周边 "的控制较少，与外部世界的零信任关系较多，导致你在安全工作中的优先级不同。与数据相关的安全风险常常被忽视。
复杂的数据流较少地受到你建立基础设施的能力的限制，而更多地被业务需求所证明，在协调数据安全控制方面产生了独特的要求--使数据在需要的地方安全地可用。
因此，思考云原生环境中的数据安全需要一个不同的视角，我们将在这篇文章中尝试提供一个。在创建了许多数据安全工具和库，并帮助几十个客户在高风险环境中保护敏感数据之后，我们收集了一些关于科技公司如何在云中建立他们的数据安全工具的意见。
云原生数据安全是不同的
每一个可靠的安全决策都来自于心理模型的组合：风险评估、风险缓解选择、威胁模型、威胁载体、损失事件场景等
。从风险角度来看，云环境与数据中心的传统服务器机架没有太大区别。但责任的划分是不同的：从理论上讲，你的云供应商有责任确保一切运行安全。但是，当它发生故障时，你可能会发现是你的"S3桶错误配置 "的错，即你的脆弱应用程序发生了故障。因此，虽然你要照顾的东西比较少，但你实际上把你的风险态势--你的组织的整体网络安全实力--扩展到了更多你无法控制的东西。
工程师们经常认为，"这是一个云；最好的安全专家正在照顾它"。从某种意义上说，这是非常正确的，因为云供应商的团队确实为数百万客户打磨了他们的一套控制措施，这些控制措施经受住了时间的考验，但它几乎没有给你一个完整的画面。
云安全应该适应与云相关的风险。请记住，根据一些法规（GDPR、PCI、CCPA、国家范围内的法规），数据所有者，而不是基础设施运营商，
要需要进行 字段级加密，防止开发人员和DBA访问敏感数据；需要安全控制，阻止SQL注入和内部人员；需要审计记录，在出错时恢复事件的情况。
云安全还应该适应云中不同的架构假设：状态管理、一次性复制、负载平衡等。
换句话说
，这个控制的 "灰色地带 "要求你在安全方面的工作更多而不是更少。
云中的数据安全
在云世界中，数据更是最终的风险资产。因此，当你可以用两个terraform脚本和一堆IaC工具来重新配置你的整个产品时，唯一重要的是可信的执行和数据安全（完整性、可用性、保密性）。
随着许多其他安全问题的消除（或从属于访问控制和基础设施管理），投资于应用安全和数据安全带来了云内安全态势的最大改善。
这两个目的的所有手段都很重要。关于应用安全有很多说法，它是无限的。不幸的是，数据安全往往被忽视，直到为时已晚。
管理复杂性
最大的数据安全挑战不在于加密或密钥管理，尽管这些都是挑战。最大的挑战是管理复杂性：设定数据流并将控制映射到它们。
Phil Venables在他的 "复杂性是安全的敌人吗？"一文中对此有很好的看法。
管理复杂性在云中变得更加严重：
- 更多的构建块可以轻松连接，并以新颖的方式交换数据。
- 拥有更多的数据和构建块意味着更复杂的访问策略和配置来协调不同的数据安全控制。
如果你能定义数据访问的阻塞点并围绕它们收集大多数数据安全，你可能会很幸运。例如，通过在每个数据库之前设置一个加密代理，或者部署一个数据访问服务，负责从受保护的存储中抓取敏感数据。见下面参考架构中的例子。
如果不可能，通过加密即服务和其他相关的安全控制，使数据在其生命周期的必要部分可以被访问是必须的。
当你完成后，你最终会有五到十个不同的安全控制，在理想情况下，它们之间应该是协调的，以避免政策差距并提供完美的深度防御。
锁定实际上是一种安全风险
当你考虑到云数据库时，虽然将大量的数据从一个云供应商转移到另一个云供应商是费时费力的，但你至少经常得到可互操作的数据模型，甚至有线协议。但是，当看到安全工具时，迁移配置和密钥往往成为一个挑战。与数据一起迁移安全工具甚至更具挑战性，因为针对云的控制也需要在另一个环境中重新部署和重新配置。
数据迁移过程中的安全问题文件中概述的风险对数据库迁移同样有效。
除了从预算和连续性的角度来看是不好的，锁定也是一个问题：迁移意味着大量的风险暴露，沿途的错误配置风险。
云架构与数据安全
云环境中的数据安全并非一切都是坏事。云环境已经提供了许多有用的安全服务。其中有始终可用且可靠的AWS IAM和KMS，实现了更细化的访问控制和加密管理。如果有必要，根据每个用户的访问控制角色对每个数据库查询进行分流比以往更容易。
云环境也有助于可用性：快照、数据库备份、加密密钥等
。 然而，也有一定的缺点。
- 一切都要花钱，而CloudHSM / KMS Vault的成本也不小。这往往会导致新的激励措施，使安全架构向合理的OPEX倾斜（完全可以理解）。
- 隐含的选择隐藏在较低的配置/管理成本之下，导致架构中出现不雅的结点。
- 现场级加密增加了数据量。如果你为数据量付费，你将为存储加密数据支付更多的费用。
云中构建数据安全层
就工程实际情况而言，在为云设计数据安全平台时，你要考虑三个核心问题：1.专注于用更少的工具减轻更多的安全风险（更少的工具→更少的错误）。记住，每个工具，甚至是安全工具，都会带来bug，增加攻击面。另外，当安全工具很多时，在由数百个组件组成的系统上协调安全策略是比较困难的
。2.有许多类型的安全控制：预防性、检测性、纠正性。它们应该被协调并一起工作。例如，如果不触发安全事件，访问控制是没有用的，但收集事件而不监控它们也是没有意义的
。3.考虑你是否需要集中式的安全或分散式的安全。如果你的产品是一个云账户中的10-20个互连的应用程序，你需要一个数据安全平台（而不是一个应用程序中的独立功能）来管理加密和数据安全控制。用特定的控制措施来武装单一的加密层是比较容易的。DLP、异常检测、防火墙、匿名化等。见NIST SP 800-204。
应用层加密与TLS
应用层加密（ALE）是发生在应用内部的加密过程，不依赖于底层传输和/或静态加密。
应用层加密与静态数据加密（数据库级）和传输中数据加密（TLS）一起工作。ALE意味着敏感数据在存储到数据库之前由应用程序加密，并在从数据库读取后由应用程序解密。
通常，只有敏感数据字段被加密，因此使用 "字段级加密"术语。例如，用户表包含加密的个人身份信息（PII），而头像、登录日期和昵称则以明文存储。
ALE可以通过各种方式实现，以满足不同的安全要求--从端到端加密和零信任架构到部分字段级数据库加密。ALE比传输和静态加密能保护更多的风险，但也要付出代价。
在基础设施的各个组件之间使用TLS是一个必要的措施。但它只能保护数据免受节点间网络流量的泄漏和篡改，并在正确设置的情况下增加节点间链接的认证。
数据库级别的加密方案通常是自毁的，因为数据和密钥最终都在同一个数据库中（因此，能够访问数据库的特权用户可以访问明文的敏感数据）。
参考架构
数据安全层通常结合了围绕数据的几个安全控制：认证、防火墙和应用级别的加密。加密引擎可以有多种形式：从访问加密密钥的独立服务，从应用程序中隐藏加密细节，到直接在应用程序代码中内置加密SDK。
数据库代理
数据库代理作为数据库的透明加密/解密代理工作。应用程序通过代理连接到数据库。中间的代理拦截数据，对其进行加密并将其发送到数据库。当应用程序读回数据时，代理解密并将其发送给应用程序。
这个方案的好处是它是 "透明 "的加密。应用程序不知道数据在到达数据库之前已被加密。数据库也不知道有人对数据进行了加密。开发者需要做的是配置数据库代理，对哪些数据字段进行加密。这种方法被称为 "字段级加密"。
加密不是数据库代理的唯一功能。它通常还会提供标记化、屏蔽、匿名化、SQL防火墙等
。
Tools：
- Acra数据库安全套件在SQL代理模式下--加密、可搜索加密、标记化、屏蔽、防火墙、访问控制、审计日志。
- ProxySQL--MySQL和MariaDB的防火墙。
数据访问对象
数据访问对象（DAO）是一种代理后台模块和数据库之间数据交换的服务。这在概念上类似于代理，但DAO服务可以与多个数据库（包括SQL和NoSQL）一起工作。DAO知道数据布局--哪些数据是敏感的并加密存储（所以DAO要求加密引擎解密），哪些数据是明文存储（所以DAO直接询问数据库）。
DAO通常为应用程序提供一个API来读/写数据到数据库，同时对敏感字段的加密/解密进行封装。DAO负责验证应用程序，并寻找/使用适当的加密密钥。
许多现有的加密即服务工具可以被配置为DAO。此外，DAO应提供高可用性，并与解决方案一起扩展。
工具：
- API服务模式下的Acra数据库安全套件--加密、标记化、访问控制。
- Hashicorp的Vault。
- 云KMS+加密API（Azure、GCP和AWS的KMS都有加密/解密API和带有生成/BYOK包装密钥的库）。
加密库（SDK）
加密库是集成到处理敏感数据的应用程序中的加密代码。该库封装了加密技术，提供 "加密 "和 "解密 "方法。应用程序负责在将字段发送到数据库之前对其进行加密，并在检索时对其进行解密。这种方法被称为 "客户端加密"。
这种方法的优点是不需要部署和维护单独的加密服务，因为应用程序负责保护通过它们的数据。
然而，也有多种缺点：应用程序可以访问加密密钥，从而大大增加了通过应用程序漏洞泄露数据的风险。此外，应用程序现在封装了敏感的加密代码，因此需要进行维护，更新依赖关系等。照顾多个应用程序的安全也比单一数据安全层复杂得多。
工具：
提供- 了一个现成的SDK。
需要记住的技术流程
数据安全与技术和组织流程相伴而生。
密钥管理
加密带来了密钥管理：生成、分发、安全存储、旋转、到期、撤销、密钥备份。参考NIST SP 800-57。
密钥备份是必不可少的，因为丢失加密密钥可能导致丢失所有用这些密钥加密的数据。因此，我们建议采用多层加密方案：单独的数据加密密钥来加密数据字段，密钥加密密钥来加密DEK，客户相关的密钥来加密KEK。这样的方案在密钥轮换方面提供了更多的灵活性，并允许我们只备份高级别的密钥。
当公司处理企业客户的敏感数据时，他们希望他们的数据是用客户相关的密钥来加密的。BYOK/HYOK方案在这里起到了救急的作用。在这种方案中，必须定义谁负责密钥的存储和备份--客户本身或解决方案提供商。
监测和审计记录
数据安全层需要强大的遥测和异常检测。将数据安全层的事件与系统其他部分的典型指标联系起来。
- 加密和解密错误。与同一应用程序相关的解密错误数量增加，可能表明该应用程序的配置错误或恶意活动。
- "访问加密密钥 "错误可能是KMS妥协或错误配置的迹象。
- 加密/解密执行服务的CPU负载--有人抓取了太多的数据吗？
- 将数据库连接错误与数据库负载联系起来，可能表明数据库集群中存在可疑活动。
安全层的基本目标是确保信任、保护数据并为数据安全合规提供基础。因此，它应该包含日志，更具体地说，审计日志：
- 涵盖所有的密钥访问过程；
- 涵盖所有的密钥管理程序；
- 涵盖所有与安全相关的访问事件。
如果审计日志包含时间戳、事件或错误的ID、服务名称、会话ID和消息本身，那就很有帮助。
但如果审计日志能提供防止篡改的保护，那就更好。通常情况下，这样的日志信息是相互加密联系的，不能被明显地改变。简单的防篡改审计日志的实现看起来像一个日志链（见这篇博文和这篇论文）；更复杂的是基于Merkle树（见RFC6962）。
应用安全是一个过程
安全是一个永无止境的过程。仅仅部署加密、监控或防火墙是不够的。
数据安全平台应该服从于一般的应用安全实践：安全软件开发（见NIST SSDF）、依赖和漏洞监控、根据流行的标准（如OWASP ASVS v4.0.2
）进行验证、安全CICD、安全测试等等。
总结
云原生安全需要不同的安全思维。数据无处不在：应用程序、数据库、备份、第三方API、分析服务等。数据安全从 "保护存储数据的地方 "转移到 "保护任何时候存在的数据"。
数据安全措施成为数据的安全边界。云原生基础设施需要协调许多工具，在数据存在的所有地方建立数据安全层。
云中的数据安全层的主要功能和非功能要求是：
- 数据安全层应提供足够的安全性，误配置、API暴露和特权管理员不应能够配置平台，将数据暴露在外面。
- 安全性不应妨碍架构的扩展。
- 数据安全措施不应妨碍系统从类似于大脑分裂的事件中持续恢复。
- 由数据安全层加密的数据不应通过单一故障变得不可访问。
- 密钥管理和加密应独立于访问管理（例如，访问管理提供精细的粒度，加密的密钥粒度不应依赖于它）。
幸运的是，有一些生产就绪的工具可以选择，与你使用的云供应商无关。检查参考基础设施，尝试这些工具，阅读数据安全博客，并保持安全!
