第 2 章 加密和密钥管理
在设备间通信是严重的安全问题。通过网络进行安全通讯的方法变得越来越重要，如大量漏洞（如 Heartbleed）或更高级的攻击，如 BEAST 和 CRIME 等。但是，加密只是一个更大的安全策略的一部分。端点的破坏意味着攻击者不再需要破坏使用加密，但能够查看和操作消息。 本章将回顾关于将传输层安全(TLS)配置为保护内部和外部资源的功能，并将称为应该特别关注的特定系统类别。 OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会试图窃听频道，以获取对敏感信息的访问。因此，所有组件都必须使用安全通信协议相互通信。
2.1. TLS 和 SSL 简介
在某些情况下，需要确保 OpenStack 部署中网络流量的保密性或完整性。您通常使用加密措施（如 TLS 协议）进行配置。在典型的部署中，通过公共网络传输的所有流量都应强化，但安全良好的实践要求内部流量也必须受到保护。它不足而无法依赖安全区分离来保护。如果攻击者可以获得虚拟机监控程序或主机资源的访问权限，请危害 API 端点或任何其他服务，他们必须能够轻松地注入或捕获消息、命令或以其他方式影响云的管理功能。 您应该安全强化使用 TLS 的所有区域，包括管理区域服务和内部服务通信。TLS 提供了相应的机制，可确保身份验证、非对 OpenStack 服务的用户通信以及 OpenStack 服务本身之间的保密性、保密性和完整性。 由于安全套接字层(SSL)协议中发布的漏洞，请考虑使用 TLS 1.2 或更高版本到 SSL，且所有情况下都禁用了 SSL，除非您需要与过时的浏览器或库兼容。
2.1.1. 公钥基础架构
公钥基础架构(PKI)是一种框架，用于提供加密算法、密码模式以及用于保护数据和身份验证的协议。它由一组系统和流程组成，以确保在验证方身份时可以加密流量。此处描述的 PKI 配置集是 PKIX 工作组开发的互联网工程任务 Force (IETF)公钥基础架构(PKIX)配置集。PKI 的核心组件有： 数字证书 - 签名的公钥证书是具有可验证实体数据的数据结构、其公钥以及一些其他属性。这些证书由证书颁发机构(CA)发布。当证书由受信任的 CA 签名时，验证后，与该实体关联的公钥可以保证与 said实体相关联。定义这些证书的最常见标准是 X.509 标准。RFC5280 中详细描述了当前标准的 X.509 v3，并由 RFC6818 更新。证书由 CA 发布，作为证明在线实体身份的机制。CA 通过从证书创建消息摘要并使用其私钥加密摘要来对证书进行数字签名。 结束实体 - 证书主体的用户、进程或系统。最终实体将证书请求发送到注册机构(RA)以供审批。若获得批准，RA 将请求转发到认证认证机构(CA)。认证认证机构验证请求以及信息是否正确，是否生成并签署证书。然后，这个签名证书会被发送到证书存储库。 依赖方 - 接收数字签名证书的端点，该端点可通过引用证书中列出的公钥进行验证。依靠方验证该链的证书，确保 CRL 不存在，并且必须能够验证证书过期日期。 证书颁发机构(CA)- CA 是一个可信实体，由终端方和依赖认证策略的方、管理处理和证书保护。 注册机构(RA)- CA 委派特定管理功能的可选系统，其中包括的功能，例如：在由 CA 发布证书前验证最终实体的功能。 certificate Revocation Lists (CRL)- A Certificate Revocation List (CRL)是已撤销的证书序列号列表。显示这些证书的最终实体不应在 PKI 模型中信任。撤销可能会因为几个原因（如密钥泄露）和 CA 危害而发生。 CRL issuer - CA 将发布证书撤销列表的可选系统。 证书存储库 - 最终实体证书和证书撤销列表的位置被存储并查询 - 有时被称为证书捆绑包。 强烈建议您使用公共密钥基础架构(PKI)安全强化所有服务，包括将 TLS 用于 API 端点。无法加密或单独签名传输或消息来解决所有这些问题。另外，还必须对主机本身进行强化和实施策略、命名空间和其他控件来保护其私有凭证和密钥。然而，关键管理和保护的挑战并不能降低这些控制的必要性，或者降低它们的重要性。
2.1.2. 认证授权
许多组织有自己认证认证机构(CA)、证书策略和用于为内部 OpenStack 用户或服务签发证书的证书管理，许多组织已建立了建立了公共密钥基础架构。公共安全区面临的公共安全区的组织还需要由广泛认可的公共 CA 签名的证书。对于通过管理网络的加密通信，建议不要使用公共 CA。相反，建议大多数部署部署自己的内部 CA。 TLS 的有效使用取决于 DNS 中给定域或子域，这些域可以由通配符使用，或者由公共或内部 CA 使用的一系列特定证书问题。为确保可以有效地验证 TLS 证书，需要通过这些 DNS 记录访问平台服务。 建议 OpenStack 云架构考虑将单独的 PKI 部署用于内部系统和面向服务的客户。这使得云部署器可以保持对 PKI 基础架构的控制，并使请求、签名和部署证书更易于内部系统。高级配置可能会对不同的安全区使用单独的 PKI 部署。这使得 OpenStack 操作员能够维护环境的加密分离，确保颁发的证书被另一个软件识别。 用于在面向互联网的云端点（或客户不应该安装标准操作系统提供证书捆绑包以外的任何接口）上支持 TLS 的证书应使用在操作系统证书捆绑包中安装的证书颁发机构来置备。 有关创建和签名证书方面的管理、策略和技术挑战。这是一个领域，云架构师或操作员可能希望在这里所推荐的指南之外寻求行业领袖和供应商的建议。
2.1.3. 使用 Director 配置加密
默认情况下，overcloud 将未加密的端点用于其服务。这意味着 overcloud 配置需要额外的环境文件来为其公共 API 端点启用 SSL/TLS。 高级 Overcloud 自定义 指南描述了如何配置 SSL/TLS 证书并将其作为 overcloud 创建流程的一部分包括 ：https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/advanced_overcloud_customization/sect-enabling_ssltls_on_the_overcloud
2.1.4. TLS 库
可以将 OpenStack 生态系统中的某些组件、服务和应用程序配置为使用 TLS 库。OpenStack 中的 TLS 和 HTTP 服务通常使用 OpenSSL 实施，该模块经过 FIPS 140-2 验证的模块。但请考虑每个应用程序或服务在它们如何使用 OpenSSL 库时仍可能会带来弱点。
2.1.5. TLS 1.0 弃用
需要 FedRAMP-authorized 系统才能从 TLS 1.0 移出。推荐的级别是 1.2，只有在需要广泛兼容性时才接受 1.1。如需更多信息，请参阅
https://www.fedramp.gov/assets/resources/documents/CSP_TLS_Requirements.pdf
。
对于 Red Hat OpenStack Platform 13 部署，HAProxy 不会接受 TLS 1.0 连接，该连接处理启用了 TLS 的 API 的 TLS 连接。这通过
no-tlsv10
选项实现。对于启用了
InternalTLS
的 HA 部署，controller plane 上的跨节点流量也会加密。这包括 RabbitMQ、MariaDB 和 Redis 等。MariaDB 和 Redis 已被弃用 TLS1.0，RabbitMQ 的弃用应该可从上游向后移植。
2.1.5.1. 检查 TLS 1.0 是否在使用中
您可以使用密码
来确定部署是否显示 TLS 1.0。可从
https://github.com/mozilla/cipherscan
克隆 Cipherscan。本例输出演示了从
horizon
接收的结果：
从非生产系统运行
密码
，因为它可能会在第一次运行时安装其他依赖项。
$ ./cipherscan https://openstack.lab.local .............................. Target: openstack.lab.local:443 prio ciphersuite protocols pfs curves 1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 2 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 3 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,1024bits None 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,1024bits None 5 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 6 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 7 ECDHE-RSA-AES128-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 8 ECDHE-RSA-AES256-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 9 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None 10 DHE-RSA-AES128-SHA TLSv1.2 DH,1024bits None 11 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None 12 DHE-RSA-AES256-SHA TLSv1.2 DH,1024bits None 13 ECDHE-RSA-DES-CBC3-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 14 EDH-RSA-DES-CBC3-SHA TLSv1.2 DH,1024bits None 15 AES128-GCM-SHA256 TLSv1.2 None None 16 AES256-GCM-SHA384 TLSv1.2 None None 17 AES128-SHA256 TLSv1.2 None None 18 AES256-SHA256 TLSv1.2 None None 19 AES128-SHA TLSv1.2 None None 20 AES256-SHA TLSv1.2 None None 21 DES-CBC3-SHA TLSv1.2 None None Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature TLS ticket lifetime hint: None NPN protocols: None OCSP stapling: not supported Cipher ordering: server Curves ordering: server - fallback: no Server supports secure renegotiation Server supported compression methods: NONE TLS Tolerance: yes Intolerance to: SSL 3.254 : absent TLS 1.0 : PRESENT TLS 1.1 : PRESENT TLS 1.2 : absent TLS 1.3 : absent TLS 1.4 : absent
扫描服务器时，Cipherscan 会公告特定 TLS 版本的支持，这是它要协商的最高 TLS 版本。如果目标服务器正确遵循 TLS 协议，它将使用相互支持的最高版本进行响应，这可能低于最初公告的 Cipherscan。如果服务器继续使用该特定版本与客户端建立连接，则它不会考虑那个协议版本。如果没有建立连接（在指定版本或任何较低版本的情况下），则被视为存在该版本的协议。例如：
Intolerance to: SSL 3.254 : absent TLS 1.0 : PRESENT TLS 1.1 : PRESENT TLS 1.2 : absent TLS 1.3 : absent TLS 1.4 : absent
在此输出中，
TLS 1.0
和
TLS 1.1
会被报告为
PRESENT
，这意味着无法建立连接，Cipherscan 无法在这些 TLS 版本的广告支持的同时连接。因此，合理地得出结论，在扫描的服务器上不会启用这些协议（及任何较低）版本。
2.1.6. 加密算法、加密模式和协议
您应该只使用 TLS 1.2。其他版本（如 TLS 1.0 和 1.1）会受到多种攻击，并被许多政府机构和监管行业所禁止。TLS 1.0 应该在您的环境中被禁用。TLS 1.1 可以用于广泛的客户端兼容性，但在启用此协议时要谨慎。只有存在强制兼容性要求并且了解相关风险时，才启用 TLS 版本 1.1。由于多个公共漏洞，不能使用所有版本的 SSL ( TLS 的前身)。