Security and Compliance
Date: Dec 29, 2019
In this sample chapter from AWS Certified SysOps Administrator - Associate (SOA-C01) Cert Guide, take a deep dive into the Shared Responsibility Model, security best practices, and available access controls to help secure cloud-based solutions.
This chapter covers the following subjects:
The Shared Responsibility Model: This section of the chapter describes the AWS Shared Responsibility Model in great detail. It also provides examples of AWS security responsibilities as well as those of the client (you).
Security Policies in AWS: This section of the chapter describes the use of powerful security policies and other security best practices in AWS.
Access Controls: This final part of the chapter details many of the powerful access controls that exist in AWS for you to use in order to help secure your cloud-based solutions.
It is amazing just how many engineers are often scared to move to the cloud due to security reasons. In all actuality, there are many reasons to move there that might encourage a more secure infrastructure. Just think, because Amazon can afford the latest in physical security measures at their data centers, you will enjoy a level of physical security that might not be possible in your own enterprise environment.
This chapter focuses on important security topics you should know and know well for AWS. This includes a look at the Shared Responsibility Model as well as an exploration of key security policies and access controls available to you.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess if you should read the entire chapter. Table 5-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A.
Table 5-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundations Topics Section |
Questions |
The Shared Responsibility Model |
1–2 |
Security Policies in AWS |
3–4 |
Access Controls |
5–6 |
1. Who is responsible for creating users, groups, and roles in IAM for use in an AWS architecture?
The AWS customer
AWS staff
The managed service provider
There are no users, roles, or groups in IAM
2. Who is responsible for securing the hypervisor in use in AWS?
AWS staff
The client of AWS
The managed service provider
There is no hypervisor in use in AWS
3. You would like to add DDoS protection against your EC2 instances and your Elastic Load Balancing services. What service should you use?
AWS CloudIPS
AWS Shield Advanced
AWS Cognito
AWS Shield Standard
4. What credentials would you require in order to submit a penetration testing request?
AWSFullAdmin
Root account
AWSIAMAdmin
AWS Region Admin
5. What is the IAM component that is often ideal for allowing EC2 instances to other AWS services and resources?
Groups
Users
Clusters
Roles
6. When creating a user account in AWS IAM, what are the options for access type? (Choose two.)
AWS Management Console access
Restore
Programmatic access
CLI only
Foundation Topics
The Shared Responsibility Model
The AWS Shared Responsibility Model is very simple. It divides the security responsibilities between two parties—the AWS customer (you) and Amazon (AWS). The fact that you are no longer responsible for a massive portion of the security required for scalable data centers is a huge advantage. You can leverage the massive budgets of Amazon and their intense expertise.
The next two sections of this chapter provide many examples of responsibilities in each part of the model. But for now, realize the Amazon responsibilities include the host operating system and virtualization layer down. From there, Amazon is also responsible for the physical security of the facilities in which the service operates. It is your (the customer’s) responsibility to secure the guest operating system (including updates and security patches), application software, and the AWS network security group firewall. Be aware that the client responsibilities will vary depending on which services the client chooses to use. The client responsibilities further vary based on the level of integration of AWS services consumed and their IT infrastructure. Laws and regulations that must be followed will also vary.
As shown in Figure 5-1, AWS is considered “Security of the Cloud”, and the customer’s responsibility is considered “Security in the Cloud.”
FIGURE 5-1 The AWS Shared Responsibility Model
In addition to partitioning the operational security concerns between the AWS client and AWS themselves, the Shared Responsibility Model applies to IT controls that are in use. Amazon categorizes these controls into three categories:
Inherited controls: These are security controls that the customer fully inherits from AWS. Perfect examples are the physical and environmental security controls used by Amazon.
Shared controls: These refer to controls that apply to both the infrastructure layer of Amazon and the customer responsibilities. Note that these shared controls apply to each domain in completely separate contexts or perspectives. For example, AWS provides the requirements (through controls) for the infrastructure. Then clients provide their own control implementation within their use of the services. Consider Identity and Access Management (IAM). The IAM service must be secured, meet regulatory compliance, and function as intended, while the customer should create well-crafted policies.
Customer-specific controls: These are security controls that the customer is solely responsible for. This varies based on the services they selected, of course. A great example would be when you apply specific patches to one of your operating systems on an EC2 instance.
Amazon Responsibilities
Remember, Amazon is considered responsible for security of the cloud. This means that AWS is responsible for protecting the infrastructure that runs the services that customers select. This encompasses the hardware and software required to power the AWS service, including the networking and facilities used.
Specific Amazon responsibilities would include the following:
Cloud software, including compute, storage, networking, and database software
Hardware
AWS Global Infrastructure (Regions, Availability Zones, Edge Locations)
Client Responsibilities
Remember, we consider the client responsible for security in the cloud. The specific services selected will cause variations in the client responsibilities. For example, if you are relying heavily on S3 for storage, you will be responsible for knowledge and proper configuration of the security permissions for your resources. Another example would be if the client chooses to use EC2 and run an operating system like Windows Server 2016. The client will be required to keep the operating system updated and patched. The client is also responsible for the application software required on this guest operating system. In addition, the client is responsible for the appropriate security group configuration for the EC2 instance.
Specific examples of client responsibilities would include the following:
Customer data
Platform, applications, Identity and Access Management (IAM)
Guest operating systems
Network and firewall configurations
Client-side data encryption
Server-side encryption (file system and or data)
Networking traffic protection (encryption, integrity, and identity)
Figure 5-2 shows an example of a customer checking the security groups settings that would apply to an EC2 instance. This is a perfect example of client responsibilities. AWS is responsible for making sure the security group functions as intended, but it is the client’s responsibility to configure it correctly.
FIGURE 5-2 Checking the Security Groups Settings for an EC2 Instance
Security Policies in AWS
There are common security policies and practices that you should be aware of when operating AWS solutions. This section of the chapter covers some of the more important ones.
DDoS Mitigation
The distributed denial of service (DDoS) attack is one to be feared. Famous examples of this attack include stories about how huge chunks of the entire Internet itself were made unavailable for relatively long periods of time. Just like with a regular old denial of service (DoS) attack, the goal is resource exhaustion so that disruption is in place for legitimate traffic that is attempting to flow or access a service or resource. Having many systems (potentially) participate in the attack (DDoS) can make the attack that much more effective due to the increase in frequency of the communications.
It is worth restating for clarity—there are two main and related objectives behind DDoS (and DoS):
Exhaust resources on the server side of the computing model.
Once exhaustion occurs, disrupt desired traffic flows or requests.
We often use the Open Systems Interconnection (OSI) model in order to help us think about and mitigate DDoS attacks. Figure 5-3 shows the OSI model.
FIGURE 5-3 The OSI Model
DDoS attacks that tend to focus on the lower layers (1 through 4) of the OSI model are often called infrastructure attacks, whereas upper layers that come under attack are referred to as application-layer attacks. An example of a Layer 4 attack might be a SYN flood or an amplified UDP reflection attack. An attack at Layer 7 (Application) might be an HTTP flood.
Let’s examine one of these in more detail. In an amplified UDP reflection attack, the attacker uses the connectionless UDP protocol to ask a server for some piece of information. The attacker forges the packet header so that it contains a different sender address. The machine that receives these “spoofed” packets will send a response back to the forged source address.
ICMP, NTP, DNS, DHCP, TFTP, and many more are all examples of UDP services that, if left unchecked, can be abused. Depending on the command sent and data requested, the amplification ratio can range from 2× to over 200×. This is to say that the attacker sends a small request to the vulnerable server, and the server sends a much larger response to the target system.
Fortunately, AWS knows of these many potentially devastating DDoS attacks and includes some powerful protections for us for free, as well as ensures these protections are in an always-on state.
AWS Shield Standard
If you are using the AWS services of Route 53 (DNS) and CloudFront (CDN), you are already taking advantage of the free DDoS prevention methods of AWS Shield Standard. AWS engages in powerful protection methods for these services that include powerful network flow monitoring as well as protection mechanisms against Layer 3 and Layer 4 attacks. For example, the amplified UDP reflection attack described previously should be blocked thanks to the default behaviors of AWS Shield Standard.
AWS Shield Advanced
While it is not free like the AWS Shield Standard’s functionality, you might be compelled to take advantage of the more advanced version, AWS Shield Advanced. This is most commonly acquired through an Enterprise-level support agreement with AWS.
As you might guess, AWS Shield Advanced has the ability to protect a wider range of services than the standard version can. Here are some of the services that are provided protection by the suite of features:
EC2
Elastic Load Balancing
Elastic IP Addressing
CloudFront
Route 53
AWS Global Accelerator
Not only do you enjoy a wider range of services that are protected, your features expand as well, including the following:
Advanced analysis
Resource baselining and trending
Protection against Application (Layer 7) attacks
AWS DDoS Response Team (DRT)
DDoS Cost Protection
Real-time Threat Dashboard access
As if this was not enough, if you use AWS Shield Advanced to protect your EC2 instances, during an attack AWS Shield Advanced automatically deploys your VPC network ACLs to the border of the AWS network. This allows the security suite to provide protection against larger DDoS events.
Data Encryption
It is well known that encrypting your data at rest is often necessary to obtain the level of security you require. Fortunately, AWS not only supports this, but provides many tools to allow you a variety of protections in a variety of configurations. Data encryption capabilities include the following:
Data encryption capabilities available in AWS storage and database services, such as EBS, S3, Glacier, Oracle RDS, SQL Server RDS, and Redshift
Flexible key management options, including AWS Key Management Service; allowing you to choose whether to have AWS manage the encryption keys or to have you keep complete control over your keys
Encrypted message queues for the transmission of sensitive data using serverside encryption (SSE) for Amazon SQS
Dedicated, hardware-based cryptographic key storage using AWS CloudHSM, allowing you to satisfy compliance requirements
In addition, AWS provides APIs for you to integrate encryption and data protection with any of the services you develop or deploy. For more information on data encryption, see Chapter 4, “Storage and Data Management.”
Inventory and Configuration
One of the legitimate concerns when moving to a cloud service like AWS is the flexibility and ease of resource creation getting out of hand. You can have inventory and the configuration of devices become unmanageable. AWS has tools such as the following to assist with this potential problem:
Amazon Inspector is a security assessment service that automatically checks applications for vulnerabilities or deviations from best practices. This inspection includes impacted networks, OS, and attached storage.
Deployment tools to manage the creation and decommissioning of AWS resources according to organization standards.
Inventory and configuration management tools, including AWS Config, that identify AWS resources and then track and manage changes to those resources over time.
Template definition and management tools, including AWS CloudFormation to create standard, preconfigured environments; for more information on CloudFormation, see Chapter 7, “Automation and Optimization.”
Monitoring and Logging
“Track everything” is the war cry for many AWS engineers with concerns about cloud security. AWS provides tools for monitoring and logging that include the following:
Deep visibility into API calls through CloudTrail, including details on the calls themselves
Log aggregation options, streamlining investigations, and compliance reporting
Alert notifications through CloudWatch when specific events occur or thresholds are exceeded
Consistent use of these tools can improve the security posture, and reduce the risk profile, of your AWS solutions.
Penetration Testing
In order to perform penetration testing to or originating from any AWS resources, you must complete a request form to obtain permissions from Amazon.
There are several important things to note about penetration testing requests. As previously mentioned, there have been modifications to some of these parameters, but your exam might not reflect the current changes:
To request permission, you must be logged in to the AWS portal using the root credentials associated with the instances you wish to test; otherwise, the form will not pre-populate correctly. If you have hired a third party to conduct your testing, Amazon suggests that you complete the form and then notify your third party when approvals are granted.
You are only permitted testing of EC2 and RDS instances that you own. Tests against any other AWS services or AWS-owned resources are prohibited.
Amazon does not permit testing small or micro RDS instance types; testing of m1.small or t1.micro EC2 instance types is not permitted.
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.
Review All Key Topics
Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 5-2 lists these key topics and the page numbers on which each is found.
Table 5-2 Key Topics for Chapter 5
Key Topic Element |
Description |
Page Number |
Overview |
The AWS Shared Responsibility Model |
132 |
List |
Amazon responsibilities |
133 |
List |
Client responsibilities |
134 |
Overview |
AWS Shield Standard and AWS Shield Advanced |
137 |
Overview |
Inventory and Configuration |
139 |
Overview |
Penetration Testing |
140 |
List |
AWS IAM identities |
144 |
Steps |
Creating users and groups in IAM |
145 |
List |
IAM best practices |
148 |
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
The AWS Shared Responsibility Model
Security of the Cloud
Security in the Cloud
DDoS
AWS Shield
AWS Account Root User
IAM Users
IAM Groups
IAM Roles
Q&A
The answers to these questions appear in Appendix A. For more practice with exam format questions, use the Pearson Test Prep Software Online.
1. Provide at least three examples each for client and AWS responsibilities in the Shared Security Model.
2. Name two services protected by AWS Shield Standard.
3. What service would you use to log API calls in AWS?