Chapter 5
Encryption on AWS

THE AWS CERTIFIED DEVELOPER – ASSOCIATE EXAM TOPICS COVERED IN THIS CHAPTER MAY INCLUDE, BUT ARE NOT LIMITED TO, THE FOLLOWING:

  • Domain 2: Security
  • check mark 2.2 Implement encryption using AWS services.
  • Domain 3: Development with AWS Services
  • check mark 3.4 Write code that interacts with AWS services by using APIs, SDKs, and AWS CLI.

Introduction to Encryption

AWS delivers a secure, scalable cloud computing platform with high availability, offering the flexibility for you to build a wide range of applications. If you require an additional layer of security for the data you store in the AWS Cloud, there are several options for encrypting data at rest. These options range from automated AWS encryption solutions to manual, client-side options. Choosing the right solutions depends on which AWS service you’re using and your requirements for key management. This chapter provides an overview of various methods for encrypting data at rest in AWS. Specifically, it covers three options and compares and contrasts the advantages of each option.

Before exploring the different ways that you can use encryption in AWS, the following section describes two services that you can use for your encryption strategy: AWS Key Management Service and AWS CloudHSM.

AWS Key Management Service

AWS Key Management Service (AWS KMS) is a managed AWS service that makes it easy to create and manage encryption keys to encrypt your data across a wide range of AWS services and in your applications. As a secure, resilient service, AWS KMS uses FIPS 140-2 validated cryptographic modules, known as a hardware security module (HSM), to protect your master keys. The Federal Information Processing Standards (FIPS) are responsible for defining security requirements for cryptographic modules. For more information about FIPS 140-2 validation, see https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf.

You can take advantage of a number of AWS KMS features and benefits when developing your applications. You can use AWS KMS to make the applications and data more secure while still enabling you to innovate quickly through an API.

AWS KMS offers the following features:

  • Centralized key management
  • Integration with other AWS services
  • Audit capabilities and high availability
  • Custom key store
  • Compliance

Centralized Key Management

AWS KMS provides you with a centralized view of your encryption keys. You can create a customer master key (CMK) to control access to your data encryption keys (data keys) and to encrypt and decrypt your data. AWS KMS uses an Advanced Encryption Standard (AES) in 256-bit mode to encrypt and secure your data.

You can use AWS KMS to create keys in one of three ways: by using AWS KMS, by using AWS CloudHSM, or by importing your own key material. Regardless of the method you use to store your keys, you can manage them with AWS KMS through the AWS Management Console or by using the AWS SDK or the AWS CLI. AWS KMS also automatically rotates your keys once a year, without having to re-encrypt data that was previously encrypted.

Integration with Other AWS Services

AWS KMS provides seamless integration with other AWS services. This integration means that, as a developer, you can quickly create keys to encrypt data that is stored in other AWS services, such as Amazon Simple Storage Service (Amazon S3).

AWS KMS provides an AWS managed master key for a variety of AWS services that integrate with AWS KMS. You can track the AWS managed CMKs in your account, but the service itself manages the keys. For greater control over the encryption process, you can generate your own CMK.

At the time of this writing, AWS KMS supports 51 AWS services, as shown in Figure 5.1.

AWS Services Integrated with KMS
Alexa for Business* Amazon EMR Amazon SageMaker AWS CodeDeploy
Amazon Athena Amazon FSx for Windows File Server Amazon Simple Email Service (Amazon SES) AWS CodePipeline
Amazon Aurora Amazon Simple Storage Service Glacier Amazon Simple Notification Service (Amazon SNS) AWS Database Migration Service
Amazon CloudWatch logs Amazon Kinesis Data Streams Amazon Simple Queue Service (Amazon SQS) AWS Glue
Amazon Comprehend* Amazon Kinesis Data Firehouse Amazon Translate AWS Lambda
Amazon Connect Amazon Kinesis Video Streams Amazon WorkMail AWS Secrets Manager
Amazon DocumentDB Amazon Lex Amazon WorkSpaces AWS Systems Manager
Amazon DynamoDB* Amazon Lightsail* AWS Backup AWS Snowball
Amazon DynamoDB Accelerator (DAX)* Amazon Managed Streaming for Kafka (MSK) AWS Certificate Manager* AWS Snowball Edge
Amazon Elastic Block Store (Amazon EBS) Amazon Neptune AWS Cloud9* AWS Snowmobile
Amazon Elastic File System (Amazon EFS) Amazon Redshift AWS CloudTrail AWS Storage Gateway
Amazon Elastic Transcoder Amazon Relational Database Service (RDS) AWS CodeBuild AWS X-Ray
Amazon Elasticsearch Service Amazon Simple Storage Service (Amazon S3) AWS CodeCommit*

Figure 5.1 Supported AWS services

Auditing Capabilities and High Availability

If AWS CloudTrail is enabled for your AWS account and Region, API requests and other activity in your AWS account are recorded to log files. With CloudTrail, you can see who has used a particular AWS KMS CMK, the API call that was sent, and when they attempted to use that particular key.

In addition to auditing capabilities, AWS KMS is a fully managed service, which means that as your encryption needs grow or change, AWS KMS can scale automatically to meet those needs. Additionally, because this is a managed service, AWS KMS stores encrypted copies or versions of your keys inside systems that are designed for 99.999999999 percent durability.

The AWS CMKs do not leave the CloudHSM instances. Your keys are stored securely within the AWS Region so that no one, including AWS employees, can retrieve your plaintext keys from AWS KMS. AWS KMS uses FIPS 140-2 validated HSMs to protect your keys and to help ensure the confidentiality and integrity of your data.

Custom Key Store

You can create your own custom key store in an CloudHSM cluster that you control, enabling you to store your AWS KMS keys in a single-tenant environment instead of the default multi-tenant environment of AWS KMS. The use of a custom key store incurs an additional cost for the CloudHSM cluster.

Compliance

Achieving compliance for your applications can be a lengthy and difficult process. The security and quality controls in AWS KMS have been validated and certified by a number of industry-specific compliance and regulatory standards. For a full list of compliance standards that have been met, see https://aws.amazon.com/compliance/services-in-scope/.

AWS CloudHSM

AWS CloudHSM offers third-party, validated FIPS 140-2, level-three hardware security modules in the AWS Cloud. The hardware security module is a computing device that provides a dedicated infrastructure to support cryptographic operations. You can use CloudHSM to support encryption for your application while running in your own Amazon Virtual Private Cloud (Amazon VPC). This means that your Amazon Elastic Compute Cloud (Amazon EC2) instances can access the CloudHSM device quickly while isolating them from other networks.

CloudHSM provides both asymmetric and symmetric encryption capabilities. Additionally, you can use the CloudHSM software libraries to integrate applications with HSMs in your cluster. The libraries include PKCS #11, Sun Java JCE (Java Cryptography Extension), and Cryptography API: Next Generation (CNG) providers for Microsoft. By using these libraries, you can perform cryptographic operations on the HSMs.

Controlling the Access Keys

Encryption on any system requires three components: data to encrypt, a method to encrypt the data using a cryptographic algorithm, and the use of encryption keys with the data and the algorithm. Most modern programming languages provide libraries with a wide range of available cryptographic algorithms, such as the Advanced Encryption Standard (AES). Choosing the right algorithm involves evaluating security, performance, and compliance requirements specific to your application. Although the selection of an encryption algorithm is important, protecting the keys from unauthorized access is critical. Managing the security of encryption keys is often performed using a key management infrastructure (KMI). A KMI is composed of two subcomponents: the storage layer that protects the plaintext keys and the management layer that authorizes key use. A common way to protect keys in a KMI is to use a hardware security module. An HSM is a dedicated storage and data processing device that performs cryptographic operations using keys on the device. An HSM typically provides tamper evidence, or resistance, to protect keys from unauthorized use. A software-based authorization layer controls who can administer the HSM and which users or applications can use which keys in the HSM.

As you deploy encryption for various data classifications in AWS, it is important to understand exactly who has access to your encryption keys or data and under what conditions. As shown in Figure 5.2, there are three different options for how you and AWS provide the encryption method and the KMI:

  • You control the encryption method and the entire KMI.
  • You control the encryption method, AWS provides the storage component of the KMI, and you provide the management layer of the KMI.
  • AWS controls the encryption method and the entire KMI.
The figure shows three different options for how you and AWS provide the encryption method and the KMI.

Figure 5.2 Encryption options in AWS

Option 1: You Control the Encryption Method and the Entire KMI

In this option, you use your own KMI to generate, store, and manage access to keys in addition to controlling all the encryption methods in your applications. This physical location of the KMI and the encryption method can be outside of AWS or in an Amazon EC2 instance that you own. The encryption method can be a combination of open source tools, AWS SDKs, or third-party software and hardware. The important security property of this option is that you have full control over the encryption keys and the execution environment that uses those keys in the encryption code. AWS has no access to your keys and cannot perform encryption or decryption on your behalf. You are responsible for the proper storage, management, and use of keys to ensure the confidentiality, integrity, and availability of your data. You can encrypt data in AWS services, as described in the following sections.

