VPN для малога офіса: трымайце яго асобна ад кантролера дамена

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

Кантролеру дамена давярае кожная машына ў дамене; шлюз VPN даступны любому ў інтэрнэце. Гэтая асіметрыя і ёсць увесь аргумент.

Дзве працы з двума рознымі профілямі ўздзеяння

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

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

Аўтэнтыфікацыя без ролі каталога

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

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

Адзін хост — па-ранейшаму адзін домен адмоваў

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

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

Акно абслугоўвання, якое патрабуе, каб VPN працаваў, каб выправіць VPN, — не акно абслугоўвання.

Перанясіце яго, не замкнуўшы сябе звонку

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

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

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