Prácticas recomendadas para usar CMEK

En esta página, se describen las prácticas recomendadas para configurar la encriptación en reposo con claves de encriptación administradas por el cliente (CMEK) en tus recursos de Google Cloud . Esta guía está dirigida a arquitectos de nube y equipos de seguridad, y describe las prácticas recomendadas y las decisiones que debes tomar mientras diseñas tu arquitectura de CMEK.

En esta guía, se asume que ya te familiarizaste con Cloud Key Management Service (Cloud KMS) y las claves de encriptación administradas por el cliente, y que leíste el análisis detallado de Cloud KMS.

Elige dónde usar la CMEK

Google recomienda que uses claves de encriptación administradas por el cliente cuando desees establecer un límite criptográfico alrededor de tus datos o los de tus clientes en la nube. Para obtener más información, consulta Claves de encriptación administradas por el cliente (CMEK).

Puedes usar CMEK creadas de forma manual o claves creadas por Autokey en servicios compatibles para ayudarte a implementar los siguientes objetivos:

  • Ser propietario de las claves de encriptación

  • Controlar y administrar tus claves de encriptación, incluida la elección de su ubicación, su nivel de protección, creación, control de acceso, rotación, uso y destrucción

  • Generar material de claves en Cloud KMS o importar material de claves que se mantenga fuera de Google Cloud.

  • Establecer una política sobre dónde se deben usar tus llaves

  • Borrar de forma selectiva los datos protegidos por tus claves en caso de una desvinculación o para corregir incidentes de seguridad (destrucción criptográfica)

  • Crear y usar claves que sean únicas para cada cliente, lo que establece un límite criptográfico para tus datos

  • Registrar el acceso administrativo y a los datos en las claves de encriptación

  • Cumplir con las reglamentaciones actuales o futuras que requieran cualquiera de estos objetivos

Google también recomienda que consideres los marcos de cumplimiento que se aplican a las necesidades de tu empresa. Los diferentes marcos de cumplimiento tienen distintos requisitos para la encriptación y la administración de claves. Por lo general, un marco de cumplimiento describe los principios y objetivos generales de la administración de claves de encriptación, pero no es prescriptivo sobre el producto o la configuración en particular que logra el cumplimiento. Es tu responsabilidad comprender los requisitos de tu marco de cumplimiento y cómo tus controles, incluida la administración de claves, pueden ayudarte a satisfacer esos requisitos.

Para obtener más información sobre cómo los servicios de Google Cloud pueden ayudar a satisfacer los requisitos de diferentes marcos de cumplimiento, consulta los siguientes recursos:

Elige la fuente de tu material de clave

Cuando creas una clave, puedes permitir que Cloud KMS genere el material de la clave por ti o importar material de claves generado fuera de Google Cloudde forma manual. Cuando sea posible, te recomendamos que elijas generar material de claves en Cloud KMS. Esta opción no expone el material de claves sin procesar fuera de Cloud KMS y crea automáticamente nuevas versiones de la clave según el período de rotación de claves que elijas. Si debes importar tu propio material de claves, te recomendamos que evalúes los siguientes riesgos y consideraciones operativas del uso del enfoque de usar tu propia clave (BYOK):

  • ¿Puedes implementar la automatización para importar de forma coherente versiones de claves nuevas? Esto incluye la configuración de Cloud KMS para restringir las versiones de claves solo a la importación y la automatización fuera de Cloud KMS para generar y, además, importar material de claves de forma coherente. ¿Cuál sería el impacto en el caso en que la automatización no cree una versión de clave nueva en el momento esperado?

  • ¿Cómo piensas almacenar o depositar de forma segura el material de claves original?

  • ¿Cómo puedes mitigar el riesgo de que tu proceso de importación de claves filtre el material de claves sin procesar?

  • ¿Cuál sería el impacto de volver a importar una clave destruida previamente porque el material de clave sin procesar se conservó fuera de Google Cloud?

  • ¿El beneficio de importar el material de claves por tu cuenta justifica el aumento de la sobrecarga operativa y el riesgo?

Elige tus modelos de administración y almacenamiento de claves

Cuando diseñes tu arquitectura de CMEK, debes decidir dónde y cómo se administrarán tus claves. Lo ideal es que elijas un modelo de gobernanza de claves y un modelo de almacenamiento de claves que se alineen. El modelo de gobernanza y el modelo de almacenamiento que elijas influyen en configuraciones críticas, como la aplicación de la separación de funciones.

Administración de claves

La gobernanza 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 los mecanismos de protección para controlar cómo se usa Cloud KMS. Los enfoques clave de administración se encuentran 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 exclusivo es responsable de administrar el ciclo de vida de todas las claves criptográficas en toda la organización. Este modelo suele ser elegido por empresas altamente reguladas con requisitos de cumplimiento estrictos.
  • Administración delegada: Un equipo de seguridad central usa rieles 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 medidas de protección pueden incluir políticas de la organización que usen restricciones administradas y personalizadas, y políticas de concesión y denegación de IAM. Esto elimina los cuellos de botella operativos centrales.
Google recomienda la administración centralizada de claves para las organizaciones con requisitos reglamentarios estrictos o aquellas que deben depender de sistemas de claves externos para administrar el ciclo de vida de las claves.

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: almacenamiento de claves en un proyecto dedicado y 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. Para obtener más información sobre el modelo de almacenamiento de claves de proyectos dedicados, consulta Almacenamiento de claves de proyectos dedicados.

  • Almacenamiento de claves en el mismo proyecto: Las claves se almacenan en el mismo proyecto deGoogle Cloud que los recursos que protegen. A veces, esto se describe como "la clave sigue a los datos". Puedes usar Autokey con el almacenamiento de claves en el mismo proyecto. Para obtener más información sobre el modelo de almacenamiento de claves en el mismo proyecto, consulta Almacenamiento de claves en el mismo proyecto.

Google recomienda la administración de claves distribuidas cuando tu prioridad es la velocidad, la agilidad y la responsabilidad clara de los desarrolladores.

En la siguiente matriz, se proporcionan ejemplos de cómo se pueden combinar estos modelos de almacenamiento y gobernanza 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
Control centralizado

Enfoque completamente centralizado

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

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

Propiedad administrada

Uso recomendado: Organizaciones que requieren supervisión central de la seguridad, pero desean maximizar la velocidad de los desarrolladores.

Impacto operativo: Baja complejidad de configuración. La seguridad centralizada aplica la política con protecciones, mientras que las llaves se encuentran junto a los recursos que protegen para facilitar la administración.
Administración delegada

No recomendado

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

DevOps autónomo

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

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

Usa una arquitectura coherente en todos tus entornos

Te recomendamos que, para cualquier aplicación, uses el mismo patrón de almacenamiento de claves en los entornos de desarrollo, prueba y producción. Esta coherencia arquitectónica ayuda a garantizar que tus permisos de IAM, canalizaciones de implementación y controles de seguridad se prueben a fondo en entornos inferiores antes de que los implementes en producción. Si eliges arquitecturas diferentes para tus entornos, corres el riesgo de que se produzca una desviación de la configuración que puede provocar fallas en la implementación.

Almacenamiento de claves en un proyecto dedicado

En un modelo de almacenamiento de claves en un proyecto dedicado, todas las claves de una carpeta de entorno específica (p.ej., Producción) se almacenan en un proyecto de claves compartido y centralizado. Los permisos de administración de claves se otorgan a un equipo de seguridad compartido, que también suele administrar las operaciones y los mecanismos de protección del ciclo de vida de las claves, como las políticas de la organización de CMEK y las políticas de IAM, y los roles otorgados.

Caso de uso

Recomendamos usar el modelo de almacenamiento de claves de proyectos dedicados si tu organización prioriza un control central estricto sobre las claves de encriptación, a menudo impulsado por requisitos reglamentarios, o cuando las claves se alojan en un HSM externo.

Si tu organización está sujeta a un marco de cumplimiento que requiere un oficial criptográfico o un custodio de claves, como PCI DSS o BSI C5, este modelo es una buena opción. Si aíslas todas las claves de una aplicación en un proyecto de claves único y dedicado, puedes otorgar el rol de administrador de Cloud KMS solo a un grupo pequeño y auditado de administradores de seguridad. Esto puede simplificar las auditorías de cumplimiento, ya que limita la cantidad de proyectos en los que se deben revisar las políticas clave de acceso de administración.

Consideraciones

Este enfoque puede generar complejidades en el IAM entre proyectos y posibles cuellos de botella para los equipos de desarrollo. Para mitigar este problema, puedes implementar el aprovisionamiento automatizado de proyectos (a veces denominado "fábrica de proyectos") para automatizar la creación de claves y la asignación de permisos, o bien usar Autokey de Cloud KMS para habilitar el aprovisionamiento a pedido que admita la separación de funciones, incluso para las canalizaciones de infraestructura como código (IaC).

Ejemplo