Amazon Simple Storage Service

You can encrypt data by using any encryption method you want and then upload the encrypted data using the Amazon Simple Storage Service (Amazon S3) API. Most common application languages include cryptographic libraries that enable you to perform encryption in your applications. There are many commonly available open source tools for data encryption; however, they go beyond the scope of this study guide. After you have encrypted an object and safely stored the key in your KMI, you can upload the encrypted object to Amazon S3 directly with a PUT request. To decrypt this data, issue the GET request in the Amazon S3 API and then pass the encrypted data to your local application for decryption.

AWS provides an alternative to these open source encryption tools with the Amazon S3 encryption client, which is an open source set of APIs embedded in the AWS SDKs. This client lets you supply a key from your KMI that can be used to encrypt or decrypt your data as part of the call to Amazon S3. The SDK leverages Java Cryptography Extensions (JCEs) in your application to take your symmetric or asymmetric key as input and encrypt the object before uploading it to Amazon S3. The process is reversed when the SDK is used to retrieve an object. The downloaded encrypted object from Amazon S3 is passed to the client along with the key from your KMI. The underlying JCE in your application decrypts the object.

The Amazon S3 encryption client is integrated into the AWS SDKs for Java, Ruby, and .NET. It provides a transparent drop-in replacement for any cryptographic code that you might have used previously with your application that interacts with Amazon S3. Although AWS provides the encryption method, you control the security of your data because you control the keys for that engine to use. If you’re using the Amazon S3 encryption client on-premises, AWS does not have access to your keys or unencrypted data. If you’re using the client in an application running in Amazon EC2, a best practice is to pass keys to the client by using secure transport (for example, Secure Sockets Layer [SSL] or Secure Shell [SSH]) from your KMI to help ensure confidentiality. Figure 5.3 shows an example of Amazon S3 client-side encryption from an on-premises system compared with encryption within an Amazon EC2 application.

The figure shows an example of Amazon S3 client-side encryption from an on-premises system compared with encryption within an Amazon EC2 application.

Figure 5.3 Amazon S3 client-side encryption

Amazon Elastic Block Store

Amazon Elastic Block Store (Amazon EBS) provides block-level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes are network-attached and persist independently from the life of an instance.

System-level or block-level encryption Because Amazon EBS volumes are presented to an instance as a block device, you can leverage most standard encryption tools for file system-level or block-level encryption. Some common block-level open source encryption solutions for Linux are Loop-AES, dm-crypt (with or without LUKS extension), and TrueCrypt. Each of these operates below the file system layer using kernel space device drivers to perform the encryption and decryption of data. These tools are useful when you want all data written to a volume to be encrypted regardless of what directory the data is stored in.

File-system encryption You can use file system-level encryption, which works by stacking an encrypted file system on top of an existing file system. This method is typically used to encrypt a specific directory. eCryptfs and EncFs are two Linux-based open source examples of file system-level encryption tools.

These solutions require you to provide keys either manually or from your KMI. An important caveat with both block-level and file system-level encryption tools is that you can use them only to encrypt data volumes that are not Amazon EBS boot volumes. This is because these tools do not allow you to make a trusted key available automatically to the boot volume at startup.

AWS partner solutions help automate the process of encrypting Amazon EBS volumes in addition to supplying and protecting the necessary keys. Trend Micro SecureCloud and SafeNet ProtectV are two such partner products that encrypt Amazon EBS volumes and include a KMI. Figure 5.4 shows how you can use the SafeNet and Trend Micro solutions to encrypt data stored on Amazon EBS using keys managed on-premises, via SaaS, or in applications running on Amazon EC2

The figure shows how you can use the SafeNet and Trend Micro solutions to encrypt data stored on Amazon EBS using keys managed on-premises, via SaaS, or in applications running on Amazon EC2.

Figure 5.4 Encryption in Amazon EBS using SafeNet ProtectV or Trend Micro SecureCloud

AWS Storage Gateway

AWS Storage Gateway is a service connecting an on-premises software appliance with Amazon S3. You can expose it to your network as an iSCSI disk to facilitate copying data from other sources. Data on disk volumes attached to the Storage Gateway are automatically uploaded to Amazon S3 based on policy. You can encrypt source data on the disk volumes by using any of the file encryption methods described previously, such as Bouncy Castle or OpenSSL, before it is written to the disk. To encrypt all the data on the disk volume, you can also use a block-level encryption tool, such as BitLocker or dm-crypt/LUKS, on the iSCSI endpoint exposed by Storage Gateway.

Amazon Relational Database Service

To encrypt data in Amazon Relational Database Service (Amazon RDS) using client-side technology, you must consider how you want data queries to work. Because Amazon RDS does not expose the attached disk it uses for data storage, transparent disk encryption using techniques described in the previous Amazon EBS section is not available. However, you can encrypt database fields in your application selectively by using any of the standard encryption libraries mentioned previously, such as Bouncy Castle and OpenSSL, before the data passes to your Amazon RDS instance.

Although this specific field data does not easily support range queries in the database, queries based on unencrypted fields can still return useful results. The encrypted fields of the returned results can be decrypted by your local application for presentation. To support more efficient querying of encrypted data, you can store a keyed-hash message authentication code (HMAC) of an encrypted field in your schema, and you can supply a key for the hash function. Subsequent queries of protected fields that contain the HMAC of the data being sought would not disclose the plaintext values in the query. This allows the database to perform a query against the encrypted data in your database without disclosing the plaintext values in the query. Any of the encryption methods you choose must be performed on your own application instance before data is sent to the Amazon RDS instance.

Amazon EMR

Amazon EMR provides an easy-to-use Hadoop implementation running on Amazon EC2. Performing encryption throughout the Hadoop operation involves encryption and key management at the following distinct phases:

  • Source data
  • Hadoop Distributed File System (HDFS)
  • Shuffle phase
  • Output data

If the source data is not encrypted, then this step can be skipped, and SSL can be used to help protect data in transit to the Amazon EMR cluster. If the source data is encrypted, then your Hadoop job must decrypt the data as it is ingested. If your job flow uses Java and the source data is in Amazon S3, you can use any of the client decryption methods described in the previous Amazon S3 sections.

The storage used for the HDFS mount point is the ephemeral storage of the cluster nodes. Depending on the instance type, there might be more than one mount. To encrypt these mount points, you must use an Amazon EMR bootstrap script that will do the following:

  1. Stop the Hadoop service.
  2. Install a file-system-encryption tool on the instance.
  3. Create an encrypted directory to mount the encrypted file system on top of the existing mount points.
  4. Restart the Hadoop service.

For example, you can perform these steps on each of the HDFS mounts by using the open source eCryptfs package and an ephemeral key generated in your code. You don’t need to worry about persistent storage of this encryption key because the data it encrypts does not persist beyond the life of the HDFS instance.

The shuffle phase involves passing data between cluster nodes before the reduce step. To encrypt this data in transit, when you create your cluster, you can enable SSL with a configure Hadoop bootstrap option.

Finally, to enable encryption of the output data, your Hadoop job should encrypt the output using a key sourced from your KMI. This data can be sent to Amazon S3 for storage in encrypted form.

Option 2: You Control the Encryption Method, AWS Provides the KMI Storage Component, and You Provide the KMI Management Layer

This option is similar to option 1 in that you manage the encryption method, but it differs from option 1 in that the keys are stored in an AWS CloudHSM appliance rather than in a key storage system that you manage on-premises. While the keys are stored in the AWS environment, they are inaccessible to any employee at AWS because only you have access to the cryptographic partitions within the dedicated HSM to use the keys.

The CloudHSM appliance is a FIPS 140-2, level 3 HSM that has both physical and logical tamper detection and response mechanisms that trigger zeroization of the appliance. Zeroization erases the HSM’s volatile memory where any decrypted keys were stored. Zeroization destroys the key that encrypts stored objects, effectively causing all keys on the HSM to be inaccessible and unrecoverable.

CloudHSM

To help you decide whether CloudHSM is appropriate for your deployment, it is important to understand the role that an HSM plays in encrypting data. You can use an HSM to generate and store key material and perform encryption and decryption operations. However, an HSM does not perform any key lifecycle management functions (such as access control policy, key rotation). This means you might need a compatible KMI, in addition to the CloudHSM appliance, before deploying your application. You can deploy the KMI either on-premises or within Amazon EC2. To help protect data and encryption keys, the KMI can communicate to the CloudHSM instance securely over SSL.

Amazon Virtual Private Cloud

Applications must be able to access your CloudHSM appliance in an Amazon Virtual Private Cloud (Amazon VPC). The CloudHSM client interacts with the CloudHSM appliance to encrypt data from your application. You can then send encrypted data to any AWS service for storage. CloudHSM and your custom application support database, disk volume, and file encryption applications. Figure 5.5 shows how the CloudHSM solution works with your applications running on Amazon EC2 in an Amazon VPC.

