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 son propietarios de sus datos y deben controlar cómo se usan.

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

La plataforma de Cloud KMS permite a los clientes de Google Cloud administrar las claves criptográficas en un servicio central en la nube, ya sea para usarlas directamente o con el fin de que las usen otros recursos y aplicaciones de la nube. En cuanto al origen de las claves, Cloud KMS proporciona las siguientes opciones:

  • El backend de software de Cloud KMS te brinda la flexibilidad necesaria para encriptar los datos con una clave simétrica o asimétrica bajo tu control (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 (HSM) validados en función del nivel 3 del estándar FIPS 140-2.
  • Cloud KMS te permite importar tus propias claves criptográficas si necesitas usar claves que hayas generado tú mismo.
  • 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 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 usar las claves externas a fin de proteger los datos en reposo. Puedes usar claves de encriptación administradas por el cliente con una clave de Cloud EKM. Cloud EKM no se analiza en este informe.

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

“Diagrama de la cartera de productos de KMS”

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

  • Control del cliente. Cloud KMS te permite administrar claves de encriptación de software y hardware, o proporcionar tus propias claves.
  • Supervisión y control de acceso. Con Cloud KMS, puedes administrar permisos en claves individuales y supervisar cómo se usan las claves.
  • Regiones. Cloud KMS proporciona la función de regionalización lista para usar. El servicio se configura 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. Cloud KMS analiza todo el material y los metadatos de las claves y crea copias de seguridad de estos de forma periódica, para ayudar a proteger tus datos contra la corrupción y con el fin de verificar que los datos puedan desencriptarse de forma correcta.
  • Seguridad. Cloud KMS ofrece opciones de protección 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.

En este informe, se analizan las características internas de la plataforma de Cloud KMS que se encuentran en la versión de disponibilidad general (DG). 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 la toma de decisiones técnicas que necesitan detalles de la arquitectura, la infraestructura y las características de Cloud KMS. En él, se supone que tienes conocimientos básicos de conceptos de encriptación y arquitecturas de nube.

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

En esta sección, se definen algunos términos y conceptos 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, sus versiones y la agrupación en llaveros de claves. En el siguiente diagrama, se ilustran las agrupaciones de claves. Debajo de este, se incluyen las definiciones relacionadas.

“Diagrama de agrupaciones de claves”

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

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

    Cloud KMS admite claves asimétricas y simétricas. Una clave simétrica se usa para realizar la encriptación simétrica a fin de proteger corpus de datos. Por ejemplo, se puede usar AES-256 en modo GCM para encriptar un bloque de texto simple. Por su parte, una clave asimétrica se puede usar para realizar encriptación asimétrica o con el fin de crear firmas digitales. En la documentación de Cloud KMS, se describen los propósitos y algoritmos admitidos.

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

    Para evitar los conflictos con los 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 conocer más detalles de la eliminación de claves y materiales de claves, consulta la sección sobre eliminación que se encuentra más adelante en este documento.

  • Metadatos de la clave: son nombres de recursos, propiedades de recursos de KMS, como las políticas de IAM; el tipo, el tamaño y 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 una sola 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 de forma automática qué versión de la clave se necesita para llevar a cabo 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 servicio KMS interno de Google, ya que Cloud KMS une las claves encriptadas por Cloud KMS. Cloud KMS usa la misma raíz de confianza que Google KMS. Debajo del diagrama, se incluyen definiciones relacionadas.

“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 (el software, el hardware y los backends externos) te permiten controlar la clave de encriptación de claves.
  • Clave maestra de KMS: es la clave que se usa para encriptar la clave de encriptación de claves (KEK). Esta clave se distribuye en la memoria. Se crea una copia de seguridad de la clave maestra de KMS en los dispositivos de hardware. Esta clave es responsable de la encriptación de tus claves.
  • Root KMS: es el servicio de administración de claves interno de Google.

2.3. Operations

  • Proyecto: los recursos de Cloud KMS pertenecen a un proyecto de Google Cloud, como todos los otros recursos de Google Cloud. Puedes alojar datos en un proyecto que no sea aquel en el que se encuentran tus claves de Cloud KMS. Esta función admite 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 mediante claves respaldadas por hardware y por 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, de modo que puedas administrar los permisos en las claves individuales y controlar su uso.

“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 administración de claves mediante Google Cloud Console o la herramienta de línea de comandos de gcloud, o bien por medio de aplicaciones que implementan las API de REST o de 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). Las CMEK usan la API de Cloud KMS. La API de Cloud KMS te permite usar claves de software (Cloud KMS) o de hardware (Cloud HSM). Las claves basadas en software y las basadas en hardware usan las protecciones de copias de seguridad redundantes de Google.

