Condividi tramite

Autenticazione basata su certificati X.509 nei cluster di Service Fabric

  • Articolo

Questo articolo integra l'introduzione alla sicurezza del cluster di Service Fabric e illustra i dettagli dell'autenticazione basata su certificati nei cluster di Service Fabric. Si presuppone che il lettore abbia familiarità con i concetti di sicurezza fondamentali e anche con i controlli esposti da Service Fabric per controllare la sicurezza di un cluster.

Argomenti trattati in questo titolo:

  • Nozioni di base sull'autenticazione basata su certificati
  • Identità e rispettivi ruoli
  • Regole di configurazione del certificato
  • Risoluzione dei problemi e domande frequenti

Nozioni di base sull'autenticazione basata su certificati

Come breve aggiornamento, in termini di sicurezza, un certificato è uno strumento destinato a associare informazioni relative a un'entità (oggetto) al loro possesso di una coppia di chiavi crittografiche asimmetriche e quindi costituisce un costrutto di base della crittografia a chiave pubblica. Le chiavi rappresentate da un certificato possono essere usate per proteggere i dati o per dimostrare l'identità dei titolari di chiavi; se usato insieme a un sistema PKI (Public Key Infrastructure), un certificato può rappresentare tratti aggiuntivi del soggetto, ad esempio la proprietà di un dominio Internet o determinati privilegi concessi dall'emittente del certificato (noto come autorità di certificazione o CA). Un'applicazione comune di certificati supporta il protocollo di crittografia TLS (Transport Layer Security), consentendo comunicazioni sicure su una rete di computer. In particolare, il client e il server usano certificati per garantire la privacy e l'integrità della comunicazione e anche per eseguire l'autenticazione reciproca.

