Zero Trust, VPN і праверка TLS выконваюць розныя задачы

Закупачныя дакументы разглядаюць zero trust, VPN і праверку TLS як адну і тую ж закупку, і кожны з іх адказвае на пытанне, на якое не здольныя іншыя. Тунэль будуе абаронены шлях, шлюз праверкі чытае трафік, які можа спыніць, а палітыка вырашае, ці можа названая асоба выканаць названую аперацыю над названым рэсурсам. Толькі апошняе — гэта рашэнне аб аўтарызацыі. Прадукт можа бездакорна выконваць першыя два і пакідаць сапраўднае пытанне адкрытым.

Тры механізмы, тры пытанні

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

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

Дзе рашэнне фактычна прымяняецца

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

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

Дэшыфраванне — не аўтарызацыя

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

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

Калі шлюза няма на шляху зусім

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

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

Перайменаваны тунэль застаецца тунэлем. Палітыка вырашае, і нешта павінна яе прымяняць.