Vipul Pathak

S3 Security is divided in 4 categories- Privacy, Log Trail, Access Permissions and Encryption.

By Default, when a bucket is created, it is marked as Private and hence no data can be shared from it until Privacy level is explicitly changed.

Similarly, when a bucket is accessed and a request is made, Logging can be configured to create Access logs/Audit trails in another bucket or even in another AWS account.

Access Permissions falls in two sub-categories- Permissions Through Bucket Policies and Permissions Controlled via ACLs. Permissions set on a bucket level are applied on all resident objects, while permissions can be applied on individual objects in a fine grained manner using the legacy ACLs method. Bucket Policies are similar to IAM Policies and they are both defined in JSON and written using AWS’ Access Policy Language. When all the multiple mechanisms (IAM Policies, Bucket Policies and ACLs) are in effect, S3 resolves requests by Union‘ing all policies/ACLs. General rules of thumb used are- (1) When explicit mention of Allow and Deny are missing, then the assumed decision is a Deny (2) When an explicit Deny is mentioned, then it always surpasses the assumed decision (3) Only when no Deny is mentioned in either of the policies and one or more methods explicitly Allow the access, then the assumed decision is Allow. This is in accordance with the Principle of Least Privilege. The policy generator tool can be used to generate policy in JSON format.

Data Encryption again can be sub-categoried in 2 parts –  In Flight and At Rest. The encryption of data that is In Flight (or In Transit or Transmitted Over The Network) is ensured by use of SSL/TLS. Practically, for a user this means that HTTPS is being used to upload or access the data.

For encryption of data At Rest (or In Storage or On Disk), S3 uses the approach of either encrypting at Server side or the User encrypt at client side and upload the data. When user encrypt the data themselves and upload it, then that phenomenon is referred to as Client Side Encryption (“CSE-C”).

CSE-C: When data is uploaded by client using AWS SDK, then the SDK generates a one time-one object symmetric key (called Data Key). The data key is used to encrypt the data at client side. The SDK then uses a Client Side Master Key (that remains on the Client side and never leave their machine) to encrypt the Data Key. SDK then sends the Data (encrypted by one time Data Key) and the Data Key (encrypted by Client Side Master Key) to S3. The Master Key can be a symmetric key (one key does both encryption/decryption) or a PKI key (a pair of Public and Private keys). If the Client Side Master Key is lost, then there is no way to decrypt the data stored in S3, since AWS doesn’t manage Client Side keys. Examples and descriptions are provided here in great detail. KMS service can also be used to manage Client side keys and the article describes that option as well.

Unlike Client Side Encryption, S3 also has an option to Encrypt data at Server Side. When encrypting data at Server Side, there are 3 options by which we can manage Keys-

SSE-S3: With this, each Object is encrypted by a unique key and then S3 also encrypt the key with a Master Key. This master key is also rotated/renewed at regular intervals. All the keys, including the unique key to encrypt the Object data and the master key, are managed by AWS and the encryption algorithm used is AES-256. If server side encryption is required for all the objects in a bucket, then bucket policy can be set to enforce it.

SSE-KMS: Key Management Service is a separate managed AWS service that allows the users to create and control encryption keys. Like SSE-S3, in this option also, each Object is encrypted by a unique key and then the key also is encrypted by an Envelop key (a.k.a. CMK or Customer Master Key). With this option, S3 uses KMS to manage all the keys. Keys are created within KMS either via  the KMS API  or via the  Encryption Keys  section of IAM portal. Use of KMS attracts additional charges but also provides some added benefits. Notable benefits are that Keys can be controlled by users, Use of keys is subject to Audit trail, Multiple envelop keys can be used and controlled via dedicated permissions etc.

SSE-C: With this option, encryption of data is done by Amazon S3 but the keys are provided by the User. This is different from CSE-C in a way that in CSE-C even the encryption is done outside of S3 (at client end) and S3 only store the encrypted object. With SSE-C, the client sends the Key to S3 over SSL for each request (Read or Write) and the key is not stored by S3, as explained here. However, a salted HMAC of the key is indeed stored by S3.

.