Análisis detallado de Cloud Key Management Service

Autores: Sonal Shah, Il-Sung Lee, Walter Poupore, Hunter Freyer,Honna Segel, Dwight Worley

Agradecimientos: Adrian Sears, John Randolph, Tim Dierks, Chris Rezek,Stanley McKenzie, Kevin Plybon, David Hale, Sergey Simakov,David U. Lee, Carrie McDaniel, Anton Chuvakin, Dave Tonisson

Última actualización: Abril de 2020

1. Introducción

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

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

La plataforma de Cloud KMS permite que los clientes de Google Cloud administren claves criptográficas en un servicio de nube central para usarlas directamente o para que otras aplicaciones y recursos de la nube las usen. Para la fuente de claves, Cloud KMS ofrece las siguientes opciones:

  • El backend de software de Cloud KMS te brinda la flexibilidad de encriptar tus datos con una clave simétrica o asimétrica que tú controlas (Cloud KMS).
  • Si necesitas una clave de hardware, puedes usar Cloud HSM para garantizar que tus claves simétricas y asimétricas solo se usen en módulos de seguridad de hardware validados en función de FIPS 140-2 nivel 3 (HSM).
  • Cloud KMS te permite importar tus propias claves criptográficas en caso de que necesites usar las claves que generas.
  • 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 se usan para proteger los datos en otros servicios de Google Cloud.
  • Con Cloud External Key Manager (Cloud EKM), puedes crear y administrar claves en un administrador de claves externo a Google Cloud y, luego, configurar la plataforma de Cloud KMS para que use las claves externas a fin de proteger tus datos en reposo. Puedes usar claves de encriptación administradas por el cliente con una clave de Cloud EKM. Por el momento, Cloud EKM no está dentro del alcance de este informe.

Google también admite claves de encriptación proporcionadas por el cliente (CSEK) para Compute Engine y Cloud Storage, mediante las cuales los datos se desencriptan y se encriptan con una clave proporcionada en la llamada a la API. CSEK no se analiza en este documento. Para obtener más información, consulta la documentación en línea.

“Diagrama de cartera de KMS”

Con Cloud KMS, el enfoque de Google es proporcionar una solución escalable, confiable y eficaz, con el amplio espectro de opciones que puedes controlar y en una plataforma que es fácil de usar. Cloud KMS se basa en cinco pilares de diseño:

  • Control de clientes. Cloud KMS te permite administrar claves de encriptación de software y hardware o proporcionar tus propias claves.
  • Control de acceso y supervisión. Con Cloud KMS, puedes administrar permisos para claves individuales y supervisar cómo se usan las claves.
  • Regiones. Cloud KMS ofrece regionalización lista para usar. El servicio está configurado para crear, almacenar y procesar claves de software solo en la región de Google Cloud que selecciones.
  • Durabilidad. Cloud KMS cumple con los estándares de durabilidad más altos de Google Cloud. Para ayudar a protegerte contra la corrupción de datos y para verificar que los datos puedan desencriptarse de forma correcta, Cloud KMS analiza y crea copias de seguridad de todo el material y los metadatos de las claves de forma periódica.
  • Seguridad. Cloud KMS ofrece protecciones sólidas contra el acceso no autorizado a las claves y está completamente integrado en los controles de la administración de identidades y accesos (IAM) y de los registros de auditoría de Cloud.

Este artículo se centra en el funcionamiento interno de la plataforma de Cloud KMS que corresponde a la versión de disponibilidad general (GA). Estas opciones te ayudan a proteger las claves y otros datos sensibles que almacenas en Google Cloud. El informe está destinado a los encargados de tomar decisiones técnicas que necesitan detalles sobre la arquitectura, la infraestructura y las características de Cloud KMS. En este documento, se supone que conoces los conceptos básicos de la encriptación y de las arquitecturas de la nube.

2. Conceptos de encriptación y administración de claves en Google

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

2.1. Claves, versiones de claves y llaveros de claves

En esta sección, se describen las claves, las versiones de claves y la agrupación de claves en llaveros de claves. En el siguiente diagrama se ilustran los agrupamientos de claves. Las definiciones relacionadas siguen el diagrama.

