CA condivisa, porte separate: un servizio per file di ammissione

Un certificato che si convalida contro un’autorità condivisa ha superato una prova di fiducia, non una prova di appartenenza. Queste due decisioni vengono spesso confuse perché entrambe avvengono al momento della connessione, e la confusione resta invisibile finché in un servizio viene ammesso qualcuno che non dovrebbe esserci. Il rimedio non è una seconda autorità; è una seconda decisione, presa per servizio e registrata dove il demone la legge. Tenete le due separate e gran parte della confusione in questo ambito scompare.

Una catena fidata non dice nulla sull’appartenenza al servizio

Due servizi possono accettare la stessa gerarchia emittente e avere comunque popolazioni diverse. Un portatile appartiene al primo e non deve raggiungere il secondo, mentre altri client della stessa gerarchia vi appartengono davvero. Rimuovere l’autorità da quel servizio escluderebbe tutti coloro che lo usano legittimamente, quindi il lavoro è di ammissione, non di fiducia.

Aiuta immaginare due serrature su una porta. Il certificato apre la serratura esterna, e una decisione per servizio apre quella interna; nessuna sostituisce l’altra. Un servizio con solo la serratura esterna non applica alcuna appartenenza, si limita ad autenticare. Scrivete entrambe le decisioni prima di modificare qualcosa, perché una politica che esiste solo nella forma di una connessione funzionante non può essere verificata. Quanto segue riguarda la serratura interna.

Trasformate le sostituzioni facoltative in una porta di ammissione

Una directory di configurazione dei client è di solito una comodità: i file al suo interno sostituiscono le impostazioni dei client che nominano, e un client senza file funziona semplicemente con i valori predefiniti del server. Una direttiva trasforma quella comodità in una porta, così che un file mancante significhi che la connessione viene rifiutata.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

L’edizione community di OpenVPN 2.6 ccd-exclusive documenta, nella sua pagina di manuale, esattamente questa condizione, e la ricerca del file nominato dipende dall’identità effettiva del client. Altre build e server gestiti da prodotti possono differire, quindi verificate la versione installata prima di affidarvi alla stessa semantica altrove.

Trattate il percorso sopra come un esempio e controllate la disposizione dispiegata invece di creare una directory inventata da una guida. Lasciate i controlli dei certificati, i controlli dell’identità del server e l’autenticazione degli account esattamente come erano, perché il frammento aggiunge una condizione e non toglie nulla. Preparate la modifica prima della produzione, poiché un rifiuto sollevato nel punto sbagliato sembra un errore di certificato e indirizza l’indagine verso l’autorità. Poi confermate che la riga di log di un client rifiutato nomini il file di configurazione mancante e non la catena.

Una directory per servizio, non un unico elenco condiviso

L’appartenenza spetta al servizio che la applica, quindi ogni servizio tiene la propria directory e i propri file. Puntare due servizi a un unico elenco li fa condividere l’appartenenza che qualcuno lo volesse o no, e la modifica che ne deriva è difficile da ricondurre a una decisione. L’autorità condivisa può restare condivisa; i file di ammissione no. Tenerli separati significa anche che un errore in un servizio non può ampliare silenziosamente un altro.

Una voce DEFAULT è il caso che inganna le persone. Fornisce impostazioni di riserva quando non viene trovato alcun file nominato, ma non è il file nominato che la porta richiede, quindi non può ammettere un client da sola. Provate un client che non ha alcuna voce e confermate il rifiuto; se quel client viene ammesso, si sta applicando il valore di riserva e ccd-exclusive non è in vigore in quell’istanza.

L’identità effettiva decide quale file viene letto

La ricerca utilizza l’identità con cui il client si è realmente autenticato, che di solito è il nome comune del certificato. Quando il server verifica anche un nome utente e una password e mappa quel nome sul nome comune, il file deve corrispondere al nome utente autenticato. Una discrepanza lascia una directory piena di nomi di file plausibili che non vengono mai selezionati.

La lettura è l’altra metà. Il demone di solito abbandona i privilegi dopo l’avvio, quindi l’account ridotto necessita di accesso in lettura alla directory e a ogni voce che contiene. I client non devono poter creare la propria voce tramite un percorso scrivibile, perché l’ammissione self-service annulla del tutto il meccanismo. Controllate i permessi di mount e di condivisione e non solo il modo del file, poiché una directory che sembra chiusa per un account può essere aperta per un altro. Poi confermate quale account usa realmente il processo in esecuzione, e non quale account menziona il file di unit. I due coincidono solo quando nient’altro li ha modificati.

Osservate separatamente il rifiuto, l’ammissione e la revoca

Provate un’identità che appartiene al servizio e confermate che si connette. Provate un certificato valido senza voce e confermate che viene rifiutato. Provate un’identità ammessa all’altro servizio e confermate che qui non è ammessa. Annotate l’istanza del servizio e l’identità effettiva accanto a ogni risultato, perché un risultato senza quel contesto nessun altro può riprodurlo.

La revoca dell’accesso è un’operazione distinta dalla revoca del certificato. Modificare un file di ammissione toglie un diritto su un servizio mentre l’identità resta valida ovunque altrove, mentre una chiave compromessa richiede la risposta di revoca dell’organizzazione. Decidete in anticipo cosa accade alle sessioni già attive, poiché né la modifica della directory né la lista di revoca le terminano da sole.

L’ammissione è anche solo la prima porta. Entrare in un servizio non dice nulla sulle sottoreti, sui database o sulle interfacce di gestione che stanno dietro, e quella politica delle risorse va scritta e verificata a parte.