Contrasinais VPN fronte a certificados de cliente: que se recupera antes

Un despregamento pide nome de usuario e contrasinal, outro un certificado de cliente e un terceiro ambos. A elección cambia moito máis que a caixa de inicio de sesión: decide como se emiten as credenciais, como caducan, como se ve a recuperación ás 2 da madrugada e quen pode revogar o acceso para exactamente un dispositivo. Compare o ciclo de vida operativo e non a caixa de diálogo.

Un contrasinal é un segredo de conta validado por un proceso de autenticación, mentres que un certificado é unha identidade máis a proba de posesión da súa chave privada. Son obxectos distintos con modos de fallo distintos.

Dúas probas distintas, dúas caixas distintas

Un contrasinal demostra o coñecemento dun segredo compartido, así que o servidor compara un hash e o sistema de contas posúe o ciclo de vida. Un certificado demostra a posesión dunha chave privada, e o servidor verifica unha cadea de sinaturas ata unha CA na que confía. O segundo pode identificar un dispositivo en lugar dunha persoa, por iso os despregamentos adoitan emitir un por portátil. Unha frase de paso que protexe un ficheiro de chave é outra terceira cousa: garda o ficheiro en repouso e non é o contrasinal da conta VPN.

A verificación do servidor segue sendo necesaria en calquera combinación. Unhas credenciais válidas enviadas a un extremo cuxa identidade deixou de comprobar seguen sendo credenciais entregadas a quen respondeu, por iso a comprobación do certificado do servidor pertence ao perfil básico e non a un paso de resolución de problemas.

A emisión, a caducidade e a revogación son o custo real

Os contrasinais son baratos de emitir e caros de manter: restablecementos, política, reutilización e a cola do servizo de asistencia. Os certificados trasladan ese custo ao principio, onde se necesita unha CA, un proceso de sinatura e unha canle de distribución, e logo engaden un calendario de caducidade que ninguén recorda. Ambos necesitan unha revogación planificada. Un certificado revogado necesita unha CRL que cada servidor lea de verdade, e unha conta desactivada necesita que o backend de autenticación a rexeite na próxima conexión e non na próxima sincronización.

Ningún dos mecanismos se volve seguro por existir. A pregunta é que ciclo de vida pode operar o equipo de forma coherente.

Que se rompe cando se perde un dispositivo

Para un portátil perdido, elimine a autorización que ese dispositivo usou realmente. Restablecer o contrasinal non revoga o seu certificado, e emitir un certificado novo non cambia o contrasinal dunha conta non relacionada. As identidades separadas por dispositivo fan posible unha retirada dirixida, mentres que as credenciais compartidas fan que retirar un dispositivo afecte varios. Escriba o procedemento de recuperación para cada mecanismo antes de necesitalo, incluído quen pode asinar un certificado de substitución fóra do horario laboral.

Practique a ruta de revogación en lugar de supoñela: revogue unha identidade de proba, confirme que o servidor a rexeita nunha conexión nova e logo restáurena. Un proceso de revogación que nunca se practica tende a fallar xusto cando se necesita.

Operar ambos sen duplicar o traballo

Moitos despregamentos combinan ambos a propósito: un certificado para o dispositivo e unha credencial de conta para a persoa, de xeito que un portátil roubado non abonda e un contrasinal filtrado tampouco. Esa combinación compensa só cando os dous ciclos de vida permanecen separados e ambos están automatizados. Se non, o servizo de asistencia xestiona dúas colas e a ganancia de seguridade segue sendo teórica.

Escolla o método que os clientes do servizo e as ferramentas de xestión realmente admiten. Debilitar a verificación para que un perfil desaxustado se conecte inverte todo o sentido, e un perfil editado ata que se conecta adoita ser un que xa non comproba aquilo para o que se construíu.

Anote que proba require cada despregamento e como se revoga cada unha. O próximo incidente preguntará exactamente por iso.