Información pormenorizada sobre Cloud Key Management Service

Autores: Sonal Shah, Il-Sung Lee, Walter Poupore, Hunter Freyer, Honna Segel y 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 y Dave Tonisson

Última actualización: abril del 2020

1. Introducción

Google Cloud parte de la premisa de que sus clientes tienen la propiedad de sus datos y son quienes deben controlar cómo se utilizan.

Cuando almacenas tus datos con Google Cloud, de forma predeterminada, se encriptan en reposo. Con nuestra plataforma de Cloud Key Management Service (Cloud KMS), puedes controlar en mayor medida cómo se encriptan tus datos en reposo y cómo se gestionan las claves de encriptado.

La plataforma de Cloud KMS permite a los clientes de Google Cloud gestionar claves criptográficas en un servicio central basado en la nube central para usarlas de manera directa o permitir que lo hagan otros recursos y aplicaciones en la nube. Cloud KMS ofrece las siguientes opciones de orígenes de claves:

  • El backend del software de Cloud KMS te ofrece flexibilidad a la hora de encriptar tus datos mediante una clave simétrica o asimétrica que tú controlas (Cloud KMS).
  • Si necesitas una clave de hardware, puedes usar Cloud HSM para asegurarte de que tus claves simétricas y asimétricas se usan exclusivamente en los módulos de seguridad de hardware (HSM) con validación FIPS 140‑2 de nivel 3.
  • Cloud KMS te permite importar tus propias claves criptográficas en caso de que debas usar las claves que generas por tu cuenta.
  • Puedes usar las claves generadas por Cloud KMS con otros servicios de Google Cloud. Estas claves se conocen como claves de encriptado gestionadas por el cliente (CMEK). La función de CMEK te permite generar, usar, rotar y eliminar las claves de encriptado que se utilizan para proteger datos en otros servicios de Google Cloud.
  • Con Cloud External Key Manager (Cloud EKM), puedes crear y gestionar claves en un gestor de claves ajeno a Google Cloud y utilizarlas para proteger tus datos en reposo en Cloud KMS. Para ello, debes configurar la plataforma de modo que permita usar claves externas. Puedes usar claves de encriptado gestionadas por el cliente con una clave de Cloud EKM. Sin embargo, este informe no abarca el uso de Cloud EKM.

Google también admite claves de encriptado proporcionadas por el cliente (CSEK) en Compute Engine y Cloud Storage, donde los datos se encriptan y desencriptan con una clave que se proporciona en la llamada a la API. Sin embargo, este documento no abarca el uso de las CSEK. Si quieres obtener más información, consulta la documentación online.

"Diagrama de la cartera de KMS"

Con Cloud KMS, Google pretende proporcionar una solución escalable, fiable y eficiente con un amplio abanico de opciones bajo tu control en una plataforma sencilla. El diseño de Cloud KMS cuenta con cinco pilares:

  • Control de clientes. Cloud KMS te permite gestionar las claves de encriptado de software y hardware, o bien proporcionar tus propias claves.
  • Control de acceso y monitorización. Con Cloud KMS, puedes gestionar los permisos de claves concretas y monitorizar cómo se usan.
  • Regionalización. Cloud KMS te permite regionalizar tus claves de forma inmediata. El servicio está configurado para crear, almacenar y procesar claves de software únicamente en la región de Google Cloud que selecciones.
  • Durabilidad. Cloud KMS cumple los estándares de durabilidad más exigentes de Google Cloud. El servicio analiza periódicamente los metadatos y el material de claves. También hace copias de seguridad de ellos para evitar que se dañen los datos y comprobar que se pueden desencriptar correctamente.
  • Seguridad. Cloud KMS ofrece un sistema de protección eficaz contra el acceso no autorizado a las claves y está completamente integrado con los controles de gestión de identidades y accesos y de los registros de auditoría de Cloud.

Este informe se centra en las funciones internas de la plataforma de Cloud KMS que están presentes en la versión con disponibilidad general (GA). Estas opciones te ayudan a proteger las claves y otros datos sensibles que almacenas en Google Cloud. Este documento está dirigido a los responsables de la toma de decisiones técnicas que necesitan conocer los detalles de la arquitectura, la infraestructura y las funciones de Cloud KMS. Se presupone que el lector tiene conocimientos básicos sobre el encriptado y las arquitecturas de nube.

2. Conceptos sobre el encriptado y la gestión de claves en Google

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

2.1. Claves, versiones de claves y conjuntos de claves

En esta sección se describen las claves, las versiones de claves y la agrupación de claves en conjuntos de claves. En el siguiente diagrama se muestra la agrupación de claves. Después, se definen algunos aspectos relacionados.

"Diagrama de la agrupación de claves".

  • Clave: un objeto con nombre que representa una clave criptográfica que se utiliza para un fin específico. El material de la clave, es decir, la información que se utiliza para las operaciones criptográficas, puede cambiar a medida que creas nuevas versiones de la clave.

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

    Cloud KMS admite claves simétricas y asimétricas. El encriptado simétrico utiliza claves simétricas para proteger conjuntos de datos. Por ejemplo, puedes usar el cifrado AES-256 en modo GCM para encriptar un bloque de texto sin formato. Por otra parte, las claves asimétricas sirven tanto para el encriptado asimétrico como para crear firmas digitales. En la documentación de Cloud KMS se describen los usos y algoritmos admitidos.

  • Conjunto de claves: agrupación de claves con fines organizativos. Los conjuntos de claves pertenecen a un proyecto de Google Cloud y se encuentran en una ubicación específica. Las claves heredan las políticas de gestión de identidades y accesos del conjunto de claves que las contiene. Si agrupas las claves con permisos relacionados en un mismo conjunto, puedes conceder, revocar o modificar los permisos de esas claves a nivel del conjunto de claves, sin tener que hacerlo individualmente con cada una de ellas. Los conjuntos de claves proporcionan comodidad y ayudan a categorizar las claves, pero si el agrupamiento no te resulta útil, puedes gestionar los permisos directamente en las claves.

    Para evitar los conflictos entre nombres de recursos, los conjuntos de clave no se pueden eliminar. Dado que ni los conjuntos de claves ni las claves tienen costes facturables ni limitaciones de cuota, su existencia no afectará a los costes ni a los límites de producción. Para obtener más información sobre cómo eliminar claves y sus materiales, consulta la sección sobre la eliminación que aparece más adelante en este documento.

  • Metadatos de claves: nombres y propiedades de recursos de KMS, como políticas de gestión de identidades y accesos, tipo, tamaño o estado de la clave y cualquier dato derivado de la información anterior. Los metadatos de claves se pueden gestionar de forma diferente que los materiales de claves.

  • Versión de la clave: representa el material asociado a esa clave en un momento dado. La versión de la clave es el recurso que contiene el material de la clave propiamente dicho. Las versiones se numeran secuencialmente, empezando por la versión 1. Cada vez que se rota una clave, se crea otra versión con material de clave nuevo. La misma clave lógica puede tener varias versiones con el paso del tiempo, lo que limita el uso de cualquier versión. Las claves simétricas siempre tienen una versión primaria que se utiliza de forma predeterminada para el encriptado. Cuando Cloud KMS realiza el desencriptado mediante claves simétricas, se identifica automáticamente qué versión de la clave hace falta.

2.2. Jerarquía de claves

En el siguiente diagrama se muestra la jerarquía de claves del servicio de gestión de claves interno de Google. Cloud KMS aprovecha el KMS interno de Google en tanto que las claves encriptadas de Cloud KMS las encapsula Google KMS. Cloud KMS utiliza la misma raíz de confianza que Google KMS. Después del diagrama, se definen algunos aspectos relacionados.

"Diagrama de la jerarquía interna de claves"

  • Clave de encriptado de datos (DEK): se usa para encriptar datos.
  • Clave de encriptado de claves (KEK): se utiliza para encriptar o encapsular las claves de encriptado de datos. Todas las opciones de la plataforma de Cloud KMS (software, hardware y backends externos) te permiten controlar la clave de encriptado de claves.
  • Clave maestra de KMS: sirve para encriptar las claves de encriptado de claves (KEK). Esta clave se distribuye en la memoria y sus copias de seguridad se crean en dispositivos de hardware. Esta clave es la encargada de encriptar tus claves.
  • Root KMS: el servicio de gestió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 el resto de los recursos de Google Cloud. Puedes alojar datos en un proyecto diferente al que incluye tus claves de Cloud KMS. De este modo, se fomenta la práctica recomendada de separación de obligaciones entre los administradores de claves y de datos.
  • Ubicaciones: los recursos de Cloud KMS se crean en una ubicación dentro de un proyecto. Para obtener más información, consulta el artículo sobre geografía y regiones.

