The application’s data-handling microservice is the only microservice that should be able to decrypt the dataWhich solution will meet these requirements?
Create a symmetric AWS Key Management Service (AWS KMS) key that is dedicated to the data-handling microservice. Create a field-level encryption profile and a configuration. Associate the KMS key and the configuration with the CloudFront cache behavior.
Create an RSA key pair that is dedicated to the data-handing microservice. Upload the public key to the CloudFront distribution. Create a field-level encryption profile and a configuration. Add the configuration to the CloudFront cache behavior.
Create a symmetric AWS Key Management Service (AWS KMS) key that is dedicated to the data-handling microservice. Create a Lambda@Edge function. Program the function to use the KMS key to encrypt the sensitive data.
Create an RSA key pair that is dedicated to the data-handling microservice. Create a Lambda@Edge function. Program the function to use the private key of the RSA key pair to encrypt the sensitive data.
Explanations:
While using a symmetric AWS KMS key for encryption is appropriate, CloudFront does not support using KMS keys directly for field-level encryption. Instead, field-level encryption in CloudFront relies on RSA public keys for encrypting data before it reaches the backend services.
This option correctly suggests creating an RSA key pair for the data-handling microservice. By uploading the public key to CloudFront and creating a field-level encryption profile, sensitive data can be encrypted before it reaches the application, ensuring that only the designated microservice with the private key can decrypt it. This meets the requirement for data encryption and access control.
This option incorrectly suggests using a Lambda@Edge function to encrypt data with a KMS key. While KMS can be used for encryption, the solution does not leverage field-level encryption in CloudFront. Also, Lambda@Edge functions would not have the ability to directly decrypt data at the CloudFront edge locations without storing the private key securely.
This option suggests using an RSA key pair, but it incorrectly states that the Lambda@Edge function should use the private key to encrypt the data. The private key should be kept secure and not used for encryption in this context. Instead, the public key should be used to encrypt the data before it reaches the backend services, making this approach insecure and not suitable for the requirements.
I opine that the answer is:
Create an RSA key pair that is dedicated to the data-handing microservice. Upload the public key to the CloudFront distribution. Create a field-level encryption profile and a configuration. Add the configuration to the CloudFront cache behavior.