Internet Engineering Task Force (IETF) A. Bierman
Request for Comments: 6536 YumaWorks
Category: Standards Track M. Bjorklund
ISSN: 2070-1721 Tail-f Systems
March 2012
Network Configuration Protocol (NETCONF) Access Control Model
Abstract
抽象
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model.
ネットワーク構成プロトコル（NETCONF）と共に使用するためのネットワーク構成インターフェイスの標準化は、人間の使いやすさと、マルチベンダーの相互運用性を促進する構造と安全な動作環境を必要とします。利用可能なすべてのNETCONFプロトコル操作とコンテンツの事前構成されたサブセットに特定のユーザのためのNETCONFプロトコルのアクセスを制限するための標準的なメカニズムが必要とされています。この文書では、このようなアクセス制御モデルを定義します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6536.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6536で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Access Control Design Objectives ................................4
2.1. Access Control Points ......................................5
2.2. Simplicity .................................................5
2.3. Procedural Interface .......................................6
2.4. Datastore Access ...........................................6
2.5. Users and Groups ...........................................6
2.6. Maintenance ................................................6
2.7. Configuration Capabilities .................................7
2.8. Identifying Security-Sensitive Content .....................7
3. NETCONF Access Control Model (NACM) .............................8
3.1. Introduction ...............................................8
3.1.1. Features ............................................8
3.1.2. External Dependencies ...............................9
3.1.3. Message Processing Model ............................9
3.2. Datastore Access ..........................................11
3.2.1. Access Rights ......................................11
3.2.2. <get> and <get-config> Operations ..................12
3.2.3. <edit-config> Operation ............................12
3.2.4. <copy-config> Operation ............................13
3.2.5. <delete-config> Operation ..........................14
3.2.6. <commit> Operation .................................14
3.2.7. <discard-changes> Operation ........................14
3.2.8. <kill-session> Operation ...........................14
3.3. Model Components ..........................................15
3.3.1. Users ..............................................15
3.3.2. Groups .............................................15
3.3.3. Emergency Recovery Session .........................15
3.3.4. Global Enforcement Controls ........................15
3.3.4.1. enable-nacm Switch ........................15
3.3.4.2. read-default Switch .......................16
3.3.4.3. write-default Switch ......................16
3.3.4.4. exec-default Switch .......................16
3.3.4.5. enable-external-groups Switch .............17
3.3.5. Access Control Rules ...............................17
3.4. Access Control Enforcement Procedures .....................17
3.4.1. Initial Operation ..................................17
3.4.2. Session Establishment ..............................18
3.4.3. "access-denied" Error Handling .....................18
3.4.4. Incoming RPC Message Validation ....................18
3.4.5. Data Node Access Validation ........................21
3.4.6. Outgoing <notification> Authorization ..............23
3.5. Data Model Definitions ....................................26
3.5.1. Data Organization ..................................26
3.5.2. YANG Module ........................................26
3.6. IANA Considerations .......................................36
3.7. Security Considerations ...................................36
3.7.1. NACM Configuration and Monitoring Considerations ...37
3.7.2. General Configuration Issues .......................38
3.7.3. Data Model Design Considerations ...................40
4. References .....................................................40
4.1. Normative References ......................................40
4.2. Informative References ....................................41
Appendix A. Usage Examples .......................................42
A.1. <groups> Example ..........................................42
A.2. Module Rule Example .......................................43
A.3. Protocol Operation Rule Example ...........................44
A.4. Data Node Rule Example ....................................46
A.5. Notification Rule Example .................................48
The NETCONF protocol does not provide any standard mechanisms to restrict the protocol operations and content that each user is authorized to access.
NETCONFプロトコルはプロトコル動作と、各ユーザがアクセスを許可されているコンテンツを制限する任意の標準的なメカニズムを提供しません。
There is a need for interoperable management of the controlled access to administrator-selected portions of the available NETCONF content within a particular server.
特定のサーバ内で利用可能なNETCONFコンテンツの管理者が選択した部分へのアクセス制御の相互運用可能な管理が必要です。
This document addresses access control mechanisms for the Operations and Content layers of NETCONF, as defined in [RFC6241]. It contains three main sections:
[RFC6241]で定義されるように、このドキュメントは、操作とNETCONFのコンテンツ層のアクセス制御メカニズムに対処します。これは3つの主要なセクションが含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following terms are defined in [RFC6241] and are not redefined here:
以下の用語は、[RFC6241]で定義されており、ここで再定義されていません。
o client
またはクライアント
o datastore o protocol operation
OデータストアOプロトコルの動作
o server
Oサーバ
o session
Oセッション
o user
Oユーザー
The following terms are defined in [RFC6020] and are not redefined here:
以下の用語は、[RFC6020]で定義されており、ここで再定義されていません。
o data node
お だた ので
o data definition statement
Oデータ定義文
The following terms are used throughout this document:
以下の用語は、この文書全体で使用されています。
access control: A security feature provided by the NETCONF server that allows an administrator to restrict access to a subset of all NETCONF protocol operations and data, based on various criteria.
アクセス制御：様々な基準に基づいて、管理者はすべてのNETCONFプロトコル操作とデータのサブセットへのアクセスを制限することを可能にするNETCONFサーバによって提供されるセキュリティ機能。
access control model (ACM): A conceptual model used to configure and monitor the access control procedures desired by the administrator to enforce a particular access control policy.
アクセス制御モデル（ACM）：特定のアクセス制御ポリシーを強制するために管理者が所望のアクセス制御手順を設定し、監視するために使用される概念モデル。
access control rule: The criterion used to determine if a particular NETCONF protocol operation will be permitted or denied.
アクセス制御ルール：特定のNETCONFプロトコルの動作を許可するか拒否するかどうかを決定するために使用される基準。
access operation: How a request attempts to access a conceptual object. One of "none", "read", "create", "delete", "update", or "execute".
アクセス動作：要求は概念的なオブジェクトにアクセスしようとする方法。 「なし」、「実行」、「読む」、「作成」、「削除」、「更新」を、またはの一つ。
recovery session: A special administrative session that is given unlimited NETCONF access and is exempt from all access control enforcement. The mechanism(s) used by a server to control and identify whether or not a session is a recovery session are implementation specific and outside the scope of this document.
リカバリ・セッション：無制限のNETCONFのアクセスを与えられ、すべてのアクセス制御執行を免除される特殊な管理セッション。制御セッションがリカバリ・セッションであるか否かを識別するためにサーバによって使用される機構（単数または複数）は特定し、この文書の範囲外で実装されています。
write access: A shorthand for the "create", "delete", and "update" access operations.
「削除」、「作成」、および「更新」アクセス操作のための速記：書き込みアクセスを。
This section documents the design objectives for the NETCONF Access Control Model presented in Section 3.
このセクションでは、第3節で提示NETCONFアクセス制御モデルの設計目標を文書化します。
NETCONF allows new protocol operations to be added at any time, and the YANG Data Modeling Language supports this feature. It is not possible to design an ACM for NETCONF that only focuses on a static set of protocol operations, like some other protocols. Since few assumptions can be made about an arbitrary protocol operation, the NETCONF architectural server components need to be protected at three conceptual control points.
NETCONFは、新しいプロトコル操作はいつでも追加することができ、かつYANGデータモデリング言語は、この機能をサポートしています。それだけでいくつかの他のプロトコルと同様に、プロトコル動作の静的セットに焦点を当てNETCONFのためのACMを設計することはできません。いくつかの仮定が任意のプロトコルの動作について行うことができるので、NETCONF建築サーバコンポーネントは、三個の概念的な制御ポイントで保護する必要があります。
These access control points, described in Figure 1, are as follows:
次のように、図1で説明したこれらのアクセスコントロールポイントは、次のとおりです。
protocol operation: Permission to invoke specific protocol operations.
プロトコルの動作：特定のプロトコル操作を起動する権限。
datastore: Permission to read and/or alter specific data nodes within any datastore.
データストア：任意のデータストア内の特定のデータノードを読み取り、および/または変更するパーミッション。
notification: Permission to receive specific notification event types.
通知：特定の通知イベント・タイプを受信する権限。
+-------------+ +-------------+
client | protocol | | data node |
request --> | operation | -------------> | access |
| allowed? | datastore | allowed? |
+-------------+ or state +-------------+
data access
+----------------+
| notification |
event --> | allowed? |
+----------------+
Figure 1
図1
There is concern that a complicated ACM will not be widely deployed because it is too hard to use. It needs to be easy to do simple things and possible to do complex things, instead of hard to do everything.
使用するには余りにも困難であるため、複雑なACMが広く展開されないという懸念があります。それはすべてを行う代わりに、ハードの、複雑な物事を行うには、簡単なことを行うのは簡単かつ可能にする必要があります。
Configuration of the access control system needs to be as simple as possible. Simple and common tasks need to be easy to configure and require little expertise or domain-specific knowledge. Complex tasks are possible using additional mechanisms, which may require additional expertise.
アクセス制御システムの構成はできるだけシンプルにする必要があります。シンプルで一般的なタスクを設定すると、ほとんどの専門知識やドメイン固有の知識を必要とすることは容易である必要があります。複雑なタスクには、追加の専門知識を必要とするかもしれない追加メカニズムを、使用可能です。
A single set of access control rules ought to be able to control all types of NETCONF protocol operation invocation, all datastore access, and all notification events.
アクセス制御規則の単一のセットは、NETCONFプロトコル動作の呼び出し、すべてのデータストアへのアクセス、およびすべての通知イベントのすべてのタイプを制御することができるようにするべきです。
Access control ought to be defined with a small and familiar set of permissions, while still allowing full control of NETCONF datastore access.
アクセス制御は、依然としてNETCONFデータストアへのアクセスの完全な制御を可能にしながら、権限の小さなと馴染みのセットで定義されるべきです。
The NETCONF protocol uses a remote procedure call model and an extensible set of protocol operations. Access control for any possible protocol operation is necessary.
NETCONFプロトコルはリモート・プロシージャ・コールモデルおよびプロトコル動作の拡張可能なセットを使用します。任意の可能なプロトコル動作のためのアクセス制御が必要です。
It is necessary to control access to specific nodes and subtrees within the NETCONF datastore, regardless of which protocol operation, standard or proprietary, was used to access the datastore.
標準または独自のプロトコルの動作は、データストアにアクセスするために使用されたにかかわらず、NETCONFデータストア内の特定のノードおよびサブツリーへのアクセスを制御する必要があります。
It is necessary that access control rules for a single user or a configurable group of users can be configured.
単一のユーザーまたはユーザーのグループ設定のためのアクセス制御規則を設定することができることが必要です。
The ACM needs to support the concept of administrative groups, to support the well-established distinction between a root account and other types of less-privileged conceptual user accounts. These groups need to be configurable by the administrator.
ACMは、rootアカウントと少ない特権概念ユーザーアカウントの他のタイプの間で十分に確立区別をサポートするために、管理グループの概念をサポートする必要があります。これらのグループは、管理者が設定する必要があります。
It is necessary that the user-to-group mapping can be delegated to a central server, such as a RADIUS server [RFC2865][RFC5607]. Since authentication is performed by the NETCONF transport layer and RADIUS performs authentication and service authorization at the same time, the underlying NETCONF transport needs to be able to report a set of group names associated with the user to the server. It is necessary that the administrator can disable the usage of these group names within the ACM.
ユーザ対グループマッピングは、RADIUSサーバ[RFC2865]、[RFC5607]のように、中央サーバに委任することができることが必要です。認証がNETCONF輸送層によって実行されるとRADIUSを同時に認証およびサービス認証を行うため、下地NETCONF輸送は、サーバへのユーザに関連付けられたグループ名のセットを報告することができる必要があります。これにより、管理者は、ACM内のこれらのグループ名の使用を無効にすることが必要です。
It ought to be possible to disable part or all of the access control model enforcement procedures without deleting any access control rules.
これは、任意アクセス制御ルールを削除せずに一部またはアクセス制御モデル執行手続きのすべてを無効にすることも可能であるべき。
Suitable configuration and monitoring mechanisms are needed to allow an administrator to easily manage all aspects of the ACM's behavior. A standard data model, suitable for use with the <edit-config> protocol operation, needs to be available for this purpose.
適切な構成および監視メカニズムは、管理者が簡単にACMの行動のすべての側面を管理できるようにするために必要とされています。 <編集設定>プロトコル操作に使用するのに適した標準的なデータ・モデルは、この目的のために利用可能である必要があります。
Access control rules to restrict access operations on specific subtrees within the configuration datastore need to be supported.
コンフィギュレーション・データストア内の特定のサブツリーにアクセス操作を制限するアクセス制御ルールをサポートする必要があります。
One of the most important aspects of the data model documentation, and biggest concerns during deployment, is the identification of security-sensitive content. This applies to protocol operations in NETCONF, not just data and notifications.
データモデルドキュメントの最も重要な側面、および展開中の最大の関心事の一つは、セキュリティに敏感なコンテンツの識別です。これは、プロトコルNETCONFでの操作だけでなく、データと通知に適用されます。
It is mandatory for security-sensitive objects to be documented in the Security Considerations section of an RFC. This is nice, but it is not good enough, for the following reasons:
セキュリティに敏感なオブジェクトは、RFCのセキュリティの考慮事項のセクションに記載されていることが必須です。これはいいですが、それは次のような理由から、十分ではありません。
o This documentation-only approach forces administrators to study the RFC and determine if there are any potential security risks introduced by a new data model.
Oこのドキュメントのみのアプローチ力の管理者は、RFCを研究し、新しいデータモデルによって導入された潜在的なセキュリティリスクがあるかどうかを判断します。
o If any security risks are identified, then the administrator must study some more RFC text and determine how to mitigate the security risk(s).
任意のセキュリティ上のリスクが特定されている場合は、O、その後、管理者がいくつかのより多くのRFCのテキストを勉強し、セキュリティリスク（複数可）を軽減する方法を決定しなければなりません。
o The ACM on each server must be configured to mitigate the security risks, e.g., require privileged access to read or write the specific data identified in the Security Considerations section.
各サーバー上のACMは、セキュリティ上のリスクを軽減するように設定する必要がありO、例えば、Security Considerations部で識別される特定のデータを読み書きする特権アクセスを必要とします。
o If the ACM is not pre-configured, then there will be a time window of vulnerability after the new data model is loaded and before the new access control rules for that data model are configured, enabled, and debugged.
ACMが事前に設定されていない場合は、新しいデータモデルがロードされた後、そのデータモデルのための新しいアクセス制御ルールが設定される前に、有効、およびデバッグO、その後、脆弱性の時間ウィンドウが存在します。
Often, the administrator just wants to disable default access to the secure content, so no inadvertent or malicious changes can be made to the server. This allows the default rules to be more lenient, without significantly increasing the security risk.
多くの場合、管理者は、単に安全なコンテンツへのデフォルトのアクセスを無効にしたいので、何の不注意や悪意のある変更は、サーバーに行うことはできません。これは、デフォルトのルールが大幅にセキュリティ上のリスクを増加させることなく、より厳密に行うことができます。
A data model designer needs to be able to use machine-readable statements to identify NETCONF content, which needs to be protected by default. This will allow client and server tools to automatically identify data-model-specific security risks, by denying access to sensitive data unless the user is explicitly authorized to perform the requested access operation.
データモデルの設計者は、デフォルトで保護する必要があるNETCONFコンテンツを、識別するために、機械読み取り可能なステートメントを使用できるようにする必要があります。これは、クライアントとサーバーのツールが自動的にユーザーが明示的に要求されたアクセス操作を実行するために許可されない限り、機密データへのアクセスを拒否することにより、データ・モデル固有のセキュリティリスクを識別することができます。
This section provides a high-level overview of the access control model structure. It describes the NETCONF protocol message processing model and the conceptual access control requirements within that model.
このセクションでは、アクセス制御モデル構造の高レベルの概要を提供します。これはNETCONFプロトコルメッセージ処理モデルと、そのモデル内の概念的なアクセス制御要件を記述する。
The NACM data model provides the following features:
NACMデータモデルは、以下の機能を提供します。
o Independent control of remote procedure call (RPC), data, and notification access.
リモートプロシージャコール（RPC）、データ、および通知アクセスのO独立制御。
o Simple access control rules configuration data model that is easy to use.
使いやすいシンプルなアクセス制御ルールの設定データモデルを、O。
o The concept of an emergency recovery session is supported, but configuration of the server for this purpose is beyond the scope of this document. An emergency recovery session will bypass all access control enforcement, in order to allow it to initialize or repair the NACM configuration.
緊急リカバリセッションのコンセプトoをサポートされていますが、この目的のために、サーバーの構成は、このドキュメントの範囲を超えています。緊急時のリカバリ・セッションは、それが初期化またはNACM構成を修復することを可能にするために、すべてのアクセス制御の施行をバイパスします。
o A simple and familiar set of datastore permissions is used.
Oデータストア権限を簡単かつ馴染みのセットが使用されます。
o Support for YANG security tagging (e.g., "nacm:default-deny-write" statement) allows default security modes to automatically exclude sensitive data.
Oタグ付けYANGセキュリティのサポート（例えば、「nacm：デフォルト-拒否 - 書き込み」文）は、デフォルトのセキュリティモードが自動的に機密データを除外することができます。
o Separate default access modes for read, write, and execute permissions.
読み取りのために別々のデフォルトのアクセスモードO、書き込み、および実行権限を。
o Access control rules are applied to configurable groups of users.
Oアクセス制御ルールは、ユーザーの設定可能なグループに適用されます。
o The access control enforcement procedures can be disabled during operation, without deleting any access control rules, in order to debug operational problems.
Oアクセス制御執行手続は、操作上の問題をデバッグするために、任意のアクセス制御ルールを削除せずに、運転中に無効にすることができます。
o Access control rules are simple to configure.
Oアクセス制御ルールは設定が簡単です。
o The number of denied protocol operation requests and denied datastore write requests can be monitored by the client.
O拒否されたプロトコルの動作要求と拒否されたデータストアの書き込み要求の数は、クライアントによって監視することができます。
o Simple unconstrained YANG instance identifiers are used to configure access control rules for specific data nodes.
O単純な非拘束YANGインスタンス識別子は、特定のデータノードのアクセス制御規則を設定するために使用されます。
The NETCONF protocol [RFC6241] is used for all management purposes within this document.
NETCONFプロトコル[RFC6241]は、この文書内のすべての管理目的のために使用されます。
The YANG Data Modeling Language [RFC6020] is used to define the NETCONF data models specified in this document.
YANGデータモデリング言語[RFC6020]はこの文書で指定されたNETCONFデータモデルを定義するために使用されます。
The following diagram shows the conceptual message flow model, including the points at which access control is applied during NETCONF message processing.
以下の図は、アクセス制御がNETCONFメッセージ処理中に適用される点を含む概念メッセージ・フロー・モデルを示しています。
+-------------------------+
| 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
図2
The following high-level sequence of conceptual processing steps is executed for each received <rpc> message, if access control enforcement is enabled:
アクセス制御施行が有効になっている場合、それぞれが、<RPC>メッセージを受信するための概念的な処理工程の次の高レベルシーケンスが実行されます。
o For each active session, access control is applied individually to all <rpc> messages (except <close-session>) received by the server, unless the session is identified as a recovery session.
セッションが回復セッションとして識別されていない限り、O、各アクティブなセッションについて、アクセス制御は、サーバによって受信された（<クローズセッション>を除く）すべての<RPC>メッセージに個別に適用されます。
o If the user is authorized to execute the specified protocol operation, then processing continues; otherwise, the request is rejected with an "access-denied" error.
ユーザは、指定されたプロトコル動作を実行することを許可されている場合は、O、処理は継続します。そうでない場合、要求は「アクセス拒否」エラーで拒否されます。
o If the configuration datastore or conceptual state data is accessed by the protocol operation, then the server checks if the client is authorized to access the nodes in the datastore. If the user is authorized to perform the requested access operation on the requested data, then processing continues.
クライアントがデータストア内のノードにアクセスすることを許可されている場合、サーバのチェック、構成データストアまたは概念的な状態データはプロトコル動作によってアクセスされる場合、O。ユーザは、要求されたデータに対して要求されたアクセス動作の実行を許可された場合、処理は継続します。
The following sequence of conceptual processing steps is executed for each generated notification event, if access control enforcement is enabled:
アクセス制御施行が有効になっている場合の概念の処理ステップの次のシーケンスが、各生成された通知イベントに対して実行されます。
o Server instrumentation generates a notification for a particular subscription.
O Serverのインストルメンテーションは、特定のサブスクリプションの通知を生成します。
o The notification access control enforcer checks the notification event type, and if it is one that the user is not authorized to read, then the notification is dropped for that subscription.
O通知アクセス制御エンフォーサは通知イベントタイプをチェックし、それは、ユーザが読み取りを許可されていないものである場合、通知は、そのサブスクリプションのためにドロップされます。
The same access control rules apply to all datastores, for example, the candidate configuration datastore or the running configuration datastore.
同じアクセス制御ルールは、例えば、すべてのデータストアに適用され、候補コンフィギュレーションデータストアまたは実行コンフィギュレーションデータストア。
Only the standard NETCONF datastores (candidate, running, and startup) are controlled by NACM. Local or remote files or datastores accessed via the <url> parameter are not controlled by NACM.
唯一の標準のNETCONFデータストア（候補、ランニング、および起動）NACMによって制御されています。 <URL>パラメータを介してアクセスローカルまたはリモートのファイルやデータストアはNACMによって制御されていません。
A small set of hard-wired datastore access rights is needed to control access to all possible NETCONF protocol operations, including vendor extensions to the standard protocol operation set.
ハードワイヤードデータストアへのアクセス権の小さなセットは、標準のプロトコル動作セットにベンダーの拡張機能を含むすべての可能なNETCONFプロトコル操作へのアクセスを制御するために必要とされます。
The "CRUDX" model can support all NETCONF protocol operations:
「CRUDX」モデルは、すべてのNETCONFプロトコル操作をサポートすることができます。
o Create: allows the client to add a new data node instance to a datastore.
Oを作成します。クライアントがデータストアに新しいデータノードのインスタンスを追加することができます。
o Read: allows the client to read a data node instance from a datastore or receive the notification event type.
Oリード：クライアントは、データストアからデータノードのインスタンスを読んだり、通知イベントのタイプを受け取ることができます。
o Update: allows the client to update an existing data node instance in a datastore.
O更新：クライアントがデータストア内の既存のデータ・ノード・インスタンスを更新することを可能にします。
o Delete: allows the client to delete a data node instance from a datastore.
O削除：クライアントがデータストアからデータノードのインスタンスを削除することができます。
o eXec: allows the client to execute the protocol operation.
O Execは：クライアントは、プロトコルの動作を実行することができます。
Data nodes to which the client does not have read access are silently omitted from the <rpc-reply> message. This is done to allow NETCONF filters for <get> and <get-config> to function properly, instead of causing an "access-denied" error because the filter criteria would otherwise include unauthorized read access to some data nodes. For NETCONF filtering purposes, the selection criteria is applied to the subset of nodes that the user is authorized to read, not the entire datastore.
クライアントが読み取りアクセス権を持っていないデータノードには、静かに、<RPC-返信>メッセージから省略されています。これは、フィルタ基準は、そうでない場合は、いくつかのデータノードへの不正な読み出しアクセスが含まれますので、<GET>と<GET-config>の関数に適切に、代わりに「アクセス拒否」のエラーを発生させるためのNETCONFフィルタを可能にするために行われます。 NETCONFフィルタリングのために、選択基準は、ユーザが、全体ではなく、データストアを読み取ることが許可されているノードのサブセットに適用されます。
The NACM access rights are not directly coupled to the <edit-config> "operation" attribute, although they are similar. Instead, a NACM access right applies to all protocol operations that would result in a particular access operation to the target datastore. This section describes how these access rights apply to the specific access operations supported by the <edit-config> protocol operation.
彼らは似ているものの、NACMのアクセス権は、直接、<編集-config>の「操作」属性に結合されていません。代わりに、NACMアクセス権ターゲットデータストアに特定のアクセス動作につながるすべてのプロトコルの操作に適用されます。このセクションでは、これらのアクセス権は、<編集-config>のプロトコル操作でサポートされている特定のアクセス操作に適用する方法について説明します。
If the effective access operation is "none" (i.e., default-operation="none") for a particular data node, then no access control is applied to that data node. This is required to allow access to a subtree within a larger data structure. For example, a user may be authorized to create a new "/interfaces/interface" list entry but not be authorized to create or delete its parent container ("/interfaces"). If the "/interfaces" container already exists in the target datastore, then the effective operation will be "none" for the "/interfaces" node if an "/interfaces/interface" list entry is edited.
効果的なアクセス動作が特定のデータノードの「なし」（すなわち、デフォルト動作=「なし」）しない場合、その後のアクセス制御は、そのデータノードに適用されません。これは、より大きなデータ構造内のサブツリーへのアクセスを許可するために必要とされます。例えば、ユーザは、新しい「/インターフェース/インターフェース」リストのエントリを作成することを許可することができるが、その親コンテナ（「/インターフェース」）を作成または削除することを許可されません。 「/インターフェース」コンテナは、すでにターゲット・データストアに存在する場合、「/インターフェース/インターフェース」リストエントリを編集する場合、効果的な操作は、「/インタフェース」ノードの「なし」しないであろう。
If the protocol operation would result in the creation of a datastore node and the user does not have "create" access permission for that node, the protocol operation is rejected with an "access-denied" error.
プロトコルの動作は、データストアのノードが作成されるでしょうし、ユーザーが持っていない場合は、そのノードのアクセス許可「を作成する」、プロトコル動作は、「アクセス拒否」エラーで拒否されます。
If the protocol operation would result in the deletion of a datastore node and the user does not have "delete" access permission for that node, the protocol operation is rejected with an "access-denied" error.
プロトコルの動作は、データストアのノードの削除につながる、ユーザーが持っていない場合は、そのノードのアクセス許可を「削除」、プロトコル動作は、「アクセス拒否」エラーで拒否されます。
If the protocol operation would result in the modification of a datastore node and the user does not have "update" access permission for that node, the protocol operation is rejected with an "access-denied" error.
プロトコルの動作は、データストアノードの変更につながる、ユーザーがそのノードの「更新」のアクセス許可を持っていない場合は、プロトコルの動作は、「アクセス拒否」エラーで拒否されます。
A "merge" or "replace" <edit-config> operation may include data nodes that do not alter portions of the existing datastore. For example, a container or list node may be present for naming purposes but does not actually alter the corresponding datastore node. These unaltered data nodes are ignored by the server and do not require any access rights by the client.
「マージ」または<編集-config>の操作は、既存のデータストアの部分を変更しないデータノードを含むことができ、「置き換え」。例えば、コンテナまたはリストのノードが目的を命名するために存在してもよいが、実際に対応するデータストアノードを変更しません。これらの変更されていないデータノードは、サーバーによって無視され、クライアントが任意のアクセス権を必要としません。
A "merge" <edit-config> operation may include data nodes but not include particular child data nodes that are present in the datastore. These missing data nodes within the scope of a "merge" <edit-config> operation are ignored by the server and do not require any access rights by the client.
「マージ」<編集-config>の操作は、データノードを含むが、データストアに存在する特定の子データノードを含まなくてもよいです。 「マージ」<編集-config>の操作の範囲内でこれらの不足しているデータノードは、サーバーによって無視され、クライアントが任意のアクセス権を必要としません。
The contents of specific restricted datastore nodes MUST NOT be exposed in any <rpc-error> elements within the reply.
特定の制限されたデータストアのノードの内容は、応答内の任意の<RPCエラー>要素において露出してはいけません。
Access control for the <copy-config> protocol operation requires special consideration because the administrator may be replacing the entire target datastore.
管理者が全体のターゲットデータストアを交換することができるので、<コピー-config>のプロトコル動作のためのアクセス制御は、特別な配慮が必要です。
If the source of the <copy-config> protocol operation is the running configuration datastore and the target is the startup configuration datastore, the client is only required to have permission to execute the <copy-config> protocol operation.
<コピー-config>のプロトコル動作のソースは実行コンフィギュレーションデータストアで、ターゲットがスタートアップコンフィギュレーションデータストアの場合、クライアントはのみ、<コピー-config>のプロトコル動作を実行する権限を有する必要があります。
Otherwise:
そうでなければ：
o If the source of the <copy-config> operation is a datastore, then data nodes to which the client does not have read access are silently omitted.
<コピー設定>のソースは、操作は、クライアントが読み取りアクセス権を持っていないために、データストア、データ・ノードである場合には、O静かに省略されています。
o If the target of the <copy-config> operation is a datastore, the client needs access to the modified nodes, specifically:
<コピー-config>の操作の対象がデータストアである場合は、O、クライアントは、具体的には、変更されたノードにアクセスする必要があります。
* If the protocol operation would result in the creation of a datastore node and the user does not have "create" access permission for that node, the protocol operation is rejected with an "access-denied" error.
*プロトコルの動作は、データストアのノードが作成されるでしょうし、ユーザーが持っていない場合は、そのノードのためのアクセス許可「を作成する」、プロトコルの動作は、「アクセス拒否」エラーで拒否されます。
* If the protocol operation would result in the deletion of a datastore node and the user does not have "delete" access permission for that node, the protocol operation is rejected with an "access-denied" error.
*プロトコルの動作は、データストアのノードの削除につながる、ユーザーが持っていない場合は、そのノードのアクセス許可を「削除」、プロトコル動作は、「アクセス拒否」エラーで拒否されます。
* If the protocol operation would result in the modification of a datastore node and the user does not have "update" access permission for that node, the protocol operation is rejected with an "access-denied" error.
プロトコルの動作は、データストアノードの変更につながる、ユーザーがそのノードの「更新」のアクセス許可を持っていない場合は*、プロトコル動作は、「アクセス拒否」エラーで拒否されます。
Access to the <delete-config> protocol operation is denied by default. The "exec-default" leaf does not apply to this protocol operation. Access control rules must be explicitly configured to allow invocation by a non-recovery session.
<削除-config>のプロトコルの動作へのアクセスはデフォルトで拒否されます。 「execのデフォルト」の葉は、このプロトコルの操作には適用されません。アクセス制御ルールは、明示的に非リカバリ・セッションで呼び出しを許可するように設定する必要があります。
The server MUST determine the exact nodes in the running configuration datastore that are actually different and only check "create", "update", and "delete" access permissions for this set of nodes, which could be empty.
サーバーは、実際には異なるものであり、唯一、「アップデート」を「作成」、および空の可能性がこのノードのセットに対するアクセス権を、「削除」チェック実行中のコンフィギュレーションデータストアの正確なノードを決定する必要があります。
For example, if a session can read the entire datastore but only change one leaf, that session needs to be able to edit and commit that one leaf.
セッションは、データストア全体を読み込むだけで1つのリーフを変更することができた場合、そのセッションは、1枚の葉を編集し、コミットできるようにする必要があります。
The client is only required to have permission to execute the <discard-changes> protocol operation. No datastore permissions are needed.
クライアントは、唯一の<廃棄変化>プロトコル動作を実行する権限を有する必要があります。いいえデータストアの権限は必要ありません。
The <kill-session> operation does not directly alter a datastore. However, it allows one session to disrupt another session that is editing a datastore.
<殺すセッション>操作が直接データストアを変更しません。しかし、それは一つのセッションは、データストアを編集して別のセッションを破壊することができます。
Access to the <kill-session> protocol operation is denied by default. The "exec-default" leaf does not apply to this protocol operation. Access control rules must be explicitly configured to allow invocation by a non-recovery session.
<キル・セッション>プロトコルの動作へのアクセスはデフォルトで拒否されます。 「execのデフォルト」の葉は、このプロトコルの操作には適用されません。アクセス制御ルールは、明示的に非リカバリ・セッションで呼び出しを許可するように設定する必要があります。
This section defines the conceptual components related to the access control model.
このセクションでは、アクセス制御モデルに関連する概念のコンポーネントを定義します。
A "user" is the conceptual entity that is associated with the access permissions granted to a particular session. A user is identified by a string that is unique within the server.
「ユーザ」は、特定のセッションに付与されたアクセス権限に関連付けられている概念のエンティティです。ユーザーがサーバー内で一意の文字列で識別されます。
As described in [RFC6241], the username string is derived from the transport layer during session establishment. If the transport layer cannot authenticate the user, the session is terminated.
[RFC6241]に記載されているように、ユーザ名の文字列は、セッション確立時にトランスポート層に由来します。トランスポート層は、ユーザーを認証できない場合、セッションは終了します。
Access to a specific NETCONF protocol operation is granted to a session, associated with a group, not a user.
特定NETCONFプロトコルの動作へのアクセスは、セッションに付与されたグループではなく、ユーザに関連付けられています。
A group is identified by its name. All group names are unique within the server.
グループは、その名前によって識別されます。すべてのグループ名は、サーバー内で一意です。
A group member is identified by a username string.
グループのメンバーは、ユーザー名の文字列で識別されます。
The same user can be a member of multiple groups.
同一のユーザが複数のグループのメンバであることができます。
The server MAY support a recovery session mechanism, which will bypass all access control enforcement. This is useful for restricting initial access and repairing a broken access control configuration.
サーバーは、すべてのアクセス制御の施行をバイパスしますリカバリ・セッション・メカニズムをサポートすることができます。これは、初期のアクセスを制限し、壊れたアクセス制御の設定を修復するために有用です。
There are five global controls that are used to help control how access control is enforced.
アクセス制御が適用されている方法を制御しやすくするために使用されている5つのグローバルコントロールがあります。
A global "enable-nacm" on/off switch is provided to enable or disable all access control enforcement. When this global switch is set to "true", then all requests are checked against the access control rules and only permitted if configured to allow the specific access request. When this global switch is set to "false", then all access requested are permitted.
グローバルな「有効-nacm」オン/オフスイッチは、すべてのアクセス制御の施行を有効または無効にするために提供されます。このグローバルスイッチが「真」に設定されている場合、すべての要求は、アクセス制御ルールと照合され、特定のアクセス要求を許可するように設定されている場合にのみ許可します。このグローバルスイッチが「偽」に設定されている場合は、その後、要求されたすべてのアクセスが許可されています。
An on/off "read-default" switch is provided to enable or disable default access to receive data in replies and notifications. When the "enable-nacm" global switch is set to "true", then this global switch is relevant if no matching access control rule is found to explicitly permit or deny read access to the requested NETCONF datastore data or notification event type.
オン/オフ「をお読み-default」をスイッチは、返信や通知にデータを送受信するために、デフォルトのアクセスを有効または無効にするために提供されます。 「有効-nacm」グローバルスイッチが「true」に設定されている場合、一致するアクセス制御ルールが明示的に要求NETCONFデータストアデータまたは通知イベントタイプへの読み取りアクセスを許可または拒否するように発見されない場合は、このグローバルスイッチが関連しています。
When this global switch is set to "permit" and no matching access control rule is found for the NETCONF datastore read or notification event requested, then access is permitted.
このグローバルスイッチを「許可」とマッチングなしのアクセス制御ルールに設定されている場合は読みNETCONFのデータストアまたは要求された通知イベントのために発見され、アクセスが許可されています。
When this global switch is set to "deny" and no matching access control rule is found for the NETCONF datastore read or notification event requested, then access is denied.
このグローバルスイッチを「拒否」に設定されていると一致するアクセス制御ルールが読みNETCONFのデータストアまたは要求された通知イベントのために見つからない場合は、アクセスは拒否されます。
An on/off "write-default" switch is provided to enable or disable default access to alter configuration data. When the "enable-nacm" global switch is set to "true", then this global switch is relevant if no matching access control rule is found to explicitly permit or deny write access to the requested NETCONF datastore data.
オン/オフ「書き込みデフォルト」スイッチは、設定データを変更するために、デフォルトのアクセスを有効または無効にするために提供されます。 「有効-nacm」グローバルスイッチが「true」に設定されている場合、一致するアクセス制御ルールが明示的に要求NETCONFデータストアのデータへの書き込みアクセスを許可または拒否することが発見されない場合は、このグローバルスイッチが関連しています。
When this global switch is set to "permit" and no matching access control rule is found for the NETCONF datastore write requested, then access is permitted.
このグローバルスイッチを「許可」とマッチングなしのアクセス制御ルールに設定されている場合、要求NETCONFデータストアの書き込みのために発見され、アクセスが許可されています。
When this global switch is set to "deny" and no matching access control rule is found for the NETCONF datastore write requested, then access is denied.
このグローバルスイッチを「拒否」に設定されていると一致するアクセス制御ルールが要求されたNETCONFデータストアの書き込みに見つからない場合は、アクセスは拒否されます。
An on/off "exec-default" switch is provided to enable or disable default access to execute protocol operations. When the "enable-nacm" global switch is set to "true", then this global switch is relevant if no matching access control rule is found to explicitly permit or deny access to the requested NETCONF protocol operation.
オン/オフ「EXECデフォルト」スイッチは、プロトコル動作を実行するために、デフォルトのアクセスを有効または無効にするために提供されます。 「有効-nacmを」グローバルスイッチが「真」に設定されていると一致するアクセス制御ルールを明示的に要求されたNETCONFプロトコルの動作へのアクセスを許可または拒否することが発見されない場合は、このグローバルスイッチが関連しています。
When this global switch is set to "permit" and no matching access control rule is found for the NETCONF protocol operation requested, then access is permitted.
このグローバルスイッチが要求されたNETCONFプロトコルの動作のために発見された「許可」とマッチングなしのアクセス制御ルールに設定されている場合、アクセスは許可されています。
When this global switch is set to "deny" and no matching access control rule is found for the NETCONF protocol operation requested, then access is denied.
このグローバルスイッチを「拒否」に設定されていると一致するアクセス制御ルールが要求されたNETCONFプロトコルの動作のために見つからない場合は、アクセスは拒否されます。
When this global switch is set to "true", the group names reported by the NETCONF transport layer for a session are used together with the locally configured group names to determine the access control rules for the session.
このグローバルスイッチが「真」に設定されている場合、セッションのNETCONF輸送層によって報告されたグループ名は、セッションのためのアクセス制御ルールを決定するために、ローカルに設定されたグループ名と一緒に使用されます。
When this switch is set to "false", the group names reported by the NETCONF transport layer are ignored by NACM.
このスイッチが「偽」に設定されている場合、NETCONFのトランスポート層によって報告されたグループ名はNACMによって無視されます。
There are four types of rules available in NACM:
NACMで利用可能なルールの4つのタイプがあります。
module rule: controls access for definitions in a specific YANG module, identified by its name.
モジュールのルール：その名前で識別される特定YANGモジュール内のコントロールの定義のためのアクセスを、。
protocol operation rule: controls access for a specific protocol operation, identified by its YANG module and name.
プロトコルの動作ルール：そのYANGモジュールと名前によって識別される特定のプロトコル操作のためのアクセスを制御します。
data node rule: controls access for a specific data node, identified by its path location within the conceptual XML document for the data node.
データノードルール：特定のデータノードの制御アクセス、データノードの概念のXML文書内のそのパスの位置によって識別されます。
notification rule: controls access for a specific notification event type, identified by its YANG module and name.
通知ルールは：そのYANGモジュールと名前で識別される特定の通知イベント・タイプ、のためのアクセスを制御します。
There are seven separate phases that need to be addressed, four of which are related to the NETCONF message processing model (Section 3.1.3). In addition, the initial startup mode for a NETCONF server, session establishment, and "access-denied" error-handling procedures also need to be considered.
NETCONFメッセージ処理モデル（3.1.3）に関連しているそのうちの4つに対処する必要がある7つのフェーズがあります。また、初期のNETCONFサーバの起動モード、セッションの確立、および「アクセス拒否」のエラー処理手続きも考慮する必要があります。
The server MUST use the access control rules in effect at the time it starts processing the message. The same access control rules MUST stay in effect for the processing of the entire message.
サーバーは、メッセージの処理を開始する時点で有効なアクセス制御ルールを使用しなければなりません。同じアクセス制御ルールは、メッセージ全体の処理のために有効にとどまらなければなりません。
Upon the very first startup of the NETCONF server, the access control configuration will probably not be present. If it isn't, a server MUST NOT allow any write access to any session role except a recovery session.
NETCONFサーバの非常に最初の起動時に、アクセス制御の設定は、おそらく存在しません。そうでない場合は、サーバが復旧セッションを除くすべてのセッションの役割への書き込みアクセスを許可してはなりません。
Access rules are enforced any time a request is initiated from a user session. Access control is not enforced for server-initiated access requests, such as the initial load of the running datastore, during bootup.
アクセスルールは、要求がユーザーセッションから開始されるたびに適用されます。アクセス制御は、起動中に、そのような実行されているデータストアの初期負荷としてサーバー開始アクセス要求のために強制されません。
The access control model applies specifically to the well-formed XML content transferred between a client and a server after session establishment has been completed and after the <hello> exchange has been successfully completed.
アクセス制御モデルは、セッションの確立が完了した後と<こんにちは>交換が正常に完了した後で、クライアントとサーバーの間で転送整形式のXMLコンテンツに特異的に適用されます。
Once session establishment is completed and a user has been authenticated, the NETCONF transport layer reports the username and a possibly empty set of group names associated with the user to the NETCONF server. The NETCONF server will enforce the access control rules, based on the supplied username, group names, and the configuration data stored on the server.
セッション確立が完了すると、ユーザが認証されると、NETCONF輸送層は、ユーザ名とNETCONFサーバへのユーザに関連付けられたグループ名の可能性が空のセットを報告します。 NETCONFサーバは、供給されたユーザ名、グループ名、およびサーバ上に格納されたコンフィギュレーションデータに基づいて、アクセス制御規則を適用します。
The "access-denied" error-tag is generated when the access control system denies access to either a request to invoke a protocol operation or a request to perform a particular access operation on the configuration datastore.
アクセス制御システムは、プロトコルの動作を起動するための要求や設定データストアに特定のアクセス操作を実行するための要求のいずれかへのアクセスを拒否するとき、「アクセス拒否」エラー・タグが生成されます。
A server MUST NOT include any information the client is not allowed to read in any <error-info> elements within the <rpc-error> response.
サーバーは、クライアントがどの<エラー情報>で<RPCエラー>応答内の要素を読み取ることが許可されていないすべての情報を含んではいけません。
The diagram below shows the basic conceptual structure of the access control processing model for incoming NETCONF <rpc> messages within a server.
以下の図は、サーバー内の着信NETCONF <RPC>メッセージのアクセス制御処理モデルの基本的な概念構造を示しています。
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
図3
Access control begins with the message dispatcher.
アクセス制御は、メッセージディスパッチャで始まります。
After the server validates the <rpc> element and determines the namespace URI and the element name of the protocol operation being requested, the server verifies that the user is authorized to invoke the protocol operation.
サーバーは<RPC>要素を検証し、URIおよびプロトコル動作の要素名が要求されているネームスペースを決定した後、サーバは、ユーザがプロトコルの動作を起動することを許可されていることを検証します。
The server MUST separately authorize every protocol operation by following these steps:
サーバーは、別途、以下の手順を実行して、すべてのプロトコルの動作を許可する必要があります：
1. If the "enable-nacm" leaf is set to "false", then the protocol operation is permitted.
「有効-nacmを」葉が「偽」に設定されている場合は1、その後、プロトコルの動作が許可されています。
2. If the requesting session is identified as a recovery session, then the protocol operation is permitted.
要求セッションをリカバリセッションと識別された場合2、プロトコル動作が許可されます。
3. If the requested operation is the NETCONF <close-session> protocol operation, then the protocol operation is permitted.
要求された操作がNETCONF <クローズセッション>プロトコル動作の場合3は、プロトコルの動作が許可されます。
4. Check all the "group" entries for ones that contain a "user-name" entry that equals the username for the session making the request. If the "enable-external-groups" leaf is "true", add to these groups the set of groups provided by the transport layer.
4.要求を行うセッションのユーザ名と等しい「ユーザー名」のエントリが含まれているもののために、すべての「グループ」の項目を確認してください。 「有効-外部グループの」葉が「真」である場合には、これらのグループにトランスポート層が提供するグループのセットを追加します。
6. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry.
6.プロセスのすべてのルールリストのエントリは、順番に彼らは、コンフィギュレーションに表示されます。ルールリストの「グループ」リーフリストは、ユーザのグループのいずれにも一致しない場合は、次のルールリストのエントリに進みます。
7. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met:
見つかった各ルールリストエントリ7.、プロセスのすべてのルールを、順番に、要求されたアクセス動作に一致するルールが見つかるまで。次の基準のすべてが満たされた場合にルールが一致します。
* The rule's "module-name" leaf is "*" or equals the name of
the YANG module where the protocol operation is defined.
* The rule does not have a "rule-type" defined or the "rule-type" is "protocol-operation" and the "rpc-name" is "*" or equals the name of the requested protocol operation.
*ルールが定義されている「ルール・タイプ」または「ルール・タイプ」を持っていない「プロトコル・オペレーション」であり、「RPC-nameは」「*」であるか、要求されたプロトコルの操作の名前に等しいです。
* The rule's "access-operations" leaf has the "exec" bit set or has the special value "*".
*ルールの「アクセス・オペレーション」の葉に「実行」ビットがセットされているか、特別な値「*」を持っています。
8. If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then the protocol operation is permitted; otherwise, it is denied.
8.一致する規則が見つかった場合には、「アクション」の葉がチェックされています。それが「許可」に等しい場合、プロトコルの動作が許可されます。それ以外の場合は拒否されます。
9. At this point, no matching rule was found in any rule-list entry.
9.この時点では、一致するルールは、任意のルールリストのエントリには見られませんでした。
10. If the requested protocol operation is defined in a YANG module advertised in the server capabilities and the "rpc" statement contains a "nacm:default-deny-all" statement, then the protocol operation is denied.
10.要求されたプロトコル操作はサーバ機能でアドバタイズYANGモジュールで定義されており、「RPC」文が含まれている場合は、「nacm：デフォルト-拒否 - すべての」文、プロトコル操作は拒否されました。
11. If the requested protocol operation is the NETCONF <kill-session> or <delete-config>, then the protocol operation is denied.
11.要求されたプロトコルの動作がNETCONFであれば、プロトコル動作が拒否され、<セッションを殺す>または<削除-config>の。
12. If the "exec-default" leaf is set to "permit", then permit the protocol operation; otherwise, deny the request.
12.「EXEC-デフォルトの」葉が「許可」に設定されている場合、プロトコル動作を許可します。それ以外の場合は、要求を拒否します。
If the user is not authorized to invoke the protocol operation, then an <rpc-error> is generated with the following information:
ユーザは、プロトコルの動作を起動することを許可されていない場合、<RPCエラー>は、次の情報が生成されます。
error-tag: access-denied
エラータグ：アクセス拒否
error-path: Identifies the requested protocol operation. The following example represents the <edit-config> protocol operation in the NETCONF base namespace:
エラーパスは：要求されたプロトコルの動作を識別します。次の例では、NETCONFベースの名前空間内の<編集設定>プロトコルの動作を表します。
<error-path
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
/nc:rpc/nc:edit-config
</error-path>
If a datastore is accessed, either directly or as a side effect of the protocol operation, then the server MUST intercept the access operation and make sure the user is authorized to perform the requested access operation on the specified data, as defined in Section 3.4.5.
データストアは、直接またはプロトコル動作の副作用として、アクセスされた場合、サーバは、アクセス動作を傍受し、セクション3.4で定義されるように、ユーザは、指定されたデータに対して要求されたアクセス動作を実行することを許可されていることを確認しなければなりません。 5。
If a data node within a datastore is accessed, then the server MUST ensure that the user is authorized to perform the requested "read", "create", "update", or "delete" access operation on the specified data node.
データストア内のデータノードにアクセスする場合、サーバは、ユーザが指定したデータ・ノードに要求された「削除」、「作成」、「読み取り」、「更新」、又はアクセス動作の実行を許可されていることを確認しなければなりません。
The data node access request is authorized by following these steps:
データノードのアクセス要求は、以下の手順を実行して許可されています。
1. If the "enable-nacm" leaf is set to "false", then the access operation is permitted.
「有効-nacmを」葉が「偽」に設定されている場合は1、その後、アクセス動作が許可されています。
2. If the requesting session is identified as a recovery session, then the access operation is permitted.
要求セッションがリカバリ・セッションとして識別されている場合は2、その後、アクセス動作が許可されています。
3. Check all the "group" entries for ones that contain a "user-name" entry that equals the username for the session making the request. If the "enable-external-groups" leaf is "true", add to these groups the set of groups provided by the transport layer.
3.要求を行うセッションのユーザ名と等しい「ユーザー名」のエントリが含まれているもののために、すべての「グループ」の項目を確認してください。 「有効-外部グループの」葉が「真」である場合には、これらのグループにトランスポート層が提供するグループのセットを追加します。
5. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry.
5.プロセスのすべてのルール・リストのエントリは、順番に彼らは、コンフィギュレーションに表示されます。ルールリストの「グループ」リーフリストは、ユーザのグループのいずれにも一致しない場合は、次のルールリストのエントリに進みます。
6. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met:
検出された各ルールリストエントリ6.、プロセスすべてのルールを、順番に、要求されたアクセス動作に一致するルールが見つかるまで。次の基準のすべてが満たされた場合にルールが一致します。
* The rule's "module-name" leaf is "*" or equals the name of
the YANG module where the requested data node is defined.
* The rule does not have a "rule-type" defined or the "rule-type" is "data-node" and the "path" matches the requested data node.
*ルールが定義されている「ルール型」または「ルール・タイプ」を持たない「データノード」であり、「パス」は、要求されたデータノードと一致します。
* For a "read" access operation, the rule's "access-operations" leaf has the "read" bit set or has the special value "*".
*「読み取り」アクセス動作のために、ルールの「アクセス・オペレーション」の葉は、設定された「読み」ビットを持っているか、特別な値「*」を持っています。
* For a "create" access operation, the rule's "access-operations" leaf has the "create" bit set or has the special value "*".
*「作成」アクセス動作のために、ルールの「アクセス・オペレーション」の葉は、設定された「作成」ビットを持っているか、特別な値「*」を持っています。
* For a "delete" access operation, the rule's "access-operations" leaf has the "delete" bit set or has the special value "*".
*「削除」アクセス動作のために、ルールの「アクセス・オペレーション」の葉は、設定された「削除」ビットを持っているか、特別な値「*」を持っています。
* For an "update" access operation, the rule's "access-operations" leaf has the "update" bit set or has the special value "*".
*「更新」アクセス動作のために、ルールの「アクセス・オペレーション」の葉は、「更新」ビットがセットされているか、特別な値「*」を持っています。
7. If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then the data node access is permitted; otherwise, it is denied. For a "read" access operation, "denied" means that the requested data is not returned in the reply.
7.一致する規則が見つかった場合には、「アクション」の葉がチェックされています。それが「許可」に等しい場合、データノードのアクセスが許可されています。それ以外の場合は拒否されます。 「読み取り」アクセス動作のために、要求されたデータが応答で返されないことを意味し、「拒否」。
8. At this point, no matching rule was found in any rule-list entry.
8.この時点で、該当するルールは、任意のルールリストエントリに見られませんでした。
9. For a "read" access operation, if the requested data node is defined in a YANG module advertised in the server capabilities and the data definition statement contains a "nacm:default-deny-all" statement, then the requested data node is not included in the reply.
「：デフォルト-拒否 - すべてnacm」声明、その後、要求されたデータノードが要求されたデータノードがサーバ機能でアドバタイズYANGモジュールで定義され、データ定義文が含まれている場合、アクセス動作を「読み取り」9.返信には含まれません。
10. For a "write" access operation, if the requested data node is defined in a YANG module advertised in the server capabilities and the data definition statement contains a "nacm:default-deny-write" or a "nacm:default-deny-all" statement, then the data node access request is denied.
または「nacm：デフォルト-拒否：「書き込み」アクセス動作のために10は、要求されたデータノードがサーバー機能とデータ定義文でアドバタイズYANGモジュールで定義されている場合は、「デフォルト・書き込みを拒否nacm」が含ま-all」文は、データ・ノードのアクセス要求が拒否されます。
11. For a "read" access operation, if the "read-default" leaf is set to "permit", then include the requested data node in the reply; otherwise, do not include the requested data node in the reply.
、アクセス動作を「読み取り」、「読み取りデフォルトの」葉が「許可」に設定されている場合、応答で要求されたデータノードを含む11.。そうでない場合は、返信に要求されたデータノードが含まれていません。
12. For a "write" access operation, if the "write-default" leaf is set to "permit", then permit the data node access request; otherwise, deny the request.
「書き込み」アクセス動作については12、「書き込みのデフォルトを」葉が「許可」、そして、データノードへのアクセス要求を許可するように設定されている場合は、それ以外の場合は、要求を拒否します。
Configuration of access control rules specifically for descendant nodes of the notification event type element are outside the scope of this document. If the user is authorized to receive the notification event type, then it is also authorized to receive any data it contains.
具体的には、通知イベント・タイプの要素の子孫ノードのアクセス制御ルールの構成は、この文書の範囲外です。ユーザーは、通知イベントのタイプを受け取ることを許可されている場合は、それが含まれている任意のデータを受信することも許可されています。
The following figure shows the conceptual message processing model for outgoing <notification> messages.
次の図は、発信<通知>メッセージの概念メッセージ処理モデルを示しています。
NETCONF server
+------------+
| XML |
| message |
| generator |
+------------+
^
|
+----------------+
| <notification> |
| generator |
+----------------+
^
|
+=================+
| <notification> |
| access control |
| <eventType> |
+=================+
^
|
+------------------------+
| server instrumentation |
+------------------------+
| ^
V |
+----------------------+
| configuration |
| datastore |
+----------------------+
Figure 4
図4
The generation of a notification for a specific subscription [RFC5277] is authorized by following these steps:
特定のサブスクリプション[RFC5277]の通知の生成は、以下の手順を実行して承認されます。
1. If the "enable-nacm" leaf is set to "false", then the notification is permitted.
「有効-nacmを」葉が「偽」に設定されている場合は1、その通知が許可されています。
2. If the session is identified as a recovery session, then the notification is permitted.
セッションがリカバリ・セッションとして識別される2.場合は、通知が許可されています。
3. If the notification is the NETCONF <replayComplete> or <notificationComplete> event type [RFC5277], then the notification is permitted.
通知はNETCONF <replayComplete>または<notificationComplete>イベント種別[RFC5277]の場合3は、通知が許可されます。
4. Check all the "group" entries for ones that contain a "user-name" entry that equals the username for the session making the request. If the "enable-external-groups" leaf is "true", add to these groups the set of groups provided by the transport layer.
4.要求を行うセッションのユーザ名と等しい「ユーザー名」のエントリが含まれているもののために、すべての「グループ」の項目を確認してください。 「有効-外部グループの」葉が「真」である場合には、これらのグループにトランスポート層が提供するグループのセットを追加します。
6. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry.
6.プロセスのすべてのルールリストのエントリは、順番に彼らは、コンフィギュレーションに表示されます。ルールリストの「グループ」リーフリストは、ユーザのグループのいずれにも一致しない場合は、次のルールリストのエントリに進みます。
7. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met:
見つかった各ルールリストエントリ7.、プロセスのすべてのルールを、順番に、要求されたアクセス動作に一致するルールが見つかるまで。次の基準のすべてが満たされた場合にルールが一致します。
* The rule's "module-name" leaf is "*" or equals the name of
the YANG module where the notification is defined.
* The rule does not have a "rule-type" defined or the "rule-type" is "notification" and the "notification-name" is "*" and equals the name of the notification.
*ルールが定義されている「ルール・タイプ」または「ルール・タイプ」で「通知」と「通知-name」を持っていない「*」であると通知の名前に等しいです。
* The rule's "access-operations" leaf has the "read" bit set or has the special value "*".
*ルールの「アクセス・オペレーション」の葉は、「*」ビットセットを「読み取る」または特別な値を持っています。
8. If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then permit the notification; otherwise, drop the notification for the associated subscription.
8.一致する規則が見つかった場合には、「アクション」の葉がチェックされています。それは「許可」に等しい場合、通知を許可します。それ以外の場合は、関連するサブスクリプションの通知をドロップします。
10. If the requested notification is defined in a YANG module advertised in the server capabilities and the "notification" statement contains a "nacm:default-deny-all" statement, then the notification is dropped for the associated subscription.
10.要求された通知は、サーバー機能でアドバタイズYANGモジュールで定義されており、「通知」文が含まれている場合：その後、通知が関連するサブスクリプションのために廃棄され、「nacmデフォルト-拒否 - すべての」文を。
11. If the "read-default" leaf is set to "permit", then permit the notification; otherwise, drop the notification for the associated subscription.
11.「読み込みデフォルトの」葉が「許可」に設定されている場合は、通知を許可します。それ以外の場合は、関連するサブスクリプションの通知をドロップします。
The following diagram highlights the contents and structure of the NACM YANG module.
次の図は、NACM YANGモジュールの内容と構造を強調しています。
+--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
The following YANG module specifies the normative NETCONF content that MUST by supported by the server.
次YANGモジュールは、サーバでサポートされていることにより、しなければならない規範NETCONFの内容を指定します。
The "ietf-netconf-acm" YANG module imports typedefs from [RFC6021].
[RFC6021]から "IETF-NETCONF-ACM" YANGモジュール輸入のtypedef。
<CODE BEGINS> file "ietf-netconf-acm@2012-02-22.yang"
ファイル "ietf-netconf-acm@2012-02-22.yang" <CODEが開始されます>
module ietf-netconf-acm {
IETF-NETCONF気筒モジュール{
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm";
名前空間 "URN：IETF：のparams：XML：NS：ヤン：IETF-NETCONF-ACM"。
prefix "nacm";
接頭辞「nacm」。
import ietf-yang-types { prefix yang; }
インポートIETF-ヤン・タイプ{プレフィックス陽。 }
organization "IETF NETCONF (Network Configuration) Working Group";
組織「IETF NETCONF（ネットワーク設定）ワーキンググループ」。
contact "WG Web: <http://tools.ietf.org/wg/netconf/> WG List: <mailto:netconf@ietf.org>
「連絡WGのWeb：<http://tools.ietf.org/wg/netconf/> WG一覧：<mailtoの：netconf@ietf.org>
WG Chair: Mehmet Ersue <mailto:mehmet.ersue@nsn.com>
WG座長：メフメットArsin <mailtoの：mehmet.ersue@nsn.co I>
WG Chair: Bert Wijnen <mailto:bertietf@bwijnen.net>
WG座長：バートWijnen <mailtoの：bertietf@bwijnen.net>
Editor: Andy Bierman <mailto:andy@yumaworks.com>
編集者：アンディBierman <mailtoの：andy@yumaworks.com>
Editor: Martin Bjorklund <mailto:mbj@tail-f.com>";
エディタ：マーティンBjorklund <mailtoの：mbj@tail-f.com>「;
description "NETCONF Access Control Model.
説明「NETCONFのアクセス制御モデル。
Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2012 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 6536; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 6536の一部です。完全な適法な通知についてはRFC自体を参照してください。 ";
revision "2012-02-22" {
改正 "2012-02-22" {
description
"Initial version";
reference
"RFC 6536: Network Configuration Protocol (NETCONF)
Access Control Model";
}
/*
* Extension statements
*/
extension default-deny-write { description "Used to indicate that the data model node represents a sensitive security system parameter.
データ・モデル・ノードは、敏感なセキュリティシステム・パラメータを表すことを示すために使用される拡張デフォルト-拒否ライト{説明」。
If present, and the NACM module is enabled (i.e.,
/nacm/enable-nacm object equals 'true'), the NETCONF server
will only allow the designated 'recovery session' to have
write access to the node. An explicit access control rule is
required for all other users.
The 'default-deny-write' extension MAY appear within a data definition statement. It is ignored otherwise."; }
「デフォルト・拒否 - 書き込み」の拡張は、データ定義文の中に表示されることがあります。それは、そうでない場合は無視されます。 ";}
extension default-deny-all { description "Used to indicate that the data model node controls a very sensitive security system parameter.
データモデルのノードは非常に敏感なセキュリティシステムパラメータを制御することを示すために使用される拡張デフォルト-拒否 - すべての{記述」。
If present, and the NACM module is enabled (i.e.,
/nacm/enable-nacm object equals 'true'), the NETCONF server
will only allow the designated 'recovery session' to have
read, write, or execute access to the node. An explicit
access control rule is required for all other users.
The 'default-deny-all' extension MAY appear within a data definition statement, 'rpc' statement, or 'notification' statement. It is ignored otherwise."; }
「デフォルト・拒否 - すべての」拡張機能は、データ定義文、「RPC」ステートメント、または「通知」ステートメントの中に表示されることがあります。それは、そうでない場合は無視されます。 ";}
/*
* Derived types
*/
typedef user-name-type { type string {
typedefのユーザ名型{型列{
length "1..max";
}
description
"General Purpose Username string.";
}
typedef matchall-string-type {
type string {
pattern "\*";
}
description
"The string containing a single asterisk '*' is used
to conceptually represent all possible values
for the particular leaf using this data type.";
}
typedef access-operations-type {
type bits {
bit create {
description
"Any protocol operation that creates a
new data node.";
}
bit read {
description
"Any protocol operation or notification that
returns the value of a data node.";
}
bit update {
description
"Any protocol operation that alters an existing
data node.";
}
bit delete {
description
"Any protocol operation that removes a data node.";
}
bit exec {
description
"Execution access to the specified protocol operation.";
}
}
description
"NETCONF Access Operation.";
}
typedef group-name-type { type string {
typedefのグループ名型{型列{
length "1..max";
pattern "[^\*].*";
}
description
"Name of administrative group to which
users can be assigned.";
}
typedef action-type {
type enumeration {
enum permit {
description
"Requested action is permitted.";
}
enum deny {
description
"Requested action is denied.";
}
}
description
"Action taken by the server when a particular
rule matches.";
}
typedef node-instance-identifier { type yang:xpath1.0; description "Path expression used to represent a special data node instance identifier string.
typedefのノードインスタンス識別子{タイプ陽：xpath1.0。説明「特別なデータノードインスタンス識別子文字列を表すために使用されるパス式。
A node-instance-identifier value is an
unrestricted YANG instance-identifier expression.
All the same rules as an instance-identifier apply
except predicates for keys are optional. If a key
predicate is missing, then the node-instance-identifier
represents all possible server instances for that key.
This XPath expression is evaluated in the following context:
このXPath式は、次のコンテキストで評価されています。
o The set of namespace declarations are those in scope on the leaf element where this type is used.
名前空間宣言のセットoをこのタイプが使用されているリーフ要素にスコープのものです。
o The set of variable bindings contains one variable, 'USER', which contains the name of the user of the current session.
O変数バインディングのセットは、現在のセッションのユーザの名前が含まれている一つの変数、「USER」を、含まれています。
o The function library is the core function library, but note that due to the syntax restrictions of an instance-identifier, no functions are allowed.
O関数ライブラリは、コア関数ライブラリですが、原因インスタンス識別子の構文の制限に、何の機能が許可されないことに注意してください。
o The context node is the root node in the data tree."; }
Oコンテキストノードは、データツリーのルートノードです ";}
/*
* Data definition statements
*/
container nacm { nacm:default-deny-all;
コンテナnacm {nacm：デフォルト-拒否 - すべて。
description "Parameters for NETCONF Access Control Model.";
説明「NETCONFのアクセス制御モデルのパラメータ。」;
leaf enable-nacm {
type boolean;
default true;
description
"Enables or disables all NETCONF access control
enforcement. If 'true', then enforcement
is enabled. If 'false', then enforcement
is disabled.";
}
leaf read-default {
type action-type;
default "permit";
description
"Controls whether read access is granted if
no appropriate rule is found for a
particular read request.";
}
leaf write-default {
type action-type;
default "deny";
description
"Controls whether create, update, or delete access
is granted if no appropriate rule is found for a
particular write request.";
}
leaf exec-default {
type action-type;
default "permit";
description
"Controls whether exec access is granted if no appropriate
rule is found for a particular protocol operation request."; }
ルールは、特定のプロトコル操作要求のために発見されました ";}
leaf enable-external-groups {
type boolean;
default true;
description
"Controls whether the server uses the groups reported by the
NETCONF transport layer when it assigns the user to a set of
NACM groups. If this leaf has the value 'false', any group
names reported by the transport layer are ignored by the
server.";
}
leaf denied-operations {
type yang:zero-based-counter32;
config false;
mandatory true;
description
"Number of times since the server last restarted that a
protocol operation request was denied.";
}
leaf denied-data-writes {
type yang:zero-based-counter32;
config false;
mandatory true;
description
"Number of times since the server last restarted that a
protocol operation request to alter
a configuration datastore was denied.";
}
leaf denied-notifications {
type yang:zero-based-counter32;
config false;
mandatory true;
description
"Number of times since the server last restarted that
a notification was dropped for a subscription because
access to the event type was denied.";
}
container groups { description "NETCONF Access Control Groups.";
コンテナグループ{説明「NETCONFアクセス制御グループ。」;
list group {
リストグループ{
key name;
キー名;
description "One NACM Group Entry. This list will only contain configured entries, not any entries learned from any transport protocols.";
説明「ワンNACMグループエントリこのリストには、設定したエントリだけが含まれます、いないすべてのエントリは、任意のトランスポートプロトコルから学びました。」;
leaf name {
type group-name-type;
description
"Group name associated with this entry.";
}
leaf-list user-name {
type user-name-type;
description
"Each entry identifies the username of
a member of the group associated with
this entry.";
}
}
}
list rule-list {
key "name";
ordered-by user;
description
"An ordered collection of access control rules.";
leaf name {
type string {
length "1..max";
}
description
"Arbitrary name assigned to the rule-list.";
}
leaf-list group {
type union {
type matchall-string-type;
type group-name-type;
}
description
"List of administrative groups that will be
assigned the associated access rights
defined by the 'rule' list.
The string '*' indicates that all groups apply to the
entry.";
}
｝
list rule {
key "name";
ordered-by user;
description
"One access control rule.
Rules are processed in user-defined order until a match is
found. A rule matches if 'module-name', 'rule-type', and
'access-operations' match the request. If a rule
matches, the 'action' leaf determines if access is granted
or not.";
leaf name {
type string {
length "1..max";
}
description
"Arbitrary name assigned to the rule.";
}
leaf module-name {
type union {
type matchall-string-type;
type string;
}
default "*";
description
"Name of the module associated with this rule.
This leaf matches if it has the value '*' or if the
object being accessed is defined in the module with the
specified module name.";
}
choice rule-type {
description
"This choice matches if all leafs present in the rule
match the request. If no leafs are present, the
choice matches all requests.";
case protocol-operation {
leaf rpc-name {
type union {
type matchall-string-type;
type string;
}
description
"This leaf matches if it has the value '*' or if
its value equals the requested protocol operation
name.";
}
}
case notification {
leaf notification-name {
type union {
type matchall-string-type;
type string;
}
description
"This leaf matches if it has the value '*' or if its
value equals the requested notification name.";
}
}
case data-node {
leaf path {
type node-instance-identifier;
mandatory true;
description
"Data Node Instance Identifier associated with the
data node controlled by this rule.
Configuration data or state data instance
identifiers start with a top-level data node. A
complete instance identifier is required for this
type of path value.
The special value '/' refers to all possible datastore contents."; } } }
「/」特殊値は、すべての可能なデータストアの内容を参照 ";}}}
leaf access-operations {
type union {
type matchall-string-type;
type access-operations-type;
}
default "*";
description
"Access operations associated with this rule.
This leaf matches if it has the value '*' or if the bit corresponding to the requested operation is set."; }
ビットがセットされ、要求された操作に対応する場合には、この葉は、それが値を持っている場合は「*」と一致しますか ";}
leaf action {
葉のアクション{
type action-type;
mandatory true;
description
"The access control action associated with the
rule. If a rule is determined to match a
particular request, then this object is used
to determine whether to permit or deny the
request.";
}
leaf comment {
type string;
description
"A textual description of the access rule.";
}
}
}
}
}
<CODE ENDS>
<CODEはENDS>
This document registers one URI in "The IETF XML Registry". Following the format in [RFC3688], the following has been registered.
この文書では、「IETF XMLレジストリ」で1つの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.
This document registers one module in the "YANG Module Names" registry. Following the format in [RFC6020], the following has been registered.
この文書は、「YANGモジュール名」レジストリに一つのモジュールを登録します。 [RFC6020]でフォーマットした後、次のように登録されています。
Name: ietf-netconf-acm
Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
Prefix: nacm
reference: RFC 6536
This entire document discusses access control requirements and mechanisms for restricting NETCONF protocol behavior within a given session.
この文書全体は、与えられたセッション内でNETCONFプロトコルの動作を制限するアクセス制御要件とメカニズムについて説明します。
This section highlights the issues for an administrator to consider when configuring a NETCONF server with NACM.
このセクションでは、NACMとNETCONFサーバを設定する際に考慮すべき管理者のための問題を強調しています。
Configuration of the access control system is highly sensitive to system security. A server may choose not to allow any user configuration to some portions of it, such as the global security level or the groups that allowed access to system resources.
アクセス制御システムの構成は、システムのセキュリティに非常に敏感です。サーバーは、このようなグローバルなセキュリティ・レベルとして、それのいくつかの部分、またはシステムリソースへのアクセスを許可されたグループにすべてのユーザーの設定を許可しないことを選択することができます。
By default, NACM enforcement is enabled. By default, "read" access to all datastore contents is enabled (unless "nacm:default-deny-all" is specified for the data definition), and "exec" access is enabled for safe protocol operations. An administrator needs to ensure that NACM is enabled and also decide if the default access parameters are set appropriately. Make sure the following data nodes are properly configured:
デフォルトでは、NACMの執行が有効になっています。デフォルトでは、すべてのデータストアのコンテンツへのアクセスが有効になっている「読み取り」（しない限り、「nacm：デフォルト--すべてを否定する」データ定義に指定されている）、そして「実行」アクセスは安全なプロトコル動作のために有効になっています。管理者は、NACMが有効になっていることを確認し、デフォルトのアクセスパラメータが適切に設定されている場合にも決定する必要があります。以下のデータノードが正しく設定されていることを確認します。
o /nacm/enable-nacm (default "true")
O / nacm /有効-nacm（デフォルトの "真"）
o /nacm/read-default (default "permit")
O / nacm /読み込みデフォルト（既定 "許可"）
o /nacm/write-default (default "deny")
O / nacm /書き込みデフォルト（デフォルト "拒否"）
o /nacm/exec-default (default "permit")
O / nacm / execのデフォルト（既定 "許可"）
An administrator needs to restrict write access to all configurable objects within this data model.
管理者は、このデータモデル内のすべての設定可能なオブジェクトへの書き込みアクセスを制限する必要があります。
If write access is allowed for configuration of access control rules, then care needs to be taken not to disrupt the access control enforcement. For example, if the NACM access control rules are edited directly within the running configuration datastore (i.e., :writable-running capability is supported and used), then care needs to be taken not to allow unintended access while the edits are being done.
書き込みアクセスは、アクセス制御ルールの設定のために許可されている場合は、ケアは、アクセス制御の執行を妨害しないように注意する必要があります。 NACMアクセス制御ルールを実行コンフィギュレーションデータストア内で直接編集している場合、例えば、（すなわち、：書込み可能 - 実行機能はサポートされて使用される）、次いでケアは編集が行われている間に、意図しないアクセスを許可しないように注意する必要があります。
An administrator needs to make sure that the translation from a transport- or implementation-dependent user identity to a NACM username is unique and correct. This requirement is specified in detail in Section 2.2 of [RFC6241].
管理者は、NACMのユーザー名にtransport-または実装依存のユーザーIDからの翻訳は、ユニークかつ正確であることを確認する必要があります。この要件は、[RFC6241]のセクション2.2で詳細に指定されています。
An administrator needs to be aware that the YANG data structures representing access control rules (/nacm/rule-list and /nacm/ rule-list/rule) are ordered by the client. The server will evaluate the access control rules according to their relative conceptual order within the running datastore configuration.
管理者は、アクセス制御ルール（/ nacm /ルールリストおよび/ nacm /ルールリスト/ルール）を表すYANGデータ構造がクライアントによって順序付けられていることに注意する必要があります。サーバが実行されているデータストアのコンフィギュレーション内での相対的な概念の順序に従ってアクセス制御ルールを評価します。
Note that the /nacm/groups data structure contains the administrative group names used by the server. These group names may be configured locally and/or provided through an external protocol, such as RADIUS [RFC2865][RFC5607].
/ nacm /グループのデータ構造は、サーバが使用する管理グループの名前が含まれていることに注意してください。これらのグループ名は、ローカルに設定および/またはそのようなRADIUS [RFC2865]、[RFC5607]のように、外部のプロトコルを介して提供されてもよいです。
An administrator needs to be aware of the security properties of any external protocol used by the NETCONF transport layer to determine group names. For example, if this protocol does not protect against man-in-the-middle attacks, an attacker might be able to inject group names that are configured in NACM, so that a user gets more permissions than it should. In such cases, the administrator may wish to disable the usage of such group names, by setting /nacm/ enable-external-groups to "false".
管理者は、グループ名を決定するためにNETCONFのトランスポート層で使用される任意の外部プロトコルのセキュリティプロパティを認識する必要があります。このプロトコルは、man-in-the-middle攻撃を防御していない場合、例えば、攻撃者は、それが必要以上のユーザーがより多くの権限を取得するように、NACMで構成されたグループ名を注入することができるかもしれません。このような場合には、管理者が「false」に設定/ nacm /有効-外部のグループによって、このようなグループ名の使用を無効にすることもできます。
An administrator needs to restrict read access to the following objects within this data model, as they reveal access control configuration that could be considered sensitive.
管理者は、彼らが敏感と考えることができ、アクセス制御の設定を明らかにするよう、このデータモデル内の次のオブジェクトへの読み取りアクセスを制限する必要があります。
o /nacm/enable-nacm
O / nacm /イネーブルnacm
o /nacm/read-default
O / nacm /読み込みデフォルト
o /nacm/write-default
O / nacm /書き込みデフォルト
o /nacm/exec-default
O / nacm / execのデフォルト
o /nacm/enable-external-groups
O / nacm /有効-外部グループ
o /nacm/groups
O / nacm /グループ
o /nacm/rule-list
O / nacm /ルールリスト
There is a risk that invocation of non-standard protocol operations will have undocumented side effects. An administrator needs to construct access control rules such that the configuration datastore is protected from such side effects.
非標準プロトコル動作の呼び出しが文書化されていない副作用を持っているおそれがあります。管理者は、コンフィギュレーション・データストアは、このような副作用から保護されるように、アクセス制御ルールを作成する必要があります。
It is possible for a session with some write access (e.g., allowed to invoke <edit-config>), but without any access to a particular datastore subtree containing sensitive data, to determine the presence or non-presence of that data. This can be done by repeatedly issuing some sort of edit request (create, update, or delete) and possibly receiving "access-denied" errors in response. These "fishing" attacks can identify the presence or non-presence of specific sensitive data even without the "error-path" field being present within the <rpc-error> response.
そのデータの存在または非存在を決定するために、（例えば、<編集設定>起動させ）、いくつかの書き込みアクセスのセッションのために可能であるが、機密データを含む特定のデータストアのサブツリーへのアクセスはありません。これは、繰り返し編集要求（作成、更新、または削除）、おそらく応じて、「アクセス拒否」のエラーを受け取るのいくつかの並べ替えを発行することによって行うことができます。これらの「フィッシング」攻撃があっても、「エラーパス」フィールドは<RPCエラー>応答内に存在することなく、特定の機密データの存在または非存在を同定することができます。
It may be possible for the set of NETCONF capabilities on the server to change over time. If so, then there is a risk that new protocol operations, notifications, and/or datastore content have been added to the device. An administrator needs to be sure the access control rules are correct for the new content in this case. Mechanisms to detect NETCONF capability changes on a specific device are outside the scope of this document.
サーバー上のNETCONF機能のセットは、時間の経過とともに変化することが可能かもしれません。もしそうなら、新しいプロトコル操作、通知、および/またはデータストアのコンテンツをデバイスに追加されているおそれがあります。管理者は、アクセス制御ルールは、この場合は、新たなコンテンツのための正しいことを確認する必要があります。特定のデバイス上のNETCONF能力の変化を検出するための機構は、この文書の範囲外です。
It is possible that the data model definition itself (e.g., YANG when-stmt) will help an unauthorized session determine the presence or even value of sensitive data nodes by examining the presence and values of different data nodes.
データ・モデルの定義自体は、（例えば、YANG-STMT）は、不正なセッションは、異なるデータノードの存在及び値を調べることによって存在または機密データノードの偶数値を決定するのを助けることが可能です。
There is a risk that non-standard protocol operations, or even the standard <get> protocol operation, may return data that "aliases" or "copies" sensitive data from a different data object. There may simply be multiple data model definitions that expose or even configure the same underlying system instrumentation.
非標準プロトコル動作、あるいは標準<GET>プロトコルの動作は、「エイリアス」または異なるデータオブジェクトから「コピー」機密データというデータを返すおそれがあります。単に公開したりしても、同じ基本システム装置を構成する複数のデータモデルの定義があるかもしれません。
A data model may contain external keys (e.g., YANG leafref), which expose values from a different data structure. An administrator needs to be aware of sensitive data models that contain leafref nodes. This entails finding all the leafref objects that "point" at the sensitive data (i.e., "path-stmt" values) that implicitly or explicitly include the sensitive data node.
データモデルは、異なるデータ構造からの値を公開外部キー（例えば、陽leafref）を含んでいてもよいです。管理者は、leafrefのノードが含まれている機密データモデルを意識する必要があります。これは、すべてのleafrefが暗黙的または明示的に機密データノードを含む機密データ（すなわち、「パスSTMT」値）で「点」というオブジェクトを見つけることを伴います。
It is beyond the scope of this document to define access control enforcement procedures for underlying device instrumentation that may exist to support the NETCONF server operation. An administrator can identify each protocol operation that the server provides and decide if it needs any access control applied to it.
これは、NETCONFサーバの操作をサポートするために存在する可能性が根底にあるデバイスの計測のためのアクセス制御執行手続きを定義するには、この文書の範囲外です。管理者は、サーバが提供する各プロトコルの動作を特定し、それに適用される任意のアクセス制御を必要とするかどうかを判断することができます。
This document incorporates the optional use of a recovery session mechanism, which can be used to bypass access control enforcement in emergencies, such as NACM configuration errors that disable all access to the server. The configuration and identification of such a recovery session mechanism are implementation-specific and outside the scope of this document. An administrator needs to be aware of any recovery session mechanisms available on the device and make sure they are used appropriately.
この文書では、サーバーへのすべてのアクセスを無効にNACM構成エラーなどの緊急事態、アクセス制御の適用をバイパスするために使用することができ、回復セッション機構の任意の使用が組み込まれています。このような回復セッション機構の構成および識別は、実装固有の及び本文書の範囲外です。管理者は、デバイスで使用可能なすべてのリカバリ・セッション・メカニズムを認識し、それらが適切に使用されていることを確認する必要があります。
It is possible for a session to disrupt configuration management, even without any write access to the configuration, by locking the datastore. This may be done to ensure all or part of the configuration remains stable while it is being retrieved, or it may be done as a "denial-of-service" attack. There is no way for the server to know the difference. An administrator may wish to restrict "exec" access to the following protocol operations: o <lock>
セッションは、データストアをロックすることにより、でもコンフィギュレーションへの書き込みアクセスせずに、構成管理を混乱することが可能です。これは、取得されている、またはそれは「サービス拒否」攻撃のように行うことができるが構成の全部または一部が安定したまま確実にするために行われてもよいです。サーバーが違いを知るための方法はありません。管理者は、次のプロトコル・オペレーションに「幹部」のアクセスを制限したい場合があります。o <ロック>
o <unlock>
O <ロック解除>
o <partial-lock>
O <パーシャル・ロック>
o <partial-unlock>
O <部分的なロック解除>
Designers need to clearly identify any sensitive data, notifications, or protocol operations defined within a YANG module. For such definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" statement ought to be present, in addition to a clear description of the security risks.
設計者は、明らかにYANGモジュール内で定義された機密データ、通知、またはプロトコルの動作を特定する必要があります。そのような定義については、「nacm：デフォルト-拒否 - 書き込み」または「nacm：デフォルト-拒否 - すべての」文はセキュリティリスクの明確な記述に加えて、存在するはずです。
Protocol operations need to be properly documented by the data model designer, so it is clear to administrators what data nodes (if any) are affected by the protocol operation and what information (if any) is returned in the <rpc-reply> message.
プロトコル動作が正しくデータモデル設計者によって文書化される必要があるので、何のデータノード（もしあれば）プロトコルの動作とどのような情報（もしあれば）によって影響を受ける<RPC返信>メッセージに返され、管理者には明らかです。
Data models ought to be designed so that different access levels for input parameters to protocol operations are not required. Use of generic protocol operations should be avoided, and if different access levels are needed, separate protocol operations should be defined instead.
データモデルは、プロトコル操作の入力パラメータの異なるアクセスレベルが必要とされないように設計されるべきです。一般的なプロトコル動作の使用は避けるべきである、と異なるアクセスレベルが必要な場合は、別のプロトコル動作が代わりに定義する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277]チザム、S.およびH.トレビノ、 "NETCONFイベント通知"、RFC 5277、2008年7月。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M.、 "YANG - ネットワーク構成プロトコルのためのデータモデリング言語（NETCONF）"、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J.、 "共通YANGデータ型"、RFC 6021、2010年10月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]エンス、R.、Bjorklund、M.、Schoenwaelder、J.、およびA. Bierman、 "ネットワーク構成プロトコル（NETCONF）"、RFC 6241、2011年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009.
[RFC5607]ネルソン、D.とG.ウェーバー、 "リモート認証ダイヤルインユーザーサービス（RADIUS）ネットワークアクセスサーバ（NAS）管理のための許可"、RFC 5607、2009年7月。
Appendix A. Usage Examples
付録A.使用例
The following XML snippets are provided as examples only, to demonstrate how NACM can be configured to perform some access control tasks.
次のXMLスニペットはNACMは、いくつかのアクセス制御タスクを実行するように構成することができる方法を示すために、例としてのみ提供されています。
A.1. <groups> Example
A.1。 <グループ>の例
There needs to be at least one <group> entry in order for any of the access control rules to be useful.
少なくとも一つの<グループ>のアクセス制御ルールのいずれかが有用であるためにはエントリーが必要です。
The following XML shows arbitrary groups and is not intended to represent any particular use case.
次のXMLは、任意のグループを示し、任意の特定のユースケースを表すことを意図するものではありません。
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <groups> <group> <name>admin</name> <user-name>admin</user-name> <user-name>andy</user-name> </group>
<nacmのxmlns = "壷：IETF：のparams：XML：NS：ヤン：IETF-NETCONF-ACM"> <グループ> <グループ> <名前>管理者</名前> <ユーザー名>管理者</ユーザー名> <ユーザー名>アンディ</ユーザー名> </グループ>
<group>
<name>limited</name>
<user-name>wilma</user-name>
<user-name>bam-bam</user-name>
</group>
<group> <name>guest</name> <user-name>guest</user-name> <user-name>guest@example.com</user-name> </group> </groups> </nacm>
<グループ> <名前>ゲスト</名前> <ユーザ名>ゲスト</ユーザー名> <ユーザー名> guest@example.com </ユーザ名> </グループ> </グループ> </ nacm >
This example shows three groups:
この例では、3つのグループを示しています。
admin: The "admin" group contains two users named "admin" and "andy".
管理者：「管理者」グループは「管理者」と「アンディ」という名前の2人のユーザーが含まれています。
limited: The "limited" group contains two users named "wilma" and "bam-bam".
限られた：「限られた」基は「ウィルマ」と「BAM-BAM」という名前の2人のユーザーが含まれています。
guest: The "guest" group contains two users named "guest" and "guest@example.com".
ゲスト：「ゲスト」グループは「ゲスト」と「guest@example.com」という名前の2人のユーザーが含まれています。
A.2. Module Rule Example
A.2。モジュールルールの例
Module rules are used to control access to all the content defined in a specific module. A module rule has the <module-name> leaf set, but no case in the "rule-type" choice.
モジュール規則は、特定のモジュールに定義されているすべてのコンテンツへのアクセスを制御するために使用されます。モジュール規則は、<モジュール名>葉のセットが、「ルール・タイプ」選択の無い場合があります。
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <rule-list> <name>guest-acl</name> <group>guest</group>
<nacmのxmlns = "壷：IETF：のparams：XML：NS：ヤン：IETF-NETCONF-ACM"> <ルール・リスト> <名前>ゲスト-ACL </名前> <グループ>ゲスト</グループ>
<rule> <name>deny-ncm</name> <module-name>ietf-netconf-monitoring</module-name> <access-operations>*</access-operations> <action>deny</action> <comment> Do not allow guests any access to the NETCONF monitoring information. </comment> </rule> </rule-list>
<ルール> <名前>拒否-NCM </名前> <モジュール名> IETF-NETCONF監視</モジュール名> <アクセス動作> * </アクセス動作> <動作> </アクション> <拒否コメントは>お客様にNETCONFモニタリング情報へのアクセスを許可しないでください。 </コメント> </ルール> </ルールリスト>
<rule-list> <name>limited-acl</name> <group>limited</group>
<ルールリスト> <名前>限ら-ACL </名前> <グループ>制限</グループ>
<rule> <name>permit-ncm</name> <module-name>ietf-netconf-monitoring</module-name> <access-operations>read</access-operations> <action>permit</action> <comment> Allow read access to the NETCONF monitoring information. </comment> </rule> <rule> <name>permit-exec</name> <module-name>*</module-name> <access-operations>exec</access-operations> <action>permit</action> <comment> Allow invocation of the supported server operations. </comment> </rule> </rule-list>
<ルール> <名前>許可-NCM </名前> <モジュール名> IETF-NETCONF監視</モジュール名> <アクセス・操作>読み込み</アクセス・オペレーション> <アクション>許可</アクション> < >コメントNETCONFモニタリング情報への読み取りアクセスを許可します。 </コメント> </ルール> <ルール> <名前>許可-のexec </名前> <モジュール名> * </モジュール名> <アクセス・操作> execの</アクセス・オペレーション> <アクション>許可< /アクション> <コメント>サポートされているサーバー操作の呼び出しを許可します。 </コメント> </ルール> </ルールリスト>
<rule-list> <name>admin-acl</name> <group>admin</group>
<ルールリスト> <名前>管理者-ACL </名前> <グループ>管理者</グループ>
<rule> <name>permit-all</name> <module-name>*</module-name> <access-operations>*</access-operations> <action>permit</action> <comment> Allow the admin group complete access to all operations and data. </comment> </rule> </rule-list> </nacm>
<ルール> <名前>許可-すべての</名前> <モジュール名> * </モジュール名> <アクセス・操作> * </アクセス・オペレーション> <アクション>許可</アクション> <コメント>許可すべての操作とデータへのadminグループの完全なアクセス。 </コメント> </ルール> </ルール・リスト> </ nacm>
This example shows four module rules:
この例では、4つのモジュールのルールを示しています。
deny-ncm: This rule prevents the "guest" group from reading any monitoring information in the "ietf-netconf-monitoring" YANG module.
拒否-NCM：このルールは、「IETF-NETCONF監視」YANGモジュール内の任意の監視情報を読んでから、「ゲスト」グループを防ぎます。
permit-ncm: This rule allows the "limited" group to read the "ietf-netconf-monitoring" YANG module.
許可-NCM：このルールは、「限定された」グループ「は、IETF-NETCONF監視」YANGモジュールを読み込むことができます。
permit-exec: This rule allows the "limited" group to invoke any protocol operation supported by the server.
許可-EXEC：このルールは、「限られた」グループがサーバーでサポートされている任意のプロトコルの動作を呼び出すことができます。
permit-all: This rule allows the "admin" group complete access to all content in the server. No subsequent rule will match for the "admin" group because of this module rule.
許可-すべて：このルールは、「管理者」グループには、サーバー内のすべてのコンテンツへの完全なアクセスを可能にします。後続のルールがあるため、このモジュールルールの「管理者」グループのために一致しなくなります。
A.3. Protocol Operation Rule Example
A.3。プロトコル動作ルールの例
Protocol operation rules are used to control access to a specific protocol operation.
プロトコルの動作規則は、特定のプロトコルの動作へのアクセスを制御するために使用されます。
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <rule-list> <name>guest-limited-acl</name> <group>limited</group> <group>guest</group>
<nacmのxmlns = "壷：IETF：のparams：XML：NS：ヤン：IETF-NETCONF-ACM"> <ルール・リスト> <名前>ゲスト限定-ACL </名前> <グループ>制限</グループ> <グループ>ゲスト</グループ>
<rule>
<name>deny-kill-session</name>
<module-name>ietf-netconf</module-name>
<rpc-name>kill-session</rpc-name>
<access-operations>exec</access-operations> <action>deny</action> <comment> Do not allow the limited or guest group to kill another session. </comment> </rule> <rule> <name>deny-delete-config</name> <module-name>ietf-netconf</module-name> <rpc-name>delete-config</rpc-name> <access-operations>exec</access-operations> <action>deny</action> <comment> Do not allow limited or guest group to delete any configurations. </comment> </rule> </rule-list>
<アクセス・操作> execの</アクセス・オペレーション> <アクション> </アクション> <コメント>否定する別のセッションを殺すために制限されたり、ゲストのグループを許可しないでください。 </コメント> </ルール> <ルール> <名前>拒否を削除-config設定</名前> <モジュール名> IETF-NETCONF </モジュール名> <RPC-名>を削除-config設定</ RPC-名> <アクセス・操作> execの</アクセス・オペレーション> <アクション> </アクション> <コメント>を否定する任意の設定を削除するには、限られたまたはゲストグループを許可しないでください。 </コメント> </ルール> </ルールリスト>
<rule-list> <name>limited-acl</name> <group>limited</group>
<ルールリスト> <名前>限ら-ACL </名前> <グループ>制限</グループ>
<rule> <name>permit-edit-config</name> <module-name>ietf-netconf</module-name> <rpc-name>edit-config</rpc-name> <access-operations>exec</access-operations> <action>permit</action> <comment> Allow the limited group to edit the configuration. </comment> </rule> </rule-list>
<ルール> <名前>許可証編集-config設定</名前> <モジュール名> IETF-NETCONF </モジュール名> <RPC-name>の編集設定</ RPC-名> <アクセス・操作> execの< /アクセス・オペレーション> <アクション>許可</アクション> <コメント>限られたグループは、設定を編集できるようにします。 </コメント> </ルール> </ルールリスト>
</nacm>
</ Nacm>
This example shows three protocol operation rules:
この例では、3つのプロトコル動作の規則を示しています。
deny-kill-session: This rule prevents the "limited" or "guest" groups from invoking the NETCONF <kill-session> protocol operation.
拒否殺すセッション：この規則は、NETCONF <殺すセッション>プロトコルの動作を呼び出すことから、「限られた」または「ゲスト」グループを防ぎます。
deny-delete-config: This rule prevents the "limited" or "guest" groups from invoking the NETCONF <delete-config> protocol operation.
拒否-削除-config設定を：このルールは、NETCONF <削除-config>のプロトコル動作を呼び出すことから、「限られた」または「ゲスト」グループを防ぎます。
permit-edit-config: This rule allows the "limited" group to invoke the NETCONF <edit-config> protocol operation. This rule will have no real effect unless the "exec-default" leaf is set to "deny".
許可編集-config設定：この規則は、NETCONF <編集-config>のプロトコルの動作を起動するための「限定」のグループを可能にします。 「execのデフォルト」葉が「拒否」に設定されていない限り、このルールは、本当の効果がありません。
A.4. Data Node Rule Example
A.4。データノードルールの例
Data node rules are used to control access to specific (config and non-config) data nodes within the NETCONF content provided by the server.
データ・ノード・ルールは、サーバが提供するNETCONFコンテンツ内の特定の（configおよび非設定）データノードへのアクセスを制御するために使用されます。
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <rule-list> <name>guest-acl</name> <group>guest</group>
<nacmのxmlns = "壷：IETF：のparams：XML：NS：ヤン：IETF-NETCONF-ACM"> <ルール・リスト> <名前>ゲスト-ACL </名前> <グループ>ゲスト</グループ>
<rule> <name>deny-nacm</name> <path xmlns:n="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> /n:nacm </path> <access-operations>*</access-operations> <action>deny</action> <comment> Deny the guest group any access to the /nacm data. </comment> </rule> </rule-list>
<ルール> <名前>拒否nacm </名前> <パスのxmlns：N = "URN：IETF：paramsは：XML：NS：陽：IETF-NETCONF-ACM"> / N：nacm </ path>の<access-業務> * </アクセス・オペレーション> <アクション>拒否</アクション> <コメント>ゲストグループに/ nacmデータへのアクセスを拒否します。 </コメント> </ルール> </ルールリスト>
<rule-list> <name>limited-acl</name> <group>limited</group>
<ルールリスト> <名前>限ら-ACL </名前> <グループ>制限</グループ>
<rule> <name>permit-acme-config</name> <path xmlns:acme="http://example.com/ns/netconf"> /acme:acme-netconf/acme:config-parameters </path> <access-operations> read create update delete </access-operations> <action>permit</action> <comment> Allow the limited group complete access to the acme NETCONF configuration parameters. Showing long form of 'access-operations' instead of shorthand. </comment> </rule> </rule-list>
<ルール> <名前>許可-ACME-config設定</名前> <パスのxmlns：ACME = "http://example.com/ns/netconf"> / ACME：ACME-NETCONF / ACME：設定パラメータ</パス> <アクセス・操作>コメント>アクメNETCONFの設定パラメータへの制限されたグループの完全なアクセスを許可する<>更新は</アクセス・オペレーション> <アクション>許可</アクションを削除作成、読み取り。 「アクセス・オペレーション」の代わりの速記の長い形式を示します。 </コメント> </ルール> </ルールリスト>
<rule-list> <name>guest-limited-acl</name> <group>guest</group> <group>limited</group>
<ルールリスト> <名前>ゲスト限定-ACL </名前> <グループ>ゲスト</グループ> <グループ>制限</グループ>
<rule> <name>permit-dummy-interface</name> <path xmlns:acme="http://example.com/ns/itf"> /acme:interfaces/acme:interface[acme:name='dummy'] </path> <access-operations>read update</access-operations> <action>permit</action> <comment> Allow the limited and guest groups read and update access to the dummy interface. </comment> </rule> </rule-list>
<ルール> <名前>許可ダミー・インターフェース</名前> <パスのxmlns：ACME = "http://example.com/ns/itf"> / ACME：インターフェイス/ ACME：インタフェース[ACME：NAME = 'ダミー「] </パス> <アクセス・操作>読み更新</アクセス・オペレーション> <アクション>許可</アクション> <コメント>限られたとゲストグループが読ん許可ダミーインターフェイスへのアクセスを更新します。 </コメント> </ルール> </ルールリスト>
<rule-list> <name>admin-acl</name> <group>admin</group> <rule> <name>permit-interface</name> <path xmlns:acme="http://example.com/ns/itf"> /acme:interfaces/acme:interface </path> <access-operations>*</access-operations> <action>permit</action> <comment> Allow admin full access to all acme interfaces. </comment> </rule> </rule-list> </nacm>
<ルールリスト> <名前>管理者-ACL </名前> <グループ>管理者</グループ> <ルール> <名前>許可-インターフェイス</名前> <パスのxmlns：ACME = "http://example.com / "NS / ITF> / ACME：インタフェース/ ACME：インタフェース</ path>の<アクセス・操作> * </アクセス・オペレーション> <アクション>許可</アクション> <コメント>すべてのACMEのインターフェイスへの管理者のフルアクセスを許可します。 </コメント> </ルール> </ルール・リスト> </ nacm>
This example shows four data node rules:
この例では4つのデータノードのルールを示しています。
deny-nacm: This rule denies the "guest" group any access to the <nacm> subtree. Note that the default namespace is only applicable because this subtree is defined in the same namespace as the <data-rule> element.
拒否-nacm：このルールは、「ゲスト」グループに<nacm>サブツリーへのアクセスを拒否します。このサブツリーは、<データ・ルール>要素と同じ名前空間に定義されているため、デフォルトの名前空間のみ適用可能であることに注意してください。
permit-acme-config: This rule gives the "limited" group read-write access to the acme <config-parameters>.
許可-ACME-config設定：このルールは、「限られた」グループアクメへの読み書きアクセスの<config-パラメータ>を与えます。
permit-dummy-interface: This rule gives the "limited" and "guest" groups read-update access to the acme <interface> entry named "dummy". This entry cannot be created or deleted by these groups, just altered.
許可-ダミーインターフェース：この規則は、「限定」を与え、「ゲスト」グループは、読み取り、更新、「ダミー」という名前のACME <インターフェース>エントリへのアクセスを。このエントリは、単に変更され、これらのグループによって作成または削除することはできません。
permit-interface: This rule gives the "admin" group read-write access to all acme <interface> entries.
許可インターフェイス：このルールは、「管理者」グループのすべてのACMEの<interface>のエントリへの読み書きアクセスを提供します。
A.5. Notification Rule Example
A.5。通知ルールの例
Notification rules are used to control access to a specific notification event type.
通知ルールは、特定の通知イベントタイプへのアクセスを制御するために使用されています。
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <rule-list> <name>sys-acl</name> <group>limited</group> <group>guest</group>
<nacmのxmlns = "壷：IETF：のparams：XML：NS：ヤン：IETF-NETCONF-ACM"> <ルール・リスト> <名前>のsys-ACL </名前> <グループ>制限</グループ> <グループ>ゲスト</グループ>
<rule> <name>deny-config-change</name> <module-name>acme-system</module-name> <notification-name>sys-config-change</notification-name> <access-operations>read</access-operations> <action>deny</action> <comment> Do not allow the guest or limited groups to receive config change events. </comment> </rule> </rule-list> </nacm>
<ルール> <名前>拒否設定変更</名前> <モジュール名> ACMEシステム</モジュール名> <通知名> SYS-CONFIG-変更</通知名> <アクセス動作>ゲストまたは制限されたグループは、設定変更イベントを受け取ることはできません。</アクセス・オペレーション> <アクション>拒否</アクション> <コメント>お読みください。 </コメント> </ルール> </ルール・リスト> </ nacm>
This example shows one notification rule:
この例では、1つの通知ルールを示しています。
deny-config-change: This rule prevents the "limited" or "guest" groups from receiving the acme <sys-config-change> event type.
拒否設定変更を：このルールは、ACMEは<sys-config設定変更>イベントタイプを受けるから、「限られた」または「ゲスト」グループを防ぎます。
Authors' Addresses
著者のアドレス
Andy Bierman YumaWorks
アンディBierman YumaWorks
EMail: andy@yumaworks.com
メールアドレス：andy@yumaworks.com
Martin Bjorklund Tail-f Systems
マーティンBjorklundテール-Fシステム
EMail: mbj@tail-f.com
メールアドレス：mbj@tail-f.com