Приймальні перевірки віртуального 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 |
Реєстрація йде першою, бо все подальше залежить від неї: пристрій, який не може зареєструватися, не можна перевірити. Вхід — окремий етап від реєстрації, а відмова — етап, який забуває більшість листів, бо шлюз, що пускає всіх, не довів, що комусь відмовляє. Відкликання й відновлення несуть більшу частину експлуатаційного ризику, і обидва дешево відпрацьовуються на копії.
Репетируйте на копії, а не на живому шлюзі
Проводьте руйнівні етапи на копії платформи, дотримуючись підтримуваної процедури розгортання, і зберігайте кожен доказ з його датою та версією конфігурації. Рядок про перезавантаження не закривається перезавантаженням із консолі, а рядок про відновлення — експортом конфігурації. Позначте, який стан повертається сам і що треба підключати заново, бо саме цю різницю успадковує експлуатаційна команда. Репетиція — ще й єдиний шанс заміряти відновлення, не пояснюючи збій.
Записуйте стан постачальника ідентичності в момент кожного тесту, бо рядок про збій, перевірений проти здорового постачальника, доводить протилежне тому, що стверджує лист. Два рецензенти на одній репетиції ловлять різне, і другий зазвичай знаходить рядок, доказом якого є знімок екрана панелі. Тримайте цей доказ прикріпленим до рядка, якому він належить, а не в теці з назвою проєкту.
Виміряйте навантаження, яке виконуватиме ваша команда
Домовтеся про навантаження, схоже на звичайний тиждень, і виміряйте його там, де збираєтеся розгортати: паралельність, склад трафіку й вікно обслуговування, яке команда справді має. Рекламована цифра пропускної здатності описує лабораторну умову й нічого не каже про ваших користувачів. Вимірюйте відновлення щодо мети відновлення, а не щодо плану.
Лист завершено, коли кожен етап має артефакт, а кожен артефакт має дату. Пристрій, який хтось обслуговує, з доказом для кожного рядка, — інша покупка, ніж найдовший список позначених галочками пунктів.