亚马逊AWS官方博客
运用最佳实践，保护 Amazon DynamoDB 中的敏感数据
Original URL: https://aws.amazon.com/cn/blogs/database/applying-best-practices-for-securing-sensitive-data-in-amazon-dynamodb/
在本系列的第一篇文章《AWS数据存储中的敏感数据保护最佳实践》（Best practices for securing sensitive data in AWS data stores）当中，已经介绍了一系列常规安全性概念，以及适用于AWS数据存储的对应AWS安全控制机制。以此为基础，大家可以围绕数据构建起更强大的安全态势。在系列第二篇《应用最佳实践保护Amazon RDS中的敏感数据》（Applying best practices for securing sensitive data in Amazon RDS）当中，我们介绍了如何将这些概念具体应用于Amazon RDS数据库。本文是系列文章中的第三篇，主要阐述如何在Amazon DynamoDB中实现这些安全概念。
数据分类与安全区建模
在安全保护方面，最重要的前提在于明确了解当前正在处理的数据，以及与处理相关的各项特定要求。这些要求可能源自法规规定，也可能来自组织内部规章制度。您在实际应用中可能不需要使用本文提及的某些特定安全控制方案，例如数据令牌化。总之，我们在努力提高安全性标准的同时，也应保证选择适当的控制机制以降低风险的认知难度。
在完成安全区设计之后，我们应使用网络访问控制列表（ACL）进行具体实现，后文将具体进行探讨。此步骤涉及对粗粒度网络区域进行定义，并使用安全组在各安全区之内进行更具体的微分段。
在实施安全区建模时，请认真考量您的网络设计。CIDR范围的大小，将直接决定各个子网中所能维持的IP地址数量。因此，我们需要在CIDR范围设定方面充分考虑到子网支持（更多IP地址）与子网数量的后续增长。只有在各项基本要求间取得平衡，您的Amazon VPC与本地数据中心或其他VPC之间才能始终拥有互不冲突的IP地址空间。关于更多详细信息，请参阅AWS单一VPC设计指南。
关于更多深入说明，以及数据分类与安全区建模的相关概念，请参阅《AWS数据存储中的敏感数据保护最佳实践》。
预防控制
下图来自本系列中的第一篇文章，其中详细描述了纵深防御的基本概念。其中涉及控制机制主要分为两大类别：预防控制与检测控制。下面，我们首先讨论预防控制。
DDoS保护(DDoS Protection)
通过使用AWS Shield，大家能够保障自己的应用程序与数据库免受分布式拒绝服务（DDoS）攻击的影响。所有AWS客户均可免费获取AWS Shield Standard提供的自动保护。AWS Shield Standard能够防御针对您网站或应用程序的各类常见、频繁出现的网络及传输层攻击。在将AWS Shield Standard与Amazon CloudFront以及Amazon Route 53结合使用之后，大家即可为全部已知基础设施（L3与L4层）建立起全面的可用性保护。
您也可以根据需求订阅AWS Shield Advanced，借此联系DDoS响应团队并获取各项检测指标。关于其他保护措施的更多详细信息，请参阅AWS Shield功能介绍。
要启用AWS Shield Advanced，请完成以下操作步骤：
- 在AWS管理控制台上，选择 AWS WAF and AWS Shield。
如果您还没有启用AWS WAF或者AWS Shield Advanced，则系统会弹出以下页面（如果已经启用，则直接弹出仪表板页面）。
- 选择 AWS Shield。 该页面中显示了Standard与Advanced版本之间的区别。
- 选择Activate AWS Shield Advanced。
- 在Activate service部分，选中所有同意条款复选框。 .
- 选择Activate service。
应用层级威胁防护(Application-level threat prevention)
为了实现应用层级的威胁防护，我们建议大家使用AWS WAF。
您的Web应用程序需要访问存储在数据库中的数据。因此，最好是根据开放Web应用程序安全项目（OWASP）中列出的十大攻击威胁设计保护方案，保证数据免遭泄漏。配置AWS WAF能够保护您的应用程序免受此类威胁侵扰。AWS WAF在全球范围内与Amazon CloudFront协同运作，也可在各区域层级为AWS资源（例如应用负载均衡器及API网关）提供保护。
要使用AWS WAF预防OWASP十大安全威胁，请使用AWS CloudFormation与owasp_10_base.yml模板创建一份Web ACL。
网络隔离（Network isolation）
在管理DynamoDB中的敏感数据时，一大关键举措在于实现网络与DyanmoDB表之间的流量隔离。Amazon VPC正是实现这一安全隔离效果的基础设计组件。
要创建VPC，请完成以下操作步骤：
- 打开VPC控制台。
- 选择Your VPCs。
- 选择 Create VPC。
- 在Name tag部分，为您的VPC选择一个名称。
- 在IPv4 CIDR block部分，指定CIDR范围。
- 在IPv6 CIDR block部分，保留默认值“No IPv6 CIDR Block”。
- 在Tenancy部分，保留默认值“Default”。 通过以下截屏可以看到，本文示例使用的名称为
demoVPC，范围为10.0.0/16。
- 选择 Create。
我们需要保证往返于DynamoDB的数据库流量始终处于VPC的私有范围之内。DynamoDB是一项区域性服务，因此我们可以通过创建VPC端点以保证进出数据库的流量始终驻留在VPC专用网络当中。
为DynamoDB创建VPC端点，可保证VPC中的各Amazon EC2实例能够使用其私有IP地址访问DynamoDB，全程数据包避免暴露到公共互联网。您的EC2实例不需要公共IP地址，而VPC之内也不需要任何互联网网关、NAT设备或者虚拟专用网关。我们使用端点策略限制针对DynamoDB的访问。往来于VPC及AWS服务之间的流量不会离开Amazon 网络。关于更多详细信息，请参阅用于DynamoDB的Amazon VPC端点。
安全组与网络ACL（Security groups and network ACLs）
DynamoDB不支持网络ACL与安全组，但大家可以使用VPC端点与VPC端点策略实现网络分离。
我们使用网络ACL实现安全区建模。关于更多详细信息，请参阅Network ACLs。安全区提供拥有良好定义的网络边界，安全区内的资产拥有相似的信任级别。安全区还可以根据特征定义以及对往来网络流量的强制性控制，让安全控制变得更加清晰易行。
下图所示，为安全区建模的一种可行方法。
创建DynamoDB VPC端点并应用端点策略
要进行安全区建模，请为每个子网创建一个DynamoDB VPC端点。要对数据平面与控制平面流量进行分离，则应对各个VPC端点应用适当的策略。
下面，我们将创建两个VPC端点，并通过以下步骤将其中之一附加至App Tier子网，而将另一个附加至控制平面子网：
- 在VPC控制台上，选择 Endpoints。
这些步骤需要进行两轮，以为两套子网分别创建DynamoDB VPC端点。 - 在Service category部分, 选择 AWS services。
- 在Service name部分, 选择 Gateway的接口类型。
- 在VPC部分，输入您希望VPC端点附加至的VPC。
- 在Configure route tables部分，选择与App Tier及Control Plane相关联的子网。 选定一份路由表，用于创建一条通过VPC端点指向DynamoDB的全新私有寻址路由。请确保您的路由表关联了正确的子网。
- 在Policy部分, 选择 Custom。
- 为App Tier或Control Plane输入相应策略。 为了保证仅从App Tier子网中接收数据平面流量，请在DynamoDB VPC端点中使用以下策略：
为了保证仅从Control Plane子网中接受控制平面操作，请在DynamoDB VPC端点中应用以下策略：
- 导航至VPC控制台，选择 Endpoints。
- 选择各端点，点击Edit Policy并为其附加对应的VPC端点策略。
身份与访问管理（Identity and Access Management）
IAM是一款面向AWS客户的基础性控制组件，也是AWS良好架构框架中安全性支柱五大最佳实践中的第一项。该框架能够帮助大家逐步了解如何在云环境中设计并运营具备高可靠性、安全性、运行效率与经济效益的架构体系最佳实践。
要开始使用IAM以及定义单一用户、组及角色访问要求之前，需要先将各访问需求要求按照控制平面操作及数据平面操作拆分开来。
控制平面操作
控制平面操作属于DynamoDB上的管理函数，包括CreateTable, DeleteTable, UpdateTable以及 CreateBackup等。由于这些函数属于高权限操作，因此在为用户或角色分配相应权限时需要格外小心。
以下示例代码，在DynamoDB上授权了一组受限的管理操作。您可以将此策略附加至特定用户、组或者角色当中。
数据平面操作
数据平面操作，通常是指在DynamoDB表中执行的数据获取、放置及删除等操作。Amazon DynamoDB上的数据平面操作主要分为两种类型：数据库身份验证与数据库访问控制。
数据库身份验证，是指允许谁访问DynamoDB表。在这里，我们需要通过IAM设置身份验证。对于人类用户，大家可以使用基于IAM角色的联合身份（例如微软Active Directory）进行身份验证，也可以直接提供IAM凭证完成身份验证。对于应用程序访问，请将IAM角色直接附加至应用程序当中，借此启用访问身份验证。
访问控制是定义用户或应用程序拥有的访问层级的控制机制。我们可以使用IAM为DynamoDB定义访问控制。首先创建一项IAM策略，赋予应用程序最小访问权限原则。请明确您的读取/写入用例，并为各用例制定独立的IAM策略。
以下示例代码，为授权数据平面访问特定DynamoDB表的权限。将其附加至特定的IAM用户，或者与特定应用程序相关的角色。
要在您的DynamoDB环境中应用微分段，请使用限制性更强的用户或角色数据平面IAM策略。例如，即使DynamoDB VPC端点IAM策略已经允许各主体对所有表执行Get、Put以及Delete等操作，但对特定用户或角色IAM策略将仅允许访问特定的表。
下图演示了这种微分段方法。
加密与令牌化（Encryption and tokenization）
加密与令牌化，是实现数据库安全性的关键所在。启用静态加密除了能够保证DynamoDB表中设定的操作权限之外，还将确保仅在显式授权AWS KMS加密密钥权限的前提下，才能对AWS账户之外的DynamoDB数据库及DynamoDB表备份数据进行读取。
令牌化则是将敏感数据替换为唯一标识符，用户可以借此在其他数据源中查找原始敏感数据。与之不同，加密是通过密码对敏感数据进行编码，保证仅有授权方能够执行读取。
服务器端加密
使用自定义主密钥（CMK）对静态数据进行中国农民。大家可以在AWS托管CMK或者归AWS拥有的CMK中做出选择。这里建议大家使用AWS托管CMK，以便能在AWS CloudTrail日志中审计主密钥的使用情况。
要在创建新DynamoDB表时启用静态加密，请完成以下操作步骤：
- 在Table settings部分，取消Use default settings默认选项。
- 在Encryption at Rest部分, 选择 KMS。
- 在下拉菜单中，选择您的KMS密钥。
- 选择 Create。
客户端加密
使用DynamoDB Encryption Client进行客户端加密，在此加密过程中，我们将在把表数据发送至DynamoDB之前对其进行加密。大家可以根据数据的实际敏感性与应用程序的安全要求选择是否执行此项加密操作。关于更多详细信息，请参阅客户端与服务器端加密。
使用KMS管理您的客户端加密密钥。使用KMS密钥授权启用对应用程序数据加密的访问权限。使用客户端加密的一大优势，在于我们可以指示DynamoDB Encryption Client在整个或者部分表条目（包括主键属性与表名称）上计算签名。通过签名机制，大家可以检测整个项目中未经授权的变更，包括属性的添加或删除、以及属性值的更新。
传输数据加密
传输数据加密，可以保证数据在应用程序与DynamoDB表之间往来移动时仍保持加密状态。DynamoDB端点可通过HTTPS端点进行访问，不论是经由AWS管理控制台、CLI以及适用于DyanmoDB的AWS SDK。
令牌化
令牌化属于加密保护的替代方法，有助于保护具有高敏感度或需要遵循特定法规（例如PCI）要求的某些数据元素。建议大家将拆分敏感数据保存至其专用的安全数据存储当中，并使用令牌替代以降低潜在成本以及端到端加密带来的复杂性。另外，您也可以使用临时的一次性令牌化操作降低安全风险。
令牌化属于应用层级的实现操作。通常，大家可以使用专用数据存储区实现令牌持久化，而后将其与敏感数据值映射起来。令牌被存储在应用程序数据库当中以替换敏感数据值，并在运行时由应用程序替换为专用令牌数据存储区内的实际值。
下图所示，为令牌化流程示例。
图中包含以下具体步骤：
- 应用程序将敏感数据（例如信用卡号）传递至令牌化API。
- 令牌化API请求对应用程序用户进行身份验证。
- 身份验证API对用户执行身份验证。
- 令牌化API为信用卡号生成令牌，将令牌与信用卡号存储至令牌化数据库，并在数据库中将令牌和信用卡号链接起来。
- 令牌化API将令牌返回至应用程序。
- 应用程序在应用程序数据库中的存储此令牌以替代信用卡号。
检测控制（Detective controls）
检测控制对于数据库的安全保障同样非常重要。
大家可以通过多种不同方法，实现对未授权流量的检测，例如使用自定义逻辑以监控VPC Flow Logs以及CloudTrail日志，借此发现各种异常状况。关于VPC Flow Logs的更多详细信息，请参阅 VPC Flow Logs。关于CloudTrail日志的更多详细信息，请参阅使用CloudTrail日志文件。
DynamoDB能够与CloudTrail相集成。通过CloudTrail收集到的信息，您可以确定指向DynamoDB的请求、发出请求的IP地址、发出请求的人、发出请求的时间以及其他详细信息。大家还可以在DynamoDB上执行两种类型的操作：控制平面操作，与数据平面操作。
DynamoDB将各类控制平面事件（例如CreateTable, ListTables以及 UpdateTable API调用）自动发布至CloudTrail。关于更多详细信息，请参阅使用AWS CloudTrail记录DynamoDB操作。
启用Amazon GuardDuty
要使用机器学习功能自动监控网络流量并检测/警告异常行为，请启用Amazon GuardDuty。具体操作步骤如下：
- 在AWS管理控制台上, 选择 Amazon GuardDuty。
- 选择 Get started。
- 选择 Enable GuardDuty。
创建CloudWatch规则
通过创建CloudWatch规则，大家可以监控GuardDuty发现结果并据此采取对应操作。您可以通过Amazon SNS设置通知警报，也可以通过AWS Lambda设置自动修复措施。具体操作步骤如下：
- 打开Amazon CloudWatch控制台。
- 在 Events下, 选择 Rules。
- 选择 Create rule。
- 在Event Source部分，选择Event Pattern。
- 在下拉菜单中, 选择 Build custom event pattern。
- 输入以下代码：
- 在Targets部分, 选择 Add target。
- 在下拉菜单中 选择 SNS topic。
- 在Topic部分, 选择您的SNS主题名称。
- 选择 Configure details并为规则输入名称与描述，即可完成规则创建流程。
以下截屏所示，为以上步骤完成后的情况。
配置漂移（Configuration drift）
所谓配置漂移，是指系统在初始部署后接受的后续修改，可能导致系统的原有安全配置偏离必要的可靠状态。
大家可以使用AWS CloudFormation漂移检测对配置进行漂移识别。要根据基线设置持续监控数据库配置，并在发生配置漂移时发送警报，请使用AWS Config。
要完成设置，我们需要完成以下操作步骤：
- 打开AWS Config控制台。
- 在Events下, 选择 Rules。 如果您是第一次启用AWS Config，可能需要完成整个初始设置流程。
- 选择 Add rule。
- 在搜索框中，输入
dynamodb。 - 选择您希望启用的DynamoDB配置选项。 现在，您可以搜索并选择DynamoDB提供的预定义规则，也可以创建新的自定义规则。
细粒度审计（Fine-grained audits）
大家可以执行其他细粒度审计，通过控制平面操作或者数据平面操作进一步提高数据库安全性。关于更多详细信息上，请参阅Amazon DyanmoDB中的身份与访问管理。
控制平面操作
控制平面操作属于DynamoDB上的管理函数，包括CreateTable, DeleteTable, UpdateTable以及 CreateBackup等。所有Amazon DynamoDB控制平面都将被记录在CloudTrail日志与DynamoDB API文档当中。
通过创建新的跟踪，大家可以将所有CloudTrail日志存储在Amazon S3中以供后续审计。关于更多详细信息，请参阅使用AWS CloudTrail记录DynamoDB操作。
要创建新的跟踪，请完成以下操作步骤：
- 打开CloudTrail控制台。
- 选择 Trails。
- 选择 Create trail。
要创建与CloudTrail所记录的全部DynamoDB API调用相匹配的Amazon CloudWatch规则，并借此触发用户预先定义的通知或操作，请完成以下步骤：
- 打开CloudWatch控制台。
- 在 Events下, 选择 Rules.
- 选择 Create rule。
- 在Event Source部分，选择Event Pattern。
- 在下拉菜单中，选择Build custom event pattern。
- 在Service Name部分, 选择 DynamoDB。
- 在Event Type部分, 选择 AWS API Call via CloudTrail。
- 选择Any operation。
- 在Targets部分, 选择 Add target。
- 在下拉菜单中，选择 SNS topic。
- 在Topic部分, 选择您的SNS主题名称。
以下截屏所示，为以上各步骤完成后的情况。
数据平面操作
CloudTrail并不支持记录DynamoDB数据平面操作，例如GetItem与PutItem。大家可以将DynamoDB Streams作为环境中各条目层级修改事件（包括创建、更新或删除）的源。要满足数据平面操作的审计需求，则必须在应用层中记录数据平面的读取操作。
DynamoDB与AWS Lambda相集成，即可创建触发器以自动响应DynamoDB流中的事件。使用触发器，大家可以保证应用程序根据DynamoDB表中的数据修改做出反应。如果在表上启用DynamoDB流，则可将流的Amazon 资源名称（ARN）与Lambda关联起来。这样在表中的条目发生修改之后，表流中会立即显示一条新的记录。AWS Lambda会检测到这条新的流记录，并同步调用Lambda函数。Lambda函数可以执行用户预先指定的任意操作，例如发送通知或者启动工作流。关于更多详细信息，请参阅将Amazon DynamoDB Streams与AWS Lambda配合使用。
最佳实践之一是遵循最低权限原则。例如，我们应通过细粒度访问控制限制对DynamoDB表中特定条目及其特定属性的访问操作。通过细粒度访问控制，大家可以限制谁有权查看、编辑以及删除条目。关于更多详细信息，请参阅使用IAM策略条件实现细粒度访问控制。
使用IAM策略条件实现基于属性的访问控制（ABAC），我们可以指定用户名及属性名进行访问限制。关于更多详细信息，请参阅YouTube上的AWS re: Infoce 2019：在AWS/基于属性的访问控制中实现权限规模化管理。
要指定用户名称，您可以使用替换变量${www.amazon.com:user_id}，由其使用“dynamodb:LeadingKeys”条件键与面向DynamoDB执行调用的用户相结合，共同替代原始的用户名称。通过这种方式，即可将对项目的访问权限定至该特定用户。
例如，我们拥有雇员EMP001、EMP002以及EMP003，他们需要向经理MNG001与MNG002汇报。下表包含他们的紧急联络信息。
ManagerID (分区键) |
Reporting_Employee (排序键) |
Emergency_Contact |
| MNG001 | EMP001 | 1234 |
| MNG001 | EMP002 | 456 |
| MNG002 | EMP003 | 987 |
在上表中创建相应条目后，将以下策略添加至代表经理的各IAM用户与角色当中：
添加以上策略之后，经理将只能看到自己的详细信息，以及向他们报告的普通用户的紧急联络信息。
关于在条目层级与属性层级应用细粒度访问控制的更多详细信息，请参阅使用IAM策略条件进行细粒度访问控制。
泳道隔离（Swim-lane isolation）
为了在不同业务域的数据库与应用程序之间实施严格的子网级隔离，大家应实施泳道隔离机制。要在DynamoDB中实现泳道隔离，请使用VPC端点，具体操作如前所述。关于泳道隔离的更多详细信息，请参阅保护AWS数据存储中敏感数据的最佳实践。
总结
本文展示了如何使用系列文章第一篇中提到的通用数据安全模式保护DynamoDB数据库，并借此帮助您为敏感数据建立起牢固可靠的安全状态。
本文还展示了如何使用分层方法实现纵深防御，借此保护DynamoDB数据库。本方案通过VPC中的网络ACL与子网，共同建立起网络安全区。
另外，我们也探讨了如何在AWS网络、IAM以及数据库服务中启用AWS预防性安全控制组合，以及如何通过Amazon GuardDuty、AWS Config以及CloudTrail设置检测控制机制为数据提供纵深防御保护。关于DynamoDB的更多详细信息，请参阅DynamoDB 入门指南。我们也欢迎您的反馈意见，请在下方评论区中与我们交流。