Esta página se ha traducido con Cloud Translation API.

Cifrado de Cloud Key Management Service

Este contenido se actualizó por última vez en enero del 2025 y representa la situación en el momento en que se redactó. Las políticas y los sistemas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos constantemente la protección que proporcionamos a nuestros clientes.

En este documento se describe cómo proporciona Cloud Key Management Service (Cloud KMS) servicios de gestión de claves en Google Cloud para el cifrado de datos en reposo. Google Cloud parte de la premisa de que Google Cloud los clientes tienen la propiedad de sus datos y son quienes deben controlar cómo se utilizan.

Cuando almacenas datos con Google Cloud, se encriptan en reposo de forma predeterminada. Con la plataforma de Cloud KMS, puedes controlar en mayor medida cómo se cifran tus datos en reposo y cómo se gestionan las claves de cifrado.

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á dirigido a los responsables de la toma de decisiones técnicas que necesitan conocer los detalles de la arquitectura, la infraestructura y las funciones de Cloud KMS. Se presupone que el lector tiene conocimientos básicos sobre el encriptado y las arquitecturas de nube.

Teclas en Google Cloud

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

Tipo de clave	Autokey de Cloud KMS	Cloud KMS gestionado por el cliente (manual)	Google-owned and Google-managed encryption key (cifrado predeterminado de Google)
Puede ver metadatos clave	Sí	Sí	No
Propiedad de las claves¹	Cliente	Cliente	Google
Puede gestionar² y controlar³ claves	La creación y la asignación de claves se automatizan. Se admite el control manual por parte del cliente.	Solo control manual por parte del cliente	Google
Cumple los requisitos normativos de las claves gestionadas por el cliente	Sí	Sí	No
Compartir llaves	Exclusivo de un cliente	Exclusivo de un cliente	Los datos de varios clientes suelen estar protegidos por claves de encriptado de claves (KEKs) compartidas.
Control de la rotación de claves	Sí	Sí	No
Políticas de organización de CMEK	Sí	Sí	No
Registrar el acceso administrativo y de datos a las claves de cifrado	Sí	Sí	No
Separación lógica de datos mediante cifrado	Sí	Sí	No
Precios	Varía	Varía	Gratis

¹ El propietario de la clave indica quién tiene los derechos de la clave. Google tiene un acceso muy restringido o nulo a las claves que te pertenecen.

La gestión de claves ² incluye las siguientes tareas:

Crea claves.
Elige el nivel de protección de las llaves.
Asigna la autoridad para gestionar las claves.
Controlar el acceso a las claves.
Controlar el uso de las llaves.
Definir y modificar el periodo de rotación de las claves o activar la rotación de las claves.
Cambiar el estado de la clave.
Eliminar versiones de clave.

³ El control de las claves implica establecer controles sobre el tipo de claves y cómo se usan, detectar variaciones y planificar medidas correctivas si es necesario. Puedes controlar tus llaves, pero delegar la gestión de las llaves en un tercero.

Principios de Cloud KMS

Con Cloud KMS, Google pretende proporcionar una solución escalable, fiable y eficiente con un amplio abanico de opciones bajo tu control. Cloud KMS se basa en los siguientes principios:

Control del cliente: Cloud KMS te permite controlar tus propias claves de software y hardware para el encriptado y la firma. Este pilar incluye la compatibilidad con las funciones de traer tus propias claves (BYOK) y conservar tus propias claves (HYOK).
Control y monitorización del acceso: con Cloud KMS, puedes gestionar los permisos de claves concretas y monitorizar cómo se usan.
Regionalización: Cloud KMS te permite regionalizar tus claves de forma inmediata. El servicio está configurado para crear, almacenar y procesar claves únicamente en la Google Cloud ubicación que selecciones.
Copias de seguridad: el servicio analiza periódicamente los metadatos y el material de claves. También hace copias de seguridad de ellos para evitar que se dañen los datos y comprobar que se pueden desencriptar correctamente.
Seguridad: Cloud KMS ofrece un sistema de protección eficaz contra el acceso no autorizado a las claves y está completamente integrado con los controles de gestión de identidades y accesos y de los registros de auditoría de Cloud.
Separación lógica de datos: el cifrado de Cloud KMS proporciona separación lógica de datos mediante el cifrado. La separación lógica de datos significa que los propietarios de los datos no comparten las claves de cifrado (KEKs y DEKs).

Fuentes y opciones de gestión de claves criptográficas

La plataforma de Cloud KMS te permite gestionar claves criptográficas en un servicio central basado en la nube para usarlas de manera directa o permitir que lo hagan otros recursos y aplicaciones en la nube.

La Google Cloud cartera de claves incluye lo siguiente:

Cifrado predeterminado: todos los datos que almacena Google se cifran en la capa de almacenamiento mediante el algoritmo estándar de cifrado avanzado (AES), AES-256. Generamos y gestionamos las claves del cifrado predeterminado, y los clientes no tienen acceso a las claves ni control sobre la rotación y la gestión de las claves. Las claves de cifrado predeterminadas se pueden compartir entre clientes. Para obtener más información, consulta Encriptado en reposo predeterminado.
Cloud KMS con claves protegidas por software: puedes controlar las claves que se generan en Cloud KMS. El backend del software de Cloud KMS te ofrece flexibilidad a la hora de encriptar o firmar tus datos mediante una clave simétrica o asimétrica que tú controlas.
Cloud KMS con claves protegidas por hardware (Cloud HSM): si usas Cloud KMS con el backend de Cloud HSM, puedes tener claves que se generen y almacenen en módulos de seguridad de hardware (HSMs) propiedad de Google y gestionados por Google. Si necesitas una clave protegida por hardware, puedes usar el backend de Cloud HSM para asegurarte de que tus claves se usan exclusivamente en los HSM con validación FIPS 140-2 de nivel 3. Puedes aprovisionar claves protegidas por hardware de forma manual, lo que requiere un administrador de Cloud KMS, o automáticamente mediante Cloud KMS Autokey. Autokey te permite automatizar los procesos de aprovisionamiento y asignación de claves de cifrado gestionadas por el cliente (CMEK). Las claves de HSM convencionales requieren que un administrador de KMS cree las claves bajo petición.
Cloud KMS con importación de claves: para cumplir los requisitos de BYOK, puedes importar tus propias claves criptográficas que generes por tu cuenta. Puedes usar y gestionar estas claves fuera deGoogle Cloud, así como usar el material de las claves en Cloud KMS para encriptar o firmar los datos que almacenes en Google Cloud.
Cloud KMS con gestor de claves externo (Cloud EKM): para cumplir los requisitos de HYOK, puedes crear y controlar claves que se almacenan en un gestor de claves externo a Google Cloud. A continuación, configura la plataforma de Cloud KMS para usar las claves externas y proteger tus datos en reposo. Puedes usar estas claves de encriptado con una clave de Cloud EKM. Para obtener más información sobre la gestión de claves externas y Cloud EKM, consulta Arquitecturas de referencia de Cloud EKM.

