Zero Trust, VPN ir TLS inspekcija atlieka skirtingus darbus
Tunelis saugo kelią, inspekcijos šliuzas mato srautą, o politika nusprendžia, kas ką gali daryti. Tik trečiasis atsako į klausimą, kurį kelia zero trust.
Pirkimo dokumentai zero trust, VPN ir TLS inspekciją traktuoja taip, tarsi tai būtų tas pats pirkimas, ir kiekvienas jų atsako į klausimą, į kurį kiti negali. Tunelis nutiesia apsaugotą kelią, inspekcijos šliuzas skaito srautą, kurį gali užbaigti, o politika nusprendžia, ar įvardyta tapatybė gali atlikti įvardytą operaciją su įvardytu ištekliu. Tik pastarasis yra autorizacijos sprendimas. Produktas gali puikiai atlikti pirmuosius du ir vis tiek palikti tikrąjį klausimą atvirą.
Trys mechanizmai, trys klausimai
Tunelis atsako, kaip srautas pasiekia tinklą. Inspekcijos šliuzas atsako, ką tarpinė priemonė gali matyti ir daryti ten, kur turi teisę užbaigti TLS. Politikos variklis atsako, kas ką gali daryti su kuriuo ištekliu, o tada jam reikia vykdymo taško, galinčio pritaikyti šį atsakymą. NIST zero trust architektūra išteklių stato į centrą ir atsisako daryti išvadą apie pasitikėjimą iš to, iš kur atkeliavo paketas.
Šią schemą sunkiau įgyvendinti nei etiketę, ir daug sunkiau suklastoti per peržiūrą. Ji taip pat perkelia klausimą nuo to, kokie produktai įdiegti, prie to, kokie sprendimai vykdomi ir kuo.
Kur sprendimas iš tikrųjų pritaikomas
Paimkite vieną užklausą: pagalbos inžinierius atidaro paslaugos konsolę, o asmeninis kompiuteris, prijungtas prie to paties komutatoriaus, neturi paveldėti šios teisės vien todėl, kad yra netoliese. Užrašykite leidžiamą operaciją, įrenginio sąlygas ir komponentą, kuris jas vykdo. Vieta nusprendžia viską: programos šliuzas, paslaugos tarpinė, pagrindinio kompiuterio kontrolė ar kita riba, kurią organizacija iš tikrųjų palaiko. Kad ir koks būtų tas komponentas, jis turi būti tiek nuotolinių, tiek vietinių bandymų kelyje.
Srautas, kuris niekada nekerta VPN įėjimo, nėra valdomas ten atliekamos patikros, kad ir kokia kruopšti ji būtų. Būtent ši viena spraga paaiškina didžiąją dalį atstumo tarp zero trust schemos ir veikiančio diegimo. Nubraižykite užklausos kelią prieš braižydami architektūrą.
Iššifravimas nėra autorizacija
Perėmimas tarnauja siauriems inspekcijos tikslams ir neša savo naštą: sertifikatus, patikimus šakninius liudijimus, privatumo peržiūrą ir programas, kurios po juo lūžta. Nė vienas iš to nėra zero trust prasmė, ir nė vienas nepakeičia politikos sprendimo. Autentifikuoti asmenį ir autorizuoti paslaugą visiškai įmanoma neiššifravus nė vieno paketo. Iššifruotas srautas nieko nesako apie tai, ar naudotojas turėjo teisę į jame perduodamą operaciją.
Politikai reikia vienos rūšies įrodymo, o iššifravimas nėra jis. Įrenginio būklė yra viena įvestis tarp tapatybės, ištekliaus jautrumo ir konteksto, ir vienkartinis jos išlaikymas nesuteikia tam kompiuteriui likusio tinklo. Sumaišius abu, autorizacijos klausimas virsta sertifikatų projektu.
Kai šliuzo kelyje visai nėra
Surašykite, kas juda neliesdamas nuotolinio šliuzo: ryšiai tarp vietinio segmento kompiuterių, kvietimai iš vieno darbo krūvio į kitą ir galiniai taškai, pasiekiami tiesiogiai debesijos paskyroje. Kiekvienam keliui įvardykite vykdymo metodą, kurį iš tikrųjų galima įdiegti šiandien. Įranga, kuri negali talpinti agento, vis tiek turi kitą aiškiai palaikomą kontrolę, o prielaida, kad agentas atsiras vėliau, dabar nieko neuždaro. Prieiga nuo paslaugos prie paslaugos paprastai labiau tinka darbo krūvio tapatybei ir prieš išteklių parašytai patikrai nei dar vienas perdangos tinklas.
Priimkite dizainą pagal elgesį, o ne pagal schemas: kokios operacijos leidžiamos, kurios draudžiamos ir kur kiekvienas atsakymas vykdomas. Patvirtinkite konkrečias leidžiamas ir draudžiamas operacijas ir įtraukite vieną vietinį maršrutą, kuris niekada nepasiekia šliuzo. Užrašykite, kas valdo politiką, kaip ji kinta ir kaip veikia atšaukimas.
Pervadintas tunelis vis tiek lieka tuneliu. Politika nusprendžia, ir kažkas turi ją vykdyti.