Modifica

Microservizi serverless integrati tramite una rete virtuale

Gestione API di Azure
Azure Cosmos DB
Funzioni di Azure
Insieme di credenziali chiave di Azure
Rete virtuale di Azure

In questa soluzione di Azure, Gestione API di Azure controlla l'accesso all'API tramite un singolo endpoint gestito. Il back-end dell'applicazione è costituito da due app per microservizi di Funzioni di Azure interdipendenti che creano e gestiscono le cartelle cliniche dei pazienti e i record di controllo. Gestione API e le due app per le funzioni accedono l'una all'altra tramite una rete virtuale bloccata.

Questo articolo e il progetto di codice associato illustrano lo scenario di esempio con i principali componenti tecnici, in modo da offrire una base per implementazioni specifiche. La soluzione automatizza tutte le distribuzioni di codice e infrastruttura con Terraform e include test di integrazione e carico e unit test automatizzati.

Architettura

Il diagramma seguente mostra il flusso della richiesta di creazione delle cartelle dei pazienti:

Diagram showing virtual network integrated microservices.

Scaricare un file di Visio di questa architettura.

Workflow

  1. I servizi e i client esterni inviano una richiesta POST a Gestione API, con un corpo di dati che include informazioni sui pazienti.
  2. Gestione API chiama la funzione CreatePatient dell'API Patient con le informazioni sul paziente specificato.
  3. La funzione CreatePatient dell'API Patient chiama la funzione CreateAuditRecord dell'app per le funzioni API Audit per creare un record di controllo.
  4. La funzione CreateAuditRecord dell'API Audit crea il record di controllo in Azure Cosmos DB e restituisce una risposta di esito positivo alla funzione CreatePatient dell'API Patient.
  5. La funzione CreatePatient crea il documento del paziente in Azure Cosmos DB e restituisce una risposta di esito positivo a Gestione API.
  6. I client e i servizi esterni ricevono la risposta di esito positivo da Gestione API.

Componenti

La soluzione usa i componenti seguenti:

  • Azure Gestione API (APIM) è una piattaforma ibrida multicloud per la gestione delle API in tutti gli ambienti. In questa soluzione Gestione API controlla l'accesso interno e di terze parti all'API Patient che consente la lettura e/o la scrittura dei dati. Gestione API consente una facile integrazione con diversi meccanismi di autenticazione.

  • Funzioni di Azure è una piattaforma di calcolo serverless che gestisce piccole porzioni di codice guidate da eventi. L'infrastruttura cloud fornisce i server aggiornati necessari per eseguire le funzioni su larga scala. La soluzione illustrata usa un set di due microservizi API di Funzioni di Azure che creano e gestiscono le operazioni per i risultati degli esami dei pazienti e i record di controllo.

  • Rete virtuale di Azure offre un ambiente applicativo isolato e altamente sicuro limitando l'accesso di rete a subnet o indirizzi IP specifici. Entrambi i servizi Gestione API e Funzioni di Azure supportano la restrizione di accesso e la distribuzione nelle reti virtuali. Questa soluzione usa l'integrazione della rete virtuale a livello di area per distribuire entrambe le app per le funzioni nella stessa rete virtuale all'interno della stessa area.

  • Azure Key Vault archivia, crittografa e gestisce in modo centralizzato l'accesso a chiavi, certificati e stringhe di connessione. Questa soluzione gestisce le chiavi host di Funzioni di Azure e le stringhe di connessione di Azure Cosmos DB in un insieme di credenziali delle chiavi a cui possono accedere solo le identità specificate.

  • Azure Cosmos DB è un database serverless completamente gestito con scalabilità automatica immediata. Nella soluzione illustrata, entrambi i microservizi archiviano i dati in Azure Cosmos DB tramite il driver Node.js di MongoDB. I servizi non condividono dati ed è possibile distribuire ogni servizio in uno specifico database indipendente.

  • Application Insights, una funzionalità di Monitoraggio di Azure, genera report sulle prestazioni, l'utilizzo, la disponibilità e il comportamento delle applicazioni per rilevare e diagnosticare eventuali anomalie.

    Gli errori nell'architettura basata su microservizi sono spesso correlati a diversi componenti e non possono essere diagnosticati esaminando singolarmente i vari servizi. La possibilità di correlare i dati di telemetria tra i componenti è fondamentale per diagnosticare questi problemi. La telemetria di Application Insights consente di gestire in maniera centralizzata la registrazione dei dati per l'intera pipeline di richieste in modo da rilevare eventuali anomalie nelle prestazioni. I dati di telemetria condividono un ID operazione, consentendo la correlazione tra i componenti.

    In Gestione API e nel runtime di Funzioni di Azure è incorporato il supporto per Application Insights in modo da generare e correlare un'ampia gamma di dati di telemetria, incluso l'output standard delle applicazioni. Le app per le funzioni usano Application Insights SDK per Node.js per tenere traccia manualmente delle dipendenze e di altri dati di telemetria personalizzati.

    Per altre informazioni sulla traccia dei dati di telemetria distribuiti in questa soluzione, vedere Telemetria distribuita.

Alternative

  • La soluzione corrente richiede una chiave di sottoscrizione per accedere all'endpoint di Gestione API, ma è anche possibile usare l'autenticazione Microsoft Entra.
  • Oltre a richiedere le chiavi di accesso api, è possibile usare l'autenticazione servizio app predefinita di Funzioni di Azure per abilitare l'autorizzazione di Microsoft Entra per le identità gestite delle API.
  • È possibile sostituire l'endpoint di Azure Cosmos DB in questa soluzione con un altro servizio MongoDB senza modificare il codice.
  • Per una maggiore sicurezza di Azure Cosmos DB, è possibile bloccare il traffico dai database Azure Cosmos DB alle app per le funzioni.
  • Componenti come Azure Cosmos DB possono inviare dati di telemetria a Monitoraggio di Azure, dove possono essere correlati ai dati di telemetria generati da Application Insights.
  • In alternativa a Terraform, è possibile usare il portale o l'interfaccia della riga di comando di Azure per le attività di rotazione delle chiavi di Key Vault.
  • Sempre in alternativa a Terraform, è possibile usare un sistema come Azure DevOps o GitHub Actions per automatizzare la distribuzione della soluzione.
  • Per una maggiore disponibilità, questa soluzione può essere distribuita in più aree. Impostare Azure Cosmos DB come multimaster, usare il supporto per più aree integrato in Gestione API e distribuire le app per le funzioni di Azure in aree abbinate.

Dettagli dello scenario

Questo articolo descrive una soluzione integrata per la gestione delle cartelle cliniche dei pazienti. Un'organizzazione che opera in campo medico-sanitario deve archiviare digitalmente nel cloud grandi quantità di dati altamente sensibili sugli esami clinici dei pazienti. I sistemi interni e di terze parti devono essere in grado di leggere e scrivere i dati in modo sicuro tramite un'API (Application Programming Interface). Tutte le interazioni con i dati devono essere riportate in un registro di controllo.

Potenziali casi d'uso

  • Accedere a dati altamente sensibili da endpoint esterni designati.
  • Implementare una procedura di controllo sicura per le operazioni di accesso ai dati.
  • Integrare app per microservizi interdipendenti con accesso e sicurezza comuni.
  • Usare le funzionalità di sicurezza della rete virtuale sfruttando al tempo stesso la flessibilità e il risparmio sui costi offerti da una soluzione serverless.

Vantaggi

Tra i vantaggi delle applicazioni serverless come Funzioni di Azure sono inclusi il risparmio sui costi e la flessibilità, grazie alla possibilità di usare solo le risorse di calcolo necessarie, anziché pagare anticipatamente per server dedicati. Questa soluzione consente a Funzioni di Azure di usare le restrizioni di accesso alla rete virtuale per la sicurezza, senza dover sostenere il costo e il sovraccarico operativo degli ambienti del servizio app di Azure (ASE) completi.

Gestione API controlla l'accesso interno e di terze parti a un set di microservizi API basato su Funzioni di Azure. L'API Patient fornisce operazioni di creazione, lettura, aggiornamento ed eliminazione per i pazienti e i risultati dei loro esami. L'API Audit fornisce operazioni per creare voci di controllo.

Ciascuna di queste due app per le funzioni archivia i propri dati in un database Azure Cosmos DB indipendente. Azure Key Vault conserva in modo sicuro tutti i segreti, le chiavi e le stringhe di connessione associati alle app e ai database. La telemetria di Application Insights e Monitoraggio di Azure consentono la registrazione centralizzata dei dati nel sistema.

Considerazioni

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

Quando si implementa questa soluzione, prendere in considerazione gli aspetti seguenti.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

A causa della riservatezza dei dati, la sicurezza è fondamentale in questa soluzione. Per proteggere i dati vengono adottati diversi meccanismi:

  • Gestione del gateway di Gestione API
  • Restrizioni di accesso alla rete virtuale
  • Chiavi di accesso e stringhe di connessione al servizio
  • Gestione delle chiavi e delle stringhe di connessione in Key Vault
  • Rotazione delle chiavi di Key Vault
  • Identità del servizio gestite

È possibile proteggere l'istanza di Azure Gestione API da attacchi DDoS (Distributed Denial of Service) usando la protezione DDoS di Azure. Protezione DDoS di Azure offre funzionalità avanzate di mitigazione DDoS per difendersi dagli attacchi DDoS a livello di dati e protocolli.

Per altre informazioni sul modello di sicurezza per questa soluzione, vedere Modello di sicurezza per la comunicazione tra Gestione API, app per le funzioni e Azure Cosmos DB.

Gestione del gateway di Gestione API

Il sistema è accessibile pubblicamente solo tramite il singolo endpoint gestito di Gestione API. La subnet di Gestione API limita il traffico in ingresso agli indirizzi IP dei nodi del gateway specificati.

Gestione API consente una facile integrazione con diversi meccanismi di autenticazione. La soluzione corrente richiede una chiave di sottoscrizione, ma è anche possibile usare Microsoft Entra ID per proteggere l'endpoint di Gestione API senza dover gestire le chiavi di sottoscrizione in Gestione API.

Rete virtuale

Per evitare di esporre API e funzioni pubblicamente, Rete virtuale di Azure limita l'accesso di rete per API e funzioni a subnet o indirizzi IP specifici. Entrambi i servizi Gestione API e Funzioni di Azure supportano la restrizione dell'accesso e la distribuzione nelle reti virtuali.

Le app per le funzioni possono limitare l'accesso a indirizzi IPv4 o IPv6 e subnet della rete virtuale. Per impostazione predefinita, un'app per le funzioni consente l'accesso completo, ma dopo l'aggiunta di una o più restrizioni relative a indirizzi o subnet, tutto il resto del traffico di rete viene rifiutato.

In questa soluzione le app per le funzioni consentono le interazioni solo all'interno della specifica rete virtuale. L'API Patient consente le chiamate dalla subnet di Gestione API aggiungendo la subnet di Gestione API all'elenco consenti restrizioni di accesso. L'API Audit consente la comunicazione con l'API Patient aggiungendo la subnet dell'API Paziente all'elenco degli elementi consentiti per le restrizioni di accesso. Le API rifiutano il traffico proveniente da altre origini.

La soluzione usa l'integrazione della rete virtuale a livello di area per integrare Gestione API e le app per le funzioni con la stessa rete virtuale e la stessa area di Azure. Per l'uso dell'integrazione della rete virtuale a livello di area è necessario considerare diversi fattori importanti:

  • Per usufruire sia dell'integrazione della rete virtuale a livello di area sia della scalabilità è necessario usare lo SKU Premium di Funzioni di Azure.
  • Per abilitare la connettività della rete virtuale, è necessario usare lo SKU Developer o Premium di Gestione API
  • Poiché le app per le funzioni vengono distribuite in una subnet della rete virtuale, è necessario configurare le restrizioni di accesso di tali app per consentire il traffico da altre subnet nella rete virtuale.
  • L'integrazione della rete virtuale a livello di area limita solo il traffico in uscita dalla funzione di Azure alla rete virtuale. Il traffico in ingresso continua a essere instradato all'esterno della rete virtuale, anche se limitatamente all'elenco di accesso dell'app.

Solo gli ambienti del servizio app offrono l'isolamento completo della rete virtuale a livello di rete. Questi ambienti possono richiedere impegno e costi di implementazione notevolmente maggiori rispetto a Funzioni di Azure, in cui è supportata l'integrazione della rete virtuale a livello di area. Inoltre, il ridimensionamento di questi ambienti è meno elastico.

Access keys

Gestione API e le app per le funzioni possono essere chiamate anche senza l'uso di chiavi di accesso. La disabilitazione delle chiavi di accesso non è tuttavia una procedura di sicurezza consigliata e quindi per l'accesso a tutti i componenti di questa soluzione è necessario l'uso di chiavi.

  • L'accesso a Gestione API richiede una chiave di sottoscrizione e pertanto gli utenti devono includere Ocp-Apim-Subscription-Key nelle intestazioni HTTP.
  • Tutte le funzioni nell'app per le funzioni API Patient richiedono una chiave di accesso API e pertanto Gestione API deve includere x-functions-key nell'intestazione HTTP quando chiama l'API Patient.
  • Per le chiamate a CreateAuditRecord nell'app per le funzioni API Audit è necessario usare una chiave di accesso API e pertanto l'API Patient deve includere x-functions-key nell'intestazione HTTP quando chiama la funzione CreateAuditRecord.
  • Entrambe le app per le funzioni usano Azure Cosmos DB come archivio dati, quindi devono usare stringa di connessione per accedere ai database di Azure Cosmos DB.

Archiviazione in Key Vault

Anche se è possibile mantenere le chiavi di accesso e le stringhe di connessione nelle impostazioni di un'applicazione, questa procedura non è consigliata, perché chiunque disponga dell'accesso all'app può visualizzare le chiavi e le stringhe. La procedura consigliata, soprattutto per gli ambienti di produzione, consiste nel conservare le chiavi e le stringhe in Azure Key Vault e nell'usare i riferimenti di Key Vault per chiamare le app. Key Vault consente l'accesso solo alle identità gestite specificate.

Per migliorare le prestazioni, Gestione API applica criteri in ingresso per memorizzare nella cache la chiave host dell'API Patient. In questo modo, per i successivi tentativi di accesso, Gestione API cerca prima la chiave nella cache.

  • Gestione API recupera la chiave host dell'API Patient, la memorizza nella cache e la inserisce in un'intestazione HTTP quando chiama l'app per le funzioni API Patient.
  • L'app per le funzioni API Patient recupera la chiave host dell'API Audit da Key Vault e la inserisce in un'intestazione HTTP quando chiama l'app per le funzioni API Audit.
  • Il runtime di Funzioni di Azure convalida le chiavi nelle intestazioni HTTP delle richieste in ingresso.

Rotazione delle chiavi

La rotazione delle chiavi di Key Vault consente di rendere più sicuro il sistema. È possibile ruotare le chiavi in modo automatico periodicamente oppure è possibile ruotarle in modo manuale o su richiesta in caso di perdita.

La rotazione delle chiavi comporta l'aggiornamento di diverse impostazioni:

  • La chiave host dell'app per le funzioni
  • Il segreto in Key Vault in cui è archiviata la chiave host
  • Il riferimento di Key Vault nelle impostazioni dell'app per le funzioni, per fare riferimento alla versione del segreto più recente
  • Il riferimento di Key Vault nei criteri di memorizzazione nella cache di Gestione API per l'API Patient

La soluzione illustrata usa Terraform per la maggior parte delle attività di rotazione delle chiavi. Per altre informazioni, vedere Schema di rotazione delle chiavi con Terraform.

Identità gestite

In questa soluzione, Gestione API e le app per le funzioni usano le identità gestite del servizio assegnate dal sistema di Azure per accedere ai segreti di Key Vault. Key Vault adotta i criteri di accesso individuali seguenti per l'identità gestita di ogni servizio:

  • Gestione API può ottenere la chiave host dell'app per le funzioni API Patient.
  • L'app per le funzioni dell'API Patient può ottenere la chiave host dell'API Audit e il stringa di connessione di Azure Cosmos DB per l'archivio dati.
  • L'app per le funzioni dell'API Audit può ottenere l'stringa di connessione di Azure Cosmos DB per l'archivio dati.

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.

Uno dei principali vantaggi delle applicazioni serverless come Funzioni di Azure è il risparmio sui costi grazie alla possibilità di pagare in base al consumo delle risorse, anziché pagare anticipatamente per server dedicati. Per il supporto della rete virtuale è necessario il piano Premium di Funzioni di Azure, per cui sono previsti costi aggiuntivi. Il piano Premium di Funzioni di Azure include il supporto per l'integrazione della rete virtuale a livello di area, ma il ridimensionamento dinamico è comunque supportato. Lo SKU Premium di Funzioni di Azure include l'integrazione della rete virtuale in Gestione API.

Per informazioni dettagliate e il calcolatore dei prezzi, vedere Prezzi di Funzioni di Azure.

Le funzioni possono essere ospitate anche nelle macchine virtuali del servizio app. Solo gli ambienti del servizio app offrono l'isolamento completo della rete virtuale a livello di rete. Questi ambienti possono richiedere costi notevolmente maggiori rispetto a un piano di Funzioni di Azure in cui è supportata l'integrazione della rete virtuale a livello di area e il loro ridimensionamento è meno elastico.

Distribuire lo scenario

Il codice sorgente per questa soluzione è disponibile su GitHub nella pagina relativa ai microservizi serverless integrati tramite una rete virtuale di Azure.

Il codice sorgente TypeScript per l'API PatientTest e l'API Audit si trovano nella /src cartella . Il codice sorgente di ogni API include un contenitore di sviluppo in cui sono installati tutti i prerequisiti per avviare rapidamente l'implementazione.

Entrambe le API dispongono di una suite completa di test di integrazione e unit test automatizzati per evitare regressioni quando si apportano modifiche. Il progetto è configurato anche per il linting con ESLint, per mantenere gli stili del codice e proteggere da errori non intenzionali. I rispettivi file README dei servizi contengono informazioni su come eseguire i test e il linting.

Distribuzione Terraform

La cartella /env del progetto di codice include script e modelli per la distribuzione Terraform. Terraform distribuisce Gestione API e le app per le funzioni e le configura per l'uso dell'istanza di Application Insights distribuita. Terraform effettua anche il provisioning di tutte le risorse e le configurazioni, tra cui il blocco della rete e il modello di sicurezza delle chiavi di accesso.

Il file LEGGIMI della distribuzione illustra come distribuire l'ambiente Terraform nella sottoscrizione di Azure. La cartella /env include anche un contenitore di sviluppo in cui sono installati tutti i prerequisiti per la distribuzione Terraform.

Test di carico Locust

Per misurare le prestazioni delle API, è possibile eseguire test di carico sulle API usando i test di carico Locust inclusi. Locust è uno strumento open source per l'esecuzione di test di carico. I test dello strumento sono scritti in Python. È possibile eseguire i test di carico in locale o in remoto in un cluster del servizio Azure Kubernetes. I test eseguono un'ampia gamma di operazioni sull'endpoint di Gestione API e verificano i comportamenti rispetto a criteri basati sull'esito positivo e negativo delle operazioni.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

  • Hannes Nel | Principal Software Engineering Lead

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Le architetture seguenti illustrano gli scenari principali Gestione API:

Gli articoli seguenti illustrano gli scenari principali di funzioni: