Lista de IP permitidas o portátil aprobado: dos controles distintos

Las solicitudes de una regla que solo permita conectarse al portátil aprobado suelen acabar como una entrada de cortafuegos para la dirección pública de la oficina. Esa regla ahora admite todos los dispositivos detrás de la dirección. El requisito y la implementación no son lo mismo. Separe lo que quiere la política de lo que la dirección puede demostrar.

Tres preguntas en una sola solicitud de política

Divida la solicitud en tres partes: de dónde viene la conexión, a qué servicio puede llegar y qué ordenador presenta la credencial. Una regla de dirección de origen responde a la primera, y una regla de servicio de destino a la segunda. Ninguna identifica la máquina física, porque ambas operan sobre campos de red que comparten muchos dispositivos. La tercera necesita una credencial emitida para ese dispositivo y que no pueda reutilizarse en silencio.

Escriba las tres respuestas por separado. Una sola línea de cortafuegos no puede satisfacer un requisito que nombra tres.

Qué puede decirle la dirección de origen

La traducción de direcciones es la razón habitual por la que una regla de origen de red admite demasiado. Todo lo que está detrás de una salida de oficina aparece como la misma dirección pública, así que la regla concede acceso a todo el grupo. Una dirección fija dentro de la VPN tiene la misma debilidad en otro lugar: es una asignación ligada a una sesión, no una propiedad del hardware. Cualquier dispositivo con una credencial aceptada puede abrir esa sesión. Trate la dirección como una restricción de red y descríbala así.

Eso sigue siendo útil para limitar la exposición, y no es autenticación de dispositivo.

Vincule el acceso a una credencial dada de alta

Si el requisito es la restricción de dispositivo, use el alta por dispositivo compatible con la VPN y dé a cada ordenador una identidad distinta.

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

El listado del almacén muestra el certificado y si hay una clave privada, y la verificación muestra si la cadena lleva al ancla prevista. Un certificado demuestra la posesión de la clave privada aceptada según la política configurada; no demuestra qué máquina física la tenía cuando esa clave puede exportarse y copiarse. Poner al perfil el nombre del portátil deja el secreto exactamente igual de portátil que antes. Donde la plataforma lo admite, las claves protegidas por hardware con una política de atestación dan un vínculo más fuerte, y el alta aún debe decidir quién puede recibir la credencial.

Pruebe el límite y luego planifique la retirada

Evalúe dos casos: el portátil aprobado y el usuario deben conectarse, y otro dispositivo que solo tenga la cuenta del usuario no debe hacerlo. Si el diseño exige una comprobación de usuario y otra de dispositivo, verifique que el método elegido aplica ambas en la misma sesión en lugar de suponer que dos ajustes independientes se combinan.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

La revocación debe retirar la identidad aceptada del dispositivo, y el tratamiento de las sesiones activas merece su propia prueba. Un TPM o un indicador de dispositivo gestionado no es un certificado limpio de salud para cada proceso de la máquina.

Registre la restricción de red, la credencial del dispositivo y la decisión de alta como tres controles con tres responsables. Eso hace revisable el límite, y es lo que una dirección por sí sola nunca puede proporcionar.