+Identity and Access Management (IDM)
---+Policy for user accounts and access rights
---+Granting and change of user accounts and access rights
---+Locking and withdrawal of user accounts in the event of inactivity or multiple failed logins
---+Withdraw or adjust access rights as the task area changes
---+Regular review of access rights
---+Privileged access rights
---+Access to cloud customer data
---+Confidentiality of authentication information
---+Authentication mechanisms

Identity and Access Management (IDM)

None

1. Resumen

Título Estándar
Policy for user accounts and access rights A role and rights concept based on the business and security requirements of the Cloud Service Provider as well as a policy for managing user accounts and access rights for internal and external employees of the Cloud Service Provider and system components that have a role in automated authorisation processes of the Cloud Service Provider are documented, communicated and made available according to SP-01:
• Assignment of unique usernames;
• Granting and modifying user accounts and access rights based on the “leastprivilege principle” and the “needtoknow” principle;
• Segregation of duties between operational and monitoring functions (“Segregation of Duties”);
• Segregation of duties between managing, approving and assigning user accounts and access rights;
• Approval by authorised individual(s) or system(s) for granting or modifying user accounts and access rights before data of the cloud customer or system components used to provision the cloud service can be accessed;
• Regular review of assigned user accounts and access rights;
• Blocking and removing access accounts in the event of inactivity;
• Timebased or eventdriven removal or adjustment of access rights in the event of changes to job responsibility;
• Twofactor or multifactor authentication for users with privileged access;
• Requirements for the approval and documentation of the management of user accounts and access rights.
Additonal Criteria-
Supplementary Information - About the CriteriaSystem components in the sense of the basic criterion cf. definition in OPS-23. Automated authorisation processes in the sense of this basic criterion concern procedures for automated software provisioning (continuous delivery) as well as for automated provisioning and deprovisioning of user accounts and access rights based on approved requests.
Granting and change of user accounts and access rights Specified procedures for granting and modifying user accounts and access rights for internal and external employees of the Cloud Service Provider as well as for system components involved in automated authorisation processes of the Cloud Service Provider ensure compliance with the role and rights concept as well as the policy for managing user accounts and access rights.
Additonal CriteriaThe Cloud Service Provider offers cloud customers a self-service with which they can independently assign and change user accounts and access rights.
Supplementary Information - About the Criteria-
Locking and withdrawal of user accounts in the event of inactivity or multiple failed logins User accounts of internal and external employees of the Cloud Service Provider as well as for system components involved in automated authorisation processes of the Cloud Service Provider are automatically locked if they have not been used for a period of two months. Approval from authorised personnel or system components are required to unlock these accounts.
Locked user accounts are automatically revoked after six months. After revocation, the procedure for granting user accounts and access rights (cf. IDM-02) must be repeated.
Additonal Criteria-
Supplementary Information - About the CriteriaLocking can result from a longer absence of the employee, for example, due to illness, parental leave, or sabbatical.
Withdraw or adjust access rights as the task area changes Access rights are promptly revoked if the job responsibilities of the Cloud Service Provider's internal or external staff or the tasks of system components involved in the Cloud Service Provider's automated authorisation processes change. Privileged access rights are adjusted or revoked within 48 hours after the change taking effect. All other access rights are adjusted or revoked within 14 days. After revocation, the procedure for granting user accounts and access rights (cf. IDM-02) must be repeated.
Additonal Criteria-
Supplementary Information - About the CriteriaChanges in the task area of internal and external employees can be triggered by changes in the employment relationship (e.g. termination, transfer) or in contracts and agreements. For privileged access rights the definition in IDM-06 applies.
Regular review of access rights Access rights of internal and external employees of the Cloud Service Provider as well as of system components that play a role in automated authorisation processes of the Cloud Service Provider are reviewed at least once a year to ensure that they still correspond to the actual area of use. The review is carried out by authorised persons from the Cloud Service Provider's organisational units, who can assess the appropriateness of the assigned access rights based on their knowledge of the task areas of the employees or system components. Identified deviations will be dealt with promptly, but no later than 7 days after their detection, by appropriate modification or withdrawal of the access rights.
Additonal CriteriaPrivileged access rights are reviewed at least every six months.
Supplementary Information - About the Criteria-
Privileged access rights Privileged access rights for internal and external employees as well as technical users of the Cloud Service Provider are assigned and changed in accordance to the policy for managing user accounts and access rights (cf. IDM-01) or a separate specific policy.
Privileged access rights are personalised, limited in time according to a risk assessment and assigned as necessary for the execution of tasks ("needtoknow principle"). Technical users are assigned to internal or external employees of the Cloud Service Provider.
Activities of users with privileged access rights are logged in order to detect any misuse of privileged access in suspicious cases. The logged information is automatically monitored for defined events that may indicate misuse. When such an event is identified, the responsible personnel are automatically informed so that they can promptly assess whether misuse has occurred and take corresponding action. In the event of proven misuse of privileged access rights, disciplinary measures are taken in accordance with HR-04.
Additonal Criteria-
Supplementary Information - About the CriteriaPrivileged access rights in the sense of the Basic Criterion are those that enable employees of the Cloud Service Provider to perform any of the following activities:
• Read or write access to the cloud customers' data processed, stored or transmitted in the cloud service, unless such data is encrypted or the encryption can be deactivated for access by the Cloud Service Provider; and
• Changes to the operational and/or security configuration of the system components in the production environment, in particular the starting, stopping, deleting or deactivating of system components, if this can affect the confidentiality, integrity or availability of the data of the cloud customers (also indirectly, e.g. by deactivating the logging and monitoring of securityrelevant events). Misused privileged access rights can be treated e.g. as a security incident, cf. SIM01.
Access to cloud customer data The cloud customer is informed by the Cloud Service Provider whenever internal or external employees of the Cloud Service Provider read or write to the cloud customer's data processed, stored or transmitted in the cloud service or have accessed it without the prior consent of the cloud customer. The Information is provided whenever data of the cloud customer is/was not encrypted, the encryption is/was disabled for access or the contractual agreements do not explicitly exclude such information. The information contains the cause, time, duration, type and scope of the access. The information is sufficiently detailed to enable subject matter experts of the cloud customer to assess the risks of the access. The information is provided in accordance with the contractual agreements, or within 72 hours after the access.
Additonal CriteriaAccess to the data processed, stored or transmitted in the cloud service by internal or external employees of the Cloud Service Provider requires the prior consent of an authorised department of the cloud customer, provided that the cloud customer's data is not encrypted, encryption is disabled for access, or contractual agreements do not explicitly exclude such consent. For the consent, the cloud customer's department is provided with meaningful information about the cause, time, duration, type and scope of the access supporting assessing the risks associated with the access.
Supplementary Information - About the CriteriaSubject matter experts in the sense of this basic criterion is personnel from e.g. IT, Compliance or Internal Audit.
Confidentiality of authentication information The allocation of authentication information to access system components used to provide the cloud service to internal and external users of the cloud provider and system components that are involved in automated authorisation processes of the cloud provider is done in an orderly manner that ensures the confidentiality of the information. If passwords are used as authentication information, their confidentiality is ensured by the following procedures, as far as technically possible:
• Users can initially create the password themselves or must change an initial password when logging on to the system component for the first time. An initial password loses its validity after a maximum of 14 days.
• When creating passwords, compliance with the password specifications (cf. IDM-09) is enforced as far as technically possible.
• The user is informed about changing or resetting the password.
• The server-side storage takes place using cryptographically strong hash functions.
Deviations are evaluated by means of a risk analysis and mitigating measures derived from this are implemented.
Additonal CriteriaThe users sign a declaration in which they assure that they treat personal (or shared) authentication information confidentially and keep it exclusively for themselves (within the members of the group).
Supplementary Information - About the CriteriaArgon2i, for example, is suitable for using a password hash function.
Insofar as this is legally binding, declarations can be signed using an electronic signature.
Authentication mechanisms System components in the Cloud Service Provider's area of responsibility that are used to provide the cloud service, authenticate users of the Cloud Service Provider's internal and external employees as well as system components that are involved in the Cloud Service Provider's automated authorisation processes. Access to the production environment requires twofactor or multifactor authentication. Within the production environment, user authentication takes place through passwords, digitally signed certificates or procedures that achieve at least an equivalent level of security. If digitally signed certificates are used, administration is carried out in accordance with the Guideline for Key Management (cf. CRY01). The password requirements are derived from a risk assessment and documented, communicated and provided in a password policy according to SP01. Compliance with the requirements is enforced by the configuration of the system components, as far as technically possible.
Additonal CriteriaAccess to the nonproduction environment requires twofactor or multifactor authentication. Within the nonproduction environment, users are authenticated using passwords, digitally signed certificates, or procedures that provide at least an equivalent level of security.
Supplementary Information - About the Criteria-

1.1 Referencias

1.2 Requisitos identificados

1.3 Regulaciones relacionadas

2. Requisitos identificados

Requisitos
Fuente Requisito

3. Regulaciones relacionadas

Regulaciones
Fuente Regulación