Цэнтралізацыя доступу партнёраў праз VPN без аб’яднання партнёраў

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

Пачніце з дамовы, якую кожны партнёр ужо падпісаў

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

Гэты запіс і ёсць вынік. Калі вы не можаце напісаць яго для аднаго партнёра, гэты партнёр не гатовы да цэнтралізацыі.

Маршрутызуйце па кантэксце, а не толькі па прызначэнні

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

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

Там, дзе адказ так, кантэкст маршрутызацыі становіцца тым, што вы дакументуеце і тэстуеце, бо ён нябачны ў traceroute.

Вырашыце, што ўводзіць супрацоўнік і што запісвае партнёр

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

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

Забараніце транзіт паміж партнёрамі яўна

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

Запішыце забарону ў запіс партнёра побач з дазволамі, каб намера перажыла змены персаналу.

Запусціце гэта як агульны сэрвіс, а не як большы ноўтбук

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

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

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