En la plataforma de Cloud KMS, puedes elegir un nivel de protección cuando creas una clave a fin de determinar qué backend de clave creará la clave y realizará todas las operaciones criptográficas futuras en ella. La plataforma de Cloud KMS proporciona dos backends (se excluye Cloud EKM), que están expuestos en la API de Cloud KMS como los niveles de protección SOFTWARE y HSM. El nivel de protección SOFTWARE se aplica a las claves que pueden separarse por medio de un módulo de seguridad de software para realizar operaciones criptográficas. El nivel de protección HSM se aplica a las claves que solo pueden separarse por medio de módulos de seguridad de hardware que realizan todas las operaciones criptográficas con las claves.

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

Las operaciones criptográficas de Cloud KMS son realizadas por módulos validados en función del estándar FIPS 140-2. Las claves con nivel de protección SOFTWARE (y las operaciones criptográficas realizadas con ellas) cumplen con el nivel 1 del estándar FIPS 140-2. Las claves con nivel de protección HSM (y las operaciones criptográficas realizadas con ellas) cumplen con el nivel 3 del estándar FIPS 140-2.

3.1. Entorno y dependencias

En esta sección, se brindan detalles acerca de la infraestructura de Google en la que se ejecuta la plataforma de Cloud KMS y los protocolos de comunicaciones 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 Borg de producción. Borg es el administrador de clústeres a gran escala de Google para controlar los trabajos por lotes y los trabajos de entrega de API. Si deseas obtener detalles de 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.

3.1.1.1. Trabajos de entrega de API de Cloud KMS

Los trabajos de entrega de API de Cloud KMS son trabajos de Borg de producción que entregan las solicitudes de los clientes para administrar y usar sus claves. Estos trabajos de entrega se ejecutan en todas las regiones de Google Cloud en las que Cloud KMS está disponible. Cada trabajo está asociado con una sola región y está configurado para acceder solo a los datos de sistemas cuya ubicación geográfica está dentro de la región de Google Cloud asociada. Para obtener más información sobre la ubicación de las claves, consulta la sección Regiones, que se encuentra más adelante en este documento.

3.1.1.2. Trabajos por lotes de Cloud KMS

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

  • Calculan las claves activas para la facturación del cliente.
  • Agrupan recursos de la API de búfer de protocolo público de Cloud KMS y reenvían los metadatos a Cloud Asset Inventory. En este contexto, los recursos son cualquier recurso que administre Cloud KMS, como claves y llaveros de claves.
  • Agrupan todos los recursos y la información de informes para las estadísticas empresariales.
  • Generan instantáneas de los datos para lograr la alta disponibilidad.
  • Verifican que los datos almacenados en el almacén de datos subyacente no estén dañados.
  • Vuelven a encriptar el material de la clave de cliente cuando se rota la clave maestra de KMS.
3.1.1.3. Generador de instantáneas de la clave de Cloud KMS

A fin de mantener la alta disponibilidad, la plataforma de Cloud KMS mantiene un almacén de datos redundante en cada instancia de un servicio compartido en el que se alojan las tareas del servidor de la API de Cloud KMS. Cada servicio implementa su propia instancia del servicio de generador de instantáneas. Gracias a esta redundancia, los servicios son muy independientes, de modo que una falla en una zona tiene un efecto limitado en otras zonas. Cuando el trabajo de la API de Cloud KMS necesita realizar una operación criptográfica, consulta el almacén de datos principal junto con los trabajos del generador de instantáneas local, en simultáneo. Luego, la API de Cloud KMS usa el trabajo que complete la solicitud de forma correcta primero. Para evitar que se genere un retraso en la canalización de generación de instantáneas que podría ocasionar la entrega de datos demasiado obsoletos, el servidor de la 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 resultado de un trabajo por lotes que se ejecuta de forma continua para cada región. Se ubican en la región de la nube asociada con el material de la clave.

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 a las comunicaciones entre el cliente y el servidor (encriptación en tránsito) en las que se usa el mecanismo de llamada de procedimiento remoto (RPC) de Google. El sistema ALTS proporciona lo siguiente:

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

Los protocolos de enlace y de encriptación de registros de ALTS son similares a los protocolos de enlace y de registros de la seguridad de la capa de transporte (TLS). El sistema ALTS realiza distintas concesiones a fin de optimizar para el entorno de producción de Google, y está completamente integrado en todo el hardware de producción y la pila de software. Para conocer más detalles, consulta la sección Entorno operativo de la plataforma de Cloud KMS, que se encuentra más adelante en este documento.

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

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

