VPN пристап со сервисна сметка: сертификат или споделено најавување

Два дизајна покриваат речиси секое ненадгледано VPN поставување: споделено човечко најавување чувано во скрипта или сертификат на машина врзан за домаќинот. Тие паѓаат на различни места, што е поважно од брзината на поставување. Зачуваната лозинка се крши кога сопственикот ќе ја смени или ќе замине; сертификатот се крши кога ќе истече или кога домаќинот се преизградува без клучот. Три услови одлучуваат кој трошок можете да го поднесете, и ниту еден дизајн не ограничува ништо додека тоа не го направи политиката за авторизација.

Започнете од задачата, а не од сметката

Задачата ја дефинира границата: кои одредишта, кои услуги, кои часови, колку долго смее да трае сесијата. Рутата на тунелот е само половина од таа граница. Портата одлучува дали сесијата е дозволена; ресурсот зад неа одлучува што смее сесијата. Прво запишете ја листата, со именуван сопственик, бидејќи двата дизајна на идентитет мора да ја задоволат.

Држете ги автентикацијата и авторизацијата одвоени додека го пишувате тоа. Автентикацијата одговара кој се поврзува; авторизацијата одговара до што смее да стигне сесијата потоа. RADIUS го носи вториот дел како атрибути како Filter-Id, Framed-IP-Address, Session-Timeout и Class, и портата ги прикачува откако најавувањето ќе успее. Дизајн што го заменува најавувањето и ја остава авторизацијата недопрена не ограничил ништо.

Споделено човечко најавување: лозинката станува граница

Повторната употреба на човечка сметка е најбрзиот пат и оној што најлошо старее. Акредитивот е лозинка, па завршува во скрипта, датотека со околина и конфигурација на планер, и секое копие бара ротација. Кога сопственикот ќе ја смени во петок, задачата паѓа при следното извршување и никој не гледа.

MFA е местото каде овој дизајн обично се распаѓа. Скриптата не може да одговори на push барање, па сметката се исклучува од политиката, и тоа е токму сметката што би ја избрал напаѓач. Исклучоците, заобиколувањето на доверлива локација и изземањата по сметка се множат, и ниту едно не е видливо за следниот човек што ги чита поставките на закупецот.

Припишувањето е другиот трошок. Секоја сесија во дневникот на портата го носи истото корисничко име, па ноќната синхронизација не може да се разликува од работата на човекот што ја напишал, и отповикувањето на задачата значи отповикување на тој човек.

Сертификат на машина: идентитет врзан за домаќинот

Сертификатот го менува прашањето од тоа што го знае сметката во тоа што е домаќинот. Со EAP-TLS клиентот приложува сертификат и докажува поседување на соодветниот приватен клуч; серверот за политики го мапира субјектот или компјутерската сметка на група и ја применува политиката за таа група. Без барање, без споделена тајна што седи во текстуална датотека.

Границата што ја создава е потесна отколку што луѓето очекуваат. Сертификатот го автентицира домаќинот, а не задачата, и секој со root или локални администраторски права може да го користи тој клуч на тој домаќин. Чувајте го клучот таму каде платформата го штити: не може да се извезе во складиштето на сертификати на Windows, поддржан од TPM каде профилот дозволува, или датотека 0600 во сопственост на root на Linux. Компромитирањето на домаќинот е компромитирање на акредитивот.

Истекувањето е повторливата грешка. Сертификат што истекува во недела ја запира задачата во недела, и портата обично пријавува општ неуспех на автентикација наместо да го наведе датумот. Проверете ги датумите од домаќинот на задачата како дел од runbook:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

Отповикувањето бара пат што портата го проверува. OpenVPN чита CRL преку опцијата crl-verify, а strongSwan зависи од CRL или OCSP според тоа како е изграден профилот на врската. Ако ниту едно не е поврзано, отстранувањето на домаќин значи чекање сертификатот да истече.

Три услови што одлучуваат меѓу нив

Споредете со платформата што ја имате, а не со референтен дизајн.

Прв услов: може ли портата да авторизира идентитет на машина? Ако само мапира корисничко име од RADIUS на корисник во директориумот, сертификатот го автентицира домаќинот и потоа застанува при авторизацијата. Втор услов: и треба ли на задачата пристап до ресурс што го носи само корисничка сметка, како мапирано споделување или лиценца по седиште? Тогаш идентитет на машина не може да го замени, и чесниот одговор е посветена корисничка сметка со ограничена политика. Трет услов: кој може да го ротира акредитивот без човек во циклусот? Автоматското запишување ги прави сертификатите евтини за одржување; лозинка што ја знае еден човек не е.

Читајте ја табелата како список на трошоци, а не како рангирање. Колоната со зачувана тајна победува во брзината на отповикување и во компатибилноста со ресурси што разбираат само кориснички сметки; колоната со сертификат победува во ротацијата и во тоа што не го ослабува MFA за да работи скрипта.

Ставете ја границата во политиката, по автентикацијата

Каков идентитет и да изберете, границата на дозволи припаѓа на политиката што се извршува по автентикацијата. Во NPS мрежните политики се оценуваат по ред и првата политика што се совпаѓа со секој услов ги применува своите поставки, па широка политика поставена над тесна го одредува резултатот без оглед што приложува клиентот. Microsoft го документира моделот на услови и поставки во својот преглед на NPS политики.

Дајте ѝ на задачата сопствена група или услов на политика, заснован на нешто што го носи идентитетот на машината: шаблон за сертификат, идентификатор на станицата што повикува или адреса од посветен базен. Потоа ограничете ја сесијата со атрибути: Filter-Id за улогата во која вашата порта го мапира, краток Session-Timeout за да се реаавтентицира заглавената задача наместо да држи сесија со денови, и Framed-IP-Address од базен на кој од другата страна применувате огнено ѕид. Авторизацијата на апликациите останува одделна: тунел до сервер за бази на податоци не е дозвола да се чита табела во него.

Проверете ги одбивањата, потоа планирајте отстранување

Пристапот што работи не докажува ништо за најмалите привилегии. Наместо тоа тестирајте ги одбивањата: поврзете се со идентитетот на задачата и посегнете кон одредиште надвор од листата, отворете втора паралелна сесија ако портата треба да дозволи само една, и повторете го најавувањето откако ќе го отповикате акредитивот.

Потоа потврдете ја истата сесија на две места. Дневникот на портата го покажува идентитетот што се автентицирал; дневникот на серверот за политики покажува која политика се совпаднала и кои атрибути ги вратила. На OpenVPN серверот го запишува заедничкото име на сертификатот, а ipsec statusall на strongSwan го печати воспоставениот тунел со идентитетот што се користи. Ако двата дневника не се согласуваат за идентитетот, политиката се совпаѓа со нешто друго од она што го претпоставувате.

Отстранувањето е дел од дизајнот, а не спринт за чистење. Запишете се што треба да се избрише (сертификат или сметка, членство во група, мрежна политика, запис во базен, правило за огнено ѕид на целта) и извршете го еднаш додека задачата е лесно да се преизгради.

Ако почнувате денес, работете по овој редослед: напишете ја листата ресурси, изберете го идентитетот со трите услови, ставете ја границата во политиката и вежбајте едно одбивање пред задачата да пушти во работа.