Descripción general de la seguridad de Espacio confidencial

En este documento se describen los controles de seguridad de Confidential Space y cómo se ha diseñado el sistema para mitigar una amplia gama de amenazas. Confidential Space se ha diseñado para que las partes puedan compartir datos confidenciales (por ejemplo, datos regulados o información personal identificable) con una carga de trabajo y, al mismo tiempo, conservar la confidencialidad y la propiedad de los datos. Espacio Confidencial ayuda a crear aislamiento para que los datos solo sean visibles para la carga de trabajo y los propietarios originales de los datos.

Puedes usar Confidential Space en situaciones en las que no puedas establecer una relación de confianza con el operador de la carga de trabajo o entre las partes originales que crearon los datos confidenciales. Por ejemplo, las instituciones financieras pueden usar Confidential Space para colaborar entre sí e identificar fraudes o analizar actividades de blanqueo de dinero. Confidential Space permite analizar conjuntos de datos de clientes sin revelar sus identidades.

Componentes de un sistema de Espacio confidencial

Confidential Space usa un entorno de ejecución de confianza (TEE) diseñado para liberar secretos solo a cargas de trabajo autorizadas. Un proceso de certificación y una imagen del SO reforzada ayudan a proteger la carga de trabajo y los datos que procesa la carga de trabajo de un operador no fiable.

Un sistema de Espacio Confidencial tiene tres componentes principales:

• Una carga de trabajo: una imagen en contenedores con un SO reforzado que se ejecuta en un TEE basado en la nube. Utilizas Confidential Computing como TEE que ofrece aislamiento de hardware y capacidades de certificación remota.
• Atestación de Google Cloud: un proveedor de tokens de OpenID Connect (OIDC). Este servicio se usa para verificar las citas de certificación de TEE y emitir tokens de autenticación. Los tokens contienen atributos de identificación de la carga de trabajo.
• Un recurso protegido: un recurso de nube gestionado, como una clave de Cloud Key Management Service o un segmento de Cloud Storage. El recurso está protegido por una política de permiso que concede acceso a tokens de identidad federada autorizados. Un paso intermedio, que usa grupos de identidades de cargas de trabajo, transforma los tokens de OIDC en tokens de identidad federada que IAM puede consumir.

El sistema ayuda a garantizar que el acceso a los recursos protegidos solo se conceda a las cargas de trabajo autorizadas. Además, Confidential Space ayuda a proteger la carga de trabajo frente a inspecciones y manipulaciones antes y después de la certificación.

En un sistema de espacio confidencial, hay tres partes:

• El autor de la carga de trabajo, que crea una imagen contenerizada que incluye una aplicación que tiene acceso a los recursos protegidos. El autor no tiene acceso a los datos ni a los resultados. Además, el autor no controla el acceso a los datos ni a los resultados.
• El operador de la carga de trabajo, que ejecuta la carga de trabajo en un Google Cloud proyecto. El operador suele tener privilegios administrativos completos en el proyecto. El operador puede gestionar Google Cloud recursos como instancias de Compute Engine, discos y reglas de redes, y puede interactuar con cualquier Google Cloud API que actúe sobre ellos. El operador no tiene acceso a los datos ni a los resultados, y no puede influir ni modificar el código ni el entorno de ejecución. Además, el operador no controla el acceso a los datos ni a los resultados.
• Los propietarios de los recursos (o los colaboradores de los datos), que son los propietarios del recurso protegido. El propietario de un recurso puede acceder a sus propios datos, definir permisos en ellos y acceder a los resultados. No pueden acceder a los datos de otros propietarios de recursos ni modificar el código por su cuenta.

Confidential Space admite un modelo de confianza en el que el autor de la carga de trabajo, el operador de la carga de trabajo y los propietarios de los recursos son partes independientes que no confían entre sí.

En el siguiente diagrama se muestran los componentes del sistema y las partes implicadas. La carga de trabajo se encuentra en un proyecto independiente del recurso protegido.

Ejemplos de tratamiento de datos seguro

Espacio Confidencial te ayuda a proteger la privacidad de los usuarios al compartir datos. En la siguiente tabla se describen tres casos prácticos de ejemplo.

Caso práctico	Caso de ejemplo
Modelo de cifrado funcional	En un modelo de cifrado funcional, Alicia quiere compartir el resultado de sus datos confidenciales con Bob sin revelar todo su conjunto de datos. Alicia cifra su conjunto de datos y protege la clave de cifrado de datos (DEK) en Cloud KMS en su proyecto. Alicia escribe un programa que implementa la carga de trabajo y comparte el archivo binario con Borja. Alice configura KMS para dar acceso al programa a la DEK. La carga de trabajo se ejecuta en el espacio confidencial de Bob, descifra y procesa el conjunto de datos de Alice, y escribe el resultado en el almacenamiento en Cloud de Bob.
Computación multipartita	En la computación multiparte, Alice y Bob quieren compartir el resultado entre ellos, pero manteniendo la confidencialidad de los conjuntos de datos de entrada. Al igual que en el modelo de cifrado funcional, Alice y Bob cifran sus respectivos conjuntos de datos y protegen las DEKs en las instancias de Cloud KMS de sus proyectos. Crean conjuntamente un programa que determina los resultados y lo ejecutan en un espacio confidencial. Alicia y Borja configuran KMS para dar acceso al programa a las DEKs. El programa lee y procesa ambos conjuntos de datos, y escribe el resultado en un segmento de Cloud Storage compartido.
Compartir claves	Un esquema más complejo utiliza la idea de claves compartidas. Una parte de la clave es una clave privada que se divide entre Alice, Bob y otros propietarios, de forma que el conocimiento de las partes individuales no da acceso al conjunto de datos cifrado. En este esquema, la confianza se reparte entre varios propietarios. La clave privada solo se ensambla en un TEE restringido por una carga de trabajo autorizada.

En estos ejemplos, solo la carga de trabajo tiene acceso al conjunto de datos cifrado y puede procesarlo. Espacio Confidencial ayuda a garantizar que nadie pueda llevar a cabo operaciones no auditadas en datos que no le pertenezcan. Los propietarios de los datos controlan cómo se usan sus datos y qué cargas de trabajo están autorizadas para actuar sobre ellos.

Proteger la integridad y la confidencialidad de una carga de trabajo

Para proteger la carga de trabajo de un operador de carga de trabajo no fiable, Confidential Space implementa los siguientes controles de seguridad:

• Un proceso de certificación detecta modificaciones en la imagen de la carga de trabajo o en su TEE. Este control ayuda a proteger la integridad de la carga de trabajo antes de la atestación.
• Una imagen base reforzada ayuda a reducir la superficie de ataque e impide que el operador de la carga de trabajo acceda a la instancia o la ponga en peligro en el tiempo de ejecución. Este control ayuda a proteger la integridad y la confidencialidad de una carga de trabajo después de la certificación. En conjunto, estos controles de seguridad ayudan a proteger la carga de trabajo, sus secretos y los datos que procesa.

Proceso de atestación

El proceso de certificación se basa en el arranque medido y las mediciones de tiempo de ejecución extendido de máquinas virtuales protegidas. Este proceso registra las mediciones de la secuencia de arranque en un registro protegido y de solo extensión en el dispositivo del módulo de plataforma segura virtual (vTPM).

Las mediciones abarcan los componentes de arranque inicial, el kernel cargado y la imagen del contenedor. Además, incluyen propiedades del entorno, como una marca que indica si la instancia es una VM confidencial. El vTPM firma (o cita) estas mediciones con una clave de atestación certificada en la que confía Google Cloud Attestation.

En el siguiente diagrama se muestran los componentes de un sistema de espacio confidencial y cómo participa cada componente en el proceso de certificación.

El proceso de certificación depende de los siguientes componentes:

• Firmware de invitado: un componente inmutable que es una parte de confianza deGoogle Cloud.
• Imagen de espacio confidencial certificada: una imagen reforzada basada en Container-Optimized OS que se lee del disco de arranque adjunto.
• Componentes de arranque inicial: gestores de arranque y kernels que interactúan con el vTPM para medir los componentes de arranque en un registro de configuración de la plataforma (PCR).

