Separación de obligaciones

La separación de obligaciones es el concepto de asegurar que un principal no tenga todos los permisos necesarios para poder completar una acción maliciosa. En Cloud Key Management Service, esto podría ser una acción como usar una clave para acceder y desencriptar datos a los que el usuario no tiene una razón válida para acceder.

La separación de obligaciones es un control empresarial que se suele usar en organizaciones más grandes, y cuyo propósito es ayudar a evitar incidentes y errores de seguridad o privacidad. Se considera una práctica recomendada.

En Cloud KMS, la separación de obligaciones requiere una distinción estricta entre las siguientes funciones:

  • Administradores de claves: Son los principales que están autorizados para administrar los ciclos de vida de las claves, incluidos la creación, el borrado, la rotación y los cambios de estado. Por ejemplo, los usuarios con la función Administrador de Cloud KMS.
  • Usuarios de claves: Son los principales que están autorizados para usar claves, incluidas la encriptación, la desencriptación, la firma o la verificación de firmas. Por ejemplo, los usuarios con la función Encriptador/desencriptador de CryptoKey de Cloud KMS.

Cuando usas claves de Cloud KMS para claves de encriptación administradas por el cliente, te recomendamos que la cuenta de servicio sea el único principal autorizado para usar la clave para la encriptación y la desencriptación. Para obtener más información sobre cómo las integraciones de CMEK controlan el acceso a los recursos, consulta Cómo los servicios integrados con CMEK controlan el acceso a los recursos.

Si deseas crear una barrera de protección para aplicar esta recomendación, puedes usar políticas de denegación de IAM para quitar los permisos de encriptación y desencriptación de los principales que no sean cuentas de servicio. Para obtener más información sobre cómo usar las funciones de IAM de forma segura, consulta Usa IAM de forma segura.

Administración de claves

La administración de claves describe quién en una organización es responsable de administrar el ciclo de vida de tus recursos de Cloud KMS y mantener barreras de protección para controlar cómo se usa Cloud KMS. Los enfoques de administración de claves existen en un espectro que va desde la administración centralizada hasta la administración delegada:

  • Administración centralizada: Un equipo de seguridad o de plataforma dedicado es responsable de administrar el ciclo de vida de todas las claves criptográficas de la organización. Las empresas altamente reguladas con requisitos de cumplimiento estrictos suelen elegir este modelo.
  • Administración delegada: Un equipo de seguridad central usa barreras de protección para exigir estándares de encriptación, pero delega la responsabilidad de las operaciones del ciclo de vida de las claves a los propietarios de las aplicaciones dentro de sus proyectos. Estas barreras de protección pueden incluir políticas de la organización que usan restricciones administradas y restricciones personalizadas, y políticas de otorgamiento y denegación de IAM. Esto elimina los cuellos de botella operativos centrales.

Almacenamiento de claves

El almacenamiento de claves describe dónde se crean los recursos de Cloud KMS dentro de una organización. Existen dos enfoques principales para el almacenamiento de claves: el almacenamiento de claves en un proyecto dedicado y el almacenamiento de claves en el mismo proyecto.

  • Almacenamiento de claves en un proyecto dedicado: Un proyecto de claves dedicado contiene claves que se usan para varias aplicaciones. Por lo general, cada carpeta de entorno tiene su propio proyecto de claves. Puedes usar Autokey con el almacenamiento de claves en un proyecto dedicado.
  • Almacenamiento de claves en el mismo proyecto: Las claves se almacenan en el mismo Google Cloud proyecto que los recursos que protegen. A veces, esto se describe como "la clave sigue los datos". Puedes usar Autokey con el almacenamiento de claves en el mismo proyecto.

Alineación de la administración y el almacenamiento

En la siguiente matriz, se proporcionan ejemplos de cómo se pueden combinar estos modelos de administración y almacenamiento para satisfacer las diferentes necesidades de la organización:

Modelo de administración Almacenamiento de claves en un proyecto dedicado Almacenamiento de claves en el mismo proyecto
Administración centralizada

Enfoque completamente centralizado

Uso recomendado: Organizaciones con requisitos reglamentarios estrictos que exigen el aislamiento de los límites del proyecto.

Impacto operativo: Complejidad de configuración alta. Requiere una automatización sólida (como una "fábrica de proyectos") para evitar demoras operativas para los equipos de desarrollo.

Propiedad administrada

Uso recomendado: Organizaciones que requieren supervisión de seguridad central pero que desean maximizar la velocidad del desarrollador.

Impacto operativo: Complejidad de configuración baja. La seguridad central aplica la política mediante barreras de protección, mientras que las claves se colocan junto con los recursos que protegen para facilitar la administración.

Administración delegada

No recomendado

La introducción de la complejidad de IAM entre proyectos anula el propósito de delegar la administración de claves a los equipos de aplicaciones.

DevOps autónomo

Uso recomendado: Organizaciones descentralizadas de alta velocidad con una cultura de DevOps sólida.

Impacto operativo: Complejidad de configuración mínima. Los equipos de aplicaciones tienen autonomía total sobre los recursos y las claves dentro de los límites de su proyecto

Almacenamiento de claves en el mismo proyecto

Para aplicar la separación de obligaciones en la administración de claves en el mismo proyecto, es necesario mantener las funciones de IAM estrictamente separadas. Por ejemplo, puedes usar políticas de denegación de IAM para quitar los permisos de encriptación y desencriptación de tus administradores de claves.

Puedes habilitar Autokey con el almacenamiento de claves en el mismo proyecto en un proyecto o una carpeta para permitir la creación automatizada de claves en el mismo proyecto que el recurso que protege la clave. Para obtener más información, consulta Habilita Autokey con el almacenamiento de claves en el mismo proyecto.

Almacenamiento de claves en un proyecto dedicado

En el modelo de almacenamiento de claves en un proyecto dedicado, un equipo de seguridad central administra los proyectos de claves dedicados, que tienen permisos de administración de claves en el proyecto de claves, pero tienen acceso restringido a los proyectos que contienen los recursos protegidos por esas claves.

Puedes habilitar Autokey con el almacenamiento de claves en un proyecto dedicado en una carpeta para permitir la creación automatizada de claves con el modelo de almacenamiento de claves centralizado. Para obtener más información, consulta Configura Autokey con el almacenamiento de claves en un proyecto dedicado.

Automatización y supervisión del cumplimiento

Google Cloud proporciona las siguientes herramientas para automatizar y supervisar tus límites de seguridad:

  • Autokey de Cloud KMS: Autokey admite el almacenamiento de claves en un proyecto dedicado y el almacenamiento de claves en el mismo proyecto. Para ambos, automatiza la separación de obligaciones otorgando automáticamente la función de uso de claves al agente de servicio requerido, no a la persona que solicita la clave. Autokey está diseñado para admitir canalizaciones de infraestructura como código que no necesitan privilegios elevados para la creación de claves.
  • Security Command Center: Supervisa los resultados de Separación de funciones de KMS para detectar cualquier principal, incluido un propietario del proyecto o una cuenta de servicio de Google, que posea permisos administrativos y criptográficos en una sola clave.
  • Métricas de encriptación de CMEK: Usa el panel Métricas de encriptación para verificar la alineación con las prácticas de separación de obligaciones en toda la organización.