Confidential computing per piattaforme di servizi sanitari

Servizio Azure Kubernetes

Questo articolo illustra una soluzione offerta da Azure Confidential Computing (ACC) per la crittografia dei dati in uso.

Architettura

Diagramma di una dimostrazione della piattaforma sanitaria riservata. La piattaforma include un provider di piattaforme ospedaliere, mediche e un provider di diagnostica.

Scaricare un file di Visio di questa architettura.

Il diagramma illustra l'architettura. In tutto il sistema:

Flusso di lavoro

La soluzione include i passaggi seguenti:

  1. Un impiegato di un ospedale locale apre un portale Web. L'intera app Web è un sito Web Azure Blob Storage statico.
  2. L'impiegato immette i dati nel portale Web dell'ospedale, che si connette a un'API Web basata su Python Flask creata da un popolare fornitore di piattaforme medicali. Un nodo riservato nel software di confidential computing SCONE protegge i dati dei pazienti. SCONE funziona all'interno di un cluster del servizio Azure Kubernetes con Software Guard Extensions (SGX) abilitato che consente di eseguire il contenitore in un enclave. L'API Web fornirà la prova che i dati sensibili e il codice dell'app sono crittografati e isolati in un ambiente di esecuzione attendibile. Ciò significa che nessun utente, nessun processo e nessun log ha accesso ai dati con testo non crittografato o al codice dell'applicazione.
  3. Il client dell'app Web dell'ospedale richiede che un servizio di attestazione (attestazione di Azure) convalidi questa evidenza e riceva un token di attestazione firmato per la verifica da parte di altre app.
  4. Se l'API Web richiede componenti aggiuntivi (ad esempio una cache Redis), può passare il token di attestazione per verificare che i dati e il codice dell'app siano rimasti finora in un enclave sicuro (vedere il passaggio 6 per la verifica).
  5. L'API Web può anche utilizzare servizi remoti, ad esempio un modello ML ospitato da un provider di diagnostica di terze parti. In questo caso, continua a passare tutti i token di attestazione per l'evidenza che gli enclave necessari sono sicuri. L'API Web può anche tentare di ricevere e verificare i token di attestazione per l'infrastruttura del provider di diagnostica.
  6. L'infrastruttura remota accetta il token di attestazione dall'API Web della piattaforma medicale e lo verifica con un certificato pubblico trovato nel servizio di attestazione di Azure. Se il token viene verificato, è quasi certo che l'enclave sia sicuro e che i dati o il codice dell'app non siano stati aperti all'esterno dell'enclave.
  7. Il provider di diagnostica, una volta accertato che i dati non siano stati esposti, li invia nel proprio enclave in un server di runtime ONNX (Open Neural Network Exchange). Un modello di intelligenza artificiale interpreta le immagini mediche e restituisce i risultati della diagnosi all'app dell’API Web riservata della piattaforma medicale. Da qui, il software può quindi interagire con le cartelle dei pazienti e/o contattare il personale dell'ospedale.

Componenti

  • Azure Blob Storage serve contenuto statico come HTML, CSS, JavaScript e file di immagine direttamente da un contenitore di archiviazione.

  • L’attestazione di Azure è una soluzione unificata che verifica in remoto l'attendibilità di una piattaforma. Attestazione di Azure verifica anche in remoto l'integrità dei file binari eseguiti nella piattaforma. Usare l’attestazione di Azure per stabilire l'attendibilità con l'applicazione riservata.

  • Azure Kubernetes Service semplifica il processo di distribuzione di un cluster Kubernetes.

  • I nodi di confidential computing sono ospitati in una serie di macchine virtuali specifiche in grado di eseguire carichi di lavoro sensibili nel servizio Azure Kubernetes all'interno di un ambiente TEE (trusted execution environment) basato su hardware consentendo al codice a livello utente di allocare aree private di memoria, note come enclave. I nodi di confidential computing possono supportare contenitori riservati o contenitori in grado di riconoscere l'enclave.

  • La piattaforma SCONE è una soluzione per ISV (Independent Software Vendor) partner di Azure di Scontain.

  • Redis è un archivio dati in memoria open source.

  • Secure Container Environment (SCONE) supporta l'esecuzione di applicazioni riservate in contenitori eseguiti all'interno di un cluster Kubernetes.

  • Confidential Inferencing ONNX Runtime Server Enclave (ONNX RT - Enclave) è un host che impedisce all'entità host ML di accedere sia alla richiesta di inferenza che alla risposta corrispondente.

Alternativi

  • È possibile usare Fortanix anziché SCONE per distribuire contenitori riservati da usare con l'applicazione in contenitori. Fortanix offre la flessibilità necessaria per eseguire e gestire il set più ampio di applicazioni: applicazioni esistenti, nuove applicazioni native dell'enclave e applicazioni preassemblate.

  • Graphene è un sistema operativo guest leggero e open source. Graphene può eseguire una singola applicazione Linux in un ambiente isolato con vantaggi paragonabili all'esecuzione di un sistema operativo completo. Offre un supporto ottimale con strumenti per la conversione di applicazioni contenitore Docker esistenti in contenitori schermati Graphene (GSC).

Dettagli dello scenario

Quando le organizzazioni collaborano, condividono le informazioni. Ma la maggioranza delle parti non vuole concedere ad altre l'accesso a tutte le porzioni di dati. Esistono meccanismi per la protezione dei dati inattivi e in transito. Tuttavia, la crittografia dei dati in uso pone diversi problemi.

Usando il confidential computing e i contenitori, la soluzione consente a un'applicazione ospitata dal provider di collaborare in modo sicuro con un ospedale e un provider di diagnostica di terze parti. Il servizio Azure Kubernetes ospita nodi di confidential computing. L’attestazione di Azure stabilisce l'attendibilità con il provider di diagnostica. Usando questi componenti di Azure, l'architettura isola i dati sensibili dei pazienti dell'ospedale mentre i dati condivisi specifici vengono elaborati nel cloud. I dati dell'ospedale non sono quindi accessibili al provider di diagnostica. Tramite questa architettura, l'applicazione ospitata dal provider può sfruttare anche l'analisi avanzata. Il provider di diagnostica rende queste analisi disponibili come servizi di confidential computing delle applicazioni di Machine Learning (ML).

Potenziali casi d'uso

Molti settori proteggono i dati usando il confidential computing per questi scopi:

  • Protezione di dati finanziari
  • Protezione delle informazioni dei pazienti
  • Esecuzione dei processi ML su informazioni riservate
  • Esecuzione di algoritmi su set di dati crittografati provenienti da più origini
  • Protezione dei dati dei contenitori e dell'integrità del codice

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di set di guide che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Le macchine virtuali (VM) di confidential computing di Azure sono disponibili in dimensioni della famiglia D di seconda generazione per esigenze di utilizzo generico. Queste dimensioni sono note collettivamente come serie D v2 o DCsv2. Questo scenario usa macchine virtuali serie DCs_v2 abilitate per SGX con immagini del sistema operativo Gen2. È tuttavia possibile distribuire solo determinate dimensioni in determinate aree. Per altre informazioni, vedere Avvio rapido: Distribuire una VM di Azure Confidential Computing nel Marketplace e Prodotti disponibili per area.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Per esplorare il costo di esecuzione di questo scenario, usare il calcolatore prezzi di Azure, che preconfigura tutti i servizi di Azure.

Per la piattaforma SaaS medica Contoso è disponibile un profilo di costi di esempio, come illustrato nel diagramma. Include i componenti seguenti:

  • Pool di nodi di sistema e pool di nodi SGX: nessun disco, tutti effimeri
  • Bilanciamento del carico del servizio Azure Kubernetes
  • Rete virtuale di Microsoft Azure: nominale
  • Registro Azure Container
  • Account di archiviazione per l'applicazione a pagina singola (SPA)

Il profilo non include i componenti seguenti:

  • Servizio di attestazione di Azure: gratuito

  • Log di Monitoraggio di Azure: basato sull'utilizzo

  • Licenze ISV SCONE

  • Servizi di conformità obbligatori per le soluzioni che funzionano con dati sensibili, tra cui:

    • Microsoft Defender for Cloud e Microsoft Defender for Kubernetes
    • Protezione DDoS di Azure: Protezione di rete
    • Firewall di Azure
    • Gateway applicazione di Azure e Web Application firewall di Azure
    • Insieme di credenziali chiave di Azure

Distribuire lo scenario

La distribuzione di questo scenario comporta i seguenti passaggi globali:

  • Distribuire il server di inferenza riservata in un cluster del servizio Azure Kubernetes abilitato per SGX esistente. Vedere il progetto del server di inferenza ONNX riservato su GitHub per informazioni su questo passaggio.

  • Configurare i criteri di attestazione di Azure.

  • Distribuire un pool di nodi del cluster del servizio Azure Kubernetes abilitato per SGX.

  • Ottenere l'accesso ad applicazioni riservate curate denominate SconeApps. SconeApps è disponibile in un repository GitHub privato attualmente disponibile solo per i clienti commerciali, tramite SCONE edizione Standard. Passare al sito Web di SCONE e contattare direttamente l'azienda per ottenere questo livello di servizio.

  • Installare ed eseguire i servizi SCONE nel cluster del servizio Azure Kubernetes.

  • Installare e testare l'applicazione basata su Flask nel cluster del servizio Azure Kubernetes.

  • Distribuire e accedere al client Web.

Questi passaggi sono incentrati sui contenitori dell'enclave. Un'infrastruttura protetta va oltre questa implementazione e include requisiti di conformità, ad esempio protezioni aggiunte richieste da HIPAA.

Autori di contributi

Questo articolo viene gestito da Microsoft. È stato originariamente scritto dai collaboratori seguenti.

Autore principale:

Passaggi successivi