Cloud infrastructure encrypts your data both when it’s stored (at rest) and when it’s moving between systems (in transit).
Let’s see what that looks like in practice. Imagine you’re storing files in Amazon S3. When you upload a file, you can configure S3 to encrypt it using server-side encryption with AWS Key Management Service (KMS). This means S3 handles the encryption for you, using a key managed by KMS. When you retrieve the file, S3 automatically decrypts it for you.
# Example of uploading an object with server-side encryption using KMS
aws s3 cp my-local-file.txt s3://my-encrypted-bucket/my-local-file.txt \
--sse aws:kms \
--sse-kms-key-id arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id
For data in transit, think about how your applications communicate. If your web server is serving content over HTTPS, the connection between the user’s browser and your server is encrypted using TLS/SSL. This prevents eavesdroppers from seeing the data exchanged, like login credentials or payment information.
# Example of checking TLS configuration for a web server (using openssl)
openssl s_client -connect www.example.com:443 -tls1_2
The fundamental problem this solves is confidentiality. Without encryption, anyone who gains unauthorized access to your storage or can intercept network traffic can read your sensitive data. Encryption transforms that readable data into an unreadable jumble, rendering it useless to an attacker.
Internally, data at rest encryption typically involves a symmetric encryption algorithm like AES-256. A unique data key is generated for each piece of data (or a group of data). This data key is then itself encrypted using a master key, often managed by a dedicated key management service (KMS). When you need to access the data, the KMS provides the encrypted data key, which is then used to decrypt the data itself. The master key never leaves the KMS, significantly reducing the attack surface. Data in transit encryption uses asymmetric cryptography (like RSA) for the initial handshake to establish a secure, symmetric session key, which is then used for the bulk of the data transfer.
The exact levers you control are primarily around key management and the encryption algorithms and modes used. For data at rest, you choose:
- Encryption provider: Will the cloud provider encrypt it (e.g., S3-SSE), or will you encrypt it before uploading (client-side encryption)?
- Key source: Will you use a cloud-managed key (e.g., AWS KMS, Azure Key Vault, Google Cloud KMS), a customer-managed key (your own key in the cloud provider’s KMS), or bring your own key (BYOK)?
- Algorithm and mode: While often abstracted away, some services allow specifying AES-256, AES-128, and modes like GCM or CBC.
For data in transit, you’re mainly concerned with:
- TLS/SSL version: Enforcing TLS 1.2 or 1.3 and disabling older, vulnerable versions like SSLv3 or TLS 1.0/1.1.
- Cipher suites: Selecting strong, modern cipher suites that offer robust encryption and authentication.
- Certificate management: Ensuring your SSL/TLS certificates are valid, up-to-date, and issued by trusted Certificate Authorities.
A common misconception is that simply enabling "encryption at rest" means your data is fully protected. However, the security of your data is fundamentally tied to the security of your encryption keys. If your keys are compromised, the encryption is rendered useless. This is why robust access control policies for your KMS keys, including principle of least privilege, are as critical as the encryption itself. Many organizations overlook the importance of auditing key usage and setting up alerts for any suspicious activity related to key access or management.
The next challenge you’ll face is implementing fine-grained access control for your encrypted resources.