Google Cloud importa chiavi quantum-safe mentre AWS porta l’AI nella sicurezza sanitaria

🛡️ Executive Summary

• Google Cloud KMS introduce in preview l’importazione quantum-safe delle chiavi software BYOK attraverso HPKE, X-Wing e gli algoritmi standardizzati ML-KEM.
• AWS propone un’architettura Bedrock che analizza in modo asincrono gli accessi alle API FHIR senza sostituire autenticazione, RBAC e controlli autorizzativi tradizionali.
• Guardrails, Comprehend Medical e Structured Outputs proteggono i dati sanitari, mentre l’AI classifica sensibilità, anomalie comportamentali e produce report di compliance.

Google e AWS applicano due tecnologie emergenti a problemi di sicurezza che esistono già oggi: proteggere le chiavi crittografiche nel cloud e controllare l’accesso ai dati sanitari. Google Cloud KMS introduce in preview l’importazione quantum-safe delle chiavi software utilizzate nelle architetture Bring Your Own Key, aggiungendo una protezione post-quantum al trasferimento verso il servizio. Amazon Web Services mostra invece come utilizzare Amazon Bedrock sopra le API sanitarie FHIR per identificare accessi anomali, classificare automaticamente la sensibilità delle informazioni e generare documentazione di compliance. In entrambi i casi la novità non sostituisce i controlli esistenti: aggiunge un nuovo livello sopra infrastrutture già operative.

Google Cloud protegge anche il viaggio delle chiavi verso KMS

Con il nuovo quantum-safe key import di Cloud KMS Google affronta un punto specifico della migrazione post-quantum: il momento nel quale una chiave generata dal cliente viene trasferita verso il cloud. Nei modelli BYOK tradizionali il materiale crittografico viene protetto durante l’importazione utilizzando algoritmi asimmetrici classici. Questi restano sicuri contro gli attacchi disponibili oggi, ma potrebbero diventare vulnerabili davanti a un computer quantistico crittograficamente rilevante. Un avversario potrebbe quindi intercettare e conservare oggi il materiale cifrato nella speranza di decifrarlo successivamente, secondo il modello Store Now, Decrypt Later. La nuova funzione crea invece fin dall’origine una busta di trasporto resistente al quantum. È il passaggio successivo della strategia già avviata da Google con firme digitali post-quantistiche e nuove funzioni Cloud KMS, spostando la protezione dalla sola firma e gestione della chiave anche alla fase di importazione.

HPKE combina ML-KEM, AES-256-GCM e derivazione della chiave

Il meccanismo utilizza Hybrid Public Key Encryption, HPKE. Il client crea un import job post-quantum attraverso le API di Cloud KMS; Google genera una chiave privata KEM e restituisce la corrispondente chiave pubblica. Sul sistema locale, librerie come Tink o OpenSSL eseguono l’operazione HPKE Seal(): il KEM stabilisce un segreto condiviso, HKDF-SHA-256 deriva una chiave AES temporanea e AES-256-GCM cifra il materiale che il cliente vuole importare. Cloud KMS riceve ciphertext e chiave incapsulata e completa l’operazione Open() all’interno del proprio perimetro. Per il livello KEM sono disponibili X-Wing, ML-KEM-768 e ML-KEM-1024, permettendo di adottare primitive standardizzate senza ricostruire l’intero workflow BYOK. Google rende inoltre generalmente disponibile Cloud KMS PQC Insights, che mostra quali chiavi asimmetriche utilizzano algoritmi classici o post-quantum e facilita la costruzione dell’inventario crittografico. È esattamente il tipo di migrazione progressiva indicato anche nelle linee guida sulla crittografia e sull’agilità degli algoritmi: il problema non consiste nel sostituire improvvisamente tutta la crittografia, ma nel sapere dove si trovano le primitive destinate a diventare obsolete.

AWS usa Bedrock per osservare le API FHIR senza rallentare le richieste

AWS affronta un problema completamente diverso attraverso la proposta di sicurezza intelligente per le API sanitarie con Amazon Bedrock. L’architettura è costruita intorno allo standard FHIR R4 e mantiene separati enforcement e analisi comportamentale. Amazon API Gateway riceve le richieste, una Lambda authorizer verifica JWT e autorizzazioni memorizzate in DynamoDB, mentre AWS HealthLake serve i dati sanitari. Soltanto dopo la risposta al client, EventBridge inoltra l’evento a funzioni Lambda dedicate all’anomaly detection, alla classificazione della sensibilità e alla reportistica. Bedrock opera quindi fuori dal percorso sincrono della richiesta, evitando di aggiungere latenza alle applicazioni cliniche.

Il modello è deliberatamente complementare: l’AI non decide se una password o un token siano validi e non sostituisce RBAC. Cerca invece comportamenti che un sistema statico può considerare formalmente autorizzati ma anomali, come un medico che normalmente consulta una decina di cartelle durante il giorno e improvvisamente ne scarica 500 alle tre del mattino.

Claude costruisce baseline comportamentali e classifica i dati sanitari

L’anomaly analyzer confronta ogni accesso con ruolo, cronologia, natura della risorsa e comportamento precedente dell’utente, producendo un rischio LOW, MEDIUM o HIGH attraverso Structured Outputs. AWS propone Claude Sonnet 4.5 per questa analisi più complessa e Claude Haiku 4.5 per la classificazione della sensibilità dei dati, dove le risorse FHIR vengono suddivise in PUBLIC, INTERNAL, CONFIDENTIAL o RESTRICTED. Un valore di glicemia può quindi ricevere una classificazione differente rispetto a un risultato relativo all’HIV senza mantenere manualmente enormi tabelle di mapping. La classificazione viene registrata in DynamoDB e può essere utilizzata dall’authorization layer durante gli accessi successivi. È una forma di content-aware authorization aggiunta sopra i controlli tradizionali, non un loro sostituto. L’approccio riflette la trasformazione più generale di Bedrock e AgentCore verso componenti AI inseriti in workflow regolamentati e verificabili, dove il modello viene confinato dentro una catena di autorizzazioni, schemi e registrazione delle attività.

I dati sanitari vengono filtrati prima e dopo il modello

La parte più delicata dell’architettura AWS riguarda inevitabilmente le Protected Health Information, PHI. Bedrock Guardrails anonimizza PII nei prompt e nelle risposte, mentre Amazon Comprehend Medical DetectPHI effettua un ulteriore passaggio prima che l’output venga scritto nei log CloudWatch. Gli indirizzi IP non vengono inviati integralmente al modello ma ridotti alle categorie “interno” o “esterno”, e gli alert SNS contengono soltanto un identificativo hash e il livello di rischio. Structured Outputs vincola inoltre il modello a schemi JSON e valori predefiniti, riducendo la possibilità che informazioni sensibili finiscano accidentalmente nei sistemi downstream. L’anomaly analyzer opera in modalità fail-open, perché un problema del motore AI non deve interrompere un workflow clinico; il sensitivity classifier utilizza invece un comportamento fail-secure, assegnando CONFIDENTIAL quando la classificazione fallisce. È una distinzione architetturale importante in un settore dove violazioni e infrastrutture sanitarie esposte continuano a mostrare il valore dei dati clinici per gli attaccanti.

Google e AWS affrontano quindi due estremi della stessa trasformazione. Google prepara la crittografia cloud a minacce che potrebbero materializzarsi tra anni, mentre AWS utilizza i modelli generativi per individuare comportamenti sospetti che avvengono oggi. Nel primo caso la parola chiave è crypto-agility: introdurre algoritmi post-quantum senza distruggere processi BYOK già consolidati. Nel secondo è separazione dei compiti: lasciare identità e autorizzazione a controlli deterministici e utilizzare l’AI dove può aggiungere contesto. Due strategie differenti, accomunate da un principio che diventa sempre più centrale nella sicurezza cloud: le nuove tecnologie funzionano meglio quando rafforzano i controlli esistenti invece di pretendere di sostituirli.