2. IAM in AWS-Azure-GCP

Identity and Access Management (IAM) is the backbone of cloud security. In modern cloud architectures, identity, not the network perimeter, is the primary boundary of trust. Because cloud resources are dynamically provisioned, globally distributed, and interact through APIs at all layers, IAM systems play a central role in defining who can do what, where, and when. This elevates authentication, authorization, privilege management, and continuous monitoring as core security responsibilities for any organization leveraging the cloud.

NIST SP 800-63, which provides authoritative guidance on digital identity and authentication requirements, forms a conceptual foundation for cloud IAM. Meanwhile, cloud providers implement their own IAM frameworks, AWS IAM, Azure Active Directory (now Microsoft Entra ID), and Google Cloud IAM, each with unique principles but a shared core philosophy: enforce least privilege, ensure secure authentication, and maintain auditable access governance. Together, these systems enable organizations to implement Zero Trust principles, meet regulatory compliance, and reduce the risk of cloud breaches.

This chapter examines IAM comprehensively across AWS, Azure, and GCP, emphasizing how misconfigurations, excessive permissions, and poor governance frequently lead to compromise. It integrates best practices, architectural guidance, and real-world risk perspectives from enterprise consulting environments.

Core IAM Concepts Across Cloud Providers

Regardless of provider, IAM systems address several universal components:

Principals (Identities)

Entities capable of making requests:

• Human users
• Service accounts
• Roles or temporary identities
• Federated identities (SSO, SAML, OIDC)

Authentication

Validation of identity using passwords, MFA, certificates, tokens, or delegated authentication.

Authorization

Determines allowable actions based on policies, roles, and conditions.

Policies and Access Rules

Each cloud platform describes permissions with a structured policy syntax.

Resource Scopes

Mapping allowed actions to specific resources.

Federation and Directory Integration

Connectivity to enterprise identity providers (IdPs) such as:

• Microsoft Entra ID
• Okta
• Ping Identity
• On-premises Active Directory

Logging and Monitoring

IAM logs are essential for auditing and threat detection.

Cloud IAM is deeply intertwined with secure API usage, a theme echoed in The Web Application Hacker’s Handbook, as attackers commonly exploit weak token handling, insufficient authorization logic, or misconfigured access boundaries.

IAM in Amazon Web Services (AWS)

AWS IAM is known for its fine-grained, policy-driven access model that emphasizes least privilege, temporary credentials, and role assumption. It operates at a global scope for identity objects, but permissions apply per-region based on resources.

Identity Types in AWS:

1. IAM Users – Human identities used sparingly in modern architectures. Ideally, replaced with federation.
2. IAM Groups – Collections of users for permissions aggregation.
3. IAM Roles – Temporary identities assumed by users or services. Roles are core to:
• EC2 instance profiles
• Lambda execution roles
• Cross-account access
• Temporary access via AWS STS
4. Service-linked Roles – Predefined roles for AWS services with built-in permissions.

AWS IAM Policies

AWS policies are JSON documents defining permissions. Core components:

• Actions: API operations (e.g., s3:ListBucket)
• Resources: ARNs defining what the policy applies to
• Effect: Allow or Deny
• Condition: Contextual restrictions (IP, MFA, time, VPC endpoint)

AWS evaluates explicit denies before allows, important when designing defense-in-depth.

AWS Access Control Best Practices

• Use Roles with Temporary Credentials

Avoid long-lived access keys. STS tokens reduce exposure.

• Enforce MFA for Privileged Actions

Aligns with NIST SP 800-63 authentication assurance levels.

• Apply Least Privilege with Permission Boundaries

Permission boundaries, SCPs (Service Control Policies), and session policies help prevent privilege escalation.

• Log All IAM Activity

Enable:

• CloudTrail logging
• IAM Access Analyzer
• GuardDuty for anomalous behavior
• Config rules for drift detection

• Enforce Strong Secrets Management

AWS Secrets Manager or Parameter Store should replace application-embedded secrets.

Common AWS IAM Misconfigurations (Real-World Patterns)

1. Wildcard Actions or Resources
   "Action": "*" or "Resource": "*" is a frequent root-cause of compromise.

2. Over-permissive S3 bucket policies
   Allows unintended public access.

3. IAM roles with assume-role permissions from any AWS account
   Used in cross-account takeover attacks.

4. Unrestricted Lambda execution roles
   Lambdas often end up with full S3 or DynamoDB control unnecessarily.

5. Hardcoded Access Keys
   A recurring source of breaches via code repositories.

IAM in Microsoft Azure (Entra ID + Azure RBAC)

Azure uses Entra ID (formerly Azure AD) as its identity provider. It is deeply integrated across Microsoft 365, SaaS platforms, and Azure resources, making Azure IAM heavily identity-centric compared to AWS’s resource-centric architecture.

Identity Types in Azure

1. Users: Human identities.
2. Groups: Security groups for role assignment.
3. Service Principals: Application or service identities.
4. Managed Identities: Automatically rotated credentials for Azure services.
5. Guest Access (B2B): External identity collaboration.

Azure RBAC (Role-Based Access Control)

Azure RBAC manages access to the Azure Resource Manager layer.

Key components:

