+IAM-01 Policy for Identities and Access Rights
---+IAM-01.01B
---+IAM-01.02B
---+IAM-01.03B
---+IAM-01.01AC

1. Übersicht

IAM-01 Policy for Identities and Access Rights

-
IAM-01.01B The cloud service provider documents, communicates and makes available according to SP-01:

1. An authorisation framework based on role-based access control and the business and security requirements of the cloud service provider; and
2. A policy for managing identities and access rights for internal and external personnel of the cloud service provider and system components that have a role in automated authorisation processes of the cloud service provider.


External personnel includes freelancers, temporary workers, suppliers and service providers with access to system components.

Requirements for physical access control in accordance with the policy for identities and access rights are specified in more detail in the physical access control policy (cf. PS-04).

If the cloud service provider offers federated identity services, in particular if the cloud service provider offers these services as a cloud service broker, the documents defined in these subcriteria should recognise the complexity of the particular cloud service architecture. This can include, but is not limited to, the following aspects:

1. Management of the trust boundaries between the different parties involved in the authentication process of a federated identity;
2. Propagation of identity management-related events across all parties involved in the authentication process of a federated identity;
3. Logging of events related to the authentication process of a federated identity; and
4. Notification of cloud service customers in case of a federation credential being compromised or a trust boundary being violated.
IAM-01.02B For the purpose of the business and security requirements these documents address at least the following aspects:

1. Aspects that are relevant for making access control decisions;
2. Assignment of unique usernames;
3. Granting and modifying identities and access rights based on the 'least-privilege-principle' and the 'need-to-know-principle';
4. Application of a role-based mechanism for assigning access rights;
5. Definition of the supported identity and role-based access types, including an assignment of access control parameters and roles to be considered for each type;
6. Segregation of duties between operational and monitoring functions ('Segregation of Duties');
7. Assigning and monitoring privileged access rights;
8. Approval by authorised individual(s) or system(s) for granting or modifying identities and access rights before cloud service customer data, cloud service derived data and cloud service provider data can be accessed;
9. Regular review of assigned identities and access rights;
10. Blocking and removing identities or limiting access in the event of inactivity;
11. Specific measures for managing identities whose use is restriced to emergency recovery and similar scenarios;
12. Time-based or event-driven removal or adjustment of access rights in the event of changes to job responsibility;
13. Multi-factor authentication for users with privileged access;
14. Remote access and access across geographic boundaries;
15. Requirements for approving and documenting the management of identities and access rights; and
16. Measures to be taken upon the detection of a potential identity compromise, such as disabling and removing the affected identities.


System components in the sense of the criterion are defined in OPS-26. 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 identities and access rights based on approved requests.

For containers, identities and access rights should be managed according to a regulated process, especially for automated authorisation processes in container environments.

If a cloud service provider uses alternative access methods for which it is not possible or feasible to block and remove identities (such as time-bounded access methods), limiting the access to an identity is an another solution for handling inactivity that fulfils this subcriterion.

Requirements for physical access control in accordance with the policy for identities and access rights are specified in more detail in the physical access control policy (cf. PS-04).

If the cloud service provider offers federated identity services, in particular if the cloud service provider offers these services as a cloud service broker, the documents defined in these subcriteria should recognise the complexity of the particular cloud service architecture. This can include, but is not limited to, the following aspects:

1. Management of the trust boundaries between the different parties involved in the authentication process of a federated identity;
2. Propagation of identity management-related events across all parties involved in the authentication process of a federated identity;
3. Logging of events related to the authentication process of a federated identity; and
4. Notification of cloud service customers in case of a federation credential being compromised or a trust boundary being violated.
IAM-01.03B The cloud service provider is capable of producing a list of the currently granted cloud-based access rights for each identity under its responsibility.

Based on this list, the cloud service provider is able to review the cloud-based access rights of the given identity.

'Cloud-based' in this case refers to all of the access rights that are within the scope of the cloud service provider's system of internal control.
IAM-01.01AC Access logs are reviewed at least every month in order to detect attempts of unauthorised access or suspicious access patterns.

A review can be carried out manually or via automated manners. In a monthly review, suspicious behaviours like e.g. access failures over a larger time frame (e.g. once a day) or consecutive logins from different countries may show up that a SIEM that only analyses real-time login attemps may overlook.

1.1 Referenzen

1.2 Identifizierte Anforderungen

1.2 Related Regulation

2. Identifizierte Anforderungen

Anforderungen

3. Related Regulations

Regulations
Impressum