曲突徙薪 – 亚马逊云科技数据库安全相关方案

1. 前言

数据对企业而言越来越重要，益发成为企业的核心资产。如何保证数据的安全，是企业必须重视的问题。然而，数据库的安全往往面临许多挑战，比如企业出海或者进入中国，如何保证安全合规，符合当地法律法规；对于数据库发布的漏洞和补丁，是否可以及时监控和修补；数据库的访问如何做到最小权限的控制，只允许特定人/应用从特定地点对特定的数据库对象进行访问；数据如何进行加密，比如如何进行存储加密、传输中的加密、指定特殊字段的加密等；数据库如何在一个节点发生故障时能够及时监测到，通过快速的故障恢复机制切换到健康的节点或者集群；如何审计数据库操作，比如异常用户的异常登录、删库跑路等行为。

针对这些安全挑战，我们可以在数据库领域进行三个方向的应对：事前防范、事中监控及修复、事后审计。事前防范可以考虑安全合规、及时监控漏洞并更新补丁、配置良好的数据库访问控制策略、设计严谨的加密策略等；事中监控及修复可以考虑构建数据库的高可用架构、及时备份以及监测数据库登录行为等；事后审计可以采用审计日志、数据库活动日志等来进行实现。本篇博客聚焦数据库的安全合规，从几个维度总结亚马逊云科技上的数据库安全方案，旨在为您考虑数据库安全时提供指导。

2. 数据库安全合规

安全合规方面有多种安全规范，比如通用的 ISO 27001 认证、中国的网络安全等级保护 MLPS、涉及信用卡支付业务的 PCI DSS 认证，涉及个人医疗信息的 HIPAA 认证，汽车行业的 R155、R156 法规等。此外，许多国家地区还有独立的安全要求，比如个人信息保护法、GDPR 等。数据库存储着企业的核心资产，必须考虑安全合规的支持。

为了辅助客户做到安全合规，亚马逊云科技的数据库通过了多种安全认证，比如 SOC，ISO，PCI，HIPAA，FedRAMP，Singapore MTCS 等，您可以从官方网站上进行查询。此外，托管数据库的多项能力，也降低了客户通过特定安全规范的技术难度，减轻客户负担。以汽车行业常见的法规 R155 为例，它对服务器安全有下列要求：

针对操作系统漏洞问题，如果您使用托管数据库，亚马逊云科技会负责对安装托管数据库的底层 EC2 的操作系统进行安全的修复。您无需像使用自建系统一样需要自己监测漏洞，找到相应修复方法，并手工登录到 EC2 自己去打安全补丁。日志审计机制方面，托管数据库可以提供对数据库的访问信息的多种审计方式，可以将审计信息输出到 CloudWatch 日志记录，也可以通过流的方式发送到 Kinesis Data Streams，供您进行更加实时的监测和审计。防泄漏机制方面，亚马逊云科技数据库原生支持数据的存储加密、传输加密等，也支持和密码管理软件 Secrets Manager 的集成，进而实现用户密码的安全存放和轮转。

3. 补丁修复

漏洞的即时发现和修复对于数据库而言也至关重要。有专门的 CVE 网站可以列出各个产品中的漏洞信息。下面是从网站上搜索到的 MySQL 的 CVE 信息，尽管有些条件是偶发或者 corner case，但是如果碰到涉及到的影响是会比较严重的，经常会带来数据库 hang 住或者重复 Crash。

亚马逊云科技的托管数据库会自动打补丁，客户只需要点击确认或者自动确认即可，减少客户运维的工作量及安全风险。Amazon RDS 和 Aurora 数据库会及时追踪 CVE 信息，并进行安全修复，也会将关键的 CVE 修复信息包含在各个版本的 Release Notes 中。即便对于 MySQL5.7 社区宣布 EOL 不再修复 CVE Bug，针对有些客户仍然需要使用 5.7 的情况，亚马逊云科技也推出了扩展支持的选项，会修复漏洞信息。

4. 访问控制

控制数据库的访问能够从入口上事先预防一些安全风险，常见的控制有三类：1） 网络安全控制； 2）数据库资源的控制，比如允许哪些用户进行更改或者删除数据库实例的操作；3）数据库登录认证和库内特定对象的访问权限。

网络安全控制可以通过控制数据库集群的部署策略来实现。尽管 RDS 数据库提供了公网访问的权限，我们强烈建议您不要在生产环境的数据库中开启公网访问。此外，您可以通过 VPC、子网组以及安全组等网络级别的控制来为数据库的访问提供最小权限。

