KMS, SSM Parameter Store, Shield, WAF

Encryption 101

Encryption in flight: Achieved via SSL, your connection to the web server is encrypted, so no one can man in the middle you and sniff the packet that you're sending to find sensitive data

SSL certificates is used to established the secure connection. Certificate is used to authenticate the other party.

Server-side encryption at rest: Done by encrypting the data in rest that's stored in the database. The encryption and decryption key must be stored and managed somewhere a key server. The server will talk to it to retrieve the key to do encryption and decryption. The data is decrypted before the data is sent back to the client.

Client side encryption: The data is encrypted by the client and never decrypted by the server. The data will be decrypted by the receiving client. Could leverage envelope encryption to do client side encryption.

KMS

Key management service. A service that will manage the encryption key for us. Used IAM for authorization the access to the keys that's stored in KMS.

Every key usage will be audited using CloudTrail! Which is very nice to track who used the key and when.

Don't store secrets in plaintext, this is very bad!

KMS keys

Symmetric (AES-256 keys): Single key used for encryption and decryption. All AWS service that integrated with KMS use symmetric keys.

Asymmetric (RSA & ECC key pair): Public and private key. Encrypt/decrypt, sign/verify operations. Used for encryption outside of AWS by users who can't call KMS API.

AWS can own keys and they are free. SSE-S3, SSE-SQS.

AWS Managed keys are also free, but only within service that they are assigned to

Customer managed keys: cost $1 / month. You will also pay for the API calls to KMS.

Keys will be automatically rotated every 1 year.

Key scopes

The keys are scoped per region. So other region cannot access the KMS key from another region. You would need snapshots to restore the snapshot with encryption enabled with another KMS key. Same key cannot be used!!!

Key policies

Default KMS key policy if you don't have one: it allows everyone in this account to have access to this key

Custom KMS key policy: You define users, role that have access to the KMS key. Can share KMS key via cross-account sharing, then you can copy encrypted snapshots across different accounts which is cool.

Multi-region keys

The same key is going to be replicated across multiple region. This is so that you can encrypt in one region and decrypt it in another region as well.

They are possible because of same key ID, key material, and automatic rotation.

Multi-region are not global! Each are managed independently, therefore, it is not recommended to use them. Use it only for global client-side encryption.

DynanoDB global table + multi-region keys + client-side encryption

This is so that you can encrypt specific column of the DynanoDB it will only be decrypted to specific client. Protection against even database admin.

Same concept can also applied to Aurora as well.

S3 Replication Encryption

For object encryption with SSE-KMS you need to enable it. You specify which key to encrypt with.

Object encrypted with SSE-C are never replicated.

SS3-S3 are replicated by default.

Then you also have to share the KMS key with the other user and have sufficient permission to use the key.

Then you can just launch the EC2 instances from the AMI that's encrypted, then they can create the same encrypted AMI with their own KMS keys.