En esta sección también se describen las opciones de 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 que se presentaron hasta el momento, este documento describe el ciclo de vida de una solicitud de Cloud KMS, y se incluye un análisis sobre la destrucción del material de las claves.

4.1. Seguridad de los materiales de las claves

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

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

Las solicitudes de los clientes a Cloud KMS se encriptan en tránsito mediante el uso de TLS entre el cliente y Google Front End (GFE). La Seguridad de transporte de la capa de la aplicación (ALTS), que se describió antes en la sección sobre comunicaciones entre el cliente y el servidor, se usa para la encriptación entre los trabajos de Cloud KMS y sus backends en diferentes centros de datos. El sistema ALTS y la encriptación en tránsito se describen de forma más detallada en la sección Ciclo de vida de una solicitud de Cloud KMS, que se encuentra más adelante en este documento.

La autenticación ocurre entre todos los trabajos de KMS, ya sea dentro de los centros de datos de Google o entre ellos.

La política de Google consiste en garantizar que los trabajos usen solo código fuente que se haya compilado, probado y revisado de manera verificable. La autorización binaria para Borg (BAB) aplica esta política a nivel operativo, y sus características se describen de forma más detallada en esta documentación sobre seguridad.

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

Sin embargo, los trabajos de la API de Cloud KMS no pueden acceder al material de una clave, y este material no se puede exportar ni ver a través de la interfaz de la API ni de ninguna otra interfaz de usuario. Ningún empleado de Google tiene acceso al material de las claves de cliente no encriptado. Además, el material de las claves se encripta con una clave maestra en Root KMS, a la que ningún individuo 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 del cliente en reposo. Cada servidor de Cloud KMS recupera una copia de la clave maestra durante el inicio como una dependencia excesiva, y, todos los días, se recupera una copia nueva de la clave maestra. La clave maestra se vuelve a encriptar de forma periódica.

4.2.2. Política de rotación

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

4.2.3. Residencia de datos

Los datos subyacentes de cada almacén de datos de Cloud KMS permanecen de forma exclusiva dentro de la región de Google Cloud a la que están asociados los datos. Esto también se aplica a las ubicaciones que son multirregiones, como us. Para obtener más detalles sobre la ubicación de los datos, consulta la sección Regiones, que se encuentra más adelante en este documento.

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

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

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

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

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 está validado en función del estándar FIPS 140-2. El objeto binario de Cloud KMS está compilado a partir de los algoritmos criptográficos primitivos de este módulo validados en función del nivel 1 del estándar FIPS 140-2. Los algoritmos más actuales que abarca este módulo se enumeran en nuestra página de documentación. Entre ellos, se incluyen las operaciones de encriptación, desencriptación y firmado con claves simétricas AES256-GCM y claves asimétricas RSA 2048, RSA 3072, RSA 4096, EC P256 y EC P384.

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

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

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

El servicio de Cloud HSM proporciona claves respaldadas por hardware a Cloud KMS. Ofrece a los clientes la capacidad de administrar y usar claves criptográficas que están protegidas por módulos de seguridad de hardware completamente administrados (HSM) en centros de datos de Google. El servicio cuenta con alta disponibilidad y ajuste de escala automático horizontal. Las claves están vinculadas criptográficamente 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 pertenece a la región que se especificó en el momento de la creación de la clave. Mediante Cloud HSM, puedes certificar de forma verificable que tus claves criptográficas se crearon y se usan de forma exclusiva dentro de un dispositivo de hardware. No se requieren cambios en las aplicaciones de clientes existentes de Cloud KMS para usar Cloud HSM: se accede a los servicios de Cloud HSM mediante la misma API y las mismas bibliotecas cliente que usa el backend de software de Cloud KMS.

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

4.5.1. HSM de Cavium

El proveedor valida que la tarjeta PCIe de los HSM de Cavium cumple con el nivel 3 del estándar FIPS 140-2. El certificado actual está disponible si se lo solicita.

4.5.2. Jerarquía de claves de HSM

En el siguiente diagrama, se muestra Cloud KMS en la mitad superior. 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.

“Diagrama de la jerarquía de claves de HSM”