数据库资源控制是针对数据库资源本身的访问权限，比如谁可以创建、更改、删除一个数据库，谁可以创建、更改、删除数据库的参数组等等。这些可以使用 AWS IAM 来实现，通过给特定的 Role 来指定对应权限。

数据库安全登录认证，常见有两种方式：1）使用普通用户名密码登录，但把密码存放在安全地方，比如 Secrets Manager。Secrets Manager 提供的密码自动轮转的功能，可以符合安全法规的需求，减少用户自己轮转密码的负担；2）使用 IAM 数据库认证。IAM 认证避免了用户显式存放密码的工作，会为每次连接生成临时凭证，用户可以根据临时凭证连接到数据库。IAM 认证适合数据库并发连接不多的情况，在每秒 200 个并发连接以下使用比较理想；如果并发较多，可以尝试使用 Secrets Manager。

在创建 RDS 数据库实例时，有一个选项是可以选择使用 Secrets Manager 来存储数据库主密钥并进行轮换，RDS 会自动为您生成密码并通过 Secrets Manager 来管理生命周期。

当然，您也可以指定密码并随后存储在 Secrets Manager 中。创建其他用户名的密码可以同样存放在 Secrets Manager 中。您在应用程序连接数据库时，可以先连接到 Secrets Manager 获得密钥，再通过该密钥连接数据库，这里是连接 Secrets Manager 的代码示例。

创建数据库实例时，您也可以选择使用 IAM 进行登录认证。

当指定 IAM 登录后，您可以在数据库内创建新用户时直接指定该用户认证采用 IAM。这样，当该用户使用 IAM 登录时，IAM 会给到客户到一个 15 分钟即过期的临时凭证，客户端通过该临时凭证连接数据库。

CREATE USER jane_doe IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS'; 

对数据库内部对象的访问，比如特定表只允许特定人从特点地点访问，您可以使用 Grant/Revoke SQL 语句来实现。如下例所示：

grant all privileges on*.* to abc@'%'identified by'111111’ with grant option; FLUSH PRIVILEGES;

对表里特定行、特定列的访问控制，您可以通过创建数据库视图，并将视图赋权给特定用户来实现。如下例所示：

CREATE VIEW [Brazil Customers] AS
SELECT CustomerName, ContactName
FROM Customers
WHERE Country = 'Brazil';

在 MySQL 8.0 中，提出了数据库角色 Role 的概念，您也可以利用到 Role，更好的进行批量用户权限的管控。

5. 加密脱敏

事前进行加密和脱敏处理，能够提高数据的安全性。对数据的加密需求一般有几种不同维度：1）存储加密，数据存储时以密文存放；2）传输加密，防止黑客从网络中间攻击，拿到信息；3）特定字段的加密和掩码，某些关键字段比如信用卡号、手机号等需要进行加密，特定用户访问时只能访问掩码之后的数据；4）数据的脱敏处理，比如生产环境数据需要导出供测试部门使用，或者是导出给合作部门使用，但需要进行脱敏处理。数据的脱敏又包含敏感数据的发现以及脱敏方案。

Amazon RDS 原生支持数据的存储加密，您在创建数据库时可以指定自己的 KMS 或者默认 KMS 来进行存储加密。

KMS 对数据加密时采用的是信封加密机制：唯一数据密钥加密客户数据，Amazon KMS 主密钥加密数据密钥。这样能够降低数据密钥泄漏的风险，也能在加密大量数据时提供较好的性能。存储加密算法采用的是 AES-256 加密算法，最小化加密对性能带来的影响。除数据库本身加密外，数据库快照的加密也是非常重要的，因为快照会允许在不同的云账号之间共享，如果不加密，会导致核心数据无法管控。RDS 数据库会使用 KMS 对主库、从库、快照、日志进行加密。通过对 KMS Key 的权限管理，可以保护数据库快照里的核心数据。

数据传输中加密能够防止恶意用户进行网络劫持进而拿到原始数据。Amazon RDS 数据库创建时，默认支持 SSL 加密。您可以通过客户端指定是否通过 SSL 方式进行连接。Amazon ElastiCache 在数据库创建时提供了是否进行传输中加密的选项。对于关键的数据，您可以选择打开该选项。

有时用户需要对表里的特殊字段，比如银行卡号信息等进行加密存储，防止他人偷窥。我们有三种方案来进行实现：

