Identity and Access Management
| FSISEC1: How do you ensure that AWS IAM Roles are compliant with the principle of least privilege? |
|---|
| FSISEC2: How do you monitor the use of elevated credentials, such as administrative accounts, and guard against privilege escalation? |
|---|
Design functional IAM Roles based on the principle of least privilege. Create roles which have the minimum set of policies, scoped down with applicable actions, resources and conditions. For example, you can create a role for all data scientists within your organization and allow them access to only AWS data analytics services with ReadOnlyAccess to specific buckets/keys.
You can also share resources in one AWS account with users in a different AWS account by delegating access across AWS accounts using AWS IAM Roles. To allow users from one account to access resources in another, create a Role that defines who can access it and what permissions it grants to users that switch to it. You can limit the Role’s permissions to only what the Role requires to perform its function, aligned with the principle of least privilege.
Review IAM Policies IAM Policies are powerful and subtle, so it's important to study and understand the permissions that are granted by each policy. For more information, read the Tips for Reviewing IAM Policies.
Review permissions using service last accessed data
Perform periodic reviews of your IAM Roles using Service Last Accessed Data. You can view a report about the last time that an IAM entity (user or role) attempted to access a service. You can then use that information to refine your policies to allow access to only the services that are in use. You can generate a report for each type of resource in IAM. For more information, read the Viewing Service Last Accessed Data process documentation.
Perform role reviews and delete unused roles Perform periodic reviews of your IAM roles and delete roles that are not in use. Before you delete a role, review its recent service-level activity by viewing service last accessed data report.
Mitigate privilege escalation Privilege escalation
refers to the ability of a bad actor to use stealthy permissions to elevate permission
levels and compromise security. Privilege escalation can result from misusing a number of
non-administrator or non-full access permissions; for example,
iam:CreatePolicyVersion. This permission allows a user without administrator
privileges to create a new custom permission and set it as the default version for a policy,
even without access to the iam:SetDefaultPolicyVersion permission. To avoid
scenarios like this, pay attention to the following permissions:
-
iam:AddUserToGroup -
iam:AttachRolePolicy -
iam:AttachUserPolicy -
iam:CreateAccessKey -
iam:CreateLoginProfile -
iam:CreatePolicyVersion -
iam:CreateRole -
iam:CreateUser -
iam:DeleteRole -
iam:DeleteRolePermissionsBoundary -
iam:DeleteRolePolicy -
iam:DeleteUserPermissionsBoundary -
iam:DeleteUserPolicy -
iam:DetachRolePolicy -
iam:PassRole -
iam:PutRolePermissionsBoundary -
iam:PutRolePolicy -
iam:PutUserPermissionsBoundary -
iam:SetDefaultPolicyVersion -
iam:UpdateAssumeRolePolicy -
iam:UpdateLoginProfile -
iam:CreatePolicyVersion -
iam:UpdateRole -
iam:UpdateRoleDescription -
sts:AssumeRole
To prevent privilege escalation, you should use service control policies (SCPs) to
prevent users in your accounts, except for administrators or delegated admins, from using
administrative IAM actions. If you want to safely delegate permissions management to
trusted employees, you can use IAM permissions boundary feature. IAM permissions
boundary allows for safe delegation of IAM permissions management while preventing
escalation of privileges. For example, developers can safely create IAM roles for
AWS Lambda functions and Amazon EC2 instances without exceeding certain permissions boundaries
defined by the administrators. Refer to the Permission
boundaries round documentation
