Mažo biuro VPN: laikykite jį atokiau nuo domeno valdiklio

Trys sąlygos nusprendžia, ar vienintelis biuro Windows serveris turėtų ir užbaigti VPN: kiek internetui atgręžtos programinės įrangos esate pasirengę paleisti kataloge, ar galite autentifikuoti nuotolinius vartotojus be šio vaidmens, ir kas nutinka jūsų administravimo prieigai, kai hostas paleidžiamas iš naujo. Jei bent vienas iš trijų turi blogą atsakymą, atskirkite vaidmenis. Tai, kad biuras mažas, keičia biudžetą, o ne riziką.

Kiekviena domeno mašina pasitiki domeno valdikliu; VPN šliuzas pasiekiamas bet kam internete. Ši asimetrija yra visas argumentas.

Du darbai su dviem skirtingais ekspozicijos profiliais

Šliuzas priima jungtis iš išorės, todėl jo klausytojas, TLS stekas ir autentifikavimo paviršius visi pasiekiami iš nepatikimų tinklų. Katalogas turi valdžią, kuria pasitiki kitos mašinos, todėl Microsoft sukietinimo gairės domeno valdiklio vaidmenį ir jo prieglobos aplinką laiko ypač jautriais. Kiekviena šiame hoste pridėta paslauga paveldi katalogo pasitikėjimo padėtį ir prideda savo atakos paviršių. Diegimo patogumas nėra pasitikėjimo riba.

Vaidmenų atskyrimas nepašalina priklausomybių. Nuotoliniams vartotojams vis dar reikia autentifikavimo, maršrutų, DNS ir prieigos taisyklių, o šliuzas, kuris jų nepraleidžia, nėra saugesnis, tik mažiau naudingas.

Autentifikavimas be katalogo vaidmens

Šliuzas gali tikrinti kredencialus per palaikomą išorinę integraciją nepriglobdamas paties katalogo. Kad ir kokia būtų ši integracija, duokite jai paskyrą, kurios teisės atitinka tikslą: skaityti autentifikavimui reikalingus atributus, nieko daugiau. VPN vartotojų priėmimas niekada nereikalauja jų įprastų paskyrų paversti domeno administratoriais ir niekada nereikalauja, kad šliuzas laikytų katalogo kopiją.

Tada apribokite tinklo kelius, kurių nuotoliniam klientui iš tikrųjų reikia. Prieiga prie vienos vidinės failų paslaugos, kartu su vardų skyrimo ir tapatybės paslaugomis, nuo kurių priklauso šis darbo srautas, yra apibrėžtas kelių rinkinys. Tai nėra priežastis leisti kiekvieną domeno valdiklio portą ar kiekvieną administravimo sąsają iš VPN baseino.

Vienas hostas vis dar yra viena gedimo sritis

Du svečiai viename hipervizoriuje atskiria savo operacinės sistemos konfigūraciją ir neatskiria savo likimo. Hipervizoriaus administratoriai, virtualus perjungimas, saugykla ir atsarginės kopijos lieka dizaino dalimi, o hosto paleidimas iš naujo pašalina abi paslaugas vienu metu. Tai vadinti aukštu prieinamumu todėl, kad diagramoje matomi du VM, yra dažna ir brangi klaida. Jei vienintelis kelias atgal eina per to hosto VPN, gedimas atima ryšį, reikalingą jam sutaisyti.

Todėl suplanuokite nepriklausomą valdymo kelią, kuris nepriklauso nuo tunelio, ir užrašykite, kas lieka pasiekiama techninės priežiūros metu. Šliuzo atnaujinimus ir katalogo priežiūrą planuokite atskirai, pažymėdami, kuriuos vartotojus ar programas paliečia kiekvienas pertraukimas.

Techninės priežiūros langas, kuris reikalauja, kad VPN veiktų, norint sutaisyti VPN, nėra techninės priežiūros langas.

Perkelkite jį neužsirakindami

Jei vaidmenys jau dalijasi vienu diegimu, venkite paskubėtos nuotolinės migracijos. Sudarykite sąrašą, ką šliuzas šiandien turi: adresus, peradresavimo taisykles, NAT, DNS nustatymus, autentifikavimo konfigūraciją ir visas paskelbtas paslaugas. Paruoškite ir pakaitalą, ir kelią atgal prieš perkeldami klausytoją ar keisdami numatytąjį maršrutą. Tada išbandykite įprasto nuotolinio vartotojo tikrą darbą per naują ribą ir patvirtinkite, kad nereikalinga administravimo prieiga vis dar nepavyksta.

Tikslas nėra gražesnė diagrama. Tai gebėjimas sutaisyti ar atstatyti VPN neliečiant dėžės, kuri inkaruoja katalogo pasitikėjimą visam biurui. Tai skirtingi tikslai, ir tik vienam jų reikia antro serverio.

Užrašykite sprendimą bet kuriuo atveju, įskaitant sąlygas, kurios jį vėl atvertų. Mažas biuras auga, o atsakymas, tikęs vienam serveriui, gali netikti kitam.