KMS

AWS S3 Encryption

~ Last updated on : ~ jayendrapatil ~ 2 Comments

AWS S3 Encryption

📌 Key Updates (2023-2026)

  • January 2023: All new S3 object uploads are automatically encrypted with SSE-S3 by default at no additional cost.
  • Terminology Change: AWS KMS replaced “Customer Master Key (CMK)” with “KMS key.” The concept is unchanged.
  • June 2023: Dual-Layer Server-Side Encryption (DSSE-KMS) introduced for compliance workloads.
  • November 2025: New bucket-level setting to standardize encryption types (block SSE-C per bucket).
  • January 2026: UpdateObjectEncryption API allows changing encryption type without data movement.
  • April 2026: SSE-C is now disabled by default on all new general purpose buckets.
  • Client-Side Encryption: AmazonS3EncryptionClient is deprecated; use the standalone Amazon S3 Encryption Client (v4) with key commitment.
  • AWS S3 Encryption supports both data at rest and data in transit encryption.
  • Starting January 5, 2023, all new object uploads to Amazon S3 are automatically encrypted with SSE-S3 at no additional cost and with no impact on performance.
  • Data in-transit
    • S3 allows protection of data in transit by enabling communication via SSL/TLS or using client-side encryption.
  • Data at Rest
    • Server-Side Encryption
      • S3 encrypts the object before saving it on disks in its data centers and decrypts it when the objects are downloaded.
      • SSE-S3 is automatically applied as the base level of encryption for every bucket.
    • Client-Side Encryption
      • Data is encrypted at the client-side and uploaded to S3.
      • The encryption process, the encryption keys, and related tools are managed by the user.

S3 Server-Side Encryption

  • Server-side encryption is about data encryption at rest.
  • Server-side encryption encrypts only the object data.
  • Any object metadata is not encrypted.
  • S3 handles the encryption (as it writes to disks) and decryption (when objects are accessed) of the data objects.
  • There is no difference in the access mechanism for both encrypted and unencrypted objects and is handled transparently by S3.
  • Starting January 5, 2023, SSE-S3 is applied as the base level of encryption for every bucket in Amazon S3. All new object uploads are automatically encrypted.
  • S3 supports the following server-side encryption options:
    • SSE-S3 – Server-Side Encryption with S3-Managed Keys (default)
    • SSE-KMS – Server-Side Encryption with AWS KMS Keys
    • DSSE-KMS – Dual-Layer Server-Side Encryption with AWS KMS Keys
    • SSE-C – Server-Side Encryption with Customer-Provided Keys

Server-Side Encryption with S3-Managed Keys – SSE-S3

  • Encryption keys are handled and managed by AWS.
  • SSE-S3 is the default encryption for all S3 buckets. Since January 5, 2023, all new objects are automatically encrypted with SSE-S3 unless a different encryption option is specified.
  • Each object is encrypted with a unique data key employing strong multi-factor encryption.
  • SSE-S3 encrypts the data key with a root key that is regularly rotated.
  • S3 server-side encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt the data.
  • Whether or not objects are encrypted with SSE-S3 can’t be enforced when they are uploaded using pre-signed URLs, because the only way server-side encryption can be specified is through the AWS Management Console or through an HTTP request header.
  • Request must set header x-amz-server-side-encryption to AES256
  • For enforcing server-side encryption for all of the objects that are stored in a bucket, use a bucket policy that denies permissions to upload an object unless the request includes x-amz-server-side-encryption header to request server-side encryption.
  • Since all objects are now encrypted by default, bucket policies to enforce encryption are no longer strictly required but can still be used to enforce a specific encryption type (e.g., SSE-KMS over SSE-S3).
SSE-S3 : Server Side Encryption using S3 Managed Keys
Source: Oreilly

Server-Side Encryption with AWS KMS Keys – SSE-KMS

Server-Side Encryption with AWS KMS Keys (SSE-KMS)

  • SSE-KMS is similar to SSE-S3, but it uses AWS Key Management Service (KMS) which provides additional benefits along with additional charges.
    • KMS is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud.
    • KMS uses KMS keys (previously called customer master keys or CMKs) to encrypt the S3 objects.
    • The KMS key material is never made available in plaintext.
    • KMS enables you to centrally create encryption keys, and define the policies that control how keys can be used.
    • Allows audit of key usage to prove they are being used correctly, by inspecting logs in AWS CloudTrail.
    • Allows keys to be temporarily disabled and re-enabled.
    • Allows keys to be rotated regularly (automatic annual rotation or on-demand rotation).
    • Security controls in AWS KMS can help meet encryption-related compliance requirements.
  • SSE-KMS enables separate permissions for the use of an envelope key (that is, a key that protects the data’s encryption key) that provides added protection against unauthorized access to the objects in S3.
  • SSE-KMS provides the option to create and manage encryption keys yourself (customer managed keys), or use an AWS managed key that is unique to you, the service you’re using, and the region you’re working in.
  • Creating and managing customer managed keys gives more flexibility, including the ability to create, rotate, disable, and define access controls, and audit the encryption keys used to protect the data.
  • Data keys used to encrypt the data are also encrypted and stored alongside the data they protect and are unique to each object.
  • Process flow
    • An application or AWS service client requests an encryption key to encrypt data and passes a reference to a KMS key under the account.
    • Client requests are authenticated based on whether they have access to use the KMS key.
    • A new data encryption key is created, and a copy of it is encrypted under the KMS key.
    • Both the data key and encrypted data key are returned to the client.
    • Data key is used to encrypt customer data and then deleted as soon as is practical.
    • Encrypted data key is stored for later use and sent back to AWS KMS when the source data needs to be decrypted.
  • S3 only supports symmetric KMS keys and not asymmetric keys.
  • Must set header x-amz-server-side-encryption to aws:kms

S3 Bucket Keys

  • S3 Bucket Keys reduce the cost of SSE-KMS by decreasing the request traffic from Amazon S3 to AWS KMS by up to 99%.
  • When enabled, S3 generates a bucket-level key from KMS and uses it to create data keys for objects in the bucket, reducing the number of KMS API calls.
  • S3 Bucket Keys are recommended for all SSE-KMS workloads to optimize both performance and cost.
  • S3 Bucket Keys are always enabled when using SSE-KMS with S3 Express One Zone.
  • Bucket Keys can be enabled at the bucket level or specified per object in PUT requests.
SSE-KMS : Server Side Encryption using AWS KMS managed keys
Source: Oreilly

Dual-Layer Server-Side Encryption with AWS KMS Keys – DSSE-KMS

  • Launched June 2023 for compliance workloads requiring two layers of encryption.
  • DSSE-KMS applies two independent layers of encryption to objects when they are uploaded to Amazon S3.
  • Each layer uses a different implementation of the 256-bit AES-GCM algorithm.
  • Designed to meet CNSSP 15 and other compliance standards requiring multi-layer encryption.
  • Can be specified in PUT/COPY requests or configured as the bucket’s default encryption.
  • Can be enforced using IAM and bucket policies.
  • Must set header x-amz-server-side-encryption to aws:kms:dsse
  • Higher cost than SSE-KMS due to additional processing overhead and KMS API calls.
  • Use cases: Government workloads, financial services, and any regulated industry requiring dual-layer encryption at rest.

Server-Side Encryption with Customer-Provided Keys – SSE-C

AWS S3 Server Side Encryption using Customer Provided Keys SSE-C

⚠️ Important Change (April 2026)

SSE-C is now disabled by default on all new general purpose buckets and existing buckets in accounts with no SSE-C encrypted objects. To use SSE-C, you must explicitly enable it by setting BlockedEncryptionTypes to NONE in the bucket’s default encryption configuration via the PutBucketEncryption API.

  • Encryption keys can be managed and provided by the Customer and S3 manages the encryption, as it writes to disks, and decryption, when you access the objects.
  • When you upload an object, the encryption key is provided as a part of the request and S3 uses that encryption key to apply AES-256 encryption to the data and removes the encryption key from memory.
  • When you download an object, the same encryption key should be provided as a part of the request. S3 first verifies the encryption key and if it matches, the object is decrypted before returning back to you.
  • As each object and each object’s version can be encrypted with a different key, you are responsible for maintaining the mapping between the object and the encryption key used.
  • SSE-C requests must be done through HTTPS and S3 will reject any requests made over HTTP when using SSE-C.
  • For security considerations, AWS recommends considering any key sent erroneously using HTTP to be compromised and it should be discarded or rotated.
  • S3 does not store the encryption key provided. Instead, a randomly salted HMAC value of the encryption key is stored which can be used to validate future requests. The salted HMAC value cannot be used to decrypt the contents of the encrypted object or to derive the value of the encryption key. That means, if you lose the encryption key, you lose the object.
  • Starting April 2026: SSE-C is disabled by default for all new general purpose buckets. You must explicitly enable SSE-C on a bucket before using it. This change was introduced to prevent ransomware attacks that exploited SSE-C with attacker-controlled keys.
SSE-C : Server-Side Encryption with Customer-Provided Keys
Source: Oreilly

Client-Side Encryption

Client-side encryption refers to encrypting data before sending it to S3 and decrypting the data after downloading it.

⚠️ SDK Update Notice

The original AmazonS3EncryptionClient class is deprecated. AWS now provides a standalone Amazon S3 Encryption Client library (currently at v4) that supports key commitment (AES-GCM with Key Commitment) for enhanced security. The AWS SDK for Java v1 reached end-of-support on December 31, 2025. Migrate to the standalone S3 Encryption Client or AWS SDK v2/v4 equivalents.

AWS KMS-managed Key (Client-Side Encryption with KMS – CSE-KMS)

  • Customer can maintain the encryption KMS key with AWS KMS and can provide the KMS key ID to the client to encrypt the data.
  • Uploading Object
    • The S3 Encryption Client first sends a request to AWS KMS for the key to encrypt the object data.
    • AWS KMS returns a randomly generated data encryption key with 2 versions: a plaintext version for encrypting the data and a cipher blob to be uploaded with the object as object metadata.
    • The client obtains a unique data encryption key for each object it uploads.
    • The S3 Encryption Client uploads the encrypted data and the cipher blob with object metadata.
  • Download Object
    • The client first downloads the encrypted object along with the cipher blob version of the data encryption key stored as object metadata.
    • The client then sends the cipher blob to AWS KMS to get the plaintext version of the same, so that it can decrypt the object data.
Client Side Encryption - KMS Key CSE-KMS
Source: Oreilly

Client-Side Master Key (CSE-C)

  • Encryption master keys are completely maintained at the Client-side.
  • Uploading Object
    • The S3 Encryption Client locally generates a random one-time-use symmetric key (data encryption key or data key).
    • Client encrypts the data encryption key using the customer-provided master key.
    • Client uses this data encryption key to encrypt the data of a single S3 object (for each object, the client generates a separate data key).
    • Client then uploads the encrypted data to S3 and also saves the encrypted data key and its material description as object metadata (x-amz-meta-x-amz-key) in S3 by default.
  • Downloading Object
    • Client first downloads the encrypted object from S3 along with the object metadata.
    • Using the material description in the metadata, the client first determines which master key to use to decrypt the encrypted data key.
    • Using that master key, the client decrypts the data key and uses it to decrypt the object.
  • Client-side master keys and your unencrypted data are never sent to AWS.
  • If the master key is lost the data cannot be decrypted.

UpdateObjectEncryption API (January 2026)

  • Launched January 29, 2026 – allows changing the server-side encryption type of existing S3 objects without any data movement.
  • Atomically updates the encryption key of objects regardless of size or storage class.
  • Uses envelope encryption to re-encrypt the data key with the newly specified encryption type.
  • Supported transitions: SSE-S3 → SSE-KMS, and applying S3 Bucket Keys to existing objects.
  • Can be used with S3 Batch Operations to change encryption type at scale while preserving object properties and S3 Lifecycle eligibility.
  • Eliminates the need to copy objects to change their encryption (previously required COPY operations).

Enforcing S3 Encryption

  • S3 Encryption in Transit
    • S3 Bucket Policy can be used to enforce SSL/TLS communication with S3 using the effect deny with condition aws:SecureTransport set to false.
  • S3 Default Encryption
    • Helps set the default encryption behavior for an S3 bucket so that all new objects are encrypted when they are stored in the bucket.
    • Objects are encrypted using SSE with either S3-managed keys (SSE-S3) or AWS KMS keys (SSE-KMS).
    • Since January 2023, SSE-S3 is automatically applied as the base level of encryption for all buckets. You can override this to SSE-KMS or DSSE-KMS.
  • S3 Bucket Policy
    • Can be applied to deny permissions to upload an object unless the request includes x-amz-server-side-encryption header to request server-side encryption.
    • Since all objects are now encrypted by default (SSE-S3), bucket policies are primarily useful to enforce a specific encryption type (e.g., SSE-KMS).
    • Bucket policies are evaluated before the default encryption.
  • Bucket-Level Encryption Standardization (November 2025)
    • New BlockedEncryptionTypes setting via the PutBucketEncryption API.
    • Allows disabling specific encryption types (e.g., SSE-C) at the bucket level.
    • Helps standardize the server-side encryption types used with your buckets.
    • Configurable via AWS Management Console, API, CLI, and CloudFormation.

