ISO 22600-1:2014
(Main)Health informatics — Privilege management and access control — Part 1: Overview and policy management
Health informatics — Privilege management and access control — Part 1: Overview and policy management
ISO 22600 defines principles and specifies services needed for managing privileges and access control to data and/or functions. It focuses on communication and use of health information distributed across policy domain boundaries. This includes healthcare information sharing across unaffiliated providers of healthcare, healthcare organizations, health insurance companies, their patients, staff members, and trading partners by both individuals and application systems ranging from a local situation to a regional or even national situation. It specifies the necessary component-based concepts and is intended to support their technical implementation. It will not specify the use of these concepts in particular clinical process pathways. ISO 22600-1:2014 proposes a template for the policy agreement. It enables the comparable documentation from all parties involved in the information exchange.
Informatique de santé — Gestion de privilèges et contrôle d'accès — Partie 1: Vue d'ensemble et gestion des politiques
L'ISO 22600 définit les principes de gestion des privilèges et de contrôle d'accès aux données et/ou aux fonctions et spécifie les services nécessaires à ces activités. Elle se concentre sur la communication et l'utilisation des informations de santé distribuées au-delà des limites d'un domaine de politique. Cela inclut le partage d'informations de santé entre professionnels de santé non affiliés, établissements de santé, sociétés d'assurance-maladie, patients, membres du personnel et partenaires commerciaux, par des individus tout comme par des systèmes d'application utilisés dans un contexte local, voire régional ou même national. Elle spécifie les concepts nécessaires pour chaque composante et est destinée à faciliter leur mise en oeuvre technique. Elle ne spécifiera pas l'utilisation de ces concepts pour des cheminements de processus cliniques particuliers. L'ISO 22600-1:2014 propose un modèle d'accord de politique, qui permet d'obtenir de toutes les parties impliquées dans l'échange d'informations une documentation comparable.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 22600-1
First edition
2014-10-01
Health informatics — Privilege
management and access control —
Part 1:
Overview and policy management
Informatique de santé — Gestion de privilèges et contrôle d’accès —
Partie 1: Vue d’ensemble et gestion des politiques
Reference number
©
ISO 2014
© ISO 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2014 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Goal and structure of privilege management and access control .4
5.1 Goal of privilege management and access control . 4
5.2 Structure of privilege management and access control . 4
6 Policy agreement . 9
6.1 Overview . 9
6.2 Identification .10
6.3 Patient consent .10
6.4 Patient privacy.10
6.5 Information identification .10
6.6 Information location .10
6.7 Information integrity .11
6.8 Security .11
6.9 Authorization .11
6.10 Role structures .11
6.11 Assignment and attestation authorities .11
6.12 Delegation rights .11
6.13 Validity time .11
6.14 Authentication of users/roles .12
6.15 Access .12
6.16 Policy agreement validity period .12
6.17 Ethics .12
6.18 Secure audit trail .12
6.19 Audit check .12
6.20 Risk analysis .12
6.21 Continuity and disaster management .13
6.22 Future system developments .13
7 Documentation .13
Annex A (informative) Example of a documentation template .14
Annex B (informative) Example of an information exchange policy agreement .21
Bibliography .27
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 215, Health informatics.
This first edition of ISO 22600-1 cancels and replaces ISO/TS 22600-1:2006, which has been technically
revised.
ISO 22600 consists of the following parts, under the general title Health informatics — Privilege
management and access control:
— Part 1: Overview and policy management
— Part 2: Formal models
— Part 3: Implementations
iv © ISO 2014 – All rights reserved
Introduction
The distributed architecture of shared care information systems is increasingly based on corporate
networks and virtual private networks. For meeting the interoperability challenge, the use of
standardized user interfaces, tools, and protocols, which ensures platform independence, but also the
number of really open information systems, is rapidly growing during the last couple of years.
As a common situation today, hospitals are supported by several vendors providing different applications,
which are not able to communicate authentication and authorization since each has its own way of
handling these functions. For achieving an integrated scenario, it takes a remarkable amount of money,
time, and efforts to get users and changing organizational environments dynamically mapped before
starting communication and cooperation. Resources required for the development and maintenance
of security functions grow exponentially with the number of applications, with the complexity of
organizations towards a regional, national, or even international level, and with the flexibility of users
playing multiple roles, sometimes even simultaneously.
The situation becomes even more challenging when inter-organizational communications happens,
thereby crossing security policy domain boundaries. Moving from one healthcare centre to another or
from country to country, different rules for privileges and their management can apply to similar types
of users, both for execution of particular functions and for access to information. The policy differences
between these domains have to be bridged automatically or through policy agreements, defining sets of
rules followed by the parties involved, for achieving interoperability.
Another challenge to be met is how to improve the quality of care by using IT without infringing the
privacy of the patient. To provide physicians with adequate information about the patient, a virtual
electronic health care record is required which makes it possible to keep track of all the activities
belonging to one patient regardless of where and by whom they have been performed and documented.
In such an environment, a generic model or specific agreement between the parties for managing
privileges and access control including the patient or its representative is needed.
Besides a diversity of roles and responsibilities, typical for any type of large organization, also ethical
and legal aspects in the healthcare scenario due to the sensitivity of person-related health information
managed and its personal and social impact have to be considered.
Advanced solutions for privilege management and access control are required today already, but
this challenge will even grow over the next couple of years. The reason is the increase of information
exchanged between systems in order to fulfil the demands of health service providers at different care
levels for having access to more and more patient-related information to ensure the quality and efficiency
of patient’s diagnosis and treatment, however combined with increased security and privacy risks.
The implementation of this International Standard might be currently too advanced and therefore not
feasible in certain organizational and technical settings. For meeting the basic principle of best possible
action, it is therefore very important that at least a policy agreement is written between the parties
stating to progress towards this International Standard when any update/upgrade of the systems is
intended. The level of formalization and granularity of policies and the objects these policies are bound
to defines the solution maturity on a pathway towards the presented specification.
The policy agreement also has to contain defined differences in the security systems and agreed
solutions on how to overcome the differences. For example, the authentication service and privileges
of a requesting party at the responding site have to be managed according to the policy declared in
the agreement. For that reason, information and service requester, as well as information and service
provider on the one hand, and information and services requested and provided on the other hand, have
to be grouped and classified in a limited number of concepts for enabling the specification of a limited
number of solution categories. Based on that classification, claimant mechanisms, target sensitivity
mechanisms, and policy specification and management mechanisms can be implemented. Once all
parties have signed the policy agreement, the communication and information exchange can start with
the existing systems if the parties can accept the risks. If there are unacceptable risks which have to be
eliminated before the information exchange starts, they also have to be recorded in the policy agreement
together with an action plan stating how these risks have to be removed. The policy agreement also has
to contain a time plan for this work and an agreement on how it has to be financed.
The documentation of the negotiation process is very important and provides the platform for the policy
agreement.
Privilege management and access control address security and privacy services required for
communication and cooperation, i.e. distributed use of health information. It also implies safety aspects,
professional standards, and legal and ethical issues. This International Standard introduces principles
and specifies services needed for managing privileges and access control. Cryptographic protocols are
out of the scope of this International Standard.
This three-part International Standard references existing architectural and security standards as well
as specifications in the healthcare area such as ISO, CEN, ASTM, OMG, W3C, etc., and endorses existing
appropriate standards or identifies enhancements or modifications or the need for new standards. It
comprises of:
— ISO 22600-1: describes the scenarios and the critical parameters in information exchange across
policy domains. It also gives examples of necessary documentation methods as the basis for the
policy agreement.
— ISO 22600-2: describes and explains, in a more detailed manner, the architectures and underlying
models for privilege management and access control which are necessary for secure information
sharing including the formal representation of policies.
— ISO 22600-3: describes examples of implementable specifications of application security services
and infrastructural services using different specification languages.
It accommodates policy bridging. It is based on a conceptual model where local authorization servers and
cross-border directory and policy repository services can assist access control in various applications
(software components). The policy repository provides information on rules for access to various
application functions based on roles and other attributes. The directory service enables identification
of the individual user. The granted access will be based on four aspects:
— the authenticated identification of principals (i.e. human users and objects that need to operate
under their own rights) involved;
— the rules for access to a specific information object including purpose of use;
— the rules regarding authorization attributes linked to the principal provided by the authorization
manager;
— the functions of the specific application.
The International Standard supports collaboration between several authorization managers that can
operate over organizational and policy borders.
This International Standard is strongly related to other ISO/TC 215 works such as ISO 17090 (all parts),
ISO 22857, ISO 21091, and ISO 21298.
This International Standard is meant to be read in conjunction with its complete set of associated
standards.
vi © ISO 2014 – All rights reserved
INTERNATIONAL STANDARD ISO 22600-1:2014(E)
Health informatics — Privilege management and access
control —
Part 1:
Overview and policy management
1 Scope
This multi-part International Standard defines principles and specifies services needed for managing
privileges and access control to data and/or functions.
It focuses on communication and use of health information distributed across policy domain boundaries.
This includes healthcare information sharing across unaffiliated providers of healthcare, healthcare
organizations, health insurance companies, their patients, staff members, and trading partners by
both individuals and application systems ranging from a local situation to a regional or even national
situation.
It specifies the necessary component-based concepts and is intended to support their technical
implementation. It will not specify the use of these concepts in particular clinical process pathways.
This part of ISO 22600 proposes a template for the policy agreement. It enables the comparable
documentation from all parties involved in the information exchange.
This part of ISO 22600 excludes platform-specific and implementation details. It does not specify
technical communication services and protocols which have been established in other standards. It also
excludes authentication techniques.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 17090 (all parts), Health informatics — Public key infrastructure
ISO 21091, Health informatics — Directory services for healthcare providers, subjects of care and other
entities
1)
ISO 21298:— , Health informatics — Functional and structural roles
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
access control
means of ensuring that the resources of a data processing system can be accessed only by authorized
entities in authorized ways
[SOURCE: ISO/IEC 2382-8:1998]
1) To be published (revision of ISO/TS 21298).
3.2
accountability
property that ensures that the actions of an entity can be traced uniquely to the entity
[SOURCE: ISO 7498-2:1989]
3.3
attribute certificate
data structure, digitally signed by an attribute authority, that binds some attribute values with
identification about its holder
[SOURCE: ISO/IEC 9594-8:2008]
3.4
authentication
provision of assurance of the claimed identity of an entity by securely associating an identifier and its
authenticator
Note 1 to entry: See also data origin authentication and peer entity authentication.
[SOURCE: ISO/IEC 15944-5:2008, 3.5]
3.5
authority
entity that is responsible for the issuance of certificates
Note 1 to entry: Two types are defined in this part of ISO 22600: certification authority, which issues public key
certificates, and attribute authority, which issues attribute certificates.
3.6
authorization
granting of privileges, which includes the granting of privileges to access data and functions
[SOURCE: ISO 7498-2:1989, modified]
3.7
availability
property of being accessible and useable upon demand by an authorized entity
[SOURCE: ISO 7498-2:1989]
3.8
certification authority
CA
certificate issuer; an authority trusted by one or more relying parties to create, assign, and manage
certificates
Note 1 to entry: Optionally, the certification authority can create the relying parties’ keys.
Note 2 to entry: Authority in the CA term does not imply any government authorization, only that it is trusted.
Certificate issuer might be a better term but CA is used very broadly.
[SOURCE: ISO/IEC 9594-8:2008]
3.9
confidentiality
property that information is not made available or disclosed to unauthorized individuals, entities, or
processes
[SOURCE: ISO 7498-2:1989]
2 © ISO 2014 – All rights reserved
3.10
delegation
conveyance of privilege from one entity that holds such privilege to another entity
3.11
identification
performance of tests to enable a data processing system to recognize entities
[SOURCE: ISO/IEC 2382-8:1998]
3.12
key
sequence of symbols that controls the operations of encipherment and decipherment
[SOURCE: ISO 7498-2:1989]
3.13
policy
set of legal, political, organizational, functional, and technical obligations for communication and
cooperation
3.14
policy agreement
written agreement where all involved parties commit themselves to a specified set of policies
3.15
principal
human users and objects that need to operate under their own rights
[SOURCE: OMG Security Services Specification: 2001]
3.16
private key
key that is used with an asymmetric cryptographic algorithm and whose possession is restricted
(usually to only one entity)
[SOURCE: ISO/IEC 10181-1:1996]
3.17
privilege
capacity assigned to an entity by an authority according to the entity’s attribute
3.18
public key
key that is used with an asymmetric cryptographic algorithm and that can be made publicly available
[SOURCE: ISO/IEC 10181-1:1996]
3.19
role
set of competences and/or performances that is associated with a task
3.20
security
combination of availability, confidentiality, integrity, and accountability
[SOURCE: ENV 13608-1:2000]
3.21
security policy
plan or course of action adopted for providing computer security
[SOURCE: ISO/IEC 2382-8:1998]
3.22
security service
service provided by a layer of communicating open systems which ensures adequate security of the
systems or of data transfers
[SOURCE: ISO 7498-2:1989]
3.23
strong authentication
authentication by means of cryptographically derived multi-factor credentials
3.24
target
resource being accessed by a claimant
4 Abbreviated terms
This list of abbreviated terms includes all abbreviations used in this part of ISO 22600.
CA Certification Authority
PKI Public Key Infrastructure
5 Goal and structure of privilege management and access control
5.1 Goal of privilege management and access control
The goals are:
a) To give directions for sharing information. This includes the policy agreement document template,
which defines and determines the structure and the contents of the agreement document.
b) To be a standard for privilege management and access control, which govern secure exchange of
information between security domains. In order to achieve this, a basic process for the information
exchange is defined. The standard for privilege management and access control also defines the
method for the secure trans-border information exchange process.
c) To establish a route for transformation of existing systems to future systems that fulfils all criteria
for the cross-border information exchange according to this International Standard.
The privilege and access control information exchange process takes into account existing situations
and takes care of standardization of information exchange across policy domain boundaries in existing
systems. The policy agreement, the policy repository, and the directory are central elements in this part
of ISO 22600.
5.2 Structure of privilege management and access control
5.2.1 Structure elements
This description of the structure for the process model of the information exchange across security
domain borders consists of the elements listed below. In this part of ISO 22600, the structure is explained
in a broad sense. For more detailed specifications, references to ISO 22600-2 are given.
4 © ISO 2014 – All rights reserved
The structure consists of the following elements:
— domain;
— policy;
— roles;
— directory;
— authentication;
— process.
The rules for these elements, agreed by the involved domains, are stored in a repository and can be
considered as a part of this structure.
5.2.2 Domain
To keep information systems that support shared care manageable and operating, principal-related
components of the system are grouped by common organizational, logical, and technical properties into
domains. Any kind of interoperability internally to a domain is called an intra-domain communication
and co-operation, whereas interoperability between domains is called an inter-domain communication
and co-operation. For example, communication could be realized between departments of a hospital
internally to the domain hospital (intra-domain communication), or externally to the domain of a special
department (inter-domain communication).
A domain might consist of sub-domains (which will inherit and might specialize policies from the parent
domain). The smallest-scale domain might be an individual workplace or a specific component within an
information system. Domains can be extended into super-domains, by chaining a set of distinct domains
and forming a common larger-scale domain for communication and co-operation.
5.2.3 Policy
5.2.3.1 Access control policy
A policy describes the organizational, administrative, legal, and technical framework including rules
and regulations, functionalities, claims and objectives, parties involved, agreements, rights, duties, and
penalties defined as well as the technological solution implemented for collecting, recording, processing,
and communicating data in information systems.
For describing policies, methods such as policy templates or formal policy modelling might be deployed.
In this International Standard, the policy model is described in ISO 22600-2:2014, 6.4. Regarding security
requirements, security policy is of special interest. The security policy is dealt with in ISO 22600-2:2014,
6.1.
The particular policy in this part of ISO 22600 regards a privilege management and access control
infrastructure. It specifies the requirements and conditions for trustworthy communication, creation,
storage, processing, and use of sensitive information. This includes legal and ethical implications,
organizational and functional aspects, as well as technical solutions.
Trustworthy co-operation between policy domains requires the definition of a common set of security
and privacy policies that applies to all collaborating entities. It shall be derived from the relevant
domain-specific policies across all of those policy domains. Those common security and privacy policies
are derived (negotiated) through a process known as policy bridging. The eventually agreed policies
need to be documented and signed by all of the domain authorities. Ideally, this whole process will be
capable of electronic representation and negotiation, to permit real-time electronic collaboration taking
place within a (pre-agreed) permitted and regulated framework. The policy negotiation in the case of
changing constraints, but at least identification, verification, and enforcement of the applicable policy,
has to take place at every service interaction.
The policy agreement is introduced in Clause 5 and is formally modelled using structured schemata
and templates in ISO 22600-2. An agreement process for information exchange shall precede the actual
information exchange process. The next subclause describes a scenario for the agreement process. The
agreement will constitute the basis for the actual information exchange process described in 5.2.8.
5.2.3.2 Agreement process
A successful agreement process depends upon the formation of a group of persons who have in-depth
knowledge of the business process requirements and systems involved in the information exchange
process and who are mandated to take decisions about the business process requirements for the
information exchange including but not limited to such attributes as the type, volume, content, quality,
timeliness, relevance, and currency of the data to be exchanged.
When the decision about the information to be exchanged has been made, the next step is to look at the
security and privacy policy in both systems and define a common policy that satisfies all parties. This
common policy can further constrain data and function permitted for communication and co-operation.
Annex A exemplifies the policy evaluation process, listing all requirements of both parties to assess
them using the proposed evaluation form. This International Standard offers an explicit way to express
policies. In legacy systems, the constraints are frequently just attributed in security levels.
In the next step of this agreement process, both parties compare their system with the evaluation
criteria by completing the evaluation form. These forms constitute the basis for the agreement between
the parties for the information exchange. Every situation where one system does not reach the level of
agreed security has to be noted in the agreement together with the action to be taken. A possible action
is to decide that no information exchange is permitted before the problem has been solved. Another
policy decided could be to constrain the communication and co-operation process in time, i.e. fixing the
requirement that the deficiency shall be corrected before a specified date.
Provisions for management and operations of common directory and policy repository services shall be
specified in the agreement.
5.2.4 Roles
Assignment of roles, privileges, and credentials as well as resulting resource access decisions have to
be dedicated to a specific principal. Therefore, identification and authentication of principals are basic
services for authorization, access control, and other application security and privacy services.
The role assignments can show great variation between healthcare establishments, both in granularity
and hierarchical organization. This creates difficulties for interoperability, which policy bridging should
overcome.
The generic concept of roles is described in ISO 22600-2:2014, 6.4 and Annex A. It will be covered in
ISO 21298.
5.2.5 Policy repository
A policy repository holds the set of rules for privilege management and access control as well as the set
of roles to which these apply. For inter-domain access control, these rules and the mechanism for role
mapping are stored in a common policy repository.
The common policy repository presents a formal representation of the policy agreement. It is used by
policy decision services, i.e. an access control service, in conjunction with the role information for an
individual entity to grant or deny access. If all requirements are met, a user of an application in one
security policy and privacy domain will be privileged to access or retrieve appropriate information
from the other security and privacy policy domain.
5.2.6 Directory
A directory service provides information about entities. Directory specifications should follow ISO 21091.
6 © ISO 2014 – All rights reserved
The common directory service to be used for inter-domain access control shall provide the necessary
information about all entities that are covered by the policy agreement. This includes information on
role assignment and authentication.
5.2.7 Authentication
There are different levels for principal authentication. Due to the sensitivity of health information and
the related security requirements, the highest level of both the requesting and the responding principals
within a communication and co-operation relationship has to be provided through strong mutual
authentication. Strong authentication should be realized in a multi-factor token-based way (minimally
by two factor credentials such as smartcards and passwords).
The authentication framework has been specified in ISO 9798 and ISO 10181. The authentication
procedure is based on a PKI. The PKI framework is given in ISO/TS 17090. The authentication certificate
follows the X.509v3 specification.
5.2.8 Process
Care processes are changing rapidly. It is therefore very important to create solutions that will allow
making the necessary changes in communication processes without any disturbances in the care
process. Many of the routines for allocation and withdrawal of roles and authorizations shall be made
as automatic as possible without losing the control. There are situations where persons involved in the
care of a patient shall have the ability to override authorizations assigned to roles and to be prepared to
justify it later.
The process will vary from site to site but the following process describes the guiding process for this
International Standard.
It consists of two security domains with one application in each domain.
An example scenario is that a person in security domain 1 needs information about a patient under his
care from security domain 2, where the patient has been treated at an earlier stage.
Under certain circumstances, the applications need to deliver to and/or retrieve information from each
other. The users of the applications govern the need. User access is controlled by each security domain
but can also be granted upon a request from a user in another security domain. The foreign request
is approved after it has been checked, with a positive result, against the agreed rules in the policy
repository. All these rules shall be specified in the policy agreement.
Both domains have their authorization system with roles according to their needs and different rules for
granting access to different information for the different roles.
The process model is visualized in Figure 1.
The steps in the process are as follows.
1) A new employee gets his/her role defined and assigned by the manager for the organizational unit
in which he or she is going to work as described in 5.2.4.
2) The new employee will then be registered in the authorization system that belongs to the appropriate
domain with the restrictions and authorization relevant for this role. This implies that the employee
is authenticated as described in 5.2.7.
3) Users in the two security domains, which fulfil the rules as defined in the policy agreement, can
then be found through the common directory service. The directory is reached from any application
in the domains covered by the policy agreement. See 5.2.6.
4) When an employee belonging to security domain 1 starts to use application 1, in system 1, in
security domain 1, the application has first to check his authorization in access control service 1
(see Figure 1).
5) Access to application 1 in security domain 1 is granted to the employee. The rules for intra- and
inter-domain communication of information are described in ISO 22600-2:2014, 6.1.
6) The employee using application 1 starts a request for information from application 2 in security
domain 2. The request contains the identifier and role of the requestor and a reference to the
relevant rule in the common policy repository.
7) In this situation, both systems will look in the policy repository to check if the requirements for
the information exchange are fulfilled. It is therefore necessary that security domains 1 and 2
have agreed upon a policy for this type of information exchange and that the rules are available
for verification in the policy repository. If the qualifications are fulfilled, the procedure continues
according to point 8 below. Otherwise, application 1 will notify the user that the request has been
denied.
8) Application 1 then sends a request for that information to application 2 in security domain 2.
9) The result of the request is then sent to application 1 where the employee can read and store it
together with the other information about that patient.
10) All transactions in application 1, application 2, the directory, and the policy repository and all
communication between the two domains shall be logged. Routines for monitoring the log shall be
defined in the policy agreement.
8 © ISO 2014 – All rights reserved
Figure 1 — Process model
6 Policy agreement
6.1 Overview
The basic part of the policy agreement shall contain descriptions of the actual legal framework including
rules and regulations. The organizational and administrative framework, functionalities, claims and
objectives, the principals involved, agreements, rights, duties, and penalties are defined as well as
the technological solution implemented for the creation, collection, storage, processing, disclosure,
retention, transmission, and use of data in applications within the security and privacy policy domains.
The policy agreement shall also contain a standardized document, purpose of which is to make it easier
to write an agreement that covers the necessary functions for the information interchange. A standard
template for the policy agreement is presented in Annex B.
Steps shall be taken to ensure that the policy agreement is understood by everybody communicating
and co-operating between the security and privacy policy domains. Ultimate responsibility for ensuring
compliance with the policy agreement rests with those within the organization who are legally
responsible for information and its appropriate use and management.
The functions are described in the following subclauses.
6.2 Identification
The policy agreement shall define the identity validation and/or verification methods used in the
domains, including identity proofing for methods used in the security and privacy policy domains for
the identification of principals such as persons (patients, healthcare professionals, health professionals,
etc.), organizations, systems, devices, applications, components, etc. If different identification systems
are used, the applied system has to be defined. Linking, mapping, or conversion mechanisms shall also
be defined. In that context, the use of a unique patient ID as well as namespace-related master patient
indexes and the use of a patient identification service shall be considered and specified.
6.3 Patient consent
The rules for patient consent have to be harmonized. If harmonization is not possible, principles have
to be defined ruling how differences shall be bridged. Both parties shall agree on those principles in the
policy agreement.
6.4 Patient privacy
Patient privacy is a key issue in communication across policy domain boundaries, and especially in
trans-border information exchange.
In order to gain a patient’s full confidence with the information transactions, it is of utmost importance
that the rules are clear and easily understood by the patients.
6.5 Information identification
The policy agreement shall define the procedure of accessing data across domain boundaries.
It shall be possible to specify, identify, and limit the information to be accessed by foreign users. For
different access modes such as read-only, transfer, process, or communicate, accessible information
might be different. Therefore, information shall be identifiable at the granularity level needed.
6.6 Information location
In order to secure the information retrieval, location and data structure of applications have to
be specified and understood by all parties. The policy agreement shall therefore contain detailed
information about the location and structure of data, uniquely described by identifiers such as URLs
and/or object identifiers (OIDs).
10 © ISO 2014 – All rights reserved
6.7 Information integrity
The integrity of the data shall be checked in order to detect unauthorized modification of data during
transfer between the security and privacy policy domains. The rules and techniques for such integrity
check shall be agreed upon and specified in the policy agreement.
6.8 Security
Security and privacy policy domains are distinguished by their policies. Ideally, the communicating and
cooperating security and privacy domains can commit to one and the same security model represented
by a harmonized policy. This is the primary goal, and the security standards defined at both CEN and
ISO shall be the primary tools for achieving this.
If such harmonization is not possible, it shall be specified in the policy agreement which policy can
be considered equivalent for which role, information, action, and purpose. For each role, information,
action, and purpose, a set of policies has to be defined. In cases where policies cannot be processed by
the systems involved, security levels have to be defined including the related rules and the equivalences
between them.
Details are defined in ISO 22600-2.
6.9 Authorization
The authorization process shall be defined in the policy agreement both internally to the security and
privacy policy domain and between the interconnected domains. Authorization is further described in
ISO 22600-2:2014, Clause 6.
6.10 Role structures
Roles are defined within each security and privacy policy domain. Privileges as well as contextual and
environmental conditions are defined in policies that are bound to one or more roles. Role assignments
and assertions are essential parts of the solution for the final policy bridging standard. The role model
is explained in detail in ISO 22600-2:2014, 6.6 to 6.9.
6.11 Assignment and attestation authorities
The policy agreement shall name the individuals in the organization who have the responsibility to
assign roles and attestation authority to employees. An employee with attestation authority has the
responsibility to atte
...
NORME ISO
INTERNATIONALE 22600-1
Première édition
2014-10-01
Informatique de santé — Gestion de
privilèges et contrôle d’accès —
Partie 1:
Vue d’ensemble et gestion des
politiques
Health informatics — Privilege management and access control —
Part 1: Overview and policy management
Numéro de référence
©
ISO 2014
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2014
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO 2014 – Tous droits réservés
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 4
5 Objectif et structure de la gestion des privilèges et du contrôle d’accès .4
5.1 Objectif de la gestion des privilèges et du contrôle d’accès . 4
5.2 Structure de la gestion des privilèges et du contrôle d’accès . 5
6 Accord de politique .10
6.1 Vue d’ensemble .10
6.2 Identification .10
6.3 Consentement du patient .10
6.4 Respect de la vie privée du patient .10
6.5 Identification d’informations.10
6.6 Localisation d’informations .11
6.7 Intégrité d’informations .11
6.8 Sécurité .11
6.9 Autorisation .11
6.10 Structures de rôle .11
6.11 Autorités d’attribution et d’attestation .11
6.12 Droits de délégation .11
6.13 Durée de validité.12
6.14 Authentification d’utilisateurs/rôles .12
6.15 Accès .12
6.16 Période de validité de l’accord de politique .12
6.17 Éthique .12
6.18 Journal d’audit de sécurité .12
6.19 Contrôle d’audit .13
6.20 Analyse de risque .13
6.21 Continuité et gestion des incidents .13
6.22 Futurs développements de système .13
7 Documentation .13
Annexe A (informative) Exemple d’un modèle de formulaire de documentation .14
Annexe B (informative) Exemple d’un accord de politique sur l’échange d’informations .22
Bibliographie .29
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui concerne
la normalisation électrotechnique.
Les procédures employées pour l’élaboration du présent document et celles destinées à son suivi sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient de noter les différents critères d’approbation
nécessaires aux différents types de documents ISO. Le présent document a été rédigé conformément aux
règles rédactionnelles des Directives ISO/IEC, Partie 2 (voir www.iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails relatifs à tous
droits de propriété identifiés au cours de l’élaboration du document figureront en Introduction et/ou
dans la liste ISO des déclarations de brevets reçues (voir www.iso.org/patents).
Tout nom commercial utilisé dans le présent document est une information donnée à des fins de
commodité pour l’utilisateur et ne bénéficie d’aucun appui particulier.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à l’évaluation
de la conformité, aussi bien que pour des informations au sujet de l’adhésion de l’ISO aux principes de
l’OMC concernant les obstacles techniques au commerce (OTC) voir le lien suivant: Avant-propos —
Informations supplémentaires.
Le comité chargé de l’élaboration du présent document est l’ISO/TC 215, Informatique de santé.
Cette première édition de l’ISO 22600-1 annule et remplace l’ISO/TS 22600-1:2006, qui a fait l’objet d’une
révision technique.
L’ISO 22600, présentée sous le titre général Informatique de santé — Gestion de privilèges et contrôle
d’accès, comprend les parties suivantes:
— Partie 1: Vue d’ensemble et gestion des politiques
— Partie 2: Modèles formels
— Partie 3: Mises en œuvre
iv © ISO 2014 – Tous droits réservés
Introduction
L’architecture répartie des systèmes d’informations de soins partagés s’appuie de plus en plus sur
des réseaux d’entreprise et des réseaux privés virtuels. Afin de relever le défi de l’interopérabilité, le
recours à des interfaces utilisateur, outils et protocoles normalisés qui garantissent l’indépendance
d’une plateforme s’est généralisé, tout comme le nombre de systèmes d’informations réellement ouverts
a rapidement augmenté au cours des dernières années.
À l’heure actuelle, il est très fréquent que des hôpitaux aient recours à plusieurs fournisseurs qui leur
installent des applications qui ne sont pas en mesure de communiquer une authentification et une
autorisation, puisque chaque application a sa propre manière de gérer ces fonctions. Aboutir à un
scénario intégré demanderait d’investir beaucoup d’argent, de temps et d’efforts pour faire correspondre
dynamiquement des utilisateurs et des environnements organisationnels changeants, avant même
de démarrer une communication et une coopération. Les ressources requises pour le développement
et la maintenance des fonctions de sécurité augmentent de façon exponentielle, parallèlement au
nombre d’applications, à l’évolution toujours plus complexe des organisations vers un niveau régional,
national, voire international et à la flexibilité des utilisateurs jouant des rôles multiples, parfois même
simultanément.
La situation s’avère même encore plus compliquée lorsqu’il s’agit de communications
inter-organisationnelles qui, comme leur nom le laisse entendre, excèdent les limites d’un domaine
de politique de sécurité. D’un centre de soins à un autre ou d’un pays à un autre, les règles régissant
les privilèges et leur gestion peuvent différer pour des types d’utilisateurs similaires, aussi bien pour
l’exécution de fonctions particulières que pour l’accès aux informations. Les différences de politiques
entre ces domaines doivent être comblées automatiquement ou via des accords de politique définissant
des ensembles de règles à respecter par les parties concernées, pour assurer l’interopérabilité.
Améliorer la qualité des soins grâce aux technologies de l’information (TI) sans pour autant violer la vie
privée du patient constitue un autre défi à relever. Afin que les médecins puissent disposer d’informations
pertinentes sur leurs patients, il est nécessaire de mettre en place un dossier informatisé de soins de
santé, permettant de garder une trace de toutes les activités associées à un patient donné, quels que
soient le lieu où ces activités ont été menées et la personne qui les a effectuées ou documentées. Dans
ce contexte, il est nécessaire de disposer d’un modèle général ou d’un accord spécifique passé entre les
parties pour pouvoir gérer les privilèges et le contrôle d’accès aux informations incluant le patient ou
son représentant.
Outre la diversité des rôles et responsabilités qui caractérise tout type de grande organisation, il est
important de prendre également en considération les questions éthiques et légales qui se posent dans le
cadre d’un scénario de soins de santé, en raison de la sensibilité des informations gérées, liées à la santé
de la personne, et de leur impact personnel et social.
Même si la gestion des privilèges et le contrôle d’accès requièrent d’ores et déjà la mise en œuvre de
solutions perfectionnées, ce besoin se fera davantage ressentir dans les prochaines années. Cela est dû à
l’augmentation du nombre d’informations échangées entre systèmes afin de répondre aux exigences des
prestataires de services de santé à différents niveaux de soins, qui veulent pouvoir accéder à toujours
plus d’informations sur le patient afin de garantir la qualité et l’efficacité des diagnostics et traitements
délivrés aux patients, même si cela implique des risques accrus en termes de sécurité et de respect de
la vie privée.
La présente Norme internationale constitue une avancée technologique telle que certains établissements
techniques et organisationnels peuvent juger son application infaisable dans l’état actuel des choses.
Par conséquent, afin de satisfaire au principe de base qui consiste à entreprendre la meilleure action
possible, il est très important que les différentes parties impliquées rédigent au moins un accord de
politique explicitant la volonté d’évoluer dans le sens de la présente Norme internationale si des mises à
jour/mises à niveau sont prévues. Le niveau de formalisation et de granularité des politiques et les objets
auxquels ces politiques sont liées définissent la maturité de la solution par rapport à la spécification
présentée.
L’accord de politique doit également mentionner les différences qui ont été identifiées entre les
systèmes de sécurité ainsi que les solutions retenues pour pallier ces différences. Par exemple, le service
d’authentification et les privilèges d’un demandeur au niveau du site de réponse doivent être gérés
conformément à la politique déclarée dans l’accord. Pour cette raison, le demandeur d’informations et de
services ainsi que le fournisseur d’informations et de services d’une part, et les informations et services
demandés et fournis d’autre part, doivent être regroupés et classés selon un nombre limité de concepts
afin de pouvoir spécifier un nombre limité de catégories de solutions. Il est alors possible, sur la base de
cette classification, de mettre en œuvre des mécanismes d’ayants droits, de sensibilité des cibles ainsi
que de spécification et de gestion des politiques. Une fois l’accord de politique signé par la totalité des
parties impliquées, la communication et l’échange d’informations peuvent débuter en s’appuyant sur
les systèmes existants, si les parties en acceptent les risques. En cas de risques inacceptables devant
être éliminés avant de débuter l’échange d’informations, ces risques doivent également être enregistrés
dans l’accord de politique, tout comme le plan d’actions explicitant la façon de supprimer ces risques.
L’accord de politique doit également inclure les échéances d’application du plan d’actions et ses moyens
de financement.
La documentation du processus de négociation est très importante et fournit la plateforme de l’accord
de politique.
La gestion des privilèges et le contrôle d’accès couvrent les services de sécurité et de respect de la
vie privée nécessaires à la communication et à la coopération, c’est-à-dire l’utilisation répartie des
informations de santé. Cela couvre également les aspects de sécurité et les normes professionnelles
ainsi que les questions légales et éthiques. La présente Norme internationale constitue une introduction
aux principes de gestion des privilèges et de contrôle d’accès et spécifie les services nécessaires à ces
activités. Les protocoles cryptographiques ne sont pas couverts par la présente Norme internationale.
La présente Norme internationale en trois parties comporte des références à des normes existantes
relatives à l’architecture et à la sécurité de même qu’à des spécifications dans le domaine des soins de
santé, comme des spécifications ISO, CEN, ASTM, OMG, W3C, etc., et est conforme à d’autres normes
pertinentes existantes ou sinon identifie les améliorations ou les modifications ou encore le besoin
d’élaborer de nouvelles normes. Elle se subdivise ainsi:
— ISO 22600-1: décrit les scénarios et les paramètres cruciaux de l’échange d’informations d’un
domaine de politique à un autre. Elle donne également des exemples des méthodes de documentation
nécessaires pouvant servir de base à l’établissement d’un accord de politique.
— ISO 22600-2: décrit et explique de manière plus détaillée les architectures et les modèles sous-
jacents de la gestion des privilèges et du contrôle d’accès nécessaires à la sécurisation du partage de
données incluant la représentation formelle des politiques.
— ISO 22600-3: donne des exemples détaillés de spécifications pouvant être mises en œuvre pour
les services de sécurité et les services d’infrastructure d’applications dans différents langages de
spécification.
Elle prend en compte la mise en relation des politiques. Elle est fondée sur un modèle conceptuel dans
lequel des serveurs d’autorisation locaux et des services d’annuaires et de répertoires de politiques
trans-domaines peuvent faciliter le contrôle d’accès dans diverses applications (composants logiciels). Le
répertoire de politiques fournit des informations sur les règles d’accès à diverses fonctions d’application
sur la base des rôles et d’autres attributs. Le service d’annuaire permet une identification de l’utilisateur
individuel. L’accès sera accordé ou non sur la base des quatre aspects suivants:
— l’identification authentifiée des acteurs principaux (c’est-à-dire utilisateurs humains et objets qui
ont besoin de fonctionner avec leurs propres droits);
— les règles d’accès à un objet d’information particulier, notamment le but de l’utilisation;
— les règles applicables aux attributs d’autorisation associés à l’acteur principal, fournies par le
gestionnaire d’autorisation;
— les fonctions de l’application spécifique.
vi © ISO 2014 – Tous droits réservés
La présente Norme internationale prend en charge une collaboration entre plusieurs gestionnaires
d’autorisation qui peuvent fonctionner au-delà de limites organisationnelles et de politique.
La présente Norme internationale est en relation étroite avec d’autres documents élaborés par le comité
technique ISO/TC 215 tels que l’ISO 17090 (toutes les parties), l’ISO 22857, l’ISO 21091 et l’ISO 21298.
Les personnes qui liront la présente Norme internationale devront également lire toutes les normes
associées.
NORME INTERNATIONALE ISO 22600-1:2014(F)
Informatique de santé — Gestion de privilèges et contrôle
d’accès —
Partie 1:
Vue d’ensemble et gestion des politiques
1 Domaine d’application
La présente Norme internationale, subdivisée en plusieurs parties, définit les principes de gestion des
privilèges et de contrôle d’accès aux données et/ou aux fonctions et spécifie les services nécessaires à
ces activités.
Elle se concentre sur la communication et l’utilisation des informations de santé distribuées au-delà des
limites d’un domaine de politique. Cela inclut le partage d’informations de santé entre professionnels
de santé non affiliés, établissements de santé, sociétés d’assurance-maladie, patients, membres du
personnel et partenaires commerciaux, par des individus tout comme par des systèmes d’application
utilisés dans un contexte local, voire régional ou même national.
Elle spécifie les concepts nécessaires pour chaque composante et est destinée à faciliter leur mise en
œuvre technique. Elle ne spécifiera pas l’utilisation de ces concepts pour des cheminements de processus
cliniques particuliers.
La présente partie de l’ISO 22600 propose un modèle d’accord de politique, qui permet d’obtenir de
toutes les parties impliquées dans l’échange d’informations une documentation comparable.
La présente partie de l’ISO 22600 exclut les détails propres à une plateforme ainsi que les détails de mise
en œuvre. Elle ne spécifie pas les services et protocoles de communication techniques qui ont été établis
dans d’autres normes. Elle exclut également les techniques d’authentification.
2 Références normatives
Les documents suivants, en totalité ou en partie, sont référencés de manière normative dans le présent
document et sont indispensables pour son application. Pour les références datées, seule l’édition citée
s’applique. Pour les références non datées, la dernière édition du document de référence s’applique (y
compris les éventuels amendements).
ISO 17090 (toutes les parties), Informatique de santé — Infrastructure de clé publique
ISO 21091, Informatique de santé — Services d’annuaires pour les fournisseurs de soins de santé, les sujets
de soins et autres entités
1)
ISO 21298:— , Informatique de santé — Rôles fonctionnels et structurels
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
1) À publier. (Révision de l’ISO/TS 21298.)
3.1
contrôle d’accès
ensemble des moyens garantissant que seules les entités autorisées peuvent accéder aux ressources
d’un système informatique, et seulement d’une manière autorisée
[SOURCE: ISO/IEC 2382-8:1998]
3.2
imputabilité
propriété qui garantit que les actions d’une entité ne peuvent être imputées qu’à cette entité
[SOURCE: ISO 7498-2:1989]
3.3
certificat d’attribut
structure de données, ayant été signée électroniquement par une autorité de gestion d’attribut qui lie
certaines valeurs d’attribut à une identification de son détenteur
[SOURCE: ISO/IEC 9594-8:2008]
3.4
authentification
moyen pour une entité d’assurer la légitimité d’une identité revendiquée par l’association sécurisée d’un
identifiant et de son authentifiant
Note 1 à l’article: Voir aussi authentification de l’origine des données et authentification de l’entité homologue.
[SOURCE: ISO/IEC 15944-5:2008, 3.5]
3.5
autorité
entité responsable de l’octroi des certificats
Note 1 à l’article: Deux types d’autorité sont définis dans la présente partie de l’ISO 22600, à savoir l’autorité de
certification qui octroie des certificats de clé publique et l’autorité de gestion d’attribut qui octroie des certificats
d’attribut.
3.6
autorisation
attribution de privilèges comprenant la délivrance de privilèges afin d’avoir accès à des données et
fonctions
[SOURCE: ISO 7498-2:1989, modifiée]
3.7
disponibilité
propriété d’être accessible et utilisable sur demande par une entité autorisée
[SOURCE: ISO 7498-2:1989]
3.8
autorité de certification
CA
émetteur de certificat; autorité de confiance déclarée compétente par une ou plusieurs parties
utilisatrices en matière de création, de délivrance et de gestion de certificats
Note 1 à l’article: L’autorité de certification peut éventuellement créer les clés de parties utilisatrices.
Note 2 à l’article: La notion d’autorité incluse dans le terme « autorité de certification » n’implique en rien une
autorisation gouvernementale, mais véhicule simplement une notion de confiance. Le terme « émetteur de
certificat » est peut-être moins ambigu, mais le terme « autorité de certification » est très largement employé.
[SOURCE: ISO/IEC 9594-8:2008]
2 © ISO 2014 – Tous droits réservés
3.9
confidentialité
propriété d’une information qui n’est ni disponible, ni divulguée aux personnes, entités ou processus
non autorisés
[SOURCE: ISO 7498-2:1989]
3.10
délégation
transmission d’un privilège détenu par une entité à une autre entité
3.11
identification
exécution de tests permettant à un système de traitement des données de reconnaître des entités
[SOURCE: ISO/IEC 2382-8:1998]
3.12
clé
série de symboles commandant les opérations de chiffrement et de déchiffrement
[SOURCE: ISO 7498-2:1989]
3.13
politique
ensemble d’obligations légales, politiques, organisationnelles, fonctionnelles et techniques applicable à
une communication et à une coopération
3.14
accord de politique
accord écrit par le biais duquel toutes les parties impliquées s’engagent à respecter un ensemble de
politiques préalablement spécifié
3.15
acteur principal
utilisateurs humains et objets qui doivent fonctionner avec leurs propres droits
[SOURCE: Spécification de l’OMG relative aux services de sécurité (OMG Security Services Specification):
2001]
3.16
clé privée
clé qui est utilisée avec un algorithme asymétrique de cryptographie et dont la possession est limitée
(habituellement à une seule entité)
[SOURCE: ISO/IEC 10181-1:1996]
3.17
privilège
capacité assignée par une autorité à une entité selon son attribut
3.18
clé publique
clé qui est utilisée avec un algorithme asymétrique de cryptographie et qui peut être rendue publique
[SOURCE: ISO/IEC 10181-1:1996]
3.19
rôle
ensemble de compétences et/ou de comportements associés à une tâche
3.20
sécurité
combinaison de propriétés de sécurité (telles que disponibilité, confidentialité, intégrité et imputabilité)
[SOURCE: ENV 13608-1:2000]
3.21
politique de sécurité
plan ou programme d’action adopté pour assurer la sécurité informatique
[SOURCE: ISO/IEC 2382-8:1998]
3.22
service de sécurité
service, fourni par une couche de systèmes ouverts, garantissant une sécurité des systèmes et du
transfert de données
[SOURCE: ISO 7498-2:1989]
3.23
stricte authentification
authentification à partir d’un justificatif d’identité à multiples facteurs obtenu de manière cryptographique
3.24
cible
ressource à laquelle un ayant droit accède
4 Abréviations
La liste d’abréviations ci-dessous inclut toutes les abréviations employées dans la présente partie de
l’ISO 22600.
CA Certification Authority (autorité de certification)
PKI Public Key Infrastructure (infrastructure de clé publique)
5 Objectif et structure de la gestion des privilèges et du contrôle d’accès
5.1 Objectif de la gestion des privilèges et du contrôle d’accès
Les objectifs sont les suivants:
a) Donner des orientations pour le partage d’informations. Cela inclut le modèle de formulaire d’accord
de politique, qui définit et détermine la structure et le contenu du document d’accord.
b) Constituer une pratique normalisée pour la gestion des privilèges et le contrôle d’accès, qui régit
l’échange sécurisé d’informations entre domaines de sécurité. De manière à atteindre cet objectif,
un processus de base d’échange d’informations est défini. La pratique normalisée de gestion
des privilèges et de contrôle d’accès définit également la méthode de sécurisation du processus
d’échange d’informations trans-domaines.
c) Établir la manière de passer de systèmes existants aux futurs systèmes qui satisferont à tous les
critères d’échange d’informations trans-domaines selon la présente Norme internationale.
Le processus d’échange d’informations de privilège et de contrôle d’accès prend en compte les situations
existantes et vise à aboutir à une normalisation de l’échange d’informations d’un domaine de politique à
un autre dans des systèmes existants. L’accord de politique, le répertoire de politiques et l’annuaire sont
des éléments capitaux dans la présente partie de l’ISO 22600.
4 © ISO 2014 – Tous droits réservés
5.2 Structure de la gestion des privilèges et du contrôle d’accès
5.2.1 Éléments de structure
Cette description de la structure du modèle de processus de l’échange d’informations d’un domaine
de sécurité à un autre est constituée des éléments répertoriés ci-dessous. Dans la présente partie de
l’ISO 22600, la structure est expliquée au sens large. Pour des spécifications plus détaillées, il est fait
référence plusieurs fois à l’ISO 22600-2.
La structure est constituée des éléments suivants:
— domaine;
— politique;
— rôles;
— annuaire;
— authentification;
— processus.
Les règles applicables à ces éléments, que les domaines impliqués ont approuvées, sont mémorisées dans
un répertoire et il peut être considéré qu’elles font partie de cette structure.
5.2.2 Domaine
Afin de pouvoir continuer à gérer et à faire fonctionner des systèmes d’informations qui prennent en
charge les soins partagés, les composantes du système associées à l’acteur principal sont regroupées
en domaines, en fonction de leurs propriétés organisationnelles, logiques et techniques communes.
Une interopérabilité interne à un domaine quelle qu’elle soit est appelée communication et coopération
intra-domaine, alors qu’une interopérabilité entre plusieurs domaines est appelée communication et
coopération inter-domaine. Par exemple, une communication pourrait être effectuée entre plusieurs
services d’un hôpital de manière interne au domaine hôpital (communication intra-domaine) ou de
manière externe au domaine vers un service particulier (communication inter-domaine).
Un domaine peut être constitué de sous-domaines (lesquels hériteront des politiques du domaine parent
et pourront les spécialiser). Le plus petit domaine possible peut être un lieu de travail individuel, ou
une composante particulière au sein d’un système d’informations. Il est possible d’accroître la portée
des domaines grâce à des super-domaines, obtenus en reliant un ensemble de domaines distincts et en
formant ainsi un domaine commun à portée accrue pour la communication et la coopération.
5.2.3 Politique
5.2.3.1 Politique de contrôle d’accès
Une politique décrit le cadre organisationnel, administratif, légal et technique en y incluant des règles
et règlements, des fonctionnalités, des déclarations et objectifs, des descriptifs des parties impliquées,
des accords, des droits, des obligations et des pénalités définis de même que la solution technologique
mise en œuvre pour la collecte, l’enregistrement, le traitement et la communication des données dans
des systèmes d’informations.
Pour décrire les politiques, des méthodes telles que des modèles de formulaire de politique ou une
modélisation formelle de politique peuvent être déployées. Dans la présente Norme internationale,
le modèle de formulaire de politique est décrit dans l’ISO 22600-2:2014, au paragraphe 6.4. En ce qui
concerne les exigences de sécurité, la politique de sécurité est d’un grand intérêt. La politique de sécurité
est abordée dans l’ISO 22600-2:2014, au paragraphe 6.1.
La politique particulière décrite dans la présente partie de l’ISO 22600 concerne une infrastructure de
gestion des privilèges et de contrôle d’accès. Elle spécifie les exigences et les conditions applicables à la
communication, à la création, à la mémorisation, au traitement et à l’utilisation en toute confiance des
informations sensibles. Cela inclut des conséquences légales et éthiques, des aspects organisationnels et
fonctionnels de même que des solutions techniques.
Une coopération en toute confiance entre des domaines de politique requiert la définition d’un ensemble
commun de politiques de sécurité et de respect de la vie privée qui s’applique à toutes les entités
intervenant dans un travail de collaboration. Cette définition doit être obtenue à partir des politiques
pertinentes propres à chaque domaine pour tous les domaines de politique. Ces politiques de sécurité
et de respect de la vie privée communes sont obtenues (après négociation) par l’intermédiaire d’un
processus connu sous le nom de mise en relation de politiques. Les politiques ayant éventuellement fait
l’objet d’un accord doivent être documentées et signées par toutes les autorités du domaine. Dans l’idéal,
la mise en œuvre de ce processus dans son intégralité aboutira à une représentation électronique et
à une négociation, permettant une collaboration électronique en temps réel au sein d’un cadre admis
(ayant fait l’objet d’un accord préalable) et réglementé. La négociation de politique dans le cas de
contraintes en évolution, mais portant au moins sur l’identification, la vérification et l’exécution de la
politique applicable doit avoir lieu au niveau de chaque interaction entre services.
L’accord de politique est introduit à l’Article 5 et est modélisé de manière formelle en utilisant les
schémas structurés et les modèles de formulaire présentés dans l’ISO 22600-2. Un processus d’accord
concernant l’échange d’informations doit précéder le réel processus d’échange d’informations. Le
paragraphe suivant décrit un scénario de processus d’accord. L’accord constituera la base du processus
réel d’échange d’informations décrit en 5.2.8.
5.2.3.2 Processus d’accord
Un processus d’accord réussi dépend de la constitution d’un groupe de personnes qui ont une connaissance
approfondie des exigences des processus métier et des systèmes impliqués dans le processus d’échange
d’informations, et qui sont mandatées pour prendre des décisions sur les exigences de ces processus en
tenant compte, entre autres, des attributs tels que le type, le volume, le contenu, la qualité, la rapidité, la
pertinence et la fiabilité des données à échanger.
Une fois la décision concernant les informations à échanger prise, l’étape suivante est de consulter
la politique de sécurité et de respect de la vie privée des deux systèmes et de définir une politique
commune qui réponde aux besoins de toutes les parties. Cette politique commune peut en outre limiter
les données et fonctions admises pour communiquer et coopérer. L’Annexe A donne un exemple du
processus d’évaluation d’une politique, en répertoriant toutes les exigences des deux parties afin de les
évaluer à l’aide du formulaire d’évaluation proposé. La présente Norme internationale offre une façon
explicite d’exprimer les politiques. Dans les systèmes existants, les contraintes sont souvent simplement
attribuées dans les niveaux de sécurité.
La prochaine étape de ce processus d’accord consiste pour les deux parties à comparer leur système
aux critères d’évaluation en complétant le formulaire d’évaluation. Ces formulaires constituent la base
de l’accord entre les parties pour l’échange d’informations. Toute situation dans le cadre de laquelle
un système n’atteint pas le niveau de sécurité convenu doit être notée dans l’accord de même que
l’action entreprise pour résoudre ce manquement. Une action possible est de décider qu’aucun échange
d’informations n’est autorisé avant que le problème ne soit résolu. Une autre action serait de décider
d’une politique permettant de limiter le processus de communication et de coopération dans le temps, à
savoir en fixant comme exigence que le manquement soit corrigé avant une date donnée.
Les dispositions de gestion et les modes de fonctionnement des services communs d’annuaires et de
répertoires de politiques doivent être spécifiés dans l’accord.
5.2.4 Rôles
L’attribution de rôles, de privilèges et de justificatifs d’identité de même que les prises de décision
concernant l’accès aux ressources qui en résultent doivent être confiées à un acteur principal spécifique.
Par conséquent, l’identification et l’authentification des acteurs principaux constituent les services de
6 © ISO 2014 – Tous droits réservés
base de l’autorisation, du contrôle d’accès et d’autres services de sécurité et de respect de la vie privée
au niveau des applications.
L’attribution des rôles peut être effectuée de manière très différente selon les établissements de soins de
santé, tant sur le plan de la granularité que sur l’organisation hiérarchique. Cela crée des difficultés en
termes d’interopérabilité, qu’il convient que la mise en relation de politiques surmonte.
Le concept général de rôles est décrit dans l’ISO 22600-2:2014, 6.4 et dans l’Annexe A. Il sera également
traité dans l’ISO 21298.
5.2.5 Répertoire de politiques
Le répertoire de politiques détient l’ensemble de règles applicables à la gestion des privilèges et au
contrôle d’accès de même que l’ensemble de rôles auxquels ces activités s’appliquent. Dans le cadre d’un
contrôle d’accès inter-domaine, ces règles et le mécanisme de mise en correspondance des rôles sont
mémorisés dans un répertoire de politiques commun.
Le répertoire de politiques commun constitue une représentation formelle de l’accord de politique.
Il est utilisé par des services de prise de décision concernant une politique, c’est-à-dire un service de
contrôle d’accès, en complément des informations du rôle pour accorder ou refuser l’accès à une entité
individuelle. Si toutes les exigences sont satisfaites, un utilisateur d’une application dans un premier
domaine de politique de sécurité et de respect de la vie privée se verra accorder le privilège d’avoir accès
aux informations appropriées ou de les récupérer auprès d’un autre domaine de politique de sécurité et
de respect de la vie privée.
5.2.6 Annuaire
Un service d’annuaire fournit des informations concernant des entités. Il convient que les spécifications
d’annuaire suivent l’ISO 21091.
Le service d’annuaire commun servant au contrôle d’accès inter-domaine doit fournir les informations
nécessaires sur toutes les entités concernées par l’accord de politique. Cela inclut les informations sur
l’attribution et l’authentification des rôles.
5.2.7 Authentification
Il existe plusieurs niveaux d’authentification des acteurs principaux. En raison de la sensibilité des
informations de santé et des exigences de sécurité associées, le plus haut niveau de l’acteur principal
à l’origine d’une demande et de l’acteur principal répondant à cette demande au sein d’une relation de
communication et de coopération doit être fourni par l’intermédiaire d’une stricte authentification
mutuelle. Il convient d’effectuer une stricte authentification multi-facteur à l’aide de jetons (au minimum
avec des justificatifs d’identité à deux facteurs tels que des cartes à puce et des mots de passe).
La structure d’authentification est spécifiée dans l’ISO 9798 et l’ISO 10181. La procédure d’authentification
est fondée sur une infrastructure de clé publique (PKI). Le cadre de l’infrastructure PKI est décrit dans
l’ISO/TS 17090. Le certificat d’authentification suit la spécification X.509v3.
5.2.8 Processus
Les processus de soins évoluent avec une grande rapidité. Il est par conséquent très important de créer des
solutions qui permettront de réaliser les changements nécessaires dans les processus de communication
sans engendrer de perturbation dans le processus de soins. Nombre de routines d’attribution et de
retrait de rôles et d’autorisations doivent autant que possible être exécutées de manière automatique,
sans perdre pour autant le contrôle. Il existe des situations dans le cadre desquelles des personnes
impliquées dans les soins d’un patient doivent avoir la possibilité de ne pas respecter les autorisations
affectées aux rôles et de pouvoir le justifier ultérieurement.
Le processus variera d’un site à un autre, mais le processus suivant en décrit le principe de fonctionnement
pour la présente Norme internationale.
Il est constitué de deux domaines de sécurité avec une seule application dans chaque domaine.
Un scénario d’exemple est qu’une personne ayant à charge un patient dans un domaine de sécurité 1
a besoin d’informations le concernant émanant d’un domaine de sécurité 2 où le patient a été traité
précédemment.
Dans certaines circonstances, les applications doivent fournir des informations à d’autres applications
et/ou récupérer des informations auprès d’autres applications. Les utilisateurs des applications sont à
l’origine de ce besoin. L’accès utilisateur est contrôlé par chaque domaine de sécurité, mais peut également
être accordé à un utilisateur se trouvant dans un autre domaine de sécurité sur simple requête. La
requête étrangère est approuvée après qu’elle a été vérifiée et que le résultat de cette vérification est
positif par rapport aux règles convenues dans le répertoire de politique. Toutes ces règles doivent être
spécifiées dans l’accord de politique.
Les deux domaines ont leur propre système d’autorisation et leurs propres rôles selon leurs besoins et
différentes règles d’accord d’accès aux différentes informations pour les différents rôles.
Le modèle de processus est représenté à la Figure 1.
Les étapes du processus sont les suivantes:
1) Un nouvel employé voit son rôle défini et attribué par le gestionnaire de l’unité organisationnelle
dans laquelle il va travailler, comme décrit en 5.2.4.
2) Le nouvel employé sera ensuite enregistré dans le système d’autorisation appartenant au domaine
approprié avec les restrictions et autorisations pertinentes pour ce rôle. Cela implique que l’employé
est authentifié comme décrit en 5.2.7.
3) Les utilisateurs des deux domaines de sécurité, qui satisfont aux règles définies dans l’accord de
politique, peuvent être retrouvés grâce au service d’annuaire commun. L’annuaire est accessible à
partir de toute application dans les domaines couverts par l’accord de politique. Voir 5.2.6.
4) Lorsqu’un employé appartenant au domaine de sécurité 1 commence à utiliser l’application 1 dans
le système 1 relevant du domaine de sécurité 1, l’application doit d’abord vérifier son autorisation
dans le service de contrôle d’accès 1 (voir Figure 1).
5) L’accès à l’application 1 dans le domaine de sécurité 1 est accordé à l’employé. Les règles applicables
à la communication intra et inter-domaine des informations sont décrites dans l’ISO 22600-2:2014,
6.1.
6) L’employé utilisant l’application 1 lance une requête pour obtenir une information auprès de
l’application 2 dans le domaine de sécurité 2. La requête contient l’identifiant et le rôle du demandeur
et une référence à la règle pertinente dans le répertoire de politiques commun.
7) Dans cette situation, les deux systèmes examineront le répertoire de politiques pour vérifier si les
exigences applicables à l’échange d’informations sont satisfaites. Il est par conséquent nécessaire
que les domaines de sécurité 1 et 2 soient régis par une politique qui a fait l’objet d’un accord pour
ce type d’échange d’informations et que les règles soient disponibles pour une vérification dans le
répertoire de politiques. Si les qualifications sont satisfaites, la procédure continue conformément
au point 8 ci-dessous. Sinon, l’application 1 notifiera à l’utilisateur qu
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.