OpenBao Transit en pymes: cifrado, llaves y auditoría
Guía técnica para separar datos sensibles, llaves y permisos con OpenBao Transit. Flujo, costo, pruebas y límites antes de llevarlo a producción.
Una clave de cifrado en OpenBao Transit recibe texto codificado y devuelve un cifrado que la aplicación guarda en su propia base. Ese gesto separa dos responsabilidades que muchas pymes mezclan en un mismo servidor: dato operativo y llave criptográfica. Para una clínica de Godoy Cruz, el objetivo es proteger DNI, token o credencial sin cambiar todo el sistema. Esta nota explica el flujo, los permisos y la prueba.
Dónde aparece el dato sensible
La documentación de OpenBao Transit describe un motor que ejecuta funciones criptográficas sobre datos en tránsito: cifra, descifra, firma, verifica, genera HMAC y produce bytes aleatorios. El dato llamativo está en el propio flujo: el texto plano viaja codificado en base64 y la respuesta entrega un ciphertext con versión, mientras la aplicación conserva ese resultado en PostgreSQL, ERP o sistema propio. La documentación de qué. OpenBao ordena la parte de acceso: el cliente se autentica, recibe un token y queda asociado a una política. El antagonista operativo es el archivo de entorno copiado de proyecto en proyecto, dónde la misma contraseña vive al lado del código y nadie sabe qué proceso la leyó. Una credencial pegada en un archivo.env puede durar más que el contrato del proveedor. La cifra externa viene de la Stack Overflow Developer Survey 2025: en proyectos de trabajo, las preocupaciones de seguridad o privacidad aparecen como el primer motivo para rechazar una tecnología. OpenBao entra cuando esa objeción debe convertirse en control medible: quién pidió cifrar, qué llave usó, qué respondió el sistema y qué quedó en auditoría.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. La aplicación detecta un dato sensible, lo codifica en base64 y llama al endpoint de cifrado de Transit. 2. OpenBao valida el token contra una política por ruta y operación. 3. Transit usa una llave nombrada, devuelve el ciphertext y registra la operación en el dispositivo de auditoría. 4. PostgreSQL guarda el ciphertext junto con usuario, estado y referencia del registro de negocio. 5. La aplicación descifra solo cuando el rol autorizado necesita leer el dato y vuelve a registrar el acceso. 6. El backup copia configuración, almacenamiento de OpenBao, base de la aplicación y logs; una prueba restaura ambos lados y descifra un registro de ensayo. OpenBao recibe tokens, rutas, texto codificado y solicitudes de operación; entrega ciphertext, firmas, verificaciones y registros de auditoría. PostgreSQL guarda registros estructurados y el valor cifrado. El administrador de seguridad maneja políticas y llaves; desarrollo consume una API acotada. Si OpenBao falla, la aplicación puede seguir mostrando datos no sensibles, pero cualquier lectura cifrada debe mostrar una alerta clara.
Qué se instala o configura primero
La pila inicial puede usar OpenBao 2.7.x, PostgreSQL 17, Caddy con HTTPS, un backend de almacenamiento, políticas por aplicación, un dispositivo de auditoría declarado en configuración y monitoreo de disponibilidad. Un VPS 2 vCPU y 4 GB cuesta entre USD 12 y USD 24 por mes; al dólar oficial venta de $1540 equivale a $18.480 a $36.960. Para producción conviene sumar réplica, almacenamiento y respaldo externo, con costo aparte. UMSA suele iniciar con una llave por aplicación y un dato de bajo riesgo antes de tocar información sensible real. El primer entregable verificable es un endpoint que cifra y descifra un valor de prueba, una política que bloquea rutas indebidas, un log de auditoría abierto y un procedimiento de restauración. Gerencia ve una respuesta corta: el dato vive en la base, la llave vive en OpenBao y el acceso queda registrado.
Dónde se rompe y cómo probarlo
El primer riesgo es dar una política amplia. La señal aparece cuando un token de lectura puede administrar llaves. La prueba mínima es llamar rutas permitidas y bloqueadas con tres tokens distintos. El segundo riesgo es registrar texto sensible en logs de aplicación. La señal aparece cuando el valor previo al cifrado queda en una traza. La prueba mínima es ejecutar cifrado con dato de ensayo y buscarlo en logs. El tercer riesgo es respaldar base y olvidar OpenBao. La señal aparece cuando PostgreSQL vuelve con ciphertext y nadie puede descifrarlo. La prueba mínima es restaurar ambos sistemas y abrir un registro cifrado. El cuarto riesgo es rotar llaves sin reenvolver datos antiguos. La señal aparece cuando conviven versiones y la aplicación no registra cuál usó. La prueba mínima es cifrar, rotar, reenvolver una muestra y descifrar valores viejos y nuevos. La primera decisión verificable es elegir un dato, una llave, una política y una prueba de restauración. El resto puede crecer desde ahí.
