CA compartida, portes separades: un servei per fitxer d’admissió
Un certificat que supera les comprovacions de l’autoritat compartida no és un bitllet per a tots els serveis. L’admissió pertany a un fitxer propi de cada servei que el dimoni exigeix.
Un certificat que valida contra una autoritat compartida ha superat una prova de confiança, no una prova de pertinença. Aquestes dues decisions sovint es confonen perquè totes dues passen en el moment de la connexió, i la confusió roman invisible fins que s’admet en un servei algú que no hi hauria de ser. La solució no és una segona autoritat; és una segona decisió, presa per a cada servei i enregistrada on la llegeix el dimoni. Mantingueu les dues separades i la major part de la confusió d’aquest àmbit desapareix.
Una cadena de confiança no diu res sobre la pertinença al servei
Dos serveis poden acceptar la mateixa jerarquia emissora i tenir poblacions diferents. Un portàtil pertany al primer i no ha d’arribar al segon, mentre que altres clients de la mateixa jerarquia sí que hi pertanyen. Treure l’autoritat d’aquell servei deixaria fora tothom qui el fa servir legítimament, així que la feina és d’admissió, no de confiança.
Ajuda imaginar dos panys en una porta. El certificat obre el pany exterior, i una decisió per servei obre l’interior; cap no substitueix l’altre. Un servei amb només el pany exterior no aplica cap pertinença, només autentica. Escriviu totes dues decisions abans de tocar res, perquè una política que només existeix en la forma d’una connexió funcional no es pot auditar. El que segueix tracta del pany interior.
Convertiu les substitucions opcionals en una porta d’admissió
Un directori de configuració de clients normalment és una comoditat: els fitxers que hi ha substitueixen la configuració dels clients que nomenen, i un client sense fitxer simplement funciona amb els valors per defecte del servidor. Una directiva converteix aquesta comoditat en una porta, de manera que un fitxer absent significa que es rebutja la connexió.
client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive
L’edició comunitària de OpenVPN 2.6 ccd-exclusive a la seva pàgina de manual documenta exactament aquesta condició, i la cerca del fitxer nomenat depèn de la identitat efectiva del client. Altres compilacions i servidors gestionats per productes poden diferir, així que confirmeu la versió instal·lada abans de confiar en la mateixa semàntica en un altre lloc.
Tracteu el camí anterior com un exemple i comproveu la disposició desplegada en lloc de crear un directori que hagi inventat una guia. Deixeu les comprovacions de certificats, les comprovacions d’identitat del servidor i l’autenticació de comptes exactament com eren, perquè el fragment afegeix una condició i no en treu cap. Prepareu el canvi abans de producció, ja que un rebuig aixecat en el moment equivocat sembla un error de certificat i envia la investigació cap a l’autoritat. Després confirmeu que la línia de registre d’un client rebutjat nomena el fitxer de configuració absent i no la cadena.
Un directori per servei, no una llista compartida
La pertinença pertany al servei que l’aplica, així que cada servei manté el seu directori i els seus fitxers. Apuntar dos serveis a una llista els fa compartir la pertinença tant si algú ho volia com si no, i el canvi resultant és difícil de rastrejar fins a una decisió. L’autoritat compartida pot continuar compartida; els fitxers d’admissió no. Mantenir-los separats també vol dir que un error en un servei no pot ampliar silenciosament un altre.
Una entrada DEFAULT és el cas que enganya la gent. Proporciona valors de reserva quan no es troba cap fitxer nomenat, però no és el fitxer nomenat que exigeix la porta, així que no pot admetre un client per si sol. Proveu un client que no tingui cap entrada i confirmeu el rebuig; si aquest client és admès, s’està aplicant el valor de reserva i ccd-exclusive no té efecte en aquella instància.
La identitat efectiva decideix quin fitxer es llegeix
La cerca utilitza la identitat amb què el client s’ha autenticat realment, que normalment és el nom comú del certificat. Quan el servidor també verifica un nom d’usuari i una contrasenya i assigna aquest nom al nom comú, el fitxer ha de coincidir amb el nom d’usuari autenticat. Una discrepància deixa un directori ple de noms de fitxer versemblants que mai no es seleccionen.
Llegir és l’altra meitat. El dimoni normalment baixa els privilegis després de l’arrencada, així que el compte reduït necessita accés de lectura al directori i a cada entrada. Els clients no han de poder crear la seva pròpia entrada per cap camí on es pugui escriure, perquè l’admissió autoservida invalida del tot el mecanisme. Comproveu els permisos de muntatge i de compartició i no només el mode del fitxer, ja que un directori que sembla tancat per a un compte pot estar obert per a un altre. Després confirmeu quin compte fa servir realment el procés en execució, i no quin compte esmenta el fitxer d’unitat. Els dos coincideixen només quan res altre els ha canviat.
Observeu el rebuig, l’admissió i la revocació per separat
Proveu una identitat que pertany al servei i confirmeu que es connecta. Proveu un certificat vàlid sense entrada i confirmeu que es rebutja. Proveu una identitat admesa a l’altre servei i confirmeu que aquí no s’admet. Enregistreu la instància del servei i la identitat efectiva al costat de cada resultat, perquè un resultat sense aquest context ningú altre no el pot reproduir.
La retirada és una operació separada de la revocació. Editar un fitxer d’admissió elimina un dret d’un servei mentre la identitat continua vàlida a tota la resta, mentre que una clau compromesa necessita la resposta de revocació de l’organització. Decidiu per endavant què passa amb les sessions ja obertes, perquè ni l’edició del directori ni la llista de revocació les tanquen per si soles.
L’admissió també és només la primera porta. Unir-se a un servei no diu res sobre les subxarxes, les bases de dades o les interfícies de gestió que hi ha darrere, i aquesta política de recursos s’ha d’escriure i provar per separat.