CWL's Christmas & New Year Deals: Up to 90% OFF!

Securing Cross-Account Access in AWS Organizations: Monitoring and Governance

With the growth of organisations, managing multiple AWS accounts becomes crucial for simplifying operations, separating workloads and providing control over access. AWS Organizations offers a central management platform for these accounts, which includes consolidated billing, policy management, and cross-account access controls. However, when cross-account access opens the door to potential risks, effective monitoring and governance  become necessary.

 

In this blog, we explore ways to monitor and manage cross-account access in an AWS Organization, deploy alerts for unusual activity, and ensure compliance with security best practices.

Prerequisites

To follow along, you should have:

  1. Basic understanding of AWS IAM, AWS CloudTrail, and AWS Config.
  2. An AWS Organization with multiple accounts configured.
  3. Administrator access in the AWS Organization management account.

Understanding Cross-Account Access in AWS Organizations

Cross-account access permits users and applications in one AWS account to access resources within another AWS account. This configuration is particularly useful for centralized logging, resource sharing, and task management. However, if not configured properly, cross-account access can lead to data leakage, privilege escalation, and other security risks.

Within AWS Organizations, cross-account access is often granted through:

  • IAM Roles: Using trust policies to allow access from one account to another.
  • Resource-Based Policies: Granting permissions on specific resources to principals in other accounts.
  • Service Control Policies (SCPs): Setting guardrails to limit actions across all accounts in an Organization Unit (OU).

 

Setting Up Cross-Account Access: A Practical Example

Let’s walk through an example scenario where an Operations account needs to access an S3 bucket in the Development account.

Step-1: Create an IAM Role in the Development Account:

Through Console

  • Go to the IAM service in the Development account.
  • Create a new role, select Another AWS Account, and enter the Operations account ID.
  • Attach an appropriate policy, e.g., AmazonS3ReadOnlyAccess, to restrict the role to read-only access on S3.
				
					{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::your-bucket-name"
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject"
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Through CLI

  • Create the Role: Run this command in the Development account to create a role that the Operations account can assume.
				
					aws iam create-role --role-name CrossAccountS3AccessRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::OPERATIONS_ACCOUNT_ID:root"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }'
  • Attach a Policy for S3 Access: Attach an S3 read-only policy to this role, limiting access to the bucket in the Development account.
				
					aws iam put-role-policy --role-name CrossAccountS3AccessRole \
  --policy-name S3ReadOnlyPolicy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "s3:ListBucket"
        ],
        "Resource": "arn:aws:s3:::your-bucket-name"
      },
      {
        "Effect": "Allow",
        "Action": [
          "s3:GetObject"
        ],
        "Resource": "arn:aws:s3:::your-bucket-name/*"
      }
    ]
  }'

Step-2: Assume the Role from the Operations Account:

Through Console

  • From the Operations account, use the AWS CLI or SDK to assume the role in the Development account.
  • Ensure only authorised users in the Operations account can assume this role by adding conditions to your policy.

Through CLI

To access the S3 bucket, users in the Operations account can assume the role created in the Development account.

  • Assume the Role: Use the following command to assume the role from the Operations account. Replace ROLE_ARN and SESSION_NAME with appropriate values.
				
					aws sts assume-role --role-arn "arn:aws:iam::DEVELOPMENT_ACCOUNT_ID:role/CrossAccountS3AccessRole" \
  --role-session-name "CrossAccountSession"
  • Export Temporary Credentials: The command returns temporary security credentials, which can be exported to access the S3 bucket:
				
					export AWS_ACCESS_KEY_ID="TEMPORARY_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="TEMPORARY_SECRET_KEY"
export AWS_SESSION_TOKEN="TEMPORARY_SESSION_TOKEN"
  • Access the S3 Bucket: With the temporary credentials, run the following command to list objects in the S3 bucket:
				
					aws s3 ls s3://your-bucket-name

Step-3: Service Control Policies (SCPs):

  • Apply an SCP at the OU level to restrict access to only the Development account. This policy acts as an additional safeguard to control access even if IAM permissions are misconfigured.

 

Monitoring Cross-Account Access Using CloudTrail

AWS CloudTrail is essential for tracking all API activity across AWS accounts. You can use CloudTrail logs to monitor when roles are assumed, and by whom, providing visibility into cross-account access.

Steps to Set Up CloudTrail for Cross-Account Access Monitoring

Step-1: Enable CloudTrail in All Accounts:

  • Ensure CloudTrail is enabled in both the Operations and Development accounts. This setup will log all actions, including role assumptions and S3 access.

Through CLI

