--- id: SOV04 pillar: sovereignty title: SOV 4. How do you decide who is technically able to decrypt your data? description: Encryption at rest answers a different question than sovereignty asks. What matters is not whether data is encrypted but who holds the key that opens it. status: draft services: [kms, object-storage] tiers: [1, 2] sidebar: order: 13 label: Key ownership source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-04-key-ownership/" source_file: "docs/architecture/pillars/sovereignty/sov-04-key-ownership.mdx" --- 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 - [`SOV 4.1`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-41-establish-per-data-set-who-is-technically-able-to-decrypt) Establish per data set who is technically able to decrypt - [`SOV 4.2`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-42-hold-the-keys-yourself-where-the-tier-requires-it) Hold the keys yourself where the tier requires it - [`SOV 4.3`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-43-distinguish-customer-managed-from-customer-originated) Distinguish customer-managed from customer-originated - [`SOV 4.4`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-44-treat-key-material-as-the-most-critical-state-you-hold) Treat key material as the most critical state you hold --- ## 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`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-44-treat-key-material-as-the-most-critical-state-you-hold) 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 **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 **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`](/architecture/pillars/sovereignty/sov-07-auditability/) and [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) 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 **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`](/architecture/pillars/reliability/rel-05-resilient-interactions/) 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`](/architecture/pillars/reliability/rel-08-backup-and-restore/#rel-83-restore-on-a-cadence-into-a-clean-environment-and-time-it) 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`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-42-hold-the-keys-yourself-where-the-tier-requires-it) 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`](/architecture/pillars/reliability/rel-08-backup-and-restore/) 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 - [`SEC 7`](/architecture/pillars/security/sec-07-encryption/) Encryption, the security-side view of the same mechanisms - [`SOV 5`](/architecture/pillars/sovereignty/sov-05-operator-access/) Operator access, which this partly answers and partly does not - [`REL 8.3`](/architecture/pillars/reliability/rel-08-backup-and-restore/#rel-83-restore-on-a-cadence-into-a-clean-environment-and-time-it) Restore testing, which has to include the key path - [`SOV 8.3`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-83-establish-the-responsibility-split-per-control) Responsibility split, which this decision moves - [`SEC 9`](/architecture/pillars/security/sec-09-secrets/) Secrets, which key material is the extreme case of