“Diagrama de agrupaciones de claves.”

  • Clave: un objeto con nombre que representa una clave criptográfica con un propósito específico. El material de la clave (los bits reales que se usan para las operaciones criptográficas), puede cambiar con el tiempo a medida que creas versiones nuevas de la clave.

    El propósito de la clave y otros atributos se conectan y administran mediante la clave. Por lo tanto, la clave es el objeto más importante para comprender el uso de KMS.

    Cloud KMS admite claves asimétricas y simétricas. Se usa una clave simétrica en la encriptación simétrica para proteger algunos corpus de datos. Por ejemplo, se usa AES-256 en modo GCM para encriptar un bloque de texto simple. Se puede usar una clave asimétrica para la encriptación asimétrica o para crear firmas digitales. Los algoritmos y los propósitos compatibles se describen en la documentación de Cloud KMS.

  • Llavero de claves: Es una agrupación de claves para 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 IAM del llavero de claves que las contiene. Si agrupas las claves que tienen permisos relacionados en un llavero de claves, puedes otorgar, revocar o modificar los permisos de ellas en el nivel del llavero de claves sin tener que realizar acciones en cada una de ellas de forma individual. Los llaveros de claves te proporcionan conveniencia y categorización, pero si el grupo de llaveros de claves no te resulta útil, puedes administrar los permisos directamente en las claves.

    Para evitar colisiones de nombres de recursos, no se puede borrar un llavero de claves. 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. Para obtener más detalles sobre la eliminación de claves y materiales de claves, consulta la sección sobre eliminación más adelante en este artículo.

  • Metadatos de la clave: son nombres de recursos, propiedades de recursos de KMS, como políticas de IAM, el tipo de clave, el tamaño de la clave, el estado de la clave y cualquier dato derivado de lo anterior. Los metadatos de la clave se pueden administrar de manera diferente al material de la clave.

  • Versión de la clave: representa 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, y se comienza con 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 limita el uso de cualquier versión. Las claves simétricas siempre tendrán una versión principal. Esta versión se usa para la encriptación de forma predeterminada. Cuando Cloud KMS realiza la desencriptación con claves simétricas, identifica automáticamente qué versión de la clave se necesita para realizar la desencriptación.

2.2. Jerarquía de claves

En el siguiente diagrama, se ilustra la jerarquía de claves del servicio de administración de claves interno de Google. Cloud KMS aprovecha el KMS interno de Google para que las claves encriptadas por Cloud KMS estén unidas por Google KMS. Cloud KMS usa la misma raíz de confianza que Google KMS. Las definiciones relacionadas siguen el diagrama.

“Diagrama de la jerarquía de claves interna”

  • Clave de encriptación de datos (DEK): Es una clave que se usa para encriptar datos.
  • Clave de encriptación de claves (KEK): Es una clave que se usa para encriptar o unir una clave de encriptación de datos. Todas las opciones de la plataforma de Cloud KMS (software, hardware y backends externos) te permiten controlar la clave de encriptación de claves.
  • Clave maestra de KMS: Es la clave que se usa para encriptar las claves de encriptación de claves (KEK). Esta clave se distribuye en la memoria. Se crean copias de seguridad de la clave maestra de KMS en los dispositivos de hardware. Esta clave se encarga de encriptar tus claves.
  • Root KMS: Es el servicio de administración de claves interno de Google.

2.3. Operaciones

  • Proyecto: Los recursos de Cloud KMS pertenecen a un proyecto de Google Cloud, al igual que todos los demás recursos de Google Cloud. Puedes alojar datos en un proyecto que no sea aquel en el que residen tus claves de Cloud KMS. Esta capacidad es compatible con la práctica recomendada de separación de obligaciones entre los administradores de claves y los administradores de datos.
  • Ubicaciones: Dentro de un proyecto, los recursos de Cloud KMS se crean en una ubicación. Para obtener más información, consulta Geografía y regiones.

3. 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 con claves respaldadas por hardware y software. La plataforma de Cloud KMS está integrada en la Administración de identidades y accesos (IAM) y en los registros de auditoría de Cloud para que puedas administrar los permisos en claves individuales y auditar cómo se usan.

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 Google Cloud Console o la herramienta de línea de comandos de gcloud, o mediante aplicaciones que implementan las API de REST o gRPC. Las aplicaciones acceden a los servicios de administración de claves mediante una API de REST o gRPC. Las aplicaciones pueden usar los servicios de Google que están habilitados para usar claves de encriptación administradas por el cliente (CMEK). A su vez, CMEK usa la API de Cloud KMS. La API de Cloud KMS te permite usar claves de software (Cloud KMS) o hardware (Cloud HSM). Las claves basadas en software y hardware aprovechan las protecciones de copias de seguridad redundantes de Google.

Con la plataforma de Cloud KMS, puedes elegir un nivel de protección cuando creas una clave para determinar qué backend crea la clave y realiza todas las operaciones criptográficas futuras en esa clave. La plataforma de Cloud KMS ofrece dos backends (excepto Cloud EKM) que se exponen en la API de Cloud KMS como los niveles de protección de SOFTWARE y HSM. El nivel de protección de SOFTWARE se aplica a las claves que un módulo de seguridad de software puede separar a fin de realizar operaciones criptográficas. El nivel de protección de HSM se aplica a las claves que solo los módulos de seguridad de hardware pueden separar a fin de realizar todas las operaciones criptográficas con las claves.

Google Cloud admite CMEK para varios servicios, incluidos Cloud Storage, BigQuery y Compute Engine. CMEK te permite usar la plataforma de Cloud KMS para administrar las claves de encriptación que usan estos servicios a fin de proteger tus datos.

