AWS S3 Configuration Best Practice: Enable Server-Side Encryption

We’ve previously written about how using checklists can avoid configuration errors, which is a useful practice for data protection. Encryption is one of the most fundamental practices in data protection because it renders data unreadable if it is lost, stolen or otherwise accessed inappropriately. Therefore, a major AWS S3 configuration error is not enabling server-side encryption since neglecting it may leave confidential information exposed in clear text.

Data encryption protects data-at-rest (data stored on S3) and data-in-transit (data traveling to/from S3). Data-in-transit can be protected by SSL/TLS, while data-at-rest can be protected by server-side encryption or client-side encryption.

Client-side encryption requires the customer to manage the encryption process, tools, and keys, which can be rather time-consuming and expensive for IT admins to manage, and frequently too complex. Consequently, most organizations prefer server-side encryption since Amazon manages the processes of encrypting their data before storage and decrypting it when accessed by an authorized and authenticated user.

Amazon offers three ways to deploy server-side encryption:

  • Amazon S3-Managed Keys (SSE-S3) – Amazon encrypts each object with a unique 256-bit Advanced Encryption Standard (AES-256) key, then encrypts that key with a frequently rotating root key. There is no additional charge for SSE-S3, which makes it an attractive offering. Organizations concerned about data security should embrace this entry-level offering.
  • KMS keys Stored in AWS Key Management Service (SSE-KMS) – KMS is Amazon’s premium offering, which adds a key management system for an additional cost. This solution is more attractive to mature organizations that need to set access permissions or to provide an audit trail for compliance.
  • Customer-Provided Keys (SSE-C) – Similar to client-side encryption, customer-provided keys require the customer to manage the encryption keys, but Amazon still handles the encryption of the data. This sort of approach may be more attractive to security-conscious organizations that want to avoid putting all their eggs in one basket, but it will introduce the same management issues as client-side encryption.

Any Amazon customer using SSE-C needs to have a strong understanding of applied cryptography or they may put their organization’s data at risk. If they connect using HTTP, Amazon will reject the request, and their key may be exposed. Even worse, if the customer loses their encryption key, then they cannot access the data. As a result, SSE-S3 or SSE-KMS may be a more manageable approach for most organizations.

Organizations using SSE-S3 can use a bucket policy to encrypt all of the objects in a bucket or they can use REST API commands to encrypt specific objects. There are too many options to explain them all, so organizations should review Amazon SSE-S3 documentation. Likewise, SSE-KMS offers similar encryption functionality, as well as advanced flexibility and control (and costs), so organizations are advised to review Amazon SSE-KMS documentation. Amazon even provides advice on how to keep SSE-KMS costs down with bucket keys.

Avoid Common Configuration Errors with OPSWAT

When it comes to common configuration errors, such as enabling server-side encryption, organizations should use checklists to ensure they are implementing best practices. Automating this process with technology can help to avoid time-consuming and expensive manual errors.

MetaDefender for Secure Storage enhances its cloud storage security solution with an integrated security checklist, so that cybersecurity professionals can ensure their organization’s cloud storage is not misconfigured as it is provisioned, which includes the development and production stages of cloud storage.

Enabling server-side encryption is a major checklist item in MetaDefender for Secure Storage, but it isn’t the only one. In future blogs, we will be exploring other major configuration errors for protecting data at rest.

Contact an OPSWAT cybersecurity expert to learn more.

Read the previous blogs in this series:

Sign up for Blog updates
Get information and insight from the leaders in advanced threat prevention.