The Delusion of S3 Encryption Benefits
Amazon’s Simple Storage Service (S3) hardly needs any introduction and any introduction can hardly do justice. One of the great features about Amazon S3 is it’s out-of-the-box Server Side Encryption (SSE) that encrypts or decrypts data seamlessly. This feature is commonly perceived to help keep the data safe from bad guys — now, does it?
Well, as always, the devil is in the details. AWS S3 offers three configurations/patterns to encrypt data on the server-side. The security benefits offered by these modes vary. This makes it critical to understand the configuration/pattern employed and the benefits accrued, to avoid being deluded into a false sense of security.
The most commonly used configuration is ‘SSE-S3’ / ‘AES-256’. Quite often development teams employ this simply because it’s the easiest to configure, encrypts the data, and it checks the box on most checklists. Let us take a look at how it works and the benefits it offers.
Whenever SSE encryption is enabled, AWS uses an account & region specific S3 service Master Key to generate an AES-256 Data Key. This Data Key is used to encrypt & decrypt data. The Data Key is protected by encrypting it with the Master Key and is stored along with the data. S3 manages Data Key handling and storage behind the scenes, making it all very seamless.
In the SSE-S3 mode, the account’s S3 service Master Key in KMS is used to generate the Data Key. When a user retrieves objects, they are decrypted on the fly and provided in clear text.
AWS SSE-S3 Server Side Encryption Pattern
In essence, anyone with access to the data is able to retrieve the objects in clear. This sounds fair, right? Now, let’s think of a scenario where a Database Admin has access to a DB Table. The table includes sensitive data such as SSN or credit card number. Usually, these column values are encrypted by the application before persisting to the database. In this case, even if the Database Admin has access to the data and is able to retrieve it, the Admin will not get the SSN/credit card number in clear.
If this file was stored in S3 instead of a DB relying on SSE-S3 mode for encryption, apart from the authorized user, any admin with full access or any user with access to the bucket due to excessive entitlements will be able to retrieve the data in clear. So, it is essential to remember that whenever, we are storing sensitive data on S3, this may not be adequate. Of course, one could make a case that the S3 Resource Policies could be defined to restrict access to the file. However, getting resource level policies right at scale is a significant challenge. Further, S3 object and policy creation or updates happen so frequently, that it will soon become a challenging technical task and a burdensome governance process to monitor resource policies for all the sensitive files.
That brings us to the next configuration option — ‘SSE-KMS’. Remember — AWS generates Data Key using an account & region specific S3 service Master Key. In this mode, instead of using the default S3 service Master Key, we can specify a Master Key generated purposefully — called the Customer Master Key (CMK). Now, what makes this different from encryption using SSE-S3 mode using S3 service’s Master Key?
AWS SSE-KMS Server Side Encryption Pattern
When we use a Customer Master Key in KMS, AWS permits us to attach a Resource Policy to the key. This resource policy allows us to define who has access to the key and for what purpose. To draw an analogy, applications use a key to encrypt sensitive data or secrets. The key used for encryption is stored in a keystore and protected with a password. Only the application is able to gain access to the key and retrieve sensitive-data in clear. One may have access to the encrypted object (sensitive data/secret), but without access to the key in keystore, the data cannot be retrieved in clear.
It is critical to note that a poorly defined Resource Policy for Customer Master Key or simply using the default policy on KMS will end up making this configuration equivalent to SSE-S3. Further, given that configuration for keys are not changed so often, we rely on the fact that the Security Ops Center (SOC) teams/admin teams will be relatively more cautious with all such requests as opposed to S3 config/object policy changes.
The last option for S3 server-side encryption is SSE-C; in this mode, the client is responsible for the management of the encryption/decryption key. The key is not stored on AWS, rather provided by the client along with each request to enable S3 to encrypt/decrypt objects. To draw an analogy, this is like archival tapes stored at an offsite facility. The tapes are stored encrypted and when needed, brought back to on-prem. Of course, in the case of SSE-C, the encryption and decryption take place on server-side. This mode is usually appropriate when the use of S3 is primarily relied on for storage.
AWS SSE-C Server Side Encryption Pattern
Here is a quick reference for the configuration modes, equivalent patterns and suitability of use:
To summarize, Amazon S3 offers multiple server side encryption configurations. Teams that work on use cases with sensitive data need to comprehend the S3 SSE patterns/configuration available, benefits each offer, and identify a suitable configuration that provides the protections required by a use- case.
Snippet from Capital One’s recent data breach disclosure statement: “Due to the particular circumstances of this incident, the unauthorized access also enabled the decrypting of data.”
#S3 #Encryption #DataProtection #S3-SSE #S3Encryption #CapitalOneBreach