3. Información general sobre 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 software y hardware. La plataforma de Cloud KMS está integrada con la gestión de identidades y accesos y los registros de auditoría de Cloud para que puedas gestionar los permisos de claves concretas y realizar auditorías de 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 gestión de claves con la consola de Google Cloud o la herramienta de línea de comandos gcloud, o a través de aplicaciones que implementan las API REST o gRPC. Las aplicaciones acceden a los servicios de gestión de claves con una API REST o gRPC. Además, pueden aprovechar los servicios de Google habilitados para usar claves de encriptado gestionadas por el cliente (CMEK). Las CMEK a su vez usan la API de Cloud KMS. La API de Cloud KMS te permite usar tanto claves de software (Cloud KMS) como de hardware (Cloud HSM). Ambas utilizan las protecciones de copias de seguridad redundantes de Google.

La plataforma de Cloud KMS te permite elegir un nivel de protección a la hora de crear una clave para determinar con qué backend de claves se crea y se realizan todas las operaciones criptográficas futuras de esa clave. La plataforma de Cloud KMS ofrece dos backends (excepto Cloud EKM), que se identifican 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 puede desencapsular 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 desencapsular los 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 gestionar las claves de encriptado que usan estos servicios para proteger tus datos.

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

3.1. Entorno y dependencias

En esta sección se proporciona información sobre la infraestructura de Google que aprovecha la plataforma de Cloud KMS y los protocolos de comunicación que utiliza tal infraestructura.

3.1.1. Tareas de Borg en Cloud KMS

Los elementos de la plataforma de Cloud KMS se ejecutan como tareas producción de Borg. Borg es el gestor de clústeres a gran escala de Google dedicado al servicio de APIs y a las tareas por lotes. Para obtener más información sobre la seguridad de nuestra infraestructura física y de producción, consulta la descripción general del diseño de seguridad de la infraestructura de Google.

3.1.1.1. Tareas de servicio de la API de Cloud KMS

Las tareas de servicio de la API de Cloud KMS son tareas de producción de Borg que sirven las solicitudes de los clientes para gestionar y utilizar sus claves. Estas tareas se ejecutan en todas las regiones de Google Cloud en las que Cloud KMS está disponible. Cada tarea se asocia a una sola región y su configuración permite acceder únicamente a los datos de sistemas ubicados geográficamente en la misma región de Google Cloud. Para obtener más información sobre la residencia de claves, consulta el apartado sobre la regionalización más adelante.

3.1.1.2. Tareas por lotes de Cloud KMS

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

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

Para asegurar una alta disponibilidad, la plataforma de Cloud KMS mantiene un almacén de datos redundante en cada instancia de los servicios compartidos que alojan las tareas del servidor de la API de Cloud KMS. Cada servicio despliega su propia instancia del servicio de captura. Gracias a esta redundancia, los servicios se vuelven muy independientes, de modo que los fallos que se dan en una zona tienen un efecto limitado en el resto. Cuando una tarea de la API de Cloud KMS debe hacer una operación criptográfica, realiza una consulta al almacén de datos principal y a las tareas de captura locales simultáneamente. La API de Cloud KMS usa la tarea que complete correctamente la solicitud primero. Para evitar cualquier retraso en el flujo de procesamiento de capturas que pueda provocar que se sirvan datos demasiado inactivos, el servidor de la API no utiliza los resultados de las tareas de captura si han transcurrido más de dos horas. Las capturas se crean como si fueran la salida de una tarea por lotes que se ejecuta de forma continua en cada región. Las capturas se encuentran en la región de Cloud asociada al material de la clave.

3.1.2. Comunicación cliente-servidor

Google utiliza el sistema Seguridad de transporte en la capa de la aplicación (ALTS) para proteger las comunicaciones entre el cliente y el servidor (encriptado en tránsito) que usan los mecanismos de llamada a procedimiento remoto (RPC) de Google. ALTS proporciona lo siguiente:

  • Un protocolo de autenticación de punto a punto para las aplicaciones
  • Un protocolo de encriptado de registros
  • Una API que expone al usuario autenticado para la autorización

Los protocolos handshake y de encriptado de registros de ALTS son similares a los protocolos handshake y Record de Seguridad en la capa de transporte (TLS). ALTS sacrifica ciertos aspectos para optimizar el entorno de producción de Google. Además, está totalmente integrada en la pila de software y hardware de producción. Para obtener más información, consulta la sección sobre el entorno operativo de la plataforma de Cloud KMS más adelante.

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

En esta sección se ahonda en los detalles de la arquitectura. En primer lugar, se hablará de la seguridad del material de claves y la protección del almacén de datos y luego se abordarán las opciones referentes al origen del material de claves:

