Profile Applicability:

  • Level 1

Description:

AWS Secrets Manager helps manage, retrieve, and rotate credentials, API keys, and other sensitive information. Ensuring that Secrets Manager secrets are not publicly accessible is critical for securing sensitive data and preventing unauthorized access. This SOP ensures that Secrets Manager secrets are not exposed to unauthorized users or the public, and access is limited to only trusted users or services with the appropriate IAM permissions.

Rationale:

  • Security: Publicly accessible secrets can lead to serious security breaches, allowing unauthorized users or attackers to gain access to sensitive resources. By ensuring secrets are not publicly accessible, we limit the exposure of these critical credentials.

  • Compliance: Many compliance standards (e.g., SOC 2, HIPAA) require that sensitive data like passwords, API keys, and tokens be stored securely and with proper access controls.

  • Best Practices: Following least privilege access principles and ensuring that secrets are properly secured helps to maintain a secure AWS environment.

Impact:

Pros:

  • Improved Security: Prevents unauthorized access to sensitive information.

  • Compliance: Meets security and regulatory requirements related to the protection of sensitive data.

  • Access Control: Limits the exposure of secrets to only authorized users and services.

Cons:

  • Operational Complexity: Ensuring proper access control and reviewing secrets access policies requires ongoing monitoring and configuration management.

  • Cost: Additional configurations (e.g., IAM roles and policies) may incur additional management overhead.

Default Value:

By default, AWS Secrets Manager secrets are not publicly accessible. However, misconfigurations, such as overly permissive IAM policies or resource-based policies, could expose secrets to unauthorized access.

Pre-requisite:

  • AWS IAM Permissions:

    • secretsmanager:DescribeSecret

    • secretsmanager:GetSecretValue

    • iam:ListAttachedRolePolicies

  • AWS CLI installed and configured.

  • Secrets Manager secrets have been created and stored.

Test Plan:

Using AWS Console:

  1. Sign in to the AWS Management Console.

  2. Navigate to Secrets Manager under Services.

  3. In the Secrets Manager Console, select Secrets.

  4. For each secret, check the Permissions tab to ensure that there are no resource-based policies allowing public access.

    • Verify that the secret is not accessible by any IAM role or user with broad permissions like * (all actions) or 0.0.0.0/0 (public IP addresses).

  5. If any secret is found to be publicly accessible, update its permissions to restrict access as described in the Implementation Steps below.

Using AWS CLI:

  1. To list all secrets and their permissions, run:

    aws secretsmanager list-secrets --query 'SecretList[*].ARN'

  2. For each secret, describe the resource-based policy by running:

    aws secretsmanager describe-secret --secret-id <secret-id> --query 'ResourcePolicy'

  3. Ensure that the resource-based policy does not allow public access. The ResourcePolicy field should not have "Effect": "Allow" for public IP addresses (0.0.0.0/0) or wildcard access ("Action": "*").

Implementation Steps:

Using AWS Console:

  1. Sign in to the AWS Management Console and navigate to Secrets Manager.

  2. In the Secrets Manager Console, select the secret you want to modify.

  3. Under the Permissions tab, review the resource-based policy and ensure it does not allow public access.

  4. If public access is granted, update the policy to restrict access to authorized users, services, or IAM roles:

    • Modify the IAM policies attached to users and services accessing the secret to ensure they have the least privilege required.

    • Update the resource-based policy (if applicable) to restrict access to specific IAM roles or services.

  5. Save the changes to apply the updated permissions.

Using AWS CLI:

  1. To update the resource-based policy for a secret to restrict public access, run:

    aws secretsmanager put-resource-policy --secret-id <secret-id> --resource-policy '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Principal":"*","Resource":"*","Condition":{"IpAddress":{"aws:SourceIp":"0.0.0.0/0"}}}]}'

  2. If necessary, update the IAM policies attached to roles or users that access the secret:

    aws iam update-assume-role-policy --role-name <role-name> --policy-document <policy-json>

  3. Verify the updated permissions by running:

    aws secretsmanager describe-secret --secret-id <secret-id> --query 'ResourcePolicy'

  4. Ensure the secret is not publicly accessible.

Backout Plan:

Using AWS Console:

  1. If restricting access causes issues with legitimate users, sign in to the AWS Management Console.

  2. Navigate to Secrets Manager, select the secret, and go to Edit.

  3. Revert the IAM policies or resource-based policies to a more permissive configuration.

  4. Save the changes and verify that the secret access is restored for the intended users.

Using AWS CLI:

  1. To revert the resource policy to allow more permissive access, use the following command:

    aws secretsmanager put-resource-policy --secret-id <SECRET_ID> --resource-policy '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] }' --region <REGION>

  2. Verify the updated policy:

    aws secretsmanager describe-secret --secret-id <SECRET_ID> --region <REGION>

References:

CIS Controls Mapping:

Version

Control ID

Control Description

IG1

IG2

IG3

v8

3.4

Encrypt Data on End-User Devices – Ensure data encryption during file system access.

v8

6.7

Implement Application Layer Filtering and Content Control – Ensure appropriate content filtering is applied to sensitive files.

v8

6.8

Define and Maintain Role-Based Access Control – Implement and manage role-based access for file systems.

v8

14.6

Protect Information Through Access Control Lists – Apply strict access control to file systems.