Las operaciones criptográficas de Cloud KMS se realizan mediante FIPS 140-2, módulos validados. Las claves con nivel de protección de SOFTWARE, y las operaciones criptográficas realizadas con ellas, cumplen con el estándar FIPS 140-2 nivel 1. Las claves con nivel de protección de HSM, y las operaciones criptográficas realizadas con ellas, cumplen con el estándar FIPS 140-2 nivel 3.

3.1. Entorno y dependencias

En esta sección, se proporcionan detalles sobre la infraestructura de Google en la que se ejecuta la plataforma de Cloud KMS y los protocolos de comunicación que usa la infraestructura.

3.1.1. Trabajos de Borg de Cloud KMS

Los elementos de la plataforma de Cloud KMS se ejecutan como trabajos de producción de Borg. Borg es el administrador de clústeres a gran escala de Google para administrar los trabajos de entrega y los trabajos por lotes de la API. Para obtener más detalles sobre la seguridad de nuestra infraestructura física y de producción, consulta Descripción general del diseño de seguridad de la infraestructura de Google.

3.1.1.1. Trabajos de entrega de la API de Cloud KMS

Los trabajos de entrega de la API de Cloud KMS son trabajos de Borg de producción que entregan las solicitudes de los clientes para administrar y usar sus claves. Estos trabajos de entrega se ejecutan en cada región de Google Cloud en la que Cloud KMS está disponible. Cada trabajo está asociado con una sola región y está configurado para acceder solo a los datos de los sistemas ubicados geográficamente en la región de Google Cloud asociada. Para obtener más información sobre la residencia de claves, consulta Regionalidad más adelante en este artículo.

3.1.1.2. Trabajos por lotes de Cloud KMS

La plataforma de Cloud KMS también mantiene una cantidad de trabajos por lotes que se ejecutan como trabajos de producción de Borg en diferentes 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 ella. Las tareas que realizan estos trabajos incluyen las siguientes:

  • Recuento de claves activas para la facturación del cliente
  • Agregar recursos desde la API de búfer de protocolo público de Cloud KMS y reenviar los metadatos a Cloud Asset Inventory. Los recursos en este contexto son cualquier recurso que administre Cloud KMS, por ejemplo, claves y llaveros de claves
  • Agregar todos los recursos y la información de informes para las estadísticas empresariales
  • Hacer instantáneas de los datos para obtener una alta disponibilidad
  • Validar que los datos almacenados en el almacén de datos subyacente no se corrompan
  • Volver a encriptar el material de la clave del cliente cuando se rota la clave maestra de KMS
3.1.1.3. Generador de instantáneas de la clave de Cloud KMS

Para mantener una alta disponibilidad, la plataforma de Cloud KMS mantiene un almacén de datos redundante en cada instancia de un servicio compartido que aloja las tareas del servidor de la API de Cloud KMS. Cada servicio implementa su propia instancia del servicio de generador de instantáneas. Esta redundancia hace que los servicios sean muy independientes, de manera que una falla en una zona tenga 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 y los trabajos del generador de instantáneas local en paralelo. Luego, la API de Cloud KMS usa el trabajo que completa la solicitud primero. Para evitar un retraso en la canalización de la generación de la instantánea de modo que se entreguen datos demasiado obsoletos, el servidor de API no usa los resultados de los trabajos del generador de instantáneas si los datos tienen más de dos horas de antigüedad. Las instantáneas se crean como el resultado de un trabajo por lotes que se ejecuta de forma continua para cada región. Las instantáneas residen en la región de la nube asociada con el material de la clave.

3.1.2. Comunicaciones entre el cliente y el servidor

Google usa la seguridad de transporte de la capa de la aplicación (ALTS) para proporcionar seguridad para las comunicaciones de cliente-servidor (encriptación en tránsito) que usan el sistema de llamada de procedimiento remoto (RPC) de Google. ALTS proporciona lo siguiente:

  • Un protocolo de autenticación entre pares para aplicaciones
  • Un protocolo de encriptación de registros
  • Una API que expone al usuario autenticado para la autorización

Los protocolos encriptación de enlace y registro de ALTS son similares a los protocolos de enlace y registro de la seguridad de la capa de transporte (TLS). ALTS realiza distintas compensaciones para optimizar el entorno de producción de Google, y está completamente integrado en toda la pila de hardware y software de producción. Para obtener más información, consulta Entorno operativo de la plataforma de Cloud KMS más adelante en este artículo.

4. Detalles de la arquitectura de la plataforma de Cloud KMS

En esta sección, se analizan en profundidad los detalles arquitectónicos, comenzando por la seguridad del material de las claves y la protección del almacén de datos. Luego, se detallan las opciones para la fuente del material de las claves:

En esta sección, también se describen las opciones para las claves de encriptación administradas por el cliente (CMEK).