En esta sección también se describen las opciones de claves de encriptado gestionadas por el cliente (CMEK).

Este informe explica el ciclo de vida de una solicitud de Cloud KMS y también aborda la destrucción del material de claves para ilustrar de manera más dinámica cómo se utilizan las estructuras arquitectónicas que se han descrito hasta ahora.

4.1. Seguridad del material de claves

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

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

Las solicitudes de los clientes a Cloud KMS se encriptan en tránsito con TLS entre el cliente y el Google Front End (GFE). La Seguridad de transporte en la capa de la aplicación (ALTS), descrita anteriormente en la sección sobre las comunicaciones cliente-servidor, se utiliza para el encriptado entre las tareas de Cloud KMS y sus backends en diferentes centros de datos. Más adelante, en la sección sobre el ciclo de vida de las solicitudes de Cloud KMS, se describen el encriptado en tránsito y ALTS más detalladamente.

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

La política de Google trata de asegurar que los trabajos utilizan únicamente código fuente desarrollado, probado y revisado de forma verificable. La autorización binaria para Borg (BAB) aplica esta política a nivel operativo. Para obtener más detalles al respecto, consulta esta documentación de seguridad.

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

Sin embargo, las tareas de la API de Cloud KMS no pueden acceder al material de claves, que tampoco se puede exportar ni consultar a través de la interfaz de la API ni de otra interfaz de usuario. Ningún empleado de Google tiene acceso al material de claves de clientes sin encriptar. Además, el material de claves se encripta con una clave maestra en Root KMS a la que no puede acceder directamente ningún usuario.

4.2. Protección del almacén de datos

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

4.2.1. Claves maestras

Cloud KMS utiliza una clave maestra para encapsular todas las claves de clientes en reposo. Cada servidor de Cloud KMS obtiene una copia de la clave maestra durante el inicio, como una dependencia fija, y cada día se genera una copia nueva de esa clave. La clave maestra se vuelve a encriptar periódicamente.

4.2.2. Política de rotación

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

4.2.3. Residencia de datos

Los datos subyacentes en cada almacén de datos de Cloud KMS permanecen exclusivamente en la región de Google Cloud a la que están asociados los datos. Esto también afecta a las ubicaciones que tienen varias regiones, por ejemplo, la multirregión us. Para obtener más información sobre la residencia de datos, consulta la sección sobre la regionalización más adelante.

4.3. Disponibilidad de claves después de crearlas

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

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

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

4.4.1. Implementaciones algorítmicas

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

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

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

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 posibilidad de usar y gestionar claves criptográficas protegidas por módulos de seguridad de hardware (HSM) totalmente gestionados en los centros de datos de Google. El servicio tiene una alta disponibilidad y autoescalado horizontal. Las claves están vinculadas de forma criptográfica a la región de KMS en la que se ha definido el almacén 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 especificada al crear las claves. Con Cloud HSM, puedes verificar que las claves criptográficas se han creado y se usan exclusivamente en un dispositivo de hardware. No es necesario modificar la aplicación para que los clientes de Cloud KMS utilicen Cloud HSM; se puede acceder a los servicios de Cloud HSM con las mismas API y bibliotecas de cliente que se usan para el backend del software de Cloud KMS.

Cloud HSM utiliza los HSM que están validados según el estándar FIPS 140‑2 de nivel 3, y siempre se ejecutan en modo FIPS. El estándar FIPS especifica los algoritmos criptográficos y la generación de números aleatorios que utilizan los HSM.

4.5.1. HSM de Cavium

El proveedor ha validado la tarjeta PCIe HSM de Cavium según el estándar FIPS 140‑2 de nivel 3. Puedes obtener el certificado previa solicitud.

4.5.2. Jerarquía de claves de HSM

En el siguiente diagrama, Cloud KMS aparece en la mitad superior. Cloud HSM encapsula las claves de clientes y, luego, Cloud KMS hace lo propio con las claves de HSM que se envían al almacén de datos de Google.

"Diagrama de jerarquía de claves de HSM"

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

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

  1. Se genera en un HSM y nunca abandona los límites definidos de los HSM. Se puede replicar en otros HSM o en copias de seguridad de los HSM.
  2. Puede usarse como una clave de encriptado de claves para encapsular de forma directa o indirecta las claves de clientes que utilizan los HSM.

Aunque las claves de clientes que encapsulan las claves raíz de HSM se pueden usar en el HSM, este no podría devolver el texto sin formato de la clave del cliente, ya que el HSM solo usa las claves de clientes para las operaciones.

