Overview of Access Control in AWS

If you are using AWS to host your applications, you need to understand how access control works in this cloud platform. Access control is the process of granting or denying permissions to users, groups, roles, and resources.?

In this article, we will explore the different types of access control in AWS, how they interact with each other, and how to use them effectively.

Main types of access control?

1. Identity and Access Management (IAM)?

This is the service that allows you to create and manage users, groups, roles, and policies. IAM policies define the actions and resources that a user, group, or role can access. You can directly attach IAM policies to users, groups, roles, or resources. You can also use IAM to federate identities from external sources, such as Active Directory or SAML providers.

2. Resource-based policies?

These are policies that are attached to specific AWS resources, such as S3 buckets, SQS queues, or Lambda functions. Resource-based policies specify who can access the resource and under what conditions. Resource-based policies can also delegate access to other AWS accounts or cross-account roles.

3. Service Control Policies (SCPs)?

These are policies that are applied to AWS Organizations, which are collections of AWS accounts that share billing and management. SCPs define the maximum permissions that the accounts in an organization can have. SCPs can restrict access to certain services, regions, or actions across all accounts in an organization.

4. Bucket policies?

These are policies that are applied to S3 buckets, which are storage containers for objects. Bucket policies control who can access the bucket and its objects, and under what conditions. Bucket policies can also delegate access to other AWS accounts or cross-account roles.

5. Key policies

These are policies that are applied to KMS keys, which are encryption keys that are used to protect data in AWS. Key policies control who can use the key to encrypt and decrypt data, and under what conditions. Key policies can also delegate access to other AWS accounts or cross-account roles.

As you can see, there are many types of access control in AWS, and they can work together or independently depending on your needs.

The following diagram shows how these types of access control interact with each other:

Best practices

To use access control effectively in AWS, you need to follow some best practices:

1. Use the principle of least privilege:?

This means granting only the minimum permissions required for a user, group, role, or resource to perform its function. This reduces the risk of unauthorized access or misuse of resources. You have a team of developers who need to deploy applications to EC2 instances.

Instead of granting them full permissions to all EC2 instances in your account, you can create an IAM role that grants them only the permissions they need to start, stop, and terminate EC2 instances in a specific development environment.

So instead of:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "arn:aws:ec2:region:account-id:instance/development-environment-*"
        }
    ]
}        

Use:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:TerminateInstances"
            ],
            "Resource": "arn:aws:ec2:region:account-id:instance/development-environment-*"
        }
    ]
}        

2. Use IAM roles for cross-account access:?

This means using IAM roles instead of sharing credentials or keys when you need to grant access to resources in another AWS account. This improves the security and auditability of cross-account access. You need to grant access to a user in another AWS account to resources in your account.

Instead of sharing your AWS account credentials with them, you can create an IAM role in your account that grants them the permissions they need. You can then share the ARN of the IAM role with the user in the other account.

Insert an IAM role assume policy:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::account-id:role/Test*" -> IAM role from another account
  }
}        

3. Use SCPs to enforce organizational boundaries:?

This means using SCPs to limit the permissions that the accounts in your organization can have. This prevents accidental or malicious actions that could affect your entire organization.

Let's say you have an organization with multiple AWS accounts and you want to prevent the accounts from accidentally or maliciously deleting S3 buckets. You can create an SCP that denies the s3:DeleteBucket permission to all accounts in your organization, except if the requester is an administrator.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "s3:DeleteBucket",
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:Requester": "arn:aws:iam::123456789012:role/AdminRole"
                }
            }
        }
    ]
}        

4. Use bucket policies for fine-grained control over S3 access?

This means using bucket policies to grant or deny access to specific S3 buckets or objects based on conditions such as IP address, time of day, HTTPS status, or source account. This enhances data protection and privacy.

You have an S3 bucket that contains sensitive data. You want to allow only users in a specific IAM group to read and write objects to the bucket. You can create a bucket policy that grants read and write access to the bucket to the IAM group. You can also add conditions to the bucket policy to restrict access based on IP address, time of day, HTTPS status, or source account.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowReadAccess",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::YourBucketName/*",
            "Condition": {
                "StringEquals": {
                    "aws:Requester", "arn:aws:iam::YourAWSAccountID:group/YourIAMGroupName"
                },
                "IpAddress": {
                    "aws:SourceIp": "192.168.1.0/24"
                }
            }
        }
    ]
}        

5. Use key policies for encryption key management?

This means using key policies to control who can use your KMS keys to encrypt and decrypt data. This ensures data confidentiality and integrity. You have a KMS key that you use to encrypt data. You want to allow only users in a specific IAM group to use the key to encrypt and decrypt data. You can create a key policy that grants the IAM group the kms:Encrypt and kms:Decrypt permissions.

{
  "Version": "2012-10-17",
  "Id": "LeastPrivilegeKeyPolicy",
  "Statement": [
    {
      "Sid": "RestrictedAccess",
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt”,
        "kms:Decrypt”
      ],
      "Resource": "*",
      "Principal": {
        "AWS": "*"
      },
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::12345678910:group/group1",
            "arn:aws:iam::12345678910:group/group2"
          ]
        }
      }
    }
}        

Access control is a vital aspect of AWS security and governance. By understanding the different types of access control in AWS and how they work together, you can design and implement a robust and flexible access control strategy for your cloud applications.