测试和实施要求初始部署DNSSEC权威

引言与基准架构 为应对互联网域名和地址系统安全增强的迫切需求，该部门拟与其根区管理合作伙伴共同推进在权威根区级别测试和实施DNSSEC，目标是在2009年底前实现带签名的根区。为以安全的方式加速部署，该部门建议首先将部署过程叠加到现有的根区管理流程上，从而最大限度地减少引入新步骤以及相关方职责的变化。1 该部门设想该流程包括：ICANN和IANA职能运营商接收和处理顶级域名DNSSEC公钥信息更新，并公开分发根区公钥；VeriSign作为根区维护者，签署根区文件数据并持有区签名密钥（ZSK）。详细的密钥签名密钥（KSK）和区签名密钥（ZSK）管理计划将由ICANN和VeriSign在征询该部门意见后共同制定。 实现这一目标需要当前根区管理合作伙伴与部门之间的合作与协作，特别是ICANN和VeriSign承诺共同为部门制定详细的DNSSEC设计、测试和实施计划供其审查。部门认为这种安排是一种临时方法，以满足紧迫的需求，并认识到与DNSSEC相关的技术、流程和/或程序方面的进步可能需要在未来进行改变。 通用要求 根区系统需要一个整体安全生命周期，例如ISO 27001中所述，并且任何用于DNSSEC实施的安防策略都应对照现有的安全控制标准进行验证。 本节其余部分重点介绍了在开发任何解决方案时都应考虑的安全要求。ISO 27002:2005（原ISO 17799:2005）和NIST SP 800-53是公认的具体控制措施来源。请注意，提及SP 800-53是作为一种方便指定一组技术安全要求的方式。2 预期本文件引用的系统将满足所有SP 800-53技术安全控制措施。 1 部门目前与ICANN（IANA职能运营商）和VeriSign（根区维护者）签订的协议规定了根区管理流程如下：（1）顶级域名运营商向IANA职能运营商提交变更请求；（2）IANA职能运营商处理该请求；（3）IANA职能运营商向部门（管理员）发送请求以进行验证/授权；（4）管理员向根区维护者发送验证/授权以使其进行变更；（5）根区维护者编辑并生成新的根区文件；（6）根区维护者将新的根区文件分发给13个根服务器运营商。2 特别注意，SP 800-53中的要求的使用并不意味着这些系统受其他《联邦信息安全管理法》（FISMA）流程的约束。 由高影响系统所需。3 在可能的情况下，为提供进一步信息，此处引用了NIST出版物作为来源。这些特殊出版物（SP）和FIPS文件并非旨在作为未来的审计清单，而是作为非约束性的指南和建议，用以建立可行的IT安全策略。ICANN和VeriSign可以根据实际情况和适用性，选择替代可用的类似安全标准。所有NIST文件引用均可在NIST计算机安全研究中心网页上找到（http://www.csrc.nist.gov/）。 安全授权与管理策略 a)4i)in NIST SP 800-37.b)i)每个合作伙伴根区签名过程中应具备安全策略；安全策略应定期审查和更新，视情况而定。生成安全授权策略的补充指南可能可以找到。这些政策应包含应急计划部分，以应对灾难恢复。（人为灾害和自然灾害）应急计划补充指南可参见 SP 800-34。i) 关于事件响应处理补充指南，可参见NIST SP 800-61。c) 这些政策应涵盖事件响应的检测、处理和报告（见下文第4条）。 2) IT 访问控制 每项关键管理职能都必须实施一项IT访问控制政策。 i) 这包括对硬件/软件组件和存储介质的使用，以及执行处理操作的能力。ii)关于访问控制策略的补充指南，可参见NIST SP 800-12。 b)未经身份验证的用户不得在密钥管理中执行任何操作。 c) 若无充分运营需求，系统内任何加密组件（例如HSM）的远程访问均不被允许。5 2009年10月29日 3) 安全培训 所有参与根区域签名流程的人员都应接受充分的IT安全培训。 i) 关于建立安全意识培训计划的补充指南，可参见 NIST SP 800-50。 4) 审计与问责程序 各角色相关的组织应制定、传播并定期审核/更新：(1) 一项正式的、成文的、涵盖目的、范围、角色、职责、管理层承诺、组织实体间协调以及合规性的审计与问责政策；以及 (2) 一套正式的、成文的程序，以促进审计与问责政策的实施和相关审计与问责控制措施的实施。 i) 关于审计和问责政策的补充指南可在 NIST SP 800-12 中找到。ii) 具体的审计事件包括以下内容： b) 对物理和异常网络攻击的事件处理第6条应包括按照部门、ICANN和VeriSign共同商定的时限和格式向该部门的国家级电信和信息管理局（NTIA）报告。 c) 审计程序应包括向美国国家电信和信息管理局（NTIA）进行月度报告。 d) 审计系统应能够根据需要生成报告。e) 这些报告的版本应公开提供。 5) 物理防护要求 应设置物理访问控制，仅允许授权人员访问硬件组件和媒体。 受控网络（例如互联网）。6 非例外事件应按4 c的要求包含在月度报告中。 2009年10月29日 i) 基于令牌的访问补充指南可在 NIST SP 800-73 和 FIPS 201 中找到。ii) 基于令牌的访问生物特征控制补充指南可在 NIST SP 800-76 中找到。 b)所有用户和访客的物理访问都应受到监控、记录和登记。 c) 所有用于存储密钥材料或生成签名的硬件组件均应配备短期备用应急电源连接，以应对现场断电情况。（参见，SP 800-53r3） d) 所有组织都应采取适当的保护措施，以防止设施受到适当的物理损坏。 6) 所有组件 所有商用现成硬件和软件组件都应有既定的维护和更新程序。 组织建立升级政策的相关补充指南可参见 NIST SP 800-40。 b) 所有硬件和软件组件均提供检测和保护免受未经授权的修改/更新/打补丁的手段。 角色特定要求 7) 根区密钥签名密钥（KSK）持有者 根区密钥对持有者（RZ KSK）负责：(1) 生成和保护RZ KSK的私钥部分；(2) 在需要时安全地导出或导入任何公钥部分；(3) 验证根区区域签名密钥（RZ ZSK）的公钥部分的有效性；(4) 签署根区的DNSKEY记录（ZSK/KSK）。 加密要求 i) RZ KSK 密钥对应为 RSA 密钥对，其模数至少为 2048 位。ii) RSA 密钥生成应满足 FIPS 186-3 中规定的要求。特别是，密钥对生成应满足 FIPS 186-3 对指数大小和素性测试的要求。iii) RZ KSK 私钥应生成并存储在通过 FIPS 140-2 认证的 硬件加密模块（HSM）8，整体通过第4级认证。9 2009年10月29日 iv) RZ KSK数字签名应使用SHA-1或SHA-256生成。10 v) 所有涉及KSK私钥组件的加密功能均应在HSM（硬件安全模块）内执行；也就是说，私钥组件仅能在具备适当控制（FIPS 140-2）的情况下导出，用于密钥备份目的。 多方控制 至少需要两人才能激活或访问包含完整RZ KSK私钥签名模块。 i) RZ KSK私钥应进行备份并至少由两人共同保管。备份副本应存储在符合FIPS 140-2标准的HSM上，该HSM需通过整体第4级验证，或应使用m of n门限方案生成，并分发给组织上相互独立的各方。ii) 存储在HSM上的备份副本应存放在不同的物理位置¹¹，其物理和程序控制措施应与运营系统相当。iii) 在门限密钥共享的情况下，各参与方应确保密钥分片得到物理安全保护。iv) 在所有情况下，参与多人共同保管的各方的名称应记录在一份清单上，该清单应在合规审计时可供查验。 c) 根区 KSK 更迭 i) 应执行RZ KSK的计划滚动。12（参见非计划滚动的应急计划。）ii) RZ KSK滚动程序应考虑未来可能需要对算法进行滚动的需求。 d) 应急计划 i) 应为初级物理设施故障（例如火灾或洪水导致主站点无法运行）而制定的恢复程序，应能在48小时内恢复功能。 ii) RZ KSK的紧急倒转程序应设计为在48小时内实现关键倒转和发布。这些程序，据理解 （硬件安全模块）作为缩写。9 注意，FIPS 186-3 和 FIPS 140-2 在 a 和 b 段中被引用作为要求，而不是补充指南。10 一旦技术上可行/广泛可用，预计将使用 SHA-2 系列。11 备份位置应在美国境内。12 部门设想 RZ KSK 的计划轮换时间表将由 ICANN 和 VeriSign 联合制定和提出，基于受影响各方（例如根服务器运营商、大规模解析器运营商等）的协商和意见。注意，后续测试计划可能指定更频繁或更少频繁的 RZ KSK 轮换，以确保充分的测试。 2009年10月29日 仅处理DNSSEC密钥提供问题，应能适应以下情况：(1)当前的RZ KSK已被泄露；(2)当前的RZ KSK不可用，但据信未被泄露。 e) 生成/支持 RZ ZSK 密钥滚动记录 RZ KSK持有者应验证RZ ZSK公钥材料（1）的来源和完整性 a）机制应支持拥有权证明并验证参数（即RSA指数） b）根区的DNSKEY记录上的签名应使用SHA-1或SHA-256生成。13 f) 审计生成与审查程序 i) 指定的审计人员不得参与对 RZ ZSK 或 RZ KSK 的多人控制。ii) 审计日志应至少每月异地备份。 8) RZ KSK 公钥分发 RZ KSK公钥应以安全的方式分发，以防止替换攻击。 b) 每个用于分发RZ KSK公钥的机制都应当 i) 建立对 RZ KSK 私有密钥持有权的证明（用于公钥分发）；或 ii) 建立对先前RZ KSK 私有密钥持有权的证明（用于根区密钥轮换）。 9) RZ区签名密钥持有者 (RZ ZSK) 根区 ZSK 持有者（RZ ZSK）负责：(1) 生成和保护 RZ ZSK 的私钥组件；(2) 在需要时安全地导出或导入任何公钥组件；(3) 根据 DNSSEC 规范生成和签名区域文件数据。 加密要求 RZ ZSK密钥对应为RSA密钥对，其模数至少为1024。 13.预计一旦在技术上可行/普及，将开始使用SHA-2系列。 比特。14 ii) RSA密钥生成应满足FIPS 186-3中规定的要求。15 特别地，密钥对生成应满足FIPS 186-3对指数大小和素性测试的要求。iii) RZ ZSK数字签名应使用SHA-1或SHA-256生成。iv) RZ ZSK私钥应生成并存储在符合FIPS 140-2标准的HSM上。至少，HSM应通过整体第4级验证。v) 所有涉及RZ ZSK私钥组件的加密操作应在HSM内执行；也就是说，私钥组件除密钥备份目的外，不得从HSM导出。 多方控制 RZ ZSK的激活至少需要两人控制。此要求可通过物理控制与技术控制的组合来满足。 ii) 若RZ ZSK私钥已备份，则应至少采用双人控制的方式备份和存储。备份副本应存储在通过FIPS 140-2认证的HSM中，该HSM整体通过了第4级认证。16 17 （1）备份副本应既保存在现场，也保存在异地。，以及身体上的与操作系统相匹配的程序控制。(2) 参与多人控制各方的名称应予以保留列入清单，并在合规审计时可供查验。 c) 应急计划 应设计从包含RZ ZSK的操作型HSM故障中恢复的流程，以便在2小时内重新建立对该区域的签名能力。 ii) RZ ZSK的紧急接管程序应设计为在部门、VeriSign和ICANN共同商定的、技术可行的时限内实现关键接管。这些程序应能够涵盖以下场景： 当前RZ ZSK已被攻破； compromised.(2) 目前的RZ ZSK不可用（例如：已损毁），但据信并非 d) 根区 ZSK 轮换 RZ ZSK应至少每六个月滚动一次。 14 注意，这些要求与 NIST SP 800-78 中为认证密钥所阐述的要求相对应。由于 DNSSEC 签署数据没有前向安全性要求，因此对长期数字签