12 Azure & AWS IAM Security Best Practices Cloud Advocate
What is Identity and Access Management (IAM)?
IAM is one of the core technologies that exists to protect a business, its systems, and data. It is one of the oldest concepts in security, tracing back to the days of keys for castles and secret passwords (think: “open sesame”). The concept of IAM for computers has existed since the 1960s, when the first passwords were used to log in to the Compatible Time Sharing System (CTSS) at Massachusetts Institute of Technology (MIT).
Over the years, IAM systems have fluctuated in difficulty. As more organizations move into the cloud, IAM is becoming increasingly complicated due to additional elements, different term definitions, new and disparate ways to control permissions, and more. For now, you must be careful to ensure that only the appropriate people or systems receive the necessary amount of access to certain systems and data.
Cloud providers like Amazon Web Services® (AWS) and Microsoft® Azure® have the options that customers need to secure their IAM policies, however, the settings are sometimes unintuitive.
Here are the best practices you should consider for your business and its security:
Identification, Authentication, Authorization and Accountability (IAAA)
IAM is the process of identifying and controlling the access that is granted to users and services. At its core is IAAA, which is:
- Identification is a statement of who a user or service claims to be. Most commonly, a user identification (ID) or email address such as Jameel@email.com.
- Authentication is the verification validation of that claim. If the identification of Jameel@email.com is used, the required proof of that claim could be a one-time password from an authenticator that would only be accessible on Jameel’s mobile phone.
- Authorization is the granting of permissions to Jameel such as Read, Write, List, etc. Only grant the level of permissions that she needs to do her job.
- Accountability is keeping an audit log to track the access request and actions, possibly down to the keystroke, that Jameel performs once she is in the system. This audit log holds her accountable for the actions that she takes in the system.
3 stages of identity and access management (IAM):
- Provisioning includes the identification and vetting of the user or system. It is necessary to confirm who the user is so that an appropriate account can be created. It is critical that accounts are set up with only the permissions required for that specific role.
- Maintenance is completed across the lifetime of this account. Changes that occur to the user’s job or project would affect the permissions needed. The account needs to reflect the current access level required. This is often the area that business’ need improvement in.
- De-provisioning is the end of the account lifecycle. Once access is no longer required, the account should be shut down to protect the business and its data.
How to Meet Major Compliance Standards with IAM
Effectively managing IAM throughout the account’s lifecycle is critical to maintain compliance with PCI-DSS, EU GDPR, HIPAA, NIST SP 800-53 Rev. 4, or any additional relevant frameworks or laws for your business. Compliance is not only a legal requirement, it is essential for protecting your business, its systems, and data. Exercise caution—compliance is just a starting point. It is possible that your business actually needs stronger controls in place in order to protect it from hackers.
Provisioning IAM Roles
When a cloud account is opened with a provider such as AWS or Azure, the first user account is created. The root user has full control over everything within the account, and therefore, it should not be used on a regular basis. It is best practice to ensure the account is well protected. If the account is hacked or used inappropriately, all corporate resources in the cloud, including the account itself, could be deleted.
It is also advisable to create multiple AWS accounts for each application stage (Development, Test, Staging, and Production). Multiple AWS accounts can be managed centrally from a dedicated account called the identity account.
The first stage of IAM requires identifying the users and systems that need access to a system or data set within your business’ systems. This is required for all environments, on-premises data centers, or cloud solutions. With a cloud account, there are specific steps to set up IAM policies appropriate for your business.
1 – Create Strong Passwords for IAM Roles
The definition of a strong password is fluid. NIST SP 800-63 Rev. 4 is a national standard for protecting IAM. Conventional knowledge that a password should contain all four options (uppercase, lowercase, symbol, and number) and be regularly changed is no longer best practice. Now, it is recommended to only use two or three of the four possible options. Additionally, NIST recommends that you change the password only when you suspect it has been compromised. Your business should use risk assessment to choose the best password options for optimal security.
Here are some general password tips to consider:
- Create a strong password for the root user account and find a secure mechanism to store it.
- If necessary, you can automate changing the passwords on a regular basis, such as every 45 days.
- Never share your passwords with anyone.
2 – Set Up Multi-Factor Authentication (MFA)
It is highly recommended that you set up MFA to secure all accounts. For the root user account, best practice recommendation is to use a hardware MFA rather than software MFA.
MFA requires two different types of authentication from different factor categories. The three factor categories of authentication are:
- Something you know: passwords, passphrases, PINs, and secret or cognitive questions
- Something you have: authenticators (like Google Authenticator™), hardware tokens (like RSA tokens), SMS one-time numbers, and asymmetric cryptographic public key certificates
- Something you are: biometrics such as facial recognition, fingerprints, retina, etc.
3 – Lock Away Root User Access Keys
Every time an account is created in AWS, an access key is generated by default. It is recommended to delete the access key for the root account, unless you need it for some specific reason. The root user does not usually need an access key, therefore, it further complicates securing the account because it adds more credentials that you must protect.
The same advice applies for all user accounts created. Uncheck the box during the account creation process, and then verify that each account does not have an access key, unless you truly need them.
If the access key is needed for an account, then it should be rotated on a regular basis and never be shared.
4 – Create Individual User Accounts
After creating an administrative account to use rather than the root user account, you can set up accounts for each of the users or machines within your business. When creating user accounts, AWS recommends that you select the option that requires the user to change the password when they first log on. Make sure that you remove any access permissions for the account in case it ends up being unused. This also eliminates the risk of an account being compromised from a malicious log in. To maximize security and efficiency, it is recommended that you grant permissions with groups.
5 – Use Groups to Assign Permissions to Users
Groups are an easier way to grant users the access they need. Imagine you are working in a hospital: Setting up accounts for 200 nurses one at a time with their own specific permissions is a lot of work. It is quicker to first determine what access a nurse requires, create a tag with the necessary permissions, and apply the tag to 200 individuals as nurses to automatically grant them the appropriate access.
Using groups is similar to Role Based Access Control (RBAC), and while AWS does use the term “roles”, it is in a different context. Terms are used in unexpected ways—in AWS, “roles” relates to granting permission to applications or cross-account access.
Within the cloud, the groups you are more likely to create are administrators or developers. There will also be groups for the business users such as accounting, sales, engineers, or even possibly nurses. Try to ensure that the permissions granted to that group are the lowest level that they need.
You should also watch for an orphaned group—a type of group that has no users attached to them. Make sure that unused groups are removed so that unauthorized users can’t be mistakenly or maliciously attached.
6 – Grant Least Privilege
Within each group, it is essential that a user is granted the lowest level of access possible that still allows them to do their job. This is the security concept known as least privilege. It is a straightforward concept, but it is very difficult to achieve. Too much access can result in data being compromised or exfiltrated. This could happen accidentally, maliciously, or it could be a hacker that gains access to that account and, because of its level of access, is able to create chaos.
Best practice is to grant only the bare minimum permissions that this group needs and then add-on from there as necessary. Being too lenient from the beginning and granting a lot of permissions with the intention of slowly locking it down leads to data being compromised. As you add new users to an existing group, they will inherit all of the permissions currently granted to that group. It is likely that at some point a user will have more permissions within a system, application, database, etc., than they should. Most users will not attempt to maliciously hurt a business, but accidents do happen. There are many network administrators who have accidentally deleted a production database, thus, it is necessary to protect the users from similar mistakes.
Permissions, privileges, or policy actions that can be granted are: List, Read, Write, Permissions Management and Tagging. In order to grant permissions, a policy is created and then attached to the group—similar to firewall policy creation. Essentially, a policy is a list of rules.
7 – Use Customer Managed Policies
A user, group, or role can perform specific actions within the cloud based on the policy it is attached to. A policy contains a list of the actions that someone or something is allowed to perform, which are grouped into the categories of List, Read, Write, Permission Management and Tagging. Creating these policies from scratch can be an overwhelming task. The cloud providers have default policies created for your use; AWS calls these managed policies. These default policies may be sufficient for your use, greatly simplifying your work.
At AWS, you can also create your own policies. There are two types of polices: customer managed or inline. When creating policies, it is best to use customer managed policies instead of inline policies, because managed policies (customer or AWS) can be seen and controlled from one place—the console. Once you create a managed policy, you can attach it to as many different AWS resources as you need.
Inline policies are unique to a user, group, or role, and therefore cannot be attached to another resource—they will have to be recreated if you want to use it for a different instance. The more policies you have means more places you have to look to review them, making it harder to manage access at a least privilege level. Use inline policies only as needed—if you already have inline policies, it is possible to convert them to customer managed policies.
8 – Use Separation of Duties
Creation of accounts and policies allows users or services to access what they require from a cloud, network, or environment. For enhanced security, this set of tasks should be separated between different employees. This is known as separation of duties or the two-person rule, which prevents just one person from being able to create a user, group, or policy (and assign it). For this process, oversight is necessary for catching potential mistakes and stopping intentional, malicious attacks. Verifying all activities ensures strong security for your cloud.
In AWS, you can enable IAM Master and IAM Manager to work together to provide IAM users and roles the access to the right permissions. These two roles should be performed by two different employees.
Want to never have to manually check to adherence to the design principles of the well-architected framework again – including IAM best practices? Have your multi-cloud infrastructure configurations scanned for adherence to over 750 industry best practices by signing up for our free trial.
IAM Role Maintenance & Management
Users may change jobs, positions, teams, etc., therefore it is necessary to revise their permissions. This is a cumbersome process to oversee all the users, groups, roles, and policies that grant them permissions. Luckily, there are tools to help this process.
9 – Review IAM Permissions
Policies should be reviewed regularly to ensure that the number of permissions included is at a least-privileged level. You can access the policy summary to see what permissions have been granted from the IAM dashboard. Find the role that you want to review and then click on the Show Policy link. Ensure that the policy is not too permissive, and watch for any policy that grants full access to the users, roles, or groups.
There are also combinations of commands in a policy that, when combined incorrectly, can lead to policies that are too permissive. One of the combinations to watch out for is Effect and Allow with NotAction. The latter allows you to create a shorter policy by restricting what someone can do. Evidently, if combined incorrectly with other commands, the policy could end up allowing too much access.
10 – Refine Permissions Using Last Accessed Information
Another way to determine if a policy has granted too many permissions is to review the last accessed information for a user, group, role, or policy. The last accessed information is in the Access Advisor tab within the IAM console. If you find that permissions are unused, then they should be removed to reduce the policy to a least privilege level. Essentially—if they do not use it, they do not need it.
Similarly, you should watch for users accounts that are unused, as well as groups that have zero users.
11 – Watch for Users that Can Edit Policy Actions, but are Not Authorized
Only certain administrator should create, delete, attach, or edit policies. If a user’s account is assigned those permissions, it is critical to determine if that is appropriate. If it is inappropriate, the permissions should be removed immediately. To determine this, review the Permissions tab within a specific user’s account from the IAM console. Check if “allow” is associated with any permissions related to policies. If the user should not have that access, it is necessary to edit the policy.
12 – View CloudTrail Events to Further Refine Permissions
Logging is a very important security control that needs to be correctly configured so it captures the events that you are worried about, such as CloudTrail data events. It is also necessary to review the log output (in AWS these are the CloudTrails) by looking for unauthorized events and then modifying the policy to reduce the access level to least privilege.
De-provisioning IAM Accounts
When accounts are no longer needed, they should be de-provisioned. This includes the accounts that have never been used and in particular, the user accounts that were assigned to employees who have now left the business, changed jobs, joined new projects, etc. Ideally, it should be part of the standard operating process to remove accounts for users that are leaving the business. Although it is a considerable amount of work, it is critical that it is done. The many best practices listed above will help to find these accounts, so you can ensure your business’ valuable data is secure.
Interested in knowing how well-architected your multi-cloud environment is? Check out the free guided public cloud risk assessment and get your results in just minutes.
Read More HERE