En el siguiente diagrama, se muestra un ejemplo de la jerarquía de recursos para un entorno de producción que usa el modelo de almacenamiento de claves de proyecto dedicado:

  • La carpeta Prod contiene carpetas y proyectos individuales para diferentes aplicaciones, además de una carpeta Shared.
  • Los proyectos de aplicación contienen una variedad de recursos diferentes, como instancias de Compute Engine y buckets de Cloud Storage, pero no contienen ninguna clave de Cloud KMS.
  • La carpeta Shared contiene recursos que se comparten entre las diferentes aplicaciones.
  • Dentro de la carpeta Shared, hay un proyecto de claves dedicado en el que está habilitada la API de Cloud KMS. Este proyecto contiene todas las claves que se usan para proteger los recursos dentro de la carpeta Prod. Si usas Autokey de Cloud KMS, Autokey aprovisionará claves en este proyecto de claves dedicado.
  • Las barreras de protección a nivel de la organización y de la carpeta, como las restricciones de políticas de la organización y las políticas de IAM, aplican la separación de funciones y otras prácticas.
  • Los desarrolladores pueden tener privilegios elevados, como el rol de propietario del proyecto, dentro de una carpeta o proyecto de aplicación individual sin otorgarles privilegios en el proyecto clave.

Almacenamiento de claves en un proyecto dedicado

Almacenamiento de claves en el mismo proyecto

En este modelo, las claves se almacenan en el mismo proyecto que los recursos que protegen. Por lo general, un equipo de seguridad central implementa los parámetros de protección de la administración de claves, incluso si los desarrolladores administran el ciclo de vida de las claves para sus propias aplicaciones.

Caso de uso

Te recomendamos que uses el mismo modelo de almacenamiento de claves del proyecto si tu prioridad es la velocidad, la agilidad y la responsabilidad clara de los desarrolladores. La colocación conjunta de las claves con los recursos que protegen alinea la propiedad de las claves con la propiedad de los datos: la clave sigue a los datos. Este modelo facilita la delegación de responsabilidades clave de administración a los propietarios de cargas de trabajo, quienes pueden asumir la responsabilidad de alinearse con las políticas de la organización de CMEK y administrar las operaciones del ciclo de vida de las claves dentro de sus proyectos.

Consideraciones

Si bien este modelo empodera a los equipos de aplicaciones, requiere una auditoría diligente de los roles de IAM dentro de cada proyecto para aplicar el principio de privilegio mínimo. Este modelo puede aumentar la complejidad operativa para las organizaciones que implementan la opción de traer tu propia clave (BYOK) o que usan claves de Cloud EKM debido a la sobrecarga que implica la coordinación entre los sistemas.

Ejemplo

En el siguiente diagrama, se muestra un ejemplo de jerarquía de recursos para un entorno de producción que usa el mismo modelo de almacenamiento de claves del proyecto:

  • La carpeta Prod contiene carpetas y proyectos individuales para diferentes aplicaciones.
  • Los proyectos de aplicación contienen una variedad de recursos diferentes, como instancias de Compute Engine y buckets de Cloud Storage, incluidas las claves de Cloud KMS que protegen esos recursos.
  • Si usas Autokey de Cloud KMS, Autokey aprovisiona claves en el proyecto de recursos.
  • Las barreras de protección a nivel de la organización y de la carpeta, como las restricciones de políticas de la organización y las políticas de IAM, aplican la separación de funciones y otras prácticas, pero, si no usas Autokey, aplicar la separación de funciones puede requerir una configuración más cuidadosa.
  • Si no usas Autokey, los desarrolladores necesitan privilegios elevados de Cloud KMS en el proyecto de recursos. Si usas Autokey, solo necesitan los roles específicos del servicio para los recursos que desean crear, como el rol de usuario de BigQuery o de administrador de Compute.

Almacenamiento de claves en el mismo proyecto

Aplica la separación de obligaciones

Independientemente de tu modelo de almacenamiento, debes mantener entidades principales y permisos separados para quienes administran tus claves de encriptación y quienes las usan. Para aplicar el principio de privilegio mínimo y la separación estricta de obligaciones, otorga roles de IAM según las responsabilidades operativas específicas.

En la siguiente tabla, se resume la separación de funciones recomendada para Cloud KMS:

Responsabilidad Rol recomendado Resumen de permisos

Administración de claves, p.ej., ciclos de vida y administración de claves

Esto puede incluir administradores humanos y principales de IaC que necesitan privilegios elevados.

 Administrador de Cloud KMS (roles/cloudkms.admin)
  • Crear, rotar, habilitar, inhabilitar y destruir claves y recursos relacionados
  • Administrar políticas de IAM

Aprovisionamiento de recursos, p.ej., creación de recursos protegidos por CMEK

Esto puede incluir desarrolladores humanos y principales de IaC sin privilegios elevados.