To set up centralized CloudTrail logging across all accounts in your AWS Organization:

  • Create a Trail in the Management Account: Run this command in the Management account to create an organization-wide CloudTrail:
				
					aws cloudtrail create-trail --name OrgTrail \
  --s3-bucket-name your-centralized-logging-bucket \
  --is-organization-trail
  • Start Logging: Enable the trail to begin logging:
				
					aws cloudtrail start-logging --name OrgTrail
  • Verify Logging Status: Check the status to ensure the trail is active:
				
					aws cloudtrail describe-trails --trail-name-list OrgTrail

Step-2: Create a Centralised Log Archive in the Management Account:

  • Create an S3 bucket in the Management account.
  • Set up CloudTrail to deliver logs from all accounts in the Organization to this central bucket.
  • Apply bucket policies to allow only designated roles or users to access these logs.

 

Step-3: Detect Role Assumptions and Cross-Account Access:

  • Look for AssumeRole events in CloudTrail logs, filtering by role names or specific user activity.
  • Example CloudTrail event filter to detect cross-account role assumptions:
				
					{
  "eventSource": "sts.amazonaws.com",
  "eventName": "AssumeRole",
  "recipientAccountId": "your-management-account-id"
}

Setting Up Alerts for Unusual Cross-Account Activity

To ensure quick responses to potentially suspicious cross-account activity, set up alerts based on CloudTrail logs using Amazon CloudWatch and AWS Lambda.

Create CloudWatch Alarms:

  • Use CloudWatch to set up alarms for specific events, such as unauthorized access attempts or unusual role assumptions.
  • For example, create an alarm for AssumeRole events occurring at odd hours, potentially indicating unauthorized access.

Use AWS Lambda for Automatic Responses:

  • Create a Lambda function to analyze CloudTrail logs in real-time. The function can trigger automated actions, like disabling a user or alerting the security team if an unusual cross-account access pattern is detected.

SNS for Notifications:

  • Integrate SNS with CloudWatch Alarms and Lambda to receive email or SMS notifications when suspicious cross-account activity occurs.

Enforcing Governance with AWS Config Rules

AWS Config provides a way to enforce and audit configuration compliance across AWS accounts. By setting rules, you can ensure that cross-account access adheres to security standards.

Enable AWS Config Across All Accounts:

  • Go to AWS Config in the Management account, enable it for all Organization accounts, and set up a centralized S3 bucket for logs.
  • Enable cross-account role access to AWS Config logs for real-time monitoring.

Through CLI

  • Enable AWS Config in Management Account: Configure AWS Config to track IAM roles and policies.
				
					aws configservice put-configuration-recorder --configuration-recorder-name default \
  --role-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/AWSConfigRole

Use Managed and Custom Config Rules:

  • Apply Config rules like iam-role-managed-policy-check or restricted-ssh, which flag insecure configurations or overly permissive cross-account access.
  • You can create custom rules to check specific conditions, such as flagging if cross-account S3 bucket policies allow unrestricted access.

Through CLI

  • Set Up Config Rules: Use managed rules or custom rules to enforce compliance on IAM roles. For example, the “iam-role-managed-policy-check” rule checks that roles are not overly permissive.



				
					aws configservice put-config-rule --config-rule-name iam-role-managed-policy-check \
  --source 'Owner=AWS,SourceIdentifier=IAM_ROLE_MANAGED_POLICY_CHECK'

Remediation Actions with Config:

  • Configure automatic remediation for non-compliant resources. For example, if an S3 bucket policy is overly permissive, automatically remove the cross-account access.

Periodic Cross-Account Access Audits

Perform regular audits to review cross-account access permissions across AWS accounts. This helps catch unused roles, misconfigured policies, or unapproved access setups.

List All Roles with Trust Policies:

  • Use AWS IAM Access Analyzer or run an IAM role policy evaluation script to identify roles that grant cross-account access.

Review IAM Policies and Permissions:

  • Regularly check IAM policies for any updates or modifications that could affect cross-account access.

Implement Least Privilege for Roles:

  • Enforce a least privilege policy, ensuring roles are granted only the permissions necessary for their specific tasks.

Learning Trivia

Cloud Security Path:

  • Beginner:

Multi-Cloud Red Team Analyst [MCRTA]

  • Intermediate:

Hybrid Multi-Cloud Red Team Specialist [CHMRTS]

  • Specialist:

Google Cloud Red Team Specialist [CGRTS]

AWS Cloud Red Team Specialist [CARTS]

Conclusion

While cross-account access in AWS Organization is incredibly strong, it can be extremely dangerous when not managed properly for security reasons. By impementing strong governance and monitoring policies, including using CloudTrail, AWS Config, and centralized logging, you can gain visibility and control over cross-account activity. Regular audits and automated alerts further strengthen your security posture, helping you detect and respond to suspicious activity in real time.

Following these best practices will ensure that cross-account access in your AWS organization remains secure, compliant, and well-managed.