In this chapter, we have covered some of the best practices that apply to AWS. At this point, I need to again stress the importance of securing your account and making sure that the root user is not being used for day-to-day tasks. The root credentials should be locked away in a secure place so that they are retrievable only in case of emergencies.
As a best practice, we want to create individual users so that these users can be uniquely identified when performing tasks within AWS and assign permissions to the users via group membership. Assigning permissions directly to users can lead to inconsistencies in access levels for users performing similar tasks. By adding permissions to groups, we can simplify the way permissions are delivered to large numbers of AWS users and apply permissions based on job role or service function, rather than configuring permissions individually.
Make sure to try and use AWS's predefined policies whenever possible. AWS has taken care of writing very well-designed JSON policies that apply exact access permission levels to resources, which can be used for various applications. Using the built-in policies makes it easier to manage access, as relying on custom policies can bring in difficulties when design and functional changes are needed in the application.
Another best practice is to ensure we are following the least privilege approach when assigning permissions. With the least privilege approach, we only assign the permissions required to complete a certain task. As an additional level of security, we can configure all our users and groups with a fairly basic set of permissions, then allow these users to assume roles that have elevated permissions.
For console and programmatic access, some other best practices should be considered:
- Configuring a strong password policy for your users; this will depend on any compliance or enterprise requirements but it is always a good practice to secure your passwords as much as you can
- Enabling multi-factor authentication for any privileged users
- Rotating credentials on a regular basis
- Removing any unnecessary credentials
- Do not share your access keys with anyone
For applications that run on Amazon EC2 instances and require access to other AWS resources, you should implement role-based access. The instance should have the permission to assume a role that gives it access and once started, that role will allow the application on the instance to securely access the resource without the need for storing credentials inside the application.
Roles can also be used to delegate permissions to users within the same account, to users from others accounts and to users authenticated by external directories. For instance, you can use roles to grant administrative access to your administrators, whose user accounts are initially set with very low permissions such as read-only. Only after they temporarily assume the role do they gain elevated access to the environment. All role assumptions can be monitored and tracked so any kind of unauthorized administrative access can be quickly identified and stopped. A second example is an external auditor, who can be given a cross-account role with read-only permissions in your AWS account. The auditor can simply use their existing user and assume the role to perform any task their role requires them to do.
Lastly, you need to monitor your AWS environment. You can simply implement monitoring of all the actions and API calls inside your AWS account by enabling CloudTrail on your account. The added value of logging all actions within your account is that you are able to have a detailed overview of how your resources are being used, who is doing what, and if any unauthorized actions are being attempted. Also, having a log of all the actions in your AWS account can be invaluable for auditing and compliance purposes. With CloudTrail, you can view, filter, and download the most recent 90 days of your account activity for all management events in supported AWS services free of charge. Since August 2017, AWS CloudTrail has been enabled by default for all customers and will provide visibility into the past seven days of account activity, without the need to configure a trail in the service to get started.