Prevent deletion of a CMK even by the root user (KMS equivalent to Backup Vault Lock)

Question

Greetings,

I have a backup vault that has Vault Lock enabled in compliance mode. The goal of using Vault Lock in compliance mode is to prevent deletion of the backups even in the event the root user is compromised.

The vault is also encrypted using a customer managed key. Please correct me if I'm wrong, but my understanding is that the customer managed key can be deleted even if it is still used to encrypt backups. If that's the case, my understanding is that Vault Lock provides no value if the CMK is deleted accidentally or maliciously, as it will be impossible to decrypt the backups. While a deletion waiting period of up to 30 days can be set on the CMK, that seems much weaker and shorter than the guarantees offered by Vault Lock.

My understanding is that KMS is different from other AWS services in that CMKs have their own policies distinct from IAM. It is thus possible to lock even the root user out of the key. Given that, am I correct to assume the following key policy effectively prevents deletion of the CMK even by the root user (but still delegates permissions for the other actions to IAM)?

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Deny Destructive Actions",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "kms:DeleteImportedKeyMaterial",
                "kms:DisableKey",
                "kms:PutKeyPolicy",
                "kms:ScheduleKeyDeletion"
            ],
            "Resource": "*"
        }
    ]
}
```

Would you recommend any changes to the above policy? Also, can you think of better or simpler ways to make a CMK undeletable even by the root user? Is there some official documentation on the above use case?

Thanks!

Leo K · Accepted Answer

There's no technical way to work around the principle that the customer ultimately owns their data and resources. Even the vault lock feature of AWS Backup can be worked around by closing the AWS account, leading to all data and keys being deleted after the 90-day suspension period, if the account isn't reopened before then. It would be hard to think of a practical way this could be completely prevented in any environment, because the resources would still incur costs, and a customer can always become unable to continue to pay their bills or become legally compromised.

KMS key policies of customer-managed keys can always be reset by an authorised user by opening a ticket with AWS Support. This is the failsafe mechanism for accidental or malicious revocation of permissions from legitimate users, which a paying customer always has to be able to reverse. The ability of support to reset the key policy is mentioned in this documentation section: https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html#prevent-unmanageable-key, although they might have some procedures against malicious key policy modifications.

The best you could do with AWS-generated KMS keys (as opposed to keys that KMS accesses in an external key store) would be to use an AWS-managed key. It has limited abilities, not being possible to use across account boundaries, for example, but an AWS-managed key cannot be deleted except by closing the AWS account. That ultimately suffices for defeating every protection mechanism, including AWS Backup's vault lock and S3's object lock.

The other option is to use an SCP, as Shajam suggested. Properly written SCPs cannot be defeated from inside the account, but they can only be modified or lifted by the management account of an AWS Organization. The management account can always close member accounts, lift SCP restrictions, and remove member accounts from the organisation, so access rights to the management account must always be limited to completely trusted personnel.

Note that if you go with an SCP, it won't suffice to restrict KMS actions. You'll additionally need to deny at least `organizations:LeaveOrganization` (which will immediately lift SCP restrictions), `account:CloseAccount` (starts the 90-day suspension period leading to all resources being destroyed), `account:StartPrimaryEmailUpdate` (change root email), `account:PutContactInformation`, `account:PutAlternateContact` (changing alternate account contacts). You should also either block or strictly monitor `support:CreateCase` (can be used to request a KMS key policy reset) and `kms:PutKeyPolicy` (which can be blocked by the key policy, though, as long as the key policy isn't reset). Depending on the contents of the key policy, you would also have to protect the IAM roles, IAM users, and potential identity providers through which you permit yourself and perhaps others to manage the key.

Taz · Answer

KMS does not currently have a compliance lock equivalent to AWS Backup Vault Lock. Every customer managed key can ultimately be scheduled for deletion by an identity that holds `kms:ScheduleKeyDeletion` on the key, and AWS does not provide an immutable or compliance‑mode flag to prevent that. The maximum waiting period you can enforce is 30 days, which is designed to give administrators time to cancel an unintended deletion, not to meet WORM‑style retention requirements.
—Taz

Shahed Kazi (@shajam) · Answer

You need SCP (*service control policy for the AWS Organisation*) to stop deleting the keys.

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteKMSKeys",
      "Effect": "Deny",
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion",
        "kms:DisableKey",
        "kms:DisableKeyRotation",
        "kms:ScheduleKeyDeletion",
        "kms:DeleteAlias"
      ],
      "Resource": "*"
    }
  ]
}
```

However, note that, someone with the right permissions can modify your SCP.

Prevent deletion of a CMK even by the root user (KMS equivalent to Backup Vault Lock)

Add your answer

Relevant content