Агульны CA, асобныя дзверы: адна служба на файл дапушчэння

Сертыфікат, які праходзіць праверку супраць агульнага ўпаўнаважанага органа, прайшоў выпрабаванне даверу, а не выпрабаванне членства. Гэтыя два рашэнні часта зліваюцца, бо абодва адбываюцца ў момант падключэння, і гэтае зліццё застаецца нябачным, пакуль у службу не дапускаюць таго, каму там быць не належыць. Выпраўленне — не другі ўпаўнаважаны орган; гэта другое рашэнне, прынятае для кожнай службы і запісанае там, дзе яго чытае дэман. Трымайце іх асобна — і большасць блытаніны ў гэтай сферы знікне.

Давераны ланцужок нічога не кажа пра членства ў службе

Дзве службы могуць прымаць адну і тую ж іерархію выпуску і мець розныя супольнасці. Адзін ноўтбук належыць першай і не павінен дасягаць другой, тады як іншыя кліенты той жа іерархіі сапраўды належаць туды. Выдаленне ўпаўнаважанага органа з гэтай службы заблакавала б усіх, хто законна ёй карыстаецца, таму работа — гэта дапушчэнне, а не давер.

Карысна ўявіць два замкі на адных дзвярах. Сертыфікат адкрывае знешні замак, а рашэнне для канкрэтнай службы адкрывае ўнутраны; ні адно не замяняе другое. Служба толькі са знешнім замком зусім не забяспечвае членства, яна толькі аўтэнтыфікуе. Запішыце абодва рашэнні, перш чым нешта змяняць, бо палітыку, якая існуе толькі ў выглядзе працоўнага злучэння, немагчыма прааўдзіраваць. Далей размова ідзе пра ўнутраны замак.

Ператварыце неабавязковыя пераазначэнні ў браму дапушчэння

Каталог канфігурацыі кліента звычайна зручнасць: файлы ў ім пераазначваюць налады для кліентаў, якіх яны называюць, а кліент без файла проста працуе з наладамі сервера па змаўчанні. Адна дырэктыва ператварае гэтую зручнасць у браму, так што адсутнасць файла азначае адмову ў злучэнні.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Супольнасная зборка OpenVPN 2.6 ccd-exclusive у сваёй старонцы дапаможніка апісвае менавіта гэтую ўмову, і пошук названага файла залежыць ад эфектыўнай ідэнтычнасці кліента. Іншыя зборкі і серверы, якімі кіруюць прадукты, могуць адрознівацца, таму пацвердзіце ўсталяваную версію, перш чым спадзявацца на тую ж семантыку ў іншым месцы.

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

Адзін каталог на службу, а не адзін агульны спіс

Членства належыць службе, якая яго забяспечвае, таму кожная служба трымае свой каталог і свае файлы. Навядзенне дзвюх службаў на адзін спіс прымушае іх дзяліць членства незалежна ад таго, ці хтосьці гэтага хацеў, і выніковую змену цяжка прывязаць да рашэння. Агульны ўпаўнаважаны орган можа заставацца агульным; файлы дапушчэння — не. Іх асобнасць азначае таксама, што памылка ў адной службе не можа моўчкі пашырыць другую.

Запіс DEFAULT — гэта выпадак, які ўводзіць людзей у зман. Ён дае запасныя налады, калі названы файл не знойдзены, але гэта не той названы файл, якога патрабуе брама, таму ён не можа дапусціць кліента сам па сабе. Праверце кліента, у якога няма зусім ніякага запісу, і пацвердзіце адмову; калі такі кліент дапушчаны, значыць прымяняецца запасны варыянт і ccd-exclusive у гэтым экземпляры не дзейнічае.

Эфектыўная ідэнтычнасць вызначае, які файл чытаецца

Пошук выкарыстоўвае ідэнтычнасць, пад якой кліент фактычна аўтэнтыфікаваўся, звычайна гэта агульнае імя сертыфіката. Калі сервер таксама правярае імя карыстальніка і пароль і адлюстроўвае гэтае імя ў агульнае імя, файл павінен адпавядаць менавіта аўтэнтыфікаванаму імені карыстальніка. Няўзгодненасць пакідае каталог, поўны праўдападобных імёнаў файлаў, якія ніколі не выбіраюцца.

Чытанне — другая палова. Дэман звычайна паніжае прывілеі пасля запуску, таму паменшанаму ўліковаму запісу патрэбны доступ на чытанне да каталога і кожнага запісу ў ім. Кліенты не павінны мець магчымасці ствараць уласны запіс праз любы шлях з запісам, бо самаабслугоўванне дапушчэння цалкам знішчае механізм. Праверце дазволы мантавання і агульнага доступу, а не толькі рэжым файла, бо каталог, які выглядае зачыненым для аднаго ўліковага запісу, можа быць адкрытым для іншага. Затым пацвердзіце, які ўліковы запіс насамрэч выкарыстоўвае працэс, а не які згадвае файл модуля. Гэтыя два супадаюць толькі тады, калі нішто іншае іх не змяніла.

Назірайце адмову, дапушчэнне і адкліканне асобна

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

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

Дапушчэнне — гэта таксама толькі першая брама. Далучэнне да службы нічога не кажа пра падсеткі, базы даных або інтэрфейсы кіравання за ёй, і палітыка гэтых рэсурсаў павінна быць напісана і пратэставана асобна.