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
IAM 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 IAM administrators. Refer to the
Permission
boundaries round documentation
