Identity and Access Management Concept
Multi-Cloud IAM architecture concept based on federated identities and authentication.Why Do You Need an Identity and Access Management Concept?
Identity and Access Management is at the core of managing trust in the cloud. Authentication and Authorization based on identities replace mechanisms from the private data center era such as trust-based on host IP.
An Identity and Access Management Concept is a document that describes your Identity and Access Management architecture for future reference.
An important distinction is IAM for humans vs. IAM for workload. Making this distinction in the Identity and Access Management Concept allows the discussion of one topic at a time.
Easy Management of Roles, Users and Permissions
Managing Identities is at the core of managing trust in the cloud. Doing so requires an airtight concept - especially for the growing complexity of multi-cloud environments.
Learn more →What an Identity and Access Management Concept Has to Cover
Core Questions
What is your source of identities?
How do identities flow from the source to other systems? (See Federated Identity and Authentication)
What level of separation will you have between different applications?
How do you keep a central overview over access permissions when there are multiple clouds involved?
Specific Questions on IAM for Humans
An Identity and Access Management Concept needs to answer the following questions:
How do you ensure Joiner / Mover / Leaver processes are supported in different parts of your Identity and Access Management landscape? (See Identity Lifecycle Management)
How does a cloud-native, self-service approach fit together with the control requirements your organization has?
Are there distinctions between identities (normal users versus admin users)? If yes, these distinctions must be laid out in the Identity and Access Management Concept. (See Privileged Access Management )
Specific Questions on IAM for Workload
An Identity and Access Management Concept needs to answer the following questions:
What documentation around access rights needs to happen? Documentation of access rights is a common requirement for companies in the finance or healthcare industries.
How does a cloud-native, self-service approach fit together with the control requirements your organization has? (See Service Account Management )
What guidelines do you have for teams migrating to the cloud? What guidelines should teams starting in the cloud follow (e.g. zero trust)?
How to Set up Resource Hierarchy for Access Management
The public cloud providers have resource hierarchies that allow inheriting permissions. Carefully crafting permission inheritance is a proven way of staying in control of access rights.
The design of your resource hierarchies must be taken into account for the Identity and Access Management Concept.
Azure
For Azure, the recommendation is to map applications that want to use the cloud to subscriptions. See
https://www.meshcloud.io/modeling-your-organizational-hierarchy-on-azure/
GCP
For GCP, the recommendation is to map applications that want to use the cloud to projects. See https://www.meshcloud.io/best-practices-organizational-structure-in-the-cloud/
AWS
For AWS, the recommendation is to map applications that want to use the cloud to accounts. See https://www.meshcloud.io/best-practices-organizational-structure-in-the-cloud/
Related Tools
Currently no tool implementations documented. Contributions welcome!
