RFC6536 中文翻译 #1
Description
RFC6536 NETCONF访问控制模型
- 完成第一轮翻译
- 重新检查
- PA2 完成
摘要
在使用NETCONF的标准网络配置接口需要结构化的安全的操作环境，该操作环境可以促进用户使用和多设备商的互操作。这就需要一个标准的机制来使用一组对于NETCONF协议操作和内容的预配置的集合来限制NETCONF协议对于特定用户的访问。本文档定义了这样的一个访问控制模型。
1.介绍
NETCONF协议没有提供任何标准机制来限制用户需要授权来访问NETCONF协议的操作类型以及内容。
这就需要一个可以进行互操作管理的访问控制，管理员可以选择指定服务器上的一部分netconf内容来做访问控制.
本文档指出了对于NETCONF[ RFC6241 ]操作类型以及内容层的访问控制机制,本文包括来如下主要内容：
- 访问控制设计的目标
- NETCONF控制访问模型(NACM)
- 对应的YANG数据模型(ietf-netconf-acm.yang)
RFC6241中定义的如下术语会继续使用，并没有进行重新定义：
- client
- datastore
- protocol operation
- server
- session
- user
RFC6020中定义的如下术语会继续使用，并没有重新定义：
- data node
- data definition statement
如下术语会在本文中使用：
access control : NETCONF服务器端提供的安全特性，该特性允许管理员来通过不同的条件来限制netconf协议的操作类型以及数据的访问。
access control model (ACM):一种用于配置和监控访问控功能的概念模型，以便管理员可以执行访问控制策略。
access control rule:一种条件，用于决定某种NETCONF协议操作被允许还是被拒绝。
access operation: 尝试访问概念对象的请求类型，请求类型是如下方式中的一种,”无”, ”读”, ”写”, ”删除”,”更新”,”执行”。
recovery session: 一种特殊的管理会话，该会话被赋予了没有限制的NETCONF访问,并且不被所有的访问控制所限制。netconf服务器上的实现该机制以及如何鉴别会话是否是recovery session是实现相关的，不再本文的讨论范围之内。
write access: 是”create”, “delete”, “update”访问操作的助记符。
2.访问控制的设计目标
本章描述了在第三章设计的NETCONF 访问控制模型的设计目标
2.1访问控制点
NETCONF协议允许在任何时候添加新的协议操作，并且数据模型语言YANG支持该特性。向其他协议一样，设计一种只是面向NETCONF固有协议的，而不是面向可扩展的协议操作是不可能的。因此没有关于任意的协议操作类型假定可以被确认下来，NETCONF协议的服务端组件框在概念上有三个控制点上需要被保护：
这三个服务访问点见图1，描述如下：
协议操作：调用指定的协议操作的授权
数据存储区：读或者写数据节点的授权
通知：接受特性类型通知事件的授权
客户端请求 —>协议操作是否被允许？－－－－－－－》数据节点访问是否被允许
数据存储区或者状态数据访问
事件 －－》是否允许通告？
2.2 简洁
主要的担心是复杂的ACM功能由于太复杂而不能被广泛的部署。我们需要的是能很容易做简单的事和做复杂事情的可能，而不是做任何事情都很难。
访问控制系统的配置应该越简单越好。简单的、通用的任务应该很容易配置，并且需要很少的经验和领域知识需要，复杂的任务可能需要额外的机制，该机制可能需要而外的经验。
一套简单的访问控制规则集合应该能够控制所有的NETCONF协议操作的调用，所有的数据存储区的访问以及所有的通告事件。
控制访问功能应该能够通过一组很小的、熟知的的权限，能够完全控制NETCONF数据存储区访问。
2.3 过程接口
NETCONF协议使用远程调用模型并使用可扩展的协议操作。对任意可能协议操作都要能够进行访问控制。
2.4 数据存储区访问
而无论是标准的还是专有的访问数据存储区的协议操作，在特定的数据存储区的特定的节点以及子树进行访问控制是必要的。
2.5 用户和群组
对单个用户或者经配置过的用户群组进行访问控制规则都是必要的。
为了更好的支持root账号以及其他的低权限的用户账号， ACM需要支持管理员群组概念。这些群组需要经过管理员进行配置。
有必要将用户和群组的映射授权给例如radius服务器那样的中心服务器。例如通过NETCONF传输层进行鉴权，通过RADIUS来同时进行鉴权和服务授权，下层NETCONF传输需要将该登陆用户以及所在群组信息上报给（RADIUS）服务器上。同时管理员能够禁止ACM中的某些群组。
2.6 维护
同时也可以提供禁止全部或者部分访问控制功能，而不用删除任何的访问控制规则。
2.7 配置能力
合适的配置和监控机制能够容易地允许管理员管理ACM行为的方方面面。一个标准ACM数据模型(data model)能够被操作操作。
对于特定配置datastore的子树的特定操作的访问控制功能是需要支持的。
2.8 标示安全敏感内容
在部署中，数据模型中一个最重要的方面和最大的考虑是标示RFC中的安全敏感区，不仅仅是模型对应的数据和通知，也包括NETCONF协议操作方面。
对于安全敏感对象的标记和记录到RFC的’Security Consideration’段落是必要的。这样做很好，但是还是不够好，这里就是原因：
- 文档化的方法使得管理员不得不研究RFC然后才能确定新的数据模型是否引入可能的安全风险
- 如果安全风险被识别出来，然后管理员需要研究更多的RFC文档然后才能清楚如何降低安全风险。
- 每一个server的ACM必须被配置以便于降低安全风险。例如，需要特权来访问对’Security Consideration’区域的指定的数据进行读写访问。
- 如果ACM没有被预配置，那么在新的模型被加载后，它的访问控制规则被配置前，就有这么久存在一个脆弱的时间窗口。
管理员经常需要禁止安全内容的缺省访问控制权限，那么疏忽和恶意改变就不会发生在server上，这就允许缺省规则需要更加宽容，而不需要增大安全风险。
数据模型的设计者需要能够使用机器可以识别的方式来标识需要保护的NETCONF内容。这就需要客户侧和服务器的相应地工具能够自动的识别数据模型中指定的安全风险 - 拒绝访问敏感数据数据，除非用户被授权能够执行被许可的访问操作
3 NETCONF 访问控制模型 (NACM)
3.1 介绍
本段简要地概述了访问控制模型结构。不仅仅描述了NETCONF协议消息处理模型，并且描述了该处理模型的概念上访问控制需求。
3.1.1 特性
NACM数据模型提供了如下特性：
- 对于RPC、数据节点、通知消息的独立的控制功能
- 可以用于配制的易用的访问规则的数据模型
- 支持一种概念上的紧急恢复session，但是如何配置该功能超出了本文的范畴。紧急恢复session会绕过所有的访问控制规则，以便于能够初始化或者修复NACM配置。
- 简单的、熟知的datastore 权限
- 支持YANG安全标签(例如: nacm:default-deny-wite语句) 允许缺省安全模式能够自动的排除安全敏感数据。
- 对于读、写、执行权限的各自独立的缺省访问模式
- 访问控制规则可以应用到可以配置的群组的用户中。
- 访问控制执行过程能够被禁用，而不需要删除访问控制规则，以便于能够调试操作上的问题。
- 简单的易于配置的访问控制规则
- 客户侧能够访问被拒绝的协议操作的统计计数以及被拒绝的datastore写请求的统计计数
- 简单的未受限制的YANG实例标识符可以用于配置访问控制规则的指定数据节点路径
3.1.2 外部依赖
NETCONF协议 [RFC6241]用于该文档中的所有管理操作使用。
YANG模型 [RFC6020] 用于定义本文档中的NETCONF数据模型。
3.1.3 消息处理模型
下面的流程图描述了概念上消息处理流图，包括所有的NETONF消息处理的访问控制点
+-------------------------+
| session |
| (username) |
+-------------------------+
| ^
V |
+--------------+ +---------------+
| message | | message |
| dispatcher | | generator |
+--------------+ +---------------+
| ^ ^
V | |
+===========+ +-------------+ +----------------+
| <rpc> |---> | <rpc-reply> | | <notification> |
| acc. ctl | | generator | | generator |
+===========+ +-------------+ +----------------+
| ^ ^ ^
V +------+ | |
+-----------+ | +=============+ +================+
| <rpc> | | | read | | <notification> |
| processor |-+ | data node | | access ctl |
| | | acc. ctl | | |
+-----------+ +=============+ +================+
| | ^ ^
V +----------------+ | |
+===========+ | | |
| write | | | |
| data node | | | |
| acc. ctl | -----------+ | | |
+===========+ | | | |
| | | | |
V V V | |
+---------------+ +-----------------+
| configuration | ---> | server |
| datastore | | instrumentation |
| | <--- | |
+---------------+ +-----------------+
Figure 2
上述图例简要的描述了访问控制功能被开启后， 收到的rpc消息的处理步骤：
- 除非这个session被认为是recovery session，那么活跃session的访问控制都是独立地作用在所有的该server接受到的所有rpc消息(除了close-message消息)。
- 如果该登陆用户被授权能够执行执行某个协议操作，那么该处理过程将继续执行，否则，该协议操作请求将被拒绝，并返回’access-denied’错误。
- 如果配置数据库或者概念上的状态信息数据被协议操作访问，那么该server将检查该user是否被授权能够访问该datastore的数据节点。
当访问控制功能被开启后，接下来概念上的处理步骤是执行生成通知消息：
- 基础服务为了某个特定的订阅生成对应的通知消息。
- 通知访问控制执行单元检查通知消息类型，然后检查是否特定的用户没有被授权来读取该消息，如果没有，那么为该订阅者的通知消息将被丢弃。
3.2 访问Datastore
同样的访问控制规则也用于所有的datastore，比如candidate datastore或者running datastore.
只有标准的NETCONF datastores (candidate, running, startup) 能够被NACM控制。本地或者远程文件 或者是通过url参数来访问的datastore不被NACM控制。
3.2.1 访问权限
仅有小集合的硬连接datastore访问权限能够所有可能的NETCONF协议操作，包括厂商扩展的操作集合。
“CRUDX”模型能够支持所有的NETCONF协议操作：
- Create: 允许客户侧添加新的数据节点的实例到datastore中
- Read: 允许客户侧从datastore中读取数据节点实例或者收到通知消息
- Update: 允许客户能够更新datastore中一个数据节点的实例
- Delete: 允许客户能够从datastore中删除一个数据节点实例
- eXec: 允许客户侧能够执行协议操作
3.2.2 get和get-config操作
客户侧没有read权限访问的数据节点要显示的在rpc-reply中忽略掉。这样做是为了允许get 和get-config 消息中的NETCONF filter功能正常，而不是产生’access-denied’错误，是因为过滤条件可能包含对某些数据节点的未授权的读操作。
3.2.3 edit-config操作
NACM访问权限虽然和edit-config操作的属性类似，但是他们并不直接耦合，而是一个NACM访问操作对所有的协议操作起作用，这样的访问操作
会导致一个对特定datastore的操作。本章描述了访问控制权限如何应用到被edit-config支持的访问操作。
如果对特定的数据节点起作用的访问操作是none (例如,default-operation是none)，那么不对该节点进行访问控制操作。这样的行为是在访问大型数据节点中的子树访问的时候是需要的。例如，一个用户可能被授权创建一个新的"/interfaces/interface" list节点，但是没有被授权创建和删除它的父节点"/interfaces"，如果"/interfaces" container已经存在于目标datastore中，那么对于节点"/interface" 节点的访问控制设定为none, 如果一个"/interfaces/interface" list节点被编辑。
如果一个协议操作会导致创建datastore中的一个数据节点，而该用户并没有对与该节点的创建权限，那么该协议操作被拒绝，并携带"access-denied"错误码。
如果一个协议操作会导致删除datastore中的一个数据节点，而该用户并没有对该节点的删除权限，那么该协议操作将被拒绝，并携带"access-denied"错误码。
如果一个协议操作会导致修改datastore中的一个数据节点，而该用户并没有对该节点的修改权限，那么该协议操作将被拒绝，并携带"access-denied"错误码。
如果一个edit-config的‘merge’或‘replace’操作可能包括已经存在于datastore中但是不被更改的部分。例如，一个container或者list节点可能仅仅是为了表示存在，但是不会真正的改变响应的datastore节点。这些不被改变的数据节点将被server侧忽略掉，并且不会进行授权操作。
被限制访问的datastore节点信息绝不能暴露在reply的rpc-error中。
3.2.4 copy-config操作
copy-config协议操作的访问控制需要被考虑因为管理员可能替换指定的整个datastore。
如果copy-config协议操作的源是running datastore，并且目标datastore是startup datastore，那么管理员仅需要有执行copy-configuration的权限，除此之外：
- 如果copy-config的源是一个datastore，那么在copy-config的时候，在源datastore中那些没有权限（这里说的应该是读权限）的数据节点将会忽略掉。
- 如果copy-config的目标是一个datastore，用户需要访问这些修改的节点，明确来说：
- 如果该协议操作将会引发一个datastore的创建操作，而用户并没有该数据节点创建权限，那么该协议操作被拒绝，并以"access-denied"错误返回。
- 如果该协议操作将会引发一个datastore的删除操作，而用户并没有该数据节点删除权限，那么该协议操作被拒绝，并以"access-denied"错误返回。
- 如果该协议操作将会引发一个datastore的修改操作，而用户并没有该数据节点修改权限，那么该协议操作被拒绝，并以"access-denied"错误返回。
3.2.5 delete-config操作
缺省情况下对delete-config协议操作的访问将被拒绝。叶子结点exec-default并不适用于该协议操作。访问控制规则必须明确的被配置来允许在非恢复回话中的调用。
3.2.6 commit操作
服务端必须能明确知道running datastore 中确定的变化的数据节点，以及仅需要检查这些节点的create、update、delete权限。
例如，如果一个回话读取整个datastore但是仅仅修改了一个叶子结点，那么该回话仅仅编辑和提交该叶子结点
3.2.7 discard-changes操作
客户侧仅需要获取能够执行discard-changes协议操作的权限。不需要datastore权限。
3.2.8 kill-session操作
kill-session操作并不直接修改datastore。尽管如此，该操作会终止一个正在操作datastore的回话。
默认情况下，kill-session操作的访问是不允许的。叶子结点exec-default并不适用于协议操作。访问控制规则必须明确的被配置来允许在非恢复回话中的调用。
3.3 模型组件
本章定义与访问控制模型与关的概念组件。
3.3.1 用户
一个用户是一个概念上的实体，TA被关联到被授权的访问控制与一个特定的回话。一个用户在服务器侧适用字符串来标识。
在RFC6241的描述中，用户名字符串来自于在会话建立阶段的传输层。如果一个传输层不能鉴权一个用户，那么该会话被终结。
3.3 模型组件
本章定义与访问控制模型与关的概念组件。
3.3.1 用户
一个用户是一个概念上的实体，TA被关联到被授权的访问控制与一个特定的回话。一个用户在服务器侧适用字符串来标识。
在RFC6241的描述中，用户名字符串来自于在会话建立阶段的传输层。如果一个传输层不能鉴权一个用户，那么该会话被终结。
3.3.2 群组
在一个回话中，对指定的NETCONF协议操作的访问被授权时基于群组的，而不是基于用户名的。
群组用名字来标识。所有的群组名字在服务内是唯一的。
群组成员适用用户名来标识。
同一个用户可以在多个不同的群组内。
3.3.3 紧急恢复回话
服务器可以（MAY）支持恢复回话机制，在该机制下，所有的访问控制执行都将被屏蔽。该功能有益于初始访问权限和恢复损坏的访问控制功能。
3.3.4 全局控制功能
有五个全局控制开关，这些控制开关有助于控制访问功能功能的执行。
3.3.4.1 enable-nacm开关
全局enable-nacm 开关可以开启和关闭所有访问控制功能，当该开关被开启后(true)，那么所有的操作请求都将依赖这些访问控制规则来执行，并且仅当该操作请求被允许后才授权。当该全局开关关闭后(false)，所有的访问操作被允许。
3.3.4.2 read-default开关
缺省读开关可以开启和关闭在接收reply中数据和notification中的默认访问权限。当该功能开启后，该开关该如下情况有关， 当没有找到可以明确的拒绝或者允许某一数据节点的读操作或者notification事件类型后的处理。
当该全局开关设置为permit时，没有找到对于read操作或者notification事件的访问控制规则，那么该访问将被允许。
当该全局开关设置为deny时，没有找到对于read操作或者notification事件的访问控制规则，那么该访问将被拒绝。
3.3.4.3 write-default开关
缺省写开关可以开启和关闭在修改配置数据节点默认访问权限。当该功能开启后，该开关该如下情况有关 - 当没有找到可以明确的拒绝对该数据库写操作规则后的处理。
当该全局开关设置为permit时，没有找到对于该数据节点的写操作访问规则，那么该访问将被允许。
当该全局开关设置为deny时，没有找到对于该数据节点的写操作访问规则，那么该访问将被拒绝。
3.3.4.4 exec-default开关
缺省执行开关可以开启和关闭在修改配置数据节点默认访问权限。当该功能开启后，该开关该如下情况有关 - 当没有找到可以明确拒绝或允许特定协议操作的规则
当该全局开关设置为permit时，没有找到对于该特定协议操作访问规则，那么该访问将被允许。
当该全局开关设置为deny时，没有找到对于特定协议操作作访问规则，那么该访问将被拒绝。
3.3.4.5 enable-eternal-groups 开关
当该开关设置为true时，对于该会话的netconf传输层携带的群组信息将与本地群组配置新配合使用，来决定该会话的访问控制权限。
当该开关设置为false时，netconf传输层携带的群组信息将被NACM忽略。
3.3.5 访问控制规则
NACM中有四种类型的访问控制规则：
- module rule (模块规则) : 对于yang模型的访问规则，用YANG模型的名字作为标志。
- protocol operation rule (协议操作规则) : 对于特定的协议操作的访问规则，用YANG模型名称和协议操作的名字来标识。
- data node rule （数据节点规则） ： 对于指定的数据节点的访问规则，用该节点的XPATH来标识。
- notification rule （通知消息规则） ： 对于指定的通知消息的访问控制，用YANG模型名字和notification名字来标识。
3.4 访问控制执行过程
3.4.1 初始操作
当netconf服务器第一次启动的时候，访问控制有可能还没有配置。如果不是这样，那么出了恢复回话外服务器不允许其他任何的回话来执行写操作。
访问控制可以在用户回话的任何的消息请求阶段来执行。访问控制不再服务器启动阶段执行，例如在启动阶段加载配置到running datastore。
3.4.2 回话建立
当回话建立和Hello消息交换完成后，访问控制功能开始介入到后续的服务器和客户侧交互的消息中。
当回话建立和用户被鉴权后，NETCONF传输层将上报用户名和一个可能为空的用户所在的组信息。NETCONF服务器将给予该用户名和组名来执行访问控制规则。
3.4.3 access-denied 错误处理
当访问控制系统拒绝一个对协议操作的请求或者是对特定数据节点访问时，access-denied将被上报给。
服务器侧绝不能在<rpc-error>中携带<error-info>消息给侧户侧。
3.4.4 入RPC消息验证
下面的流程图描述了在NETCONF服务器上，基本的概念上的对NETCONF 消息处理的访问控制处理过程。
NETCONF server
+------------+
| XML |
| message |
| dispatcher |
+------------+
|
|
V
+------------+
| NC-base NS |
| <rpc> |
+------------+
| | |
| | +-------------------------+
| +------------+ |
V V V
+-----------+ +---------------+ +------------+
| Vendor NS | | NC-base NS | | NC-base NS |
| <my-edit> | | <edit-config> | | <unlock> |
+-----------+ +---------------+ +------------+
| |
| |
V V
+----------------------+
| |
| configuration |
| datastore |
+----------------------+
Figure 3
访问控制在消息分发(message dispatcher)就开始被执行。
在服务器验证xml中的节点和确定对应名字空间URI以及被请求的协议操作名称后，服务器开始验证是否该用户被授权可以执行该协议操作。
服务器必须按照以下步骤来授权每一个协议操作：
- 当
enable-nacm叶子被设置为false时，那么该协议操作被允许。 - 当该会话被标识成恢复回话，那么该协议操作被允许。
- 当请求的操作是类型时，该协议操作被允许。
- 检查所有的
group条目来找到那么包含该该会话用户名的群组信息。如果enable-external-groups叶子被设置为true时，那么由传输层上报的用户群组信息也要考虑进去。 - 如果没有找到任何群组信息，那么跳到第10步。
- 处理这些群组对应的所有的
rule-list条目，如果rule-list中的群组信息不匹配第4步中标识出来的群组信息，那么检查下一个rule-list条目。 - 对于所有找到的
rule-list条目，处理所有的rule-list下面的rule，直到一个匹配的条目被找到。当下面所有条件被满足时可以说一个匹配的rule被找到了:
- 当rule的module-name叶子的值是*（星号)或者等于该协议请求操作的YANG模型时。
- 当rule的rule-type为空或者（该类型为protocol-operation且 （rpc名字是*或者是该请求的协议操作名称))。
- 当rule的access-operation设置了exec比特位或者是*（星号)。 - 如果匹配条目被找到后，那么将检查
action域，如果该值为permit那么该协议操作被允许否则将北拒绝。 - 到此为止，没有在rule-list找到任何的匹配条目。
- 如果该请求的协议操作被定义在YANG模型中，并且在server的hello消息的被通告，如果在yang模型中该协议操作携带
nacm:default-deny-all声明，那么该协议操作被拒绝。 - 如果该协议请求是
<kill-session>或者<delete-connfig>，那么该协议操作被拒绝。 - 如果
exec-default叶子结点设置为permit，那么将允许该协议操作，否则拒绝该请求。
如果用户没有被授权执指定的协议操作，那么<rpc-error>消息奖杯发送给客户侧：
- error-tag: access-denied
- error-path: 指定被请求的协议操作。下面的这个例子表示一个被拒绝的<edit-config>操作:
<error-path xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> /nc:rpc/nc:edit-config </error-path>
无论datastore是由于直接访问还是由于协议操作的边界效应，服务器都需要拦截该访问操作，并确保该协议访问操作时被授权的，详见3.4.5。
3.4.5 数据节点访问验证
如果datastore的一个数据节点被访问，那么服务器必须确保该用户被授权对该数据节点进行读取、创建、更新、删除操作。
数据节点授权访问要遵循如下步骤：
- 如果
enable-nacm设置为false，那么该访问被允许。 - 如果该会话是恢复会话，那么该访问被允许。
- 检查所有的
group条目来找到那么包含该该会话用户名的群组信息。如果enable-external-groups叶子被设置为true时，那么由传输层上报的用户群组信息也要考虑进去。 - 如果没有找到任何群组信息，那么跳到第9步。
- 处理这些群组对应的所有的
rule-list条目，如果rule-list中的群组信息不匹配第4步中标识出来的群组信息，那么检查下一个rule-list条目。 - 对于所有找到的
rule-list条目，处理所有的rule-list下面的rule，直到一个匹配的条目被找到。当下面所有条件被满足时可以说一个匹配的rule被找到了:
- 当rule的module-name叶子的值是*（星号)或者等于该数据节点所在的YANG模型时。
- 当rule没有指定rule-type类型或者是（该类型是data-node并且path匹配被请求的数据节点）。
- 对一个读操作时，该rule的access-operation的read比特被置位或者是*时。
- 对一个创建操作时，该rule的access-operation的create比特被置位或者是*时。
- 对一个删除操作时，该rule的access-operation的delete比特被置位或者是*时。
- 对一个更新操作时，该rule的access-operation的update比特被置位或者是*时。 - 如果一个匹配的rule被找到后，那么接下来需要检查
action叶子。如果该值为permit，那么该节点的访问被允许，否则将被拒绝。对于读操作来说，拒绝意味着被请求的数据节点不会出现在reply消息中。 - 至此，没有rule-list中的rule被找到。
- 对于读操作，如果被请求访问的节点被定义在server的hello消息的能力通告中，而该数据被定义为
nacm:default-deny-all，那么该节点不会在reply消息中出现。 - 对于写操作，如果被请求访问的节点被定义在server的hello消息的能力通告中，而该数据被定义为
nacm:default-deny-all，那么该数据节点的访问被拒绝。 - 对于读操作来说，如果
read-default是permit，那么该数据节点会被包括在reply消息中，否则不会被包含在reply消息中。 - 对于写操作来说，如果
write-default是permit，那么允许该数据节点的访问，否则被拒绝。
3.4.6 外发notification的授权
对于notification中下层节点的访问控制规则的配置不在本文的讨论访问之内。如果用户被授权收到notification消息，那么他也被授权收到相关的数据节点。
下图描述了概念上的外发notification的消息处理模型：
NETCONF server
+------------+
| XML |
| message |
| generator |
+------------+
^
|
+----------------+
| <notification> |
| generator |
+----------------+
^
|
+=================+
| <notification> |
| access control |
| <eventType> |
+=================+
^
|
+------------------------+
| server instrumentation |
+------------------------+
| ^
V |
+----------------------+
| configuration |
| datastore |
+----------------------+
Figure 4
对于按照RFC5277种定义的指定的notification的订阅消息的生成按照下面的步骤进行授权：
- 如果
enable-nacm设置为false，那么该访问被允许。 - 如果该会话是恢复会话，那么该访问被允许。
- 如果notification消息的类型是或者是，那么该消息被允许。
- 检查所有的
group条目来找到那么包含该该会话用户名的群组信息。如果enable-external-groups叶子被设置为true时，那么由传输层上报的用户群组信息也要考虑进去。 - 如果没有找到任何群组信息，那么跳到第10步。
- 处理这些群组对应的所有的
rule-list条目，如果rule-list中的群组信息不匹配第4步中标识出来的群组信息，那么检查下一个rule-list条目。 - 对于所有找到的
rule-list条目，处理所有的rule-list下面的rule，直到一个匹配的条目被找到。当下面所有条件被满足时可以说一个匹配的rule被找到了:
- 如果module-name是*或者是该notification消息定义的yang模型名称。
- 该rule没有设置rule-type或者(该值是notification并且notification-name是或者是notification名字)。 - 该rule的access-operation的read比特被置位或者是`。 - 如果匹配的rule被找到，那么
action域将被检查，如果该值是permit，那么该notification被允许，否则丢弃掉该订阅者的该通知消息。 - 否则没有rule-list中的rule被找到。
- 如果请求的notification被定义在YANG模型中，该模型被server中的hello消息中进行通告，当该notification被声明了`nacm-default-deny-all'时，那么对该订阅者的notification将被丢弃掉。
- 如果
read-default设置为permit，那么该notification被允许，否则丢弃掉对该订阅者的通知消息。
3.5 数据模型定义
3.5.1 数据组织
下面的图是展示简要的模型信息以及结构。
+--rw nacm
+--rw enable-nacm? boolean
+--rw read-default? action-type
+--rw write-default? action-type
+--rw exec-default? action-type
+--rw enable-external-groups? boolean
+--ro denied-operations yang:zero-based-counter32
+--ro denied-data-writes yang:zero-based-counter32
+--ro denied-notifications yang:zero-based-counter32
+--rw groups
| +--rw group [name]
| +--rw name group-name-type
| +--rw user-name* user-name-type
+--rw rule-list [name]
+--rw name string
+--rw group* union
+--rw rule [name]
+--rw name string
+--rw module-name? union
+--rw (rule-type)?
| +--:(protocol-operation)
| | +--rw rpc-name? union
| +--:(notification)
| | +--rw notification-name? union
| +--:(data-node)
| +--rw path node-instance-identifier
+--rw access-operations? union
+--rw action action-type
+--rw comment? string
3.5.2 YANG模型
略 详见RFC6536
3.6 IANA考虑
本文在The IETF XML Registry 中注册了一个URI条目。按照RFC3688中的格式，下面的信息被注册:
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
本文在YANG Module Names注册了一个模型。按照RFC6020的格式，下面的信息被注册:
Name: ietf-netconf-acm
Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
Prefix: nacm
reference: RFC 6536
3.7 安全方面的考虑
本文主要讨论了访问控制需求以及在给定会话的限制NETCONF协议的行为的机制。
本段重点讨论管理员在使用NACM配置方面的一些问题。
3.7.1 NACM配置以及配置监控的考虑
系统安全对访问控制系统的配置非常的敏感。一个服务器可以选择不允许任何用户配置部分系统功能，例如能够配置系统资源的组信息以及全局安全级别等。
默认情况下，nacm功能开启后，对所有datastore的read权限是开启的(除非有得数据节点定义了nacm:default-deny-all)，并且对于安全的协议操作的exec权限也是开启的。管理员需要确保nacm被开启并决定默认设置的访问控制参数是否合适。确保下列数据节点被正确的设置了：
/nacm/enable-nacm(默认开启)/nacm/read-default(默认允许)/nacm/write-default(默认拒绝)/nacm/exec-default(默认允许)
管理员需要限制对所有配置节点的写操作的访问。
如果访问控制中的写操作是被允许的，需要很小心的被访问控制执行。例如如果在running datastore中的访问控制规则被直接编辑 （例如:writable-running能力被开启),需要很小心的，以防止意外访问的出现。
管理员需要确保来源于传输层和实现相关的用户鉴定的正确性以及唯一性，该需求在RFC6241的2.2章有详细的描述。
管理员需要关注访问控制模型的YANG的数据结构(/nacm/rule-list以及/nacm/rule-list/rule)是按照用户名进行排序的。这样服务器侧会在该running datastore 配置中的访问控制顺序来评估该访问控制的访问。
注意的是/nacm/groups/数据结构包含服务器侧使用的管理群组信息。这些群组可以进行本地配置或者通过额外的协议来提供，例如RADIUS协议 [RFC2865] [RFC5607]。
管理员需要关注任外部协议的安全属性，其中包括NETCONF传输层，该层决定了该会话的群组信息。例如，如果这个协议没有对中间人工具的保护，那么攻击者可能能够注入群组信息导nacm中，因此该会话的用户将会得到他本不应该得到的权限。对于这个情况，管理员需要禁止使用该群组信息，那么需要将enable-external-groups设置关闭。
管理员需要限制对于以下节点的读操作，这些节点的读去的访问控制被认为是非常敏感的：/nacm/enable-namc/nacm/read-default/nacm/write-default/nacm/exec-default/nacm/enable-external-groups/nacm/groups/nacm/rule-list
3.7.2 一般性的配置问题
当调用非标准协议操作时会存在没有在文档中描述的副作用，这种风险是存在的。管理员需要构建防止该副作用发生的访问控制规则。
可能存在这样一种情况，在一个会话中一些写操作，这些写操作并没有权限来触及特定datastore中的某些敏感的数据，但是仍然可以通过不停的尝试各种操作的组合（创建、更新、删除）后的收到的access-denied错误来检测到这些敏感数据是否存在。这些钓鱼攻击不需要<rpc-error>中的error-path信息来识别这些这些敏感信息的存在还是不存在。
在运行期，设置服务器的NETCONF能力是可能的。那么就存在这样一种风险，新的协议操作，通知消息或者datastore支持的模型添加到设备上，在这种情况下，管理员需要确保对这些新添加的内容的访问控制规则正确性。检测NETCONF能力变化的机制不在本文中描述。
数据模型的定义本身（例如YANG的when语句）有可能帮助未授权的绘画作品来探测敏感信息的模型存在与否，甚至敏感信息的获取。
对于非标准的协议操作甚至是标准的<get> 协议操作可能返回敏感信息的别名或者副本信息。可能就是简单的存在多重的数据模型定义，这些模型定义同时配置同样的下层系统对象上。
数据模型可能包含外部的键值（例如YANG leafref），这些外键的将这些这些数值暴露在不同的数据层级和结构中。管理员需要关注包含leafref定义的敏感信息。需要引起注意的是需要找到指向敏感信息的leafref节点。
对于已经支持了NETCONF服务器功能的下层基础系统层面的访问控制执行过程确保已经超过了本文描述的范围。管理员需要识别每一个协议操作，这些协议操作是系统提供的，管理员需要决定对于他们是否需要访问控制规则。
本文吸收了可选使用的恢复回话机制，该机制在应急情况下能够用于绕开所有的访问控制规则，例如可以绕开服务器端使用的错误配置导致的禁止所有的访问功能。配置和标识这样的恢复回话机制是现实相关的，不再本文描述的范围之内。管理员需要注意任何的有效的恢复会话以及对他们的正确使用。
即使没有对datastore进行写操作，仍然有可能中断整体的配置管理功能，例如通过来锁定datastore。这可以通过下面的方式达成，通过确保所有或者部分配置功能仍然后效当他们在获取时，或者使用“拒绝服务”(DoS)攻击。服务器端无法区分出他们的不同。管理员可能希望限制对下列协议操作实施exec权限：
<lock><unlock><partial-lock><partial-unlock>
3.7.3 建模方面的考虑
设计者需要清楚的识别出敏感信息，在yang模型中的通知消息或者是协议操作。对于这些敏感信息使用 nacm:default-deny-write 或者 nacm:default-deny-all。并且要清楚的描述出他们的安全隐患。
设计者需要对协议操作需要进行合适的描述以及文档化工作，由此对于model的使用者 - 管理员能够清晰的知道什么数据节点被该协议操作影响以及什么信息通过返回给客户端。
数据模型的入参数（action、rpc）不需要定义不同的访问控制规则。需要避免使用通用的协议操作，如果不同的访问控制规则是需要的，应该使用单独的协议操作。
4参考索引
略
附录
略
<完>