If you would like to be notified when Ricky & Monique Magalhaes release the next part in this article series please sign up to our InsideAWS.com Real-Time Article Update newsletter.
If you would like to read the first part in this article series please go to AWS Identity and Access Management (Part 1).
Identity and Access Management (IAM) go hand in hand with attaining a secure environment, for AWS this is no different. To secure your AWS cloud, IAM plays a critical role.
In this two-part article we will look at IAM for AWS and best practices to obtain the paramount level of security when utilising AWS.
Introduction
As with all AWS services, Amazon has simplified the approach for enterprise with regards to the simplicity with which the various solutions are implemented within the enterprise.
This critical practice, AWS IAM, has been strategically designed and developed with the Amazon services in mind, ready to be applied with little aggravation removing the challenge of planning, designing, selecting and testing an IAM solution to match the AWS architectures, working across the AWS gamut.
This spread and capability makes the solution very scalable and offers the flexibility that allows for the administrator to mould the access control (as they require) to the services, resources and users that they manage in the AWS cloud.
AWS has streamlined the process immensely; all the arduous work has been done for you and automated. All it takes from you is to be conversant with the solution, gain the experience by using it and follow the best practices to implement the solution with success.
Amazon details some best practices to follow when considering IAM user accounts, AWS Access Keys, roles, groups, permissions, policies, credentials and logs to name a few.
Recommended best practices
- Creating user accounts (sharing and security is not a good idea)
Always create individual accounts for users that require access to the AWS infrastructure or APIs or use IAM federation. It’s important that you do not share your credentials. Through creating individual IAM users for access to the AWS account, each user will have their own credentials and each user can be managed by setting appropriate permissions for each user. If a credential is shared, not only is it difficult to audit (who did what) but if a problem arises and the legal team addresses it, it is difficult to prove the circumstances or with whom the fault lies.
- AWS account Access Keys
Credentials are essential to access AWS resources, without them access will not be possible. A practice that should be avoided is using the AWS account Access Keys to access the resources. These Access Keys should only be utilised in times of emergency otherwise the keys should be securely stowed away, out of reach and out of use.
Ensure the Access Keys are secure by following best practice:
-
- Only create the access keys when needed. Always use an account password for access and create an IAM user with admin privileges instead.
- This access key is a master key and should be treated with care; it’s the root key and should be locked away.
- If the Access Keys have been created you have two options to secure them. Either delete them (if they don’t exist you don’t need to secure them) otherwise make sure that you rotate them regularly. Deletion is the best option to follow.
- Don’t share the AWS account password or access keys.
- Utilise a strong AWS password.
- Use multifactor authentication on the AWS account.
- Use roles or groups to assign permission to IAM users
IAM Groups can be created per job function and users can be assigned to the appropriate group. Permissions are assigned as needed for each group and every IAM user in a particular group will acquire the same permissions as that group.
Not only does RBAC make it easier to manage the access to the resource but it allow allows for simplified mapping of access in future when auditing the access to resources.
- Least privilege approach
It’s advised to always utilise a least privilege approach when setting permissions. Rather allow little access than too much, you can always increase access if required but it is more difficult to manage the situation if a lenient approach is undertaken.
Often more access is allowed when troubleshooting or when creating access to a new service and this escalated access then becomes permanent and forgotten. If the account with escalated access is ignored or forgotten and becomes compromised, the attacker will gain an escalated level of privilege that might result in a high level of access to resources that the attacker typically would not have been able to access under a least privilege approach.
The flip side of the coin is that a user should only have the access required for the user to perform his/her work; more access can lead to temptation or potentially a mistake that could easily have been avoided.
Finding the most suitable set of permissions allowable is often challenging and can take some trial and error to get right. Amazon provides templates with predefined permissions for common functions; this might be a good place to start.
- Passwords
IAM Passwords should be strong and regularly rotated. The organisation can allow users to create and change their own passwords or not. A password policy can also be set on the IAM console for password creation so that password creation requirements can be defined as required.
- Utilise multi-factor authentication for IAM users
Multi-factor authentication ensures further security, especially important for IAM users that access sensitive resources (privileged users). Access requires the combination of users credentials and the multi-factor authentications generated secure code.
In cloud environments this is a key aspect of security. We have all seen the breaches that have occurred recently – where online networks have been compromised and user’s credentials leaked. For this reason it is important that passwords be rotated frequently to avoid this issue. A multifactor and OTP credential is a rotational credential that cannot be captured, as it’s dynamic.
- Use roles for applications that run on EC2 instances
Applications running on Amazon EC2 instance require credentials to access other AWS services. These credentials should be provided to the application securely; this is where using IAM roles come to play. The permissions given to the role governs what the application will be permitted to do.
- Regular rotation of credentials is essential
Set up a policy for your AWS account to ensure all IAM users change their passwords as regularly as you feel necessary to minimise risk. If a password is compromised the regular rotation of passwords will ensure that the compromised password validity is limited.
- Remove credentials not in use
All credentials that are not being used should not subsist. By removing these credentials (passwords, Multifactor authentication devices, access keys etc.) that are not used will reduce your security risk. If they are not being used they are of no use to the organisation and only increasing the organisations security risk. It’s essential to monitor credentials (you can generate a credential report for all IAM users for your account) and remove the unnecessary ones on a regular basis.
- Keep logs/history of AWS account activity
Amazon provides logging features in AWS services. By investigating these logs regularly you can keep on top of access to resources and quickly realise unsatisfactory permissions or gaps where improvement can be made.
- Utilise policy conditions
By defining policies through setting up conditions for allowable access to resources, will ensure that resources remain secure. Although somewhat challenging, the more unambiguous the conditions surrounding allowable access or denied access will ensure better resource control and ultimate security.
Conclusion
AWS provides an IAM solution with a set of capabilities that successfully support the AWS services and have the maturity and skill-set to ensure the solution remains current and well suited.
The labour intensive work has been done for you but to ensure the solution runs as it should and with success, be mindful of the suggested best practices.
If you would like to be notified when Ricky & Monique Magalhaes release the next part in this article series please sign up to our InsideAWS.com Real-Time Article Update newsletter.
If you would like to read the first part in this article series please go to AWS Identity and Access Management (Part 1).
