利用 Amazon CloudHSM 为出海企业打造 PCI-DSS 安全合规底座

背景

合规是企业出海面临的首要问题，出海企业海外运营需要遵守当地的法律和行业合规要求，否则业务将无法开展，并会面临巨额罚款以及数据泄露等风险，导致经济和声誉的双重损失。对于出海企业常见的合规有 PCI-DSS，GDPR，HIPPA，ISO 27001，SOC2 等，这些合规标准的实施范围通常分为物理基础设施层级（云本身的安全）以及用户服务层级（云内部的安全）。

合规审计的要求十分复杂，数量也非常繁多，如 PCI-DSS 的安全控制要求有 300 条以上，这大大增加了出海企业的合规成本。在这些合规要求中，隐私数据保护是其中的核心，如 PCI-DSS 的主要要求就是围绕保护持卡人数据（姓名、卡号、有效期）和敏感验证数据（磁条信息、密码、CVV）保护展开的，比较有代表性的就是要求 4：在开放或公共网络上加密传输持卡人数据。在传输过程中保护持卡人数据就涉及到使用 TLS 证书，若证书私钥的保护不力，黑客则会利用泄露的证书私钥进行中间人攻击，窃取持卡人的信息，造成信息泄露风险。因此出海企业需要基于行业立法机构和企业级用户的安全合规要求建立起一套合规框架，来保护 TLS 证书私钥安全，进而对持卡人数据保护。在金融/支付行业中，通常要求使用 FIPS 140-2 Level 3 安全认证的专用加密机保护，同时根据安全规范设置对私钥的访问策略、数据保护方案等。

本篇博客会主要介绍如何利用亚马逊云科技提供的全球化基础设施以及 140+项安全合规认证、300+安全合规云服务和功能，帮助出海用户打造安全合规的业务底座，大幅度减轻出海用户出海在合规、审计工作中的压力和成本，提升安全合规竞争力，促进出海企业在海外业务的发展。

场景

通过使用符合 FIPS 140-2 Level 3 标准、PCI-DSS 合规要求的 CloudHSM，为用户传输中的 TLS 加密数据分载方案。

FIPS 140-2 标准是由美国国家标准技术研究院（NIST）定义的加密安全要求，在金融和支付行业中广泛使用，金融/支付企业主要使用满足 FIPS 140-2 Level 3 验证的加密设备保护和管理秘钥。FIPS 140-2 level 3 要求对企图通过物理登录、使用或篡改加密模块的攻击活动，具有更高的检测与作出反应的能力，同时要求加密机有基于身份识别的验证和授权（IAM）机制，因此用户需要使用单租户的加密设备，对加密机设备拥有完全的管理控制以及对设备的单独访问。

PCI-DSS 合规是由支付卡行业安全标准委员会（PCI SSC）于 2006 年设立的国际信息安全标准，其目的是加强对信用卡持卡人信息的保护，以减少信用卡欺诈犯罪。该合规规定了存储、处理和传输持卡人数据/敏感信息的 12 大类要求和最佳安全实践。如 PCI-DSS 要求 4 就规定，对持卡人数据传输过程中要进行加密保护。其子要求 4.1 则规定了：企业需要使用强大的加密和安全协议在开放的公共网络中传输持卡人敏感信息，这也意味着需要使用可信的秘钥和证书、安全的加密协议（TLS v1.2 以上）以及高标准的秘钥强度。因此用户需要使用硬件加密设备生成和保护证书及私钥，以提供对私钥的高度安全防护。

PCI-DSS 安全要求 4 部分截图（图片源自 PCI-DSS v3.2.1 官方文档）