1. 应用程序实现。可以手动更改应用程序，在写入数据库之前，将对应列用特定 key 进行加密，然后将密文入库；在读取数据时，从数据库中读取密文，然后进行解密操作，拿到原始信息。密钥可以使用 KMS 进行创建和管理。
   
2. 使用亚马逊合作伙伴 Baffle 的方案。Baffle 是一家美国的商业公司，专攻数据保护领域，支持数据加密和动态掩码，支持 Amazon KMS，支持多种数据库产品比如 Amazon Aurora，Redshift 等。下面是 Baffle 的示意图。Baffle 以 Baffle Shield 方式对外提供服务，在 RDS 前面增加了 Proxy 层，可以对用户输入的数据进行加密存储，并为用户访问数据时进行掩码操作，它可以对不同的用户采用不同的策略。
   
3. 使用 ShardingSphere 方案。可以使用开源产品或者亚马逊合作伙伴 SphereEx 的技术支持。ShardingJDBC 支持在 JDBC 层级对数据进行加解密操作，简化了您需要手动写程序的负担。你可以查看 ShardingSphere 文档来了解更多详细内容。
   

客户敏感数据的保护也涉及到如何找到敏感数据，亚马逊云科技推出的敏感数据保护方案能够自动扫描包括 RDS 在内的数据源，根据用户定义的敏感数据规则识别出敏感数据，并通过 UI 的方式进行展现。而生产环境数据在导出构建测试环境或者分享给其他部门时，经常需要进行脱敏操作，防止敏感数据泄漏。亚马逊合作伙伴安华金和提供了多种脱敏方案，包括静态脱敏和动态脱敏。

6. 高可用架构及备份恢复

数据库面临安全风险而导致某个数据库节点甚至整套集群停机时，是否能够进行快速的应对尽快恢复服务，对客户业务至关重要。大体而言，可以从两方面来进行应对：1. 数据库的高可用架构保障。当某个节点发生故障时，及时切换到其他节点（低 RTO），同时尽可能减少数据丢失（低 RPO）；2. 备份恢复。包括日常自动备份以及重要事件节点比如应用新版本发布时的手动备份等。数据库发生故障时，可以基于备份恢复出数据库系统。

在多种不同方案中选型时，可以从几个维度进行综合考量：1）RTO。数据库 Down机的时间直接影响了恢复速度；2）RPO。数据可能丢失的范围；3）因高可用产生的额外架构模块是否可以支撑业务负载；4）成本。采用此方案带来的额外成本消耗；5）支持范围，比如是否支持跨区域的容灾。

下面列出了 Amazon RDS 常见的高可用架构以及对应的指标对比，前四项属于架构层面，后两项为备份恢复方面。从 RTO/RPO 方面，RDS 多可用区实例、多可用区集群、Aurora、全球数据库等都能提供很小的 RPO，而故障切换时间 RTO 一般能在 1-2 分钟以内能够完成；备份恢复方案的 RTO 视数据库规模大小决定，不同数据库可能恢复时间差异会较大。RDS 的 PITR 按时间点恢复功能能够恢复出 5 分钟之前的数据形态，所以 RPO 最大为 5 分钟，相对架构方面较长，但是成本较低。从业务负载支撑方面，多可用区集群、RDS/Aurora 读副本以及 Aurora 全球数据库都能对外提供服务，相对多可用区实例来说能够更好利用到计算节点资源。从容灾范围方面，RDS 读副本和备份恢复都可以支持跨区域操作，Aurora 全球数据库能够使跨区域的数据库复制延迟降低到 1 秒，主区域故障时也能在分钟内进行快速从区域提升或者 failover 切换。

在构建数据库高可用方案应对高可用以及安全风险时，建议您根据应用的实际情况和成本预算进行综合评估和考量。对于重要行业比如需要符合 PCI 安全规范或者重要业务系统比如需要通过等保三级的情况，建议您选择跨区域的备份方案，来提升数据库的高可用。

7. 监控与审计

数据库的监控以及及时审计能够帮助用户及时发现可能安全风险并进行应对。

首先，数据库的日常监测中，发现异常指标，可能是由于安全风险带来的。我们可以采用 CloudWatch、Enhanced Monitoring 增强监控、Performance Insights、RDS Events 进行日常监控处理，发现可能的性能问题及异常行为。

其次，数据库的登录行为监控。您可以开启 GuardDuty for RDS Protection，目前适用于 Aurora 数据库，它能够以 AI 方式监控数据库登录信息，发现可疑登陆行为，及时进行告警。

GuardDuty 可以监控多种异常行为，也会标注不同风险级别：

• 用户以异常方式成功登录到您账户中的 RDS 数据库。 （高风险）
• 在您账户的 RDS 数据库上观察到一次或多次不寻常的登录尝试失败。
• 在经历了多次异常失败尝试后，用户以异常方式成功地从公有 IP 登录到您账户中的 RDS 数据库。（高风险）
• 用户从已知的恶意 IP 地址成功登录到您账户中的 RDS 数据库。（高风险）
• 与已知恶意活动相关的 IP 地址尝试登录您账户中的 RDS 数据库，但未成功。
• 与已知恶意活动相关的 IP 地址探测了您账户中的 RDS 数据库；未尝试进行身份验证。
• 用户从 Tor 出口节点 IP 地址成功登录到您账户中的 RDS 数据库。（高风险）
• 一个 Tor IP 地址试图登录您账户中的 RDS 数据库，但未成功。
• Tor 出口节点 IP 地址探测了您账户中的 RDS 数据库，但未尝试进行身份验证。

使用 GuardDuty 来进行数据库安全保护时，和保护其他服务一样，可以与亚马逊其他安全系统 SecurityHub，Amazon Detective 进行良好集成。

此外，数据库的快速审计对于及时发现用户的异常操作以及满足安全部门的审计需求也是安全方面的关注重点。Amazon RDS 数据库提供多个审计选项来支撑不同的诉求。

审计日志 Audit Log。Amazon RDS MySQL/MariaDB 通过 Option Group 的方式提供对 MariaDB 审计插件的兼容。MariaDB 审计插件可以记录数据库活动，比如用户登录数据库、针对数据库运行查询等。数据库的活动记录存储在日志文件中，您可以选择将日志文件上传到 CloudWatch 进而在 CloudWatch 上进行日志分析、警报定义等，也可以选择通过 RDS 的接口 API 下载日志。

Amazon Aurora MySQL 支持通过参数的方式进行审计日志的输出，而且该参数是动态参数，打开审计日志可以在线完成而无需重启数据库。同样，Aurora 的审计日志也可以上传到 CloudWatch 进行后续分析，也可以通过 RDS API 接口下载。Aurora 审计日志的实现相比 RDS MySQL 进行了优化，它可以同步生成几个文件，能够实现多个并发事务的日志记录，降低了打开审计日志对 MySQL 数据库的性能影响。

Database Activity Streams 审计。Amazon Aurora 支持 Database Activity Streams 来进行进一步的审计。

相较审计日志而言，DAS 有如下优势：

• 审计信息相对更加实时。审计日志信息会通过 Kinesis Data Streams 的方式流到后端，用户可以更加实时获取审计信息，进行相对更加快速的处理。
• 提供更加详细的日志输出。除了命令类型外，还提供很多输出信息，比如时间戳、进程号、查询执行结果行数、事务 ID 信息等等。
• 审计信息加密。通过 KMS 进行审计信息加密，并可以单独赋予操作审计日志的权限给特定用户，可以避免 DBA 操作审计日志，提供更加安全的保证。
• 和第三方审计软件集成，比如 Imperva’s SecureSphere Database Audit and Protection, McAfee’s Data Center Security Suite 和 IBM’s Infosphere Guardium。

当您在 Aurora 数据库上开启 DAS 后，亚马逊会自动创建一个 Kinesis Data Streams。您可以在该 Stream 后通过 Kinesis Data Firehose 和 Lambda 的方式来进行审计信息的处理（参考该方案），也可以直接通过第三方的软件进行审计操作（参考该方案）。

Amazon 其他托管数据库比如 ElastiCache 支持将日志传输到 CloudWatch 或 Kinesis Firehose，DocumentDB 和 Neptune 等均支持将日志传输到 CloudWatch，DynamoDB 支持将 audit 日志打出到 CloudTrail 中，您可以间接将 CloudTrail 数据打出到 CloudWatch。

API 审计。Cloud Trail 中支持对 RDS 的配置，来进行对于数据库资源操作行为的审计，比如创建、更改、删除数据库等。您可以视情况进行审计配置。

8. 总结

数据是企业和组织的重要资产，数据库安全越发重要。保障数据库的安全，一般从几个维度入手：安全合规、漏洞修复、访问控制、加密脱敏、高可用容灾以及监控审计。本篇博客从上述维度分享了亚马逊托管数据库的功能、应对策略以及一些合作伙伴的方案，希望能对您的数据库安全建设起到帮助。最后总结本文提出的数据库安全最佳实践相关的技术供您参考。

本篇作者