Análisis detallado de Cloud Key Management Service

Este contenido se actualizó por última vez en julio de 2023 y representa el statu quo en el momento de su redacción. Es posible que cambien las políticas y los sistemas de seguridad de Google, ya que mejoramos la protección de nuestros clientes de forma continua.

Google Cloud trabaja a partir de la idea fundamental de que los clientes son propietarios de sus datos y deben controlar cómo se usan.

Cuando almacenas datos con Google Cloud, estos se encriptan en reposo de forma predeterminada. Cuando usas la plataforma de Cloud Key Management Service (Cloud KMS), puedes obtener un mayor control sobre la forma en que tus datos se encriptan en reposo y cómo se administran las claves de encriptación.

En la siguiente tabla, se describen los diferentes tipos de claves de Google Cloud.

Tipo de clave	Administración de claves	Uso compartido de claves	Rotación automática	Precios
Clave de encriptación predeterminada	Solo Google administra estas claves.	Los datos de varios clientes pueden usar la misma clave de encriptación de claves (KEK).	Sí, consulta Encriptación en reposo predeterminada.	Gratis.
Claves de Cloud KMS	El cliente controla estas claves.	Es exclusivo de un cliente.	Sí, para la encriptación simétrica, no para las claves asimétricas. Consulta Rotación de claves.	Consulta los precios de Cloud Key Management Service.

Este documento se centra en el funcionamiento interno de la plataforma de Cloud KMS. Estas opciones te ayudan a proteger las claves y otros datos confidenciales que almacenas en Google Cloud. Este documento está destinado a los encargados de la toma de decisiones técnicas que necesitan detalles de la arquitectura, la infraestructura y las características de Cloud KMS. En este documento, se supone que tienes conocimientos básicos de conceptos de encriptación y arquitecturas de nube.

Aspectos fundamentales del diseño de Cloud KMS

En Cloud KMS, el objetivo de Google es proporcionar una solución escalable, confiable y eficaz, junto con una amplia variedad de opciones que puedes controlar. Cloud KMS se basa en los siguientes cinco pilares de diseño:

• Control de clientes: Cloud KMS te permite controlar tus propias claves de software y hardware para la encriptación y la firma. Este pilar incluye compatibilidad con claves adquiridas por el usuario (BYOK) y retención de claves (HYOK).
• Control y supervisión de acceso: Con Cloud KMS, puedes administrar permisos en claves individuales y supervisar cómo se usan las claves.
• Regionalidad: Cloud KMS proporciona la función de regionalización lista para usar. El servicio se configura para crear, almacenar y procesar claves solo en la región de Google Cloud que selecciones.
• Copias de seguridad: Cloud KMS analiza todo el material y los metadatos de las claves y crea copias de seguridad de estos de forma periódica para ayudar a proteger tus datos contra la corrupción y con el fin de verificar que los datos puedan desencriptarse de forma correcta.
• Seguridad: Cloud KMS ofrece protección sólida contra el acceso no autorizado a las claves y está completamente integrado en los controles de Identity and Access Management (IAM) y de Registros de auditoría de Cloud.

Fuentes y opciones de administración para los materiales clave

La plataforma de Cloud KMS te permite administrar claves criptográficas en un servicio central en la nube para su uso directo o la puedan usar otros recursos y aplicaciones de la nube.

En el siguiente diagrama, se muestra la cartera de claves de Google Cloud, organizada desde el material de clave controlado por Google hasta el material de clave controlado por el cliente.

Las opciones que se muestran en el diagrama anterior son las siguientes:

• Encriptación predeterminada: Todos los datos que Google almacena se encriptan en la capa de almacenamiento mediante el algoritmo del Estándar de encriptación avanzada (AES), AES-256. Generamos y administramos las claves para la encriptación predeterminada, y los clientes no tienen acceso a las claves ni al control de rotación y administración de claves. Es posible que las claves de encriptación predeterminadas se compartan entre los clientes. Para obtener más información, consulta Encriptación en reposo.

• Cloud KMS con claves generadas por software: mediante Cloud KMS, puedes controlar las claves que genera Google. El backend de software de Cloud KMS te brinda la flexibilidad necesaria para encriptar o firmar tus datos con una clave simétrica o asimétrica bajo tu control.

• Cloud KMS con claves generadas por hardware (Cloud HSM): Mediante el uso de Cloud KMS con el backend de Cloud HSM, puedes tener las claves que se generan y se almacenan en módulos de seguridad de hardware (HSM) administrados y propiedad de Google. Si necesitas una clave protegida por hardware, puedes usar el backend de Cloud HSM para asegurarte de que tus claves simétricas y asimétricas solo se usen en HSM validados en función del nivel 3 del estándar FIPS 140-2.

• Cloud KMS con importación de claves: Para satisfacer los requisitos de BYOK, puedes importar tus propias claves criptográficas que generas tú mismo. Puedes usar y administrar estas claves fuera de Google Cloud y usar el material de clave en Cloud KMS para encriptar o firmar datos que almacenas en Google Cloud.

• Cloud KMS con administrador de claves externo (Cloud EKM): Para satisfacer los requisitos de HYOK, puedes crear y controlar las claves que se almacenan en un administrador de claves externo a Google Cloud. Luego, configuras la plataforma de Cloud KMS para usar las claves externas a fin de proteger los datos en reposo. Puedes usar estas claves de encriptación con una clave de Cloud EKM. Para obtener más información sobre la administración de claves externas y Cloud EKM, consulta Arquitecturas de referencia para una implementación confiable de los servicios de Cloud EKM.

Puedes optar por usar claves generadas por Cloud KMS con otros servicios de Google Cloud. Estas claves se conocen como claves de encriptación administradas por el cliente (CMEK). La función de CMEK te permite generar, usar, rotar y destruir claves de encriptación que ayudan a proteger datos en otros servicios de Google Cloud.

Administración de claves y conceptos de encriptación en Google

En esta sección, se definen algunos términos para la administración de claves en el contexto de la infraestructura de administración de claves de varias capas de Google.

Llaveros de claves, claves y versiones de claves

En el siguiente diagrama, se ilustran las agrupaciones de claves y se muestran las claves y los llaveros de claves con una sola versión principal y varias versiones anteriores.

Los conceptos clave que se muestran en el diagrama anterior son los siguientes:

