Please enable JavaScript.
Coggle requires JavaScript to display documents.
KMS & client side encryptuin (definition (Generate customer master key…
KMS & client side encryptuin
definition
Create & control encryption key used to encypt data
For EBS, S3, RDS and redshift
Generate customer master key and data key
diagram
data key- used to encrypt the data . Data key can be brought by customer
CMS used to encrypted the data key
feature
Customer Master key
can never be exported
If need to export, need to use Cloud HSM
How to setup ?
Define key adminsitration permission
defnie user that can administrer (but can't use) the key
key usage permission
define user that can use the key to encrypt and decrypt the data but can't administre the key
where it is store ?
in aWS share environment
May not comply to regulatory
solution: can use AWS HSM
KMS is integrated with CloudTrail, which provides you the ability to audit who used which keys, on which resource and when
● Customer master keys (CMKs) are used to control access to data encryption keys that encrypt and decrypt your data
● You can choose to have KMS automatically rotate master keys created within KMS once per year
without the need to re-encrypt data that has already been encrypted with your master key.
KMS also saves the CMK's older cryptographic material
so it can be used to decrypt data that it encrypted.
● To help ensure that your keys and your data is highly available, KMS stores multiple copies of encrypted
versions of your keys in systems that are designed for 99.999999999% durability.
data key
Encryption keys that you can use to encrypt data, including large amounts of data and other
data encryption keys.
○ You can use CMKs to generate, encrypt, and decrypt data keys. However, KMS does not store,
manage, or track your data keys, or perform cryptographic operations with data keys.
○ Data keys can be generated at 128-bit or 256-bit lengths and encrypted under a master key you
defin
3 type
custimer maged type
. You have full control as you mange, create and own the CMK
over these CMKs, including establishing and maintaining their key policies, IAM policies, and
grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating
aliases that refer to the CMK, and scheduling the CMKs for deletion.
AWS Managed CMK
are CMKs in your account that are created, managed, and used on your
behalf by an AWS service that integrates with KMS. You can view the AWS managed CMKs in
your account, view their key policies, and audit their use in CloudTrail logs. However, you cannot
manage these CMKs or change their permissions. And, you cannot use AWS managed CMKs in
cryptographic operations directly; the service that creates them uses them on your behalf
AWS Owned CMK
are not in your AWS account. They are part of a collection of CMKs that AWS
owns and manages for use in multiple AWS accounts. AWS services can use AWS owned CMK
key policy
When you create a CMK, permissions that determine who can use and manage that CMK
are contained in a document called the key policy.
Key material (=CMK)
A CMK contains the key material used to encrypt and decrypt data. When you create a CMK, by default
AWS KMS generates the key material for that CMK. But you can create a CMK without key material and
then import your own key material into that CMK.
● When you import key material, you can specify an expiration date. When the key material expires, KMS
deletes the key material and the CMK becomes unusable. You can also delete key material on demand.
Deleting key
Deleting a CMK deletes the key material and all metadata associated with the CMK and is irreversible.
You can no longer decrypt the data that was encrypted under that CMK, which means that data become unrecoverable
● You can temporarily disable keys so they cannot be used by anyone.
● KMS supports custom key stores backed by AWS CloudHSM clusters. A key store is a secure location
for storing cryptographic keys.
● You can connect directly to AWS KMS through a private endpoint in your VPC instead of connecting
over the internet. When you use a VPC endpoint, communication between your VPC and AWS KMS is
conducted entirely within the AWS network.
HSM
features
A hardware security module (HSM) is a hardware appliance that provides secure key storage and cryptographic operations within a tamper-resistant hardware device.
IT is designed and validated to government standards for secure key management.
HSMs are designed to securely store cryptographic key material and use the key material without exposing it outside the cryptographic boundary of the appliance.
It is used direcrly from application
. AWS CloudHSM helps you comply with strict key management requirements within the AWS Cloud without sacrificing application performance.
Manage only by customer
You can securely generate, store, and manage the cryptographic keys used for data encryption in a way that ensures that only you have access to the keys
Diff between HSM And KMS
client side encryption
As previously mentioned, with CSE, encryption takes place before data is submitted to AWS and decryption after data is retrieved from AWS.
The encryption software you specify supplies the encryption key used.
Currently, encryption clients are available for Amazon S3, Amazon DynamoDB, the Amazon EMR File System (EMRFS), and the AWS Encryption SDK.
The AWS Encryption SDK is an encryption library that helps make it easier for developers to implement encryption best practices in their applications.
The SDK enables developers to focus on the core functionality of their application, rather than on how to best encrypt and decrypt data.
The encryption client can use keys provided by an on-premises key management infrastructure (KMI), which provides the client-side master key (CSE-C).
The CSE-C and your unencrypted data are never sent to AWS.
It's important that you safely manage your encryption keys. If you lose them, you won't be able to decrypt your data.
The CSE-C may also be requested by an application running on an EC2 instance with the encryption client. Keys may also be provided by a KMI running on an EC2 instance.
For more information about these differences, see
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html
.
SSe-S3
Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it rotates regularly. Amazon S3 server-side encryption uses one of the strongest block ciphers available to encrypt your data, 256-bit Advanced Encryption Standard (AES-256).
With SSE-S3, you can encrypt data on upload simply by adding an additional request header when writing the object. Decryption happens automatically when data is retrieved. Note that metadata, which you can include with your object, is not encrypted.
Therefore, AWS recommends that customers do not place sensitive information in Amazon S3 metadata. SSE-S3 provides additional security by storing the encrypted data and encryption keys in different hosts. SSE-S3 also makes it possible for you to enforce encryption requirements. For example, you can create and apply bucket policies that require that only encrypted data can be uploaded to your buckets. Choose SSE-S3 if you prefer to have AWS manage your keys, as opposed to client-side encryption.
