Две проверки при вход не са два фактора: 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 сървърът и директорията ще обвиняват другите двама.

Пуснете отново четирите отказа след всяка промяна на плъгин или фърмуер. Те са евтини, а политиката, която защитават, е частта, която нападателят проверява първа.