Determining Appropriate Data Security Controls

By Mark Wilkins

Date: Jul 3, 2023

Return to the article

This chapter covers the following topics:

• Data Access and Governance

• Amazon EBS Encryption

• Amazon S3 Bucket Security

• AWS Key Management Service

• AWS Certificate Manager

This chapter covers content that’s important to the following exam domain and task statement:

Domain 1: Design Secure Architectures

Task Statement 3: Determine appropriate data security controls

Organizations have workloads and associated cloud services fail while operating at AWS. Amazon Elastic Compute Cloud (EC2) instances fail, Amazon Elastic Block Store (EBS) volumes crash, and cloud services can stop working. However, you shouldn’t have go to your boss and announce, “We’ve lost some data.” Fortunately, all data can be securely and redundantly stored at AWS.

All data stored at AWS using any storage service can be encrypted; organizations make the decision about whether encryption is required. However, Amazon S3 objects and S3 Glacier archive storage is automatically encrypted at rest. All other storage services at AWS store data records in an unencrypted state to start. For example, Amazon S3 buckets are encrypted using server-side encryption using Amazon S3, the AWS Key Management Service (KMS) with customer master keys (CMK) and data keys, or encryption keys supplied by each organization. Amazon EBS volumes—both boot and data volumes—can be encrypted at rest and in transit using CMKs provided by AWS KMS. Shared storage services such as Amazon EFS and Amazon FSx for Windows File Server can also be encrypted at rest, as can Amazon DynamoDB tables, Amazon Relational Database Service (RDS) deployments, and Amazon Simple Queue Service (SQS) queues.

AWS does not have single-tenant persistent data storage for individual organizations; all storage services offered at AWS are multi-tenant by design. AWS has the responsibility to ensure that each organization’s stored data records are isolated to the AWS account in which they are first created. Organizations can secure data at rest by choosing to encrypt all data records; protecting data in transit can be achieved using Transport Layer Security (TLS).

Each organization is in control of the storage and retrieval of its data records that are stored at AWS. It’s the organization’s responsibility to define the security and accessibility of all data records stored at AWS. All data storage at AWS starts as private storage only accessible across the AWS private network. Organizations can choose to make select Amazon S3 buckets public, but all other storage services offered by AWS remain private and are not publicly accessible across the Internet. AWS VPN and AWS Direct Connect connections from on-premises locations can directly access AWS storage services; however, EBS volumes can only be accessed through the attached EC2 instance. Figure 5-1 illustrates the options for data encryption at AWS that are discussed in this chapter.

“Do I Know This Already?”

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 5-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A Sections.”

Table 5-1 “Do I Know This Already?” Section-to-Question Mapping

1. What AWS service assists in protecting access to AWS?

1. AWS Shield

2. Amazon Macie

3. Amazon EBS volumes

4. Amazon DynamoDB databases

2. What is the purpose of using detective controls?

1. To enable and enforce multifactor access

2. To detect and alert when security controls change

3. To manage AWS Organizations backups

4. To analyze compliance levels

3. Which of the following determines whether an attached Amazon EBS volume can be encrypted?

1. The type of Amazon EC2 instance

2. The size of the Amazon EBS volume

3. The type of the Amazon EBS volume

4. The IOPS assigned to the Amazon EBS volume

4. Where are data keys stored when they are delivered to an Amazon EC2 instance for safekeeping?

1. The associated Amazon EBS volume

2. Unsecured RAM

3. Secured RAM

4. AWS Key Management Service

5. What security policy allows multiple AWS accounts to access the same Amazon S3 bucket?

1. Amazon IAM policy

2. AWS IAM server control policy

3. Amazon S3 Bucket policy

4. Amazon IAM policy

6. What type of encryption can be carried out before uploading objects to Amazon S3 to ensure absolute encryption outside AWS control?

1. RSA encryption

2. AES 128-bit encryption

3. Client-side encryption

4. Server-side encryption

7. What is the advantage of importing your organization’s symmetric keys into AWS KMS?

1. High level of compliance

2. Faster encryption and decryption

3. Absolute control of encryption keys

4. None

8. What additional AWS service can work with AWS KMS as a custom key store?

1. Encrypted EBS volume

2. Encrypted Amazon S3 bucket

3. AWS CloudHSM

4. Encrypted AWS SQS queue

9. How does AWS charge for provisioning SSL/TLS certificates for AWS services using AWS Certificate Manager?

1. It charges per certificate per year.

2. It charges for private TLS certificates only.

3. It does not charge for AWS services.

4. It charges per certificate check.

10. Where are the security certificates for the AWS Application Load Balancer stored?

1. Amazon S3 bucket

2. Amazon EBS volume

3. AWS Certificate Manager

4. AWS KMS service

Foundation Topics

Data Access and Governance

Many on-premises and AWS-hosted workloads store their associated data records in the AWS cloud. Personal data stored in the public cloud is sometimes defined as personally identifiable information (PII). Sensitive data types, such as PII, must be protected to comply with privacy regulations such as the General Data Protection Regulation (GDPR), laws such as the Health Insurance Portability and Accountability Act (HIPAA), and industry standards such as the Payment Card Industry Data Security Standard (PCI DSS). More than 13 billion data records have been stolen since 2013, according to the 2022 Thales Data Threat Report (https://cpl.thalesgroup.com/data-threat-report). AWS Artifact, located in the AWS Management console, provides on-demand access to all current AWS compliance and security reports, including Service Organization Control (SOC) and Payment Card Industry (PCI) reports and certifications from accreditation bodies validating the implementation and operating effectiveness of AWS security controls (see Figure 5-2).

Data Retention and Classification

When classifying data, it’s important for each organization to implement data retention policies for each class of stored data. Organizations should design security policies using security zones for all data records, and data classification requirements based on how data is stored and who has access to it (see Figure 5-3). Defined security zones for data records range from highly protected to publicly accessible.

Security zones are typically used to segregate different types of organizational data assets based on their sensitivity or importance, with the most sensitive or valuable data being placed in the highest security zone. This segregation enables organizations to implement different levels of security controls and access restrictions based on the sensitivity of the data, ensuring that only authorized users with the appropriate level of clearance can access and view sensitive data records.

Additionally, the creation of relevant security zones can help organizations prevent the spread of security breaches by limiting the potential impact to a specific area of the organization. Organizations also should create a network perimeter with defined network flow and access policies for data records defining where and how data can be accessed. Defense-in-depth security at AWS is applied using infrastructure security controls, AWS IAM security policies, and AWS detective controls (see Figure 5-4).

Infrastructure Security

Infrastructure security requires deploying the following protections:

• DDoS Protection: Amazon deploys AWS WAF and Shield to protect the AWS cloud from DDoS attacks.

• Network isolation: EC2 instances must be hosted in a virtual private cloud (VPC). Many AWS services can be accessed from a VPC with private VPC endpoints (Interface and Gateway endpoints), ensuring workload traffic remains on the private AWS network.

• Application-layer threat protection: The AWS Web Application Firewall (WAF) allows organizations to create rules and filters to accept or reject incoming requests to Amazon CloudFront distributions, Amazon API Gateway deployments, and Application Load Balancers, and HTTP/HTTPS traffic to web servers.

• Security groups: Security groups must be designed to allow ingress traffic from associated security groups.

• Network ACL: Design network ACLs to implement zone-based models for your workload (web/app servers/database), allowing only legitimate traffic to reach each subnet.

IAM Controls

AWS Identity and Access Management (IAM) policies are useful for controlling access to the data layer (database, queue, AWS EBS volumes, shared data [AWS EFS and AWS FSx for Windows File Server], and Amazon S3 storage) and managing IAM user and federated user activity and infrastructure security. Separate administrative tasks should be created for Amazon RDS with IAM policies (see Example 5-1) that control access to database data records. For authentication and authorization to any workload or organizational data records, enable multifactor authentication (MFA) for all administrators and end users.

Example 5-1 Administrative Access to Amazon RDS

"Version": "2012-10-17",
    "Statement": [
        {
            "Sid": " Controlled Admin Tasks",
            "Effect": "Allow",
            "Action": [
                "rds:CreateDBSnapshot",
                "rds:StopDBInstance",
                "rds:StartDBInstance"
            ],
            "Resource": [
                "arn:aws:rds:[AWS_region]:[_AWS_account_
id]:snapshot:*",
                "arn:aws:rds:[AWS_region]:[_AWS_account_
id]:db:demoDB"
            ]
        },
        {
            "Sid": "DescribeInstances",
            "Effect": "Allow",
            "Action": "rds:DescribeDBInstances",
            "Resource": "*"
        }
    ]
}

