Azure Confidential Computing

Global Azure 2023

Transcript

1. #GlobalAzure
   May 11th – 13th, 2023
   

   View Slide

2. #GlobalAzure
   #YourLocationHashTag
   

   View Slide

3. View Slide

4. • Introducción
   • Manos a la obra
   • Conclusiones https://jmfloreszazo.com
   

   View Slide

5. Término que se usa en la industria por el Consorcio de Computación Confidencial (CCC), una
   fundación que se dedica a definir y acelerar el proceso de adopción de la computación confidencial.
   La CCC lo define como: la protección de datos en uso mediante la realización de cálculos en un entorno
   de ejecución fiable (Trusted Execution Environment, TEE).
   Un TEE es un entorno que impone la ejecución de solo código autorizado. Cualquier dato en el TEE no
   puede ser leído ni manipulado por ningún código fuera del entorno.
   El modelo de amenazas en informática confidencial tiene como objetivo eliminar o reducir la
   capacidad de un operador del proveedor de nube y otros actores en el dominio del inquilino para
   acceder al código y los datos mientras se ejecuta.
   

   View Slide

6. Datos en descanso
   Datos en storages, blobs,
   etc. se en encriptan
   cuando estan
   inactivos
   Datos en transito
   Encriptar datos en cuando
   viajan en redes privadas o
   publicas
   Datos en uso
   Proteger/encriptar datos en
   uso, tanto en RAM como en
   computación
   Encriptado estándar y existente Confidential Computing
   

   View Slide

7. Sistema Operativo
   Hipervisor
   Host OS
   Hardware
   App App TEE
   Datos
   Código
   Enclave
   Entrono aislado de código y datos de un Workload confidencial de otro sistema con una memoria encriptada
   

   View Slide

8. Parte no segura de la aplicación
   #2 Creación del Enclave
   la aplicación crea el enclave
   #3 CallTrusted()
   llamando a la parte segura
   #6 Logica de Aplicación
   procesado de negocio
   OS, VM, BIOS, …
   #1 App
   parte segura e insegura
   Parte segura de la aplicación
   #4 Proceso secreto
   la aplicación del enclave
   #5 Return
   función de retorno segura
   Enclave
   Bridge
   

   View Slide

9. Los datos estan bajo
   el control del cliente
   en las fase de
   descanso, transito y
   uso
   El proveedor de la
   plataforma en la nube
   esta fuera de la base
   informática de
   confianza
   El código que se
   ejecuta en la nube
   esta protegido y
   verificado por el
   cliente
   El historial de
   actividades es
   inmutable y auditable
   

   View Slide

10. Sin computación confidencial: El proveedor de la nube y la
    infraestructura puede acceder a tus datos.
    Cloud
    Con computación confidencial: Tus despliegues de Kubernetes
    estan encriptados en runtime y protegidos de la infraestructura.
    Cloud
    

    View Slide

11. Azure ofrece ya muchas herramientas para salvaguardar los datos en reposo a través de modelos de cifrados en el
    cliente y servidor. Además también existen mecanismos de seguridad como TLS y HTTPS para los datos en
    transito.
    Y aquí es donde se muestra la tercera fase: el cifrado de lo datos en uso.
    Azure nos ofrece como proveedor de la nube varios mecanismos para depender menos de la confianza en la
    infraestructura de la computación confidencial: minimiza la confianza en el kernel del sistema operativo, del host,
    del hipervisor, del administrador de la máquina virtual o del host.
    Azure Confidential Computing, nos puede ayudar con:
    • Evitar acceso no autorizados.
    • Cumplimiento de normativas.
    • Garantiza colaboración segura y no confiable.
    • Procesamiento aislado.
    

    View Slide

