IEC 62351-8:2026

• Abstract:

  IEC 62351-8:2026 is to facilitate role-based access control (RBAC) for power system management. RBAC assigns human users, automated systems, and software applications (collectively called "subjects" in this document) to specified "roles", and restricts their access to only those resources, which the security policies identify as necessary for their roles.; As electric power systems become more automated and cyber security concerns become more prominent, it is becoming increasingly critical to ensure that access to data (read, write, control, etc.) is restricted. As in many aspects of security, RBAC is not just a technology; it is a way of running a business. RBAC is not a new concept; in fact, it is used by many operating systems to control access to system resources. Specifically, RBAC provides an alternative to the all-or-nothing super-user model in which all subjects have access to all data, including control commands.; RBAC is a primary method to meet the security principle of least privilege, which states that no subject should be authorized more permissions than necessary for performing that subject’s task. With RBAC, authorization is separated from authentication. RBAC enables an organization to subdivide super-user capabilities and package them into special user accounts' termed roles for assignment to specific individuals according to their associated duties. This subdivision enables security policies to determine who or what systems are permitted access to which data in other systems. RBAC thus provides a means of reallocating system controls as defined by the organization policy. In particular, RBAC can protect sensitive system operations from inadvertent (or deliberate) actions by unauthorized users. Clearly RBAC is not confined to human users though; it applies equally well to automated systems and software applications, i.e., software parts operating independent of user interactions.; The following interactions are in scope:; – local (direct wired) access to the object by a human user, a local and automated computer agent, or a built-in human machine interface (HMI) or panel;; – remote (via dial-up or wireless media) access to the object by a human user;; – remote (via dial-up or wireless media) access to the object by a remote automated computer agent, e.g., another object at another substation, a distributed energy resource at an end-user’s facility, or a control centre application.; While this document defines a set of mandatory roles to be supported, the exchange format for defined specific or custom roles is also in scope of this document. This is achieved by defining two different encoding approaches to handle the definition of custom roles, either based on specific permissions or based on constraints to existing permissions. The definition on handling custom based roles was started in IEC 62351-90-1 and taken over into the IEC 62351-8:2020. Moreover, additionally to the definition of custom roles based on associated permissions, this document also includes options how to assign permissions to objects in a general way. Referencing documents will provide a mapping to a concrete data model to ensure an interoperability for standard roles used in different data models as well as for custom defined roles. Referencing documents might be standards such as IEC PAS 61850-90-19 or IEC 60870-5-7:2025 or also definitions by an operator.; Out of scope for this document are all topics which are not directly related to the definition of roles and access tokens for local and remote access, especially administrative or organizational tasks, such as:; – definition of usernames and password definitions/policies;; – management of keys and/or key exchange;; – engineering process of roles;; – assignment of roles;; – selection of trusted certification authorities issuing credentials (access tokens);; – defining the tasks of a security officer;; – integrating local policies in RBAC.; Existing standards (see ANSI INCITS 359-2004,

• Status: Published
• Publication Date: 21-Jul-2026
• ICS: 33.200 - Telecontrol. Telemetering
• Technical Committee: TC 57 - Power systems management and associated information exchange
• Drafting Committee: WG 15 - TC 57/WG 15
• Current Stage: PPUB - Publication issued
• Start Date: 22-Jul-2026
• Completion Date: 29-May-2026

• Revises: IEC TS 62351-8:2011 - Power systems management and associated information exchange - Data and communications security - Part 8: Role-based access control
• Effective Date: 24-Jul-2026

IEC 62351-8 ®
Edition 2.0 2026-07
INTERNATIONAL
STANDARD
Power systems management and associated information exchange - Data and
communications security -
Part 8: Role-based access control for power system management
ICS 33.200  ISBN 978-2-8327-1354-9

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

