Guía de gestión de secretos

Todos tenemos secretos. A veces son placeres culpables que intentamos mantener ocultos, como ver telerrealidad cutre o darnos un capricho con comida reconfortante rara. A menudo nos preocupa:

«¿Cómo mantenemos a salvo el secreto?»

«¿Qué podría pasar si alguien descubre el secreto?»

«¿Quién guarda un secreto?»

«¿Qué pasa si perdemos un secreto?»

En Bazaarvoice, nuestro equipo de seguridad parte de estas mismas preguntas cuando se trata de la gestión de secretos. Les interesan menos los secretos triviales, como quién ha dejado los platos en el fregadero de la oficina o quién se ha acabado la leche. En cambio, se centran en los secretos que se usan en los sistemas que dan soporte a una amplia gama de productos de la organización. Entre ellos:

• Claves de API y tokens

• Cadenas de conexión a bases de datos que contienen contraseñas

• Claves de cifrado

• Contraseñas

Con cientos de sistemas y componentes que dependen de secretos en Bazaarvoice, enumerarlos y responder a las preguntas anteriores de forma rápida, coherente y fiable puede convertirse en un reto si no hay estándares que sirvan de guía.

Esta publicación hablará sobre la gestión de secretos y explicará cómo implementó Bazaarvoice un Secret Catalog con software de código abierto. Incluirá ejemplos reutilizables y consejos útiles para reducir el riesgo y mejorar el cumplimiento normativo en tu organización. ¡Vamos a ello!

Catálogo de secretos

Bazaarvoice cumple la norma ISO27001Se abre en una ventana nueva y se asegura de que sus sistemas empleen herramientas y prácticas estándar del sector para almacenar los secretos de forma segura. Sin embargo, no siempre están en el mismo sitio y pueden almacenarse con distintas herramientas. A veces AWS Secret ManagerSe abre en una ventana nueva tiene sentido; otras veces, AWS KMSSe abre en una ventana nueva es una mejor opción para una solución concreta. Puede que incluso tengas una estrategia multicloud, que dispersa aún más los secretos. Ahí es donde un catálogo de secretos resulta muy útil, ya que ofrece una vista unificada de los secretos en todas las herramientas y proveedores.

Puede sonar un poco aburrido, y la información que se recoge no hace falta la mayor parte del tiempo. Sin embargo, en caso de incidente, tener un catálogo secreto se convierte en un recurso muy valioso para reducir el tiempo que necesitas para resolver el problema.

Bazaarvoice reconoció el valor de un catálogo de secretos y decidió implantarlo. El equipo de Seguridad acordó que cada entrada del catálogo debe cumplir los siguientes criterios:

• Un nombre único

• Una buena descripción de su finalidad

• Responsabilidad clara

• Dónde se almacena

• Una lista de sistemas dependientes

• Referencias a la documentación para solucionar cualquier incidente relacionado, por ejemplo, cómo rotar una clave de API

Es fundamental que el valor del secretodebe permanecer en su ubicación original y segura fuera del Catalog, pero es esencial saber dónde se almacena el secreto. Hacerlo evita un único punto de fallo y no obstaculiza ningún criterio de éxito.

Saber dónde se almacenan los secretos ayuda a identificar malas prácticas. Por ejemplo, guardar una clave SSH solo en los portátiles de los miembros del equipo supondría un riesgo importante. Una persona puede dejar la empresa, ganar la lotería o incluso derramar una bebida sobre su portátil (¡todos conocemos a alguien así!). Los almacenes ya definidos en el catálogo orientan a las personas a la hora de decidir cómo guardar un secreto nuevo, dirigiéndolas hacia herramientas seguras y aprobadas que resisten el error humano.

Hay que admitir que el primer intento de implementar el catálogo en Bazaarvoice no salió del todo según lo previsto. Los equipos empezaron a cumplir los criterios, pero enseguida se hizo evidente que cada equipo producía interpretaciones diferentes almacenadas en varios lugares y formatos. Seguridad no tendría una vista unificada si acabaran existiendo varios catálogos de secretos. Los equipos necesitarían orientación adicional y un estándar concreto para tener éxito.

¡Para esto ya tenemos el ajuste perfecto!

A Bazaarvoice le encantan los catálogos. Después de nuestros clientes, quizá sean lo que más nos gusta. Hay un catálogo de productos para cada uno de nuestros más de diez mil clientes, un catálogo de datos y, sobre todo, un catálogo de servicios impulsado por BackstageSe abre en una ventana nueva.

«BackstageSe abre en una ventana nueva unifica todas tus herramientas de infraestructura, servicios y documentación para crear un entorno de desarrollo fluido de principio a fin».

Desde el primer momento, incluye entidades básicas que permiten un potente modelado del ecosistema:

https://backstage.io/docs/features/software-catalog/system-model#ecosystem-modeling

Como se muestra en el diagrama anterior, en el núcleo del modelo de Backstage están los Systems, los Components y los Resources, las entidades más relevantes para la gestión de secretos. Puedes encontrar descripciones detalladas de cada entidad en la documentación de modelado de BackstageSe abre en una ventana nueva. En resumen, se pueden entender así:

• Sistema

  – Una colección de entidades de nivel inferior, incluidos Components y Resources, que actúa como capa de abstracción.

• Componente

  – Una pieza de software. Opcionalmente, puede producir o consumir API.

• Recurso

  – La infraestructura que los Components necesitan para funcionar.

Nuevos tipos de recursos

Los ResourcesSe abre en una ventana nueva son una de las entidades de Backstage que se utilizan para representar la infraestructura. Encajan muy bien para representar secretos, lo que nos permite evitar escribir software propio para hacer el mismo trabajo. Por eso definimos dos nuevos Resource Types: secret y secret-store.

Consejo: Acuerda de antemano los Tipos permitidos para evitar una proliferación de variantes como «database» y «db» que pueden empeorar la búsqueda y el filtrado.

Como ya habían invertido el esfuerzo en modelar el ecosistema de Bazaarvoice, añadir el YAML necesario para definir secretos y secret stores resultó trivial para los equipos.

Ejemplo mínimo de secret store:

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: aws-secrets-manager
description: Resources of type 'secret' can depend on this Resource to indicate that it is stored in AWS Secrets Manager
spec:
type: secret-store
owner: team-x

Ejemplo mínimo de secret:

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: system-a-top-secret-key
description: An example key stored in AWS Secrets Manager
links:
- url:https://internal-dev-handbook/docs/how-to-rotate-secrets
title: Rotation guide
spec:
type: secret
owner: team-1
system: system-a
dependsOn:
- resource:aws-secrets-manager

Por último, para conectar los puntos con los Systems, Components y Resources existentes, basta con añadir una sección dependsOn a sus definiciones. Por ejemplo:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: system-a-component
...
spec:
...
dependsOn:
- resource:system-a-top-secret-key

¿Qué aspecto tiene?

¡A nuestros ojos es fantástico! Analicemos la imagen de arriba.

La sección «About» explica el secreto, incluido el sistema al que está asociado, quién es su propietario y el hecho de que actualmente está en producción. También ofrece un enlace al código fuente y una forma de informar de problemas o errores, como erratas.

La sección «Relations», impulsada por un pluginSe abre en una ventana nueva adicional, ofrece un gráfico visual e interactivo que muestra las relaciones asociadas al secreto. Este gráfico ayuda a los usuarios a hacerse rápidamente una imagen mental de los recursos en el contexto de sus sistemas, propietarios y componentes. Navegar por este gráfico ha demostrado ser un mecanismo eficaz y eficiente para entender las relaciones asociadas al secreto.

La sección «Links» ofrece un lugar coherente donde consultar la documentación relacionada con la gestión de secretos.

Por último, el pluginSe abre en una ventana nueva «PagerDuty» se integra con el sistema de guardias y elimina la necesidad de identificar contactos manualmente durante los incidentes de emergencia.

El valor de Backstage se aprecia en la potencia de los plugins disponibles. La búsqueda y el filtrado facilitan la capacidad de descubrimiento, y la API abre la puerta a más integraciones con sistemas internos.

Mantenerse fresco

Mantener una documentación precisa y actualizada siempre es un reto. Ubicar el catálogo de servicios junto con las bases de código relacionadas ayuda a evitar el riesgo de que quede obsoleto y se ha convertido en un aspecto a tener en cuenta al revisar y aprobar cambios.

Estamos al principio de nuestro camino con este enfoque de catálogo de secretos y queremos compartir nuestras mejoras graduales en próximas entradas del blog a medida que avancemos.

Sobre el autor

John McCloskey es Principal Software Engineer y vive en Belfast, Irlanda del Norte. Dirige los equipos de desarrollo responsables de las plataformas Catalog y Actionable Insights de Bazaarvoice. En su tiempo libre, a John McCloskey le gusta correr, hacer senderismo y explorar nuevos destinos.