• Launcher: un componente que descarga el archivo binario de la carga de trabajo del repositorio de imágenes y mide el contenedor y su configuración en un PCR. El lanzador lee su configuración del servidor de metadatos de la instancia.

• Código de gestión de la certificación: código responsable de preparar una cita de PCR y de devolver la cita, la clave de certificación y el registro de eventos completo del vTPM.

• Atestación de Google Cloud: un servicio que verifica la cita, reproduce el registro de eventos, emite el token de OIDC y devuelve el token con los atributos de la política de acceso a la carga de trabajo.

Imagen protegida

La imagen de Confidential Space es un SO mínimo y específico. La imagen ejecuta el lanzador de contenedores, que a su vez inicia un solo contenedor. La imagen de Confidential Space se basa en las mejoras de seguridad de Container-Optimized OS y añade las siguientes ventajas:

• Particiones de disco cifradas con protección de integridad: la imagen de Confidential Space incluye las siguientes particiones:
  • Una partición root-fs y una partición OEM que incluye el archivo binario del launcher. Estas particiones son inmutables y están protegidas por dm-verity.
  • Una partición temporal de escritura que almacena el archivo binario de la carga de trabajo descargada. dm-crypt cifra esta partición y protege su integridad.
  • Una partición tmp-fs que se asigna a la RAM. En un TEE de una VM confidencial, la memoria de la VM está encriptada. Además, el sistema swap-fs está inhabilitado, lo que ayuda a evitar que un sistema operativo mal configurado almacene datos en el disco.
• Conexiones de red cifradas y autenticadas: el launcher usa TLS para autenticar la certificación de Google Cloud y proteger sus enlaces de comunicación.
• Varias mediciones de arranque: estas mediciones incluyen argumentos de línea de comandos del kernel, dm-verity configuración de root-fs y el archivo binario de la carga de trabajo.

• Acceso remoto y herramientas específicas de la nube inhabilitados: estas herramientas incluyen sshd y Inicio de sesión del SO.

• Transiciones de estado reducidas: por ejemplo, el launcher ejecuta un solo contenedor y, a continuación, finaliza.

Modelo de amenazas y mitigaciones

En esta sección se describen los modelos de amenazas que ayuda a mitigar Confidential Space y los nuevos riesgos que introduce.

Los siguientes ataques no se incluyen en este documento:

• Ataques a la cadena de suministro de software que se aplican al firmware de la interfaz de firmware extensible unificada (UEFI) de invitado, al bootloader y al kernel de la imagen de Confidential Space, al tiempo de ejecución del contenedor y a las dependencias de terceros de la carga de trabajo. Los colaboradores de datos dan por hecho que los propietarios de los recursos han revisado y auditado la imagen del contenedor antes de compartir su recurso con una política de permiso.
• Ataques a Google Cloud, como los escapes de máquinas virtuales.

Posibles ataques

Confidential Space se ha diseñado para protegerse frente a tres posibles ataques:

• Un operador de cargas de trabajo malintencionado: un operador de cargas de trabajo malintencionado puede modificar el contenido del disco, interceptar conexiones de red e intentar poner en peligro el TEE en tiempo de ejecución. Un operador malicioso puede ampliar la superficie de ataque o restringir el entorno de ejecución. Por ejemplo, un operador malintencionado puede añadir una consola serie para introducir nuevos vectores de ataque. Otro ejemplo es que un operador malintencionado puede restringir recursos, como limitar el tamaño de la memoria de un invitado, cambiar su espacio en disco o modificar las reglas del cortafuegos. Estas restricciones pueden activar errores de E/S que podrían dar lugar a casos de error mal probados.
• Un cliente de certificación malicioso: este atacante se conecta a Google Cloud Attestation y envía mensajes de registro de eventos mal formados, pero firmados.
• Un propietario de recursos malintencionado: un propietario de recursos malintencionado tiene control total sobre el conjunto de datos cifrado que consume la carga de trabajo. Este atacante podría presentar entradas incorrectas o datos sesgados e intentar activar vulnerabilidades de análisis en la carga de trabajo o intentar eludir sus controles de privacidad.

Superficies de ataque

En la siguiente tabla se describen las superficies de ataque disponibles para los atacantes.

Atacante	Objetivo	Superficie de ataque	Riesgos
Operador de carga de trabajo	TEE, carga de trabajo	Lecturas de disco	Todo lo que se lea del disco estará bajo el control del atacante. Servicios como los discos persistentes multiescritura y las unidades de disco dinámicas permiten que un atacante modifique el contenido de los discos de forma dinámica y a voluntad.
Operador de carga de trabajo	TEE, carga de trabajo	Escrituras de disco	Cualquier elemento escrito en el disco es visible para un atacante. Consulta las funciones de instantáneas de disco e importación.
Operador de carga de trabajo	TEE, carga de trabajo	Servidor de metadatos	Los atributos de instancia leídos del servidor de metadatos están bajo el control del atacante, incluidas las variables de entorno y la secuencia de comandos de inicio.
Operador de carga de trabajo	TEE, carga de trabajo	Red	Las conexiones de redes externas al repositorio de imágenes o a Google Cloud Attestation se pueden interceptar. Este ataque se lleva a cabo mediante una VPC privada con una instancia de Cloud Router pública.
Cliente de atestación	Google Cloud Attestation	Registro de eventos y mensajes de certificación	Google Cloud Attestation tiene una lógica compleja y con un uso intensivo de la criptografía que resulta difícil de escribir de forma defensiva.
Propietario del recurso	Carga de trabajo	Conjunto de datos cifrado	Un atacante puede envenenar los conjuntos de datos de entrada de la carga de trabajo, lo que significa que los datos cifrados no son necesariamente datos de confianza.

Google Cloud infraestructura

Google Cloud incluye el hipervisor de Compute Engine, el vTPM de la VM confidencial, el firmware UEFI del invitado y una instancia de atestación de Google Cloud alojada. El material de claves sensibles, como las claves de firma de vTPM y OIDC, se ha diseñado para protegerse de forma segura.

La infraestructura de Google está diseñada para aislar de forma lógica los datos de cada cliente de los datos de otros clientes y usuarios, aunque se almacenen en el mismo servidor físico. El acceso de administrador para el personal de asistencia y los ingenieros está limitado, auditado y es transparente para los clientes. Además, el cifrado de memoria en línea de las máquinas virtuales confidenciales ayuda a proteger la confidencialidad de la memoria de la instancia. El cifrado de memoria insertado hace que la inspección directa o el registro accidental de memoria (registro de fallos del kernel) no sean eficaces. Para obtener más información sobre cómo protegemos nuestra plataforma, consulta el resumen de seguridad de Google.

Amenazas y mitigaciones

Un sistema de archivos cifrado con protección de integridad se ha diseñado para mitigar los riesgos de ataques al disco. Además, después de leer el código del disco, se mide y esos datos no se vuelven a leer del disco. Los secretos nunca se revelan en formato de texto sin cifrar en el disco ni en ningún dispositivo externo, como una consola serie.

Los riesgos de los ataques a la red se mitigan mediante canales autenticados y cifrados de extremo a extremo. El acceso a redes externas, como SSH, está inhabilitado en la imagen. Un protocolo de certificación ayuda a proteger la secuencia de arranque y cualquier configuración leída del servidor de metadatos. Por último, se espera que las cargas de trabajo de Espacio Confidencial usen controles de privacidad diferencial para mitigar los riesgos derivados de conjuntos de datos sesgados.

En las siguientes tablas se describen las amenazas y las mitigaciones:

• Ataques al proceso de arranque medido

• Ataques al iniciador de contenedores

• Ataques a Google Cloud Attestation

• Ataques a cargas de trabajo

Ataques al proceso de arranque medido

En esta tabla se describen las posibles amenazas y las estrategias de mitigación relacionadas con el proceso de arranque medido.

