“Encryption Enabled” Does Not Automatically Mean Your AWS Data Is Protected
Teams treat encryption as yes-or-no. A more useful question is: who can use the KMS key, who can change its policy, and can one identity reach both the object and the key?
Teams often treat encryption as a yes-or-no question: is server-side encryption enabled? A more meaningful security assessment asks which KMS key protects the data, who can use that key, who can modify its policy, whether another AWS account can decrypt the data, and whether an overprivileged workload can access both the encrypted object and the key.
OWASP A04 covers missing encryption, weak cryptography, key exposure and improper key management. It emphasizes encryption at rest, encryption in transit and appropriate protection of sensitive information.
The encryption checkbox problem
An encrypted S3 bucket may still be exposed when:
- A broad bucket policy permits object access.
- The corresponding KMS key policy permits the same external principal.
- An application role has both
s3:GetObjectandkms:Decrypt. - Administrative identities can change the KMS policy.
- Sensitive data is stored without sufficient identity restrictions.
Data access and key access must be evaluated together
Confidentiality is the intersection of two questions, not one:
Common AWS encryption posture risks
- Unencrypted buckets, or AWS-managed keys where customer-managed control is required.
- Broad KMS key policies and cross-account key usage.
- Excessive
kms:Decryptand identities able to change key policies. - Sensitive data stored in externally accessible resources.
How Securitain connects data security with IAM
Securitain approaches this from the AWS posture and authorization layer — examining encryption status across supported data resources, KMS keys and resource policies, S3 exposure, identities with sensitive-data permissions, cross-account access, wildcard resource access, identities capable of changing key or resource policies, toxic permission combinations, and the blast radius if an identity is compromised.
Securitain does not, by itself, prove whether an application uses an outdated hashing algorithm, generates predictable random numbers, reuses initialization vectors, hashes passwords incorrectly, validates certificates incorrectly, or uses a weak custom encryption library. Those require application-code review, SAST, DAST, dependency analysis and penetration testing. Securitain's role is to identify AWS encryption posture, key-policy exposure and identity access to encrypted resources.
What a meaningful remediation looks like
- 1Restrict
kms:Decryptto specific roles. - 2Restrict key-policy principals and add encryption-context conditions.
- 3Remove unused cross-account access.
- 4Separate key administrators from key users.
- 5Restrict S3 access to expected workloads.
Encryption protects data only when access to the data and access to the key are both controlled.
Securitain provides read-only AWS IAM and security-posture analysis through temporary STS sessions. It helps teams understand identities, effective permissions, attack paths, resource exposure and remediation opportunities without requiring permanent administrative access to the customer's AWS account.