En esta página se describen las prácticas recomendadas para configurar el cifrado en reposo con claves de cifrado gestionadas por el cliente (CMEKs) en tus recursos de Google Cloud . Esta guía está dirigida a arquitectos de la nube y equipos de seguridad, y describe las prácticas recomendadas y las decisiones que debe tomar al diseñar su arquitectura de CMEK.
En esta guía se da por hecho que ya conoces Cloud Key Management Service (Cloud KMS) y las claves de encriptado gestionadas por el cliente y que has leído el artículo detallado sobre Cloud KMS.Decisiones preliminares
Las recomendaciones de esta página están dirigidas a los clientes que usan CMEKs para cifrar sus datos. Si no sabes si debes usar CMEKs creadas manualmente o automáticamente como parte de tu estrategia de seguridad, en esta sección se ofrecen directrices para tomar estas decisiones preliminares.
Decidir si usar claves de cifrado gestionadas por el cliente
Te recomendamos que uses CMEK para cifrar los datos en reposo de los servicios de Google Cloud si necesitas alguna de las siguientes funciones:
Tener tus propias claves de cifrado.
Controla y gestiona tus claves de cifrado, incluida la elección de la ubicación, el nivel de protección, la creación, el control de acceso, la rotación, el uso y la destrucción.
Genera material de claves en Cloud KMS o importa material de claves que se mantenga fuera de Google Cloud.
Define la política sobre dónde se deben usar tus claves.
Eliminar de forma selectiva los datos protegidos por tus claves en caso de baja o para solucionar eventos de seguridad (destrucción criptográfica).
Crea y usa claves únicas para cada cliente, lo que establece un límite criptográfico en torno a tus datos.
Registra el acceso administrativo y de datos a las claves de cifrado.
Cumplir la normativa actual o futura que requiera alguno de estos objetivos.
Elegir la creación de claves manual o automática
En esta guía se describen las prácticas recomendadas para tomar las decisiones que debes tomar al aprovisionar CMEKs por tu cuenta. Clave automática de Cloud KMS toma algunas de estas decisiones por ti y automatiza muchas recomendaciones de esta guía. Usar Autokey es más sencillo que aprovisionar claves por tu cuenta y es la opción recomendada si las claves creadas por Autokey cumplen todos tus requisitos.
Autokey aprovisiona CMEKs por ti. Las CMEKs proporcionadas por Autokey tienen las siguientes características:
- Nivel de protección: HSM.
- Algoritmo: AES-256 GCM.
Periodo de rotación: un año.
Una vez que Autokey crea una clave, un administrador de Cloud KMS puede editar el periodo de rotación predeterminado.
- Separación de funciones:
- La cuenta de servicio del servicio recibe automáticamente los permisos de cifrado y descifrado de la clave.
- Los permisos de administrador de Cloud KMS se aplican como de costumbre a las claves creadas por Autokey. Los administradores de Cloud KMS pueden ver, actualizar, habilitar o inhabilitar, y destruir las claves creadas por Autokey. Los administradores de Cloud KMS no tienen permisos de cifrado y descifrado.
- Los desarrolladores de Autokey solo pueden solicitar la creación y la asignación de claves. No pueden ver ni gestionar llaves.
- Especificidad o granularidad de la clave: las claves creadas por Autokey tienen una granularidad que varía según el tipo de recurso. Para obtener información específica sobre la granularidad de las claves de cada servicio, consulta Servicios compatibles.
Ubicación: Autokey crea claves en la misma ubicación que el recurso que se va a proteger.
Si necesitas crear recursos protegidos con CMEK en ubicaciones en las que Cloud HSM no está disponible, debes crear la CMEK manualmente.
- Estado de la versión de la clave: las claves recién creadas que se solicitan mediante Autokey se crean como versión de clave principal en el estado habilitado.
- Nombre del conjunto de claves: todas las claves creadas por Autokey se crean en un conjunto de claves llamado
autokeyen el proyecto Autokey de la ubicación seleccionada. Los conjuntos de claves de tu proyecto Autokey se crean cuando un desarrollador de Autokey solicita la primera clave en una ubicación determinada. - Nombres de las claves: las claves creadas por Autokey siguen esta convención de nomenclatura:
PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX. - Exportación de claves: al igual que todas las claves de Cloud KMS, las claves creadas por Autokey no se pueden exportar.
- Monitorización de claves: al igual que todas las claves de Cloud KMS que se usan en servicios integrados con CMEK compatibles con la monitorización de claves, las claves creadas por Autokey se monitorizan en el panel de control de Cloud KMS.
Si tienes requisitos que no se pueden cumplir con las claves creadas por Autokey, como un nivel de protección que no sea HSM o servicios que no sean compatibles con Autokey, te recomendamos que uses CMEKs creadas manualmente en lugar de Autokey.
Diseñar la arquitectura de CMEK
Al diseñar una arquitectura de CMEK, debes tener en cuenta la configuración de las claves que vas a usar y cómo se gestionan. Estas decisiones influyen en los costes, los gastos operativos y la facilidad de implementar funciones como el cifrado destructivo.
En las siguientes secciones se analizan las recomendaciones para cada opción de diseño.
Usar un proyecto de clave CMEK centralizado para cada entorno
Te recomendamos que uses un proyecto de clave CMEK centralizado para cada carpeta de entorno. No crees recursos cifrados con CMEK en el mismo proyecto en el que gestionas las claves de Cloud KMS. Este enfoque ayuda a evitar que se compartan claves de cifrado entre entornos y a habilitar la separación de tareas.
En el siguiente diagrama se ilustran estos conceptos en el diseño recomendado:
- Cada carpeta de entorno tiene un proyecto de claves de Cloud KMS administrado independientemente de los proyectos de aplicaciones.
- Los conjuntos de claves y las claves de Cloud KMS se aprovisionan en el proyecto de claves de Cloud KMS, y estas claves se usan para cifrar recursos en los proyectos de aplicaciones.
- Las políticas de Gestión de Identidades y Accesos (IAM) se aplican a proyectos o carpetas para habilitar la separación de funciones. La entidad que gestiona las claves de Cloud KMS en el proyecto de claves de Cloud KMS no es la misma que usa las claves de cifrado en los proyectos de aplicaciones.
Crear conjuntos de claves de Cloud KMS para cada ubicación
Debes crear conjuntos de claves de Cloud KMS en las ubicaciones en las que desplieguesGoogle Cloud recursos encriptados con CMEK.
- Los recursos regionales y zonales deben usar un conjunto de claves y una CMEK en la misma región que el recurso o en la ubicación
global. Los recursos de una sola región y de una zona no pueden usar un conjunto de claves multirregión que no seaglobal. - Los recursos multirregionales (como un conjunto de datos de BigQuery en la
usmultirregión) deben usar un llavero y una CMEK en la misma multirregión o birregión. Los recursos multirregionales no pueden usar un conjunto de claves regional. - Los recursos globales deben usar un conjunto de claves y una CMEK en la ubicación
global.
Aplicar claves regionales es una parte de la estrategia de regionalización de datos. Al obligar a usar conjuntos de claves y claves en una región definida, también obliga a que los recursos coincidan con la región del conjunto de claves. Para obtener información sobre la residencia de datos, consulta el artículo Controlar la residencia de datos.
En el caso de las cargas de trabajo que requieren alta disponibilidad o funciones de recuperación ante desastres en varias ubicaciones, es tu responsabilidad evaluar si tu carga de trabajo es resiliente en caso de que Cloud KMS no esté disponible en una región determinada. Por ejemplo, un disco persistente de Compute Engine cifrado con una clave de Cloud KMS de la región A no se puede volver a crear en la región B en un escenario de recuperación tras desastres en el que la región A no esté disponible. Para reducir el riesgo de que se produzca esta situación, puedes planificar el cifrado de un recurso con claves global.
Para obtener más información, consulta Elegir el mejor tipo de ubicación.
Si usas Autokey de Cloud KMS, se crearán conjuntos de claves en la misma ubicación que los recursos que protejas.
Elegir una estrategia de granularidad de claves
La granularidad hace referencia a la escala y el ámbito del uso previsto de cada clave. Por ejemplo, se dice que una clave que protege varios recursos es menos granular que una clave que protege solo un recurso.
Las claves de Cloud KMS aprovisionadas manualmente para CMEK deben aprovisionarse con antelación antes de crear un recurso que se cifre con la clave, como un disco persistente de Compute Engine. Puedes crear claves muy específicas para recursos concretos o claves menos específicas para reutilizarlas en varios recursos.
Aunque no hay un patrón universalmente correcto, ten en cuenta las siguientes ventajas e inconvenientes de los diferentes patrones:
Claves de alta granularidad: por ejemplo, una clave para cada recurso
- Más control para inhabilitar versiones de claves de forma segura: inhabilitar o destruir una versión de clave que se usa en un ámbito reducido tiene menos riesgo de afectar a otros recursos que inhabilitar o destruir una clave compartida. Esto también significa que usar claves muy granulares ayuda a reducir el posible impacto de una clave vulnerada en comparación con el uso de claves de baja granularidad.
- Coste: usar claves granulares requiere mantener más versiones de claves activas en comparación con una estrategia que usa claves con menor granularidad. Como los precios de Cloud KMS se basan en el número de versiones de claves activas, si eliges una granularidad de claves más alta, los costes serán mayores.
- Sobrecarga operativa: usar claves muy granulares puede requerir esfuerzo administrativo o herramientas adicionales para automatizar el aprovisionamiento de un gran número de recursos de Cloud KMS y gestionar los controles de acceso de los agentes de servicio para que solo puedan usar las claves adecuadas. Si necesitas claves con una alta granularidad, Autokey puede ser una buena opción para automatizar el aprovisionamiento. Para obtener más información sobre la granularidad de las claves de Autokey de cada servicio, consulta Servicios compatibles.
Claves de baja granularidad: por ejemplo, una clave para cada aplicación, región y entorno.
- Se requiere precaución para inhabilitar versiones de claves de forma segura: inhabilitar o destruir una versión de clave que se utiliza en un ámbito amplio requiere más cuidado que inhabilitar o destruir una clave muy granular. Debes asegurarte de que todos los recursos cifrados con esa versión de la clave se vuelvan a cifrar de forma segura con una nueva versión de la clave antes de inhabilitar la antigua. En muchos tipos de recursos, puede ver el uso de las claves para identificar dónde se ha usado una clave. Esto también significa que, si usas claves de baja granularidad, puede aumentar el impacto potencial de una clave que se haya visto comprometida en comparación con el uso de claves de alta granularidad.
- Coste: si usas claves menos granulares, tendrás que crear menos versiones de claves y los precios de Cloud KMS se basan en el número de versiones de claves activas.
- Sobrecarga operativa: puedes definir y aprovisionar previamente un número conocido de claves, con lo que se requiere menos esfuerzo para asegurar los controles de acceso adecuados.
Elegir el nivel de protección de las llaves
Cuando crees una clave, es tu responsabilidad seleccionar el nivel de protección adecuado para cada clave en función de tus requisitos para los datos y las cargas de trabajo cifrados con CMEK. Las siguientes preguntas pueden ayudarte en tu evaluación:
¿Necesitas alguna de las funciones de CMEK? Puedes consultar las funciones que se indican en la sección Decidir si se debe usar CMEK de esta página.
- Si es así, continúa con la siguiente pregunta.
- Si no es así, te recomendamos que uses el Google cifrado predeterminado.
¿Necesitas que el material de tu clave permanezca dentro del límite físico de un módulo de seguridad de hardware (HSM)?
- Si es así, continúa con la siguiente pregunta.
- Si no es así, te recomendamos que uses CMEK con claves respaldadas por software.
¿Necesitas que el material de la clave se almacene fuera de Google Cloud?
- En ese caso, te recomendamos que uses CMEK con Cloud External Key Manager.
- Si no es así, te recomendamos que uses CMEK con Cloud HSM (claves respaldadas por hardware).
Usar material de clave generado por Google Cloudsiempre que sea posible
Esta sección no se aplica a las claves de EKM de Cloud.
Cuando creas una clave, debes permitir que Cloud KMS genere el material de la clave o importar manualmente el material de la clave generado fuera de Google Cloud. Cuando sea posible, te recomendamos que elijas la opción generada. Esta opción no expone el material de claves sin procesar fuera de Cloud KMS y crea automáticamente versiones de claves nuevas en función del periodo de rotación de claves que elijas. Si necesitas importar tu propio material de clave, te recomendamos que evalúes los siguientes aspectos operativos y riesgos de usar el enfoque de traer tu propia clave (BYOK):
- ¿Puedes implementar la automatización para importar de forma constante nuevas versiones de claves? Esto incluye tanto la configuración de Cloud KMS para restringir las versiones de claves a la importación como la automatización fuera de Cloud KMS para generar e importar material de claves de forma coherente. ¿Qué ocurre si la automatización no crea una nueva versión de la clave en el momento previsto?
- ¿Cómo tiene previsto almacenar o depositar de forma segura el material de la clave original?
- ¿Cómo puedes mitigar el riesgo de que tu proceso de importación de claves filtre el material de clave sin procesar?
- ¿Qué ocurriría si se volviera a importar una clave que se había destruido anteriormente porque el material de la clave sin procesar se había conservado fuera de Google Cloud?
- ¿Merece la pena importar el material de claves por tu cuenta a pesar del aumento de la carga operativa y del riesgo?
Elige el propósito y el algoritmo de clave adecuados para tus necesidades
Cuando creas una clave, debes seleccionar el propósito y el algoritmo subyacente de la clave. En los casos prácticos de CMEK, solo se pueden usar claves con el propósito simétrico ENCRYPT_DECRYPT. Este propósito de clave siempre usa el algoritmo GOOGLE_SYMMETRIC_ENCRYPTION, que utiliza claves del estándar de cifrado avanzado (AES-256) de 256 bits en modo Galois/Counter (GCM), con metadatos internos de Cloud KMS. Cuando usas Autokey, estos ajustes se aplican automáticamente.
Para otros casos prácticos, como el cifrado del lado del cliente, consulta los propósitos y algoritmos de las claves disponibles para elegir la opción que mejor se adapte a tu caso práctico.
Elige un periodo de rotación
Te recomendamos que evalúes el periodo de rotación de claves adecuado para tus necesidades. La frecuencia de la rotación de claves depende de los requisitos de tus cargas de trabajo en función de la sensibilidad o el cumplimiento. Por ejemplo, puede que sea necesario rotar las claves al menos una vez al año para cumplir determinados estándares, o bien puede que elijas un periodo de rotación más frecuente para cargas de trabajo muy sensibles.
Después de rotar una clave simétrica, la nueva versión se marca como versión de clave principal y se usa para todas las solicitudes nuevas de protección de información. Las versiones de clave antiguas siguen estando disponibles para desencriptar los datos encriptados anteriormente con esa versión. Cuando rotas una clave, los datos que se encriptaron con versiones anteriores de la clave no se vuelven a encriptar automáticamente.
La rotación frecuente de claves ayuda a limitar el número de mensajes cifrados con la misma versión de clave, lo que contribuye a reducir el riesgo y las consecuencias de que una clave se vea comprometida.
Si usas Autokey, las claves se crean con un periodo de rotación predeterminado de un año. Puedes cambiar el periodo de rotación de las claves después de crearlas.Aplicar los controles de acceso adecuados
Te recomendamos que tengas en cuenta los principios de privilegio mínimo y separación de obligaciones al planificar los controles de acceso. En las siguientes secciones se presentan estas recomendaciones.
Aplica el principio de mínimos accesos
Cuando asignes permisos para gestionar CMEKs, ten en cuenta el principio de mínimos privilegios y concede los permisos mínimos necesarios para realizar una tarea. Te recomendamos que no uses los roles básicos. En su lugar, concede roles de Cloud KMS predefinidos para mitigar los riesgos de incidentes de seguridad relacionados con el acceso con demasiados privilegios.
Security Command Center puede detectar automáticamente las infracciones de este principio y los problemas relacionados con él mediante los resultados de vulnerabilidades de IAM.Plan de separación de funciones
Mantén identidades y permisos independientes para los administradores de tus claves de cifrado y para los usuarios que las utilizan. NIST SP 800-152 define una separación de funciones entre el responsable de criptografía, que habilita y gestiona los servicios de un sistema de gestión de claves criptográficas, y un usuario que utiliza esas claves para cifrar o descifrar recursos.
Cuando usas CMEK para gestionar el cifrado en reposo con Google Cloud servicios,
el rol de gestión de identidades y accesos para usar las claves de cifrado se asigna al agente de servicio del servicio Google Cloud , no al usuario individual. Por ejemplo, para crear objetos en un segmento de Cloud Storage cifrado, un usuario solo necesita el rol de gestión de identidades y accesos roles/storage.objectCreator, y el agente de servicio de Cloud Storage del mismo proyecto (como service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) necesita el rol de gestión de identidades y accesos roles/cloudkms.cryptoKeyEncrypterDecrypter.
En la siguiente tabla se indica qué roles de IAM se suelen asociar a cada función de trabajo:
| Rol de gestión de identidades y accesos | Descripción | Designación NIST SP 800-152 |
|---|---|---|
roles/cloudkms.admin |
Proporciona acceso a los recursos de Cloud KMS, excepto a los tipos de recursos y las operaciones criptográficas restringidos. | Responsable de criptografía |
roles/cloudkms.cryptoKeyEncrypterDecrypter |
Permite usar recursos de Cloud KMS solo para operaciones de encrypt y decrypt. |
Usuario del sistema de gestión de claves criptográficas |
roles/cloudkms.viewer |
Permiso para habilitar las operaciones get y list. |
Auditor de administrador |
Aplicar CMEK de forma coherente
En las siguientes secciones se describen controles adicionales para ayudar a mitigar riesgos, como el uso incoherente de claves o la eliminación o destrucción accidental.
Aplicar gravámenes de proyectos
Te recomendamos que protejas los proyectos con retenciones para evitar que se eliminen por error. Cuando se aplica una retención de proyecto, se impide que se elimine el proyecto de la clave de Cloud KMS hasta que se retire la retención.
Requerir claves CMEK
Te recomendamos que apliques el uso de CMEK en todo tu entorno mediante restricciones de políticas 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.
Requerir una duración mínima programada para la destrucción
Te recomendamos que definas una duración mínima para la programación de la destrucción. La destrucción de claves es una operación irreversible que puede provocar la pérdida de datos. De forma predeterminada, Cloud KMS usa una duración programada para la destrucción (a veces denominada periodo de eliminación no definitiva) de 30 días antes de que el material de las claves se destruya de forma irreversible. De esta forma, tendrás tiempo para restaurar una clave en caso de que se elimine por error. Sin embargo, es posible que un usuario con el rol Administrador de Cloud KMS cree una clave con una duración de programación de destrucción de tan solo 24 horas, lo que podría no ser suficiente para detectar un problema y restaurar la clave. La duración de la destrucción programada solo se puede definir durante la creación de la clave.
Mientras una clave esté programada para su eliminación, no se podrá usar para operaciones criptográficas y se producirá un error en cualquier solicitud para usarla. Durante este tiempo, monitoriza los registros de auditoría para comprobar que la clave no se está usando. Si quieres volver a usar la clave, debes restaurarla antes de que finalice el periodo programado para su destrucción.
Para asegurarte de que todas las claves creadas cumplan un periodo mínimo programado para la destrucción,
te recomendamos que configures la restricción de la política de organización
constraints/cloudkms.minimumDestroyScheduledDuration
con un mínimo de 30 días o con el periodo que prefieras. Esta política de organización impide que los usuarios creen claves con una duración programada para la destrucción inferior al valor especificado en la política.
Aplicar los niveles de protección permitidos para las CMEKs
Te recomendamos que apliques tus requisitos de niveles de protección de claves de forma coherente en todo tu entorno mediante restricciones de políticas de la organización.
Usa constraints/cloudkms.allowedProtectionLevels
para obligar a que las nuevas claves, versiones de claves y tareas de importación usen los niveles de protección que permitas.
Configurar controles de detección para CMEKs
Google Cloud proporciona varios controles de detección para CMEKs. En las siguientes secciones se explica cómo habilitar y usar estos controles en Cloud KMS.
Habilitar y agregar el registro de auditoría
Le recomendamos que agregue los registros de auditoría de actividad de administrador de Cloud KMS (junto con los registros de actividad de administrador de todos los servicios) en una ubicación centralizada para todos los recursos de su organización. De esta forma, un equipo de seguridad o un auditor pueden revisar toda la actividad relacionada con la creación o modificación de recursos de Cloud KMS a la vez. Para obtener información sobre cómo configurar sumideros de registros agregados, consulta el artículo sobre cómo agregar y almacenar los registros de tu organización.
De forma opcional, puedes habilitar los registros de acceso a datos para registrar las operaciones que usen las claves, incluidas las operaciones de cifrado y descifrado. Si usas CMEKs, se puede generar un volumen de registros considerable, lo que puede afectar a tus costes, ya que cada operación de cada servicio que use CMEKs creará registros de acceso a datos. Antes de habilitar los registros de acceso a datos, te recomendamos que definas un caso práctico claro para los registros adicionales y que evalúes cómo aumentarán tus costes de registro.
Monitorizar el uso de claves
Puedes consultar el uso de las claves con la API de inventario de Cloud KMS para identificar los recursos de tu organización que dependen de las claves de Cloud KMS y están protegidos por ellas. Google Cloud Este panel de control se puede usar para monitorizar el estado, el uso y la disponibilidad de tus versiones de clave y los recursos correspondientes que protegen. El panel de control también identifica los datos a los que no se puede acceder debido a que la clave está inhabilitada o destruida, de modo que pueda tomar medidas como purgar los datos inaccesibles o volver a habilitar la clave. Puedes usar Cloud Monitoring con Cloud KMS para configurar alertas de eventos críticos, como la programación de la destrucción de una clave. Cloud Monitoring te ofrece la oportunidad de clasificar por orden de prioridad por qué se ha llevado a cabo una operación de este tipo y de activar un proceso posterior opcional para restaurar la clave si es necesario.Te recomendamos que elabores un plan operativo para detectar automáticamente los eventos que consideres importantes y que revises periódicamente el panel de control de uso clave.
Habilitar Security Command Center para los resultados de vulnerabilidades de Cloud KMS
Security Command Center genera resultados de vulnerabilidades que destacan las configuraciones incorrectas asociadas a Cloud KMS y a otros recursos. Te recomendamos que habilites Security Command Center e integres estas detecciones en tus operaciones de seguridad. Entre estos resultados se incluyen problemas como claves de Cloud KMS accesibles públicamente, proyectos de Cloud KMS con el rol owner con demasiados permisos o roles de gestión de identidades y accesos que infringen la separación de funciones.
Evalúa tus requisitos de cumplimiento
Cada marco de cumplimiento tiene requisitos diferentes en cuanto al cifrado y la gestión de claves. Un marco de cumplimiento suele describir los principios y objetivos generales de la gestión de claves de cifrado, pero no especifica el producto o la configuración concretos que permiten cumplir los requisitos. Es tu responsabilidad conocer los requisitos de tu marco de cumplimiento y cómo tus controles, incluida la gestión de claves, pueden cumplir esos requisitos.
Para obtener información sobre cómo pueden ayudar los servicios de Google Cloud a cumplir los requisitos de diferentes marcos de cumplimiento, consulta los siguientes recursos:- Protección de datos sanitarios en Google Cloud
- Recursos sobre cumplimiento de Cloud y normativas
- Google Cloud Guía de implementación de FedRAMP
- Cumplimiento del estándar de seguridad de datos del PCI
Resumen de las prácticas recomendadas
En la siguiente tabla se resumen las prácticas recomendadas que se indican en este documento:
| Tema | Tarea |
|---|---|
| Decidir si usar claves de cifrado gestionadas por el cliente | Usa CMEK si necesitas alguna de las funciones que ofrece CMEK. |
| Elegir la creación de claves manual o automática | Usa Autokey de Cloud KMS si las características de las claves creadas por Autokey se ajustan a 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 Cloud que protegen las claves. |
| Llaveros de claves de Cloud KMS | Crea conjuntos de claves de Cloud KMS para cada ubicación en la que quieras proteger Google Cloud recursos. |
| Granularidad de las claves | Elige un patrón de granularidad de claves que se ajuste a tus necesidades o usa Autokey para aprovisionar claves automáticamente con la granularidad recomendada para cada servicio. |
| Nivel de protección | Elige Cloud EKM si el material de tu clave debe almacenarse fuera de Google Cloud. Elige Cloud HSM si el material de tus claves se puede alojar en módulos de seguridad de hardware (HSM) propiedad de Google Cloud. Elige claves de software si no necesitas Cloud HSM ni Cloud EKM. Consulta las directrices para seleccionar un nivel de protección. |
| Material de la clave | Para el material de clave alojado en Google Cloud, utilice el material de clave generado por Google Cloudsiempre que sea posible. Si usas material de clave importado, implementa la automatización y los procedimientos para mitigar los riesgos. |
| Propósito y algoritmo de la clave | Todas las claves CMEK deben usar el propósito de clave simétrica ENCRYPT_DECRYPT y el algoritmo GOOGLE_SYMMETRIC_ENCRYPTION. |
| Periodo de rotación | Usa la rotación automática de claves para asegurarte de que las claves se roten según la programación. Elige y aplica un periodo de rotación que se adapte a tus necesidades. Lo ideal es que sea al menos una vez al año. Usa una rotación de claves más frecuente para las cargas de trabajo sensibles. |
| Mínimos privilegios | Concede los roles predefinidos más limitados que permitan a tus principales completar sus tareas. No uses roles básicos. |
| Separación de tareas | Mantén permisos independientes para los administradores de claves y las entidades que usan claves. |
| Gravámenes de proyectos | Usa bloqueos de proyectos para evitar que se eliminen por error tus proyectos clave. |
| Requerir CMEKs | Usa la restricción constraints/gcp.restrictNonCmekServices. |
| Requerir una duración mínima programada para la destrucción | Usa la restricción constraints/cloudkms.minimumDestroyScheduledDuration. |
| Aplicar los niveles de protección permitidos para las CMEKs | Usa la restricción constraints/cloudkms.allowedProtectionLevels. |
| Habilitar y agregar el registro de auditoría | Agrega registros de auditoría de la actividad administrativa de todos los recursos de tu organización. Decide si quieres habilitar el registro de operaciones mediante claves. |
| Monitorizar el uso de claves | Usa la API de inventario de Cloud KMS o la Google Cloud consola para conocer el uso de las claves. También puedes usar Cloud Monitoring para definir alertas sobre operaciones sensibles, como programar la destrucción de una clave. |
| Habilitar Security Command Center para Cloud KMS | Revisa los resultados de las vulnerabilidades e integra la revisión de los resultados de las vulnerabilidades en tus operaciones de seguridad. |
| Evaluar los requisitos de cumplimiento | Revisa tu arquitectura de Cloud KMS y compárala con los requisitos de cumplimiento que debas cumplir. |
Siguientes pasos
- Consulta más información sobre cómo Autokey de Cloud KMS reduce el esfuerzo que tienes que hacer para usar CMEK de forma coherente.