The Fundamental Security Concepts in AWS - Part 2
The Fundamental Security Concepts in AWS - Part 2
Summarizing the remaining three pillars of AWS security: Infrastructure Protection, Data Protection, and Incident Response.
Join the DZone community and get the full member experience.Join For Free
Two weeks ago, I presented the first of a three-part examination of security concepts and controls in AWS. We looked at the key security principle of AWS: AWS is responsible for the security of the cloud; you are responsible for security in the cloud. See Figure 1.
Many people and organizations are surprised at how much responsibility for security in AWS falls to them. I believe that AWS got it exactly right with this.
Imagine for a moment that AWS decided that it was responsible for the security of all data that it stores, uses, or transmits across its network and that AWS required you or your organization to delegate all of your data security to an AWS security black-box. That would not make me feel all warm and fuzzy. In fact, I would not trust a third party to secure the critical data assets of my organization. As you saw in Part 1 of this series, and as you'll see in Part 2 as well, AWS provides a wide range of compliance, monitoring, and encryption services that enable any organization to secure its critical data assets in the cloud. I would argue that I am able to secure data in AWS more simply and more thoroughly than I can with on-premises data.
In Part 1, we looked at two of the five security pillars in AWS - IAM and Detective Controls. Today, we'll finish this off by summarizing the remaining three pillars: Infrastructure Protection. We'll finish this off in part three by looking at protection of data-at-rest, data-in-transit, Data Protection, and Incident Response.
AWS breaks Infrastructure Protection down into three broad categories:
Protecting network and host-level boundaries.
System security configuration and maintenance.
Enforcing service-level protection.
Protecting Network and Host-Level Boundaries
Amazon Virtual Private Cloud (Amazon VPC) allows you to define your network topology that spans an AWS Region with a private IP address range you determine.
Within a VPC, you can create subnets in one or more Availability Zones. Each subnet has an associated route table that defines routing rules for managing the paths that traffic within the subnet takes. You can define a publicly routable subnet by having a route that goes to an internet gateway, a NAT Gateway, or a Customer Gateway attached to the VPC. The absence of a route to the internet gateway prevents instances from being directly reachable.
A subnet can also have an NACL (Network Access Control List) attached to it. Unlike Security groups, which allow outbound traffic by default, you can configure NACL’s to limit both inbound and outbound traffic. Last, AWS has implemented the concept of VPC gateways. A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with other resources. In addition, traffic between your VPC and the other service or resource does not leave the Amazon network.
When a host is launched within a VPC, it normally adopts the security group of the VPC. Security groups act like one-way stateful firewalls. Moreover, you can also define relationships between security groups. For example, instances within a database tier security group can be configured to only accept traffic from instances within a related specific application tier.
Security Groups for EC2-VPC
When you launch an instance in a VPC, you must specify a security group that's created for the VPC. Security groups for EC2-VPC have additional capabilities that aren't supported by security groups for EC2-Classic (Hint: EC2 classic is going away soon, hopefully).
After you launch an instance in a VPC, you can change the security groups that affect it. Security groups are associated with network interfaces. Changing an instance's security groups changes the security groups associated with the primary network interface (eth0). You can also change the security groups associated with any other primary or secondary network interface.
Your VPC can be enabled for IPv6 (IPv6 is not enabled by default). If it is enabled, you can add rules to your VPC security groups to enable inbound and outbound IPv6 traffic as well. To my mind, correct security group configuration is the most important element in securing your EC2 instances.
VPC Security Components
Security Group Rules
The rules of a security group control the inbound traffic that's allowed to reach the instances that are associated with the security group and the outbound traffic that's allowed to leave them.
The following are the characteristics of security group rules:
- By default, security groups allow all outbound traffic.
- You can't change the outbound rules for an EC2-Classic security group.
- Security group rules are always permissive; you can't create rules that deny access.
- Security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. For VPC security groups, this also means that all responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules (unless prohibited by a NACL).
- You can add and remove rules at any time. Your changes are automatically applied to the instances associated with the security group almost immediately after you initiate the change.
System Security Configuration and Maintenance
AWS Systems Manager allows you to centralize operational data from multiple AWS services and automate tasks across your AWS resources. You can create logical groups of resources such as applications, different layers of an application stack, or production versus development environments. Systems Manager provides a central place to view and manage your AWS resources, so you can have complete visibility and control over your operations.
AWS Systems Manager
Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. Amazon Inspector automatically assesses applications for vulnerabilities or deviations from best practices. After performing an assessment, Amazon Inspector produces a detailed list of security findings prioritized by level of severity. These findings can be reviewed directly or as part of detailed assessment reports which are available via the Amazon Inspector console or API.
AWS Systems Manager Patch Manager
AWS Systems Manager Patch Manager automates the process of patching managed instances with security-related updates. For Linux-based instances, you can also install patches for non-security updates. You can patch fleets of Amazon EC2 instances or your on-premises servers and virtual machines (VMs) by operating system type. This includes supported versions of Windows, Ubuntu Server, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), and Amazon Linux. You can scan instances to see only a report of missing patches, or you can scan and automatically install all missing patches.
Enforcing Service-Level Protection
You can protect AWS service endpoints by defining policies using IAM. See Part 1 of this series for information on IAM. IAM can help you define policies for access to services and operations. However, for some services, you can also define fine-grained controls to specific resources within those services. Additionally, some resources have their own resource-level policies.
For example, Amazon S3 has bucket policies to define access levels to objects and/or entire buckets, and AWS KMS has policies to define administrators and users of the keys in AWS KMS. Use IAM and resource policies to define a robust protection scheme for your resources.
AWS Key Management Service (KMS)
AWS Key Management Service (KMS) is a managed service that makes it easy for you to create and control the encryption keys used to encrypt your data and uses FIPS 140-2 validated hardware security modules to protect the security of your keys. AWS Key Management Service is integrated with most other AWS services to help you protect the data you store with these services. AWS Key Management Service is also integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs.
In AWS, there are a number of different approaches to consider when addressing data protection. They are:
- Data classification.
- Protecting data at rest.
- Protecting data in transit.
- Data backup/replication/recovery.
Data classification provides a way to categorize organizational data based on levels of sensitivity. This includes understanding what data types are available, where the data is located, and access levels and protection of the data (for example, through encryption access control). By carefully managing an appropriate data classification system along with each tier’s protection requirements, you can map the controls and level of access/protection appropriate to the data. For example, public-facing content is available for anyone to access, whereas critical content is encrypted and stored in a protected manner.
Understanding and using resource tags is often ignored by AWS users but they are a simple and powerful method of organizing your AWS assets. My number one recommendation to new users of AWS is:
***Take advantage of Resource Tagging***
Tags enable you to categorize your AWS resources in different ways, for example, by purpose, owner, cost center, or environment. Each tag consists of a key and an optional value, both of which you define.
AWS recommends that you devise a set of tag keys that meets your needs for each resource type. Using a consistent set of tag keys makes it easier for you to manage your resources. You can search and filter the resources based on the tags you add.
The following diagram illustrates how tagging works. Tags are simply key:value pairs. In this example, you've assigned two tags to each of your instances, one called Owner and another called Stack. Each of the tags also has an associated value.
Tags don't have any semantic meaning and are interpreted strictly as a string of characters. Also, tags are not automatically assigned to your resources. You can edit tag keys and values, and you can remove tags from a resource at any time. If you add a tag that has the same key as an existing tag on that resource, the new value overwrites the old value. If you delete a resource, any tags for the resource are also deleted.
Besides resource tags, the primary data classification tools offered by AWS are:
Amazon Macie is a security service that uses machine learning to automatically discover, classify, and protect sensitive data in AWS. Macie recognizes sensitive data such as personally identifiable information (PII) or intellectual property and provides you with dashboards and alerts that give visibility into how this data is being accessed or moved. Amazon Macie continuously monitors data access activity for anomalies and delivers alerts when it detects the risk of unauthorized access or inadvertent data leaks.
Three other tools that are useful for aggregating and monitoring resources have already been mentioned. These are AWS Systems Manager, AWS Config, and Service Manager.
Data protection refers to protecting data while in-transit (as it travels to and from Amazon S3) and at rest (while it is stored on disk in Amazon S3).
AWS uses a dual key approach to encrypting most data: Customer Master Keys (CMKs) and Data Keys (DKs). A high-level diagram is shown below.
Customer Master Keys
The primary resources in AWS KMS are customer master keys (CMKs). You can use a CMK to encrypt and decrypt up to 4 kilobytes (4096 bytes) of data at a time. Typically, you use CMKs to generate, encrypt, and decrypt the data keys that you use outside of AWS KMS to encrypt your data.
AWS KMS stores, tracks, and protects your CMKs. When you want to use a CMK, you access it through AWS KMS. CMKs never leave AWS KMS unencrypted. This strategy differs from data keys that AWS KMS returns to you, optionally in plaintext. AWS KMS does not store, manage, or track your data keys.
There are two types of CMKs in AWS accounts:
- Customer-managed CMKs are CMKs that you create, manage, and use.
- AWS managed CMKs are CMKs in your account that are created, managed, and used on your behalf by an AWS service that is integrated with AWS KMS.
Data keys are encryption keys that you can use to encrypt data, including large amounts of data and other data encryption keys. You can use your AWS KMS CMKs to generate, encrypt, and decrypt data keys, but AWS KMS does not store, manage, or track your data keys, and AWS KMS cannot use a data key to encrypt data for you. You must use and manage data keys inside your application.
AWS KMS uses envelope encryption to protect data. Envelope encryption is the practice of encrypting plaintext data with a unique data key, and then encrypting the data key with a key encryption key (KEK).
The key AWS service that supports encryption is AWS KMS, which provides an easy-to-use, secure, and redundant key management service. The following service is also important:
- AWS CloudHSM provides a hardware security module for managing keys.
AWS Key Management Service (KMS): AWS KMS allows you to centrally manage and securely store your keys. You can generate keys in AWS KMS or import them from your key management infrastructure. These keys can be used from within your applications and supported AWS services to protect your data, but the key never leaves AWS KMS. You set usage policies on these keys that determine which users can use them to encrypt and decrypt data. All requests to use these keys are logged in AWS CloudTrail so you can understand who used which key when.
AWS CloudHSM is a cloud-based hardware security module (HSM) that enables you to easily generate and use your own encryption keys on the AWS Cloud. With CloudHSM, you can manage your own encryption keys using FIPS 140-2 Level 3 validated HSMs.
That's all for today. Tune back in tomorrow when we'll discuss securing data at rest, data in transit, and more!
Opinions expressed by DZone contributors are their own.