ISO/IEC 10181-3:1996

Information technology - Open Systems Interconnection - Security frameworks for open systems: Access control framework

Specifies a general framework for the provision of access control. The purpose of access control is to counter the threat of unauthorized operations involving a computer or communication system.

Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Cadres de sécurité pour les systèmes ouverts: Cadre de contrôle d'accès

General Information

• Status: Published
• Publication Date: 18-Sep-1996
• ICS: 35.100.01 - Open systems interconnection in general
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9093 - International Standard confirmed
• Start Date: 20-Sep-2006
• Completion Date: 30-Oct-2025

Overview

ISO/IEC 10181-3:1996 - Access control framework defines a general framework for providing access control in Open Systems Interconnection (OSI) and other open systems. Part of the ISO/IEC 10181 security frameworks (identical to ITU‑T X.812), this standard describes the goals, components, information items and architectural options needed to protect systems and objects from unauthorized operations such as unauthorized use, disclosure, modification, destruction and denial of service.

Key topics and technical elements

• Goals and threat model: purpose of access control to counter unauthorized operations and the threat classes addressed.
• Access control policies: expression categories, groups and roles, security labels, multiple-initiator policies, granularity, inheritance, precedence and default rules; policy management types (fixed, administratively imposed, user-selected) and cross‑domain policy mapping.
• Access control information (ACI): types and bindings including initiator ACI, target ACI, access request ACI, operand ACI, contextual information, and initiator-/target-/request‑bound ACIs.
• Protection of ACI: use of access control certificates and access control tokens to convey authorization data.
• Classification of mechanisms: principal schemes described are ACL (access control list), capability schemes, label‑based schemes and context‑based schemes - with their ACIs and supporting mechanisms and variations.
• Distribution and architecture: incoming, outgoing and interposed control; distribution of components across multiple security domains; forwarding of access control certificates.
• Interactions with other security services: integration with authentication, data integrity, confidentiality, audit and other access‑related services.
• Annexes: practical guidance on certificate exchange, OSI layer use, non‑unique identities, component distribution, rule‑based vs identity‑based policies, and example mechanisms.

Practical applications and users

ISO/IEC 10181-3 is targeted to:

• Security architects, system designers and network engineers who design access control services for distributed and OSI-based systems.
• Standards implementers and vendors building access control mechanisms, tokens and certificate formats.
• Enterprise security teams and auditors defining policy management, policy mapping across domains and compliance requirements.
• Researchers and educators studying canonical access control architectures and interactions with authentication, audit and confidentiality services.

Typical uses include designing interoperable access control services for distributed applications, defining policy expression and mapping for multi‑domain environments, and selecting appropriate mechanisms (ACL, capability, label or context based) for system requirements.

Related standards

• ISO/IEC 10181 family (Parts 1–7) - security frameworks for open systems
• ITU‑T Recommendation X.812 (identical text)

Keywords: ISO/IEC 10181-3, access control framework, Open Systems Interconnection, access control policies, ACL, capability, label-based, access control certificate, ACI, authentication, audit.

Standards Content (Sample)

INTERNATIONAL
ISO/IEC
STANDARD 10181-3
First edition
1996-09-I 5
Information technology - Open Systems
Interconnection - Security frameworks for
open systems: Access control framework
Technologies de I’informa tion - Inter-connexion de syst&mes
ouverts (OS/) - Cadres g&W-aux pour la s&uritb des systemes ouverts:
Cadre g&&al de contr6le d’accb
Reference number
ISO/IEC 10181-3: 1996(E)
Contents
Page
Scope .
Normative references .
........................................................................
2.1 Identical Recommendations I International Standards
..........................
Paired Recommendations I International Standards equivalent in technical content
2.2
Definitions .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Abbreviations
..............................................................................................................
5 General discussion of access control
.........................................................................................................................
Goal of access control
5.1
...........................................................................................................
52 . Basic aspects of access control
.................................................................................
Performing access control functions
5.2.1
Other access control activities .
5.2.2
AC1 forwarding .
5.2.3
.........................................................................................
Distribution of access control components
53 .
....................................................................................................
Incoming access control
5.3.1
....................................................................................................
Outgoing access control
5.3.2
..................................................................................................
Interposed access control
5.3.3
....................................
5.4 Distribution of access control components across multiple security domains
.....................................................................................................................
55 . Threats to access control
...................................................................................................................................
6 Access control policies
........................................................................................................
61 . Access control policy expression
.......................................................................................
6.1.1 Access control policy categories
...............................................................................................................
6.1.2 Groups and roles
...................................................................................................................
6.1.3 Security labels
..........................................................................
6.1.4 Multiple initiator access control policies
.............................................................................................................................
6.2 Policy management
....................................................................................................................
6.2.1 Fixed policies
...................................................................................
6.2.2 Administratively-imposed policies
.......................................................................................................
User-selected policies
6.2.3
...............................................................................................................
. Granularity and containment
..................................................................................................................................
64 . Inheritance rules
...................................................................................
Precedence among access control policy rules
.....................................................................................................
616 Default access control policy rules
......................................................................
Policy mapping through cooperating security domains
67 .
.......................................................................................................
7 Access control information and facilities
AC1 .
7.1
7.1.1 Initiator AC1 .
0 ISO/IEC 1996
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
electronic or mecRanicaI, including photocopying and
utilized in any form or by any means,
microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Gentive 20 l Switzerland
Printed in S witzerlland
ii
ISO/IEC 10181=3:1996(E)
@ ISO/IEC
........................................................................................................................
7.1.2 Target AC1
...........................................................................................................
7.1.3 Access request AC1
Operand AC1 .
7.1.4
Contextual information .
7.1.5
Initiator-bound AC1 .
7.1.6
Target-bound AC1 .
7.1.7
...............................................................................................
7.1.8 Access request-bound AC1
Protection of AC1 .
7.2
Access control certificates .
7.2.1
Access control tokens .
7.2.2
...................................................................................................................... 16
7.3 Access control facilities
........................................................................................... 16
7.3.1 Management related facilities
................................................................................................ 17
7.3.2 Operation related facilities
................................................................................................. 19
Classification of access control mechanisms
.........................................................................................................................................
8.1 Introduction
........................................................................................................................................ 20
8.2 ACL scheme
.................................................................................................................... 20
8.2.1 Basic features
8.2.2 AC1 .
.................................................................................................... 20
8.2.3 Supporting mechanisms
.................................................................................................. 21
8.2.4 Variations of this scheme
...............................................................................................................................
8.3 Capability scheme
.................................................................................................................... 22
8.3.1 Basic features
.................................................................................................................................... 22
8.3.2 AC1
.................................................................................................... 22
8.3.3 Supporting mechanisms
Variation of this scheme - Capabilities without specific operations . 22
8.3.4
............................................................................................................................
8.4 Label based scheme
Basic features .
8.4.1
AC1 .
8.4.2
Supporting mechanisms .
8.4.3
Labeled channels as targets .
8.4.4
8.5 Context based scheme .
8.5.1 Basic features .
8.5.2 AC1 .
8.5.3 Supporting mechanisms .
8.5.4 Variations of this scheme .
. . . . . . . . . . . . . .D. 25
9 Interaction with other security services and mechanisms
9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2 Data integrity
Data confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9:4 Audit
9.5 Other access-related services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
.................................................................
Annex A - Exchange of access control certificates among components
A. 1 Introduction .
Forwarding access control certificates .
A.2
.................................................................................. 27
A.3 Forwarding multiple access control certificates
A.3.1 Example .
A.3.2 Generalization .
A.3.3 Simplifications .
............................................................................................
Annex B - Access control in the OS1 reference model
B . 1 General .
Use of access control within the OS1 layers . 29
B.2
B.2.1 Use of access control at the network layer . 29
Use of access control at the transport layer . 29
B.2.2
................................................................... 29
B.2.3 Use of access control at the application layer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Annex C - Non-uniqueness of access control identities
. . .
o ISO/IEC
ISO/IEC 10181-3: 1996(E)
............................................................................................
Annex D - Distribution of access control components
D. 1 Aspects considered .
.....................................................................................................................
D.2 AEC and ADC locations
.................................................................................. 32
D.3 Interactions among access control components
..............................................................................................
Annex E - Rule-based versus identity-based policies
...............................................................
Annex F - A mechanism to support AC1 forwarding through an initiator
..................................................................................................
Annex G - Access control security service outline
iv
ISO/IEC 10181=3:1996(E)
@ ISO/IEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of IS0 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. IS0 and IEC technical committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 10181-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 21, Qpen Systems Interconnection, data management and open distributed processing, in
collaboration with ITU-T. The identical text is published as ITU-T Recommendation X.812.
ISOIIEC 10181 consists of the following parts, under the general title Information technology - Open Systems
Interconnection - Security frameworks for open systems:
- Part 1: Overview
Part 2: Authentication framework
Part 3: Access control framework
Part 4: Non-repudiation framework
- Part 5: Confidentiality framework
Part 6: Integrity framework
- Part 7: Security audit framework
Annexes A to G of this part of ISO/IEC 1018 1 are for information only.

