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