This content originally appeared on DEV Community and was authored by Mohamed Zahra
Lock away your AWSaccount root user access keys
Do not use your AWSaccount root user access key to make programmatic requests to Amazon Web Services (AWS). The access key for your AWS account root user gives full access to all your resources for all services, including your billing information. You cannot reduce the permissions associated with this key and must protect it like you would your credit card numbers or other sensitive secret.
- If you don't already have an access key for your AWS account root user, don't create one. Instead, use your account email address and password to sign in to the AWSManagement Console and create an IAM user for yourself that has administrative permissions. If you do need to create a new account, you can do so by signing into your existing account.
- If you do have an access key for your AWS account root user, delete it. If you must keep it, rotate (change) the access key regularly. To delete or rotate your root user access keys, go to the My Security Credentials page in the AWSManagement Console.
- Never share your AWSaccount root user password or access keys with anyone. The remaining sections of this document discuss various ways to avoid having to share your account's root user credentials with other users. They also explain how to avoid embedding them in an application.
- Use a strong password to help protect account-level access to the AWSManagement Console. For information about managing your AWSaccount root user password, see Changing the AWS account root user password.
- Enable AWS multi-factor authentication (MFA) on your AWSaccount root user account. For more information, see Using multi-factor authentication (MFA) in AWS.
Create individual IAM users
Don't give your AWS account credentials to anyone else.
Instead, create individual users for anyone who needs access to
your account. Create an IAM user for yourself as well, give that
user administrative permissions and use it for all your work.
You can create individual IAM users for people who access
your account. Each IAM user has a unique set of security
credentials, and you can grant different permissions to them. If
necessary, you can change or revoke an I AM user's permissions
anytime. It is possible to revoke the root user's password if
you don't want to give it to someone else. AWS recommends that
you create new users without permissions and require them to
change their password immediately. After they sign in for the
first time, you can add policies to the user.
Use user groups to assign permissions to IAM users
You can create user groups that relate to job functions
(administrators, developers, accounting, etc.) Next, define the
relevant permissions for each user group. All the users in an
IAM zser group inherit the permissions of the user group they
belong to. That way, you can make changes for everyone in a
user group in just one place.
Grant least privilege
When you create IAM policies, follow the standard security
advice of granting least privilege, or granting only the
permissions required to perform a task. This is more secure
than starting with too many permissions and then trying to
tighten them later. It's important to start with a minimum set
of permissions and grant additional permissions as necessary.
A.Understand access level groupings
You can use access level groupings to understand the level of
access that a policy grants. Policy actions are classified as
List, Read, Write, Permissions management, or Tagging. For
example, you can choose actions from the List and Read access
levels to grant read-only access to your users.
B.Validate your policies
IAM Access Analyzer provides over 100 policy checks to validate
your policies. It generates security warnings when a statement
in your policy allows access we consider overly permissive. You
can use the actionable recommendations that are provided
through the security warnings as you work toward granting least
privilege.
C.Generate a policy based on access activity
You can create a policy based on the access activity for an IAM
entity. IAM Access Analyzer reviews your CloudTrail logs and
generates a policy template that contains the permissions that
have been used by the entity in your specified time frame. You
can use the template to create a managed policy with fine-
grained permissions.
D.Use last accessed information
Last accessed information includes information about the
actions that were last accessed for some services, such as
Amazon EC2,IAM, Lambda, and Amazon S3. View this information on
the Access Advisor tab on the IAM console details page for an
IAM user, group, role, or policy. You can use this information
to identify unnecessary permissions so that you can refine your
IAM or Organizations policies to better adhere to the principle
of least privilege.
E.Review account events in AWS CloudTrail
To further reduce permissions, you can view your account's
events in AWS CloudTrail Event history. CloudTrail event logs
include detailed event information that you can use to reduce
the policy's permissions. The logs include only the actions and
resources that your IAM entities need.
Get started using permissions with AWS managed policies
AWS managed policies can give your employees the permissions
they need to get started. These policies are already available
in your account and are maintained and updated by AWS. To get
started quickly, you can use AWS managed policies to give your
employee access to the services they want or need.AWS managed
policies are designed to provide permissions for many common use
cases. Full access AWS managed policies define permissions for
service administrators by granting full access to a service.
Power-user policies such as AWSCodeCommitPowerUser and
AWSKeyManagementServicePowerUser provide multiple levels of
access to services without allowing permissions management
permissions. Partial-access policies like
AmazonMobileAnalyticsWriteOnlyAccess and AmazonEC2ReadOnlyAccess
provide specific levels of permission for users, user groups,
and roles.
Validate your policies
It is a best practice to validate the policies that you create.
You can perform policy validation when you create and edit JSON
policies. IAM identifies any JSON syntax errors, while IAM
Access Analyzer provides over 100 policy checks and actionable
recommendations to help you author secure and functional
policies. We recommend that you review and validate all of your
existing policies
Use customer managed policies instead of inline policies
For custom policies, we recommend that you use managed policies
instead of inline policies. A key advantage of using these
policies is that you can view all of your managed policies in
one place in the console. You can also view this information
with a single AWS CLI or AWS API operation. Inline policies are
policies that exist only on an IAM identity (user, user group,
or role). Managed policies are separate IAM resources that you
can attach to multiple identities.
Use access levels to review IAM permissions
AWS categorizes each service action into one of five access
levels based on what each action does: List, Read, Write,
Permissions management, or Tagging. You can use these access
levels to determine which actions to include in your policies.
Make sure that your policies grant the least privilege that is
needed to perform only the necessary actions.
Configure a strong password policy for your users
If you allow users to change their own passwords, create a
custom password policy that requires them to create strong
passwords and rotate their passwords periodically. You can
upgrade from the default password policy to define password
requirements, such as minimum length, minimum length and
whether it requires nonalphabetic characters. For more
information, see Setting an account password policy for IAM
users.
Enable MFA
For extra security, we recommend that you require multi-factor
authentication (MFA) for all users in your account. With MFA,
users have a device that generates a response to an
authentication challenge. Both the user's credentials and the
device-generated response are required to complete the sign-in
process. If a user's password or access keys are compromised,
your account resources are still secure because of the
additional authentication requirement.
The response is generated in one of the following ways:
1.Virtual and hardware MFA devices generate a code that you view
on the app or device and then enter on the sign-in screen.
2.U2F security keys generate a response when you tap the device.
The user does not manually enter a code on the sign-in screen.
Use roles for applications that run on Amazon EC2 instances
Amazon EC2 is a cloud computing platform that allows you to run
applications on an Amazon EC2 instance. When you launch an EC2
server, you can specify a role for the instance as a launch
parameter. Roles provide temporary credentials to the EC2
instances and these credentials are automatically rotated for
you. The role's permissions determine what the application is
allowed to do.
Use roles to delegate permissions
Don't share security credentials between accounts to allow users
from another AWS account to access resources in your AWS
account. Instead, use IAM roles. You can define a role that
specifies what permissions the IAM users in the other account
are allowed. You can also designate which AWS accounts have the
IAM users that are allowed to assume the role.
Do not share access keys
Do not embed access keys within unencrypted code or share these
security credentials between users in your AWS account. For
applications that need access to AWS, configure the program to
retrieve temporary security credentials using an IAM role. To
allow your users individual programmatic access, create a user
with personal access keys.
Rotate credentials regularly
If a password or access key is compromised without your
knowledge, you limit how long the credentials can be used to
access your resources. Change your own passwords and access keys
regularly, and make sure that all IAM users in your account do
as well. You can apply a custom password policy to your account
to require all your IAM user to rotate their IAM passwords.
Remove unnecessary credentials
You can find unused passwords or access keys using the console,
using the CLI or API, or by downloading the credentials report.
Passwords and access keys that have not been used recently might
be good candidates for removal. If you created an IAM user for
an application that does not use the console then the IAM
doesn't need a password.
Use policy conditions for extra security
You can define the conditions under which your IAM policies
allow access to a resource. For example, you can write
conditions to specify a range of allowable IP addresses that a
request must come from. You can also set conditions that require
the use of SSL or MFA (multi-factor authentication).
Monitor activity in your AWS account
Logging features are available in the following AWS services:
- Amazon CloudFront.
- AWS CloudTrail.
- Amazon CloudWatch.
- AWS Config.
- Amazon Simple Storage Service
This content originally appeared on DEV Community and was authored by Mohamed Zahra
Mohamed Zahra | Sciencx (2021-07-20T18:22:26+00:00) Security best practices in IAM.. Summarized.. Retrieved from https://www.scien.cx/2021/07/20/security-best-practices-in-iam-summarized/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.