Detective Controls

Detective controls are a type of security control designed to detect and alert when potential security incidents or breaches occcur. Detective controls typically are used with preventive and corrective controls forming a comprehensive security strategy. Examples of detective controls at AWS include intrusion detection systems, and auditing or logging systems that monitor user activity and alert on suspicious behavior. The goal of detective controls is to identify potential security threats or vulnerabilities before they can cause harm, allowing organizations to take appropriate action to prevent or mitigate the impact of a security incident.

Detective controls are an important part of a defense-in-depth security strategy as they provide an additional layer of protection by detecting and responding to potential security threats. Detective controls at AWS include the following security services:

• VPC Flow Logs: A feature of Amazon VPC that monitors network traffic at the elastic network interface, subnet, or entire VPC. Captured network traffic can be used for troubleshooting connectivity issues and to check current network access rules.

• AWS CloudTrail: Continuously monitor and record API usage and user activity across AWS infrastructure.

• AWS CloudWatch: Monitors AWS cloud services such as Amazon RDS databases, EC2 instances, and DynamoDB tables and hosted applications by collecting and tracking metric data, application and operating system log files, and using automated responses to defined alarms.

• Amazon GuardDuty: Provides continuous threat detection and analysis of VPC Flow Logs, Amazon Route 53 DNS query logs, and AWS CloudTrail S3 data event logs, and protecting AWS accounts and data stored in Amazon S3 from malicious activity. AWS GuardDuty malware protection can help detect malicious files stored on EBS volumes, protecting attached EC2 instances and Amazon Elastic Kubernetes Service (EKS) clusters.

• AWS Config: Detects configuration changes in RDS AWS infrastructure including Amazon RDS, EC2 instances, VPC and database architecture, including security groups, database instances, snapshots, and subnet groups.

• Amazon Macie: Uses machine learning and pattern matching to protect Amazon S3 objects and sensitive data types.

• Access Analyzer for S3: Monitors Amazon S3 buckets and details public or cross-account access.

• Amazon Detective: Graphically analyzes AWS CloudTrail management events, VPC Flow Logs, AWS GuardDuty findings, and Amazon EKS audit logs to help identify the cause of potential security issues.

Amazon EBS Encryption

Amazon Elastic Block Storage (EBS) volumes provide persistent block-level storage volumes for EC2 instances. They can be used to store a wide variety of data, including operating system files, application data, and database records. EBS volumes are automatically replicated within their availability zone to protect against data loss due to failure, and support a range of performance levels and storage options to meet the needs of different workloads.

Amazon Elastic Block Store (EBS) provides the option to encrypt EBS volumes to protect the data records. Encrypting EBS volumes ensures that the data cannot be read or accessed by unauthorized parties, even if the underlying storage volume is compromised. Encryption is performed using a customer master key and data key managed by the AWS Key Management Service (KMS), which provides a secure and auditable encryption service for managing data encryption at AWS using encryption keys. EBS volumes can be encrypted when first created, or volumes can be encrypted after they have been created. EBS also provides the option to encrypt snapshots of EBS volumes, enabling you to create encrypted backups of your EBS volumes.

Both EBS boot and data volumes can be encrypted. Most EC2 instances support EBS volumes’ encryption, including the C4, I2, I3, M3, M4, R3, and R4 families. AWS has made the encryption process incredibly easy to deploy; when creating an EBS volume, merely checking off the option to enable encryption starts the encryption process (see Figure 5-5), which is managed by AWS Key Management Service (KMS). More details on AWS KMS are provided throughout this chapter.

The CMK protects all the other keys issued for data encryption and decryption of your EBS volumes within your AWS account. All AWS KMS-issued CMKs are protected using envelope encryption, which means AWS is responsible for creating and wrapping the “envelope” that contains the CMKs of the respective AWS account. Envelope encryption encrypts the plaintext data with a data key, and then encrypts the data key using a key that is managed by the AWS Key Management Service (KMS). KMS keys are created inside AWS KMS and never leave AWS KMS unencrypted. AWS cryptographic tools and services support the Advanced Encryption Standard (AES) with 128-, 192-, or 256-bit keys. AES is combined with Galois/Counter Mode (GCM), which provides high-performance symmetric key operation using a block size of 128 bits and is used by AWS KMS. AES and GCM are documented as AES-GCM.

After enabling your customer key using KMS for your AWS account, for additional security, it’s a good idea to add another key administrator and to allow key rotation of your Customer Master Keys. Administrators can use the KMS master key provided to create additional AWS KMS administrators, and to optionally enable key rotation of the CMK (see Figure 5-6).

To encrypt an EBS volume using the AWS Key Management Service, a CMK can be created by AWS and stored in AWS KMS. Optionally, organizations can choose to specify the key material for the CMK, which can be generated by KMS or imported from your own key management infrastructure. After a CMK has been created, you can create an encrypted EBS volume using the EC2 dashboard and specifying the ID of the CMK when creating the volume (see Figure 5-7). The EBS volume will be encrypted using the specified CMK, and the data on the EBS volume will be encrypted at rest on the underlying storage.

When you attach the encrypted EBS volume to an EC2 instance, the instance will automatically download and install the necessary encryption and decryption components, including the appropriate version of the AWS Encryption SDK and the public key portion of the CMK. The instance will then use the CMK to encrypt and decrypt data as it is written to and read from the EBS volume. The private key portion of the CMK remains securely stored in AWS KMS, and is never made available to the EC2 instance.

When an EBS volume has been encrypted and attached to an EC2 instance, the following data types are encrypted:

• Data at rest inside the EBS volume

• All data that moves between the attached EBS volume and the EC2 instance

• All snapshots created from the EBS volume

• All volumes created from the encrypted snapshots

AWS KMS performs the following steps, as illustrated in Figure 5-8, to encrypt and decrypt the EBS volume:

Step 1. AWS EBS sends a request to KMS, specifying the CMK to use for the AWS EBS volume encryption.

Step 2. AWS KMS generates a new data key, encrypts it using the specified CMK, and sends the encrypted key to AWS EBS to be stored with the volume metadata.

Step 3. The Amazon EC2 service sends a decrypt request to KMS.

Step 4. EBS sends a request to KMS to decrypt the data key.

Step 5. KMS uses the CMK to decrypt the encrypted data key and sends the decrypted key to the EC2 service.

Step 6. EC2 stores the plaintext decrypted key in protected hypervisor memory on the bare-metal server where the EC2 instance is hosted and uses the key when required to perform decryption for the EBS volume.

Amazon S3 Bucket Security

By default, only the owner who created an S3 bucket has access to the objects stored in the bucket. There are several methods for controlling security for an S3 bucket (see Figure 5-9):

• ACLs: You can use access control lists (ACLs) to control primary access from other AWS accounts for list and write objects and read and write bucket permissions, public access, and access to S3 logging information. ACLs are available for purposes of backward compatibility and are the weakest type of S3 security (and therefore not recommended).

  Figure 5-9 S3 Permission Settings

• IAM policy: You can grant access to other AWS users and groups of IAM users by using IAM permission policies in partnership with resource policies.

• S3 Bucket policy: You can control direct access to an S3 bucket, as shown in Example 5-2, by creating a bucket policy assigned directly to the S3 bucket. An S3 bucket policy is a JSON-formatted document that defines which actions are allowed or denied on an S3 bucket and its contents. A bucket policy is attached directly to the bucket it is protecting, and the policy settings list who has access to the bucket and what they can do with the objects in the bucket. An S3 bucket policy might allow a specific IAM user to read and write objects in the bucket, while denying access to all other users. Or, the policy might allow any user to read objects in the bucket but allow only authenticated users to write objects.

  S3 bucket policies are defined using the AWS Policy Language, which provides a set of keywords and operations that you can use to specify the conditions under which a policy takes effect. A bucket policy can also allow access from multiple AWS accounts to a single S3 bucket.

Example 5-2 S3 Bucket Policy

{
  "Version": "2012-10-17",
  "Id": "S3PolicyId1",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
                     "arn:aws:s3:::2021232reports",
         "arn:aws:s3:::2021232reports/*"
      ],
      "Condition": {
          "NotIpAddress": {"aws:SourceIp": "54.242.144.0/24"}
      }
    }
  ]
}

• Query string authentication: Query string authentication is a method to authenticate requests to an Amazon S3 bucket allowing organizations to generate a URL (see Figure 5-10) that can be shared with end users. When an end user clicks the URL, they are granted access to the specified S3 bucket and its contents.

  Figure 5-10 Presigned URL for S3 Object Access

  The URL includes a set of parameters that specify the credentials that grant access to the bucket. These parameters include the access key ID, an expiration time for the URL, and a signature that is calculated using the access key secret.

  When someone attempts to access the URL, the Amazon S3 service checks the signature to verify that it matches the expected value. If the signature is valid, the user is granted access to the bucket; otherwise, the request is denied.

  The use case for using query string authentication is useful for granting temporary access to an S3 bucket without having to create an IAM user or provide AWS access keys. However, query string authentication is not as secure as IAM policies or bucket policies because the URL and its parameters are included in each request; therefore, anyone who has access to the URL can potentially gain access to the bucket.

• Blocking S3 public access: S3 Buckets always start as private, with no default public access (see Figure 5-11). When the Block Public Access (Bucket Settings) setting is enabled, attempts at changing security settings to allow public access to objects in the S3 bucket are denied. You can block public access on an individual S3 bucket or on all S3 buckets in your AWS account by editing the public access settings for your account using the S3 console. Choices for blocking S3 public access include the following:

  • Public: Everyone has access to list objects, write objects, and read and write permissions.

  • Objects Can Be Public: The bucket is not public; however, public access can be granted to individual objects by users with permissions.

  • Buckets and Objects Not Public: No public access is allowed to the bucket or the objects within the bucket.

S3 Storage at Rest

For the AWS Certified Solutions Architect – Associate (SAA-C03) exam, the key topics to know about S3 storage at rest are as follows:

• SSE-S3: With SSE-S3, Amazon S3 manages the encryption and decryption of the data in the bucket. Organizations that select this option don’t manage the encryption keys but can access the data in the bucket without having to manage the keys. SSE-S3 uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key to encrypt the data in the bucket. The key is automatically generated by Amazon S3 and is regularly rotated to ensure the security of the encrypted data (see Figure 5-12). Note that SSE encrypts the object data but the optional tag object metadata remains unencrypted.

  Figure 5-12 SSE-S3 Encryption Process

• SSE-KMS: Organizations can select AWS KMS to manage their encryption keys. Select the default CMK or choose a CMK that was already created in AWS KMS before starting an S3 encryption process. Accessing encrypted objects managed by KMS can be expensive: If you have an exceptionally large number of encrypted objects, a large volume of decryption requests will be made to KMS. You can configure SSE-KMS to significantly reduce the cost of the encryption and decryption process. When an S3 Bucket Key is configured for SSE-KMS server-side encryption, a short-lived encryption key is created and stored and used to encrypt objects internally inside AWS S3 rather than utilize AWS KMS encryption processes. The S3 Bucket Key creates unique data keys for encrypting objects in the specific S3 bucket that has enabled the S3 Bucket Key option. The encryption process reduces AWS KMS requests for external encryption keys and can reduce encryption costs by 99%. The S3 Bucket Key is a worker process within the S3 bucket that enables you to perform encryption services without constant communication with KMS.

• SSE-C: You can use SSE with a customer-provided encryption key. With each request, the encryption key is provided to AWS, and Amazon S3 manages the encryption and decryption of S3 objects by using the supplied key. The same encryption key that was used to encrypt the object must be provided before the object can be decrypted (see Figure 5-13). After the encryption process is complete, the supplied encryption key is deleted from memory. To upload an object with an organization-provided encryption key (SSE-C), the AWS CLI, AWS SDK, or Amazon S3 REST API must be used.

Amazon S3 Object Lock Policies

Amazon S3 buckets and Amazon S3 Glacier have data policies that can lock objects so they cannot be deleted or changed. Amazon S3 objects can be locked using a write-once/read-many (WORM) policy. Object lock policies enable you to set rules that restrict certain actions on objects, such as deleting or overwriting them, in order to protect objects and ensure they remain available and unaltered. Object lock policies are set at the S3 bucket level and apply to all objects in the bucket, or set on individual objects. This can be useful for complying with legal or regulatory requirements or protecting important or sensitive data. Apply a WORM policy, as shown in Figure 5-14, to stop an Amazon S3 object from being overwritten, or deleted for a fixed time period, or indefinitely. There are several options to WORM policies to understand. First is the retention period, which refers to a set number of days or years during which an object will remain locked, protected, and unable to be overwritten or deleted. There are two retention modes:

• Governance mode: An S3 object cannot have its lock settings overwritten and cannot itself be overwritten or deleted unless the user has unique permissions. To override governance mode retention settings, an IAM user must have the s3: BypassGovernanceRetention permission and x-amz-bypass-governance-retention: true applied.

• Compliance mode: A protected object in your AWS account cannot be overwritten or deleted by anyone, including the root user, for the entire retention period.

Legal Hold

An object lock allows you to place a legal hold on an S3 object. Legal hold provides the same protection as a previously discussed retention period but does not have an expiration date. expiration date. Once in force, a legal hold remains in place until it is removed. An object lock works on S3 buckets that have versioning already enabled. Legal hold can be applied to a single S3 object. A legal hold can be placed and removed by any user with the s3:PutObjectLegalHold permission applied to their IAM user or group account they are a member of.

Amazon S3 Glacier Storage at Rest

Objects stored in Amazon S3 Glacier are automatically encrypted using SSE and AES-256 encryption. Amazon S3 Glacier Vault Lock enables you to deploy and enforce regulatory and required compliance controls by applying a Vault Lock policy on an Amazon S3 Glacier vault. Once a WORM policy has been applied to an S3 Glacier vault, the policy cannot be changed.

Data Backup and Replication

Amazon S3 object backups can be carried out with the services and utilities listed in Table 5-2. AWS Backup and AWS DataSync can back up additional AWS storage service data records.

Table 5-2 Data Backup and Replication Options

AWS Key Management Service

AWS Key Management Service (KMS) lets organizations create, manage, and control cryptographic keys used to protect data records. AWS KMS integrates with AWS services that can encrypt data records (see Figure 5-15).

Organizations do not have to directly interface with AWS KMS to enable data encryption; instead, they can use AWS KMS services through more than 100 integrated AWS services, such as Amazon EBS storage, Amazon RDS, Amazon S3, Amazon EFS, Amazon FSx for Windows File Server, Amazon Aurora, and Amazon DynamoDB. When you enable encryption services using AWS KMS, a CMK is automatically generated in your AWS account for data encryption and decryption services. Organizations can choose to create one or more CMKs and use them to match their security requirements. A custom CMK allows you to control each key’s access control and usage policy; you can also grant permissions to other AWS accounts and services to use a specific custom CMK.

You can also choose to create symmetric CMKs, which use the same key to encrypt and decrypt data, or asymmetric CMKs, which use a public/private key pair (one for encrypting and one for decrypting).

The most common way to use KMS is to choose which AWS service will encrypt your data and select the CMK from within the AWS service itself; for example, you can encrypt an RDS database volume, as shown in Figure 5-16.

Envelope Encryption

KMS uses a process called envelope encryption to encrypt data at rest. It involves two layers of encryption: the first layer encrypts the data using a key generated by the organization, and the second layer encrypts the customer-generated key using a key that is managed by the AWS Key Management Service (KMS). This process enables each organization to retain control over their encryption keys and also enables them to rotate and manage the keys as needed, while still benefitting from the security and reliability of using the KMS for encryption key management. When you need to encrypt data, KMS generates a data key that is used to encrypt the data locally within the AWS service or application. The data keys are also encrypted under the organization’s CMK. When it’s time to decrypt your data, a request is sent to KMS to decrypt the data key (that is, the data key copy that was stored with the encrypted data) using your CMK. The entire encryption or decryption process is logged in AWS CloudTrail for auditing purposes.

Organizations that choose to import 256-bit symmetric keys into AWS KMS for compliance requirements are responsible for managing the imported keys’ expiration dates.

In addition to encrypting your data, AWS KMS provides other security features to help protect your encryption keys:

• Key management: As an administrator, you can create, rotate, disable, and delete the CMKs that are used to encrypt your data. You can also view the key policy for a CMK, which specifies who has access to the CMK and what actions they can perform with it.

• Access control: Organizations can use AWS IAM policies to control who has access to their CMKs and what actions can be performed with them. For example, users can be granted the ability to encrypt data using a specific CMK, but not to decrypt it or change the key policy.

• Auditing: AWS KMS logs all API calls to AWS CloudTrail so organizations can track who is using each CMK and for what purpose. Auditing can help ensure that encryption keys are being used securely and in accordance with an organization’s security policies.

• Key material: KMS stores the key material for your CMKs in secure hardware devices called hardware security modules (HSMs). This helps protect the security of each organization’s keys and ensures that they are only accessible to authorized users.

• Key rotation: CMKS can be configured to automatically be rotated on an annual basis, to help prevent security breaches.

AWS KMS Cheat Sheet

For the AWS Certified Solutions Architect – Associate (SAA-C03) exam, you need to understand the following critical aspects of AWS KMS:

• AWS KMS can be used to create symmetric keys within a custom key store such as AWS CloudHSM.

• An organization’s symmetric keys can be imported for use with AWS KMS.

• AWS KMS can create symmetric and asymmetric data key pairs for application use.

• CMKs can be automatically rotated annually.

• CMKs can be disabled and re-enabled.

• AWS KMS keys can be audited with AWS CloudTrail.

AWS CloudHSM

Instead of using the default AWS KMS store, you can create a custom key store using a VPC-hosted AWS CloudHSM cluster and authorize KMS to use it as its dedicated key store. AWS CloudHSM clusters are created using multiple single-tenant hardware devices (see Figure 5-17). Amazon maintains the AWS CloudHSM hardware and backs up its contents but never enters an AWS CloudHSM device. Organizations might use an AWS CloudHSM deployment if compliance rules explicitly require that encryption keys are protected in a single-tenant hardware device. AWS CloudHSM can operate as a complete stand-alone hardware device for your synchronous and asynchronous keys and provide you with Federal Information Processing Standard (FIPS) 140-2 Level 3 compliance.

AWS Certificate Manager

AWS Certificate Manager (ACM) is a managed service that allows you to provision, manage, and deploy public and private SSL/TLS certificates that can be used with your AWS services and AWS-hosted websites and applications. Certificates can also be deployed on ELB load balancers, CloudFront distributions, Elastic Beanstalk, and APIs hosted on Amazon API Gateway. There is no additional charge for provisioning public or private SSL/TLS certificates for use with AWS services. However, organizations will pay a fee for creating and operating a private certificate authority (CA) and for the private certificates that are issued by the private CA that is used by your internally hosted resources, such as application servers or appliances.

ACM can generate the following certificate types (see Figure 5-18):

• Public certificates: ELB port 443 traffic, CloudFront distributions, and public-facing APIs hosted by Amazon API Gateway all use public certificates. Use AWS Certificate Manager to request a public certificate for a domain name for your site. AWS Certificate Manager validates that you own or control the domain name in your certificate request. Validation options include DNS validation and email validation.

• Private certificates: Delegated private certificates are managed by an AWS Certificate Manager–hosted private CA, which can automatically renew and deploy certificates for private-facing Amazon ELB and Amazon API Gateway deployments. Private certificates can also secure Amazon EC2 instances, Amazon ECS containers, and IoT devices.

• Imported certificates: Third-party certificates can be imported into AWS Certificate Manager.

• CA certificates: Certificates can be issued for creating a private CA up to five levels deep, including a root CA, three levels of subordinate CAs, and a single issuing CA.

Encryption in Transit

AWS uses HTTPS endpoints communication, providing encryption in transit for communicating with AWS APIs. AWS service endpoints can also be accessed using TLS version 1.2. Some AWS services offer endpoints that support the Federal Processing Standard (FIPS) 140-2 in some regions. Each endpoint is the URL of the entry point for each AWS service. AWS SDKs and the AWS Command Line Interface (AWS CLI) automatically use the default endpoint for each service per AWS Region, but an alternative endpoint can be specified for API requests. Most AWS services have regional endpoints that can be used to make requests. The format for a regional endpoint is protocol://service-code.region-code.amazonaws.com. AWS endpoints can be referenced here: https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html.

Global endpoints are used for global services and services located in edge locations. The global AWS services are

• Amazon CloudFront

• AWS Global Accelerator

• AWS Identity and Access Management (IAM)

• AWS Organizations

• Amazon Route 53

• AWS Shield Advanced

• AWS WAF Classic

HTTP endpoints for domains and hosted workloads hosted at AWS can be be blocked with Security Groups and Network ACLs and can automatically be redirected to HTTPS endpoints when using Amazon CloudFront or an Amazon ELB.

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 16, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the margin of the page. Table 5-3 lists these key topics and the page number on which each is found.

Table 5-3 Chapter 5 Key Topics

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

Amazon Elastic Block Storage (EBS)

symmetric key

access control list (ACL)

bucket policy

write-once/read-many (WORM)

AWS Key Management Service (KMS)

certificate authority (CA)

Q & A

The answers to these questions appear in Appendix A. Use the Pearson Test Prep Software Online for more practice with exam format questions.

1. Which AWS storage service is available with AWS as a single-tenant storage design?

2. What is the default state of an S3 bucket regarding public access when the bucket is first created?

3. What is the security advantage of using SSE-C encryption with Amazon S3 buckets?

4. Describe the concept of envelope encryption that KMS uses.

5. What type of data stored at AWS is always automatically encrypted by default?

6. Why is AWS CloudHSM chosen by companies that must adhere to a high compliance standard?

7. How does AWS KMS carry out automatic key rotation for imported keys?

8. Where can private CAs created by AWS Certificate Manager be deployed?

© 2024 Pearson Education, Pearson IT Certification. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240