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 Cloud de Confiance . 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.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 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 Cloud de Confiance.
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 Cloud de Confiance 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 Cloud de Confiancede 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 Cloud de Confiance?
¿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.
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 deCloud de Confiance 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.
Alinea la administración y el almacenamiento
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 llamado "fábrica de proyectos") para automatizar la creación de claves y la asignación de permisos.
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.
- 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 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.
- Las medidas 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 la aplicación de la separación de funciones puede requerir una configuración más cuidadosa.
- Los desarrolladores necesitan privilegios elevados de Cloud KMS en el proyecto de recursos para poder crear y administrar claves.
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) |
|
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:
|
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. |
Encriptador y desencriptador de CryptoKey de Cloud KMS
(roles/cloudkms.cryptoKeyEncrypterDecrypter) |
Encripta y desencripta datos con la clave. |
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 recursoKeyHandle. - 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.
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 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
Debes crear llaveros de claves de Cloud KMS en las ubicaciones en las que planeas implementar recursos de Cloud de Confiance encriptados con 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 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 Cloud de Confiance.
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.
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 Cloud de Confiance .
- 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.
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.
* Si necesitas que tu material de claves se almacene fuera de
Cloud de Confiance, usa claves de Cloud EKM. Te recomendamos el nivel de protección EXTERNAL_VPC para una mejor disponibilidad.
* Si no necesitas almacenar el material de las claves fuera de Cloud de Confiance, te recomendamos que uses 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.
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.
Configura controles de detección para las CMEK
Cloud de Confiance 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.
Resumen de prácticas recomendadas
En la siguiente tabla, se resumen las prácticas recomendadas de este documento.
| Tema | Tarea |
|---|---|
| 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 Cloud de Confianceque 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 Cloud de Confiance. |
| Nivel de detalle de las claves | Elige un patrón de nivel de detalle de claves que satisfaga tus necesidades de tolerancia al riesgo, los costos y la sobrecarga operativa. |
| Nivel de protección | Elige Cloud EKM si tu material de claves debe almacenarse fuera de Cloud de Confiance o si necesitas una certificación FIPS 140-2 de nivel 2 o 3. De lo contrario, elige las claves de software. Revisa la guía para seleccionar un nivel de protección. |
| Material de clave | Para el material de claves alojado en Cloud de Confiance, usa material de claves generado por Cloud de Confiancesiempre 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. |
| Evalúa los requisitos de cumplimiento | Revisa tu arquitectura de Cloud KMS y compárala con los requisitos de cumplimiento que debas satisfacer. |