Skip to main content

πŸ“ AWS Account Root User credentials were used is the last 30 days πŸ”΄πŸŸ’

  • Contextual name: πŸ“ Root User credentials were used is the last 30 days πŸ”΄πŸŸ’
  • ID: /ce/ca/aws/iam/root-account-used-recently
  • Located in: πŸ“ AWS IAM

Flags​

Our Metadata​

  • Policy Type: COMPLIANCE_POLICY
  • Policy Category:
    • SECURITY

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
βœ‰οΈ dec-x-e58fd8e01

Logic​

TODO πŸ”΄β€‹

Open File

TODO​

Needs additional checks for access_key_1_last_used_date, access_key_2_last_used_date

Description​

Open File

Description​

Verify that the AWS root account credentials have not been used to access your AWS account in the past 30 days. Root account credentials should not be used for day-to-day operations, including administrative tasks. Instead, assign appropriate permissions to individual IAM users or roles to limit dependency on the root account.

Rationale​

The AWS root account has unrestricted access to all resources in the AWS environment. Routine use of the root account increases the risk of accidental or intentional misuse, which could result in data breaches, resource compromise, or loss of account control. By ensuring root user credentials are only used for critical administrative tasks (e.g., billing or account setup), organizations can reduce security risks and adhere to best practices for least-privilege access.

Additionally, frequent root account usage can undermine auditing efforts and make it difficult to track accountability.

Impact​

May require additional administrative effort to configure and maintain IAM roles and secure workflows.

... see more

Remediation​

Open File

Remediation​

Ensure all root account usage is necessary, logged, and secured. For any non-critical tasks, use IAM roles or users.

Consider implementing these steps to effectively minimize the use of root account credentials and enhance the security of your AWS account.

From Command Line​

Enable MFA for the root account (if not already enabled)​

Create the virtual device entity in IAM to represent a virtual MFA device:

aws iam create-virtual-mfa-device \
--virtual-mfa-device-name {{mfa-device-name}} \
--outfile {{filepath}} \
--bootstrap-method {{bootstrap-method}}

Enable an MFA device for use with AWS:

aws iam enable-mfa-device \
--user-name root \
--serial-number {{mfa-device-arn}} \
--authentication-code1 123456 \
--authentication-code2 789012
Create and use IAM roles for administrative tasks​

Define and assign roles with specific permissions instead of relying on root user credentials:

aws iam create-role --role-name {{admin-role}} --assume-role-policy-document file://{{trust-policy}}.json
aws iam attach-role-policy --role-name {{admin-role}} --policy-arn {{arn:aws:iam::aws:policy/admin-access}}

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

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlags
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 16c information security operations and administration;22
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 67e users with privileged access accounts subject to a greater level of monitoring in light of the heightened risks involved.11
πŸ’Ό CIS AWS v1.2.0 β†’ πŸ’Ό 1.1 Avoid the use of the "root" account11
πŸ’Ό CIS AWS v1.3.0 β†’ πŸ’Ό 1.7 Eliminate use of the root user for administrative and daily tasks11
πŸ’Ό CIS AWS v1.4.0 β†’ πŸ’Ό 1.7 Eliminate use of the 'root' user for administrative and daily tasks11
πŸ’Ό CIS AWS v1.5.0 β†’ πŸ’Ό 1.7 Eliminate use of the 'root' user for administrative and daily tasks - Level 1 (Automated)11
πŸ’Ό CIS AWS v2.0.0 β†’ πŸ’Ό 1.7 Eliminate use of the 'root' user for administrative and daily tasks - Level 1 (Manual)11
πŸ’Ό CIS AWS v3.0.0 β†’ πŸ’Ό 1.7 Eliminate use of the 'root' user for administrative and daily tasks - Level 1 (Manual)11
πŸ’Ό CIS AWS v4.0.0 β†’ πŸ’Ό 1.7 Eliminate use of the 'root' user for administrative and daily tasks (Manual)1
πŸ’Ό CIS AWS v4.0.1 β†’ πŸ’Ό 1.7 Eliminate use of the 'root' user for administrative and daily tasks (Manual)1
πŸ’Ό CIS AWS v5.0.0 β†’ πŸ’Ό 1.6 Eliminate use of the 'root' user for administrative and daily tasks (Manual)1
πŸ’Ό Cloudaware Framework β†’ πŸ’Ό Credential Lifecycle Management17
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-2(7) Privileged User Accounts (M)(H)67
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-2(9) Restrictions on Use of Shared and Group Accounts (M)(H)22
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-6(1) Authorize Access to Security Functions (M)(H)44
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-6(2) Non-privileged Access for Nonsecurity Functions (M)(H)14
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-6(5) Privileged Accounts (M)(H)35
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό IA-5 Authenticator Management (L)(M)(H)61420
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό SI-4(20) Privileged Users (H)4648
πŸ’Ό FedRAMP Low Security Controls β†’ πŸ’Ό IA-5 Authenticator Management (L)(M)(H)120
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-2(7) Privileged User Accounts (M)(H)7
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-2(9) Restrictions on Use of Shared and Group Accounts (M)(H)2
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-6(1) Authorize Access to Security Functions (M)(H)4
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-6(2) Non-privileged Access for Nonsecurity Functions (M)(H)4
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-6(5) Privileged Accounts (M)(H)5
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό IA-5 Authenticator Management (L)(M)(H)420
πŸ’Ό GDPR β†’ πŸ’Ό Art. 30 Records of processing activities34
πŸ’Ό GDPR β†’ πŸ’Ό Art. 32 Security of processing55
πŸ’Ό ISO/IEC 27001:2013 β†’ πŸ’Ό A.9.2.2 User access provisioning44
πŸ’Ό ISO/IEC 27001:2013 β†’ πŸ’Ό A.9.3.1 Use of secret authentication information33
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 5.15 Access control1416
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 8.2 Privileged access rights77
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes1922
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties1735
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)1922
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.DS-5: Protections against data leaks are implemented4351
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization23
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.AA-03: Users, services, and hardware are authenticated22
πŸ’Ό 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 duties58
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected82
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected69
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected67
πŸ’Ό NIST SP 800-53 Revision 4 β†’ πŸ’Ό AC-5 SEPARATION OF DUTIES33
πŸ’Ό NIST SP 800-53 Revision 5 β†’ πŸ’Ό AC-2(7) Account Management _ Privileged User Accounts11
πŸ’Ό NIST SP 800-53 Revision 5 β†’ πŸ’Ό AC-6(2) Least Privilege _ Non-privileged Access for Nonsecurity Functions44
πŸ’Ό NIST SP 800-53 Revision 5 β†’ πŸ’Ό AC-6(5) Least Privilege _ Privileged Accounts33
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.22
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods.111
πŸ’Ό PCI DSS v4.0.1 β†’ πŸ’Ό 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.2
πŸ’Ό 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.1
πŸ’Ό PCI DSS v4.0 β†’ πŸ’Ό 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.2
πŸ’Ό 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.1