Un plan práctico de gestión de secretos para aplicaciones autoalojadas

Por qué la gestión de secretos es un requisito operativo, no solo un requisito de seguridad

Una aplicación autoalojada rara vez funciona con una sola credencial. Puede necesitar una cuenta de base de datos, una contraseña SMTP, tokens de API de terceros, webhooks, material de firma y una o más claves de cifrado. Si esos valores no se gestionan, el trabajo rutinario se vuelve arriesgado: es más difícil reproducir una implementación, la salida de un miembro del personal deja accesos poco claros y una sospecha de exposición puede convertirse en una interrupción urgente.

Un proceso útil de gestión de secretos hace que el trabajo autorizado sea predecible. El equipo sabe qué hace cada secreto, quién es responsable de él, dónde se proporciona, de qué aplicación depende y cómo puede sustituirse. Esto es coherente con el énfasis de NIST CSF 2.0 en establecer, comunicar y aplicar roles, responsabilidades y autoridades de ciberseguridad.

La infraestructura gestionada puede reducir la carga operativa en torno a una aplicación, pero no resuelve la gobernanza de credenciales. Por ejemplo, Airbip implementa aplicaciones de catálogo como cargas de trabajo Docker en sus servidores en la nube y automatiza el enrutamiento y los certificados TLS mediante Traefik y Let’s Encrypt. Los clientes aún deben decidir quién puede crear, aprobar, ver y rotar las credenciales de aplicación que conectan esas cargas de trabajo con bases de datos y servicios externos.

• Trate cada secreto de producción como una dependencia operativa con un responsable.
• Diseñe procedimientos de sustitución antes de que se sospeche urgentemente o se sepa que un secreto ha sido expuesto.
• Cuando sea práctico, mantenga separadas las responsabilidades de administración de infraestructura y la aprobación comercial de cuentas sensibles de terceros.

Qué se considera un secreto

Un secreto es información cuya divulgación podría permitir acceso no autorizado, suplantación, descifrado o una acción privilegiada. Una clave secreta simétrica, por ejemplo, es una clave criptográfica que no es pública y cuya confidencialidad es fundamental para su propósito.

No limite el registro a valores llamados literalmente PASSWORD. Una cadena de conexión puede contener un nombre de usuario y una contraseña. Una exportación de configuración puede contener un token de integración. Una clave privada, un valor de firma de cookies, un secreto de cliente OAuth o un código de recuperación pueden tener más consecuencias que una contraseña convencional.

En cambio, la configuración ordinaria normalmente no concede acceso si se divulga. Algunos ejemplos pueden incluir la URL pública de una aplicación, un ajuste de funcionalidad no sensible, una configuración regional o una elección de nivel de registro. La clasificación debe basarse en lo que permite la divulgación, en lugar de en el nombre de una variable de entorno.

• Nombres de usuario y contraseñas de bases de datos, incluidas las credenciales incorporadas en cadenas de conexión.
• Tokens de API, secretos de webhook y secretos de cliente OAuth utilizados por integraciones.
• Nombres de usuario y contraseñas SMTP utilizados para enviar correo electrónico desde la aplicación.
• Valores de firma de sesión, claves privadas y otras claves de firma.
• Claves de cifrado, material de cifrado de claves y códigos de recuperación.
• Contraseñas de administrador y tokens de acceso para cuentas de aplicaciones, servidores o servicios de terceros.

Separe los secretos de la configuración no sensible antes de la implementación

Antes de la implementación, cree dos listas: configuración que puede conservarse en la documentación ordinaria de implementación y valores que necesitan un manejo restringido. Este pequeño paso evita un modo de fallo común en el que un práctico archivo .env se convierte en la fuente informal de referencia para todo, incluidas las credenciales de producción.

Para implementaciones basadas en Docker, utilice un método separado de entrega de secretos cuando la aplicación lo admita. Docker recomienda utilizar secretos en lugar de variables de entorno para valores sensibles en implementaciones con Compose. Los secretos de Compose se declaran en el nivel superior y después se conceden explícitamente a servicios individuales; un servicio no puede acceder a un secreto declarado salvo que su propia definición incluya esa concesión.

Los secretos de Docker se montan como archivos en lugar de establecerse directamente como variables de entorno, normalmente en /run/secrets. Este enfoque puede limitar qué servicio recibe un valor. No elimina la necesidad de proteger el host, la configuración de implementación ni a las personas con acceso administrativo, y la aplicación debe poder leer el secreto en el formato proporcionado.

Evite incluir credenciales de compilación en argumentos de compilación o variables de entorno de Docker. Docker indica que estos pueden persistir en la imagen final. Utilice montajes de secretos de compilación o montajes SSH para las credenciales necesarias solo durante una compilación. Excluya también los archivos .env del contexto de compilación con .dockerignore cuando puedan contener secretos; de lo contrario, pueden incluirse en una capa de la imagen.

• Clasifique cada valor de implementación antes de añadirlo a un archivo Compose, una tarea de CI o un panel de administración.
• Conceda un secreto de Docker Compose solo al servicio que lo necesite.
• Revise la documentación de configuración de la aplicación para determinar si acepta un secreto desde un archivo, una variable de entorno u otro mecanismo.
• Revise Dockerfiles, contextos de compilación e historial de imágenes cuando se hayan utilizado credenciales en tiempo de compilación.

Mapee todos los lugares donde puede exponerse un secreto

Un secreto está protegido solo tanto como lo esté cada una de sus copias. El archivo de implementación es solo una ubicación que debe inspeccionarse. Los artefactos de compilación, el portátil de un desarrollador, una solicitud de soporte archivada o una configuración exportada pueden convertirse discretamente en copias adicionales que sobreviven a la credencial prevista.

Cree un mapa de exposición para cada secreto de alto valor. Registre tanto las ubicaciones intencionadas, como un almacén de secretos restringido, como las posibles ubicaciones accidentales, como el historial de shell, capturas de pantalla o informes de errores. El mapa es especialmente valioso durante la respuesta a incidentes porque indica al equipo qué debe revisarse después de una rotación.

Los registros merecen atención explícita. OWASP ASVS señala que las credenciales y los datos de pago pueden estar prohibidos en los registros, mientras que los tokens de sesión pueden necesitar hash o enmascaramiento. También incluye un requisito de verificación para documentar un inventario de los archivos y servicios donde se almacenan o difunden los registros. Trate los destinos de registros, los rastreadores de errores y los canales de soporte como parte del perímetro de secretos.

• Repositorios de código fuente, incluidos archivos .env confirmados, ejemplos e historial de confirmaciones.
• Archivos Compose, variables de CI/CD, historial de shell y salida de línea de comandos.
• Registros de contenedores, registros de proxy inverso, informes de errores de aplicaciones y servicios externos de registros.
• Tickets de soporte, mensajes de chat, correo electrónico, capturas de pantalla y salida de terminal copiada.
• Copias de seguridad, volcados de bases de datos, exportaciones de configuración y antiguas instantáneas de servidores.
• Equipos de administradores, bóvedas de gestores de contraseñas, sesiones de navegador y medios extraíbles.

Elija un modelo de responsabilidad antes de conceder acceso

Los equipos pequeños a menudo concentran la responsabilidad en una cuenta de administrador. Esto puede ser conveniente, pero dificulta la aprobación, la recuperación y la desvinculación. En su lugar, asigne roles nominativos para cada secreto importante, incluso cuando una persona asuma temporalmente más de un rol.

Un modelo práctico separa al responsable de la aplicación, al administrador de infraestructura y al responsable del servicio de terceros. El responsable de la aplicación decide si una integración es necesaria y acepta su riesgo comercial. El administrador de infraestructura proporciona la configuración aprobada al servicio en ejecución y mantiene el acceso a la implementación. El responsable del servicio de terceros administra la cuenta externa que emitió la credencial, como un proveedor de correo electrónico o una plataforma de API.

La guía de NIST respalda definir roles y restringir cuentas privilegiadas al personal o los roles definidos. Cuando sea posible, los administradores deben usar cuentas sin privilegios para el trabajo ordinario y reservar el acceso privilegiado para las tareas que lo requieran.

• Responsable de la aplicación: aprueba el propósito, el uso de datos y la necesidad comercial.
• Administrador de infraestructura: implementa los valores aprobados y controla el acceso a nivel de plataforma.
• Responsable del servicio de terceros: gestiona la cuenta del proveedor externo, la relación de facturación y la emisión de credenciales.
• Revisor de seguridad u operaciones: confirma periódicamente el acceso, la caducidad, el estado de rotación y la preparación para la recuperación.

Almacene y proporcione secretos de forma segura

Elija el proceso más sencillo que limite de forma fiable la divulgación y permita la recuperación. La mejor opción depende del tamaño del equipo, el número de aplicaciones, la rotación de personal, los requisitos de cumplimiento y la frecuencia con la que cambian las credenciales. Un sistema maduro de secretos no es automáticamente el primer paso adecuado si el equipo no puede operarlo de forma coherente.

Un almacén de secretos cifrado con acceso individual de usuarios suele ser una buena elección cuando varias personas necesitan acceso controlado a un inventario creciente. La configuración de implementación restringida es útil cuando el mecanismo de implementación puede limitar quién puede leer o modificar un valor. Un flujo de entrada manual puede ser apropiado para un número reducido de cambios poco frecuentes, siempre que el proceso registre quién introdujo el secreto, dónde se introdujo y cómo se recupera el valor.

