ISO/IEC 29146:2024
(Main)Information technology — Security techniques — A framework for access management
Information technology — Security techniques — A framework for access management
This document defines and establishes a framework for access management (AM) and the secure management of the process to access information and information and communications technologies (ICT) resources, associated with the accountability of a subject within some contexts. This document provides concepts, terms and definitions applicable to distributed access management techniques in network environments. This document also provides explanations about related architecture, components and management functions. The subjects involved in access management can be uniquely recognized to access information systems, as defined in the ISO/IEC 24760 series. The nature and qualities of physical access control involved in access management systems are outside the scope of this document.
Technologies de l'information — Techniques de sécurité — Cadre pour la gestion de l'accès
Le présent document définit et établit un cadre pour la gestion de l'accès (AM, access management) et la gestion sécurisée du processus d'accès à l'information et aux ressources des technologies de l'information et de la communication (TIC), associé à la responsabilité d'un sujet dans certains contextes. Le présent document fournit des concepts, des termes et des définitions applicables aux techniques de gestion d'accès distribuée dans des environnements en réseau. Le présent document fournit également des explications concernant l'architecture, les composants et les fonctions de gestion associés. Les sujets impliqués dans la gestion d'accès peuvent être reconnus de manière unique pour accéder aux systèmes d'information, tel que défini dans la série ISO/IEC 24760. La nature et les qualités du contrôle d'accès physique intervenant dans les systèmes de gestion d'accès ne relèvent pas du domaine d'application du présent document.
General Information
- Status
- Published
- Publication Date
- 18-Jan-2024
- Current Stage
- 6060 - International Standard published
- Start Date
- 19-Jan-2024
- Due Date
- 04-Nov-2024
- Completion Date
- 19-Jan-2024
Relations
- Effective Date
- 05-Nov-2022
- Effective Date
- 05-Nov-2022
Overview
ISO/IEC 29146:2024 - "Information technology - Security techniques - A framework for access management" defines a comprehensive framework for access management (AM) in distributed networked environments. The standard explains concepts, terms and definitions, describes a reference architecture and core components (authentication endpoints, policy decision point (PDP), policy enforcement point (PEP), policy information point (PIP), policy administration point (PAP)), and sets out management functions and processes for secure control of access to ICT resources. Physical access control is explicitly out of scope.
Key topics and requirements
- Access control model and policies: Framework for defining authorization policies, attributes (subject, resource, environment) and models used to govern access decisions.
- Identity and authentication linkage: Access management relies on underlying identity management (see ISO/IEC 24760 series) and entity authentication assurances (ISO/IEC 29115).
- Access tokens: Definition and role of trusted objects that encapsulate authority for a subject to access resources; issued by PDP and enforced by PEP.
- Reference architecture and components: Clear roles and interactions for endpoints, PDP, PEP, PIP, PAP and additional service components for subject-centric and enterprise-centric implementations.
- Management functions and processes: Authorization, privilege management, policy-related attribute management, monitoring, alarm management and audit/validation of AMS.
- Federated access control: Considerations for cross-organization collaborations and federated authorization.
- Operational concerns: Threats, control objectives, validation of the access management framework and ongoing maintenance requirements.
Applications and practical value
ISO/IEC 29146:2024 is practical for organizations designing, implementing or evaluating an Access Management System (AMS) in on-premises, cloud or hybrid environments. Typical uses include:
- Designing policy-driven IAM solutions and authorization flows.
- Integrating identity services with access control for distributed applications and APIs.
- Implementing access tokens and secure enforcement points in microservices and cloud platforms.
- Defining privilege lifecycle and authorization processes for enterprise systems.
- Validating and auditing AMS behavior, monitoring and alarm handling for security operations.
Who should use this standard
- Security architects and engineers
- Identity & Access Management (IAM) practitioners
- System and solution integrators building authorization services
- Compliance officers and auditors assessing access controls
- Vendors of access management and security products
Related standards
- ISO/IEC 24760 series - framework for identity management (terminology and concepts)
- ISO/IEC 29115 - entity authentication assurance framework
Keywords: ISO/IEC 29146:2024, access management, access control, access token, PDP, PEP, PIP, IAM, authorization, privilege management, federated access.
Buy Documents
ISO/IEC 29146:2024 - Information technology — Security techniques — A framework for access management Released:19. 01. 2024
ISO/IEC 29146:2024 - Technologies de l'information — Techniques de sécurité — Cadre pour la gestion de l'accès
Get Certified
Connect with accredited certification bodies for this standard
BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.
Bureau Veritas
Bureau Veritas is a world leader in laboratory testing, inspection and certification services.
DNV
DNV is an independent assurance and risk management provider.
Sponsored listings
Frequently Asked Questions
ISO/IEC 29146:2024 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology — Security techniques — A framework for access management". This standard covers: This document defines and establishes a framework for access management (AM) and the secure management of the process to access information and information and communications technologies (ICT) resources, associated with the accountability of a subject within some contexts. This document provides concepts, terms and definitions applicable to distributed access management techniques in network environments. This document also provides explanations about related architecture, components and management functions. The subjects involved in access management can be uniquely recognized to access information systems, as defined in the ISO/IEC 24760 series. The nature and qualities of physical access control involved in access management systems are outside the scope of this document.
This document defines and establishes a framework for access management (AM) and the secure management of the process to access information and information and communications technologies (ICT) resources, associated with the accountability of a subject within some contexts. This document provides concepts, terms and definitions applicable to distributed access management techniques in network environments. This document also provides explanations about related architecture, components and management functions. The subjects involved in access management can be uniquely recognized to access information systems, as defined in the ISO/IEC 24760 series. The nature and qualities of physical access control involved in access management systems are outside the scope of this document.
ISO/IEC 29146:2024 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 29146:2024 has the following relationships with other standards: It is inter standard links to ISO/IEC 29146:2016/Amd 1:2022, ISO/IEC 29146:2016. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO/IEC 29146:2024 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
International
Standard
ISO/IEC 29146
Second edition
Information technology — Security
2024-01
techniques — A framework for
access management
Technologies de l'information — Techniques de sécurité — Cadre
pour gestion d'accès
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Concepts . 5
5.1 A model for controlling access to resources .5
5.1.1 Overview .5
5.1.2 Relationship between identity management system and access management
system .6
5.1.3 Security characteristics of the access method .7
5.2 Relationships between logical and physical access control .7
5.3 Access management system functions and processes .8
5.3.1 Overview .8
5.3.2 Access control policy .8
5.3.3 Privilege management.9
5.3.4 Policy-related attribute information management .10
5.3.5 Authorization .11
5.3.6 Monitoring management . 12
5.3.7 Alarm management . 12
5.3.8 Federated access control . 13
6 Reference architecture . 14
6.1 Overview .14
6.2 Basic components of an access management system . 15
6.2.1 Authentication endpoint . 15
6.2.2 Policy decision point . 15
6.2.3 Policy information point . 15
6.2.4 Policy administration point .16
6.2.5 Policy enforcement point .16
6.3 Additional service components .16
6.3.1 General .16
6.3.2 Subject centric implementation .16
6.3.3 Enterprise centric implementation .18
7 Additional requirements and concerns . 19
7.1 Access to administrative information .19
7.2 AMS models and policy issues .19
7.2.1 Access control models .19
7.2.2 Policies in access management .19
7.3 L egal and regulatory requirements. 20
8 Practice .20
8.1 Processes . 20
8.1.1 Authorization process . 20
8.1.2 Privilege management process . 20
8.2 Threats .21
8.3 Control objectives . 22
8.3.1 General . 22
8.3.2 Validating the access management framework . 22
8.3.3 Validating the access management system .24
8.3.4 Validating the maintenance of an implemented AMS . 28
Annex A (informative) Common access control models .31
© ISO/IEC 2024 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take 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, ISO and IEC had not
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 www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
This second edition cancels and replaces the first edition (ISO/IEC 29146:2016), of which it constitutes a
minor revision. It also incorporates the Amendment ISO/IEC 29146:2016/Amd.1:2022. The changes are as
follows:
— the text has been editorially revised and normative references updated.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
© ISO/IEC 2024 – All rights reserved
iv
Introduction
Management of information security is a complex task that is based primarily on a risk-based approach and
that is supported by several security techniques. The complexity is handled by several supporting systems
that can automatically apply a set of rules or policies consistently.
Within the management of information security, access management plays a key role in the administration
of the relationships between the accessing party (subjects that can be human or non-human entities) and the
information technology resources. With the development of the Internet, information technology resources
can also be located over distributed networks. The management of access is expected to comply to a policy
and to have common terms and models defined in a framework.
Identity management is also an important part of access management. Access management is mediated
through the identification and authentication of parties that seek to access information technology
resources. Access management relies on the existence of an underlying identity management system.
A framework for access management is one part of an overall identity and access management framework.
The other part is the framework for identity management, which is defined in the ISO/IEC 24760 series.
This document describes the concepts, actors, components, reference architecture, functional requirements
and the practice of an access control framework.
The document focuses mainly on the access control for a single organization. It provides additional
considerations for access control in collaborative arrangements across multiple organizations. The
document includes examples of access control models.
© ISO/IEC 2024 – All rights reserved
v
International Standard ISO/IEC 29146:2024(en)
Information technology — Security techniques — A
framework for access management
1 Scope
This document defines and establishes a framework for access management (AM) and the secure
management of the process to access information and information and communications technologies (ICT)
resources, associated with the accountability of a subject within some contexts.
This document provides concepts, terms and definitions applicable to distributed access management
techniques in network environments.
This document also provides explanations about related architecture, components and management
functions.
The subjects involved in access management can be uniquely recognized to access information systems, as
defined in the ISO/IEC 24760 series.
The nature and qualities of physical access control involved in access management systems are outside the
scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 24760-1, Information technology — Security techniques — A framework for identity management —
Part 1: Terminology and concepts
ISO/IEC 29115, Information technology — Security techniques — Entity authentication assurance framework
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 24760-1, ISO/IEC 29115, and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
access control
granting or denying an operation to be performed on a resource (3.14)
Note 1 to entry: A primary purpose of access control is to prevent unauthorized access to information or use of
ICT resources based on the business and security requirements; that is, the application of authorization policies to
particular access requests.
Note 2 to entry: When an authenticated subject (3.15) makes a request, the resource owner will authorize (or not)
access in accordance with access policy and subject privileges.
© ISO/IEC 2024 – All rights reserved
3.2
access management
set of processes to manage access control (3.1) for a set of resources (3.14)
3.3
access token
trusted object encapsulating the authority for a subject (3.15) to access a resource (3.14)
Note 1 to entry: An access token is issued by the policy decision point (PDP) and consumed by the policy enforcement
point (PEP) for the resource.
Note 2 to entry: An access token may contain access permission information for a subject to access the resource and
identifying information for the authority of the authorization decision.
Note 3 to entry: An access token may contain information that enables its integrity to be validated.
Note 4 to entry: An access token may take a physical or a virtual form.
3.4
attribute
characteristic or property used to describe and to control access to a resource (3.14)
Note 1 to entry: The rules for accessing a resource are defined in an access control (3.1) policy which specifies the
attributes required for the granting of access by a subject (3.15) to a resource for a specific operation.
Note 2 to entry: Attributes can include subject attributes, resource attributes, environmental attributes and other
attributes used to control access as specified in the access control policy.
3.5
endpoint
location in an access management (3.2) system where an access control (3.1) function is performed
Note 1 to entry: There can be the following different types of endpoints:
— authentication endpoint, where subject (3.15) authentication is performed;
— authorization endpoint, where subject authorization is performed;
— endpoint discovery service, that searches for and locates endpoints;
— initial endpoint discovery service, used at the start of subject interactions with an access management system.
Note 2 to entry: Endpoint discovery services are commonly used in distributed and networked systems.
3.6
enterprise centric implementation
access management (3.2) conducted under the control of a policy decision point
3.7
need-to-know
security objective of keeping the subject’s (3.15) access to data resources (3.14) to the minimum necessary
for a requesting user to perform their functions
Note 1 to entry: Need-to-know is authorized at the discretion of the resource owner.
Note 2 to entry: Need-to-have is the security objective of the requester for the fulfilment of specific tasks that may be
limited at the resource owner’s discretion.
© ISO/IEC 2024 – All rights reserved
3.8
privilege
access right
permission
authorization to a subject (3.15) to access a resource (3.14)
Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request
is granted according to its access control policy. The access control policy is based on privileges and may include other
environmental factors (e.g. time-of-day, location, etc.)
Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a policy
decision point in order to grant or deny an operation that a subject is willing to perform on a resource.
Note 3 to entry: A resource may have multiple distinct privileges associated with it which correspond to various
defined levels of access. For example, a data resource could have read, write, execute and delete privileges available
for assignment to subjects. A request by a subject for access to the resource might be allowed for some levels of access
request but disallowed for other levels depending on the level of access requested and the resource privileges that
have been assigned to the subject.
3.9
role
name given to a defined set of system functions that may be performed by multiple entities
Note 1 to entry: The name is usually descriptive of the functionality.
Note 2 to entry: Entities can be but are not necessarily human subjects.
Note 3 to entry: Roles are implemented by a set of privilege (3.8) attributes to provide the necessary access to data
resources or objects.
Note 4 to entry: Subjects assigned to a role inherit the access privileges associated with the role. In operational use,
subjects will need to be authenticated as members of the role group before being allowed to perform the functions of
the role.
3.10
policy decision point
PDP
service that implements an access control policy to adjudicate requests from entities to access resources
(3.14) and provide authorization decisions for use by a policy enforcement point (3.11)
Note 1 to entry: Authorization decisions are used by a policy enforcement point to control access to a resource. An
authorization decision may be communicated through the use of an access token (3.3).
Note 2 to entry: PDP also audits the decisions in an audit trail and is able to trigger alarms.
Note 3 to entry: The term corresponds to access decision function (ADF) in ISO/IEC 10181-3. It is presumed that this
function is located over a network from the subject (3.15) and may be located over a network from the corresponding
policy enforcement point.
3.11
policy enforcement point
PEP
service that enforces the access decision by the policy decision point (3.10)
Note 1 to entry: The PEP receives authorization decisions made by the PDP and implements them in order to control
access by entities to resources (3.14). An authorization decision may be received in the form of an access token (3.3)
presented by a subject (3.15) when an access request is made.
Note 2 to entry: The term corresponds to access enforcement function (AEF) in ISO/IEC 10181-3. It is presumed that
this function is located over a network from the subject and may be located over a network from the corresponding
policy decision point.
© ISO/IEC 2024 – All rights reserved
3.12
policy administration point
PAP
service that administers access authorization policy
3.13
policy information point
PIP
service that acts as the source of attributes (3.4) that are used by a policy decision point (3.10) to make
authorization decisions
Note 1 to entry: Attributes can include resource (3.14), subject (3.15) and environment privileges (3.8)/permissions.
3.14
resource
object
physical, network, or any information asset that can be accessed for use by a subject (3.15)
3.15
subject
entity requesting access to a resource (3.14) controlled by an access control (3.1) system
3.16
security token service
STS
service that builds, signs, exchanges and issues access tokens (3.3) based on decision made by a policy
decision point (3.10)
Note 1 to entry: This service may be split into separate components.
3.17
subject centric implementation
access management (3.2) implemented as component services that are called by a subject (3.15) to acquire
the means recognized by the policy enforcement point (3.11) for accessing a resource (3.14)
Note 1 to entry: Component services may include policy decision point service, policy enforcement point service and
associated discovery services that enable the subject to locate and contact the access control (3.1) services.
4 Abbreviated terms
AA attribute authority
ABAC attribute-based access control
ACL access control list
AM access management
AMS access management system
CBAC capabilities-based access control
DAC discretionary access control
IBAC identity-based access control
ICT information and communication technology
IMS identity management system
© ISO/IEC 2024 – All rights reserved
IT information technology
MAC mandatory access control
PBAC pseudonym-based access control
PAP policy administration point
PEP policy enforcement point
PDP policy decision point
PII personally identifiable information
PIP policy information point
RBAC role-based access control
REDS resource endpoint discovery service
STS security token service
TLS transport layer security
XACML extensible access control markup language
5 Concepts
5.1 A model for controlling access to resources
5.1.1 Overview
The conceptual sequence in giving access to a resource is as follows.
a) Subject authentication is needed before giving access to a resource. However, authentication is a
separate function that is typically implemented on a session basis rather than for each access request.
b) Authorization decision to allow or deny access to the resource is made based on a policy, and an access
token is issued to convey the result of the decision.
c) Authorization enforcement is conducted on the resource based on the decision result and resource
access will be given.
Figure 1 shows this decision sequence.
Figure 1 — Access control model sequence
Subject and resource are depicted as balloons while conceptual functions are depicted as rectangles.
For the purpose of being accessed, a resource is characterized by the following:
— an identifier, either for a specific resource or for a resource class;
— one or more modes of access;
© ISO/IEC 2024 – All rights reserved
— a set of attributes associated with the modes of access and other access criteria as specified in the access
control policy.
An access management system is responsible for the administration and operation of authorizations to
access. Authorizations are supported by administrative activity which assigns and maintains resource
attributes and subject privileges in accordance with the access management policy.
Resources in IT systems are typically dynamic. They run a lifecycle from creation to destruction and this is
a continuous process.
a) Resources have a life-cycle which runs from creation to destruction.
b) Resources are continually being created, updated and destroyed.
c) Resources need to be assigned access attributes (usually at the time of creation) which will be used by
the access management system to control access by subjects to the resources. [Typically this is done by
pre-defining recognized resource types with associated access attribute templates. When a resource of
a known type is created, it inherits the access attributes of the corresponding template].
d) Resources are owned by a party which might be a person or an organization. The owner is often the
creator of the resource but not always and the ownership may change during the life of the resource.
5.1.2 Relationship between identity management system and access management system
In the model described here, the subject is authenticated using an identity management system (IMS), as
described in ISO/IEC 24760-2. The authenticated subject then requests access using the access management
system (AMS). The access management system determines whether or not to authorize the subject request
to access the resource. Subject authorization comprises two distinct activities:
— the pre-assignment of resource access privileges to subjects, and
— the granting of access to resources by subjects in operational use.
Figure 2 shows the relationship between an identity management system and an access management system.
Figure 2 — Identity management system and access management system relationship
© ISO/IEC 2024 – All rights reserved
Authentication is supported by an identity management system. In an access management system using the
IBAC model, identity is the basis for the assignment of resource access privileges to subjects and for the
authorization of resource access requests by subjects in operational use.
NOTE Granting access to a resource can require a minimum stated level of authentication assurance for the subject
which depends on the risk profile of resource. The required level depends on the identity-related risk pertaining to the
resource to be accessed. For further information on authentication level of assurance, see ISO/IEC 29115.
Authorization is provided by the access management system that supports access information management.
Implementation practice for access management systems can vary according to the architecture and the
access control model used, for example:
a) when an AMS is implemented as a Web service system, a subject may request access to a resource
without first being authenticated. In this case, the AMS will direct the subject to request the IMS to
provide authentication, and
b) when an ABAC model is adopted, there is a possibility that the subject does not require any
authentication. In this case, an anonymous entity may be allowed to go directly to the AMS, and an
authorization decision will be made based on a credential that can be validated to prove that the subject
possesses the asserted attributes.
5.1.3 Security characteristics of the access method
Consideration should be given to address the security aspects of access control systems implementation and
processes, particularly where federated architectures are employed.
For security reasons, the integrity of the access request may first require validation before it is further
processed by the access management system.
Where communication channels can be trusted, such as for private connections within an organization,
additional protection may not be needed. However, where communication channels run across public
networks or other unprotected channels, measures to protect the integrity and confidentiality of access
requests and associated data should be provided for both the access request itself (privileges, subject
authentication data, resource, requested operation, etc.) and the data sent to or received from the resource
during the period of access.
There are two approaches to establish a secure communication channel between the subject and the access
management system. The following approaches consider the time at which that secure communication
channel will be established:
a) a secure communication channel may be established before the transmission of the privileges or of the
data that will be used to obtain the privileges [e.g. by the construction of a Transport Layer Security
(TLS) session with the server supporting the resource];
b) a secure communication channel may be established after the successful transmission of the privileges
or of the data that has been used to authenticate an identifier of the subject.
In the latter case, the secure communication channel is established either after a successful authentication
exchange or after the successful acceptance of an access token; the integrity and the confidentiality keys
are derived from the authentication exchange or derived from information contained in the access token
or from information linked to the access token. Then, the transmission of the operation requested on the
resource can be made through that secure communication channel.
5.2 Relationships between logical and physical access control
This document mainly focuses on logical access control. Logical access control is supported by physical
access control.
Logical access to a resource in an enterprise system should be supported by a secure physical infrastructure
which provides an effective set of controls and actions that cannot be subverted.
© ISO/IEC 2024 – All rights reserved
For logical access to a resource hosted by an outsourced service, the outsourced service should be
accountable for its physical and logical access control so that it can be trusted by the subject.
5.3 Access management system functions and processes
5.3.1 Overview
An access management system enforces an access control policy and provides two core operational
functions:
a) to assign resource access privileges to subjects in advance of operational use; alternatively, to assign
access privileges to attributes (as in the ABAC model) and then assign attributes to subjects who inherit
the associated access privileges;
b) to use these privileges (together with other information where appropriate) to control subject access to
system resources in operational use.
In addition, an AMS provides administrative functions to support the core functions, including:
— policy management;
— policy-related access attribute management;
— monitoring and record keeping management.
Resource access policy should implement the following principles:
a) setting access attributes on a “need-to-know” basis;
b) minimalizing data access in order to restrict access to only strictly required data and minimize data
leakage and disclosure risk;
c) segregating and protecting of sensitive data;
d) protecting of PII;
e) using multifactor authentication based on the criticality and sensitivity of resource accessed.
5.3.2 Access control policy
An access management system enforces an access control policy. A number of access control models exist
(see Annex A). This document focuses on the following models which are sufficiently flexible to be suitable
for use in both centralized and distributed network environments:
— identity-based access control (IBAC) model;
— role-based access control (RBAC) model;
— attribute-based access control (ABAC) model.
Access control policy should be described in natural language or another suitable representation, e.g. a
formal language, to express the objectives for the control of access to resources, the methods and processes
for exercising the control, and any requirements for monitoring, auditing and other non-core functions.
There may be multiple access control policies within an organization. Typically, a group of resources on one
technology may be accessed under the control of a decision point responding to one policy, while access to
another group of resources developed with a different technology will be managed under a different decision
point responding to a second access control policy. Both decision points may also respond to the same access
control policy, which is recommended.
Where multiple access control systems operate within an organization and they are to be integrated into a
single system, policy differences should be reconciled and a common access control policy developed and
© ISO/IEC 2024 – All rights reserved
documented. An alternate approach can be to integrate the systems as an intra-organization federation, in
which case, the considerations and requirements described in 5.3.8 shall be applicable.
Access control is provided through mechanisms for granting or denying operations to be performed on
resources based on an access control policy.
Authorization decisions are made based on the evaluation of subject privileges and attributes against access
rules set out for the relevant resource. Rules can also include environmental attributes such as time of
day and location from which the request is made. For example, no operation can be done on the resource
between 9:00 p.m. and 7:00 a.m.
If a mandatory access control (MAC) model applies, a rule will necessarily be global to a set of resources. For
example, subjects should be cleared to “Top Secret” for any operation that they would like to perform on a
given set of resources.
NOTE As multiple rules can be applied sequentially, the order of application can affect the efficiency of the
decision process. However, the optimum ordering will depend on the relative likelihood of grant/deny access decisions
in operational use.
In general, individual rules may be implemented by means of an access control matrix associated with each
resource which contains one or more entries.
Each entry will indicate the condition(s) that a subject shall fulfil in order to perform one or more operations
on the resource. The major condition to fulfil is that the subject shall possess some privilege(s).
ABAC is the common situation where access control is based on AMS defined attributes possessed by
subjects. IBAC model, a similar IBAC model called pseudonym-based access control (PBAC) model, and RBAC
model are particular cases of ABAC where the attributes are, respectively, an identity, a pseudonymous
identity, and a role. These four models may be implemented using ACLs.
When the subject presents a capability ticket for authorization (also referred as a capability-based access
control (CBAC) model), it is necessary to verify that the capability ticket as an access token is effective for
that operation.
In access management systems that embody more than one access model, care should be taken to ensure
that policies specifying access to resources by subjects do not result in conflicting access decisions for the
same subject via different paths: a policy administration point should be able to manage various models of
ABAC, IBAC, PBAC, RBAC, or CBAC.
An access control policy should have the following characteristics:
a) be based on policy requirements common to required models in place, to protect information to meet
business requirements and for reasons of legal and regulatory compliance and intellectual property;
b) contain a policy hierarchy, based upon the common policy, from which access control rules applying to
individuals with same characteristics may be defined;
c) describe the attributes supporting a defined classification. This categorization will enable policy
interoperability and compliance across organizations;
d) describe procedures for the provisioning and management of privileges, the access control process and
exception handling.
5.3.3 Privilege management
The requirements for privilege management are defined by the access control policy as mentioned in 5.3.2.
Under identity-based access control policy, privilege management is conducted on the basis of subject
identity. IBAC policy employs mechanisms such as access control lists (ACLs) to specify the identities of those
allowed to access a resource and the types of operation on the resource that they are allowed to perform.
In the IBAC model, the granting of resource access privileges to a subject is made prior to any subject access
request, and subject identity and access privileges are added to the relevant resource ACL(s).
© ISO/IEC 2024 – All rights reserved
If an authenticated subject identity matches an identity recorded in the relevant ACL, the subject is given
access to the resource in accordance with its access privileges. Each resource has an associated ACL in which
the access privileges for the subjects that are authorized to access the resource are recorded. In the IBAC
model, the authorization decisions are made prior to any specific access request and result in the subject
and the subject access privileges being added to the relevant resource ACL(s).
In the RBAC model, a role (or roles) is assigned to each subject and is recorded in the account for the subject.
Authorization decisions are made based on the access privileges assigned to the relevant role within the
access management system. In an RBAC model, the privileges are assigned to roles not subjects. A separate
activity assigns roles to subjects. This also affects the authorization process when requesting access to
resources that is a two-step process in an RBAC model:
— authorize the access request for the role;
— authenticate the subject to be a member of the role group.
Under the ABAC model, policy-related access attributes are assigned to subjects. Authorization decisions are
based on the attributes possessed by subjects.
A subject may access resources as a member of a group, the possessor of attributes or as an individual. Role-
based, attribute-based and identity-based access control schemes can exist concurrently in an access control
system.
Privilege management comprises the following activities:
a) creating the set of privileges to be used to denote and limit the types of operation that may be performed
on resources;
b) establishing the rules specifying the assignment of privileges in accordance with the access control
policy and the access control model employed, e.g. assignment to identities, roles, capabilities or other
defined attributes;
c) the update and revocation of privileges and identity attributes.
The implementation of access control policy results from the assignment of resource access privileges to
subjects, roles, groups, etc. Privileges should be assigned on a “need-to-know” basis, granting the lowest
level of privilege consistent with the subject being able to perform the relevant activity.
NOTE Privileges can be assigned to both human subjects and non-human subjects. For example, when a device or
a service is added to a network, it can be assigned resource access privileges.
5.3.4 Policy-related attribute information management
Management of information for setting of privileges to attributes is an administrative activity as illustrated
in Figure 5.
This kind of information is:
a) obtained from various sources including attribute authorities, resources and the environment;
b) managed through the policy administration point (PAP);
c) stored in the policy information point (PIP).
The resulting information is made available to the policy decision point (PDP) to control access to resources.
Attribute information is managed within an AMS in accordance with the access control policy described
previously.
In the case of an ABAC model, the policy is formulated in terms of the attributes that are used to govern
access to resources and how the attributes are mapped to resource access privileges. For an RBAC model,
the policy specifies how the resource access privileges are assigned to the various roles.
© ISO/IEC 2024 – All rights reserved
Under a DAC policy, attributes are managed by resource owners, while under a MAC policy, additional
attributes are managed by policy officers.
The PBAC model employs mechanisms such as ACLs which contain the pseudonyms of the subjects permitted
to access the resource, together with the subject access permissions for the resource. If a subject presents a
pseudonym that matches one held in the ACL, the subject may be given the right to perform the operation on
the resource, subject to its permissions and any other checks that may apply.
The IBAC model employs a similar mechanism where identities are used rather
...
Norme
internationale
ISO/IEC 29146
Deuxième édition
Technologies de l'information —
2024-01
Techniques de sécurité — Cadre
pour la gestion de l'accès
Information technology — Security techniques — A framework
for access management
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2024
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
© ISO/IEC 2024 – Tous droits réservés
ii
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 4
5 Concepts . 5
5.1 Modèle de contrôle d'accès aux ressources .5
5.1.1 Vue d'ensemble.5
5.1.2 Relation entre le système de gestion de l'identité et le système de gestion d'accès .6
5.1.3 Caractéristiques de sécurité de la méthode d'accès .7
5.2 Relations entre le contrôle d'accès logique et physique .7
5.3 Fonctions et processus du système de gestion d'accès .8
5.3.1 Vue d'ensemble.8
5.3.2 Règle de contrôle d'accès .8
5.3.3 Gestion des privilèges .10
5.3.4 Gestion des informations sur les attributs liés aux règles .11
5.3.5 Autorisation .11
5.3.6 Gestion de la surveillance . 12
5.3.7 Gestion des alarmes . 13
5.3.8 Contrôle d'accès fédéré . 13
6 Architecture de référence .15
6.1 Vue d'ensemble . 15
6.2 Composants de base d'un système de gestion d'accès . 15
6.2.1 Appareil utilisateur d'authentification . 15
6.2.2 Point de décision de règle . 15
6.2.3 Point d'information de règle .16
6.2.4 Point d'administration de règle .16
6.2.5 Point d'application de règle .16
6.3 Composants de services supplémentaires .16
6.3.1 Généralités .16
6.3.2 Mise en œuvre centrée sur le sujet .16
6.3.3 Mise en œuvre centrée sur l'entreprise .18
7 Exigences et enjeux supplémentaires . 19
7.1 Accès aux informations administratives .19
7.2 Modèles d'AMS et enjeux de règle . 20
7.2.1 Modèles de contrôle d'accès . 20
7.2.2 Règles dans la gestion d'accès . 20
7.3 Exigences légales et réglementaires .21
8 Mise en œuvre .21
8.1 Processus .21
8.1.1 Processus d'autorisation .21
8.1.2 Processus de gestion des privilèges .21
8.2 Menaces . 22
8.3 Objectifs des mesures. 23
8.3.1 Généralités . 23
8.3.2 Validation du cadre de gestion d'accès . 23
8.3.3 Validation du système de gestion d'accès. 26
8.3.4 Validation de la maintenance d'un AMS mis en œuvre . 29
Annexe A (informative) Modèles communs de contrôle d'accès .32
Bibliographie .35
© ISO/IEC 2024 – Tous droits réservés
iii
Avant-propos
L'ISO (Organisation internationale de normalisation) et l’IEC (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou
de l’IEC participent au développement de Normes internationales par l'intermédiaire des comités techniques
créés par l'organisation concernée afin de s'occuper des domaines particuliers de l'activité technique.
Les comités techniques de l'ISO et de l’IEC collaborent dans des domaines d'intérêt commun. D'autres
organisations internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et l’IEC,
participent également aux travaux.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont décrites
dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents critères
d'approbation requis pour les différents types de documents. Le présent document a été rédigé conformément
aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.iso.org/directives ou
www.iec.ch/members_experts/refdocs).
L’ISO et l’IEC attirent 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’ISO et l’IEC ne prennent 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’ISO et l'IEC n'avaient pas 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 www.iso.org/brevets et https://patents.iec.ch. L’ISO et l’IEC ne sauraient être
tenues pour responsables de ne pas avoir identifié tout ou partie de tels droits de propriété.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions spécifiques
de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion de l'ISO aux
principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au commerce
(OTC), voir www.iso.org/iso/avant-propos. Pour l'IEC, voir www.iec.ch/understanding-standards.
Le présent document a été élaboré par le comité technique mixte ISO/IEC JTC 1, Technologies de l'information,
sous-comité SC 27, Sécurité de l'information, cybersécurité et protection de la vie privée.
Cette deuxième édition annule et remplace la première édition (ISO/IEC 29146:2016), dont elle constitue
une révision mineure. Elle incorpore également l'Amendement ISO/IEC 29146:2016/Amd.1:2022. Les
modifications sont les suivantes:
— le texte a fait l'objet d'une révision éditoriale et les références normatives ont été mises à jour.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/members.html et www.iec.ch/national-committees.
© ISO/IEC 2024 – Tous droits réservés
iv
Introduction
La gestion de la sécurité de l'information est une tâche complexe qui s'appuie principalement sur une
approche de la gestion des risques et qui est soutenue par plusieurs techniques de sécurité. La complexité
est traitée par plusieurs systèmes d'appui qui peuvent appliquer automatiquement un ensemble de règles ou
de règles de manière régulière.
Dans le cadre de la gestion de la sécurité de l'information, la gestion d'accès joue un rôle clé dans
l'administration des relations entre la partie ayant accès (sujets pouvant être des entités humaines ou non)
et les ressources des technologies de l'information. Avec le développement de l'Internet, les ressources des
technologies de l'information peuvent également être situées sur des réseaux distribués. La gestion d'accès
est censée être conforme à une règle et avoir des termes et modèles communs définis dans un cadre.
La gestion de l'identité constitue également une part importante de la gestion d'accès. La gestion d'accès
s'effectue par l'identification et l'authentification des parties souhaitant accéder aux ressources des
technologies de l'information. La gestion d'accès repose sur l'existence d'un système de gestion de l'identité
sous-jacent.
Un cadre pour la gestion de l'accès constitue une partie d'un cadre général de gestion de l'identité et de
l'accès. L'autre partie est le cadre pour la gestion de l'identité, défini dans la série ISO/IEC 24760.
Le présent document décrit les concepts, les acteurs, les composants, l'architecture de référence, les
exigences fonctionnelles et la pratique d'un cadre de contrôle d'accès.
Le document se concentre principalement sur le contrôle d'accès pour un seul organisme. Il fournit des
considérations supplémentaires pour le contrôle d'accès dans les accords de collaboration entre plusieurs
organismes. Le document comprend des exemples de modèles de contrôle d'accès.
© ISO/IEC 2024 – Tous droits réservés
v
Norme internationale ISO/IEC 29146:2024(fr)
Technologies de l'information — Techniques de sécurité —
Cadre pour la gestion de l'accès
1 Domaine d'application
Le présent document définit et établit un cadre pour la gestion de l'accès (AM, access management) et la
gestion sécurisée du processus d'accès à l'information et aux ressources des technologies de l'information et
de la communication (TIC), associé à la responsabilité d'un sujet dans certains contextes.
Le présent document fournit des concepts, des termes et des définitions applicables aux techniques de
gestion d'accès distribuée dans des environnements en réseau.
Le présent document fournit également des explications concernant l'architecture, les composants et les
fonctions de gestion associés.
Les sujets impliqués dans la gestion d'accès peuvent être reconnus de manière unique pour accéder aux
systèmes d'information, tel que défini dans la série ISO/IEC 24760.
La nature et les qualités du contrôle d'accès physique intervenant dans les systèmes de gestion d'accès ne
relèvent pas du domaine d'application du présent document.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique. Pour
les références non datées, la dernière édition du document de référence s'applique (y compris les éventuels
amendements).
ISO/IEC 24760-1, Sécurité de l'information, cybersécurité et protection de la vie privée — Cadre pour la gestion
de l'identité — Partie 1: Concepts fondamentaux et terminologie
ISO/IEC 29115, Technologies de l'information — Techniques de sécurité — Cadre d'assurance de l'authentification
d'entité
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO/IEC 24760-1 et de l'ISO/IEC 29115
ainsi que les suivants, s'appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1
contrôle d'accès
autorisation ou refus d'une opération à effectuer sur une ressource (3.14)
Note 1 à l'article: Le contrôle d'accès a pour objectif principal d'empêcher l'accès non autorisé aux informations
ou l'utilisation non autorisée des ressources des TCI sur la base des exigences métier et de sécurité, c'est-à-dire
l'application des règles d'autorisation aux demandes d'accès particulières.
© ISO/IEC 2024 – Tous droits réservés
Note 2 à l'article: Lorsqu'un sujet (3.15) authentifié effectue une demande, le propriétaire de la ressource autorise (ou
non) l'accès conformément à la règle d'accès et aux privilèges du sujet.
3.2
gestion d'accès
ensemble de processus visant à gérer le contrôle d'accès (3.1) pour un ensemble de ressources (3.14)
3.3
jeton d'accès
objet de confiance qui contient l'autorité permettant à un sujet (3.15) d'accéder à une ressource (3.14)
Note 1 à l'article: Un jeton d'accès est émis par le point de décision de règle (PDP) et consommé par le point d'application
de règle (PEP) pour la ressource.
Note 2 à l'article: Un jeton d'accès peut contenir des informations relatives à l'autorisation d'accès d'un sujet à une
ressource et des informations d'identification pour l'autorité de la décision d'autorisation.
Note 3 à l'article: Un jeton d'accès peut contenir des informations permettant la validation de son intégrité.
Note 4 à l'article: Un jeton d'accès peut se présenter sous forme physique ou virtuelle.
3.4
attribut
caractéristique ou propriété utilisée pour décrire et contrôler l'accès à une ressource (3.14)
Note 1 à l'article: Les règles d'accès à une ressource sont définies dans une règle de contrôle d'accès (3.1) qui spécifie
les attributs exigés pour l'autorisation d'accès d'un sujet (3.15) à une ressource pour une opération spécifique.
Note 2 à l'article: Les attributs peuvent inclure les attributs du sujet, les attributs de la ressource, les attributs
environnementaux et d'autres attributs utilisés pour le contrôle d'accès tel que spécifié dans la règle de contrôle
d'accès.
3.5
appareil utilisateur
emplacement dans un système de gestion d'accès (3.2) où une fonction de contrôle d'accès (3.1) est effectuée
Note 1 à l'article: Les différents types d’appareils utilisateur suivants peuvent exister:
— appareil utilisateur d'authentification, où l'authentification du sujet (3.15) est effectuée;
— appareil utilisateur d'autorisation, où l'autorisation du sujet est effectuée;
— service de découverte d’appareil utilisateur, qui recherche et localise les appareils utilisateur;
— service de découverte d’appareil utilisateur initial, utilisé au début des interactions du sujet avec un système de
gestion d'accès.
Note 2 à l'article: Les services de découverte d’appareil utilisateur sont généralement utilisés dans les systèmes
distribués et en réseau.
3.6
mise en œuvre centrée sur l'entreprise
gestion d'accès (3.2) effectuée sous le contrôle d'un point de décision de règle
3.7
besoin d'en connaître
objectif de sécurité consistant à limiter l'accès du sujet (3.15) aux ressources (3.14) de données au minimum
nécessaire pour permettre à un utilisateur demandeur d'exercer ses fonctions
Note 1 à l'article: Le besoin d'en connaître est autorisé à la discrétion du propriétaire de la ressource.
Note 2 à l'article: Le besoin d'avoir est l'objectif de sécurité du demandeur pour la réalisation de tâches spécifiques
susceptibles d'être limitées à la discrétion du propriétaire de la ressource.
© ISO/IEC 2024 – Tous droits réservés
3.8
privilège
droit d'accès
autorisation
autorisation octroyée à un sujet (3.15) d'accéder à une ressource (3.14)
Note 1 à l'article: Le privilège est une condition nécessaire mais non suffisante d'accès. L'accès est permis lorsque la
demande d'accès est accordée conformément à sa règle de contrôle d'accès. La règle de contrôle d'accès est fondée sur
les privilèges et peut comprendre d'autres facteurs environnementaux (par exemple, heure, localisation, etc.).
Note 2 à l'article: Les privilèges prennent la forme de données présentées par un sujet ou obtenues pour un sujet, qui
sont utilisées par un point de décision de règle en vue d'autoriser ou de refuser une opération qu'un sujet souhaite
effectuer sur une ressource.
Note 3 à l'article: Une ressource peut être associée à plusieurs privilèges distincts qui correspondent à différents
niveaux d'accès définis. Par exemple, une ressource de données peut avoir des privilèges de lecture, d'écriture,
d'exécution et de suppression pouvant être attribués aux sujets. Une demande d'accès à la ressource par un sujet peut
être autorisée pour certains niveaux de demande d'accès mais refusée pour d'autres niveaux, selon le niveau d'accès
demandé et les privilèges de la ressource qui ont été attribués au sujet.
3.9
rôle
nom donné à un ensemble défini de fonctions système pouvant être effectuées par plusieurs entités
Note 1 à l'article: Le nom décrit généralement la fonctionnalité.
Note 2 à l'article: Les entités peuvent être mais ne sont pas nécessairement des sujets humains.
Note 3 à l'article: Les rôles sont mis en œuvre par un ensemble d'attributs de privilège (3.8) pour fournir l'accès
nécessaire aux ressources de données ou aux objets.
Note 4 à l'article: Les sujets affectés à un rôle héritent des privilèges d'accès associés à ce rôle. Dans le cadre d'une
utilisation opérationnelle, les sujets doivent être authentifiés en tant que membres du groupe de rôle avant d'être
autorisés à exécuter les fonctions du rôle.
3.10
point de décision de règle
PDP [policy decision point]
service qui met en œuvre une règle de contrôle d'accès visant à arbitrer les demandes d'accès à des ressources
(3.14) provenant d'entités et à fournir des décisions d'autorisation en vue de leur utilisation par un point
d'application de règle (3.11)
Note 1 à l'article: Les décisions d'autorisation sont utilisées par un point d'application de règle pour contrôler l'accès à
une ressource. Une décision d'autorisation peut être communiquée par l'utilisation d'un jeton d'accès (3.3).
Note 2 à l'article: Le PDP contrôle également les décisions dans une piste d'audit et est en mesure de déclencher des
alarmes.
Note 3 à l'article: Ce terme correspond à «fonction décisionnelle d'accès» (ADF) dans l'ISO/IEC 10181-3. Il est présumé
que cette fonction est située sur un réseau à partir du sujet (3.15) et qu'elle peut être située sur un réseau à partir du
point d'application de règle correspondant.
3.11
point d'application de règle
PEP [policy enforcement point]
service qui applique la décision d'accès émise par le point de décision de règle (3.10)
Note 1 à l'article: Le PEP reçoit les décisions d'autorisation prises par le PDP et les applique en vue de contrôler l'accès
des entités aux ressources (3.14). Une décision d'autorisation peut être reçue sous la forme d'un jeton d'accès (3.3)
présenté par un sujet (3.15) lorsqu'une demande d'accès est effectuée.
Note 2 à l'article: Ce terme correspond à «fonction d'application de contrôle d'accès» (AEF) dans l'ISO/IEC 10181-3.
Il est présumé que cette fonction est située sur un réseau à partir du sujet et qu'elle peut être située sur un réseau à
partir du point de décision de règle correspondant.
© ISO/IEC 2024 – Tous droits réservés
3.12
point d'administration de règle
PAP
service qui administre la règle d'autorisation des accès
3.13
point d'information de règle
PIP
service qui agit en tant que source des attributs (3.4) utilisés par un point de décision de règle (3.10) pour
prendre des décisions d'autorisation
Note 1 à l'article: Les attributs peuvent inclure les privilèges (3.8)/autorisations des ressources (3.14), des sujets (3.15)
et des environnements.
3.14
ressource
objet
actif physique, réseau ou toute information auxquels un sujet (3.15) peut avoir accès pour l'utiliser
3.15
sujet
entité demandant l'accès à une ressource (3.14) contrôlée par un système de contrôle d'accès (3.1)
3.16
service de jeton de sécurité
STS [security token service]
service qui crée, signe, échange et émet des jetons d'accès (3.3) sur la base de la décision d'un point de décision
de règle (3.10)
Note 1 à l'article: Ce service peut être divisé en plusieurs composants.
3.17
mise en œuvre centrée sur le sujet
gestion d'accès (3.2) mise en œuvre sous forme de services de composants appelés par un sujet (3.15) pour
acquérir les moyens reconnus par le point d'application de règle (3.11) afin d'accéder à une ressource (3.14)
Note 1 à l'article: Les services de composants peuvent inclure un service de point de décision de règle, un service de
point d'application de règle et les services de découverte associés permettant au sujet de localiser et de contacter les
services de contrôle d'accès (3.1).
4 Abréviations
AA autorité d'attribut
ABAC contrôle d'accès basé sur les attributs [attribute-based access control]
AM gestion d'accès [access management]
AMS système de gestion d'accès [access management system]
CBAC contrôle d'accès basé sur les capacités [capabilities-based access control]
DAC contrôle d'accès discrétionnaire [discretionary access control]
DCP données à caractère personnel
IBAC contrôle d'accès basé sur l'identité [identity-based access control]
IMS système de gestion de l'identité [identity management system]
© ISO/IEC 2024 – Tous droits réservés
LCA liste de contrôle d'accès
MAC contrôle d'accès obligatoire [mandatory access control]
PAP point d'administration de règle
PBAC contrôle d'accès basé sur le pseudonyme [pseudonym-based access control]
PDP point de décision de règle
PEP point d'application de règle [policy enforcement point]
PIP point d'information de règle
RBAC contrôle d'accès basé sur le rôle [role-based access control]
REDS service de découverte d’appareil utilisateur de ressource [resource endpoint discovery service]
STS service de jeton de sécurité [security token service]
TI technologie de l'information
TIC technologie de l'information et de la communication
TLS sécurité de la couche de transport [transport layer security]
XACML langage XML de contrôle d'accès [extensible access control markup language]
5 Concepts
5.1 Modèle de contrôle d'accès aux ressources
5.1.1 Vue d'ensemble
La séquence conceptuelle de l'octroi de l'accès à une ressource est comme suit.
a) L'authentification du sujet est nécessaire avant l'octroi de l'accès à une ressource. Toutefois,
l'authentification est une fonction distincte qui est généralement mise en œuvre sur la base d'une
session plutôt que pour chaque demande d'accès.
b) La décision d'autorisation ou de refus de l'accès à la ressource est prise sur la base d'une règle, et un
jeton d'accès est émis pour transmettre le résultat de la décision.
c) L'autorisation est appliquée sur la ressource sur la base du résultat de la décision et l'accès à la ressource
est octroyé.
La Figure 1 présente cette séquence de décision.
Figure 1 — Séquence du modèle de contrôle d'accès
Le sujet et la ressource sont représentés par des bulles et les fonctions conceptuelles par des rectangles.
© ISO/IEC 2024 – Tous droits réservés
Afin de pouvoir être accessible, une ressource est caractérisée par les éléments suivants:
— un identifiant, pour une classe spécifique ou pour une classe de ressource;
— un ou plusieurs modes d'accès;
— un ensemble d'attributs associés aux modes d'accès et à d'autres critères d'accès tels que spécifiés dans
la règle de contrôle d'accès.
Un système de gestion d'accès est responsable de l'administration et du fonctionnement des autorisations
d'accès. Les autorisations sont soutenues par l'activité d'administration qui affecte et gère les attributs des
ressources et les privilèges des sujets conformément à la règle de gestion d'accès.
Les ressources dans les systèmes informatiques sont généralement dynamiques. Elles ont un cycle de vie
allant de leur création à leur destruction dans un processus continu.
a) Les ressources ont un cycle de vie allant de leur création à leur destruction.
b) Les ressources sont créées, mises à jour et détruites de façon continue.
c) Il est nécessaire d'affecter aux ressources des attributs d'accès (généralement lors de leur création) qui
sont utilisés par le système de gestion d'accès pour contrôler l'accès des sujets aux ressources. [Pour
ce faire, des types de ressources sont généralement prédéfinis avec des modèles d'attributs d'accès
associés. À la création d'une ressource de type connu, celle-ci hérite des attributs d'accès du modèle
correspondant.]
d) Les ressources sont détenues par une partie qui peut être une personne ou un organisme. Le propriétaire
est souvent, mais pas toujours, le créateur de la ressource et la propriété est susceptible d'évoluer au
cours de la vie de la ressource.
5.1.2 Relation entre le système de gestion de l'identité et le système de gestion d'accès
Dans le modèle décrit ici, le sujet est authentifié à l'aide d'un système de gestion de l'identité (IMS), tel que
décrit dans l'ISO/IEC 24760-2. Le sujet authentifié demande ensuite l'accès à l'aide du système de gestion
d'accès (AMS). Le système de gestion d'accès détermine s'il autorise ou non la demande d'accès à la ressource
par le sujet. L'autorisation du sujet comprend deux activités distinctes:
— la pré-attribution aux sujets des privilèges d'accès aux ressources; et
— l'autorisation de l'accès aux ressources par les sujets en utilisation opérationnelle.
La Figure 2 présente la relation entre un système de gestion de l'identité et un système de gestion d'accès.
Figure 2 — Relation entre le système de gestion de l'identité et le système de gestion d'accès
© ISO/IEC 2024 – Tous droits réservés
L'authentification est soutenue par un système de gestion de l'identité. Dans un système de gestion d'accès
utilisant le modèle IBAC, l'identité est la base de l'attribution aux sujets des privilèges d'accès aux ressources
et de l'autorisation des demandes d'accès aux ressources par les sujets en utilisation opérationnelle.
NOTE L'autorisation de l'accès à une ressource peut exiger un niveau défini minimal d'assurance de
l'authentification du sujet en fonction du profil de risque de la ressource. Le niveau exigé dépend du risque lié à
l'identité relatif à la ressource faisant l'objet d'une demande d'accès. Pour de plus amples informations sur le niveau
d'assurance de l'authentification, voir l'ISO/IEC 29115.
L'autorisation est fournie par le système de gestion d'accès qui assure la gestion des informations d'accès.
La pratique de mise en œuvre pour les systèmes de gestion d'accès peut varier selon l'architecture et le
modèle de contrôle d'accès utilisés, par exemple:
a) lorsqu'un AMS est mis en œuvre en tant que système de services Web, un sujet peut demander l'accès à
une ressource sans authentification préalable. Dans ce cas, l'AMS invite le sujet à demander à l'IMS de
fournir une authentification; et
b) lorsqu'un modèle ABAC est adopté, il est possible qu'aucune authentification ne soit exigée de la part
d'un sujet. Dans ce cas, une entité anonyme peut être autorisée à s'adresser directement à l'AMS et
une décision d'autorisation est prise sur la base d'un justificatif d'identité qui peut être validé afin de
prouver que le sujet possède les attributs déclarés.
5.1.3 Caractéristiques de sécurité de la méthode d'accès
Il convient de prendre en compte les aspects liés à la sécurité de la mise en œuvre et des processus des
systèmes de contrôle d'accès, en particulier lorsque des architectures fédérées sont utilisées.
Pour des raisons de sécurité, il peut être nécessaire de d'abord valider l'intégrité de la demande d'accès
avant que celle-ci ne soit traitée par le système de gestion d'accès.
Lorsque les canaux de communication sont fiables, comme dans le cas des connexions privées au sein d'un
organisme, une protection supplémentaire peut ne pas être nécessaire. Toutefois, lorsque les canaux de
communication empruntent des réseaux publics ou d'autres canaux non protégés, il convient de prévoir des
mesures visant à protéger l'intégrité et la confidentialité des demandes d'accès et des données associées
pour la demande d'accès elle-même (privilèges, données d'authentification du sujet, ressource, opération
demandée, etc.) et pour les données envoyées à la ressource ou reçues de celle-ci pendant la période d'accès.
Il existe deux approches pour établir un canal de communication sécurisé entre le sujet et le système de
gestion d'accès. Les approches suivantes considèrent le moment auquel ce canal de communication sécurisé
est établi:
a) un canal de communication sécurisé peut être établi avant la transmission des privilèges ou des données
qui sont utilisées pour l'obtention des privilèges [par exemple, par la construction d'une session de
sécurité de la couche de transport (TLS) avec le serveur qui soutient la ressource];
b) un canal de communication peut être établi après la transmission réussie des privilèges ou des données
ayant été utilisées pour authentifier un identifiant du sujet.
Dans le dernier cas, le canal de communication sécurisé est établi après un échange d'authentification réussi
ou après l'acceptation d'un jeton d'accès; l'intégrité et les clés de confidentialité sont obtenues à partir de
l'échange d'authentification, ou à partir des informations contenues dans le jeton d'accès ou des informations
liées au jeton d'accès. Ensuite, l'opération demandée sur la ressource peut être transmise via ce canal de
communication sécurisé.
5.2 Relations entre le contrôle d'accès logique et physique
Le présent document se concentre essentiellement sur le contrôle d'accès logique. Le contrôle d'accès logique
est soutenu par le contrôle d'accès physique.
© ISO/IEC 2024 – Tous droits réservés
Il convient que l'accès logique à une ressource dans un système d'entreprise soit soutenu par une
infrastructure physique sécurisée qui fournit un ensemble efficace de mesures et d'actions ne pouvant pas
être contournées.
Lorsque l'accès logique à une ressource est hébergé par un service externalisé, il convient que le service
externalisé soit responsable du contrôle d'accès physique et logique de sorte que le sujet puisse lui faire
confiance.
5.3 Fonctions et processus du système de gestion d'accès
5.3.1 Vue d'ensemble
Un système de gestion d'accès applique une règle de contrôle d'accès et fournit deux fonctions opérationnelles
fondamentales:
a) attribuer des privilèges d'accès aux ressources aux sujets avant leur utilisation opérationnelle;
autrement, attribuer des privilèges d'accès aux attributs (comme dans le modèle ABAC) puis attribuer
les attributs aux sujets qui héritent des privilèges d'accès associés;
b) utiliser ces privilèges (ainsi que d'autres informations, le cas échéant) pour contrôler l'accès des sujets
aux ressources du système lors de l'utilisation opérationnelle.
En outre, un AMS fournit des fonctions d'administration en soutien des fonctions fondamentales, notamment:
— la gestion des règles;
— la gestion des attributs d'accès liés aux règles;
— la gestion de la surveillance et de la conservation des enregistrements.
Il convient que la règle d'accès aux ressources mette en œuvre les principes suivants:
a) établir les attributs d'accès sur la base du «besoin d'en connaître»;
b) réduire au minimum l'accès aux données afin de limiter l'accès aux seules données strictement
nécessaires et réduire au minimum la fuite de données et le risque de divulgation;
c) séparer et protéger les données sensibles;
d) protéger les DCP;
e) utiliser l'authentification multifactorielle sur la base de la criticité et de la sensibilité de la ressource
demandée.
5.3.2 Règle de contrôle d'accès
Un système de gestion d'accès applique une règle de contrôle d'accès. Il existe plusieurs modèles de contrôle
d'accès (voir Annexe A). Le présent document se concentre sur les modèles suivants qui sont suffisamment
flexibles pour convenir à l'utilisation dans des environnements en réseau centralisé et distribué:
— modèle de contrôle d'accès basé sur l'identité (IBAC);
— modèle de contrôle d'accès basé sur le rôle (RBAC);
— modèle de contrôle d'accès basé sur les attributs (ABAC).
Il convient que la règle de contrôle d'accès soit décrite dans un langage naturel ou par une autre représentation
appropriée, par exemple un langage formel, pour exprimer les objectifs du contrôle d'accès aux ressources,
les méthodes et les processus d'exercice de ce contrôle et les exigences de surveillance, d'audit et des autres
fonctions non fondamentales.
© ISO/IEC 2024 – Tous droits réservés
Il peut exister plusieurs règles de contrôle d'accès au sein d'un organisme. Généralement, un groupe
de ressources fondées sur une technologie peut être accessible sous le contrôle d'un point de décision
répondant à une règle, tandis que l'accès à un autre groupe de ressources développées à l'aide d'une
technologie différente est géré par un point de décision différent répondant à une autre règle de contrôle
d'accès. Les deux points de décision peuvent également répondre à la même règle de contrôle d'accès, ce qui
est recommandé.
Lorsque plusieurs systèmes de contrôle d'accès sont opérationnels au sein d'un organisme et qu'ils doivent
être intégrés dans un seul système, il convient d'harmoniser les différences de règle et de développer et
documenter une règle de contrôle d'accès commune. Une méthode alternative peut consister à intégrer les
systèmes en tant que fédération interne à l'organisme, auquel cas les considérations et les exigences décrites
en 5.3.8 doivent s'appliquer.
Le contrôle d'accès est fourni grâce à des mécanismes permettant d'autoriser ou de refuser les opérations à
réaliser sur les ressources sur la base d'une règle de contrôle d'accès.
Les décisions d'autorisation sont prises sur la base de l'évaluation des privilèges et des attributs du sujet
par rapport aux règles d'accès définies pour la ressource considérée. Les règles peuvent également inclure
les attributs de l'environnement tels que l'heure et la localisation depuis laquelle la demande est faite. Par
exemple, aucune opération n'est autorisée sur la ressource entre 21 h et 7 h.
En cas d'application d'un modèle de contrôle d'accès obligatoire, une règle est nécessairement générale à un
ensemble de ressources. Par exemple, il convient que les sujets soient habilités au niveau «très secret» pour
toute opération qu'ils souhaitent réaliser sur un ensemble de ressources donné.
NOTE Étant donné que plusieurs règles peuvent s'appliquer successivement, l'ordre de leur application peut avoir
une incidence sur l'efficacité du processus de décision. Toutefois, l'ordre optimal dépend de la probabilité relative des
décisions d'autorisation/de refus d'accès en utilisation opérationnelle.
En général, les règles individuelles peuvent être mises en œuvre à l'aide d'une matrice de contrôle d'accès
associée à chaque ressource qui contient une ou plusieurs entrée(s).
Chaque entrée indique la ou les condition(s) qu'un sujet doit remplir afin de réaliser une ou plusieurs
opération(s) sur la ressource. La condition principale à remplir est que le sujet doit posséder un ou plusieurs
privilège(s).
Le modèle ABAC est la situation courante où le contrôle d'accès est fondé sur des attributs définis par
l'AMS détenus par les sujets. Le modèle IBAC, un modèle IBAC similaire appelé modèle de contrôle d'accès
basé sur le pseudonyme (PBAC), et le modèle RBAC sont des cas particuliers d'ABAC où les attributs sont,
respectivement, une identité, une identité pseudonymique et un rôle. Ces quatre modèles peuvent être mis
en œuvre à l'aide de listes de contrôle d'accès (LCA).
Lorsque le sujet présente un ticket de moyen pour une autorisation (également désigné «modèle de contrôle
d'accès basé sur les capacités (CBAC)»), il est nécessaire de vérifier que le ticket de moyen est valable en tant
que jeton d'accès pour l'opération en question.
Dans les systèmes de gestion d'accès qui comprennent plusieurs modèles d'accès, il convient de veiller
à ce que les règles spécifiant l'accès aux ressources par les sujets n'entraînent pas de décisions d'accès
contradictoires pour le même sujet via différents chemins: il convient qu'un point d'administration de règle
soit capable de gérer divers modèles d'ABAC, d'IBAC, de PBAC, de RBAC, ou de CBAC.
Il convient qu'une règle de contrôle d'accès présente les caractéristiques suivantes:
a) être fondée sur des exigences de règle communes aux modèles requis en place, pour protéger les
informations afin de satisfaire aux exigences métier et pour des raisons de conformité légale et
réglementaire et de propriété intellectuelle;
b) contenir une hiérarchie de règles, sur la base de la règle commune, à partir de laquelle les règles de
contrôle d'accès applicables aux individus ayant les mêmes caractéristiques peuvent être définies;
c) décrire les attributs soutenant une classification définie. Cette catégorisation permet l'interopérabilité
et la conformité des règles entre les organismes;
© ISO/IEC 2024 – Tous droits réservés
d) décrire les procédures pour la délivrance et la gestion des privilèges, le processus de contrôle d'accès et
la gestion des exceptions.
5.3.3 Gestion des privilèges
Les exigences pour la gestion des privilèges sont définies par la règle de contrôle d'accès telle que mentionnée
en 5.3.2.
Dans le cadre d'un
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...