En el contexto de la seguridad de las aplicaciones, un secreto es cualquier dato que demuestre que quien lo posee es quien o lo que afirma ser durante el proceso de autenticación y autorización. Si actores maliciosos obtienen acceso a secretos, consiguen acceder de forma no autorizada a sus sistemas y pueden utilizarlos para diversos fines, como robar secretos corporativos e información de clientes o incluso secuestrar sus datos para exigir un rescate.

Un ejemplo clásico es el nombre de usuario y la contraseña que permiten a una aplicación acceder a su base de datos, pero un secreto también puede consistir en claves de API, credenciales, certificados y claves privadas, entre otros tipos de información. Dado que los secretos se utilizan para controlar el acceso a los activos de una organización, almacenarlos y protegerlos de forma segura es fundamental para reducir el riesgo de que la organización se vea comprometida.

¿Qué es la gestión de secretos?

La gestión de secretos es el proceso que utiliza una organización para:

  • Identificar datos sensibles
  • Clasificar los datos
  • Etiquetar los datos
  • Almacenar los datos de forma segura
  • Distribuir secretos
  • Rota (sustituye) los secretos periódicamente

Cuando las organizaciones pasan de arquitecturas monolíticas a arquitecturas de microservicios, aumenta el número de componentes independientes de aplicaciones e infraestructura —cada uno con sus propias credenciales—, lo que implica que hay muchos más secretos que gestionar.

Formas de almacenar secretos

Veamos más de cerca dos opciones para almacenar secretos de forma segura:

Vault

El enfoque de bóveda implica instalar una herramienta de terceros para la gestión de secretos. La solución de bóveda cifra cada secreto para impedir que usuarios no autorizados accedan a él. La bóveda expone una API que permite a los usuarios acceder a los secretos según las políticas establecidas. Cuando los usuarios se autentican en la API, solo pueden acceder a los secretos para los que tienen autorización.

Desventajas:

  • Debes gestionar por tu cuenta la solución y las credenciales
  • Requiere que se cree una infraestructura a su alrededor; de lo contrario, resulta difícil que los equipos trabajen con ella de forma independiente.

Ventajas:

  • Familiaridad en el sector (la mayoría de los desarrolladores saben utilizar este tipo de herramientas)
  • Se integra fácilmente con otras herramientas proporcionadas por el proveedor de la bóveda
  • Algunas bóvedas están disponibles de forma gratuita

En el mercado hay numerosas herramientas que los desarrolladores pueden utilizar para almacenar y gestionar secretos cifrados. Para ver un ejemplo de cómo utilizar una herramienta centralizada y automatizada de gestión de secretos, lea nuestro artículo «Protección de claves privadas SSL en NGINX con HashiCorp Vault».

Proveedores de servicios en la nube

Otro enfoque consiste en utilizar un proveedor de servicios en la nube para gestionar secretos como servicio. Una de sus ventajas es que la herramienta de gestión de secretos suele integrarse estrechamente con otros servicios en la nube, como las bases de datos gestionadas. Los servicios de los proveedores de nube también pueden ofrecer funciones como la rotación automática, aunque es necesario seguir investigando para determinar si esta opción provoca periodos de inactividad.

Desventaja:

  • No suele ser gratuito

Ventajas:

  • El proveedor de servicios en la nube configura y gestiona el acceso y la interfaz de usuario
  • Se integra perfectamente con otros servicios del proveedor de nube
  • Se puede gestionar con una herramienta de infraestructura como código

Dónde no almacenar secretos

Los secretos deben gestionarse con cuidado para evitar interrupciones en la aplicación cuando se desbloquean y se accede a ellos. Una práctica recomendada es no incluir nunca secretos en un sistema de control de versiones. Almacenar secretos allí expone a una organización a un posible desastre si se accede a ellos accidentalmente o se ven comprometidos cuando un equipo o una persona actualiza el código o la aplicación. Por este motivo, si alguna vez se incluye un secreto en el control de versiones, aunque sea brevemente, debe considerarse comprometido. Los datos confidenciales deben eliminarse del repositorio y borrarse del historial del sistema de control de versiones.