Дзве праверкі ўваходу — не два фактары: 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 і каталог будуць вінаваціць адзін аднаго.

Паўтарыце чатыры адмовы пасля любога змянення плагіна або прашыўкі. Яны танныя, а палітыка, якую яны абараняюць, — гэта тое, што зламыснік правярае першым.