ISO/IEC 10181=3:1996(E) o ISO/IEC
Introduction
This Recommendation I International Standard defines a general framework for the provision of access control. The
primary goal of access control is to counter the threat of unauthorized operations involving a computer or
communications system; these threats are frequently subdivided into classes known as unauthorized use, disclosure,
modification, destruction and denial of service.
vi
ISO/IEC 10181=3:1996(E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY -
OPEN SYSTEMS INTERCONNECTION -
SECURITY FRAMEWORKS FOR OPEN SYSTEMS:
ACCESS CONTROL FRAMEWORK
1 Scope
The Security Frameworks are intended to address the application of security services in an Open Systems environment,
where the term Qpen Systems is taken to include areas such as Database, Distributed Applications, ODP and OSI. The
Security Frameworks are concerned with defining the means of providing protection for systems and objects within
systems, and with the interactions between systems. The Security Frameworks are not concerned with the methodology
for constructing systems or mechanisms.
The Security Frameworks address both data elements and sequences of operations (but not protocol elements) that are
used to obtain specific security services. These security services may apply to the communicating entities of systems as
well as to data exchanged between systems, and to data managed by systems.
In the case of Access Control, accesses may either be to a system (i.e. to an entity that is the communicating part of a
system) or within a system. The information items that need to be presented to obtain the access, as well as the sequence
of operations to request the access and for notification of the results of the access, are considered to be within the scope
of the Security Frameworks. However, any information items and operations that are dependent solely on a particular
application and that are strictly concerned with local access within a system are considered to be outside the scope of the
Security Frameworks.
Many applications have requirements for security to protect against threats to resources, including information, resulting
from the interconnection of Open Systems. Some commonly known threats, together with the security services and
mechanisms that can be used to protect against them, in an OS1 environment, are described in CCITT Rec. X.800 I
IS0 7498-2.
The process of determining which uses of resources within an Open System environment are permitted and, where
appropriate, preventing unauthorized access is called access control. This Recommendation I International Standard
defines a general framework for the provision of access control services.
This Security Framework:
defines the basic concepts for access control;
a>
demonstrates the manner in which the basic concepts of access control can be special .ized to
support some
W
commonly recognized access control services and mechanisms;
defines these services and corresponding access control mechanisms;
C>
identifies functional requirements for protocols to support these access control services and mechanisms;
d)
identifies management requirements to support these access control services and mechanisms;
e)
addresses the interaction of access control services and mechanisms with other security services and
f>
mechanisms.
As with other security services, access control can be provided only within the context of a defined security policy for a
The definition of access control policies is outside the scope of this Recommendation I
particular application.
International Standard, however, some characteristics of access control policies are discussed.
details of the protocol
It is not a matter for this Recommendation I International Standard to specify exchanges which
in order to provide access control services.
may need to be performed
mechanisms to
This Recommendation I I nternational Standard does not specify particular support these access control
security management services and protocols.
services nor the details of
ITU-T Rec. X.812 (1995 E)
ISO/IEC 10181-3 : 1996 (E)
A number of different types of standard can use this framework including:
standards that incorporate the concept of access control;
a>
b) standards that specify abstract services that include access control;
standards that specify uses of an access control service;
C)
d) standards that specify the means of providing access control within an Open System environment; and
standards that specify access control mechanisms.
e)
Such standards can use this framework as follows:
-
standard types a, b, c, d, and e can use the terminology of this framework;
-
standard types b, c, d, and e can use the facilities defined in clause 7 of this framework; and
-
standard type e can be based upon the classes of mechanism defined in clause 8.
2 Normative references
The following Recommendations and International Standards contain provisions, which through reference in this text,
constitute provisions of this Recommendation I International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation I International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
21 . Identical Recommendations I International Standards
-
ITU-T Recommendation X.200 (1994) I ISOLIEC 7498- 1: 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
-
ITU-T Recommendation X.810 (1995) I ISOLIEC 10181-1:1996, Information technology - Open Systems
Interconnection - Security frameworks for open systems: Overview.
-
ITU-T Recommendation X.8 ll(l995) I ISOAEC 1018 l-2: 1996, Information technology - Open Systems
Interconnection - Security frameworks for open systems: Authentication framework.
-
ITU-T Recommendation X.880 (1994) I ISOLIEC 137 12-1: 1995, Information technology - Remote
Operations: Concepts model and notation.
Paired Recommendations I International Standards equivalent in technical content
22 .
-
CCITT Recommendation X.800 (199 l), Security Architecture for Open Systems Interconnection for
CCITT applications.
IS0 7498-2: 1989, Information processing systems - Open Systems Interconnection - Basic Reference
Model - Part 2.9 Security Architecture.
3 Definitions
For the purposes of this Recommendation I International Standard, the following definitions apply.
This Recommendation I International Standard makes use of the following terms defined in CCITT
iec. X.800 I IS0 7498-2:
access control;
a)
b) access control list;
accountability;
Cl
d) authentication;
authentication information;
e)
authorization;
2 ITU-T Rec. X.812 (1995 E)
ISO/IEC 10181-3 : 1996 (E)
g) capability;
h) identity-based security policy;
rule-based security policy;
.
security audit;
J)
security label;
k)
security policy;
1)
security service;
m>
sensitivity.
n>
32 This Recommendation I International Standard makes use of the following terms defined in ITU-T
Rec. X.810 I ISO/IEC 10181-l:
secure interaction policy;
a)
security certificate;
b)
security domain;
C>
security domain authority;
d)
security information;
e>
security policy rules;
f>
g) security token;
h) trust.
This Recommendation I International Standard makes use of the following term defined in ITU-T Rec. X.200 I
ISO/IEC 7498- 1:
real system.
34 . For the purposes of this Recommendation I International Standard, the following definitions apply:
3.4.1 access control certificate: A security certificate that contains ACI.
3.4.2 Access Control Decision Information (ADI): The portion (possibly all) of the AC1 made available to the
ADF in making a particular access control decision.
3.4.3 Access Control Decision Function (ADF): A specialized function that makes access control decisions by
applying access control policy rules to an access request, AD1 (of initiators, targets, access requests, or that retained from
prior decisions), and the context in which the access request is made.
3.4.4 Access Control Enforcement Function (AEF): A specialized function that is part of the access between
enforces the decision made by the ADF.
an initiator and a target on each access request and
Access Control Information (ACI): Any information used for access control purposes, including contextual
3.4.5
information.
3.4.6 access control policy: The set of rules that define the conditions under which an access may take place.
3.4.7 access control policy rules: Security policy rules concerning the provision of the access control service.
3.4.8 access control token: A security token that contains ACI.
3.4.9 access request: The operations and operands that form part of an attempted access.
3.4.10 access request access control decision information; access request ADI: AD1 derived from access request-
bound ACI.
3.4.11 access request access control information; access request ACI: AC1 about an access request.
3.4.12 access request-bound access control information; access request-bound ACI: AC1 bound to an access
request.
3.4.13 clearance: Initiator-bound AC1 that can be compared with security labels of targets.
ITU-T Rec. X.812 (1995 E)
ISO/IEC 10181-3 : 1996 (E)
3.4.14 contextual information: Information about or derived from the context in which an access request is made
(e.g. time of day).
3.4.15 initiator: An entity (e.g. human user or computer-based entity) that attempts to access other entities.
3.4.16 initiator access control decision information; initiator ADI: AD1 derived from initiator-bound ACI.
3.4.17 initiator access control information; initiator ACI: AC1 about an initiator.
3.4.18 initiator-bound access control information; initiator-bound ACI: AC1 bound to an initiator.
3.4.19 operand access control decision information; operand ADI: AD1 derived from operand-bound ACI.
3.4.20 operand access control information; operand ACI: AC1 about the operands of an access request.
3.4.21 operand-bound access control information; operand-bound ACI: AC1 bound to the operands of an access
request.
3.4.22 retained ADI: AD1 which has been retained by an ADF from earlier access control decisions for use in future
access control decisions.
3.4.23 target: An entity to which access may be attempted.
3.4.24 target access control decision information; target ADI: AD1 derived from target-bound ACI.
3.4.25 target access control information; target ACI: AC1 about a target.
3.4.26 target-bound access control information; target-bound ACI: AC1 bound to a target.
4 Abbreviations
AC1 Access Control Information
AD1 Access Control Decision Information
ADF Access Control Decision Function
AEF Access Control Enforcement Function
SI Security Information
SDA Security Domain Authority
5 General discussion of access control
51 0 Goal of access control
For the purpose of this Security Framework, the primary goal of access control is to counter the threat of unauthorized
operations involving a computer or communications system; these threats are frequently subdivided into classes
known as:
-
unauthorized use;
-
disclosure;
-
modification;
-
destruction; and
- denial of service.
The subgoals of this Security Framework are:
-
control of access by processes (which may be acting on behalf of humans or other processes) to data,
different processes or other computing resources;
-
control of access within a security domain or across one or more security domains;
-
control of access according to its context; for example, dependent on such factors as time of attempted
access, location of the accessor or route of access;
-
control of access that is reactive to changes in authorization during access.
4 ITU-T Rec. X.812 (1995 E)
ISO/IEC 10181-3 : 1996 (E)
52 . Basic aspects of access control
The following subclauses describe abstract access control functions largely independent of access control policies and
system designs. Access control in real systems is concerned with many types of entities, such aS:
-
physical entities (e.g. real systems);
-
logical entities (e.g. OS1 layer entities, files, organizations, and enterprises);
-
human users.
Access control in real systems can require a complex set of activities. The activities are:
-
establishing access control policy representation;
-
establishing AC1 representations;
-
allocating AC1 to elements (initiators, targets or access requests);
-
binding AC1 to elements;
-
making AD1 available to the ADF;
-
performing access control functions;
-
modification of AC1 (any time after allocating AC1 values; includes revocation);
-
revocation of ADI.
These activities can be divided into two groups:
-
the operational activities (making AD1 available to the ADF and performing access control functions);
-
and
the management activities (all the remaining activities).
Some of the activities above may be grouped as a single identifiable activity within a real system. Although some access
control activities necessarily precede others, there is often overlap among them and some activities may be performed
repeatedly.
A detailed disc s involved in performing
ussion of the notion access control functions will be presented first since all the
other activities support this one.
52.1 Performing access control functions
For the purpose of this subclause, the functions which are fundamental to access control are illustrated in Figures 5-l
and 5-2. Other functions may be necessary for the overall operation of access control. In later discussions, a variety of
ways in which these functions may be implemented are presented, including different ways of distributing the access
control functions and ACI, and different styles of communication among access control functions in the same or
cooperating security domains.
Present
Submit
Am
ACCe6S
Request
Initiator Request AEF
Target
c----- --m-s r
+
l r
I I
I
Decision TlSO6350-95/dOl
Decision
Request
I I
Figure 5-l - Illustration of fundamental access control functions
IT&T Rec. X.812 (1995 E)
ISO/IEC 10181-3 : 1996 (E)
Decision
Decision
Request
Initiator ADI Target ADI
Access Request ADI Contextual Information
ADF
c
1 Retained 1
ADI
I
Access Control TISO6360-95’dO2
Policy Rules
I
Figure 5-2 - Illustration of ADF
The basic entities and functions involved in access control are the initiator, the Access Control Enforcement
function (AEF), the Access Control Decision Function (ADF), and the target.
Initiators represent both the human beings and computer-based entities that access or attempt to access targets. Within a
real system, an initiator is represented by a computer-based entity, although the access requests of the computer-based
entity on behalf of the initiator may be further limited by the AC1 of the computer based-entity.
Targets represent computer-based or communications entities to which access is attempted or that are accessed
bY
initiators. A target may be, for example, an OS1 layer entity, a file, or a real system.
An access request represents the operations and operands that form part of an attempted access.
The AEF ensures that only allowable accesses, as determined by the ADF, are performed by the initiator on the target.
When the initiator makes a request to perform a particular access on the target, the AEF informs the ADF that a decision
is required so that a determination can be made.
In order to perform this decision, the ADF is provided with the access request (as part of the decision request) and the
following types of Access Control Decision Information (ADI):
-
initiator AD1 (AD1 derived from the AC1 bound to the initiator);
-
target AD1 (AD1 derived from the AC1 bound to the target);
-
access request AD1 (AD1 derived from the AC1 bound to the access request).
The other inputs to the ADF are the access control policy rules (from the ADF’s security domain authority), and any
contextual information needed to interpret the ADI or policy. Examples of contextual information include the location of
the initiator, the time of access, or the particular communications path in use.
Based on these inputs, and possibly from AD1 retained from prior decisions, the ADF arrives at a decision to allow or
deny the initiator’s attempted access to the target. The decision is conveyed to the AEF which then either allows the
access request to pass to the target or takes other appropriate actions.
In many situations, successive access requests by an initiator on a target are related. A typical example is in an
application that opens a connection to a peer target application process and then attempts to perform several accesses
using the same (retained) ADI. For some succeeding access requests communicated over the connection, additional ADI
may need to be provided to the ADF for it to allow the access request. In other situations, a security policy may demand
that certain related access requests between one or more initiators and one or more targets are subject to restrictions. In
such cases, the ADF may use retained AD1 from prior decisions involving multiple initiators and targets to make the
decision on a particular access request.
6 IT&T Rec. X.812 (1995 E)
ISO/IEC 10181-3 : 1996 (E)
For the purposes of this subclause, an access request involves a single interaction by an initiator with a target, if
permitted by the AEF. Although some access requests between an initiator and a target are purely independent of others,
it is often the case that two entities enter into a set of related access requests such as a query-response paradigm. In such
cases, the initiator and target roles are assumed by the entities as necessary, either simultaneously or alternately, and the
access control functions are carried out for each access request, possibly by separate AEF components, ADF
components and access control policies.
5.2.2 Other access control activities
5.2.2.1 Establishing access control policy representations
Access control policies commonly are stated in natural languages as broad principles; for example: only managers of at
least a certain rank are allowed to examine salary information of employees. The conversion of these principles into
rules is an engineering design activity that necessarily precedes the other access control activities and is not within the
scope of this Security Framework. An overview of access control policy concepts is given in clause 6.
5.2.2.2 Establishing ACI representations
In this activity, choices are made for the representation of AC1 within real systems (data structures) and for exchange
between real systems (syntaxes). A broad range of possible representations is discussed in this Security Framework. AC1
representations must be able to support the requirements of specific access control policies. Some AC1 representations
Different AC1 representations may be used for
may be appropriate both for use within and between real systems.
different purposes and among particular elements.
The chosen AC1 representations can be considered as templates for the assignment of particular AC1 values for elements
in a security domain (as discussed in the next subclause). One aspect of establishing AC1 representations is the
determination of the types and ranges of the AC1 values that may be assigned to elements in a security domain (but not
which types can be assigned to specific elements).
Representation of AC1 exchanged between real systems for access control management purposes or for AC1 exchanges
among entities and access control functions are candidates for OS1 standardization. How AC1 is represented within real
systems or for presentation to a local ADF are not matters for OS1 standardization. Protecting the exchange of AC1 is
discussed in 7.2. For OS1 applications (and, possibly, others), it is appropriate to consider AC1 representations as
attributes which consist of attribute type-attribute value pairs.
5.2.2.3 Allocating AC1 to initiators and targets
In this activity, the specific attribute types and attribute values of AC1 assigned to an element are designated by an SDA,
its agents, or other entities (e.g. resource owners). These entities may specify or modify AC1 allocations in accordance
with the security domain policy. AC1 allocated by an entity may be limited by the AC1 that has been bound to it by
another entity. The allocation of AC1 to elements is a continuing activity as new elements are added to a security
domain.
NOTE - The administrative act of granting “access rights” is sometimes referred to as authorization. This meaning is
included in the allocation of AC1 to initiators or targets.
AC1 can be either information about a single entity or information about a relationship among entities. The AC1
allocated to an initiator may be purely about that initiator, or it may be about relationships between that initiator and
particular targets, or about relationships between that initiator and possible contexts. Thus, the AC1 allocated to an
initiator may include initiator ACI, target ACI, or contextual information. Similarly, AC1 allocated to a target may
include target ACI, initiator AC1 (about one or more initiators), or contextual information.
In actual operation, AC1 must be bound to an element (see 5.2.2.4) so that an ADF that uses AD1 derived from the bound
AC1 has confidence in that information. Thus, although the allocation of AC1 to elements is a prerequisite to
constructing bound ACI, only AC1 that is bound to an element is actually present in real open systems.
5.2.2.4 Binding AC1 to initiators, targets and access requests
Binding AC1 to an element (i.e. an initiator, target or access request) creates a secure linkage between an element and the
AC1 allocated to that element. The binding provides assurance to access control functions and other elements both that
the AC1 is indeed assigned to the particular element and that no modification has occurred since the binding was made.
Binding is achieved by using an integrity service. Several binding mechanisms are possible, including some that are
dependent on the location of the element and the ACI, while others may depend on some cryptographic signing or
sealing process. The integrity of the binding of AC1 to elements needs to be protected within initiator and target systems
(e.g. by relying upon operating system functions such as file protection and process separation) and, also, in the
exchange of ACI. Since there may be several possible representations of an element’s AC1 (both within systems and
between systems), different binding mechanisms may be used for the same ACI. Under some security policies, the
confidentiality of AC1 also needs to be maintained.
ITU-T Rec. X.812 (1995 E)
ISO/IEC 10181-3 : 1996 (E)
The binding of AC1 to elements is a continuing activity as new elements are added to a security domain. An SDA, its
agents, or other allowed entities, may delete or add AC1 bindings at will in accordance with the applicable security
policy. An SDA may modify the AC1 bound to an element as needed to express changing security policy or attributes.
The bound AC1 may include validity period indicators, thereby minimizing the AC1 that may later need to be revoked.
The time at which AC1 is bound to an element and the entity that causes the binding mechanism to be invoked depends
on the type of element. Initiators will have AC1 bound to them by an SDA or its agents by the time they are able to make
accesses.
All targets will have AC1 bound to them by an SDA or its agents by the time they become accessible. Targets that are
created by an application on behalf of a user or another application will have their AC1 bound to them at the time of
creation or after their creation. The AC1 bound to such targets may be restricted by limitations in the AC1 bound to the
user or the application.
AC1 is bound to an access request by a user or application, or by an SDA or its agent on behalf of the user or application,
before the access is attempted. Again, the AC1 bound to the access request may be restricted by limitations in the AC1
bound to the user or application. It is often the case that an access request causes a new target entity to be created
(e.g. when a file is transferred between systems). Such a target’s AC1 may be specified in (or derived from) AC1 bound
to the access request.
5.2.2.5 Making AD1 available to the ADF
If allowed by the access control policy and if the binding mechanism in use permits, a subset of the AC1 bound to an
initiator or target may be selected by the initiator or target for use at the ADF in making particular access control
decisions. The AC1 bound to one element may be temporarily bound to another element, for example, when one entity
acts on behalf of another entity.
In order to perform its functions, the various ADI of Figure 5-2 must be made available to the ADF. Note that no
assumptions are made in this subclause about the physical distribution of entities, functions, or ADI, nor how any of the
inputs are made available to the ADF. Some possible relationships among entities and distributed access control
components are discussed in 5.3,5.4 and Annex D.
Three possibilities exist for initiator ADI, target AD1 or access request ADI:
AD1 may be pre-placed at one or more ADF components after allocation of AC1 values;
AD1 may be derived from bound AC1 delivered to the ADF components during the access
control process
b)
(possibly in conjunction with the attempted access);
c) AD1 may be derived from bound AC1 obtained from other sources (e.g. a Directory Service Agent).
Either the initiator or target obtains the bound AC1 [which for the ADF is indistinguishable from b)] or
the ADF obtains the bound AC1 as needed [which for the initiator or target is indistinguishable from a)].
The means through which the ADF obtains the bound AC1 and derives this AD1 is not specified. Initiator-bound AC1 is
not necessarily delivered by the initiator, target-bound AC1 is not necessarily delivered by the target, nor is acc
...

