[要約] RFC 8341は、ネットワーク構成アクセス制御モデルに関する標準化ドキュメントです。その目的は、ネットワーク機器へのアクセス制御を効果的に管理するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) A. Bierman
Request for Comments: 8341 YumaWorks
STD: 91 M. Bjorklund
Obsoletes: 6536 Tail-f Systems
Category: Standards Track March 2018
ISSN: 2070-1721
Network Configuration Access Control Model
ネットワーク構成アクセス制御モデル
Abstract
概要
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol 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 or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.
ネットワーク構成プロトコル（NETCONF）またはRESTCONFプロトコルで使用するネットワーク構成インターフェースの標準化には、人間の使いやすさとマルチベンダーの相互運用性を促進する構造化された安全な動作環境が必要です。特定のユーザーのNETCONFまたはRESTCONFプロトコルアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前設定されたサブセットに制限するための標準的なメカニズムが必要です。このドキュメントでは、そのようなアクセス制御モデルを定義しています。
This document obsoletes RFC 6536.
このドキュメントはRFC 6536を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8341.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8341で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Changes since RFC 6536 .....................................6
2. Access Control Design Objectives ................................7
2.1. Access Control Points ......................................7
2.2. Simplicity .................................................8
2.3. Procedural Interface .......................................8
2.4. Datastore Access ...........................................8
2.5. Users and Groups ...........................................8
2.6. Maintenance ................................................9
2.7. Configuration Capabilities .................................9
2.8. Identifying Security-Sensitive Content .....................9
3. NETCONF Access Control Model (NACM) ............................10
3.1. Overview ..................................................10
3.1.1. Features ...........................................10
3.1.2. External Dependencies ..............................11
3.1.3. Message Processing Model ...........................11
3.2. Datastore Access ..........................................14
3.2.1. Mapping New Datastores to NACM .....................14
3.2.2. Access Rights ......................................14
3.2.3. RESTCONF Methods ...................................15
3.2.4. <get> and <get-config> Operations ..................16
3.2.5. <edit-config> Operation ............................16
3.2.6. <copy-config> Operation ............................18
3.2.7. <delete-config> Operation ..........................18
3.2.8. <commit> Operation .................................19
3.2.9. <discard-changes> Operation ........................19
3.2.10. <kill-session> Operation ..........................19
3.3. Model Components ..........................................19
3.3.1. Users ..............................................19
3.3.2. Groups .............................................20
3.3.3. Emergency Recovery Session .........................20
3.3.4. Global Enforcement Controls ........................20
3.3.4.1. enable-nacm Switch ........................20
3.3.4.2. read-default Switch .......................20
3.3.4.3. write-default Switch ......................21
3.3.4.4. exec-default Switch .......................21
3.3.4.5. enable-external-groups Switch .............22
3.3.5. Access Control Rules ...............................22
3.4. Access Control Enforcement Procedures .....................22
3.4.1. Initial Operation ..................................23
3.4.2. Session Establishment ..............................23
3.4.3. "access-denied" Error Handling .....................23
3.4.4. Incoming RPC Message Validation ....................24
3.4.5. Data Node Access Validation ........................26
3.4.6. Outgoing <notification> Authorization ..............29
3.5. Data Model Definitions ....................................31
3.5.1. Data Organization ..................................31
3.5.2. YANG Module ........................................32
4. IANA Considerations ............................................42
5. Security Considerations ........................................42
5.1. NACM Configuration and Monitoring Considerations ..........43
5.2. General Configuration Issues ..............................45
5.3. Data Model Design Considerations ..........................47
6. References .....................................................47
6.1. Normative References ......................................47
6.2. Informative References ....................................49
Appendix A. Usage Examples ........................................50
A.1. <groups> Example ...........................................50
A.2. Module Rule Example ........................................51
A.3. Protocol Operation Rule Example ............................53
A.4. Data Node Rule Example .....................................55
A.5. Notification Rule Example ..................................57
Authors' Addresses ................................................58
The Network Configuration Protocol (NETCONF) and the RESTCONF protocol do not provide any standard mechanisms to restrict the protocol operations and content that each user is authorized to access.
ネットワーク構成プロトコル（NETCONF）とRESTCONFプロトコルは、各ユーザーがアクセスを許可されているプロトコル操作とコンテンツを制限する標準的なメカニズムを提供しません。
There is a need for interoperable management of the controlled access to administrator-selected portions of the available NETCONF or RESTCONF content within a particular server.
特定のサーバー内の利用可能なNETCONFまたはRESTCONFコンテンツの管理者が選択した部分への制御されたアクセスの相互運用可能な管理が必要です。
This document addresses access control mechanisms for the Operations and Content layers of NETCONF, as defined in [RFC6241]; and RESTCONF, as defined in [RFC8040]. It contains three main sections:
このドキュメントは、[RFC6241]で定義されているように、NETCONFの操作層とコンテンツ層のアクセス制御メカニズムを扱います。および[RFC8040]で定義されているRESTCONF。 3つの主要なセクションが含まれています。
1. Access Control Design Objectives
1. アクセス制御の設計目標
2. NETCONF Access Control Model (NACM)
2. NETCONFアクセス制御モデル（NACM）
3. YANG Data Model (ietf-netconf-acm.yang)
3. THATデータモデル（ietf-netconf-acm.yang）
YANG version 1.1 [RFC7950] adds two new constructs that need special access control handling. The "action" statement is similar to the "rpc" statement, except that it is located within a data node. The "notification" statement can also be located within a data node.
YANGバージョン1.1 [RFC7950]では、特別なアクセス制御処理を必要とする2つの新しい構成が追加されています。 「action」ステートメントは「rpc」ステートメントに似ていますが、データノード内にある点が異なります。 「通知」ステートメントは、データノード内に配置することもできます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following terms are defined in [RFC8342] and are not redefined here:
以下の用語は[RFC8342]で定義されており、ここでは再定義されません。
o datastore
o データストア
o configuration datastore
o 構成データストア
o conventional configuration datastore
o 従来の構成データストア
o candidate configuration datastore
o 候補構成データストア
o running configuration datastore
o 実行構成データストア
o startup configuration datastore o operational state datastore
oスタートアップ構成データストアo動作状態データストア
o client
o クライアント
o server
o サーバ
The following terms are defined in [RFC6241] and are not redefined here:
以下の用語は[RFC6241]で定義されており、ここでは再定義されません。
o protocol operation
o プロトコル操作
o session
o セッション
o user
o ユーザー
The following terms are defined in [RFC7950] and are not redefined here:
以下の用語は[RFC7950]で定義されており、ここでは再定義されません。
o action
o アクション
o data node
o だた ので
o data definition statement
o データ定義ステートメント
The following terms are defined in [RFC8040] and are not redefined here:
以下の用語は[RFC8040]で定義されており、ここでは再定義されません。
o data resource
o データリソース
o datastore resource
o データストアリソース
o operation resource
o 運用リソース
o target resource
o ターゲットリソース
The following term is defined in [RFC7230] and is not redefined here:
次の用語は[RFC7230]で定義されており、ここでは再定義されていません。
o request URI
o リクエストURI
The following terms are used throughout this document:
このドキュメントでは、次の用語が使用されています。
access control: A security feature provided by the server that allows an administrator to restrict access to a subset of all protocol operations and data, based on various criteria.
アクセス制御：管理者がさまざまな基準に基づいて、すべてのプロトコル操作とデータのサブセットへのアクセスを制限できるようにするサーバーによって提供されるセキュリティ機能。
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 access operation will be permitted or denied.
アクセス制御規則：特定のアクセス操作が許可されるか拒否されるかを決定するために使用される基準。
access operation: How a request attempts to access a conceptual object. One of "none", "read", "create", "delete", "update", or "execute".
アクセス操作：リクエストが概念オブジェクトにアクセスする方法。 「なし」、「読み取り」、「作成」、「削除」、「更新」、または「実行」のいずれか。
data node hierarchy: The hierarchy of data nodes that identifies the specific "action" or "notification" node in the datastore.
データノード階層：データストア内の特定の「アクション」または「通知」ノードを識別するデータノードの階層。
recovery session: A special administrative session that is given unlimited NETCONF access and is exempt from all access control enforcement. The mechanism or mechanisms used by a server to control and identify whether or not a session is a recovery session are implementation specific and are outside the scope of this document.
リカバリー・セッション：無制限のNETCONFアクセスが与えられ、すべてのアクセス制御の実施から免除される特別な管理セッション。セッションが回復セッションであるかどうかを制御および識別するためにサーバーが使用するメカニズムは実装固有であり、このドキュメントの範囲外です。
write access: A shorthand for the "create", "delete", and "update" access operations.
書き込みアクセス：「作成」、「削除」、および「更新」アクセス操作の省略形。
The NACM procedures and data model have been updated to support new data modeling capabilities in version 1.1 of the YANG data modeling language. The "action" and "notification" statements can be used within data nodes to define data-model-specific operations and notifications.
NACMの手順とデータモデルが更新され、YANGデータモデリング言語のバージョン1.1の新しいデータモデリング機能がサポートされるようになりました。 「アクション」および「通知」ステートメントをデータノード内で使用して、データモデル固有の操作と通知を定義できます。
An important use case for these new YANG statements is the increased access control granularity that can be achieved over top-level "rpc" and "notification" statements. The new "action" and "notification" statements are used within data nodes, and access to the action or notification can be restricted to specific instances of these data nodes.
これらの新しいYANGステートメントの重要な使用例は、トップレベルの「rpc」および「通知」ステートメントで達成できるアクセス制御の細分性の向上です。新しい「アクション」および「通知」ステートメントがデータノード内で使用され、アクションまたは通知へのアクセスをこれらのデータノードの特定のインスタンスに制限できます。
Support for the RESTCONF protocol has been added. The RESTCONF operations are similar to the NETCONF operations, so a simple mapping to the existing NACM procedures and data model is possible.
RESTCONFプロトコルのサポートが追加されました。 RESTCONF操作はNETCONF操作に似ているため、既存のNACMプロシージャとデータモデルへの簡単なマッピングが可能です。
The data node access behavior for path matches has been clarified to also include matching descendant nodes of the specified path.
パス一致のデータノードアクセス動作が明確になり、指定したパスの一致する子孫ノードも含まれるようになりました。
The <edit-config> operation access rights behavior has been clarified to indicate that write access is not required for data nodes that are implicitly modified through side effects (such as the evaluation of YANG when-stmts, or data nodes implicitly deleted when creating a data node under a different branch under a YANG choice-stmt).
<edit-config>操作のアクセス権の動作が明確になり、副作用によって暗黙的に変更されたデータノード（YANG when-stmtsの評価、または作成時に暗黙的に削除されたデータノードなど）には書き込みアクセスが不要であることを示しますYANG choice-stmtの下の別のブランチの下のデータノード）。
The Security Considerations section has been updated to comply with the "YANG module security guidelines" [YANG-SEC]. Note that the YANG module in this document does not define any RPC operations.
「セキュリティに関する考慮事項」セクションが更新され、「YANGモジュールのセキュリティガイドライン」[YANG-SEC]に準拠するようになりました。このドキュメントのYANGモジュールは、RPC操作を定義していないことに注意してください。
This section documents the design objectives for the NETCONF access control model presented in Section 3.
このセクションでは、セクション3で示したNETCONFアクセスコントロールモデルの設計目標について説明します。
NETCONF allows server implementers to add new custom protocol operations, and the YANG data modeling language supports this feature. These operations can be defined in standard or proprietary YANG modules.
NETCONFにより、サーバー実装者は新しいカスタムプロトコル操作を追加でき、YANGデータモデリング言語はこの機能をサポートします。これらの操作は、標準または独自のYANGモジュールで定義できます。
It is not possible to design an ACM for NETCONF that only focuses on a static set of standard protocol operations defined by NETCONF itself, 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自体によって定義された標準プロトコル操作の静的セットにのみ焦点を当てたNETCONFのACMを設計することはできません。任意のプロトコル操作についてはほとんど想定できないため、NETCONFアーキテクチャサーバーコンポーネントは、3つの概念的な制御点で保護する必要があります。
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.
notification：特定の通知イベントタイプを受信する権限。
+-------------+ +-------------+
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. 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 that may require additional expertise.
複雑なACMは使いづらいため、あまり普及しないのではないかと懸念されています。アクセス制御システムの構成は、できるだけ単純である必要があります。シンプルで一般的なタスクは、設定が簡単で、専門知識やドメイン固有の知識はほとんど必要ありません。複雑なタスクは、追加の専門知識を必要とする可能性がある追加のメカニズムを使用して可能です。
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 datastore access.
アクセス制御は、データストアアクセスの完全な制御を許可しながら、小さくて使い慣れた一連の権限で定義する必要があります。
NETCONF uses a Remote Procedure Call (RPC) model and an extensible set of protocol operations. Access control for any possible protocol operation is necessary.
NETCONFは、リモートプロシージャコール（RPC）モデルと拡張可能なプロトコル操作のセットを使用します。可能なプロトコル操作のアクセス制御が必要です。
It is necessary to control access to specific nodes and subtrees within the datastore, regardless of which protocol operation -- standard or proprietary -- was used to access the datastore.
データストアへのアクセスに使用されたプロトコル操作（標準または専用）に関係なく、データストア内の特定のノードおよびサブツリーへのアクセスを制御する必要があります。
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 transport layer and RADIUS performs authentication and service authorization at the same time, the underlying transport protocol 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]などの中央サーバーに委任できる必要があります。認証はトランスポート層によって実行され、RADIUSは認証とサービス承認を同時に実行するため、基になるトランスポートプロトコルは、ユーザーに関連付けられた一連のグループ名をサーバーに報告できる必要があります。管理者は、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の動作のすべての側面を簡単に管理できるようにするには、適切な構成および監視メカニズムが必要です。 <edit-config>プロトコル操作での使用に適した標準データモデルは、この目的で使用できる必要があります。
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 one of the biggest concerns during deployment, is the identification of security-sensitive content. This applies to protocol operations in NETCONF, not just data and notifications.
データモデルドキュメントの最も重要な側面の1つであり、展開時の最大の懸念の1つは、セキュリティ上重要なコンテンツの識別です。これは、データと通知だけでなく、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.
o 各サーバーのACMは、セキュリティリスクを軽減するように構成する必要があります。たとえば、「セキュリティに関する考慮事項」セクションで特定された特定のデータの読み取りまたは書き込みに特権アクセスが必要です。
o If the ACM is not preconfigured, 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.
o ACMが事前構成されていない場合、新しいデータモデルが読み込まれてから、そのデータモデルの新しいアクセス制御ルールが構成、有効化、およびデバッグされるまでの間に、脆弱性の時間枠が存在します。
Often, the administrator just wants to disable default access to the secure content so that 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 content that 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.
データモデルの設計者は、機械で読み取り可能なステートメントを使用して、デフォルトで保護する必要のあるコンテンツを識別できる必要があります。これにより、クライアントとサーバーのツールは、ユーザーが要求されたアクセス操作の実行を明示的に許可されていない限り、機密データへのアクセスを拒否することにより、データモデル固有のセキュリティリスクを自動的に識別できます。
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 RPC, action, data, and notification access is provided.
o RPC、アクション、データ、および通知アクセスの独立した制御が提供されます。
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., a "nacm:default-deny-write" statement) allows default security modes to automatically exclude sensitive data.
o YANGセキュリティタグ付け（たとえば、「nacm：default-deny-write」ステートメント）のサポートにより、デフォルトのセキュリティモードで機密データを自動的に除外できます。
o Separate default access modes for read, write, and execute permissions are provided.
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 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インスタンス識別子を使用して、特定のデータノードのアクセス制御ルールを構成します。
NETCONF [RFC6241] and RESTCONF [RFC8040] are used for network management purposes within this document.
NETCONF [RFC6241]およびRESTCONF [RFC8040]は、このドキュメント内のネットワーク管理目的で使用されます。
The YANG data modeling language [RFC7950] is used to define the data models for use with NETCONF or RESTCONF. YANG is also used to define the data model in this document.
YANGデータモデリング言語[RFC7950]は、NETCONFまたはRESTCONFで使用するデータモデルを定義するために使用されます。このドキュメントでは、YANGを使用してデータモデルを定義しています。
The following diagram shows the conceptual message flow model, including the points at which access control is applied during NETCONF message processing.
次の図は、NETCONFメッセージ処理中にアクセス制御が適用されるポイントを含む、概念的なメッセージフローモデルを示しています。
RESTCONF operations are mapped to the access control model based on the HTTP method and resource class used in the operation. For example, a POST method on a data resource is considered "write data node" access, but a POST method on an operation resource is considered "operation" access.
RESTCONF操作は、操作で使用されるHTTPメソッドとリソースクラスに基づいてアクセス制御モデルにマップされます。たとえば、データリソースのPOSTメソッドは「データノードの書き込み」アクセスと見なされますが、操作リソースのPOSTメソッドは「操作」アクセスと見なされます。
The new "pre-read data node acc. ctl" boxes in the diagram below refer to group read access as it relates to data node ancestors of an action or notification. As an example, if an action is defined as /interfaces/interface/reset-interface, the group must be authorized to (1) read /interfaces and /interfaces/interface and (2) execute on /interfaces/interface/reset-interface.
以下の図の新しい「事前読み取りデータノードacc。ctl」ボックスは、アクションまたは通知のデータノードの祖先に関連するため、グループ読み取りアクセスを指します。例として、アクションが/ interfaces / interface / reset-interfaceとして定義されている場合、グループには、（1）/ interfacesおよび/ interfaces / interfaceの読み取り、および（2）/ interfaces / interface / reset-interfaceでの実行を許可する必要があります。 。
+-------------------------+
| session |
| (username) |
+-------------------------+
| ^
V |
+--------------+ +---------------+
| message | | message |
| dispatcher | | generator |
+--------------+ +---------------+
| | ^ ^
| V | |
| +=============+ | |
| | pre-read | | |
| | data node | | |
| | acc. ctl | | |
| +=============+ | |
| | | |
V V | |
+===========+ +-------------+ +----------------+
| operation |---> | reply | | <notification> |
| acc. ctl | | generator | | generator |
+===========+ +-------------+ +----------------+
| ^ ^ ^
V +------+ | |
+-----------+ | +=============+ +================+
| operation | | | read | | <notification> |
| processor |-+ | data node | | access ctl |
| | | acc. ctl | | |
+-----------+ +=============+ +================+
| | ^ ^ ^
V +----------------+ | | |
+===========+ | | | +============+
| write | | | | | pre-read |
| data node | | | | | data node |
| acc. ctl | -----------+ | | | | 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>メッセージ（<close-session>を除く）にアクセス制御が個別に適用されます。
o If the <action> operation defined in [RFC7950] is invoked, then read access is required for all instances in the hierarchy of data nodes that identifies the specific action in the datastore, and execute access is required for the action node. If the user is not authorized to read all the specified data nodes and execute the action, then the request is rejected with an "access-denied" error.
o [RFC7950]で定義されている<action>オペレーションが呼び出されると、データストアの特定のアクションを識別するデータノードの階層内のすべてのインスタンスに読み取りアクセスが必要であり、アクションノードには実行アクセスが必要です。ユーザーが指定されたすべてのデータノードの読み取りとアクションの実行を許可されていない場合、リクエストは「アクセス拒否」エラーで拒否されます。
o Otherwise, if the user is not authorized to execute the specified protocol operation, then the request is rejected with an "access-denied" error.
o それ以外の場合、指定されたプロトコル操作を実行する権限がユーザーにない場合、要求は「アクセス拒否」エラーで拒否されます。
o If a datastore is accessed by the protocol operation, then the server checks to see if the client is authorized to access the nodes in the datastore. If the user is not authorized to perform the requested access operation on the requested data, then the request is rejected with an "access-denied" error.
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 サーバー計装は、特定のサブスクリプションの通知を生成します。
o If the "notification" statement is specified within a data subtree, as specified in [RFC7950], then read access is required for all instances in the hierarchy of data nodes that identifies the specific notification in the datastore, and read access is required for the notification node. If the user is not authorized to read all the specified data nodes and the notification node, then the notification is dropped for that subscription.
o [notification]ステートメントが[RFC7950]で指定されているようにデータサブツリー内で指定されている場合、データストア内の特定の通知を識別するデータノードの階層内のすべてのインスタンスに読み取りアクセスが必要です。通知ノード。ユーザーが指定されたすべてのデータノードと通知ノードの読み取りを許可されていない場合、そのサブスクリプションの通知は削除されます。
o If the "notification" statement is a top-level statement, 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 that support the NACM -- for example, the candidate configuration datastore or the running configuration datastore.
NACMをサポートするすべてのデータストア（たとえば、候補構成データストアや実行構成データストア）には、同じアクセス制御規則が適用されます。
All conventional configuration datastores and the operational state datastore are controlled by the NACM. Local files, remote files, or datastores accessed via the <url> parameter are not controlled by the NACM.
すべての従来の構成データストアと運用状態データストアは、NACMによって制御されます。 <url>パラメータを介してアクセスされるローカルファイル、リモートファイル、またはデータストアは、NACMによって制御されません。
It is possible that new datastores will be defined over time for use with NETCONF. The NACM MAY be applied to other datastores that have similar access rights as defined in the NACM. To apply the NACM to a new datastore, the new datastore specification needs to define how it maps to the NACM CRUDX (Create, Read, Update, Delete, eXec) access rights. It is possible that only a subset of the NACM access rights would be applicable. For example, only retrieval access control would be needed for a read-only datastore. Operations and access rights not supported by the NACM CRUDX model are outside the scope of this document. A datastore does not need to use the NACM, e.g., the datastore specification defines something else or does not use access control.
NETCONFで使用するために、新しいデータストアが徐々に定義される可能性があります。 NACMは、NACMで定義されているのと同様のアクセス権を持つ他のデータストアに適用される場合があります。 NACMを新しいデータストアに適用するには、新しいデータストア仕様で、NACM CRUDX（作成、読み取り、更新、削除、eXec）アクセス権へのマッピング方法を定義する必要があります。 NACMアクセス権のサブセットのみが適用される可能性があります。たとえば、読み取り専用のデータストアでは、検索アクセス制御のみが必要です。 NACM CRUDXモデルでサポートされていない操作とアクセス権は、このドキュメントの範囲外です。データストアはNACMを使用する必要がありません。たとえば、データストアの仕様は他の何かを定義するか、アクセス制御を使用しません。
A small set of hard-wired datastore access rights is needed to control access to all possible protocol operations, including vendor extensions to the standard protocol operation set.
標準プロトコル操作セットへのベンダー拡張を含む、考えられるすべてのプロトコル操作へのアクセスを制御するには、ハードワイヤードデータストアアクセス権の小さなセットが必要です。
The CRUDX model can support all protocol operations:
CRUDXモデルは、すべてのプロトコル操作をサポートできます。
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 operation.
o eXec：クライアントが操作を実行できるようにします。
The RESTCONF protocol utilizes HTTP methods to perform datastore operations, similar to NETCONF. The NACM procedures were originally written for NETCONF protocol operations, so the RESTCONF methods are mapped to NETCONF operations for the purpose of access control processing. The enforcement procedures described within this document apply to both protocols unless explicitly stated otherwise.
RESTCONFプロトコルは、NETCONFと同様に、HTTPメソッドを使用してデータストア操作を実行します。 NACMプロシージャは元々NETCONFプロトコル操作用に作成されていたため、RESTCONFメソッドはアクセス制御処理の目的でNETCONF操作にマップされます。このドキュメントで説明されている強制手順は、特に明記されていない限り、両方のプロトコルに適用されます。
The request URI needs to be considered when processing RESTCONF requests on data resources:
データリソースでRESTCONFリクエストを処理するときは、リクエストURIを考慮する必要があります。
o For HEAD and GET requests, any data nodes that are ancestor nodes of the target resource are considered to be part of the retrieval request for access control purposes.
o HEADおよびGET要求の場合、ターゲットリソースの祖先ノードであるデータノードは、アクセス制御の目的で取得要求の一部と見なされます。
o For PUT, PATCH, and DELETE requests, any data nodes that are ancestor nodes of the target resource are not considered to be part of the edit request for access control purposes. The access operation for these nodes is considered to be "none". The edit begins at the target resource.
o PUT、PATCH、およびDELETE要求の場合、ターゲットリソースの祖先ノードであるデータノードは、アクセス制御のための編集要求の一部とは見なされません。これらのノードのアクセス操作は「なし」と見なされます。編集はターゲットリソースから始まります。
o For POST requests on data resources, any data nodes that are specified in the request URI, including the target resource, are not considered to be part of the edit request for access control purposes. The access operation for these nodes is considered to be "none". The edit begins at a child node of the target resource, specified in the message body.
o データリソースに対するPOSTリクエストの場合、ターゲットリソースを含む、リクエストURIで指定されたデータノードは、アクセス制御のための編集リクエストの一部とは見なされません。これらのノードのアクセス操作は「なし」と見なされます。編集は、メッセージ本文で指定されたターゲットリソースの子ノードから始まります。
Not all RESTCONF methods are subject to access control. The following table specifies how each method is mapped to NETCONF protocol operations. The value "none" indicates that the NACM is not applied at all to the specific RESTCONF method.
すべてのRESTCONFメソッドがアクセス制御の対象になるわけではありません。次の表は、各メソッドがNETCONFプロトコル操作にどのようにマップされるかを示しています。値「none」は、NACMが特定のRESTCONFメソッドにまったく適用されないことを示します。
+---------+-----------------+---------------------+-----------------+
| Method | Resource class | NETCONF operation | Access |
| | | | operation |
+---------+-----------------+---------------------+-----------------+
| OPTIONS | all | none | none |
| HEAD | all | <get>, <get-config> | read |
| GET | all | <get>, <get-config> | read |
| POST | datastore, data | <edit-config> | create |
| POST | operation | specified operation | execute |
| PUT | data | <edit-config> | create, update |
| PUT | datastore | <copy-config> | update |
| PATCH | data, datastore | <edit-config> | update |
| DELETE | data | <edit-config> | delete |
+---------+-----------------+---------------------+-----------------+
Table 1: Mapping RESTCONF Methods to NETCONF
表1：RESTCONFメソッドのNETCONFへのマッピング
The NACM access rights are not directly coupled to the <get> and <get-config> protocol operations but apply to all <rpc> operations that would result in a "read" access operation to the target datastore. This section describes how these access rights apply to the specific access operations supported by the <get> and <get-config> protocol operations.
NACMアクセス権は、<get>および<get-config>プロトコル操作に直接結合されていませんが、ターゲットデータストアへの「読み取り」アクセス操作になるすべての<rpc>操作に適用されます。このセクションでは、これらのアクセス権が<get>および<get-config>プロトコル操作でサポートされる特定のアクセス操作にどのように適用されるかについて説明します。
Data nodes to which the client does not have read access are silently omitted, along with any descendants, 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 are applied to the subset of nodes that the user is authorized to read, not the entire datastore.
クライアントが読み取りアクセス権を持たないデータノードは、その子孫とともに、<rpc-reply>メッセージから暗黙的に省略されます。これにより、<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アクセス権は、類似していますが、<edit-config>の "operation"属性に直接結合されていません。代わりに、NACMアクセス権は、ターゲットデータストアへの特定のアクセス操作となるすべてのプロトコル操作に適用されます。このセクションでは、これらのアクセス権が<edit-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.
特定のデータノードの有効なアクセス操作が「なし」（つまり、default-operation = "none"）の場合、そのデータノードにはアクセス制御が適用されません。これは、より大きなデータ構造内のサブツリーへのアクセスを許可するために必要です。たとえば、ユーザーは新しい「/ interfaces / interface」リストエントリの作成を許可されているが、その親コンテナ（「/ interfaces」）の作成または削除は許可されていない場合があります。 「/ interfaces」コンテナがターゲットデータストアにすでに存在する場合、「/ interfaces / interface」リストのエントリを編集すると、「/ interfaces」ノードに対して有効な操作は「なし」になります。
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.
「マージ」または「置換」<edit-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.
「マージ」<edit-config>操作にはデータノードが含まれる場合がありますが、データストアに存在する特定の子データノードは含まれません。 「マージ」<edit-config>操作のスコープ内にあるこれらの欠落したデータノードは、サーバーによって無視され、クライアントによるアクセス権を必要としません。
The contents of specific restricted datastore nodes MUST NOT be exposed in any <rpc-error> elements within the reply.
特定の制限されたデータストアノードの内容は、応答内の<rpc-error>要素で公開してはなりません（MUST NOT）。
An <edit-config> operation may cause data nodes to be implicitly created or deleted as an implicit side effect of a requested operation. For example, a YANG when-stmt expression may evaluate to a different result, causing data nodes to be deleted, or created with default values; or if a data node is created under one branch of a YANG choice-stmt, then all data nodes under the other branches are implicitly removed. No NACM access rights are required on any data nodes that are implicitly changed as a side effect of another allowed operation.
<edit-config>操作では、要求された操作の暗黙的な副作用として、データノードが暗黙的に作成または削除される場合があります。たとえば、YANG when-stmt式が異なる結果に評価され、データノードが削除されるか、デフォルト値で作成される場合があります。または、データノードがYANG choice-stmtの1つのブランチの下に作成された場合、他のブランチの下のすべてのデータノードは暗黙的に削除されます。別の許可された操作の副作用として暗黙的に変更されるデータノードでは、NACMアクセス権は必要ありません。
Access control for the <copy-config> protocol operation requires special consideration because the administrator may be replacing the entire target datastore.
管理者がターゲットデータストア全体を置き換える可能性があるため、<copy-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.
<copy-config>プロトコル操作のソースが実行構成データストアであり、ターゲットが起動構成データストアである場合、クライアントに必要なのは、<copy-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 <copy-config>操作のソースがデータストアの場合、クライアントが読み取りアクセス権を持たないデータノードは通知なく省略されます。
o If the target of the <copy-config> operation is a datastore, the client needs access to the modified nodes. Specifically:
o <copy-config>操作のターゲットがデータストアの場合、クライアントは変更されたノードにアクセスする必要があります。具体的には：
* 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.
<delete-config>プロトコル操作へのアクセスは、デフォルトで拒否されます。 「exec-default」リーフは、このプロトコル操作には適用されません。非回復セッションによる呼び出しを許可するには、アクセス制御ルールを明示的に構成する必要があります。
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.
クライアントには、<discard-changes>プロトコル操作を実行する権限のみが必要です。データストアの権限は必要ありません。
The <kill-session> operation does not directly alter a datastore. However, it allows one session to disrupt another session that is editing a datastore.
<kill-session>操作は、データストアを直接変更しません。ただし、1つのセッションがデータストアを編集している別のセッションを中断することを許可します。
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.
<kill-session>プロトコル操作へのアクセスは、デフォルトで拒否されています。 「exec-default」リーフは、このプロトコル操作には適用されません。非回復セッションによる呼び出しを許可するには、アクセス制御ルールを明示的に構成する必要があります。
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. The session is associated with a group (i.e., not with a user).
特定のNETCONFプロトコル操作へのアクセスがセッションに許可されます。セッションはグループに関連付けられています（つまり、ユーザーには関連付けられていません）。
A group is identified by its name. All group names are unique within the server.
グループはその名前で識別されます。すべてのグループ名はサーバー内で一意です。
Access control is applied at the level of groups. A group contains zero or more group members.
アクセス制御はグループのレベルで適用されます。グループには0個以上のグループメンバーが含まれます。
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.
サーバーは、すべてのアクセス制御の実施をバイパスする回復セッションメカニズムをサポートしてもよい（MAY）。これは、初期アクセスを制限し、壊れたアクセス制御構成を修復するのに役立ちます。
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", 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", all access requests are permitted.
すべてのアクセス制御の実施を有効または無効にするためのグローバルな「enable-nacm」オン/オフスイッチが用意されています。このグローバルスイッチが「true」に設定されている場合、すべてのリクエストはアクセスコントロールルールに対してチェックされ、特定のアクセスリクエストを許可するように構成されている場合にのみ許可されます。このグローバルスイッチを「false」に設定すると、すべてのアクセス要求が許可されます。
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", this global switch is relevant if no matching access control rule is found to explicitly permit or deny read access to the requested datastore data or notification event type.
オン/オフの「read-default」スイッチは、返信と通知でデータを受信するためのデフォルトアクセスを有効または無効にするために提供されています。 「enable-nacm」グローバルスイッチが「true」に設定されている場合、要求されたデータストアデータまたは通知イベントタイプへの読み取りアクセスを明示的に許可または拒否する一致するアクセス制御ルールが見つからない場合、このグローバルスイッチが関係します。
When this global switch is set to "permit" and no matching access control rule is found for the datastore read or notification event requested, access is permitted.
このグローバルスイッチが「許可」に設定され、要求されたデータストア読み取りまたは通知イベントに一致するアクセス制御ルールが見つからない場合、アクセスは許可されます。
When this global switch is set to "deny" and no matching access control rule is found for the datastore read or notification event requested, access is denied. This means that the requested data is not sent to the client. See step 11 in Section 3.4.5 for details.
このグローバルスイッチが「拒否」に設定され、要求されたデータストア読み取りまたは通知イベントに一致するアクセス制御ルールが見つからない場合、アクセスは拒否されます。つまり、要求されたデータはクライアントに送信されません。詳細は、3.4.5項の手順11を参照してください。
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", this global switch is relevant if no matching access control rule is found to explicitly permit or deny write access to the requested datastore data.
オン/オフの「デフォルト書き込み」スイッチは、構成データを変更するためのデフォルトアクセスを有効または無効にするために提供されています。 「enable-nacm」グローバルスイッチが「true」に設定されている場合、要求されたデータストアデータへの書き込みアクセスを明示的に許可または拒否する一致するアクセス制御ルールが見つからない場合、このグローバルスイッチが関係します。
When this global switch is set to "permit" and no matching access control rule is found for the datastore write requested, access is permitted.
このグローバルスイッチが「許可」に設定されていて、要求されたデータストア書き込みに一致するアクセス制御ルールが見つからない場合、アクセスは許可されます。
When this global switch is set to "deny" and no matching access control rule is found for the datastore write requested, access is denied. See step 12 in Section 3.4.5 for details.
このグローバルスイッチが「拒否」に設定されていて、要求されたデータストアの書き込みに対して一致するアクセス制御ルールが見つからない場合、アクセスは拒否されます。詳細は、3.4.5項のステップ12を参照してください。
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", 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-default」スイッチが提供されています。 「enable-nacm」グローバルスイッチが「true」に設定されている場合、要求されたNETCONFプロトコル操作へのアクセスを明示的に許可または拒否する一致するアクセスコントロールルールが見つからない場合、このグローバルスイッチが関係します。
When this global switch is set to "permit" and no matching access control rule is found for the NETCONF protocol operation requested, 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, access is denied. See step 12 in Section 3.4.4 and step 13 in Section 3.4.5 for details.
このグローバルスイッチが「拒否」に設定されていて、要求されたNETCONFプロトコル操作に一致するアクセス制御規則が見つからない場合、アクセスは拒否されます。詳細は、3.4.4項のステップ12および3.4.5項のステップ13を参照してください。
When this global switch is set to "true", the group names reported by the transport layer for a session are used together with the locally configured group names to determine the access control rules for the session.
このグローバルスイッチが "true"に設定されている場合、セッションのトランスポート層によって報告されたグループ名は、ローカルに構成されたグループ名と共に使用され、セッションのアクセス制御規則を決定します。
When this switch is set to "false", the group names reported by the transport layer are ignored by the NACM.
このスイッチが「false」に設定されている場合、トランスポート層によって報告されたグループ名はNACMによって無視されます。
There are four types of rules available in the 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 and its descendants, 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 six separate phases that need to be addressed, four of which are related to the NETCONF message processing model (Section 3.1.3):
対処する必要のある6つの個別のフェーズがあり、そのうち4つはNETCONFメッセージ処理モデル（セクション3.1.3）に関連しています。
1. Initial operation
1. 初期運用
2. Session establishment
2. セッションの確立
3. "access-denied" error handling
3. 「アクセス拒否」エラー処理
4. Incoming RPC message validation
4. 着信RPCメッセージの検証
5. Data node access validation
5. データノードアクセスの検証
6. Outgoing <notification> authorization
6. 送信<notification>承認
In addition, the initial startup mode for a NETCONF server, session establishment, and "access-denied" error-handling procedures also need to be considered.
さらに、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 configuration 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.
アクセス制御モデルは、セッションの確立が完了し、<hello>交換が正常に完了した後、クライアントとサーバー間で転送される整形式のXMLコンテンツに特に適用されます。
Once session establishment is completed and a user has been authenticated, the 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サーバーは、提供されたユーザー名、グループ名、サーバーに保存されている構成データに基づいて、アクセス制御ルールを適用します。
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-error>応答内の<error-info>要素で読み取ることを許可されていない情報を含めてはなりません（MUST NOT）。
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
+---------------+
| <rpc> message |
+---------------+
| | |
| | +--------------------------------+
| +---------------+ |
V V V
+------------------+ +--------------------+ +--------------------+
| vendor operation | | standard operation | | standard operation |
| <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.
1. 「enable-nacm」リーフが「false」に設定されている場合、プロトコル操作は許可されます。
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.
3. 要求された操作がNETCONF <close-session>プロトコル操作である場合、プロトコル操作は許可されます。
4. Check all the "group" entries to see if any of them 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. すべての「グループ」エントリをチェックして、それらのいずれかに、要求を行うセッションのユーザー名と等しい「ユーザー名」エントリが含まれているかどうかを確認します。 「enable-external-groups」リーフが「true」の場合、トランスポート層によって提供されるグループのセットをこれらのグループに追加します。
5. If no groups are found, continue with step 10.
5. グループが見つからない場合は、手順10に進みます。
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.
* ルールの「モジュール名」リーフは「*」であるか、プロトコル操作が定義されているYANGモジュールの名前と同じです。
* Either (1) the rule does not have a "rule-type" defined or (2) the "rule-type" is "protocol-operation" and the "rpc-name" is "*" or equals the name of the requested protocol operation.
* （1）ルールに「rule-type」が定義されていないか、（2）「rule-type」が「protocol-operation」であり、「rpc-name」が「*」であるか、要求された名前と等しいプロトコル操作。
* The rule's "access-operations" leaf has the "exec" bit set or has the special value "*".
* ルールの「アクセス操作」リーフには、「exec」ビットが設定されているか、特別な値「*」が設定されています。
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：default-deny-all」ステートメントが含まれている場合、プロトコル操作は拒否されます。
11. If the requested protocol operation is the NETCONF <kill-session> or <delete-config>, then the protocol operation is denied.
11. 要求されたプロトコル操作がNETCONF <kill-session>または<delete-config>である場合、プロトコル操作は拒否されます。
12. If the "exec-default" leaf is set to "permit", then permit the protocol operation; otherwise, deny the request.
12. 「exec-default」リーフが「許可」に設定されている場合、プロトコル操作を許可します。それ以外の場合は、要求を拒否します。
If the user is not authorized to invoke the protocol operation, then an <rpc-error> is generated with the following information:
ユーザーがプロトコル操作の呼び出しを許可されていない場合、<rpc-error>は次の情報とともに生成されます。
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:
error-path：要求されたプロトコル操作を識別します。次の例は、NETCONF基本名前空間の<edit-config>プロトコル操作を表しています。
<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 that 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 (1) a data node within a datastore is accessed or (2) an action or notification is tied to a data node, then the server MUST ensure that the user is authorized to perform the requested "read", "create", "update", "delete", or "execute" access operation on the specified data node.
（1）データストア内のデータノードがアクセスされるか、（2）アクションまたは通知がデータノードに関連付けられている場合、サーバーは、ユーザーが要求された「読み取り」、「作成」、「を実行することを承認されていることを確認する必要があります。指定されたデータノードに対するアクセス操作の「更新」、「削除」、または「実行」。
If an action is requested to be executed, the server MUST ensure that the user is authorized to perform the "execute" access operation on the requested action.
アクションの実行が要求された場合、サーバーは、ユーザーが要求されたアクションに対して「実行」アクセス操作を実行することを許可されていることを確認する必要があります。
If a notification tied to a data node is generated, the server MUST ensure that the user is authorized to perform the "read" access operation on the requested notification.
データノードに関連付けられた通知が生成される場合、サーバーは、ユーザーが要求された通知で「読み取り」アクセス操作を実行することを許可されていることを確認する必要があります。
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.
1. 「enable-nacm」リーフが「false」に設定されている場合、アクセス操作は許可されます。
2. If the requesting session is identified as a recovery session, then the access operation is permitted.
2. 要求しているセッションが回復セッションとして識別されると、アクセス操作が許可されます。
3. Check all the "group" entries to see if any of them 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. すべての「グループ」エントリをチェックして、それらのいずれかに、要求を行うセッションのユーザー名と等しい「ユーザー名」エントリが含まれているかどうかを確認します。 「enable-external-groups」リーフが「true」の場合、トランスポート層によって提供されるグループのセットをこれらのグループに追加します。
4. If no groups are found, continue with step 9.
4. グループが見つからない場合は、手順9に進みます。
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.
* ルールの「モジュール名」リーフは「*」であるか、要求されたデータノードが定義されているYANGモジュールの名前と同じです。
* Either (1) the rule does not have a "rule-type" defined or (2) the "rule-type" is "data-node" and the "path" matches the requested data node, action node, or notification node. A path is considered to match if the requested node is the node specified by the path or is a descendant node of the path.
* （1）ルールに「rule-type」が定義されていないか、（2）「rule-type」が「data-node」であり、「path」が要求されたデータノード、アクションノード、または通知ノードと一致する。要求されたノードがパスで指定されたノードであるか、パスの子孫ノードである場合、パスは一致すると見なされます。
* 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 "*".
* 「更新」アクセス操作の場合、ルールの「アクセス操作」リーフには「更新」ビットが設定されているか、特別な値「*」が設定されています。
* For an "execute" access operation, the rule's "access-operations" leaf has the "exec" 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 and all its descendants are not included in the reply.
9. 「読み取り」アクセス操作の場合、要求されたデータノードがサーバー機能でアドバタイズされたYANGモジュールで定義され、データ定義ステートメントに「nacm：default-deny-all」ステートメントが含まれている場合、要求されたデータノードとそのすべてのノード子孫は返信に含まれません。
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 access request is denied for the data node and all its descendants.
10. 「書き込み」アクセス操作の場合、要求されたデータノードがサーバー機能でアドバタイズされたYANGモジュールで定義され、データ定義ステートメントに「nacm：default-deny-write」または「nacm：default-deny-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 or any of its descendants 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. 「write」アクセス操作の場合、「write-default」リーフが「permit」に設定されている場合、データノードアクセス要求を許可します。それ以外の場合は、要求を拒否します。
13. For an "execute" access operation, if the "exec-default" leaf is set to "permit", then permit the request; otherwise, deny the request.
13. 「実行」アクセス操作の場合、「exec-default」リーフが「許可」に設定されている場合、要求を許可します。それ以外の場合は、要求を拒否します。
Configuration of access control rules specifically for descendant nodes of the notification event type 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.
通知イベントタイプの子孫ノード専用のアクセス制御ルールの構成は、このドキュメントの範囲外です。ユーザーが通知イベントタイプの受信を許可されている場合は、その中に含まれるデータの受信も許可されています。
If the notification is specified within a data subtree, as specified in [RFC7950], then read access to the notification is required. Processing continues as described in Section 3.4.5.
[RFC7950]で指定されているように、通知がデータサブツリー内で指定されている場合、通知への読み取りアクセスが必要です。セクション3.4.5で説明されているように、処理は続行されます。
The following figure shows the conceptual message processing model for outgoing <notification> messages.
次の図は、発信<notification>メッセージの概念的なメッセージ処理モデルを示しています。
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.
1. 「enable-nacm」リーフが「false」に設定されている場合、通知は許可されます。
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.
3. 通知がNETCONF <replayComplete>または<notificationComplete>イベントタイプ[RFC5277]の場合、通知は許可されます。
4. Check all the "group" entries to see if any of them 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. すべての「グループ」エントリをチェックして、それらのいずれかに、要求を行うセッションのユーザー名と等しい「ユーザー名」エントリが含まれているかどうかを確認します。 「enable-external-groups」リーフが「true」の場合、トランスポート層によって提供されるグループのセットをこれらのグループに追加します。
5. If no groups are found, continue with step 10.
5. グループが見つからない場合は、手順10に進みます。
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.
* ルールの「モジュール名」リーフは「*」であるか、通知が定義されているYANGモジュールの名前と同じです。
* Either (1) the rule does not have a "rule-type" defined or (2) the "rule-type" is "notification" and the "notification-name" is "*" or equals the name of the notification.
* （1）ルールに「ルールタイプ」が定義されていないか、（2）「ルールタイプ」が「通知」で、「通知名」が「*」であるか、通知の名前と等しい。
* 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. 一致するルールが見つかった場合、「アクション」リーフがチェックされます。 「許可」に等しい場合は、通知を許可します。それ以外の場合は、関連するサブスクリプションの通知をドロップします。
9. Otherwise, no matching rule was found in any rule-list entry.
9. それ以外の場合、どのルールリストエントリにも一致するルールは見つかりませんでした。
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モジュールで定義されていて、「notification」ステートメントに「nacm：default-deny-all」ステートメントが含まれている場合、関連するサブスクリプションの通知はドロップされます。
11. If the "read-default" leaf is set to "permit", then permit the notification; otherwise, drop the notification for the associated subscription.
11. 「read-default」リーフが「permit」に設定されている場合、通知を許可します。それ以外の場合は、関連するサブスクリプションの通知をドロップします。
The following diagram highlights the contents and structure of the NACM YANG module.
次の図は、NACM YANGモジュールの内容と構造を示しています。
module: ietf-netconf-acm
+--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 be supported by the server.
次のYANGモジュールは、サーバーがサポートする必要がある規範的なNETCONFコンテンツを指定します。
The "ietf-netconf-acm" YANG module imports typedefs from [RFC6991].
"ietf-netconf-acm" YANGモジュールは、[RFC6991]からtypedefをインポートします。
<CODE BEGINS> file "ietf-netconf-acm@2018-02-14.yang"
module ietf-netconf-acm {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm";
prefix nacm;
接頭辞nacm;
import ietf-yang-types {
prefix yang;
}
organization "IETF NETCONF (Network Configuration) Working Group";
組織「IETF NETCONF（ネットワーク構成）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Andy Bierman
<mailto:andy@yumaworks.com>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>";
description "Network Configuration Access Control Model.
説明「ネットワーク構成アクセス制御モデル。
Copyright (c) 2012 - 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2012-2018 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
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 (https://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETF文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8341; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 8341の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision "2018-02-14" {
description
"Added support for YANG 1.1 actions and notifications tied to
data nodes. Clarified how NACM extensions can be used by
other data models.";
reference
"RFC 8341: Network Configuration Access Control Model";
}
revision "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.
extension default-deny-write {description "データモデルノードが機密性の高いセキュリティシステムパラメータを表すことを示すために使用されます。
If present, 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.
存在する場合、NETCONFサーバーは指定された「回復セッション」にのみノードへの書き込みアクセスを許可します。他のすべてのユーザーには、明示的なアクセス制御ルールが必要です。
If the NACM module is used, then it must be enabled (i.e., /nacm/enable-nacm object equals 'true'), or this extension is ignored.
NACMモジュールを使用する場合は、有効にする必要があります（つまり、/ nacm / enable-nacmオブジェクトが「true」に等しい）。この拡張機能は無視されます。
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.
extension default-deny-all {description "データモデルノードが非常に機密性の高いセキュリティシステムパラメータを制御することを示すために使用されます。
If present, 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.
存在する場合、NETCONFサーバーは、指定された「回復セッション」に、ノードへの読み取り、書き込み、または実行アクセスのみを許可します。他のすべてのユーザーには、明示的なアクセス制御ルールが必要です。
If the NACM module is used, then it must be enabled (i.e., /nacm/enable-nacm object equals 'true'), or this extension is ignored.
NACMモジュールを使用する場合は、有効にする必要があります（つまり、/ nacm / enable-nacmオブジェクトが「true」に等しい）。この拡張機能は無視されます。
The 'default-deny-all' extension MAY appear within a data
definition statement, 'rpc' statement, or 'notification'
statement. It is ignored otherwise.";
}
/*
* Derived types
*/
typedef user-name-type {
type string {
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
"Access operation.";
}
typedef group-name-type {
type string {
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, action, or notification instance-identifier
string.
A node-instance-identifier value is an unrestricted YANG instance-identifier expression.
node-instance-identifier値は、無制限のYANGインスタンスID表現です。
All the same rules as an instance-identifier apply, except that predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key.
キーの述語がオプションであることを除いて、インスタンス識別子と同じ規則がすべて適用されます。キー述語が欠落している場合、node-instance-identifierはそのキーのすべての可能なサーバーインスタンスを表します。
This XML Path Language (XPath) expression is evaluated in the following context:
このXMLパス言語（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 変数バインディングのセットには、現在のセッションのユーザーの名前を含む1つの変数「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 コンテキストノードは、データツリーのルートノードです。
The accessible tree includes actions and notifications tied
to data nodes.";
}
/*
* Data definition statements
*/
container nacm {
nacm:default-deny-all;
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.";
list group {
key name;
description "One NACM group entry. This list will only contain configured entries, not any entries learned from any transport protocols.";
説明 "1つの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 whether or not access is granted.";
ルールは、一致が見つかるまでユーザー定義の順序で処理されます。 'module-name'、 'rule-type'、および 'access-operations'がリクエストに一致する場合、ルールは一致します。ルールが一致すると、「アクション」リーフがアクセスを許可するかどうかを決定します。 ";
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, action, or notification 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.
構成データまたは状態データのインスタンス識別子は、最上位のデータノードで始まります。このタイプのパス値には、完全なインスタンスIDが必要です。
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 has been 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>
<コード終了>
This document reuses the URI for "ietf-netconf-acm" in the "IETF XML Registry".
このドキュメントは、「IETF XMLレジストリ」の「ietf-netconf-acm」のURIを再利用します。
This document updates the module registration in the "YANG Module Names" registry to reference this RFC instead of RFC 6536 for "ietf-netconf-acm". Following the format in [RFC6020], the following has been registered.
このドキュメントは、「ietf-netconf-acm」のRFC 6536ではなくこのRFCを参照するように、「YANG Module Names」レジストリのモジュール登録を更新します。 [RFC6020]のフォーマットに従い、以下が登録されています。
Name: ietf-netconf-acm
Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
Prefix: nacm
Reference: RFC 8341
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246].
このドキュメントで指定されているYANGモジュールは、NETCONF [RFC6241]やRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義します。最下位のNETCONFレイヤーはセキュアなトランスポートレイヤーであり、実装に必須のセキュアなトランスポートはセキュアシェル（SSH）です[RFC6242]。最も低いRESTCONF層はHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC5246]です。
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
NETCONFアクセス制御モデル[RFC8341]は、特定のNETCONFまたはRESTCONFユーザーのアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
There is a risk related to the lack of access control enforcement for the RESTCONF OPTIONS and PATCH methods. The risk here is that the response to OPTIONS and PATCH may vary based on the presence or absence of a resource corresponding to the URL's path. If this is the case, then it can be used to trivially probe for the presence or absence of values within a tree. Therefore, a server MUST NOT vary its responses based on the existence of the underlying resource, which would indicate the presence or absence of resource instances. In particular, servers should not expose any instance information before ensuring that the client has the necessary access permissions to obtain that information. In such cases, servers are expected to always return the "access-denied" error response.
RESTCONF OPTIONSおよびPATCHメソッドのアクセス制御の実施の欠如に関連するリスクがあります。ここでのリスクは、OPTIONSとPATCHへの応答が、URLのパスに対応するリソースの有無に基づいて変化する可能性があることです。この場合は、ツリー内の値の有無を簡単に調べるために使用できます。したがって、サーバーは、リソースインスタンスの存在または不在を示す、基礎となるリソースの存在に基づいてその応答を変更してはなりません（MUST NOT）。特に、サーバーは、クライアントがその情報を取得するために必要なアクセス許可を持っていることを確認する前に、インスタンス情報を公開してはなりません。このような場合、サーバーは常に「アクセス拒否」エラー応答を返すことが期待されています。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYANGモジュールには、書き込み可能/作成可能/削除可能なデータノードが多数定義されています（つまり、config true、デフォルトです）。これらのデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。適切な保護なしにこれらのデータノードに書き込み操作（edit-configなど）を行うと、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
o /nacm: The entire /nacm subtree is related to security. Refer to the following sections for more details.
o / nacm：/ nacmサブツリー全体がセキュリティに関連しています。詳細については、次のセクションを参照してください。
This section highlights the issues for an administrator to consider when configuring a NETCONF server with the 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 the NACM is enabled and also decide if the default access parameters are set appropriately. Make sure that the following data nodes are properly configured:
デフォルトでは、NACM実施は有効になっています。デフォルトでは、すべてのデータストアコンテンツへの「読み取り」アクセスが有効になっており（データ定義に「nacm：default-deny-all」が指定されていない限り）、安全なプロトコル操作のために「exec」アクセスが有効になっています。管理者は、NACMが有効になっていることを確認し、デフォルトのアクセスパラメータが適切に設定されているかどうかを判断する必要もあります。以下のデータノードが正しく構成されていることを確認してください。
o /nacm/enable-nacm (default "true")
o / nacm / enable-nacm（デフォルトは「true」）
o /nacm/read-default (default "permit")
o / nacm / read-default（デフォルトは「許可」）
o /nacm/write-default (default "deny")
o / nacm / write-default（デフォルトは「拒否」）
o /nacm/exec-default (default "permit")
o / nacm / exec-default（デフォルトは「許可」）
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アクセスコントロールルールが実行中の構成データストア内で直接編集される場合（つまり、：writable-running機能がサポートされ、使用されている場合）、編集の実行中に意図しないアクセスを許可しないように注意する必要があります。
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].
管理者は、トランスポート依存または実装依存のユーザーIDからNACMユーザー名への変換が一意かつ正しいことを確認する必要があります。この要件は、[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 configuration datastore.
管理者は、アクセス制御規則（/ nacm / rule-listおよび/ nacm / rule-list / rule）を表す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 / groupsデータ構造には、サーバーが使用する管理グループ名が含まれていることに注意してください。これらのグループ名はローカルで設定するか、RADIUS [RFC2865] [RFC5607]などの外部プロトコルを介して提供することができます。
An administrator needs to be aware of the security properties of any external protocol used by the 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 the 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".
管理者は、トランスポート層がグループ名を決定するために使用する外部プロトコルのセキュリティプロパティを認識する必要があります。たとえば、このプロトコルが中間者攻撃から保護されていない場合、攻撃者はNACMで構成されているグループ名を挿入して、ユーザーが必要以上の権限を取得できるようにする可能性があります。そのような場合、管理者は/ nacm / enable-external-groupsを「false」に設定することにより、そのようなグループ名の使用を無効にすることができます。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYANGモジュールの一部の読み取り可能なデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。したがって、これらのデータノードへの読み取りアクセスを制御することが重要です（たとえば、get、get-config、または通知を介して）。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
o /nacm/enable-nacm
o / nacm / enable-nacm
o /nacm/read-default
o / nacm / read-default
o /nacm/write-default
o / nacm / write-default
o /nacm/exec-default
o / nacm / exec-default
o /nacm/enable-external-groups o /nacm/groups
o / nacm / enable-external-groups o / nacm / groups
o /nacm/rule-list
o / nacm / rule-list
An administrator needs to restrict read access to the above-listed objects within this data model, as they reveal access control configuration that could be considered sensitive.
管理者は、機密と見なされる可能性のあるアクセス制御構成を明らかにするため、このデータモデル内の上記のオブジェクトへの読み取りアクセスを制限する必要があります。
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.
一部の書き込みアクセス権（<edit-config>の呼び出しが許可されているなど）はあるが、機密データを含む特定のデータストアサブツリーへのアクセス権がないセッションでは、そのデータの有無を判断することができます。これは、ある種の編集要求（作成、更新、または削除）を繰り返し発行し、応答として「アクセス拒否」エラーを受信することで実行できます。これらの「フィッシング」攻撃は、<rpc-error>応答内に「error-path」フィールドが存在しなくても、特定の機密データの有無を識別できます。
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 that 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., a 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 when-stmt）は、さまざまなデータノードの存在と値を調べることにより、不正なセッションが機密データノードの存在または値さえも決定するのに役立つ可能性があります。
It is possible that the data model definition itself (e.g., a YANG when-stmt or choice-stmt) will allow a session to implicitly create or delete nodes that the session does not have write access to as an implicit side effect from the processing of an allowed <edit-config> operation.
データモデル定義自体（たとえば、YANG when-stmtまたはchoice-stmt）により、セッションが書き込みアクセス権を持たないノードを暗黙的に作成または削除できるようになる可能性があります。許可されている<edit-config>操作。
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 includes the sensitive data node.
データモデルには、別のデータ構造の値を公開する外部キー（YANG leafrefなど）が含まれる場合があります。管理者は、leafrefノードを含む機密データモデルを認識する必要があります。これには、機密データノードを暗黙的または明示的に含む機密データ（「path-stmt」値）を「ポイント」するすべてのleafrefオブジェクトを見つける必要があります。
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 are outside the scope of this document. An administrator needs to be aware of any recovery session mechanisms available on the device and make sure that 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 that 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:
データストアをロックすることにより、構成への書き込みアクセスがなくても、セッションが構成管理を中断する可能性があります。これは、構成のすべてまたは一部が取得されている間、安定した状態を保つために行われる場合と、「サービス拒否」攻撃として行われる場合があります。サーバーが違いを知る方法はありません。管理者は、次のプロトコル操作への「exec」アクセスを制限したい場合があります。
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：default-deny-write」または「nacm：default-deny-all」ステートメントが存在する必要があります。
Protocol operations need to be properly documented by the data model designer so that 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-reply>メッセージで返される情報（存在する場合）が管理者に明確になります。
Data models ought to be designed so that different access levels for input parameters to protocol operations are not required. The 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, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.
[RFC5277] Chisholm、S。およびH. Trevino、「NETCONFイベント通知」、RFC 5277、DOI 10.17487 / RFC5277、2008年7月、<https://www.rfc-editor.org/info/rfc5277>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-editor。 org / info / rfc6020>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M。、「Using the NETCONF Protocol over Secure Shell（SSH）」、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<https：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K。、およびR. Wilton、「Network Management Datastore Architecture（NMDA）」、RFC 8342、DOI 10.17487 / RFC8342、2018年3月、< https://www.rfc-editor.org/info/rfc8342>。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126]ブレイ、T。、パオリ、J.、Sperberg-McQueen、M。、マラー、E。、およびF.イェルガウ、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation REC-xml-20081126、2008年11月、<https://www.w3.org/TR/2008/REC-xml-20081126>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：/ /www.rfc-editor.org/info/rfc2865>。
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, DOI 10.17487/RFC5607, July 2009, <https://www.rfc-editor.org/info/rfc5607>.
[RFC5607] Nelson、D。およびG. Weber、「ネットワークアクセスサーバー（NAS）管理用のリモート認証ダイヤルインユーザーサービス（RADIUS）承認」、RFC 5607、DOI 10.17487 / RFC5607、2009年7月、<https：// www.rfc-editor.org/info/rfc5607>。
[YANG-SEC] IETF, "YANG Security Guidelines", <https://trac.ietf.org/ trac/ops/wiki/yang-security-guidelines>.
[YANG-SEC] IETF、「YANGセキュリティガイドライン」、<https://trac.ietf.org/ trac / ops / wiki / yang-security-guidelines>。
The following XML [W3C.REC-xml-20081126] snippets are provided as examples only, to demonstrate how the NACM can be configured to perform some access control tasks.
次のXML [W3C.REC-xml-20081126]スニペットは、一部のアクセス制御タスクを実行するようにNACMを構成する方法を示すために、例としてのみ提供されています。
There needs to be at least one <group> entry in order for any of the access control rules to be useful.
アクセスコントロールルールを有効にするには、少なくとも1つの<group>エントリが必要です。
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>
<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>
This example shows three groups:
この例は、3つのグループを示しています。
admin: The "admin" group contains two users named "admin" and "andy".
admin：「admin」グループには、「admin」と「andy」という2人のユーザーが含まれています。
limited: The "limited" group contains two users named "wilma" and "bam-bam".
limited：「limited」グループには、「wilma」と「bam-bam」という名前の2人のユーザーが含まれています。
guest: The "guest" group contains two users named "guest" and "guest@example.com".
guest：「guest」グループには、「guest」と「guest@example.com」という名前の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 nodes from the "rule-type" choice set.
モジュールルールは、特定のモジュールで定義されたすべてのコンテンツへのアクセスを制御するために使用されます。モジュールルールには「module-name」リーフセットがありますが、「rule-type」選択セットのノードはありません。
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
<rule-list>
<name>guest-acl</name>
<group>guest</group>
<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>
<rule-list>
<name>limited-acl</name>
<group>limited</group>
<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>
<rule-list>
<name>admin-acl</name>
<group>admin</group>
<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>
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.
deny-ncm：このルールは、「ゲスト」グループが「ietf-netconf-monitoring」YANGモジュール内の監視情報を読み取るのを防ぎます。
permit-ncm: This rule allows the "limited" group to read the "ietf-netconf-monitoring" YANG module.
permit-ncm：このルールは、「制限された」グループが「ietf-netconf-monitoring」YANGモジュールを読み取ることを許可します。
permit-exec: This rule allows the "limited" group to invoke any protocol operation supported by the server.
permit-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.
permit-all：このルールは、「admin」グループにサーバー内のすべてのコンテンツへの完全なアクセスを許可します。このモジュールルールのため、後続のルールは「admin」グループに一致しません。
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>
<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' group or the '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 the 'limited' group or the 'guest' group
to delete any configurations.
</comment>
</rule>
</rule-list>
<rule-list>
<name>limited-acl</name>
<group>limited</group>
<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>
</nacm>
This example shows three protocol operation rules:
この例は、3つのプロトコル操作ルールを示しています。
deny-kill-session: This rule prevents the "limited" group or the "guest" group from invoking the NETCONF <kill-session> protocol operation.
deny-kill-session：このルールは、「制限された」グループまたは「ゲスト」グループがNETCONF <kill-session>プロトコル操作を呼び出すことを防ぎます。
deny-delete-config: This rule prevents the "limited" group or the "guest" group from invoking the NETCONF <delete-config> protocol operation.
deny-delete-config：このルールは、「制限された」グループまたは「ゲスト」グループがNETCONF <delete-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".
permit-edit-config：このルールは、「制限された」グループがNETCONF <edit-config>プロトコル操作を呼び出すことを許可します。 「exec-default」リーフが「deny」に設定されていない限り、このルールは実際には効果がありません。
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コンテンツ内の特定の（構成および非構成）データノードへのアクセスを制御するために使用されます。
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
<rule-list>
<name>guest-acl</name>
<group>guest</group>
<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>
<rule-list>
<name>limited-acl</name>
<group>limited</group>
<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>
<rule-list>
<name>guest-limited-acl</name>
<group>guest</group>
<group>limited</group>
<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>
<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 the 'admin' group full access to all acme interfaces. </comment> </rule> </rule-list> </nacm> This example shows four data node rules:
<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>「admin」グループにフルアクセスを許可するすべてのacmeインターフェース。 </ comment> </ rule> </ rule-list> </ nacm>この例は、4つのデータノードルールを示しています。
deny-nacm: This rule denies the "guest" group any access to the /nacm subtree.
deny-nacm：このルールは、「ゲスト」グループに/ nacmサブツリーへのアクセスを拒否します。
permit-acme-config: This rule gives the "limited" group read-write access to the acme <config-parameters>.
permit-acme-config：このルールは、「制限された」グループに、acme <config-parameters>への読み取り/書き込みアクセス権を付与します。
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; it can only be altered.
permit-dummy-interface：このルールは、「限られた」グループと「ゲスト」グループに、「ダミー」という名前のacme <interface>エントリへの読み取り更新アクセスを許可します。このエントリは、これらのグループによって作成または削除することはできません。変更のみ可能です。
permit-interface: This rule gives the "admin" group read-write access to all acme <interface> entries.
permit-interface：このルールは、「admin」グループに、すべてのacme <interface>エントリへの読み取り/書き込みアクセス権を付与します。
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>
<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' group or the 'limited' group
to receive config change events.
</comment>
</rule>
</rule-list>
</nacm>
This example shows one notification rule:
この例は、1つの通知ルールを示しています。
deny-config-change: This rule prevents the "limited" group or the "guest" group from receiving the acme <sys-config-change> event type.
deny-config-change：このルールは、「制限された」グループまたは「ゲスト」グループがacme <sys-config-change>イベントタイプを受信しないようにします。
Authors' Addresses
著者のアドレス
Andy Bierman YumaWorks 685 Cochran St. Suite #160 Simi Valley, CA 93065 United States of America
アンディ・ビアマンYumaWorks 685 Cochran St. Suite＃160 Simi Valley、CA 93065アメリカ合衆国
Email: andy@yumaworks.com
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-fシステム
Email: mbj@tail-f.com