4.5.3. Protección del almacén de datos

Los HSM no se utilizan como almacenamiento permanente de claves; solo las almacenan cuando se están utilizando. Como el almacenamiento de los HSM es limitado, las claves de HSM se encriptan y se guardan en el almacén de datos de claves de Cloud KMS. Más adelante, en la sección sobre el backend del almacén de datos entraremos en más profundidad.

4.5.4. Política de rotación

La estrategia de protección de claves de Cloud HSM incluye varios tipos de claves. Los clientes rotan sus propias claves y confían en que Cloud KMS rote las de HSM.

4.5.5. Proceso de aprovisionamiento y gestión

El aprovisionamiento de HSM se lleva a cabo en un laboratorio repleto de medidas de seguridad físicas y logísticas, entre las que se incluyen, por ejemplo, los controles de autorización de varias partes que evitan los riesgos que representa un solo agente.

A continuación se indican algunos aspectos invariables del sistema de Cloud HSM:

  1. Las claves de clientes no se pueden extraer como texto sin formato.
  2. Las claves de clientes no se pueden sacar de la región de origen.
  3. Todos los cambios que se realicen en la configuración de los HSM aprovisionados cuentan con la protección de varias medidas de seguridad.
  4. Las operaciones administrativas se registran acorde con la separación de obligaciones entre administradores de Cloud HSM y del almacenamiento de registros.
  5. El diseño de los HSM pretende protegerlos frente a manipulaciones (como insertar hardware malicioso, modificar el software o extraer secretos sin autorización) durante el ciclo de vida operativo.

4.5.6. Firmware controlado por el proveedor

El firmware de HSM está firmado digitalmente por el proveedor de HSM. Google no puede crear ni actualizar el firmware de HSM. Se firma todo el firmware del proveedor, incluido el de desarrollo que se utiliza para las pruebas.

4.5.7. Regionalización

Las claves de clientes se asignan a regiones geográficas específicas al vincularse a una clave raíz de HSM en concreto. Por ejemplo, una clave creada específicamente 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 creada en la multirregión us no se puede migrar a la región us-west1 ni salir de ella.

4.6. Cloud KMS: importación de claves

Te recomendamos que importes tus propias claves a tu entorno en la nube. Por ejemplo, es posible que tengas un requisito normativo que dicta que las claves que se usan para encriptar los datos en la nube deben generarse de una forma concreta o en un entorno específico. Cloud KMS te permite importar las claves criptográficas que hayas creado on‑premise o en un gestor de claves externo. Gracias a la importación de claves, puedes importar esas claves y cumplir con tales requisitos normativos. Además, puedes importar claves asimétricas para poder firmar también en la nube.

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

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

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

En el caso de Cloud HSM, la parte de la clave privada de la clave de encapsulado solo está disponible en Cloud HSM. De este modo, Google no podrá desencapsular el material de la clave fuera de Cloud HSM.

4.7. Claves de encriptado gestionadas por el cliente (CMEK)

De forma predeterminada, Google Cloud encripta todos los datos de clientes almacenados en en reposo. Además, Google gestiona las claves utilizadas para ello. En algunos productos de Google Cloud, sin embargo, los clientes pueden usar Cloud KMS para gestionar las claves usadas para el encriptado. La CMEK se puede utilizar en claves respaldadas por software y hardware. Cloud KMS permite al cliente controlar muchos aspectos de las claves (como crearlas, habilitarlas, inhabilitarlas, rotarlas y destruirlas) y gestionar los permisos de gestión de identidades y accesos correspondientes. Cloud KMS incluye varios roles predefinidos de gestión de identidades y accesos que tienen privilegios y limitaciones específicos, y que se pueden conceder a usuarios y cuentas de servicio concretos para implementar la separación de obligaciones recomendada.

En los siguientes temas se proporcionan detalles sobre los productos integrados en la plataforma de Cloud KMS que son compatibles con la CMEK:

El modo en el que la rotación de claves influye en la versión de la clave utilizada depende de cómo cada producto implemente la CMEK. Normalmente, al rotar una clave de Cloud KMS no se vuelven a encriptar los datos del servicio de CMEK asociado. Por ejemplo, BigQuery no rota automáticamente la clave de encriptado de una tabla cuando se rota la clave de Cloud KMS asociada con esa tabla. Las tablas de BigQuery disponibles seguirán utilizando la versión de clave con la que se crearon. Las nuevas usarán la versión de la clave actual. Para obtener más información, consulta la documentación de cada producto.

Para ver la lista completa de integraciones y servicios compatibles con CMEK, consulta la documentación. Google sigue invirtiendo en la integración con CMEK para otros productos de Google Cloud.

4.8. Ciclo de vida de las solicitudes de Cloud KMS

Esta sección explica el ciclo de vida de una solicitud de Cloud KMS y también aborda la destrucción del material de claves para ilustrar de manera más dinámica cómo se utilizan las estructuras arquitectónicas que se han descrito hasta ahora.

"Diagrama del ciclo de vida de las solicitudes de KMS"

Las fases de este ciclo de vida son las siguientes:

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

4.9. Destrucción del material de claves

En este informe se describe cómo eliminar datos en Google Cloud. El material de claves se considera datos del cliente, por lo que el enfoque que explica este informe se aplica a Cloud KMS. Además, como Google no comparte el material de claves fuera de Cloud KMS, el material de la clave se destruye bajo solicitud cuando transcurre el periodo de 24 horas en el que está pendiente de eliminación y las copias de seguridad ya han caducado. No se asegura el funcionamiento de este proceso para las copias de claves importadas que quedan fuera del control de Cloud KMS.

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

Una vez que se haya programado la eliminación, la versión de la clave dejará de estar disponible para las operaciones criptográficas. Antes del transcurso de 24 horas, los usuarios pueden restaurar la versión de la 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 las políticas de seguridad y almacenamiento de datos, las restricciones de acceso y las estrategias de mitigación de riesgos diseñadas para optimizar la fiabilidad, la durabilidad y la disponibilidad a la vez que protegen el material de claves. En esta sección se describen la estructura operativa del servicio, las responsabilidades de los miembros del equipo de operaciones, los mecanismos de autenticación y los protocolos de auditoría y almacenamiento de registros. La información que aparece a continuación se aplica tanto a las capacidades de las claves respaldadas por software como por hardware.

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

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

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

5.2. Regionalización de los recursos de Cloud KMS

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

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

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

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

5.2.1. Centros de datos y regiones de Cloud

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

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

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

5.2.2. Regionalización

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

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

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

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

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

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

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

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

5.2.3. Monitorización de la regionalización

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

5.3. Autenticación y autorización

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

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

  • Comprobar que el cliente ha activado la API de Cloud KMS y tiene una cuenta de facturación activa.
  • Comprobar que el cliente no ha superado su cuota e informar del uso de cuota.
  • Aplicar Controles de Servicio de VPC.
  • Comprobar que el cliente está en la lista de permitidos de las regiones de nube privadas correspondientes.

5.4. Almacenamiento de registros

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

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 consultarlos en la consola de Cloud. Toda la actividad de administración (por ejemplo, crear o destruir una clave) se plasma en esos registros. Los clientes también pueden habilitar el almacenamiento de registros para el resto de las acciones que usen una clave, como encriptar o desencriptar datos con una clave. Los clientes deciden durante cuánto tiempo quieren conservar los registros, así como quién los puede ver.

5.4.2. Registros de Transparencia de acceso

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

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

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

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

5.4.3. Registros de solicitudes internas

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

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

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

5.5. Backend del almacén de datos

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

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

Durabilidad. Cloud KMS utiliza el encriptado autenticado para guardar material de claves de clientes en el almacén de datos. Además, todos los metadatos se autentican mediante un código de autenticación de mensajes basado en hash (HMAC) para comprobar que no se han alterado ni dañado en reposo. Cada hora, una tarea por lotes analiza todo el material y los metadatos de claves y verifica que los HMAC son válidos y que el material de la clave puede desencriptarse correctamente. Si hay datos dañados, se avisa inmediatamente a los ingenieros de Cloud KMS para que puedan tomar medidas.

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

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

El equipo de Cloud KMS ha documentado los procedimientos para restaurar copias de seguridad en situaciones de emergencia.

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

Protección. En la capa de aplicaciones de Cloud KMS, el material de claves de clientes se encripta antes de almacenarse. Los ingenieros del almacén de datos no tienen acceso al material de claves del cliente como texto sin formato. Además, el almacén de datos encripta todos los datos que gestiona antes de escribir al almacenamiento permanente. Por lo tanto, sin acceso a las claves de encriptado del almacén de datos, que se guardan en el KMS interno de Google, aunque se acceda a las capas de almacenamiento subyacentes (incluidos los discos y las cintas), no se podrá hacer lo propio si quiera con los datos encriptados de Cloud KMS.

6. Más informa ción

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

Informes:

Otra documentación: