AWS Billing
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-BILLING-1 | Check that the ability to modify or update AWS Billing options are only assumable to authorized principals. | In all AWS environments, ensure that only billing and account administrators are able to update or modify AWS billing and account options. Unauthorized modifications could affect your billing payments, budgets, or account information such as email addresses and security contacts. | For unauthorized principals, either remove the associated IAM Actions | https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsbilling.html |
aws-portal:ModifyBilling aws-portal:ModifyAccount aws-portal:ModifyPaymentMethods |
AWS Budgets
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-BUDGETS-1 | Check that the ability to modify or update AWS Budgets options are only assumable to authorized principals. | In all AWS environments, ensure that only Budget administrators and authorized principals should be able to update or modify AWS Budgets options. Unauthorized modifications could affect your cost and usage budgets | For unauthorized principals, either remove the associated IAM Actions | https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html |
budgets:ModifyBudget |
Amazon CloudTrail
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-CLOUDTRAIL-1 | Check that Principals aren’t allowed to DeleteTrail or StopLogging | As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that this functionality cannot be disabled by most entities within your Organization. This permission should be limited to breakglass roles (those who own the logging capability). It is also important to call out that Cloudtrail supports Resource Level Permissions for individual trails, so this can be scoped to Infosec/Logging Team owned Trails if the usecase exists for other independent teams to need access to manage their own trails | Verify that DeleteTrail and StopLogging are explicitly denied to non-whitelisted Principals And That DeleteTrail and StopLogging permissions don’t exist in an Allow Statement for any non-whitelisted principal | https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscloudtrail.html |
cloudtrail:DeleteTrail cloudtrail:StopLogging |
| IAM-CLOUDTRAIL-2 | Check that only authorized principals are able to UpdateTrail. | Unauthorized principals could potentially turn off log file validation, turn off multi region trails, or turn off organizational trails. As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that this functionality is only for authorized principals within your Organization. Examples of authorized principals include break glass roles or those who own the logging capability, such as Security or the Logging Team. | Verify that UpdateTrail is allowed only for authorized principals and denied for all else. | https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_UpdateTrail.html |
cloudtrail:UpdateTrail |
| IAM-CLOUDTRAIL-4 | Check that Principals aren’t allowed to PutEventSelectors or PutInsightSelectors. | As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that the CloudTrail event selectors can’t be modified to disable the majority of CloudTrail events within your Organization. This permission should be limited to breakglass roles (those who own the logging capability). It is also important to call out that Cloudtrail supports Resource Level Permissions for individual trails, so this can be scoped to Infosec/Logging Team owned Trails if the usecase exists for other independent teams to need access to manage their own trails | Verify that PutEventSelectors and PutInsightSelectors are explicitly denied to non-whitelisted Principals and that PutEventSelectors and PutInsightSelectors permissions don’t exist in an Allow Statement for any non-whitelisted principal | https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscloudtrail.html |
cloudtrail:PutEventSelectors cloudtrail:PutInsightSelectors |
| IAM-CLOUDTRAIL-5 | Check that only authorized administrative Principals are allowed AWS CloudTrail modification permissions. | As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that this functionality cannot be disabled or modified by most unathorized entities within your Organization. This permission should be limited to those who own the logging capability or break glass principals. It is also important to call out that Cloudtrail supports Resource Level Permissions for individual trails, so this CloudTrail permissions can be scoped to Infosec or Logging Team owned Trails if the usecase exists for other independent teams that need access to manage their own trails. | Verify that CloudTrail modification permissions are explicitly denied to non-whitelisted Principals and that the CloudTrail modification permissions don’t exist in an Allow statement for any unauthorized principal. | https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscloudtrail.html |
cloudtrail:DeleteTrail cloudtrail:PutEventSelectors cloudtrail:PutInsightSelectors cloudtrail:RemoveTags cloudtrail:StopLogging cloudtrail:UpdateTrail |
AWS CodeCommit
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-CODECOMMIT-1 | DeleteRepository action for CodeCommit is only allowed to whitelisted roles | CodeCommit acts as the source of truth for the versioning of different projects used by the application and/or central IT teams. If privileges to delete repository are not clearly managed, it can lead to accidental deletion of repository leading to data loss | Addingaws:ResourceTag/${TagKey}in the IAM policy’s condition to only allow whitelisted roles to delete the repository | codecommit:DeleteRepository |
Amazon Elastic Compute Cloud (EC2)
Amazon Elastic Container Registry (ECR)
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-ECR-2 | Check that only authorized principals are able to pull images from ECR. | An authorization token is used to manage authorization to ECR. Only authorized principals should have the ability to retrieve the authorization token, in order to protect any images in ECR. | For the action ecr:GetAuthorizationToken either: Explicitly grant to a list of authorized principals OR Consider usingaws:PrincipalOrgPathswhen multiple AWS Accounts need access. | https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr_managed_policies.html#AmazonEC2ContainerRegistryReadOnly https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_GetAuthorizationToken.html |
ecr:GetAuthorizationToken |
Amazon Elastic Kubernetes Service
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-EKS-1 | Check that the management of your EKS clusters is for authorized principals only. | It is important that access control to the management of your EKS clusters is only performed by your authorized principals. Protect against unauthorized modifications or changes to your EKS clusters by limiting access to only your administrative principals. | eks:CreateCluster eks:CreateFargateProfile eks:CreateNodegroup eks:DeleteCluster eks:DeleteFargateProfile eks:DeleteNodegroup eks:TagResource eks:UntagResource eks:UpdateClusterConfig eks:UpdateClusterVersion eks:UpdateNodegroupConfig eks:UpdateNodegroupVersion |
Amazon GuardDuty
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-GUARDDUTY-1 | Ensure GuardDuty master account does not have permission to StopMonitoringMembers action | The master account should not have permissions to deregister a centralized member account unless it is done by a security admin Makes the accounts go “invisible” which can lead to malicious activities which cannot be viewed at org master level | Remove principal ARNs if they don’t meet the whitelisted role name and/or statement body | guardduty:StopMonitoringMembers |
AWS Identity and Access Management (IAM)
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-IAM-1 | Check that the management of AWS IAM Users, secret access keys, and multi-factor authentication is for authorized principals only. | While AWS IAM Users are typically not recommended today, in favor of federated principals, IAM Users might be needed for break glass procedures or operational availability when an identity provider is unavailable and federation is not possible. However, in general these actions are sensitive should be scoped appropriately. | Secure by restricting to Security Operations only and authorized roles. | https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html |
iam:AddUserToGroup iam:AttachGroupPolicy iam:CreateLoginProfile iam:CreateUser iam:CreateVirtualMFADeviceiam iam:DeleteAccessKey iam:DeleteGroup iam:DeleteGroupPolicy iam:DeleteLoginProfile iam:DeleteUser iam:DeleteUserPolicy iam:DeleteVirtualMFADevice iam:DetachGroupPolicy iam:DetachUserPolicy iam:EnableMFADevice iam:PutGroupPolicy iam:PutUserPolicy iam:RemoveUserFromGroup iam:ResyncMFADevice iam:UpdateAccessKey iam:UpdateGroup iam:UpdateLoginProfile iam:UpdateUser |
| IAM-IAM-11 | Check that the management of AWS IAM Users, AWS IAM Roles, AWS IAM Groups, secret access keys, and multi-factor authentication is for authorized principals only. | It is important that access control to the management of your AWS principals and AWS permissions is only performed by your authorized principals. Protect against unauthorized identity by limiting access to only your administrative principals. | Verify that IAM administrative and modification permissions are explicitly denied to non-whitelisted principals and that the IAM modification permissions don’t exist in an Allow statement for any unauthorized principals. | https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html |
iam:AddClientIDToOpenIDConnectProvider iam:AddRoleToInstanceProfile iam:AddUserToGroup iam:AttachGroupPolicy iam:AttachRolePolicy iam:AttachUserPolicy iam:ChangePassword iam:CreateAccessKey iam:CreateAccountAlias iam:CreateGroup iam:CreateInstanceProfile iam:CreateLoginProfile iam:CreateOpenIDConnectProvider iam:CreatePolicy iam:CreatePolicyVersion iam:CreateRole iam:CreateSAMLProvider iam:CreateServiceLinkedRole iam:CreateServiceSpecificCredential iam:CreateUser iam:CreateVirtualMFADevice iam:DeactivateMFADevice iam:DeleteAccessKey iam:DeleteAccountAlias iam:DeleteAccountPasswordPolicy iam:DeleteGroup iam:DeleteGroupPolicy iam:DeleteInstanceProfile iam:DeleteLoginProfile iam:DeleteOpenIDConnectProvider iam:DeletePolicy iam:DeletePolicyVersion iam:DeleteRole iam:DeleteRolePermissionsBoundary iam:DeleteRolePolicy iam:DeleteSAMLProvider iam:DeleteServerCertificate iam:DeleteServiceLinkedRole iam:DeleteServiceSpecificCredential iam:DeleteSigningCertificate iam:DeleteSSHPublicKey iam:DeleteUser iam:DeleteUserPermissionsBoundary iam:DeleteUserPolicy iam:DeleteVirtualMFADevice iam:DetachGroupPolicy iam:DetachRolePolicy iam:DetachUserPolicy iam:EnableMFADevice iam:PutGroupPolicy iam:PutRolePermissionsBoundary iam:PutRolePolicy iam:PutUserPermissionsBoundary iam:PutUserPolicy iam:RemoveClientIDFromOpenIDConnectProvider iam:RemoveRoleFromInstanceProfile iam:RemoveUserFromGroup iam:ResetServiceSpecificCredential iam:ResyncMFADevice iam:SetDefaultPolicyVersion iam:SetSecurityTokenServicePreferences iam:TagRole iam:TagUser iam:UntagRole iam:UntagUser iam:UpdateAccessKey iam:UpdateAccountPasswordPolicy iam:UpdateAssumeRolePolicy iam:UpdateGroup iam:UpdateLoginProfile iam:UpdateOpenIDConnectProviderThumbprint iam:UpdateRole iam:UpdateRoleDescription iam:UpdateSAMLProvider iam:UpdateServerCertificate iam:UpdateServiceSpecificCredential iam:UpdateSigningCertificate iam:UpdateSSHPublicKey iam:UpdateUser iam:UploadServerCertificate iam:UploadSigningCertificate iam:UploadSSHPublicKey |
| IAM-IAM-2 | Check that the management of IAM Roles and Policies for authorized principals only, ideally build automation roles only. | The creation, update, and deletion of roles and policies and SAML provides needs to occur on approved changes to the IAM environment. However, these changes should be gated and restricted to authorized roles only, such as build automation, to prevent against any unintended principal granting themselves unauthorized permissions. The following permissions should be scoped appropriately. | Secure to only allow build automation. | https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html |
iam:AttachRolePolicy iam:AttachUserPolicy iam:CreateAccountAlias iam:UpdateAssumeRolePolicy iam:CreateSAMLProvider iam:CreateServiceLinkedRole iam:DeleteAccountAlias iam:DeleteAccountPasswordPolicy iam:DeletePolicy iam:DeletePolicyVersion iam:DeleteRole iam:DeleteRolePermissionsBoundary iam:DeleteRolePolicy iam:DeleteSAMLProvider iam:DeleteServiceLinkedRole iam:DeleteUserPermissionsBoundary iam:DetachRolePolicy iam:PutRolePermissionsBoundary iam:PutRolePolicy iam:PutUserPermissionsBoundary iam:UpdateAccountPasswordPolicy iam:UpdateAssumeRolePolicy iam:UpdateRole iam:UpdateRoleDescription iam:UpdateSAMLProvider |
| IAM-IAM-4 | IAM Policy Documents utilized as a Permissions Boundary are protected from modification from unauthorized entities | When utilizing a delegated admin model of IAM to allow developers to create their own roles - a permissions boundary is utilized to prevent privilege escalation. It is important to ensure that the Delegated Admins do not have access to modify the Policy Document used as their Permissions Boundary - this creates a risk of privilege escalation. | Prevent the following IAM Actions: “iam:CreatePolicyVersion”, “iam:DeletePolicy”, “iam:DeletePolicyVersion”, “iam:SetDefaultPolicyVersion” on the ARN of the policy document that is utilized as the permissions boundary. This can be achieved as an outright deny at the SCP, or at the Permissions Boundary level. Utilizing IAM Paths (eg - a seperate path for Delegated Admins vs Protected IAM entities) to achieve the same outcome - as long as developers cannot edit their own Permissions Boundary, or alter the current policy version. | https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate |
iam:CreatePolicyVersion iam:DeletePolicy iam:DeletePolicyVersion iam:SetDefaultPolicyVersion |
| IAM-IAM-7 | iam:GetAccountAuthorizationDetails is limited to only whitelisted roles | Since this action provides all information (IAM principals and their relationship with each other) about your IAM constrcuts in an account it can be used for recon for unintended actions | Removal of the action from the policy | https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountAuthorizationDetails.html |
iam:GetAccountAuthorizationDetails |
| IAM-IAM-8 | iam:CreateUser is not allowed in roles/users who do not have business justification to have it | In enterprise environment, the need for having permissions to create IAM users is negligible. The only use case would be for power user who creates on-demand users in case of an incident or emergency. Thus, general use roles should not be having this permission. | Removal of the action from the role unless it is whitelisted | iam:CreateUser |
|
| IAM-IAM-9 | Adding Managed Policy for denying high risk APIs | From the attacker perspective, walking through the first three steps of an attack (Reconnaissance, Scanning, and Access & Escalation), an attacker could leverage specific API calls in order to do damage to an AWS account. These particular APIs are what are commonly used in known attacks. | Add a policy that specifically denies the APIs contained within the Reference section, and adding the policy to IAM Users and Roles that are used as service users/roles. | s3:ListBucket s3:ListAllMyBuckets lambda:ListFunctions kms:ListKeys kms:ListAliases cloudtrail:DescribeTrails cloudtrail:ListTrails iam:Generate iam:Get iam:List* organizations:DescribeAccount organizations:DescribeOrganization organizations:DescribeOrganizationalUnit organizations:ListAccounts organizations:ListAWSServiceAccessForOrganization organizations:DescribePolicy organizations:ListChildren organizations:ListParents organizations:ListPoliciesForTarget organizations:ListRoots organizations:ListPolicies organizations:ListTargetsForPolicy ec2:TerminateInstances ec2:ModifyInstanceMetadataOptions |
AWS Key Management Service (KMS)
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-KMS-2 | Check that either only authorized principals or no principals can delete imported key material. | This is a potentially destructive action. Deletes key material that you previously imported. This operation makes the specified customer master key (CMK) unusable until the key material is reimported. All encrypted data is unreadable and unable to be decrypted until the customer reimports the exact same key material. A decision should be made if any break-glass roles should have this capability. These authorized roles should be whitelisted and all other rules should trigger a violation. | Permission kms:DeleteImportedKeyMaterial should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to delete imported key material. | https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys-delete-key-material.html |
kms:DeleteImportedKeyMaterial |
| IAM-KMS-3 | Check that either only authorized principals or no principals can delete CMKs. | Deleting a CMK is a destructive and potentially dangerous operation. When a CMK is deleted, all data that was encrypted under the CMK is unrecoverable. Even in development this can be disruptive as there might be unnecessary downtime. The preventive control is to avoid ununauthorized capability of deleting CMKs. Relying on the 7 day waiting period and notificatons require appropriate detective controls. | Permission kms:ScheduleKeyDeletion should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to delete CMKs | https://docs.aws.amazon.com/kms/latest/APIReference/API_ScheduleKeyDeletion.html |
kms:ScheduleKeyDeletion |
| IAM-KMS-4 | Check that either only authorized principals or no principals can disable CMKs. | If you disable a CMK, it cannot be used to encrypt or decrypt data until you re-enable it. This has immediate effectiveness. This could potentially incur downtime in a production environment. Even in development this can be disruptive as there might be unnecessary downtime. | Permission kms:DisableKey should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to disable CMKs. | https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html |
kms:DisableKey |
| IAM-KMS-5 | Check that either only authorized principals or no principals can place a new KMS key policy. | Users with the PutKeyPolicy permission for a CMK can completely replace the key policy for a CMK with a different key policy of their choice. | Permission kms:PutKeyPolicy should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to put key policy. | https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf |
kms:PutKeyPolicy |
| IAM-KMS-7 | Check that either only authorized principals or no principals can disable key rotation. | Disabling key rotation will prevent the CMK from automatic annual rotation. | Permission kms:DisableKeyRotation should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to disable CMKs. | https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html |
kms:DisableKeyRotation |
| IAM-KMS-9 | Check that only authorized administrative Principals are allowed AWS KMS administrative permissions. | AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. It is important that access control to the management of your keys is only performed by authorized administrative key management administrators. | Verify that KMS administrative and modification permissions are explicitly denied to non-whitelisted Principals and that the KMS modification permissions don’t exist in an Allow statement for any unauthorized principal. | https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html |
kms:CancelKeyDeletion kms:ConnectCustomKeyStore kms:CreateAlias kms:CreateCustomKeyStore kms:CreateGrant kms:CreateKey kms:DeleteAlias kms:DeleteCustomKeyStore kms:DeleteImportedKeyMaterial kms:DisableKey kms:DisableKeyRotation kms:DisconnectCustomKeyStore kms:ImportKeyMaterial kms:PutKeyPolicy kms:RetireGrant kms:RevokeGrant kms:ScheduleKeyDeletion kms:TagResource kms:UntagResource kms:UpdateAlias kms:UpdateCustomKeyStore kms:UpdateKeyDescription |
AWS Lambda
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-LAMBDA-2 | Check that the management of your Lambdas is for authorized principals only. | It is important that access control to the management of your Lambdas is only performed by your authorized principals. Protect against unauthorized modifications or changes to your Lambdas by limiting access to only your administrative principals. | lambda:AddLayerVersionPermission lambda:AddPermission lambda:CreateAlias lambda:CreateEventSourceMapping lambda:CreateFunction lambda:DeleteAlias lambda:DeleteEventSourceMapping lambda:DeleteFunction lambda:DeleteFunctionConcurrency lambda:DeleteFunctionEventInvokeConfig lambda:DeleteLayerVersion lambda:DeleteProvisionedConcurrencyConfig lambda:DisableReplication lambda:EnableReplication lambda:InvokeAsync lambda:InvokeFunction lambda:PublishLayerVersion lambda:PublishVersion lambda:PutFunctionConcurrency lambda:PutFunctionEventInvokeConfig lambda:PutProvisionedConcurrencyConfig lambda:RemoveLayerVersionPermission lambda:RemovePermission lambda:TagResource lambda:UntagResource lambda:UpdateAlias lambda:UpdateEventSourceMapping lambda:UpdateFunctionCode lambda:UpdateFunctionConfiguration lambda:UpdateFunctionEventInvokeConfig |
Amazon Simple Storage Service (S3)
Amazon Simple Storage Service (S3) Access Points
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-S3-AP-1 | Check that the VPC mentioned in the S3-AccessEndpoint is valid VPC | The Access Point cannot be edited once it has been created. If it has been created incorrectly, the only method is to delete the access point and create a new access point. | Check the VPC value provided in the API call payload for creating access point is a valid VPC in the account specified. | https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html |
s3:CreateAccessPoint |
| IAM-S3-AP-2 | Block Public access to buckets and objects through access points | The block public access setting of the Access point should not be open to public unless really justified by customer requirements. | Check PublicAccessBlockConfiguration setting of access point is set to not allow public access. |
s3:CreateAccessPoint |
|
| IAM-S3-AP-3 | Allow s3:GetObject and s3:PutObject on the S3 Access Points owned by the account. | If a user has IAM policies or bucket policies which allow authorized users to interact with the bucket’s objects through access point, the s3:DataAccessPointAccount condition should be added to ensure only access points owned by the buckets are allowed to perform s3:GetObject and s3:PutObjects | Add s3:DataAccessPointAccount condition to the bucket policy to deny all GetObject and PutObject actions to S3 Access point’s owner account | https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies |
s3:DataAccessPointAccount |
| IAM-S3-AP-4 | Limit access to the S3 bucket only through a specific S3 Access Point for the bucket | Buckets which have specific access points enabled and do not have access pattern outside of access points. These buckets should have bucket policies which allow GetObject and PubObject only through the approved S3 Access Endpoints | Add s3:DataAccessPointAccount condition to the bucket policy to deny all GetObject and PutObject actions to S3 Access point’s owner account | https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies |
s3:DataAccessPointAccount |
| IAM-S3-AP-5 | Limit access to the S3 bucket only to traffic originated from VPC and coming through S3 Access Points | Buckets which have S3 access points enabled should have bucket policy which limits access to them only through traffic originating from Amazon VPCs. This additional control prevents misconfiguration of bucket access pattern. | Add s3:AccessPointNetworkOrigin condition with VPC value to the bucket policy to deny all GetObject and PutObject actions to S3 Access point’s owner account |
https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies |
s3:AccessPointNetworkOrigin |
| IAM-S3-AP-6 | Limit access to S3 bucket objects by restricting principals which have a common tag as the object | Buckets which have S3 access points enabled should have S3 access point policy enabled which allows IAM principals to make call to the objects which are tagged with a particular value | Add s3:ExistingObjectTag condition in the S3 Access Endpoint policy which has allows certain principals with the similar tags to get access to the objects |
https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies |
s3:GetObject |
AWS Secrets Manager
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-SECRETSMANAGER-1 | Check that DeleteSecret is appropriately scoped and for authorized principals. | Deleting a secret makes the secret immediately inaccessible and could impact applications that depend on the secret. | Check that Only authorized principals can invoke DeleteSecret Scope using secretsmanager:SecretId secretsmanager:AllowRotationLambdaArn or with a tag secretsmanager:ResourceTag/Optionally prevent disabling of the recovery window using theconditionssecretsmanager:ForceDeleteWithoutRecovery and secretsmanager:RecoveryWindowInDays | https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteSecret.html#SecretsManager-DeleteSecret-request-ForceDeleteWithoutRecovery https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_iam-permissions.html#iam-contextkeys |
secretsmanager:DeleteSecret |
| IAM-SECRETSMANAGER-2 | Check that only authorized principals are able to retrieve a secret value. | Sensitive or confidential information (e.g., credentials) would be expected to be stored in AWS Secrets Manager. Ensuring only authorized access reduces the risk of unauthorized access. | Check that only authorized principals can invoke GetSecretValue. Specify the Secret Resource Arn. Also, scope using the Condition key secretsmanager:SecretId or secretsmanager:ResourceTag/ | https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_iam-permissions.html#iam-contextkeys |
secretsmanager:GetSecretValue |
| IAM-SECRETSMANAGER-3 | Check for separation of duties between managing a secret and reading or writing to a secret. | An administrator is required to manage creating secret via CreateSecret. Though populating the secret value including both reading GetSecretValue and writing the secret PutSecretValue should be performed by a separate principal, ideally only automation should be generating a (random) secret value and rotating the secret. Separating out the management from actually viewing the secret data reduces the risk of unauthorized access. | Check that the administration CreateSecret principal is separate from the secret value principal GetSecretValue and PutSecretValue. | secretsmanager:CreateSecret |
Amazon Systems Manager (SSM)
| Identifier | Guardrail | Rationale | Remediation | References | IAM Actions |
|---|---|---|---|---|---|
| IAM-SSM-1 | Check that usage of ssm:SendCommand is scoped via the usage of Resource Level Permissions or via the usage of conditions such as ssm:ResourceTag (no usage of * except for breakglass/admin roles) | ssm:RunCommand allows command execution on a machine that is managed by SSM (SSM Agent Installed and Instance Profile configured with proper permissions). If a wildcard resource is specified - this grants unrestricted access to command execution on all SSM Managed EC2 Instances across the account. While some usecases may legitimately require this access (Breakglass/Admin Accounts, IR, etc), the majority of roles should be scoped to have this access only to EC2 Instances required for function. | Usage of Resource Level Permissions - Specifiying the ARN of the instances needed in the statement of the policy arn:Partition:ec2:{Region}:Account:instance/{InstanceId} Or Usage of a tag condition - ec2:ResourceTag to scope usage of the command to only instances containing the appropriate tag | https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssystemsmanager.html#awssystemsmanager-managed-instance https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html |
ssm:SendCommand |
| IAM-SSM-2 | ssm:StartSession action with Resource * that doesnt have a condition statement such as ssm:ResourceTag | StartSession permission allows a principal to start an SSH session with the instance target. Unrestricted access to this can lead to logging into resources which may or may not be owned by the intended principal. Session manager should allow login into properly tagged resources only. If there are the instances being spun up either deliberately or accidentally with the appropriate tags it should not be accessible via SSH using Systems Manager | Usage of tag condition such as ssm:ResourceTag OR Removal of the ssm:StartSession action from the IAM policy | https://docs.aws.amazon.com/systems-manager/latest/userguide/auth-and-access-control-permissions-reference.html |
ssm:StartSession |