加密机是一种专门用于加密、解密及相关管理的设备，包含加密、解密，密钥管理，随机数生成，认证、授权，审计和日志等多种功能。它的诞生有几十年的历史，最初应用在军事和通信领域，后被广泛应用在金融、电子商务、医疗、物联网等领域。为了物理安全、保障性能、独立控制、便于日常审计等原因，在很长一段时间，都只有物理加密机。物理加密机及相关配套建设一次性高投入、长周期、不易扩展和维护，使得它门槛较高，只在特种行业且规模较大公司中使用。随着信息技术特别是云计算和云安全技术的发展，云加密机概念应运而生，它与物理加密机功能相同，且实施时间短，一次性投入成本低，扩展性好，降低了加密机的使用门槛，使之更为普及。Amazon CloudHSM 就是一种基于硬件安全模块（HSM）的亚马逊云计算平台上的单租户加密机。它拥有多项合规认证，如 FIPS 140-2 Level 3、PCI-DSS、PCI-PIN、PCI-3DS、SOC2 等，满足用户基础设施合规需求并有效保护 TLS 证书私钥。亚马逊云科技用户可以从 Amazon Artifact、亚马逊云科技合规计划主页获取关于 CloudHSM 的合规认证信息和报告。Amazon CloudHSM 服务提供的 OpenSSL 动态引擎支持与 NGINX、Apache 或 Tomcat 网页服务器集成，实现对用户传输中的 TLS 加密数据进行分载，配合 Amazon Network Load Balancer 实现云上业务的高可用。

面对的挑战

搭建满足 PCI-DSS 合规的本地物理 FIPS 140-2 Level 3 HSM 加密机流程复杂，成本也十分高昂。这是因为这些合规的认证范围不局限于单独的 HSM 加密机设备，也覆盖了托管加密机的数据中心。如 PCI-DSS 要求 9 就指出用户需要限制对持卡人数据环境的物理访问，这就要求用户自建满足 TIA 标准的数据中心建筑、电力、消防、网络等系统的同时，配置数据中心物理及逻辑访问控制（要求 9.1、9.2、9.3、9.4）、持卡人数据存储及传输保护方案（要求 9.5-9.7）、监控系统，以及规范数据销毁策略（要求 9.8）等。数据中心各项要求通过审计认证后才能投入使用。如果企业想实现更高标准的业务连续性，通常需要搭建多个数据中心以满足跨区域容灾方案，总成本会高达数百万美元，建设周期长达数年，造成产品服务交付缓慢，让出海企业承担高昂的合规成本。

PCI-DSS 安全要求 9 部分截图（图片源自 PCI-DSS v3.2.1 官方文档）

同时，随着企业业务增长，用户流量激增，数据中心中的HSM物理加密机无法及时弹性扩容，用户需要通过不断采购新的加密机物理设备来满足业务的要求，这些设备采购的长周期会阻碍企业业务增长。如今很多企业将应用服务托管在云计算平台上，若要在云端使用数据中心的 HSM 物理加密机设备，则需要搭建专线将本地连通云上系统，这类混合型架构的搭建和管理都十分复杂，需要考虑到本地和云平台的统一监控、维护更新，需要配置专线的高可用方案，还会遇到网络连接的带宽、延时限制等。并且物理 HSM 加密机的维护工作也给运维人员带来了不小的压力，如需要定期去数据中心更新加密机的操作系统、定期备份加密机中的秘钥数据、为加密机集群内的加密机之间配置高可用数据同步等。

解决方案介绍

利用 Amazon CloudHSM 进行 TLS 卸载提高用户传输中的数据安全性

在这篇 blog 中，我们将介绍如何利用符合 FIPS 140-2 Level 3 安全标准的 Amazon CloudHSM 服务的安全合规、低成本、弹性、高可用等优势，为出海企业解决上述海外业务落地过程中常见的挑战，快速搭建满足 PCI-DSS 的安全合规底座。在云上利用 Amazon CloudHSM 的经典场景有三类，分别是:

1) 将网页服务器中的 TLS 流量解密分载至 Amazon CloudHSM，以提升解密的效率和用户数据传输过程中的安全性
2) 利用 Amazon CloudHSM 集成 Private Certificate Authority (PCA)，搭建和管理企业符合 FIPS 140-2 Level3 安全标准的 PKI。使用 Amazon CloudHSM 保护根 CA 及其私钥，并利用 PCA 储存和管理 CloudHSM 签发的下级证书颁发机构（如 MATTER PKI 场景）
3) 利用 Amazon CloudHSM 保存用于数据库透明数据加密的主密钥（信封加密场景）

