Identity and Access Management in Your AWS Landing Zone

Identity and Access Management (IAM) is the foundation of security in your AWS Landing Zone. Properly configured IAM ensures users have the right access to the right resources at the right time, while preventing unauthorized access and supporting compliance requirements.

The IAM Challenge in Multi-Account Environments

Without proper planning, IAM in a multi-account Landing Zone becomes unwieldy:

Users need separate credentials for each account
Permissions are inconsistent across accounts
Onboarding and offboarding are manual processes
Audit trails are fragmented
Compliance becomes difficult to demonstrate

AWS IAM Identity Center (formerly AWS SSO) solves these challenges by providing centralised identity and access management across all your accounts.

IAM Identity Center: The Foundation

IAM Identity Center is the recommended approach for managing human user access in your Landing Zone.

Key Benefits

Single Sign-On: Users authenticate once and access multiple accounts
Centralised Management: Define users, groups, and permissions in one place
Temporary Credentials: Automatic rotation, no long-lived access keys
Integration: Connects with existing identity providers
Audit Trail: Centralised logging of access across all accounts

Architecture

Identity Source (Azure AD, Okta, or IAM Identity Center directory)
    ↓
IAM Identity Center (in Management Account)
    ↓
Permission Sets (collections of IAM policies)
    ↓
Account Assignments (which groups get which permissions in which accounts)

Setting Up IAM Identity Center

Step 1: Choose Your Identity Source

Built-in Directory: Simple, for small organisations

Manage users directly in IAM Identity Center
Good for startups or AWS-only organisations

Active Directory: Common for established enterprises

AWS Managed Microsoft AD
AD Connector to on-premises AD
Leverage existing identity infrastructure

External Identity Provider: Modern, flexible approach

Azure AD
Okta
Google Workspace
Any SAML 2.0 provider

For Australian businesses: If you have existing identity infrastructure, integrate with it. Otherwise, start with the built-in directory.

Step 2: Define Permission Sets

Permission sets are collections of IAM policies that define what users can do in AWS accounts.

Standard Permission Sets:

Administrator: Full access

{
  "ManagedPolicies": ["arn:aws:iam::aws:policy/AdministratorAccess"],
  "SessionDuration": "PT4H"
}

Power User: Everything except IAM

{
  "ManagedPolicies": ["arn:aws:iam::aws:policy/PowerUserAccess"],
  "SessionDuration": "PT8H"
}

Read Only: View-only access

{
  "ManagedPolicies": ["arn:aws:iam::aws:policy/ReadOnlyAccess"],
  "SessionDuration": "PT8H"
}

Custom Permission Sets for specific roles:

Developer:

EC2, Lambda, API Gateway full access
RDS, DynamoDB read access
CloudWatch Logs read access
S3 access to specific buckets
No IAM or billing access

Data Analyst:

Athena, Glue, QuickSight access
S3 read access to data lake
RDS read-only access
No compute provisioning

Security Auditor:

Security Hub, GuardDuty, Config read access
CloudTrail read access
Read-only access to security-related services
No modification permissions

Step 3: Create Groups

Organise users into groups aligned with your organisation:

By Role:

Administrators
Developers
Data Engineers
Security Team
Finance Team

By Environment:

Production Access
Non-Production Access
Sandbox Access

By Application:

Application A Team
Application B Team

Step 4: Assign Permissions

Link groups to permission sets in specific accounts:

Administrators Group
  → Administrator Permission Set
    → All Accounts

Developers Group
  → Power User Permission Set
    → Development Accounts
  → Read Only Permission Set
    → Production Accounts

Security Team
  → Security Auditor Permission Set
    → All Accounts
  → Administrator Permission Set
    → Security Account

Best Practices for Permission Sets

Principle of Least Privilege

Grant only the minimum permissions needed:

Start with no access
Add permissions as needed
Regularly review and remove unused permissions
Use read-only access when modification isn’t required

Use Managed Policies Where Possible

AWS provides hundreds of managed policies:

Regularly updated by AWS
Well-tested and documented
Cover common use cases

Only create custom policies when managed policies don’t meet your needs.

Implement Session Duration Limits

Shorter sessions are more secure:

1-4 hours: Administrative access
8-12 hours: Standard user access
Read-only: Longer durations acceptable

Users can extend sessions if needed, providing a balance between security and convenience.

Enable MFA

Require multi-factor authentication for:

All users accessing production accounts
Any administrative access
Access to sensitive data

