En este documento, se describen los controles de seguridad de Confidential Space y cómo el sistema está diseñado para mitigar una amplia gama de amenazas. Confidential Space se diseñó para permitir que las partes compartan datos confidenciales (por ejemplo, datos regulados o información de identificación personal [PII]) con una carga de trabajo mientras conservan la confidencialidad y la propiedad de los datos. Confidential Space ayuda a crear aislamiento a fin de que los datos solo sean visibles para la carga de trabajo y los propietarios originales de los datos.
Puedes usar Confidential Space para situaciones en las que no puedes establecer 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í a fin de identificar fraudes o analizar actividades de lavado de dinero. Confidential Space permite el análisis en conjuntos de datos de clientes y, al mismo tiempo, mantiene las identidades de los clientes privadas.
Componentes de un sistema de Confidential Space
Confidential Space usa un entorno de ejecución confiable (TEE) que está diseñado para liberar secretos solo en cargas de trabajo autorizadas. Un proceso de certificación y una imagen de SO endurecida ayudan a proteger la carga de trabajo y los datos que procesa la carga de trabajo desde un operador no confiable.
Un sistema de Confidential Space tiene tres componentes principales:
- Una carga de trabajo: una imagen alojada en contenedores con un SO endurecido que se ejecuta en un TEE basado en la nube. Usa Confidential Computing como el TEE que ofrece aislamiento de hardware y capacidades de certificación remota.
- Un servicio de certificación: un proveedor de tokens de OpenID Connect (OIDC). Usa este servicio a fin de verificar las certificaciones de TEE y los tokens de autenticación de la versión. Los tokens contienen atributos de identificación para la carga de trabajo.
- Un recurso protegido: un recurso de nube administrado, como una clave de Cloud Key Management Service o un bucket de Cloud Storage. El recurso está protegido por una política de permisos que otorga acceso a tokens de identidad federada autorizados. Un paso intermedio, mediante grupos de Workload Identity, 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 otorgue a las cargas de trabajo autorizadas. Además, Confidential Space ayuda a proteger la carga de trabajo de la inspección y la manipulación antes y después de la certificación.
En un sistema de Confidential Space, hay tres partes:
- El autor de la carga de trabajo, que crea una imagen alojada en contenedores 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 o los resultados.
- El operador de la carga de trabajo, que ejecuta la carga de trabajo en un proyecto de Google Cloud. Por lo general, el operador tiene privilegios administrativos completos en el proyecto. El operador puede administrar recursos de Google Cloud, como instancias de Compute Engine, discos y reglas de red. Además, puede interactuar con cualquier API de Google Cloud que actúe sobre ellos. El operador no tiene acceso a los datos ni a los resultados y no puede influir en el código o el entorno de ejecución ni modificarlo. Además, el operador no controla el acceso a los datos o los resultados.
- Los propietarios de los recursos (o colaboradores de datos), que poseen el recurso protegido. El propietario de un recurso puede acceder a sus propios datos, establecer permisos en sus propios datos y acceder a los resultados. No puede acceder a los datos de otros propietarios de recursos ni modificar el código por sí mismo.
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 recursos son partes independiente, que no confían entre sí.
En el siguiente diagrama, se muestran los componentes y partes del sistema. La carga de trabajo se encuentra en un proyecto separado del recurso protegido.
Ejemplos de procesamiento seguro de datos
Confidential Space te ayuda a mantener la privacidad del usuario mientras comparte datos. En la siguiente tabla, se describen tres casos de uso de ejemplo.
| Caso de uso | Situación de ejemplo |
|---|---|
| Modelo de encriptación funcional | En un modelo de encriptación funcional, Alice desea compartir el resultado de sus datos confidenciales con Bob, sin revelar su conjunto de datos completo. Alice encripta su conjunto de datos y protege la clave de encriptación de datos (DEK) en Cloud KMS en su proyecto. Alice escribe un programa que implementa la carga de trabajo y comparte el objeto binario con Bob. También configura KMS para que el programa tenga acceso a la DEK. La carga de trabajo se ejecuta en el Confidential Space de Bob, desencripta y procesa el conjunto de datos de Alice y escribe el resultado en Cloud Storage de Bob. |
| Procesamiento multipartita | En el procesamiento multipartita, Alice y Bob quieren compartir el resultado entre sí y preservar la confidencialidad de los conjuntos de datos de entrada. Al igual que en el modelo de encriptación funcional, Alice y Bob encriptan sus respectivos conjuntos de datos y protegen las DEK en las instancias de Cloud KMS de sus proyectos. De forma conjunta, crean un programa que determina los resultados y lo ejecutan en un Confidential Space. Alice y Bob configuran KMS para otorgarle al programa acceso a las DEK. El programa lee y procesa ambos conjuntos de datos y escribe el resultado en un bucket de Cloud Storage compartido. |
| Claves compartidas | Un esquema más complejo usa la idea de claves compartidas. Una clave compartida es una clave privada que se divide entre Alice, Bob y otros propietarios, de modo que el conocimiento de las partes individuales de la clave no otorgue acceso al conjunto de datos encriptado. En este esquema, la confianza se divide en varios propietarios. La clave privada se ensambla solo en un TEE restringido, mediante una carga de trabajo autorizada. |
En estos ejemplos, solo la carga de trabajo tiene acceso al conjunto de datos encriptado y puede procesarlo. Confidential Space ayuda a garantizar que nadie pueda realizar operaciones no auditadas en datos que no son de su propiedad. Los propietarios de los datos controlan cómo se usan sus datos y qué cargas de trabajo están autorizadas para actuar en ellos.
Protege la integridad y confidencialidad de una carga de trabajo
Para ayudar a proteger la carga de trabajo de un operador de carga de trabajo no confiable, Confidential Space implementa los siguientes controles de seguridad:
- Un proceso de certificación detecta modificaciones en la imagen de la carga de trabajo o su TEE. Este control ayuda a proteger la precertificación de integridad de la carga de trabajo.
- Una imagen base endurecida ayuda a reducir la superficie de ataque y ayuda a evitar que el operador de la carga de trabajo acceda a la instancia durante la ejecución o la ponga en riesgo. Este control ayuda a proteger la integridad y la confidencialidad de una carga de trabajo después de la certificación. Juntos, estos controles de seguridad protegen la carga de trabajo, sus secretos y los datos que procesa.
Proceso de certificación
El proceso de certificación se basa en el inicio medido de VM protegida y las mediciones extendidas del entorno de ejecución. Este proceso captura las medidas de la secuencia de inicio en un registro protegido de solo extensión en el dispositivo del módulo de plataforma segura virtual (vTPM).
Las mediciones abarcan los componentes de inicio anticipado, el kernel cargado y la imagen de contenedor. Además, incluyen propiedades del entorno, como una marca que indica que la instancia es una Confidential VM. El vTPM firma (o certifica) estas mediciones mediante una clave de certificación certificada que cuenta con la confianza del servicio de certificación.
En el siguiente diagrama, se muestran los componentes de un sistema de Confidential Space y cómo cada componente participa 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 confiable de Google Cloud.
- Imagen de Confidential Space certificada: una imagen endurecida basada en Container-Optimized OS que se lee desde el disco de arranque conectado.
- Componentes de inicio anticipado: bootloaders y kernels que interactúan con el vTPM para medir los componentes de inicio en un registro de configuración de la plataforma (PCR).
Iniciador: un componente que descarga el objeto binario de la carga de trabajo desde el repositorio de imágenes y mide el contenedor y su configuración en un PCR. El iniciador lee la configuración desde el servidor de metadatos de la instancia.
Código de control de certificación: código responsable de preparar una certificación de PCR y mostrar la certificación de vTPM, la clave de certificación y el registro de eventos completo.
El servicio de certificación: un servicio que verifica la certificación, vuelve a reproducir el registro de eventos, emite el token de OIDC y muestra el token con los atributos para la política de acceso de carga de trabajo.
Imagen endurecida
La imagen de Confidential Space es un SO mínimo y de un solo propósito. La imagen ejecuta el iniciador de contenedores, que, a su vez, inicia un solo contenedor. La imagen de Confidential Space se basa en las mejoras de la seguridad existente de Container-Optimized OS y agrega los siguientes beneficios:
- Particiones de disco encriptadas con protección de integridad: La imagen de Confidential Space incluye las siguientes particiones:
- Una partición
root-fsy una partición del OEM que incluye el objeto binario del iniciador. Estas particiones son inmutables ydm-veritylas protege. - Una partición temporal que admite escritura y almacena el objeto binario descargado de la carga de trabajo.
dm-cryptencripta esta partición y protege su integridad. - Una partición
tmp-fsque se asigna a la RAM. En un TEE de Confidential VM, la memoria de la VM está encriptada. Además, el sistema deswap-fsestá inhabilitado, lo que ayuda a evitar que un sistema operativo mal configurado almacene datos en el disco.
- Una partición
- Conexiones de red autenticadas y encriptadas: El iniciador usa TLS para autenticar el servicio de certificación y proteger sus vínculos de comunicación.
- Varias mediciones de inicio: Estas mediciones incluyen argumentos de la línea de comandos de kernel, la configuración de
dm-veritypararoot-fsy el objeto binario de la carga de trabajo. Acceso remoto inhabilitado y herramientas específicas de la nube: Estas herramientas incluyen sshd y el Acceso al SO.
Transiciones de estado reducidas: Por ejemplo, el iniciador ejecuta un solo contenedor y, luego, finaliza.
Modelo de amenaza y mitigaciones
En esta sección, se describen los modelos de amenaza que Confidential Space ayuda a mitigar y los nuevos riesgos que presenta Confidential Space.
Los siguientes ataques están fuera del alcance de este documento:
- Ataques de cadena de suministro de software que se aplican al firmware de la interfaz de firmware extensible unificada (UEFI) de invitado, al kernel y al bootloader de imágenes de Confidential Space, al entorno de ejecución del contenedor y a las dependencias de terceros para la carga de trabajo Los colaboradores de datos dan por sentado que los propietarios de recursos revisaron y auditaron la imagen de contenedor antes de compartir sus recursos con una política de permiso.
- Ataques en Google Cloud, como escapes de VM.
Posibles ataques
Confidential Space está diseñado para defender de tres ataques posibles:
- Un operador de carga de trabajo malicioso: Un operador de carga de trabajo malicioso puede modificar el contenido del disco, interceptar conexiones de red y tratar de poner en riesgo el TEE en el entorno de ejecución. Un operador malicioso puede expandir la superficie de ataque o restringir el entorno de ejecución. Por ejemplo, un operador malicioso puede agregar una consola en serie para ingresar nuevos vectores de ataque. Otro ejemplo es que un operador malicioso puede restringir recursos, como limitar el tamaño de la memoria de un invitado, cambiar su espacio en el disco o cambiar las reglas de firewall. Estas restricciones pueden activar errores de E/S que podrían dar lugar a casos de error probados de forma incorrecta.
- Un cliente de certificación malicioso: Este atacante se conecta al servicio de certificación y envía mensajes de registro de eventos con formato incorrecto, pero firmados.
- Un propietario de recursos malicioso: Un propietario de recursos malicioso tiene control total sobre el conjunto de datos encriptado que consume la carga de trabajo. Este atacante puede presentar entradas con formato incorrecto o datos sesgados e intentar activar las 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 | Diana | Superficie de ataque | Riesgos |
|---|---|---|---|
| Operador de carga de trabajo | TEE, carga de trabajo | Lecturas de disco |
Todo lo que se lea desde el disco está bajo el control del atacante. Los servicios como los discos persistentes de varios escritores y las conexiones de discos dinámicas significan que un atacante puede modificar el contenido del disco de forma dinámica y a voluntad. |
| Operador de carga de trabajo | TEE, carga de trabajo | Escrituras en disco | Cualquier elemento escrito en el disco es visible para un atacante. Consulta las funciones de importación e instantáneas de disco. |
| Operador de carga de trabajo | TEE, carga de trabajo | Servidor de metadatos | Los atributos de la instancia leídos desde el servidor de metadatos están bajo el control del atacante, incluidas la secuencia de comandos de inicio y las variables de entorno. |
| Operador de carga de trabajo | TEE, carga de trabajo | Red | Se pueden interceptar las conexiones de red externas al repositorio de imágenes o al servicio de certificación. Este ataque se realiza mediante una VPC privada con una instancia pública de Cloud Router. |
| Cliente de certificación | Servicio de certificación | Mensajes de registro de eventos y certificación | El servicio de certificación tiene una lógica criptográfica y compleja, que es difícil de escribir de manera defensiva. |
| Propietario del recurso | Carga de trabajo | Conjunto de datos encriptado | Un atacante puede contaminar los conjuntos de datos de entrada de la carga de trabajo, lo que significa que los datos encriptados no son necesariamente datos de confianza. |
Infraestructura de Google Cloud
Google Cloud incluye el hipervisor de Compute Engine, el vTPM para la Confidential VM, el firmware UEFI de invitado y un servicio de certificación alojado. El material de las claves sensibles, como las claves de firma de vTPM y OIDC, está diseñado para estar protegido 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, incluso cuando se almacenan en el mismo servidor físico. El acceso de administrador para los ingenieros y el personal de asistencia es limitado, auditado y transparente para los clientes. Además, la encriptación de memoria intercalada en Confidential VMs ayuda a proteger la confidencialidad de la memoria de la instancia. La encriptación de memoria intercalada hace que la inspección directa o el registro de memoria accidental (registro de fallas del kernel) sean ineficaces. Para obtener más información sobre cómo protegemos nuestra plataforma, consulta la descripción general de seguridad de Google.
Amenazas y mitigaciones
Un sistema de archivos encriptado con protección de la integridad está diseñado para mitigar los riesgos de ataques al disco. Además, una vez que se lee el código desde el disco, se mide y nunca se vuelven a leer los datos desde el disco. Los secretos nunca se divulgan en formato de texto simple al disco ni a ningún dispositivo externo, como una consola en serie.
Los riesgos de los ataques de red se mitigan mediante canales autenticados encriptados de extremo a extremo. El acceso a la red externa, como SSH, está inhabilitado en la imagen. Un protocolo de certificación ayuda a proteger la secuencia de inicio y cualquier configuración leída desde el servidor de metadatos. Por último, se espera que las cargas de trabajo de Confidential Space usen controles de privacidad diferencial para mitigar los riesgos de conjuntos de datos sesgados.
En las siguientes tablas, se describen las amenazas y las mitigaciones:
Ataques al proceso de inicio medido
En esta tabla, se describen posibles amenazas y estrategias de mitigación relacionadas con el proceso de inicio medido.
| Amenaza | Mitigación | Implementación de la mitigación |
|---|---|---|
Un atacante inicia una VM protegida con un firmware antiguo que no admite el inicio medido. Si se ejecuta de forma correcta, un atacante puede reproducir medidas arbitrarias y anular la certificación remota. |
El plano de control de Google Cloud mitiga esta amenaza. Confidential Space agrega un dispositivo de vTPM y un firmware UEFI actualizado. Además, Confidential Space habilita el inicio medido, y este no se puede inhabilitar. |
En la infraestructura de Google Cloud |
Un atacante reemplaza 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 se ejecuta de forma correcta, un atacante puede reproducir medidas arbitrarias y anular la certificación remota. |
El hipervisor mitiga esta amenaza. Cuando se reinicia 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 cuando habilitas Confidential Computing |
| Un atacante modifica los archivos de configuración no medidos, lo que afecta de manera negativa la ejecución del programa. | El proceso de certificación mitiga esta amenaza. Todos los objetos binarios ejecutables y los archivos de configuración respectivos se miden por completo antes de ejecutarse. En particular, se miden las variables de inicio seguro, la configuración de grub y los argumentos de la línea de comandos del kernel. La revisión de seguridad descubrió que no se perdió ninguna medición en el proceso de certificación. |
En la imagen de Confidential Space |
| Un atacante activa vulnerabilidades de corrupción de memoria en los componentes de inicio anticipado y obtiene la ejecución del código. | Los componentes de inicio anticipado se escriben en lenguaje C. Estos componentes procesan datos del usuario que no son de confianza y pueden ser vulnerables a problemas de corrupción de memoria. Para ver un ejemplo reciente, consulta BootHole.
Este riesgo se mitiga mediante el proceso de certificación: los componentes de inicio anticipado deben medir cualquier dato controlado por el usuario antes de procesarlo. Un ataque BootHole usa un
Sin embargo, en un sistema de Confidential Space, ese ataque no pasa la certificación, ya que las mediciones de Un riesgo relacionado proviene de la lógica compleja del sistema de archivos. Las 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 de |
En la imagen de Confidential Space |
| Un atacante modifica los objetos binarios de inicio anticipado en el disco después de que se leen y miden, y antes de que se lean y ejecuten (TOCTOU del disco). | Los componentes de inicio anticipado se crearon para máquinas de equipos físicos y es posible que no estén acostumbrados al entorno dinámico de la nube. Los componentes de inicio pueden suponer que el contenido del disco no puede cambiar durante la ejecución, lo que es un supuesto incorrecto para los entornos de nube. Este riesgo se mitiga mediante la programación defensiva: el contenido del disco se lee solo una vez mediante el patrón de lectura, medición y ejecución. La revisión de seguridad para la imagen de Confidential Space no identificó problemas de TOCTOU en los componentes de inicio anticipado, como el UEFI, elcorrector de compatibilidad o GNU GRUB. |
En la imagen de Confidential Space |
| Un atacante modifica los controladores de dispositivo y los servicios del modo de usuario en el disco después de que se carga el kernel. | Un sistema de archivos raíz con protección de integridad mitiga esta amenaza.
|
En la imagen de Confidential Space |
Ataques al iniciador de contenedores
En esta tabla, se describen las posibles amenazas y las estrategias de mitigación relacionadas con el iniciador.
| Amenaza | Mitigación | Implementación de la mitigación |
|---|---|---|
| Un atacante intercepta la conexión de red del iniciador o del repositorio de imágenes. | La conexión al repositorio de imágenes está protegida por una conexión TLS encriptada y autenticada. Un atacante puede cambiar la URL de la imagen y controlar el objeto binario de la carga de trabajo. Sin embargo, estas acciones se reflejan en el registro de certificación. El repositorio de imágenes no se controla con una lista de acceso, por lo que se supone que todos pueden ver la imagen. Debes asegurarte de que la imagen de contenedor de la carga de trabajo no contenga ningún secreto. |
En la imagen de Confidential Space |
| Un atacante modifica la imagen de la carga de trabajo en el disco después de que se descargó y midió. | Esta amenaza se mitiga mediante una partición que admite escritura, que está encriptada y cuya integridad está protegida.
La imagen de la carga de trabajo y sus datos temporales están protegidos por
El proceso de encriptación de disco de |
En la imagen de Confidential Space |
| Un atacante modifica la configuración del iniciador 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 el servicio de certificación |
Ataques al servicio de certificación
En esta tabla, se describen posibles amenazas y estrategias de mitigación relacionadas con el servicio de certificación.
| Amenaza | Mitigación | Implementación de la mitigación |
|---|---|---|
| Un atacante intercepta la conexión de red del iniciador o el servicio de certificación y lee el token secreto desde la red. | Esta amenaza se mitiga mediante una conexión TLS encriptada y autenticada. Esta conexión ayuda a proteger el token del espionaje pasivo. Un atacante no puede actuar como un servicio porque no tiene la clave de TLS. Incluso si tiene éxito, el atacante no puede crear tokens de OIDC válidos. Un atacante no puede actuar como un cliente válido porque la identidad del cliente está garantizada por el protocolo de certificación. |
Dentro de la red entre tu carga de trabajo y el servicio de certificación. |
| Un atacante explota las discrepancias de análisis, lo que genera cambios no detectados en el proceso de certificación. | Esta amenaza puede ocurrir porque el registro de eventos de las mediciones se serializa y se envía al servicio de certificación, en el que se analiza y procesa. Una discrepancia de análisis ocurre cuando el servicio y el SO del entorno de ejecución no coinciden en la semántica del registro.
Por ejemplo, si el campo
Este riesgo se mitiga mediante un motor de análisis que refleja de forma correcta el comportamiento del SO. En particular, |
En la imagen de Confidential Space |
| Un atacante usa todos los recursos del servicio, lo que desactiva el servicio en un ataque de denegación del servicio (DoS). El servicio se interrumpe para otros usuarios de Confidential Space. | Este riesgo de confiabilidad se mitiga mediante un servicio elástico distribuido que se puede replicar y escalar horizontalmente con facilidad según sea necesario. El código evita que los clientes maliciosos agoten los recursos. |
En la carga de trabajo |
Ataques a las cargas de trabajo
En esta tabla, se describen posibles amenazas y estrategias de mitigación relacionadas con las cargas de trabajo.
| Amenaza | Mitigación | Implementación de la mitigación |
|---|---|---|
| Un atacante lee los secretos del entorno de ejecución desde la partición que admite escritura. |
Esta amenaza se mitiga con un sistema de archivos encriptado. El sistema de archivos que admite escritura se activa mediante Como técnica de defensa en profundidad, los tokens de OIDC tienen alcance y corta duración. |
En la imagen de Confidential Space |
| Un atacante lee los secretos del entorno de ejecución desde la consola en serie. | Esta amenaza se mitiga en la imagen de Confidential Space porque las credenciales y los tokens nunca se imprimen en la consola en serie. Además, el registro en la nube está inhabilitado. | En la imagen de Confidential Space |
| Un atacante actualiza las claves SSH autorizadas mediante el paquete OSLogin y, luego, se conecta a la instancia en ejecución. |
Esta amenaza se mitiga en la imagen de Confidential Space porque los servicios predeterminados de systemd están enmascarados, incluido sshd. |
En 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. | En 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. | En la imagen de Confidential Space |
| Un atacante pasa un conjunto de datos encriptado y con formato incorrecto a la carga de trabajo. | Esta amenaza se mitiga mediante el código de análisis defensivo en la carga de trabajo. | En la carga de trabajo |
| Un atacante pasa un conjunto de datos sesgado o contaminado a la carga de trabajo y, luego, intenta obtener información sobre los conjuntos de datos de otras partes. | Esta amenaza se mitiga mediante la implementación de controles de privacidad diferencial en la carga de trabajo. | En la carga de trabajo |
Pruebas de seguridad
Confidential Space pasó por un proceso integral de revisión de seguridad en Google. Este proceso de revisión de seguridad incluyó las siguientes pruebas y auditorías:
Pruebas de integración de extremo a extremo del flujo negativo
Estas pruebas verificaron que la certificación fallara 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 inicio medido
Esta revisión se centró en identificar las mediciones faltantes y los errores de lectura doble. Las pruebas verificaron que el código se escribió con las prácticas recomendadas de seguridad en mente y que, cuando se produjo un error, el código se cerró (se apagó).
Auditoría manual del proceso de compilación para la lógica del iniciador y la imagen de Confidential Space:
Esta revisión se enfocó en la eliminación de paquetes y la reducción de la superficie de ataque.
Auditoría manual del servicio de certificación
Esta revisión se enfocó en la implementación del protocolo de certificación correcto y en evitar los problemas de análisis.
Revisión de criptografía por expertos en seguridad cibernética
Esta revisión se centró en el protocolo de certificación, la encriptación del sistema de archivos y las soluciones de integridad.
Revisión de privacidad por expertos en privacidad
Esta revisión se centró en los controles de privacidad diferencial de las cargas de trabajo que creó Google.
Pruebas de fuzz continuas
Estas pruebas abarcaron componentes críticos de seguridad, como el vTPM y el servicio de certificación.
NCC Group, una organización externa de pruebas de penetración, realizó pruebas de penetración en el sistema. NCC nombró a Confidential Space como una plataforma de procesamiento segura.
¿Qué sigue?
- Para comenzar a usar Confidential Space, consulta Analiza datos confidenciales con Confidential Space.
- Para escuchar nuestra presentación de Next 2022, consulta What's new in confidential computing?.
- Para leer nuestro blog de anuncios, consulta Introducing Confidential Space to help unlock the value of secure data collaboration.
Para obtener más información sobre la protección de 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.