下图展示了本方案的架构图。我们利用 Amazon CloudHSM 生成用于HTTPS加密的私钥和证书签名请求（CSR），通过第三方 CA 签发证书后，将证书和虚拟 PEM 私钥添加至 NGINX Web 服务器配置文件中。在 TLS 握手流程中，NGINX 通过 Amazon CloudHSM OpenSSL 动态引擎去访问加密机中的私钥，并将加密数据发送至加密机中进行 TLS 分载，利用满足 PCI-DSS 合规认证、FIPS 140-2 Level 3 安全标准的加密机可以进一步保护用户数据在传输过程中的完整性、保密性和可用性。同时我们利用亚马逊云科技 Network Load Balancer 提供负载均衡服务，配合后端服务的弹性扩缩容，实现整体服务的高可用。

利用 Amazon CloudHSM 对传输中的加密数据进行 TLS 卸载架构示意图

利用 Amazon CloudHSM 进行 TLS 分载是如何工作的？

1. 客户端向服务器发送一个 hello 消息。
2. 服务器响应一个 hello 消息，并向客户端发送服务器的证书。
3. 客户端执行以下操作：
- a.验证服务器证书是否由客户端信任的根证书签名。
- b.从服务器证书中提取公钥。
- c.生成一个 premaster secret 随机数并使用服务器的公钥进行加密。
- d.将加密后的 premaster secret 发送给服务器。
4. 为了解密客户端发来的加密 premaster secret，服务器会将其发送到 CloudHSM 中。CloudHSM 使用其中存储的私钥解密 premaster secret，然后将解密后的明文发送给服务器。客户端和服务器使用 premaster secret 和两个 hello 消息共同计算出一个会话秘钥。
5. 握手过程结束，客户端和服务器之间的通信都使用会话秘钥加解密。

所需条件

部署前，你需要拥有以下环境：

拥有 2 个公有子网和 2 个私有子网的的 VPC，以满足业务高可用的要求。
一个已创建并生效的 CloudHSM 集群，在集群中创建 2 台在不同可用区私有子网中的 HSM 以满足高可用。对于关键业务，我们建议至少在两个不同可用区中创建至少 3 台 HSM。
在 HSM 中创建一个 crypto user（CU）用户。
安装和配置好 OpenSSL 客户端 SDK 5 动态引擎的位于不同可用区私有子网中的 2 台 Amazon Linux2 EC2 实例。同时将两台 Amazon Linux2 EC2 实例注册到目标组，然后将目标组添加到网络负载均衡器上，教程请参考使用弹性负载平衡添加负载均衡器。
在 HSM 中创建一个 RSA 私钥，导出虚拟 PEM 私钥，利用该虚拟私钥生成证书签名请求（CSR），并由第三方受信证书颁发机构签名 CSR 生成 TLS 证书，教程请参考生成或导入私钥和 TLS 证书。
在 EC2 服务器中安装 NGINX 版本：基础版 21.6 或企业版（optional）nginx-plus-r27

操作步骤

本章节会介绍如何在 EC2 里安装并配置 NGINX Web 服务器，以便借助 Amazon CloudHSM 进行 TLS 分载。

通过 SSM Session Manager 连接到 EC2 服务器
首先在 shell 中使用以下命令验证 OpenSSL 动态引擎安装是否成功

openssl engine -t cloudhsm

若显示以下结果则表示安装成功。

运行以下命令以创建 Web 服务器证书和虚拟 PEM 私钥所需的目录。

mkdir -p /etc/pki/nginx/private

运行以下命令以将当前路径下您的 Web 服务器证书和虚拟 PEM 私钥复制到所需位置。将 server.crt 和 server.key 替换成您证书和私钥的名字。

cp server.crt /etc/pki/nginx/server.crt
cp server.key /etc/pki/nginx/private/server.key

本方案使用 NGINX 系统用户运行 NGINX 服务，需要运行以下命令更改文件所有权，授权 NGINX 系统用户可读取它们。

chown nginx /etc/pki/nginx/server.crt 
chown nginx /etc/pki/nginx/private/server.key

