Acceso VPN con cuenta de servicio: certificado o inicio de sesión compartido

Dos diseños cubren casi cualquier configuración de VPN sin supervisión: un inicio de sesión humano compartido guardado en un script, o un certificado de máquina vinculado al host. Fallan en lugares distintos, lo que importa más que la velocidad de configuración. Una contraseña almacenada se rompe cuando su dueño la cambia o se marcha; un certificado se rompe cuando caduca o cuando el host se reconstruye sin la clave. Tres condiciones deciden qué coste puede asumir, y ninguno de los dos diseños limita nada hasta que lo hace la política de autorización.

Empiece por la tarea, no por la cuenta

La tarea define el límite: qué destinos, qué servicios, qué horarios, cuánto puede durar una sesión. Una ruta de túnel es solo la mitad de ese límite. La puerta de enlace decide si se permite la sesión; el recurso que hay detrás decide qué puede hacer la sesión. Escriba primero la lista, con un propietario nombrado, porque ambos diseños de identidad tienen que satisfacerla.

Mantenga la autenticación y la autorización separadas mientras lo escribe. La autenticación responde quién se conecta; la autorización responde a qué puede llegar la sesión después. RADIUS lleva la segunda parte como atributos como Filter-Id, Framed-IP-Address, Session-Timeout y Class, y la puerta de enlace los adjunta en cuanto el inicio de sesión tiene éxito. Un diseño que cambia el inicio de sesión y deja intacta la autorización no ha limitado nada.

Inicio de sesión humano compartido: la contraseña se convierte en el límite

Reutilizar una cuenta humana es el camino más rápido y el que peor envejece. La credencial es una contraseña, así que acaba en un script, un archivo de entorno y una configuración del planificador, y cada copia necesita rotación. Cuando el dueño la cambia un viernes, la tarea falla en la siguiente ejecución y nadie está mirando.

El MFA es donde este diseño suele derrumbarse. Un script no puede responder a una solicitud push, así que la cuenta queda excluida de la política, que es exactamente la cuenta que elegiría un atacante. Las exclusiones, los desvíos de ubicación de confianza y las exenciones por cuenta se multiplican, y ninguna es visible para la siguiente persona que lea la configuración del inquilino.

La atribución es el otro coste. Cada sesión del registro de la puerta de enlace lleva el mismo nombre de usuario, así que la sincronización nocturna no se distingue del trabajo de la persona que la escribió, y revocar la tarea significa revocar a esa persona.

Certificado de máquina: identidad vinculada al host

Un certificado cambia la pregunta de qué sabe la cuenta a qué es el host. Con EAP-TLS el cliente presenta un certificado y demuestra la posesión de la clave privada correspondiente; el servidor de políticas asigna el sujeto o la cuenta de equipo a un grupo y aplica la política de ese grupo. Sin solicitud, sin secreto compartido en un archivo de texto.

El límite que crea es más estrecho de lo que la gente espera. Un certificado autentica el host, no la tarea, y cualquiera con derechos de root o de administrador local puede usar esa clave en ese host. Guarde la clave donde la plataforma la protege: no exportable en el almacén de certificados de Windows, con respaldo de TPM donde el perfil lo permita, o un archivo 0600 propiedad de root en Linux. Comprometer el host es comprometer la credencial.

La caducidad es el fallo recurrente. Un certificado que caduca un domingo detiene la tarea el domingo, y la puerta de enlace suele informar de un fallo de autenticación genérico en lugar de nombrar la fecha. Compruebe las fechas desde el host de la tarea como parte del runbook:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

La revocación necesita una ruta que la puerta de enlace compruebe. OpenVPN lee una CRL mediante la opción crl-verify, y strongSwan depende de CRL o OCSP según cómo esté construido el perfil de conexión. Si ninguno está conectado, retirar un host significa esperar a que caduque el certificado.

Tres condiciones que deciden entre ellos

Haga la comparación contra la plataforma que tiene, no contra un diseño de referencia.

Primera condición: ¿puede la puerta de enlace autorizar una identidad de máquina? Si solo asigna un nombre de usuario RADIUS a un usuario del directorio, un certificado autentica el host y luego se atasca en la autorización. Segunda condición: ¿necesita la tarea acceso a un recurso que solo lleva una cuenta de usuario, como un recurso compartido montado o una licencia por puesto? Entonces una identidad de máquina no puede sustituirlo, y la respuesta honesta es una cuenta de usuario dedicada con una política acotada. Tercera condición: ¿quién puede rotar la credencial sin una persona en el bucle? El enrolamiento automático hace que los certificados sean baratos de mantener; una contraseña que conoce una sola persona, no.

Lea la tabla como una lista de costes, no como una clasificación. La columna del secreto almacenado gana en velocidad de revocación y en compatibilidad con recursos que solo entienden cuentas de usuario; la columna del certificado gana en rotación y en no debilitar el MFA para que funcione un script.

Ponga el límite en la política, después de la autenticación

Sea cual sea la identidad que elija, el límite de permisos pertenece a la política que se ejecuta después de la autenticación. En NPS, las políticas de red se evalúan en orden y la primera política que coincide con cada condición aplica su configuración, así que una política amplia colocada por encima de una estrecha decide el resultado independientemente de lo que presente el cliente. Microsoft documenta el modelo de condiciones y configuración en su resumen de políticas NPS.

Dé a la tarea su propio grupo o condición de política, basado en algo que lleve la identidad de máquina: una plantilla de certificado, un identificador de estación que llama o una dirección de un pool dedicado. Luego acote la sesión con atributos: un Filter-Id para el rol al que la asigna su puerta de enlace, un Session-Timeout corto para que una tarea atascada se reautentique en lugar de mantener una sesión durante días, y un Framed-IP-Address de un pool que filtre con firewall al otro lado. La autorización de aplicaciones sigue aparte: un túnel hacia un servidor de bases de datos no es permiso para leer una tabla dentro de él.

Verifique las denegaciones, luego planifique la retirada

El acceso que funciona no demuestra nada sobre el mínimo privilegio. Pruebe las denegaciones en su lugar: conéctese con la identidad de la tarea e intente alcanzar un destino fuera de la lista, abra una segunda sesión simultánea si la puerta de enlace debe permitir solo una, y repita el inicio de sesión tras revocar la credencial.

Luego confirme la misma sesión en dos lugares. El registro de la puerta de enlace muestra la identidad que se autenticó; el registro del servidor de políticas muestra qué política coincidió y qué atributos devolvió. En OpenVPN el servidor registra el nombre común del certificado, e ipsec statusall en strongSwan imprime el túnel establecido con la identidad en uso. Si los dos registros no coinciden sobre la identidad, la política está coincidiendo con algo distinto de lo que supone.

La retirada forma parte del diseño, no de un sprint de limpieza. Anote todo lo que hay que borrar (certificado o cuenta, pertenencia a grupo, política de red, entrada de pool, regla de firewall en el objetivo) y ejecútelo una vez mientras la tarea es fácil de reconstruir.

Si empieza hoy, trabaje en este orden: escriba la lista de recursos, elija la identidad con las tres condiciones, ponga el límite en la política y practique una denegación antes de que la tarea entre en servicio.