--- id: SOV05 pillar: sovereignty title: SOV 5. How do you limit provider and operator access, including to data in use? description: Encryption at rest and in transit leave a gap while data is being processed. Closing that gap is possible, and it is a decision with real operational cost. status: draft services: [confidential-kubernetes] tiers: [1, 2] sidebar: order: 14 label: Operator access source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-05-operator-access/" source_file: "docs/architecture/pillars/sovereignty/sov-05-operator-access.mdx" --- Data has three states and the standard controls cover two of them. Encrypted at rest, encrypted in transit, and in plaintext while being processed. The third is where anyone with sufficient access to the host can read it, and that includes whoever operates the host. For most workloads that is an acceptable and normal position, addressed contractually and through the provider's own controls. For Tier 1 data it is frequently the specific concern that drove the classification, and it has a technical answer. ## Best practices - [`SOV 5.1`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-51-establish-who-can-technically-reach-the-data-including-the-provider) Establish who can technically reach the data, including the provider - [`SOV 5.2`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-52-close-the-data-in-use-gap-where-the-tier-requires-it) Close the data-in-use gap where the tier requires it - [`SOV 5.3`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-53-constrain-the-support-and-operations-paths) Constrain the support and operations paths - [`SOV 5.4`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-54-weigh-what-restricting-access-costs-you) Weigh what restricting access costs you --- ## SOV 5.1 Establish who can technically reach the data, including the provider **Risk if not established:** High Access reviews usually enumerate your own people, which is [`SEC 5.4`](/architecture/pillars/security/sec-05-least-privilege/#sec-54-review-actual-entitlements-against-intended-ones-on-a-cadence) and necessary. The sovereignty question extends the enumeration to everyone else with a technical path. Work through the layers. **Your users and workloads**, which your access model governs. **Your administrators**, who can usually reach everything. **The provider's operators**, who maintain the infrastructure the workload runs on. **Subprocessors and vendors**, which is [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/). **Anyone with legal authority over any of them**, which is the jurisdictional question. For each layer, the useful answers are what the path is, what constrains it, and what records it. A path that exists with contractual constraints and audit records is a different position than a path that exists unexamined. The point is not to conclude that provider access is unacceptable. It is normal, necessary for operating a platform, and governed. The point is that a Tier 1 assessment will ask, and the answer should be researched rather than improvised. **On STACKIT.** The platform's own controls and certifications describe the provider-side position, and the certification scope in [`SOV 8.1`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-81-identify-which-frameworks-actually-apply) is the evidence that the controls exist and are audited. What you control architecturally is how much is exposed in the first place, which is the rest of this question. A managed service means the provider operates the layer, which is the trade `COST 1.2` prices and [`SOV 8.3`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-83-establish-the-responsibility-split-per-control) maps. Running the same component yourself moves the operational burden to you and narrows the access surface, and for Tier 1 that trade sometimes runs the other way than it does elsewhere. **Tradeoffs.** **Operational Excellence.** Reducing provider access generally means operating more yourself, which costs the expertise and the hours that [`COST 1.2`](/architecture/pillars/cost-optimization/cost-01-cost-model/#cost-12-include-operational-labour-not-only-resource-consumption) counts. **Verify.** List every party with a technical path to your Tier 1 data. For each, what constrains it and what records its use? --- ## SOV 5.2 Close the data-in-use gap where the tier requires it **Risk if not established:** High Confidential computing is the mechanism that addresses the third state. Data stays encrypted in memory, and the isolation is enforced by the processor rather than by the software stack around it, which means the host operator has no path to the plaintext. The property that matters beyond the encryption is **remote attestation**: a cryptographic statement that the workload is running in the configuration you expect, on hardware you can verify, rather than in an environment that merely claims to be. Without attestation, the encryption protects against an adversary who was already excluded; with it, the claim becomes demonstrable to a third party. That demonstrability is why this is a sovereignty control and not only a security one. It converts a statement about operator access into evidence, which is exactly what [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/) and [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) need. Establish availability before the design depends on it. Confidential computing is not universally available, and a Tier 1 requirement that assumes it needs the assumption confirmed early. **On STACKIT.** Data-in-use protection is a conversation to have with STACKIT during design rather than a setting to switch on, so a Tier 1 workload that depends on it raises it while the architecture is still cheap to change. Bring the two questions an assessment will ask, because assessments do ask them: which technology encloses the memory, and what the attestation ultimately proves. Those two decide whether the control counts as evidence or as a claim, and an answer you cannot source is a claim. **Tradeoffs.** **Performance Efficiency** and **Cost Optimization.** Confidential computing carries overhead and a narrower set of available configurations. **Operational Excellence.** It is a different operating model with its own attestation and key handling, rather than a setting on an existing cluster. **Verify.** For your Tier 1 workload, is data protected while in use? If not, is that a recorded decision or an unexamined default? --- ## SOV 5.3 Constrain the support and operations paths **Risk if not established:** Medium The access path most likely to be used is the one created for a legitimate purpose during an incident, when normal constraints are least welcome. Four things make it governable rather than exceptional. **Scope**, so that support access reaches the component in question rather than the estate. **Duration**, so that access granted for an incident ends with it, which is the same expiry [`SEC 5.2`](/architecture/pillars/security/sec-05-least-privilege/#sec-52-prefer-elevation-that-expires-over-standing-privilege) argues for. **Records**, so that the use is visible afterwards. **Approval**, so that a person other than the requester agreed. The failure mode is a standing grant created during an incident that nobody removed, which is the same finding [`SEC 5.2`](/architecture/pillars/security/sec-05-least-privilege/#sec-52-prefer-elevation-that-expires-over-standing-privilege) produces from the security side and which here has an additional consequence: a standing path is a standing answer to the question [`SOV 5.1`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-51-establish-who-can-technically-reach-the-data-including-the-provider) asks. Include your own emergency access in this. A break-glass account is a deliberate exception with the same requirements, and its use should be conspicuous rather than merely recorded. **On STACKIT.** The audit log in [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/) is what makes access to platform resources visible after the fact, and it is on by default rather than something to enable. For access inside a workload, the records are your own, which is [`SEC 11.1`](/architecture/pillars/security/sec-11-detection-and-response/#sec-111-collect-security-relevant-signals-where-the-subject-cannot-alter-them). Where a support interaction involves sharing diagnostic data rather than granting access, that is the [`SOV 2.3`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/#sov-23-watch-the-paths-that-are-not-obviously-data-paths) path, and it is worth deciding in advance what may be attached to a ticket. **Tradeoffs.** **Operational Excellence.** Time-bounded, approved access is slower during an incident, which is when speed matters most. The mitigation is preparing the path rather than removing the constraint, so that the approval is fast rather than absent. **Verify.** How many standing access grants exist that were created for a specific past incident? --- ## SOV 5.4 Weigh what restricting access costs you **Risk if not established:** Medium Every reduction in provider access moves work and risk to you, and a design that maximizes restriction without weighing that has usually made the workload worse. The costs are concrete. Support becomes harder when the provider cannot see the system. Managed services become less usable or unavailable. Recovery paths that depend on provider intervention close. Operating expertise has to exist in your team. The benefit is equally concrete and is what the tier is asking for, so the answer is not to minimize restriction either. It is to apply it where the classification requires it and not elsewhere, which is why [`SOV 1.3`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/#sov-13-classify-per-data-set-because-a-workload-rarely-sits-at-one-tier) asks for per-data-set classification rather than one tier for the workload. State the cost in the record. A control whose cost is undocumented gets removed during the first efficiency review by somebody who can see the price and not the reason, which is [`COST 7.4`](/architecture/pillars/cost-optimization/cost-07-flow-based-optimization/#cost-74-reconcile-with-the-reliability-and-performance-decisions-rather-than-around-them) from the other side. Revisit when the mechanisms improve. Confidential computing, key management and access models all develop, and a trade that was unfavourable two years ago may not be today. **On STACKIT.** The clearest case is the managed-versus-self-operated choice. A managed database removes operational work and means the provider operates the layer. Running the equivalent yourself narrows that and hands you patching, backup, failover and expertise, which [`REL 8`](/architecture/pillars/reliability/rel-08-backup-and-restore/) and [`SEC 8`](/architecture/pillars/security/sec-08-hardening-and-patching/) then apply to in full. Neither is the right answer generally. For Tier 3 the managed option is almost always better; for Tier 1 the calculation is genuinely different, and it should be made rather than inherited. **Tradeoffs.** This practice is the tradeoff. Sovereignty controls carry costs that land on **Operational Excellence**, **Reliability** and **Cost Optimization**, and a control whose cost is not written down beside it is the one that gets quietly removed. **Verify.** For your strongest access restriction, what does it cost per year in effort and in capability? Is that written down next to the control? --- ## Related - [`SEC 5`](/architecture/pillars/security/sec-05-least-privilege/) Least privilege, whose enumeration this extends beyond your organization - [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/) Key ownership, the other half of the same question - [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) Jurisdiction, which asks who the parties answer to - [`SOV 8.3`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-83-establish-the-responsibility-split-per-control) Responsibility split, which these decisions move - [Sovereignty tradeoffs](/architecture/pillars/sovereignty/tradeoffs/), which collects what this pillar costs