配置 NGINX 环境变量文件路径，Systemd 将会在该指定的文件中查找 NGINX 环境变量文件：

sed -i '/Service/a\EnvironmentFile=/etc/sysconfig/nginx' /lib/systemd/system/nginx.service

为 NGINX 服务配置 CloudHSM CU 凭据的环境变量，NGINX 会利用 CU 用户权限通过 OpenSSL 加密引擎进行 TLS 解密操作，请输入以下命令，将 USER 和 PASSWORD 替换为您自己的信息：

echo "CLOUDHSM_PIN=USER:PASSWORD" >> /etc/sysconfig/nginx

在/etc/nginx/nginx.conf 文件中对 NGINX 服务器配置：

使用文本编辑器编辑打开文件

vim /etc/nginx/nginx.conf

在文件顶部，添加以下内容：

ssl_engine cloudhsm;
env CLOUDHSM_PIN;

在 TLS 模块添加以下内容，请将 location 指令块中的匹配参数和 proxy_pass 反向代理规则根据您的后端应用服务信息进行修改：

# Settings for a TLS enabled server.
server {
    listen       443 ssl http2 default_server;
    listen       [::]:443 ssl http2 default_server;
    server_name  _;
    root         /usr/share/nginx/html;

    ssl_certificate "/etc/pki/nginx/server.crt";
    ssl_certificate_key "/etc/pki/nginx/private/server.key";
    # It is *strongly* recommended to generate unique DH parameters
    # Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
    #ssl_dhparam "/etc/pki/nginx/dhparams.pem";
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout  10m;
    ssl_protocols TLSv1.2;
    ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA";
    ssl_prefer_server_ciphers on;

    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

location / {
proxy_pass http://backend_server;
    }

    error_page 404 /404.html;
    location = /40x.html {
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

验证 NGINX 配置是否正确，输入以下命令

nginx -t

若显示以下输入则表示配置成功。

加载 NGINX 配置文件、关闭并启动 NGINX、为 NGINX 设置开机启动：

sudo systemctl stop nginx
systemctl daemon-reload
systemctl enable nginx
systemctl start nginx

总结

在本篇博客中，我们介绍了如何使用 Amazon CloudHSM 服务搭建 TLS 分载方案，以提升用户数据传输过程中的安全性，满足金融出海企业的 PCI-DSS 安全合规要求。此外该解决方案还具有以下几个优势:

安全性——Amazon CloudHSM 为单租户加密设备，由用户完全管控，实现 HSM 用户精细化权限管理、HSM 用户法定人数验证，支持 RSA、AES、3DES、ECC 等多种类型密钥，加密机数据默认加密并支持自动备份对数据进一步保护，这些功能满足了更高标准的安全合规要求。

同时亚马逊云科技帮助出海用户打造了全球化的安全合规底座，满足了基础设施层级的合规性。利用责任共担模型，用户可以省去对于物理数据中心合规审计和维护的工作量。

性价比更高——采用即付即用的付费模式，出海企业不再需要搭建数据中心和采购加密机，省去大量基础设施投入成本；
高可用性——通过搭建 CloudHSM 跨可用区集群和跨可用区应用服务器，可以实现 CloudHSM 以及业务的高可用性。利用集群，HSM 加密机的操作和内部数据将自动保持同步更新，确保即使某个可用区出现问题，利用 CloudHSM 客户端实现 CloudHSM 故障切换，将秘钥操作请求转移到健康可用区的 HSM 加密机。同时，利用 Network Load Balancer 健康检查，在某可用区的应用服务器出现问题时，Load Balancer 会将流量路由到健康的应用服务器，应用仍然可以正常访问；
易于维护——Amazon CloudHSM 的 HSM 之间的数据同步由亚马逊云科技自动托管，加密机的创建、管理以及秘钥管理通过远程访问 API 实现，实现“一键式”操作，大幅减轻 HSM 基础设施和高可用架构的搭建与 HSM 运维压力。

同时，我们针对 Amazon CloudHSM 设计了 RTO 优化的容灾方案保证业务在灾难发生时的连续性，在下一篇博客中我们将会对该方案进行介绍。

亚马逊AWS官方博客