IEC Secretariat Tel.: [phone]
3, rue de Varembé [e-mail]
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
The world's leading online dictionary on electrotechnology,
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: [e-mail].
CONTENTS
FOREWORD . 6
INTRODUCTION . 8
1 Scope . 10
1.1 General . 10
1.2 Published versions of the standard and related namespace names . 12
1.3 Identification of the code component . 12
1.4 Code Component distribution . 12
2 Normative references . 13
3 Terms and definitions . 13
4 Abbreviated terms . 16
5 RBAC – Process model and concepts . 17
5.1 General . 17
5.2 Overview of RBAC process model . 18
5.3 Generic RBAC concepts . 18
5.4 Separation of subjects, roles, and permissions . 20
5.4.1 RBAC model . 20
5.4.2 Subject assignment (subject-to-role mapping) . 23
5.4.3 Role-to-permission mapping . 23
5.4.4 Permission definition . 23
5.4.5 operationSet assignment (mapping of roles-permission-combinations
to objects) . 23
5.5 Criteria for defining roles . 24
5.5.1 Policies. 24
5.5.2 Subjects, roles, and permissions . 24
5.5.3 Introducing roles reduces complexity . 24
6 Definition of roles and permission assignment . 25
6.1 General . 25
6.2 Pre-defined roles . 25
6.3 Role-to-permission assignment . 26
6.3.1 General . 26
6.3.2 Number of supported permissions by a role . 27
6.3.3 Number of supported roles . 27
6.3.4 Assigning permissions to roles . 27
6.4 Definition of pre-defined and custom based roles . 29
6.4.1 General . 29
6.4.2 Encoding of roles based on specific permissions . 30
6.4.3 Encoding of roles using constraints on existing permissions . 36
6.5 Consideration of operational states . 39
6.6 Security event consideration for the engineering of roles and permissions . 40
7 Simplified role assignment . 42
7.1 General . 42
7.2 Application of roles associated with multiple role definitions (generic roles) . 42
7.3 Illustrative examples . 43
7.3.1 General . 43
7.3.2 Application of pre-defined role "VIEWER" on Device-X for all role
definitions . 44
7.3.3 Application of custom role "OPERATOR-DFR" on Device-Y for all
supported role definitions . 45
7.3.4 Application of pre-defined role "SECADM" for selected role definitions . 46
8 Definition of access tokens . 48
8.1 General . 48
8.2 Supported profiles . 48
8.3 Role-based access control related Object Identifiers . 48
8.4 General structure of the access tokens . 49
8.4.1 Profile specific mandatory components in the access tokens . 49
8.4.2 Optional access token components . 50
8.4.3 Definition of specific fields . 50
8.5 Access token profiles . 55
8.5.1 General . 55
8.5.2 Profile A: X.509 Public-key certificate . 55
8.5.3 Profile B: X.509 Attribute certificate . 59
8.5.4 Profile C: JSON Web Token – JWT . 63
8.5.5 Profile D: RADIUS provided access token information . 66
8.5.6 Profile E: LDAP provided RBAC information . 69
9 Verification of access tokens . 75
9.1 General . 75
9.2 Multiple access token existence . 75
9.3 Subject authentication. 75
9.4 Access token availability . 76
9.5 Validity period . 76
9.6 Access token integrity . 76
9.7 Issuer . 76
9.8 Role ID . 77
9.9 Revision . 77
9.10 Area of responsibility . 77
9.11 Role definition . 77
9.12 Revocation state . 77
9.13 Operation . 78
9.14 Sequence number . 78
9.15 Revocation methods . 78
9.15.1 General . 78
9.15.2 Supported methods . 79
10 RBAC access token distribution models . 79
10.1 General . 79
10.2 PUSH model . 80
10.3 PULL model . 81
11 Interaction with backend services for RBAC access token distribution . 83
11.1 General . 83
11.2 Using directory services with LDAP . 83
11.2.1 General . 83
11.2.2 Secure communication . 83
11.2.3 LDAP Directory organization . 85
11.3 Using OAuth to provide JWT token . 85
11.3.1 General . 85
11.3.2 Secure communication . 87
11.4 Using AAA services with RADIUS . 87
11.4.1 General . 87
11.4.2 Secure communication . 87
11.4.3 Peer configuration . 88
11.4.4 RADIUS server organization . 88
11.5 Comparison of backend interaction depending on RBAC profile . 89
12 Access token transport . 90
12.1 General . 90
12.2 Transport in Ethernet-based protocols . 90
12.3 Usage in non-Ethernet based protocols. 91
12.4 Usage in the context of the application protocol . 91
13 Conformity . 91
13.1 General . 91
13.2 Notation . 91
13.3 Mapping to existing authorization mechanisms . 91
13.4 Conformance to access token format . 92
13.5 Conformance to access token content . 92
13.6 Access token distribution . 94
13.7 Role information . 94
13.8 Role information exchange . 95
13.9 Security events . 95
Annex A (informative) Security Events . 96
A.1 General . 96
A.2 Mapping of general access token security events . 96
A.3 Mapping of access token security events specific for profile A, B, and C . 97
A.4 Mapping of security events related to backend service interaction . 97
A.5 Mapping of security events related to RBAC engineering and maintenance . 97
Annex B (informative) Role definition from previous revisions/editions of IEC 62351-8 . 99
B.1 General . 99
B.2 Role definition from IEC TS 62351-8:2011 . 99
B.3 Role definition from IEC 62351-8:2020 . 100
Annex C (informative) Informative example for specific role definition . 102
C.1 General . 102
C.2 Use case description . 102
C.3 XACML definition example . 102
C.4 Role description . 103
C.5 Permission group description . 104
C.6 Permission description . 105
C.7 Request syntax for PDP . 109
Annex D (informative) Examples for LDAP interaction . 110
D.1 General . 110
D.2 Import of new LDAP schema for "IEC6351-RoleStructure" . 110
D.3 Import of new LDAP schema for "roles" . 110
Annex E (informative) General application of RBAC access token . 111
E.1 General . 111
E.2 Session-based approach . 111
E.3 Message-based approach . 113
Bibliography . 114
Figure 1 – Generic framework for access control . 19
Figure 2 – Diagram of RBAC with static and dynamic separation of duty (enhanced
version of ANSI INCITS 359-2004). 20
Figure 3 – Overview on the concepts of subjects, roles, permissions, and
operationSets . 22
Figure 4 – Referencing Documents . 26
Figure 5 – Relation of Roles and Permissions . 27
Figure 6 – Object binding using distinct role and permission files . 31
Figure 7 – XACML structure . 32
Figure 8 – Object binding using operationSets and O2OS files . 36
Figure 9 – operationSets definition on the example of IEC 61850 . 38
Figure 10 – operationSets assignment to objects utilizing O2OS files . 39
Figure 11 – Generic roles – Interrelation of referencing documents with IEC 62351-8
with examples for role identification triplets . 43
Figure 12 – Example LDAP tree . 72
Figure 13 – LDAP object class roles . 72
Figure 14 – Assignment of LDAP groups to IED known roles . 73
Figure 15 – LDAP memberOf assignment . 74
Figure 16 – Schematic view of authorization based on RBAC PUSH model . 81
Figure 17 – Schematic view of authorization based on RBAC PULL model. 82
Figure 18 – RBAC model using OAuth workflow applying JWT . 86
Figure E.1 – Session based RBAC approach (simplified IEC 62351-4 end-to-end
security). 113

