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 汇报。下表包含他们的紧急联络信息。
在上表中创建相应条目后，将以下策略添加至代表经理的各 IAM 用户与角色当中：
添加以上策略之后，经理将只能看到自己的详细信息，以及向他们报告的普通用户的紧急联络信息。
关于在条目层级与属性层级应用细粒度访问控制的更多详细信息，请参阅使用IAM策略条件进行细粒度访问控制。
泳道隔离（Swim-lane isolation）
为了在不同业务域的数据库与应用程序之间实施严格的子网级隔离，大家应实施泳道隔离机制。要在 DynamoDB 中实现泳道隔离，请使用 VPC 端点，具体操作如前所述。关于泳道隔离的更多详细信息，请参阅保护AWS数据存储中敏感数据的最佳实践。
总结
本文展示了如何使用系列文章第一篇中提到的通用数据安全模式保护 DynamoDB 数据库，并借此帮助您为敏感数据建立起牢固可靠的安全状态。
本文还展示了如何使用分层方法实现纵深防御，借此保护 DynamoDB 数据库。本方案通过 VPC 中的网络 ACL 与子网，共同建立起网络安全区。
另外，我们也探讨了如何在 AWS 网络、IAM 以及数据库服务中启用 AWS 预防性安全控制组合，以及如何通过 Amazon GuardDuty、AWS Config 以及 CloudTrail 设置检测控制机制为数据提供纵深防御保护。关于 DynamoDB 的更多详细信息，请参阅DynamoDB 入门指南。我们也欢迎您的反馈意见，请在下方评论区中与我们交流。
作者介绍：
Amazon Web Services 公司解决方案架构师。他与金融服务业客户合作，帮助他们在云环境中部署安全、弹性且高度可扩展的高性能应用程序。
Amazon Web Services 公司解决方案架构师。他与 AWS 客户一道为数据库相关项目提供指导与技术支持，帮助项目方借助 AWS 的力量提高解决方案价值。
本文转载自亚马逊 AWS 官方博客。
原文链接：
运用最佳实践，保护 Amazon DynamoDB 中的敏感数据
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论