Dvi VPN vartai iš eilės: ką kiekvieni iš tikrųjų nusprendžia
Dvi VPN pakopos iš eilės turėtų reikšti du atskirus leidimo sprendimus. Įvardykite, ką tikrina kiekvieni vartai, tada patikrinkite, ko atsisako vidiniai.
Dviejų VPN sujungimas grandine paprastai parduodamas kaip papildomas šifravimas, tačiau tai yra mažiausiai įdomus jo veiksmas. Tikrasis produktas yra antrasis autorizacijos sprendimas, kurį priima kitas savininkas dėl kito išteklių rinkinio. Jei abi pakopos priima tuos pačius prisijungimo duomenis ir pasiekia tuos pačius tikslus, vidiniai vartai yra papuošimas su papildomu vėlavimu. Sprendimas, ar tas antrasis sprendimas vertas savo veiklos sąnaudų, prasideda įvardijant, ką kiekvieni vartai iš tikrųjų tikrina.
Vienas tunelis, tada antras sprendimas
Išoriniai vartai atsako į platų klausimą: ar tai patvirtintas darbuotojo įrenginys ir ar jam leidžiama pasiekti bendrą vidinį tinklą. Vidiniai vartai atsako į siauresnį: ar ši tapatybė turi priežiūros teisę ir ar jai leidžiama pasiekti šiuos konkrečius valdymo galinius taškus. Tai skirtingi klausimai su skirtingais savininkais, ir nė vienas neimplikuoja kito. Maršruto per abi pakopas egzistavimas nėra įgaliojimas naudoti tai, kas yra už antrųjų. Pasiekti tolimą įėjimą įrodo, kad maršrutas veikia, ir nieko daugiau.
Principas senas ir vis dar ignoruojamas: tinklo vieta pati savaime nieko neargumentuoja. NIST nulinio pasitikėjimo architektūros santrauka tai sako aiškiai, atmesdama numanomą pasitikėjimą, kylantį iš to, iš kur atėjo ryšys ar kas valdo tinklą. Pritaikyta čia, atvykimas prie vidinio įėjimo yra jo išteklių išankstinė sąlyga, niekada ne leidimas jais naudotis.
Užrašykite, ką tikrina kiekvieni vartai
Kiekvienai pakopai užrašykite tapatybę, kurią ji tikrina, tikslus, kuriuos leidžia, ir sąlygas, kuriomis ją galima praleisti. Išoriniai vartai gali teisėtai leisti įprastas vidines paslaugas ir vidinių vartų klausytoją, ir nieko daugiau. Vidiniai vartai gali reikalauti vaidmens teiginio ir leisti tik keitimo įraše nurodytus valdymo adresus. Programėlė tolimajame gale pasilieka paskutinį žodį dėl to, kokias operacijas tas vaidmuo gali atlikti, todėl grandinė prideda vartus nepakeisdama programėlės autorizacijos.
| Gate | Identity it checks | Destinations it permits | How it could be skipped | When it is removed |
|---|---|---|---|---|
| Outer gateway | Employee account plus a managed device posture | General internal services and the inner gateway's listener | Any alternate path to the same destinations, including a public listener | Ordinary work stops and the inner stage becomes unreachable |
| Inner gateway | A maintenance entitlement or role claim on that identity | The named management addresses in the change record | Direct routes from the outer domain to those addresses | Maintenance access ends while general access stays as it was |
Du praleidimai tyliai sugriauna dizainą. Jei išorinė sritis jau tiesiogiai pasiekia kiekvieną jautrų tikslą, vidiniai vartai yra pasirenkami, o ne privalomi. Jei viešas klausytojas ar antras privatus maršrutas siūlo tą patį prieinamumą, numatytas kelias yra viena iš kelių galimybių. Paskirkite savininką ir kiekvienai taisyklių grupei, ir tegul jų sutartis įvardija tikslo paslaugas, leidžiamas šaltinio tapatybes, privatų DNS, adresų vertimą ir kas atsako, kai perdavimas nepavyksta. Adresas, kuriuo pasitikima išoriniame tinkle, niekada neturi pakeisti vidinės srities autorizacijos.
Tikrinkite atsisakymo atvejus, o ne sėkmingą kelią
Sėkmingas ryšys per abejus vartus įrodo labai mažai, nes tai yra atvejis, kurį visi tikrino diegimo metu. Įdomūs atvejai yra tie, kai viena pakopa praeina, o kita atsisako. Trys iš jų apima didžiąją dalį rizikos, ir kiekvienas turi laukiamą rezultatą, kurį galima patikrinti, o ne ginčytis.
Kai bendras prieinamumas patvirtintas, o jautraus vaidmens nėra, įprastas darbas turi tęstis, kol jautraus tikslo atsisakoma. Patvirtinkite abi pakopas ir pasiekiamas rinkinys turėtų būti keitimo įraše nurodyti priežiūros galiniai taškai, nieko platesnio. Jei teisė atšaukiama sesijos viduryje, sutarta sesijos politika turi įsigalioti nenutraukdama nesusijusio bendro prieinamumo. Ar tas atšaukimas užbaigia esamą sesiją iš karto, ar per kitą pakartotinę autentifikaciją, yra politikos sprendimas, kuris sutartyje jau turėtų būti. Kas parašė priėmimo atvejus, nėra tas žmogus, kuris turėtų juos aiškinti incidento metu.
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"Suskaičiuokite pridėtas priklausomybes
Kiekviena papildoma pakopa prideda komponentą, kuris gali sugesti, ir maršrutą, kuris turi teisingai įsiterpti į išorinį tunelį. Dalinio gedimo metu išorinis kelias lieka veikti, o vidinis nepasiekiamas, todėl vartotojas mato sveiką VPN piktogramą šalia paslaugos, kuri niekada neatsako.
Tikrinkite maršrutus ir blokavimo taisykles gedimo metu, o ne tik įprastu atveju. Išorinio tunelio stumiamas numatytasis maršrutas gali užfiksuoti paties vidinių vartų adresą, ir tai antrą pakopą paverčia ryšiu, kuris užsimezga ir tada nukrenta. Užrašykite, kas turi likti užblokuota, kol nėra vidinio tunelio, nes atsitiktinis atsarginis kelias aplink jį yra blogiau nei švarus nutrūkimas. Naudokite tą pačią patikros formą abiejuose šuoliuose, kad kiekvienas būtų išmatuotas, o ne numatytas. Du prisijungusios būsenos indikatoriai neįrodo nei įsiterpimo, nei izoliacijos.
Ko antrųjų vartų negalima nusipirkti
Paklauskite, ar dveji vartai dalijasi prisijungimo duomenimis, sertifikavimo institucija ar valdymo plokštuma. Kur dalijasi, jie taip pat dalijasi svarbiausiais gedimų režimais, o antroji pakopa kainuoja daugiau nei nepriklausomybė, kurią tarsi prideda. Atskiros kriptografinės sesijos nesukuria atskirų administracinių kontrolių.
Laikykite vidinius vartus tol, kol jie vykdo reikalavimą, kurį galite suformuluoti ir patikrinti, pavyzdžiui, vaidmenį, kurio išorinė sritis niekada netikrina. Pašalinkite juos, kai vienintelis jų darbas yra iš naujo autentifikuoti tą pačią tapatybę tiems patiems tikslams. Bet kuriuo atveju užrašykite reikalavimą, savininką ir gedimo elgseną kartu, kad kita peržiūra ginčytųsi dėl reikalavimo, o ne dėl schemos.