El Cloud HSM tiene una clave (no se muestra) que controla la migración de material dentro del dominio administrativo de Cloud HSM. Es posible que una región tenga varios dominios administrativos de HSM.

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

  1. Se genera en un HSM y, a lo largo de su existencia, nunca sale de los límites bien definidos de los HSM. Se puede replicar en otros HSM o en copias de seguridad de los HSM.
  2. Se puede usar como clave de encriptación de claves para unir directa o indirectamente las claves del cliente que los HSM usan.

Las claves del cliente unidas por medio de las claves raíz de HSM se pueden usar en el HSM, pero este nunca muestra el texto simple de la clave de cliente. El 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 estas 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 tema se describe en detalle en la sección Backend del almacén de datos, que se encuentra más adelante en este documento.

4.5.4. Política de rotación

Hay varios tipos de claves involucrados en la estrategia de protección de claves de Cloud HSM. Los clientes rotan sus claves y confían en Cloud KMS para rotar las claves de HSM.

4.5.5. Proceso de aprovisionamiento y control

El aprovisionamiento de HSM se lleva a cabo en un lab equipado con numerosas protecciones físicas y lógicas, entre las que se incluyen, por ejemplo, los controles de autorización de varias partes para ayudar a evitar el peligro de un solo agente.

A continuación, se incluyen variantes a nivel de sistema de Cloud HSM:

  1. Las claves de cliente no se pueden extraer como texto simple.
  2. Las claves de cliente no se pueden llevar fuera de la región de origen.
  3. Todos los cambios en la configuración de HSM aprovisionados están protegidos por medio de varios métodos 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 registro.
  5. Los HSM están diseñados para tener protección contra la alteración (como la inserción de hardware malicioso, las modificaciones de software o la extracción de Secrets no autorizada) durante todo el ciclo de vida operativo.

4.5.6. Firmware controlado por el proveedor

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

4.5.7. Regiones

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 en particular. Por ejemplo, una clave que se creó de forma específica en la región us-west1 no se puede migrar a la región us-east1 ni a una multirregión us. Del mismo modo, una clave que se creó en la multirregión us no se puede migrar a la región us-west1 o fuera de ella.

4.6. Cloud KMS: Importación de claves

Recomendamos que importes tus claves a tu entorno de nube. Por ejemplo, puede que tengas un requisito normativo que indique que las claves que usas para encriptar los datos de la nube deben generarse de una forma en particular o en un entorno específico. Cloud KMS te permite importar las claves criptográficas que creaste de forma local o en un External Key Manager. La importación de claves te permite importar estas claves y cumplir con estas obligaciones normativas. También puedes importar claves asimétricas para extender tus 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. Si encriptas el material de tus claves con esta clave de unión, se protege el material 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 le corresponde a esta clave pública se almacena dentro de Google Cloud y se usa para separar la clave una vez que llega al proyecto de Google Cloud. El método de importación que elijas determinará el algoritmo que se usará para crear la clave de unión. Cuando el material de tu clave esté unido, podrás importarlo a una clave o versión de clave nueva en Cloud KMS.

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

Para Cloud HSM, la parte de clave privada de la clave de unión está disponible solo dentro de Cloud HSM. Esta restricción impide que Google una el material de tu clave fuera de Cloud HSM.

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

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

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

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

Consulta esta documentación para obtener la lista completa de integraciones de CMEK y servicios compatibles con CMEK. Google continúa invirtiendo en la integración de CMEK para otros productos de Google Cloud.

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 que se presentaron hasta ahora, en esta sección, se describe el ciclo de vida de una solicitud de Cloud KMS, incluido un análisis sobre la destrucción del material de una clave.

“Diagrama del ciclo de vida de una solicitud de KMS”

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

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

4.9. Destrucción del material de una clave

En este informe, se describe el proceso de eliminación de datos en Google Cloud. Se considera que el material de una clave son datos del cliente, por lo que el método que se describe en el informe se aplica a Cloud KMS. Además, debido a que Google nunca comparte el material de una clave fuera de Cloud KMS, este se destruye a pedido cuando se cumple el período de eliminación pendiente de 24 horas y las copias de seguridad se vencen. Este proceso no se garantiza para las copias de claves importadas que existen fuera del control de Cloud KMS.

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

Una vez que se programa su destrucción, la versión de una clave no está disponible para operaciones criptográficas. El usuario puede restablecer la versión de la clave para que no se destruya dentro de un período de 24 horas.

5. Entorno operativo de la plataforma de Cloud KMS

Dentro del entorno operativo de la plataforma de Cloud KMS, se incluyen políticas de seguridad y almacenamiento de datos, restricciones de acceso y estrategias de mitigación de riesgos que se diseñaron para optimizar la confiabilidad, la durabilidad y la disponibilidad, a la vez que se protege el material de las claves. En esta sección, se analizan la estructura operativa, las responsabilidades de los miembros del equipo de operaciones, los mecanismos de autenticación y los protocolos de auditoría y registro del servicio. El análisis que se incluye a continuación se aplica a las capacidades de las claves respaldadas por software y por 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 los administradores de productos y los ingenieros de confiabilidad de sitios (SRE), con el fin de diseñar el sistema y, en última instancia, escribir la mayor parte del código y las pruebas para el servicio de Cloud KMS. El código incluye el trabajo principal que entrega las solicitudes del cliente, además de trabajos secundarios para actividades como la replicación de datos y la facturación. También es posible que los SRE escriban código. Sin embargo, las obligaciones de los ingenieros de software y de los SRE están separadas. La responsabilidad principal de los SRE es mantener el entorno de producción para los trabajos de Cloud KMS. Los SRE miden y alcanzan la confiabilidad mediante trabajo de ingeniería y operaciones.

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

5.2. Regiones de los recursos de Cloud KMS

Hay cuatro tipos de ubicaciones de Google Cloud en los que puedes crear recursos de Cloud KMS:

  • Ubicaciones regionales: una ubicación regional consiste en zonas dentro de un espacio geográfico específico, como Iowa.
  • Ubicaciones birregionales: una ubicación birregional 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 Estados Unidos.
  • Ubicación global: La ubicación global consiste en zonas de todo el mundo. Cuando creas tus recursos de Cloud KMS en la ubicación global, están disponibles desde zonas de todo el mundo.

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

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

5.2.1. Regiones de Cloud y centros de datos

Una región de Google Cloud contiene un centro de datos específico o un conjunto de centros de datos específico, que se determina por su clasificación como una sola región, una birregión, 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 cuentan con requisitos de seguridad física estrictos. Cualquier espacio físico en el que puede haber datos de usuarios requiere de entradas con lectores de credenciales o escáneres de iris a fin de autenticar la identidad de quienes ingresan. No se debe mantener las puertas abiertas para que ingresen varias personas a la vez, sino que cada persona debe autenticar su identidad de forma individual. No se puede ingresar a estas áreas ni salir de ellas con bolsos, a menos que sean transparentes y se hayan autorizado de forma explícita luego de una inspección por parte del personal de seguridad. Se requiere un permiso especial para ingresar o salir con cualquier dispositivo electrónico que pueda transmitir o registrar datos.

5.2.2. Regiones

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

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

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

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

Cuando usas CMEK, las siguientes restricciones geográficas de Cloud KMS se aplican a tus claves, sin importar las ubicaciones personalizadas, birregionales o multirregionales que elijas en otros productos de Google Cloud que deseas usar con CMEK:

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

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

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

5.2.3. Supervisión de las regiones

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

5.3. Autenticación y autorización

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

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

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

5.4. Registros

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

5.4.1. Registros de auditoría de Cloud

Cloud KMS registra la actividad de los clientes en los registros de auditoría de Cloud. Los clientes pueden ver estos registros en Cloud Console. Toda la actividad del administrador, como la creación o la destrucción de una clave, se ingresa en estos registros. Los clientes también pueden optar por habilitar los registros para cualquier otra acción en la que se use una clave, como el uso de una clave en la encriptación o desencriptación de datos. Los clientes controlan durante cuánto tiempo desean conservar los registros, además de quién puede verlos.

5.4.2. Registros de Transparencia de acceso

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

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

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

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

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 protocolo o método de API) y el recurso al que se accede (como el nombre del recurso, el algoritmo de la clave o el nivel de protección de la clave). Estos registros no almacenan texto simple, texto cifrado ni material de la clave del cliente. Antes de que se agreguen nuevos tipos de datos a estos registros, un equipo que se especializa en las revisiones de privacidad debe aprobar los cambios a los datos que están registrados.

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

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

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 admite varios sistemas cruciales de Google.

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

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

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

El equipo de Cloud KMS cuenta con procedimientos documentados para restablecer copias de seguridad en caso de emergencia.

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

Protección. En la capa de la aplicación de Cloud KMS, el material de las claves de clientes se encripta antes de su almacenamiento. Los ingenieros del almacén de datos no tienen acceso al material de las claves de clientes en formato de texto simple. Además, el almacén de datos encripta todos los datos que administra antes de escribir en el almacenamiento permanente, por lo 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 a 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: