Verifiche di accettazione per un gateway VPN virtuale con autenticazione a due fattori
Dimostrate il gateway passo dopo passo: registrazione, accesso, rifiuto, revoca e ripristino, ciascuno con un artefatto e una condizione di superamento scritta prima della prova.
I fornitori descrivono questo apparato come virtuale e capace di due fattori, e nessuna delle due parole risponde alle domande che decidono l’acquisto. Quale immagine di hypervisor è supportata, quali client possono registrarsi, che cosa dimostra davvero il secondo fattore e che cosa accade quando il fornitore di identità cade restano aperti. Trasformateli in fasi di accettazione che potete eseguire in una prova, e la decisione smette di dipendere da quanto è persuasiva la scheda tecnica. Il foglio qui sotto è una struttura per quelle prove, non una classifica di prodotti.
Che cosa deve confermare il fornitore su questa distribuzione
Cominciate fissando la distribuzione su una pagina: l’hypervisor o il cloud, l’architettura guest, l’immagine supportata e le interfacce che l’apparato si aspetta. Aggiungete gli utenti, con i loro sistemi operativi, se i dispositivi sono gestiti e come devono funzionare registrazione e accesso. Poi l’accesso privato: applicazioni e prefissi, disposizione del DNS, percorsi di ritorno e se un’uscita Internet pubblica fa parte dell’offerta.
Le operazioni appartengono alla stessa pagina: chi mantiene l’apparato, da dove arrivano gli aggiornamenti, dove finiscono i log, come è protetta la configurazione e quale obiettivo di ripristino l’azienda ha davvero concordato. Chiedete al fornitore di confermare quella combinazione esatta, non che il software giri in una macchina virtuale. Tenete visibili le dipendenze esterne, come un fornitore di identità o un servizio di licenza, perché fanno parte della distribuzione che siano fornite con essa o no. Una pagina di distribuzione senza dipendenze nominate è di solito una pagina di distribuzione con una dipendenza sconosciuta.
Dimostrate che il secondo fattore è un secondo fattore
Nominate l’autenticatore e il flusso di verifica, e dite quale identità stabilisce ogni passo. Due richieste di password di seguito non sono un secondo fattore, e una password più un codice monouso è un’affermazione diversa da quella di un autenticatore crittografico legato al servizio. Scrivete il flusso che comprate, non l’etichetta sulla scatola.
La resistenza al phishing è una proprietà separata, e la guida del NIST sugli autenticatori la tratta come tale: un codice che un utente può essere indotto a inoltrare soddisfa ancora l’autenticazione multifattore ma fallisce quella condizione aggiuntiva. Chiedete la proprietà esplicitamente se vi importa. Poi pretendete una dimostrazione dal tipo di client che i vostri utenti eseguono davvero, che copra la registrazione, una sfida rifiutata o scaduta, il recupero dopo la perdita dell’autenticatore e la revoca di un utente mentre gli altri restano connessi. Tenete la verifica dell’identità del gateway nell’ambito, perché un client che si fida di qualsiasi gateway ha spostato il problema invece di risolverlo.
Scrivete la condizione di superamento prima di rompere qualcosa
La tabella qui sotto è la parte del foglio che sopravvive al contatto con un fornitore, perché ogni riga chiede un artefatto invece di un’assicurazione. Riempite la condizione di superamento prima della prova, e trattate una riga senza prove come una riga fallita. Cinque fasi coprono ciò che un gateway deve fare.
| 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 |
La registrazione viene per prima perché tutto ciò che segue ne dipende: un dispositivo che non può registrarsi non può essere provato. L’accesso è una fase separata dalla registrazione, e il rifiuto è la fase che quasi tutti i fogli dimenticano, perché un gateway che ammette tutti non ha dimostrato di rifiutare qualcuno. Revoca e ripristino portano la maggior parte del rischio operativo, ed entrambi si provano a poco su una copia.
Esercitatevi sulla copia, non sul gateway in produzione
Eseguite le fasi di disturbo su una copia della piattaforma, seguendo la procedura di distribuzione supportata, e conservate ogni prova con la sua data e versione di configurazione. Una riga di riavvio non si risponde con un riavvio dalla console, e una riga di ripristino non si risponde esportando la configurazione. Annotate quale stato torna da solo e che cosa deve riconnettersi, perché è quella differenza che il team operativo eredita. La prova è anche l’unica occasione per cronometrare un ripristino senza spiegare un’interruzione.
Registrate lo stato del fornitore di identità nel momento di ogni test, perché una riga di interruzione provata contro un fornitore sano dimostra il contrario di ciò che il foglio afferma. Due revisori nella stessa prova colgono cose diverse, e il secondo di solito trova la riga la cui prova è uno screenshot di una dashboard. Tenete quella prova attaccata alla riga a cui appartiene, non in una cartella col nome del progetto.
Misurate il carico di lavoro che il vostro team eseguirà
Concordate un carico simile a una settimana normale, poi misuratelo dove pensate di distribuire: concorrenza, miscela di traffico e finestra di manutenzione che il team ha davvero. Una cifra di throughput pubblicizzata descrive una condizione di laboratorio e non dice nulla sui vostri utenti. Misurate il ripristino rispetto all’obiettivo di ripristino, non rispetto al piano.
Il foglio è finito quando ogni fase ha un artefatto e ogni artefatto ha una data. Un apparato che qualcuno mantiene, con prove per ogni riga, è un acquisto diverso dalla lista più lunga di caselle spuntate.