When a contractor leaves the company, the security team must guarantee that every credential, script and automation the person touched is rendered unusable within minutes. In practice, dozens of internal tools, such as databases, container orchestrators and SSH bastions, remain reachable through shared service accounts or long‑lived tokens that were never rotated. The result is a hidden attack surface that auditors love to point out.
ISO 27001 does not prescribe a specific technology stack, but it does require that organizations demonstrate control over who can use each tool, when the use occurs, and what data flows through the connection. The standard’s Annex A controls demand evidence of authentication, authorization, logging, and review for every privileged interaction. Without a single point that can observe and enforce policy, teams end up stitching together disparate logs that are difficult to correlate.
At its core, ISO 27001 expects three categories of evidence for tool use: a record of the identity that initiated the session, a trace of the commands or queries executed, and a review process that can approve or reject risky actions before they reach the target system. Control A.9.2 (User access management) calls for formal processes to grant, modify, and revoke rights. Control A.12.4 (Logging) requires that logs be protected against tampering and retained for a period that satisfies audit requirements. Control A.14.2 (Security in development and support processes) asks for mechanisms that limit the blast radius of a compromised account.
Key control areas the standard expects
ISO 27001 breaks down the responsibilities into several concrete checkpoints:
- Identity verification: Every request must be tied to a verified, non‑shared identity, preferably using federated authentication such as OIDC or SAML.
- Just‑in‑time provisioning: Access should be granted only for the time needed to perform a specific task, then automatically revoked.
- Command‑level audit: The system must capture each command, query, or API call, along with timestamps and the originating user.
- Inline data protection: Sensitive fields in responses (for example, credit‑card numbers or personal identifiers) must be masked before they are stored in logs.
- Human approval workflow: High‑risk operations, such as dropping a database or modifying a firewall rule, must be routed for manual approval before execution.
- Session recording and replay: The full interaction should be recorded so that investigators can replay exactly what happened during an incident.
Why a centralized gateway is essential
When each tool maintains its own authentication and logging, correlating activity across the environment becomes a manual, error‑prone exercise. Auditors ask for a single, immutable trail that shows the end‑to‑end flow from identity to action. A centralized, protocol‑aware gateway can sit in the data path for every connection, ensuring that the same policy engine enforces the controls listed above regardless of whether the request targets a PostgreSQL database, a Kubernetes cluster, or an SSH host.
Introducing hoop.dev as the data‑path enforcement layer
hoop.dev is a Layer 7 gateway that proxies connections to databases, Kubernetes, SSH, RDP and internal HTTP services. By placing hoop.dev between the identity provider and the target resource, every request passes through a single enforcement point. hoop.dev records each session, masks sensitive response fields, requires just‑in‑time approval for risky commands, and blocks disallowed operations before they reach the backend.