• Role Definitions – Built-in or custom roles.
• Role Assignments – Bind identity + role + scope.
• Scopes:
• Management group
• Subscription
• Resource group
• Resource

Azure’s hierarchical scopes enable powerful inheritance models.

Privileged Identity Management (PIM)

PIM enables Just-In-Time (JIT) privilege elevation, reducing risk of standing privileges, a direct embodiment of Zero Trust.

Features include:

• Time-bound access
• MFA enforcement for elevation
• Approval workflows
• Audit logs

PIM is arguably one of Azure’s strongest security capabilities.

Conditional Access (Aligned with NIST SP 800-63)

A cornerstone of Azure identity security:

• Enforces MFA
• Blocks risky sign-ins
• Applies device compliance rules
• Supports geolocation restrictions
• Integrates with continuous risk scoring

Conditional Access represents modern identity-based perimeter enforcement.

Common Azure IAM Misconfigurations

1. Global Administrator role assigned too broadly
   Massive blast radius in SaaS and PaaS services.

2. Service principals with excessive Graph API permissions
   Leads to cloud-wide privilege escalation.

3. Disabled or misconfigured Conditional Access
   Allows MFA bypass.

4. Publicly exposed app registrations
   Enables token forgery attacks.

5. Failure to use managed identities
   Leads to secret leakage in CI/CD pipelines.

IAM in Google Cloud Platform (GCP IAM)

GCP’s IAM model is built on the principle of resource hierarchy enforcement, lightweight service accounts, and highly structured permissions.

GCP Resource Hierarchy

Structure:

1. Organization
2. Folders
3. Projects
4. Resources

IAM roles cascade downward in the hierarchy, similar to Azure’s scoping.

Identity Types in GCP

1. Google Accounts (users)
2. Service Accounts (core to GCP operations)
3. Groups
4. Workload Identity Federation
5. Cloud-managed identities

GCP frequently uses service accounts for automation, CI/CD, serverless, and Kubernetes workloads.

GCP IAM Roles

GCP offers three types:

• Primitive Roles (Owner, Editor, Viewer) – too broad, should be avoided
• Predefined Roles – granular permissions for each service
• Custom Roles – least privilege tailored to specific workloads

GCP’s predefined roles are more fine-grained than AWS or Azure equivalents.

Service Account Security

GCP’s service account architecture is powerful but commonly misused. Best practices include:

• Avoid assigning Editor to default service accounts
• Rotate service account keys (or better: avoid keys entirely)
• Restrict service account impersonation
• Use Workload Identity Federation for external systems (avoids secrets)

Common GCP IAM Misconfigurations

1. Service accounts with excessive permissions
   Especially when assigned primitive roles.
2. Hardcoded service account keys
   A major breach vector.
3. Improper IAM role inheritance across folders/projects
   Leads to privilege accumulation.
4. Over-permissive Cloud Storage ACLs
   Similar to S3 bucket exposure cases.

Cross-Cloud IAM Threats and Attack Techniques

For educational purposes, here are conceptual, not operational, threat models:

• Credential Leakage

Via code repositories, logs, configuration files, or CI/CD pipelines.

• Misconfigured Federation

Poorly secured trust relationships allow unauthorized SSO access.

• Privilege Escalation via Over-permissive Roles

Attackers exploit broad roles to escalate privileges in cloud accounts.

• Token Replay or Theft

If access tokens lack proper lifecycle management.

• Lateral Movement Across Services

Attackers pivot across workloads using overly trusted service accounts.

These risks reinforce the need for strong IAM governance.

Best Practices for IAM Across AWS, Azure, and GCP

Implement Zero Trust Identity Controls

• MFA enforced everywhere
• Continuous access evaluation
• Least privilege role design
• Privilege expiration, not elevation persistence

Use Identity Federation (Do Not Use Local Cloud Users)

• Integrate with enterprise IdPs
• Centralize lifecycle management
• Improve compliance and auditability

Enforce Conditional Access Policies

Aligned with NIST SP 800-63 for authentication assurance.

Use Managed Identities and Avoid Secrets

Secrets should never be hardcoded or stored in repositories.

Audit Identity Activity Continuously

Checklist:

• CloudTrail / Monitor / Cloud Audit Logs
• Alert on privilege changes
• Least privilege reviews every quarter
• Automated IAM policy linting

Separate Duties and Enforce Segregation

• Distinct admin roles for IAM, network, security, and billing
• Scoped permissions to minimize blast radius

Align IAM with DevSecOps

• IAM as code (policy-as-code)
• Automated test coverage for permission drift

Identity is the new perimeter in cloud computing, and AWS, Azure, and GCP implement powerful, but different, IAM frameworks to enforce secure access, policy-based governance, and zero-trust principles. Misconfigurations, not platform flaws, remain the dominant cause of cloud compromises. By understanding identity types, policy models, least-privilege strategies, and provider-specific risk patterns, cybersecurity professionals can design and maintain strong, scalable access controls across any multi-cloud environment.

NIST SP 800-63 provides essential guidance on identity assurance, authentication strength, and policy enforcement, while cloud providers extend these principles into practical IAM architectures. As organizations embrace hybrid and cloud-native ecosystems, mastery of cross-cloud IAM becomes a core skill for any cybersecurity professional.