Праверкі прыёмкі віртуальнага VPN-шлюза з двухфактарнай аўтэнтыфікацыяй
Давядзіце шлюз па этапах: рэгістрацыя, уваход, адмова, адкліканне і аднаўленне — кожны з артэфактам і ўмовай праходжання, запісанай да тэсту.
Пастаўшчыкі апісваюць гэтую прыладу як віртуальную і здольную да двухфактарнай аўтэнтыфікацыі, і ніводнае з гэтых слоў не адказвае на пытанні, што вырашаюць куплю. Які вобраз гіпервізара падтрымліваецца, якія кліенты могуць зарэгістравацца, што насамрэч даказвае другі фактар і што адбываецца, калі пастаўшчык ідэнтычнасці выходзіць з ладу, — усё яшчэ адкрыта. Ператварыце гэта ў этапы прыёмкі, якія можна прагнаць на рэпетыцыі, і рашэнне перастане залежаць ад таго, наколькі пераканаўчы тэхнічны ліст. Аркуш ніжэй — гэта структура для такіх доказаў, а не рэйтынг прадуктаў.
Што пастаўшчык павінен пацвердзіць пра гэтае разгортванне
Пачніце з таго, каб сціснуць разгортванне да адной старонкі: гіпервізар або воблака, архітэктура гасцявой сістэмы, падтрыманы вобраз і інтэрфейсы, якія чакае прылада. Дадайце карыстальнікаў з іх аперацыйнымі сістэмамі, інфармацыю, ці кіруюцца прылады, і як павінны працаваць рэгістрацыя і ўваход. Затым прыватны доступ: праграмы і прэфіксы, арганізацыя DNS, зваротныя шляхі і ці ўваходзіць публічны выхад у інтэрнэт у прапанову.
Эксплуатацыя належыць на тую ж старонку: хто абслугоўвае скрыню, адкуль прыходзяць абнаўленні, куды ідуць журналы, як абараняецца канфігурацыя і якую мэту аднаўлення бізнес сапраўды ўзгадніў. Папрасіце пастаўшчыка пацвердзіць менавіта гэтую камбінацыю, а не тое, што праграма працуе ў віртуальнай машыне. Трымайце знешнія залежнасці, такія як пастаўшчык ідэнтычнасці або служба ліцэнзавання, бачнымі, бо яны частка разгортвання незалежна ад таго, ці пастаўляюцца яны разам з ім. Старонка разгортвання без названай залежнасці звычайна азначае старонку разгортвання з невядомай залежнасцю.
Давядзіце, што другі фактар — гэта другі фактар
Назвіце аўтэнтыфікатар і працэс праверкі і скажыце, якую ідэнтычнасць усталёўвае кожны крок. Два запыты пароля запар — не другі фактар, а пароль плюс аднаразовы код — гэта іншае сцвярджэнне, чым крыптаграфічны аўтэнтыфікатар, прывязаны да сэрвісу. Запішыце працэс, які вы купляеце, а не этыкетку на скрынцы.
Устойлівасць да фішынгу — асобная ўласцівасць, і кіраўніцтва NIST па аўтэнтыфікатарах разглядае яе менавіта так: код, які карыстальніка можна падмануць пераслаць, усё яшчэ задавальняе шматафактарную аўтэнтыфікацыю, але не выконвае гэтую дадатковую ўмову. Патрабуйце гэтую ўласцівасць яўна, калі яна для вас важная. Затым запатрабуйце дэманстрацыю з таго тыпу кліента, які вашыя карыстальнікі сапраўды выкарыстоўваюць, з ахопам рэгістрацыі, адхіленага або пратэрмінаванага выкліку, аднаўлення пасля страчанага аўтэнтыфікатара і адклікання аднаго карыстальніка, пакуль іншыя застаюцца падключанымі. Трымайце праверку ідэнтычнасці шлюза ў межах, бо кліент, які давярае любому шлюзу, перамясціў праблему, а не вырашыў яе.
Запішыце ўмову праходжання, перш чым нешта зламаць
Табліца ніжэй — гэта частка аркуша, якая вытрымлівае сутыкненне з пастаўшчыком, бо кожны радок патрабуе артэфакт замест гарантыі. Запоўніце ўмову праходжання да рэпетыцыі і лічыце радок без доказаў праваленым радком. Пяць этапаў ахопліваюць тое, што павінен рабіць шлюз.
| 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 |
Рэгістрацыя ідзе першай, бо ўсё далейшае ад яе залежыць: прыладу, якая не можа зарэгістравацца, нельга праверыць. Уваход — асобны этап ад рэгістрацыі, а адмова — этап, які большасць аркушаў забывае, бо шлюз, што пускае ўсіх, не даказаў, што камусьці адмаўляе. Адкліканне і аднаўленне нясуць большую частку эксплуатацыйнай рызыкі, і абодва танна рэпетаваць на копіі.
Рэпетуйце на копіі, а не на жывым шлюзе
Праводзьце разбуральныя этапы на копіі платформы, прытрымліваючыся падтрыманай працэдуры разгортвання, і захоўвайце кожны доказ з яго датай і версіяй канфігурацыі. Радок перазагрузкі не закрываецца перазапускам з кансолі, а радок аднаўлення — экспартам канфігурацыі. Заўважце, які стан вяртаецца сам і што мусіць перападключыцца, бо менавіта гэтая розніца дастаецца камандзе эксплуатацыі. Рэпетыцыя — таксама адзіны шанец замерыць аднаўленне, не тлумачачы збой.
Фіксуйце стан пастаўшчыка ідэнтычнасці ў момант кожнага тэсту, бо радок пра збой, правераны супраць здаровага пастаўшчыка, даказвае процілеглае таму, што сцвярджае аркуш. Два рэцэнзенты на адной рэпетыцыі ловяць рознае, і другі звычайна знаходзіць радок, чый доказ — здымак экрана панэлі кіравання. Трымайце гэты доказ прымацаваным да радка, якому ён належыць, а не ў папцы, названай у гонар праекта.
Змерце нагрузку, якую будзе выконваць ваша каманда
Узгадніце нагрузку, падобную на звычайны тыдзень, затым змерце яе там, дзе плануеце разгортваць: адначасовасць, сумесь трафіку і акно абслугоўвання, якое каманда сапраўды мае. Заяўленая лічба прапускной здольнасці апісвае лабараторную ўмову і нічога не кажа пра вашых карыстальнікаў. Змерце аднаўленне адносна мэты аднаўлення, а не адносна плана.
Аркуш скончаны, калі кожны этап мае артэфакт, а кожны артэфакт мае дату. Прылада, якую хтосьці абслугоўвае, з доказам на кожны радок — гэта іншая купля, чым найдаўжэйшы спіс адзначаных квадрацікаў.