Por que as chaves do servidor e as credenciais de usuario necesitan propietarios separados

A chave que demostra que a túa pasarela é ela mesma e a credencial que di que unha persoa pode unirse son ambos segredos, e aí remata o parecido. Un identifica un servizo ante cada cliente; o outro identifica un usuario ante ese servizo. Mesturalos aforra un paso durante a instalación e custa unha tarde durante un incidente, porque a recuperación de cada un non é a mesma operación. A separación é aburrida de configurar e memorable de omitir.

Dous segredos, dous propietarios distintos

A pasarela garda unha chave privada ou un certificado cuxa única tarefa é demostrar a súa identidade durante o protocolo de enlace. Os clientes necesitan o material público correspondente para verificala, e nunca necesitan a metade privada. Esa asimetría é o que fai posible a autenticación do servidor sen darlle a cada usuario a capacidade de suplantar o servidor.

O material de usuario vai na outra dirección. Unha chave privada de cliente, un certificado de cliente ou un contrasinal demostran que a esta persoa ou dispositivo concreto se lle concedeu acceso. Espérase que se distribúa, se copie entre dispositivos e finalmente se revogue.

WireGuard fai obvia a separación porque cada participante ten un par de chaves: a chave privada do servidor queda no servidor, e un ficheiro de configuración que lle entregas a un usuario contén a súa propia chave privada máis a chave pública do servidor. Un perfil que contén a chave privada do servidor non é un atallo, é un compromiso agardando un recurso compartido.

Tres preguntas que deciden a separación

Pregunta quen debe poder ler o segredo, que permitiría facer a un atacante unha exposición e se a solución é unha revogación ou unha reconstrución do servizo.

Se un usuario pode lelo e demostra a identidade da pasarela, a resposta á segunda pregunta é que o atacante pode suplantar o teu servidor ante cada cliente — o peor resultado, porque os clientes están deseñados para confiar nesa identidade. Se só demostra un usuario, a exposición concede o acceso dese usuario a un par, e a revogación é unha operación rutineira. Se é unha chave de autoridade de certificación, a exposición é peor que ambas, xa que o atacante pode acuñar identidades nas que confía cada extremo.

Eses tres respostas producen a regra de almacenamento: a chave de CA vive fóra de liña ou nunha caixa forte, a chave da pasarela vive na pasarela, e as chaves de usuario viven cos usuarios. Calquera disposición que poña as tres nun só directorio por comodidade converteu unha decisión nun accidente.

O que un cliente realmente necesita

Un cliente necesita o certificado público ou a chave pública do par, o material de CA ou a pegada na que debe confiar, a súa propia chave privada e os detalles do extremo. Esa lista non contén nada que pertenza á identidade privada da pasarela.

A documentación é onde isto se filtra. Unha guía que di copia o directorio do servidor e borra o que non necesites xa ensinou o modelo equivocado, porque o ficheiro que queda tras o paso de borrado raramente o revisa alguén.

Revoga un usuario sen tocar a pasarela

Como as identidades de usuario se emiten por separado, poden retirarse por separado. Un despregamento baseado en certificados revoga o certificado de cliente e publica unha lista de revogación actualizada; un despregamento de WireGuard elimina a entrada do par da configuración do servidor. Ningunha desas operacións cambia a chave propia da pasarela.

Conserva o rexistro de emisión, ou non saberás que identidade retirar. Unha folla de cálculo abonda, sempre que nomee a persoa, o dispositivo, o número de serie ou a chave pública e a data, e sempre que alguén se encargue dela despois de que se marche a persoa que a construíu.

Os comandos seguintes inspeccionan un certificado de cliente e despois revógano mediante unha autoridade ao estilo de OpenSSL, que é o fluxo que easy-rsa envolve:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publica a nova lista onde os clientes a comproban, ou a revogación é unha nota nun ficheiro que non cambia nada. Se a túa pasarela acepta certificados de cliente sen consultar unha lista de revogación, dío explicitamente en lugar de insinuar que a revogación funciona.

Mantén as copias de seguridade tan separadas como os segredos

Un arquivo de reconstrución contén lexitimamente a chave da pasarela e o material de CA, porque sen eles unha restauración non pode reproducir o servizo. Un paquete de configuración de cliente non debe, e os dous non deben gardarse xuntos. Etiqueta cada arquivo por quen pode gardalo, non pola data en que se fixo. Esa etiqueta é o que le un administrador canso ás dúas da madrugada.

Esa distinción tamén fixa quen pode recuperar cada un. Administrar a pasarela, emitir identidades de usuario e ler copias de seguridade son tres poderes distintos, e quen necesita un non necesita automaticamente os outros. Escribe eses permisos e despois compróbaos contra o que o teu almacenamento permite realmente, porque a herdanza de directorios concede en silencio máis do que a política pretende.