This chapter is from the book
This chapter is from the book
This chapter is from the book
Access Controls
AWS solutions must provide secure access by clients and providers of the technologies. This is accomplished using a robust set of technologies.
Infrastructure Security
Amazon provides security capabilities and services to increase privacy and control network access. These include the following:
Network firewalls built into Virtual Private Cloud (VPC), and web application firewall capabilities in AWS WAF, let you create private networks and control access to your instances and applications.
Encryption in transit with TLS across all services.
Connectivity options that enable private, or dedicated, connections from your office or on-premises environment.
Identity and Access Management
IAM is a cloud service that helps you securely control access to AWS resources. You use IAM to control who is authenticated and authorized to use resources.
Upon AWS account creation, you begin with a single sign-in that has complete access to all AWS services in the account. This sign-in is called the AWS account root user. You access AWS with the account by signing in with the email address and password you used at sign-up.
Amazon strongly recommends that you do not use the root account for your everyday tasks, even the administrative ones. Instead, follow the best practice of using the root account only to create your first IAM user. Then securely lock away the root account credentials and use them to perform only a few account and service management tasks.
IAM permits extremely fine-grained permissions. For example, you might grant someone read access to only a single bucket of objects in S3. Or you might use IAM to control specific calls (GetObject) against a single object stored in S3. Perhaps you examine a particular time/date range or the source IP address of the call.
Other features of IAM include the following:
Access from service to resource in AWS: For example, you can have an application running on an EC2 instance access an S3 bucket. As you will learn later in this chapter, we often use roles for such access.
Multi-factor authentication (MFA): Permitting access through a password and a code from an approved device, thus strengthening security greatly. Figure 5-4 shows the configuration area for MFA in the IAM Management Console.
FIGURE 5-4 Configuring MFA for an Account
Identity federation: Users who have already authenticated with another service can gain temporary access to resources and services in your account.
Identity information for assurance: CloudTrail can trace and log all API activity against every service and resource in your account. Figure 5-5 shows the CloudTrail Dashboard in AWS.
FIGURE 5-5 The CloudTrail Dashboard
PCI DSS compliance: IAM supports the processing, storage, and transmission of credit card data by a merchant or service provider, and it has been validated as being compliant with the Payment Card Industry (PCI) Data Security Standard (DSS).
Integration: IAM integrates with every major service of AWS.
Eventually consistent: Amazon replicates important data around the world with their Global Infrastructure to help ensure high availability (HA). As a result, data in some locations might lag others. Therefore, with IAM, consider implementing your changes for IAM first, and then verify full replication before working with dependent service deployments.
Always free: Whereas some services of AWS can be used for one year free (using the Free Tier account), IAM services remain free for the life of your account.
Accessibility options: You can access the components of IAM in a variety of ways, including the AWS Management Console, AWS command-line tools, AWS SDKs, and IAM HTTPS API.
)
)
It is critical that you understand the main identities you’ll use in IAM. Realize that there is much more to IAM than these identities, but at this point in your AWS education, we are covering the main foundational components.
Remember, an account that supersedes the IAM service is root. As stated earlier in this chapter, this account should rarely be used.
Identities in IAM consist of the following:
Users: These are the entities you create in AWS to represent the people or services that use the IAM user to interact with AWS. When you create an IAM user, you grant it permissions by making it a member of a group. You assign appropriate permission policies to the group. This is the recommended approach from Amazon. Note that you could directly attaching policies to the user, but this is not recommended because it is not a scalable approach and could make security management more difficult. You can also clone the permissions of an existing IAM user. This approach automatically makes the new user a member of the same groups and attaches all the same policies. Figure 5-6 shows a user in AWS.
FIGURE 5-6 A User in AWS IAM
Groups: A collection of IAM users. You can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users.
Roles: These are similar to user accounts, but they do not have credentials (password or access keys) associated with them.
)
In the following steps, we create a group that provides full access to S3 in AWS and then create a user, adding it to this group:
Step 1. Navigate to the AWS Management Console and then search for the IAM service.
Step 2. Select Groups in the left navigation pane. Figure 5-7 shows the Groups console.
FIGURE 5-7 Groups in IAM
Step 3. Click the Create New Group button.
Step 4. Set the Group Name and click Next Step.
Step 5. In the Attach Policy page (shown in Figure 5-8), enter S3 in the Filter option.
FIGURE 5-8 The Attach Policy Page
Step 6. Check AmazonS3FullAccess and click Next Step.
Step 7. Review the configuration and click Create Group.
Step 8. Click the Users option in the left navigation pane.
Step 9. Click the Add User button.
Step 10. Provide the username and then allow both types of access to the accounts. Leave the defaults in place regarding the password. Figure 5-9 shows this page.
FIGURE 5-9 Naming the User Account
Step 11. Click Next: Permissions.
Step 12. Add the user to the group you created earlier in these steps. Click Next: Tags.
Step 13. Click Next: Review. Remember, adding tags is an excellent idea to indicate various identifiers, but here in a lab environment, we will just skip it.
Step 14. Review your settings and click Create User.
)
)
)
Best Practices with IAM
While IAM in AWS provides many exciting capabilities, its complexity can cause organizations to make fatal flaws when working with the service. This is why following best practices is critical.
You should consider following most (if not all) of these recommendations.
Care of the root account: The root account for your AWS implementation should be used infrequently. The current best practice is to delete any access keys associated with root. Root should never have automation keys. You should never automate against root, and the only reason to have keys is for automation. Root should have only a login (email address and password) and physical MFA. Physical MFA is the best practice because you do not want a single person with root access on the phone; it should be a separate hardware device locked up and not used except in an emergency. As you no doubt realize, MFA for root on a phone, which could be lost, could be obtained easily. Some companies have one team manage the password for root, while another team manages the physical MFA device. This ensures checks and balances to gain access to root. Exceptions to these best practices may be in the case of organizations where new AWS accounts are managed via automation.
Create individual IAM users: Because you do not want to use root for your AWS implementation, it is critical that you create additional users. This would include for yourself so that you are not required to use root. In larger organizations, you will have a large team working on AWS. You must create multiple users for your staff to ensure that everyone is authenticating and being authorized for only those resources and permissions that are required for members to do their jobs. You will most likely have one user in IAM for every person who requires administrative access.
Use groups to assign permissions to IAM users: Even though it might seem silly, if you are the sole administrator of your AWS implementation, you will want to create a group and assign permissions to this group. Why? If you do need to grow and hire another administrator, you can just add that user account to the group you created. We always want our AWS implementations to scale, and using groups helps ensure this. It should also be noted that applying permissions to groups instead of individual user accounts will help eliminate assignment errors, as we are minimizing the number of permissions we must grant.
Use AWS-defined policies for permissions: Amazon was very kind to us. They defined a ton of policies we can easily leverage when working with IAM. What’s more, AWS maintains and updates these policies as they introduce new services and API operations. The policies that AWS created for us are defined around the most common tasks we need to perform. These make up an excellent starting place for your own policies. You can copy a given policy and customize it to make it even more secure. Oftentimes, you will find the default defined policies are too broad with access.
Grant least privilege: Create the IAM user identity for your AWS user that provides the least privileges they require. That way, if an attacker does manage to capture security credentials and begins acting as that user in the AWS architecture, he can do a limited amount of damage.
Review IAM permissions: You should not use a “set and forget” policy when it comes to your permissions in IAM. You should consistently review the permissions level assigned to ensure that you are following least privilege concepts and that you are still granting those permissions to the groups that require them. There is even a policy summary option within IAM to facilitate this.
Always configure a strong password policy for your users: It is a sad fact of human nature: Your users will tend to be lazy about setting (and changing) their passwords. They will tend to use simple passwords that are easy for them to remember. Unfortunately, these simple passwords are also easy to crack. Help your security by setting a strong password policy that your users must adhere to. Figure 5-10 shows the configuration of a password policy for user accounts in the IAM Management Console.
FIGURE 5-10 Configuring a Password Policy
Enable multi-factor authentication for privileged user accounts: Of course, you do this for the seldom-used AWS root account, but you should also protect key admin accounts you have created in AWS. Using multi-factor authentication (MFA) ensures the user knows something (like a password) and also possesses something (like a smartphone). With most AWS environments today, MFA is considered mandatory.
Use roles: You should consider the use of roles in AWS when you have applications or services running on EC2 instances that need to access other services or resources.
Use roles to delegate permissions: Roles can also prove valuable when you need to permit one AWS account to access resources in another AWS account. This is a much more secure option to providing the other AWS account with username and password information for your account. And remember, the use of roles is always recommended within an AWS account.
Do not share access keys: It might be tempting to take the access keys that permit programmatic access to a service or resource and just share those with another account that needs the same access. Resist this temptation. Remember, you can always create a role that encompasses the required access.
Rotate credentials: Be sure to change passwords and access keys regularly in AWS. The reason for this, of course, is the fact that if these credentials are compromised, you will have minimized the damage that can be done when the stolen credentials no longer function. Roles rotate credentials automatically for you many times per day. This is a huge security advantage and makes their use desirable, especially at scale.
Remove unnecessary credentials: Because it is so easy to learn and test new features in AWS, it can get messy as far as IAM components you leave in place that are no longer needed are concerned. Be sure to routinely audit your resources for any “droppings” that are no longer needed. AWS even assists in this regard with structuring reports around credentials that have not been recently used. Again, roles provide another built-in advantage in this regard.
Use policy conditions: Always consider building conditions into your security policies. For example, access might have to come from a select range of IP addresses, or MFA might be required.
Monitor, monitor, monitor: AWS services provide the option for an intense amount of logging. Here are just some of the services where careful logging and analysis can dramatically improve security:
CloudFront
CloudTrail
CloudWatch
AWS Config
S3
)
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 8, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.