Conformità e configurazione HIPAA con Apigee Edge

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X.
informazioni

Conformità HIPAA con Apigee Edge

Garantire che i dati dei nostri clienti siano al sicuro e sempre a loro disposizione è una delle nostre priorità. Per dimostrare la propria conformità agli standard di sicurezza del settore, Google ha richiesto e ottenuto le certificazioni di sicurezza come la certificazione ISO 27001 e i controlli SOC 2 e SOC 3 di Tipo II. Per i clienti soggetti ai requisiti della normativa HIPAA (Health Insurance Portability and Accountability Act), Apigee Edge può anche supportare la conformità HIPAA.

In base alla normativa HIPAA, alcune informazioni riguardanti la salute della persona o i servizi sanitari sono considerate dati sanitari protetti (PHI, Protected Health Information). I clienti di Apigee Edge soggetti alla normativa HIPAA che intendono utilizzare Apigee Edge con dati di tipo PHI devono firmare un Contratto di società in affari (BAA) con Google.

È responsabilità dei clienti di Apigee Edge determinare se sono soggetti ai requisiti HIPAA e se utilizzano o intendono utilizzare i servizi Google con dati di tipo PHI. I clienti che non hanno firmato un BAA con Google non devono utilizzare i servizi Google con dati di tipo PHI.

Gli amministratori sono tenuti a esaminare e accettare un BAA prima di utilizzare i servizi Google con dati di tipo PHI.

Abbiamo pubblicato la nostra Guida alla configurazione HIPAA di Apigee in questo argomento per aiutare i clienti a comprendere come organizzare i dati nei servizi Google quando gestiscono dati di tipo PHI. Questa guida è rivolta ai dipendenti delle organizzazioni che sono responsabili dell'implementazione e della conformità della normativa HIPAA con Apigee Edge.

Guida alla configurazione HIPAA per Edge Public Cloud

Questa guida viene fornita unicamente a scopo informativo. Apigee non intende che le informazioni o i suggerimenti contenuti in questa guida costituiscano una consulenza legale. Ogni cliente è tenuto a valutare autonomamente il modo in cui usa i servizi per adempiere ai propri obblighi di conformità legale.

I seguenti elementi devono essere esaminati dai clienti soggetti all'Health Insurance Portability and Accountability Act (noto come HIPAA, e successive modifiche, tra cui l'Health Information Technology for Economic and Clinical Health — HITECH Act) che hanno acquistato il pacchetto di conformità HIPAA. Questi elementi sono self-service all'interno di Edge e possono aiutare a supportare l'organizzazione del cliente nel rispetto degli obblighi di conformità HIPAA. Il concetto generale è "Google protegge la piattaforma, il cliente protegge i suoi dati".

Requisiti HIPAA Sezioni
Conformità HIPAA: Sicurezza - Controllo dell'accesso Utilizzo/Autorizzazioni
Conformità HIPAA: processo di gestione della sicurezza - revisione dell'attività del sistema informatico Audit trail
Conformità HIPAA: gestione delle password di sicurezza Requisiti per le password complessi o SAML
Conformità HIPAA: Sicurezza - Processo di gestione della sicurezza Scansione degli endpoint
Conformità HIPAA: Sicurezza - Trasmissione Configurazione TLS

Traccia / Debug

Trace/Debug è uno strumento per la risoluzione dei problemi che consente all'utente di visualizzare lo stato e i contenuti di una chiamata API mentre viene elaborata tramite il processore di messaggi Apigee. Trace e Debug sono due nomi per lo stesso servizio ma accessibili tramite meccanismi diversi. Trace è il nome di questo servizio all'interno della UI Edge. Debug è il nome dello stesso servizio quando utilizzato tramite chiamate API. L'uso del termine Trace in questo documento è valido sia per Trace che per Debug.

Durante una sessione di traccia, il "mascheramento dei dati" viene applicato se abilitato e configurato dal cliente. Questo strumento può bloccare la visualizzazione dei dati durante una traccia. Consulta la sezione Mascheramento dei dati di seguito.