Roles de administrador o editor específicos del servicio, como los siguientes:

  • BigQuery User (roles/bigquery.user)
  • Administrador de Compute (roles/compute.admin)
 Selecciona claves durante la creación de recursos.

Uso de la clave, p.ej., encriptación y desencriptación

Otorga este rol solo a los agentes de servicio. Para las claves que se usan en las integraciones de CMEK, los principales humanos no necesitan estos permisos.

Cuando usas Autokey, este rol se otorga al agente de servicio automáticamente.

 Encriptador y desencriptador de CryptoKey de Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) Encripta y desencripta datos con la clave.
Las claves creadas con Autokey cumplen automáticamente con estos principios.

Aplica la elevación de privilegio mínimo para las canalizaciones de IaC

Muchas organizaciones automatizan el aprovisionamiento de recursos con canalizaciones de infraestructura como código (IaC), como los ejecutores de Terraform. La forma en que diseñas el almacenamiento de claves afecta directamente la postura de seguridad de estas canalizaciones.

Para automatizar el aprovisionamiento de claves de Cloud KMS, tus canalizaciones de IaC deben tener roles administrativos con privilegios altos para generar claves y modificar políticas de IAM. Si un atacante compromete la canalización de IaC, podría obtener el control administrativo completo sobre tu plano de administración de claves.

  • Si usas el almacenamiento de claves de proyectos dedicados, la canalización requiere acceso de administrador al proyecto central de Cloud KMS. Si se vulnera la canalización, se podría exponer el plano de administración de claves de toda tu organización.
  • Si usas el almacenamiento de claves en el mismo proyecto, la canalización solo requiere acceso administrativo al proyecto de recursos. Esto limita el alcance del riesgo potencial a la aplicación específica, pero aún requiere la administración de privilegios elevados dentro del proyecto.

Autokey de Cloud KMS aborda este riesgo delegando el aprovisionamiento de claves a un agente de servicio seguro administrado por Google, de modo que puedas implementar una canalización de privilegio mínimo para el aprovisionamiento continuo de claves:

  • Canalizaciones con pocos privilegios: La canalización de IaC solo requiere el rol de usuario de Autokey de Cloud KMS con pocos privilegios (roles/cloudkms.autokeyUser) para solicitar una clave creando un recurso KeyHandle.
  • Aprovisionamiento automatizado: El agente de servicio de Cloud KMS administrado por Google se encarga de la creación de claves y las actualizaciones de políticas de IAM tras bambalinas.
  • Alcance limitado del riesgo: Al minimizar los permisos otorgados a tu canalización, este diseño evita otorgar a tus canalizaciones de implementación privilegios elevados de creación de claves o de administrador de seguridad, o la capacidad de asignar roles de ayuda, lo que reduce significativamente el riesgo de que se vulnere una canalización.

Una canalización de IaC que habilita Autokey requiere un rol más permisivo, como el de administrador de Autokey de Cloud KMS (roles/cloudkms.autokeyAdmin), por lo que, si usas canalizaciones de IaC para administrar la habilitación de Autokey, también debes aplicar la separación de funciones a las entidades principales individuales de IaC.

Elige si quieres usar Autokey

Después de elegir la arquitectura de almacenamiento de claves, debes decidir cómo se aprovisionan las claves. Recomendamos automatizar la creación de claves con Autokey de Cloud KMS siempre que sea posible para reducir el trabajo repetitivo y los errores de configuración. Autokey tiene compatibilidad integrada con ambos modelos de almacenamiento:

  • Autokey con almacenamiento de claves en el mismo proyecto: Los desarrolladores generan claves sin problemas dentro de sus propios proyectos a pedido, al mismo tiempo que cumplen con las medidas de protección centrales. Puedes habilitar Autokey con almacenamiento de claves en el mismo proyecto para cada proyecto o para todos los proyectos de una carpeta.
  • Autokey con almacenamiento de claves en un proyecto dedicado: Los desarrolladores generan claves sin problemas en un proyecto de claves central en nombre de los recursos de otros proyectos. Habilitas Autokey con almacenamiento de claves en un proyecto dedicado a nivel de la carpeta.

Las siguientes prácticas recomendadas se automatizan cuando usas Autokey:

  • Crea claves en la misma ubicación que el recurso que protegerán
  • Mantén la separación de obligaciones entre los administradores de claves y los propietarios de recursos
  • Otorga roles de IAM en claves nuevas
  • Usa el nivel de protección HSM.
  • Sigue las estrategias de granularidad recomendadas
  • Programa la rotación automática de claves cada 365 días