Para proporcionar una vista dinámica de cómo se usan las estructuras arquitectónicas presentadas hasta el momento, este documento describe el ciclo de vida de una solicitud de Cloud KMS, incluido un debate sobre la destrucción del material de las claves.

4.1. Seguridad del material de las claves

En Cloud KMS, el material de las claves siempre está encriptado en reposo y en tránsito. El material de las claves 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 del cliente se rota o se verifica su integridad

Las solicitudes de clientes a Cloud KMS se encriptan en tránsito mediante TLS entre el cliente y Google Front End (GFE). La seguridad de transporte de la capa de la aplicación (ALTS), descrita anteriormente en la sección sobre comunicaciones entre clientes y servidores, se usa para la encriptación entre trabajos de Cloud KMS y sus backends en diferentes centros de datos. ALTS y la encriptación en tránsito se describen con más detalle en Ciclo de vida de una solicitud de Cloud KMS más adelante en este artículo.

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

La política de Google es garantizar que los trabajos solo usen código fuente compilado, probado y revisado de manera verificable. La autorización binaria para Borg (BAB) aplica esta política a nivel operativo y se describe con más detalle en esta documentación de seguridad.

Los trabajos de la API de Cloud KMS pueden acceder a los metadatos de las claves (por ejemplo, la política de IAM o el período de rotación). Un empleado de Google con una justificación comercial válida y documentada (como un error o un problema del cliente) también puede acceder a los metadatos de las claves. Los accesos se registran internamente y los registros que pertenecen a los datos cubiertos por la Transparencia de acceso también están disponibles para los clientes calificados.

Sin embargo, los trabajos de la API de Cloud KMS no pueden acceder al material de las claves, y este material no se puede exportar ni ver a través de la interfaz de API ni ninguna otra interfaz de usuario. Ningún empleado de Google tiene acceso al material de las claves de clientes no encriptado. Además, el material de las claves se encripta con una clave maestra en Root KMS, a la que nadie puede acceder directamente.

4.2. Protección del almacén de datos

En esta sección, se describe cómo Google KMS protege los datos de las claves.

4.2.1. Claves maestras

Cloud KMS usa una clave maestra para unir todas las claves de cliente en reposo. Cada servidor de Cloud KMS recupera una copia de la clave maestra durante el inicio como una dependencia excesiva y se recupera una copia nueva de la clave maestra cada día. La clave maestra se vuelve a encriptar periódicamente.

4.2.2. Política de rotación

La rotación de claves es parte de las prácticas recomendadas generalmente aceptadas para el manejo de material de las claves. Existe una política de rotación para las claves que se usan a fin de proteger los almacenes de datos de Cloud KMS. También se aplica una política de rotación de claves a las claves maestras de KMS internas de Google que unen las claves de Cloud KMS. La clave maestra de KMS tiene un texto cifrado con una antigüedad máxima programada de 90 días con una antigüedad máxima de un día para la clave de cliente almacenada en caché. Cloud KMS actualiza las claves maestras en las tareas de KMS cada 24 horas y vuelve a encriptar todas las claves de cliente de forma mensual.

4.2.3. Residencia de datos

Los datos subyacentes a cada almacén de datos de Cloud KMS permanecen exclusivamente dentro de la región de Google Cloud con la que están asociados. Esto también se aplica a las ubicaciones multirregionales, por ejemplo, a la multirregión us. Para obtener más información sobre la residencia de los datos, consulta Regionalidad más adelante en este artículo.

4.3. Disponibilidad de claves después de la creación

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

4.4. Backend de software de Cloud KMS: nivel de protección de SOFTWARE

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

4.4.1. 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 es validado en función de FIPS 140-2. El objeto binario de Cloud KMS se compila en función de las primitivas criptográficas validadas a partir de FIPS 140-2 nivel 1 de este módulo. Los algoritmos más actuales que abarca este módulo se enumeran en nuestra página de documentación y, además, incluyen operaciones de encriptación, desencriptación y firma con claves simétricas AES256-GCM y claves asimétricas RSA 2048, RSA 3072, RSA 4096, EC P256 y EC P384.

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

Cuando se generan claves de encriptación, Cloud KMS usa BoringSSL. FIPS 140-2 requiere que se usen sus propios PRNG (también conocidos como DRBG). En BoringCrypto, Cloud KMS usa CTR-DRBG exclusivamente con AES-256. Esto proporciona un resultado para RAND_bytes, la interfaz principal a partir de la cual el resto del sistema obtiene datos aleatorios. Este PRNG se propaga a partir del RNG del kernel de Linux, que se propaga desde varias fuentes de entropía independientes. Esta propagación incluye eventos entrópicos del entorno del centro de datos, como mediciones detalladas de las búsquedas en discos y las horas de llegada de paquetes, y la instrucción RDRAND de Intel, cuando está disponible. Para obtener más información sobre el comportamiento del generador de números aleatorios para BoringSSL (modo compatible con FIPS), consulta el diseño de RNG.

4.5. Backend de HSM de Cloud KMS: nivel de protección de HARDWARE

El servicio Cloud HSM proporciona claves respaldadas por hardware a Cloud KMS. Ofrece a los clientes la capacidad de administrar y usar claves criptográficas protegidas por los módulos de seguridad de hardware (HSM) completamente administrados en los centros de datos de Google. El servicio tiene alta disponibilidad y ajuste de escala automático horizontal. Las claves están vinculadas de forma criptográfica a la región de KMS en la que se definió el llavero de claves. Con Cloud HSM, las claves que creas y usas no se pueden materializar fuera del clúster de HSM que pertenecen a la región especificada en el momento de la creación de la clave. Con Cloud HSM, puedes demostrar de manera verificable que tus claves criptográficas se crean y usan exclusivamente en un dispositivo de hardware. No se necesitan cambios en las aplicaciones para que los clientes existentes de Cloud KMS usen Cloud HSM: se accede a los servicios de Cloud HSM mediante la misma API y las mismas bibliotecas cliente con las que se accede al backend de software de Cloud KMS.

Cloud HSM usa HSM validadas por FIPS 140-2 nivel 3 y que siempre se ejecutan en modo FIPS. El estándar FIPS especifica los la generación de números aleatorios y algoritmos criptográficos que usan los HSM.

4.5.1. HSM Cavium

El proveedor valida que la tarjeta PCIe Cavium cumple con el estándar FIPS 140-2 Nivel 3. El certificado actual está disponible a pedido.

4.5.2. Jerarquía de las claves de HSM

En el siguiente diagrama, vemos Cloud KMS en la mitad superior del diagrama. Cloud HSM une las claves del cliente y, luego, Cloud KMS une las claves de HSM que se pasan al almacén de datos de Google.

Cloud HSM tiene una clave (no se muestra) que controla la migración de material dentro del dominio administrativo de Cloud HSM. Una región puede tener varios dominios administrativos de HSM.

La clave raíz de HSM tiene dos características:

  1. Se genera en un HSM y durante todo su ciclo de vida nunca deja los límites bien definidos de los HSM. Se puede replicar en otros HSM o en copias de seguridad de HSM.
  2. Se puede usar como una clave de encriptación de claves para unir de forma directa o indirecta las claves de cliente que usan los HSM.

Las claves de cliente unidas por las claves raíz de HSM se pueden usar en el HSM, pero el HSM nunca muestra el texto sin formato de la clave de cliente. HSM solo usa la clave de cliente para las operaciones.

4.5.3. Protección del almacén de datos

Los HSM no se usan como almacenamiento permanente para las claves. Solo almacenan claves mientras se usan. Debido a que el almacenamiento de HSM es limitado, las claves de HSM se encriptan y almacenan en el almacén de datos de claves de Cloud KMS. Este asunto se describe en detalle en Backend del almacén de datos más adelante en este artículo.

4.5.4. Política de rotación

Varios tipos de claves están involucradas en la estrategia de protección de claves de Cloud HSM. Los clientes rotan sus propias claves y confían en Cloud KMS para rotar las claves de HSM.

4.5.5. Proceso de aprovisionamiento y gestión

El aprovisionamiento de HSM se lleva a cabo en un lab equipado con numerosas protecciones físicas y lógicas, incluidos los controles de autorización de varias partes, para ayudar a prevenir poner en peligro a un solo departamento.

Las siguientes son variantes dentro del nivel de sistema de Cloud HSM:

  1. Las claves de cliente no se pueden extraer como texto sin formato.
  2. Las claves de cliente no se pueden mover fuera de la región de origen.
  3. Todos los cambios de configuración en los HSM aprovisionados se protegen a través de varias protecciones de seguridad.
  4. Las operaciones administrativas se registran y cumplen con la separación de obligaciones entre los administradores de Cloud HSM y los administradores de registros.
  5. Los HSM están diseñados para protegerse contra la manipulación (como la inserción de hardware malicioso o modificaciones de software, o la extracción de secretos no autorizada) durante todo el ciclo de vida operativo.

4.5.6. Firmware controlado por el proveedor

El proveedor de HSM proporciona su firma digital en el firmware de HSM. Google no puede crear ni actualizar el firmware del HSM. Todo el firmware del proveedor está firmado, incluido el firmware de desarrollo que se usa para las pruebas.

4.5.7. Regionalidad

Las claves de cliente se asignan a regiones geográficas específicas como resultado de su vinculación a una clave raíz de HSM específica. Por ejemplo, una clave creada específicamente en la región us-west1 no puede migrar a la región us-east1 o a una multirregión us. Del mismo modo, una clave creada en la multirregión us no puede migrar hacia o desde la región us-west1.

4.6. Cloud KMS: importación de claves

Recomendamos que importes tus propias claves a tu entorno de nube. Por ejemplo, puede que tengas un requisito reglamentario según el cual las claves usadas para encriptar tus datos de la nube deban generarse de una manera o en un entorno específico. Cloud KMS te permite importar tus propias claves criptográficas que creaste de forma local o en un administrador de claves externo. La importación de claves te permite importar estas claves y cumplir con estas obligaciones reglamentarias. También puedes importar claves asimétricas para extender las capacidades de firma a la nube.

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

Esta clave de unión pública de Cloud KMS se usa para encriptar, en el cliente, la clave que se importará. La clave privada que coincide con esta clave pública se almacena en Google Cloud y se usa para separar la clave después de que llega al proyecto de Google Cloud. El método de importación que elijas determina el algoritmo utilizado para crear la clave de unión. Después de unir el material de tu clave, puedes importarlo a una nueva clave o versión de clave en Cloud KMS.

Las claves importadas se pueden usar con el nivel de protección HSM o SOFTWARE.

La porción de clave privada de la clave de unión está disponible solamente en Cloud HSM. La restricción de la porción de clave privada a Cloud HSM evita que Google una tu material de clave fuera de Cloud HSM.

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

De forma predeterminada, Google Cloud encripta todos los datos del cliente 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 para administrar las claves que se usan en la encriptación. CMEK se puede usar para claves respaldadas por hardware y software. Cloud KMS permite al cliente controlar muchos aspectos de las claves (como crear, habilitar/inhabilitar, rotar y destruir claves) y administrar los permisos de IAM adecuados para ellas. Cloud KMS incluye varias funciones de IAM predefinidas que tienen limitaciones y privilegios específicos y que se pueden otorgar a usuarios y cuentas de servicio específicos para aplicar una separación recomendada de obligaciones.

En los siguientes temas, se proporcionan detalles sobre los productos integrados en la plataforma de Cloud KMS que admite CMEK:

El impacto de la rotación de claves en la versión de clave usada depende de cómo un producto implementa CMEK. En general, la rotación de la clave de Cloud KMS no vuelve a encriptar los datos en el servicio de CMEK asociado. Por ejemplo, BigQuery no rota de forma automática una clave de encriptación de tabla cuando la clave de Cloud KMS asociada a la tabla se rota. Las tablas existentes de BigQuery continúan usando la versión de clave con la que se crearon. Las nuevas tablas de BigQuery usan la versión actual de la clave. Para obtener más información, consulta la documentación de cada producto.

Consulta esta documentación para obtener una lista completa de las integraciones de CMEK y los servicios que cumplen con CMEK. Google sigue invirtiendo en la integración de CMEK para otros productos de Google Cloud.

4.8. Ciclo de vida de una solicitud de Cloud KMS

Para proporcionar una vista dinámica de cómo se usan las estructuras de arquitectura hasta ahora, esta sección describe el ciclo de vida de una solicitud de Cloud KMS, incluido un análisis sobre la destrucción de material de claves.

Los pasos en este ciclo de vida incluyen los siguientes:

  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 de Google Front End (GFE).
  2. GFE proporciona hosting de IP pública de su nombre de DNS público, protección contra denegación del servicio (DoS) y finalización de TLS. Cuando el cliente envía su solicitud, por lo general, se enruta a un GFE cerca del cliente, independientemente de la ubicación a la cual se orienta la solicitud. Los GFE manejan 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) enruta 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 la solicitud está dirigida a us-west1, la solicitud 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 ALTS, que autentica de forma mutua los trabajos de GFE y Cloud KMS.
  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 verificar estos aspectos:
    • El cliente tiene una credencial válida y puede autenticarse.
    • El proyecto de Google Cloud tiene habilitada la API de Cloud KMS y tiene 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 rechazarán la solicitud.
  5. Después de que se aprueban estas verificaciones, el framework reenvía la solicitud y la credencial a Cloud KMS. Cloud KMS analiza la solicitud a fin de determinar a qué recursos se accede y, luego, verifica con IAM para ver si el emisor está autorizado a realizar la solicitud. IAM también le indica a Cloud KMS si la solicitud se debe escribir 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 obtener el recurso solicitado. Una vez recuperado, se desencripta el material de la clave de cliente para su uso.
  7. Con el material de la clave, Cloud KMS luego realiza la operación criptográfica y reenvía la versión unida de la clave al backend del software de Cloud KMS o al HSM de Cloud, según el nivel de protección de la clave.
  8. Una vez que se completa la operación criptográfica, la respuesta se envía al cliente a través del mismo tipo de canal de GFE a KMS.
  9. Como se muestra la respuesta, Cloud KMS también activa algunos eventos de forma asíncrona:
    • Los registros de auditoría y solicitudes se completan y se ponen en cola para escribirse.
    • Los informes se envían para la facturación y la administración de las cuotas.
    • 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.

4.9. Destrucción del material de una clave

