Централизирајте го пристапот на партнерите до VPN без да ги споите партнерите

Предлогот е разумен: пет партнерски тунели расфрлани низ десетина преносни сметачи, пет групи клиентски верзии, пет скрипти за поддршка и еден инженер што знае како се вклопуваат. Нивното преместување на контролирано ниво за пристап ја решава расфрланоста на крајните точки. Истовремено создава нов објект во архитектурата — заедничка услуга за пристап што сега бара свој модел на авторизација; а неуспехот што сите го потценуваат е централен апарат со вклучени сите тунели што тивко станува транзитна мрежа меѓу организации што никогаш не се согласиле да бидат соседи. Тој ризик е дизајнерска одлука, а не нешто што хардверот го прави сам. Работата подолу е начинот на кој ја задржувам удобноста без да го прифатам случајниот несакан ефект.

Започнете од договорот што секој партнер веќе го потпишал

Пред каква било конфигурација, потврдете дека партнерот воопшто дозволува заедничка порта или поврзување на локација. Лична сметка за оддалечен пристап, барање за состојба на уред или интерактивен MFA-тек може да не бидат преносливи на ненадгледуван заеднички тунел, а групирањето вработени зад еден копиран клиентски идентитет е вид кратенка што опстојува сè додека партнерот не ги ревидира своите дневници. За секое дозволено поврзување запишете ги опсезите на дестинација, приватните DNS домени, овластените внатрешни извори, сопственикот на автентикацијата и што треба да се случи кога тунелот ќе откаже. Побарајте од партнерот писмено да го потврди заедничкото поврзување, вклучително и изворните опсези што ќе ги прифати. Усното одобрување обично го менува значењето во неделата кога се менува нивниот безбедносен тим.

Тој запис е резултатот. Ако не можете да го напишете за еден партнер, тој партнер не е подготвен за централизација.

Рутирајте според контекст, а не само според дестинација

Два партнера на крајот ќе го користат истиот приватен опсег, бидејќи секоја организација избира од истиот простор RFC 1918. Една обична рутирачка табела не може да го избере вистинскиот партнер само врз основа на адресата на дестинацијата, па опсезите што се преклопуваат бараат одделни рутирачки контексти или друг договорен дизајн. Моделот на домен за проследување во RFC 4364 опишува зошто ова одделување е важно, а распоредувањето не мора да работи MPLS за да бара истото својство од својата портална платформа.

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

Каде одговорот е да, рутирачкиот контекст станува она што го документирате и тестирате, бидејќи тој е невидлив во traceroute.

Одлучете што внесува вработениот и што запишува партнерот

Дел од партнерската работа одговара на апликациски посредник или оддалечен работен простор отворен во контекстот на тој партнер. Друга работа бара рутиран мрежен пристап од одобрен сегмент на вработени, а двете создаваат различни изворни адреси и различни траги за ревизија на далечниот крај. Заедничка преведена изворна адреса може да задоволи список за одобрување, а притоа да крие кој уред што направил, затоа сочувајте сигурен запис за врската вработен–сесија и задржете ја автентикацијата на апликацијата наместо да ја третирате порталната адреса како идентитет — што е удобно сè до моментот кога партнерот ќе праша кој го направил тоа.

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

Изречно забранете транзит меѓу партнери

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

Запишете ја забраната во записот за партнерот до дозволите, за да ја надживее намерата промената на персоналот.

Водете го како заедничка услуга, а не како поголем преносен сметач

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

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

Држете мала табела со партнер, контекст, дозволени опсези и сопственик. Тоа ќе биде првото нешто што некој ќе го побара за време на инцидент.