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 Cloud de Confiance . Esta guía está dirigida a arquitectos de la nube y equipos de seguridad, y describe las prácticas recomendadas y las decisiones que debes tomar al diseñar tu 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.Decidir si usar CMEK
Te recomendamos que uses CMEK para cifrar los datos en reposo de los servicios de Cloud de Confiance 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 Cloud de Confiance.
Define una 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 problemas 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 a los datos a las claves de cifrado.
Cumplir la normativa actual o futura que requiera alguno de estos objetivos.
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 el coste, los gastos operativos y la facilidad de implementar funciones como el cifrado con destrucción de claves.
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 cree recursos cifrados con CMEK en el mismo proyecto en el que gestione 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 llaveros de claves de Cloud KMS para cada ubicación
Debes crear conjuntos de claves de Cloud KMS en las ubicaciones en las que desplieguesCloud de Confiance 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 globales deben usar un conjunto de claves y una CMEK en la ubicación
global.
La aplicación de 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.
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 una situación de recuperación ante desastres en la 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.
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 que se usan 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.
En general, recomendamos la siguiente estrategia de granularidad:
- Cada clave protege los recursos de una sola ubicación. Por ejemplo:
us-central1. - Cada clave protege los recursos de un solo servicio o producto, como BigQuery.
- Cada clave protege los recursos de un solo Cloud de Confiance proyecto.
Puede que esta recomendación no sea la estrategia de granularidad ideal para tu organización. En la mayoría de las organizaciones, esta estrategia ofrece un buen equilibrio entre la sobrecarga de mantener muchas claves muy granulares y los posibles riesgos de usar claves menos granulares que se comparten entre muchos proyectos, servicios o recursos.
Si quieres seguir una estrategia de granularidad diferente, ten en cuenta las siguientes ventajas e inconvenientes de los distintos 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. Una granularidad de clave más alta requiere un mayor número de versiones de clave activas, lo que conlleva costes adicionales.
- 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.
Claves de baja granularidad: por ejemplo, una clave para cada aplicación, región y entorno:
- 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 precaución 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. 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 se usan claves menos granulares, se necesitan menos versiones de claves, lo que conlleva un coste inferior.
- Sobrecarga operativa: puedes definir y preaprovisionar un número conocido de claves, con 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 utilices el S3NS cifrado predeterminado.
¿Necesita una certificación FIPS 140-2 de nivel 2 o 3, o que el material de la clave se almacene fuera de Cloud de Confiance?
- En ese caso, te recomendamos que uses CMEK con Cloud External Key Manager.
- Si no es así, te recomendamos que uses CMEK con claves respaldadas por software.
Usar material de clave generado por Cloud de Confiancesiempre 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 Cloud de Confiance. 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):
- ¿Puede 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 Cloud de Confiance?
- ¿Merece la pena importar el material de claves para reducir la sobrecarga operativa y el 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, la rotación de claves puede ser necesaria al menos una vez al año para cumplir determinados estándares, o puedes elegir 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.
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.
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 utilicen. 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 Cloud de Confiance servicios,
el rol de gestión de identidades y accesos para usar las claves de cifrado se asigna al agente de servicio del servicio Cloud de Confiance , 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.s3ns-system.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 claves de cifrado gestionadas por el cliente 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, no se puede eliminar el proyecto de claves 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, se dispone de un 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 eliminación programada de tan solo 24 horas, lo que podría no ser suficiente para que detectes un problema y restaures 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 una duración mínima programada 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 la duración 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
Cloud de Confiance proporciona varios controles de detección para CMEKs. En las siguientes secciones se explica cómo habilitar y usar estos controles relevantes para 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.
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 ni 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 ayudarte los servicios de Cloud de Confiance a cumplir los requisitos de diferentes marcos de cumplimiento, consulta el siguiente recurso: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 CMEK | Usa CMEK si necesitas alguna de las funciones que habilita CMEK. |
| 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 Confiance 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 Cloud de Confiance recursos. |
| Granularidad de las claves | Elige un patrón de granularidad de clave que se ajuste a tus necesidades de tolerancia al riesgo, coste y sobrecarga operativa. |
| Nivel de protección | Elige Cloud EKM si el material de tus 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 llaves de software. Consulta las directrices para seleccionar un nivel de protección. |
| Material de la clave | Para el material de clave alojado en Cloud de Confiance, utilice el material de clave generado por Cloud de Confiancesiempre 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 accesos | 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. |
| Evaluar los requisitos de cumplimiento | Revisa tu arquitectura de Cloud KMS y compárala con los requisitos de cumplimiento que debas cumplir. |