User authentication and authorization
At the core of IAM is delivering a life- cycle process for the authentication and authorization of identities. In the past, the focus may have been on identities specifically tied to a human user. However, as companies rely more on automations, API integrations, device-to-device integrations, and other dynamic digital services, attention should be given to proper authentication and authorization of non-human identities as well. These non-human identities include things such as devices, service accounts, and workload identities, which should be considered as part of the audit, and in Chapter 1, Cloud Architecture and Navigation, we discussed the importance of understanding the end-to-end ITinfrastructure and landscape prior to starting an audit, which should include these items.
In the case of user authentication and authorization, it’s important to understand the source of identities and where those are managed. Cloud providers offer the ability to consume, share, and/or sync identity information within hybrid environments, across cloud providers, and with separate cloud-based identity stores. Additional functionality that may be configured is the ability for third-party managed identities to access your enterprise’s cloud resources, such as in the case of business-to -consumer (known as B2C), business-to-business (known as B2B), or with the use of social sign-ins. These types of externalidentity integrations and configurations are typically separate from the configuration options for enterprise identities. Other scenarios may include cross-account identities, where the identity is part of the organization but may reside within a cloud environment linked to a separate account (AWS), separate tenant (Azure), or separate project (GCP). With this in mind, it’s important to understand all identity use cases, integration points, and where the identity life cycle should begin and end for all identity types. This will help with verifying thesource of truth for identities and assessing all the necessary components where configuration should allow, or, in some cases, preventing identities from being managed directly or accessing resources. This will also aid in determining which controls are in scope for review.
Another important item to understand is the default approach that each of the cloud providers takes to authentication and authorization. For example, in a newly created Microsoft Azure environment, the security default behavior will be to enforce MFA and user registration to MFA within 14 days, and with GCP, service accounts have permission to call Google Cloud APIs. To learn more about default authentication and authorization settings, check out the following links:
