Probas de aceptación para unha pasarela VPN virtual con autenticación de dous factores
Demostre a pasarela etapa por etapa: rexistro, inicio de sesión, denegación, revocación e restauración, cada unha cun artefacto e unha condición de aprobación escrita antes da proba.
Os provedores describen este aparello como virtual e capaz de dous factores, e ningunha das dúas palabras responde ás preguntas que deciden a compra. Que imaxe de hipervisor se admite, que clientes poden rexistrarse, que demostra realmente o segundo factor e que ocorre cando o provedor de identidade cae seguen abertos. Converter esas preguntas en etapas de aceptación que poida executar nun ensaio, e a decisión deixa de depender de quão persuasiva sexa a ficha técnica. A folla de abaixo é unha estrutura para esas probas, non unha clasificación de produtos.
Que debe confirmar o provedor sobre este despregamento
Comece fixando o despregamento nunha páxina: o hipervisor ou a nube, a arquitectura de convidado, a imaxe admitida e as interfaces que espera o aparello. Engada os usuarios, cos seus sistemas operativos, se os dispositivos están xestionados e como deben funcionar o rexistro e o inicio de sesión. Despois, o acceso privado: aplicacións e prefixos, disposición de DNS, rutas de retorno e se unha saída pública a internet forma parte da oferta.
As operacións pertencen á mesma páxina: quen mantén o equipo, de onde veñen as actualizacións, a onde van os rexistros, como se protexe a configuración e que obxectivo de recuperación acordou realmente o negocio. Pida ao provedor que confirme esa combinación exacta, non que o software se execute nunha máquina virtual. Manteña visibles as dependencias externas, como un provedor de identidade ou un servizo de licenzas, porque forman parte do despregamento tanto se se inclúen como se non. Unha páxina de despregamento sen ningunha dependencia nomeada adoita ser unha páxina de despregamento cunha dependencia descoñecida.
Demostre que o segundo factor é un segundo factor
Nomee o autenticador e o fluxo de verificación, e diga que identidade establece cada paso. Dous avisos de contrasinal seguidos non son un segundo factor, e un contrasinal máis un código dun só uso é unha afirmación distinta da dun autenticador criptográfico vinculado ao servizo. Escriba o fluxo que compra, non a etiqueta da caixa.
A resistencia ao phishing é unha propiedade aparte, e a guía de autenticadores do NIST trátaa como tal: un código que se pode enganar a un usuario para que o retransmita segue cumprindo a autenticación multifactor mentres falla esa condición adicional. Pida a propiedade de forma explícita se lle importa. Despois esixa unha demostración co tipo de cliente que os seus usuarios executan de verdade, que cubra o rexistro, un desafío rexeitado ou caducado, a recuperación tras perder o autenticador e a revocación dun usuario mentres os demais seguen conectados. Manteña a verificación de identidade da pasarela dentro do alcance, porque un cliente que confía en calquera pasarela moveu o problema en lugar de resolvelo.
Escriba a condición de aprobación antes de romper nada
A táboa de abaixo é a parte da folla que sobrevive ao contacto cun provedor, porque cada fila pide un artefacto en lugar dunha garantía. Encha a condición de aprobación antes do ensaio e trate unha fila sen probas como unha fila fallida. Cinco etapas cobren o que debe facer unha pasarela.
| 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 |
O rexistro vai primeiro porque todo o posterior depende del: un dispositivo que non pode rexistrarse non se pode probar. O inicio de sesión é unha etapa separada do rexistro, e a denegación é a etapa que máis follas esquecen, porque unha pasarela que admite a todos non demostrou que denegue a ninguén. A revocación e a restauración concentran a maior parte do risco operativo, e ambas son baratas de ensaiar nunha copia.
Ensaie na copia, non na pasarela en produción
Execute as etapas disruptivas nunha copia da plataforma, seguindo o procedemento de despregamento admitido, e conserve cada proba coa súa data e versión de configuración. Unha fila de reinicio non se responde cun reinicio desde a consola, e unha fila de restauración non se responde exportando a configuración. Anote que estado volve só e que ten que reconectarse, porque esa diferenza é o que herda o equipo de operacións. O ensaio é tamén a única ocasión de cronometrar unha restauración sen ter que explicar unha caída.
Rexistre o estado do provedor de identidade no momento de cada proba, porque unha fila de caída probada contra un provedor san demostra o contrario do que afirma a folla. Dous revisores no mesmo ensaio detectan cousas distintas, e o segundo adoita atopar a fila cuxa proba é unha captura dun panel. Manteña esa proba anexa á fila á que pertence, non nun cartafol co nome do proxecto.
Mida a carga de traballo que executará o seu equipo
Acorde unha carga parecida a unha semana normal, e mídaa onde pensa despregar: concorrencia, mestura de tráfico e a xanela de mantemento que o equipo ten de verdade. Unha cifra de rendemento anunciada describe unha condición de laboratorio e non di nada sobre os seus usuarios. Mida a restauración contra o obxectivo de recuperación, non contra o plan.
A folla está rematada cando cada etapa ten un artefacto e cada artefacto ten unha data. Un aparello que alguén mantén, con probas para cada fila, é unha compra distinta da lista máis longa de casillas marcadas.