By Wolfgang Unger

How can I secure my AWS resources?
How can we ensure the security of our data and applications on AWS?
As you might already know, AWS works with the shared responsibility model to secure your cloud resources. This means, AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.


But this also means, you are responsible for the Security in the cloud. It is your responsibility to take care of the security of the login process, secure your data in the cloud, encrypt data in rest and in transit and so on. We will have a look on the most importing best practices you have to follow :

IAM Rules :

1. Avoid using the AWS root account user for daily tasks.
You need this user only for a couple of actions ( like changing the credit card), so always use a IAM user for daily tasks, not the root user

2. Avoid using AWS root account user access keys as it gives full access to all resources.
The root user don't need access keys for the CLI. Use your IAM user for this purpose.

3. MFA authentication is enabled for the root account to provide two-factor authentication

4. Assign individual IAM users with necessary permissions to enable login Ensure these User Accounts also have MFA authentication.
It is good to have a Master Account for your IAM users and access the other accounts, holding the resources, by IAM roles in these accounts.

5. Always ensure a strong password policy for users

6. IAM Access Keys must be rotated at periodic intervals

7. Provide access to a resource through IAM Roles, use Instance Roles for EC2, EB and ECS

8. Provide access to other company accounts through IAM Roles.
Create Roles in your Stage accounts and perform a switch role after login in the Master Account with your IAM User.

9. Apply the principle of least privilege. Grant least access while creating IAM Policies, to perform only the necessary actions.
Don't assign the Adminstrator Policy to anybody ! Only assign rights which are really needed. In the Prod Stage Account this is of highest priority .

10. Conditions can be defined for Policies under which access is granted to a resource. This way you can limit the access even more fine granular.

S3 Rules:

1. Ensure S3 buckets are not publicly accessible (public read or write permissions). S3 Buckets serving as static webside of course need public read permissions

2. Make use of object-level or bucket-level permissions in addition to IAM Policies to grant access to resources


3. Enable MFA Delete to prevent accidental deletion of buckets ( not possible if data in the bucket must be deleted or cleaned up by functionality)
4. Consider encryption of stored data, which can be done in two ways — server-side and client-side encryption

5. Enable encryption of inbound and outbound data traffic, through SSL endpoints

6. Configure S3 lifecycle management through rule-based actions and use versioning to store and retrieve multiple versions of an object in a bucket, to deal with accidental deletions

7. Ensure S3 access logging is enabled

EC2, SGs & Computing Rules:

1. Restrict access to instances from limited IP ranges using Security Groups Limit the range of open ports on EC2 security groups, to prevent exposure to vulnerabilities

2. Ensure data and disk volumes in EBS are encrypted with AES-256, the industry standard algorithm

3. Ensure ALBs/ELBs have a valid security group attached to it

4. Monitor and optimize default security groups, as they allow unrestricted access for inbound and outbound traffic ( you can use Trusted advisor)

5. Ensure restricted inbound access to SSH, FTP, SMTP, MySQL, PostgreSQL, MongoDB, MSSQL, CIFS, etc; to required entities only

6. Use IAM roles to grant access to EC2, instead of access keys for temporary requirements

7. Always place non internet-facing servers ( application servers for example) in private subnets, allow access only from inside the VPC.

RDS Rules:

1. Ensure encryption of the RDS instances and snapshots, using AES-256 level encryption

2. Ensure RDS security groups do not allow unrestricted access

3. Protect data in transit to RDS through SSL endpoints

4. Monitor control to RDS using AWS KMS and Customer Managed Keys

5. Ensure RDS database instances and snapshots are not publicly accessible

6. Always place Databases in private subnets, allow access only from inside the VPC.

7. Enable the auto minor upgrade feature for RDS

Conclusion

Hopefully your accounts are all setup the correct way and you did not find any security issues.
If not, you should get it fixed real quick, you might have some trouble pretty soon.
Find someone with the knowHow to do it right, of course you can also contact us,
we would proudly help to get your architecture save and up to date with all best practices .

Contact us