Audit access in an AWS account with k9

Auditing access to data in AWS and gathering evidence that you comply with logical access controls required by standards is a complex operation. It’s common for organizations to spend months building scripts to gather the information they need only to find it doesn’t make any sense and they’ve created a maintenance burden.

Review Principals’ Access

The k9 resource access inventory shows who has access to what data in AWS, and what kind of access they have, in terms everyone can understand. k9 analyzes each AWS IAM user and role (IAM principal) in your AWS account and reports what access capability each principal has to supported services and resources.

Each principal access summary contains:

• Principal name
• Principal unique identifier (ARN)
• Principal Type
• AWS Service Name
• Principal’s Access Capability to that service or resource

Audit principals’ access by executing k9 Security Kata 4. For example, the AccountAdminAccessRole-Sandbox in the sample access inventory report (xslx) (also available in JSON) has pervasive access to many AWS services and resources:

Figure 1. Principal Access Summary for a Privileged role

The excerpt in figure 1 shows that the AccountAdminAccessRole-Sandbox IAM role has full access to the CloudTrail, IAM, and KMS services. That role has the capability to administer-resource, read-config, read-data, write-data, and delete-data in each of those services.

At the bottom of Figure 1, you can also see that the role has those same capabilities for a KMS encryption key whose ARN ends in 9738. k9 tells you who has access to particular resources such as KMS encryption keys and S3 buckets. The AWS security policy language is very flexible and has the ability to create both coarse-grained and fine-grained access policies. Determining if a particular IAM principal has access to a particular resource is impractical to do by hand.

Here’s another excerpt showing AccountAdminAccessRole-Sandbox has full access to the AWS S3 API and a couple buckets:

Figure 2. Admin with privileged access to data in S3

When a principal has few access capabilities to an API or resource, that is reflected accordingly. Here is an excerpt of the k9-auditor‘s access to S3:

Figure 3. Audit-level access to read configurations in S3

The k9-auditor role used to analyze AWS accounts has the capability to read configurations (read-config) about S3 buckets, and nothing more.

Review principal access summaries periodically to verify each IAM user or role has the expected, and least amount of privileges to perform the business function.

Supports standard controls:

• SOC 2 / Trust Services Criteria: CC6.1
• ISO27001: 9.2.3, 9.2.5, 9.4.1
• PCI DSS: 2.4, 7.1, 7.2, 8.1, 8.7, 10.2.3
• HIPAA: 164.308, 164.312, 164.314

Identify and review privileged IAM users and roles

Periodic review of privileged users is a core security control in every standard.  Identify the privileged IAM users and roles in an AWS account by filtering the principal access summaries for the administer-resource capability. These IAM principals have the ability to administer AWS services and resources.

The highest privilege of all is the ability to administer the Identity and Access Management service, IAM.  IAM administrators can change anything because they can give themselves any access they want.

Because knowing who can administer IAM is so important, the Principals Summary answers this question directly by enabling you to filter by ‘Principal is Admin’.

Here is the list of IAM Administrators for the k9-dev AWS account:

Figure 4. IAM Administrators ready for review

Review the list of IAM administrators periodically to verify only authorized principals have administrative privileges by executing k9 Security Kata 1.

Supports standard controls:

• SOC 2 / Trust Services Criteria: CC6.2, CC6.3
• ISO27001: 9.2.3, 9.2.5
• PCI DSS: 8.1, 10.2.5
• HIPAA: 164.308, 164.312, 164.314

Identify unused IAM users and roles

Identify the unused IAM users and roles by reviewing when each IAM principal was last used:

Figure 5. Identify unused principals

k9 gathers the information about when each principal logged into the console with a password or accessed the account using an API key or assuming a role. k9 reports the most recent value for each of those access methods so you can easily determine if and when the IAM principal was used last. Blank values mean AWS has no recorded use.

Review this list to identify unused principals that are candidates for decommissioning according to your activity policies by executing k9 Security Kata 2.

Supports standard controls:

• SOC 2 / Trust Services Criteria: CC6.2
• ISO27001: 9.2.5
• PCI DSS: 8.1.4
• HIPAA: 164.308

Now let’s review access to critical data and encryption resources.

Review access to critical data stores and encryption keys

Review who has access to critical data stores and encryption keys using k9’s resource access summaries. This view lets you focus directly on your most critical information assets and spot problems quickly.

Let’s illustrate resource access summaries with an example. Within the k9 development environment, the most important S3 bucket is the qm-dev-k9-reports, which is an internal report storage bucket for k9 dev. Who has access to data in this bucket?

The qm-dev-k9-reports‘s resource access summary shows varying levels of access for five IAM principals:

Figure 6. Audit access to S3 bucket resources

The ci, skuenzli, k9-auditor, k9-backend-dev, and k9-report-publisher-dev IAM principals each have access according to the principals’ responsibilities in the dev environment.

Notably, no other principals have access to the bucket. Even IAM principals with full access to AWS services such as the AccountAdminAccessRole-Sandbox IAM role discussed in the Principal Access Summary do not have access to the bucket. This is because that access has been denied via S3 Bucket resource policy (details).

Review access to your critical data stores by filtering the resource access summaries by resource name or ARN as described in k9 Security Kata 4. The k9 continuous security policy engineering process can help your team implement and maintain least privilege access to data and encryption keys

Encryption keys are a critical cloud resource type and standards give keys special attention.  k9 helps you review who and what kind of access each principal has to your AWS KMS encryption key resources. Here’s an excerpt of the access summary for a test encryption key in the k9 dev environment:

Figure 7. Audit access to KMS encryption key resources

Figure 7 shows the ci user has full access to administer the key. The ci and k9-backend-devprincipals have the ability to call KMS APIs that read and write data with this key by, e.g. decrypting or encrypting. The k9-auditor role only has the capability to read the key’s configuration.

Review access to encryption keys by focusing on who has the capability to administer-resource, read-data, or write-data with that key. The k9 guide to securing data in AWS with KMS can help your team partition and control access to data using KMS encryption keys effectively.

Supports standard controls:

• SOC 2 / Trust Services Criteria: CC6.1, CC6.3
• ISO27001: 8.1.1, 8.1.2, 8.2.1, 9.4.1, 10.1.2
• PCI DSS: 3.5.2, 7.1, 7.2, 8.2
• HIPAA: 164.308, 164.312, 164.314

Summary

This guide showed how you can audit access to critical data and services in AWS and report your compliance with standard security controls with comprehensive, understandable evidence.

k9 helps you secure, audit, and demonstrate compliance quickly and easily.  It’s easy to get up and running with k9, so these access reports are only a few hours away.  These access inventory reports are also delivered in JSON for import into your SIEM and other security event and audit analysis systems. Contact us with questions or a demo today.