Amenaza	Solución	Implementación de la mitigación
Un atacante inicia una VM blindada con un firmware antiguo que no admite el arranque medido. Si lo consigue, un atacante puede reproducir mediciones arbitrarias y eludir la certificación remota.	Esta amenaza se mitiga mediante el plano de control de Google Cloud . Confidential Space añade un dispositivo vTPM y un firmware UEFI actualizado. Además, Confidential Space habilita el arranque medido, que no se puede inhabilitar.	Infraestructura de Google Cloud
Un atacante sobrescribe el firmware UEFI en la memoria física del invitado, reinicia el invitado, lo que restablece los registros de vTPM, y ejecuta el firmware modificado. Si el ataque tiene éxito, el atacante puede reproducir mediciones arbitrarias y eludir la certificación remota.	El hipervisor mitiga esta amenaza. Al reiniciar el invitado, el hipervisor carga una copia limpia del firmware UEFI en la memoria del invitado. Se descartan las modificaciones anteriores en la memoria del invitado. Además, el reinicio del invitado es el único evento que restablece el vTPM.	En Google Cloud y si habilitas Confidential Computing
Un atacante modifica archivos de configuración no medidos, lo que afecta negativamente a la ejecución del programa.	Este riesgo se mitiga mediante el proceso de certificación. Todos los archivos binarios ejecutables y los archivos de configuración correspondientes se miden por completo antes de ejecutarse. En concreto, se miden las variables de arranque seguro, la configuración de grub y los argumentos de la línea de comandos del kernel. En la revisión de seguridad se ha determinado que no se ha omitido ninguna medición en el proceso de atestación.	Dentro de la imagen de Confidential Space
Un atacante activa vulnerabilidades de corrupción de memoria en los componentes de arranque inicial y obtiene la ejecución de código.	Los componentes de arranque inicial están escritos en lenguaje C. Estos componentes tratan datos de usuarios no fiables y pueden ser vulnerables a problemas de corrupción de memoria. Un ejemplo reciente es BootHole. Este riesgo se mitiga mediante el proceso de certificación: los componentes de arranque inicial deben medir los datos controlados por el usuario antes de procesarlos. Un ataque BootHole usa un grub.cfg modificado para obtener la ejecución de código y eludir el arranque seguro. Sin embargo, en un sistema de Espacio Confidencial, ese ataque no supera la certificación, ya que las mediciones de grub.cfg no coinciden con la configuración esperada. Un riesgo relacionado es la lógica compleja del sistema de archivos. Vulnerabilidades anteriores, como Sequoia, demuestran que los controladores del sistema de archivos procesan estructuras de datos complejas y pueden ser vulnerables a problemas de corrupción de memoria. Este riesgo se mitiga mediante la protección de la integridad a nivel de bloque dm-verity y dm-crypt, y desactivando los montajes automáticos.	Dentro de la imagen de Confidential Space
Un atacante modifica los archivos binarios de inicio temprano en el disco después de que se hayan leído y medido, pero antes de que se lean y se ejecuten (condición de carrera TOCTOU en el disco).	Los componentes de inicio temprano se crearon para máquinas sin sistema operativo y es posible que no estén preparados para el entorno dinámico de la nube. Es posible que los componentes de arranque asuman que el contenido del disco no puede cambiar durante la ejecución, lo cual es un error en los entornos de nube. Este riesgo se mitiga mediante la programación defensiva: el contenido del disco es de solo lectura después de usar el patrón de lectura, medición y ejecución. En la revisión de seguridad de la imagen de Confidential Space no se han identificado problemas de TOCTOU en los componentes de arranque inicial, como UEFI, Shim o GNU GRUB.	Dentro de la imagen de Confidential Space
Un atacante modifica los controladores de dispositivos y los servicios en modo de usuario en el disco después de que se haya cargado el kernel.	Esta amenaza se mitiga mediante un sistema de archivos raíz con protección de integridad. Root-fs de la imagen de Espacio confidencial está protegido con integridad por dm-verity. La configuración (root-hash) se transfiere en un argumento de comando del kernel y, a continuación, Google Cloud Attestation la mide y la certifica.	Dentro de la imagen de Confidential Space

