Administración de secretos con Cloud KMS

Con frecuencia, las aplicaciones requieren acceder a fragmentos de datos sensibles durante el tiempo de compilación o ejecución. Estos fragmentos de datos se suelen conocer como secretos. Los secretos son conceptualmente parecidos a los archivos de configuración, pero suelen ser más sensibles, dado que pueden otorgar acceso a datos adicionales, como los del usuario.

En este tema, se describen algunos de los conceptos principales de la administración de secretos. Además, se proporciona orientación sobre cómo administrar los secretos mediante Cloud Key Management Service.

Descripción general de la administración de secretos

La administración de secretos se puede realizar de varias maneras. Los secretos se pueden almacenar en los siguientes medios:

  • Objetos binarios o código
  • Un administrador de implementaciones
  • Un volumen secreto de un contenedor
  • Metadatos de una VM
  • Un sistema de almacenamiento

Por lo general, para elegir una de esas opciones se debe lograr un equilibrio entre la seguridad y la funcionalidad. Estas son algunas de las inquietudes de seguridad más comunes:

  • Autorización: La administración del acceso a los secretos o a la ubicación en donde se almacenan, incluidos alcances de autorización estrictos
  • Verificación del uso: La capacidad de auditar a bajo nivel de detalle (por ejemplo, para cada secreto) el acceso a los secretos y su uso
  • Encriptación en reposo: La encriptación de los secretos en caso del robo o pérdida de los datos
  • Rotación: La capacidad de rotar o actualizar los secretos, ya sea con regularidad o según sea necesario si ocurre un incidente
  • Aislamiento: La separación entre la ubicación en donde se administran los secretos y en donde se usan. El aislamiento también es válido para la separación de tareas entre los usuarios que tienen la capacidad de administrar los secretos y los que pueden usarlos

Estas son algunas de las inquietudes de funcionalidad más comunes:

  • Coherencia: La sincronización de los secretos en varias ubicaciones y aplicaciones
  • Administración de versiones: La comprensión del momento y el modo en que se actualizan las claves para respaldar la rotación de los secretos

Elige una solución de administración de secretos

Elegir la mejor solución de administración de secretos depende del entorno, los secretos y las necesidades de seguridad existentes. Estas son algunas estrategias comunes:

  1. Almacenar los secretos en el código, encriptados con una clave de Cloud KMS. Por lo general, esta solución se implementa mediante la encriptación de los secretos en la capa de la aplicación. Esta solución ayuda a proporcionar una capa de protección adicional contra las amenazas internas, pues restringe el alcance de acceso al secreto. Solo los desarrolladores que tienen acceso al código y a la clave correspondiente pueden acceder al secreto. Implementar esta opción es conveniente incluso si todos los desarrolladores pueden acceder al código y a la clave, dado que proporciona la capacidad de auditar el acceso al secreto, lo que no es posible en un repositorio de código.

  2. Almacenar los secretos en un depósito de almacenamiento de Cloud Storage, encriptados en reposo. Los beneficios de esta solución son similares a los de la anterior, pues también permite restringir el acceso a los secretos a un conjunto pequeño de desarrolladores y proporciona la capacidad de auditar ese acceso. Además, si almacenas los secretos en una ubicación independiente, puedes rotarlos con más facilidad cuando sea necesario (por ejemplo, si se detecta un incumplimiento de las normas de seguridad). Esta solución también permite separar los sistemas. Por ejemplo, si ocurre un incumplimiento de datos en el repositorio de código en donde se usan los secretos, es posible que estos permanezcan protegidos.

  3. Usar una solución de administración de secretos de terceros. Una herramienta de administración de secretos dedicada es una extensión de las dos primeras opciones de la lista. Además, estas herramientas podrían permitir no solo rotar los secretos con más facilidad, sino también, en algunos casos, realizar esa rotación en tu nombre o simplificar la rotación frecuente.

Cambia los secretos

Otra consideración importante para elegir una solución de administración de secretos es la facilidad de cambiar los secretos. Por ejemplo, puede ser tentador codificar los secretos, pero esta solución dificulta cambiarlos más adelante y hace que sea más tedioso.

