Contrôles d’acceptation pour une passerelle VPN virtuelle avec authentification à deux facteurs
Prouvez la passerelle étape par étape : enrôlement, connexion, refus, révocation et restauration, chacune avec un artefact et une condition de réussite écrite avant le test.
Les fournisseurs décrivent cette appliance comme virtuelle et compatible deux facteurs, et aucun des deux mots ne répond aux questions qui décident de l’achat. Quelle image d’hyperviseur est prise en charge, quels clients peuvent s’enrôler, ce que le second facteur prouve réellement et ce qui se passe quand le fournisseur d’identité tombe restent ouverts. Transformez-les en étapes d’acceptation que vous pouvez exécuter en répétition, et la décision cesse de dépendre du pouvoir de persuasion de la fiche technique. La feuille ci-dessous est une structure pour ces preuves, pas un classement de produits.
Ce que le fournisseur doit confirmer sur ce déploiement
Commencez par tenir le déploiement sur une page : l’hyperviseur ou le cloud, l’architecture invitée, l’image prise en charge et les interfaces attendues par l’appliance. Ajoutez les utilisateurs, avec leurs systèmes d’exploitation, si les appareils sont gérés et comment l’enrôlement et la connexion sont censés fonctionner. Puis l’accès privé : applications et préfixes, organisation du DNS, chemins de retour, et si une sortie Internet publique fait partie de l’offre.
L’exploitation appartient à la même page : qui maintient la boîte, d’où viennent les mises à jour, où vont les journaux, comment la configuration est protégée et quel objectif de restauration l’entreprise a réellement accepté. Demandez au fournisseur de confirmer cette combinaison exacte, et non que le logiciel tourne dans une machine virtuelle. Gardez visibles les dépendances externes, comme un fournisseur d’identité ou un service de licence, car elles font partie du déploiement qu’elles soient livrées avec lui ou non. Une page de déploiement sans dépendance nommée est généralement une page de déploiement avec une dépendance inconnue.
Prouvez que le second facteur est un second facteur
Nommez l’authentificateur et le flux de vérification, et dites quelle identité chaque étape établit. Deux demandes de mot de passe successives ne sont pas un second facteur, et un mot de passe plus un code à usage unique est une affirmation différente d’un authentificateur cryptographique lié au service. Écrivez le flux que vous achetez, pas l’étiquette sur la boîte.
La résistance au hameçonnage est une propriété distincte, et le guide du NIST sur les authentificateurs la traite comme telle : un code qu’un utilisateur peut être amené à relayer satisfait encore l’authentification multifacteur tout en échouant à cette condition supplémentaire. Exigez la propriété explicitement si elle compte pour vous. Exigez ensuite une démonstration sur le type de client que vos utilisateurs font réellement tourner, couvrant l’enrôlement, un défi rejeté ou expiré, la récupération après perte d’authentificateur et la révocation d’un utilisateur pendant que les autres restent connectés. Gardez la vérification de l’identité de la passerelle dans le périmètre, car un client qui fait confiance à n’importe quelle passerelle a déplacé le problème au lieu de le résoudre.
Écrivez la condition de réussite avant de casser quoi que ce soit
Le tableau ci-dessous est la partie de la feuille qui survit au contact d’un fournisseur, car chaque ligne demande un artefact plutôt qu’une assurance. Remplissez la condition de réussite avant la répétition, et traitez une ligne sans preuve comme une ligne échouée. Cinq étapes couvrent ce qu’une passerelle doit faire.
| 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 |
L’enrôlement vient en premier parce que tout ce qui suit en dépend : un appareil qui ne peut pas s’enrôler ne peut pas être testé. La connexion est une étape distincte de l’enrôlement, et le refus est l’étape que la plupart des feuilles oublient, car une passerelle qui admet tout le monde n’a pas démontré qu’elle refuse qui que ce soit. La révocation et la restauration portent l’essentiel du risque opérationnel, et les deux se répètent à peu de frais sur une copie.
Répétez sur la copie, pas sur la passerelle en production
Exécutez les étapes perturbatrices sur une copie de la plateforme, en suivant la procédure de déploiement prise en charge, et conservez chaque preuve avec sa date et sa version de configuration. Une ligne de redémarrage ne se répond pas par un redémarrage depuis la console, et une ligne de restauration ne se répond pas en exportant la configuration. Notez quel état revient de lui-même et ce qui doit se reconnecter, car c’est cette différence que l’équipe d’exploitation hérite. La répétition est aussi la seule occasion de chronométrer une restauration sans avoir à expliquer une panne.
Enregistrez l’état du fournisseur d’identité au moment de chaque test, car une ligne de panne testée contre un fournisseur sain prouve le contraire de ce que la feuille affirme. Deux relecteurs sur la même répétition attrapent des choses différentes, et le second trouve généralement la ligne dont la preuve est une capture d’écran d’un tableau de bord. Gardez cette preuve attachée à la ligne à laquelle elle appartient, pas dans un dossier au nom du projet.
Mesurez la charge de travail que votre équipe fera tourner
Convenez d’une charge proche d’une semaine normale, puis mesurez-la là où vous comptez déployer : concurrence, mélange de trafic et fenêtre de maintenance dont l’équipe dispose réellement. Un chiffre de débit annoncé décrit une condition de laboratoire et ne dit rien de vos utilisateurs. Mesurez la restauration par rapport à l’objectif de restauration, et non par rapport au plan.
La feuille est terminée quand chaque étape a un artefact et chaque artefact a une date. Une appliance que quelqu’un maintient, avec une preuve pour chaque ligne, est un autre achat que la plus longue liste de cases cochées.