Evite tratar un documento compartido en texto sin formato, un chat de equipo sin restricciones o un repositorio como el almacén principal de secretos de producción. Tampoco suponga que un secreto de Compose es una bóveda completa: Compose puede obtener el contenido secreto de un archivo del host o, en Docker Compose, de una variable de entorno del host. Esas ubicaciones de origen requieren sus propios controles de acceso. Los secretos de Compose respaldados por variables de entorno no son compatibles con docker stack deploy.

• Utilice un almacén de secretos cifrado con cuentas individuales cuando varias personas necesiten acceso o la auditabilidad sea importante.
• Utilice ajustes de implementación restringidos cuando solo un pequeño grupo administrativo deba proporcionar valores a las cargas de trabajo.
• Utilice un flujo manual documentado solo para cambios de bajo volumen con pasos claros de aprobación, transferencia segura y recuperación.
• Mantenga en la documentación de implementación una referencia al ID de registro del secreto, no a su valor real.

Aplique el principio de mínimo privilegio a bases de datos, servicios de correo, API e integraciones

El mínimo privilegio consiste en dar a usuarios y procesos únicamente el acceso necesario para sus tareas asignadas. NIST también exige que los privilegios se revisen periódicamente y que los accesos innecesarios se eliminen o reasignen. Aplique esto a las credenciales, no solo a los usuarios humanos.

Para una base de datos, prefiera una cuenta específica de la aplicación en lugar de una cuenta de administrador compartida. Para el correo electrónico, use credenciales destinadas a la función de envío de la aplicación en vez de la contraseña del buzón de una persona. Para las API, elija los permisos disponibles más limitados y separe las credenciales de desarrollo, prueba y producción. Para las integraciones, identifique si el token puede leer datos, escribir datos, eliminar datos, administrar usuarios o crear credenciales adicionales.

Una prueba útil es el radio de impacto: si este valor se expone, ¿qué puede hacer realmente un atacante? Un token de alcance limitado vinculado a una aplicación es más fácil de revocar y menos perjudicial que un token con amplios privilegios reutilizado entre sistemas.

• Cree credenciales de base de datos independientes por aplicación y entorno cuando el servicio lo permita.
• Evite usar un superusuario de base de datos o una credencial de administrador amplia para el acceso rutinario de aplicaciones.
• Utilice tokens de API separados para aplicaciones o integraciones separadas, en lugar de reutilizar un token general.
• Limite los permisos, los datos accesibles y las capacidades administrativas a la necesidad real de la aplicación.
• Revise las credenciales después de cambios de rol, proveedor, integración o arquitectura.

Cree un procedimiento de rotación que evite integraciones interrumpidas

La rotación es una sustitución controlada, no simplemente un restablecimiento de contraseña. Un cambio no planificado puede interrumpir la conectividad con la base de datos, la entrega de correo electrónico, los webhooks o automatizaciones esenciales. La secuencia más segura consiste en preparar un reemplazo, actualizar el servicio consumidor, validarlo, revocar el valor anterior y documentar el resultado.

Comience con una entrada de inventario que indique si son posibles las credenciales en paralelo. Algunos proveedores permiten que un token nuevo coexista brevemente con el token anterior; eso facilita una transición por etapas. Cuando no haya solapamiento disponible, programe una ventana de mantenimiento, defina una ruta de reversión y asegúrese de que los responsables adecuados estén disponibles.

Después del cambio, verifique la función real en lugar de limitarse a comprobar que el servicio se inicia. Pruebe una lectura y escritura de base de datos apropiadas para la aplicación, envíe un correo electrónico controlado, realice una llamada de API autorizada o ejecute el flujo de trabajo crítico. A continuación, elimine la credencial anterior y busque en las ubicaciones de exposición conocidas si la rotación siguió a una sospecha de filtración.

• 1. Inventario: identifique la credencial, el responsable, los consumidores, las dependencias y las ubicaciones de exposición.
• 2. Sustitución: genere u obtenga un nuevo valor mediante el proceso aprobado por el responsable del tercero.
• 3. Actualización: proporcione el reemplazo únicamente a la aplicación autorizada o a la ruta de implementación autorizada.
• 4. Validación: pruebe la integración o función específica que depende de la credencial.
• 5. Revocación: desactive, elimine o invalide de otro modo el valor anterior tan pronto como sea seguro.
• 6. Documentación: registre la fecha, el operador, el resultado de la validación, la próxima fecha de revisión y cualquier excepción.