Condividi tramite

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

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. Le connessioni al 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 'pinning dell'impronta digitale'; in questo caso, la dichiarazione si riferisce a un certificato specifico e la forza dello schema di autenticazione si basa sul presupposto che sia computazionalmente impossibile forgiare un certificato che produca 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. Le identità basate su Windows/Kerberos anche sono supportate, ma non rientrano nell'ambito di questo articolo; fare riferimento alla 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 basate su 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 al cluster, il runtime di Service Fabric assegnerà a un chiamante autenticato uno dei due ruoli come base per l'autorizzazione successiva. Esamineremo l'autenticazione in dettaglio 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 alterare in modo sottile il risultato dell'autenticazione; alcuni esempi includono flag che limitano o annullano l'imposizione degli elenchi di revoche di certificati e così via.

Annotazioni

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, amministratore client (ruolo privilegiato)
  • le credenziali accettate per il ruolo, dichiarate dall'impronta digitale o dal nome comune del soggetto

Dichiarazioni di convalida dei certificati basate su impronta digitale

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 sua catena può essere costruita, le firme corrispondono.
  • il certificato è temporalmente valido (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 creazione o la convalida della catena verranno soppressi per le dichiarazioni basate sull'impronta digitale, ad eccezione dei certificati scaduti, anche se esistono misure anche 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 esemplifica un set di regole di convalida basate sull'impronta digitale.

<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, al presentatore di un certificato con l'impronta digitale SHA-1 'd5ec...4264' gli verrà concesso il ruolo di 'amministratore'; viceversa, un chiamante che esegue l'autenticazione con certificato '7c8f...01b0' gli verrà concesso il ruolo di 'utente', limitato principalmente alle operazioni di sola lettura. Un chiamante in ingresso che presenta un certificato la cui impronta digitale è 'abcd...1234' o 'ef01...5678' sarà accettato come nodo peer nel cluster. Infine, un client che si connette a un endpoint di gestione del cluster si aspetta che l'impronta digitale del certificato del server sia 'ef01...5678'.

Come accennato in precedenza, Service Fabric prevede l'accettazione di certificati scaduti, perché i certificati hanno una durata limitata e, quando dichiarati dall'impronta digitale (che si riferisce a una specifica istanza del certificato), permettere a un certificato di scadere comporterà un errore di connessione al cluster o un collasso definitivo del cluster. È fin troppo facile dimenticare o trascurare la rotazione di un certificato ancorato tramite impronta digitale, e purtroppo il recupero da tale situazione è difficile.

A tale scopo, il proprietario del cluster può dichiarare in modo esplicito che i certificati autofirmati identificati dall'impronta digitale devono essere considerati validi.

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

Questo comportamento non si estende ai certificati rilasciati dalla CA; in caso affermativo, un certificato revocato, noto,to-becompromesso, potrebbe diventare "valido" non appena non figura più nell'elenco di revoche di certificati della CA e quindi presentare un rischio di 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 del soggetto (solo)
  • nome comune soggetto con pinning dell'emittente

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 presentatore 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'impronta digitale dell'emittente diretto 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'emittente".

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. Fissare le autorità emittenti porterà a considerare lo stato "radice non attendibile" come un errore non critico; nonostante le apparenze, si tratta di una forma di convalida più rigorosa, poiché consente al proprietario del cluster di limitare 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. In questo caso, i caratteri jolly sono supportati e il confronto delle 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.

Annotazioni

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 il pinning del certificato emittente a fare affidamento sulle autorità radice fidate.
  • 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 il pinning dell'emittente; questo permette 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 in base al 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.

Annotazioni

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)

È importante notare che, per le dichiarazioni di presentazione basate su nomi comuni, un certificato è considerato una corrispondenza se il nome comune del soggetto è identico al campo X509FindValue (o X509FindValueSecondary) della dichiarazione, tramite un confronto di stringhe esatto e sensibile alle maiuscole. Ciò è in contrasto con le regole di convalida, che supportano la corrispondenza con caratteri jolly, nonché confronti di 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 una scorciatoia per sopprimere uno stato di errore di costruzione della catena di revoca offline (o uno stato di errore di convalida dei criteri di catena successiva).

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.
  • CertificateExpirySafetyMargin: intervallo 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 periodicamente emette report sull'integrità riguardanti la loro disponibilità rimanente. All'interno dell'intervallo di "sicurezza", questi rapporti sulla salute vengono portati allo stato di "avviso". Il valore predefinito è 30 giorni.
  • CertificateHealthReportingInterval: controlla la frequenza dei rapporti di stato 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 quando rileva modifiche nelle impostazioni di sicurezza. Se 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 dell'applicazione delle nuove impostazioni a qualsiasi nodo, ma viene eseguita solo nel nodo che ospita la replica primaria del servizio Cluster Manager 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 UD. 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. Per altri dettagli, vedere Aggiornamenti del cluster di Service Fabric e altri articoli sullo stesso argomento. 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'impronta digitale (TP), con 'A' come impronta digitale 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 tramite impronta digitale

La sequenza seguente descrive come usare un aggiornamento a 2 fasi per introdurre in sicurezza un certificato del cluster secondario, dichiarato dall'impronta digitale; 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 certificati basati su impronta digitale a certificati basati 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 dato ruolo sia tramite impronta digitale che tramite nome comune nella stessa configurazione 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'impronta digitale '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 dell'aggiornamento del dominio 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 impronta digitale A o nome comune B; tutti gli altri nodi presenteranno e accetteranno 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 del 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 individuato tramite CN e accetteranno i certificati con impronta digitale A o nome comune B; tutti gli altri nodi presenteranno e accetteranno solo il certificato A, selezionato dall'impronta digitale.
  • 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.

Annotazioni

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

Effettuare il debug dei problemi relativi all'autenticazione nei cluster di Service Fabric non è affatto semplice, ma ci auguriamo che i seguenti suggerimenti e consigli 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\Admin" 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 inattivi/in fase di riavvio
  • i tentativi di connessione vengono rifiutati
  • I tentativi di connessione stanno esaurendo il tempo a disposizione.

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 tentare di emulare le regole di convalida (controllare l'impronta digitale o l'uguaglianza del nome comune, controllare le impronte digitali dell'emittente, se specificato).

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

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    In questo caso, il certificato è identificato dal nome comune, e si applica uno dei seguenti casi:

    • gli emittenti non vengono fissati e il certificato radice non è attendibile o
    • le autorità emittenti sono fissate, ma la dichiarazione non include l'impronta digitale dell'emittente diretto 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. Cerca gli errori indicati di seguito.

    • 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 impronta digitale
      • 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; verificare che a SFAdmins sia concesso l'accesso "read|execute" alla chiave privata.

    • tipo di provider non valido: indica un certificato CNG (Crypto New Generation) ("Provider di archiviazione chiavi software Microsoft"); 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)