Puedes usar las claves generadas por Cloud KMS con otrosGoogle Cloud servicios. Estas claves se conocen como CMEKs. La función de CMEK te permite generar, usar, rotar y eliminar claves de cifrado que ayudan a proteger tus datos en otros servicios de Google Cloud. Cuando usas CMEK con Google Cloud servicios, se gestionan el acceso a las claves y el seguimiento.

Encriptado y gestión de claves en Google

En esta sección se definen algunos términos de la gestión de claves en el contexto de la infraestructura multicapa para la gestión de claves de Google.

Conjuntos de claves, claves y versiones de clave

En el siguiente diagrama se muestra la agrupación de claves, así como los conjuntos de claves y las claves con una sola versión principal y varias versiones anteriores.

Diagrama de la agrupación de claves.

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

Clave: un objeto con nombre que representa una clave criptográfica que se utiliza para un fin específico. El material de la clave, es decir, la información que se utiliza para las operaciones criptográficas, puede cambiar a medida que creas nuevas versiones de la clave. Puedes asignar políticas de admisión de gestión de identidades y accesos a nivel de clave en la jerarquía de recursos.

El propósito y otros atributos de la clave están vinculados a ella y se gestionan usándola. Por lo tanto, la clave es el objeto más importante para comprender el uso de KMS.

Cloud KMS admite claves simétricas y asimétricas. Las claves simétricas se usan para crear o validar firmas MAC, o bien para el cifrado simétrico, con el fin de proteger conjuntos de datos. Por ejemplo, puedes usar el cifrado AES-256 en modo GCM para encriptar un bloque de texto sin formato. Las claves asimétricas se pueden usar para el cifrado o la firma asimétricos. Para obtener más información, consulta Usos y algoritmos admitidos.
Conjunto de claves: agrupación de claves con fines organizativos. Los conjuntos de claves pertenecen a un Google Cloud proyecto y se encuentran en una ubicación específica. Las claves heredan las políticas de permiso de su conjunto de claves. Si agrupas las claves con permisos relacionados en un mismo conjunto, puedes conceder, revocar o modificar los permisos de esas claves a nivel del conjunto de claves, sin tener que hacerlo individualmente con cada una de ellas. Los conjuntos de claves proporcionan comodidad y ayudan a categorizar las claves, pero si el agrupamiento no te resulta útil, puedes gestionar los permisos directamente en las claves. Las etiquetas te permiten permitir o denegar políticas de forma condicional en función de si un recurso tiene una etiqueta específica. Puede aplicar etiquetas a nivel de llavero en la jerarquía de recursos.

Para evitar los conflictos entre nombres de recursos, no puedes eliminar conjuntos de claves ni claves. Dado que ni los conjuntos de claves ni las claves tienen costes facturables ni limitaciones de cuota, su existencia no afectará a los costes ni a los límites de producción.
Metadatos de claves: nombres y propiedades de recursos de KMS, como políticas de permisos, tipo, tamaño o estado de la clave y cualquier dato derivado de claves y conjuntos de claves.
Versión de la clave: el material asociado a la clave en un momento dado. La versión de la clave es el recurso que contiene el material de la clave propiamente dicho. Las versiones se numeran secuencialmente, empezando por la versión 1. Cada vez que se rota una clave, se crea otra versión con material de clave nuevo. La misma clave lógica puede tener varias versiones con el paso del tiempo, lo que significa que tus datos se cifran con diferentes versiones de la clave. Las claves simétricas tienen una versión primaria. De forma predeterminada, se usa la versión principal para el cifrado. Cuando Cloud KMS realiza el desencriptado mediante claves simétricas, se identifica automáticamente qué versión de la clave hace falta.

Jerarquía de claves

En el siguiente diagrama se muestra la jerarquía de claves y el encriptado envolvente de Cloud KMS y del almacén de claves interno de Google. El cifrado envolvente es el proceso de cifrar una clave con otra para almacenarla de forma segura o transmitirla a través de un canal no fiable. Todas las claves de este diagrama son claves simétricas.

Diagrama de la jerarquía interna de claves.

Dentro de la jerarquía de claves, una clave de cifrado de datos (DEK) cifra los fragmentos de datos. Una clave de cifrado de claves (KEK) se usa para cifrar o encapsular la DEK. Todas las opciones de la plataforma de Cloud KMS (software, hardware y backends externos) te permiten controlar la KEK. Las KEK se almacenan en Cloud KMS. El material de claves nunca abandona el límite del sistema de Cloud KMS.

En el caso de las claves protegidas por software, una clave maestra del KMS específica de la ubicación encripta la KEK. La clave maestra del KMS se almacena en el almacén de claves. Hay una clave maestra de KMS independiente en Keystore para cada ubicación de Cloud KMS. Cada servidor de Cloud KMS obtiene una copia de la clave maestra de KMS durante el inicio, como una dependencia fija, y cada día se genera una copia nueva de esa clave. La clave maestra de KMS se vuelve a encriptar periódicamente con la clave maestra de Keystore en Keystore. La clave maestra del almacén de claves está protegida por la clave maestra raíz del almacén de claves.

En el caso de las claves protegidas por hardware, una clave de encapsulado de HSM específica de una ubicación cifra la KEK, y la clave de encapsulado de HSM se cifra con la clave maestra de KMS. Para obtener más información, consulta Crear claves. En el caso de las claves externas, una clave de encapsulamiento de EKM cifra la DEK encapsulada, y la clave de encapsulamiento de EKM se cifra con la clave maestra de KMS.

Cloud KMS usa Keystore, que es el servicio interno de gestión de claves de Google, para encapsular las claves encriptadas de Cloud KMS. Cloud KMS utiliza la misma raíz de confianza que Keystore. Para obtener más información sobre Keystore, consulta la sección Gestión de claves del documento sobre el cifrado en reposo.

Restricciones operativas

Cloud KMS funciona con las siguientes restricciones:

Proyecto: los recursos de Cloud KMS pertenecen a un Google Cloudproyecto, al igual que el resto de los recursos Google Cloud. Tus claves de Cloud KMS pueden residir en un proyecto diferente al de los datos que protegen. Si mantienes las claves en el mismo proyecto que los datos que protegen los recursos, puedes quitar el rol de propietario del proyecto para aplicar la práctica recomendada de separación de obligaciones entre los administradores de claves y los administradores de datos.
Ubicaciones: los recursos de Cloud KMS se crean en una ubicación dentro de un proyecto. Para obtener más información sobre las ubicaciones, consulta el artículo sobre geografía y regiones.
Coherencia: Cloud KMS propaga las operaciones en claves, conjuntos de claves y versiones de claves mediante una coherencia fuerte o eventual. Para obtener más información, consulta Coherencia de los recursos de Cloud KMS.

