5.7. 规划 PKI 的检查列表
- 问： 将创建多少个安全域，以及将哪些子系统实例放在每个域中？
- 问： 应为每个子系统分配哪些端口？是否需要具有单个 SSL/TLS 端口，或者最好让端口分离以提高安全性？
- 问： 哪些子系统应放在防火墙后面？哪些客户端或其他子系统需要访问这些受防火墙保护的子系统，以及如何授予访问权限？LDAP 数据库是否允许防火墙访问？
- 问： 需要物理保护哪些子系统？将如何授予访问权限，以及谁将被授予访问权限？
- 问： 所有代理和管理员的物理位置是什么？子系统的物理位置是什么？管理员或代理如何及时访问子系统服务？每个地理位置或时区需要有子系统吗？
- 问： 您需要安装多少个子系统？
- 问： 是否需要克隆任何子系统，如果如此，那么可以安全地存储其关键资料的方法？
- 问： 子系统证书和密钥是否存储在证书系统中的内部软件令牌或外部硬件令牌上？
- 问： CA 签名证书的要求是什么？证书系统是否需要控制属性，如有效期？CA 证书如何分发？
- 问： 将发布哪些证书？它们需要具备哪些特征，以及哪些配置文件设置可用于这些特征？需要对证书放置哪些限制？
- 问： 批准证书请求的要求是什么？请求者如何对自己进行身份验证，以及批准请求需要哪种流程？
- 问： 许多外部客户端是否需要验证证书状态？证书管理器中的内部 OCSP 能否处理负载？
- 问： PKI 是否允许替换密钥？它是否需要密钥归档和恢复？
- 问： 组织是否使用智能卡？如果是这样，如果智能卡被误解，则允许临时智能卡，需要密钥存档和恢复？
- 问： 发布证书和 CRL 在哪里？在接收结束时需要进行什么配置才能发布工作？需要发布哪些证书或 CRL？
问：
将创建多少个安全域，以及将哪些子系统实例放在每个域中？
答：
如果子系统具有可信关系，则只能与另一个子系统通信。由于安全域中的子系统相互自动信任关系，因此子系统加入域非常重要。安全域可以有不同的证书发布策略、不同的子系统类型，或者不同的目录服务器数据库。映射每个子系统所属的位置（包括物理机上和相互关系），并相应地将其分配到安全域。
问：
应为每个子系统分配哪些端口？是否需要具有单个 SSL/TLS 端口，或者最好让端口分离以提高安全性？
答：
最安全的解决方案是为每个 SSL/TLS 接口使用单独的端口。但是，实现多个端口的可行性可能取决于您的网络设置、防火墙规则和其他网络状况。
问：
哪些子系统应放在防火墙后面？哪些客户端或其他子系统需要访问这些受防火墙保护的子系统，以及如何授予访问权限？LDAP 数据库是否允许防火墙访问？
答：
安装子系统的位置取决于网络设计。OCSP 子系统特别设计为在防火墙外操作方便用户，而 CA、KRA 和 TPS 在防火墙后面都应安全以提高安全性。
在决定子系统的位置时，务必要规划服务器需要访问 的其他子系统 或服务（包括内部数据库、CA 或外部用户），并查看防火墙、子网和 VPN 配置。
问：
需要物理保护哪些子系统？将如何授予访问权限，以及谁将被授予访问权限？
答：
CA、TKS 和 KRA 所有存储非常敏感的密钥和证书信息。对于某些部署，可能需要限制这些子系统运行的计算机的物理访问。在这种情况下，子系统及其主机机器都必须包含在更大的基础架构清单和安全设计中。
问：
所有代理和管理员的物理位置是什么？子系统的物理位置是什么？管理员或代理如何及时访问子系统服务？每个地理位置或时区需要有子系统吗？
答：
证书系统用户的物理位置可能会影响请求批准和令牌注册等内容，以及因为网络滞后造成的系统性能。在决定要安装的子系统的位置和数量时，应考虑处理证书操作的响应时间的重要性。
问：
您需要安装多少个子系统？
答：
主要考虑是每个子系统的预期负载，然后是第二级的地理位置或部门部门。具有公平负载（如 KRA 或 TKS）的子系统可能只需要整个 PKI 的一个实例。具有高负载(CA)的系统，或者可能受益于本地代理的本地实例（如 TPS）可能需要多个实例。
可以克隆子系统，这意味着它们本质上是集群，作为一个单元运行，这适用于负载平衡和高可用性。克隆特别适用于 CA 和 KRA，其中可能需要通过大量用户访问相同的密钥和证书数据，或者具有可靠的故障转移。
在规划多个子系统实例时，请记住子系统在已建立的安全域中如何适合。安全域在子系统之间创建可信关系，允许它们一起查找可用子系统以响应即时需求。单个 PKI 中可以使用多个安全域，以及多种类型的子系统实例，或者一个安全域可用于所有子系统。
问：
是否需要克隆任何子系统，如果如此，那么可以安全地存储其关键资料的方法？
答：
克隆的子系统可以一起工作，基本上作为一个实例。这对高需求系统、故障转移或负载平衡可能很好，但维护可能变得困难。例如，克隆的 CA 具有它们发布的证书的序列号范围，克隆可能会达到其范围的末尾。
问：
子系统证书和密钥是否存储在证书系统中的内部软件令牌或外部硬件令牌上？
答：
证书系统支持两个硬件安全模块(HSM)：nCipher nShield Connect XC 和 Thales Luna HSM。在安装子系统前，使用硬件令牌可能需要额外的设置和配置，但它也会添加另一个安全层。
问：
CA 签名证书的要求是什么？证书系统是否需要控制属性，如有效期？CA 证书如何分发？
答：
这里的实际问题是，CA 将是一个 root CA，它在发布证书时设置自己的规则，或者将一个从属 CA （您的 PKI 中的另一个 CA 还是外部 CA）设置对其可能发布的证书类型的限制。
证书管理器可以配置为 root CA 或从属 CA。root CA 和从属 CA 之间的区别在于谁为 CA 签名证书签名。root CA 为自己的证书签名。从属 CA 有另一个 CA （内部或外部）为其证书签名。
自签名 root CA 问题并签署自己的 CA 签名证书。这允许 CA 设置自己的配置规则，如有效周期和允许的从属 CA 的数量。
从属 CA 具有其由公共 CA 或其他证书系统 root CA 发布的证书。此 CA 会 从属 到其他 CA 的规则有关其证书设置以及如何使用证书，如它可以发布的证书类型、允许包含在证书中的扩展以及从属 CA 的从属 CA 可以创建。
一个选项是让证书管理器从属到公共 CA。这可能非常严格，因为它引入了公共 CA 放置到从属 CA 可能会发布的证书类型的限制，以及证书链的性质。另一方面，与公共 CA 串联的一个好处是，第三方负责将 root CA 证书提交到 Web 浏览器或其他客户端软件，这对具有管理员无法由浏览器控制的不同公司访问的证书具有主要优势。
其他选项使 CA 从属到证书系统 CA。将证书系统 CA 设置为 root CA 意味着证书系统管理员通过设置控制 CA 签名证书内容的策略来控制所有从属 CA。
最简单的方法是使第一个 CA 安装自签名 root，因此不需要应用到第三方并等待证书发布。请确定您确定有多少个 root CA 以及根和从属 CA 的位置。
问：
将发布哪些证书？它们需要具备哪些特征，以及哪些配置文件设置可用于这些特征？需要对证书放置哪些限制？
答：
与 第 5.4.6 节 “使用和自定义证书配置文件” 中的联系一样，可以自定义配置 CA 发布的每个证书类型的配置集（配置由 CA 发布的证书类型的格式）。这意味着主题 DN、有效周期、SSL/TLS 客户端的类型和其他元素可由管理员为特定目的定义。为安全起见，配置文件应仅提供 PKI 所需的功能。应该禁用任何不必要的配置集。
问：
批准证书请求的要求是什么？请求者如何对自己进行身份验证，以及批准请求需要哪种流程？
答：
请求批准过程直接影响证书的安全性。自动化流程速度更快，但安全性较低，因为请求者的身份仅经过监管地验证。同样，代理批准的注册也更为安全（因为在最安全的场景中，他们可能需要个人验证和支持识别功能），但它们也可能是最耗时的。
首先确定需要保护身份验证过程的安全，然后确定验证身份所需的身份验证(approval)机制。
问：
许多外部客户端是否需要验证证书状态？证书管理器中的内部 OCSP 能否处理负载？
答：
发布 CRL 并验证证书非常重要。确定哪个类型的客户端将检查证书状态（主要是内部客户端？外部客户端会验证用户证书或服务器证书？），并尝试确定将运行多少 OCSP 检查。CA 有一个内部 OCSP，可用于内部检查或不经常检查，但大量 OCSP 检查可能会减慢 CA 性能的速度。对于大量 OCSP 检查，特别是对于大型 CRL，请考虑使用单独的 OCSP Manager 来关闭 CA。
问：
PKI 是否允许替换密钥？它是否需要密钥归档和恢复？
答：
如果丢失的证书或令牌被简单地撤销和替换，则不需要有一个机制来恢复它们。但是，当使用证书签名或加密数据（如电子邮件、文件或硬盘）时，密钥必须始终可用，以便可以恢复数据。在这种情况下，使用 KRA 归档密钥，以便始终访问数据。
问：
组织是否使用智能卡？如果是这样，如果智能卡被误解，则允许临时智能卡，需要密钥存档和恢复？
答：
如果没有使用智能卡，则无需配置 TPS 或 TKS，因为这些子系统仅用于令牌管理。但是，如果使用智能卡，则需要 TPS 和 TKS。如果令牌可以被丢失和替换，那么还需要有一个 KRA 来归档密钥，以便重新生成令牌的证书。
问：
发布证书和 CRL 在哪里？在接收结束时需要进行什么配置才能发布工作？需要发布哪些证书或 CRL？
答：
确定什么客户端需要访问证书或 CRL 信息以及允许该访问的方式。在这里，您的 cna 定义发布策略。
