AWS Cloud Security in a Nutshell
By: Supun Sandeeptha
Tags: Software Development, Security, AWS, DevOps, Development

Hi Folks, Today we are going to look at the AWS Cloud Security Best Practices. Security has become a trending topic all over the world with more and more data leaks from small enterprises to large scale enterprises. So let’s see how we can secure our AWS Account !

AWS Shared Responsibility Model

AWS Shared Responsibility Model

Below stated policies are measures which are advised by the AWS Cloud. AWS Cloud takes responsibility for their infrastructure, but they don’t take the responsibility for the security of the environment inside the customer’s account. Initially when an account is created below mentioned actions can be taken to layout the basic security measures of the root account.

1. Grant Least Privilege Access — Granting the least access needed to perform the desired actions for a particular user.

a. As enterprises are handling multiple client workloads on AWS, AWS has advised to separate these workloads using different accounts using AWS Organizations.

b. AWS advises to maintain common permission guardrails that restrict access to all identities. E.g.: Blocking Users using multiple regions, restricting users to use only one region. Restricting the users from deleting common resources such as security policies, etc.

c. Use the service control policies. E.g.: — Avoid users getting unwanted level of privileges inside the AWS cloud environment

d. Using Permission Boundaries: — Using Permission boundaries to control the level of access that administrators have over-controlling and managing accounts. E.g.: — Administrators can’t create policies that escalate their own access.

e. Reduce Permissions continuously: — Evaluate the access which are not used by identities and remove the unused permissions.

2. Enable Identity Federation: Centrally manage users and access across multiple applications and services. In order to federate multiple accounts in AWS Organizations use AWS Single Sign-on

3. Enable MFA in the root account. (Highly Recommended). Require activating MFA to all users as well.

4. Rotate Credentials (Change the passwords, access keys of your account regularly.) Set up an account policy so that other users and root account also needed to change the passwords regularly.

5. Lock away your AWS account root user access keys. AWS recommends this approach because access keys of your root account have access to all resources and services including billing details by default. Therefore, delete the root access keys If there are ones in your account, if there are no access keys for your root account, don’t create one.

6. Never Share the password of your root account with anyone. If other users require access to the AWS cloud environment create individual IAM users and groups. Give the users necessary permissions only. For yourself also create an administrator IAM User.

7. User Groups to Manage Users. (When your organization is growing and increasing the number of users, create groups with the necessary level of access to your AWS cloud environment and add users to those groups).

8. Be careful when granting users IAM access, as they get the privilege to deal with creating users, groups, using access keys, etc. When revoking permissions of such a user who had administrator access, we never know whether he has created other user accounts using his admin and IAM privileges. In that case, even if the root user revokes access for that admin user, he might use some other accounts access keys and access the account at a later time. This might be one critical threat that anyone never saw coming. (Highly recommended to keep the IAM full access with the root user only)

9. Configure a Strong Password Policy for users.

a. If users have the permission to create their own password for the accounts, there should be a password policy in place in order to make sure that, the password has a minimum length (14 characters recommended) assigned by the user, contains alphabetical and non-alphabetical characters and frequent password rotation requirements.

10. Use IAM Roles to grant permissions, when permission is needed from AWS service to service. E.g.: When EC2 instances need to access S3 buckets.

a. Create an IAM role selecting which services needs to access which service with what level of rights. E.g.: EC2 instances can only list S3 buckets. Never store access keys inside EC2 servers inside the AWS config directory. In case your EC2 instance is hacked, the hacker gets access to access key information.

11. Do not share AWS access keys.

a. Access keys provide programmatic access to the AWS environment. Never share the access keys or expose the keys in unencrypted environments. For applications that need to access AWS services, create roles that provide temporary permissions to the application.

12. Monitor activity in your AWS account using the below tools available with AWS

a. Amazon CloudFront — Log user requests that CloudFront receives.

b. AWS CloudTrail — Logs AWS API calls and related events made by or on behalf of an AWS account.

c. AWS Cloudwatch — Monitors your AWS cloud resources and the applications you run on AWS.

d. AWS Config — Provides detailed historical information about the configuration of your AWS services, including the IAM users, groups, roles, and policies.

Best Practices when using the AWS Services

1. Tighten the Cloud Trail configurations.

a. CloudTrail is an AWS service that generates log files of all API calls made within the Aws, including the AWS management console, SDKs, command-line tools, etc. This is a very important way of tracking what’s happening inside the AWS account. For auditing as well as post-incident investigation, this is very important.

b. If a hacker gets access to the AWS account, there’s a possibility they try to disable CloudTrail, therefore it’s recommended to keep the CloudTrail permissions only with the root user.

c. Enable CloudTrail across all geographic regions and AWS services to prevent activity monitoring gaps.

d. Turn on CloudTrail log file validation so that any changes made to the log file itself after it has been delivered to the S3 bucket is trackable to ensure log file integrity.

e. Enable access logging for CloudTrail S3 bucket so that you can track access requests and identify potentially unauthorized or unwarranted access attempts

f. Turn on multifactor authentication (MFA) to delete CloudTrail S3 buckets and encrypt all data in flight and at Rest.

2. Best Practices when using AWS Database and data storage services

a. Ensure that S3 buckets don’t have pubic read/write access unless required by the business.

b. Turn on RedShift audit logging in order to support auditing and post-incident forensic investigations for a given database.

c. Encrypt data stored on EBS as an extra security layer.

d. Encrypt Amazon RDS as an extra security layer.

e. Enable require _ssl parameter in all Redshift clusters to minimize the risk of man-in-middle attack.

f. Restrict public access to database instances to avoid malicious attacks such as brute force attacks, SQL injections, or DoS attacks.

g. In all possible cases place the database instances in private subnets.

3. Automate Detective Control

Automating Detective Control

a. If some incident happens in your AWS account, how to respond to that event? That’s where Automate Detective Controls come to play. You can use Cloudformation to deploy your infrastructure and use AWS CloudTrail to log the events if some malicious event happens in your account, you can automate the action against that event using this architecture.

4. Secure Your Operating Systems and Applications

a. With the AWS shared responsibility model, you manage your operating systems and applications security. Amazon EC2 presents a true virtual computing environment, in which you can use web services interfaces to launch instances with a variety of operating systems with custom preloaded applications. You can standardize the operating system and application builds and centrally manage the security of your operating systems and applications in a single secure build repository. You can build and test a pre-configured AMI to meet your security requirements.

b. Disable root API access keys and secret key

c. Restrict access to instances from limited IP ranges using Security Groups.

d. Use Bastion hosts to access your EC-2 instances.

e. Password protect the .pem file on user machines.

f. Delete the pub key of users from the authorizedkeys file on your instances when users leave your organization.

g. Rotate credentials (DB, Access Keys)

h. Regularly run least privilege checks using IAM user Access Advisor and IAM user Last Used Access Keys.

i. Implement a single primary function per Amazon EC2 instance to keep functions that require different security levels from co-existing on the same server. E.g.: Implement web servers, database servers, and DNS servers separately.

j. Enable only necessary and secure services, protocols, daemons, etc. only required to the functioning of the operating system.

k. Never use password authentication mechanisms to authenticate with servers. (Configure sshd to allow only public key authentication. Set PubkeyAuthentication to Yes and PasswordAuthentication to No in sshd_config)

l. Always use encrypted communication channels.

5. Securing your AWS Infrastructure

a. Using Amazon VPC to define an isolated network for each workload or organizational entity.

b. Using private and public subnets to place your components based on business needs.

c. Using security groups to manage access to instances that have similar functions and security requirements.

d. Using Network Access Control Lists (NACLs) that allow stateless management of IP traffic. NACLs are agnostic of TCP and UDP sessions, but they allow granular control over IP protocols (for example GRE, IPsec ESP, ICMP), as well as control on a per-source/destination IP address and port for TCP and UDP. NACLs work in conjunction with Security groups.

e. Using host-based firewalls as a last line of defense.

6. Using Tags to manage AWS resources

a. Tagging Aws resources can help you in many ways when you have hundreds of resources are in play within your AWS cloud environment.

b. Generating alarms, if a resource is not tagged properly.

c. Proposed Minimum Tags.

i. Platform_Owner

ii. Resource_Owner

iii. Project Name

iv. Environment (Prod, Stag, Test, Dev)

d. Tags can be useful when generating consolidated reports per project or when it comes to billing.

e. You can add up to any 10 tags per resource.

This is a very summarized version of precautions that we can take to secure our AWS account. If you have any new ideas or different opinions regarding the AWS Cloud Security, feel free to comment.

👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