The role split¶

Two grants, deliberately unequal, because reading a report and issuing a certificate are different powers.

What each can do¶

Why it matters¶

The reader grant is the one that gets used routinely — every report someone on the rota opens. It is therefore the one most likely to be sitting in an active session when something goes wrong.

If that grant could also sign, a compromised rota session could mint a certificate under your identity and publish it. Researchers would then encrypt to an attacker's key, and the compromise would look exactly like normal operation. Splitting the grants means the routine credential cannot do the irreversible thing.

The certifier grant is used approximately once per certificate. It should be harder to obtain — an MFA condition on an administrative role — precisely because it is rare.

Negative tests are the point¶

A least-privilege split that is only declared is not a split. The property worth asserting is the refusal: that a reader role asking for kms:Sign gets AccessDenied.

That is why the integration suite checks it. A positive test proves the permission exists; only the negative test proves the boundary does.

What this does not protect against¶

An administrator who can assume either role, or who can edit the key policy, is outside this boundary — the split is between operational roles, not against account-level compromise.

It also does not protect a report after it has been decrypted. If the plaintext is pasted into a ticket, the confidentiality this whole design provides ends at that moment. That is an operational discipline question, and no amount of key management answers it.