Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save krishnasrinivas/67f57d0c7160633296355c1431717ec3 to your computer and use it in GitHub Desktop.
Save krishnasrinivas/67f57d0c7160633296355c1431717ec3 to your computer and use it in GitHub Desktop.

Service Side Encryption (SSE) in AWS S3:

Three types of SSE supported.

  • SSE-C - client provides data encryption key for every get/put object calls. AWS S3 does not store client provided data encryption key. Client provided data encryption key may be generated by AWS KMS for every get/put object calls. It is user responsibility to securely save/map data encryption keys generated by KMS and AWS S3 does not store any data encryption key.
  • SSE-S3 - client does not provide any encryption key for any get/put object calls. AWS S3 uses one single key (generated at first time) to encrypt/decrypt objects. Accordingly AWS docs, this key is stored along with object data.
  • SSE-KMS - client provides Customer Master Key (CMK) for any get/put object calls. AWS S3 uses client's provided CMK to generate data keys using KMS to encrypt/decrypt objects. This data key is encrypted using KMS and is stored along with object data.

Below bucket policy prevents uploading unencrypted objects (even by owner/auth user).

  • SSE-KMS:
{
   "Version":"2012-10-17",
   "Id":"PutObjPolicy",
   "Statement":[{
         "Sid":"DenyUnEncryptedObjectUploads",
         "Effect":"Deny",
         "Principal":"*",
         "Action":"s3:PutObject",
         "Resource":"arn:aws:s3:::YourBucket/*",
         "Condition":{
            "StringNotEquals":{
               "s3:x-amz-server-side-encryption":"aws:kms"
            }
         }
      }
   ]
}
  • SSE-S3:
{
  "Version": "2012-10-17",
  "Id": "PutObjPolicy",
  "Statement": [
    {
      "Sid": "DenyIncorrectEncryptionHeader",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::YourBucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    },
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::YourBucket/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }
  ]
}

AWS KMS:

  • KMS provides API to create Customer Master Key (CMK) which is not retrievable.
  • KMS provides APIs to encrypt/decrypt data of max. 4KiB size.
  • KMS provides APIs to generate data keys using CMK.
  • KMS is not a vault i.e. there is no way user generated keys (even data keys generated by KMS) are stored in KMS.
  • KMS uses HSMs underneath.
  • KMS is a general purpose key management service it can be hooked into any AWS services like S3 (or even services outside of AWS).

Hashicorp Vault:

  • In simple words, it is encrypted key/value store.
  • All keys/values are stored in vault. It comes with default expiry time and sealing/unsealing.
  • It also provides ecnrypt/decrypt functions like AWS KMS.
  • By default, it is not HA and fault tolerance. The recommendation is to use Consul as data store which provides HA and fault tolerance.

Azure Vault:

  • It is encrypted key/value store along with AWS KMS features.
  • It uses HSM to perform encrypt/decrypt operations.

Keywhiz:

  • It is same as Hashicorp Vault written in Java.

https://gist.github.com/maxvt/bb49a6c7243163b8120625fc8ae3f3cd is nice work of comparing various key management systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment