Akceptaj kontroloj por virtuala VPN-pordego kun dufaktora identigo
Pruvu la pordegon stadion post stadio: aliĝo, ensaluto, malakcepto, revoko kaj restarigo, ĉiu kun artefakto kaj trapasa kondiĉo skribita antaŭ la testado.
Vendistoj priskribas ĉi tiun aparaton kiel virtuala kaj kapabla je du faktoroj, kaj neniu el la du vortoj respondas la demandojn, kiuj decidas la aĉeton. Kiun hipervizilan bildon oni subtenas, kiuj klientoj povas aliĝi, kion la dua faktoro efektive pruvas, kaj kio okazas kiam la identiga provizanto paneas, restas malfermitaj. Turnu tiujn en akceptajn stadiojn, kiujn vi povas ruli en provludo, kaj la decido ĉesos dependi de tio, kiom konvinka estas la datumfolio. La folio malsupre estas strukturo por tiaj pruvoj, ne rangigo de produktoj.
Kion la provizanto devas konfirmi pri ĉi tiu deplojo
Komencu per tio, ke vi kunpremos la deplojon sur unu paĝon: la hipervizilo aŭ nubo, la gastigita arkitekturo, la subtenata bildo kaj la interfacoj, kiujn la aparato atendas. Aldonu la uzantojn kun iliaj operaciumoj, ĉu la aparatoj estas administrataj, kaj kiel aliĝo kaj ensaluto devas funkcii. Poste la privata aliro: aplikaĵoj kaj prefiksoj, DNS-aranĝo, revenaj vojoj, kaj ĉu publika interreta eliro estas parto de la oferto.
Operacioj apartenas al la sama paĝo: kiu prizorgas la skatolon, de kie venas ĝisdatigoj, kien iras protokoloj, kiel la agordo estas protektata, kaj kiun restarigan celon la entrepreno efektive interkonsentis. Petu de la provizanto konfirmi ĝuste tiun kombinon, ne ke la programaro ruliĝas en virtuala maŝino. Tenu videblaj eksterajn dependecojn kiel identigan provizanton aŭ licencan servon, ĉar ili estas parto de la deplojo sendepende de tio, ĉu ili estas liverataj kun ĝi. Deploja paĝo sen nomita dependeco kutime estas deploja paĝo kun nekonata dependeco.
Pruvu, ke la dua faktoro estas dua faktoro
Nomu la identigilon kaj la kontrolan fluon, kaj diru, kiun identecon ĉiu paŝo starigas. Du sinsekvaj pasvortaj petoj ne estas dua faktoro, kaj pasvorto plus unufoja kodo estas malsama aserto ol kriptografia identigilo ligita al la servo. Skribu la fluon, kiun vi aĉetas, ne la etikedon sur la skatolo.
Rezisto al fiŝado estas aparta eco, kaj la NIST-gvidilo pri identigiloj traktas ĝin ĝuste tiel: kodo, kiun uzanto povas esti trompita plusendi, ankoraŭ plenumas plurfaktoran identigon dum ĝi malsukcesas tiun pliun kondiĉon. Postulu la econ eksplicite, se ĝi gravas por vi. Poste postulu demonstron el la klienta tipo, kiun viaj uzantoj efektive uzas, kovrante aliĝon, malakceptitan aŭ eksvalidiĝintan defion, restarigon post perdita identigilo, kaj revokon de unu uzanto dum la aliaj restas konektitaj. Tenu la identeckontrolon de la pordego en la amplekso, ĉar kliento, kiu fidas ajnan pordegon, movis la problemon anstataŭ solvi ĝin.
Skribu la trapassan kondiĉon antaŭ ol vi rompos ion
La tabelo malsupre estas la parto de la folio, kiu postvivas kontakton kun provizanto, ĉar ĉiu vico petas artefakton anstataŭ certigon. Plenigu la trapassan kondiĉon antaŭ la provludo, kaj traktu vicon sen pruvo kiel malsukcesan vicon. Kvin stadioj kovras tion, kion pordego devas fari.
| 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 |
Aliĝo venas unue, ĉar ĉio malsupra dependas de ĝi: aparato, kiu ne povas aliĝi, ne povas esti testata. Ensaluto estas aparta stadio de aliĝo, kaj malakcepto estas la stadio, kiun plej multaj folioj forgesas, ĉar pordego, kiu enlasas ĉiujn, ne pruvis, ke ĝi malakceptas iun. Revoko kaj restarigo portas la plej grandan parton de la operacia risko, kaj ambaŭ estas malmultekoste provludeblaj sur kopio.
Provludu sur la kopio, ne sur la viva pordego
Rulu la perturbajn stadiojn sur kopio de la platformo, sekvante la subtenatan deplojan proceduron, kaj konservu ĉiun pruvon kun ĝia dato kaj agorda versio. Vico pri restartigo ne estas respondata per restartigo el la konzolo, kaj vico pri restarigo ne estas respondata per eksporto de la agordo. Notu, kiu stato revenas memstare kaj kio devas rekonektiĝi, ĉar ĝuste tiu diferenco estas tio, kion heredas la operacia teamo. La provludo ankaŭ estas la sola ŝanco mezuri restarigon sen klarigi paneon.
Registru la staton de la identiga provizanto en la momento de ĉiu testado, ĉar panea vico testita kontraŭ sana provizanto pruvas la malon de tio, kion la folio asertas. Du reviziantoj en la sama provludo kaptas malsamajn aferojn, kaj la dua kutime trovas la vicon, kies pruvo estas ekrankopio de panelo. Tenu tiun pruvon alkroĉitan al la vico, al kiu ĝi apartenas, ne en dosierujo nomita laŭ la projekto.
Mezuru la laborŝarĝon, kiun via teamo rulos
Interkonsentu laborŝarĝon similan al normala semajno, poste mezuru ĝin tie, kie vi intencas deploji: samtempeco, trafika miksaĵo, kaj la prizorga fenestro, kiun la teamo efektive havas. Anoncita trafluo-cifero priskribas laboratorian kondiĉon kaj diras nenion pri viaj uzantoj. Mezuru la restarigon kontraŭ la restariga celo, ne kontraŭ la plano.
La folio estas finita, kiam ĉiu stadio havas artefakton kaj ĉiu artefakto havas daton. Aparato, kiun iu prizorgas, kun pruvo por ĉiu vico, estas malsama aĉeto ol la plej longa listo de markitaj skatoloj.