Acceso VPN con conta de servizo: certificado ou inicio de sesión compartido

Dous deseños cobren case calquera configuración de VPN sen supervisión: un inicio de sesión humano compartido gardado nun script, ou un certificado de máquina ligado ao host. Fallan en lugares distintos, o que importa máis que a velocidade de configuración. Un contrasinal almacenado rompe cando o seu dono o cambia ou marcha; un certificado rompe cando caduca ou cando o host se reconstrúe sen a clave. Tres condicións deciden que custo pode soportar, e ningún dos dous deseños limita nada ata que o fai a política de autorización.

Comece pola tarefa, non pola conta

A tarefa define o límite: que destinos, que servizos, que horarios, canto pode durar unha sesión. Unha ruta de túnel é só a metade dese límite. A pasarela decide se se permite a sesión; o recurso que hai detrás decide que pode facer a sesión. Escriba primeiro a lista, cun propietario nomeado, porque ambos os deseños de identidade teñen que satisfacela.

Manteña a autenticación e a autorización separadas mentres o escribe. A autenticación responde quen se conecta; a autorización responde a que pode chegar a sesión despois. RADIUS leva a segunda parte como atributos como Filter-Id, Framed-IP-Address, Session-Timeout e Class, e a pasarela achégallos en canto o inicio de sesión ten éxito. Un deseño que cambia o inicio de sesión e deixa intacta a autorización non limitou nada.

Inicio de sesión humano compartido: o contrasinal convértese no límite

Reutilizar unha conta humana é o camiño máis rápido e o que peor envellece. A credencial é un contrasinal, así que acaba nun script, un ficheiro de contorno e unha configuración do planificador, e cada copia necesita rotación. Cando o dono o cambia un venres, a tarefa falla na seguinte execución e ninguén está mirando.

O MFA é onde este deseño adoita derrubarse. Un script non pode responder a unha solicitude push, así que a conta queda excluída da política, que é exactamente a conta que elixiría un atacante. As exclusións, os desvíos de localización de confianza e as exencións por conta multiplícanse, e ningunha é visible para a seguinte persoa que lea a configuración do inquilino.

A atribución é o outro custo. Cada sesión do rexistro da pasarela leva o mesmo nome de usuario, así que a sincronización nocturna non se distingue do traballo da persoa que a escribiu, e revogar a tarefa significa revogar a esa persoa.

Certificado de máquina: identidade ligada ao host

Un certificado cambia a pregunta do que sabe a conta ao que é o host. Con EAP-TLS o cliente presenta un certificado e demostra a posesión da clave privada correspondente; o servidor de políticas asigna o suxeito ou a conta de equipo a un grupo e aplica a política dese grupo. Sen solicitude, sen segredo compartido nun ficheiro de texto.

O límite que crea é máis estreito do que a xente espera. Un certificado autentica o host, non a tarefa, e calquera con dereitos de root ou de administrador local pode usar esa clave nese host. Garde a clave onde a plataforma a protexe: non exportable no almacén de certificados de Windows, con respaldo de TPM onde o perfil o permita, ou un ficheiro 0600 propiedade de root en Linux. Comprometer o host é comprometer a credencial.

A caducidade é o fallo recorrente. Un certificado que caduca un domingo detén a tarefa o domingo, e a pasarela adoita informar dun fallo de autenticación xenérico en lugar de nomear a data. Comprobe as datas desde o host da tarefa como parte do runbook:

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

A revogación necesita un camiño que a pasarela comprobe. OpenVPN le unha CRL mediante a opción crl-verify, e strongSwan depende de CRL ou OCSP segundo como estea construído o perfil de conexión. Se ningún dos dous está conectado, retirar un host significa esperar a que caduque o certificado.

Tres condicións que deciden entre eles

Faga a comparación contra a plataforma que ten, non contra un deseño de referencia.

Primeira condición: pode a pasarela autorizar unha identidade de máquina? Se só asigna un nome de usuario RADIUS a un usuario do directorio, un certificado autentica o host e logo atasca na autorización. Segunda condición: a tarefa necesita acceso a un recurso que só leva unha conta de usuario, como un recurso compartido montado ou unha licenza por posto? Entón unha identidade de máquina non pode substituílo, e a resposta honesta é unha conta de usuario dedicada cunha política acoutada. Terceira condición: quen pode rotar a credencial sen unha persoa no circuíto? O rexistro automático fai que os certificados sexan baratos de manter; un contrasinal que coñece unha soa persoa, non.

Lea a táboa como unha lista de custos, non como unha clasificación. A columna do segredo almacenado gaña en velocidade de revogación e en compatibilidade con recursos que só entenden contas de usuario; a columna do certificado gaña en rotación e en non debilitar o MFA para que funcione un script.

Pon o límite na política, despois da autenticación

Sexa cal sexa a identidade que escolla, o límite de permisos pertence á política que se executa despois da autenticación. En NPS, as políticas de rede avalíanse en orde e a primeira política que coincide con cada condición aplica a súa configuración, así que unha política ampla colocada por riba dunha estreita decide o resultado independentemente do que presente o cliente. Microsoft documenta o modelo de condicións e configuración no seu resumo de políticas NPS.

Dea á tarefa o seu propio grupo ou condición de política, baseado en algo que leve a identidade de máquina: un modelo de certificado, un identificador de estación de chamada ou un enderezo dun pool dedicado. Logo acoute a sesión con atributos: un Filter-Id para o rol ao que a súa pasarela a asigna, un Session-Timeout curto para que unha tarefa atascada se reautentique en lugar de manter unha sesión durante días, e un Framed-IP-Address dun pool que filtre con firewall no outro lado. A autorización de aplicacións segue aparte: un túnel a un servidor de bases de datos non é permiso para ler unha táboa dentro del.

Comprobe as denegacións, logo planifique a retirada

O acceso que funciona non demostra nada sobre o mínimo privilexio. Probe as denegacións no seu lugar: conéctese coa identidade da tarefa e intente alcanzar un destino fóra da lista, abra unha segunda sesión simultánea se a pasarela debe permitir só unha, e repita o inicio de sesión tras revogar a credencial.

Logo confirme a mesma sesión en dous lugares. O rexistro da pasarela mostra a identidade que se autenticou; o rexistro do servidor de políticas mostra que política coincidiu e que atributos devolveu. En OpenVPN o servidor rexistra o nome común do certificado, e ipsec statusall en strongSwan imprime o túnel establecido coa identidade en uso. Se os dous rexistros non coinciden sobre a identidade, a política está a coincidir con algo distinto do que supón.

A retirada forma parte do deseño, non dun sprint de limpeza. Anote todo o que hai que borrar (certificado ou conta, pertenza a grupo, política de rede, entrada de pool, regra de firewall no obxectivo) e execúteo unha vez mentres a tarefa é fácil de reconstruír.

Se comeza hoxe, traballe nesta orde: escriba a lista de recursos, escolla a identidade coas tres condicións, pon o límite na política e pratique unha denegación antes de que a tarefa entre en servizo.