A sovereign storage deployment is usually described by where the data sits and which staff can log in. Both descriptions tend to omit the vendor. Support tunnels, phone-home telemetry and remote diagnostic sessions are a working path into the system, frequently granted once at installation and never reviewed, and often exempted from the change control, approval and logging applied to every other form of access.
The exemption is rarely deliberate. Support access is negotiated by an operations team under time pressure during an incident, documented in a runbook rather than an architecture, and then inherited by everyone who follows. By the time a sovereignty review takes place, the tunnel is treated as part of the platform rather than an access path with a jurisdiction at the other end.
The engineer at the far end of the session holds effective administrative capability over a system whose sovereignty argument rests on the claim that only named local staff do. Vendor support should exist, since a storage platform without it is a different and worse risk. The question is whether that access is bounded, brokered, recorded and reviewable in the same way as any other privileged path.
Remote support is not one mechanism but several, with different owners. An inbound tunnel, typically a jump host or VPN endpoint the vendor connects into, is the one most people picture and the one most likely to be documented. An outbound call-home channel, in which the system itself initiates a connection to the vendor to deliver health data, is harder to see because it looks like ordinary egress and is often permitted by a firewall rule written years earlier.
A third path is the interactive screen-sharing session, where an administrator joins a call and shares a console. Nothing in the storage system records that session, because from the system's perspective the local administrator performed every action. A fourth is the cloud-hosted management or monitoring plane, where the vendor operates a service that holds configuration and telemetry from the deployment, which places a copy of operational data outside the boundary regardless of where bulk data resides.
Each has a different data flow and a different controlling entity, and a review covering only the first describes the system as more closed than it is. The same enumeration discipline that applies to logs crossing a data boundary applies here, since telemetry and support are usually the same channel.
Most support arrangements are standing: a vendor account exists, a key is installed, or a tunnel is left configured, and it works whenever the vendor chooses to use it. Standing access is convenient during an incident and indefensible in review, since the vendor's ability to reach the system is continuous while the customer's awareness of it is episodic.
The alternative is just-in-time access, where no usable credential exists until a request is approved, the credential is issued for a bounded window, and it expires without any action. The mechanism can be a privileged access broker, a time-limited certificate, or a tunnel endpoint that is administratively disabled and enabled per ticket. What makes it work is not the technology but the default state, which is closed.
Just-in-time access also produces the artifact a review needs: every grant has a requester, an approver, a reason, a start time and an end time, which converts an unbounded capability into a countable series of events. If the enumeration of privileged actors is part of who can change the system, then support sessions belong in that enumeration with names attached.
The diagnostic bundle is the least examined data flow in most deployments. It is generated during an incident, uploaded to a vendor portal, and treated as a technical artifact rather than an export of data. Contents vary by product and version, and few organizations have opened one.
A bundle typically includes configuration, cluster state, performance counters and system logs. Depending on the product it may also include object keys and bucket names, account and user identifiers, IP addresses and hostnames, access logs showing which principal read which path, and occasionally fragments of payload captured in a stack trace or debug-level log line. Object keys alone can be disclosive, since key names often encode customer identifiers, case numbers or file names.
| Support path | What it can reach | What to require before it is used |
|---|---|---|
| Inbound tunnel or jump host | Interactive administrative access to nodes and management interfaces | Per-ticket enablement, named vendor identity, session recording |
| Outbound call-home | Continuous export of configuration, counters and health state | Destination, payload contents and an option to route through a local relay |
| Screen-sharing session | Everything the local administrator can see and do | A local operator at the keyboard and a record of commands executed |
| Diagnostic bundle upload | Logs, configuration, identifiers and possibly object key names | A local review step and a documented manifest of bundle contents |
| Vendor-hosted management plane | Persistent copy of configuration and telemetry outside the boundary | Hosting location, retention period and controlling legal entity |
The practical control is a manifest and a local inspection step. A bundle written to a local path, reviewed or redacted, then uploaded deliberately is a different artifact from one that leaves automatically.
Three questions decide whether support access is auditable. Who approves a session, and is that person inside the organization. What is recorded, and is the record held by the customer rather than the vendor. How long is it kept, and does it survive the case being closed.
Session recording is the control most often skipped, on the assumption that it is intrusive or expensive. In practice a terminal session proxy capturing commands and output produces the only evidence that answers what an auditor will actually ask, which is what the vendor did, not what it could do.
Approval routing deserves the same scrutiny. If the approver is the same engineer who opened the case, the control is procedural rather than real. If approval can be granted by the vendor's own portal, the control does not exist. These conditions are cheap to write into a contract at renewal and nearly impossible to retrofit during an outage, which is why they belong in procurement checks on the vendor and its subcontractors rather than in an operations runbook.
RING is software-defined storage deployed on the customer's own servers inside the customer's own facility, so the network boundary around the system is one the operator defines. Support connectivity is something the operator permits rather than inherits from a hosted service, which makes per-ticket enablement and local brokering an available design rather than a negotiation.
RING emits operational metrics and logs that the operator can retain locally. That matters because it separates two things often bundled together: the telemetry an operator needs day to day, which can stay inside the boundary, and the subset a vendor needs during a case, which can be produced deliberately and reviewed before it is sent. Administrative access itself follows the customer's own account and policy model, so vendor identities, where they exist, are visible in the same place as every other privileged account.
Write down every support path that exists today, including unused ones: tunnel endpoints, call-home destinations, vendor accounts, installed keys, firewall rules permitting egress to vendor domains, and any hosted management service holding a copy of configuration. For each, record the default state, the approval path, what is recorded and where the record lives. A path that cannot be described in those four fields is standing access regardless of what the contract says.
Review that list quarterly and after every vendor upgrade, since upgrades reintroduce default call-home settings with some regularity. Once a year, generate a support bundle and read it, so its contents are known. Include one support session in the evidence sample for any sovereignty audit, and require that the session record be produced from the customer's own system rather than from the vendor's case notes.