SOV 4. How do you decide who is technically able to decrypt your data?
Last updated on
Nearly all managed storage encrypts at rest, and that fact is frequently cited as if it settled the sovereignty question. It does not. Encryption with a provider-held key protects against a stolen disk and a decommissioned drive, which is worth having and is a different threat than the one Tier 1 is concerned with.
The sovereignty question is narrower and harder: which parties are technically capable of decrypting this data, and is that set the one you intended?
Best practices
Section titled “Best practices”SOV 4.1Establish per data set who is technically able to decryptSOV 4.2Hold the keys yourself where the tier requires itSOV 4.3Distinguish customer-managed from customer-originatedSOV 4.4Treat key material as the most critical state you hold
SOV 4.1 Establish per data set who is technically able to decrypt
Section titled “SOV 4.1 Establish per data set who is technically able to decrypt”Risk if not established: High
The answer differs per data set and per service, and the only way to know it is to work it out deliberately for each.
Three arrangements produce three different answers. Provider-managed keys mean the provider can decrypt, which is what makes the service work transparently. Customer-managed keys in the provider’s key service narrow it: you control the key’s lifecycle and can revoke it, and the key service still holds the material. Customer-held keys that never reach the provider mean only you can decrypt, and the provider cannot help you if you lose them.
Each is appropriate somewhere. The failure is not choosing the weaker option; it is having an arrangement nobody chose, then describing the data as encrypted as though that answered the question.
Ask the question per service rather than once. A workload frequently has its database under one arrangement, its object storage under another, and its backups under a third, and the effective answer is the weakest of them.
On STACKIT. The Key Management Service is the mechanism for customer-managed keys, organized into key rings with keys of several algorithm types.
Which managed services can be configured to use a KMS key, and which use platform-managed encryption only, decides how far this practice can be taken. That mapping is the thing to establish before the design assumes it.
There is no central list of it, and no single team holds one. Whether a service accepts a KMS key is that service’s own decision and its own roadmap, so the mapping is assembled per service, for the services your workload uses, and it is assembled again the next time because the answers move.
Plan for that rather than around it. Establish it for your services before the design depends on it, because at Tier 1 this is usually the first question the architecture turns on and the answer can be no. Ask the service teams directly and record what you were told with the date on it, since an answer without one is worth little six months later. It may also arrive as a by-product: assessing a service against ES³’s data dimension asks who controls access to the data it holds, so a service with an SML result has been asked this question under audit.
Tradeoffs. Reliability. Every step away from provider-managed keys adds a dependency whose
failure makes data unreadable, which SOV 4.4 addresses and which is the honest reason the
default is what it is.
Verify. For each data set, list who holds a key that decrypts it. Was that list decided, or is it the default?
SOV 4.2 Hold the keys yourself where the tier requires it
Section titled “SOV 4.2 Hold the keys yourself where the tier requires it”Risk if not established: High
For Tier 1 data, the question of whether the provider can technically decrypt is frequently the point of the classification. Where that is the requirement, key custody has to be arranged rather than assumed.
Two mechanisms serve this and they differ in an important way. Importing your own key material into the provider’s key service means the key originated with you and the provider holds a copy to operate on. Supplying the key with each request means the provider never retains it, and the data is unreadable without you supplying it again.
The second is stronger and much more operationally demanding, since every reader needs the key at the moment of reading, and nothing recovers the data if that path breaks.
Match the mechanism to the requirement rather than taking the strongest available. A Tier 2 workload using per-request keys has bought an operational burden that its classification did not ask for, and it will eventually be worked around.
On STACKIT. KMS supports importing key material that you generated elsewhere, protected by a wrapping key, which is the mechanism for a key that originated with you rather than with the platform.
Object Storage supports customer-provided encryption keys through the S3 interface, where the key travels with the request and is not retained. That is the stronger arrangement, with the consequence that losing the key means losing the objects, and that consequence is the whole point.
The design decision is which data sets warrant which, and recording the reasoning matters as much as the choice, because the operational cost will be questioned later by somebody who was not in the conversation.
Tradeoffs. Reliability and Operational Excellence, substantially. Customer-held keys move the recovery burden entirely to you, and there is no support path that recovers data from a lost key. That is the property being purchased.
Verify. For your Tier 1 data, where did the key originate and who holds a copy today?
SOV 4.3 Distinguish customer-managed from customer-originated
Section titled “SOV 4.3 Distinguish customer-managed from customer-originated”Risk if not established: High
These two are routinely described with the same words and answer different questions, and the confusion produces assessments that claim more than the architecture delivers.
Customer-managed means you control the key’s lifecycle: creation, rotation, disabling and deletion, and therefore access revocation. The key material is generated by and held in the provider’s key service.
Customer-originated, usually called bring your own key, means the material was generated by you and imported. You control the lifecycle and the provider holds a copy in order to use it.
Customer-held means the provider never retains the material.
Each is a legitimate arrangement and each is defensible. What is not defensible is describing one as another in an assessment, because the difference is precisely what an auditor asking about provider access is trying to establish.
Write down which one applies per data set, using the distinction rather than the marketing term.
That record is what SOV 7 and SOV 8 will draw on.
On STACKIT. KMS covers the first two, with key creation and lifecycle control in the service and key import for material generated elsewhere. Object Storage customer-provided keys cover the third.
Being explicit about which one a given data set uses is the difference between an accurate compliance statement and an optimistic one, and the accurate version is more useful even where it claims less.
Tradeoffs. None. Precision costs nothing and prevents a class of finding that is expensive to correct once it is in a published assessment.
Verify. For each encrypted data set, which of the three arrangements applies? Does your compliance documentation use the same distinction?
SOV 4.4 Treat key material as the most critical state you hold
Section titled “SOV 4.4 Treat key material as the most critical state you hold”Risk if not established: High
The moment you take custody of keys, you have taken custody of the availability of the data. A lost key is data loss with no recovery path, and the strength of the arrangement is what removes the recovery path.
Three properties need designing, and each is more consequential than its equivalent for ordinary
data. Availability, because the key service is now on the critical path of every read, which
is REL 5 applied to a dependency whose failure is total. Durability, because a backup of
encrypted data without the key is not a backup, which is exactly what REL 8.3 tests for.
Access control, because whoever can use the key can read everything it protects, which makes
it the highest-value target in the estate.
Rotation is where these interact badly. Rotating a key without retaining the ability to decrypt data encrypted under the previous one is destructive, and it is a mistake that surfaces during a restore rather than during the rotation.
The general form is that key custody moves risk rather than removing it. That is the right trade
for Tier 1 data and a poor one where the classification did not require it, which is why SOV 4.2
asks for the match.
On STACKIT. KMS supports key rotation and key versioning, and the operational question is whether every consumer of a key handles a version change and whether previous versions remain available for data encrypted under them. That is design work in the application rather than a platform setting.
Where keys are held entirely outside the platform, the key store’s own availability and backup
become your responsibility, and it inherits the requirements of REL 8 in full. A key store that
is less durable than the data it protects has made the data less durable.
Tradeoffs. Reliability, directly and substantially. The key service becomes a single point of failure for data access, and mitigating that is real design work rather than a configuration choice.
Verify. If your key service were unavailable for an hour, what would still work? If a key were lost, what data would be unrecoverable?
Related
Section titled “Related”SEC 7Encryption, the security-side view of the same mechanismsSOV 5Operator access, which this partly answers and partly does notREL 8.3Restore testing, which has to include the key pathSOV 8.3Responsibility split, which this decision movesSEC 9Secrets, which key material is the extreme case of