Engineering

How To Handle Secrets and Sensitive Data in AWS

How To Handle Secrets and Sensitive Data in AWS

Introduction

With a reputation for reliability and scalability, Amazon AWS is a leading cloud provider which many Fortune 500 companies rely on to host their infrastructure. Since the systems are hosted outside of the organization’s internal boundaries, security remains a big concern. 

Any sensitive or secret configuration data, such as usernames, passwords, and API keys, should be handled with extreme care especially if the systems handle financial transactions or personal data. If the data is compromised, it could lead to financial penalties and brand devaluation for the company. 

So, what’s the best way to handle secrets and sensitive data in AWS? Read on to find out!

How Does AWS Handle Your Sensitive Configuration Data?

When we mention the words sensitivity or secrets, we should automatically think of encryption. AWS uses hardware encryption, and its master key never leaves its servers. 

Ideally, you should have one environment per AWS account for better isolation and security. With this setup, production data and applications will never interact with non-prod environment resources. Examples of sensitive data include API keys, usernames, passwords, and even API URLs. These should be encrypted at rest and in transit and should only be decrypted during application runtime.

AWS Key Management Service (KMS)

The underlying system that AWS uses to encrypt sensitive data is called AWS Key Management Service (KMS).

KMS is a fully managed service that can be used to create, store, and control encryption keys in order to encrypt your data. It’s a highly durable and available service with the following specifications:

  • KMS encryption keys are regional.
  • The service leverages Hardware Security Modules (HSM) under the hood, which guarantees the security and integrity of the generated keys. This implies that the key generation algorithm cannot be regenerated with software.
  • It offers easy key rotation and logs all key-related events to AWS CloudTrail.

AWS KMS has customer master keys (CMKs) and data keys.

CMKs never leave the AWS KMS service unencrypted. They contain a metadata-like key ID, creation date, etc. They can be used to encrypt or decrypt arbitrary chunks of data that are no larger than 4 KB. Typically, CMKs are used to generate, encrypt, and decrypt the data keys used outside of AWS KMS to encrypt your data. This is known as envelope encryption.

CMKs can be:

  • Customer-managed: These are created and managed by the AWS user. Access can be controlled using the AWS IAM service.
  • AWS-managed: These are created and managed by AWS on your behalf. They can be identified by the format AWS/service-name.
  • AWS-owned: These are not in your AWS account. They are part of a collection of CMKs that AWS owns and manages for use in multiple AWS accounts. They cannot be viewed or managed by the user.

Data keys are symmetric keys generated by AWS KMS that can encrypt/decrypt large amounts of data. AWS KMS does not store, manage, track, or perform cryptographic operations with data keys. You must use and manage data keys outside of AWS KMS.

How Does AWS KMS Encrypt Your Data?

To create a data key, call the GenerateDataKey operation. AWS KMS will then use the specified CMK to generate data keys. As you can see in the figure below, it generates a plaintext data key and an encrypted data key.

This plaintext data key is used to encrypt the data. Afterward, the plaintext key is removed as soon as possible from memory so the data doesn’t get compromised. The encrypted key is stored along with the encrypted data for use during decryption.

For decryption, you need to use the Decrypt operation. AWS KMS uses the customer master key to decrypt the encrypted data key stored along with the data. It returns the plaintext key, which is then used to decrypt the data again. This plaintext key is removed from the memory.

Decrypting Data with a Data Key

To decrypt your data, pass the encrypted data key to the Decrypt operation. AWS KMS will use your CMK to decrypt the data key, after which it will return the plaintext data key. Use the plaintext data key to decrypt your data, and then remove the plaintext data key from memory as soon as possible.

The following diagram shows how to use the Decrypt operation to decrypt an encrypted data key.

AWS has two products – AWS Secrets Manager and AWS Parameter Store – which can be used to help secure secret data with encryption keys managed through AWS KMS.

AWS Secrets Manager is a new service fully managed by AWS to ensure that the security of credentials stored on it is tied to IAM access on your AWS account. Secrets Manager also comes with a rotation feature that automatically rotates API keys, passwords, and more. This can be configured and wired with a Lambda function to help perform the rotation.

AWS Parameter Store, just like Secrets Manager, has the security tied to your IAM account in AWS. All requests are made via either the API or CLI. The keys for both services are generated from the console. There is no secret rotation feature of any sort, but you can customize one through Lambda functions.

Accessing the Secrets

AWS has built-in APIs that enable users and applications to retrieve secrets.

For example, both secrets management systems can be accessed by their respective SDKs. The Python SDK for AWS, for instance, is Boto3.

Secrets Manager

response = self.secretsmanager_client.get_secret_value(**kwargs)

Parameter Store
response = client.get_parameter(

    Name=‘string’,

    WithDecryption=True|False

)

For further security, it’s ideal to create a VPC endpoint so that network traffic does not traverse outside the AWS network when retrieving the secret data.

Consider Third-Party Tools If You Are Using Kubernetes 

Kubernetes is a very popular tool used to pass AWS secrets as either environment variables or files. 

You can refer to this excellent example of the Kubernetes/AWS Secrets Manager retrieval tool.

Important Note

The drawback of injecting secrets as environment variables or files is that your secret could become accessible inside the system, where a compromised SSH session can reveal all your sensitive data. So, if you are willing to expose secrets to environment variables, then adding another layer of encryption is needed at the application level. 

For example:

bash-3.2$ env|grep PASSWORD

Correct   ENCRYPTED_PASSWORD=445fg0fdf4$%%$%fd45SSS!@&fdsffds

Incorrect PASSWORD=my#sp3CialP2dword

Conclusion

Sensitive configuration data should always be handled with care and stored in a single space. Environments should be separate per account or project base to isolate unwanted access to your sensitive data. AWS already provides very secure, reliable, and highly auditable secrets management tools, including Secrets Manager and Parameter Store. If you plan to use AWS as a hosting provider, download our guide for a full breakdown of the cloud provider.

By Raymond Gao, Wizeline Site Reliability Engineer
By Raymond Gao, Wizeline Site Reliability Engineer

Aisha Owolabi

Posted by Aisha Owolabi on July 21, 2021