SOV 5. How do you limit provider and operator access, including to data in use?
Last updated on
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
Section titled “Best practices”SOV 5.1Establish who can technically reach the data, including the providerSOV 5.2Close the data-in-use gap where the tier requires itSOV 5.3Constrain the support and operations pathsSOV 5.4Weigh what restricting access costs you
SOV 5.1 Establish who can technically reach the data, including the provider
Section titled “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 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. 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 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 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 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
Section titled “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 and SOV 8 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
Section titled “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 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 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 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 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.
Where a support interaction involves sharing diagnostic data rather than granting access, that is
the SOV 2.3 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
Section titled “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 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 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 and
SEC 8 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
Section titled “Related”SEC 5Least privilege, whose enumeration this extends beyond your organizationSOV 4Key ownership, the other half of the same questionSOV 6Jurisdiction, which asks who the parties answer toSOV 8.3Responsibility split, which these decisions move- Sovereignty tradeoffs, which collects what this pillar costs