Table 1 – Published versions and related namespace names . 12
Table 2 – Attributes of the IEC 62351-8 code component . 12
Table 3 – Pre-defined roles . 25
Table 4 – Template for role-to-permission mapping. 28
Table 5 – Template for permission definition . 29
Table 6 – Evaluation Context . 36
Table 7 – Possible range of permissions per role . 38
Table 8 – Security Event Mapping to IEC 62351-14 . 41
Table 9 – Access token: meta information . 49
Table 10 – Access token: user role information . 49
Table 11 – Optional access token components . 50
Table 12 – AoR fields and format . 54
Table 13 – Informative example: AoR handling on IED . 55
Table 14 – Mapping between ID and attribute certificate . 63
Table 15 – RBAC profile comparison . 89
Table 16 – Conformance to access token format . 92
Table 17 – Access token: meta information . 93
Table 18 – Access token: user role information . 93
Table 19 – Optional access token components . 93
Table 20 – Generic Role support. 94
Table 21 – Conformance to access token distribution . 94
Table 22 – Support of pre-defined roles . 94
Table A.1 – General access token security events mapped to IEC 62351-14 . 96
Table A.2 – Profile A, B, and C specific access token security events mapped to
IEC 62351-14 . 97
Table A.3 – Security event logs related to backend service interaction . 97
Table A.4 – Security event logs related to RBAC engineering and maintenance . 98
Table B.1 – List of pre-defined role-to-permission assignment (2011 version) . 99
Table B.2 – List of pre-defined role-to-permission assignment (2021 version) . 100
Table C.1 – Permission assignment . 102

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Power systems management and associated information exchange -
Data and communications security -
Part 8: Role-based access control for power system management

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC 62351-8 has been prepared by IEC technical committee 57: Power systems management
and associated information exchange. It is an International Standard.
This second edition cancels and replaces the first edition published in 2020. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous
edition:
a) Removal of mapping of roles to permission to objects based on the target data model and/or
protocol to allow for other mappings than IEC 61850. Mapping is delegated to separate
documents;
b) Specification of handling of a combination of roles and permissions as operationSet to allow
more fine-grained assignments to objects;
c) Specification of a simplified roles assignment to more efficiently handle situations in which
roles are used relating to different data models, including examples;
d) Inclusion of new profile to allow for fetching RBAC information from LDAP repositories;
e) Definition of specific security events throughout the document;
f) Alignment of terminology and enhancement with examples.
The text of this International Standard is based on the following documents:
Draft Report on voting
57/2882/FDIS 57/2921/RVD
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
Recipients of this document are invited to submit, with their comments, notification of any
relevant patent rights of which they are aware and to provide supporting documentation.
This document includes code components, i.e., components that are intended to be directly
processed by a computer. Such content is any text found between the markers BEGINS> and , or otherwise is clearly labelled in this document as a code
component.
The purchase of this document carries a copyright license for the purchaser to sell software
containing code components from this document directly to end users and to end users via
distributors, subject to IEC software licensing conditions, which can be found at:
http://www.iec.ch/CCv1.
In the case of any discrepancy between the document and the code components, the code
components take precedence.
In this document, the following print types are used:
Encoding in ASN.1 or XACML: couriernew
A list of all the parts in the IEC 62351 series, published under the general title Power systems
management and associated information exchange, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
INTRODUCTION
This document provides a standard for access control in power systems. The power system
environment supported by this document is enterprise-wide and extends beyond traditional
borders to include external providers, suppliers, and other energy partners. Driving factors are
the liberalization of the energy sector to include many more stakeholders, the increasingly
decentralized generation of energy, and the need to control access to sensitive data of
resources and stakeholders.
The power system sector is continually improving the delivery of energy by leveraging technical
advances in computer-based applications. Utility operators, energy brokers, and end-users are
increasingly accessing multiple applications to deliver, transmit and consume energy in a
personalized way. These disparate applications are naturally connected to a common network
infrastructure that typically supports protection equipment, substation automation protocols,
inter-station protocols, remote access, and business-to-business services. Consequently,
secure access to these distributed and often loosely coupled applications is even more
important than access to an application running on a stand-alone device.
Secure access to computer-based applications involves authentication of the user to the
application. After authentication, the types of interactions that the user can perform with the
application is then determined. The use of local mechanisms for authorization creates a
patchwork of approaches which are difficult to uniformly administer across the breadth of a
power system enterprise. Each application decides with its own logic the authorization process.
However, if applications can use a network to help manage access, a database can serve as a
trusted source of user’s group or role affiliation. Thus, the access to a shared user base can be
controlled centrally. Each application can then examine the permissions listed for a subject and
corresponding role and determine their level of authorization.
This document defines role-based access control (RBAC) for enterprise-wide use in power
systems. It supports a distributed or service-oriented architecture where security is a distributed
service and applications are consumers of distributed services.
In this document, the role of a user is contained in a data structure called "access token" for
that user and is provided to the accessed resource. Access tokens are created and administered
by a (possibly federated) identity management. All access tokens have a lifetime and are
subject to expiration. Prior to verification of the access token itself, the user who tries to get
access is authenticated by the resource. The resource has a trust relation to the access token
management. The access token can be provided as self-contained object by the user or a
central repository or as data structure by a central repository. Specifically, the self-contained
access tokens enable local verification of the access token’s validity at remote sites without the
need to access a centralized repository. To ensure availability of information in the repository,
redundancy may be considered. Note that redundancy concepts are out of scope for this
document.
Different access token formats are supported as five defined profiles. These access tokens can
be bound to a specific transport or to a specific application in conjunction with different types
of repositories, holding the access tokens. Common to all profiles is the information contained,
to allow a migration from one profile to another.
As RBAC is being adopted for several protocols and data models this document has been
changed accordingly. In its current version it focuses on the general definition of RBAC,
mandatory to be supported roles and options for assigning roles to permissions. The actual
assignment of roles to permissions, and consequently the binding of RBAC related information
to objects, is addressed in the referencing documents, which directly relate to the target data
model. The existing definition of the IEC 61850 specific roles and permissions has been moved
to IEC 61850-90-19. Likewise for IEC 60807-5-101/-104 the specifics are handled in
IEC 60870-5-7:2025. Moreover, IEEE 1815 specifics will be handled in the context of
DNP3SAv6. This document provides information about the role to permission assignment of
previous versions of this document in Annex B.
This standard is maintained. Technical issues identified after publication will be handled via the
TISSUE database to keep correctness and interoperability. Approved technical issues will be
published as INF document and might be further handled according to IEC directives.