The figure shows how the CloudHSM solution works with your applications running on Amazon EC2 in an Amazon VPC.

Figure 5.5 Deploying AWS CloudHSM in an Amazon VPC

To achieve the highest availability and durability of keys in your CloudHSM appliance, AWS recommends deploying multiple CloudHSM applications across different Availability Zones or with an on-premises HSM appliance that you manage.

Option 3: AWS Controls the Encryption Method and the Entire KMI

AWS provides server-side encryption of your data, transparently managing the encryption method and keys.

AWS Key Management Service

AWS Key Management Service (AWS KMS) is a managed encryption service that lets you provision and use keys to encrypt your data in AWS services and your applications. Master keys in AWS KMS are used in a similar way to how master keys in an HSM are used. Master keys are designed never to be exported from the service. You can send data to the service to be encrypted or decrypted using a specific master key under your account. This design gives you centralized control over who can access your master keys to encrypt and decrypt data, and it gives you the ability to audit this access.

AWS KMS is natively integrated with other AWS services, including Amazon EBS, Amazon S3, and Amazon Redshift, to simplify encryption of your data within those services. AWS SDKs are integrated with AWS KMS to enable you to encrypt data in your custom applications. For applications that must encrypt data, AWS KMS provides global availability, low latency, and a high level of durability for your keys.

AWS KMS and other services that encrypt your data directly use a method called envelope encryption to balance performance and security. Figure 5.6 describes the flow of envelope encryption.

The figure illustrates the flow of envelope encryption.

Figure 5.6 Flow of envelope encryption

The key-encrypting keys that are used to encrypt data keys are stored and managed separately from the data and the data keys. Strict access controls are placed on the encryption keys designed to prevent unauthorized use by AWS employees. When you need access to your plaintext data, this process is reversed. The encrypted data key is decrypted using the key-encrypting key; the data key is used to decrypt your data.

The following AWS services offer a variety of encryption features from which you can choose.

Amazon S3

There are three ways to encrypt your data in Amazon S3 using server-side encryption.

Server-side encryption You can set an API flag or use the AWS Management Console to encrypt data before it is written to disk in Amazon S3. Each object is encrypted with a unique data key. As an additional safeguard, this key is encrypted with a periodically rotated master key managed by Amazon S3. Amazon S3 server-side encryption uses 256-bit Advanced Encryption Standard (AES) keys for both object and master keys. This feature is offered at no additional cost beyond what you pay for using Amazon S3.

Server-side encryption using customer-provided keys You can use your own encryption key while uploading an object to Amazon S3. Amazon S3 uses this encryption key to encrypt your data using AES-256. After the object is encrypted, the encryption key is deleted from the Amazon S3 system that used it to protect your data. When you retrieve this object from Amazon S3, you must provide the same encryption key in your request. Amazon S3 verifies that the encryption key matches, decrypts the object, and returns the object to you. This feature is offered at no additional cost beyond what you pay for using Amazon S3.

Server-side encryption using AWS KMS You can encrypt your data in Amazon S3 by defining an AWS KMS master key within your account. This master key is used to encrypt the unique object key (referred to as a data key, as shown in Figure 5.6) that ultimately encrypts your object.

When you upload your object, a request is sent to AWS KMS to create an object key. AWS KMS generates this object key and encrypts it using the master key that you specified earlier; AWS KMS returns this encrypted object key along with the plaintext object key to Amazon S3. The Amazon S3 web server encrypts your object using the plaintext object key, stores the now encrypted object (with the encrypted object key), and deletes the plaintext object key from memory.

To retrieve this encrypted object, Amazon S3 sends the encrypted object key to AWS KMS. AWS KMS decrypts the object key using the correct master key and returns the decrypted (plaintext) object key to Amazon S3. With the plaintext object key, Amazon S3 decrypts the encrypted object and returns it to you.

Amazon S3 also enables you to define a default encryption policy. You can specify that all objects are encrypted when stored. You can also define a bucket policy that rejects uploads of unencrypted objects.

Amazon EBS