• Clave: es un objeto con nombre que representa una clave criptográfica que se usa para un propósito específico. El material de la clave (los bits que se usan para las operaciones criptográficas) puede cambiar a lo largo del tiempo, a medida que creas versiones nuevas de la clave. Puedes asignar políticas de permisos de IAM a nivel de clave en la jerarquía de recursos.

  El propósito y otros atributos de la clave están conectados con esta, y se administran mediante el uso de la clave. Por este motivo, la clave es el objeto más importante para comprender el uso de KMS.

  Cloud KMS admite claves asimétricas y simétricas. Una clave simétrica se usa para crear o validar firmas MAC o para la encriptación simétrica a fin de proteger corpus de datos. Por ejemplo, puedes usar AES-256 en modo GCM para encriptar un bloque de texto simple. Por su parte, una clave asimétrica se puede usar para realizar encriptación asimétrica o firma asimétrica. Para obtener más información, consulta Algoritmos y propósitos compatibles.

• Llavero de claves: es una agrupación de claves con fines organizativos. Un llavero de claves pertenece a un proyecto de Google Cloud y reside en una ubicación específica. Las claves heredan las políticas de permisos de su llavero de claves. Si agrupas claves con permisos relacionados en un llavero de claves, puedes otorgar, revocar o modificar los permisos de esas claves a nivel del llavero de claves, sin necesidad de hacerlo en cada una de forma individual. Los llaveros de claves son más cómodos y permiten la categorización, pero si la agrupación de llaveros de claves no te resulta útil, puedes administrar los permisos directamente en las claves. Las etiquetas te permiten denegar o permitir condicionalmente políticas en función de si un recurso tiene una etiqueta específica. Puedes aplicar etiquetas a nivel de llavero de claves en la jerarquía de recursos.

  Para evitar los conflictos con los nombres de recursos, no puedes borrar un llavero de claves ni una clave. Las claves y los llaveros de claves no tienen costos facturables ni limitaciones de cuota, por lo que su existencia continua no afecta los límites de costo ni de producción.

• Metadatos de la clave: son nombres de recursos, propiedades de recursos de KMS, como las políticas de permiso, el tipo, el tamaño y el estado de la clave, y cualquier dato derivado de claves y llaveros de claves.

• Versión de la clave: El material de la clave asociado con una clave en un momento determinado. La versión de la clave es el recurso que contiene el material de la clave real. A las versiones se les asigna un número de manera secuencial, a partir de la versión 1. Cuando se rota una clave, se crea una versión nueva con nuevo material de la clave. La misma clave lógica puede tener varias versiones a lo largo del tiempo, lo que significa que los datos se encriptan con diferentes versiones de clave. Las claves simétricas tienen una versión principal. Según la configuración predeterminada, se usa la versión principal para la encriptación. Cuando Cloud KMS realiza la desencriptación con claves simétricas, identifica de forma automática qué versión de la clave se necesita para llevar a cabo la desencriptación.

Jerarquía de claves de software

En el siguiente diagrama, se ilustra la jerarquía de claves para Cloud KMS y el almacén de claves interno de Google. Cloud KMS usa Keystore, que es el servicio de administración de claves interno de Google, para unir las claves encriptadas de Cloud KMS. La unión de claves es el proceso de usar una clave para encriptar otra con el propósito de almacenarla de forma segura o transmitirla por medio de un canal no confiable. Cloud KMS usa la misma raíz de confianza que el almacén de claves.

La jerarquía de claves que se muestra en el diagrama anterior es la siguiente:

1. Una clave de encriptación de datos (DEK) encripta los fragmentos de datos.
2. Una clave de encriptación de claves (KEK) se usa para encriptar o unir la DEK. Todas las opciones de la plataforma de Cloud KMS (el software, el hardware y los backends externos) te permiten controlar la KEK. Las KEK se almacenan en Cloud KMS.
3. Una clave maestra de KMS encripta la KEK. La clave maestra de KMS se almacena en el almacén de claves. Hay una clave maestra de KMS independiente en el almacén de claves para cada ubicación de Cloud KMS. Las KEK en Cloud KMS están protegidas por la clave maestra de KMS de la ubicación. Cada servidor de Cloud KMS recupera una copia de la clave maestra durante el inicio como una dependencia excesiva, y, todos los días, se recupera una copia nueva de la clave maestra. La clave maestra de KMS se vuelve a encriptar de forma periódica.
4. La clave maestra de KMS está protegida por la clave maestra de almacén de claves en el almacén de claves.
5. La clave maestra del almacén de claves raíz está protegida por la clave maestra del almacén de claves raíz.

Para obtener más información sobre el almacén de claves, consulta Administración de claves en el documento de encriptación en reposo.

Restricciones operativas clave

Cloud KMS funciona con las siguientes restricciones:

• Proyecto: los recursos de Cloud KMS pertenecen a un proyecto de Google Cloud, como todos los otros recursos de Google Cloud. Puedes alojar datos en un proyecto que no sea aquel en el que se encuentran tus claves de Cloud KMS. Para respaldar la práctica recomendada de separación de obligaciones entre los administradores de claves y los administradores de datos, puedes quitar el rol de propietario del proyecto de clave.
• Ubicaciones: dentro de un proyecto, los recursos de Cloud KMS se crean en una ubicación. Consulta Geografía y regiones para obtener más información sobre las ubicaciones.
• Coherencia: Cloud KMS propaga operaciones en claves, llaveros de claves y versiones de claves mediante la coherencia sólida o la coherencia eventual. Para obtener más información, consulta Coherencia de recursos de Cloud KMS.

Descripción general de la plataforma de Cloud KMS

La plataforma de Cloud KMS admite varios algoritmos criptográficos y proporciona métodos para encriptar y firmar digitalmente mediante claves respaldadas por hardware y por software. La plataforma de Cloud KMS está integrada en Identity and Access Management (IAM) y en Registros de auditoría de Cloud, de modo que puedas administrar los permisos en las claves individuales y controlar su uso.

En el diagrama anterior, se muestran los componentes principales de la plataforma de Cloud KMS.

• Los administradores acceden a los servicios de administración de claves mediante la consola de Cloud o Google Cloud CLI.

• Las aplicaciones acceden a los servicios de administración de claves mediante la implementación de la API de REST, gRPC o las bibliotecas cliente. Las aplicaciones pueden usar los servicios de Google que están habilitados para usar CMEK. Las CMEK usan la API de Cloud Key Management Service. Si tu aplicación usa PKCS #11, puedes integrarla en Cloud KMS con la biblioteca para PKCS #11.

• La API de Cloud KMS te permite usar software, hardware o claves externas. Las claves basadas en software y las basadas en hardware usan las protecciones de copias de seguridad redundantes de Google.

• Si usas claves de hardware, los HSM certificados con el Nivel 3 del estándar FIPS 140-2 en Google Cloud almacenan las claves. Para obtener más información sobre nuestra certificación, consulta Certificado 4399.

• Cloud KMS usa el almacén de datos interno de Google para almacenar el material de las claves de clientes encriptado. Este almacén de datos cuenta con alta disponibilidad y admite muchos de los sistemas esenciales de Google. Consulta Protección de Datastore.

• En intervalos periódicos, el sistema de copias de seguridad independiente crea una copia de seguridad de todo el almacén de datos en el almacenamiento en línea y de archivo. Esta copia de seguridad permite que Cloud KMS logre sus objetivos de durabilidad. Consulta Protección de Datastore.

Validación con FIPS 140-2

Las operaciones criptográficas de Cloud KMS son realizadas por módulos validados en función del estándar FIPS 140-2. Las claves con nivel de protección SOFTWARE (y las operaciones criptográficas realizadas con ellas) cumplen con el nivel 1 del estándar FIPS 140-2. Estas operaciones de criptografía usan BoringCrypto, que es una biblioteca criptográfica de código abierto mantenida por Google. Las claves con nivel de protección HSM (y las operaciones criptográficas realizadas con ellas) cumplen con el nivel 3 del estándar FIPS 140-2.

Dependencias de infraestructura de Google

Los elementos de la plataforma de Cloud KMS se ejecutan como trabajos de Borg de producción. Borg es el administrador de clústeres a gran escala de Google para controlar los trabajos por lotes y los trabajos de entrega de API.

Para obtener información sobre la seguridad de nuestra infraestructura física y de producción, consulta la descripción general del diseño de seguridad de la infraestructura de Google.

Trabajos de entrega de API de Cloud KMS

Los trabajos de entrega de API de Cloud KMS son trabajos de Borg de producción que entregan las solicitudes de los clientes para administrar y usar sus claves. Los trabajos de entrega de API de Cloud KMS también procesan acciones diferidas a partir de solicitudes de clientes, como rotar claves según una programación, crear claves asimétricas y, luego, importar claves. Estos trabajos de entrega se ejecutan en todas las regiones de Google Cloud en las que Cloud KMS está disponible. Cada trabajo está asociado con una sola región y está configurado para acceder solo a los datos de sistemas cuya ubicación geográfica está dentro de la región de Google Cloud asociada.

Trabajos por lotes de Cloud KMS

La plataforma de Cloud KMS también mantiene cierta cantidad de trabajos por lotes que se ejecutan como trabajos de Borg de producción en varios programas. Los trabajos por lotes son específicos de la región y solo agregan datos de la región de Google Cloud asociada y se ejecutan dentro de esta. Entre las tareas que realizan estos trabajos, se incluyen las siguientes:

• Contar las claves activas para la facturación del cliente.
• Agregar recursos desde la API de búfer de protocolo público para Cloud KMS y reenviar los metadatos a Cloud Asset Inventory. En este contexto, los recursos son cualquier recurso que administre Cloud KMS, como claves y llaveros de claves.
• Agrupar todos los recursos y la información de informes para las estadísticas empresariales.
• Capturar instantáneas de los datos para alta disponibilidad.
• Verificar que los datos almacenados en el almacén de datos subyacente no estén dañados.
• Volver a encriptar el material de la clave de cliente cuando se rota la clave maestra de KMS.

Generador de instantáneas de la clave de Cloud KMS

A fin de mantener la alta disponibilidad, la plataforma de Cloud KMS mantiene un almacén de datos redundante en cada instancia del servicio compartido en el que se alojan las tareas del servidor de la API de Cloud KMS. Cada servicio implementa su propia instancia del servicio de generador de instantáneas. Gracias a esta redundancia, los servicios son muy independientes, de modo que una falla en una zona tiene un efecto limitado en otras zonas. Cuando el trabajo de la API de Cloud KMS necesita realizar una operación criptográfica, consulta el almacén de datos principal junto con los trabajos del generador de instantáneas local, en simultáneo. Si el almacén de datos principal es lento o no está disponible, la respuesta puede entregarse desde una instantánea, si la instantánea no tiene más de dos horas de antigüedad. Las instantáneas se crean como resultado de un trabajo por lotes que se ejecuta de forma continua para cada región. Se ubican en la región de la nube asociada con el material de la clave.

Comunicaciones entre el cliente y el servidor

Google usa la seguridad de transporte de la capa de la aplicación (ALTS) para ayudar a proporcionar seguridad a las comunicaciones cliente-servidor que usan el mecanismo de llamada de procedimiento remoto (RPC) de Google.

Para obtener más información, consulta Autenticación, integridad y encriptación entre servicios.

Arquitectura de la plataforma de Cloud KMS

En esta sección, se describen los detalles arquitectónicos de la seguridad de los materiales de claves y la protección del almacén de datos.

Seguridad de los materiales de las claves

En Cloud KMS, el material de las claves siempre está encriptado en reposo y en tránsito. Solo se desencripta en los siguientes casos:

• Cuando el cliente lo usa
• Cuando la clave interna de Google que se usa para proteger el material de las claves de cliente se rota o se verifica su integridad.

Las solicitudes de los clientes a Cloud KMS se encriptan en tránsito mediante el uso de TLS entre el cliente y Google Front End (GFE).

La autenticación ocurre entre todos los trabajos de Cloud KMS, tanto dentro de los centros de datos de Google como entre ellos.

La política de Google consiste en garantizar que los trabajos usen solo código fuente que se haya compilado, probado y revisado de manera verificable. La autorización binaria para Borg (BAB) aplica esta política a nivel operativo.

Los trabajos de la API de Cloud KMS pueden acceder a los metadatos de una clave (por ejemplo, la política de IAM o el período de rotación). Un empleado de Google que tenga una justificación empresarial válida y documentada (como un error o un problema de un cliente) también puede acceder a los metadatos de una clave. Estos eventos de acceso se registran de forma interna, y los registros correspondientes a los datos cubiertos por la Transparencia de acceso también están disponibles para los clientes calificados.

El material de clave desencriptado no se puede exportar ni ver a través de la interfaz de la API ni de ninguna otra interfaz de usuario. Ningún empleado de Google tiene acceso al material de clave del cliente no encriptado. Además, el material de clave se encripta con una clave maestra en Keystore, a la que ningún individuo puede acceder directamente. En un HSM, los trabajos de la API de Cloud KMS nunca acceden a un material de clave en un estado desencriptado.