1 Scope
1.1 General
The scope of this part of IEC 62351 is to facilitate role-based access control (RBAC) for power
system management. RBAC assigns human users, automated systems, and software
applications (collectively called "subjects" in this document) to specified "roles", and restricts
their access to only those resources, which the security policies identify as necessary for their
roles.
As electric power systems become more automated and cyber security concerns become more
prominent, it is becoming increasingly critical to ensure that access to data (read, write, control,
etc.) is restricted. As in many aspects of security, RBAC is not just a technology; it is a way of
running a business. RBAC is not a new concept; in fact, it is used by many operating systems
to control access to system resources. Specifically, RBAC provides an alternative to the all-or-
nothing super-user model in which all subjects have access to all data, including control
commands.
RBAC is a primary method to meet the security principle of least privilege, which states that no
subject should be authorized more permissions than necessary for performing that subject’s
task. With RBAC, authorization is separated from authentication. RBAC enables an organization
to subdivide super-user capabilities and package them into special user accounts' termed roles
for assignment to specific individuals according to their associated duties. This subdivision
enables security policies to determine who or what systems are permitted access to which data
in other systems. RBAC thus provides a means of reallocating system controls as defined by
the organization policy. In particular, RBAC can protect sensitive system operations from
inadvertent (or deliberate) actions by unauthorized users. Clearly RBAC is not confined to
human users though; it applies equally well to automated systems and software applications,
i.e., software parts operating independent of user interactions.
The following interactions are in scope:
– local (direct wired) access to the object by a human user, a local and automated computer
agent, or a built-in human machine interface (HMI) or panel;
– remote (via dial-up or wireless media) access to the object by a human user;
– remote (via dial-up or wireless media) access to the object by a remote automated computer
agent, e.g., another object at another substation, a distributed energy resource at an end-
user’s facility, or a control centre application.
While this document defines a set of mandatory roles to be supported, the exchange format for
defined specific or custom roles is also in scope of this document. This is achieved by defining
two different encoding approaches to handle the definition of custom roles, either based on
specific permissions or based on constraints to existing permissions. The definition on handling
custom based roles was started in IEC 62351-90-1 and taken over into the IEC 62351-8:2020.
Moreover, additionally to the definition of custom roles based on associated permissions, this
document also includes options how to assign permissions to objects in a general way.
Referencing documents will provide a mapping to a concrete data model to ensure an
interoperability for standard roles used in different data models as well as for custom defined
roles. Referencing documents might be standards such as IEC PAS 61850-90-19 or
IEC 60870-5-7:2025 or also definitions by an operator.
Out of scope for this document are all topics which are not directly related to the definition of
roles and access tokens for local and remote access, especially administrative or organizational
tasks, such as:
– definition of usernames and password definitions/policies;
– management of keys and/or key exchange;
– engineering process of roles;
– assignment of roles;
– selection of trusted certification authorities issuing credentials (access tokens);
– defining the tasks of a security officer;
– integrating local policies in RBAC.
NOTE Specifically, the management of certificates is addressed in IEC 62351-9.
Existing standards (see ANSI INCITS 359-2004, IEC 62443 (all parts), and IEEE 802.1X-2020)
in process control industry and access control (RFC 2904 and RFC 2905) are not sufficient for
addressing specifics of power system automation as none of them specify either the exact role
name and associated permissions or the format of the access tokens nor the detailed
mechanism by which access tokens are transferred to and authenticated by the target system.
This is addressed in this document by defining the access token format, distribution and
verification based on existing technology.
Throughout the document security events are defined. These security events are intended to
support the error handling and thus to increase system resilience. Implementations need to
provide a mechanism for announcing security events.
The information about security events and potential detailed information can only be provided
by the entity based on the availability of this information through the underlying platform or
utilized components.
It is strongly recommended that the security events defined throughout the document are made
available to the operational infrastructure by cyber security events as specified in IEC 62351-14
and/or by monitoring objects as specified in IEC 62351-7. Annex A provides a mapping of the
defined events in this document to the notion of IEC 62351-14.
Notices, warnings, errors, and alarms are used to indicate the severity of an event from a
security point of view. The following notion from IEC 62351-14 is used:
– A notice refers to a cyber security related activity during the routine use or maintenance of
an entity. It does not relate to a cyber security breach or attack or deviation from the normal
operating condition of an entity.
– A warning is a deviation from the normal operating condition of an entity but not necessary
a cyber-attack.
– An error describes an unforeseen condition, which can indicate unauthorized activity. It
might not require immediate action.
– An alarm is an indication of a serious problem, which might indicate unauthorized activity.
Action is expected to be taken immediately.
In any case, it is expected that an organization’s security policy determines the final handling
of events based on the operational environment. For instance, the assessment of one of more
alarms could rise to the le
...