When creating a volume in Amazon EBS, you can choose to encrypt it using an AWS KMS master key within your account that encrypts the unique volume key that will ultimately encrypt your EBS volume. After you make your selection, the Amazon EC2 server sends an authenticated request to AWS KMS to create a volume key. AWS KMS generates this volume key, encrypts it using the master key, and returns the plaintext volume key and the encrypted volume key to the Amazon EC2 server. The plaintext volume key is stored in memory to encrypt and decrypt all data going to and from your attached EBS volume. When the encrypted volume (or any encrypted snapshots derived from that volume) needs to be re-attached to an instance, a call is made to AWS KMS to decrypt the encrypted volume key. AWS KMS decrypts this encrypted volume key with the correct master key and returns the decrypted volume key to Amazon EC2.

Amazon EMR

S3DistCp is an Amazon EMR feature that moves large amounts of data from Amazon S3 into HDFS, from HDFS to Amazon S3, and between Amazon S3 buckets. With S3DistCp, you can request Amazon S3 to use server-side encryption when it writes Amazon EMR data to an Amazon S3 bucket. This feature is offered at no additional cost beyond what you pay for using Amazon S3 to store your Amazon EMR data.

Amazon Redshift

When creating an Amazon Redshift cluster, you can choose to encrypt all data in user-created tables. For server-side encryption of an Amazon Redshift cluster, you can choose from the following options:

256-bit AES keys Data blocks (included backups) are encrypted using random 256-bit AES keys. These keys are themselves encrypted using a random 256-bit AES database key, which is encrypted by a 256-bit AES cluster master key that is unique to your cluster. The cluster master key is encrypted with a periodically rotated regional master key unique to the Amazon Redshift service that is stored in separate systems under AWS control. This feature is offered at no additional cost beyond what you pay for using Amazon Redshift.

CloudHSM cluster master key The 256-bit AES cluster master key used to encrypt your database keys is generated in your CloudHSM or by using HSM appliance on-premises. This cluster master key is then encrypted by a master key that never leaves your HSM.

When the Amazon Redshift cluster starts, the cluster master key is decrypted in your HSM and used to decrypt the database key. The database key is sent to the Amazon Redshift hosts and resides only in memory for the life of the cluster. If the cluster ever restarts, the cluster master key is again retrieved from your HSM—it is not stored on disk in plaintext. This option lets you more tightly control the hierarchy and lifecycle of the keys used to encrypt your data. This feature is offered at no additional cost beyond what you pay for using Amazon Redshift (and CloudHSM, if you choose this option for storing keys).

AWS KMS cluster master key The 256-bit AES cluster master key used to encrypt your database keys is generated in AWS KMS. This cluster master key is then encrypted by a master key within AWS KMS. When the Amazon Redshift cluster starts up, the cluster master key is decrypted in AWS KMS and used to decrypt the database key, which is sent to the Amazon Redshift hosts to reside only in memory for the life of the cluster. If the cluster ever restarts, the cluster master key is again retrieved from the hardened security appliance in AWS KMS—it is not stored on disk in plaintext. This option lets you define fine-grained controls over the access and use of your master keys and audit these controls through AWS CloudTrail. In addition to encrypting data generated within your Amazon Redshift cluster, you can also load encrypted data into Amazon Redshift from Amazon S3 that was previously encrypted using the Amazon S3 Encryption Client and keys that you provide. Amazon Redshift supports the decryption and re-encryption of data going between Amazon S3 and Amazon Redshift to protect the full lifecycle of your data.

These server-side encryption features across multiple services in AWS enable you to encrypt your data easily by setting the configuration in the AWS Management Console by making a CLI or API request for the given AWS service. AWS automatically and securely manages the authorized use of encryption keys. Because unauthorized access to those keys could lead to the disclosure of your data, AWS has built systems and processes with strong access controls that minimize the chance of unauthorized access. AWS had these systems verified by third-party audits to achieve security certifications, including SOC 1, 2, and 3; PCI-DSS; and FedRAMP.

Summary

If you take all responsibility for the encryption method and the KMI, you can have granular control over how your applications encrypt data. However, that granular control comes at a cost—both in terms of deployment effort and an inability to have AWS services tightly integrate with your applications’ encryption methods. As an alternative, you can choose a managed service that enables easier deployment and tighter integration with AWS Cloud services. This option offers checkbox encryption for several services that store your data, control over your own keys, secured storage for your keys, and auditability on all data access attempts.

Exam Essentials

Know how to define key management infrastructure (KMI). A KMI consists of two infrastructure components. The first component is a storage layer that protects plaintext keys. The second component is a management layer that authorizes use of stored keys.

Understand the available options for how you and AWS provide encryption using a KMI. With the first option, you control the encryption method in addition to the entire KMI. In the second option, you control the encryption method and the management layer of the KMI, and AWS provides the storage layer. In the third option, AWS controls the encryption method and both components of the KMI.

Understand the maintenance trade-offs of each key management option. For any options that involve customers managing the components of the KMI or encryption method, maintenance increases significantly. The increased maintenance also reduces your ability to take advantage of built-in integrations between AWS KMS and other services. For options that involve using built-in AWS functionality, additional maintenance is required only when migrating legacy applications to take advantage of new features.

Understand the encryption options available in Amazon S3. Regardless of the key management tools and process, you are able to encrypt any objects before uploading them to an Amazon S3 bucket. However, any custom encryption logic adds to processing overhead for the encryption and decryption of the data. AWS provides the Amazon S3 encryption client to help streamline this process (available in the Java, Ruby, and .NET AWS SDKs). When encrypting data on-premises, AWS has no visibility into the encryption keys or mechanisms used. For server-side encryption, Amazon S3 supports AWS-managed keys, customer-managed keys, and encryption using AWS KMS.

Understand the encryption options available in Amazon EBS. Like any on-premises block storage, Amazon EBS supports both block-level and file-system encryption. However, an important caveat with block-level and file-system encryption tools, such as TrueCrypt and eCryptfs, is that you cannot use them to encrypt the boot volume of an Amazon EC2 instance. Amazon EBS supports encryption by using customer-managed keys and AWS KMS.

Understand the encryption options available in Amazon RDS. Because Amazon RDS does not expose the underlying file system of databases, block-level and file-system encryption options are not available. However, standard libraries for encryption of database fields are fully supported. It is important to evaluate the types of queries that will be run against a database before selecting an encryption process, as this could affect the ability to run queries on encrypted data.

Resources to Review

Exercises

Exercise 5.1

Configure an Amazon S3 Bucket to Deny Unencrypted Uploads

In this exercise, you will enforce object encryption for an Amazon S3 bucket by using a bucket policy to reject PUT requests without encryption headers.

  1. Sign in to the AWS Management Console, and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
  2. Create a new bucket with a name of your choice.
  3. Apply the following policy to the bucket: 
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIncorrectEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::<bucket_name>/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
    },
    {
      "Sid": "DenyMissingEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::<bucket_name>/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": true
        }
    }
  ]
}
  4. From the AWS Identity and Access Management (IAM) console, open the policy simulator.
  5. Select an existing policy with access to the bucket that you created.
  6. Test the PutObject Amazon S3 action with and without the x-amz-server-side-encryption header.

When you are uploading a new object or making a copy of an existing object, you can specify whether you want Amazon S3 to encrypt your data by adding the header to the API request.

Exercise 5.2

Create and Disable an AWS Key Management Service (AWS KMS) Key

In this exercise, you will create a customer master key (CMK) in the AWS Management Console and then disable it. You can disable and re-enable the AWS KMS CMKs that you manage.

  1. Sign in to the AWS Management Console and open the AWS Key Management Service (AWS KMS) console at https://console.aws.amazon.com/kms.
  2. Choose Create key.
  3. Provide values for the key alias, description, and tag(s), and then choose Next.

    The alias name cannot begin with aws. The aws prefix is reserved by AWS to represent AWS managed CMKs in your account.

  4. Select one or more IAM users who can administer the CMK and then choose Next. Make sure to select your IAM user.
  5. Select one or more IAM users to use the CMK for cryptographic operations. Make sure to select your IAM user.
  6. Choose Finish to create the CMK.
  7. Locate the key in the AWS KMS console.
  8. Select the check box next to the alias of the CMK that you want to disable.
  9. Choose Key actions ➢ Disable.

If you disable a CMK, you cannot use it to encrypt or decrypt data until you re-enable it.

Exercise 5.3

Create an AWS KMS Customer Master Key with the Python SDK

In this exercise, you will create a new AWS KMS customer master key (CMK) using the AWS Command Line Interface (AWS CLI). You will use Python as one of the supported programming languages.

  1. To create the AWS KMS CMK, run the following Python script: 
    import boto3
import json
 
kms_client = boto3.client('kms', region_name='us-west-1')
 
response = kms_client.create_key(
    Description='My KMS Key',
    KeyUsage='ENCRYPT_DECRYPT',
    Origin='AWS_KMS',
    Tags=[
        {
            'TagKey': 'KeyPurpose',
            'TagValue': 'dev-on-aws-key'
        },
    ]
)
 
print(response)
  2. To list the CMKs and describe the available keys, run the following script: 
    import boto3
import json
# List the KMS Keys by ID
kms_client = boto3.client('kms', region_name='us-west-1')
try:
    response = kms_client.list_keys()
except ClientError as e:
    logging.error(e)
 
print(json.dumps(response, indent=4, sort_keys=True))
 
  3. To describe the keys inside AWS KMS, run the following script: 
    import boto3
import json
# List the KMS Keys by ID
kms_client = boto3.client('kms', region_name='us-west-1')
 
# Describe the Keys
for key in response['Keys']:
    try:
        key_info = kms_client.describe_key(KeyId=key['KeyArn'])
        key_id = key_info['KeyMetadata']['KeyId']
        key_arn = key_info['KeyMetadata']['Arn']
        key_state = key_info['KeyMetadata']['KeyState']
        key_description = key_info['KeyMetadata']['Description']
        print('Key ID: ' + key_id)
        print('Key ARN: ' + key_arn)
        print('Key State: ' + key_state)
        print('Key Description: ' + key_description)
        print('-------------------------------------')
    except ClientError as e:
        logging.error(e)
 
  4. To delete the AWS KMS key, run the following script: 
    import boto3
 
kms_client = boto3.client('kms', region_name='us-west-1')
response = kms_client.schedule_key_deletion(
    KeyId='fasdf1-2451b-151-bea2-easdfg8',
    PendingWindowInDays=7
)
 
print(response, indent=4, sort_keys=True)

 

Review Questions

  1. Which components are required in an encryption system? (Select THREE.)

    1. A user to upload data
    2. Data to encrypt
    3. A database to store encryption keys
    4. A method to encrypt data
    5. A cryptographic algorithm

  2. Which are the components of key management infrastructure (KMI)? (Select TWO.)

    1. Storage layer
    2. Data layer
    3. Management layer
    4. Encryption layer

  3. Which of the following are methods for you and AWS to provide an encryption method and key management infrastructure (KMI)? (Select THREE.)

    1. You control the encryption method and key management, and AWS provides the storage component of the KMI.
    2. You control the storage component of the KMI, and AWS provides the encryption method and key management.
    3. You control the encryption method and KMI.
    4. AWS controls the encryption method and the entire KMI.
    5. None of the above.

  4. Which option uses AWS Key Management Service (AWS KMS) to manage keys to provide server-side encryption to Amazon Simple Storage Service (Amazon S3)?

    1. Amazon S3 managed encryption keys (SSE-S3)
    2. Customer-provided encryption keys (SSE-C)
    3. Use client-side encryption
    4. None of the above

  5. Which AWS encryption service provides asymmetric encryption capabilities?

    1. AWS Key Management Service (AWS KMS).
    2. AWS CloudHSM.
    3. AWS does not provide asymmetric encryption services.
    4. None of the above.

  6. Which AWS encryption service provides symmetric encryption capabilities? (Select TWO.)

    1. AWS Key Management Service (AWS KMS).
    2. AWS CloudHSM.
    3. AWS does not provide symmetric encryption services.
    4. None of the above.

  7. An organization is using Amazon Simple Storage Service (Amazon S3), and it would like to ensure that all objects that are stored in Amazon S3 are encrypted. However, it does not want to be responsible for managing any of the encryption keys. As their lead developer, which service and feature should you recommend?

    1. Server-side encryption with AWS Key Management Service (SSE-KMS).
    2. Customer-provided encryption keys (SSE-C).
    3. Amazon S3 managed encryption keys (SSE-S3).
    4. This is not possible in AWS.

  8. Which feature of AWS Key Management Service (AWS KMS) enables you to use an AWS CloudHSM cluster for the storage of your encryption keys?

    1. Centralized key management
    2. AWS CloudHSM
    3. Custom key stores
    4. S3DistCp

  9. An organization is using AWS Key Management Service (AWS KMS) to support encryption and would like to encrypt Amazon Elastic Block Store (Amazon EBS) volumes. It wants to encrypt its volumes quickly, with little development time. As their lead developer, what should you recommend?

    1. Implement AWS KMS to encrypt the Amazon EBS volumes.
    2. Use open source or third-party encryption tooling.
    3. Use AWS CloudHSM.
    4. AWS does not provide a mechanism to encrypt Amazon EBS volumes.

  10. Which of the following AWS services does not integrate with AWS Key Management Service (AWS KMS)?

    1. Amazon Elastic Block Store (Amazon EBS)
    2. Amazon Simple Storage Service (Amazon S3)
    3. Amazon Redshift
    4. None of the above
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset