Scenari di sicurezza di un cluster di Service Fabric

Articolo
06/01/2023

Un cluster di Azure Service Fabric è una risorsa di cui si è proprietari. È responsabilità dell'utente proteggere i cluster per evitare che utenti non autorizzati si connettano a essi. Un cluster sicuro è particolarmente importante quando si eseguono carichi di lavoro nel cluster. È possibile creare un cluster non protetto, ma se il cluster espone gli endpoint di gestione a Internet pubblico, gli utenti anonimi possono connettersi. I cluster non protetti non sono supportati per l'esecuzione di carichi di lavoro di produzione.

In questo articolo viene fornita una panoramica degli scenari di sicurezza per i cluster di Azure e i cluster autonomi e le varie tecnologie che è possibile usare per la relativa implementazione:

Sicurezza da nodo a nodo
Sicurezza da client a nodo
Controllo degli accessi in base al ruolo di Service Fabric

Sicurezza da nodo a nodo

La sicurezza da nodo a nodo aiuta a proteggere la comunicazione tra le macchine virtuali o i computer del cluster. Questo scenario di sicurezza assicura che solo i computer autorizzati a connettersi al cluster possano partecipare all'hosting di applicazioni e servizi nel cluster.

Diagram of node-to-node communication

I cluster eseguiti in Azure e i cluster autonomi eseguiti in Windows possono usare entrambi la sicurezza basata su certificati o la sicurezza di Windows per computer Windows Server.

Sicurezza basata su certificati da nodo a nodo

Service Fabric usa i certificati server X.509 specificati durante le configurazioni del tipo di nodo quando si crea un cluster. È possibile configurare la sicurezza dei certificati nel portale di Azure usando un modello di Azure Resource Manager o un modello JSON autonomo. Alla fine di questo articolo viene fornita una rapida panoramica di questi certificati e di come è possibile acquisirli o crearli.

Il comportamento predefinito di Service Fabric SDK consiste nel distribuire e installare il certificato con la data di scadenza più estesa. Questo certificato primario deve essere diverso dal client amministratore e dai certificati client di sola lettura impostati per la sicurezza da client a nodo. Il comportamento classico dell'SDK ha consentito la definizione di certificati primari e secondari per consentire rollover avviati manualmente; non è consigliabile usare le nuove funzionalità.

Per informazioni su come impostare la sicurezza basata su certificati in un cluster per Azure, vedere Configurare un cluster di Service Fabric usando un modello di Azure Resource Manager .

Per informazioni su come impostare la sicurezza basata su certificati in un cluster di Windows Server autonomo, vedere proteggere un cluster autonomo in Windows mediante certificati X.509.

Sicurezza di Windows da nodo a nodo

Nota

autenticazione di Windows si basa su Kerberos. NTLM non è supportato come tipo di autenticazione.

Quando possibile, usare l'autenticazione del certificato X.509 per i cluster di Service Fabric.

Per informazioni su come impostare la sicurezza Windows in un cluster di Windows Server autonomo, vedere proteggere un cluster autonomo in Windows mediante la sicurezza Windows.

Sicurezza da client a nodo

La sicurezza da client a nodo autentica i client e aiuta a proteggere la comunicazione tra un client e i singoli nodi del cluster. Questo tipo di sicurezza aiuta a garantire che solo gli utenti autorizzati possano accedere al cluster e alle applicazioni distribuite nel cluster. I client vengono identificati in modo univoco con le credenziali di sicurezza di Windows o le credenziali di sicurezza del relativo certificato.

Diagram of client-to-node communication

I cluster in esecuzione in Azure e i cluster autonomi in esecuzione in Windows possono usare la sicurezza dei certificati o la sicurezza di Windows, anche se è consigliabile usare l'autenticazione del certificato X.509 quando possibile.

Sicurezza basata su certificati da client a nodo

Impostare la sicurezza basata su certificati da client a nodo durante la creazione del cluster tramite il portale di Azure usando un modello di Resource Manager o un modello JSON autonomo. Per creare il certificato, specificare un certificato client di amministrazione o un certificato client utente. Come procedura consigliata, i certificati client di amministrazione e i certificati client utente specificati devono essere diversi dai certificati primario e secondario specificati per la sicurezza da nodo a nodo. I certificati del cluster hanno gli stessi diritti dei certificati di amministratore client. Tuttavia, devono essere usati solo dal cluster e non dagli utenti amministratori come procedura consigliata per la sicurezza.

I client che si connettono al cluster con il certificato amministratore hanno accesso completo alle funzionalità di gestione. I client che si connettono al cluster con il certificato client utente di sola lettura hanno solo l'accesso in lettura alle funzionalità di gestione. Questi certificati vengono usati per il controllo degli accessi in base al ruolo di Service Fabric descritto più avanti in questo articolo.

Per informazioni su come impostare la sicurezza basata su certificati in un cluster per Azure, vedere Configurare un cluster di Service Fabric usando un modello di Azure Resource Manager .

Per informazioni su come impostare la sicurezza basata su certificati in un cluster di Windows Server autonomo, vedere proteggere un cluster autonomo in Windows mediante certificati X.509.

Sicurezza da client a nodo di Microsoft Entra in Azure

Microsoft Entra ID consente alle organizzazioni (note come tenant) di gestire l'accesso degli utenti alle applicazioni. Alcune applicazioni sono caratterizzate da un'interfaccia utente di accesso basata sul Web, altre invece da un'esperienza client nativa. Se non è già stato creato un tenant, iniziare leggendo Come ottenere un tenant di Microsoft Entra.

Per i cluster in esecuzione in Azure, è anche possibile usare Microsoft Entra ID per proteggere l'accesso agli endpoint di gestione. Un cluster di Service Fabric offre diversi punti di accesso alle proprie funzionalità di gestione, tra cui Service Fabric Explorer e Visual Studio basati sul Web. Di conseguenza, per controllare l'accesso al cluster si creano due applicazioni Microsoft Entra: un'applicazione Web e un'applicazione nativa. Per informazioni su come creare gli artefatti Di Microsoft Entra necessari e su come popolarli quando si crea il cluster, vedere Configurare l'ID Microsoft Entra per autenticare i client.

Suggerimenti per la sicurezza

Per i cluster di Service Fabric distribuiti in una rete pubblica ospitata in Azure, la raccomandazione per l'autenticazione reciproca client-nodo è:

Usare l'ID Microsoft Entra per l'identità client
Un certificato per l'identità del server e la crittografia TLS della comunicazione HTTP

Per i cluster di Service Fabric distribuiti in una rete pubblica ospitata in Azure, per la sicurezza da nodo a nodo consigliabile usare un certificato cluster per autenticare i nodi.

Per i cluster di Windows Server autonomi, se sono presenti Windows Server 2012 R2 e Active Directory è consigliabile usare la sicurezza di Windows con account del servizio gestito del gruppo. In caso contrario, usare la sicurezza di Windows con account di Windows.

Controllo degli accessi in base al ruolo di Service Fabric

È possibile usare il controllo di accesso per limitare l'accesso a determinate operazioni di cluster per gruppi di utenti diversi. In questo modo il cluster è più sicuro. Per i client che si connettono a un cluster, sono supportati due tipi di controllo di accesso diversi: il ruolo di amministratore e il ruolo utente.

Gli utenti assegnati al ruolo di amministratore hanno accesso completo alle funzionalità di gestione, incluse funzionalità di lettura/scrittura. Gli utenti assegnati al ruolo di utente, per impostazione predefinita, hanno solo l'accesso in lettura alle funzionalità di gestione, ad esempio funzionalità di query, e la possibilità di risolvere applicazioni e servizi.

Impostare i ruoli del client di amministratore e utente quando si crea il cluster. Assegnare i ruoli fornendo identità separate(ad esempio, usando certificati o ID Microsoft Entra) per ogni tipo di ruolo. Per altre informazioni sulle impostazioni di controllo di accesso predefinite e su come modificare le impostazioni predefinite, vedere Controllo degli accessi in base al ruolo di Service Fabric per i client di Service Fabric.

Certificati X.509 e Service Fabric

I certificati digitali X.509 vengono comunemente usati per autenticare client e server, oltre a essere usati per crittografare e firmare digitalmente i messaggi. Service Fabric usa certificati X.509 per proteggere un cluster e fornire le funzionalità di sicurezza dell'applicazione. Per altre informazioni sui certificati digitali X.509, vedere Uso dei certificati. Si usa Key Vault per gestire i certificati dei cluster di Service Fabric in Azure.

Alcuni elementi importanti da considerare:

Per creare i certificati usati nei cluster che eseguono carichi di lavoro di produzione, usare un servizio certificati di Windows Server configurato correttamente oppure ottenerli da un'Autorità di certificazione (CA) approvata.
Non usare mai certificati temporanei o di test creati mediante strumenti come MakeCert.exe in un ambiente di produzione.
È possibile usare un certificato autofirmato, ma solo in un cluster di test. Non usare un certificato autofirmato nell'ambiente di produzione.
Quando si genera l'identificazione personale del certificato, assicurarsi di generare un'identificazione personale SHA1. SHA1 è l'algoritmo che viene usato durante la configurazione delle identificazioni personali dei certificati client e cluster.

Cluster e certificato del server (obbligatorio)

Questi certificati (uno primario ed eventualmente uno secondario) sono necessari per proteggere un cluster e prevenire accessi non autorizzati. Questi certificati forniscono l'autenticazione del cluster e del server.

L’autenticazione del cluster autentica la comunicazione da nodo a nodo per la federazione di cluster. Solo i nodi che possono dimostrare la propria identità con il certificato possono essere aggiunti al cluster. L’autenticazione del server autentica gli endpoint di gestione del cluster in un client di gestione, in modo che il client di gestione sappia con certezza di comunicare con il cluster reale e di non essere soggetto a un attacco "man in the middle". Questo certificato fornisce anche tls per l'API di gestione HTTPS e per Service Fabric Explorer su HTTPS. Uno dei primi controlli eseguiti quando un client o un nodo autentica un nodo consiste nel controllare il valore del nome comune nel campo Oggetto. Questo nome comune o uno dei nomi alternativi del soggetto dei certificati deve essere presente nell'elenco di nomi comuni consentiti.

Il certificato deve soddisfare i requisiti seguenti:

Il certificato deve includere una chiave privata. In genere questi certificati hanno l'estensione pfx o pem.
Il certificato deve essere stato creato per lo scambio di chiave, esportabile in un file con estensione pfx (Personal Information Exchange).
Il nome del soggetto del certificato deve corrispondere al dominio usato per accedere al cluster di Service Fabric. Questa corrispondenza è necessaria per fornire un protocollo TLS per l'endpoint di gestione HTTPS del cluster e Service Fabric Explorer. Non è possibile ottenere un certificato TLS/SSL da un'autorità di certificazione (CA) per il dominio *.cloudapp.azure.com. È necessario ottenere un nome di dominio personalizzato per il cluster. Quando si richiede un certificato da una CA, il nome del soggetto del certificato deve corrispondere al nome di dominio personalizzato usato per il cluster.

Altri aspetti da considerare:

Il campo Soggetto può avere più valori. Ogni valore è preceduto da un'inizializzazione per indicare il tipo di valore. L'inizializzazione è in genere CN per il nome comune, ad esempio, CN = www.contoso.com.
Il campo Soggetto può essere vuoto.
Se il campo facoltativo Nome alternativo soggetto è popolato, deve contenere sia il nome comune del certificato sia una voce per ogni nome alternativo del soggetto. Queste voci vengono immesse come valori di nomi DNS. Per informazioni su come generare certificati con nomi alternativi del soggetto, vedere Come aggiungere un nome alternativo del soggetto a un certificato LDAP sicuro.
Il valore del campo Scopi designati del certificato deve includere un valore appropriato, ad esempio Autenticazione server o Autenticazione client.

Certificati delle applicazioni (facoltativo)

Per motivi di sicurezza dell'applicazione, è possibile installare nel cluster numerosi certificati aggiuntivi. Prima di creare il cluster, considerare gli scenari di protezione delle applicazioni che richiedono l'installazione di un certificato sui nodi, ad esempio:

Crittografia e decrittografia dei valori di configurazione dell'applicazione.
Crittografia dei dati tra i nodi durante la replica.

Il concetto di creazione di cluster sicuri è lo stesso per i cluster sia Linux che Windows.

Certificati di autenticazione client (facoltativo)

Per le operazioni client degli utenti o degli amministratori è possibile specificare un numero qualsiasi di certificati aggiuntivi. Il client può usare questi certificati quando è necessaria l'autenticazione reciproca. I certificati client in genere non vengono rilasciati da un'autorità di certificazione di terze parti. In genere l'archivio personale della località utente corrente contiene invece certificati client inseriti da un'autorità radice. Il certificato deve avere un valore Scopi designati dell’autenticazione client.

Per impostazione predefinita, il certificato del cluster ha privilegi "Client amministratore". Questi certificati client aggiuntivi non devono essere installati nel cluster, ma vengono specificati come consentiti nella configurazione del cluster. Tuttavia, i certificati client devono essere installati nel client del computer per connettersi al cluster ed eseguire qualsiasi operazione.