En este informe, se describe cómo borrar datos en Google Cloud. El material de la clave se considera datos del cliente, por lo que el enfoque que describe el informe se aplica a Cloud KMS. Además, debido a que Google nunca comparte el material de la clave fuera de Cloud KMS, este se destruye a pedido cuando se completa el período de eliminación pendiente de 24 horas y las copias de seguridad caducan. Este proceso no está garantizado para copias de claves importadas que existen fuera del control de Cloud KMS.

Mientras que el material de las claves se destruye como se describió anteriormente, las claves y los llaveros de claves no se pueden borrar. Las versiones de clave tampoco se pueden borrar, pero el material de clave que contienen 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.

Una vez que está programada su destrucción, no hay una versión de clave disponible para las operaciones criptográficas. Durante el período de 24 horas, el usuario puede restablecer la versión de clave para que no se destruya.

5. Entorno operativo de la plataforma de Cloud KMS

El entorno operativo de la plataforma de Cloud KMS incluye políticas de seguridad y almacenamiento de datos, restricciones de acceso y estrategias de mitigación de riesgos diseñadas para optimizar la confiabilidad, la durabilidad y la disponibilidad, al mismo tiempo que protegen el material de las claves. En esta sección, se analiza 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 registro. El debate siguiente aplica a las capacidades de clave respaldadas por software y hardware.

5.1. 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 administradores de productos y, también, ingenieros de confiabilidad de sitios (SRE), para diseñar el sistema y, en última instancia, escribir gran parte del código y de las pruebas para el servicio de Cloud KMS. El código incluye el trabajo principal que entrega solicitudes de clientes, así como trabajos secundarios para actividades como la replicación de datos y la facturación. Los SRE también pueden escribir código. Sin embargo, los ingenieros de software y los equipos de SRE están separados. Los SRE son, en su mayoría, responsables de mantener el entorno de producción para los trabajos de Cloud KMS. Los SRE miden y logran la confiabilidad a través del trabajo de ingeniería y operaciones.

Los operadores del sistema son responsables del proceso de compilación y lanzamiento, la supervisión, las alertas y la planificación de la capacidad para Cloud KMS. Son los primeros en responder a los problemas y las interrupciones de los clientes de Cloud KMS. Como ejemplo, los operadores del sistema aprovechan herramientas y automatización para minimizar el trabajo manual de los sistemas a fin de que puedan enfocarse en los esfuerzos que aportan valor a largo plazo.

5.2. Regionalidad de los recursos de Cloud KMS

Puedes crear recursos de Cloud KMS en uno de estos cuatro tipos de ubicaciones de Google Cloud:

  • Ubicaciones regionales: Una ubicación regional consiste en zonas dentro de un espacio geográfico específico, como Iowa.
  • Ubicaciones regionales duales: Una ubicación regional dual consiste en zonas en dos lugares geográficos específicos, como Iowa y Carolina del Sur.
  • Ubicaciones multirregionales: Una ubicación multirregional consiste en zonas distribuidas en un área geográfica general, como los Estados Unidos.
  • La ubicación global. La ubicación global consiste en zonas distribuidas en todo el mundo. Cuando creas tus recursos de Cloud KMS en la ubicación global, estos están disponibles en zonas de todo el mundo.

Las ubicaciones representan las regiones geográficas en las que se administran las solicitudes a Cloud KMS para 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 la documentación de Cloud KMS.

5.2.1. Regiones de nube 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, determinado por su clasificación como una sola región, una región doble, una multirregión o una ubicación 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 tienen requisitos de seguridad física estrictos. Para los espacios físicos que pueden contener datos del usuario, se requieren entradas con lectores de credenciales o escáneres de iris usados para autenticar a quienes ingresan. Las puertas no se abren a fin de que ingresen varias personas. Cada persona debe autenticarse individualmente. No se permite ingresar ni salir de estas áreas con bolsos, a menos que sean transparentes y que estén autorizados de manera explícita después de la 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 grabar datos.

5.2.2. Regionalidad

En algunos sectores, es necesario que las claves criptográficas se encuentren en una ubicación específica. Como se mencionó anteriormente en Regionalidad de los recursos de Cloud KMS, Cloud KMS ofrece cuatro tipos de ubicaciones regionales para ayudarte a cumplir con esos requisitos.

Para ubicaciones de una sola región, de región doble 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 de región doble o multirregionales no deja los límites de las ubicaciones seleccionadas.

Para la región global, no se especifica ninguna garantía de regionalidad.

Cloud KMS no garantiza la residencia de metadatos de las claves, registros de uso ni 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 desees usar con CMEK:

  • Para una región específica: Debido a que la región de una clave de KMS administrada por el cliente siempre debe correlacionarse con la región del recurso que protege en un servicio de Google Cloud determinado, se garantiza que las restricciones de residencia de las claves y los recursos de una sola región sean compatibles y que se apliquen.
  • Para ubicaciones de región doble o multirregionales: Los usuarios pueden elegir correlacionar 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 las regiones de otros productos estén alineadas con la ubicación regional de Cloud KMS que elijas.