Cuando busques una solución de administración de secretos, ten en cuenta los siguientes requisitos de diseño y su relevancia para tu aplicación:

  • Rotar los secretos. Puede que quieras rotar los secretos con frecuencia, sobre todo por razones de seguridad. Lo ideal es almacenar varias versiones de cada secreto y hacer que el código las pruebe de a una a la vez. Si almacenas varias versiones de un secreto y las rotas con versiones nuevas según sea necesario, puedes mantener mejor la coherencia con un sistema externo que pueda necesitarlo. Esto también permite revertir a versiones anteriores del secreto cuando lo necesites. Implementar esta solución puede ser complicado, pero puede facilitar la administración de secretos a largo plazo si se consideran estas necesidades con anticipación.
  • Almacenar los secretos en caché local. Puede que necesites almacenar los secretos en caché local según la ubicación en donde los almacenas con respecto a tu aplicación. Estos secretos se pueden actualizar con frecuencia, como varias veces por hora. La ventaja de esta solución es que, si los actualizas con más frecuencia, podrás responder más rápido ante una interrupción. Sin embargo, la desventaja es que, si ocurre alguna configuración incorrecta del secreto, una actualización más frecuente permite que el error se extienda más rápido por toda tu flota.
  • Usar una solución o plataforma independiente. Puedes evitar los compromisos a largo plazo si almacenas tus secretos en una solución de administración de secretos independiente de la plataforma. Esto te da la libertad de elegir en caso de que aparezca una solución más flexible.

Administra los secretos con Google Cloud Platform

GCP cuenta con varios métodos que te ayudan a elegir el modo de implementar tu solución de administración de secretos. En esta sección, se describe una estrategia en la que se usa Cloud Storage para el almacenamiento de los secretos, Cloud KMS para las claves de encriptación, Cloud Identity and Access Management para el control de acceso y Cloud Audit Logging para la auditoría.

Este es un método de implementación que usa la administración de secretos en GCP. Consulta Almacena secretos encriptados con Cloud KMS para obtener más información.

  • Crea dos proyectos. El primero usa Cloud Storage para almacenar secretos y el segundo usa Cloud KMS a fin de administrar las claves de encriptación.
  • Asigna las funciones storage.objectAdmin y cloudkms.cryptoKeyEncrypterDecrypter a los usuarios que deben acceder a los secretos. Como alternativa, puedes usar una cuenta de servicio que acceda a Cloud Storage en nombre del usuario. Asegúrate de que los usuarios que no necesitan acceder a los secretos tengan permisos de administración, pero no de acceso.
  • En Cloud Storage, almacena cada secreto como un objeto encriptado y agrupa los secretos en depósitos según sea necesario. En general, puedes agrupar los secretos que tengan las mismas necesidades de uso, acceso y protección.
  • Protege cada depósito con una clave única de Cloud KMS en la capa de la aplicación. También puedes usar la encriptación predeterminada de Google.
  • Rota los secretos periódicamente siempre que sea posible.
  • Supervisa la actividad mediante los registros de auditoría de Cloud. En la configuración predeterminada, se registran las actividades administrativas, como la rotación de las claves o los cambios de permisos de Cloud IAM. También puedes habilitar los registros de acceso a los datos para los objetos de Cloud Storage. Estos registros de acceso a los datos facilitan supervisar los secretos más importantes.

Esta solución abarca la mayoría de los requisitos de administración de secretos que se describieron en Elige una solución de administración de secretos. Sin embargo, uno de los requisitos que no abarca es la administración de versiones, pues este varía según la aplicación en particular.

Antes de implementar una solución como esta, también debes considerar qué alternativa de encriptación se ajusta mejor a tus necesidades y cómo quieres administrar el acceso de los usuarios a los secretos.

Alternativas de encriptación

En GCP, existen dos alternativas para encriptar los secretos:

  • Usar la encriptación de la capa de aplicación mediante una clave de Cloud KMS. Con esta alternativa, puedes implementar la encriptación en los objetos o depósitos de Cloud Storage sobre la base de la encriptación de Google existente mediante una clave almacenada en Cloud KMS. Esta es la alternativa recomendada.

  • Usar la encriptación predeterminada integrada en el depósito de Cloud Storage. GCP permite encriptar el contenido del cliente almacenado en reposo mediante uno o varios mecanismos de encriptación. Como el nombre lo indica, esta encriptación está disponible en la configuración predeterminada, sin que debas realizar ninguna acción adicional.

Consulta Encriptación en reposo para obtener más información sobre estas y otras alternativas de encriptación.

Encriptación de la capa de aplicación mediante una clave de Cloud KMS

La manera recomendada de almacenar los secretos es usar la encriptación de la capa de aplicación mediante una clave de Cloud KMS. Este método es bastante útil si quieres implementar una capa de control adicional o si tienes un requisito de cumplimiento por el cual debes administrar tus propias claves.

Para implementar este tipo de encriptación, debes enviar los secretos que quieres encriptar a Cloud KMS mediante una solicitud Encrypt. Luego, Cloud KMS muestra los secretos encriptados que puedes escribir en el almacenamiento.

Cloud KMS admite secretos que tengan un tamaño máximo de 64 KiB. Si necesitas encriptar secretos de mayor tamaño, te recomendamos que uses una jerarquía de claves, una clave de encriptación de datos generada localmente (DEK) para encriptar el secreto y una clave de encriptación de claves (KEK) en Cloud KMS a fin de encriptar la DEK. Consulta Encriptación de sobre si quieres obtener más información.

Encriptación predeterminada

Si no es posible usar la encriptación de la capa de aplicación, puedes usar la encriptación predeterminada de Cloud Storage. Por lo general, esta alternativa se usa cuando necesitas proteger los secretos almacenados mediante una solución en la nube.

Esta encriptación se habilita de manera automática y no debes realizar ninguna acción para implementarla.

Administra el acceso a los secretos

Existen dos opciones principales para restringir y aplicar el acceso:

  • Controles de acceso al depósito en donde se almacena el secreto. Esta opción admite uno o varios secretos (objetos) por depósito y es la opción recomendada.
  • Controles de acceso a la clave que se usa para encriptar el depósito en donde se almacena el secreto. Esta opción admite uno o varios secretos por clave.

Te recomendamos segregar los secretos solo si eso permite mejorar la seguridad y la facilidad de uso. Una recomendación común es limitar la cantidad de datos que protege cada clave de encriptación (para lograr el aislamiento criptográfico) o cada lista de control de acceso. Esto permite controlar el acceso a los secretos con más detalle, evitar los permisos accidentales y admitir auditorías más detalladas. Agrupa los secretos solo cuando sea lógico hacerlo. Por ejemplo, puedes agrupar algunos secretos para simplificar el control, como cuando una aplicación individual necesita acceder a un grupo de secretos específico en un entorno de ejecución.

Te recomendamos seguir estos lineamientos para decidir cómo almacenar los secretos:

  • Almacena cada secreto como su propio objeto.
  • Almacena los secretos en un solo depósito si tienen varias características en común.
  • Usa una clave de encriptación única para encriptar cada depósito, incluidos los secretos agrupados de manera lógica.

Estos son algunos casos en los que podrías agrupar los secretos:

  • La misma aplicación necesita acceder a los secretos.
  • Las mismas personas administran las versiones de los secretos y el acceso a ellos.
  • El entorno es el mismo, como producción, desarrollo o pruebas.
  • El tiempo de uso es el mismo, como el tiempo de compilación o implementación.
  • El nivel de protección deseado es el mismo.

Rotación de claves

Se recomienda rotar las claves de encriptación de los secretos periódicamente. Rotar las claves facilita limitar la cantidad de datos que se encriptan con una sola clave y también el ciclo de vida de ella en caso de que se vulnere. Las claves se pueden rotar de manera automática o manual. Por ejemplo, puedes rotar una clave de manera manual cuando se actualice una nueva versión del secreto. Para obtener más información. consulta Rotación de claves.

Rotación de secretos

Puedes rotar las claves y también los secretos. Por lo general, los secretos se rotan (o actualizan) cuando se crea una versión nueva, como por ejemplo, cuando generas una contraseña nueva para la credencial de una base de datos. También puedes rotar las claves periódicamente para limitar el ciclo de vida del secreto.

La rotación de los secretos causa que estos tengan varias versiones que se deben administrar. En un momento determinado, pueden existir una o varias versiones válidas de un secreto. Te recomendamos que consideres conservar las versiones anteriores de un secreto durante un tiempo, pues podrías necesitarlas si la aplicación se revierte a una versión anterior.

Una manera de administrar varias versiones de los secretos es crear un objeto por cada versión y almacenar estos objetos en el mismo depósito asociado con ese secreto específico. Luego, puedes usar una convención de nombres para realizar un seguimiento de la versión actual. Además, puedes usar un conjunto centralizado de variables que te ayuden a determinar qué secreto se debe usar en un momento determinado.

Administración de permisos mediante Cloud IAM

Una de las recomendaciones de administración de secretos de GCP es usar Cloud IAM, que te permite crear y administrar los permisos de los recursos de GCP. También permite unificar el control de acceso a los servicios de GCP en un solo sistema y cuenta con un conjunto coherente de operaciones. Consulta la documentación de Cloud IAM para obtener más información sobre esta herramienta.

La separación de obligaciones es un concepto fundamental de la administración de funciones y accesos. Debes evitar que una sola persona pueda encriptar y desencriptar los datos, y administrar o crear claves nuevas al mismo tiempo. Consulta Separación de obligaciones para obtener más información.

Puedes administrar los permisos de estas dos maneras:

  • Sin una cuenta de servicio. Esta es la opción recomendada.
  • Con una cuenta de servicio

Administración de permisos sin una cuenta de servicio

La configuración ideal de administración de secretos mediante Cloud KMS debe minimizar el acceso innecesario y aplicar la separación de obligaciones. Este tipo de configuración requiere que existan los siguientes usuarios:

  • Un administrador de nivel organizativo. Este usuario tiene la función resourcemanager.organizationAdmin. El administrador de nivel organizativo suele ser el propietario comercial de la cuenta. Ten en cuenta que si usaste la función resourcemanager.projectCreator en su lugar, a ese usuario se le otorga el acceso de owner a esos proyectos. Este nivel de acceso suele ser innecesario. Te recomendamos que no uses esta función para la administración de secretos.
  • Un segundo usuario que tenga la función storage.objectstorageA.admin. Este usuario se encarga de administrar los secretos. Este usuario también usa una cuenta de servicio que tiene la función storage.admin para el producto que contiene el depósito de Cloud Storage. Esta cuenta de servicio permite restringir la capacidad del usuario de editar los metadatos del depósito o borrarlo.
  • Un tercer usuario que tenga la función cloudkms.admin. Este usuario se encarga de administrar las claves que se usan para encriptar los secretos.
  • Un cuarto usuario que tenga las funciones storage.objectAdmin y cloudkms.cryptoKeyEncrypterDecrypter. Este es el usuario final que debe acceder a los secretos.

Administración de permisos con una cuenta de servicio

Una implementación alternativa requiere que el usuario final solo tenga permisos para el depósito de almacenamiento y que el servicio de almacenamiento use una cuenta de servicio a fin de acceder a la clave en nombre del usuario. Esta configuración es similar a la que se describe en Administración de permisos sin una cuenta de servicio, con las siguientes diferencias:

  • El usuario final que accede a los secretos tiene la función storage.objectAdmin.
  • Existe un quinto usuario que tiene la función cloudkms.cryptoKeyEncrypterDecrypter y se usa con la cuenta de servicio de Cloud Storage.

Esta configuración permite que exista una situación en la que ninguna persona tiene permiso para encriptar o desencriptar mediante una clave, lo que puede ser la mejor opción en algunos casos. No obstante, esta configuración permite que Cloud Storage pueda encriptar y desencriptar mediante la clave con autoridad propia.

Auditoría mediante Cloud Audit Logging

El último aspecto que debes tener en cuenta para la administración de secretos en GCP es usar registros de auditoría de Cloud. Este servicio consta de dos secuencias de registro que generan los servicios de GCP: actividad del administrador y acceso a los datos. Estas secuencias permiten obtener información sobre qué acciones se ejecutaron, quién las realizó, además de dónde y cuándo se llevaron a cabo en tus proyectos de GCP.

Los registros de actividad del administrador contienen entradas de registro de las llamadas a la API o las acciones administrativas que modifican la configuración o los metadatos de un servicio o proyecto. Este registro siempre está habilitado y todos los miembros del proyecto pueden verlo.

Los registro de acceso a los datos contienen entradas de registro de las llamadas a la API que crean, modifican o leen los datos proporcionados por el usuario y administrados por un servicio, como los datos almacenados en un servicio de bases de datos. Solo los propietarios del proyecto y los usuarios con la función de lector de registros privados.

En la configuración predeterminada de Cloud Storage y Cloud KMS, están habilitados los registros de actividad del administrador, que incluyen acciones como crear un depósito nuevo o rotar una clave. El usuario no debe realizar ninguna opción para habilitar estos registros.

Al contrario, en la configuración predeterminada de Cloud Storage y Cloud KMS, no están habilitados los registros de acceso a los datos, dado que pueden representar un volumen de datos importante. Estos registros realizan un seguimiento de las acciones que ocurren con frecuencia, en especial cuando se implementa la solución que se describe en este artículo. Algunas de estas acciones son las operaciones de lectura del depósito y encriptar o desencriptar mediante una clave. Además, es necesario usar Cloud Storage y Cloud KMS para acceder a los secretos, por lo que las interacciones con ellos podrían almacenarse en cualquiera de las dos ubicaciones (aunque almacenarlas en ambos sería redundante).

Si decides usar el registro, te recomendamos habilitar los registros de acceso a los datos en los objetos de Cloud Storage en lugar de las claves de Cloud KMS. Estos registros proporcionan datos más detallados y fáciles de auditar que los registros de acceso a los datos de las claves de Cloud KMS. También puedes habilitar los registros de acceso a los datos en los objetos de Cloud Storage para los secretos más importantes.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...