Claves de encriptado gestionadas por el cliente

De forma predeterminada, Google Cloud cifra todos los datos de clientes almacenados en reposo. Además, Google gestiona las claves utilizadas para ello. En los productos compatibles Google Cloud que almacenan de forma persistente tu contenido de cliente (por ejemplo, Cloud Storage), puedes usar Cloud KMS para gestionar las claves de cifrado gestionadas por el cliente (CMEKs). Las CMEKs son claves de cifrado que te pertenecen y que se pueden usar con claves externas, claves protegidas por software y claves protegidas por hardware.

Las CMEK te permiten tener un mayor control sobre las claves que se usan para cifrar los datos en reposo en los Google Cloud servicios compatibles y proporcionan un límite criptográfico en torno a tus datos. Puedes gestionar las CMEKs directamente en Cloud KMS o automatizar el aprovisionamiento y la asignación mediante Autokey. Cuando un servicio usa CMEK, tus cargas de trabajo pueden acceder a los recursos de la misma forma que cuando solo usas el cifrado predeterminado.

Cloud KMS te permite controlar muchos aspectos de las claves (como crearlas, habilitarlas, inhabilitarlas, rotarlas y destruirlas) y gestionar los permisos de gestión de identidades y accesos correspondientes. Para implementar la separación de obligaciones recomendada, Cloud KMS incluye varios roles predefinidos de gestión de identidades y accesos que tienen privilegios y limitaciones específicos, y que se pueden conceder a usuarios y cuentas de servicio concretos.

Como Cloud KMS usa el cifrado envolvente, una CMEK es una KEK que cifra las DEKs. Para obtener más información, consulta Jerarquía de claves.

La rotación de CMEK funciona de forma diferente en función del tipo de recurso que proteja la clave. Ten en cuenta los siguientes ejemplos:

En Spanner, una nueva versión de la clave vuelve a cifrar la DEK.
En el caso de otros tipos de recursos, como los segmentos de Cloud Storage, solo los recursos creados recientemente se cifran con la nueva versión de la clave, lo que significa que diferentes versiones de una clave protegen diferentes subconjuntos de datos.
En algunos casos, el recurso de nube debe volver a crearse con la nueva versión de la clave. Por ejemplo, de forma predeterminada, BigQuery no rota automáticamente la clave de cifrado de una tabla cuando se rota la clave de Cloud KMS asociada con esa tabla. Las tablas de BigQuery disponibles seguirán utilizando la versión de clave con la que se crearon.

Para obtener más información sobre la rotación de claves, consulta la documentación de cada producto.

Las políticas de organización de CMEK te permiten controlar mejor cómo se usa CMEK en tus proyectos. Estas políticas te permiten controlar los servicios y proyectos que contienen claves permitidas para CMEK, así como el nivel de protección de las claves.

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

Autokey de Cloud KMS

Autokey te permite agilizar el proceso de aprovisionamiento de CMEK. Durante un proceso de aprovisionamiento manual de CMEK, un administrador de Cloud KMS debe planificar los tipos de conjuntos de claves, claves y cuentas de servicio antes de que sean necesarios, así como coordinarse con los desarrolladores para aprovisionar las claves. Con Autokey, el administrador de Cloud KMS delega su autoridad en el agente de servicio de Cloud KMS del proyecto. Cuando habilitas Autokey, un desarrollador puede solicitar una clave de Cloud KMS y el agente de servicio proporciona la clave adecuada para la intención del desarrollador. Con Autokey, las claves están disponibles bajo demanda, son coherentes y siguen las prácticas estándar del sector.

Autokey aprovisiona y asigna conjuntos de claves, claves y cuentas de servicio bajo demanda a medida que los desarrolladores crean recursos en la nube, respetando la separación de funciones. El aprovisionamiento y la asignación de claves siguen las prácticas y recomendaciones estándar del sector en materia de seguridad de los datos, entre las que se incluyen las siguientes:

Nivel de protección HSM: las claves creadas con Autokey siempre son claves de HSM y, por lo tanto, se almacenan en el backend de Cloud HSM. Son claves de encriptado AES-256 GCM.
Separación de funciones: para mantener la separación de funciones, las identidades que pueden usar la clave para cifrar y descifrar son diferentes de las identidades que gestionan la clave (incluida su rotación, destrucción o cambio de estado).
Rotación de claves: las claves se rotan anualmente.
Ubicación conjunta de la clave y los recursos: la clave se encuentra en la misma ubicación que el recurso que protege.
Especificidad de la clave: la especificidad de la clave es adecuada para el tipo de recurso que protege, por tipo de recurso. La especificidad significa que no tienes que revisar manualmente los tipos de recursos de cada servicio y decidir cuántos tipos de recursos debe proteger una sola clave.

Las claves solicitadas mediante Autokey funcionan de forma idéntica a otras claves de Cloud HSM con los mismos ajustes. Autokey simplifica el uso de Terraform porque elimina la necesidad de ejecutar la infraestructura como código con privilegios elevados de creación de claves. Autokey está disponible en todas lasGoogle Cloud ubicaciones en las que se ofrece Cloud HSM.

Autokey solo está disponible para determinados recursos Google Cloud . Para obtener más información, consulta la descripción general de Autokey.

Arquitectura y componentes 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 con claves externas, claves protegidas por hardware y claves protegidas por software. La plataforma de Cloud KMS está integrada con Gestión de Identidades y Accesos (IAM) y Registros de auditoría de Cloud para que puedas gestionar los permisos de claves concretas y auditar cómo se utilizan.

Diagrama de la arquitectura de Cloud KMS.

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

Los administradores acceden a los servicios de gestión de claves con la consola de Cloud o la CLI de Google Cloud.
Las aplicaciones acceden a los servicios de gestión de claves implementando la API REST, gRPC o las bibliotecas de cliente. Además, pueden aprovechar los servicios de Google habilitados para usar CMEK. Las CMEK a su vez usan la API de Cloud Key Management Service. Si tu aplicación usa PKCS #11, puedes integrarla con Cloud KMS mediante la biblioteca de PKCS #11.
La API de Cloud KMS te permite usar claves de software, hardware o externas. Puedes generar y gestionar claves protegidas por software y por hardware mediante el endpoint del servicio Cloud KMS. Tanto las llaves protegidas por software como las protegidas por hardware utilizan las protecciones de copias de seguridad redundantes de Google.
Si usas claves protegidas por hardware, los HSMs con certificación FIPS 140-2 de nivel 3Google Cloud almacenan las claves. Para obtener más información sobre nuestra certificación, consulta el certificado n.º 4399.
Cloud KMS utiliza el almacén de datos interno de Google para almacenar material de claves de clientes cifrado. Este almacén de datos tiene una alta disponibilidad y es compatible con muchos sistemas críticos de Google. Consulta Protección de Datastore.
A intervalos regulares, el sistema de copias de seguridad independiente crea copias de seguridad de todo el almacén de datos en el almacenamiento online y en el de archivo. Esta copia de seguridad permite que Cloud KMS alcance sus objetivos de durabilidad. Consulta Protección del almacén de datos.

Validación FIPS 140-2

Las operaciones criptográficas de Cloud KMS se realizan mediante nuestros módulos validados por el estándar FIPS 140-2. Las claves con el nivel de protección SOFTWARE y las operaciones criptográficas que se realizan con ellas cumplen el estándar FIPS 140-2 de nivel 1. Estas operaciones criptográficas usan BoringCrypto, una biblioteca criptográfica de código abierto mantenida por Google. Las claves con el nivel de protección HSM y las operaciones criptográficas que se realizan con ellas cumplen el estándar FIPS 140-2 de nivel 3.

Seguridad del material de claves

En Cloud KMS, el material de claves siempre se encripta en reposo y en tránsito, y solo se desencripta en los siguientes casos:

Cuando el cliente lo está utilizando.
Cuando se rota la clave interna de Google que se usa para proteger el material de claves del cliente o se comprueba su integridad.

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

La autenticación tiene lugar entre todas las tareas de Cloud KMS, tanto dentro de los centros de datos de Google como entre ellos.

La política de Google trata de asegurar que los trabajos utilizan únicamente código fuente desarrollado, probado y revisado de forma verificable. La autorización binaria para Borg (BAB) aplica esta política a nivel operativo.

Las tareas de la API de Cloud KMS pueden acceder a los metadatos de claves (como la política de permisos o el periodo de rotación). Un empleado de Google con una justificación empresarial válida y documentada (como un error o un problema del cliente) también puede acceder a ellos. Estos eventos de acceso se registran de forma interna y los clientes que reúnen ciertos requisitos pueden acceder a los registros relacionados con los datos que abarca la Transparencia de acceso.

El material de claves descifrado no se puede exportar ni consultar a través de la interfaz de la API ni de otra interfaz de usuario. Ningún empleado de Google tiene acceso al material de claves de clientes sin encriptar. Además, el material de claves se encripta con una clave maestra en Keystore, a la que no puede acceder directamente ningún usuario. En un HSM, las tareas de la API de Cloud KMS nunca acceden al material de claves en un estado descifrado.

Protección del almacén de datos

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

Disponibilidad. Cloud KMS utiliza el almacén de datos interno de Google, que tiene una alta disponibilidad y es compatible con una serie de sistemas críticos de Google.

Durabilidad. Cloud KMS utiliza el encriptado autenticado para guardar material de 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 comprobar que no se han alterado ni dañado en reposo. Cada hora, una tarea por lotes analiza todo el material y los metadatos de claves y verifica que los HMAC son válidos y que el material de la clave puede desencriptarse correctamente. Si hay datos dañados, se avisa inmediatamente a los ingenieros de Cloud KMS para que puedan tomar medidas.

Cloud KMS utiliza varios tipos de copias de seguridad para el almacén de datos:

De forma predeterminada, el almacén de datos conserva un historial de cambios de todas las filas durante cuatro días. En caso de emergencia, se puede ampliar su duración para que haya más tiempo para corregir los problemas.
Cada hora, el almacén de datos registra una captura. La captura se puede validar y usar para la restauración, si es necesario. Estas capturas se guardan durante cuatro días.
Cada día, se graba una copia de seguridad completa en el disco y en el almacenamiento de archivo.

El equipo de Cloud KMS ha documentado los procedimientos para restaurar copias de seguridad y mitigar la pérdida de datos cuando se produce una emergencia del lado del servicio.

Copias de seguridad. Las copias de seguridad del almacén de datos de Cloud KMS se encuentran en la región asociada. Google Cloud Estas copias de seguridad se encriptan en reposo. Para acceder a los datos de las copias de seguridad, se valora la justificación de acceso (por ejemplo, el número de una incidencia presentada al equipo de Asistencia de Google); además, el acceso humano se refleja en los registros de Transparencia de acceso.

Protección. En la capa de aplicaciones de Cloud KMS, el material de tus claves se encripta antes de almacenarse. Los ingenieros que tienen acceso al almacén de datos no tienen acceso al material de claves del cliente como texto sin formato. Además, el almacén de datos cifra todos los datos que gestiona antes de escribirlos 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 acceder a los datos cifrados de Cloud KMS sin acceso a las claves de cifrado del almacén de datos, que se almacenan en Keystore.

Política de rotación. Una de las prácticas recomendadas para gestionar el material de claves que goza de una aceptación general consiste en rotar las claves. Hay una política de rotación para las claves que se utilizan para proteger los almacenes de datos de Cloud KMS. También se aplica otra política de rotación para las claves maestras de Keystore que encapsulan las claves maestras de Cloud KMS. La clave maestra de Keystore tiene un texto cifrado programado con una antigüedad máxima de 90 días y una clave de cliente almacenada en caché con una antigüedad máxima de un día. Cloud KMS actualiza las claves maestras de KMS en las tareas de KMS cada 24 horas y vuelve a encriptar todas las claves de clientes de manera mensual.

Residencia de datos. Los datos subyacentes en cada almacén de datos de Cloud KMS permanecen exclusivamente en la región a la que están asociados los datos. Google Cloud Esto también afecta a las ubicaciones que tienen varias regiones, por ejemplo, la multirregión us.

Disponibilidad de claves después de crearlas

Cloud KMS permite usar una clave justo después de que el almacén de datos de Cloud KMS confirme la transacción que crea la clave y de que la capa de almacenamiento reconozca su creación.

Back-ends de claves y niveles de protección

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

SOFTWARE: se aplica a las claves que puede desencapsular un módulo de seguridad de software para realizar operaciones criptográficas.
HSM: se aplica a las claves que solo pueden desencapsular los HSM que realizan todas las operaciones criptográficas con las claves.
EXTERNAL o EXTERNAL-VPC: se aplica a External Key Manager (EKM). EXTERNAL-VPC te permite conectar EKM a Google Cloud a través de una red de VPC.

Backend del 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 describe en detalle cómo se implementa este nivel.

Implementaciones algorítmicas

En el caso de las claves de software, Cloud KMS utiliza el módulo BoringCrypto dentro de la implementación de BoringSSL de Google para todas las tareas criptográficas relacionadas. El módulo BoringCrypto está validado según el estándar FIPS 140-2. El binario de Cloud KMS se ha creado a partir de los primitivos criptográficos con la validación FIPS 140-2 de nivel 1 de este módulo. En la sección Usos y algoritmos de las claves se indican los algoritmos más recientes que abarca este módulo, así como las operaciones de encriptado, de desencriptado y de firma con el cifrado AES256-GCM simétrico y las claves criptográficas asimétricas RSA 2048, RSA 3072, RSA 4096, EC P256 y EC P384.

Generación de números aleatorios y entropía

Cloud KMS utiliza BoringSSL para generar claves de encriptado. El estándar FIPS 140‑2 requiere que se utilicen sus propios generadores de números pseudoaleatorios (PRNG), también conocidos como DRBG. En BoringCrypto, Cloud KMS solo utiliza CTR‑DRBG con AES-256, que proporciona la salida de RAND_bytes, la interfaz principal de la que el resto del sistema obtiene datos aleatorios. Este PRNG se deriva del RNG del kernel de Linux, que a su vez se origina a partir de varios orígenes de entropía independientes. Entre ellos, están los eventos entrópicos del entorno del centro de datos (como las mediciones detalladas de búsqueda de discos y los tiempos de llegada entre paquetes) y la instrucción RDRAND de Intel, siempre que esté disponible. Para obtener más información sobre el comportamiento del generador de números aleatorios para BoringSSL (el modo que cumple los estándares FIPS), consulta el diseño del RNG.

Backend de Cloud HSM: nivel de protección HARDWARE

Cloud HSM proporciona claves protegidas por hardware a Cloud KMS. Te permite usar claves criptográficas protegidas por HSMs totalmente gestionados y con certificación FIPS 140-2 de nivel 3 en los centros de datos de Google. Cloud HSM tiene una alta disponibilidad y ofrece un escalado flexible, al igual que Cloud KMS. Puedes acceder al backend de Cloud HSM con las mismas API y bibliotecas de cliente que se usan para Cloud KMS. Para obtener más información sobre el backend de Cloud HSM, consulta el artículo sobre la arquitectura de Cloud HSM.

Cloud EKM: nivel de protección EXTERNAL

Cloud EKM te permite cifrar datos con claves de cifrado fuera de la nube que siguen bajo tu control.

Las claves con los niveles de protección EXTERNAL y EXTERNAL_VPC se almacenan y gestionan en un sistema de gestión de claves externo. Para obtener más información, consulta las arquitecturas de referencia de Cloud EKM.

Proceso de creación de claves

En el siguiente diagrama se ilustra el proceso de creación de claves para los diferentes back-ends de claves y niveles de protección.

Diagrama del proceso de creación de claves.

El proceso de creación de claves incluye lo siguiente:

Mediante la API de Cloud KMS, un usuario pide a Cloud KMS que cree una clave. Esta solicitud incluye el nivel de protección (si la clave está protegida por software, hardware o de forma externa).
Cloud KMS verifica la identidad del usuario y si tiene permiso para crear la clave.
La clave se genera de la siguiente manera:
- En el caso de las claves protegidas por software, Cloud KMS genera la clave del cliente.
- En el caso de las claves protegidas por hardware, Cloud KMS envía una solicitud a Cloud HSM. Cloud HSM envía la solicitud al HSM para generar una clave. El HSM genera una clave de cliente y la cifra (envuelve) con la clave de envoltorio regional del HSM. Cloud HSM envía la clave encapsulada a Cloud KMS.
- En el caso de las claves externas, Cloud KMS envía una solicitud a Cloud EKM. Cloud EKM envía la solicitud al gestor de claves externo para generar una clave nueva. EKM genera una clave nueva y la cifra con la clave de envoltorio de EKM. Cloud EKM envía la clave envuelta a Cloud KMS.
Cloud KMS encripta la clave de cliente encapsulada con la clave maestra de KMS y la envía al almacén de datos de KMS para que se almacene.
Cloud KMS envía al usuario una respuesta de éxito con el URI completo de la versión de la clave.

Importación de claves

Te recomendamos que importes tus propias claves que hayas creado on-premise o en un EKM a tu entorno en la nube. Por ejemplo, es posible que tengas un requisito normativo que dicta que las claves que se usan para encriptar los datos en la nube deben generarse de una forma concreta o en un entorno específico. La importación de claves te permite importar esas claves y cumplir con tus obligaciones normativas. Para poder firmar también en la nube, puedes importar claves asimétricas.

Como parte de la importación de claves, Cloud KMS genera una clave de encapsulado pública, es decir, un par de claves pública/privada con uno de los métodos de importación compatibles. Si la utilizas para encriptar el material de la clave, lo protegerías mientras se encuentra en tránsito.

Utiliza la clave de encapsulado pública para cifrar la clave que se va a importar en el cliente. La clave privada que coincide con la clave pública se almacena en Google Cloudy se utiliza para desencapsular la clave pública cuando llega al proyecto deGoogle Cloud . El algoritmo que se usa para crear la clave de encapsulado depende del método de importación que selecciones. Una vez encapsulado el material de la clave, puedes importarlo a una clave o a una versión de clave nuevas en Cloud KMS.

Puedes usar claves importadas con el nivel de protección HSM o SOFTWARE. En el caso de Cloud HSM, la parte de la clave privada de la clave de encapsulado solo está disponible en Cloud HSM. De este modo, Google no podrá desencapsular el material de la clave fuera de Cloud HSM.

Ciclo de vida de las solicitudes de Cloud KMS

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

Diagrama del ciclo de vida de las solicitudes de KMS.

Las fases de este ciclo de vida son las siguientes:

El personal de tu organización o una tarea que se ejecuta en nombre de tu organización envía una solicitud al servicio de Cloud KMS (https://cloudkms.googleapis.com). El DNS resuelve esta dirección en cualquier dirección IP Anycast del GFE.
GFE proporciona el alojamiento de IPs público de su nombre de DNS público, la protección de la denegación de servicio (DoS) y la terminación de TLS. Cuando envías tu solicitud, por lo general, se le dirige a un GFE cercano, independientemente de la ubicación a la que esté orientada la solicitud. Los GFEs gestionan la negociación de TLS y se basan en los parámetros y la URL de la solicitud para determinar qué balanceador de carga de software mundial (GSLB) se encarga de dirigir la solicitud.
Hay un objetivo de GSLB independiente para cada región de Cloud KMS. Si la solicitud llega a un GFE en us-east1 y está destinada a us-west1, se enruta entre los centros de datos de us-east1 y us-west1. Todas las comunicaciones entre los centros de datos se encriptan en tránsito mediante ALTS, por lo que se autentican mutuamente las tareas de GFE y Cloud KMS.
Cuando la solicitud llega a la tarea de Cloud KMS, primero se procesa con un framework que gestiona gran parte del trabajo que comparten todos los servicios deGoogle Cloud . Este framework autentica la cuenta y realiza una serie de comprobaciones para verificar lo siguiente:
- La cuenta tiene una credencial válida y se puede autenticar.
- La API de Cloud KMS está habilitada en el proyecto y la cuenta de facturación es válida.
- Hay suficiente cuota para ejecutar la solicitud.
- La cuenta se encuentra en la lista de permitidos para utilizar laGoogle Cloud región correspondiente.
- Los Controles de Servicio de VPC no rechazan la solicitud.
Si las comprobaciones prosperan, el framework reenvía la solicitud y la credencial a Cloud KMS. Cloud KMS analiza la solicitud para determinar a qué recursos se accede y, después, comprueba la gestión de identidades y accesos para ver si el llamador tiene permiso para realizar la solicitud. Además, la gestión de identidades y accesos indica si la repetición de la solicitud debe escribirse en los registros de auditoría. Si la opción Justificaciones de acceso a claves está habilitada, se envía un aviso de justificación que debes aprobar.
Una vez que se ha autenticado y autorizado la solicitud, Cloud KMS llama a los backends del almacén de datos de la región para obtener el recurso solicitado. Una vez que se ha obtenido el recurso, se desencripta el material de la clave para utilizarlo.
Con el material de la clave, Cloud KMS procede a realizar la operación criptográfica y reenvía la versión encapsulada de la clave al backend del software de Cloud KMS, al backend de Cloud HSM o al backend de Cloud EKM, en función del nivel de protección de la clave.
Tras completar la operación criptográfica, se te envía la respuesta a través del mismo tipo de canal de GFE a KMS que la solicitud.
Desde que se devuelve la respuesta, Cloud KMS también activa los siguientes eventos de forma asíncrona:
- Los registros de auditoría y de solicitud se rellenan y se ponen en cola para escribirse.
- Los informes se envían para calcular la facturación y gestionar las cuotas.
- Si la solicitud ha actualizado los metadatos de un recurso, se envían los cambios a Inventario de Recursos de Cloud a través de actualizaciones de tareas por lotes.

Integridad de datos de extremo a extremo

Cloud KMS te permite calcular sumas de comprobación de claves y material de claves para asegurarte de que no estén dañados. Estas sumas de comprobación te ayudan a protegerte de la pérdida de datos que pueda deberse a la corrupción del hardware o del software. Las bibliotecas auxiliares te permiten verificar la integridad de las claves. Puedes usar bibliotecas auxiliares para verificar la integridad de las claves proporcionando sumas de comprobación a Cloud KMS, que el servidor verifica. Además, estas bibliotecas te permiten recibir sumas de comprobación para verificar los datos de respuesta en el cliente.

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

Corrupción durante el tránsito, como en la pila entre el momento en que se envían los datos y el momento en que se protegen con TLS.
Problemas en cualquier proxy intermedio entre tu endpoint y KMS (por ejemplo, en las solicitudes entrantes).
Operaciones criptográficas defectuosas, corrupción de la memoria de la máquina o corrupción 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 Verificar la integridad de datos completa.

Destrucción del material de claves

El material de claves se considera datos del cliente, por lo que el enfoque que se describe en Eliminación de datos en Google Cloud también se aplica a Cloud KMS. El material de la clave se destruye bajo solicitud cuando transcurre el periodo Programado para destrucción y las copias de seguridad caducan. El material de la clave que aún esté presente en las copias de seguridad (una vez que haya finalizado el periodo programado para la destrucción) solo se puede usar para la recuperación ante desastres regional y no para restaurar claves individuales. No se asegura el funcionamiento de este proceso para las copias de claves importadas que quedan fuera del control de Cloud KMS.

De forma predeterminada, las claves de Cloud KMS permanecen 30 días en el estado Programada para la destrucción (eliminación no definitiva) antes de que el material de la clave se elimine lógicamente del sistema. Puedes cambiar esta duración. Para obtener más información, consulta Duración variable del estado Programado para eliminación.

Aunque el material de claves se destruye, las claves y los conjuntos de claves no se pueden eliminar. Las versiones de clave no se pueden eliminar, pero se puede destruir el material de la versión de la clave para que los recursos no se puedan utilizar más. Dado que ni los conjuntos de claves ni las claves tienen costes facturables ni limitaciones de cuota, su existencia no afectará a los costes ni a los límites de producción.

Una vez que se haya programado la eliminación de una versión de la clave, esta dejará de estar disponible para las operaciones criptográficas. Durante el periodo de eliminación pendiente, puedes restaurar la versión de la clave para que no se destruya.

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

Para evitar eliminar una clave por error, ten en cuenta estas prácticas recomendadas:

Define la restricción Duración programada mínima por clave con un valor más alto. Esta restricción define el tiempo mínimo del periodo programado para la destrucción de las claves nuevas.
Aplica la restricción Restringir la destrucción de claves a las claves inhabilitadas para que solo se puedan destruir las claves inhabilitadas. Para obtener más información, consulta Requerir que las claves se inhabiliten antes de destruirse.
Crea un rol de KMS personalizado que no incluya el permiso cloudkms.cryptoKeyVersions.destroy.
Cambia el campo destroy_scheduled_duration a un periodo más largo.
Monitoriza y añade alertas para los 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 deshabiliten la clave un par de días antes de que se elimine.

Dependencias de la infraestructura de Google

Los elementos de la plataforma de Cloud KMS se ejecutan como tareas producción de Borg. Borg es el gestor de clústeres a gran escala de Google dedicado al servicio de APIs y a las tareas por lotes.

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.

Tareas de servicio de la API de Cloud KMS

Las tareas de servicio de la API de Cloud KMS son tareas de producción de Borg que sirven las solicitudes de los clientes para gestionar y utilizar sus claves. Las tareas de servicio de la API de Cloud KMS también procesan acciones diferidas de las solicitudes de los clientes, como la rotación de claves programada, la creación de claves asimétricas y la importación de claves. Estas tareas se ejecutan en todas lasGoogle Cloud regiones en las que Cloud KMS está disponible. Cada tarea se asocia a una sola región y su configuración permite acceder únicamente a los datos de sistemas ubicados geográficamente en la misma región.Google Cloud

Tareas por lotes de Cloud KMS

La plataforma de Cloud KMS también tiene programada una serie de tareas por lotes que se ejecutan como tareas de producción de Borg. Las tareas por lotes son específicas de cada región y solo pueden añadir datos de la región asociada y ejecutarse en ella. Google CloudEntre otras, pueden realizar las siguientes tareas:

Contar las claves activas para la facturación de clientes.
Añadir recursos de la API pública de búfer de protocolo de Cloud KMS y reenviar los metadatos a Inventario de Recursos de Cloud. En este contexto, los recursos son todos aquellos que gestiona Cloud KMS, como claves y conjuntos de claves.
Añadir todos los recursos y generar informes de analíticas empresariales.
Capturar datos para mantener una alta disponibilidad.
Validar que ningún dato del almacén de datos subyacente tenga fallos.
Volver a encriptar el material de la clave del cliente cuando la clave maestra de KMS se va a rotar.

Capturador de claves de Cloud KMS

Para asegurar una alta disponibilidad, la plataforma de Cloud KMS mantiene un almacén de datos redundante en cada instancia del servicio compartido que aloja las tareas del servidor de la API de Cloud KMS. Cada servicio compartido despliega su propia instancia del servicio de captura. Gracias a esta redundancia, los servicios se vuelven muy independientes, de modo que los fallos que se dan en una zona tienen un efecto limitado en el resto. Cuando una tarea de la API de Cloud KMS debe hacer una operación criptográfica, realiza una consulta al almacén de datos principal y a las tareas de captura locales simultáneamente. Si el almacén de datos principal es lento o no está disponible, la respuesta se puede servir desde una captura, siempre que no tenga más de dos horas. Las capturas se crean como si fueran la salida de una tarea por lotes que se ejecuta de forma continua en cada región. Las capturas se encuentran en la región de Cloud asociada al material de la clave.

Comunicación cliente-servidor

Google utiliza Seguridad de transporte en la capa de la aplicación (ALTS) para proteger las comunicaciones entre el cliente y el servidor que usan los mecanismos de llamada a procedimiento remoto (RPC) de Google.

Para obtener más información, consulta el artículo Autenticación, integridad y cifrado entre servicios.

Entorno operativo de la plataforma de Cloud KMS

El entorno operativo de la plataforma de Cloud KMS incluye las políticas de seguridad y almacenamiento de datos, las restricciones de acceso y las estrategias de mitigación de riesgos diseñadas para optimizar la fiabilidad, la durabilidad y la disponibilidad a la vez que protegen el material de claves. En esta sección se describen la estructura operativa del servicio, las responsabilidades de los miembros del equipo de operaciones, los mecanismos de autenticación y los protocolos de auditoría y almacenamiento de registros. Esta sección se aplica tanto a las capacidades de las claves protegidas por software como por hardware.

Ingenieros de software, equipo de Site Reliability Engineering y operadores de sistemas

Los ingenieros de software se encargan de asociarse con otras partes, como con los responsables de productos y los miembros del equipo de Site Reliability Engineering (SRE), para diseñar el sistema y escribir gran parte del código y las pruebas del servicio de Cloud KMS. El código incluye la tarea principal que sirve las solicitudes de los clientes, así como trabajos secundarios dedicados a actividades como la replicación de datos y la facturación. Los SRE también pueden escribir código. Sin embargo, las obligaciones de los ingenieros de software y de los SRE están separadas. Los SRE se encargan principalmente del mantenimiento del entorno de producción de las tareas de Cloud KMS. Los SRE miden la fiabilidad y la obtienen a través de los procesos de ingeniería y operaciones.

Los operadores de sistemas lidian con el proceso de compilación y lanzamiento, la monitorización, las alertas y la planificación de la capacidad de Cloud KMS. También son los primeros en responder a los problemas de los clientes y atender las interrupciones de Cloud KMS. Por ejemplo, los operadores de sistemas aprovechan distintas herramientas y la automatización para minimizar el trabajo de los sistemas manuales y centrarse en las acciones que resultarán valiosas a largo plazo.

Las tareas de los operadores del sistema se definen en los procedimientos operativos estándar. Los operadores del sistema no acceden al material de claves de los clientes mientras realizan sus tareas.

Regionalización de los recursos de Cloud KMS

Para ayudarte a cumplir los requisitos de residencia de claves, puedes crear recursos de Cloud KMS en uno de los cuatro tipos de Google Cloud ubicaciones:

Una ubicación regional consta de diferentes zonas en un punto geográfico específico, como Iowa.
Una ubicación birregional consta de diferentes zonas en dos puntos geográficos específicos, como Iowa y Carolina del Sur.
Una ubicación multirregional consta de diferentes zonas repartidas en un área geográfica general, como Estados Unidos.
La ubicación mundial consta de diferentes zonas distribuidas por todo el mundo. Cuando creas tus recursos de Cloud KMS en la ubicación mundial, están disponibles en todas las zonas del mundo.

Las ubicaciones representan las regiones geográficas en las que se gestionan las solicitudes a Cloud KMS para un recurso determinado y donde 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.

Centros de datos y regiones de Cloud

Una Google Cloud región contiene un centro de datos específico o un conjunto concreto de centros de datos según su ubicación (una sola región, birregional, multirregional o mundial). Para obtener más información sobre las Google Cloud regiones, consulta las Google Cloud ubicaciones.

Cada centro de datos contiene bastidores de máquinas para la computación, las redes o el almacenamiento de datos, que utilizan la infraestructura de Borg de Google.

Los centros de datos de Google tienen unos requisitos de seguridad física estrictos. Es obligatorio que todo espacio físico que pueda contener datos de usuarios tenga lectores de tarjetas identificativas y reconocimiento de iris en la entrada para autenticar a los individuos. Las puertas no pueden permanecer abiertas para recibir a más de una persona a la vez. Se debe autenticar a cada uno de forma individual. En tales zonas, no está permitido entrar ni salir con bolso, con la salvedad de aquellos que sean transparentes y se autoricen de forma explícita una vez que el personal de seguridad los inspeccione. Se necesita un permiso especial para entrar o salir con cualquier dispositivo electrónico que pueda transmitir o grabar datos.

Residencia de claves

En algunos sectores es obligatorio que las claves criptográficas se encuentren en una ubicación específica. Cloud KMS tiene términos de ubicación de datos con garantías sobre la residencia de datos. Tal y como se explicaba anteriormente, en la sección sobre la regionalización de recursos de Cloud KMS, este servicio ofrece cuatro tipos de ubicaciones regionales para ayudarte a cumplir esos requisitos.

En el caso de las ubicaciones de una sola región, birregionales o multirregionales, Cloud KMS crea, almacena y procesa tus claves protegidas por software y por hardware, así como sus materiales, únicamente en esa ubicación. Los sistemas de almacenamiento y de procesamiento de datos que utiliza Cloud KMS están configurados de modo que solo se usan los recursos de laGoogle Cloud región asociada al material de la clave. El material de claves creado en ubicaciones birregionales o multirregionales no abandona los límites de las ubicaciones seleccionadas.

La región mundial no cuenta con ninguna garantía referente a la regionalización.

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

Al usar la CMEK, se aplican las siguientes restricciones geográficas de Cloud KMS a las claves, independientemente de las ubicaciones personalizadas, birregionales o multirregionales que selecciones en otros Google Cloud productos que admitan la CMEK:

Para una región específica: dado que la región de una clave de KMS gestionada por el cliente siempre debe estar relacionada con la región del recurso que protege en cualquier Google Cloud servicio, se garantiza e implementa la compatibilidad con las restricciones de residencia de recursos y claves en una sola región.
Para las ubicaciones birregionales o multirregionales: para garantizar el cumplimiento de la residencia, los usuarios pueden seleccionar cualquier ubicación multirregional definida por Google para sus claves y Google Cloud recursos. Para asegurar esta residencia geográfica, cerciórate de que las regiones de otros productos se corresponden con la ubicación regional de Cloud KMS que has elegido.

En la siguiente tabla se resume la residencia de los materiales de claves de Cloud KMS.

Tipo de región	En reposo y en uso
Una sola región	Residente
Dos regiones o varias regiones	Residente en las regiones que constituyen una ubicación birregional o multirregional

Monitorización de la regionalización

Los servicios internos de monitorización de datos de Google hacen un seguimiento de forma activa de la residencia de claves. Cloud KMS envía alertas a los miembros del equipo de SRE si detecta errores de configuración no intencionados o si el material de claves abandona los límites de la región configurada, se almacena en la región equivocada o se accede a él desde una región incorrecta.

Alta disponibilidad

Cloud KMS puede ayudarte a simplificar tus requisitos de disponibilidad en función de las regiones que selecciones. Cuanto más granular sea la ubicación, más redundancia tendrás que crear. En el caso de las aplicaciones con niveles de disponibilidad más altos, utiliza ubicaciones multirregión en lugar de intentar crear tu propio sistema de replicación de claves. Debes equilibrar las funciones de redundancia integradas con tus necesidades de regionalización de datos.

Autenticación y autorización

Cloud KMS acepta varios métodos de autenticación, como OAuth2, JWT y ALTS. Independientemente del mecanismo, Cloud KMS resuelve la credencial proporcionada para identificar la cuenta principal (la entidad que está autenticada y autoriza la solicitud) y llama a la gestión de identidades y accesos para comprobar si tiene permiso para realizar la solicitud y si se ha escrito un registro de auditoría.

Cloud KMS utiliza una versión interna de la API Service Control pública para diversos aspectos de la gestión de servicios. Antes de que una tarea de Cloud KMS gestione una solicitud, se envía una solicitud de comprobación a la API Service Control, que implementa varios controles que comparten todos los Google Cloud servicios, como los siguientes:

Comprobar si has activado la API de Cloud KMS y tienes una cuenta de facturación activa.
Comprobar que no has superado tu cuota e informar del uso de cuota.
Aplicar Controles de Servicio de VPC.
Comprobar si estás en la lista de permitidos de las regiones de nube privada correspondientes.

Gestión de cuotas

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

Cuotas de solicitudes criptográficas para operaciones como encriptar, desencriptar o firmar.
Cuotas de solicitudes de lectura para operaciones como obtener metadatos de claves u obtener una política de gestión de identidades y accesos.
Cuotas de solicitudes de escritura para operaciones como crear una clave o definir una política de gestión de identidades y accesos.

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

Cloud HSM y Cloud EKM tienen cuotas adicionales para las operaciones criptográficas. Estas cuotas deben cumplirse 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 se aplican a cada ubicación.

Ten en cuenta los siguientes ejemplos:

Para llamar a la función de descifrado con una clave de software en asia-northeast1, se necesita una unidad de la cuota de solicitudes criptográficas (global).
Para crear una clave de HSM en us-central1, se necesita una unidad de cuota de solicitudes de escritura y ninguna cuota de HSM.
Llamar a la función de cifrado con una clave de EKM en europe requiere una unidad de cuota de solicitudes criptográficas (global) y una unidad de cuota de solicitudes de KMS externo en europe.

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

Almacenamiento de registros

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

Registros de auditoría de Cloud

Cloud KMS registra tu actividad en los registros de auditoría de Cloud. Puedes ver estos registros en la consola de Cloud. Toda la actividad de administración (por ejemplo, crear o destruir una clave) se registra en estos registros. También puedes habilitar el registro de todas las demás acciones que usen una clave, como encriptar o desencriptar datos con una clave. Tú controlas durante cuánto tiempo quieres conservar los registros y quién puede verlos.

Registros de Transparencia de acceso

Los clientes que cumplan los requisitos pueden habilitar los registros de Transparencia de acceso, que reflejan las acciones que los empleados de Google realizan en tu organización deGoogle Cloud . Los registros de Transparencia de acceso, junto con los de los registros de auditoría de Cloud, pueden ayudarte a responder preguntas sobre quién hizo qué, dónde se hizo y cuándo se hizo.

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

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

Recurso afectado y acción realizada.
Hora en que se ha llevado a cabo la acción.
Los motivos de la acción. Por ejemplo, un caso de asistencia iniciado por el cliente (con el número del caso) o de asistencia por parte de Google, solicitudes de datos de terceros o solicitudes de revisión que ha iniciado Google.
Datos sobre quién ha realizado la acción (por ejemplo, la ubicación de un miembro del personal de Google).

Registros de solicitudes internas

Los registros de solicitudes recopilan cada solicitud que se envía a la plataforma de Cloud KMS. Este registro contiene detalles sobre el tipo de solicitud (como el método o el protocolo de la API) y el recurso al que se accede (como el nombre de recurso, el algoritmo de la clave o su nivel de protección). En estos registros no se almacena el texto sin formato del cliente, el texto cifrado ni el material de la clave. Antes de que se añadan nuevos tipos de datos a estos registros, un equipo especializado en revisiones de privacidad debe aprobar los cambios realizados en los datos registrados.

Las entradas de registro se eliminan de forma permanente cuando ha transcurrido el tiempo de vida configurado (TTL).

Los SRE de Cloud KMS y los ingenieros de turno pueden acceder a los registros de solicitudes. El acceso humano a los registros y el acceso que devuelva datos de clientes requiere una justificación empresarial válida y documentada. Con algunas excepciones concretas, el acceso humano queda registrado y los clientes que cumplen ciertos requisitos pueden ver esos registros de Transparencia de acceso.

Supervisión

Cloud KMS se integra con Cloud Monitoring. Esta integración te permite monitorizar muchas operaciones de Cloud KMS, crear paneles de control y configurar alertas. Por ejemplo, puedes monitorizar cuándo se programa la destrucción de claves o monitorizar y ajustar las cuotas de Cloud KMS cuando las operaciones criptográficas superen un umbral que definas. Para obtener más información sobre las métricas de Cloud KMS disponibles, consulta el artículo Usar Cloud Monitoring con Cloud KMS.

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

Siguientes pasos

Para obtener más información sobre Cloud KMS, consulta 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 cifrado enGoogle Cloud, consulta Claves de cifrado gestionadas por el cliente (CMEK).
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.

Cifrado de Cloud Key Management Service Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.