¿Qué es un secreto?

En el contexto de la seguridad de aplicaciones, un secreto es cualquier información que autentica y valida la identidad de su poseedor durante los procesos de autenticación y autorización. Si los actores malintencionados consiguen acceder a los secretos, obtienen un acceso involuntario a sus sistemas que pueden utilizar para diversos fines, como robar secretos corporativos e información de clientes o incluso pedir un rescate por sus datos.

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 ser claves 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 crucial 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:

  • Detectar datos sensibles
  • Clasificar los datos
  • Etiquetar los datos
  • Almacenar los datos de forma segura
  • Distribuir secretos
  • Rotar (sustituir) regularmente los secretos

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

Formas de guardar secretos

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

Almacén

La solución de almacén implica el uso de una herramienta de gestión de secretos de terceros, que cifra cada secreto para evitar el acceso no autorizado. Esta solución proporciona una API que permite a los usuarios acceder a los secretos de acuerdo con las políticas definidas. Al autenticarse, los usuarios de la API solo pueden acceder a los secretos para los que tienen autorización.

Inconvenientes:

  • Debe autogestionar la solución y las credenciales.
  • Requiere que se construya una infraestructura a su alrededor o es difícil para los equipos trabajar con ella de manera independiente.

Ventajas:

  • Familiaridad con el sector (la mayoría de los desarrolladores saben utilizar estas herramientas).
  • Se integra fácilmente con otras herramientas proporcionadas por el proveedor de almacenes.
  • Algunos almacenes son gratuitos.

Existen numerosas herramientas en el mercado que los desarrolladores pueden utilizar para almacenar y gestionar secretos cifrados. Para ver un ejemplo de cómo utilizar una herramienta de gestión de secretos automatizada de forma centralizada, lea nuestro blog, «Protecting SSL Private Keys in NGINX with HashiCorp Vault» (Protección de claves privadas SSL en NGINX con HashiCorp Vault).

Proveedores de nube

Otro enfoque consiste en recurrir a un proveedor de nube para la gestión de secretos como servicio. Una de las 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 habrá que investigar en el futuro si esa opción genera tiempo de inactividad.

Inconveniente:

  • No suele ser gratis.

Ventajas:

  • El proveedor de la nube configura y gestiona el acceso y la interfaz de usuario.
  • Se integra perfectamente con otros servicios de proveedores de nube.
  • Puede gestionarse con una herramienta de infraestructura como código.
Dónde no guardar secretos

Los secretos deben gestionarse con sumo cuidado para evitar interrupciones en la aplicación cuando se desbloquean y acceden a ellos. Una de las mejores prácticas es nunca registrar secretos en un sistema de control de código fuente. Almacenar secretos allí expone a la organización a un riesgo potencial, ya que podrían ser accedidos accidentalmente o comprometidos cuando un equipo o persona actualiza el código o la aplicación. Por esta razón, si algún secreto llega a registrarse en el control de código fuente, incluso de manera temporal, debe considerarse comprometido. Los datos sensibles deben eliminarse del repositorio y ser completamente eliminados del historial del sistema de control de código fuente.