The "Green Checkmark" Fallacy
We all love the green checkmark. You spin up an S3 bucket, click "Enable Encryption", and feel safe. You launch an RDS instance, check the box for encryption, and tell your CISO: "We are compliant."
But are you?
Some engineers seem to confuse Encryption with Data Sovereignty.
Encryption means the data is unreadable without a key.
Sovereignty means you decide who gets to use that key.
Who Owns the Lock?
Here is the hierarchy of trust in AWS KMS (Key Management Service). It determines who actually owns your data.
1. AWS Managed Keys (The Default)
This is what happens when you just click "Enable Encryption" without configuring anything else.
-The Key Material: Generated by AWS.
-The Policy: Written by AWS.
-The Problem: As the documentation explicitly states: "You cannot manage these keys, rotate them, or change their key policies."
If a legal entity issues a subpoena to AWS for your data, AWS has both the encrypted data and the key to decrypt it. Technically, they can be compelled to unlock your door. You might not even know it happened.
2. Customer Managed Keys (CMK)
his is the baseline for professional cloud security. You generate the key. You define the policy. Most importantly:
The Key Policy is the boundary.
Unlike IAM policies, which belong to the Identity (User/Role), the Key Policy belongs to the Resource (The Key). If your Key Policy says "Deny access to everyone except this specific App-Role," even the AWS Root User cannot decrypt that data.
3. External Key Store (XKS) – The "Hold Your Own Key" (HYOK) Strategy
This is the nuclear option for highly regulated industries (Finance, Public Sector in EU). Your key material never enters the AWS Cloud unencrypted. It lives in an external Hardware Security Module (HSM), for example, from providers like Thales. AWS KMS simply makes an API call to your external HSM to decrypt data.
If you sense a threat or need to revoke access instantly ("Kill Switch"), you cut the connection to the HSM. AWS is left with encrypted gibberish and no way to decipher it.
The Code: Enforcing Separation of Duties
The true power of a Customer Managed Key (CMK) lies in the Key Policy. Here is a pattern I use to enforce "Separation of Duties". This ensures that the Cloud Admin (who manages EC2/S3) cannot decrypt the sensitive data (HR/Finance).
Only the specific workload (e.g., an EC2 Role) and the Key Admin have access.
{
"Sid": "Allow use of the key for the App Role ONLY",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/Production-App-Role"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
Resource": "arn:aws:kms:eu-central-1:123456789012:key/your-key-id
}
Update 30.01.26: Community Feedback
Thanks to the sharp eyes of Gabriel Pavel from the LinkedIn community! We refined the IAM policy above. In a production Sovereign Cloud environment, always adhere to the Principle of Least Privilege. Never use wildcards (*) for sensitive KMS actions if you can target specific Key ARNs.
Security is a team sport.
By explicitly defining the Principal, you stop implicit access.
Why This Matters: The CLOUD Act & FISA 702
This isn't just paranoia; it's legal reality. The US CLOUD Act
allows US federal law enforcement to compel US-based technology companies (like AWS, Azure, Google) to provide requested data stored on servers, regardless of whether the data is stored within the US or on foreign soil (e.g., in the Frankfurt Region).
If AWS holds the key (Managed Key), they can technically comply. If you hold the key (XKS) or strictly govern the policy (CMK) outside their standard admin scope, you introduce a technical barrier that aligns with European Digital Sovereignty requirements.
Summary
"Encryption enabled" is a feature. Key Management is a discipline.
If you are building casual side projects, AWS Managed Keys are fine. But if you are building for enterprise clients, healthcare, or handling PII (Personally Identifiable Information) in Europe, you need to move up the ladder.
Stop using default keys for sensitive data.
Create Customer Managed Keys.
Write strictly scoped Key Policies.
For critical data, look into XKS.
As Gabriel Pavel recently pointed out in a discussion we had on Linkedin:
"Without ownership of the key policy, you can't truly enforce risk control yourself."
Don't just lock your door. Keep the key.
Links for further reading:
AWS KMS Concepts - Managed Keys
https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-keys
AWS External Key Store (XKS)
https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
Thales CipherTrust for AWS XKS
https://cpl.thalesgroup.com/encryption/amazon-web-services-aws/external-key-store-xks
Top comments (2)
Another great post Ali!
I love how this post brings to light the limitations of encryption in cloud security. It's like, I always thought that as long as my data was encrypted, it was safe, but no, the key to all that security could be held by the very cloud provider I'm trusting with my stuff. The idea of having control over those keys, and being able to set strict policies around who gets to use them, is incredibly appealing to me - it's like giving myself a safety net, a way to ensure that even if something goes wrong, I can still protect myself.
Hi Aryan,
You identified the critical distinction accurately. Encryption at rest is a standard compliance checkbox, but key ownership is the actual security perimeter.
Many overlook that trusting the provider with both the data and the key essentially negates sovereignty in my view.
Moving to customer managed keys and defining your own key policies is exactly how you shift from passive trust to active control
Good to see you grasping these architectural nuances so quickly and thank your for your comment.