Cómo proteger datos de clientes (PII y datos financieros) en un SaaS o fintech

El modelo de amenaza de un SaaS que custodia datos de terceros

Cuando un SaaS o fintech almacena PII y datos financieros de sus clientes, asume la posición de operador (controlador-operador, en el lenguaje de la LGPD) de datos que no son suyos. Esto cambia el modelo de amenaza: el atacante no busca solo su operación, sino el agregado de datos de todos sus tenants concentrado en una única plataforma. Un solo compromiso puede exponer a miles de titulares de una vez, y la superficie incluye credenciales de aplicación, claves de API, accesos administrativos internos y el propio plano de control del proveedor de nube.

El NIST SP 800-53 y el NIST Cybersecurity Framework organizan esa defensa en funciones (Identificar, Proteger, Detectar, Responder, Recuperar) y el principio que las atraviesa a todas es la defensa en profundidad: ningún control único debe ser el punto entre el atacante y los datos en claro. El OWASP, en el Top 10 de aplicaciones (A02:2021 Cryptographic Failures, A01:2021 Broken Access Control) y en las cheat sheets, describe los puntos donde las aplicaciones SaaS típicamente fallan: casi siempre en la gestión de claves, en el control de acceso y en el aislamiento, no en la elección del algoritmo de cifrado.

Para el resto de este artículo, el enfoque es técnico y preventivo: las capas concretas que reducen el impacto de un compromiso, en el orden en que suelen ser atacadas. El cumplimiento legal (LGPD) es el contexto, pero el objetivo aquí es la protección técnica del dato, no la atención documental al regulador.

Cifrado en tránsito y en reposo, y la gestión de claves que importa

El cifrado en tránsito es el control más maduro y menos negociable: TLS 1.2 como mínimo, prefiriendo TLS 1.3, con suites de cifrado modernas, HSTS y desactivación de protocolos y cifrados obsoletos (SSLv3, TLS 1.0/1.1, RC4, 3DES). Esto aplica al tráfico cliente-servidor y también al tráfico interno entre microservicios y entre la aplicación y la base de datos: el perímetro interno no es confiable por defecto. La OWASP Transport Layer Security Cheat Sheet y los benchmarks del CIS detallan la configuración segura.

En reposo, AES-256 (GCM para datos de aplicación, con autenticación) es el estándar práctico, y la mayoría de los proveedores ofrece cifrado de volumen y de base de datos transparente. El punto crítico, sin embargo, no es el cifrado: es dónde vive la clave. Claves incrustadas en código, en variables de entorno en texto claro o en archivos de configuración anulan todo lo demás. La recomendación del NIST SP 800-57 (gestión de claves) y la práctica consolidada es usar un KMS dedicado (AWS KMS, Google Cloud KMS, Azure Key Vault o HSM) con envelope encryption: la clave de datos cifra el dato, y la clave maestra del KMS cifra la clave de datos, sin salir nunca del módulo.

Sobre el KMS deben incidir tres disciplinas. Rotación automática de claves en un intervalo definido, con versionado que permita descifrar datos antiguos. Separación de funciones, de modo que quien opera la aplicación no sea quien administra las claves maestras, y que el acceso de descifrado sea autorizado por política y registrado. Y cifrado a nivel de campo para los datos más sensibles (CPF, datos bancarios, secretos de cliente), de modo que incluso un dump completo de la base no revele el contenido sin el acceso a la clave correspondiente.

Vale distinguir qué protege cada capa. El cifrado de disco protege contra la pérdida física y el descarte indebido de medios. El cifrado transparente de base de datos protege contra el acceso directo al archivo. Solo el cifrado a nivel de campo, con la clave fuera de la base, protege el dato contra una credencial de aplicación comprometida o una inyección de SQL exitosa, que es el escenario más probable en un SaaS expuesto a internet.

Tokenización y enmascaramiento: reducir lo que existe para ser robado

La forma más eficaz de proteger un dato sensible es no tenerlo donde no necesita estar. La tokenización sustituye el dato real (número de tarjeta, CPF, cuenta bancaria) por un token sin valor matemático fuera de la bóveda que mantiene el mapeo. La aplicación, los logs y la mayor parte de la base pasan a operar sobre tokens; el dato original queda concentrado en un único componente fuertemente controlado. Para datos de tarjeta, el PCI DSS trata la tokenización como mecanismo central de reducción de alcance, y el mismo razonamiento se aplica a cualquier PII de alto valor.

El enmascaramiento actúa sobre la exposición: al mostrar, exportar o usar datos en ambientes no productivos, se presenta solo lo necesario (los cuatro últimos dígitos, por ejemplo) o un valor sustituto realista. Los ambientes de desarrollo, homologación y analytics no deben recibir PII real: la anonimización o seudonimización de datos antes de salir de producción elimina una fuente recurrente de fuga por controles débiles en ambientes secundarios.

Estos controles refuerzan la minimización: cada campo recolectado y retenido amplía la superficie. Conviene auditar lo que realmente es necesario, definir un período de retención por categoría de dato e implementar purga automática al final del plazo. El dato que no existe no se filtra, y el dato que ya fue descartado dentro de una política clara reduce tanto el riesgo técnico como la exposición en caso de incidente.

Aislamiento multi-tenant, control de acceso y auditoría

En un SaaS multi-tenant, la fuga entre clientes es una de las fallas más graves y específicas del modelo. Hay tres estrategias principales: base de datos por tenant (mayor aislamiento, mayor costo operacional), esquema por tenant, y tabla compartida con identificador de tenant y segregación por fila. Cuando se usa el enfoque compartido, el control no puede depender solo de que la capa de aplicación recuerde filtrar por tenant: la Row-Level Security en la base, aplicada de forma obligatoria, garantiza el aislamiento incluso si una consulta olvida la cláusula. Cada camino de código que toca datos necesita ser validado contra el escenario de confusión de tenant.

El control de acceso sigue el principio de mínimo privilegio del NIST SP 800-53 (familia AC) y del CIS Controls v8: cada identidad, humana o de servicio, recibe solo el acceso necesario, por el tiempo necesario. Para datos sensibles, el acceso administrativo debe ser just-in-time y aprobado, con MFA resistente a phishing, y las cuentas de servicio deben tener credenciales de corta duración en lugar de claves estáticas. RBAC o ABAC bien modelados evitan que un soporte de primer nivel o un job de batch tenga un alcance demasiado amplio.

La auditoría cierra el ciclo. Toda lectura y escritura de datos sensibles, todo acceso administrativo y toda operación de descifrado deben generar un registro con identidad, recurso, acción y hora, en una pista inmutable y centralizada, fuera del alcance de quien es auditado. Sin eso, un acceso indebido es indistinguible del uso legítimo, y la fase de Detección del NIST CSF no tiene materia prima. Los logs de auditoría también son el insumo que permite detectar exfiltración lenta y abuso de credencial interna antes de que escalen.

Prevención y detección de fuga de datos

Incluso con cifrado, tokenización y acceso restringido, los datos escapan por caminos laterales: secretos comiteados en repositorios, claves de API expuestas en logs o en respuestas de error, exportaciones voluminosas no monitoreadas, y bases o buckets mal configurados y expuestos a internet. La prevención de pérdida de datos (DLP) y el escaneo continuo de secretos en el código y en la infraestructura cubren buena parte de esos vectores, así como la revisión de configuración de almacenamiento y el endurecimiento de la postura de nube (CSPM).

La detección complementa la prevención. El monitoreo del comportamiento de acceso (volúmenes anómalos de lectura, acceso fuera de horario, patrones de exfiltración) y la correlación de eventos en un SOC permiten reaccionar mientras el incidente aún es contenible. Y como parte de los datos filtrados solo aparece después (credenciales y bases a la venta en foros y mercados), el monitoreo de exposición en fuentes externas y dark web acorta el tiempo entre la fuga y la respuesta, permitiendo rotar credenciales y notificar antes de que el dato sea ampliamente explotado.

Es aquí donde Decripte actúa como socio técnico: monitoreo y SOC para detección y respuesta, vigilancia de dark web para identificar credenciales y datos expuestos de su organización y de sus clientes, y seguridad preventiva para cerrar las brechas de configuración y acceso antes de que se conviertan en incidente. Para los equipos que están estructurando esta capa, Decripte ofrece un plan gratuito de Gestión de Amenazas, un punto de partida para mapear la exposición sin costo inicial.

Checklist práctico

1. 1

   1. Mapee y clasifique los datos sensibles

   Inventaríe dónde se recolectan, transitan y persisten la PII y los datos financieros (bases de datos, cachés, colas, logs, backups, ambientes no productivos). Clasifique por sensibilidad y defina el tratamiento exigido para cada categoría antes de aplicar controles.

2. 2

   2. Fuerce el cifrado en tránsito

   Exija TLS 1.2+ (prefiriendo 1.3) con HSTS en el tráfico externo y también entre servicios internos y bases de datos. Desactive protocolos y cifrados obsoletos siguiendo la OWASP TLS Cheat Sheet y los benchmarks del CIS.

3. 3

   3. Centralice las claves en un KMS

   Migre las claves incrustadas a un KMS o HSM con envelope encryption, rotación automática, versionado y separación de funciones entre la operación de la aplicación y la administración de las claves. Aplique cifrado a nivel de campo a los datos más sensibles.

4. 4

   4. Tokenice y enmascare

   Sustituya números de tarjeta, CPF y datos bancarios por tokens, manteniendo el dato real solo en la bóveda. Enmascare en pantallas, exportaciones y logs, y elimine o seudonimice la PII de los ambientes de desarrollo y analytics.

5. 5

   5. Garantice el aislamiento entre tenants

   Elija la estrategia de aislamiento de forma explícita y, en modelos compartidos, aplique Row-Level Security en la base. Incluya pruebas que validen que ningún camino de código devuelve datos de otro tenant.

6. 6

   6. Aplique mínimo privilegio y auditoría

   Modele RBAC/ABAC con acceso just-in-time y MFA resistente a phishing para datos sensibles. Use credenciales de corta duración para los servicios y registre toda lectura, escritura y descifrado en una pista de auditoría inmutable y centralizada.

7. 7

   7. Monitoree fugas y exposición

   Implemente DLP y escaneo de secretos, revise la configuración de buckets y bases expuestas y establezca monitoreo continuo de acceso anómalo y de exposición en dark web para reducir el tiempo de respuesta a incidentes.

Preguntas frecuentes