Дві перевірки входу — не два фактори: VPN і RADIUS

Додавання другого бекенду автентифікації до VPN-шлюзу виглядає як додавання другого фактора. Зазвичай воно додає другу перевірку, інший об’єкт з іншими режимами відмови. Чи мають обидві завершитися успішно, що кожна доводить і що відбувається, коли одна недоступна, це три окремі рішення. Помилитеся, і шлюз буде суворішим у демонстрації та слабшим під час збою.

Що насправді доводить другий бекенд

Пошук у локальному обліковому записі доводить, що ім’я існує в базі даних і що пароль до нього підійшов. Обмін RADIUS доводить, що сервер RADIUS повернув Access-Accept для отриманих атрибутів. Жодне з тверджень не згадує тип фактора, бо обидві перевіряють знання. А настанова NIST щодо цифрової ідентичності рахує різні типи факторів та їхні автентифікатори, а не сервери чи запити.

Існує законний дизайн, у якому беруть участь обидві системи. Центральна служба може автентифікувати людину, тоді як шлюз незалежно перевіряє, чи має цей обліковий запис право на цей тунель. Це авторизація поряд з автентифікацією, і називати це двофакторним означає плутати перевірку політики з доказом володіння.

RADIUS може нести справжній другий фактор, коли стоїть перед чимось, що перевіряє один, наприклад push-підтвердженням або апаратним токеном. Конверт не повідомляє, які автентифікатори пред’явив користувач, тому читайте політику бекенду, а не ярлик шлюзу.

AND, OR і резервна — різні продукти

Перш ніж порівнювати реалізації, вирішіть, що означає обидві у вашій вимозі. Політика AND вимагає проходження кожної названої перевірки, політика OR приймає будь-яку успішну, а резервна пробує другу лише за зазначених умов відмови. Ці три поводяться протилежно під час збою, і зазвичай лише одна з них — те, що мав на увазі огляд.

Додавання двох записів бекенду на екран конфігурації не розкриває, яку політику реалізує продукт. Деякі шлюзи з’єднують плагіни по порядку і зупиняються на першій відмові, що є AND лише тоді, коли кожен плагін обов’язковий. Інші вважають локальний обліковий запис перевизначенням, що перетворює центральний збій на обхід. Надійна відповідь — задокументований негативний тест для кожного шляху, виконаний на тій збірці, яку ви розгортаєте.

Резервна заслуговує найбільшої недовіри, бо існує, щоб продовжувати працювати, коли щось зламано. Резервна, що приймає локальний пароль щоразу, коли RADIUS недоступний, перетворила центральну політику на другі, слабші двері.

Подвійна перевірка OpenVPN — конкретний випадок

Спільний OpenVPN 2.6 вимагає і клієнтський сертифікат, і налаштований скрипт auth-user-pass-verify, коли ввімкнено обидва. Це задокументований AND між перевіркою сертифіката та скриптом облікових даних, і це справді дві перевірки. Це все ще не автоматично два типи факторів, оскільки скрипт може перевіряти лише пароль.

Комбінація також залишає відкритим питання зіставлення. Сертифікат зазвичай ідентифікує пристрій, а облікові дані — людину, і ніщо в типовому потоці не вимагає, щоб обидва стосувалися одного суб’єкта. Вирішіть, які пари дозволені, потім реалізуйте це зіставлення в скрипті перевірки або на пізнішому етапі авторизації.

Режим лише сертифіката — це одна перевірка, що спирається на ключ, який може бути або не бути захищений PIN. PIN перетворює ті самі облікові дані на знання плюс володіння лише якщо ключ не можна використовувати без нього. Залишення ключа незашифрованим на диску зводить другу частину до прав на файл.

Виробники пристроїв будують власну обв’язку, часто модуль PAM або плагін RADIUS за веб-консоллю. Поведінка спільноти — це орієнтир того, як виглядають подвійні перевірки, а не опис того, як пристрій їх поєднує.

Перевірте комбінацію на своєму шлюзі

Прочитайте конфігурацію, перш ніж довіряти підсумку консолі. Рядки, що визначають політику, це режим сертифіката, скрипт облікових даних і порядок плагінів.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep показує, чи потрібен сертифікат і який скрипт виконується після нього, і порядок важливіший, ніж підказують назви. Дамп сертифіката дає ідентичність, яку побачить шлюз, включно з CN і серійним номером, потрібними для карти зіставлення. Тест RADIUS — негативний випадок: неправильний пароль має дати Access-Reject, а правильний Access-Accept. Якщо відхилені облікові дані все ж дають сеанс, скрипт взагалі не на шляху автентифікації.

Потім запустіть випадок збою на лабораторному екземплярі: зупиніть обов’язковий бекенд і підключіться з чинними обліковими даними. Очікуваний результат — відмова, а все інше — це резервна політика, яку ніхто не задокументував.

Запишіть вимогу як негативні випадки

Придатна вимога називає докази, облікові записи, яким дозволено їх подавати, і результат, коли бракує перевіряча. Вона також зазначає дозволене зіставлення між ідентичністю пристрою та ідентичністю людини. Це точніше, ніж назви продуктів у замовленні, і це можна перевірити.

Приймання має включати чотири відмови: непідхожий локальний обліковий запис, відсутній обов’язковий доказ, недійсний другий фактор і недоступний обов’язковий бекенд. Кожній відмові потрібен рядок журналу, що відрізняє її від інших, інакше наступний інцидент починається зі здогадів. Записуйте, який компонент ухвалив кожне рішення, оскільки шлюз, сервер RADIUS і каталог звинувачуватимуть одне одного.

Повторюйте чотири відмови після будь-якої зміни плагіна або прошивки. Вони дешеві, і політика, яку вони захищають, це та частина, яку зловмисник перевіряє першою.