Organizations that generate structured output, CSV reports, JSON payloads, analytics dashboards, often do so from scripts that run under a shared service account. Those scripts connect directly to the underlying database or analytics engine, using static credentials stored in CI pipelines or configuration files. Because the connection bypasses any enforcement point, the organization cannot tell which engineer triggered a particular export, whether the data contained sensitive fields, or whether a risky query received a review before execution. The result is a black box that fails ISO 27001’s evidentiary requirements.
Identity providers such as OIDC or SAML can ensure that only members of approved groups obtain tokens, but a token alone does not record what the holder actually does, nor can it intervene when a query attempts to exfiltrate personally identifiable information. Even with least‑privilege roles that restrict access to read‑only tables, a user can still run a SELECT that returns an entire customer table, copy it locally, and ship it out of the network. The request travels straight to the target service, and the only audit trail lives in the target’s own logs, logs that are often incomplete, unstructured, and inaccessible to the compliance team without additional tooling. To meet ISO 27001, an organization needs a control point that can record sessions, mask sensitive data, require just‑in‑time approvals, and block disallowed commands before they reach the target.
Introducing a data‑path gateway
hoop.dev fills the missing enforcement layer by sitting in the data path as a Layer 7 gateway. Every connection from a user or an automated agent to a database, Kubernetes cluster, or other supported target passes through hoop.dev. The gateway validates the OIDC token, extracts group membership, and then applies policy before the request reaches the target.
Because hoop.dev is the only point where traffic is inspected, it can:
- Record each session, capturing the user identity, timestamps, and the exact commands or queries issued.
- Mask sensitive fields in the response stream, ensuring that downstream files never contain raw credit‑card numbers or personal identifiers unless a higher‑level approval is granted.
- Require just‑in‑time approval for risky operations, such as exporting more than a configured row count or accessing tables labeled as confidential.
- Block disallowed commands outright, preventing accidental or malicious data exfiltration.
All of these enforcement outcomes exist only because hoop.dev sits in the data path; the identity system alone cannot provide them.
Generating iso 27001 evidence
iso 27001 demands documented evidence that access to information assets is controlled, monitored, and reviewed. hoop.dev produces that evidence automatically:
- Per‑user session logs – each log entry includes the authenticated subject, the exact query, and the outcome. Auditors can filter logs by user, date range, or data category.
- Approval trails – when a request triggers a JIT approval, hoop.dev stores the approver’s identity, the reason for approval, and the time of decision. This satisfies the control that “privileged actions are reviewed before execution.”
- Data‑masking records – the gateway logs which fields were masked and which remained visible, giving a clear picture of data‑handling policies in practice.
- Replay capability – recorded sessions can be replayed in a sandbox, allowing auditors to verify that the observed behavior matches the logged intent.
Because the logs originate at the gateway, they remain immutable from the perspective of the target system. The compliance team can retain them in an audit‑ready storage solution of its choice, and the logs are structured enough to feed directly into iso 27001 audit tools.
How the pieces fit together
The overall architecture consists of three layers:
- Setup: An identity provider issues OIDC tokens. Roles and groups reflect business responsibilities. This layer decides who may start a session but does not enforce what the session does.
- The data path: hoop.dev sits between the requester and the target service. It is the sole place where policy can be evaluated, data can be masked, and approvals can be requested.
- Enforcement outcomes: Session recording, inline masking, JIT approval, and command blocking all happen inside hoop.dev. Without the gateway, none of these controls would exist.
By separating identity verification from policy enforcement, organizations gain a clear, auditable boundary that aligns with iso 27001’s requirement for “controlled access” and “monitoring of information access.”
Getting started
Begin with the getting‑started guide. It walks you through deploying the gateway, configuring OIDC, and registering a database connection. The learn section dives deeper into masking policies, approval workflows, and session replay.
FAQ
Q: Does hoop.dev replace my existing database credentials?
A: No. The gateway stores the credential it uses to talk to the target, while users authenticate with their own OIDC token. The original credential never leaves hoop.dev, reducing credential sprawl.
Q: Can I still run automated jobs that generate reports?
A: Yes. Automated agents can be granted service‑account identities that are verified by the same OIDC flow. Policies can be tuned so routine jobs run without manual approval, while any deviation triggers a JIT request.
Q: How long should I retain session logs?
A: Retention depends on the downstream storage you integrate with hoop.dev. The gateway itself does not impose a limit; you decide the period that satisfies your iso 27001 audit schedule.
Explore the open‑source code on GitHub to see how the gateway is built and to contribute enhancements.
