9. 安全考虑

本节提供了NETCONF消息层的基本操作和NETCONF协议的基本操作的安全考虑。 NETCONF传输的安全注意事项在传输文档中提供，NETCONF操纵的内容的安全注意事项可以在定义数据模型的文档中找到。

本文档没有指定授权方案，因为这样的方案可能与元数据模型或数据模型相关联。 实施者应该使用NETCONF提供全面的授权方案。

个人用户通过NETCONF服务器授权可能会或可能不会将1:1映射到其他接口。首先，数据模型可能不兼容。其次，可能需要基于安全传输层中可用的机制（例如，SSH，Blocks Extensible Exchange Protocol（BEEP）等）进行授权。

另外，如果这些操作也不能被全局锁定的文件或操作对象所保护，配置操作可能会产生意想不到的后果。例如，如果正在运行的配置未被锁定，则可能从候选配置中提交部分完整的访问列表，这对于候选配置的锁的所有者而言是不知道的，导致设备不安全或不可访问。

配置信息本质上是敏感的。它的传输清晰，没有完整性检查，让设备面临经典的窃听和虚假的数据注入攻击。配置信息通常包含密码，用户名，服务描述和拓扑信息，所有这些都是敏感的。正因为如此，这个协议应该仔细实施，并充分注意到其他管理接口可能会遇到的各种攻击方式。

因此，协议必须最低限度地支持保密和认证选项。预计底层协议（SSH，BEEP等）将根据需要提供机密性和身份验证。还期望NETCONF会话的每一端的身份可以被另一端使用，以便确定任何给定请求的授权。人们也可以很容易地设想一些额外的信息，例如传输和加密方法，以供授权之用。 NETCONF本身不提供重新认证的手段，更不用说认证。所有这些行为都发生在较低层次上。

不同的环境在认证之前和之后都可能允许不同的权限。因此，本文档中未指定授权模型。当一个操作没有正确的授权，一个简单的“访问被拒绝”就足够了。

请注意，授权信息可以以配置信息的形式进行交换，这是保证连接安全的更多理由。

有人说，重要的是要认识到，有些行为比另外其他的行为显然更敏感。例如，启动或运行配置的<copy-config>显然不是正常的配置操作，而<edit-config>是。这样的全局性操作必须禁止个人没有授权执行的信息的改变。例如，如果不允许用户A在接口上配置IP地址，但用户B已经在<candidate>配置中的接口上配置了IP地址，则不得允许用户提交<candidate>配置。

同样，仅仅因为有人说“在特定的地方通过URL功能去写配置”，这并不意味着没有适当的授权，一个元素就可以做到这一点。

<lock>操作将演示NETCONF旨在供具有至少一些管理员信任的系统使用。如本文档中所述，可以锁定主体可能无法访问的配置部分。毕竟，整个配置被锁定。为了缓解这个问题，有两种方法。

• 如果知道违规会话的会话标识符，可以从NETCONF中以编程方式终止另一个NETCONF会话。
• 另一种解锁的方法是在设备的本地用户界面中提供一个功能。

这两种机制的竞争条件可以通过从认证，授权和计帐（AAA）服务器中删除有问题的用户来改善。但是，这种解决方案在所有的部署场景中都没有用处，例如使用SSH公钥/私钥对的情况。