Identity and access management (IAM) is the process of identifying and controlling the access granted to users, devices and services. It is one of the oldest concepts in security, tracing back to the days of keys for castles and secret passwords. The concept of IAM for computers has existed since the 1960s, when the first passwords were used for logging in to the Compatible Time Sharing System at MIT.
As more organizations move into the cloud, IAM becomes increasingly complicated, but companies still need to ensure that people can only access systems and data appropriate for their role.
Cloud providers like Amazon Web Services (AWS) and Microsoft Azure have several options for IAM policies. The following are best practices to consider when using these platforms.
1) Protect the Root User Account
When a cloud account is opened, the first user account is created. The root user has full control over everything within the account, and therefore it should be well protected and not used regularly. If this account is compromised, all corporate resources in the cloud could be deleted, including the account itself.
It is also advisable to create multiple 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.
2) Set Up Multi-Factor Authentication (MFA)
MFA is highly recommended to secure all accounts. MFA requires two different types of authentication from three categories:
- Something you know: passwords, passphrases, PINs, and secret questions
- Something you have: authenticators like Google Authenticator, hardware tokens like RSA tokens and SMS one-time numbers
- Something you are: biometrics such as facial recognition, fingerprints, retina, etc.
For the root user account, use a hardware MFA rather than software.
3) Lock Away User Access Keys
Every time an account is created in AWS, an access key is generated by default. Delete these access keys, especially for the root account, unless you need them for some specific reason. They just add more credentials to protect. If the access key is needed, it should be rotated regularly and never shared.
4) Use Groups to Assign Permissions
Groups are an easier way to grant users access. Imagine 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 nurses.
5) Grant Least Privilege
It is essential that users are granted the lowest level of access possible that still allows them to do their jobs. This is the security concept known as ‘least privilege.’ Too much access can result in compromised data from an account that, because of its level of access, is able to create chaos.
6) Use Customer Managed Policies
A user, group, or role can perform specific actions within the cloud based on the policy it is attached to. Cloud providers have default policies that can greatly simplify the policy process. When creating policies, it is best to use customer-managed policies instead of inline policies because managed policies can be seen and controlled from one place—the console.
7) Use Separation of Duties
For enhanced security, the creation of accounts and policies should be separated between 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 and policy and assign it.
8) Review and Refine Permissions Using Last Accessed Information
Policies and permissions should be reviewed regularly, especially when people leave or change roles. Access the policy summary to see what permissions have been granted from the IAM dashboard. Ensure that the policy is not too permissive, and watch for any policy that grants full access to users, roles, or groups.
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. If you find that permissions are unused, they should be removed.
9) Watch for Users that Can Edit Policy Actions but are Not Authorized
Only certain administrators should create, delete, attach, or edit policies. Review the Permissions tab within a specific user’s account from the IAM console and see if “allow” is associated with any permissions related to policies. If the user should not have that access, edit the policy.
10) Deprovision 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, user accounts that were assigned to employees who have now left the business, changed jobs or joined new projects.
Ideally, it should be part of the standard operating process to remove accounts for users that are leaving the business. The ten best practices listed above will help to find these accounts, so you can ensure your business’s valuable data is secure.