Protección del almacén de datos

El almacén de datos para Cloud KMS tiene alta disponibilidad, es durable y está protegido.

Disponibilidad. Cloud KMS usa el almacén de datos interno de Google, que tiene alta disponibilidad y admite varios sistemas cruciales de Google.

Durabilidad. Cloud KMS usa la encriptación autenticada para almacenar el material de las claves de clientes en el almacén de datos. Además, todos los metadatos se autentican mediante un código de autenticación de mensajes basado en hash (HMAC) para garantizar que no se hayan alterado ni dañado en reposo. Cada una hora, un trabajo por lotes analiza todo el material y los metadatos de las claves, y verifica que los HMAC sean válidos y que el material de las claves se pueda desencriptar de forma correcta. Si hay datos dañados, se alerta de inmediato a los ingenieros de Cloud KMS para que puedan tomar medidas.

Cloud KMS usa varios tipos de copias de seguridad para su almacén de datos:

• De forma predeterminada, el almacén de datos mantiene un historial de cambios de cada fila durante cuatro días. En el caso de una emergencia, este ciclo de vida se puede extender a fin de proporcionar más tiempo para solucionar problemas.
• Cada una hora, el almacén de datos registra una instantánea. La instantánea se puede validar y usar para realizar un restablecimiento, si es necesario. Estas instantáneas se conservan durante cuatro días.
• Todos los días, se crea una copia de seguridad completa en el disco y en el almacenamiento de archivo.

El equipo de Cloud KMS cuenta con procedimientos documentados para restablecer copias de seguridad a fin de mitigar la pérdida de datos cuando se produce una emergencia del servicio.

Copias de seguridad Las copias de seguridad del almacén de datos de Cloud KMS residen en su región de Google Cloud asociada. Todas estas copias de seguridad se encriptan en reposo. El acceso a los datos en las copias de seguridad está restringido en función de las justificaciones de acceso (como un número de ticket que presentaste a la Atención al cliente de Google), y los accesos humanos se registran en los registros de Transparencia de acceso.

Protección. En la capa de la aplicación de Cloud KMS, el material de las claves de clientes se encripta antes de su almacenamiento. Los ingenieros con acceso al almacén de datos no tienen acceso al material de las claves de clientes en formato de texto simple. Además, el almacén de datos encripta todos los datos que administra antes de escribir en el almacenamiento permanente. Por lo tanto, el acceso a las capas de almacenamiento subyacentes, incluidos los discos o el almacenamiento de archivos, no permite el acceso a los datos encriptados de Cloud KMS sin acceso a las claves de encriptación del almacén de datos, que se almacenan en el almacén de claves.

Política de rotación. La rotación de claves forma parte de las prácticas recomendadas que se aceptan de forma general para el control del material de las claves. Existe una política de rotación para las claves, que se usa a fin de proteger los almacenes de datos de Cloud KMS. También se aplica una política de rotación a las claves maestras del almacén de claves que unen las claves maestras de Cloud KMS. La clave maestra de Keystone tiene programadas una antigüedad máxima para el texto cifrado de 90 días y una antigüedad máxima de clave de cliente almacenada en caché de un día. Cloud KMS actualiza la claves maestras de KMS en las tareas de KMS cada 24 horas y vuelve a encriptar todas las claves de los clientes todos los meses.

Residencia de los datos. Los datos subyacentes de cada almacén de datos de Cloud KMS permanecen de forma exclusiva dentro de la región de Google Cloud a la que están asociados los datos. Esto también se aplica a las ubicaciones multirregionales, como la multirregión us.

Disponibilidad de una clave después de su creación

Cloud KMS permite que una clave se use inmediatamente después de que el almacén de datos de Cloud KMS confirma la transacción que crea la clave, y luego de que la capa de almacenamiento reconoce su creación.

Backend de clave

Cuando creas una clave con Cloud KMS, puedes elegir un nivel de protección para determinar qué backend de clave crea la clave y realiza todas las operaciones criptográficas futuras en esa clave. Los backends se exponen en la API de Cloud KMS como los siguientes niveles de protección:

• SOFTWARE: Se aplica a las claves que pueden separarse por medio de un módulo de seguridad de software para realizar operaciones criptográficas.
• HSM: Se aplica a las claves que solo pueden separarse por medio de HSM que realizan todas las operaciones criptográficas con las claves.
• EXTERNAL o EXTERNAL-VPC: Se aplican al administrador de claves externas (EKM). EXTERNAL-VPC te permite conectar el EKM a Google Cloud a través de una red de VPC.

Backend de software de Cloud KMS: Nivel de protección SOFTWARE

El nivel de protección SOFTWARE se aplica a las claves cuyas operaciones criptográficas se realizan en software. En esta sección, se describen los detalles de la manera en la que se implementa este nivel.

Implementaciones algorítmicas

Para las claves de software, Cloud KMS usa el módulo BoringCrypto (BCM) dentro de la implementación de BoringSSL de Google para todo el trabajo criptográfico relacionado. El BCM está validado en función del estándar FIPS 140-2. El objeto binario de Cloud KMS está compilado a partir de los algoritmos criptográficos primitivos de este módulo validados en función del nivel 1 del estándar FIPS 140-2. Los algoritmos más actuales que abarca este módulo se enumeran en Algoritmos y propósitos de KMS. Entre ellos, se incluyen las operaciones de encriptación, desencriptación y firmado con claves simétricas AES256-GCM y claves asimétricas RSA 2048, RSA 3072, RSA 4096, EC P256 y EC P384.

Entropía y generación de números aleatorios

Cuando se generan claves de encriptación, Cloud KMS usa BoringSSL. El estándar FIPS 140-2 requiere que se usen sus propios generadores de números pseudoaleatorios (PRNG, también conocidos como DRBG). En BoringCrypto, Cloud KMS usa de forma exclusiva CTR-DRBG con AES-256. Esto proporciona un resultado para RAND_bytes, la interfaz principal mediante la cual el resto del sistema obtiene datos aleatorios. Este PRNG se origina en el generador de números aleatorios (RNG) del kernel de Linux, que, a su vez, se origina en varias fuentes entrópicas independientes. Este origen incluye eventos entrópicos del entorno del centro de datos, como mediciones detalladas de las búsquedas en discos y horas de llegada entre paquetes, y la instrucción RDRAND de Intel cuando está disponible. Si deseas obtener más información sobre el comportamiento del generador de números aleatorios para BoringSSL (modo de cumplimiento con el estándar FIPS), consulta Diseño de RNG.