NORME
ISO/CEI
INTERNATIONALE 10181-3
Première édition
1996-09-15
Technologies de l’information -
Interconnexion de systèmes ouverts
(OSI) - Cadres de sécurité pour les
systèmes ouverts: Cadre de contrôle
d’accès
Open Sys tems In terconnection - Security
Information technology -
frameworks for open s ystems: Access control framework
Numéro de référence
lSO/CEl 10181-3:1996(F)
ISO/CEIl0181-3:1996(F)
Sommaire
Page
Domaine d’application .
Références normatives .
Recommandations 1 Normes internationales identiques .
2.1
........................................................................ 2
2.2 Paires de Recommandations 1 Normes internationales
Définitions .
Abréviations .
Discussion générale sur le contrôle d’accès .
5.1 But du contrôle d’accès .
Aspects élémentaires du contrôle d’accès . 5
5.2
Réalisation des fonctions de contrôle d’accès . 5
5.2.1
.................................................................................. 7
5.2.2 Autres activités de contrôle d’accès
............................................................................................... 9
5.2.3 Envoi de l’information ACI
Distribution des composants de contrôle d’accès .
5.3
Contrôle d’accès entrant .
5.3.1
Contrôle d’accès sortant .
5.3.2
Contrôle d’accès interposé . 11
5.3.3
....... 11
Distribution des composants de contrôle d’accès à travers des domaines de sécurité multiples.
5:5 Menaces sur le contrôle d’accès .
Politiques de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.................................................................................... 12
61 . Expression de la politique de contrôle d’accès
..................................................................... 12
6.1.1 Catégories de politiques de contrôle d’accès
6.1.2 Groupes et rôles .
6.1.3 Etiquettes de sécurité .
Politiques de contrôle de sécurité d’initiateurs multiples .
6.1.4
62 . Gestion de la politique .
6.2.1 Politiques fixes .
6.2.2 Politiques appliquées administrativement .
6.2.3 Politiques sélectionnées par l’utilisateur .
............................................................................................................................. 13
63 . Finesse et inclusion
Règles d’héritage . 13
64 .
........................................................................ 14
65 . Priorités entre règles de politique de contrôle d’accès
Règles de politique de contrôle de sécurité par défaut . 14
66 .
................................... 14
67 . Correspondance de politique par le biais de domaines de sécurité coopérants
0 ISOKEI 1996
Droits de reproduction réservés. Sauf prescription différente, 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’éditeur.
ISOKEI Copyright Office l Case postale 56 l CH-l 211 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
@ ISOKEI
ISOKEI 10181-3:1996(F)
Information de contrôle d’accès et fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 15
7.1 Information ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 15
7.1.1 Information ACI d’initiateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.2 Information ACI de cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.3 Information ACI de demande d’accès . . . . . . . . . . . .*. 15
7.1.4 Opérande de l’information ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.5 Information de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 16
7.1.6 Information ACI attachée à l’initiateur . . . . . . . . . . . . . . . .*. 16
7.1.7 Information ACI attachée à la cible . . . . . . . . . . . . .*.
7.1.8 Information ACI attachée à la demande d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Protection de l’information ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2.1 Certificats de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2.2 Jetons de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Fonctionnalités de contrôle d’accès
7.3 . 17
Fonctionnalités liées à la gestion
7.3.1 . 18
Fonctionnalités relatives à l’exploitation
7.3.2 . 18
........................................................................................ 20
Classification des mécanismes de contrôle d’accès
.........................................................................................................................................
8.1 Introduction
82 . Structure de liste ACL .
............................................................................................
8.2.1 Caractéristiques élémentaires
Information ACI .
8.2.2
Mécanismes de support .
8.2.3
Variantes de cette structure .
8.2.4
8.3 Structure de capacité .
............................................................................................ 23
8.3.1 Caractéristiques élémentaires
................................................................................................................
8.3.2 Information ACI
.....................................................................................................
8.3.3 Mécanismes de support
...............................
8.3.4 Variantes de cette structure - Capacités sans opérations spécifiques
Structure fondée sur l’étiquette .
8.4
8.4.1 Caractéristiques élémentaires .
8.4.2 Information ACI .
8.4.3 Mécanismes de support .
8.4.4 Voies étiquetées comme cibles .
Structure fondée sur le contexte .
85 .
Caractéristiques élémentaires .
8.5.1
Information ACI .
8.5.2
8.5.3 Mécanismes de support .
8.5.4 Variantes de cette structure .
.........................................................................
9 Interaction avec d’autres services et mécanismes de sécurité
91 Authentification .
Intégrité des données .
9:2
................................................................................................................
9.3 Confidentialité des données
9.4 Audit .
Autres services liés à l’accès .
95 .
..............................................................
Annexe A - Echange de certificats de contrôle d’accès entre composants
Introduction .
A. 1
.............................................................................................
A.2 Envoi des certificats de contrôle d’accès
...............................................................................
A.3 Envoi de multiples certificats de contrôle d’accès
A.3.1 Exemple .
A.3.2 Généralisation .
Simplifications . 30
A.3.3
ISOKEI 10181-3:1996(F) @ ISOKEI
- Contrôle d’accès dans le modèle de référence OS1
Annexe B .
B.l Généralités .
B.2 Utilisation du contrôle d’accès dans les couches OS1
......................................................................... 31
B.2.1 Utilisation du contrôle d’accès pour la couche réseau
....................................................... 31
B.2.2 Utilisation du contrôle d’accès pour la couche transport
................................................... 31
B.2.3 Utilisation du contrôle d’accès pour la couche application
............................................... 31
Annexe C - Non-unicité des identités de contrôle d’accès
......................................................................................
- Distribution des composants de contrôle d’accès
Annexe D .
D. 1 Aspects considérés .
D.2 Localisation des composants AEC et ADC
........................................................................................
D.3 Interactions entre composants de contrôle d’accès .
Annexe E - Politiques fondées sur les règles versus politiques fondées sur l’identité
............................................
Annexe F - Un mécanisme pour mettre en oeuvre l’envoi de l’information ACI par le biais d’un initiateur
.......... 37
Annexe G - Grandes lignes du service de sécurité de contrôle d’accès
.................................................................. 38
1v
@ ISOKEI ISOKEI 10181-3:1996(F)
Avant-propos
LIS0 (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de I’ISO ou de la CE1 participent au développement de Normes inter-
nationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de I’ISO et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 1018 l-3 a été élaborée par le comité technique
mixte ISO/CEI JTC 1, Technologies de l’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’UIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.812.
L’ISOKEI 1018 1 comprend les parties suivantes, présentées sous le titre général
Interconnexion de systèmes ouverts (OU) -
Technologies de l’information -
Cadres de sécurité pour les systèmes ouverts:
Partie 1: Présentation
- Partie 2: Cadre d’authentification
- Partie 3: Cadre de contrôle d’accès
Partie 4: Cadre de non-répudiation
- Partie 5: Cadre de confidentialité
- Partie 6: Cadre d’intégrité
- Partie 7: Cadre d’audit de sécurité
Les annexes A à G de la présente partie de l’ISO/CEI 10181 sont données uni-
quement à titre d’information.

ISOKEI 10181-3:1996(F) @ ISOKEI
Introduction
La présente Recommandation 1 Norme internationale définit un cadre général pour la fourniture du contrôle d’accès. Le
but essentiel du contrôle d’accès est de parer au risque d’opérations non autorisées au moyen d’un ordinateur ou d’un
système de communication; ces menaces sont fréquemment subdivisées en classes qui sont notamment les suivantes:
utilisation non autorisée, divulgation, modification, destruction ou déni de service.
Vl
ISOKEI 10181-3 : 1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE SYSTÈMES
OUVERTS (OSI) - CADRES DE SÉCURITÉ POUR LES SYSTÈMES OUVERTS:
CADRE DE CONTRÔLE D’ACCÈS
1 Domaine d’application
Les cadres de sécurité sont destinés à traiter l’application des services de sécurité dans l’environnement des systèmes
ouverts, où le terme systèmes ouverts est utilisé pour des domaines tels que les bases de données, les applications
distribuées, le traitement ODP et l’interconnexion OSI. Les cadres de sécurité sont destinés à définir les moyens d’oftir
la protection des systèmes et des objets au sein des systèmes, ainsi que les interactions entre systèmes. Les cadres ne
traitent pas de la méthodologie de construction des systèmes ou des mécanismes.
Les cadres couvrent à la fois les éléments de données et les séquences d’opérations (mais pas les éléments de protocole)
utilisés pour obtenir des services spécifiques de sécurité. Ces services de sécurité peuvent s’appliquer aux entités
communicantes des systèmes aussi bien qu’aux données échangées entre systèmes, et aux données gérées par les
systèmes.
Dans le cas du contrôle d’accès, les accès peuvent être destinés à un système (par exemple, vers une entité qui est la
partie communicante d’un système) ou prendre place au sein d’un système. Les éléments de données qui doivent être
présentés pour obtenir l’accès, ainsi que la séquence d’opérations de la demande et pour la notification des résultats de
l’accès, sont considérés comme faisant partie des cadres de sécurité. Cependant, tout élément de données et toute
opération qui dépend seulement d’une application et qui est strictement concerné par l’accès local au sein d’un système ne
fait pas partie du domaine d’application des cadres de sécurité.
Plusieurs applications ont des besoins de sécurité pour protéger des menaces sur des ressources, y compris l’information,
résultant de l’interconnexion des systèmes ouverts. Certaines menaces communément connues, dans un environ-
nement OSI, ainsi que les services et mécanismes de sécurité pour s’en protéger, sont décrits dans la Rec. X.800 du
CCITT 1 ISO 7498-2.
Le processus de détermination des utilisations de ressources permises dans un environnement de système ouvert et,
lorsque cela est approprié, la prévention contre un accès non autorisé est appelé contrôle d’accès. La présente
Recommandation 1 Norme internationale définit un cadre général pour la fourniture des services de contrôle d’accès.
Ce cadre de sécurité:
définit les concepts élémentaires du contrôle d’accès;
b) démontre la façon dont les concepts élémentaires du contrôle d’accès peuvent être spécialisés pour mettre
en œuvre quelques services et mécanismes d’accès communément reconnus;
définit ces services et mécanismes de contrôle d’accès correspondants;
C>
d) identifie les besoins fonctionnels des protocoles pour la mise en œuvre de ces services et mécanismes de
contrôle d’accès;
identifie les besoins de gestion afin de mettre en œuvre ces services et mécanismes de contrôle d’accès;
e>
couvre l’interaction des services
et mécanismes de contrôle d’accès avec d’autres services et mécanismes
f)
de sécurité.
Comme pour les autres services de sécurité, le contrôle d’accès peut être fourni seulement dans le contexte d’une
politique de sécurité définie pour une application particulière. La définition des politiques de contrôle d’accès ne fait pas
partie du domaine d’application de la présente Recommandation 1 Norme internationale, cependant, certaines caracté-
ristiques des politiques de contrôle d’accès sont présentées.
L’objet de la présente Recommandation 1 Norme internationale n’est pas de spécifier les détails des échanges
de
protocoles qui peuvent s’avérer nécessaires pour fournir les services de contrôle d’accès.
Rec. UIT-T X.812 (1995 F)
ISO/CEI 10181-3 : 1996 (F)
1 Norme internationale en œuvre ces
La présente Recommandation ne spécifie pas de mécanisme particulier pour mettre
services de contrôle d’accès ni les détails des services et protocoles de gestion de la sécurité.
Différents types de normes peuvent utiliser ce cadre y compris:
incorporent le concept du contrôle d’accès;
les normes qui
les normes qui spécifient les services d’accès incluant le contrôle d’accès;
les normes qui spécifient les utilisations d’un service de contrôle d’accès;
C>
spécifient les moyens de fournir le contrôle d’accès au sein d’un environnement de système
d) les normes qui
ouvert;
les normes qui spécifient les mécanismes de contrôle d’accès.
e)
De telles normes peuvent utiliser ce cadre de la façon suivante:
-
les normes de types a), b), c), d) et e) peuvent utiliser la terminologie de ce cadre;
-
les normes de types b), c), d) et e) peuvent utiliser les fonctionnalités définies dans l’article 7 de ce cadre;
-
la norme de type e) peut être fondée sur les classes de mécanismes définies dans l’article 8 de ce cadre.
2 Références normatives
Les Recommandations et les Normes internationales suivantes contiennent des dispositions qui, par suite de la référence
qui y est faite, constituent des dispositions valables pour la présente Recommandation 1 Norme internationale. Au
moment de la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à
révision, et les parties prenantes aux accords fondés sur la présente Recommandation 1 Norme internationale sont invitées
à rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de 1’UIT tient à jour une liste des Recommandations de l’UIT-T en vigueur.
21 . Recommandations 1 Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) 1 ISO/CEI 7498-l : 1994, Technologies de l’information -
Interconnexion des systèmes ouverts - Modèle de référence de base: le modèle de référence de base.
-
Recommandation UIT-T X.8 10 (1995) 1 ISOKEI 10 18 l- 1: 1996, Technologies de Z’information -
- Cadres de sécurité pour les systèmes ouverts: aperçu général.
Interconnexion des systèmes ouverts
-
Recommandation UIT-T X.8 11 (1995) 1 ISO/CEI 10 18 l-2: 1996, Technologies de I?nformation -
Interconnexion des systèmes ouverts - Cadre de sécurité pour systèmes ouverts: cadre d’authentification.
-
Recommandation UIT-T X.880 (1994) 1 ISOKEI 13712-1:1995, Technologies de I?nformation -
Opérations distantes: concepts, modèle et notation.
Paires de Recommandations 1 Normes internationales équivalentes par leur contenu technique
22 0
-
Recommandation X.800 du CCITT (1991), Architecture de sécurité pour l’interconnexion des systèmes
ouverts d’applications du CCITT.
- Interconnexion de systèmes ouverts - Modèle
ISO 7498-2: 1989, Systèmes de traitement de l’information
de référence de base - Partie 2: architecture de sécurité.
3 Définitions
Pour les besoins de la présente Recommandation 1 Norme internationale, les définitions suivantes s’appliquent.
31 La présente Recommandation 1 Norme internationale utilise les termes suivants définis dans la Rec. X.800 du
CCITT 11so 7498-2:
contrôle d’accès;
a)
b) liste de contrôle d’accès;
I
imputabilité;
c)
Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
authentification;
information d’authentification;
e>
autorisation;
g) capacité;
h) politique de sécurité fondée sur l’identité;
i) politique de sécurité fondée sur des règles;
.
audit de sécurité;
J)
k) label de sécurité;
politique de sécurité;
1)
service de sécurité;
m)
n) sensibilité.
La présente Recommandation 1 Norme internationale utilise les termes suivants définis dans la Rec. UIT-T
3.2
X.810 1 ISOKEI 11081-l:
politique d’interaction sécurisée;
certificat de sécurité;
domaine de sécurité;
autorité du domaine de sécurité;
d)
information de sécurité;
règles de politique de sécurité;
jeton de sécurité;
g>
confiance.
h)
La présente Recommandation 1 Norme internationale utilise les termes suivants définis dans la Rec. UIT-T
3.3
X.200 1 ISOKEI 7498-1:
-
réel.
système
3.4 Les définitions suivantes s’appliquent pour la présente Recommandation 1 Norme internationale:
3.4.1 certificat de contrôle d’accès: Certificat de sécurité contenant l’information ACI.
3.4.2 information de décision de contrôle d’accés (ADI)
( access control decision information): Partie
(éventuellement toute) de l’information ACI fournie à la fonction ADF pour décider d’un contrôle d’accès particulier.
3.4.3 fonction de décision de contrôle d’accés (ADF) (access control decision finction): Fonction spécialisée
prenant des décisions de contrôle d’accès par l’application des règles de la politique de contrôle d’accès à une demande
d’accès, et l’exploitation de l’information ADI et du contexte dans lequel la demande d’accès est effectuée.
3.4.4 fonction d’application de contrôle d’accès (AEF) (
access control enforcement function): Fonction
spécialisée qui, pour chaque demande d’accès, fait partie du chemin d’accès entre un initiateur et une cible et applique la
décision prise par la fonction ADF.
3.4.5 information de contrôle d’accés (ACI) ( access control information): Toute information utilisée à des fins de
contrôle d’accès, incluant l’information de contexte.
de contrôle d’accés:
3.4.6 Ensemble des règles définissant les conditions dans lesquelles l’accès peut se
dérouler.
3.4.7 régles de politique de contrôle d’accès: Règles concernant la fourniture du service de
de politique de sécurité
contrôle d’accès.
jeton de contrôle d’accés: Jeton de sécurité contenant l’information ACI.
3.4.8
3.4.9 demande d’accès: Opérations et opérandes faisant partie d’une tentative d’accès.
3.4.10 information de décision de contrôle d’accés d’une demande d’accés; demande d’accés ADI: Information
ADI dérivée d’une information ACI attachée à une demande d’accès.
3.4.11 information de contrôle d’accès d’une demande d’accès; demande d’accés ACI: Information ACI sur une
demande d’accès.
Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
à une
contrôle d’accés attachée h une demande d’actes; ACI attachée demande d’accès:
3.4.12 information de
à une demande d’accès.
Information ACI attachée
3.4.13 autorisation: Information ACI attachée à l’initiateur qui peut être comparée aux étiquettes de sécurité des
information contextuelle: Information relati .ve au contexte dans lequel la demande d’accès est effectuée (par
3.4.14
heure du jour) ou dérivant d’un tel contexte.
exemple
3.4.15 initiateur: Entité (personne ou mécanisme informatique par exemple) qui tente d’accéder à d’autres entités.
3.4.16 information de décision de contrôle d’accés d’initiateur; initiateur ADI: Information ADI dérivée de
l’information ACI attachée à l’initiateur.
3.4.17 information de contrôle d’accés d’initiateur; information ACI initiateur: Information ACI de l’initiateur.
3.4.18 information de contrôle d’accés attachée B l’initiateur; information ACI attachée à l’initiateur:
Information ACI attachée à un initiateur.
information de décision de contrôle d’accés d’opérande; information ADI d’opérande: Information ADI
3.4.19
dérivée de l’information ADI attachée à l’opérande.
3.4.20 information de contrôle d’accés d’opérande; information ACI d’opérande: Information ACI sur les
opérandes d’une demande d’accès.
information ACI attachée à l’opérande:
3.4.21 information de contrôle d’accés attachée B l’opérande;
Information ACI attachée aux opérandes d’une demande d’accès.
3.4.22 information ADI retenue: Information ADI retenue par une fonction ADF lors d’une précédente décision de
contrôle d’accès pour être utilisée dans de futures décisions de contrôle d’accès.
3.4.23 cible: Entité pour laquelle un accès peut être tenté.
3.4.24 information de décision de contrôle d’accés de cible; information ADI de cible: Information ADI dérivée
de l’information ACI attachée à la cible.
3.4.25 information de contrôle d’accés de cible; information ACI de cible: Information ACI relative à une cible.
3.4.26 information de contrôle d’accès attachée à la cible; information ACI attachée à la cible: Information ACI
attachée à la cible.
4 Abréviations
Information de contrôle d’accès (access control information)
ACI
ADI Information de décision de contrôle d’accès (access control decision information)
ADF Fonction de décision de contrôle d’accès (access control decision function)
Fonction d’application de contrôle d’accès (access control enforcement function)
AEF
SI Information de sécurité (security information)
SDA Autorité du domaine de sécurité (security domain authority)
5 Discussion générale sur le contrôle d’accès
51 l But du contrôle d’accès
Dans ce cadre de sécurité, le premier but du contrôle d’accès est d’éviter la menace d’opérations non autorisées
impliquant un ordinateur ou un système de communication; ces menaces sont fréquemment subdivisées en classes
appelées:
-
utilisation non autorisée;
- divulgation;
- modification;
-
destruction;
- reiks de- service.
4 Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
Les sous-objectifs de ce cadre de sécurité sont:
- le contrôle d’accès par les processus (qui peuvent agir pour le compte d’humains ou d’autres processus)
vers les données, les processus ou d’autres ressources de calculs;
-
le contrôle d’accès au sein d’un domaine de sécurité ou au travers de plusieurs domaines de s&.rité;
-
le contrôle d’accès en fonction de son contexte; par exemple, en fonction de facteurs comme l’heure de la
tentative d’accès, le lieu de l’accédant ou la route d’accès;
-
le contrôle d’accès réagissant aux changements dans l’autorisation lors de l’accès.
52 . Aspects élémentaires du contrôle d’accès
Les paragraphes suivants décrivent les fonctions abstraites de contrôle d’accès largement indépendantes des politiques de
contrôle d’accès et des conceptions de systèmes. Le contrôle d’accès dans les systèmes réels concerne plusieurs types
d’entités, telles que:
les entités physiques (par exemple, systèmes réels);
-
les entités logiques (par exemple, entités de couche OSI, fichiers, organisations, et entreprises);
-
les usagers.
Le contrôle d’accès dans les systèmes réels peut nécessiter un ensemble d’activités complexes:
-
établissement de la politique de contrôle d’accès;
-
établissement des représentations de l’information ACI;
-
affectation de l’information ACI aux éléments (initiateurs, cibles ou demandes d’accès);
-
rattachement de l’information ACI aux éléments;
-
mise à disposition de l’information ADI pour la fonction ADF;
-
exécution des fonctions de contrôle d’accès;
-
modification de l’information ACI (à n’importe quel moment après l’affectation des valeurs de
ACI ; y compris la révocation);
l’information
-
révocation de l’information ADI.
Ces activités peuvent être divisées en deux groupes:
-
les activités opérationnelles (mise à disposition de l’information ADI pour la fonction ADF et réalisation
des fonctions de contrôle d’accès);
-
les activités de gestion (toutes les autres activités).
Certaines activités ci-dessus peuvent être groupées dans une seule entité identifiable au sein d’un système réel. Bien que
certaines activités de contrôle d’accès précèdent nécessairement les autres, il y a souvent recouvrement et certaines
activités peuvent être réalisées à plusieurs reprises.
Une présentation détaillée des notions mises en jeu dans la réalisation des fonctions de contrôle d’accès sera
d’abord
présentée étant donné que d’autres activités les mettent en œuvre.
5.2.1 Réalisation des fonctions de contrôle d’accés
Pour ce paragraphe, les fonctions fondamentales du contrôle d’accès sont illustrées sur les Figures 5-l et 5-2. D’autres
fonctions peuvent être nécessaires pour le fonctionnement global du contrôle d’accès. Les discussions qui suivent,
présentent plusieurs façons de mettre en œuvre ces fonctions, y compris différentes façons de distribuer les fonctions de
contrôle d’accès et l’information ACI, et différents styles de communication entre les fonctions de contrôle d’accès dans
le même domaine de sécurité ou entre domaines de sécurité coopérants.
Les entités élémentaires et les fonctions mises en œuvre dans le contrôle d’accès sont l’initiateur, la fonction d’application
de contrôle d’accès (AEF), la fonction de décision de contrôle d’accès (ADF), et la cible.
Les initiateurs représentent à la fois les êtres humains et les entités liées à l’ordinateur qui accèdent ou tentent d’accéder
aux cibles. Au sein d’un système réel, un initiateur est représenté par une entité liée à l’ordinateur, bien que les demandes
d’accès de l’entité liée à l’ordinateur pour le compte de l’initiateur puissent être limitées par l’information ACI de l’entité
liée à l’ordinateur.
Rec. UIT-T X.812 (1995 F) 5
ISOKEI 10181-3 : 1996 (F)
présente la
soumet la
demande
demande
initiateur cible
d’acc&
d’accès
fonction AEF
-----w w-w--
b
I r
l
A
demande
TIS06350-95/dOl
de décision décision
fonction ADF
Figure 5-l- Illustration des fonctions fondamentales du contrôle d’accès
demande de
dkcision
dhsion
1 T
information ADI cible
initiateur AD I
information ADI information de contexte
D
fonction ADF
de demande d’accès
information
ADI
retenue
r&gles de politique
TISO636@95/d 02
de contrôle d’ac&s
T
Figure 5-2 - Illustration de la fonction ADF
Les cibles représentent des entités liées au calculateur ou des entités de communication vers lesquelles l’accès est tenté
ou bien les entités accédées par les initiateurs. Une cible peut, par exemple, être une entité de couche OSI, un fichier, ou
un système réel.
Une demande d’accès représente les opérations et les opérandes faisant partie d’une tentative d’accès.
La fonction AEF garantit que seuls les accès légitimes de l’initiateur, déterminés par la fonction ADF, sont réalisés sur la
cible. Lorsque l’initiateur effectue une demande pour réaliser un accès particulier sur la cible, la fonction AEF informe la
fonction ADF qu’une décision est requise afin de prendre une résolution.
Afin de prendre une décision, la demande d’accès (en tant que partie de la demande de décision) et les types suivants
d’information de décision de contrôle d’accès (ADI) sont fournis à la fonction ADF:
-
ADI d’initiateur (information ADI dérivée de l’information ACI attachée à l’initiateur);
-
ADI de cible (information ADI dérivée de l’information ACI attachée à la cible);
-
ADI de demande d’accès @formation ADI dérivée de l’information ACI attachée à la demande d’accès).
6 ‘Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
Les autres entrees de la fonction ADF sont les règles de la politique de contrôle d’accès (de l’autorité du domaine de
sécurité de la fonction ADF), et toute information de contexte nécessaire pour interpréter l’information ADI ou la
politique. Des exemples d’informations de contexte incluent l’emplacement de l’initiateur, l’heure d’accès, ou le chemin
particulier de communications en cours d’utilisation.
Fondée sur ces entrées, et éventuellement sur l’information ADI retenue des décisions précédentes, la fonction ADF
aboutit à une décision pour autoriser ou dénier l’accès tenté par l’initiateur sur la cible. La décision est transportée jusqu’à
la fonction AEF qui permet ensuite à la demande d’accès d’arriver jusqu’à la cible ou qui prend d’autres actions
appropriées.
Dans plusieurs cas, les demandes d’accès successives d’un initiateur sur une cible sont liées. Un exemple typique
concerne une application qui ouvre une connexion vers un processus d’application cible de même niveau et ensuite tente
de réaliser plusieurs accès en utilisant la même information ADI (retenue). Pour certaines demandes d’accès suivantes
transmises sur la connexion, il peut être nécessaire de fournir une information ADI additionnelle à la fonction ADF afin
qu’elle autorise la demande d’accès. Dans d’autres cas, une politique de sécurité peut demander que, entre un ou plusieurs
initiateurs, certaines demandes d’accès liées soient sujettes à restrictions. Dans de tels cas, la fonction ADF peut utiliser
l’information ADI retenue de décisions précédentes impliquant plusieurs initiateurs et cibles pour prendre une décision
sur une demande d’accès particulière.
Pour ce paragraphe, une demande d’accès met en jeu une seule interaction entre un initiateur et une cible, si cela est
permis par le fonction AEF. Bien que certaines demandes d’accès entre un initiateur et une cible soient simplement
indépendantes, il arrive souvent que deux entités participent à un ensemble de demandes d’accès liées tel qu’un
paradigme de question-réponse. Dans ces cas, les rôles d’initiateur et de cible sont assurés, comme requis, par les entités,
soit simultanément soit de façon alternée, et les fonctions de contrôle d’accès sont mises en œuvre pour chaque demande
d’accès, éventuellement par des composants distincts de fonction AEF, des composants de fonction ADF et des
politiques de contrôle d’accès.
5.2.2 Autres activités de contrôle d’accès
5.2.2.1 Etablissement des représentations de politique de contrôle d’accés
Les politiques de contrôle d’accès sont communément définies en langages naturels sous forme de principes généraux;
par exemple: seuls les responsables d’au moins un certain rang sont autorisés à examiner les informations salariales des
employés. La transposition de ces principes dans des règles est une activité de conception qui précède nécessairement les
autres activités de contrôle d’accès et ne fait pas partie du domaine d’application de ce cadre de sécurité. Un aperçu des
concepts de politique de contrôle d’accès est donné dans l’article 6.
5.2.2.2 Etablissement des représentations des informations ACI
Dans cette activité, sont effectués les choix pour la représentation de l’information ACI au sein de systèmes réels
(structure des données) et pour l’échange entre systèmes réels (syntaxes). Un grand domaine de représentations possibles
est présenté dans ce cadre de sécurité. Les représentations de l’information ACI doivent être en mesure de répondre aux
exigences de politiques spécifiques de contrôle de sécurité. Certaines représentations de l’information ACI peuvent être
appropriées pour une utilisation à la fois dans et entre les systèmes réels. Des représentations différentes d’information
ACI peuvent être utilisées à des fins différentes et entre des éléments particuliers.
Les représentations choisies pour l’information ACI peuvent être considérées comme des gabarits pour l’affectation de
valeurs particulières d’information ACI à des éléments dans un domaine de sécurité (comme cela est présenté dans le
paragraphe suivant). Un des aspects de l’établissement de la représentation d’information ACI concerne la détermination
des types et des intervalles des valeurs de l’information ACI pouvant être assignés aux éléments dans un domaine de
sécurité (mais pas les types pouvant être affectés à des éléments spécifiques).
Les représentations de l’information ACI échangée entre systèmes réels à des fins de gestion de contrôle d’accès ou pour
des échanges d’information ACI entre entités et fonctions de contrôle d’accès sont candidates à la normalisation OSI. La
façon dont l’information ACI est représentée au sein de systèmes réels ou est présentée à une fonction locale ADF n’est
pas sujette à normalisation. La protection de l’échange d’information ACI est présentée en 7.2. Pour les applications OS1
(et, éventuellement, les autres), il est approprié de considérer les représentations de l’information ACI comme des
attributs consistant en des paires de la forme type d’attribut-valeur d’attribut.
5.2.2.3 Affectation de l’information ACI aux initiateurs et aux cibles
Dans cette activité, les types spécifiques d’attribut et de valeurs d’attribut de l’information ACI affectés à un élément sont
désignés par une autorité SDA, ses agents, ou d’autres entités (par exemple, les propriétaires de la ressource). Ces entités
peuvent, en accord avec la politique du domaine de sécurité, spécifier ou modifier l’affectation de l’information ACI.
Rec. UIT-T X.812 (1995 F) 7
ISO/CEI 10181-3 : 1996 (F)
L’information ACI affectée par une entité peut être limitée par l’information ACI qui lui a été attachée par une autre
entité. L’affectation de l’information ACI aux éléments est une activité continue puisque de nouveaux éléments sont
ajoutés à un domaine de sécurité.
administratif accordant des «droits d’accès» est quelquefois appelé autorisation. Cette
NOTE - L’acte signification est
l’information ACI aux initiateurs et cibles.
incluse dans l’affectation de
L’information ACI peut être de l’information relative à une seule entité ou de l’information relative à une relation entre
plusieurs entités. L’information ACI affectée à un initiateur peut être simplement relative à cet initiateur, peut être
relative aux relations entre cet initiateur et des cibles particulières, ou peut être relative à des relations entre cet initiateur
et des contextes possibles. Ainsi, l’information ACI affectée à un initiateur peut inclure l’information ACI de l’initiateur,
l’information ACI de la cible, ou l’information de contexte. De façon similaire, l’information ACI affectée à une cible
peut inclure l’information ACI de cible, l’information ACI d’initiateur (relative à un ou plusieurs initiateurs), ou
l’information de contexte.
Dans une opération effective, l’information ACI doit être attachée à un élément (voir 5.2.2.4) de sorte qu’une fonction
ADF utilisant l’information ADI dérivée de l’information ACI at
...

