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.
- 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
- 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.
- 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.
- 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.
- 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)
- 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.
- 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.
- 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
- data centers exist in a specific geographical place
- data centers exist in two specific geographical places.
- data centers are spread across a general geographical area
- 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.
AWS S3 Data Protection
- Amazon S3 provides a 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 Data Protection
- S3 allows protection of data in-transit by enabling communication via SSL or using client-side encryption
Data at Rest
- S3 supports both client side encryption and server side encryption for protecting data at rest
- Using Server-Side Encryption, S3 encrypts the object before saving it on disks in its data centers and decrypt it when the objects are downloaded
- Using Client-Side Encryption, data is encrypted at client-side and uploaded to S3. In this case, the encryption process, the encryption keys, and related tools are managed by the user.
- 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 or unencrypted objects and is handled transparently by S3
Server-Side Encryption with S3-Managed Keys (SSE-S3)
- Each object is encrypted with a unique data key employing strong multi-factor encryption.
- SSE-S3 encrypts the data key with a master 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
Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS)
- SSE-KMS is similar to SSE-S3, but it uses AWS Key management Services (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 customer master keys (CMKs) to encrypt the S3 objects.
- Master key is never made available
- KMS enables you to centrally create encryption keys, define the policies that control how keys can be used
- Allows audit use of key usage to prove they are being used correctly, by inspecting logs in AWS CloudTrail
- Allows keys to temporarily disabled and re-enabled
- Allows keys to be rotated regularly
- 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 of the objects in S3.
- SSE-KMS provides the option to create and manage encryption keys yourself, or use a default customer master key (CMK) that is unique to you, the service you’re using, and the region you’re working in.
- Creating and Managing CMK gives more flexibility, including the ability to create, rotate, disable, and define access controls, and to audit the encryption keys used to protect the data.
- Data keys used to encrypt your 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 master key under the account.
- Client requests are authenticated based on whether they have access to use the master key.
- A new data encryption key is created, and a copy of it is encrypted under the master 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.
Server-Side Encryption with Customer-Provided Keys (SSE-C)
- 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 matches decrypts the object 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 request must be done through HTTPS and S3 will reject any requests made over HTTP when using SSE-C.
- For security considerations, AWS recommends to consider any key sent erroneously using HTTP to be compromised and discarded or rotated
- S3 does not store the encryption key provided. Instead, it stores a randomly salted HMAC value of the encryption key which can be used to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means, if you lose the encryption key, you lose the object.
Client-side encryption refers to encrypting data before sending it to Amazon S3 and decrypting the data after downloading it
AWS KMS-managed Customer Master Key (CMK)
- Customer can maintain the encryption CMK with AWS KMS and can provide the CMK id to the client to encrypt the data
- Uploading Object
- AWS 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 plain text version for encrypting the data and cipher blob to be uploaded with the object as object metadata
- Client obtains a unique data encryption key for each object it uploads.
- AWS S3 encryption client uploads the encrypted data and the cipher blob with object metadata
- Download Object
- AWS Client first downloads the encrypted object from S3 along with the cipher blob version of the data encryption key stored as object metadata
- AWS Client then sends the cipher blob to AWS KMS to get the plain text version of the same, so that it can decrypt the object data.
Client-Side master key
- Encryption master keys are completely maintained at Client-side
- Uploading Object
- S3 encryption client ( for e.g. AmazonS3EncryptionClient in the AWS SDK for Java) locally generates randomly a one-time-use symmetric key (also known as a 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 Amazon S3 and also saves the encrypted data key and its material description as object metadata (x-amz-meta-x-amz-key) in Amazon S3 by default
- Downloading Object
- Client first downloads the encrypted object from Amazon 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
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.
- 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
- Use Amazon S3 server-side encryption with AWS Key Management Service managed keys
- Use Amazon S3 server-side encryption with customer-provided keys
- Use Amazon S3 server-side encryption with EC2 key pair.
- Use Amazon S3 bucket policies to restrict access to the data at rest.
- Encrypt the data on the client-side before ingesting to Amazon S3 using their own master key
- Use SSL to encrypt the data while in transit to Amazon S3.
- 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?
- The user should use the same encryption key for all versions of the same object
- It is possible to have different encryption keys for different versions of the same object
- AWS S3 does not allow the user to upload his own keys for server side encryption
- The SSE-C does not work when versioning is enabled
- 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?
- The admin should upload his secret key to the AWS console and let S3 decrypt the objects
- 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
- S3 does not support client supplied encryption keys for server side encryption
- The admin should send the keys and encryption algorithm with each API call
- 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?
- User should not use his own security key as it is not secure
- Configure S3 to rotate the user’s encryption key at regular intervals
- Configure S3 to store the user’s keys securely with SSL
- Keep rotating the encryption key manually at the client side
- 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?
- 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?
- A single facility in eu-west-1 and a single facility in eu-central-1
- A single facility in eu-west-1 and a single facility in us-east-1
- Multiple facilities in eu-west-1
- A single facility in eu-west-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?
- 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)
- 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)
- 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)
- 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)
- A user has enabled server side encryption with S3. The user downloads the encrypted object from S3. How can the user decrypt it?
- S3 does not support server side encryption
- S3 provides a server side key to decrypt the object
- The user needs to decrypt the object using their own private key
- S3 manages encryption and decryption automatically
- 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?