Transcripción del vídeo

¿Cómo se asegura de que sus secretos se almacenan de forma segura para evitar filtraciones de datos y el caos en sus flujos de trabajo en DevOps?

Hola, soy Alex Greer con el equipo de IBM Cloud, y antes de empezar asegúrese de dar "like" y a suscribirse ahora.

¿Qué es un secreto?

Un secreto es una credencial digital que va a permitir que las entidades se comuniquen y realicen acciones en un servicio. Esta parte de la información mantiene el punto de acceso seguro. Así que veamos cómo existe este paradigma.

Empecemos con una entidad local que necesita acceder a algún tipo de servicio. Lo dejaremos un poco ambiguo por ahora, digamos que se trata de cualquier tipo de servicio. Para comunicarse correctamente con el servicio y poder emprender la acción que necesita para realizar su trabajo, esta entidad necesita comunicar al servicio dos cosas: en primer lugar, quién es, para que el servicio pueda entender qué o quién está interactuando con él. En segundo lugar, va a tener que conocer el conjunto de permisos que debe otorgar en el contexto de su servicio. Con esta información, el servicio ya puede permitir adecuadamente que la entidad interactúe con él. Cómo hacemos posible esta interacción es con algo que llamamos "secreto"

Ahora, con esta dinámica establecida, pasemos a un ejemplo con usuarios. Para los usuarios, diremos que este usuario de aquí es nuestra entidad, y diremos que nuestro servicio de aquí - digamos que es un desarrollador, y resulta que necesita acceso de lectura o escritura. Para ello, interactúan con el repositorio de desarrollo. Para obtener ese acceso de nuevo, volviendo a la necesidad, tenemos autorización y permiso. La forma en que se va a establecer esta comunicación, en este caso en concreto, es mediante credenciales de usuario. Ahora ese usuario puede interactuar con el repositorio de desarrollo del modo que necesita para hacer su trabajo.

Ahora, mirando la historia de una aplicación nativa de la nube, tenemos muchos microservicios que deben hablar entre sí. Vamos a examinarlo con detalles. Llamémoslo servicio "A", que necesita interactuar con una base de datos llamada "DB" y obtener una información específica que necesita para realizar su trabajo. Lo que necesita, que aquí está en forma de secreto, es lo que llamamos "configuraciones de BD". Una vez más, esta configuración de DB va a permitir que tenga la comunicación correcta con el servicio diciendo, esto es lo que soy y esto es lo que vine a lograr.

Pero ahora que tenemos nuestras credenciales de usuario en nuestras DB configs como ejemplos de secretos, nos damos cuenta de la vulnerabilidad que se puede crear aquí si estas credenciales cayeran en las manos equivocadas. Y por eso es tan importante establecer un lugar centralizado para gestionar todas estas cosas a medida que construimos más aplicaciones y microservicios. Cuanto más tenemos, más complejo es el problema. Si esta información cae en las manos equivocadas, ¿cómo nos podemos proteger? ¿Cómo se puede evitar llegar a ese punto? ¿Cómo se han aislado esos datos?

Si miramos el daño que esto puede causar, podemos hablar de millones de dólares, por ejemplo, por una brecha en los datos. En términos de operaciones de desarrollador, si no se gestiona esta información correctamente, aún en el caso de que no intervenga un agente malintencionado, puede resultar confuso incluso para los equipos que lo utilicen. Por lo tanto, lo que tenemos que hacer es asegurarnos de que la información esté centralizada y correctamente almacenada para que podamos aprovechar estos secretos de la manera adecuada y se puedan establecer comunicaciones correctas con los servicios.

Bien, ahora veamos la siguiente capa de la cebolla en un ejemplo más complicado.

Volvamos a Jane, la desarrolladora de la empresa. Jane, nuestra "desarrolladora E", tiene que acceder al repositorio de desarrollo al que se ha hecho referencia antes. Vamos a seguir adelante y llamar a esto, tal vez es GitHub. Lo que necesita es tener acceso de escritura y, por lo tanto, tendrá que solicitar la información que le va a dar acceso a ese rol. Aquí es donde se necesita un servicio de gestión de secretos.

Un servicio de gestión de secretos puede almacenar estas credenciales de forma segura, junto con otros tipos de secretos, de forma centralizada para que pueda acceder Jane, o quizás otros servicios, como vamos a ver a continuación. Una vez hecho esto, Jane puede estar segura de que sus credenciales se almacenan de forma segura y solo debe preocuparse de autenticarse ante el servicio y hacer su trabajo, ya que el gestor de secretos se va a encargar de la seguridad.