NORME
ISO/CEI
INTERNATIONALE 10181-3
Première édition
1996-09-15
Technologies de l’information -
Interconnexion de systèmes ouverts
(OSI) - Cadres de sécurité pour les
systèmes ouverts: Cadre de contrôle
d’accès
Open Sys tems In terconnection - Security
Information technology -
frameworks for open s ystems: Access control framework
Numéro de référence
lSO/CEl 10181-3:1996(F)
ISO/CEIl0181-3:1996(F)
Sommaire
Page
Domaine d’application .
Références normatives .
Recommandations 1 Normes internationales identiques .
2.1
........................................................................ 2
2.2 Paires de Recommandations 1 Normes internationales
Définitions .
Abréviations .
Discussion générale sur le contrôle d’accès .
5.1 But du contrôle d’accès .
Aspects élémentaires du contrôle d’accès . 5
5.2
Réalisation des fonctions de contrôle d’accès . 5
5.2.1
.................................................................................. 7
5.2.2 Autres activités de contrôle d’accès
............................................................................................... 9
5.2.3 Envoi de l’information ACI
Distribution des composants de contrôle d’accès .
5.3
Contrôle d’accès entrant .
5.3.1
Contrôle d’accès sortant .
5.3.2
Contrôle d’accès interposé . 11
5.3.3
....... 11
Distribution des composants de contrôle d’accès à travers des domaines de sécurité multiples.
5:5 Menaces sur le contrôle d’accès .
Politiques de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.................................................................................... 12
61 . Expression de la politique de contrôle d’accès
..................................................................... 12
6.1.1 Catégories de politiques de contrôle d’accès
6.1.2 Groupes et rôles .
6.1.3 Etiquettes de sécurité .
Politiques de contrôle de sécurité d’initiateurs multiples .
6.1.4
62 . Gestion de la politique .
6.2.1 Politiques fixes .
6.2.2 Politiques appliquées administrativement .
6.2.3 Politiques sélectionnées par l’utilisateur .
............................................................................................................................. 13
63 . Finesse et inclusion
Règles d’héritage . 13
64 .
........................................................................ 14
65 . Priorités entre règles de politique de contrôle d’accès
Règles de politique de contrôle de sécurité par défaut . 14
66 .
................................... 14
67 . Correspondance de politique par le biais de domaines de sécurité coopérants
0 ISOKEI 1996
Droits de reproduction réservés. Sauf prescription différente, 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’éditeur.
ISOKEI Copyright Office l Case postale 56 l CH-l 211 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
@ ISOKEI
ISOKEI 10181-3:1996(F)
Information de contrôle d’accès et fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 15
7.1 Information ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 15
7.1.1 Information ACI d’initiateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.2 Information ACI de cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.3 Information ACI de demande d’accès . . . . . . . . . . . .*. 15
7.1.4 Opérande de l’information ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.5 Information de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 16
7.1.6 Information ACI attachée à l’initiateur . . . . . . . . . . . . . . . .*. 16
7.1.7 Information ACI attachée à la cible . . . . . . . . . . . . .*.
7.1.8 Information ACI attachée à la demande d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Protection de l’information ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2.1 Certificats de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2.2 Jetons de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Fonctionnalités de contrôle d’accès
7.3 . 17
Fonctionnalités liées à la gestion
7.3.1 . 18
Fonctionnalités relatives à l’exploitation
7.3.2 . 18
........................................................................................ 20
Classification des mécanismes de contrôle d’accès
.........................................................................................................................................
8.1 Introduction
82 . Structure de liste ACL .
............................................................................................
8.2.1 Caractéristiques élémentaires
Information ACI .
8.2.2
Mécanismes de support .
8.2.3
Variantes de cette structure .
8.2.4
8.3 Structure de capacité .
............................................................................................ 23
8.3.1 Caractéristiques élémentaires
................................................................................................................
8.3.2 Information ACI
.....................................................................................................
8.3.3 Mécanismes de support
...............................
8.3.4 Variantes de cette structure - Capacités sans opérations spécifiques
Structure fondée sur l’étiquette .
8.4
8.4.1 Caractéristiques élémentaires .
8.4.2 Information ACI .
8.4.3 Mécanismes de support .
8.4.4 Voies étiquetées comme cibles .
Structure fondée sur le contexte .
85 .
Caractéristiques élémentaires .
8.5.1
Information ACI .
8.5.2
8.5.3 Mécanismes de support .
8.5.4 Variantes de cette structure .
.........................................................................
9 Interaction avec d’autres services et mécanismes de sécurité
91 Authentification .
Intégrité des données .
9:2
................................................................................................................
9.3 Confidentialité des données
9.4 Audit .
Autres services liés à l’accès .
95 .
..............................................................
Annexe A - Echange de certificats de contrôle d’accès entre composants
Introduction .
A. 1
.............................................................................................
A.2 Envoi des certificats de contrôle d’accès
...............................................................................
A.3 Envoi de multiples certificats de contrôle d’accès
A.3.1 Exemple .
A.3.2 Généralisation .
Simplifications . 30
A.3.3
ISOKEI 10181-3:1996(F) @ ISOKEI
- Contrôle d’accès dans le modèle de référence OS1
Annexe B .
B.l Généralités .
B.2 Utilisation du contrôle d’accès dans les couches OS1
......................................................................... 31
B.2.1 Utilisation du contrôle d’accès pour la couche réseau
....................................................... 31
B.2.2 Utilisation du contrôle d’accès pour la couche transport
................................................... 31
B.2.3 Utilisation du contrôle d’accès pour la couche application
............................................... 31
Annexe C - Non-unicité des identités de contrôle d’accès
......................................................................................
- Distribution des composants de contrôle d’accès
Annexe D .
D. 1 Aspects considérés .
D.2 Localisation des composants AEC et ADC
........................................................................................
D.3 Interactions entre composants de contrôle d’accès .
Annexe E - Politiques fondées sur les règles versus politiques fondées sur l’identité
............................................
Annexe F - Un mécanisme pour mettre en oeuvre l’envoi de l’information ACI par le biais d’un initiateur
.......... 37
Annexe G - Grandes lignes du service de sécurité de contrôle d’accès
.................................................................. 38
1v
@ ISOKEI ISOKEI 10181-3:1996(F)
Avant-propos
LIS0 (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de I’ISO ou de la CE1 participent au développement de Normes inter-
nationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de I’ISO et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 1018 l-3 a été élaborée par le comité technique
mixte ISO/CEI JTC 1, Technologies de l’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’UIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.812.
L’ISOKEI 1018 1 comprend les parties suivantes, présentées sous le titre général
Interconnexion de systèmes ouverts (OU) -
Technologies de l’information -
Cadres de sécurité pour les systèmes ouverts:
Partie 1: Présentation
- Partie 2: Cadre d’authentification
- Partie 3: Cadre de contrôle d’accès
Partie 4: Cadre de non-répudiation
- Partie 5: Cadre de confidentialité
- Partie 6: Cadre d’intégrité
- Partie 7: Cadre d’audit de sécurité
Les annexes A à G de la présente partie de l’ISO/CEI 10181 sont données uni-
quement à titre d’information.

ISOKEI 10181-3:1996(F) @ ISOKEI
Introduction
La présente Recommandation 1 Norme internationale définit un cadre général pour la fourniture du contrôle d’accès. Le
but essentiel du contrôle d’accès est de parer au risque d’opérations non autorisées au moyen d’un ordinateur ou d’un
système de communication; ces menaces sont fréquemment subdivisées en classes qui sont notamment les suivantes:
utilisation non autorisée, divulgation, modification, destruction ou déni de service.
Vl
ISOKEI 10181-3 : 1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE SYSTÈMES
OUVERTS (OSI) - CADRES DE SÉCURITÉ POUR LES SYSTÈMES OUVERTS:
CADRE DE CONTRÔLE D’ACCÈS
1 Domaine d’application
Les cadres de sécurité sont destinés à traiter l’application des services de sécurité dans l’environnement des systèmes
ouverts, où le terme systèmes ouverts est utilisé pour des domaines tels que les bases de données, les applications
distribuées, le traitement ODP et l’interconnexion OSI. Les cadres de sécurité sont destinés à définir les moyens d’oftir
la protection des systèmes et des objets au sein des systèmes, ainsi que les interactions entre systèmes. Les cadres ne
traitent pas de la méthodologie de construction des systèmes ou des mécanismes.
Les cadres couvrent à la fois les éléments de données et les séquences d’opérations (mais pas les éléments de protocole)
utilisés pour obtenir des services spécifiques de sécurité. Ces services de sécurité peuvent s’appliquer aux entités
communicantes des systèmes aussi bien qu’aux données échangées entre systèmes, et aux données gérées par les
systèmes.
Dans le cas du contrôle d’accès, les accès peuvent être destinés à un système (par exemple, vers une entité qui est la
partie communicante d’un système) ou prendre place au sein d’un système. Les éléments de données qui doivent être
présentés pour obtenir l’accès, ainsi que la séquence d’opérations de la demande et pour la notification des résultats de
l’accès, sont considérés comme faisant partie des cadres de sécurité. Cependant, tout élément de données et toute
opération qui dépend seulement d’une application et qui est strictement concerné par l’accès local au sein d’un système ne
fait pas partie du domaine d’application des cadres de sécurité.
Plusieurs applications ont des besoins de sécurité pour protéger des menaces sur des ressources, y compris l’information,
résultant de l’interconnexion des systèmes ouverts. Certaines menaces communément connues, dans un environ-
nement OSI, ainsi que les services et mécanismes de sécurité pour s’en protéger, sont décrits dans la Rec. X.800 du
CCITT 1 ISO 7498-2.
Le processus de détermination des utilisations de ressources permises dans un environnement de système ouvert et,
lorsque cela est approprié, la prévention contre un accès non autorisé est appelé contrôle d’accès. La présente
Recommandation 1 Norme internationale définit un cadre général pour la fourniture des services de contrôle d’accès.
Ce cadre de sécurité:
définit les concepts élémentaires du contrôle d’accès;
b) démontre la façon dont les concepts élémentaires du contrôle d’accès peuvent être spécialisés pour mettre
en œuvre quelques services et mécanismes d’accès communément reconnus;
définit ces services et mécanismes de contrôle d’accès correspondants;
C>
d) identifie les besoins fonctionnels des protocoles pour la mise en œuvre de ces services et mécanismes de
contrôle d’accès;
identifie les besoins de gestion afin de mettre en œuvre ces services et mécanismes de contrôle d’accès;
e>
couvre l’interaction des services
et mécanismes de contrôle d’accès avec d’autres services et mécanismes
f)
de sécurité.
Comme pour les autres services de sécurité, le contrôle d’accès peut être fourni seulement dans le contexte d’une
politique de sécurité définie pour une application particulière. La définition des politiques de contrôle d’accès ne fait pas
partie du domaine d’application de la présente Recommandation 1 Norme internationale, cependant, certaines caracté-
ristiques des politiques de contrôle d’accès sont présentées.
L’objet de la présente Recommandation 1 Norme internationale n’est pas de spécifier les détails des échanges
de
protocoles qui peuvent s’avérer nécessaires pour fournir les services de contrôle d’accès.
Rec. UIT-T X.812 (1995 F)
ISO/CEI 10181-3 : 1996 (F)
1 Norme internationale en œuvre ces
La présente Recommandation ne spécifie pas de mécanisme particulier pour mettre
services de contrôle d’accès ni les détails des services et protocoles de gestion de la sécurité.
Différents types de normes peuvent utiliser ce cadre y compris:
incorporent le concept du contrôle d’accès;
les normes qui
les normes qui spécifient les services d’accès incluant le contrôle d’accès;
les normes qui spécifient les utilisations d’un service de contrôle d’accès;
C>
spécifient les moyens de fournir le contrôle d’accès au sein d’un environnement de système
d) les normes qui
ouvert;
les normes qui spécifient les mécanismes de contrôle d’accès.
e)
De telles normes peuvent utiliser ce cadre de la façon suivante:
-
les normes de types a), b), c), d) et e) peuvent utiliser la terminologie de ce cadre;
-
les normes de types b), c), d) et e) peuvent utiliser les fonctionnalités définies dans l’article 7 de ce cadre;
-
la norme de type e) peut être fondée sur les classes de mécanismes définies dans l’article 8 de ce cadre.
2 Références normatives
Les Recommandations et les Normes internationales suivantes contiennent des dispositions qui, par suite de la référence
qui y est faite, constituent des dispositions valables pour la présente Recommandation 1 Norme internationale. Au
moment de la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à
révision, et les parties prenantes aux accords fondés sur la présente Recommandation 1 Norme internationale sont invitées
à rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de 1’UIT tient à jour une liste des Recommandations de l’UIT-T en vigueur.
21 . Recommandations 1 Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) 1 ISO/CEI 7498-l : 1994, Technologies de l’information -
Interconnexion des systèmes ouverts - Modèle de référence de base: le modèle de référence de base.
-
Recommandation UIT-T X.8 10 (1995) 1 ISOKEI 10 18 l- 1: 1996, Technologies de Z’information -
- Cadres de sécurité pour les systèmes ouverts: aperçu général.
Interconnexion des systèmes ouverts
-
Recommandation UIT-T X.8 11 (1995) 1 ISO/CEI 10 18 l-2: 1996, Technologies de I?nformation -
Interconnexion des systèmes ouverts - Cadre de sécurité pour systèmes ouverts: cadre d’authentification.
-
Recommandation UIT-T X.880 (1994) 1 ISOKEI 13712-1:1995, Technologies de I?nformation -
Opérations distantes: concepts, modèle et notation.
Paires de Recommandations 1 Normes internationales équivalentes par leur contenu technique
22 0
-
Recommandation X.800 du CCITT (1991), Architecture de sécurité pour l’interconnexion des systèmes
ouverts d’applications du CCITT.
- Interconnexion de systèmes ouverts - Modèle
ISO 7498-2: 1989, Systèmes de traitement de l’information
de référence de base - Partie 2: architecture de sécurité.
3 Définitions
Pour les besoins de la présente Recommandation 1 Norme internationale, les définitions suivantes s’appliquent.
31 La présente Recommandation 1 Norme internationale utilise les termes suivants définis dans la Rec. X.800 du
CCITT 11so 7498-2:
contrôle d’accès;
a)
b) liste de contrôle d’accès;
I
imputabilité;
c)
Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
authentification;
information d’authentification;
e>
autorisation;
g) capacité;
h) politique de sécurité fondée sur l’identité;
i) politique de sécurité fondée sur des règles;
.
audit de sécurité;
J)
k) label de sécurité;
politique de sécurité;
1)
service de sécurité;
m)
n) sensibilité.
La présente Recommandation 1 Norme internationale utilise les termes suivants définis dans la Rec. UIT-T
3.2
X.810 1 ISOKEI 11081-l:
politique d’interaction sécurisée;
certificat de sécurité;
domaine de sécurité;
autorité du domaine de sécurité;
d)
information de sécurité;
règles de politique de sécurité;
jeton de sécurité;
g>
confiance.
h)
La présente Recommandation 1 Norme internationale utilise les termes suivants définis dans la Rec. UIT-T
3.3
X.200 1 ISOKEI 7498-1:
-
réel.
système
3.4 Les définitions suivantes s’appliquent pour la présente Recommandation 1 Norme internationale:
3.4.1 certificat de contrôle d’accès: Certificat de sécurité contenant l’information ACI.
3.4.2 information de décision de contrôle d’accés (ADI)
( access control decision information): Partie
(éventuellement toute) de l’information ACI fournie à la fonction ADF pour décider d’un contrôle d’accès particulier.
3.4.3 fonction de décision de contrôle d’accés (ADF) (access control decision finction): Fonction spécialisée
prenant des décisions de contrôle d’accès par l’application des règles de la politique de contrôle d’accès à une demande
d’accès, et l’exploitation de l’information ADI et du contexte dans lequel la demande d’accès est effectuée.
3.4.4 fonction d’application de contrôle d’accès (AEF) (
access control enforcement function): Fonction
spécialisée qui, pour chaque demande d’accès, fait partie du chemin d’accès entre un initiateur et une cible et applique la
décision prise par la fonction ADF.
3.4.5 information de contrôle d’accés (ACI) ( access control information): Toute information utilisée à des fins de
contrôle d’accès, incluant l’information de contexte.
de contrôle d’accés:
3.4.6 Ensemble des règles définissant les conditions dans lesquelles l’accès peut se
dérouler.
3.4.7 régles de politique de contrôle d’accès: Règles concernant la fourniture du service de
de politique de sécurité
contrôle d’accès.
jeton de contrôle d’accés: Jeton de sécurité contenant l’information ACI.
3.4.8
3.4.9 demande d’accès: Opérations et opérandes faisant partie d’une tentative d’accès.
3.4.10 information de décision de contrôle d’accés d’une demande d’accés; demande d’accés ADI: Information
ADI dérivée d’une information ACI attachée à une demande d’accès.
3.4.11 information de contrôle d’accès d’une demande d’accès; demande d’accés ACI: Information ACI sur une
demande d’accès.
Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
à une
contrôle d’accés attachée h une demande d’actes; ACI attachée demande d’accès:
3.4.12 information de
à une demande d’accès.
Information ACI attachée
3.4.13 autorisation: Information ACI attachée à l’initiateur qui peut être comparée aux étiquettes de sécurité des
information contextuelle: Information relati .ve au contexte dans lequel la demande d’accès est effectuée (par
3.4.14
heure du jour) ou dérivant d’un tel contexte.
exemple
3.4.15 initiateur: Entité (personne ou mécanisme informatique par exemple) qui tente d’accéder à d’autres entités.
3.4.16 information de décision de contrôle d’accés d’initiateur; initiateur ADI: Information ADI dérivée de
l’information ACI attachée à l’initiateur.
3.4.17 information de contrôle d’accés d’initiateur; information ACI initiateur: Information ACI de l’initiateur.
3.4.18 information de contrôle d’accés attachée B l’initiateur; information ACI attachée à l’initiateur:
Information ACI attachée à un initiateur.
information de décision de contrôle d’accés d’opérande; information ADI d’opérande: Information ADI
3.4.19
dérivée de l’information ADI attachée à l’opérande.
3.4.20 information de contrôle d’accés d’opérande; information ACI d’opérande: Information ACI sur les
opérandes d’une demande d’accès.
information ACI attachée à l’opérande:
3.4.21 information de contrôle d’accés attachée B l’opérande;
Information ACI attachée aux opérandes d’une demande d’accès.
3.4.22 information ADI retenue: Information ADI retenue par une fonction ADF lors d’une précédente décision de
contrôle d’accès pour être utilisée dans de futures décisions de contrôle d’accès.
3.4.23 cible: Entité pour laquelle un accès peut être tenté.
3.4.24 information de décision de contrôle d’accés de cible; information ADI de cible: Information ADI dérivée
de l’information ACI attachée à la cible.
3.4.25 information de contrôle d’accés de cible; information ACI de cible: Information ACI relative à une cible.
3.4.26 information de contrôle d’accès attachée à la cible; information ACI attachée à la cible: Information ACI
attachée à la cible.
4 Abréviations
Information de contrôle d’accès (access control information)
ACI
ADI Information de décision de contrôle d’accès (access control decision information)
ADF Fonction de décision de contrôle d’accès (access control decision function)
Fonction d’application de contrôle d’accès (access control enforcement function)
AEF
SI Information de sécurité (security information)
SDA Autorité du domaine de sécurité (security domain authority)
5 Discussion générale sur le contrôle d’accès
51 l But du contrôle d’accès
Dans ce cadre de sécurité, le premier but du contrôle d’accès est d’éviter la menace d’opérations non autorisées
impliquant un ordinateur ou un système de communication; ces menaces sont fréquemment subdivisées en classes
appelées:
-
utilisation non autorisée;
- divulgation;
- modification;
-
destruction;
- reiks de- service.
4 Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
Les sous-objectifs de ce cadre de sécurité sont:
- le contrôle d’accès par les processus (qui peuvent agir pour le compte d’humains ou d’autres processus)
vers les données, les processus ou d’autres ressources de calculs;
-
le contrôle d’accès au sein d’un domaine de sécurité ou au travers de plusieurs domaines de s&.rité;
-
le contrôle d’accès en fonction de son contexte; par exemple, en fonction de facteurs comme l’heure de la
tentative d’accès, le lieu de l’accédant ou la route d’accès;
-
le contrôle d’accès réagissant aux changements dans l’autorisation lors de l’accès.
52 . Aspects élémentaires du contrôle d’accès
Les paragraphes suivants décrivent les fonctions abstraites de contrôle d’accès largement indépendantes des politiques de
contrôle d’accès et des conceptions de systèmes. Le contrôle d’accès dans les systèmes réels concerne plusieurs types
d’entités, telles que:
les entités physiques (par exemple, systèmes réels);
-
les entités logiques (par exemple, entités de couche OSI, fichiers, organisations, et entreprises);
-
les usagers.
Le contrôle d’accès dans les systèmes réels peut nécessiter un ensemble d’activités complexes:
-
établissement de la politique de contrôle d’accès;
-
établissement des représentations de l’information ACI;
-
affectation de l’information ACI aux éléments (initiateurs, cibles ou demandes d’accès);
-
rattachement de l’information ACI aux éléments;
-
mise à disposition de l’information ADI pour la fonction ADF;
-
exécution des fonctions de contrôle d’accès;
-
modification de l’information ACI (à n’importe quel moment après l’affectation des valeurs de
ACI ; y compris la révocation);
l’information
-
révocation de l’information ADI.
Ces activités peuvent être divisées en deux groupes:
-
les activités opérationnelles (mise à disposition de l’information ADI pour la fonction ADF et réalisation
des fonctions de contrôle d’accès);
-
les activités de gestion (toutes les autres activités).
Certaines activités ci-dessus peuvent être groupées dans une seule entité identifiable au sein d’un système réel. Bien que
certaines activités de contrôle d’accès précèdent nécessairement les autres, il y a souvent recouvrement et certaines
activités peuvent être réalisées à plusieurs reprises.
Une présentation détaillée des notions mises en jeu dans la réalisation des fonctions de contrôle d’accès sera
d’abord
présentée étant donné que d’autres activités les mettent en œuvre.
5.2.1 Réalisation des fonctions de contrôle d’accés
Pour ce paragraphe, les fonctions fondamentales du contrôle d’accès sont illustrées sur les Figures 5-l et 5-2. D’autres
fonctions peuvent être nécessaires pour le fonctionnement global du contrôle d’accès. Les discussions qui suivent,
présentent plusieurs façons de mettre en œuvre ces fonctions, y compris différentes façons de distribuer les fonctions de
contrôle d’accès et l’information ACI, et différents styles de communication entre les fonctions de contrôle d’accès dans
le même domaine de sécurité ou entre domaines de sécurité coopérants.
Les entités élémentaires et les fonctions mises en œuvre dans le contrôle d’accès sont l’initiateur, la fonction d’application
de contrôle d’accès (AEF), la fonction de décision de contrôle d’accès (ADF), et la cible.
Les initiateurs représentent à la fois les êtres humains et les entités liées à l’ordinateur qui accèdent ou tentent d’accéder
aux cibles. Au sein d’un système réel, un initiateur est représenté par une entité liée à l’ordinateur, bien que les demandes
d’accès de l’entité liée à l’ordinateur pour le compte de l’initiateur puissent être limitées par l’information ACI de l’entité
liée à l’ordinateur.
Rec. UIT-T X.812 (1995 F) 5
ISOKEI 10181-3 : 1996 (F)
présente la
soumet la
demande
demande
initiateur cible
d’acc&
d’accès
fonction AEF
-----w w-w--
b
I r
l
A
demande
TIS06350-95/dOl
de décision décision
fonction ADF
Figure 5-l- Illustration des fonctions fondamentales du contrôle d’accès
demande de
dkcision
dhsion
1 T
information ADI cible
initiateur AD I
information ADI information de contexte
D
fonction ADF
de demande d’accès
information
ADI
retenue
r&gles de politique
TISO636@95/d 02
de contrôle d’ac&s
T
Figure 5-2 - Illustration de la fonction ADF
Les cibles représentent des entités liées au calculateur ou des entités de communication vers lesquelles l’accès est tenté
ou bien les entités accédées par les initiateurs. Une cible peut, par exemple, être une entité de couche OSI, un fichier, ou
un système réel.
Une demande d’accès représente les opérations et les opérandes faisant partie d’une tentative d’accès.
La fonction AEF garantit que seuls les accès légitimes de l’initiateur, déterminés par la fonction ADF, sont réalisés sur la
cible. Lorsque l’initiateur effectue une demande pour réaliser un accès particulier sur la cible, la fonction AEF informe la
fonction ADF qu’une décision est requise afin de prendre une résolution.
Afin de prendre une décision, la demande d’accès (en tant que partie de la demande de décision) et les types suivants
d’information de décision de contrôle d’accès (ADI) sont fournis à la fonction ADF:
-
ADI d’initiateur (information ADI dérivée de l’information ACI attachée à l’initiateur);
-
ADI de cible (information ADI dérivée de l’information ACI attachée à la cible);
-
ADI de demande d’accès @formation ADI dérivée de l’information ACI attachée à la demande d’accès).
6 ‘Rec. UIT-T X.812 (1995 F)
ISOKEI 10181-3 : 1996 (F)
Les autres entrees de la fonction ADF sont les règles de la politique de contrôle d’accès (de l’autorité du domaine de
sécurité de la fonction ADF), et toute information de contexte nécessaire pour interpréter l’information ADI ou la
politique. Des exemples d’informations de contexte incluent l’emplacement de l’initiateur, l’heure d’accès, ou le chemin
particulier de communications en cours d’utilisation.
Fondée sur ces entrées, et éventuellement sur l’information ADI retenue des décisions précédentes, la fonction ADF
aboutit à une décision pour autoriser ou dénier l’accès tenté par l’initiateur sur la cible. La décision est transportée jusqu’à
la fonction AEF qui permet ensuite à la demande d’accès d’arriver jusqu’à la cible ou qui prend d’autres actions
appropriées.
Dans plusieurs cas, les demandes d’accès successives d’un initiateur sur une cible sont liées. Un exemple typique
concerne une application qui ouvre une connexion vers un processus d’application cible de même niveau et ensuite tente
de réaliser plusieurs accès en utilisant la même information ADI (retenue). Pour certaines demandes d’accès suivantes
transmises sur la connexion, il peut être nécessaire de fournir une information ADI additionnelle à la fonction ADF afin
qu’elle autorise la demande d’accès. Dans d’autres cas, une politique de sécurité peut demander que, entre un ou plusieurs
initiateurs, certaines demandes d’accès liées soient sujettes à restrictions. Dans de tels cas, la fonction ADF peut utiliser
l’information ADI retenue de décisions précédentes impliquant plusieurs initiateurs et cibles pour prendre une décision
sur une demande d’accès particulière.
Pour ce paragraphe, une demande d’accès met en jeu une seule interaction entre un initiateur et une cible, si cela est
permis par le fonction AEF. Bien que certaines demandes d’accès entre un initiateur et une cible soient simplement
indépendantes, il arrive souvent que deux entités participent à un ensemble de demandes d’accès liées tel qu’un
paradigme de question-réponse. Dans ces cas, les rôles d’initiateur et de cible sont assurés, comme requis, par les entités,
soit simultanément soit de façon alternée, et les fonctions de contrôle d’accès sont mises en œuvre pour chaque demande
d’accès, éventuellement par des composants distincts de fonction AEF, des composants de fonction ADF et des
politiques de contrôle d’accès.
5.2.2 Autres activités de contrôle d’accès
5.2.2.1 Etablissement des représentations de politique de contrôle d’accés
Les politiques de contrôle d’accès sont communément définies en langages naturels sous forme de principes généraux;
par exemple: seuls les responsables d’au moins un certain rang sont autorisés à examiner les informations salariales des
employés. La transposition de ces principes dans des règles est une activité de conception qui précède nécessairement les
autres activités de contrôle d’accès et ne fait pas partie du domaine d’application de ce cadre de sécurité. Un aperçu des
concepts de politique de contrôle d’accès est donné dans l’article 6.
5.2.2.2 Etablissement des représentations des informations ACI
Dans cette activité, sont effectués les choix pour la représentation de l’information ACI au sein de systèmes réels
(structure des données) et pour l’échange entre systèmes réels (syntaxes). Un grand domaine de représentations possibles
est présenté dans ce cadre de sécurité. Les représentations de l’information ACI doivent être en mesure de répondre aux
exigences de politiques spécifiques de contrôle de sécurité. Certaines représentations de l’information ACI peuvent être
appropriées pour une utilisation à la fois dans et entre les systèmes réels. Des représentations différentes d’information
ACI peuvent être utilisées à des fins différentes et entre des éléments particuliers.
Les représentations choisies pour l’information ACI peuvent être considérées comme des gabarits pour l’affectation de
valeurs particulières d’information ACI à des éléments dans un domaine de sécurité (comme cela est présenté dans le
paragraphe suivant). Un des aspects de l’établissement de la représentation d’information ACI concerne la détermination
des types et des intervalles des valeurs de l’information ACI pouvant être assignés aux éléments dans un domaine de
sécurité (mais pas les types pouvant être affectés à des éléments spécifiques).
Les représentations de l’information ACI échangée entre systèmes réels à des fins de gestion de contrôle d’accès ou pour
des échanges d’information ACI entre entités et fonctions de contrôle d’accès sont candidates à la normalisation OSI. La
façon dont l’information ACI est représentée au sein de systèmes réels ou est présentée à une fonction locale ADF n’est
pas sujette à normalisation. La protection de l’échange d’information ACI est présentée en 7.2. Pour les applications OS1
(et, éventuellement, les autres), il est approprié de considérer les représentations de l’information ACI comme des
attributs consistant en des paires de la forme type d’attribut-valeur d’attribut.
5.2.2.3 Affectation de l’information ACI aux initiateurs et aux cibles
Dans cette activité, les types spécifiques d’attribut et de valeurs d’attribut de l’information ACI affectés à un élément sont
désignés par une autorité SDA, ses agents, ou d’autres entités (par exemple, les propriétaires de la ressource). Ces entités
peuvent, en accord avec la politique du domaine de sécurité, spécifier ou modifier l’affectation de l’information ACI.
Rec. UIT-T X.812 (1995 F) 7
ISO/CEI 10181-3 : 1996 (F)
L’information ACI affectée par une entité peut être limitée par l’information ACI qui lui a été attachée par une autre
entité. L’affectation de l’information ACI aux éléments est une activité continue puisque de nouveaux éléments sont
ajoutés à un domaine de sécurité.
administratif accordant des «droits d’accès» est quelquefois appelé autorisation. Cette
NOTE - L’acte signification est
l’information ACI aux initiateurs et cibles.
incluse dans l’affectation de
L’information ACI peut être de l’information relative à une seule entité ou de l’information relative à une relation entre
plusieurs entités. L’information ACI affectée à un initiateur peut être simplement relative à cet initiateur, peut être
relative aux relations entre cet initiateur et des cibles particulières, ou peut être relative à des relations entre cet initiateur
et des contextes possibles. Ainsi, l’information ACI affectée à un initiateur peut inclure l’information ACI de l’initiateur,
l’information ACI de la cible, ou l’information de contexte. De façon similaire, l’information ACI affectée à une cible
peut inclure l’information ACI de cible, l’information ACI d’initiateur (relative à un ou plusieurs initiateurs), ou
l’information de contexte.
Dans une opération effective, l’information ACI doit être attachée à un élément (voir 5.2.2.4) de sorte qu’une fonction
ADF utilisant l’information ADI dérivée de l’information ACI at
...