12. Azure nos ofrece la siguiente oferta de productos:
    • Microsoft Azure Attestation, servicio de atestación remota para validad la confiabilidad de múltiples entornos
    de ejecución confiables (TEE) y verificar la integridad de los archivos binarios que se ejecutan en el TEE.
    • Azure Key Vault Managed HSM, es un servicio totalmente administrado, de alta disponibilidad, de un solo
    inquilino y que cumple con los estándares que permiten proteger con claves criptográficas gracias a su módulo
    de seguridad gestionado por hardware.
    • Trusted Launch, disponible en máquinas G2 y que ofrece seguridad reforzada (arranque seguro, módulo de
    plataforma virtual confiable y monitoreo de integridad en el arranque) que protege conta rootkits y malware a
    nivel de kernel.
    • Azure Confidential Ledger (ACL), es un registro a prueba de manipulaciones para almacenar datos
    confidenciales para el mantenimiento de registros y auditorías o para la transparencia de datos en escenarios
    multi-party. Ofrece garantías Write-Once-Read-Many, que hacen los datos no se puedan borrar ni modificar. Se
    basa en el Confidential Consortium Framework (CCF) de Microsoft Research.
    • Azure IoT Edge, permite ejecuciones seguras a través de enclaves seguros de IoT. Los dispositivos de IoT suelen
    estar expuestos a manipulaciones y falsificaciones por que se puede trabajar físicamente con ellos. Confidential
    Edge agrega confianza e integridad a los datos capturados y enviados.
    

    View Slide

13. • Siempre cifrado con enclaves seguros en Azure SQL. La confidencialidad de los datos para que malware y
    usuarios con privilegios no autorizados puedan ejecutar consultas SQL directamente dentro de un TEE.
    • Confidential Containers on ACI. Contenedores Serverless que cumplen con el requisito de computación
    confidencial. A fecha de Septiembre de 2022 este recurso se encuentra en Private Preview.
    • Azure DCsv3 VMs with Intel SGX (DCsv2 y DCdsv3), Intel Software Guard Extensions nos permite mayor
    potencia de trabajo con Enclave. En AMD tenemos SEV-SNP (Secure Encrypted Virtualization). En resumen son
    mejoras en la CPU que admiten la implementación de CC gracias a extensiones en las VM (cifrado en memoria
    e integridad de la CPU) está presente en:
    − Las VM DCsv2, DCsv3 y DCdsv3.
    − En contenedores compatibles con enclave que se ejecuten en AKS. Los nodos usan Intel SGX.
    − VMs basadas en AMD SEV-SNP.
    − Confidential Interference ONNX Runtime, un servidor de ML que restringe el acceso a la parte que aloja
    el ML tanto en la solicitud como en la respuesta.
    

    View Slide

14. Gobierno: identidad digital, anticorrupción, prevención del cibercrimen, procesos
    judiciales, seguridad ciudadana, etc.
    Industria: propiedad intelectual, patentes, procesos, cumplimientos
    regulatorios, auditorias, etc.
    Financiero y Seguros: prevención de fraudes, pagos seguros, blanqueo de
    capitales, algoritmos de ML propietarios, etc.
    Salud: diagnósticos, prevención de fraudes a seguros, desarrollo de fármacos,
    seguimientos, historiales, confidencialidad, etc.
    

    View Slide

15. Lo primero es crear una infraestructura desde el CLI de Azure:
    • az group create --name myTestWithCC-RG --location westeurope
    • az aks create -g myTestWithCC-RG --name myTestAKSCluster --generate-ssh-keys --enable-addons confcom
    • az aks nodepool add --cluster-name myTestAKSCluster --name confcompool1 --resource-group myTestWithCC-RG
    --node-vm-size Standard_DC2s_v3 --node-count 2
    • az aks get-credentials --resource-group myTestWithCC-RG --name myTestAKSCluster
    • Visualizamos los nodos que tenemos y podemos observar que tenemos los confcompool1, los que hemos desplegado con una DC2s_v3.
    • Los nodos, llamados nodepool1, son estándar sin ningún tipo de seguridad.
    

    View Slide

16. Ahora lo que vamos a hacer es irnos a nuestro CLI y ejecutar:
    • az login
    • Nos situamos en la suscripción donde habíamos creado la infra desde el CLI de Azure.
    • az aks get-credentials --resource-group myTestWithCC-RG --name myTestAKSCluster
    • Visualizamos los nodos que tenemos funcionando los sgx-device-plugin-xxxx, esto lo podías hacer desde Azure CLI, pero
    como más adelante lo necesitamos para lanzar un YAML, por eso lo he partido en 2 acciones:
    

    View Slide

17. Y creamos el siguiente YAML, con el nombre hello-world-enclave.yaml:
    apiVersion: batch/v1
    kind: Job
    metadata:
    name: sgx-test
    labels:
    app: sgx-test
    spec:
    template:
    metadata:
    labels:
    app: sgx-test
    spec:
    containers:
    - name: sgxtest
    image: oeciteam/sgx-test:1.0
    resources:
    limits:
    sgx.intel.com/epc: 5Mi
    restartPolicy: Never
    backoffLimit: 0
    

    View Slide

18. Vamos a desgranar que hace este contenedor.
    Lo primero es ir a las fuentes y clonarlas en nuestro equipo:
    https://github.com/openenclave/openenclave/tree/master/samples/helloworld
    Donde podemos ver dos proyectos. Uno llamado Host y otro Enclave, que se corresponden con la parte no segura de la aplicación y la parte
    segura de la aplicación. Ver imagen de AKS Confidential Compute 10, de esta misma sección.
    La parte más importante de host.cs es donde se crea y llama al enclave:
    

    View Slide

19. Siendo la parte más interesante de enc.cs:
    Ya que se puede observar, no tiene nada raro en el proyecto, parece un C muy puro.
    En realidad donde esta la magia de la seguridad para los enclaves es en el fichero: helloworld.edl
    

    View Slide

20. Donde observamos que estamos usando una librería propia del SDK OpenEnclave:
    • https://openenclave.io/sdk/
    • https://github.com/openenclave/openenclave
    Y donde hemos definido que parte de la aplicación es segura y cual no lo es.
    

    View Slide

21. Microsoft
    Confidential Big Data Spark
    Confidential AI using Nvidia GPUs
    

    View Slide

22. ¿Lenguajes?
    Tras revisar este sistema y ver que efectivamente es una buena solución para aislar nuestras máquinas, K8s o algoritmos secretos, la mayoría de los
    desarrollo actuales se realizan con lenguajes distintos a C++, pongamos Python, Java, C# muchos de los cuales son interpretado. Aquí no he
    podido probar como funciona por ejemplo: https://github.com/enclaive/enclaive-docker-cs-sgx/ y ver si el ejemplo que acceder a memoria que
    tengo en mi presentación https://jmfloreszazo.com/azure-confidential-computing/ funciona igual.
    ¿Cómo se solucionará el manejo de acceso a la memoria cuando nuestras fuentes ya pueden ser descompiladas?
    Otra cuestión es el futuro, he visto que desde hace tiempo se usa este sistema, Intel SGX lleva desde 2013 y que han existido desde entonces
    ataques a Intel SGX en hardware Intel Core deprecando incluso su uso en las versiones 11th y 12th, pero manteniendo esto en los Intel Xeon. Pero
    recientemente Intel esta apostado por ello.
    ¿Cómo nos afecta esto?, ¿Por qué Microsoft esta desplegando tantas máquinas con Intel SGX y AMD SEV?, ¿Por qué se está haciendo
    tanta inversión en el consorcio por parte de Google, AMD, Intel, CISCO, NVIDIA, …?.
    Son preguntas a las que aun no he visto respuesta, pero que debido a los casos de usos planteados al principio, son las mayores beneficiarias o
    mejor dicho, las mayores beneficiarias serán las Cloud Publicas por qué podrán atraer esos sistemas a los enclaves. Eso si siendo Microsoft el que
    más está apostando en comparación con AWS y CGP.
    Y otras tantas preguntas que con el uso y revisión de los documentos del consorcio nos podrán ir surgiendo. Pero como desarrollador
    para mi lo más acuciante es el tema de los lenguajes interpretado y compilados, del cual tengo que hacer la demo y ya os contaré.
    

    View Slide

23. Y a continuación algunos enlaces:
    • Confidential Computing: The Next Frontier in Data Security.
    • A Technical Analysis of Confidential Computing v1.2.
    • Confidential Computing: Hardware-Based Trusted Execution for Applications and Data.
    • Azure Confidential Computing.
    • nVidia Confidential Computing.
    • Intel Confidential Computing.
    • Google Confidential Computing.
    • What You Need to Know About This New Cybersecurity Trend.
    • Why now is the time for confidential computing.
    • Example with C#.
    • Azure Samples (GitHub).
    

    View Slide

24. View Slide

25. View Slide