数据安全性和强化指南

本文档为强化 Red Hat Ceph Storage 安全性提供建议和良好的实践信息，重点在于使用 cephadm 进行 Red Hat Ceph Storage 部署。虽然遵循本指南中的说明将有助于增强您的环境的安全性，但我们不保证遵循这些建议的安全性或合规。

红帽 Ceph 存储(RHCS)是一种高度可扩展且可靠的对象存储解决方案，它通常与 OpenStack 等云计算解决方案进行部署，如单机存储服务或使用 iSCSI 等接口作为网络附加存储。

所有 RHCS 部署均由一个存储集群组成，通常被称为 Ceph 存储集群或 RADOS（可靠的分布式对象存储），它们由三种类型的守护进程组成：

所有 RHCS 部署都会在 Ceph 存储集群或 RADOS（Reliable Autonomous Distributed Object Store）中存储最终用户数据。通常，用户不直接与 Ceph Storage 集群交互，而是与 Ceph 客户端交互。

主要 Ceph Storage 集群客户端有三个：

其他客户端包括 librados，开发人员可以创建自定义应用与 Ceph 存储集群交互，以及命令行界面客户端，以供管理使用。

Red Hat Ceph Storage 安全性的一个重要方面是交付具有安全内置前期且红帽支持随时间的解决方案。红帽使用 Red Hat Ceph Storage 采取的具体步骤包括：

此外，红帽还维护了一个专门的安全团队，针对我们的产品分析威胁和漏洞，并通过客户门户网站提供相关建议和更新。这个团队决定哪些问题很重要，而不是与大多数理论问题相关的问题。红帽产品安全团队在维护了专业技术方面，并对与订阅产品关联的上游社区做出了大量贡献。红帽安全公告 （红帽安全公告）的一个主要部分提供了影响红帽解决方案的安全缺陷通知 - 通常会在漏洞首次发布之日提供相关的补丁程序。

威胁者是一个抽象的、用于指代您可能需要防御的一类行为的方式。能够使用更加强大的安全控制，这是成功攻击缓解和防止所需的安全控制。安全性是根据要求进行的平衡便利、防御和成本方面的问题。在某些情况下，可能无法确保 Red Hat Ceph Storage 部署免受此处描述的所有威胁行为。在部署 Red Hat Ceph Storage 时，您必须决定部署和使用余下的平衡。

作为风险评估的一部分，您还必须考虑您存储和任何可访问资源的数据类型，因为这将影响某些参与者。然而，即使您的数据对威胁威胁者没有吸引力，它们也可能很吸引于您的计算资源。

以下实践可帮助缓解上述发现的一些风险：

安全区由用户在系统中共享共同信任要求的用户、应用程序、服务器或网络组成。通常，它们共享相同的身份验证和授权要求和用户。虽然您可以进一步重新定义这些区域定义，但本指南指的是四个不同的安全区，其中 3 个形成部署安全强化的 Red Hat Ceph Storage 集群所需的最小级别。这些安全区被列为从至少被信任到最受信任：

这些安全区可以单独映射，或者合并以代表给定 RHCS 部署中的大多数可能信任的区域。安全区应根据您的特定 RHCS 部署拓扑进行映射。区域及其信任要求会因 Red Hat Ceph Storage 在独立容量中运行，或为公共、私有或混合云提供。

有关这些安全区的可视化表示，请参阅 安全优化架构。

必须仔细配置跨多个安全区（具有不同信任级别或身份验证要求）的组件。这些连接通常是网络架构的弱点，并且应始终配置为满足所连接任何区域的最高信任级别。在很多情况下，连接的区的安全性控制应该是主要问题，因为攻击的可能性较高。区域满足对于攻击者向部署中更敏感的部分迁移或目标的攻击者提供了机会。

在某些情况下，Red Hat Ceph Storage 管理员可能需要考虑在比集成点所在的任何区域以外的标准安全集成点。例如，Ceph Cluster Security Zone 可以轻松地与其他安全区隔离，因为没有理由将它连接到其他安全区。相反，Storage Access Security Zone 必须提供对 Ceph 监控节点上的 6789 端口的访问，并在 Ceph OSD 节点上提供端口 6800-7300。但是，端口 3000 应该专用于 Storage Access Security 区域，因为它提供了对 Ceph 管理员公开的 Ceph Grafana 监控信息的访问。Ceph 客户端安全区中的 Ceph 对象网关需要访问 Ceph 集群安全性区的监控器（端口 6789）和 OSD（端口 6800-7300），并且可能会将其 S3 和 Swift API 公开给公共安全区，如通过 HTTP 端口 80 或 HTTPS 端口 443 ；但是，它可能需要限制访问 admin API 的访问。

因为 Red Hat Ceph Storage 的设计，分离安全区比较困难。由于核心服务通常至少跨越两个区域，因此在将安全控制应用到它们时，必须考虑特殊考虑。

Red Hat Ceph Storage 集群的守护进程通常在防火墙后被隔离的节点上运行，这使其比较简单来保护 RHCS 集群。

与之相反，Red Hat Ceph Storage 客户端（如 Ceph 块设备(rbd)、Ceph Filesystem(cephfs)和 Ceph 对象网关(rgw)访问 RHCS 存储集群，但将其服务公开给其他云计算平台。

Red Hat Ceph Storage 集群中的所有节点都使用 SSH 作为部署集群的一部分。这意味着每个节点：

Ceph 对象网关可以和 HAProxy 和 keepalived 一起部署，以实现负载平衡和故障转移。对象网关 Red Hat Ceph Storage 版本 2 和 3 使用 Civetweb。Civetweb 的早期版本不支持 SSL 及更新的版本，但有一些性能限制。

Red Hat Ceph Storage 版本 5 使用 Beast。您可以将 Beast 前端 web 服务器配置为使用 OpenSSL 库来提供传输层安全性(TLS)。

当使用 HAProxy 和 keepalived 终止 SSL 连接时，HAProxy 和 keepalived 组件使用加密密钥。

当使用 HAProxy 和 keepalived 终止 SSL 时，负载均衡器和 Ceph 对象网关之间的连接不会加密。

详情请参阅 为 Beast 和 HAProxy 和 keepalived 配置 SSL。

Ceph 的 on-wire 协议 msgr2 的第二个版本具有以下功能：

Ceph 守护进程绑定到多个端口，允许旧旧 v1- 兼容新的 v2 兼容 Ceph 客户端，以连接同一存储集群。Ceph 客户端或其他 Ceph 守护进程连接到 Ceph Monitor 守护进程将先尝试使用 v2 协议（如果可能），但若不可能，则使用旧的 v1 协议。默认情况下，启用 messenger 协议 v1 和 v2。新的 v2 端口为 3300，旧的 v1 端口默认为 6789。

messenger v2 协议有两个配置选项，用于控制是否使用 v1 还是 v2 协议：

同样，两个选项根据使用的 IPv4 和 IPv6 地址进行控制：

msgr2 协议支持两种连接模式：

默认模式是 crc。

从 Red Hat Ceph Storage 5 及之后的版本开始，默认启用通过网络的所有 Ceph 流量加密，并引入 messenger 版本 2 协议。mesenger v2 的安全模式设置加密 Ceph 守护进程和 Ceph 客户端之间的通信，从而为您提供端到端加密。

您可以使用 ceph config dump 命令 ( netstat -Ip | grep ceph-osd 命令) 检查 messenger v2 协议的加密，或者在 v2 端口上验证 Ceph 守护进程。

messenger v2 协议支持压缩功能。默认情况下不启用压缩。

建议不要压缩和加密相同的消息，因为对等点之间的消息级别会减少。如果启用了加密，将忽略启用压缩的请求，直到配置选项 ms_osd_compress_mode 设为 true。

它支持两种压缩模式：

若要确保启用消息的压缩，请运行 debug_ms 命令并检查连接的一些调试条目。另外，您可以运行 ceph config get 命令，获取网络信息的不同配置选项的详细信息。

Red Hat Ceph Storage 在一些情况下支持对静止数据（data at rest）进行加密：

Ceph 使用 LUKS v1 而不是 LUKS v2，因为 LUKS v1 在 Linux 发行版之间拥有广泛的支持。

在创建 OSD 时，LVM 将生成一个 secret 密钥，并通过 stdin 在 JSON 有效负载中安全地将密钥传递给 Ceph Monitor。加密密钥的属性名称为 dmcrypt_key。

默认情况下，Ceph 不会加密 Ceph OSD 中存储的数据。系统管理员必须启用 dmcrypt 来加密 Ceph OSD 中存储的数据。使用 Ceph 编排器服务规格文件将 Ceph OSD 添加到存储集群时，在 文件中设置以下选项以加密 Ceph OSD：