S3 Bucket Policy Enforce Encryption

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is storing data on Amazon Simple Storage Service (S3). The company’s security policy mandates that data is encrypted at rest. Which of the following methods can achieve this? Choose 3 answers
    1. Use Amazon S3 server-side encryption with AWS Key Management Service managed keys
    2. Use Amazon S3 server-side encryption with customer-provided keys
    3. Use Amazon S3 server-side encryption with EC2 key pair.
    4. Use Amazon S3 bucket policies to restrict access to the data at rest.
    5. Encrypt the data on the client-side before ingesting to Amazon S3 using their own master key
    6. Use SSL to encrypt the data while in transit to Amazon S3.
  2. A user has enabled versioning on an S3 bucket. The user is using server side encryption for data at Rest. If the user is supplying his own keys for encryption (SSE-C) which of the below mentioned statements is true?
    1. The user should use the same encryption key for all versions of the same object
    2. It is possible to have different encryption keys for different versions of the same object
    3. AWS S3 does not allow the user to upload his own keys for server side encryption
    4. The SSE-C does not work when versioning is enabled
  3. A storage admin wants to encrypt all the objects stored in S3 using server side encryption. The user does not want to use the AES 256 encryption key provided by S3. How can the user achieve this?
    1. The admin should upload his secret key to the AWS console and let S3 decrypt the objects
    2. The admin should use CLI or API to upload the encryption key to the S3 bucket. When making a call to the S3 API mention the encryption key URL in each request
    3. S3 does not support client supplied encryption keys for server side encryption
    4. The admin should send the keys and encryption algorithm with each API call
  4. A user has enabled versioning on an S3 bucket. The user is using server side encryption for data at rest. If the user is supplying his own keys for encryption (SSE-C), what is recommended to the user for the purpose of security?
    1. User should not use his own security key as it is not secure
    2. Configure S3 to rotate the user’s encryption key at regular intervals
    3. Configure S3 to store the user’s keys securely with SSL
    4. Keep rotating the encryption key manually at the client side
  5. A system admin is planning to encrypt all objects being uploaded to S3 from an application. The system admin does not want to implement his own encryption algorithm; instead he is planning to use server side encryption by supplying his own key (SSE-C). Which parameter is not required while making a call for SSE-C?
    1. x-amz-server-side-encryption-customer-key-AES-256
    2. x-amz-server-side-encryption-customer-key
    3. x-amz-server-side-encryption-customer-algorithm
    4. x-amz-server-side-encryption-customer-key-MD5
  6. You are designing a personal document-archiving solution for your global enterprise with thousands of employee. Each employee has potentially gigabytes of data to be backed up in this archiving solution. The solution will be exposed to the employees as an application, where they can just drag and drop their files to the archiving system. Employees can retrieve their archives through a web interface. The corporate network has high bandwidth AWS DirectConnect connectivity to AWS. You have regulatory requirements that all data needs to be encrypted before being uploaded to the cloud. How do you implement this in a highly available and cost efficient way?
    1. Manage encryption keys on-premise in an encrypted relational database. Set up an on-premises server with sufficient storage to temporarily store files and then upload them to Amazon S3, providing a client-side master key. (Storing temporary increases cost and not a high availability option)
    2. Manage encryption keys in a Hardware Security Module(HSM) appliance on-premise server with sufficient storage to temporarily store, encrypt, and upload files directly into Amazon Glacier. (Not cost effective)
    3. Manage encryption keys in Amazon Key Management Service (KMS), upload to Amazon Simple Storage Service (S3) with client-side encryption using a KMS key ID and configure Amazon S3 lifecycle policies to store each object using the Amazon S3 Glacier storage class. (with CSE-KMS the encryption happens at client side before the object is uploaded to S3 and KMS is cost effective as well)
    4. Manage encryption keys in an AWS CloudHSM appliance. Encrypt files prior to uploading on the employee desktop and then upload directly into Amazon Glacier (Not cost effective)
  7. A user has enabled server side encryption with S3. The user downloads the encrypted object from S3. How can the user decrypt it?
    1. S3 does not support server side encryption
    2. S3 provides a server side key to decrypt the object
    3. The user needs to decrypt the object using their own private key
    4. S3 manages encryption and decryption automatically
  8. When uploading an object, what request header can be explicitly specified in a request to Amazon S3 to encrypt object data when saved on the server side?
    1. x-amz-storage-class
    2. Content-MD5
    3. x-amz-security-token
    4. x-amz-server-side-encryption
  9. A company must ensure that any objects uploaded to an S3 bucket are encrypted. Which of the following actions should the SysOps Administrator take to meet this requirement? (Select TWO.)
    1. Implement AWS Shield to protect against unencrypted objects stored in S3 buckets.
    2. Implement Object access control list (ACL) to deny unencrypted objects from being uploaded to the S3 bucket.
    3. Implement Amazon S3 default encryption to make sure that any object being uploaded is encrypted before it is stored.
    4. Implement Amazon Inspector to inspect objects uploaded to the S3 bucket to make sure that they are encrypted.
    5. Implement S3 bucket policies to deny unencrypted objects from being uploaded to the buckets.
  10. A company wants to ensure all objects in their S3 bucket are encrypted with SSE-KMS using a specific customer managed key. They also want to reduce AWS KMS costs. What combination of steps should be taken? (Select TWO.)
    1. Configure the bucket’s default encryption to use SSE-KMS with the specific customer managed KMS key.
    2. Configure a bucket policy to deny all s3:PutObject requests that don’t include the x-amz-server-side-encryption header set to AES256.
    3. Enable S3 Transfer Acceleration to reduce KMS API calls.
    4. Enable S3 Bucket Keys to reduce request traffic from S3 to KMS and lower costs by up to 99%.
    5. Use DSSE-KMS to apply dual-layer encryption for cost savings.
  11. An organization needs to change the encryption type of millions of existing S3 objects from SSE-S3 to SSE-KMS without impacting object metadata or lifecycle policies. What is the most efficient approach?
    1. Download all objects and re-upload them with SSE-KMS specified in the PUT request.
    2. Use S3 Batch Operations with a COPY operation to copy objects in-place with SSE-KMS encryption.
    3. Use S3 Batch Operations with the UpdateObjectEncryption operation to atomically change the encryption type without data movement.
    4. Change the bucket default encryption to SSE-KMS; existing objects will be automatically re-encrypted.

References

AWS Key Management Service – KMS

AWS KMS - Owned vs Managed vs Customer Managed Keys
~ Last updated on : ~ jayendrapatil ~ 18 Comments

AWS Key Management Service – KMS

  • AWS Key Management Service – KMS is a managed encryption service that allows the creation and control of encryption keys to enable data encryption.
  • provides a highly available key storage, management, and auditing solution to encrypt the data across AWS services & within applications.
  • uses hardware security modules (HSMs) to protect and validate the keys, certified under FIPS 140-3 Security Level 3 by NIST (upgraded from FIPS 140-2 in 2023).
  • seamlessly integrates with several AWS services to make encrypting data in those services easy.
  • is integrated with AWS CloudTrail to provide encryption key usage logs to help meet auditing, regulatory, and compliance needs.
  • is regional and keys are only stored and used in the region in which they are created. They cannot be transferred to another region.
  • enforces usage and management policies, to control which IAM user, role from the account, or other accounts can manage and use keys.
  • can create and manage keys by
    • Create, edit, and view symmetric and asymmetric keys, including HMAC keys.
    • Control access to the keys by using key policies, IAM policies, and grants. Policies can be further refined using condition keys.
    • Supports attribute-based access control (ABAC).
    • Create, delete, list, and update aliases for the keys.
    • Tag the keys for identification, automation, and cost tracking.
    • Enable and disable keys.
    • Enable and disable automatic rotation of the cryptographic material in keys.
    • Delete keys to complete the key lifecycle.
  • supports the following cryptographic operations
    • Encrypt, decrypt, and re-encrypt data with symmetric or asymmetric keys.
    • Sign and verify messages with asymmetric keys.
    • Generate exportable symmetric data keys and asymmetric data key pairs.
    • Generate and verify HMAC codes.
    • Generate random numbers suitable for cryptographic applications
  • supports multi-region keys, which act like copies of the same KMS key in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions.
  • supports VPC private endpoint to connect KMS privately from a VPC.
  • supports keys in a CloudHSM key store backed by the CloudHSM cluster.
  • supports post-quantum cryptography including ML-DSA digital signatures and hybrid post-quantum TLS with ML-KEM for protection against future quantum computing threats.

Envelope encryption

  • AWS cloud services integrated with AWS KMS use a method called envelope encryption to protect the data.
  • Envelope encryption is an optimized method for encrypting data that uses two different keys (Master key and Data key)
  • With Envelop encryption
    • A data key is generated and used by the AWS service to encrypt each piece of data or resource.
    • Data key is encrypted under a defined master key.
    • Encrypted data key is then stored by the AWS service.
    • For data decryption by the AWS service, the encrypted data key is passed to KMS and decrypted under the master key that was originally encrypted so the service can then decrypt the data.
  • When the data is encrypted directly with KMS it must be transferred over the network.
  • Envelope encryption can offer significant performance benefits as KMS only supports sending data less than 4 KB to be encrypted.
  • Envelope encryption reduces the network load for the application or AWS cloud service as only the request and fulfillment of the data key must go over the network.

KMS Service Concepts

KMS Usage

KMS Keys OR Customer Master Keys (CMKs)

  • AWS KMS key is a logical representation of a cryptographic key.
  • KMS Keys can be used to create symmetric or asymmetric keys for encryption or signing OR HMAC keys to generate and verify HMAC tags.
  • Symmetric keys and the private keys of asymmetric keys never leave AWS KMS unencrypted.
  • A KMS key contains metadata, such as the key ID, key spec, key usage, creation date, description, key state, and a reference to the key material that is used to run cryptographic operations with the KMS key.
  • Symmetric keys are 256-bit AES keys that are not exportable.
  • KMS keys can be used to generate, encrypt, and decrypt the data keys, used outside of AWS KMS to encrypt the data [Envelope Encryption]
  • Key material for symmetric keys and the private keys of asymmetric key never leaves AWS KMS unencrypted.
  • Supported key specs include:
    • Symmetric: SYMMETRIC_DEFAULT (256-bit AES-GCM)
    • Asymmetric (RSA): RSA_2048, RSA_3072, RSA_4096
    • Asymmetric (ECC): ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, ECC_SECG_P256K1
    • Asymmetric (EdDSA): ECC_NIST_EDWARDS25519 (Ed25519) – Added November 2025
    • Post-Quantum: ML_DSA_44, ML_DSA_65, ML_DSA_87 – Added June 2025
    • HMAC: HMAC_224, HMAC_256, HMAC_384, HMAC_512

Customer Keys and AWS Keys

AWS KMS - Owned vs Managed vs Customer Managed Keys

AWS Managed Keys

  • AWS Managed keys are created, managed, and used on your behalf by AWS services in your AWS account.
  • keys are automatically rotated every year (~365 days) and the rotation schedule cannot be changed.
  • have permission to view the AWS managed keys in your account, view their key policies, and audit their use in CloudTrail logs.
  • cannot manage or rotate these keys, change their key policies, or use them in cryptographic operations directly; the service that creates them uses them on your behalf.

Customer managed keys

  • Customer managed keys are created by you to encrypt your service resources in your account.
  • Automatic rotation is optional. When enabled, the rotation period is configurable from 90 days to 7 years (2560 days), with a default of 365 days. (Updated April 2024 — previously fixed at 1 year.)
  • Supports on-demand rotation via the RotateKeyOnDemand API, allowing immediate rotation at any time (maximum 25 on-demand rotations per key). (Added April 2024)
  • provides full control over these keys, including establishing and maintaining their key policies, IAM policies, and grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating aliases refering the KMS keys, and scheduling the KMS keys for deletion.

AWS Owned Keys

  • AWS owned keys are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts.
  • AWS owned keys are not in your AWS account, however, an AWS service can use the associated AWS owned keys to protect the resources in your account.
  • cannot view, use, track, or audit them

Key Material

  • KMS keys contain a reference to the key material used to encrypt and decrypt data.
  • By default, AWS KMS generates the key material for a newly created key.
  • KMS key can be created without key material and then your own key material can be imported or created in the AWS CloudHSM cluster associated with an AWS KMS custom key store.
  • Key material cannot be extracted, exported, viewed, or managed.
  • Key material cannot be deleted; you must delete the KMS key.

Key Material Origin

  • Key material origin is a KMS key property that identifies the source of the key material in the KMS key.
  • Symmetric encryption KMS keys can have one of the following key material origin values.
    • AWS_KMS
      • AWS KMS creates and manages the key material for the KMS key in AWS KMS.
    • EXTERNAL
      • Key has imported key material.
      • Management and security of the key are the customer’s responsibility.
      • Only symmetric keys are supported.
      • Automatic rotation is not supported.
      • Supports on-demand rotation (June 2025) — enables rotating imported key material without changing the key ARN or key ID.
    • AWS_CLOUDHSM
      • AWS KMS created the key material for the KMS key in the AWS CloudHSM cluster associated with the custom key store.
    • EXTERNAL_KEY_STORE
      • Key material is a cryptographic key in an external key manager outside of AWS.
      • This origin is supported only for KMS keys in an external key store.

Data Keys

  • Data keys are encryption keys that you can use to encrypt data, including large amounts of data and other data encryption keys.
  • KMS does not store, manage, or track your data keys.
  • Data keys must be used by services outside of KMS.

Encryption Context

  • Encryption context provides an optional set of key–value pairs that can contain additional contextual information about the data.
  • AWS KMS uses the encryption context as additional authenticated data (AAD) to support authenticated encryption.
  • Encryption context is not secret and not encrypted and appears in plaintext in CloudTrail Logs so you can use it to identify and categorize your cryptographic operations.
  • Encryption context should not include sensitive information.
  • Encryption context usage
    • When an encryption context is included in an encryption request, it is cryptographically bound to the ciphertext such that the same encryption context is required to decrypt the data.
    • If the encryption context provided in the decryption request is not an exact, case-sensitive match, the decrypt request fails.
  • Only the order of the key-value pairs in the encryption context can vary.

Key Policies

  • help determine who can use and manage those keys.
  • can add, remove, or change permissions at any time for a customer-managed key.
  • cannot edit the key policy for AWS owned or managed keys.

Grants

  • provides permissions, an alternative to the key policy and IAM policy, that allows AWS principals to use the KMS keys.
  • are often used for temporary permissions because you can create one, use its permissions, and delete it without changing the key policies or IAM policies.
  • permissions specified in the grant might not take effect immediately due to eventual consistency.

Grant Tokens

  • help mitigate the potential delay with grants.
  • use the grant token received in the response to CreateGrant API request to make the permissions in the grant take effect immediately.

Alias

  • Alias helps provide a friendly name for a KMS key.
  • can be used to refer to different KMS keys in each AWS Region.
  • can be used to point to different keys without changing the code.
  • can allow and deny access to KMS keys based on their aliases without editing policies or managing grants.
  • aliases are independent resources, not properties of a KMS key, and can be added, changed, and deleted without affecting the associated KMS key.

Encryption & Decryption Process

  • Use KMS to get encrypted and plaintext data keys using CMK.
  • Use the plaintext data key to encrypt the data and store the encrypted data key with the data.
  • Use KMS decrypt to get the plaintext data key and decrypt the data.
  • Remove the plaintext data key from memory, once the operation is completed.

KMS Working

  • KMS centrally manages and securely stores the keys.
  • Keys can be generated or imported from the key management infrastructure (KMI).
  • Keys can be used from within the applications and supported AWS services to protect the data, but the key never leaves KMS.
  • Data is submitted to KMS to be encrypted, or decrypted, under keys that you control.
  • Usage policies on these keys can be set that determines which users can use them to encrypt and decrypt data.

KMS Access Control

  • Primary way to manage access to AWS KMS keys is with policies.
  • KMS keys access can be controlled using
    • Key Policies
      • are resource-based policies
      • every KMS key has a key policy
      • is a primary mechanism for controlling access to a key.
      • can be used alone to control access to the keys.
    • IAM policies
      • use IAM policies in combination with the key policy to control access to keys.
      • helps manage all of the permissions for your IAM identities in IAM.
    • Grants
      • Use grants in combination with the key policy and IAM policies to allow access to keys.
      • helps allow access to the keys in the key policy, and to allow users to delegate their access to others.
  • To allow access to a KMS CMK, a key policy MUST be used, either alone or in combination with IAM policies or grants.
  • IAM policies by themselves are not sufficient to allow access to keys, though they can be used in combination with a key policy.
  • IAM user who creates a KMS key is not considered to be the key owner and they don’t automatically have permission to use or manage the KMS key that they created.

Rotating KMS or Customer Master Keys

  • Key rotation changes only the key material, which is the cryptographic secret that is used in encryption operations.
  • KMS keys can be enabled for automatic key rotation, where KMS generates new cryptographic material for the key at a configurable interval.
  • KMS saves all previous versions of the cryptographic material in perpetuity so it can decrypt any data encrypted with that key.
  • KMS does not delete any rotated key material until you delete the KMS key.
  • All new encryption requests against a key are encrypted under the newest version of the key.
  • Rotation can be tracked in CloudWatch and CloudTrail.
  • Rotation history can be viewed for any KMS key, showing all previous rotations with timestamps. (Added April 2024)

Automatic Key Rotation

  • Automatic key rotation has the following benefits
    • properties of the KMS key like ID, ARN, region, policies, and permissions do not change.
    • applications or aliases refering the key do not need to change
    • Rotating key material does not affect the use of the KMS key in any AWS service.
  • Automatic key rotation is supported only on symmetric encryption KMS keys with key material that KMS generates i.e. Origin = AWS_KMS.
  • Automatic key rotation is not supported for
    • asymmetric keys,
    • HMAC keys,
    • keys in custom key stores, and
    • keys with imported key material.
  • AWS managed keys
    • automatically rotated every 1 year (approximately 365 days)
    • rotation cannot be enabled or disabled
  • Customer Managed keys
    • automatic key rotation is supported but is optional.
    • automatic key rotation is disabled, by default, and needs to be enabled.
    • Rotation period is configurable from 90 days to 7 years (2560 days), with a default of 365 days. (Updated April 2024 — previously fixed at 1 year.)
  • CMKs with imported key material or keys generated in a CloudHSM cluster using the KMS custom key store feature
    • do not support automatic key rotation.
    • provide flexibility to manually rotate keys as required.
    • Imported keys now support on-demand rotation (June 2025) — new key material can be imported and rotated without changing key ARN.

On-Demand Key Rotation

  • On-demand rotation allows immediate rotation of key material at any time using the RotateKeyOnDemand API. (Launched April 2024)
  • Supported for symmetric encryption KMS keys (both AWS_KMS and EXTERNAL origin as of June 2025).
  • Maximum of 25 on-demand rotations per KMS key.
  • On-demand rotations do not change existing automatic rotation schedules.
  • Cannot perform on-demand rotation on AWS managed keys, asymmetric keys, HMAC keys, or keys in custom key stores.
  • Useful for immediate compliance requirements or security incident response without waiting for the next scheduled rotation.

Manual Key Rotation

  • Manual key rotation can be performed by creating a KMS key and updating the applications or aliases to point to the new key.
  • does not retain the ID, ARN, and policies of the key.
  • can help control the rotation frequency esp. if the frequency required is less than 90 days.
  • is also a good solution for KMS keys that are not eligible for automatic or on-demand key rotation, such as asymmetric keys, HMAC keys, and keys in custom key stores.
  • For manually rotated keys, data has to be re-encrypted depending on the application’s configuration.

Rotation Pricing

  • First and second rotation of a key adds $1/month (prorated hourly) in cost.
  • Price increase is capped at the second rotation — subsequent rotations incur no additional cost (maximum $3/month per key).

KMS Deletion

  • KMS key deletion deletes the key material and all metadata associated with the key and is irreversible.
  • Data encrypted by the deleted key cannot be recovered, once the key is deleted.
  • AWS recommends disabling the key before deleting it.
  • AWS Managed and Owned keys cannot be deleted. Only Customer managed keys can be scheduled for deletion.
  • KMS never deletes the keys unless you explicitly schedule them for deletion and the mandatory waiting period expires.
  • KMS requires setting a waiting period of 7-30 days for key deletion. During the waiting period, the KMS key status and key state is Pending deletion.
    • Key pending deletion cannot be used in any cryptographic operations.
    • Key material of keys that are pending deletion is not rotated.
  • Use the GetKeyLastUsage API to verify a key has not been recently used before scheduling deletion. (Added April 2026)
  • Use the kms:TrailingDaysWithoutKeyUsage condition key to create policies that prevent accidental deletion of recently used keys.

KMS Key Usage Tracking

  • AWS KMS tracks the last usage of all KMS keys for cryptographic operations. (Launched April 2026)
  • The GetKeyLastUsage API returns the timestamp, operation type, and associated CloudTrail event ID of the last cryptographic operation performed with a key.
  • Helps identify unused keys for cleanup and cost optimization.
  • The kms:TrailingDaysWithoutKeyUsage condition key enables policy-based protection against accidental deletion of recently used keys.
  • Key-level filtering for AWS KMS API usage is available in Amazon CloudWatch metrics for enhanced operational visibility. (Launched March 2025)

KMS Multi-Region Keys

  • AWS KMS supports multi-region keys, which are AWS KMS keys in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions.
  • Multi-Region keys have the same key material and key ID, so data can be encrypted in one AWS Region and decrypted in a different AWS Region without re-encrypting or making a cross-Region call to AWS KMS.
  • Multi-Region keys never leave AWS KMS unencrypted.
  • Multi-Region keys are not global and each multi-region key needs to be replicated and managed independently.

Post-Quantum Cryptography Support

  • AWS KMS supports post-quantum cryptographic algorithms to help organizations prepare for future quantum computing threats.
  • ML-DSA (Module-Lattice Digital Signature Algorithm) – Added June 2025
    • Supports FIPS 204 standard for quantum-resistant digital signatures.
    • Available key specs: ML_DSA_44, ML_DSA_65, ML_DSA_87 (varying security levels).
    • Keys are generated and used within FIPS 140-3 Level 3 certified HSMs.
    • Use cases include signing firmware, operating systems, applications, and other artifacts.
  • Hybrid Post-Quantum TLS (ML-KEM) – Added 2025
    • AWS KMS endpoints support Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for hybrid post-quantum key agreement.
    • Combines classical key exchange (X25519) with post-quantum algorithms (ML-KEM) for defense-in-depth.
    • Protects against “harvest now, decrypt later” attacks where adversaries store encrypted data for future quantum decryption.
    • Available on non-FIPS endpoints in all AWS Regions in the aws partition.
  • EdDSA (Edwards-curve Digital Signature Algorithm) – Added November 2025
    • Supports Ed25519 via the ECC_NIST_EDWARDS25519 key spec.
    • Provides 128-bit security level equivalent to NIST P-256.
    • Offers faster signing performance and smaller signature/public key sizes (64 bytes / 32 bytes).

KMS Features

  • Create keys with a unique alias and description
  • Import your own keys
  • Control which IAM users and roles can manage keys
  • Control which IAM users and roles can use keys to encrypt & decrypt data
  • Choose to have AWS KMS automatically rotate keys with configurable rotation periods (90 days to 7 years)
  • Perform on-demand key rotation at any time
  • Temporarily disable keys so they cannot be used by anyone
  • Re-enable disabled keys
  • Delete keys that you no longer use
  • Audit use of keys by inspecting logs in AWS CloudTrail
  • Track last usage of keys with the GetKeyLastUsage API
  • Monitor key usage with key-level CloudWatch metrics

KMS with VPC Interface Endpoint

  • AWS KMS can be connected through a private interface endpoint in the Virtual Private Cloud (VPC).
  • Interface VPC endpoint ensures the communication between the VPC and AWS KMS is conducted entirely within the AWS network.
  • Interface VPC endpoint connects the VPC directly to KMS without an internet gateway, NAT device, VPN, or Direct Connect connection.
  • Instances in the VPC do not need public IP addresses to communicate with AWS KMS.

KMS vs CloudHSM

AWS KMS vs CloudHSM

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are designing a personal document-archiving solution for your global enterprise with thousands of employee. Each employee has potentially gigabytes of data to be backed up in this archiving solution. The solution will be exposed to he employees as an application, where they can just drag and drop their files to the archiving system. Employees can retrieve their archives through a web interface. The corporate network has high bandwidth AWS DirectConnect connectivity to AWS. You have regulatory requirements that all data needs to be encrypted before being uploaded to the cloud. How do you implement this in a highly available and cost efficient way?
    1. Manage encryption keys on-premise in an encrypted relational database. Set up an on-premises server with sufficient storage to temporarily store files and then upload them to Amazon S3, providing a client-side master key. (Storing temporary increases cost and not a high availability option)
    2. Manage encryption keys in a Hardware Security Module (HSM) appliance on-premise server with sufficient storage to temporarily store, encrypt, and upload files directly into amazon Glacier. (Not cost effective)
    3. Manage encryption keys in amazon Key Management Service (KMS), upload to amazon simple storage service (s3) with client-side encryption using a KMS customer master key ID and configure Amazon S3 lifecycle policies to store each object using the amazon glacier storage tier. (With CSE-KMS the encryption happens at client side before the object is upload to S3 and KMS is cost effective as well)
    4. Manage encryption keys in an AWS CloudHSM appliance. Encrypt files prior to uploading on the employee desktop and then upload directly into amazon glacier (Not cost effective)
  2. An AWS customer is deploying an application that is composed of an Auto Scaling group of EC2 Instances. The customers security policy requires that every outbound connection from these instances to any other service within the customers Virtual Private Cloud must be authenticated using a unique x 509 certificate that contains the specific instance-id. In addition an x 509 certificates must be designed by the customer’s Key management service in order to be trusted for authentication.
    Which of the following configurations will support these requirements?
    1. Configure an IAM Role that grants access to an Amazon S3 object containing a signed certificate and configure the Auto Scaling group to launch instances with this role. Have the instances bootstrap get the certificate from Amazon S3 upon first boot.
    2. Embed a certificate into the Amazon Machine Image that is used by the Auto Scaling group Have the launched instances generate a certificate signature request with the instance’s assigned instance-id to the Key management service for signature.
    3. Configure the Auto Scaling group to send an SNS notification of the launch of a new instance to the trusted key management service. Have the Key management service generate a signed certificate and send it directly to the newly launched instance.
    4. Configure the launched instances to generate a new certificate upon first boot. Have the Key management service poll the AutoScaling group for associated instances and send new instances a certificate signature that contains the specific instance-id.
  3. A company has a customer master key (CMK) with imported key materials. Company policy requires that all encryption keys must be rotated every year. What can be done to implement the above policy?
    1. Enable automatic key rotation annually for the CMK.
    2. Use AWS Command Line interface to create an AWS Lambda function to rotate the existing CMK annually.
    3. Import new key material to the existing CMK and manually rotate the CMK.
    4. Create a new CMK, import new key material to it, and point the key alias to the new CMK. (NOTE: As of June 2025, on-demand rotation is now supported for imported keys, allowing rotation without changing the key ARN. However, this answer remains valid for the exam context.)
  4. An organization policy states that all encryption keys must be automatically rotated every 12 months. Which AWS Key Management Service (KMS) key type should be used to meet this requirement? (Select TWO)
    1. AWS managed Customer Master Key (CMK) (Automatically rotated every year.)
    2. Customer managed CMK with AWS generated key material (Supports configurable automatic rotation from 90 days to 7 years.)
    3. Customer managed CMK with imported key material
    4. AWS managed data key
  5. A security team needs to rotate a customer managed KMS key immediately due to a potential security incident. The key uses AWS-generated key material. What is the MOST efficient approach? [New Question – 2024 Feature]
    1. Create a new KMS key and update all aliases to point to the new key.
    2. Disable automatic rotation and manually reimport the key material.
    3. Use the RotateKeyOnDemand API to immediately rotate the key material. (On-demand rotation immediately generates new key material while preserving key ID, ARN, and policies.)
    4. Schedule the key for deletion and create a replacement key.
  6. An organization wants to configure KMS key rotation to occur every 180 days to meet a compliance requirement. Which configuration is correct? [New Question – 2024 Feature]
    1. Enable automatic rotation with the default settings, as KMS rotates keys every 180 days.
    2. Enable automatic rotation and set the rotation period to 180 days using the EnableKeyRotation API with the RotationPeriodInDays parameter. (Since April 2024, rotation period is configurable between 90-2560 days.)
    3. Automatic rotation does not support custom intervals; use manual rotation instead.
    4. Contact AWS support to configure a custom rotation schedule.
  7. A company wants to protect its digital signatures against future quantum computing threats. Which AWS KMS key spec should be used? [New Question – 2025 Feature]
    1. RSA_4096
    2. ECC_NIST_P521
    3. ML_DSA_65 (ML-DSA is a post-quantum digital signature algorithm (FIPS 204) supported in KMS since June 2025, designed to resist quantum computing attacks.)
    4. HMAC_512

References

Google Cloud KMS Key Management Service

~ jayendrapatil

