亚马逊AWS官方博客
在亚马逊云科技数据存储中保护敏感数据的最佳实践
要确保云端敏感数据的安全，我们必须制定行之有效的保护策略。而策略制定，又要求我们对常规数据安全模式拥有全面了解，并将这些模式明确映射至云安全控制当中。以此为基础，您可以将这些控制方法应用于数据存储层面的各类实施方案之内，包括Amazon Relational Database Service (Amazon RDS)与Amazon DynamoDB等等。
本文将重点介绍常规数据安全模式，以及可用于保护您数据的相应AWS安全控制方法。本文中会提及Amazon RDS与Amazon DynamoDB，但关于更多具体实现层面的细节信息，请参阅在Amazon RDS中应用敏感数据保护最佳实践和在Amazon DynamoDB中应用敏感数据保护最佳实践。
亚马逊云科技云采用框架
亚马逊云科技云采用框架 (Amazon CAF)为您指代指导与最佳实践，帮助您在整个组织之内为云计算构建全面的采用方法。在这套框架内，Amazon CAF的安全视角共涵盖以下五项关键功能：
- 亚马逊云科技身份与访问管理 (IAM)：对跨越多种亚马逊云科技服务、行动及资源的用户权限进行定义、执行并审计。
- 检测控制： 改善您的安全状况，降低环境风险水平，提供发现问题所需要的可见性，避免您的业务遭到意外安全问题的影响。
- 基础设施安全：缩小您所管理的基础设施的暴露区域，增强AWS整体基础设施的隐私性与控制水平。
- 数据保护：实施适当的保护措施，使用原生集成的加密服务帮助保护传输数据与静态数据。
- 事件响应：根据安全计划指南，定义并执行对安全事件的响应。
基于Amazon CAF安全性视角实施安全保护的第一步，就是从数据角度考虑安全性问题。
不同于以本地及非本地角度审视数据安全，需要考虑的是哪些数据需要保护、如何存储这部分数据以及谁有权访问这些数据。以下三个类别，可帮助您从数据角度深入考量安全性议题：
- 数据分类与安全区建模。
- 纵深防御。
- 泳道隔离。
在本文中，我们将具体了解这几个类别。
数据分类与安全区建模
数据分类
不同数据在重要程度与敏感性方面自然有所区别，因此我们需要对数据进行正确分类，而后才能探讨如何对其加以保护。作为分类流程的重要部分，您需要在严格的安全状态与灵活的敏捷环境之间做出微妙的权衡与取舍。
严格的安全措施往往对应冗长的访问控制过程，借此为数据安全性提供更强有力的保障。但是，这种安全机制可能与敏捷、快节奏的开发环境背道而驰。在开发环境中，开发者希望以自助方式访问数据存储。因此，我们需要设计数据分类方法以满足广泛的访问需求。
在大多数情况下，数据的分类方式不必像公共数据或私有数据那些非此即彼，您可以在数据分类模型中添加适当的保真度级别。如下图所示，不同数据对应不同的敏感度，您的数据可能分别对应不同敏感度与机密性级别。请设计适当的预防与检测控制组合以设计数据安全控制机制，确保与数据敏感度确切匹配。
安全区建模
关于数据安全的另一种视角，是考虑数据是如何以及在哪里被访问的。安全区提供经过明确定义的网络边界，从而实施控制以保护其中的所有资产。安全区还能够清晰和方便地基于它的特征来定义和执行进出安全区域的网络流控制。
例如，所有包含敏感数据的资产都可被分组进同一安全区内。您可以在安全区之上为其他安全组创建一套分层网络流控制架构。考虑这样一个实例：我们针对应用程序中的逻辑资产建立受限区，并将面向互联网资产划入外部区。你可以通过亚马逊云科技网络访问控制列表（ACL）结合IAM策略作为补充，以定义网络流量控制策略。以此为基础，您只能从受限区（而非面向互联网的外部区）访问安全区。这种方法将把您的敏感数据置于互联网可访问范围之下的两个安全层内，如下图所示。
与数据分类模型结合使用时，安全区建模还可以实现多因素数据访问策略。数据分类使您能够为数据定义适当的安全区，据此更灵活地将适当级别的网络流控制与访问策略应用于不同数据。
纵深防御
纵深防御的基本概念，是指将多个安全控制层结合起来以保证在某一安全控制方法失败时提供冗余。您可以对系统应用两类安全控制方法，借此实现纵深防御：
- 预防性：这些控制方法围绕IAM的Amazon CAF安全视角功能、基础设施安全与数据保护建立而成。
- 检测性：这些控制方法可检测配置变更或恶意操作，并及时执行事件响应。将检测控制与预防控制配合起来，即可建立起良好的总体安全态势。
在有效的安全态势之下，您需要同时使用预防性与检测性安全控制，确保适应动态且不断变化的业务与技术发展。
预防性控制
您可以将预防性控制划分为三大主要类别：
- IAM
- 基础设施安全
- 数据保护（加密与令牌化）
您应根据实际用例，对各类控制手段进行分层与排序。例如，您可以在数据库层或用户活动开始时（或者同时兼顾二者）应用IAM控制方法。作为一种思维模型，下图所示为一种利用分层控制对数据访问加以保护的方法。
下面具体来看各个控制层。
DDoS保护：分布式拒绝服务（DDoS）攻击可能通过应用程序吞没您的数据库。通过将Amazon Shield等服务与内容交付网络服务（例如Amazon CloudFront）相结合，您的应用程序及数据库将免受L3与L4层流量攻击的侵扰。关于更多详细信息，请参阅AWS DDoS弹性最佳实践。
网络隔离：保护数据库的一大重要基本方式，就是将数据库放置在虚拟私有云（VPC）内，或者只允许通过VPC端点从VPC对其进行访问。这种方式适用于DynamoDB及Amazon S3等区域性服务。
在这两种情况下，出入数据库的流量都将驻留在你的网络之内，且不会向外部公开。因此，对数据库的访问可以仅限于VPC内部的资源，从而更轻松地对数据库实施细粒度网络访问控制。
应用层威胁防护：此层通过应用层间接应用于您的数据库。其基本思路在于，您的安全性将由最薄弱的环节决定。应用程序本身具备对数据库“前门”的访问权限，因此您必须确保自己的应用程序免受SQL注入等威胁的侵扰。
通过在应用负载均衡器ALB或CloudFront分发机制上启用Amazon WAF，您的应用程序将免受此类威胁的影响。这有助于缓解诸如SQL注入或OWASP Top 10应用程序漏洞等应用级攻击。您还可以启用数据库防火墙应用程序解决方案，包括可从Amazon Marketplace获取的合作伙伴产品。
安全组与网络ACL：限制指向数据库的网络流量，可保证仅合法流量可进入数据库，其他所有流量均将被阻止，借此减少攻击向量。您可以使用网络ACL建立基于区域的模型（Web/应用程序/数据库），并使用安全组为应用程序栈内的各组件提供微分段。在AWS安全最佳实践白皮书的“使用安全分区与网络分段”部分，您可以获取关于安全区建模的更多详细信息。
通过为每个应用程序设置安全组，您可以仅允许来自特定应用程序安全组的入站流量为数据库的网络安全建模。这种方法还消除了使用应用程序无类域间路由（CIDR）范围来管理数据库网络安全性所带来的复杂性因素。关于如何配置安全组的更多详细信息，请参阅使用安全组。
身份与访问管理（IAM）：为了建立强大而灵活的身份验证机制，请将管理流（数据库管理任务）与应用程序流（应用程序对数据的访问）区分开来。对于管理流，请考虑使用IAM并为身份验证及授权实施多因素身份验证。以下代码示例为Amazon RDS的IAM策略，此策略启用一组有限的管理功能，并可将其附加至其他IAM用户、组或角色。
应用程序流则负责对相应数据库访问凭证执行最低权限原则。
对于权限要求更高的管理流，请从专用网络区启动数据库连接及操作。此区被视为管理流相应区，而且与应用程序流相分离（根据前文提到的安全区建模）。因为数据库管理凭证与操作同应用程序凭证及操作相分离，所以此方法将有效限制对环境造成破坏的可能性。作为可选项，您可以从AWS Marketplace获取并实施数据库防火墙解决方案，借此确保从给定安全区执行的数据库命令在类型上与安全区要求相符。
当数据库需要使用到未集成至IAM的访问凭证时，您可以考虑使用密钥管理系统。Amazon Secrets Manager 或 Amazon Systems Manager Parameter Store等此类系统可帮助您安全地存储、轮替并授权运行时对数据库凭证进行访问。
加密与令牌化：数据加密与令牌化有助于预防多种风险，例如通过未授权访问机制致使数据泄露。启用静态数据与传输数据加密（未来将在后续博文中介绍如何在Amazon RDS与Amazon DynamoDB中实现静态与传输数据加密）。
另外，请考虑如何生成主加密密钥以及如何管理生命周期。一种简单且强大的加密密钥管理机制，在于使用Amazon Key Management Service (Amazon KMS)。Amazon KMS支持客户主密钥（CMK），并可与Amazon S3、Amazon EMR、Amazon Redshift、Amazon RDS以及DynamoDB相集成（详见区域支持），借此使用托管在Amazon KMS中的密钥进行数据加密。
考虑使用Amazon KMS托管加密密钥进行应用层级（也称客户端）加密。但是，是否使用应用级加密可能取决于以下因素：需要接受高度保护的数据分类，对端到端加密的需求，以及后端基础设施是否能够支持端到端加密。这里提醒大家认真考虑此选项，其可能会限制数据库所能对应用程序加密数据执行的原生函数。
最后，令牌化属于另外一种加密替代方法，有助于保护高敏感度或需要遵循特定法规要求（例如支付卡行业标准，即PCI）的某些数据。将敏感数据分离至独立的专用安全数据存储之内，并在其位置上使用令牌，将帮助您有效避免潜在的成本及端到端加密复杂性。借助这种方法，您还可以通过一次性临时令牌快速降低风险。
检测性控制
检测性控制的有效应用，将帮助您及时获取对变更与事件做出响应的信息。强大的检测机制与安全信息及事件监控（SIEM）系统相集成，您能够快速响应安全漏洞并不断改善数据的安全态势。
下面来看可供您使用的几种常见检测性控制方法：
检测未授权流量：连续监控VPC流日志可帮助您识别并纠正任何安全异常。Amazon GuardDuty是一项托管服务，可在云端提供托管威胁情报。GuardDuty将从VPC流日志、Amazon CloudTrail以及DNS日志当中获取馈送数据，并使用机器学习、基于特征码的签名以及外部威胁情报源为您提供具备可操作性的发现结果。您可以将这些发现引入Amazon CloudWatch事件以驱动自动响应。
配置偏移：配置偏移是指系统当前安全配置，与其所应满足的安全状态之间发生的偏离。在初始部署之后，对系统的修改有可能导致配置偏移。为了确保数据库安全性与完整性，您必须识别、报告并修复配置偏移问题。您可以将Amazon Config与DynamoDB配合使用，轻松立足表层级检测配置漂移；Amazon Config也可以与Amazon RDS一同使用，借此检测数据库实例、安全组、快照、子网组以及事件订阅。
细粒度审计：请考虑对数据库管理及应用程序流进行审计。对数据库访问及使用范围的审计方案，还应根据特定环境及实际使用情况进行微调。审计可能对性能造成影响，而且使用的数据库不同，您的审计范围及程度也将有所不同。
您可能需要首先捕捉所有直接数据定义语言（DDL）及数据操作语言（DML）语句，以及数据库上的数据库管理事件（尤其是在首次进行生产级发布的早期阶段）。接下来，您可以根据使用情况逐渐摸索情况，缩小条件范围，据此增强对当前安全设计的信心。
在Amazon RDS中，您可以使用CloudTrail记录一切指向Amazon RDS API（例如CreateDBInstance, StartDBInstance以及StopDBInstance）的调用。此外，如果您的数据库引擎能够支持，也可以使用配置驱动的单一数据库管理系统引擎中的SQL审计或系统审计表，对指向数据库的SQL查询进行审计。我们将在后续文章中具体讨论这些内容。
您可以使用CloudWatch设置警报规则，创建实时Amazon SNS通知或执行AWS Lambda函数，借此在工单系统中创建安全事件或在SIEM系统中触发事件。另外，您也可以配置CloudTrail将事件日志发送至CloudWatch。Amazon Aurora MySQL、Amazon RDS MySQL以及MariaDB可以将包含已审计SQL查询的数据库实例日志事件直接发布至CloudWatch。
泳道隔离
泳道隔离能够在域驱动型设计背景之下得到充分发挥。如果您考虑将微服务分组至类似于您业务模型的域当中，也可以尝试结合业务域上下文设计微服务中的数据存储安全性。以此为基础，您可以实现两项目标：
- 强制执行纯微服务数据访问模式，确保只能通过自有微服务API对微服务数据存储进行访问。
- 确保来自某一微服务域的敏感数据不会通过另一微服务域被泄露出去。
这里我们不妨考虑一个典型的组织场景，组织通过API收集、保留及公开多种敏感性及机密性级别的数据。例如，某家银行可能存储有大量包含高敏感度内容的支付域API数据。该银行还可能需要在市场营销域内使用API，用于在公司网站上公布营销数据。
此外，相较于所涉及数据敏感度较低的营销域API，支付域API可能拥有更高的安全性与非功能性要求。在此示例中，泳道隔离将在两个域之间建立严格的网络分隔（网络泳道），确保任何人无法通过营销域中的请求遍历或直接访问支付域内的数据存储。
您可以将适当的IAM控制与网络流控制方法加以组合，建立这种泳道隔离。网络流控制将在数据存储层的整个子网上添加一个网络ACL，或者仅允许从支付域VPC端点访问数据存储，同时拒绝任何其他流量。关于更多详细信息，请参阅VPC端点与网络ACL。
总结
在本文中，我们探讨了在亚马逊云科技上保护数据安全的一系列最佳实践与实现方法。本文还解释了Amazon CAF以及Amazon CAF安全性视角内的五大关键功能：Amazon IAM、检测性控制、基础设施安全、数据保护以及事件响应。
本文中提到的最佳安全实践还与安全视角中的某些关键功能相关，具体包括定义IAM控制、对数据库实施检测性控制的多种方法、通过网络流控制增强数据周边基础设施安全性，以及通过加密与令牌化实现数据保护等。
关于数据安全最佳实践的更多详细信息，请参阅《AWS安全最佳实践》白皮书以及《AWS安全概述——数据库服务》白皮书。
在本系列文章的第2篇中，我们将探讨如何在Amazon RDS数据库中实现这些概念。
在本系列文章的第3篇中，我们将探讨如何在Amazon DynamoDB数据库中实现这些概念。