...
encrypted: true
...

...
encrypted: true
...

Ceph 集群中的 Ceph 和 Ceph 对象网关守护进程具有 secret 密钥。此密钥用于连接集群并进行身份验证。您可以使用密钥轮转功能，在活跃的 Ceph 集群中更新活跃的安全密钥，以最少的服务中断。

关键轮转有助于确保满足当前的行业和安全合规性要求。

为了识别用户和防止中间人攻击，Ceph 提供其 cephx 身份验证系统来验证用户和守护进程。有关 cephx 的更多详细信息，请参阅 Ceph 用户管理。

cephx 使用共享密钥来进行身份验证，这意味着客户端和服务器均有客户端的机密密钥的副本。身份验证协议使得双方能够为每个方证明其各自具有密钥副本，而无需实际发现。这提供了 mutual 身份验证，这意味着集群是确保用户具有 secret 密钥，用户则确保集群具有 secret 密钥的副本。

用户是个人或系统参与者，如使用 Ceph 客户端与红帽 Ceph Storage 集群守护进程交互的应用程序。

Ceph 使用默认启用的身份验证和授权运行。Ceph 客户端可以指定用户名和包含指定用户密钥的密钥环，通常是使用命令行。如果未提供用户和密钥环作为参数，Ceph 将使用 client.admin 管理用户作为默认值。如果未指定密钥环，Ceph 将使用 Ceph 配置中的 keyring 设置查找密钥环。

有关配置 Red Hat Ceph Storage 集群以使用身份验证的详情，请参阅 Red Hat Ceph Storage 8 的 配置指南。更具体地说，请参阅 Ceph 身份验证配置。

Ceph 对象网关提供 RESTful 应用程序编程接口(API)服务，提供自己的用户管理，以进行身份验证并授权用户访问包含用户数据的 S3 和 Swift API。身份验证包括：

Ceph 对象网关在 Ceph 存储集群池中存储所有用户身份验证信息。更多信息可以存储关于用户的信息，包括名称、电子邮件地址、配额和使用。

如需了解更多详细信息，请参阅 用户管理和创建用户 。

红帽 Ceph 存储支持使用轻量级目录访问协议(LDAP)服务器来验证 Ceph 对象网关用户。当配置为使用 LDAP 或 Active Directory(AD)时，Ceph Object Gateway defers 到 LDAP 服务器，以验证 Ceph 对象网关的用户。

Ceph 对象网关控制是否使用 LDAP。但是，配置完成后，它是负责验证用户的 LDAP 服务器。

为了保护 Ceph 对象网关和 LDAP 服务器之间的通信，红帽建议使用 LDAP 安全或 LDAPS 部署配置。

红帽 Ceph 存储支持使用 OpenStack Keystone 验证 Ceph 对象网关 Swift API 用户。Ceph 对象网关可以接受 Keystone 令牌，对用户进行身份验证并创建对应的 Ceph 对象网关用户。当 Keystone 验证令牌时，Ceph 对象网关会认为用户通过身份验证。

Ceph 对象网关控制是否使用 OpenStack Keystone 进行身份验证。但是，配置完成后，它是负责对用户进行身份验证的 OpenStack Keystone 服务。

配置 Ceph 对象网关以搭配 Keystone 使用时，需要将 Keystone 用于创建请求的 OpenSSL 证书转换为 nss db 格式。

Ceph 管理堆栈使用基于服务的模块化架构构建，该架构依赖于 nginx 和 oauth2-proxy 组件。

Ceph 管理网关(mgmt-gateway)为 Ceph 控制面板和监控提供统一访问、改进的用户体验和高可用性。

OAuth2 代理(oauth2-proxy)服务提供增强的安全性、无缝 SSO 和集中式身份验证管理。

自行启用 mgmt-gateway 服务，为集群提供单进入点、监控和仪表板的高可用性，以及提高安全性。启用服务与 oauth2-proxy 以使用 SSO。

使用 Ceph 管理网关(mgmt-gateway)和 OAuth2 代理(oauth2-proxy)，在配置了单点登录(SSO)时，nginx 会自动通过 oauth2-proxy 将用户定向到配置的身份提供程序(IdP)。然后 IdP 运行身份验证并登录。

此配置提供以下优点：

有关此模块 SSO 解决方案和使用 Ceph 控制面板实施的更多信息，请参阅启用 OAuth2 单点登录。

ceph config get mgr mgr/cephadm/container_image_oauth2_proxy

ceph config get mgr mgr/cephadm/container_image_oauth2_proxy

ceph config set mgr mgr/cephadm/container_image_oauth2_proxy NEW_OAUTH2_PROXY_IMAGE
ceph orch redeploy oauth2_proxy

ceph config set mgr mgr/cephadm/container_image_oauth2_proxy NEW_OAUTH2_PROXY_IMAGE
ceph orch redeploy oauth2_proxy

管理红帽 Ceph 存储集群涉及使用命令行工具。CLI 工具需要管理员密钥才能获得集群的访问权限。默认情况下，Ceph 将管理员密钥存储在 /etc/ceph 目录中。默认文件名是 ceph.client.admin.keyring。采取步骤来保护密钥环，以便只有具有管理特权的用户才能访问密钥环。

Red Hat Ceph Storage 提供两个网络：

所有 Ceph 守护进程和 Ceph 客户端都需要访问公共网络，该网络是存储访问安全区的一部分。相反，仅 OSD 守护进程需要访问集群网络（这是 Ceph 集群安全区的一部分）。

Ceph 配置包含 public_network 和 cluster_network 设置。为了强化目的，使用 CIDR 标记指定 IP 地址和子网掩码。如果集群有多个子网，请指定多个以逗号分隔的 IP 地址和子网掩码条目。

public_network = <public-network/netmask>[,<public-network/netmask>]
cluster_network = <cluster-network/netmask>[,<cluster-network/netmask>]

public_network = <public-network/netmask>[,<public-network/netmask>]
cluster_network = <cluster-network/netmask>[,<cluster-network/netmask>]

详情请参阅 Red Hat Ceph Storage 配置指南中的 Ceph网络配置 部分。

系统管理员在 Red Hat Enterprise Linux 8 服务器上部署红帽 Ceph 存储集群。SELinux 默认是开启的，防火墙会阻止除 SSH 服务端口 22 之外的所有入站流量；但是，您需要确定系统确实是这样配置的，以确定没有打开未验证的端口或没有启用不需要的服务。

在每个服务器节点上，执行以下操作：

每个 Ceph 守护进程使用一个或多个端口与 Red Hat Ceph Storage 集群中的其他守护进程通信。在某些情况下，您可以更改默认端口设置。管理员通常仅更改使用 Ceph 对象网关或 ceph-radosgw 守护进程的默认端口。

Ceph Storage 集群守护进程包括 ceph-mon、ceph-mgr 和 ceph-osd。这些守护进程及其主机组成了 Ceph 集群安全区，该区域应使用自己的子网来强化目的。

Ceph 客户端包括 ceph-radosgw、ceph-mds、ceph-fuse、libcephfs、rbd、librbd 和 librados。这些守护进程及其主机组成存储访问安全区，该区应使用自己的子网来强化目的。

在 Ceph Storage Cluster zone 主机上，请考虑仅启用运行 Ceph 客户端的主机来连接 Ceph Storage Cluster 守护进程。例如：

firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept"

# firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept"

将 <zone-name> 替换为区名称，<ipaddress> 替换为 IP 地址，<netmask> 替换为 CIDR 标记中的子网掩码，将 <port-number> 替换为端口号或范围。使用 --permanent 标志重复该过程，以便更改在重新引导后仍然有效。例如：

firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept" --permanent

# firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept" --permanent

Red Hat Ceph Storage 提供基本的系统监控和报告 ceph-mgr 守护进程插件；即 RESTful API、仪表板和 Prometheus 和 Zabbix 等其他插件。Ceph 使用 collectd 和 socket 收集此信息，以检索设置、配置详细信息和统计信息。

除了默认的系统行为外，系统管理员还可以配置 collectd 以报告安全性问题，例如配置 IP Tables 或 ConnTrack 插件，以分别跟踪开放端口和连接。

系统管理员也可以在运行时检索配置设置。请参阅 在运行时查看 Ceph 配置。

系统安全的一个重要方面是定期审核集群的管理员操作。Red Hat Ceph Storage 在 /var/log/ceph/CLUSTER_FSID/ceph.audit.log 文件中存储管理员操作的历史记录。在 monitor 主机上运行以下命令：

cat /var/log/ceph/6c58dfb8-4342-11ee-a953-fa163e843234/ceph.audit.log

[root@host04 ~]# cat /var/log/ceph/6c58dfb8-4342-11ee-a953-fa163e843234/ceph.audit.log

每个条目都将包含：

以下是 Ceph 审计日志的输出：

2023-09-01T10:20:21.445990+0000 mon.host01 (mon.0) 122301 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "config generate-minimal-conf"}]: dispatch
2023-09-01T10:20:21.446972+0000 mon.host01 (mon.0) 122302 : audit [INF] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "auth get", "entity": "client.admin"}]: dispatch
2023-09-01T10:20:21.453790+0000 mon.host01 (mon.0) 122303 : audit [INF] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea'
2023-09-01T10:20:21.457119+0000 mon.host01 (mon.0) 122304 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "osd tree", "states": ["destroyed"], "format": "json"}]: dispatch
2023-09-01T10:20:30.671816+0000 mon.host01 (mon.0) 122305 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "osd blocklist ls", "format": "json"}]: dispatch

2023-09-01T10:20:21.445990+0000 mon.host01 (mon.0) 122301 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "config generate-minimal-conf"}]: dispatch
2023-09-01T10:20:21.446972+0000 mon.host01 (mon.0) 122302 : audit [INF] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "auth get", "entity": "client.admin"}]: dispatch
2023-09-01T10:20:21.453790+0000 mon.host01 (mon.0) 122303 : audit [INF] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea'
2023-09-01T10:20:21.457119+0000 mon.host01 (mon.0) 122304 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "osd tree", "states": ["destroyed"], "format": "json"}]: dispatch
2023-09-01T10:20:30.671816+0000 mon.host01 (mon.0) 122305 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "osd blocklist ls", "format": "json"}]: dispatch

在 Ceph 等分布式系统中，操作可能在一个实例上开始，并可传播到集群中的其他节点。当操作开始时，日志表示 dispatch。当操作结束时，日志表示 finished。

Ceph Storage Cluster-​ 通常被称为可靠的自主分布式对象存储或 RADOS-​ 存储作为池中的对象。在大多数情况下，这些对象是代表客户端数据的原子单元，如 Ceph 块设备镜像、Ceph 对象网关对象或 Ceph Filesystem 文件。但是，在 librados 基础上构建的自定义应用可以绑定到池，也可以存储数据。

cephx 控制对存储对象数据的池的访问。但是，Ceph Storage Cluster 用户通常是 Ceph 客户端，而不是用户。因此，用户 通常不会 直接在 Ceph Storage Cluster 池中写入、读取或写入对象。

红帽 Ceph 存储的最常见用途是 Ceph 块设备接口，也称为 RADOS 块设备或 RBD，创建虚拟卷、镜像和计算实例，并将它们存储为池中的一系列对象。Ceph 将这些对象分配到 PG，并将它们伪随机放在整个集群的 OSD 中。

根据应用程序使用的 Ceph Block Device 接口（通常为 Red Hat OpenStack Platform），用户可以创建、修改和删除卷和镜像。Ceph 处理各个对象的创建、检索、更新和删除操作。

删除卷和镜像会以无法恢复的方式销毁对应的对象。但是，重新隐藏的数据工件可能会继续驻留在存储介质上，直到被覆盖为止。数据也可能保留在备份存档中。

Ceph 文件系统接口创建虚拟文件系统，并将它们作为池中一系列对象来存储它们。Ceph 将这些对象分配到 PG，并将它们伪随机放在整个集群的 OSD 中。

通常，Ceph 文件系统使用两个池：

根据应用程序使用的 Ceph System 接口（通常为 Red Hat OpenStack Platform），用户可以在 Ceph 文件系统中创建、修改和删除文件。Ceph 处理代表该文件的每个对象的创建、检索、更新和删除操作。

删除文件会以无法恢复的方式销毁对应的对象。但是，重新隐藏的数据工件可能会继续驻留在存储介质上，直到被覆盖为止。数据也可能保留在备份存档中。

从数据安全性和保留角度看，Ceph 对象网关接口与 Ceph 块设备和 Ceph 文件系统接口相比有一些重要的区别。Ceph 对象网关向用户提供服务。Ceph 对象网关可能会存储：