As AWS and Security practitioners on large-scale AWS deployments, we’ve about seen it all. Most of these are very easy to implement and will go a very long way to ensuring your success on AWS.
1. Disable Root API Access Key and Secret Key
In AWS parlance, a “root” user is the login credential you used to create your AWS account with. This user was originally required for some very important aspects of your access to AWS services. It must be used only to create your initial administrative accounts in IAM. All future administration should then be done with these newly created IAM accounts.
Create 2-3 IAM users with administrative policies via a group. It is highly recommended that you create at least 2, but no more than 3 IAM administrators. This provides redundancy in case credentials are lost but limits the number of users with unlimited access to your AWS resources.
Disable/Remove the default AWS root user API access keys.Before deleting the root api make sure you create admin accounts.
2. Enable MFA Tokens Everywhere
There is also a nearly combative challenge between some more traditional security practices where the powers that be keep increasing the minimum password length, complexity requirements, shortening the time between password changes, or some combination. While these practices look good on paper, and may get you a compliance check box filled, in reality, they may drive actual users to the opposite behaviors. Some popular examples are storing passwords in an email or text message (today’s version of writing it on the keyboard or monitor,) using a rotation pattern with a series of similar passwords, incrementing a password by just adding a number, or bracketing an easily remembered word with special characters.
Given the potential risk, and undesirable outcome, adding another layer of security here just makes good business sense. Let’s be honest, a realistic password policy with an added extra layer of security on top of it helps the business, the users, and you stay secure.
3.Reduce IAM Users with Admin Rights
While the most common response in no, in many cases, IAM users are given full access to your AWS environment which includes both creating and deleting resources in all of the services. With the low cost of storage in the cloud, it is a recommended best practice to limit those users and applications that can permanently delete information.
AWS has provided you the ability in many situations to implement the least privilege methodology in many ways that may not be possible, or challenging to implement, in a traditional on-premise infrastructure.
While limiting access is a good best practice, there is always the need to do things that require increased privileges. You may want to allow a user to delete S3 objects, or you may want to give someone Admin privileges while you are away.
4.Use Roles for EC2
If you’re deploying an application on AWS that requires more than a simple web server, you’re going to quickly want to take advantage of AWS’ giant list of services. After all, we use AWS because we love building awesome things with these services.
In order for an application on an EC2 instance to store objects in S3, process messages from an SQS queue or any number of other AWS services, it will require permission to access the service’s API. The only way to communicate with the API is with an authentication token.
AWS uses API Access and Secret keys to get that authentication token, and yes, your application running on an EC2 instance will need that key pair to get to S3.
By implementing the Roles API key based approach org can have following benifits.
a. Reduced the surface area of attack
EC2 Role credentials are unique to an EC2 instance, if an instance is compromised, terminate the instance and let AutoScaling take care of launching a new one. No need to rotate keys like when an IAM Access Key is compromised.
b. Temporary authentication credentials
STS automatically rotates the credentials when the token expires, and the SDKs and CLI know how to handle this automatically.
c. Auditable activity
The AWS CloudTrail service allows you to examine activity from Roles.
d. Automatically generated authentication credentials
The Access key is not statically assigned to an IAM user, so there is no need to store them in a configuration file.
e. Limited privilege
Roles can be assigned IAM policies, so you can create Roles with very specific access to AWS services and resources. If a group of instances should send messages to a specific SNS topic, then you can restrict it to that topic ARN in the policy.
5. Least Privilege: Limit what IAM Entities Can Do with Strong Policies
Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized.
6.Rotate all the Keys Regularly
AWS recommends that as a best practice that all credentials, passwords and API Access Keys alike, be rotated on a regular basis. If a credential is compromised, this limits the amount of time that a key valid for.
One best practice I followed was that API Access keys were to be rotated every 90 days. My process was simple, but burdensome: 1) An operator tracked the age of an Access Key; 2) The operator created a new Access Key; 3)
The operator then supplied the new Access Key to the automation process; 4) After testing and deploying, the old Access Key was deactivated. Eventually, or at next rotation, the old Access Key was deleted
7.Watch your security groups
AWS provides the tools necessary to help control what traffic is allowed, and in this blog, we are going talk about Security Groups and their relatives, the Network Access Control List (NACL).
An old network sage once told me, “Block everything, only allow in what you need,” and in many cases he was spot on. If you try to figure out what to block all the time, that may be your full time job and a pretty negative one at that.
So, do you need to allow all traffic from 0.0.0.0/0? In AWS Network terms, that means everyone, every machine, everywhere has the ability to make a connection to your AWS resources.
8.World-Readable/Listable S3 Bucket Policies
By default, S3 does have a default Deny rule, so if you do nothing, only the account owner will ever be able to use S3. However, a quick review reveals three places where you can configure additional access to S3, IAM Policies, S3 Bucket Policies, and S3 Access Control Lists (ACLs).
Each one of these, or any combination of these, can be used to control access to S3, but as you grow with the service over time, it is possible to lose track of where or what is allowing access. This can open up security holes where you were not aware they existed. This can put your data at risk of loss or compromise
So, as a security best practice, it would be highly recommended to not use any S3 ACL if you can. While these do offer an easy way to configure access, they should be considered a legacy security control and not used
There are genreally 2 better options to configure your s3 bucket policies
If you are leveraging one more than the other, and it is working, it is okay to stick with that one. If you haven’t made a decision yet, I am going to reiterate what AWS include in the blog post above:
a.If you’re more interested in “What can this user do in AWS?” then IAM policies are probably the way to go. You can easily answer this by looking up an IAM user and then examining their IAM policies to see what rights they have
b.If you’re more interested in “Who can access this S3 bucket?” then S3 bucket policies will likely suit you better. You can easily answer this by looking up a bucket and examining the bucket policy
Pick one, and stick with it. Make it a policy going forward and try to stay away mixing them. It will be easier in the long run and for the people who follow in your footsteps.
References:
https://aws.amazon.com/documentation/
https://blogs.aws.amazon.com/security/
https://www.cisecurity.org/benchmark/amazon_web_services/
https://cloudsentry.evident.io
1. Disable Root API Access Key and Secret Key
In AWS parlance, a “root” user is the login credential you used to create your AWS account with. This user was originally required for some very important aspects of your access to AWS services. It must be used only to create your initial administrative accounts in IAM. All future administration should then be done with these newly created IAM accounts.
Create 2-3 IAM users with administrative policies via a group. It is highly recommended that you create at least 2, but no more than 3 IAM administrators. This provides redundancy in case credentials are lost but limits the number of users with unlimited access to your AWS resources.
Disable/Remove the default AWS root user API access keys.Before deleting the root api make sure you create admin accounts.
2. Enable MFA Tokens Everywhere
There is also a nearly combative challenge between some more traditional security practices where the powers that be keep increasing the minimum password length, complexity requirements, shortening the time between password changes, or some combination. While these practices look good on paper, and may get you a compliance check box filled, in reality, they may drive actual users to the opposite behaviors. Some popular examples are storing passwords in an email or text message (today’s version of writing it on the keyboard or monitor,) using a rotation pattern with a series of similar passwords, incrementing a password by just adding a number, or bracketing an easily remembered word with special characters.
Given the potential risk, and undesirable outcome, adding another layer of security here just makes good business sense. Let’s be honest, a realistic password policy with an added extra layer of security on top of it helps the business, the users, and you stay secure.
3.Reduce IAM Users with Admin Rights
While the most common response in no, in many cases, IAM users are given full access to your AWS environment which includes both creating and deleting resources in all of the services. With the low cost of storage in the cloud, it is a recommended best practice to limit those users and applications that can permanently delete information.
AWS has provided you the ability in many situations to implement the least privilege methodology in many ways that may not be possible, or challenging to implement, in a traditional on-premise infrastructure.
While limiting access is a good best practice, there is always the need to do things that require increased privileges. You may want to allow a user to delete S3 objects, or you may want to give someone Admin privileges while you are away.
4.Use Roles for EC2
If you’re deploying an application on AWS that requires more than a simple web server, you’re going to quickly want to take advantage of AWS’ giant list of services. After all, we use AWS because we love building awesome things with these services.
In order for an application on an EC2 instance to store objects in S3, process messages from an SQS queue or any number of other AWS services, it will require permission to access the service’s API. The only way to communicate with the API is with an authentication token.
AWS uses API Access and Secret keys to get that authentication token, and yes, your application running on an EC2 instance will need that key pair to get to S3.
By implementing the Roles API key based approach org can have following benifits.
a. Reduced the surface area of attack
EC2 Role credentials are unique to an EC2 instance, if an instance is compromised, terminate the instance and let AutoScaling take care of launching a new one. No need to rotate keys like when an IAM Access Key is compromised.
b. Temporary authentication credentials
STS automatically rotates the credentials when the token expires, and the SDKs and CLI know how to handle this automatically.
c. Auditable activity
The AWS CloudTrail service allows you to examine activity from Roles.
d. Automatically generated authentication credentials
The Access key is not statically assigned to an IAM user, so there is no need to store them in a configuration file.
e. Limited privilege
Roles can be assigned IAM policies, so you can create Roles with very specific access to AWS services and resources. If a group of instances should send messages to a specific SNS topic, then you can restrict it to that topic ARN in the policy.
5. Least Privilege: Limit what IAM Entities Can Do with Strong Policies
Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized.
6.Rotate all the Keys Regularly
AWS recommends that as a best practice that all credentials, passwords and API Access Keys alike, be rotated on a regular basis. If a credential is compromised, this limits the amount of time that a key valid for.
One best practice I followed was that API Access keys were to be rotated every 90 days. My process was simple, but burdensome: 1) An operator tracked the age of an Access Key; 2) The operator created a new Access Key; 3)
The operator then supplied the new Access Key to the automation process; 4) After testing and deploying, the old Access Key was deactivated. Eventually, or at next rotation, the old Access Key was deleted
7.Watch your security groups
AWS provides the tools necessary to help control what traffic is allowed, and in this blog, we are going talk about Security Groups and their relatives, the Network Access Control List (NACL).
An old network sage once told me, “Block everything, only allow in what you need,” and in many cases he was spot on. If you try to figure out what to block all the time, that may be your full time job and a pretty negative one at that.
So, do you need to allow all traffic from 0.0.0.0/0? In AWS Network terms, that means everyone, every machine, everywhere has the ability to make a connection to your AWS resources.
8.World-Readable/Listable S3 Bucket Policies
By default, S3 does have a default Deny rule, so if you do nothing, only the account owner will ever be able to use S3. However, a quick review reveals three places where you can configure additional access to S3, IAM Policies, S3 Bucket Policies, and S3 Access Control Lists (ACLs).
Each one of these, or any combination of these, can be used to control access to S3, but as you grow with the service over time, it is possible to lose track of where or what is allowing access. This can open up security holes where you were not aware they existed. This can put your data at risk of loss or compromise
So, as a security best practice, it would be highly recommended to not use any S3 ACL if you can. While these do offer an easy way to configure access, they should be considered a legacy security control and not used
There are genreally 2 better options to configure your s3 bucket policies
If you are leveraging one more than the other, and it is working, it is okay to stick with that one. If you haven’t made a decision yet, I am going to reiterate what AWS include in the blog post above:
a.If you’re more interested in “What can this user do in AWS?” then IAM policies are probably the way to go. You can easily answer this by looking up an IAM user and then examining their IAM policies to see what rights they have
b.If you’re more interested in “Who can access this S3 bucket?” then S3 bucket policies will likely suit you better. You can easily answer this by looking up a bucket and examining the bucket policy
Pick one, and stick with it. Make it a policy going forward and try to stay away mixing them. It will be easier in the long run and for the people who follow in your footsteps.
References:
https://aws.amazon.com/documentation/
https://blogs.aws.amazon.com/security/
https://www.cisecurity.org/benchmark/amazon_web_services/
https://cloudsentry.evident.io