En la siguiente tabla, se resumen las ubicaciones del material de las claves para Cloud KMS.

Residencia de datos de Cloud KMS En reposo, en uso
(una sola región)
En reposo, en uso
(región doble/multirregión)
Material de la clave de software Residente Residente en las regiones que constituyen la región doble o la multirregión.
Material de la clave de hardware (HSM) Residente Residente en las regiones que constituyen la región doble o la multirregión.

5.2.3. Supervisión de regionalidad

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

5.3. Autenticación y autorización

Cloud KMS acepta una variedad de mecanismos de autenticación, como OAuth2, JWT y ALTS. Independientemente del mecanismo, Cloud KMS resuelve la credencial proporcionada para identificar el principal (la entidad que se autentica y que autoriza la solicitud) y llama a IAM para ver si el principal está autorizado a realizar la solicitud y si se escribe un registro de auditoría.

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

  • Verificar si el cliente activó la API de Cloud KMS y tiene una cuenta de facturación activa
  • Verificar si el cliente no superó su cuota y, luego, informar el uso de esta
  • Aplicar los Controles del servicio de VPC
  • Verificar si el cliente está en la lista de anunciantes permitidos de las regiones de nube privadas aplicables

5.4. Logging

Tres tipos de registros están asociados con Cloud KMS: registros de Cloud Audit Logging, registros de la Transparencia de acceso y registros de solicitudes internas.

5.4.1. Registros de auditoría de Cloud

Cloud KMS registra la actividad del cliente en los registros de Cloud Audit Logs. Los clientes pueden ver estos registros en Cloud Console. Toda la actividad del administrador, por ejemplo, la creación o destrucción de una clave, se registra en estos registros. Los clientes también pueden optar por habilitar el registro de todas las otras acciones en las que se usa una clave, como el uso de una clave para encriptar o desencriptar datos. Los clientes controlan por cuánto tiempo desean conservar los registros y quiénes pueden verlos.

5.4.2. Registros de Transparencia de acceso

Los clientes aptos pueden optar por habilitar los registros de Transparencia de acceso, que proporcionan registros de 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 sobre quién hizo qué, dónde y cuándo.

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

Las entradas de registro de Transparencia de acceso incluyen los siguientes tipos de detalles:

  • Acción y recurso afectados
  • Hora de la acción
  • Motivos de la acción. Algunos ejemplos de motivos 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)

5.4.3. 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 método o protocolo 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 sin formato, texto cifrado ni material de las claves. Antes de agregar nuevos tipos de datos a estos registros, un equipo que se especializa en revisiones de privacidad debe aprobar los cambios en los datos que se registran.

Las entradas de registro se borran de forma permanente cuando expira 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 se puede acceder a él para clasificar a los clientes en los registros de la Transparencia de acceso.

5.5. Backend 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 es compatible con varios sistemas críticos de Google.

Durabilidad. Cloud KMS usa la encriptación autenticada para almacenar el material de las claves de cliente en el almacén de datos. Además, todos los metadatos se autentican con 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 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 correctamente. Si se daña algún dato, los ingenieros de Cloud KMS recibirán una alerta de inmediato para que puedan tomar medidas.

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

  • De forma predeterminada, el almacén de datos mantiene un historial de cambios de cada fila durante varias horas. En una emergencia, esta vida útil se puede extender para proporcionar más tiempo para solucionar problemas.
  • Cada hora, el almacén de datos registra una instantánea. La instantánea se puede validar y usar para el restablecimiento, si es necesario. Estas instantáneas se conservan durante cuatro días.
  • Todos los días se copia una copia de seguridad completa en el disco y la cinta.

El equipo de Cloud KMS ha documentado los procedimientos para restablecer las copias de seguridad en emergencias.

Residencia. Las copias de seguridad del almacén de datos de Cloud KMS residen en su región asociada de Google Cloud. Estas copias de seguridad están encriptadas en reposo. El acceso a los datos en las copias de seguridad se bloquea en función de las justificaciones de acceso (como un número de ticket que solicitaste al equipo de asistencia de Google) y el acceso humano se registra en los registros de Transparencia de acceso.

Protección. En la capa de la aplicación de Cloud KMS, el material de las claves del cliente se encripta antes de que se almacene. Los ingenieros de Datastore no tienen acceso al material de las claves de cliente 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 que el acceso a las capas de almacenamiento subyacentes, incluidos los discos o la cinta, no permitiría el acceso a los datos encriptados de Cloud KMS sin acceso las claves de encriptación del almacén de datos, que se almacenan en el KMS interno de Google.

6. Lecturas adicionales

Para obtener más información, explora los siguientes recursos:

Informes:

Otra documentación: