Skip to main content

🛡️ AWS Account Root User has active access keys🟢

Logic​

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-0a7801fb1

Description​

Open File

Description​

The root user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the root user account be deleted.

Rationale​

Deleting access keys associated with the root user account limits vectors by which the account can be compromised. Additionally, deleting the root access keys encourages the creation and use of role based accounts that are least privileged.

Audit​

Perform the following to determine if the root user account has access keys:

From Console​
  1. Login to the AWS Management Console.
  2. Click Services.
  3. Click IAM.
  4. Click on Credential Report.
  5. This will download a .csv file which contains credential usage for all IAM users within an AWS Account - open this file.
  6. For the <root_account> user, ensure the access_key_1_active and access_key_2_active fields are set to FALSE.
From Command Line​

Run the following command:

aws iam get-account-summary | grep "AccountAccessKeysPresent"

... [see more](description.md)

Remediation​

Open File

Remediation​

Perform the following to delete active root user access keys.

From Console​

  1. Sign in to the AWS Management Console as root and open the IAM console at https://console.aws.amazon.com/iam/.
  2. Click on <root_account> at the top right and select My Security Credentials from the drop down list.
  3. On the pop out screen Click on Continue to Security Credentials.
  4. Click on Access Keys (Access Key ID and Secret Access Key).
  5. If there are active keys, under Status, click Delete (Note: Deleted keys cannot be recovered).

Note: While a key can be made inactive, this inactive key will still show up in the CLI command from the audit procedure, and may lead to a key being falsely flagged as being non-compliant.

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 APRA CPG 234 → 💼 47c segregation of duty controls which prevent personnel from deploying their own software changes to production;55no data
💼 APRA CPG 234 → 💼 c. prohibiting sharing of accounts and passwords (with the possible exception of generic accounts, where prohibiting sharing of accounts and passwords is unavoidable due to technology constraints);11no data
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [IAM.4] IAM root user access key should not exist11no data
💼 CIS AWS v1.2.0 → 💼 1.12 Ensure no root account access key exists11no data
💼 CIS AWS v1.3.0 → 💼 1.4 Ensure no root user account access key exists11no data
💼 CIS AWS v1.4.0 → 💼 1.4 Ensure no 'root' user account access key exists11no data
💼 CIS AWS v1.5.0 → 💼 1.4 Ensure no 'root' user account access key exists - Level 1 (Automated)11no data
💼 CIS AWS v2.0.0 → 💼 1.4 Ensure no 'root' user account access key exists - Level 1 (Automated)11no data
💼 CIS AWS v3.0.0 → 💼 1.4 Ensure no 'root' user account access key exists - Level 1 (Automated)11no data
💼 CIS AWS v4.0.0 → 💼 1.4 Ensure no 'root' user account access key exists (Automated)1no data
💼 CIS AWS v4.0.1 → 💼 1.4 Ensure no 'root' user account access key exists (Automated)1no data
💼 CIS AWS v5.0.0 → 💼 1.3 Ensure no 'root' user account access key exists (Automated)1no data
💼 CIS AWS v6.0.0 → 💼 2.3 Ensure no 'root' user account access key exists (Automated)1no data
💼 Cloudaware Framework → 💼 Credential Lifecycle Management18no data
💼 FedRAMP High Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)16no data
💼 FedRAMP High Security Controls → 💼 AC-2(9) Restrictions on Use of Shared and Group Accounts (M)(H)22no data
💼 FedRAMP High Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)3767no data
💼 FedRAMP High Security Controls → 💼 AC-6 Least Privilege (M)(H)81156no data
💼 FedRAMP High Security Controls → 💼 AC-6(2) Non-privileged Access for Nonsecurity Functions (M)(H)14no data
💼 FedRAMP High Security Controls → 💼 AC-6(5) Privileged Accounts (M)(H)35no data
💼 FedRAMP High Security Controls → 💼 AC-6(10) Prohibit Non-privileged Users from Executing Privileged Functions (M)(H)13no data
💼 FedRAMP Low Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)67no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)16no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2(9) Restrictions on Use of Shared and Group Accounts (M)(H)2no data
💼 FedRAMP Moderate Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)67no data
💼 FedRAMP Moderate Security Controls → 💼 AC-6 Least Privilege (M)(H)656no data
💼 FedRAMP Moderate Security Controls → 💼 AC-6(2) Non-privileged Access for Nonsecurity Functions (M)(H)4no data
💼 FedRAMP Moderate Security Controls → 💼 AC-6(5) Privileged Accounts (M)(H)5no data
💼 FedRAMP Moderate Security Controls → 💼 AC-6(10) Prohibit Non-privileged Users from Executing Privileged Functions (M)(H)3no data
💼 GDPR → 💼 Art. 25 Data protection by design and by default1010no data
💼 GDPR → 💼 Art. 32 Security of processing55no data
💼 ISO/IEC 27001:2013 → 💼 A.9.1.2 Access to networks and network services1718no data
💼 ISO/IEC 27001:2022 → 💼 5.10 Acceptable use of information and other associated assets1126no data
💼 ISO/IEC 27001:2022 → 💼 5.15 Access control1430no data
💼 ISO/IEC 27001:2022 → 💼 8.2 Privileged access rights710no data
💼 ISO/IEC 27001:2022 → 💼 8.3 Information access restriction1023no data
💼 ISO/IEC 27001:2022 → 💼 8.4 Access to source code821no data
💼 NIST CSF v1.1 → 💼 PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties1752no data
💼 NIST CSF v1.1 → 💼 PR.DS-1: Data-at-rest is protected1528no data
💼 NIST CSF v1.1 → 💼 PR.DS-2: Data-in-transit is protected1631no data
💼 NIST CSF v1.1 → 💼 PR.DS-5: Protections against data leaks are implemented4766no data
💼 NIST CSF v1.1 → 💼 PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities2130no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties91no data
💼 NIST CSF v2.0 → 💼 PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected118no data
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected98no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected112no data
💼 NIST SP 800-53 Revision 4 → 💼 SC-12 CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT544no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-2(1) Account Management _ Automated System Account Management416no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-3(7) Access Enforcement _ Role-based Access Control14no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-3(15) Access Enforcement _ Discretionary and Mandatory Access Control11no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-6 Least Privilege102349no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-6(2) Least Privilege _ Non-privileged Access for Nonsecurity Functions44no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-6(5) Least Privilege _ Privileged Accounts33no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-6(10) Least Privilege _ Prohibit Non-privileged Users from Executing Privileged Functions2no data
💼 PCI DSS v3.2.1 → 💼 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.18no data
💼 PCI DSS v3.2.1 → 💼 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.5330no data
💼 PCI DSS v3.2.1 → 💼 7.2.1 Coverage of all system components.7no data
💼 PCI DSS v3.2.1 → 💼 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods.112no data
💼 PCI DSS v4.0.1 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.11no data
💼 PCI DSS v4.0.1 → 💼 2.2.2 Vendor default accounts are managed.8no data
💼 PCI DSS v4.0.1 → 💼 7.3.1 An access control system(s) is in place that restricts access based on a user's need to know and covers all system components.7no data
💼 PCI DSS v4.0.1 → 💼 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis.2no data
💼 PCI DSS v4.0 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.11no data
💼 PCI DSS v4.0 → 💼 2.2.2 Vendor default accounts are managed.8no data
💼 PCI DSS v4.0 → 💼 7.3.1 An access control system(s) is in place that restricts access based on a user's need to know and covers all system components.7no data
💼 PCI DSS v4.0 → 💼 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis.22no data