The Fundamental Security Concepts in AWS - Part 1

The Shared Responsibility Model

When you begin working in AWS, the most important security (and, to a certain point, operational) principle that you must understand is who is responsible for what. Who is accountable for patching the OS? Who is responsible for encrypting data-at-rest? Who is accountable for application security? Who is liable for regulatory compliance? As it turns out, you are -- for all of these.

Under the AWS shared responsibility model, AWS provides a global secure infrastructure and foundation compute, storage, networking and database services. Essentially, everything up to and including the hypervisor is the responsibility of AWS. You, the client, are responsible for protecting the confidentiality, integrity, and availability of your data in the cloud, and for meeting specific business and compliance requirements.  

The shared responsibility model for infrastructure services, such as Amazon Elastic Compute Cloud (Amazon EC2), for example, specifies that AWS manages the security of the following assets:

• Facilities

• Physical security of hardware

• Network infrastructure

• Virtualization infrastructure

In the case of Amazon EC2, for example, you as the customer are responsible for the security of the following assets:

• Operating systems

• Applications

• Data in transit

• Data at rest

• Data stores

• Credentials

• Policies and configuration

Securing your environment in AWS can be complicated simply because of the large number of native security controls that AWS provides, and because of the interactions between many of these controls. The diagram below is one visualization of the number and types of AWS security controls and their relationships.

Mind Map of AWS Monitoring Solutions. Courtesy of Andreas Wittig.

In order to simplify this, we have broken this down into five security pillars. We chose to present these concepts in this manner because it naturally mimics the five pillars that define the AWS Well-Architected Framework.

The Five Major AWS Security Pillars

IAM

IAM is all about Identity:

• Users
• Groups
• Roles
• Policies

This section describes IAM identities, which you create to provide authentication for people and processes in your AWS account. This section also describes IAM groups, which are collections of IAM users that you can manage as a unit. Roles are usually temporary and service-specific. Roles can be authenticated and then authorized to perform specific actions in AWS. Each of these entities can be associated with one or more policies to determine what actions a user, role, or member of a group can do with which AWS resources and under what conditions. 

All of this can be very complicated and it is easy to do incorrectly.

The AWS Account Root User

When you create your first AWS account, you create an account (or root user) identity, which you use to sign in to AWS. Note that when you create your first AWS account, you will need to provide a credit card even though individuals who use AWS as a test environment often don't accrue any costs. You first sign in to the AWS Management Console as the root user using the email address and password that you provide when you create the account. This combination of your email address and password defines your root user credentials.

When you sign in as the root user, you have complete, unrestricted access to all resources in your AWS account, including access to your billing information and the ability to change your password. This level of access is necessary when you initially set up the account. However, AWS recommends that you don't use root user credentials for everyday access. It is not possible to restrict the permissions that are granted to the AWS root account. Instead, AWS strongly recommends that you adhere to the best practice of using the root user only to create your first IAM user and then securely locking away the root user credentials. 

An additional best practice – both for Root accounts and for IAM users is to use two-factor authentication (2FA). 2FA should always be used for AWS authentication. A common solution is to use the virtual 2FA application, Authy. Authy is free, TOTP compliant, easy to configure, and works on both iOS and Android smartphones.

IAM Users

An IAM user is an entity that you create in AWS. The IAM user usually represents a person but can also refer to a service who uses the IAM user account to interact with AWS. A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API. A user in AWS consists of a name, a password to sign into the AWS Management Console, and up to two access keys that can be used with the API. When you create an IAM user, it makes sense to grant that account permissions by making it a member of the appropriate group that has appropriate permission policies attached. You can also clone the permissions of an existing IAM user, which automatically makes the new user a member of the same groups and attaches all the same policies.

IAM Groups

An IAM group is a collection of IAM users. The AWS concept of a group is a familiar one -- similar to groups in AD or UNIX. You can use groups to specify permissions for a collection of users, which can make those permissions easier to manage. For example, you could have a group called Admins and give that group all of the permissions that administrators typically need. Any user in that group automatically has the permissions that are assigned to the group. If a person changes jobs in your organization, instead of editing that user's permissions, you can remove him or her from the old groups and add him or her to the appropriate new groups. Note that a group is not truly an identity because it cannot be identified as a Principal in a resource-based or trust policy (more on policies later). Groups are the means to attach policies to multiple users at one time.

IAM Roles

IAM roles are typically the hardest IAM concept for new users to grasp. An IAM role is similar to a user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone or any service that needs it.

