![](\"https:\/\/www.trendmicro.com\/content\/dam\/trendmicro\/global\/en\/devops\/21\/b\/12-azure-aws-security-best-practices.jpg\")
<\/p>\n<\/p>\n
<\/div>\nWhat is Identity and Access Management (IAM)?<\/span><\/p>\n 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: \u201copen sesame\u201d). 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).<\/p>\n 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.<\/p>\n Cloud providers like Amazon Web Services\u00ae<\/sup><\/a> (AWS) and Microsoft\u00ae<\/sup> Azure\u00ae<\/sup><\/a> have the options that customers need to secure their IAM policies, however, the settings are sometimes unintuitive.<\/p>\n Here are the best practices you should consider for your business and its security:<\/p>\n Identification, Authentication, Authorization and Accountability (IAAA)<\/span><\/p>\n IAM is the process of identifying and controlling the access that is granted to users and services. At its core is IAAA, which is:<\/p>\n 3 stages of identity and access management (IAM):<\/b><\/p>\n How to Meet Major Compliance Standards with IAM Provisioning IAM Roles<\/span><\/p>\n 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.<\/p>\n 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<\/a> from a dedicated account called the identity account.<\/p>\n The first stage of IAM requires identifying the users and systems that need access to a system or data set within your business\u2019 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.<\/p>\n 1 \u2013 Create Strong Passwords for IAM Roles<\/span><\/p>\n 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.<\/p>\n Here are some general password tips to consider:<\/p>\n 2 \u2013 Set Up Multi-Factor Authentication (MFA)<\/span><\/p>\n 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<\/a> rather than software MFA.<\/p>\n MFA requires two different types of authentication from different factor categories. The three factor categories of authentication are:<\/p>\n 3 \u2013 Lock Away Root User Access Keys<\/span><\/p>\n 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.<\/p>\n 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<\/a>, unless you truly need them.<\/p>\n If the access key is needed for an account, then it should be rotated on a regular basis<\/a> and never be shared.<\/p>\n 4 \u2013 Create Individual User Accounts<\/span><\/p>\n 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.<\/p>\n 5 \u2013 Use Groups to Assign Permissions to Users<\/span><\/p>\n 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.<\/p>\n Using groups is similar to Role Based Access Control (RBAC), and while AWS does use the term \u201croles\u201d, it is in a different context. Terms are used in unexpected ways\u2014in AWS, \u201croles\u201d relates to granting permission to applications or cross-account access.<\/p>\n 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.<\/p>\n You should also watch for an orphaned group\u2014a type of group that has no users attached to them. Make sure that unused groups<\/a> are removed so that unauthorized users can\u2019t be mistakenly or maliciously attached.<\/p>\n 6 \u2013 Grant Least Privilege<\/span><\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2014similar to firewall policy creation. Essentially, a policy is a list of rules.<\/p>\n 7 \u2013 Use Customer Managed Policies<\/span><\/p>\n 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<\/a>. These default policies may be sufficient for your use, greatly simplifying your work.<\/p>\n 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<\/a>, because managed policies (customer or AWS) can be seen and controlled from one place\u2014the console. Once you create a managed policy, you can attach it to as many different AWS resources as you need.<\/p>\n Inline policies are unique to a user, group, or role, and therefore cannot be attached to another resource\u2014they 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\u2014if you already have inline policies, it is possible to convert them to customer managed policies<\/a>.<\/p>\n 8 \u2013 Use Separation of Duties<\/span><\/p>\n 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.<\/p>\n In AWS, you can enable IAM Master and IAM Manager<\/a> 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.<\/p>\n Want to never have to manually check to adherence to the design principles of the well-architected framework again \u2013 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.<\/p>\n IAM Role Maintenance & Management<\/span><\/p>\n 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.<\/p>\n 9 \u2013 Review IAM Permissions<\/span><\/p>\n 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<\/a>, and watch for any policy that grants full access<\/a> to the users, roles, or groups.<\/p>\n 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<\/a>.<\/p>\n 10 \u2013 Refine Permissions Using Last Accessed Information<\/span><\/p>\n 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\u2014if they do not use it, they do not need it.<\/p>\n Similarly, you should watch for users accounts that are unused<\/a>, as well as groups that have zero users<\/a>.<\/p>\n 11 \u2013 Watch for Users that Can Edit Policy Actions, but are Not Authorized<\/span><\/p>\n Only certain administrator should create, delete, attach, or edit policies. If a user\u2019s 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<\/a> within a specific user’s account from the IAM console. Check if \u201callow\u201d is associated with any permissions related to policies. If the user should not have that access, it is necessary to edit the policy.<\/p>\n 12 \u2013 View CloudTrail Events to Further Refine Permissions<\/span><\/p>\n Logging is a very important security control that needs to be correctly configured<\/a> so it captures the events that you are worried about, such as CloudTrail data events<\/a>. It is also necessary to review the log output (in AWS these are the CloudTrails<\/a>) by looking for unauthorized events and then modifying the policy to reduce the access level to least privilege.<\/p>\n De-provisioning IAM Accounts<\/span><\/p>\n 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\u2019 valuable data is secure.<\/p>\n Interested in knowing how well-architected your multi-cloud environment is? Check out the free guided public cloud risk assessment<\/a> and get your results in just minutes.<\/p>\n\n
\n
<\/b>Effectively managing IAM throughout the account\u2019s 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\u2014compliance is just a starting point. It is possible that your business actually needs stronger controls in place in order to protect it from hackers.<\/p>\n\n
\n