Why LGPD matters for self‑hosted deployments
A data‑science contractor departs, yet a CI job that the contractor configured still holds a static token capable of querying the customer database. The token can run arbitrary SQL against the self‑hosted PostgreSQL cluster, returning names, addresses, and payment details of Brazilian citizens. When the security team discovers the lingering credential, they realize that every query executed by that job is invisible to auditors, and any accidental data exposure would be a direct violation of the Lei Geral de Proteção de Dados (LGPD). The incident highlights a fundamental tension: self‑hosted models give teams full control over infrastructure, but that control often lacks the centralized guardrails required by privacy law.
LGPD’s core technical requirements
LGPD obliges organizations that process personal data of Brazilian residents to demonstrate:
- Accountability: documented policies and technical measures that show how data is handled.
- Purpose limitation and data minimization: only collect and retain data needed for a defined purpose.
- Security of processing: protect data against unauthorized access, alteration, and disclosure.
- Transparency and auditability: maintain records of who accessed what data, when, and why.
- Data subject rights support: be able to locate, correct, or delete personal data on request.
Regulators expect concrete evidence, logs, approvals, and proof of masking, rather than abstract policies.
Where the gap appears in typical self‑hosted stacks
Most self‑hosted environments rely on static credentials stored in configuration files or secret managers that are accessed directly by applications. Access control is often enforced at the identity provider level, while the actual database or Kubernetes API sees the request as coming from a service account with broad privileges. This architecture creates three blind spots:
- No unified audit trail. Each component writes its own logs, making it hard to reconstruct a complete picture of a user’s activity.
- No real‑time data protection. Sensitive fields travel in clear text from the database to the client, so any compromised client can exfiltrate personal data.
- No just‑in‑time approval. Long‑lived credentials allow any command, even dangerous ones, without a human review.
Because the enforcement points sit inside the target services, removing a credential or revoking a role does not retroactively protect data that has already been read.
How hoop.dev fills the gap
hoop.dev is a Layer 7 gateway that sits between identities and the self‑hosted resources you need to protect. It intercepts traffic at the protocol level, whether the client is psql, kubectl, or ssh, and applies policy before the request reaches the target. By placing the enforcement layer in the data path, hoop.dev becomes the sole place where masking, approval, and recording can be guaranteed.