Also, a role does not have standard long-term credentials (password or access keys) associated with it. Instead, if a user or service assumes a role, temporary security credentials are created dynamically and provided to the user. An IAM user can assume a role to temporarily take on different permissions for a specific task. A role can be assigned to a federated user who signs in by using an external identity provider such as Facebook or Google. AWS uses details passed by the identity provider to determine which role is mapped to the federated user.

Applications that run on an Amazon EC2 instance need credentials in order to access other AWS services. To provide credentials to the application in a secure way, use IAM roles. A role is an entity that has its own set of permissions but isn't a user or group. Roles also don't have their own permanent set of credentials the way IAM users do. In the case of Amazon EC2, IAM dynamically provides temporary credentials to the EC2 instance to, for example, access an S3 bucket, and these credentials are automatically rotated for you.

Temporary Credentials

Temporary credentials are primarily used by IAM roles, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This prevents you from accidentally performing tasks that are not permitted by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid.

IAM Policies

A policy is a JSON document in AWS that, when attached to an identity or resource, defines their permissions. AWS evaluates these policies when a principal, such as a user or a role, makes a request. Permissions in the policies determine whether the request is allowed or denied. Policies are stored in AWS as JSON documents attached to principals as identity-based policies, or to resources as resource-based policies. AWS provides hundreds of “canned” policies that support common scenarios.

The difficulty with policies isn't really the concept or the anatomy. Instead, it's the overwhelming number of possible actions, principals, resources, and conditions that we can insert into them. Additionally, the "context" of the policies (i.e. using them on an S3 bucket vs. an IAM user) also changes what can be inserted into them.

A good practice is to begin with the end in mind. Literally ask yourself and team: Who is allowed to do what to which resources at what times. List those answers out in a pseudo code and then search for a canned AWS policy or create a policy that fulfills those requirements.

Testing IAM Policies With the IAM Policy Simulator

The IAM Policy Simulator is available at: https://policysim.aws.amazon.com/home/index.jsp?#

Note that you must be logged into your AWS account to access the simulator.

With the IAM policy simulator, you can test and troubleshoot IAM and resource-based policies in a number of ways.

Detective Controls 

Monitor Everything in Your AWS Account

You can use logging features in AWS to determine the actions users have taken in your account and the resources that were used. The log files show the time and date of actions, the source IP for an action, which actions failed due to inadequate permissions, and more.

These are some of the keylogging features available in AWS. Others will be discussed in subsequent sections.

• Amazon CloudWatch – Arguably the most important monitoring solution in AWS, CloudWatch monitors your AWS Cloud resources and the applications you run on AWS. You can set alarms in CloudWatch based on metrics or thresholds that you define that you define.

Sample CloudWatch Console Screenshot

• AWS CloudTrail logs every AWS API call and related events made by or on behalf of an AWS account. 

• Amazon CloudFront logs user requests that CloudFront receives. Moreover, CloudFront provides mechanisms for secure distribution data and monitoring of those data flows. 

• AWS Config provides detailed historical information about the configuration of your AWS resources, including your IAM users, groups, roles, and policies. For example, you can use AWS Config to determine the permissions that belonged to a user or group at a specific time.

• AWS Service Catalog allows IT administrators to create, manage, monitor, and distribute portfolios of approved products to end users, who can then access the products they need in a personalized portal. Typical products include servers, databases, websites, or applications that are deployed using AWS resources (for example, an Amazon EC2 instance or an Amazon RDS database). You can control which users have access to specific products to enforce compliance with organizational business standards and to manage product lifecycles.

• AWS Trusted Advisor AWS Premium Support plans include access to the Trusted Advisor tool, which offers a one-view snapshot of your service and helps identify common security misconfigurations, suggestions for improving system performance, and underutilized resources.

• Amazon GuardDuty uses integrated threat intelligence such as lists of known malicious IP addresses, anomaly detection, and machine learning to identify activity associated with threats, such as compromised EC2 instances mining Bitcoin or an attacker scanning your web servers for known application vulnerabilities. It also monitors AWS account access behavior for signs of compromise, such as detecting an atypical instance type deployed by a user from an unusual geo-location, or an attempt to disable CloudTrail logging or to snapshot a database from a suspicious IP address.

Conclusion

AWS is a good partner. They take care of their responsibilities and expect you to do the same. To this end, AWS offers a staggering number of tools and services to support their clients' security efforts. 

Having strong authentication and authorization controls and automating responses to security events is clearly the future of security controls. In part two, I'll discuss the other three AWS security pillars that describe how you can protect infrastructure at multiple levels, protect data, both at rest and in transit, manage and classify data with resource tags and encryption, and how to automate incident response.