Scenari di sicurezza di un cluster di Service Fabric

Un cluster di Azure Service Fabric è una risorsa di cui si è proprietari. È necessario 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. La creazione di cluster non protetti, anche se possibile, potrebbe consentire a utenti anonimi di connettersi a un cluster che espone gli endpoint di gestione a Internet pubblico.

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

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.

Diagramma della comunicazione da nodo a nodo

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. Alla fine di questo articolo viene fornita una rapida panoramica di questi certificati e di come è possibile acquisirli o crearli.

Impostare la sicurezza basata su certificati durante la creazione del cluster tramite il portale di Azure usando un modello di Azure Resource Manager o un modello JSON autonomo. È possibile impostare un certificato primario e un certificato secondario facoltativo che viene usato per i rollover dei certificati. I certificati primario e secondario impostcati devono essere diversi dai certificati client di amministrazione e dai certificati client di sola lettura impostati per la sicurezza da client a nodo.

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

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.

Diagramma della comunicazione da client a nodo

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

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. Per impostazione predefinita, i certificati cluster per la sicurezza da nodo a nodo vengono aggiunti all'elenco di certificati Amministratore client consentiti.

I client che si connettono al cluster con il certificato di amministrazione 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 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 di Azure Active Directory da client a nodo in Azure

Per i cluster eseguiti in Azure è anche possibile proteggere l'accesso agli endpoint di gestione usando Azure Active Directory (Azure AD). Per informazioni su come creare i necessari elementi di AAD, su come popolarli durante la creazione dei cluster e su come connettersi a tali cluster in seguito, vedere Configurare un cluster di Service Fabric usando un modello di Azure Resource Manager.

Suggerimenti per la sicurezza

Per i cluster di Azure si consiglia di usare la sicurezza di Azure AD per l'autenticazione dei client e dei certificati per la sicurezza da nodo a nodo.

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 comunque la sicurezza di Windows con account di Windows.

Controllo degli accessi in base al ruolo

È 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, tramite certificati o Azure AD) per ogni tipo di ruolo. Per altre informazioni sulle impostazioni predefinite del controllo di accesso e su come modificarle, vedere Controllo di accesso basato sui ruoli 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. Per altre informazioni sui certificati digitali X.509, vedere Uso dei certificati.

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.

Certificati server X.509

L'attività principale dei certificati del server è l'autenticazione di un server (nodo) nei client o di un server (nodo) in un server (nodo). 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.

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 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.

Il valore del campo Scopi designati del certificato deve includere un valore appropriato, ad esempio Autenticazione server o Autenticazione client.

Certificati client X.509

I certificati client in genere non vengono rilasciati da un'autorità di certificazione di terze parti. In genere l'archivio personale del percorso utente corrente contiene invece certificati client inseriti da un'autorità radice, con lo scopo designato Autenticazione client. Il client può usare tali certificati quando è necessaria l'autenticazione reciproca.

Nota

Tutte le operazioni di gestione in un cluster di Service Fabric richiedono certificati server. I certificati client non possono essere usati per la gestione.

Passaggi successivi