IAM in Shared Responsibility

Identity and access management is one of the clearest customer-owned control domains in cloud systems. Providers may operate the identity platform, but the customer still decides account boundaries, authentication policy, administrative access, privilege design, service identities, and lifecycle governance. That is why IAM is often the fastest way to expose whether a team truly understands shared responsibility.

The four lessons in this chapter move from the administrative boundary outward. They start with accounts, tenants, and administrative separation, then cover authentication and MFA, role and permission design, and finally workload and service identity. Read together, they show how IAM ownership sits at the center of nearly every other control family, from data access and incident response to compliance evidence and lateral movement risk.

Pay Attention To

• which IAM controls the provider operates versus which policies the customer must define and review
• how human access and workload access fail in different ways but require the same ownership discipline
• why least privilege is an operating program, not a one-time design setting

Use this chapter when shared responsibility feels abstract. IAM usually makes the customer side of the boundary impossible to ignore.

In this section

• Cloud Accounts, Tenants, and Administrative Boundaries
  Cloud accounts, tenants, and administrative boundaries are one of the earliest IAM choices a customer makes, and they shape everything that follows.
• Authentication, MFA, and Sign-In Controls
  Authentication, MFA, and sign-in controls are another area where the provider supplies the mechanism but the customer owns the policy.
• Roles, Permissions, and Least Privilege
  Roles, permissions, and least privilege are where IAM architecture becomes concrete.
• Service Identity and Workload Authentication
  Service identity and workload authentication show that IAM is not only about human users.