IEC 62351-8 ®
Edition 2.0 2026-07
NORME
INTERNATIONALE
Gestion des systèmes de puissance et échanges d'informations associés -
Sécurité des communications et des données -
Partie 8: Contrôle d'accès basé sur les rôles pour la gestion de systèmes de
puissance
ICS 33.200  ISBN 978-2-8327-1354-9

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: [phone]
3, rue de Varembé [e-mail]
CH-1211 Geneva 20 www.iec.ch
Switzerland
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
dans 25 langues additionnelles. Egalement appelé
Published détaille les nouvelles publications parues.
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: [e-mail].
SOMMAIRE
AVANT-PROPOS . 6
INTRODUCTION . 9
1 Domaine d'application . 11
1.1 Généralités . 11
1.2 Versions publiées de la norme et nom d'espace de nom associé . 13
1.3 Identification de l'élément de code . 13
1.4 Distribution des éléments de code . 13
2 Références normatives . 14
3 Termes et définitions . 15
4 Abréviations . 18
5 RBAC – Modèle de processus et concepts . 19
5.1 Généralités . 19
5.2 Vue d'ensemble du modèle de processus RBAC . 20
5.3 Concepts génériques de RBAC . 20
5.4 Séparation des sujets, rôles et permissions . 22
5.4.1 Modèle de RBAC . 22
5.4.2 Affectation de sujet (mise en correspondance sujet-rôle) . 25
5.4.3 Mise en correspondance rôle-permission . 26
5.4.4 Définition des permissions . 26
5.4.5 Affectation operationSet (mise en correspondance de combinaisons
rôles-permissions avec des objets) . 26
5.5 Critères de définition des rôles . 27
5.5.1 Politiques . 27
5.5.2 Sujets, rôles et permissions . 27
5.5.3 Réduction de la complexité par l'introduction de rôles . 27
6 Définition des rôles et affectation des permissions . 28
6.1 Généralités . 28
6.2 Rôles prédéfinis . 28
6.3 Affectation rôle-permission . 29
6.3.1 Généralités . 29
6.3.2 Nombre de permissions prises en charge par un rôle. 30
6.3.3 Nombre de rôles pris en charge . 30
6.3.4 Affectation des permissions aux rôles . 30
6.4 Définition des rôles prédéfinis et personnalisés . 33
6.4.1 Généralités . 33
6.4.2 Codage des rôles en fonction des permissions spécifiques . 34
6.4.3 Codage des rôles à l'aide de contraintes sur les permissions existantes . 40
6.5 Prise en compte des états opérationnels . 43
6.6 Prise en compte des événements de sécurité pour l'ingénierie des rôles et
des permissions . 44
7 Affectation simplifiée des rôles . 46
7.1 Généralités . 46
7.2 Application de rôles associés à des définitions de rôles multiples (rôles
génériques). 46
7.3 Exemples illustratifs . 48
7.3.1 Généralités . 48
7.3.2 Application du rôle prédéfini "VIEWER" sur le Device-X pour toutes les
définitions de rôles . 48
7.3.3 Application du rôle personnalisé "OPERATOR-DFR" sur le Device-Y
pour toutes les définitions de rôles prises en charge . 49
7.3.4 Application du rôle prédéfini "SECADM" aux définitions de rôles
sélectionnées . 50
8 Définition des jetons d'accès . 52
8.1 Généralités . 52
8.2 Profils pris en charge . 52
8.3 Identificateurs d'objets liés au contrôle d'accès basé sur les rôles . 52
8.4 Structure générale des jetons d'accès . 53
8.4.1 Composants obligatoires spécifiques au profil dans les jetons d'accès . 53
8.4.2 Composants facultatifs des jetons d'accès . 54
8.4.3 Définition des champs spécifiques . 55
8.5 Profils des jetons d'accès . 60
8.5.1 Généralités . 60
8.5.2 Profil A: Certificat X.509 de clé publique . 60
8.5.3 Profil B: Certificat X.509 d'attribut . 64
8.5.4 Profil C: Jeton web JSON – JWT . 68
8.5.5 Profil D: Informations sur le jeton d'accès fournies par RADIUS . 71
8.5.6 Profil E: Informations RBAC fournies par LDAP . 74
9 Vérification des jetons d'accès . 80
9.1 Généralités . 80
9.2 Existence de plusieurs jetons d'accès . 80
9.3 Authentification du sujet . 80
9.4 Disponibilité du jeton d'accès . 81
9.5 Période de validité . 81
9.6 Intégrité des jetons d'accès. 81
9.7 Émetteur . 82
9.8 Role ID . 82
9.9 Révision . 82
9.10 Zone de responsabilité . 82
9.11 Définition du rôle. 83
9.12 État de révocation . 83
9.13 Opération . 83
9.14 Numéro de séquence . 83
9.15 Méthodes de révocation . 84
9.15.1 Généralités . 84
9.15.2 Méthodes prises en charge . 84
10 Modèles de distribution des jetons d'accès RBAC . 85
10.1 Généralités . 85
10.2 Modèle de PUSH . 85
10.3 Modèle de PULL . 87
11 Interaction avec les services backend pour la distribution des jetons d'accès
RBAC . 89
11.1 Généralités . 89
11.2 Utilisation des services de répertoire avec LDAP . 89
11.2.1 Généralités . 89
11.2.2 Communication sécurisée . 89
11.2.3 Organisation du répertoire LDAP . 91
11.3 Utilisation de l'OAuth pour fournir le jeton JWT . 92
11.3.1 Généralités . 92
11.3.2 Communication sécurisée . 93
11.4 Utilisation des services AAA avec RADIUS . 93
11.4.1 Généralités . 93
11.4.2 Communication sécurisée . 94
11.4.3 Configuration d'homologue . 95
11.4.4 Organisation du serveur RADIUS. 95
11.5 Comparaison de l'interaction avec le backend en fonction du profil RBAC . 95
12 Transport des jetons d'accès . 97
12.1 Généralités . 97
12.2 Transport dans les protocoles Ethernet . 97
12.3 Utilisation dans les protocoles non Ethernet . 98
12.4 Utilisation dans le contexte du protocole d'application. 98
13 Conformité . 98
13.1 Généralités . 98
13.2 Notation . 98
13.3 Mise en correspondance avec les mécanismes existants d'autorisation . 99
13.4 Conformité au format de jetons d'accès . 99
13.5 Conformité au contenu des jetons d'accès . 99
13.6 Distribution des jetons d'accès . 101
13.7 Informations sur les rôles . 101
13.8 Échange d'informations relatives au rôle . 102
13.9 Événements de sécurité . 102
Annexe A (informative) Événements de sécurité . 103
A.1 Généralités . 103
A.2 Mise en correspondance des événements de sécurité des jetons d'accès
généraux . 103
A.3 Mise en correspondance des événements de sécurité des jetons d'accès
spécifiques aux profils A, B et C . 104
A.4 Mise en correspondance des événements de sécurité liés à l'interaction
avec le service backend . 104
A.5 Mise en correspondance des événements de sécurité liés à l'ingénierie et à
la maintenance de RBAC . 105
Annexe B (informative) Définition des rôles dans les révisions/éditions précédentes de
l'IEC 62351-8 . 107
B.1 Généralités . 107
B.2 Définition des rôles selon l'IEC TS 62351-8:2011 . 107
B.3 Définition des rôles selon l'IEC 62351-8:2020 . 108
Annexe C (informative) Exemple informatif de définition de rôle spécifique . 110
C.1 Généralités . 110
C.2 Description de cas d'utilisation . 110
C.3 Exemple de définition XACML . 110
C.4 Description du rôle . 111
C.5 Description du groupe de permissions . 112
C.6 Description de permission . 113
C.7 Syntaxe de demande pour le PDP . 117
Annexe D (informative) Exemples d'interaction LDAP . 118
D.1 Généralités . 118
D.2 Import du nouveau schéma LDAP pour "IEC6351-RoleStructure" . 118
D.3 Import du nouveau schéma LDAP pour "roles" . 118
Annexe E (informative) Application générale de jetons d'accès RBAC . 119
E.1 Généralités . 119
E.2 Approche par session . 119
E.3 Approche par message . 121
Bibliographie . 122