In Service Fabric, il livello fondamentale di un cluster (federazione) si basa anche su TLS (tra gli altri protocolli) per ottenere una rete affidabile e sicura dei nodi partecipanti. Connessione ions nel cluster tramite le API client di Service Fabric usano TLS e per proteggere il traffico e anche per stabilire le identità delle parti. In particolare, se usato per l'autenticazione in Service Fabric, è possibile usare un certificato per dimostrare le attestazioni seguenti: a) il relatore delle credenziali del certificato ha il possesso della chiave privata del certificato b) che l'hash SHA-1 ('identificazione personale) del certificato corrisponde a una dichiarazione inclusa nella definizione del cluster o c) che il nome comune soggetto distinto del certificato corrisponde a una dichiarazione inclusa nella definizione del cluster, e l'emittente del certificato è noto o attendibile.

Nell'elenco precedente 'b' è noto colloquialmente come 'identificazione personale pinning'; in questo caso, la dichiarazione si riferisce a un certificato specifico e il livello di attendibilità dello schema di autenticazione si basa sul presupposto che sia computazionale non verificabile forgiare un certificato che produce lo stesso valore hash di un altro, pur essendo ancora un oggetto valido e ben formato in tutti gli altri aspetti. L'elemento 'c' rappresenta una forma alternativa di dichiarazione di un certificato, in cui l'attendibilità dello schema si applica alla combinazione dell'oggetto del certificato e dell'autorità emittente. In questo caso, la dichiarazione fa riferimento a una classe di certificati: due certificati con le stesse caratteristiche vengono considerati completamente equivalenti.

Le sezioni seguenti illustrano in dettaglio in che modo il runtime di Service Fabric usa e convalida i certificati per garantire la sicurezza del cluster.

Identità e rispettivi ruoli

Prima di approfondire i dettagli dell'autenticazione o della protezione dei canali di comunicazione, è importante elencare gli attori partecipanti e i ruoli corrispondenti che svolgono in un cluster:

  • Il runtime di Service Fabric, denominato "system": il set di servizi che forniscono le astrazioni e le funzionalità che rappresentano il cluster. Quando si fa riferimento alla comunicazione nel cluster tra istanze di sistema, si userà il termine "identità cluster". quando si fa riferimento al cluster come destinatario/destinazione del traffico dall'esterno del cluster, si userà il termine "identità server".
  • applicazioni ospitate, denominate "applicazioni": codice fornito dal proprietario del cluster, che viene orchestrato ed eseguito nel cluster
  • client: entità a cui è consentito connettersi ed eseguire funzionalità in un cluster, in base alla configurazione del cluster. Si distingue tra due livelli di privilegi: rispettivamente 'user' e 'admin'. Un client 'user' è limitato principalmente alle operazioni di sola lettura (ma non a tutte le funzionalità di sola lettura), mentre un client 'admin' ha accesso illimitato alle funzionalità del cluster. Per altri dettagli, vedere Ruoli di sicurezza in un cluster di Service Fabric.
  • (solo Azure) i servizi di Service Fabric che orchestrano ed espongono controlli per il funzionamento e la gestione dei cluster di Service Fabric, definiti semplicemente "servizio". A seconda dell'ambiente, il "servizio" può fare riferimento al provider di risorse di Azure Service Fabric o ad altri provider di risorse di proprietà e gestiti dal team di Service Fabric.

In un cluster sicuro, ognuno di questi ruoli può essere configurato con la propria identità distinta, dichiarata come associazione di un nome di ruolo predefinito e delle credenziali corrispondenti. Service Fabric supporta la dichiarazione di credenziali come certificati o entità servizio basata su dominio. Sono supportate anche le identità basate su Windows/Kerberos, ma non rientrano nell'ambito di questo articolo. Fare riferimento a Sicurezza basata su Windows nei cluster di Service Fabric. Nei cluster di Azure i ruoli client possono anche essere dichiarati come identità basate su ID Di Microsoft Entra.

Come indicato in precedenza, il runtime di Service Fabric definisce due livelli di privilegio in un cluster: 'admin' e 'user'. Un client amministratore e un componente 'system' funzionano entrambi con privilegi 'admin' e quindi non sono distinguibili l'uno dall'altro. Dopo aver stabilito una connessione in/al cluster, un chiamante autenticato verrà concesso dal runtime di Service Fabric uno dei due ruoli come base per l'autorizzazione successiva. Verranno esaminate in dettaglio l'autenticazione nelle sezioni seguenti.

Regole di configurazione del certificato

Regole di convalida

Le impostazioni di sicurezza di un cluster di Service Fabric descrivono, in linea di principio, gli aspetti seguenti:

  • il tipo di autenticazione; si tratta di una caratteristica non modificabile in fase di creazione del cluster. Esempi di queste impostazioni sono "ClusterCredentialType", "ServerCredentialType" e i valori consentiti sono "none", "x509" o "windows". Questo articolo è incentrato sull'autenticazione di tipo x509.
  • le regole di convalida (autenticazione); queste impostazioni vengono impostate dal proprietario del cluster e descrivono quali credenziali devono essere accettate per un determinato ruolo. Gli esempi verranno esaminati in modo approfondito immediatamente sotto.
  • impostazioni utilizzate per modificare o modificare in modo secondario il risultato dell'autenticazione; Alcuni esempi includono flag che limitano o annullano l'imposizione degli elenchi di revoche di certificati e così via.

Nota

Gli esempi di configurazione del cluster forniti di seguito sono estratti dal manifesto del cluster in formato XML, come il formato più digerito che supporta direttamente la funzionalità di Service Fabric descritta in questo articolo. Le stesse impostazioni possono essere espresse direttamente nelle rappresentazioni JSON di una definizione di cluster, indipendentemente dal manifesto di un cluster JSON autonomo o da un modello di Gestione risorse di Azure.

Una regola di convalida del certificato include gli elementi seguenti:

  • ruolo corrispondente: client, client amministratore (ruolo con privilegi)
  • le credenziali accettate per il ruolo, dichiarate dall'identificazione personale o dal nome comune del soggetto

Dichiarazioni di convalida dei certificati basate sull'identificazione personale

Nel caso di regole di convalida basate sull'identificazione personale, le credenziali presentate da un chiamante che richiede una connessione in/al cluster verranno convalidate nel modo seguente:

  • la credenziale è un certificato valido e ben formato: la catena può essere compilata, le firme corrispondono
  • il certificato è ora valida (NotBefore <= now < NotAfter)
  • l'hash SHA-1 del certificato corrisponde alla dichiarazione, come confronto tra stringhe senza distinzione tra maiuscole e minuscole, escludendo tutti gli spazi vuoti

Eventuali errori di attendibilità riscontrati durante la compilazione o la convalida della catena verranno eliminati per le dichiarazioni basate sull'identificazione personale, ad eccezione dei certificati scaduti, anche se esistono anche disposizioni per tale caso. In particolare, gli errori correlati a: stato di revoca sconosciuto o offline, radice non attendibile, utilizzo di chiavi non valide, catena parziale sono considerati errori non irreversibili; La premessa, in questo caso, è che il certificato è semplicemente una busta per una coppia di chiavi. La sicurezza risiede nel fatto che il proprietario del cluster ha impostato in posizioni misura per proteggere la chiave privata.

L'estratto seguente da un manifesto del cluster esegue l'esempio di un set di regole di convalida basate sull'identificazione personale:

<Section Name="Security">
  <Parameter Name="ClusterCredentialType" Value="X509" />
  <Parameter Name="ServerAuthCredentialType" Value="X509" />
  <Parameter Name="AdminClientCertThumbprints" Value="d5ec...4264" />
  <Parameter Name="ClientCertThumbprints" Value="7c8f...01b0" />
  <Parameter Name="ClusterCertThumbprints" Value="abcd...1234,ef01...5678" />
  <Parameter Name="ServerCertThumbprints" Value="ef01...5678" />
</Section>

Ognuna delle voci precedenti fa riferimento a un'identità specifica come descritto in precedenza; ogni voce consente inoltre di specificare più valori, come elenco delimitato da virgole di stringhe. In questo esempio, dopo aver convalidato correttamente le credenziali in ingresso, il relatore di un certificato con l'identificazione personale SHA-1 'd5ec... 4264" verrà concesso il ruolo "amministratore" ; viceversa, un chiamante che esegue l'autenticazione con certificato '7c8f... A 01b0 verrà concesso un ruolo "utente", limitato principalmente alle operazioni di sola lettura. Un chiamante in ingresso che presenta un certificato la cui identificazione personale è 'abcd... 1234" o "ef01... 5678' verrà accettato come nodo peer nel cluster. Infine, un client che si connette a un endpoint di gestione del cluster prevede che l'identificazione personale del certificato del server sia 'ef01... 5678'.

Come accennato in precedenza, Service Fabric esegue il provisioning per l'accettazione di certificati scaduti; Il motivo è che i certificati hanno una durata limitata e, se dichiarati dall'identificazione personale (che fa riferimento a un'istanza di certificato specifica), consentendo la scadenza di un certificato genererà un errore di connessione al cluster o un collasso definitivo del cluster. È troppo facile dimenticare o trascurare la rotazione di un certificato con identificazione personale aggiunta, e purtroppo il recupero da tale situazione è difficile.

A tale scopo, il proprietario del cluster può dichiarare in modo esplicito che i certificati autofirmati dichiarati dall'identificazione personale devono essere considerati validi, come indicato di seguito:

  <Section Name="Security">
    <Parameter Name="AcceptExpiredPinnedClusterCertificate" Value="true" />
  </Section>

Questo comportamento non si estende ai certificati rilasciati dalla CA; se questo fosse il caso, un certificato scaduto revocato, noto come compromesso, potrebbe diventare "valido" non appena non figura più nell'elenco di revoche di certificati della CA e quindi presentare un rischio per la sicurezza. Con i certificati autofirmato, il proprietario del cluster è considerato l'unica parte responsabile della salvaguardia della chiave privata del certificato, che non è il caso dei certificati rilasciati dalla CA. Il proprietario del cluster potrebbe non essere a conoscenza di come o quando il certificato è stato dichiarato compromesso.

Dichiarazioni di convalida dei certificati comuni basate sui nomi

Le dichiarazioni comuni basate sui nomi accettano una delle seguenti forme:

  • nome comune soggetto (solo)
  • nome comune soggetto con aggiunta dell'autorità di certificazione

Si consideri prima di tutto un estratto da un manifesto del cluster che esemplifica entrambi gli stili di dichiarazione:

    <Section Name="Security/ServerX509Names">
      <Parameter Name="server.demo.system.servicefabric.azure-int" Value="" />
    </Section>
    <Section Name="Security/ClusterX509Names">
      <Parameter Name="cluster.demo.system.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

Le dichiarazioni fanno riferimento rispettivamente alle identità del server e del cluster; Si noti che le dichiarazioni basate su CN hanno sezioni personalizzate nel manifesto del cluster, separate dallo standard 'Security'. In entrambe le dichiarazioni, 'Name' rappresenta il nome comune del soggetto distinto del certificato e il campo 'Value' rappresenta l'autorità emittente prevista, come indicato di seguito:

  • nel primo caso, la dichiarazione indica che l'elemento nome comune del soggetto distinto del certificato server deve corrispondere alla stringa "server.demo.system.servicefabric.azure-int"; il campo "Valore" vuoto indica l'aspettativa che la radice della catena di certificati sia attendibile nel nodo o nel computer in cui viene convalidato il certificato del server; in Windows questo significa che il certificato può essere concatenato a uno qualsiasi dei certificati installati nell'archivio 'CA radice attendibile';
  • nel secondo caso, la dichiarazione indica che il relatore di un certificato viene accettato come nodo peer nel cluster se il nome comune del certificato corrisponde alla stringa "cluster.demo.system.servicefabric.azure-int" e l'identificazione personale dell'autorità emittente diretta del certificato corrisponde a una delle voci separate da virgole nel campo "Valore". Questo tipo di regola è noto in modo colloquiale come "nome comune con pinning dell'autorità di certificazione".

In entrambi i casi, la catena del certificato viene compilata e dovrebbe essere senza errori; ovvero errori di revoca, errori di catena parziale o errori di attendibilità non validi per il tempo sono considerati irreversibili e la convalida del certificato avrà esito negativo. L'aggiunta delle autorità emittenti comporterà la considerazione dello stato "radice non attendibile" come errore non irreversibile; nonostante le apparenze, si tratta di una forma più rigorosa di convalida, in quanto consente al proprietario del cluster di vincolare il set di autorità emittenti autorizzate/accettate alla propria PKI.

Dopo aver compilato la catena di certificati, viene convalidata in base a un criterio TLS/SSL standard con l'oggetto dichiarato come nome remoto; Un certificato verrà considerato una corrispondenza se il nome comune del soggetto o uno dei nomi alternativi del soggetto corrisponde alla dichiarazione CN dal manifesto del cluster. I caratteri jolly sono supportati in questo caso e la corrispondenza di stringhe non fa distinzione tra maiuscole e minuscole.

È necessario chiarire che la sequenza descritta in precedenza può essere eseguita per ogni tipo di utilizzo delle chiavi dichiarato dal certificato. Se il certificato specifica l'utilizzo della chiave di autenticazione client, la catena viene compilata e valutata per primo per un ruolo client. In caso di esito positivo, la valutazione viene completata e la convalida ha esito positivo. Se il certificato non dispone dell'utilizzo dell'autenticazione client o la convalida non è riuscita, il runtime di Service Fabric compilerà e valuterà la catena per l'autenticazione server.

Per completare l'esempio, l'estratto seguente illustra la dichiarazione dei certificati client in base al nome comune:

    <Section Name="Security/AdminClientX509Names">
      <Parameter Name="admin.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>
    <Section Name="Security/ClientX509Names">
      <Parameter Name="user.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

Le dichiarazioni precedenti corrispondono rispettivamente alle identità dell'amministratore e dell'utente; la convalida dei certificati dichiarati in questo modo è esattamente come descritto per gli esempi precedenti, dei certificati del cluster e del server.

Nota

Le dichiarazioni comuni basate sui nomi sono progettate per semplificare la rotazione e, in generale, la gestione dei certificati del cluster. È tuttavia consigliabile attenersi alle raccomandazioni seguenti per garantire la disponibilità e la sicurezza del cluster continui:

  • preferire l'aggiunta dell'autorità di certificazione a basarsi su radici attendibili
  • evitare di combinare autorità emittenti da diverse PKI
  • assicurarsi che tutte le autorità emittenti previste siano elencate nella dichiarazione del certificato; un'autorità emittente non corrispondente genererà una convalida non riuscita
  • assicurarsi che gli endpoint dei criteri di certificato dell'infrastruttura a chiave pubblica siano individuabili, disponibili e accessibili. Ciò significa che gli endpoint AIA, CRL o OCSP vengono dichiarati nel certificato foglia e sono accessibili in modo che la compilazione della catena di certificati possa essere completata.

Associandolo tutti insieme, dopo aver ricevuto una richiesta di connessione in un cluster protetto con certificati X.509, il runtime di Service Fabric userà le impostazioni di sicurezza del cluster per convalidare le credenziali della parte remota, come descritto in precedenza; in caso di esito positivo, il chiamante o l'entità remota viene considerata autenticata. Se la credenziale corrisponde a più regole di convalida, il runtime concederà al chiamante il ruolo con privilegi più elevati di una delle regole corrispondenti.

Regole di presentazione

La sezione precedente descrive il funzionamento dell'autenticazione in un cluster protetto da certificati; questa sezione illustra come il runtime di Service Fabric individua e carica i certificati usati per la comunicazione nel cluster; chiamiamo queste regole di "presentazione".

Come per le regole di convalida, le regole di presentazione specificano un ruolo e la dichiarazione di credenziale associata, espressa tramite identificazione personale o nome comune. A differenza delle regole di convalida, le dichiarazioni comuni basate sui nomi non dispongono di disposizioni per l'aggiunta dell'autorità emittente; ciò consente una maggiore flessibilità e prestazioni migliorate. Le regole di presentazione vengono dichiarate nelle sezioni "NodeType" del manifesto del cluster, per ogni tipo di nodo distinto; Le impostazioni vengono suddivise dalle sezioni Sicurezza del cluster per consentire a ogni tipo di nodo di avere la configurazione completa in una singola sezione. Nei cluster di Azure Service Fabric le dichiarazioni di certificato del tipo di nodo predefinito sono le impostazioni corrispondenti nella sezione Sicurezza della definizione del cluster.

Dichiarazioni di presentazione dei certificati basate sull'identificazione personale

Come descritto in precedenza, il runtime di Service Fabric distingue tra il relativo ruolo come peer di altri nodi nel cluster e come server per le operazioni di gestione del cluster. In linea di principio, queste impostazioni possono essere configurate in modo distinto, ma in pratica tendono ad allinearsi. Per la parte restante di questo articolo, si presuppone che le impostazioni corrispondano per semplicità.

Si consideri l'estratto seguente da un manifesto del cluster:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindByThumbprint" X509FindValue="cc71...1984" X509FindValueSecondary="49e2...19d6" X509StoreName="my" Name="ClusterCertificate" />
        <ServerCertificate X509FindValue="cc71...1984" Name="ServerCertificate" />
        <ClientCertificate X509FindValue="cc71...1984" Name="ClientCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

L'elemento 'ClusterCertificate' illustra lo schema completo, inclusi i parametri facoltativi ('X509FindValueSecondary') o quelli con valori predefiniti appropriati ('X509StoreName'); le altre dichiarazioni mostrano un formato abbreviato. La dichiarazione del certificato del cluster precedente indica che le impostazioni di sicurezza dei nodi di tipo 'nt1vm' vengono inizializzate con il certificato 'cc71.. 1984 come primario, e '49e2.. Certificato 19d6 come secondario; entrambi i certificati sono disponibili nell'archivio certificati LocalMachine'My' (o nel percorso equivalente linux var /lib/sfcerts).

Dichiarazioni comuni di presentazione dei certificati basati sui nomi

I certificati del tipo di nodo possono anche essere dichiarati dal nome comune del soggetto, come illustrato di seguito:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindBySubjectName" X509FindValue="demo.cluster.azuredocpr.system.servicefabric.azure-int" Name="ClusterCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Per entrambi i tipi di dichiarazione, un nodo di Service Fabric leggerà la configurazione all'avvio, individua e carica i certificati specificati e li ordina in ordine decrescente dell'attributo NotBefore; I certificati scaduti vengono ignorati e il primo elemento dell'elenco viene selezionato come credenziale client per qualsiasi connessione di Service Fabric tentata da questo nodo. In effetti, Service Fabric favorisce il certificato rilasciato più di recente.

Nota

Prima della versione 7.2.445 (7.2 CU4), Service Fabric ha selezionato il certificato di scadenza più lontano (il certificato con la proprietà 'NotAfter' più lontana)

Si noti che, per le dichiarazioni di presentazione basate su nomi comuni, un certificato viene considerato una corrispondenza se il nome comune del soggetto è uguale al campo X509FindValue (o X509FindValueSecondary) della dichiarazione come confronto di stringhe con distinzione tra maiuscole e minuscole. Ciò è in contrasto con le regole di convalida, che supporta la corrispondenza con caratteri jolly, nonché confronti tra stringhe senza distinzione tra maiuscole e minuscole.

Impostazioni di configurazione dei certificati varie

È stato menzionato in precedenza che le impostazioni di sicurezza di un cluster di Service Fabric consentono anche di modificare in modo secondario il comportamento del codice di autenticazione. Mentre l'articolo sulle impostazioni del cluster di Service Fabric rappresenta l'elenco completo e più aggiornato delle impostazioni, si espanderà il significato di una selezione di alcune delle impostazioni di sicurezza qui, per completare l'esposizione completa sull'autenticazione basata su certificati. Per ogni impostazione, verrà illustrata la finalità, il valore/comportamento predefinito, il modo in cui influisce sull'autenticazione e sui valori accettabili.

Come accennato, la convalida del certificato implica sempre la compilazione e la valutazione della catena del certificato. Per i certificati rilasciati dalla CA, questa chiamata api del sistema operativo apparentemente semplice comporta in genere diverse chiamate in uscita a vari endpoint dell'infrastruttura a chiave pubblica emittente, memorizzazione nella cache delle risposte e così via. Data la prevalenza delle chiamate di convalida dei certificati in un cluster di Service Fabric, eventuali problemi negli endpoint dell'infrastruttura a chiave pubblica possono comportare una riduzione della disponibilità del cluster o una suddivisione totale. Anche se le chiamate in uscita non possono essere eliminate (vedere di seguito nella sezione Domande frequenti per altre informazioni), è possibile usare le impostazioni seguenti per mascherare gli errori di convalida causati da chiamate CRL non riuscite.

  • CrlCheckingFlag : nella sezione "Sicurezza" stringa convertita in UINT. Il valore di questa impostazione viene usato da Service Fabric per mascherare gli errori di stato della catena di certificati modificando il comportamento della compilazione della catena; viene passato alla chiamata Win32 CryptoAPI CertGetCertificateChain come parametro "dwFlags" e può essere impostato su qualsiasi combinazione valida di flag accettati dalla funzione. Un valore pari a 0 impone al runtime di Service Fabric di ignorare eventuali errori di stato di attendibilità. Questa operazione non è consigliata perché l'uso costituisce un'esposizione significativa alla sicurezza. Il valore predefinito è 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

Quando usare: per i test locali, con certificati autofirmati o certificati per sviluppatori che non sono completamente formati/non hanno un'infrastruttura a chiave pubblica appropriata per supportare i certificati. Può essere usato anche come mitigazione negli ambienti con ga gapped aria durante la transizione tra le infrastruttura a chiave pubblica.

Come usare: verrà illustrato un esempio che forza il controllo della revoca per accedere solo agli URL memorizzati nella cache. Assumendo:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

quindi la dichiarazione nel manifesto del cluster diventa:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError: nella sezione "Sicurezza" booleano con un valore predefinito "false". Rappresenta un collegamento per eliminare lo stato di errore di compilazione della catena di "revoca offline" o uno stato di errore di convalida dei criteri di catena successivo.

Quando usare: test locali o con certificati per sviluppatori non supportati da un'infrastruttura a chiave pubblica appropriata. Usare come mitigazione in ambienti con disponibilità a aria limitata o quando l'infrastruttura a chiave pubblica è nota come inaccessibile.

Come usare:

  <Section Name="Security">
    <Parameter Name="IgnoreCrlOfflineError" Value="true" />
  </Section>

Altre impostazioni rilevanti (tutte nella sezione "Sicurezza"):

  • AcceptExpiredPinnedClusterCertificate- descritto nella sezione dedicata alla convalida dei certificati basata sull'identificazione personale; consente di accettare i certificati del cluster autofirmati scaduti.
  • CertificateExpiry Cassaforte tyMargin- interval, espresso in minuti prima del timestamp NotAfter del certificato e durante il quale il certificato viene considerato a rischio di scadenza. Service Fabric monitora i certificati del cluster e genera periodicamente report sull'integrità sulla disponibilità rimanente. All'interno dell'intervallo di "sicurezza", questi report sull'integrità vengono elevati allo stato di "avviso". Il valore predefinito è 30 giorni.
  • CertificateHealthReportingInterval: controlla la frequenza dei report sull'integrità relativi alla validità rimanente dei certificati del cluster. I report verranno generati una sola volta per questo intervallo. Il valore è espresso in secondi, con un valore predefinito di 8 ore.
  • EnforcePrevalidationOnSecurityChanges: valore booleano, controlla il comportamento dell'aggiornamento del cluster durante il rilevamento delle modifiche delle impostazioni di sicurezza. Se il valore è impostato su "true", l'aggiornamento del cluster tenterà di garantire che almeno uno dei certificati corrispondenti a una delle regole di presentazione possa superare una regola di convalida corrispondente. La pre-convalida viene eseguita prima che le nuove impostazioni vengano applicate a un nodo, ma solo sul nodo che ospita la replica primaria del servizio Gestione cluster al momento dell'avvio dell'aggiornamento. A partire da questo articolo, l'impostazione ha il valore predefinito "false" e verrà impostata su "true" per i nuovi cluster di Azure Service Fabric con una versione di runtime a partire dalla versione 7.1.

Scenario end-to-end (esempi)

Sono stati esaminati le regole di presentazione, le regole di convalida e i flag di modifica, ma come funziona tutto questo insieme? In questa sezione verranno illustrati due esempi end-to-end che illustrano come usare le impostazioni di sicurezza per gli aggiornamenti di cluster sicuri. Si noti che questo non è destinato a essere una tesi completa sulla gestione corretta dei certificati in Service Fabric, cercare un articolo complementare su questo argomento.

La separazione delle regole di presentazione e convalida pone l'ovvia domanda (o preoccupazione) del fatto che possano divergere e quali sarebbero le conseguenze. È infatti possibile che la selezione di un nodo di un certificato di autenticazione non superi le regole di convalida di un altro nodo. In effetti, questa discrepanza è la causa principale di eventi imprevisti correlati all'autenticazione. Allo stesso tempo, la separazione di queste regole consente a un cluster di continuare a funzionare durante un aggiornamento che modifica le impostazioni di sicurezza del cluster. Si consideri che, aumentando prima le regole di convalida come primo passaggio, tutti i nodi del cluster convergeranno sulle nuove impostazioni mentre usano ancora le credenziali correnti.

Tenere presente che, in un cluster di Service Fabric, un aggiornamento passa attraverso (fino a 5) "domini di aggiornamento" o id utente. Solo i nodi nell'UD corrente vengono aggiornati/modificati in un determinato momento e l'aggiornamento procederà al successivo UD solo se la disponibilità del cluster lo consente. (Fare riferimento a Aggiornamenti del cluster di Service Fabric e altri articoli sullo stesso argomento per altri dettagli. Le modifiche di certificato/sicurezza sono particolarmente rischiose, poiché possono isolare i nodi dal cluster o lasciare il cluster al perimetro della perdita del quorum.

Per descrivere le impostazioni di sicurezza di un nodo, verrà usata la notazione seguente:

Nk: {P:{TP=A}, V:{TP=A}}, dove:

  • 'Nk' rappresenta un nodo nel dominio di aggiornamento k
  • 'P' rappresenta le regole di presentazione correnti del nodo (presupponendo che si faccia riferimento solo ai certificati del cluster);
  • 'V' rappresenta le regole di convalida correnti del nodo (solo certificato del cluster)
  • 'TP=A' rappresenta una dichiarazione basata sull'identificazione personale (TP), con 'A' come identificazione personale del certificato
  • 'CN=B' rappresenta una dichiarazione comune basata sul nome (CN), con 'B' come nome comune del soggetto del certificato

Rotazione di un certificato cluster dichiarato dall'identificazione personale

La sequenza seguente descrive come usare un aggiornamento a 2 fasi per introdurre in modo sicuro un certificato del cluster secondario, dichiarato dall'identificazione personale; la prima fase introduce la nuova dichiarazione di certificato nelle regole di convalida e la seconda fase lo introduce nelle regole di presentazione:

  • stato iniziale: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - Il cluster è inattivo, tutti i nodi condividono una configurazione comune
  • al completamento dell'aggiornamento dominio 0: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - i nodi in UD0 presenteranno il certificato A e accetteranno i certificati A o B; tutti gli altri nodi presenti e accettano solo il certificato A
  • al completamento dell'ultimo dominio di aggiornamento: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - tutti i nodi presentano il certificato A, tutti i nodi accettano il certificato A o B

A questo punto, il cluster è di nuovo in equilibrio e la seconda fase dell'aggiornamento/modifica delle impostazioni di sicurezza può iniziare:

  • al completamento dell'aggiornamento dominio 0: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - I nodi in UD0 inizieranno a presentare B, che viene accettato da qualsiasi altro nodo del cluster.
  • al completamento dell'ultimo dominio di aggiornamento: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} - Tutti i nodi sono passati alla presentazione del certificato B. Il certificato A può ora essere ritirato/rimosso dalla definizione del cluster con un set successivo di aggiornamenti.

Conversione di un cluster da identificazione personale a dichiarazioni di certificato basate su nomi comuni

Analogamente, la modifica del tipo di dichiarazione di certificato (dall'identificazione personale al nome comune) seguirà lo stesso modello riportato in precedenza. Si noti che le regole di convalida consentono di dichiarare i certificati di un determinato ruolo sia dall'identificazione personale che dal nome comune nella stessa definizione del cluster. Al contrario, le regole di presentazione consentono solo una forma di dichiarazione. L'approccio sicuro alla conversione di un certificato cluster dall'identificazione personale al nome comune consiste nell'introdurre innanzitutto il certificato di destinazione previsto tramite identificazione personale e quindi modificare tale dichiarazione in un certificato comune basato sul nome. Nell'esempio seguente si presuppone che l'identificazione personale 'A' e il nome comune del soggetto 'B' facciano riferimento allo stesso certificato.

  • stato iniziale: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - Il cluster è inattivo, tutti i nodi condividono una configurazione comune, con A come identificazione personale del certificato primario
  • al completamento del dominio di aggiornamento 0: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - i nodi in UD0 presenteranno il certificato A e accetteranno i certificati con identificazione personale A o nome comune B; tutti gli altri nodi presenti e accettano solo il certificato A
  • al completamento dell'ultimo dominio di aggiornamento: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - tutti i nodi presentano il certificato A, tutti i nodi accettano il certificato A (TP) o B (CN)

A questo punto è possibile procedere con la modifica delle regole di presentazione con un aggiornamento successivo:

  • al completamento dell'aggiornamento dominio 0: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - I nodi in UD0 presenteranno il certificato B trovato dal CN e accetteranno i certificati con identificazione personale A o nome comune B; tutti gli altri nodi presenti e accettano solo il certificato A, selezionato dall'identificazione personale
  • al completamento dell'ultimo dominio di aggiornamento: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} - tutti i nodi presentano il certificato B trovato da CN, tutti i nodi accetterebbero il certificato A (TP) o B (CN)

Il completamento della fase 2 contrassegna anche la conversione del cluster in certificati comuni basati sui nomi; Le dichiarazioni di convalida basate sull'identificazione personale possono essere rimosse in un successivo aggiornamento del cluster.

Nota

Nei cluster di Azure Service Fabric i flussi di lavoro presentati in precedenza vengono orchestrati dal provider di risorse di Service Fabric; Il proprietario del cluster è ancora responsabile del provisioning dei certificati nel cluster in base alle regole indicate (presentazione o convalida) ed è consigliabile eseguire modifiche in più passaggi.

In un articolo separato verrà illustrato l'argomento relativo alla gestione e al provisioning dei certificati in un cluster di Service Fabric.

Risoluzione dei problemi e domande frequenti

Durante il debug dei problemi relativi all'autenticazione nei cluster di Service Fabric non è facile, si spera che i suggerimenti e i suggerimenti seguenti possano essere utili. Il modo più semplice per iniziare le indagini consiste nell'esaminare i registri eventi di Service Fabric nei nodi del cluster, non necessariamente solo quelli che mostrano sintomi, ma anche nodi che sono attivi ma non sono in grado di connettersi a uno dei loro vicini. In Windows, gli eventi di importanza vengono in genere registrati nei canali "Registri applicazioni e servizi\Microsoft-ServiceFabric\Amministrazione" o "Operational". A volte può essere utile abilitare la registrazione CAPI2, per acquisire altri dettagli relativi alla convalida del certificato, al recupero di CRL/CTL e così via. Ricordarsi di disabilitarlo dopo aver completato la riproduzione, può essere piuttosto dettagliato.

I sintomi tipici che si manifestano in un cluster che riscontrano problemi di autenticazione sono:

  • nodi inattivo/ciclo
  • i tentativi di connessione vengono rifiutati
  • il timeout dei tentativi di connessione

Ognuno dei sintomi può essere causato da problemi diversi, e la stessa causa radice può mostrare manifestazioni diverse; di conseguenza, verrà elencato solo un piccolo esempio di problemi tipici, con consigli per risolverli.

  • I nodi possono scambiare messaggi ma non possono connettersi. Una possibile causa per cui i tentativi di connessione devono essere terminati è l'errore "certificato non corrispondente". Una delle parti in una connessione da Service Fabric a Service Fabric presenta un certificato che non supera le regole di convalida del destinatario. Può essere accompagnato da uno degli errori seguenti:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    Per diagnosticare/analizzare ulteriormente: in ognuno dei nodi che tentano la connessione, determinare quale certificato viene presentato; esaminare il certificato e provare ad emulare le regole di convalida (controllare l'identificazione personale o l'uguaglianza dei nomi comuni, controllare le identificazioni personali dell'autorità di certificazione, se specificato).

    Un altro codice di errore comune a corredo può essere:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    In questo caso, il certificato viene dichiarato dal nome comune e si applica uno dei seguenti:

    • le autorità emittenti non vengono aggiunte e il certificato radice non è attendibile o
    • le autorità emittenti vengono aggiunte, ma la dichiarazione non include l'identificazione personale dell'autorità emittente diretta di questo certificato

  • Un nodo è in funzione, ma non può connettersi ad altri nodi; altri nodi non ricevono traffico in ingresso dal nodo che ha esito negativo. In questo caso, è possibile che il caricamento del certificato non riesca nel nodo locale. Cercare gli errori seguenti:

    • certificato non trovato: assicurarsi che i certificati dichiarati nelle regole di presentazione possano essere risolti dal contenuto dell'archivio certificati LocalMachine\My (o come specificato). Possibili cause di errore possono includere:

      • caratteri non validi nella dichiarazione di identificazione personale
      • il certificato non è installato
      • il certificato è scaduto
      • la dichiarazione common-name include il prefisso 'CN='
      • la dichiarazione specifica un carattere jolly e non esiste alcuna corrispondenza esatta nell'archivio certificati (dichiarazione: CN=*.mydomain.com, certificato effettivo: CN=server.mydomain.com)

    • credenziali sconosciute: indica una chiave privata mancante corrispondente al certificato, in genere accompagnata dal codice di errore:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Per rimediare, verificare l'esistenza della chiave privata; verify SF Amministrazione s viene concesso l'accesso 'read|execute' alla chiave privata.

    • tipo di provider non valido: indica un certificato CNG (Crypto New Generation) ("Microsoft Software Key Archiviazione Provider"); al momento Service Fabric supporta solo i certificati CAPI1. In genere accompagnato da codice di errore:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Per rimediare, ricreare il certificato del cluster usando un provider CAPI1 ,ad esempio "Microsoft Enhanced RSA and AES Cryptographic Provider". Per altre informazioni sui provider di crittografia, vedere Understanding Cryptographic Providers (Informazioni sui provider di crittografia)