Lo realmente importante es que el servicio de gestión de secretos interactúe con el servicio IAM del proveedor de servicios de nube o con el servicio de gestión de identidad y acceso. IAM va a ser la fuente de confianza que va a permitir que el gestor de secretos autentique quién es Jane y le pueda dar acceso a GitHub por un lado, y, por otro lado, le permita obtener el conjunto adecuado de roles en función del paradigma que tenga dentro del servicio IAM. Con todo esto ya podemos entender lo que significa para un usuario obtener el permiso adecuado y poder acceder a la herramienta que desee del servicio, y lo pueda hacer en el contexto de uso de un servicio de gestión de secretos.

Ahora examinaremos la forma en que un servicio interactúa con otro servicio y veremos dónde puede resultar más dañina una brecha en los datos.

Examinaremos un ejemplo de comunicación entre servicio y servicio. Comenzaremos por una aplicación de préstamos. Esta app de préstamos quiere solicitar permisos de acceso; hablamos de la misma base de datos que antes. Seamos un poco más específicos: esta base de datos a la que necesita acceder es una tabla dada dentro de la base de datos tiene la información necesaria para dar a su modelo con el fin de ser capaz de hacer un juicio sobre si quieren proporcionar un consumidor solo. La llamaremos base de datos de perfiles. En ella, tenemos el perfil DB, y sabemos que el conjunto de permisos que deseamos conceder van a ser permisos de lectura para la tabla A. Así que de nuevo, ¿dónde vamos a almacenar el secreto que en última instancia nos va a dar acceso a la autenticación y, en última instancia, al conjunto de permisos que necesitamos aquí? De nuevo va a ser el servicio de gestión de secretos, y dicho servicio se tiene que comunicar de nuevo con Cloud IAM. Ahora que el entorno está definido, ¿qué tipo de credencial tenemos? La credencial que tenemos se llama configuración de BD. Vamos a volver al escenario que acabamos de explicar: esta configuración de BD permite que esta aplicación de préstamos pueda tener acceso de lectura o pueda obtener un conjunto de información específico de una determinada tabla de una base de datos que contiene datos de información personal y otra información altamente confidencial. En el caso de que estas configuraciones de BD no estén correctamente almacenadas o que el servicio que almacena vea su seguridad comprometida, lo que tenemos es un escenario catastrófico para el proveedor, ya que el proveedor de este servicio de esta aplicación de préstamos tiene que explicar a su cliente que un tercero malintencionado ha podido obtener acceso acceder a esta configuración de BD. Y esta configuración de BD ha permitido que dicho tercero robada sus datos e hiciera lo que quiso contra el cliente. Para evitarlo, es necesario almacenar en una ubicación segura para que nadie sin permiso pueda acceder y el cliente tenga el nivel de aislamiento de datos que necesita para su empresa. Aquí es donde intervienen los servicios de gestión de secretos.

Como ya hemos dicho antes, los servicios de gestión de secretos ayudan a garantizar el almacenamiento seguro de los secretos para que no se deba preocupar por brechas en los datos que afecten a sus credenciales ni a ningún otro tipo de secreto. Por último, este servicio facilita y mejora el rendimiento de la gestión de secretos mientras usted realiza sus operaciones de DevOps.

Gracias. Si tiene alguna pregunta, escríbanos. Si desea ver más vídeos como este en el futuro, asegúrese de dar "like" y suscríbase; y no olvide que puede aumentar sus conocimientos y obtener un pase para IBM Cloud Labs, que aloja labs sobre Kubernetes interactivos mediante navegador.

Cómo trabajar con secretos de distintos tipos

Los secretos que cree en Secrets Manager pueden ser estáticos o dinámicos por naturaleza. Un secreto estático tiene su fecha y hora de caducidad impuesta a la hora de creación o rotación del secreto. Por el contrario, un secreto dinámicoUn valor exclusivo, como una contraseña o una clave de API, que se crea dinámicamente y se cede a una aplicación que requiere acceso a un recurso protegido. Una vez que finaliza la cesión del secreto dinámico, el acceso al recurso protegido se revoca y el secreto se suprime automáticamente. tiene su fecha y hora de caducidad impuesta cuando se lee o se accede a sus datos secretos.

Secrets Manager clasifica todavía más los secretos estáticos y dinámicos por su propósito o función general. Por ejemplo, cada tipo de secreto se identifica mediante un nombre programático, como por ejemplo username_password. Si desea gestionar su secreto utilizando la API o CLI de Secrets Manager, puede utilizar estos nombres programáticos para ejecutar operaciones sobre secretos según su tipo.

Revise la tabla siguiente para conocer los tipos de secretos estáticos y dinámicos que puede crear y gestionar con el servicio.

* Requiere una configuración del motor antes de que se puedan crear secretos en el servicio.

Características soportadas por tipo de secreto

La tabla siguiente compara y contrasta algunas características comunes entre los tipos de secreto.

Comparación de características entre tipos de secreto

	Secretos arbitrarios	Credenciales de IAM	Credenciales de usuario	Secretos de clave-valor	Certificados importados	Certificados públicos	Certificados privados	Credenciales de servicio	Credenciales personalizadas
Rotación automática		[1]
Rotación manual
Caducidad
Notificaciones
Historial de versiones
Restaurar a la versión anterior
Soporte de SDK
Soporte de plugin de CLI
Compatibilidad con la API HTTP de HashiCorp Vault

¿Qué es un secreto?

Los secretos que almacena con el servicio constan de atributos de metadatos y un valor de secreto. Mientras que los atributos de metadatos le ayudan a identificar un secreto, el valor de secreto son los datos que necesitan los servicios protegidos para autenticarse y autorizar su aplicación.

Consulte la imagen siguiente para ver cómo se estructura un secreto.

{
    "name": "my-username-password",
    "id": "cb123456-8e73-4857-594839587438",
    "description": "Description for this secret",
    "secret_type": "username_password",
    "secret_group_id": "ab654321-3958-9484-1395840384754",
    "state": 1,
    "state_description": "Active",
    "create_by": "iam-ServiceId-gj403948-3048-6059-304958674930",
    "created_at": "2023-03-08-T20:44:11Z",
    "labels": [
        "dev",
        "us-south"
    ],
    "username": "user123",
    "password": "cloudy-rainy-coffee-book"
}

1. Los campos name, id y description, y otros campos comunes, contienen información sobre un secreto. Estos campos almacenan los atributos generales del secreto que puede utilizar para comprender su propósito e historial.

2. Cuando recupera el valor de un secreto, los campos que se devuelven difieren en función del tipo de secreto.

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para un secreto arbitrary.

   {
       "name": "my-secret",
       "secret_type": "arbitrary",
       ...
       "payload": "The quick brown fox jumped over the lazy dog."
   }
   

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para un secreto username_password.

   {
       "name": "my-secret",
       "secret_type": "username-password",
       ...
       "username": "foo",
       "password": "bar"
   }
   

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para un secreto IAM credential.

   {
       "name": "my-iam-credentials",
       "secret_type": "iam_credentials",
       ...
       "api_key": "RmnPBn6n1dzoo0v3kyznKEpg0WzdTpW9lW7FtKa017_u",
       "api_key_id": "ApiKey-dcd0b857-b590-4507-8c64-ae89a23e8d76",
       "service_id": "ServiceId-bb4ccc31-bd31-493a-bb58-52ec399800be",
   }
   

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para un secreto KV.

   {
       "name": "my-kv-secret",
       "secret_type": "kv",
       ...
       "data": '{"key":"value"}'
   }
   

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para los secretos imported_cert y public_cert.

   {
       "name": "my-certificate",
       "secret_type": "imported_cert/public_cert",
       ...
       "certificate":"...",
       "intermediate":"...",
       "private_key":"..."
   }
   

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para un secreto private_cert.

   {
       "name": "my-certificate",
       "secret_type": "private_cert",
       ...
       "certificate":"...",
       "ca_chain":"...",
       "private_key":"..."
   }
   

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para un secreto service_credentials.

   {
       "name": "my-secret",
       "secret_type": "service_credential",
       ...
       "credentials": {
           "key": "The quick brown fox jumped over the lazy dog."
           }
   }
   

   El siguiente ejemplo truncado muestra cómo se representan los datos secretos para un secreto custom_credentials.

   {
       "name": "my-secret",
       "secret_type": "custom_credential",
       ...
       "credentials_content": {
           "key": "The quick brown fox jumped over the lazy dog."
           }
   }
   

Estados secretos y transiciones

Los secretos, en su vida, transitan a través de varios estados que son una función de cuánto tiempo los secretos están en existencia y si se puede acceder a sus recursos asociados.

Secrets Manager proporciona una interfaz gráfica de usuario y una API REST para el seguimiento de secretos a medida que pasan por varios estados en su ciclo de vida. El siguiente diagrama muestra cómo un secreto pasa por los estados entre su generación y su destrucción.

¿Cómo puedo empezar?

Para empezar a utilizar los secretos, puede ir a la página Secretos de la interfaz de usuario de Secrets Manager o econsultar la Rrferencia de API para obtener más información sobre la creación de secretos mediante programación.