Figure 1 – Cadre générique du contrôle d'accès . 21
Figure 2 – Schéma de RBAC avec séparations statique et dynamique des
responsabilités (version améliorée de l'ANSI INCITS 359-2004) . 22
Figure 3 – Vue d'ensemble sur les concepts de sujets, rôles, permissions et
operationSets . 25
Figure 4 – Documents de référence . 30
Figure 5 – Relation entre les rôles et les permissions . 31
Figure 6 – Liaison d'objets à l'aide de fichiers de rôles et de permissions distincts . 34
Figure 7 – Structure XACML . 35
Figure 8 – Liaison d'objets à l'aide d'operationSets et de fichiers O2OS . 40
Figure 9 – Définition des operationSets sur l'exemple de l'IEC 61850 . 42
Figure 10 – Affectation des operationSets aux objets qui utilisent des fichiers O2OS . 43
Figure 11 – Rôles génériques – Corrélation des documents de référence avec
l'IEC 62351-8 avec des exemples de triplets d'identification de rôle . 47
Figure 12 – Exemple d'arborescence LDAP . 77
Figure 13 – Rôles de classe d'objets LDAP . 77
Figure 14 – Affectation des groupes LDAP à des rôles connus d'IED . 78
Figure 15 – Affectation LDAP memberOf. 79
Figure 16 – Vue schématique de l'autorisation d'après le modèle PUSH de RBAC . 86
Figure 17 – Vue schématique de l'autorisation d'après le modèle PULL de RBAC . 88
Figure 18 – Modèle RBAC avec flux de travail OAuth appliquant JWT . 92
Figure E.1 – Approche RBAC par session (sécurité de bout en bout de l'IEC 62351-4
simplifiée) . 121

Tableau 1 – Versions publiées et nom d'espace de nom associé . 13
Tableau 2 – Attributs de l'élément de code de l'IEC 62351-8 . 13
Tableau 3 – Rôles prédéfinis . 28
Tableau 4 – Modèle de mise en correspondance rôle-permission. 32
Tableau 5 – Modèle de définition des permissions . 32
Tableau 6 – Contexte d'évaluation . 40
Tableau 7 – Plage possible de permissions par rôle . 42
Tableau 8 – Mise en correspondance des événements de sécurité selon
l'IEC 62351-14 . 45
Tableau 9 – Jeton d'accès: métadonnées d'informations . 53
Tableau 10 – Jeton d'accès: informations sur le rôle de l'utilisateur . 54
Tableau 11 – Composants facultatifs des jetons d'accès . 54
Tableau 12 – Champs et format de l'AoR . 59
Tableau 13 – Exemple informatif: Gestion de l'AoR sur un IED . 60
Tableau 14 – Mise en correspondance entre ID et certificat d'attribut. 68
Tableau 15 – Comparaison des profils RBAC . 96
Tableau 16 – Conformité au format de jetons d'accès . 99
Tableau 17 – Jeton d'accès: métadonnées d'informations . 100
Tableau 18 – Jeton d'accès: informations sur le rôle de l'utilisateur . 100
Tableau 19 – Composants facultatifs des jetons d'accès . 100
Tableau 20 – Prise en charge des rôles génériques . 101
Tableau 21 – Conformité à la distribution des jetons d'accès . 101
Tableau 22 – Prise en charge des rôles prédéfinis . 102
Tableau A.1 – Événements de sécurité des jetons d'accès généraux mis en
correspondance selon l'IEC 62351-14 . 103
Tableau A.2 – Événements de sécurité des jetons d'accès spécifiques des profils A, B
et C mis en correspondance selon l'IEC 62351-14 . 104
Tableau A.3 – Journaux des événements de sécurité liés à l'interaction avec le service
backend . 104
Tableau A.4 – Journaux des événements de sécurité liés à l'ingénierie et à la
maintenance de RBAC . 105
Tableau B.1 – Liste d'affectations rôle-permission prédéfinies (version 2011) . 107
Tableau B.2 – Liste d'affectations rôle-permission prédéfinies (version 2021) . 108
Tableau C.1 – Affectation de permission . 110

COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
Gestion des systèmes de puissance
et échanges d'informations associés -
Sécurité des communications et des données -
Partie 8: Contrôle d'accès basé sur les rôles pour la gestion
de systèmes de puissance
AVANT-PROPOS
1) La Commission Électrotechnique Internationale (IEC) est une organisation mondiale de normalisation composée
de l'ensemble des comités électrotechniques nationaux (Comités nationaux de l'IEC). L'IEC a pour objet de
favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de
l'électricité et de l'électronique. À cet effet, l'IEC – entre autres activités – publie des Normes internationales,
des Spécifications techniques, des Rapports techniques, des Spécifications accessibles au public (PAS) et des
Guides (ci-après dénommés "Publication(s) de l'IEC"). Leur élaboration est confiée à des comités d'études, aux
travaux desquels tout Comité national intéressé par le sujet traité peut participer. Les organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'IEC, participent également aux
travaux. L'IEC collabore étroitement avec l'Organisation Internationale de Normalisation (ISO), selon des
conditions fixées par accord entre les deux organisations.
2) Les décisions ou accords officiels de l'IEC concernant les questions techniques représentent, dans la mesure du
possible, un accord international sur les sujets étudiés, étant donné que les Comités nationaux de l'IEC intéressés
sont représentés dans chaque comité d'études.
3) Les Publications de l'IEC se présentent sous la forme de recommandations internationales et sont agréées
comme telles par les Comités nationaux de l'IEC. Tous les efforts raisonnables sont entrepris afin que l'IEC
s'assure de l'exactitude du contenu technique de ses publications; l'IEC ne peut pas être tenue responsable de
l'éventuelle mauvaise utilisation ou interprétation qui en est faite par un quelconque utilisateur final.
4) Dans le but d'encourager l'uniformité internationale, les Comités nationaux de l'IEC s'engagent, dans toute la
mesure possible, à appliquer de façon transparente les Publications de l'IEC dans leurs publications nationales
et régionales. Toutes divergences entre toutes Publications de l'IEC et toutes publications nationales ou
régionales correspondantes doivent être indiquées en termes clairs dans ces dernières.
5) L'IEC elle-même ne fournit aucune attestation de conformité. Des organismes de certification indépendants
fournissent des services d'évaluation de conformité et, dans certains secteurs, accèdent aux marques de
conformité de l'IEC. L'IEC n'est responsable d'aucun des services effectués par les organismes de certification
indépendants.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à l'IEC, à ses administrateurs, employés, auxiliaires ou mandataires,
y compris ses experts particuliers et les membres de ses comités d'études et des Comités nationaux de l'IEC,
pour tout préjudice causé en cas de dommages corporels et matériels, ou de tout autre dommage de quelque
nature que ce soit, directe ou indirecte, ou pour supporter les coûts (y compris les frais de justice) et les dépenses
découlant de la publication ou de l'utilisation de cette Publication de l'IEC ou de toute autre Publication de l'IEC,
ou au crédit qui lui est accordé.
8) L'attention est attirée sur les références normatives citées dans cette publication. L'utilisation de publications
référencées est obligatoire pour une application correcte de la présente publication.
9) L'IEC attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation d'un
ou de plusieurs brevets. L'IEC ne prend pas position quant à la preuve, à la validité et à l'applicabilité de tout
droit de brevet revendiqué à cet égard. À la date de publication du présent document, l'IEC avait reçu notification
qu'un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois, il y a lieu d'avertir les
responsables de la mise en application du présent document que des informations plus récentes sont
susceptibles de figurer dans la base de données de brevets, disponible à l'adresse https://patents.iec.ch. L'IEC
ne saurait être tenue pour responsable de ne pas avoir identifié de tels droits de brevets.
L'IEC 62351-8 a été établie par le comité d'études 57 de l'IEC: Gestion des systèmes de
puissance et échanges d'informations associés. Il s'agit d'une Norme internationale.
Cette deuxième édition annule et remplace la première édition parue en 2020. Cette édition
constitue une révision technique.
Cette édition inclut les modifications techniques majeures suivantes par rapport à l'édition
précédente:
a) Suppression de la mise en correspondance des rôles avec les permissions pour les objets
selon le modèle de données et/ou le protocole cible pour permettre d'autres mises en
correspondance que celles de l'IEC 61850. La mise en correspondance est déléguée à des
documents distincts;
b) Spécification du traitement d'une combinaison de rôles et de permissions en tant
qu'operationSet pour permettre des affectations plus fines aux objets;
c) Spécification d'une affectation simplifiée des rôles pour traiter plus efficacement les
situations dans lesquelles les rôles sont utilisés en relation avec différents modèles de
données, y compris des exemples;
d) Inclusion d'un nouveau profil pour permettre de récupérer des informations RBAC à partir
de référentiels LDAP;
e) Définition d'événements de sécurité spécifiques dans l'ensemble du document;
f) Alignement de la terminologie et renforcement avec des exemples.
Le texte de cette Norme internationale est issu des documents suivants:
Projet Rapport de vote
57/2882/FDIS 57/2921/RVD
Le rapport de vote indiqué dans le tableau ci-dessus donne toute information sur le vote ayant
abouti à son approbation.
La langue employée pour l'élaboration de cette Norme internationale est l'anglais.
Ce document a été rédigé selon les Directives ISO/IEC, Partie 2, il a été développé selon les
Directives ISO/IEC, Partie 1 et les Directives ISO/IEC, Supplément IEC, disponibles sous
www.iec.ch/members_experts/refdocs. Les principaux types de documents développés par
l'IEC sont décrits plus en détail sous www.iec.ch/publications.
Les destinataires du présent document sont invités à présenter, avec leurs observations, la
notification des droits de propriété dont ils auraient éventuellement connaissance et à fournir
une documentation explicative.
Le présent document comprend des composants de code, c'est-à-dire des composants destinés
à être directement traités par un ordinateur. Les éléments de code sont représentés par du
texte placé entre les marqueurs et , ou sont clairement
identifiés en tant qu'éléments de code dans le présent document.
Sinon, ils sont clairement indiqués dans le présent document comme composants de code.
L'achat du présent document IEC est accompagné d'une licence de copyright permettant à
l'acheteur de vendre des logiciels contenant les composants de code du présent document aux
utilisateurs finaux, directement ou par l'intermédiaire de distributeurs soumis aux conditions de
licence des logiciels IEC, qui peuvent être consultées à l'adresse: http://www.iec.ch/CCv1.
Dans le cas d'une divergence entre le document les composants de code, les composants de
code prévalent.
Dans le présent document, les caractères d'imprimerie suivants sont utilisés:
Codage en ASN.1 ou XACML: couriernew
Une liste de toutes les parties de la série IEC 62351, publiées sous le titre général Gestion des
systèmes de puissance et échanges d'informations associés, se trouve sur le site web de l'IEC.
Le comité a décidé que le contenu de ce document ne sera pas modifié avant la date de stabilité
indiquée sur le site web de l'IEC sous webstore.iec.ch dans les données relatives au document
recherché. À cette date, le document sera
– reconduit,
– supprimé, ou
– révisé.
INTRODUCTION
Le présent document est une norme qui fournit les exigences relatives au contrôle d'accès dans
les systèmes de puissance. L'environnement de systèmes de puissance pris en charge par le
présent document est à l'échelle de l'entreprise et s'étend au-delà des limites traditionnelles
pour comprendre les fournisseurs externes, les prestataires et les autres partenaires
énergétiques. Les éléments moteurs sont la libéralisation du secteur énergétique pour
comprendre davantage de parties prenantes, la décentralisation progressive de la production
d'énergie et le besoin de contrôle d'accès aux données sensibles relatives aux ressources et
aux parties prenantes.
Le secteur des systèmes de puissance améliore de manière continue la fourniture d'énergie en
tirant profit des avancées technologiques des applications informatiques. Les opérateurs
d'entreprises d'électricité, les acheteurs d'énergie et les utilisateurs finaux accèdent de plus en
plus à de multiples applications lorsqu'il s'agit de fournir, transmettre et consommer de l'énergie
de manière personnalisée. Ces applications disparates sont naturellement raccordées à une
infrastructure commune de réseaux qui prend généralement en charge les dispositifs de
protection, les protocoles d'automatisation de poste, les protocoles entre postes, les accès à
distance et les services interentreprises. Par conséquent, les accès sécurisés à ces
applications distribuées et souvent couplées de manière souple sont encore plus importants
que les accès à une application en cours d'exécution sur un dispositif autonome.
L'accès sécurisé aux applications informatiques implique l'authentification de l'utilisateur pour
l'application. Après l'authentification, les types d'interactions que cet utilisateur peut avoir avec
l'application sont déterminés. L'utilisation de mécanismes locaux d'autorisation engendre une
multitude d'approches disparates difficiles à gérer de manière uniforme à tous les niveaux d'une
entreprise de systèmes de puissance. Chaque application décide, avec sa propre logique, du
processus d'autorisation. Cependant, si les applications peuvent utiliser un réseau en vue de
faciliter la gestion de l'accès, une base de données peut être utilisée comme une source de
confiance de groupe d'utilisateurs ou d'affiliation de rôle. Par conséquent, l'accès à une base
partagée d'utilisateurs peut être commandé de manière centrale. Chaque application peut
ensuite examiner les permissions énumérées pour un sujet et le rôle correspondant et
déterminer leur niveau d'autorisation.
Le présent document définit les contrôles d'accès basés sur les rôles (RBAC – role-based
access control) pour les usages à tous les niveaux d'une entreprise dans les systèmes de
puissance. Il prend en charge une architecture distribuée ou orientée service dans laquelle la
sécurité est un service distribué et les applications sont les consommatrices des services
distribués.
Dans le présent document, le rôle d'un utilisateur est contenu dans une structure de données,
appelée "jeton d'accès" pour cet utilisateur et est fourni à la ressource à laquelle il accède. Les
jetons d'accès sont créés et gérés par un outil de gestion d'identités (éventuellement fédéré).
Tous les jetons d'accès ont une durée de vie et sont soumis à expiration. Avant la vérification
du jeton d'accès proprement dit, l'utilisateur qui tente d'obtenir l'accès est authentifié par la
ressource. La ressource a une relation de confiance avec la gestion du jeton d'accès. Le jeton
d'accès peut être fourni en tant qu'objet autonome par l'utilisateur ou un référentiel central, ou
en tant que structure de données par un référentiel central. Plus précisément, le jeton d'accès
autonome permet de vérifier localement la validité du jeton d'accès sur des sites distants sans
qu'il soit nécessaire d'accéder à un référentiel centralisé. Pour assurer la disponibilité des
informations dans le référentiel, la redondance peut être envisagée. À noter que les concepts
de redondance n'entrent pas dans le champ d'application du présent document.
Différents formats de jetons d'accès sont pris en charge comme cinq profils définis. Ces jetons
d'accès peuvent être liés à un transport spécifique ou à une application spécifique
conjointement avec différents types de référentiels, contenant les jetons d'accès. Les
informations contenues permettant la migration d'un profil à un autre sont communes à tous les
profils.
Étant donné que le système RBAC est en cours d'adoption pour plusieurs protocoles et modèles
de données, le présent document a été modifié en conséquence. Dans sa version actuelle, il
se concentre sur la définition générale de RBAC, sur les rôles obligatoires à prendre en charge
et sur les options d'affectation des rôles aux permissions. L'affectation réelle des rôles aux
permissions et, par conséquent, la liaison des informations relatives au RBAC avec les objets
sont traitées dans les documents de référence, qui se rapportent directement au modèle de
données cible. La définition existante des rôles et permissions spécifiques à l'IEC 61850 a été
déplacée vers l'IEC 61850-90-19. De même pour l'IEC 60807-5-101/-104, les spécificités sont
traitées dans l'IEC 60870-5-7:2025. De plus, les spécificités de l'IEEE 1815 sont traitées dans
le contexte de DNP3SAv6. Le présent document fournit des informations sur l'affectation des
rôles et des permissions des versions précédentes du document dans l'Annexe B.
La présente norme est maintenue. Les questions techniques identifiées après publication sont
traitées par le biais de la base de données TISSUE afin de conserver l'exactitude et
l'interopérabilité. Les questions techniques approuvées sont publiées en tant que document
INF et peuvent être traitées ultérieurement conformément aux directives de l'IEC.

1 Domaine d'application
1.1 Généralités
La présente partie de l'IEC 62351 a pour objet de faciliter le contrôle d'accès basé sur les rôles
(RBAC) pour la gestion de systèmes de puissance. Le RBAC attribue des utilisateurs humains,
des systèmes automatisés et des applications logicielles (appelés "sujets" dans le présent
document) aux "rôles" spécifiés et limite leur accès à ces ressources uniquement, que les
politiques de sécurité identifient comme nécessaires à leurs rôles.
Les systèmes électriques de puissance étant de plus en plus automatisés et les préoccupations
relatives à la cybersécurité étant de plus en plus importantes, il est de plus en plus critique
d'assurer la restriction de l'accès aux données (lecture, écriture, contrôle, etc.). Comme pour
beaucoup d'aspects liés à la sécurité, le RBAC n'est pas uniquement une technologie; il s'agit
d'une manière de diriger une entreprise. Le RBAC n'est pas un concept nouveau; en réalité, il
est utilisé par de nombreux systèmes d'exploitation pour contrôler l'accès aux ressources de
systèmes. Le RBAC fournit notamment une alternative au modèle tout ou rien de super
utilisateur dans lequel tous les sujets ont accès à toutes les données, y compris aux
commandes de contrôle.
Le RBAC est une méthode primaire pour satisfaire au principe de sécurité de moindre privilège,
qui indique qu'il convient qu'aucun sujet ne se voit attribué plus de permissions que nécessaire
pour effectuer la tâche affectée audit sujet. Avec le RBAC, l'autorisation est distincte de
l'authentification. Le RBAC permet à une organisation de subdiviser les capacités des super-
utilisateurs et de les regrouper dans des comptes d'utilisateurs spéciaux, appelés rôles, pour
les attribuer à des personnes spécifiques en fonction des responsabilités qui leur sont
associées. Cette sous-division permet aux politiques de sécurité de déterminer les personnes
ou les systèmes qui ont accès aux données dans d'autres systèmes. Le RBAC fournit ainsi un
moyen de réattribuer des contrôles de systèmes comme cela est défini par la politique
organisationnelle. Le RBAC peut notamment protéger des opérations sensibles de systèmes
contre des actions commises par inadvertance (ou délibérées) par des utilisateurs non
autorisés. Cependant, le RBAC ne se limite clairement pas aux utilisateurs humains; il
s'applique tout aussi bien aux systèmes automatisés qu'aux applications logicielles,
c'est-à-dire, aux parties logicielles qui fonctionnent indépendamment des interactions avec
l'utilisateur.
Les interactions suivantes relèvent du domaine d'application:
– accès local (raccordé directement) à l'objet par un utilisateur humain, un agent ordinateur
automatisé local, ou à l'aide de l'IHM ou du panneau intégré(e) aux objets;
– accès à distance (par ligne commutée ou support sans fil) à l'objet par un utilisateur humain;
– accès à distance (par ligne commutée ou support sans fil) à l'objet par un agent ordinateur
automatisé distant, par exemple, un autre objet dans un autre poste, une ressource
d'énergie distribuée dans l'installation d'un utilisateur final, ou une application centrale de
contrôle.
Tandis que le
...