Configure MFA in your identity provider or IAM Identity Center.

Cross-Account Access Patterns

Beyond human users, resources in one account often need to access resources in another.

IAM Roles for Cross-Account Access

The preferred method for cross-account resource access.

Example: Application in Production Account accessing Data in Shared Services Account

In Shared Services Account, create a role:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::PRODUCTION_ACCOUNT_ID:root"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "unique-external-id"
      }
    }
  }]
}

In Production Account, grant permissions to assume the role:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/DataAccessRole"
  }]
}

Service Control Policies (SCPs)

SCPs define the maximum permissions for accounts in your organisation.

Use SCPs to:

Enforce guardrails across all accounts
Prevent actions even for administrators
Ensure compliance requirements

Example SCPs:

Prevent leaving the organization:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": [
      "organisations:LeaveOrganization"
    ],
    "Resource": "*"
  }]
}

Restrict to specific regions (data sovereignty):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": [
          "ap-southeast-2",
          "ap-southeast-4"
        ]
      }
    }
  }]
}

Prevent disabling security services:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "guardduty:DeleteDetector",
      "config:DeleteConfigRule",
      "config:StopConfigurationRecorder"
    ],
    "Resource": "*"
  }]
}

Emergency Access

Despite best practices, you may need emergency access mechanisms.

Break-Glass Accounts

Create emergency access IAM users:

Store credentials in a secure vault (Bitwarden, 1Password, etc)
Require multiple team members to access
Configure alerts when used
Regular rotation of credentials
Use only in genuine emergencies

Root Account Protection

The root account in each AWS account has unlimited access.

Secure the root account:

Use a strong, unique password
Enable MFA (hardware token preferred)
Never use for day-to-day operations
Store credentials in secure, offline storage
Regularly verify access still works (quarterly)
Monitor root account usage with CloudTrail alarms

Monitoring and Compliance

Access Logging

Enable comprehensive logging:

CloudTrail: All API calls including assume role
IAM Identity Center audit logs: User authentication and authorization
Access Advisor: Identify unused permissions

Alerts and Notifications

Configure alerts for suspicious activity:

Root account usage
Console login failures
Changes to IAM policies
Assume role from unusual IP addresses
Access from unexpected regions

Regular Reviews

Establish processes for:

Quarterly access reviews: Verify users still need their permissions
Inactive user cleanup: Disable users who haven’t logged in recently
Permission set audits: Remove unused permissions
Group membership reviews: Ensure users are in appropriate groups

Common IAM Mistakes

Using root account credentials: Lock them away
Long-lived access keys: Use temporary credentials via IAM Identity Center
Overly permissive policies: Start restrictive, add as needed
Sharing credentials: Every person gets their own identity
Not enabling MFA: Required for production access
Inconsistent permissions across accounts: Use Permission Sets
No regular reviews: Permissions accumulate over time
Missing CloudTrail: Essential for audit and security

Implementation Roadmap

Week 1: Foundation

Enable IAM Identity Center
Configure identity source
Create initial permission sets
Set up groups

Week 2: User Migration

Create user accounts
Assign to groups
Provide onboarding documentation
Disable old IAM user credentials

Implement SCPs
Configure MFA requirements
Set up monitoring and alerts
Document processes

Week 4: Optimisation

Review permissions
Implement break-glass procedures
Conduct access review
Train teams on new processes

Compliance Considerations

For Australian regulated industries:

Industry regulations:

Clearly defined access controls
Regular access reviews
MFA for privileged access
Audit logging

Privacy Act:

Access controls for personal information
Audit trail of who accessed what
Ability to revoke access quickly

ISM (Information Security Manual):

Principle of least privilege
Regular credential rotation
MFA for all users
Monitoring of privileged access

Conclusion

Identity and Access Management is critical to your Landing Zone security. IAM Identity Center provides centralised, secure, and scalable access management across all your AWS accounts.

By implementing proper IAM architecture from the start, you establish a foundation for secure operations, simplified compliance, and efficient user management that scales with your organisation.

CloudPoint specialises in implementing IAM strategies for Australian businesses, ensuring security, compliance, and operational efficiency. Contact us to review your IAM architecture or implement IAM Identity Center in your Landing Zone.

Need Help with IAM in Your Landing Zone?

CloudPoint implements identity and access management as part of secure AWS landing zones. Get in touch to discuss your requirements.

Learn more about our Landing Zone service →