Audit trail y compliance — trazabilidad sin tracking
Los sistemas SSI gob enfrentan un dilema operativo: necesitan auditoría (compliance regulatorio, investigación de fraude, transparencia) pero deben preservar privacy (LPDP, principio de minimización).
La resolución no es elegir entre uno y otro — es diseñar la auditoría desde el principio para ser estructuralmente compatible con privacy.
El dilema en una frase
Hoy, sistemas centralizados resuelven auditoría guardando todo: quién hizo qué cuándo. Sistemas SSI con privacy by design resuelven privacy minimizando todo. La pregunta: ¿cómo se obtiene trazabilidad operativa con minimización de datos personales?
Las 5 categorías de auditoría
Cinco tipos de auditoría que un sistema SSI gob necesita soportar:
| Categoría | Qué se audita | Privacy concern |
|---|---|---|
| Operativa | Sistema funcionando OK | Sin datos personales |
| Seguridad | Intentos de fraude, breaches | Sin datos personales agregados |
| Compliance regulatoria | LPDP, Ley 27.275 | Métricas + datos cuando hay orden judicial |
| Investigativa | Fraude específico, mala praxis | Datos puntuales con orden judicial |
| Transparencia pública | Funcionamiento del sistema | Agregados, sin individuales |
Cada categoría tiene distinta política de retención + acceso.
Lo que SÍ se loggea
| Tipo de evento | Datos loggeados | Por qué |
|---|---|---|
| Emisión de credencial | Tipo de credencial + timestamp + issuer | Sin datos del subject |
| Revocación | Tipo + timestamp + razón categórica | Sin identificar al individuo |
| Verificación | Tipo + timestamp + resultado | Sin identificar a verifier o subject |
| Errores operativos | Tipo + timestamp | Sin contenido del request |
| Configuración del sistema | Cambios + operador + timestamp | Trazabilidad de admin |
Lo que NO se loggea (por default)
- DIDs específicos del holder que se presentan a verificadores.
- Contenido específico de las credenciales que se intercambian.
- Patrones de uso del holder.
- Relaciones entre verifiers (qué verifier consultó qué credencial).
El default es minimización agresiva. Excepciones requieren justificación explícita.
El acceso a logs
Tres niveles de acceso típicos:
Acceso operativo
Equipo del sistema. Ven logs agregados, sin datos individuales.
Acceso compliance
Audit team. Ven logs agregados + alertas. Pueden requerir datos puntuales con justificación.
Acceso investigativo
Con orden judicial. Acceso a datos específicos del evento bajo investigación.
El reto de detectar fraude
Sin datos identificables, ¿cómo se detecta fraude?
Tres aproximaciones complementarias:
- 1Patterns no-identificables. "Hubo 1000 emisiones de constancia de domicilio en 1 hora desde la misma IP" — anomalía detectable sin identificar individuos.
- 2Anonymized fraud signals. Hashes de patrones que indican fraude potencial. Sin posibilidad de reverse-engineering.
- 3Investigación bajo orden. Cuando hay sospecha fundada, orden judicial habilita acceso a datos específicos.
Estos tres aproximaciones se combinan para mantener compliance + privacy.
El audit trail criptográficamente protegido
Los logs en sí mismos deben ser protegidos:
Append-only
Los logs nunca se modifican. Solo se agregan nuevas entradas. Tampering imposible sin detección.
Chain of hashes
Cada entry incluye hash del anterior. Modificar un log rompe la chain.
Timestamp criptográfico
Usando servicios de timestamp (RFC 3161) o anchors blockchain.
Backup distribuido
Logs guardados en múltiples lugares para prevenir destrucción.
Cumplimiento LPDP
LPDP exige cuatro cosas específicas relevantes para audit:
- 1Logs de access requests: quién pidió datos personales, cuándo, por qué.
- 2Logs de modificación: cuando un ciudadano rectifica sus datos.
- 3Logs de cancelación: cuando un ciudadano pide eliminación.
- 4Logs de oposición: cuando un ciudadano se opone al tratamiento.
Los cuatro son operativos del sistema, no de los individuos. Se loggean sin comprometer privacy individual.
Cumplimiento Ley 27.275
La Ley 27.275 (acceso a información pública) exige que el sistema:
- Publique información agregada sobre funcionamiento.
- Pueda responder solicitudes de información en plazos.
- Documente sus excepciones cuando rechaza solicitudes.
Esto se cumple con dashboards públicos + procesos transparentes, sin comprometer datos individuales.
La retención
¿Cuánto tiempo se guardan los logs?
| Tipo | Retención típica |
|---|---|
| Logs operativos del sistema | 1-2 años |
| Logs de errores | 6-12 meses |
| Logs regulatorios LPDP | 5-10 años (per ley) |
| Logs de auditoría compliance | 5-10 años |
| Logs investigativos | Específico al caso |
Después del período, los logs deben ser destruidos o anonimizados de forma irreversible.
Los anti-patrones
Tres prácticas que rompen el balance:
El stack técnico
Una implementación robusta usa:
- Centralized logging: Elasticsearch, Splunk, AWS CloudWatch.
- Append-only storage: S3 Object Lock, dedicated WORM storage.
- Access control: IAM riguroso, principle of least privilege.
- Audit of logs: los logs mismos están auditados (meta-audit).
- Encryption at rest: logs encriptados con keys separadas.
Referencias
- LPDP 25.326 — Argentina
- NIST SP 800-92 — Guide to Computer Security Log Management
- RFC 3161 — Time-Stamp Protocol
Relacionados
- Key management del issuer — el corazón de la seguridad — el contexto criptográfico
- Consent management — el consentimiento como datos — el siguiente nivel privacy
- LPDP 25.326 — qué pide a la identidad digital — el marco regulatorio