Post by Patience Ogbeba MBCS
Cloud Architect | Cloud security | Cybersecurity-PenTester| Post-Quantum Encryption Advocate | Professional Member - The British Chartered Institute for IT
A symmetric KMS key uses the same key material for both encrypt and decrypt operations BUT The key material being shared does not mean the permissions have to be shared. AWS KMS evaluates permissions at the API level. When a workload calls kms:Encrypt, → KMS checks whether the calling principal is explicitly allowed to perform that action. When it calls kms:Decrypt, → KMS checks whether the calling principal is explicitly allowed to perform that action. You can grant one without the other. The key itself does not care about it's material. KMS enforces this actions at the gate. This means you can and should » give your ingestion pipeline only the right to encrypt » and your processing service only the right to decrypt. Security Implication If your ingestion pipeline is compromised, » the attacker can write garbage to your data store » the attacker cannot read a single byte of your existing records. This is a meaningful security boundary. When engineers set up AWS KMS for the first time, the most natural thing is to create one key and one IAM role that can do everything with it. » The role writes encrypted data to S3. » The role reads it back. » The role handles both sides of the transaction. What happens if that role is compromised? » An attacker who gains control of a role with both kms:Encrypt and kms:Decrypt permissions can read every piece of encrypted data your system has ever produced. Splitting roles does not prevent the initial compromise. It cuts the blast radius in half and frequently makes the difference between a security incident and a catastrophic data breach.
