Sicurezza del servizio e dell'applicazione Service Fabric

  • Articolo

Un'architettura di microservizi può apportare numerosi vantaggi. Gestire la sicurezza dei microservizi, tuttavia, richiede procedure complesse, diverse da quelle necessarie per gestire la sicurezza delle tradizionali applicazioni monolitiche.

Con una struttura monolitica, l'applicazione viene normalmente eseguita su uno o più server all'interno di una rete ed è più semplice identificare le porte esposte e le API e gli indirizzi IP. Nella maggior parte dei casi, inoltre, è presente un perimetro o un limite e un database da proteggere. Se il sistema viene compromesso a seguito di un attacco o di una violazione della sicurezza, quindi, è probabile che tutti gli elementi all'interno del sistema risultino a disposizione dell'autore dell'attacco. Con i microservizi, il sistema è più complesso. I servizi vengono decentralizzati e distribuiti su molti host e migrano dall'uno all'altro. Con strumenti di sicurezza appropriati, è possibile limitare i privilegi di cui può usufruire il responsabile dell'attacco e la quantità di dati disponibili con un singolo attacco perpetrato tramite la violazione di un servizio. Le comunicazioni, inoltre, non avvengono internamente ma in rete e sono presenti numerose porte esposte e interazioni tra servizi. Conoscere queste interazioni e sapere quando si verificano è di fondamentale importanza per la sicurezza dell'applicazione.

Questo articolo non è una guida alla sicurezza dei microservizi, poiché online sono disponibili molte risorse di questo tipo, ma descrive come possono essere applicati in Service Fabric vari aspetti relativi alla sicurezza.

Autenticazione e autorizzazione

È spesso necessario che le risorse e le API esposte da un servizio vengano limitate a determinati client o utenti attendibili. ovvero il processo con cui si accerta in modo affidabile l'identità di un utente. mentre l'autorizzazione è il processo che rende le API o i servizi disponibili per alcuni utenti autenticati, ma non per altri.

Authentication

Il primo passaggio del processo decisionale relativo all'attendibilità a livello di API è l'autenticazione, ovvero il processo con cui si accerta in modo affidabile l'identità di un utente. In scenari di microservizi, l'autenticazione viene in genere gestita centralmente. Se si usa un gateway API, tuttavia, è possibile scaricare l'autenticazione sul gateway. Se si usa questo approccio, accertarsi che i singoli servizi non possano essere raggiunti direttamente (senza il gateway API), a meno che non siano stati configurati strumenti di sicurezza aggiuntivi per l'autenticazione dei messaggi, indipendentemente dal fatto che provengano o meno dal gateway.

Se è possibile accedere direttamente ai servizi, è possibile usare un servizio di autenticazione come Microsoft Entra ID o un microservizio di autenticazione dedicato che funge da servizio token di sicurezza (STS) per autenticare gli utenti. Le decisioni sull'attendibilità vengono condivise tra i servizi tramite cookie o token di sicurezza.

Per ASP.NET Core, il principale meccanismo di autenticazione degli utenti è il sistema di appartenenze ASP.NET Core Identity, che archivia le informazioni sugli utenti (inclusi dati di accesso, ruoli e attestazioni) in un archivio dati configurato dallo sviluppatore. ASP.NET Core Identity supporta l'autenticazione a due fattori, Sono supportati anche provider di autenticazione esterni, in modo che gli utenti possano accedere usando processi di autenticazione esistenti da provider come Microsoft, Google, Facebook o Twitter.

Autorizzazione

Dopo l'autenticazione, i servizi devono autorizzare l'accesso utente o determinare cosa può fare un utente. Questo processo, ad esempio, consente a un servizio di rendere le API disponibili per alcuni utenti autenticati, ma non per tutti. L'autorizzazione è ortogonale e indipendente dall'autenticazione, che costituisce invece il processo con cui si accerta l'identità di un utente. L'autenticazione, inoltre, può creare una o più identità per l'utente corrente.

L'autorizzazione di ASP.NET Core può essere eseguita in base ai ruoli degli utenti o a criteri personalizzati come il controllo delle attestazioni o altre regole euristiche.

Limitare e proteggere l'accesso con un gateway API

Le applicazioni cloud necessitano in genere di un gateway front-end per garantire un singolo punto di ingresso per utenti, dispositivi o altre applicazioni. Un gateway API si trova tra i client e i servizi e costituisce il punto di ingresso per tutti i servizi forniti dall'applicazione. e funge da proxy inverso, indirizzando le richieste dai client ai servizi. Può anche eseguire varie attività di taglio incrociato, ad esempio autenticazione e autorizzazione, terminazione TLS e limitazione della frequenza. Se non si distribuisce un gateway, i client devono inviare le richieste direttamente ai servizi front-end.

In Service Fabric un gateway può essere qualsiasi servizio senza stato, ad esempio un'applicazione ASP.NET Core, o un altro servizio progettati per l'ingresso del traffico, ad esempio Traefik, Hub eventi, Hub IoT o Gestione API di Azure.

Gestione API si integra direttamente in Service Fabric, consentendo di pubblicare API con un ampio set di regole di routing nei servizi Service Fabric back-end. Consente inoltre di proteggere l'accesso ai servizi back-end, impedire attacchi DoS con la limitazione o verificare chiavi API, token JWT, certificati e altre credenziali. Per altre informazioni, vedere Panoramica di Service Fabric con Gestione API di Azure.

Gestire i segreti dell'applicazione

I segreti possono essere informazioni riservate, ad esempio le stringhe di connessione di archiviazione, le password o altri valori che non devono essere gestiti in testo normale. Questo articolo usa Azure Key Vault per gestire chiavi e segreti. Tuttavia, l' uso di segreti in un'applicazione è indipendente dalla piattaforma cloud per consentire alle applicazioni di essere distribuite in un cluster ospitato in un punto qualsiasi.

Il metodo consigliato per gestire le impostazioni di configurazione del servizio è tramite i pacchetti di configurazione del servizio. I pacchetti di configurazione dispongono di controllo delle versioni e sono aggiornabili tramite gli aggiornamenti in sequenza gestiti con convalida dell'integrità e rollback automatico. Questo approccio è da preferire alla configurazione globale in quanto riduce le probabilità di un'interruzione del servizio globale. I segreti crittografati non rappresentano un'eccezione. Service Fabric offre funzionalità incorporate per crittografare e decrittografare i valori in un file Settings.xml del pacchetto configurazione tramite la crittografia del certificato.

Il diagramma seguente illustra il flusso di base per la gestione dei segreti in un'applicazione di Service Fabric:

secret management overview

In questo flusso sono presenti quattro passaggi principali:

  1. Ottenere un certificato di crittografia dei dati.
  2. Installare il certificato nel cluster.
  3. Crittografare i valori dei segreti quando si distribuisce un'applicazione con il certificato e inserirli nel file di configurazione Settings.xml del servizio.
  4. Leggere i valori crittografati risultati da Settings. XML eseguendo la decrittografia con lo stesso certificato di crittografia.

Azure Key Vault viene usato come percorso di archiviazione sicuro per i certificati e come un modo per ottenere i certificati installati nei cluster Service Fabric in Azure. Se non si esegue la distribuzione in Azure, non è necessario usare l'insieme di credenziali delle chiavi per gestire i segreti nelle applicazioni di Service Fabric.

Per un esempio, vedere Gestire i segreti dell'applicazione.

Proteggere l'ambiente di hosting

Azure Service Fabric consente di proteggere le applicazioni in esecuzione nel cluster con account utente diversi. Service Fabric permette anche di proteggere le risorse usate dalle applicazioni in fase di distribuzione con l'account utente, ad esempio file, directory e certificati. In questo modo le applicazioni in esecuzione, anche in un ambiente ospitato condiviso, sono reciprocamente protette.

Il manifesto dell'applicazione dichiara le entità di sicurezza (utenti e gruppi) necessarie per eseguire i servizi e proteggere le risorse. Alle entità di sicurezza viene fatto riferimento nei criteri, ad esempio nei criteri RunAs, di binding degli endpoint, di condivisione dei pacchetti e di accesso di sicurezza. I criteri vengono quindi applicati alle risorse del servizio nella sezione ServiceManifestImport del manifesto dell'applicazione.

Quando si dichiarano le entità, è possibile anche definire e creare gruppi di utenti per aggiungere uno o più utenti a ogni gruppo e gestirli insieme. Questo aspetto è utile quando sono presenti più utenti per punti di ingresso del servizio differenti che devono avere determinati privilegi comuni disponibili a livello di gruppo.

Per impostazione predefinita, le applicazioni di Service Fabric vengono eseguite con lo stesso account con cui viene eseguito il processo Fabric.exe. Service Fabric consente anche di eseguire le applicazioni con un account utente locale o un account di sistema locale, specificato nel manifesto dell'applicazione. Per altre informazioni, vedere Run a service as a local user account or local system account (Eseguire un servizio come account utente locale o account di sistema locale) o Eseguire uno script di avvio del servizio come account utente o di sistema locale.

Quando si esegue Service Fabric su un cluster Windows autonomo, è possibile eseguire un servizio con account di dominio di Active Directory o account del servizio gestito del gruppo.

Proteggere i contenitori

Service Fabric fornisce un meccanismo per i servizi all'interno di un contenitore per accedere a un certificato che viene installato nei nodi in un cluster di Windows o Linux (versione 5.7 o versioni successive). Questo certificato PFX può essere usato per autenticare l'applicazione o il servizio o per proteggere la comunicazione con altri servizi. Per altre informazioni, vedere Import a certificate into a container (Importare un certificato in un contenitore).

Service Fabric supporta anche gMSA (account del servizio gestito del gruppo) per i contenitori di Windows. Per altre informazioni, vedere Configurare gMSA per i contenitori di Windows.

Proteggere le comunicazioni dei servizi

In Service Fabric un servizio viene eseguito in una posizione nel cluster di Service Fabric, in genere distribuito su più macchine virtuali. Service Fabric offre varie opzioni per la protezione delle comunicazioni di servizio.

È possibile abilitare endpoint HTTPS nei servizi Web ASP.NET Core o Java.

È possibile anche stabilire una connessione protetta tra il proxy inverso e i servizi, abilitando un canale protetto end-to-end. La connessione ai servizi protetti è supportata solo quando il proxy inverso è configurato per l'ascolto su HTTPS. Per informazioni sulla configurazione del proxy inverso, vedere Proxy inverso in Azure Service Fabric. L'articolo Connettersi a un servizio protetto descrive come stabilire una connessione sicura tra il proxy inverso e i servizi.

Il framework di applicazioni di Reliable Services offre alcuni stack e strumenti predefiniti che è possibile usare per migliorare la sicurezza. Sono disponibili alcuni articoli che illustrano come migliorare la sicurezza quando si usa la comunicazione remota per un servizio (in C# o Java) o Windows Communication Foundation.

Includere il certificato endpoint nelle applicazioni di Service Fabric

Per configurare il certificato dell'endpoint dell'applicazione, includere il certificato aggiungendo un elemento EndpointCertificate insieme all'elemento User per l'account principale al manifesto dell'applicazione. Per impostazione predefinita, l'account principale è NetworkService. In questo modo verrà fornita la gestione dell'ACL della chiave privata del certificato dell'applicazione per l'entità fornita.

<ApplicationManifest … >
  ...
  <Principals>
    <Users>
      <User Name="Service1" AccountType="NetworkService" />
    </Users>
  </Principals>
  <Certificates>
    <EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
  </Certificates>
</ApplicationManifest>

Crittografare i dati inattivi delle applicazioni

Ogni tipo di nodo in un cluster di Service Fabric in esecuzione in Azure è supportato da un set di scalabilità di macchine virtuali. Usando un modello di Azure Resource Manager, è possibile collegare dischi dati ai set di scalabilità che costituiscono il cluster di Service Fabric. Se i servizi salvano i dati su un disco dati collegato, è possibile proteggere i dati dell'applicazione crittografando i dischi dati.

Passaggi successivi