Debido a que Autokey de Cloud KMS controla el aprovisionamiento y la asignación de claves en curso, usar Autokey reduce gran parte de la sobrecarga de establecer políticas, herramientas y procedimientos operativos personalizados. Si bien simplifica el esfuerzo inicial y continuo, aún debes establecer recursos operativos y configurar controles de detección y supervisión para garantizar una administración coherente en toda tu organización.

Cumplimiento y Autokey

Muchos regímenes de cumplimiento requieren que, en última instancia, mantengas el control sobre tus claves de encriptación, independientemente de tu proveedor de servicios en la nube.

Delegar las tareas de rutina del aprovisionamiento de claves a Autokey de Cloud KMS no incumple este estándar. Autokey actúa estrictamente como un motor de automatización que ejecuta tus políticas predefinidas. Conservas la propiedad, la autoridad y el control criptográfico definitivos a través de tres mecanismos principales:

  • Tu responsable de la criptografía conserva el control exclusivo de las claves. Solo los administradores pueden inhabilitar, rotar o destruir versiones de claves. El servicio de Autokey no puede realizar estas acciones de ciclo de vida.
  • Tus administradores determinan exactamente dónde se habilita Autokey y qué principales pueden solicitar claves. Puedes inhabilitar Autokey o revocar permisos en cualquier nivel de la jerarquía de recursos en cualquier momento, lo que detendrá la automatización de inmediato.
  • Cada clave generada, permiso asignado y política ajustada por Autokey se registra en Cloud Logging. Esto proporciona a los auditores un registro de auditoría continuo y automatizado para verificar el cumplimiento.

En lugar de debilitar la administración, delegar el aprovisionamiento en Autokey fortalece el cumplimiento. Reemplaza los pasos de configuración manuales y propensos a errores por la aplicación programática de la separación de funciones y la seguridad de la canalización, lo que satisface los estrictos requisitos de control de los esquemas de cumplimiento, como NIST SP 800-152 y PCI DSS.

Alinearse con las prácticas recomendadas de administración de claves

Google recomienda prácticas para la ubicación, el nivel de protección, el programa de rotación, la granularidad y los permisos de las claves. Puedes implementar estas prácticas con el enfoque automatizado de la clave automática de Cloud KMS o configurándolas de forma manual. Puedes ver qué tan bien se alinean tus claves con estas prácticas usando el panel de métricas de encriptación. Puedes detectar incumplimientos de la separación de funciones con los hallazgos de vulnerabilidades de Security Command Center.

Ubicación de la clave

Cuando usas la CMEK manual, debes crear llaveros de claves de Cloud KMS en las ubicaciones en las que planeas implementar recursos de Google Cloud que estén encriptados con la CMEK. Debes hacer esto antes de crear las claves.

  • Los recursos regionales y zonales deben usar un llavero de claves y una clave en la misma región que el recurso o en la ubicación global. Los recursos zonales y de una sola región no pueden usar un llavero de claves multirregional que no sea global.
  • Los recursos multirregionales (como un conjunto de datos de BigQuery en la región múltiple us) deben usar un llavero de claves y una clave en la misma región múltiple. Los recursos multirregionales no pueden usar una clave regional.
  • Los recursos globales deben usar un llavero de claves y una clave en la ubicación global.

En la mayoría de los casos, estas restricciones se aplican a través del servicio de Google Cloud.

Aplicar el uso de claves regionales es una parte de una estrategia de regionalización de datos exitosa. Cuando exiges el uso de llaveros de claves y claves en una región definida, también exiges que los recursos coincidan con la región del llavero de claves. Para obtener más información sobre la residencia de datos, consulta Controla la residencia de los datos. Para obtener más información, consulta Elige una ubicación adecuada.

Si usas Autokey de Cloud KMS, los llaveros de claves se crean automáticamente en la misma ubicación que los recursos que proteges.

Elige una estrategia de nivel de detalle para las claves

El nivel de detalle hace referencia a la escala y el alcance del uso previsto de cada clave. Por ejemplo, se dice que una clave que protege varios recursos es menos detallada que una clave que protege solo un recurso. Elegir una estrategia de granularidad de claves adecuada te ayuda a cumplir con la recomendación del NIST de que cada clave tenga un propósito específico.

En general, recomendamos que cada clave se use de la siguiente manera:

  • Se usa para un solo proyecto Google Cloud .
  • Se usa en una sola ubicación, por ejemplo, us-central1.
  • Se usa en un solo servicio o producto, por ejemplo, BigQuery.
  • Siempre que sea posible, se usa para un solo recurso, por ejemplo, un solo bucket de Cloud Storage.

Para la mayoría de las organizaciones, esta estrategia proporciona un buen equilibrio entre la sobrecarga de mantener muchas claves altamente detalladas y los riesgos potenciales de usar claves menos detalladas que se comparten entre muchos proyectos, servicios o recursos.

Las claves creadas con Autokey de Cloud KMS siguen esta recomendación.

Seguir estos lineamientos de granularidad facilita la inhabilitación o destrucción seguras de versiones de claves y limita los riesgos de destrucción accidental o maliciosa de claves.

Elige el nivel de protección para las claves

Cuando creas una clave, es tu responsabilidad seleccionar el nivel de protección adecuado para cada clave en función de los requisitos de los datos y las cargas de trabajo encriptados con CMEK. Las siguientes preguntas pueden ayudarte en tu evaluación:

  1. ¿Tienes requisitos regulatorios, de aislamiento o de residencia especializados? Evalúa si tu carga de trabajo requiere alguna de las siguientes características de alta seguridad:

    • Almacenamiento externo: Usa la CMEK manual con Cloud EKM. Recomendamos el nivel de protección EXTERNAL_VPC para una mejor disponibilidad.
    • Hardware dedicado: Usa CMEK manual con Cloud HSM de un solo arrendatario.

    De lo contrario, continúa con la siguiente pregunta.

  2. ¿Quieres aprovisionamiento de claves y administración del ciclo de vida automatizados?

    • Si es así, usa Autokey de Cloud KMS. Autokey crea claves automáticamente con el nivel de protección HSM de múltiples usuarios. Incluso si las claves respaldadas por software son aceptables para ti, te recomendamos que aceptes el parámetro de referencia de seguridad más alto de Cloud HSM para beneficiarte de la automatización que proporciona Autokey.

    • De lo contrario, continúa con la siguiente pregunta.

  3. ¿Necesitas que tu material de claves permanezca dentro del límite físico de un módulo de seguridad de hardware (HSM)?

    • Si es así, usa Cloud HSM multiusuario.
    • De lo contrario, usa claves respaldadas por software.

Elige un período de rotación

Cloud KMS admite la rotación de claves automática de claves simétricas respaldadas por software y respaldadas por hardware, como las que se usan para la CMEK. En el caso de las claves respaldadas por software, te recomendamos que uses el período de rotación estándar de la industria de 90 días. En el caso de las claves de Cloud HSM, recomendamos el período de rotación estándar de la industria de 365 días. Las claves externas se deben rotar de forma manual según el programa que elijas.

Te recomendamos que evalúes el período de rotación de claves adecuado en función de tus necesidades. La frecuencia de rotación de claves depende de los requisitos de tus cargas de trabajo en cuanto a la sensibilidad o el cumplimiento. Por ejemplo, podrías configurar la rotación de claves al menos una vez al año para satisfacer determinados estándares de cumplimiento, o bien podrías elegir un período de rotación más frecuente para las cargas de trabajo altamente sensibles.

La rotación frecuente de claves ayuda a limitar la cantidad de mensajes encriptados con la misma versión de clave, lo que ayuda a reducir el riesgo y las consecuencias en caso de que se vulnere una clave.

Aplica el principio de privilegio mínimo

Cuando otorgues roles de IAM, sigue el principio de privilegio mínimo. Te recomendamos que evites usar roles básicos como propietario, editor y visualizador. En su lugar, otorga roles predefinidos de Cloud KMS para mitigar los riesgos de incidentes de seguridad relacionados con el acceso con privilegios excesivos. Por ejemplo, si un principal solo necesita importar material de claves, otorga el rol de importador de Cloud KMS (roles/cloudkms.importer) en lugar del rol de administrador de Cloud KMS (roles/cloudkms.admin), que es más permisivo.

Establece barreras operativas

En las siguientes secciones, se describen los controles que puedes implementar para mitigar riesgos, como el uso incoherente de claves o la eliminación o destrucción accidentales.

Aplica retenciones del proyecto

Te recomendamos que protejas los proyectos con retenciones (versión preliminar) para evitar la eliminación accidental de tus proyectos de Cloud KMS y las claves que contienen. Mientras se aplica una retención del proyecto, se bloquea la eliminación del proyecto hasta que se quite la retención. En el caso de los proyectos que contienen claves de Cloud KMS, esto evita una posible causa de eliminación accidental de claves.

Exige el uso de claves CMEK

Te recomendamos que exijas el uso de CMEK en todo tu entorno con restricciones en la política de la organización.

Usa constraints/gcp.restrictNonCmekServices para bloquear las solicitudes de creación de determinados tipos de recursos sin especificar una clave CMEK.

Requiere Autokey de Cloud KMS

Usar la clave automática de Cloud KMS para crear todas tus CMEK garantiza que las claves se creen de manera coherente. Si deseas aplicar esta coherencia, puedes configurar una carpeta para que requiera CMEK creadas por Autokey y evitar que se usen claves creadas manualmente para la CMEK. Para obtener información sobre cómo configurar estas restricciones, consulta Cómo aplicar el uso de Autokey.

Especifica una duración mínima para la destrucción programada

Te recomendamos que establezcas una duración mínima para la destrucción programada. La destrucción de claves es una operación irreversible que puede provocar la pérdida permanente de datos. De forma predeterminada, Cloud KMS usa una duración para la destrucción programada (a veces, llamado período de borrado no definitivo) de 30 días antes de que el material de la clave se destruya de forma irrecuperable. Esto da tiempo para restablecer una clave en caso de destrucción accidental. Sin embargo, es posible que alguien con el rol de administrador de Cloud KMS cree una clave con una duración de destrucción programada de tan solo 24 horas, lo que podría no ser suficiente para que detectes un problema y restablezcas la clave. La duración de destrucción programada solo se puede establecer durante la creación de la clave.

Cuando una clave está programada para su destrucción, no se puede usar para operaciones criptográficas y todas las solicitudes para usar la clave fallan. Durante este tiempo, supervisa los registros de auditoría para verificar que la clave no esté en uso. Si quieres volver a usar la clave, debes restablecerla antes del final del período de destrucción programada.

Para garantizar que todas las claves creadas cumplan con una duración mínima de destrucción programada, te recomendamos que configures la restricción en la política de la organización constraints/cloudkms.minimumDestroyScheduledDuration con un mínimo de 30 días o la duración que prefieras. Esta política de la organización impide que los usuarios creen claves con una duración de destrucción programada inferior al valor especificado en la política.

Aplica los niveles de protección permitidos para las CMEK

Te recomendamos que apliques tus requisitos para los niveles de protección de claves de manera coherente en todo tu entorno con restricciones en la política de la organización.

Usa constraints/cloudkms.allowedProtectionLevels para especificar que las claves nuevas, las versiones de claves y los trabajos de importación deben usar los niveles de protección permitidos.

Cuando apliques el uso de Autokey, todas las claves tendrán respaldo de hardware.

Configura controles de detección para las CMEK

Google Cloud proporciona varios controles de detección para las CMEK. En las siguientes secciones, se explica cómo habilitar y usar los controles pertinentes para Cloud KMS.

Habilita y agrega registros de auditoría

Te recomendamos que agregues los registros de auditoría de actividad del administrador de Cloud KMS en una ubicación centralizada para todos los recursos de tu organización. Esto permite que un equipo de seguridad o un auditor revise toda la actividad relacionada con la creación o modificación de recursos de Cloud KMS al mismo tiempo. Para obtener orientación sobre cómo configurar receptores de registros agregados, consulta Agrega y almacena los registros de tu organización.

De manera opcional, puedes habilitar los registros de acceso a los datos para registrar las operaciones que usan las claves, incluidas las operaciones de encriptación y desencriptación. Cuando se usan CMEK, esto puede generar un volumen de registros considerable y afectar tus costos, ya que cada operación de cada servicio que usa CMEK creará registros de acceso a los datos. Antes de habilitar los registros de acceso a los datos, te recomendamos que definas un caso de uso claro para los registros adicionales y evalúes cómo aumentarán tus costos de registro.

Habilita Security Command Center para ver los hallazgos de vulnerabilidades de Cloud KMS

Security Command Center genera hallazgos de vulnerabilidades que destacan los errores de configuración asociados con Cloud KMS y otros recursos. Te recomendamos que habilites Security Command Center y que integres estos hallazgos en tus operaciones de seguridad existentes. Estos hallazgos incluyen problemas como claves de Cloud KMS de acceso público, proyectos de Cloud KMS con el rol owner demasiado permisivo o roles de IAM que infringen la separación de obligaciones.

Supervisión y corrección

Te recomendamos que la verificación del uso de claves y la alineación con las prácticas recomendadas sean un componente central de tu estrategia de supervisión, ya que sirven como un control de detección crucial para identificar riesgos y errores de configuración en tu configuración de CMEK. Haz un seguimiento de esos hallazgos, clasifícalos según tus procedimientos de seguridad y corrígelos de inmediato. Las siguientes herramientas te ayudan a identificar los problemas que puedes resolver para mejorar tu postura de seguridad:

  • Panel Métricas de encriptación: Puedes ver las métricas de encriptación para saber qué recursos están protegidos con una CMEK y qué tan bien se alinean esas CMEK con las prácticas recomendadas. Para identificar los problemas que se deben corregir, puedes consultar las listas de recursos que no están protegidos por una CMEK y las listas de claves que no se alinean por completo con las prácticas recomendadas.

  • Panel de uso de claves: Puedes consultar el uso de las claves para identificar los recursos de Google Cloud de tu organización que dependen de las claves de Cloud KMS y están protegidos por ellas. Este panel se puede usar para supervisar el estado, el uso y la disponibilidad de tus versiones de clave y los recursos que protegen. El panel también identifica los datos a los que no se puede acceder debido a una clave inhabilitada o destruida para que puedas tomar medidas, como borrar definitivamente los datos inaccesibles o volver a habilitar la clave. La información del panel Uso de claves también está disponible a través de la API de Cloud KMS Inventory.

Te recomendamos que establezcas un plan operativo para detectar automáticamente los eventos que consideres importantes y que revises periódicamente el panel del uso de las claves.

Resumen de prácticas recomendadas

En la siguiente tabla, se resumen las prácticas recomendadas de este documento.

Tema Tarea
Elige la creación manual o automática de las claves Usa Autokey de Cloud KMS si las características de las claves que crea Autokey satisfacen tus necesidades.
Proyectos de claves de Cloud KMS Usa un proyecto de claves centralizado para cada entorno. No crees recursos de Cloud KMS en el mismo proyecto que los recursos de Google Cloudque protegen las claves.
Llaveros de claves de Cloud KMS Crea llaveros de claves de Cloud KMS para cada ubicación en la que desees proteger recursos de Google Cloud.
Nivel de detalle de las claves Elige un patrón de nivel de detalle de las claves que satisfaga tus necesidades o usa Autokey para aprovisionar claves automáticamente con el nivel de detalle recomendado para cada servicio.
Nivel de protección Elige Cloud EKM si tu material de claves debe almacenarse fuera de Google Cloud. Elige Cloud HSM de un solo arrendatario si tu material de claves debe alojarse en particiones dedicadas en módulos de seguridad de hardware (HSM) propiedad de Google Cloud. Elige Cloud HSM de múltiples arrendatarios si tu material de claves se puede alojar en clústeres de módulos de seguridad de hardware (HSM) propiedad de Google Cloudque se comparten con otros clientes de Google Cloud . Elige claves de software si no precisas Cloud HSM ni Cloud EKM. Revisa la guía para seleccionar un nivel de protección.
Material de clave Para el material de claves alojado en Google Cloud, usa material de claves generado por Google Cloudsiempre que sea posible. Si usas material de claves importado, implementa automatización y procedimientos para mitigar los riesgos.
Propósito y algoritmo de las claves Todas las claves de CMEK deben usar el propósito de clave simétrica ENCRYPT_DECRYPT y el algoritmo GOOGLE_SYMMETRIC_ENCRYPTION.
Período de rotación Usa la rotación automática de claves para asegurarte de que tus claves se roten en función de un programa. Elige y aplica un período de rotación que satisfaga tus necesidades, idealmente, al menos una vez al año. Usa una rotación de claves más frecuente para las cargas de trabajo sensibles.
Privilegio mínimo Otorga los roles predefinidos más limitados que permitan a tus principales completar sus tareas. No uses roles básicos.
Separación de obligaciones Mantén permisos independientes para los administradores de claves y las entidades principales que usan claves.
Retenciones de proyecto Usa retenciones de proyecto para evitar la eliminación accidental de tus proyectos clave.
Exige el uso de CMEK Usa la restricción constraints/gcp.restrictNonCmekServices.
Especifica una duración mínima para la destrucción programada Usa la restricción constraints/cloudkms.minimumDestroyScheduledDuration.
Aplica los niveles de protección permitidos para las CMEK Usa la restricción constraints/cloudkms.allowedProtectionLevels.
Habilita y agrega registros de auditoría Agrega registros de auditoría de la actividad administrativa para todos los recursos de tu organización. Evalúa si deseas habilitar el registro de operaciones con claves.
Supervisa el uso de las claves Usa la API de Cloud KMS Inventory o la consola de Google Cloud para comprender el uso de las claves. De manera opcional, usa Cloud Monitoring para configurar alertas sobre operaciones sensibles, como programar la destrucción de una clave.
Habilita Security Command Center para Cloud KMS Revisa los hallazgos de las vulnerabilidades y, además, incorpora la revisión de estos hallazgos como parte de tus operaciones de seguridad.
Evalúa los requisitos de cumplimiento Revisa tu arquitectura de Cloud KMS y compárala con los requisitos de cumplimiento que debas satisfacer.

¿Qué sigue?

  • Obtén más información sobre cómo Autokey de Cloud KMS reduce los esfuerzos necesarios para usar CMEK de forma coherente.