Backend de Cloud HSM: nivel de protección de HARDWARE

Cloud HSM proporciona claves respaldadas por hardware a Cloud KMS. Te permite usar claves criptográficas que están protegidas por HSM certificados con el nivel 3 del estándar FIPS 140-2 en el centro de datos de Google. Cloud HSM tiene alta disponibilidad y proporciona escalamiento elástico, al igual que Cloud KMS. No se requieren cambios en las aplicaciones de clientes existentes de Cloud KMS, ya que pueden acceder al backend de Cloud HSM con la misma API y las mismas bibliotecas cliente que usa Cloud KMS. Para obtener más información sobre el backend de Cloud HSM, consulta Arquitectura de Cloud HSM.

Cloud EKM: Nivel de protección EXTERNO

Cloud EKM te permite encriptar datos mediante claves de encriptación fuera de la nube que permanecen en tu control.

Las claves con los niveles de protección EXTERNAL y EXTERNAL_VPC se almacenan y administran en un sistema de administración de claves externo. Para obtener más información, consulta Arquitecturas de referencia para una implementación confiable de los servicios de Cloud EKM.

Importación de claves

Es posible que desees importar las claves propias que creaste de forma local o en un EKM a tu entorno de nube. Por ejemplo, puede que tengas un requisito normativo que indique que las claves que usas para encriptar los datos de la nube deben generarse de una forma en particular o en un entorno específico. La importación de claves te permite importar estas claves y cumplir con tus obligaciones normativas. Para extender tus capacidades de firma a la nube, también puedes importar claves asimétricas.

Como parte de la importación de claves, Cloud KMS genera una clave de unión pública, que es un par de clave pública/privada, mediante uno de los métodos de importación admitidos. Si encriptas el material de tus claves con esta clave de unión, se protege el material en tránsito.

Usa la clave de unión pública para encriptar la clave que se importará en el cliente. La clave privada que coincide con la clave pública se almacena dentro de Google Cloud y se usa para separar la clave pública una vez que llega al proyecto de Google Cloud. El método de importación que elijas determinará el algoritmo que se usará para crear la clave de unión. Cuando el material de tu clave esté unido, podrás importarlo a una clave o versión de clave nueva en Cloud KMS.

Puedes usar claves importadas con el nivel de protección HSM o SOFTWARE. Para Cloud HSM, la parte de clave privada de la clave de unión está disponible solo dentro de Cloud HSM. Esta restricción impide que Google una el material de tu clave fuera de Cloud HSM.

Claves de encriptación administradas por el cliente (CMEK)

De forma predeterminada, Google Cloud encripta todos los datos de clientes almacenados en reposo, y Google administra las claves que se usan para la encriptación. En el caso de algunos productos de Google Cloud, los clientes pueden usar Cloud KMS en su lugar a fin de administrar las claves que se usan para la encriptación. Las CMEK se pueden usar para las claves respaldadas por software, hardware o externos. Cloud KMS te permite controlar muchos aspectos de las claves (como su creación, habilitación, inhabilitación, rotación y destrucción), así como administrar los permisos de IAM adecuados en ellas. Para aplicar una separación de obligaciones recomendada, Cloud KMS incluye varios roles de IAM predefinidos que tienen privilegios y limitaciones específicos y se pueden otorgar a usuarios y cuentas de servicio específicos.

La rotación de la clave de Cloud KMS no vuelve a encriptar los datos en el servicio de CMEK asociado. En cambio, los recursos recién creados se encriptan con la versión de clave nueva, lo que significa que las diferentes versiones de una clave protegen diferentes subconjuntos de datos. Por ejemplo, BigQuery no rota la clave de encriptación de una tabla de forma automática cuando se rota una clave de Cloud KMS asociada a la tabla. Las tablas de BigQuery existentes continúan usando la versión de la clave con la que se crearon. Las tablas de BigQuery nuevas usan la versión actual de la clave. Para obtener más información, consulta la documentación de cada producto.

Las políticas de la organización de CMEK proporcionan un mayor control sobre el uso de CMEK en los proyectos. Estas políticas te permiten controlar los servicios y los proyectos que contienen claves permitidas para CMEK.

Google Cloud admite las CMEK en varios servicios, incluidos Cloud Storage, BigQuery y Compute Engine. Consulta Integraciones de CMEK para obtener la lista completa de integraciones de CMEK y servicios compatibles con CMEK. Google continúa invirtiendo en la integración de CMEK para otros productos de Google Cloud.

Ciclo de vida de una solicitud de Cloud KMS

En esta sección, se describe el ciclo de vida de una solicitud de Cloud KMS, incluido un análisis sobre la destrucción del material de clave. En el siguiente diagrama, se muestra un cliente que solicita acceso a las instancias de servicio de Cloud KMS en us-east1 y us-west1, y cómo se enrutan las solicitudes mediante Google Front End (GFE).

Estos son los pasos que se incluyen en el ciclo de vida:

1. Un cliente o un trabajo que se ejecuta en nombre de un cliente crea una solicitud al servicio de Cloud KMS, https://cloudkms.googleapis.com. El DNS resuelve esta dirección en una dirección IP anycast del GFE.
2. El GFE proporciona hosting de IP pública de su nombre de DNS público, protección contra la denegación del servicio (DoS) y finalización de TLS. Cuando el cliente envía su solicitud, esta se suele enrutar a un GFE cerca del cliente, sin importar la ubicación que la solicitud del cliente tenga como destino. Los GFE controlan la negociación de TLS y, mediante la URL y los parámetros de la solicitud, determinan qué balanceador de cargas de software global (GSLB) enrutará la solicitud.
3. Hay un objetivo de GSLB distinto para cada región de Cloud KMS. Si la solicitud llega a Google en us-east1 y está dirigida a us-west1, se enruta entre los centros de datos de us-east1 y us-west1. Toda la comunicación entre los centros de datos se encripta en tránsito mediante la ALTS, que autentica de forma mutua los trabajos de Cloud KMS y GFE.
4. Cuando la solicitud llega al trabajo de Cloud KMS, primero la procesa un framework que controla gran parte del trabajo común a todos los servicios de Google Cloud. Este framework autentica al usuario y realiza una serie de verificaciones para comprobar que se cumplen estos aspectos:
   • El cliente tiene una credencial válida y se puede autenticar.
   • El proyecto tiene la API de Cloud KMS habilitada y una cuenta de facturación válida.
   • La cuota es suficiente para ejecutar la solicitud.
   • El cliente está en la lista de anunciantes permitidos para usar la región de Google Cloud relevante.
   • Los Controles del servicio de VPC no rechazan la solicitud.
5. Si todos estos aspectos se cumplen, el framework reenvía la solicitud y la credencial a Cloud KMS. Cloud KMS analiza la solicitud para determinar a qué recursos se está accediendo y, luego, verifica con la IAM a fin de detectar si el emisor está autorizado para hacer la solicitud. IAM también le indica a Cloud KMS si el caso de la solicitud debe escribirse en los registros de auditoría.
6. Una vez que la solicitud se autentica y autoriza, Cloud KMS llama a sus backends del almacén de datos dentro de la región para recuperar el recurso solicitado. Una vez que se recupera el recurso, se desencripta el material de la clave de cliente para su uso.
7. Con el material de la clave, Cloud KMS realiza la operación criptográfica, y reenvía la versión unida de la clave al backend de software de Cloud KMS, al backend de Cloud HSM o al backend de Cloud EKM, según el nivel de protección de la clave.
8. Luego de que se completa la operación criptográfica, la respuesta se envía al cliente en el mismo tipo de canal de GFE a KMS en el que se envió la solicitud.
9. A la vez que se muestra la respuesta, Cloud KMS activa algunos eventos de forma asíncrona:
   • Los registros de auditoría y de solicitudes se completan y se ponen en cola para escribirse.
   • Los informes se envían para fines de administración de la facturación y la cuota.
   • Si la solicitud actualizó los metadatos de un recurso, el cambio se envía a Cloud Asset Inventory a través de actualizaciones de trabajos por lotes.

Integridad de los datos de extremo a extremo

Cloud KMS te permite calcular sumas de verificación para claves y materiales de claves a fin de garantizar que no estén dañados. Estas sumas de verificación te ayudan a protegerte de la pérdida de datos que puede deberse a la corrupción de hardware o al software. Las bibliotecas auxiliares le permiten verificar la integridad de las claves. Puedes usar las bibliotecas auxiliares para verificar la integridad de la clave si proporcionas sumas de verificación a Cloud KMS, que el servidor verifica. Además, estas bibliotecas te permiten recibir sumas de verificación para verificar los datos de respuesta del cliente.

La integridad de los datos de extremo a extremo ayuda a proteger tu entorno de amenazas como las siguientes:

• Corrupción durante el tránsito; por ejemplo, en la pila entre el momento en que se envían los datos y el momento en que se protegen con TLS.
• Problemas en los proxies intermedios entre tu extremo y el KMS (por ejemplo, para solicitudes entrantes).
• Operaciones criptográficas con errores, daños en la memoria de la máquina o daños del HSM en la arquitectura de Cloud KMS.
• Corrupción durante la comunicación con un EKM externo.

Para obtener más información, consulta Verifica la integridad de los datos de extremo a extremo.

Destrucción del material de una clave

Se considera que el material de una clave son datos del cliente, por lo que el método que se describe en Eliminación de datos en Google Cloud también se aplica a Cloud KMS. El material de clave se destruye a pedido, cuando se completa el período Programado para su destrucción y las copias de seguridad vencen. El material de clave que aún está presente en las copias de seguridad (después de que finalice el período de destrucción) solo se puede usar para la recuperación ante desastres regional, y no para el restablecimiento de claves individuales. Este proceso no se garantiza para las copias de claves importadas que existen fuera del control de Cloud KMS.

De forma predeterminada, las claves en Cloud KMS pasan 24 horas en estado Programado para su destrucción (Borrar de forma no definitiva) antes de que el material de la clave se borre de forma lógica del sistema. Puedes cambiar esta duración. Para obtener más información, consulta Duración variable del estado Programado para su destrucción.

Aunque el material de la clave se destruye, las claves y los llaveros de claves no se pueden borrar. Las versiones de claves tampoco se pueden borrar, pero el material de las versiones de claves se puede destruir a fin de que los recursos no puedan volver a usarse. Las claves y los llaveros de claves no tienen costos facturables ni limitaciones de cuota, por lo que su existencia continua no afecta los límites de costo ni de producción.

Cuando se programa la destrucción de una versión de clave, no está disponible para las operaciones criptográficas. Dentro del período de eliminación pendiente, puedes restablecer la versión de clave para que no se destruya.

Si borras una clave importada por error, puedes volver a importarla. Para obtener más información, consulta Vuelve a importar una clave destruida.

Para evitar borrar una clave por accidente, ten en cuenta las siguientes recomendaciones:

• Crea un rol de KMS personalizado que no incluya el permiso cloudkms.cryptoKeyVersions.destroy.
• Cambiar el campo destroy_scheduled_duration a un período más largo.

• Supervisa y agrega alertas para eventos de destrucción de claves. Por ejemplo, crea el siguiente filtro de Cloud Logging:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Crea procesos que inhabiliten la clave durante un par de días antes de que se borre.

Entorno operativo de la plataforma de Cloud KMS

Dentro del entorno operativo de la plataforma de Cloud KMS, se incluyen políticas de seguridad y almacenamiento de datos, restricciones de acceso y estrategias de mitigación de riesgos que se diseñaron para optimizar la confiabilidad, la durabilidad y la disponibilidad, a la vez que se protege el material de las claves. En esta sección, se analizan la estructura operativa, las responsabilidades de los miembros del equipo de operaciones, los mecanismos de autenticación y los protocolos de auditoría y registro del servicio. Esta sección se aplica a las capacidades de claves respaldadas por software y por hardware.

Ingenieros de software, ingenieros de confiabilidad de sitios y operadores de sistemas

Los ingenieros de software son responsables de asociarse con otras partes interesadas, como los administradores de productos y los ingenieros de confiabilidad de sitios (SRE), con el fin de diseñar el sistema y escribir la mayor parte del código y las pruebas para el servicio de Cloud KMS. El código incluye el trabajo principal que entrega las solicitudes del cliente, además de trabajos secundarios para actividades como la replicación de datos y la facturación. También es posible que los SRE escriban código. Sin embargo, las obligaciones de los ingenieros de software y de los SRE están separadas. La responsabilidad principal de los SRE es mantener el entorno de producción para los trabajos de Cloud KMS. Los SRE miden y alcanzan la confiabilidad mediante trabajo de ingeniería y operaciones.

Los operadores de sistemas son responsables del proceso de compilación y lanzamiento, la supervisión, las alertas y la planificación de la capacidad de Cloud KMS. Son el personal de primera línea para los problemas de los clientes y las interrupciones en Cloud KMS. Por ejemplo, los operadores de sistemas usan herramientas y automatización para minimizar el trabajo de los sistemas manuales, de modo que puedan concentrarse en las actividades que generan valor a largo plazo.

Las obligaciones para los operadores de sistemas se definen en procedimientos operativos estándar. Los operadores de sistemas no acceden al material de las claves de cliente mientras realizan sus tareas.

Regiones de los recursos de Cloud KMS

Para cumplir con cualquier requisito de residencia clave, puedes crear recursos de Cloud KMS en uno de los cuatro tipos de ubicaciones de Google Cloud:

• Una ubicación de región consta de zonas en un lugar geográfico específico, como Iowa.
• Una ubicación birregional consiste en zonas de dos lugares geográficos específicos, como Iowa y Carolina del Sur.
• Una ubicación multirregional consiste en zonas distribuidas en un área geográfica general, como los Estados Unidos.
• La ubicación global consiste en zonas de todo el mundo. Cuando creas tus recursos de Cloud KMS en la ubicación global, están disponibles desde zonas de todo el mundo.

Las ubicaciones representan las regiones geográficas en las que se controlan las solicitudes a Cloud KMS relacionadas con un recurso determinado y en las que se almacenan las claves criptográficas correspondientes.

Para obtener más información sobre las ubicaciones de Cloud KMS disponibles, consulta Ubicaciones de Cloud KMS.

Regiones de Cloud y centros de datos

Una región de Google Cloud contiene un centro de datos específico o un conjunto de centros de datos específico, que se determina por su clasificación como regional, birregional, multirregional o global. Para obtener más información sobre las regiones de Google Cloud, consulta Ubicaciones de Google Cloud.

Cada centro de datos contiene bastidores de máquinas para procesar, conectar o almacenar datos. Estas máquinas ejecutan la infraestructura de Borg de Google.

Los centros de datos de Google cuentan con requisitos de seguridad física estrictos. Cualquier espacio físico en el que puede haber datos de usuarios requiere de entradas con lectores de credenciales y escáneres de iris a fin de autenticar la identidad de quienes ingresan. Las puertas no se mantienen abiertas para más de una persona. Cada persona debe autenticarse de forma individual. No se puede ingresar a estas áreas ni salir de ellas con bolsos, a menos que sean transparentes y se hayan autorizado de forma explícita luego de una inspección por parte del personal de seguridad. Se requiere un permiso especial para ingresar o salir con cualquier dispositivo electrónico que pueda transmitir o registrar datos.

Residencia de las claves

En algunos sectores, se requiere que las claves criptográficas residan en una ubicación específica. Cloud KMS tiene términos de ubicación de datos con garantía de residencia de datos. Como se explicó en Regiones de los recursos de Cloud KMS, Cloud KMS ofrece cuatro tipos de ubicaciones regionales para ayudarte a cumplir con esos requisitos.

En los casos de ubicaciones de una sola región, birregionales o multirregionales, Cloud KMS crea, almacena y procesa las claves respaldadas por software y hardware y el material de las claves solo en esa ubicación. Los sistemas de procesamiento de datos y almacenamiento que usa Cloud KMS están configurados para usar solo recursos dentro de la región de Google Cloud asociada con el material de las claves. El material de las claves creado en ubicaciones birregionales o multirregionales no sale de los límites de las ubicaciones seleccionadas.

Para la región global, no hay garantías de regionalidad especificadas.

Cloud KMS no garantiza la residencia de los metadatos de las claves, los registros de uso ni el material de las claves en tránsito. Los metadatos de las claves incluyen nombres de recursos; propiedades de los recursos de Cloud KMS, como el tipo, el tamaño y el estado de la clave; políticas de IAM y cualquier dato derivado de los metadatos.

Cuando usas CMEK, las siguientes restricciones geográficas de Cloud KMS se aplican a tus claves, independientemente de las ubicaciones personalizadas, de región doble o multirregionales que elijas en otros productos de Google Cloud que admitan CMEK:

• En el caso de una región específica: debido a que la región de la clave de KMS administrada por el cliente siempre debe estar correlacionada con la región del recurso al que protege en un servicio determinado de Google Cloud, se garantiza la compatibilidad y la aplicación de las restricciones de residencia para las claves y los recursos de una sola región.
• En el caso de ubicaciones birregionales o multirregionales: los usuarios pueden seleccionar multirregiones definidas por Google para sus claves y recursos de Google Cloud a fin de garantizar el cumplimiento de la residencia. Para garantizar esta residencia geográfica, asegúrate de que tus regiones en otros productos correspondan con las ubicaciones regionales que elegiste en Cloud KMS.

En la siguiente tabla, se resume la residencia del material de las claves para Cloud KMS.

Tipo de región	En reposo, en uso
Unirregional	Residente
Birregional o multirregional	Residente en las regiones que constituyen la birregión o la multirregión.

Supervisión de las regiones

Los servicios de supervisión de datos internos de Google supervisan de forma activa la residencia de las claves. Cloud KMS envía alertas a los miembros del equipo de SRE si detecta parámetros de configuración incorrectos por error, si el material de una clave abandona los límites de su región configurada o se almacena en la región incorrecta, o si se accede al material desde una región incorrecta.

Alta disponibilidad

Cloud KMS puede ayudarte a simplificar los requisitos de disponibilidad según las regiones que selecciones. Cuanto más detallada sea la ubicación, más redundancia tendrás para compilar. En el caso de las aplicaciones con niveles de disponibilidad más altos, usa ubicaciones multirregionales en lugar de intentar compilar tu propio sistema de replicación de claves. Debes equilibrar las capacidades de redundancia integradas con tus necesidades de regionalización de datos.

Autenticación y autorización

Cloud KMS acepta varios mecanismos de autenticación, como OAuth2, JWT, y ALTS. Cualquiera sea el mecanismo, Cloud KMS resuelve la credencial proporcionada a fin de identificar el principal (la entidad que se autentica y que autoriza la solicitud) y llama a IAM para descubrir si el principal está autorizado para realizar la solicitud y si se escribirá un registro de auditoría.

Cloud KMS usa una versión interna de la API de Service Control pública para muchos aspectos de la administración de servicios. Antes de que un trabajo de Cloud KMS controle una solicitud, este envía una solicitud de verificación a la API de Service Control, que aplica muchos controles comunes a todos los servicios de Google Cloud, como los que se incluyen a continuación:

• Se verifica si activaste la API de Cloud KMS y si tienes una cuenta de facturación activa.
• Se verifica si no superaste tu cuota y se informa el uso de esta.
• Se aplican los Controles del servicio de VPC.
• Se verifica si estás en la lista de anunciantes permitidos de las regiones de nube privada aplicables.

Administración de la cuota

Cloud KMS tiene límites de uso, llamados cuotas, en las solicitudes realizadas al servicio. Cloud KMS contiene las siguientes cuotas:

• Cuotas de solicitudes criptográficas para operaciones como la encriptación, la desencriptación o la firma.
• Cuotas de solicitudes de lectura para operaciones como la obtención de metadatos clave o la obtención de una política de IAM.
• Cuotas de solicitudes de escritura para operaciones como la creación de una clave o la configuración de una política de IAM.

Estas cuotas se cobran al proyecto asociado con el emisor. Estas cuotas también son globales, lo que significa que se aplican al uso del KMS de emisor en todas las regiones y multirregiones. Estas cuotas se evalúan para todos los niveles de protección.

Cloud HSM y Cloud EKM tienen cuotas adicionales para las operaciones criptográficas. Estas cuotas se deben cumplir además de la cuota de solicitudes criptográficas. Las cuotas de Cloud HSM y Cloud EKM se cobran al proyecto en el que reside la clave y las cuotas se aplican a cada ubicación.

Considera los siguientes ejemplos:

• Llamar al método de desencriptación con una clave de software en asia-northeast1 requiere una unidad de cuota (global) de solicitudes criptográficas.
• Para crear una clave de HSM en us-central1, se requiere una unidad de cuota de solicitudes de escritura y ninguna cuota de HSM.
• La llamada a la encriptación con una clave de EKM en europe requiere una unidad de cuota (global) de solicitudes criptográficas y una unidad de solicitudes de KMS externas en europe.

Para obtener más información sobre el tipo de cuota disponible, consulta Cuotas de uso de los recursos de Cloud KMS. Puedes ver el límite de cuota en la consola de Cloud. Los límites de cuota iniciales son límites flexibles que puedes solicitar ajustar según las necesidades de la carga de trabajo.

Registros

Hay tres tipos de registros asociados con Cloud KMS: Registros de auditoría de Cloud, registros de Transparencia de acceso y registros internos de solicitudes.

Registros de auditoría de Cloud

Cloud KMS registra tu actividad en Registros de auditoría de Cloud. Los clientes pueden ver estos registros en la consola de Cloud. Toda la actividad del administrador, como la creación o la destrucción de una clave, se ingresa en estos registros. También puedes optar por habilitar los registros para cualquier otra acción en la que se use una clave, como el uso de una clave en la encriptación o desencriptación de datos. Tú controlas cuánto tiempo deseas conservar los registros y quién puede verlos.

Registros de Transparencia de acceso

Los clientes aptos pueden elegir habilitar los registros de Transparencia de acceso, que les proporcionan registros de las acciones que los empleados de Google realizan en tu organización de Google Cloud. Los registros de Transparencia de acceso, junto con los registros de auditoría de Cloud, pueden ayudarte a responder preguntas relacionadas con quién hizo qué, en dónde y cuándo.

Puedes integrar los registros de Transparencia de acceso en tus herramientas existentes de información de seguridad y administración de eventos (SIEM) para automatizar las auditorías de estas acciones. Estos registros están disponibles en la consola de Cloud junto con tus Registros de auditoría de Cloud.

En las entradas de registro de Transparencia de acceso, se incluyen los siguientes tipos de detalles:

• Acción y recurso afectados
• Hora de la acción
• Razones para realizar la acción. Entre los ejemplos de razones, se incluyen la asistencia iniciada por el cliente (con un número de caso), la asistencia iniciada por Google, las solicitudes de datos de terceros y las solicitudes de revisión iniciadas por Google
• Datos acerca de quién actúa sobre los datos (por ejemplo, la ubicación de los miembros del personal de Google).

Registros de solicitudes internas

Los registros de solicitudes almacenan un registro por cada solicitud enviada a la plataforma de Cloud KMS. Este registro contiene detalles sobre el tipo de solicitud (como protocolo o método de API) y el recurso al que se accede (como el nombre del recurso, el algoritmo de la clave o el nivel de protección de la clave). Estos registros no almacenan texto simple, texto cifrado ni material de la clave del cliente. Antes de que se agreguen nuevos tipos de datos a estos registros, un equipo que se especializa en las revisiones de privacidad debe aprobar los cambios a los datos que están registrados.

Las entradas de registro se borran de forma permanente cuando vence el tiempo de actividad (TTL) configurado.

Los ingenieros y SRE de Cloud KMS que están de turno pueden acceder a los registros de solicitudes. El acceso humano a los registros y cualquier acceso que muestre datos del cliente requiere una justificación empresarial válida y documentada. Con algunas excepciones específicas, se registra el acceso humano, y los clientes calificados pueden acceder a él en los registros de Transparencia de acceso.

Supervisión

Cloud KMS se integra en Cloud Monitoring. Esta integración te permite supervisar, compilar paneles y crear alertas en muchas operaciones de Cloud KMS. Por ejemplo, puedes supervisar la programación de destrucción de las claves o supervisar y ajustar las cuotas de Cloud KMS cuando las operaciones criptográficas superan el umbral que definiste. Para obtener más información sobre las métricas de Cloud KMS disponibles, consulta Usa Cloud Monitoring con Cloud KMS.

Además, Security Command Center tiene detectores de vulnerabilidades de KMS integrados. Estos detectores ayudan a garantizar que los proyectos que incluyen claves sigan nuestras prácticas recomendadas. Para obtener más información sobre el detector de vulnerabilidades de KMS, consulta Hallazgos de vulnerabilidades para Cloud KMS.

¿Qué sigue?

• Para obtener más información sobre Cloud KMS, explora los siguientes recursos:
  • Documentación de Cloud KMS
  • Documentación de Cloud HSM
• Para obtener información sobre cómo usar tus propias claves de encriptación en Google Cloud, consulta Claves de encriptación administradas por el cliente (CMEK).
• Descubre cómo Google se prepara para un mundo poscuántico.
• Para obtener más información sobre la seguridad de la infraestructura de Google, consulta la descripción general del diseño de seguridad de la infraestructura de Google.
• Para obtener información general sobre la seguridad de Google Cloud, consulta la sección Seguridad del sitio web de Google Cloud.