Pruebas de aceptación para una puerta de enlace VPN virtual con autenticación de dos factores
Demuestre la puerta de enlace etapa por etapa: alta, inicio de sesión, denegación, revocación y restauración, cada una con un artefacto y una condición de aprobación escrita antes de la prueba.
Los proveedores describen este equipo como virtual y capaz de dos factores, y ninguna de las dos palabras responde a las preguntas que deciden la compra. Qué imagen de hipervisor se admite, qué clientes pueden darse de alta, qué demuestra realmente el segundo factor y qué ocurre cuando el proveedor de identidad se cae siguen abiertos. Conviértalos en etapas de aceptación que pueda ejecutar en un ensayo, y la decisión deja de depender de lo persuasiva que sea la ficha técnica. La hoja de abajo es una estructura para esas pruebas, no una clasificación de productos.
Qué debe confirmar el proveedor sobre este despliegue
Empiece fijando el despliegue en una página: el hipervisor o la nube, la arquitectura de invitado, la imagen admitida y las interfaces que espera el equipo. Añada los usuarios, con sus sistemas operativos, si los dispositivos están gestionados y cómo deben funcionar el alta y el inicio de sesión. Después, el acceso privado: aplicaciones y prefijos, disposición de DNS, rutas de retorno y si una salida pública a internet forma parte de la oferta.
Las operaciones pertenecen a la misma página: quién mantiene el equipo, de dónde vienen las actualizaciones, adónde van los registros, cómo se protege la configuración y qué objetivo de recuperación ha acordado realmente el negocio. Pida al proveedor que confirme esa combinación exacta, no que el software se ejecute en una máquina virtual. Mantenga visibles las dependencias externas, como un proveedor de identidad o un servicio de licencias, porque forman parte del despliegue tanto si se incluyen como si no. Una página de despliegue sin ninguna dependencia nombrada suele ser una página de despliegue con una dependencia desconocida.
Demuestre que el segundo factor es un segundo factor
Nombre el autenticador y el flujo de verificación, y diga qué identidad establece cada paso. Dos avisos de contraseña seguidos no son un segundo factor, y una contraseña más un código de un solo uso es una afirmación distinta de la de un autenticador criptográfico vinculado al servicio. Escriba el flujo que compra, no la etiqueta de la caja.
La resistencia al phishing es una propiedad aparte, y la guía de autenticadores del NIST la trata como tal: un código que se puede engañar a un usuario para que retransmita sigue cumpliendo la autenticación multifactor mientras falla esa condición adicional. Pida la propiedad de forma explícita si le importa. Después exija una demostración con el tipo de cliente que sus usuarios ejecutan de verdad, que cubra el alta, un desafío rechazado o caducado, la recuperación tras perder el autenticador y la revocación de un usuario mientras los demás siguen conectados. Mantenga la verificación de identidad de la puerta de enlace dentro del alcance, porque un cliente que confía en cualquier puerta de enlace ha movido el problema en lugar de resolverlo.
Escriba la condición de aprobación antes de romper nada
La tabla de abajo es la parte de la hoja que sobrevive al contacto con un proveedor, porque cada fila pide un artefacto en lugar de una garantía. Rellene la condición de aprobación antes del ensayo y trate una fila sin pruebas como una fila fallida. Cinco etapas cubren lo que debe hacer una puerta de enlace.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
El alta va primero porque todo lo posterior depende de ella: un dispositivo que no puede darse de alta no se puede probar. El inicio de sesión es una etapa separada del alta, y la denegación es la etapa que más hojas olvidan, porque una puerta de enlace que admite a todos no ha demostrado que deniegue a nadie. La revocación y la restauración concentran la mayor parte del riesgo operativo, y ambas son baratas de ensayar en una copia.
Ensaye en la copia, no en la puerta de enlace en producción
Ejecute las etapas disruptivas en una copia de la plataforma, siguiendo el procedimiento de despliegue admitido, y conserve cada prueba con su fecha y versión de configuración. Una fila de reinicio no se responde con un reinicio desde la consola, y una fila de restauración no se responde exportando la configuración. Anote qué estado vuelve solo y qué tiene que reconectarse, porque esa diferencia es lo que hereda el equipo de operaciones. El ensayo es también la única ocasión de cronometrar una restauración sin tener que explicar una caída.
Registre el estado del proveedor de identidad en el momento de cada prueba, porque una fila de caída probada contra un proveedor sano demuestra lo contrario de lo que afirma la hoja. Dos revisores en el mismo ensayo detectan cosas distintas, y el segundo suele encontrar la fila cuya prueba es una captura de un panel. Mantenga esa prueba adjunta a la fila a la que pertenece, no en una carpeta con el nombre del proyecto.
Mida la carga de trabajo que ejecutará su equipo
Acuerde una carga parecida a una semana normal, y mídala donde piensa desplegar: concurrencia, mezcla de tráfico y la ventana de mantenimiento que el equipo tiene de verdad. Una cifra de rendimiento anunciada describe una condición de laboratorio y no dice nada de sus usuarios. Mida la restauración contra el objetivo de recuperación, no contra el plan.
La hoja está terminada cuando cada etapa tiene un artefacto y cada artefacto tiene una fecha. Un equipo que alguien mantiene, con pruebas para cada fila, es una compra distinta de la lista más larga de casillas marcadas.