Ataques al launcher de contenedores

En esta tabla se describen las posibles amenazas y las estrategias de mitigación relacionadas con el launcher.

Amenaza	Solución	Implementación de la mitigación
Un atacante intercepta la conexión de red del launcher o del repositorio de imágenes.	La conexión al repositorio de imágenes está protegida por una conexión TLS cifrada y autenticada. Un atacante puede cambiar la URL de la imagen y controlar el binario de la carga de trabajo. Sin embargo, estas acciones se reflejan en el registro de atestación. El repositorio de imágenes no se controla mediante una lista de acceso, por lo que se da por hecho que todos los usuarios pueden ver la imagen. Debes asegurarte de que la imagen del contenedor de la carga de trabajo no contenga ningún secreto.	Dentro de la imagen de Confidential Space
Un atacante modifica la imagen de la carga de trabajo en el disco después de que se haya descargado y medido.	Esta amenaza se mitiga mediante una partición grabable que está cifrada y cuya integridad está protegida. La imagen de la carga de trabajo y sus datos temporales están protegidos por dm-crypt mediante claves efímeras por arranque. El proceso de cifrado de disco dm-crypt permite ataques de reversión, en los que un atacante sustituye el contenido del disco por textos cifrados y etiquetas vistos anteriormente. Estos ataques se consideran muy complejos en la configuración de Confidential Space.	Dentro de la imagen de Confidential Space
Un atacante modifica la configuración del launcher en el servidor de metadatos y controla la URL del repositorio de imágenes.	El proceso de certificación detecta configuraciones no seguras que cargan imágenes no auténticas.	En Google Cloud Attestation

Ataques a Google Cloud Attestation

En esta tabla se describen las posibles amenazas y las estrategias de mitigación de Google Cloud Attestation.

Amenaza	Solución	Implementación de la mitigación
Un atacante intercepta la conexión de red del launcher o de Google Cloud Attestation y lee el token secreto de la conexión.	Esta amenaza se mitiga mediante una conexión TLS autenticada y cifrada. Esta conexión ayuda a proteger el token de escuchas pasivas. Un atacante no puede suplantar la identidad del servicio porque le falta la clave TLS. Aunque lo consiga, el atacante no podrá crear tokens OIDC válidos. Un atacante no puede suplantar la identidad de un cliente válido porque el protocolo de certificación garantiza la identidad del cliente.	En la red entre tu carga de trabajo y el servicio de atestación.
Un atacante aprovecha las discrepancias de análisis, lo que provoca cambios no detectados en el proceso de certificación.	Esta amenaza puede producirse porque el registro de eventos de mediciones se serializa y se envía a Google Cloud Attestation, donde se analiza y se procesa. Se produce una discrepancia de análisis cuando el servicio y el SO de tiempo de ejecución no coinciden en la semántica del registro. Por ejemplo, si el campo cmdline tiene una lista de argumentos separados por comas, el kernel y el servicio podrían analizar de forma diferente una cadena como a=1, b=2 c='3,d=e' (ten en cuenta el ,d en la subcadena de valor). Este riesgo se mitiga con un motor de análisis que refleja correctamente el comportamiento del SO. En concreto, cmdline se procesa como una cadena completa y no se divide en pares clave-valor.	Dentro de la imagen de Confidential Space
Un atacante usa todos los recursos del servicio, lo que provoca que el servicio deje de funcionar en un ataque de denegación de servicio (DoS). El servicio se interrumpe para otros usuarios de Confidential Space.	Este riesgo de fiabilidad se mitiga al tener un servicio distribuido y elástico que se puede replicar y ampliar fácilmente según sea necesario. El código evita que los clientes maliciosos agoten los recursos.	En la carga de trabajo

Ataques a cargas de trabajo

En esta tabla se describen las posibles amenazas y las estrategias de mitigación relacionadas con las cargas de trabajo.

Amenaza	Solución	Implementación de la mitigación
Un atacante lee secretos del tiempo de ejecución de la partición de escritura.	Esta amenaza se mitiga con un sistema de archivos cifrado. El sistema de archivos de escritura se monta con dm-crypt. La memoria de intercambio está inhabilitada y el contenido de la memoria no se pagina en el disco. Como técnica de defensa en profundidad, los tokens de OIDC tienen un ámbito y una duración limitados.	Dentro de la imagen de Confidential Space
Un atacante lee secretos del tiempo de ejecución desde la consola serie.	Esta amenaza se mitiga en la imagen de Confidential Space porque las credenciales y los tokens nunca se imprimen en la consola serie. Además, el registro en la nube está inhabilitado.	Dentro de la imagen de Confidential Space
Un atacante actualiza las claves SSH autorizadas mediante el paquete OSLogin y, a continuación, se conecta a la instancia en ejecución.	Esta amenaza se mitiga en la imagen de Confidential Space porque los servicios systemd predeterminados están enmascarados, incluido sshd.	Dentro de la imagen de Confidential Space
Un atacante actualiza las secuencias de comandos de inicio en el servidor de metadatos, que el agente invitado carga automáticamente.	Esta amenaza se mitiga en la imagen de Confidential Space porque el paquete del agente invitado está inhabilitado.	Dentro de la imagen de Confidential Space
Un atacante envía paquetes incorrectos a la VM mediante el agente de configuración del SO.	Esta amenaza se mitiga en la imagen de Confidential Space porque el agente de configuración del SO está inhabilitado.	Dentro de la imagen de Confidential Space
Un atacante envía un conjunto de datos cifrado y con formato incorrecto a la carga de trabajo.	Esta amenaza se mitiga mediante el uso de código de análisis defensivo en la carga de trabajo.	En la carga de trabajo
Un atacante envía un conjunto de datos sesgado o envenenado a la carga de trabajo e intenta obtener información sobre los conjuntos de datos de terceros.	Esta amenaza se mitiga implementando controles de privacidad diferencial en la carga de trabajo.	En la carga de trabajo

Pruebas de seguridad

Confidential Space ha pasado por un proceso de revisión de seguridad exhaustivo en Google. Este proceso de revisión de seguridad incluyó las siguientes pruebas y auditorías:

• Pruebas de integración de extremo a extremo de flujo negativo

  Estas pruebas verificaron que la atestación falla en mediciones incorrectas, como cuando el código se ejecuta en un entorno TEE inesperado o inicia un contenedor de carga de trabajo modificado.

• Auditoría manual del proceso de arranque medido

  Esta revisión se ha centrado en identificar las mediciones que faltan y los errores de lectura doble. Las pruebas verificaron que el código se había escrito teniendo en cuenta las prácticas recomendadas de seguridad y que, cuando se producía un error, el código se cerraba.

• Auditoría manual del proceso de compilación de la imagen de espacio confidencial y la lógica del launcher:

  Esta revisión se ha centrado en la eliminación de paquetes y en la reducción de la superficie de ataque.

• Auditoría manual de Google Cloud Attestation

  Esta revisión se ha centrado en la implementación del protocolo de certificación correcto y en evitar problemas de análisis.

• Revisión de criptografía por expertos en ciberseguridad

  Esta revisión se ha centrado en el protocolo de certificación, el cifrado del sistema de archivos y las soluciones de integridad.

• Revisión de la privacidad por expertos

  Esta revisión se ha centrado en los controles de privacidad diferencial de las cargas de trabajo creadas por Google.

• Pruebas de fuzzing continuas

  Estas pruebas abarcaron componentes críticos de seguridad, como vTPM y Google Cloud Attestation.

NCC Group, una organización externa de pruebas de penetración, realizó pruebas de penetración en el sistema. NCC ha revisado Confidential Space como plataforma de computación segura.

Siguientes pasos

• Para empezar a usar Confidential Space, consulta el artículo Analizar datos confidenciales con Confidential Space.

• Para obtener más información sobre cómo proteger los datos en uso, consulta Confidential Computing.

• Para obtener más información sobre la seguridad de la infraestructura de Google, consulta la descripción general del diseño de seguridad de la infraestructura de Google.