A recent report indicates that the cloud market was valued at $148 billion in 2016 with expected annual growth rate at 25%. Statistics, provided by RightScale, show that 31% of enterprises are running more than 1000 VMs in private cloud and 17% of enterprises are having more than 1000 VMs in public cloud. Given such massively sophisticated infrastructures, it’s crucial to design your cloud infrastructure efficiently. In the meantime, Amazon continues to dominate the cloud market with almost one-third of the market share. So, we will be focusing on the infrastructure of Amazon Web Services (AWS). There are some tools that can be exploited to help designing efficient scalable AWS infrastructure. This article aims to discuss various considerations with access control management in AWS infrastructure. The weakest link in an enterprise is the people who administer and exploit the resources. Thus, it’s important to learn the best practices in securing such activities/information from hacker hands and allow for the scalability of organization infrastructure.
Let’s start with discussing authentication. Authentication is a key corner in access control management. It is required by most credible security and compliance standards such as NIST, ISO and HIPPA. In AWS, the access is granted based on least privileges and this access is audited via SOC-2 audit on 24/7 basis. While planning for AWS authentication, it’s critical to consider user-based and group-based security policies. AWS opens the doors for managed, inline or custom policies written in JSON format (Details of security policies are beyond the scope of this article). For such users and groups, it’s always recommended to have password-policy that defines the criteria of strong passwords that should be used. Also, make sure to think through authorization levels from user, group and resource perspectives while developing the security policies.
AWS supports six different authentication options. These options can be bundled or used individually:
- Email Address and Password: this is the root-user account for the person who first creates the AWS account for the organization.
- Multi-Factor Authentication (MFA): AWS supports MFA in which you will get a code on your registered phone number, for example, to confirm your identity.
- Access Keys: can be used to provide third-party access or implement oauth-2 like mechanisms. This is important for automating processes. Please note that AWS limits the number of access keys to two.
- Key Pairs: AWS supports public-key cryptography which allow for multiple users to have similar credentials. You can have a maximum of two key-pairs. AWS supports CloudFront Key pairs and X.509 certificates. (X.509 certificates are digital certificates that use the X.509 public key infrastructure standard to associate a public key with an identity contained in a certificate).
- IAM Usernames: Root user creates different user accounts for the users in the organization who are supposed to use different AWS services. These users will have controlled-customized access to resources.
Figure 1.0 shows a screenshot of “Security Credentials” page from Console login to AWS. Blue arrows refer to the different authentication options that can be configured. Although AWS provides console login for users, you should be wise in making the proper decision in selecting the authentication mechanism. For example, key pairs might be suitable to provide access to multiple users with similar credentials. However, if access keys were poorly designed, you might end up with unauthorized users consuming the organization’s AWS services once they get access to these keys. In AWS, user and authentication related items are managed through Identity and Access Management (IAM). If you are not familiar with IAM, think about active directory in an organization. IAM is an improved version of active directory to manage users, groups, roles, policies and various account settings in AWS.
Figure 1.0 Authentication Options in AWS
That is all about user accounts, but what about the root-level account?! Amazon refers to the first AWS account that gets created for the organization on AWS as “Root Account”. This account has full access to all account resources; it can neither be disabled nor controlled via IAM. Please, remember that this account should NOT be used for daily operation. Login information for the root account should be stored in an encrypted format in a “safe” place. This place should have MFA mechanism applied to it. AWS supports Google Authenticator for virtual devices and Gemalto for hardware devices.
Due to the cost of maintaining stored login information for the root-level account, some experts recommend that you don’t have to store this login information!!! SMEs suggest that you can create an IAM role with full admin privileges and change the root account password to something you won’t remember (e.g. random string). Once you change the password, don’t save the new password and use a forget-password link to gain access to the root account if needed. Typically, you should NOT use the root account unless you need to change the root account info, change billing info, buying new AWS items, testing AWS’ public IP address, or close AWS account. Moreover, there are various security-related activities that can be done on the root account. These activities are monitored via the account dashboard. Ideally, the security status on the dashboard should show 5/5 completed activities. Figure 2.0 shows the dashboard of IAM for a Root-level account. Please note that you may not need MFA mechanism if you are going to change the account password to a random string.
Figure 2.0 IAM Dashboard Page for Root Level Account
Once the root account is properly configured, you should start thinking about creating user accounts. Generally, it’s recommended to have an account for each environment for your applications (e.g. development, test, and production). Furthermore, you may need additional accounts for more granular security or specific needs (No worries, you can enable cross-account access to use resources shared by other accounts). Keep in mind that the more accounts you have, the better granularity of user account security but also the higher complexity user management becomes. If you encounter unexpected high bills, you can enable consolidated billings on your accounts to monitor the billing activity of each account separately.
One way to think about designing multiple user accounts is to consider these accounts from governance perspective in which you have a trusting account (provider) and a trusted account (consumer). Trusting accounts should have higher privileges to support the creation of Virtual Private Clouds (VPCs), Network Access Control Lists (NACLs), Subnets, consumer accounts, IAM, managed services, Virtual Private Networks, security groups and EC2 instances. On the other hand, the trusted account will only focus on the resources that can be consumed (e.g. EC2 Resources, database resources (RDS) or Elastic Boxes).
AWS makes it easy for you to apply the provider/consumer concept by providing the ability to create Roles, Groups and Users through IAM. During the creation of the new role, you will have the option to define the security policy(ies) that can control this role. Similarly, groups and users can be configured. Figure 3.0 shows the five steps that are needed to create a new customized role.
Figure 3.0 IAM Create Role Page
There are various approaches to access resources supported by AWS. These approaches can be categorized into administrative (AWS management console and Command Line Interface), APIs and Managed Services. Details on these items are beyond the scope of this article, but it’s important to note that these tools do not monitor all resource access control metadata. Information related to Relational Database Server logon or EC2 instance logon is not captured. Such information can be monitored via OS-based monitoring or logging.
While creating roles, users and groups, think about your password management strategy. Password management is a vital element of secure infrastructure. You will need to consider aspects like minimum password length, password reuse, complexity rules, password expiration and expiration procedure. AWS supports the use of various tools to collect statistics on password metadata. These tools include IAM console, AWS CloudTrail, Credential Report, Access Advisor, Simple Notification Service (SNS) and CloudWatch (Details on these tools are beyond the scope of this article). The rule of thumb is that if you are at the console, you need a password. If you are consuming an API or using CLI, you need access keys.
Figure 4.0 summarizes best practices needed to be considered for designing scalable IAM accounts. Please, notice the density of rows originated from Roles and Groups. It’s expected that policies are applied at a more generic level so they can be easily maintained. Users are not expected to have special permissions except in extreme scenarios where one user has ultimate special needs that are not shared by other users.
Figure 4.0 Best Practices in Designing AWS IAM Accounts for Organization
Finally, we can summarize the best practices that we’ve discussed in this article in the following bullet points:
- Individual Users:
Always start by granting least-privileges.
- Enable Credential Rotation per user.
Use unique Credentials for each User.
Manage Permissions through Roles and Groups.
- Conditional Access:
Restrict Database creation to be limited to specific engine.
Restrict access from specific IP address/range.
Enable CloudTrail to log API calls activities.
Log calls to S3 bucket associated with your account.
- Strong Password:
Use password tools.
Consider Password Strength Metrics.
- Credential Rotations:
Rotate your passwords on fixed schedule.
Use Credential Report to identify credentials should be rotated.
Note that EC2 instances rotate credentials for IAM roles by default.
Enable MFA for all users.
Use IAM roles to share access. (Use IAM roles for EC2 instances).
Sources of Provided Statistics
About the Author
Mohamed Farag has been in the IT industry for 7 years out of which 4 years were spent in business consulting. Mohamed is Salesforce Certified Platform Developer, Certified SAFe 4.0 Agilist, Certified IBM Mobile Application Developer and Certified Microsoft Technology Specialist. On part-time basis, Mohamed pursues his PhD in the field of Systems Engineering at George Washington University.