Le mappe chiave-valore (KVM) criptate vengono utilizzate per i clienti che richiedono la conformità HIPAA. Con un KVM criptato in uso è comunque possibile usare Trace, ma alcune variabili non saranno visibili nella schermata di visualizzazione Trace. È possibile eseguire ulteriori passaggi per visualizzare queste variabili anche durante una traccia.

Istruzioni dettagliate sull'uso di Trace sono disponibili nella pagina relativa all'utilizzo dello strumento Trace.

I dettagli sui KVM, inclusi quelli criptati, sono disponibili nella pagina Utilizzo delle mappe chiave-valore.

Utilizzo/Autorizzazioni

L'accesso a Trace è gestito tramite il sistema RBAC (Role-Based Access Control) per gli account utente all'interno di Edge (conformità HIPAA: sicurezza - controllo accesso). Istruzioni dettagliate sull'utilizzo del sistema RBAC per concedere e revocare privilegi di Trace sono disponibili in Assegnare ruoli e Creare ruoli personalizzati nella UI. Le autorizzazioni di Trace consentono all'utente di avviare una traccia, interromperne una e accedere all'output da una sessione di Trace.

Poiché Trace ha accesso al payload delle chiamate API (precedentemente chiamato "Corpo del messaggio"), è importante valutare chi ha accesso all'esecuzione di Trace. Poiché la gestione utenti è una responsabilità del cliente, anche la concessione delle autorizzazioni Trace è responsabilità del cliente. Apigee, in qualità di proprietario della piattaforma, ha la possibilità di aggiungere un utente all'organizzazione di un cliente e di assegnare i privilegi. Questa funzionalità viene utilizzata solo su richiesta del cliente per ricevere assistenza in situazioni in cui sembra che l'assistenza clienti non sia disponibile e si ritiene che l'esame di una sessione di Trace fornisca le informazioni migliori sulla causa principale.

Mascheramento dei dati

Il mascheramento dei dati impedisce la visualizzazione dei dati sensibili solo durante una sessione di Trace/Debug, sia in Trace (UI Edge) che nel backend tramite il debug (API Edge). I dettagli su come configurare il mascheramento sono disponibili nella sezione Mascheramento e occultamento dei dati.

Il mascheramento dei dati NON impedisce che i dati siano visibili nei file di log, nella cache, nell'analisi e così via. Per assistenza con il mascheramento dei dati nei log, valuta la possibilità di aggiungere un pattern regex al file logback.xml. In genere, i dati sensibili non devono essere scritti nella cache o ad analisi senza una solida giustificazione aziendale ed esame da parte dei team legali e della sicurezza.

Cache L1 e L2

L'utilizzo della cache L1 utilizzerà automaticamente anche la cache L2. La cache L1 è di "solo memoria", mentre la cache L2 scrive i dati su disco per sincronizzarli su più cache L1. La cache L2 è ciò che mantiene sincronizzati più processori di messaggi all'interno di una regione e a livello globale. Al momento non è possibile avere la cache L1 abilitata senza una cache L2. La cache L2 scrive i dati sul disco in modo che possano essere sincronizzati con altri processori di messaggi per l'organizzazione del cliente. Istruzioni dettagliate sull'utilizzo della cache sono disponibili in Aggiunta di memorizzazione nella cache e persistenza.

Audit trail

I Clienti hanno la possibilità di esaminare l'audit trail di tutte le attività amministrative eseguite all'interno della loro organizzazione, incluso l'utilizzo di Trace (conformità HIPAA: Security Management Process - Information System Activity Review). Istruzioni dettagliate sono disponibili qui e nella pagina relativa all'utilizzo dello strumento Trace.

Requisiti per password complesse o SAML

Per i clienti HIPAA, le password utente sono configurate in modo da soddisfare requisiti avanzati come lunghezza, complessità e durata. (Conformità HIPAA: Gestione delle password di sicurezza)

Edge offre inoltre l'autenticazione a più fattori, descritta in Abilitare l'autenticazione a due fattori per il tuo account Apigee, e SAML, descritta in Abilitazione dell'autenticazione SAML per Edge, come alternativa ai controlli di autenticazione.

Sicurezza degli endpoint

Analisi degli endpoint

I clienti di Edge Cloud sono responsabili della scansione e dei test dei loro endpoint API (a volte chiamati "componenti di runtime") in Edge ( conformità HIPAA: Sicurezza - Processo di gestione della sicurezza). I test dei clienti devono riguardare gli effettivi servizi proxy API ospitati su Edge, dove il traffico API viene inviato a Edge prima di essere elaborato e poi consegnato al data center del cliente. Il test delle risorse condivise, ad esempio l'interfaccia utente del portale di gestione, non è approvato per i singoli clienti (un report di terze parti relativo ai test dei servizi condivisi è disponibile per i clienti ai sensi di un accordo di non divulgazione e su richiesta).

I clienti dovrebbero testare i loro endpoint API e sono incoraggiati a farlo. Il tuo contratto con Apigee non vieta i test degli endpoint API, ma ti richiede di non testare l'UI di gestione condivisa. Anche se sono necessari ulteriori chiarimenti, apri un ticket di assistenza che faccia riferimento ai test pianificati. Si prega di inviare in anticipo una notifica ad Apigee per consentirci di venire a conoscenza del traffico di test.

I clienti che testano i loro endpoint devono cercare eventuali problemi specifici delle API, eventuali problemi relativi ai servizi Apigee e anche controllare il protocollo TLS e altri elementi configurabili. Tutti gli elementi trovati e correlati ai servizi Apigee devono essere comunicati ad Apigee tramite un ticket di assistenza.

La maggior parte degli elementi relativi all'endpoint sono self-service del cliente e possono essere risolti esaminando la documentazione di Edge. Se non è chiaro come risolvere il problema, apri una richiesta di assistenza.

Configurazione TLS

È responsabilità dei clienti definire e configurare i propri endpoint TLS per i proxy API. Questa è una funzionalità self-service di Edge. I requisiti dei clienti in merito alla selezione di crittografia, protocollo e algoritmi sono ampiamente variabili e specifici per singoli casi d'uso. Poiché Apigee non conosce i dettagli del design delle API e dei payload dei dati di ogni cliente, i clienti hanno la responsabilità di determinare la crittografia appropriata per i dati in transito ( conformità HIPAA: Sicurezza - Trasmissione).

Istruzioni dettagliate sulla configurazione TLS sono disponibili in TLS/SSL.

Archiviazione dati

L'archiviazione dei dati in Edge non è necessaria per il corretto funzionamento di Edge. Tuttavia, sono disponibili servizi per l'archiviazione dei dati in Edge. I clienti possono scegliere di utilizzare la cache o le analisi per l'archiviazione dei dati. Per evitare l'uso accidentale o dannoso dei servizi di archiviazione dati di Edge in modo non conforme da parte degli amministratori dei clienti, consigliamo di controllare la configurazione, i criteri e i deployment da parte degli amministratori dei clienti.

Crittografia dei dati del payload

Gli strumenti di crittografia dei dati non vengono offerti ai clienti per il loro utilizzo all'interno di Edge. Tuttavia, i clienti sono liberi di criptare i dati prima di inviarli a Edge. I dati criptati nel payload (o nel corpo del messaggio) non impediscono il funzionamento di Edge. Alcuni criteri perimetrali potrebbero non essere in grado di interagire con i dati se vengono ricevuti criptati dal cliente. Ad esempio, una trasformazione non è possibile se i dati stessi non sono disponibili per la modifica a Edge. Tuttavia, altri criteri e pacchetti creati dal cliente funzioneranno anche se il payload dei dati è criptato.

PII negli URI

La piattaforma di analisi unificata di Apigee (UAP) acquisisce i dati di analisi, compresi eventuali dati di tipo PHI o altri dati sensibili inclusi nell'URI (Uniform Resource Identifier) di una chiamata API in Apigee Edge e li conserva per 13 mesi. PHI nell'URI è supportato dagli standard FHIR (Fast Healthcare Interoperability Resources) ed è quindi supportato da Apigee. I dati di analisi nell'UAP sono criptati at-rest per impostazione predefinita.

Al momento Apigee non supporta:

  • Mascheramento dei dati in UAP
  • Modificare il ciclo di conservazione
  • Disattivazione di UAP
  • Eliminazione dell'URI dalla raccolta dati UAP