Google Cloud KMS Key Management Service

  • Google Cloud KMS – Key Management Service provides a centralized, scalable, fast cloud key management service to manage encryption keys
  • KMS helps apply hardware security modules (HSMs) effortlessly to the most sensitive data by just a toggle between software- and hardware-protected encryption keys with the press of a button.
  • KMS provides support for external keys using Cloud External Key Manager to protect the data in Google Cloud and separate the data from the key

Cloud KMS Keys, Keys Versions, and Key Rings

  • A Cloud KMS key is a named object containing one or more key versions, along with metadata for the key.
  • A key exists on exactly one key ring tied to a specific location.
  • After creation, a key cannot be moved to another location or exported.

Google Cloud KMS Keys, Key Rings, and Key VersionsKey

  • A named object representing a cryptographic key that is used for a specific purpose. The key material – the actual bits used for cryptographic operations – can change over time as new key versions are created
  • Key is the most important object for understanding KMS usage.
  • Key purpose and other attributes of the key are connected with and managed using the key.
  • IAM permissions and roles can be used to allow and deny access to keys
  • Cloud KMS supports both asymmetric keys and symmetric keys.
    • Symmetric key
      • is used for symmetric encryption to protect some corpus of data for e.g., using AES-256 to encrypt a block of plaintext.
    • Asymmetric key
      • consists of a public and private key.
      • can be used for asymmetric encryption, or for creating digital signatures.
  • Key’s type (symmetric or asymmetric) can’t be changed after key creation

Key Ring

  • A grouping of keys for organizational purposes.
  • Key ring belongs to Google Cloud project and resides in a specific location
  • Keys inherit IAM policies from the Key Ring that contains them.
  • Grouping keys with related permissions in a key ring allows you to grant, revoke, or modify permissions to those keys at the key ring level without needing to act on each key individually.
  • Key rings provide convenience and categorization
  • To prevent resource name collisions, a key ring cannot be deleted.
  • Key rings and keys do not have billable costs or quota limitations, so their continued existence does not affect costs or production limits.

Key Metadata

  • Includes resource names, properties of KMS resources such as IAM policies, key type, key size, key state, and any other derived data
  • Key metadata can be managed differently than the key material.

Key Version

  • Represents the key material associated with a key at some point in time.
  • Key version is the resource that contains the actual key material.
  • Granting access to a key also grants access to all of its enabled versions. Access to a key version cannot be managed.
  • A key version can be disabled or destroyed without affecting other versions
  • Disabling or destroying a key also disables or destroys each key version.
  • Versions are numbered sequentially, beginning with version 1.
  • When a key is rotated, a new key version is created with new key material.
  • The same logical key can have multiple versions over time, thus limiting the use of any single version.
  • Symmetric keys will always have a primary version. This version is used for encrypting by default, if not version is specified
  • Asymmetric keys do not have primary versions, and a version must be specified when using the key.
  • When Cloud KMS performs decryption using symmetric keys, it identifies automatically which key version is needed to perform the decryption.

Key States

  • A key version’s state is always one of the following:
    • Pending generation (PENDING_GENERATION)
      • Applies to asymmetric keys only
      • is still being generated and can’t be used, enabled, disabled, or destroyed yet.
      • KMS will automatically change the state to enabled as soon as the version is ready.
    • Enabled (ENABLED)
      • is ready for use.
    • Disabled (DISABLED)
      • may not be used, but the key material is still available, and the version can be placed back into the enabled state.
    • Scheduled for destruction (DESTROY_SCHEDULED):
      • is scheduled for destruction, and will be destroyed soon.
      • can be placed back into the disabled state.
    • Destroyed (DESTROYED)
      • is destroyed, and the key material is no longer stored in Cloud KMS.
      • If the key version was used
        • for asymmetric or symmetric encryption, any ciphertext encrypted with this version is not recoverable.
        • for digital signing, new signatures cannot be created.
      • may not leave the destroyed state once entered.
  • A key version can only be used when it is enabled.

Google Cloud KMS Key States

Key Rotation

  • For symmetric encryption, periodically and automatically rotating keys is a recommended security practice
  • Cloud MS does not support automatic rotation of asymmetric keys and has to be done manually
  • With key rotation, data encrypted with previous key versions is not automatically re-encrypted with the new key version.
  • Rotating keys provides several benefits:
    • Limiting the number of messages encrypted with the same key version helps prevent brute-force attacks enabled by cryptanalysis.
    • In the event that a key is compromised, regular rotation limits the number of actual messages vulnerable to compromise.
    • If you suspect that a key version is compromised, disable it and revoke access to it as soon as possible.
    • Regular key rotation helps validate the key rotation procedures before a real-life security incident occurs.
    • Regular key rotation ensures that the system is resilient to manual rotation, whether due to a security breach or the need to migrate your application to a stronger cryptographic algorithm.

Key Hierarchy

Google Cloud KMS Key Hierarchy

  • Data Encryption Key (DEK)
    • A key used to encrypt data.
  • Key Encryption Key (KEK)
    • A key used to encrypt, or wrap, a DEK.
    • All Cloud KMS platform options (software, hardware, and external backends) allow you to control KEK.
  • KMS Master Key
    • The key used to encrypt the KEK.
    • This key is distributed in memory.
    • KMS Master Key is backed up on hardware devices.
  • Root KMS
    • Google’s internal key management service.

Cloud KMS Locations

  • Within a project, Cloud KMS resources can be created in one of many locations.
  • A key’s location impacts the performance of applications using the key
  • Regional
    • data centers exist in a specific geographical place
  • Dual-regional
    • data centers exist in two specific geographical places.
  • Multi-regional
    • data centers are spread across a general geographical area
  • Global
    • special multi-region with its data centers spread throughout the world
  • Reading and writing resources or associated metadata in dual-regional or multi-regional locations, including the global location may be slower than reading or writing from a single region.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References

Google_Cloud_Key_Management_Service_KMS

Google Cloud Data Encryption

~ jayendrapatil

Google Cloud Data Encryption

  • Encryption is a process that takes legible data as input (often called plaintext) and transforms it into an output (often called ciphertext) that reveals little or no information about the plaintext
  • Encryption can be used to protect data in three states:
    • Encryption at Rest protects the data from a system compromise or data exfiltration by encrypting data while stored.
    • Encryption in Transit: protects the data if communications are intercepted while data moves between the site and the cloud provider or between two services.
    • Encryption in Use: protects the data when it is being used by servers to run computations, e.g. homomorphic encryption.

Encryption at Rest

  • Google uses several layers of encryption to protect customer data at rest.
  • All customer content stored at rest is encrypted, without any action required from the customer, using one or more encryption mechanisms.
  • All data stored in Google Cloud is encrypted at the storage level using AES256
  • Google encrypts data prior to it being written to disk.

Google Cloud Encryption At Rest Options

Google Cloud Default Encryption

  • Data for storage is split into chunks
  • Each chunk is encrypted with a unique Data Encryption Key (DEK)
  • Two chunks will not have the same encryption key, even if they are part of the same Cloud Storage object, owned by the same customer, or stored on the same machine
  • If a chunk of data is updated, it is encrypted with a new key, rather than by reusing the existing key
  • Data encryption keys are stored with the data because of the high volume of keys at Google, and the need for low latency and high availability
  • Backups are encrypted using a separate DEK
  • Data encryption keys are encrypted with (“wrapped” by) Key Encryption Keys (KEK) also referred to as Envelope Encryption
  • KEKs are stored centrally inside Google’s Key Management Service (KMS)
  • Having a smaller number of KEKs than DEKs and using a central KMS makes storing and encrypting data at Google scale manageable, and allows us to track and control data access from a central point.
  • KEKs are not exportable from Google’s KMS by design; all encryption and decryption with these keys must be done within KMS
  • KMS can automatically rotate KEKs at regular time intervals
  • KMS maintains an active key with a set of historical keys for decryption
  • Google uses a common cryptographic library, Tink, which incorporates the FIPS 140–2 validated module, BoringCrypto, to implement encryption consistently across almost all Google Cloud products.

Google Cloud Default Data Encryption

Google Cloud Default Decryption

  • Service makes a call to the storage system for the data it needs.
  • The storage system identifies the chunks in which that data is stored (the chunk IDs) and where they are stored.
  • For each chunk, the storage system pulls the wrapped DEK stored with that chunk and sends it to KMS for unwrapping.
  • The storage system verifies that the identified job is allowed to access that data chunk based on a job identifier, and using the chunk ID
  • KMS verifies that the storage system is authorized both to use the KEK associated with the service and to unwrap that specific DEK.
  • KMS passes the unwrapped DEK back to the storage system, which decrypts the data chunk and passes it to the service.

Google Cloud Decryption

Cloud Key Management Service – KMS

  • Cloud KMS help centralized management of encryption keys
  • Google’s Key Management Service is redundant and globally distributed.
  • Cloud KMS allows the customer to manage the encryption keys  (CMEK)
  • A CMEK or Customer Managed Encryption Key can be used in both server-side encryption (SSE) and client-side encryption (CSE).
  • CMEK key can be used with KMS encrypt/decrypt and also be attached to a bucket, GCE disk, etc.
  • CMEK supports importing your own key material, which is useful for migrations.

Customer Supplied Encryption Keys – CSEKs

  • Customer-Supplied Encryption Keys (CSEK) allows you to supply your own encryption keys, Google uses the key to protect the Google-generated keys used to encrypt and decrypt your data.
  • CSEK support only Google Cloud Storage and Google Compute Engine.
  • CSEK Encryption
    • User provides a raw CSEK as part of an API call.
    • The key is transmitted from the Google front end to the storage system’s memory
    • This key is used as the Key Encryption Key (KEK) in Google Cloud Storage for the data.
  • CSEK Decryption
    • Raw CSEK is used to unwrap wrapped chunk keys, to create raw chunk keys in memory.
    • These are used to decrypt data chunks stored in the storage systems.
    • These keys are used as the data encryption keys (DEK) in Google Cloud Storage for your data.
  • Raw CSEK, CSEK-derived keys, and raw chunk/disk keys are never stored on disk unencrypted.
  • Raw chunk/disk keys are stored wrapped with CSEK-derived keys, and with Google keys where automatic restart is used. Google does not permanently store your keys on its servers.

Google Cloud Encryption At Rest Decision Tree

Encryption in Transit

  • Google applies several security measures to help ensure the authenticity, integrity, and privacy of data in transit.
    • Authentication: data source verification, either a human or a process, and destination.
    • Integrity: ensures data sent arrives at its destination unaltered.
    • Encryption: ensures data is unintelligible to keep it private.
  • Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted.
  • Data is encrypted and authenticated in transit at one or more network layers when it moves outside physical boundaries not controlled by Google or on behalf of Google.
  • Depending on the connection that is being made, Google applies default protections to data in transit for e.g, communications are secured between the user and the Google Front End (GFE) using TLS.
  • Google Cloud customers with additional requirements for encryption of data over WAN can choose to implement further protections for data as it moves from a user to an application or VM to VM. These protections include IPSec tunnels, Gmail S/MIME, managed SSL certificates, and Istio.

Google Cloud Encryption In Transit

  • [Connection A] – User to Google Front End
    • Google accepts requests from around the world using a globally distributed system called the Google Front End (GFE)
    • GFE terminates traffic for incoming HTTP(S), TCP, and TLS proxy traffic, provides DDoS attack countermeasures, and routes and load balances traffic to the Google Cloud services themselves.
    • User requests to customer applications can be routed through a Google Cloud HTTP(S) or TCP/SSL Proxy Load Balancer external load balancer
    • Google automatically encrypts traffic between GFEs and the backends load balancers that reside within VPC networks
  • [Connection B] – User to customer application hosted on Google Cloud
    • Cloud VPN or Interconnect can help secure a direct connection to a VM using an external IP or network load balancer IP. As the connection does not go through GFE, it’s not encrypted by default.
  • [Connection C] – Virtual Machine to Virtual Machine
    • VM to VM connections is encrypted if they leave a physical boundary, and are authenticated within the physical boundary.
    • VM to VM traffic, using external IP addresses, is not encrypted by default, and its security is provided at the user’s discretion
  • [Connection D] – Virtual Machine to Google Cloud Service
    • Connectivity to Google APIs and services can be protected using private google access or private service access
    • From the VM to the GFE, Google Cloud services support protecting these connections with TLS by default
  • [Connection E] – Google Cloud Service to Google Cloud Service
    • Routing from one Google service to another takes place on Google Cloud network backbone and may require routing traffic outside of physical boundaries controlled by or on behalf of Google
    • Connections between these services are encrypted if they leave a physical boundary, and authenticated within the physical boundary.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References

AWS S3 Data Protection

~ Last updated on : ~ jayendrapatil ~ 4 Comments

AWS S3 Data Protection

  • S3 provides S3 data protection using highly durable storage infrastructure designed for mission-critical and primary data storage.
  • Objects are redundantly stored on multiple devices across multiple facilities in an S3 region.
  • S3 PUT and PUT Object copy operations synchronously store the data across multiple facilities before returning SUCCESS.
  • Once the objects are stored, S3 maintains its durability by quickly detecting and repairing any lost redundancy.
  • S3 also regularly verifies the integrity of data stored using checksums. If  S3 detects data corruption, it is repaired using redundant data.
  • In addition, S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data
  • Data protection against accidental overwrites and deletions can be added by enabling Versioning to preserve, retrieve and restore every version of the object stored
  • S3 also provides the ability to protect data in transit (as it travels to and from S3) and at rest (while it is stored in S3)

S3 Encryption

Refer blog post @ S3 Encryption

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A customer is leveraging Amazon Simple Storage Service in eu-west-1 to store static content for a web-based property. The customer is storing objects using the Standard Storage class. Where are the customers objects replicated?
    1. A single facility in eu-west-1 and a single facility in eu-central-1
    2. A single facility in eu-west-1 and a single facility in us-east-1
    3. Multiple facilities in eu-west-1
    4. A single facility in eu-west-1
  2. A system admin is planning to encrypt all objects being uploaded to S3 from an application. The system admin does not want to implement his own encryption algorithm; instead he is planning to use server side encryption by supplying his own key (SSE-C). Which parameter is not required while making a call for SSE-C?
    1. x-amz-server-side-encryption-customer-key-AES-256
    2. x-amz-server-side-encryption-customer-key
    3. x-amz-server-side-encryption-customer-algorithm
    4. x-amz-server-side-encryption-customer-key-MD5

References

AWS_S3_Security