CA compartida, portas separadas: un servizo por ficheiro de admisión

Un certificado que se valida contra unha autoridade compartida superou unha proba de confianza, non unha proba de pertenza. Esas dúas decisións adoitan confundirse porque ambas ocorren no momento da conexión, e a confusión permanece invisible ata que se admite nun servizo a alguén que non debería estar nel. A solución non é unha segunda autoridade; é unha segunda decisión, tomada por servizo e rexistrada onde o daemon a le. Manteña as dúas separadas e a maior parte da confusión neste eido desaparece.

Unha cadea de confianza non di nada sobre a pertenza ao servizo

Dous servizos poden aceptar a mesma xerarquía emisora e aínda así ter poboacións diferentes. Un portátil pertence ao primeiro e non debe acadar o segundo, mentres que outros clientes da mesma xerarquía si pertencen alí. Retirar a autoridade dese servizo deixaría fóra a todos os que o usan lexitimamente, así que o traballo é de admisión, non de confianza.

Axuda imaxinar dous ferrollos nunha porta. O certificado abre o ferrollo exterior, e unha decisión por servizo abre o interior; ningún substitúe o outro. Un servizo só co ferrollo exterior non aplica pertenza de ningún xeito, só autentica. Escriba ambas as decisións antes de tocar nada, porque unha política que só existe na forma dunha conexión que funciona non se pode auditar. O que segue trata do ferrollo interior.

Converta as substitucións opcionais nunha porta de admisión

Un directorio de configuración de clientes adoita ser unha comodidade: os ficheiros que contén substitúen axustes dos clientes que nomean, e un cliente sen ficheiro simplemente execútase cos valores predeterminados do servidor. Unha directiva converte esa comodidade nunha porta, de modo que un ficheiro ausente significa que se rexeita a conexión.

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

A edición comunitaria de OpenVPN 2.6 ccd-exclusive en a súa páxina de manual documenta exactamente esta condición, e a busca do ficheiro nomeado depende da identidade efectiva do cliente. Outras compilacións e servidores xestionados por produtos poden diferir, así que confirme a versión instalada antes de confiar na mesma semántica noutro lugar.

Trate a ruta anterior como un exemplo e comprobe a disposición despregada en lugar de crear un directorio que inventase unha guía. Deixe as comprobacións de certificados, as comprobacións de identidade do servidor e a autenticación de contas exactamente como estaban, porque o fragmento engade unha condición e non quita nada. Prepare o cambio antes de produción, xa que un rexeitamento levantado no punto equivocado parece un fallo de certificado e envía a investigación cara á autoridade. Despois confirme que a liña de rexistro dun cliente rexeitado nomea o ficheiro de configuración ausente e non a cadea.

Un directorio por servizo, non unha lista compartida

A pertenza corresponde ao servizo que a aplica, así que cada servizo mantén o seu propio directorio e os seus propios ficheiros. Apuntar dous servizos a unha lista fai que compartan a pertenza tanto se alguén o pretendía como se non, e o cambio resultante é difícil de rastrexar ata unha decisión. A autoridade compartida pode seguir compartida; os ficheiros de admisión non. Mantalos separados tamén significa que un erro nun servizo non pode ampliar outro en silencio.

Unha entrada DEFAULT é o caso que engana a xente. Proporciona axustes de reserva cando non se atopa ningún ficheiro nomeado, pero non é o ficheiro nomeado que esixe a porta, así que non pode admitir un cliente por si soa. Proba un cliente que non teña ningunha entrada e confirma o rexeitamento; se ese cliente é admitido, estase aplicando o valor de reserva e ccd-exclusive non está vixente nesa instancia.

A identidade efectiva decide que ficheiro se le

A busca utiliza a identidade coa que o cliente se autenticou realmente, que normalmente é o nome común do certificado. Cando o servidor tamén verifica un nome de usuario e un contrasinal e asigna ese nome ao nome común, o ficheiro debe coincidir co nome de usuario autenticado. Unha discrepancia deixa un directorio cheo de nomes de ficheiro verosímiles que nunca se seleccionan.

Ler é a outra metade. O daemon adoita abandonar privilexios despois do arranque, así que a conta reducida necesita acceso de lectura ao directorio e a cada entrada. Os clientes non deben poder crear a súa propia entrada por ningunha ruta na que se poida escribir, porque a admisión autoservizo anula por completo o mecanismo. Comprobe os permisos de montaxe e de compartición e non só o modo do ficheiro, xa que un directorio que parece pechado para unha conta pode estar aberto para outra. Despois confirme que conta usa realmente o proceso en execución, e non que conta menciona o ficheiro de unidade. Ambas coinciden só cando nada máis as cambiou.

Observe o rexeitamento, a admisión e a revogación por separado

Probe unha identidade que pertence ao servizo e confirme que se conecta. Probe un certificado válido sen entrada e confirme que se rexeita. Probe unha identidade admitida no outro servizo e confirme que aquí non se admite. Anote a instancia do servizo e a identidade efectiva xunto a cada resultado, porque un resultado sen ese contexto ninguén máis o pode reproducir.

A retirada é unha operación distinta da revogación. Editar un ficheiro de admisión elimina un dereito dun servizo mentres a identidade segue sendo válida en todo o demais, mentres que unha chave comprometida require a resposta de revogación da organización. Decida de antemán que ocorre coas sesións xa establecidas, porque nin a edición do directorio nin a lista de revogación as terminan por si soas.

A admisión tamén é só a primeira porta. Unirse a un servizo non di nada sobre as subredes, as bases de datos ou as interfaces de xestión que hai detrás, e esa política de recursos debe escribirse e probarse por separado.