Zero Trust, VPN и TLS инспекцията вършат различни задачи

Документите за обществени поръчки третират zero trust, VPN и TLS инспекцията като една и съща покупка, а всяко от тях отговаря на въпрос, на който другите не могат. Тунелът изгражда защитен път, инспекционният шлюз чете трафик, който може да прекрати, а политиката решава дали даден идентитет може да извърши дадена операция върху даден ресурс. Само последното е решение за оторизация. Един продукт може да прави първите две безупречно и пак да остави истинския въпрос отворен.

Три механизма, три въпроса

Тунелът отговаря как трафикът стига до мрежата. Инспекционният шлюз отговаря какво може да види и направи междинно устройство там, където е оторизирано да прекратява TLS. Политиковият двигател отговаря кой какво може да прави с кой ресурс и след това се нуждае от точка за налагане, способна да приложи този отговор. Архитектурата zero trust на NIST поставя ресурса в центъра и отказва да извежда доверие от това откъде е дошъл пакетът.

Тази рамка е по-трудна за удовлетворяване от етикет и много по-трудна за фалшифициране при преглед. Тя също така отмества въпроса от това кои продукти са внедрени към това кои решения се налагат и от какво.

Къде решението действително се прилага

Вземете една заявка: инженер по поддръжката отваря сервизна конзола и лична машина, включена в същия комутатор, не бива да наследява това разрешение само защото е наблизо. Запишете разрешената операция, условията на устройството и компонента, който ги налага. Разположението решава всичко: приложен шлюз, сервизен прокси, контрол на хоста или друга граница, която организацията действително поддържа. Какъвто и да се окаже този компонент, той трябва да стои на пътя и на отдалечените, и на локалните опити.

Трафик, който никога не пресича входа на VPN, не се управлява от проверка, извършена там, колкото и старателна да е тя. Тази единствена празнина обяснява по-голямата част от разстоянието между схема за zero trust и работещо внедряване. Начертайте пътя на заявката, преди да начертаете архитектурата.

Декриптирането не е оторизация

Прихващането служи на тесни цели за инспекция и носи собствени тежести: сертификати, доверени корени, преглед на поверителността и приложения, които се чупят под него. Нищо от това не е смисълът на zero trust и нищо от това не замества решение на политика. Удостоверяването на човек и оторизирането на услуга е напълно възможно без декриптиране на нито един пакет. Декриптиран поток не казва нищо за това дали потребителят е имал право на операцията, пренасяна в него.

Политиката се нуждае от един вид доказателство и декриптирането не е то. Състоянието на устройството е един вход сред идентитет, чувствителност на ресурса и контекст и преминаването му веднъж не дава на тази машина останалата част от мрежата. Смесването на двете превръща въпрос за оторизация в проект за сертификати.

Когато шлюзът изобщо не е на пътя

Направете опис на това, което пътува, без да докосва отдалечения шлюз: връзки между машини в локалния сегмент, извиквания от една работна нагрузка към друга и крайни точки, достигнати директно в облачен акаунт. За всеки път назовете метод за налагане, който действително може да бъде внедрен днес. Оборудване, което не може да приюти агент, все още се нуждае от друг изрично поддържан контрол, а допускането, че агентът ще дойде по-късно, сега не затваря нищо. Достъпът услуга към услуга обикновено подхожда по-добре на идентитет на работна нагрузка и проверка, написана срещу ресурса, отколкото на още една насложена мрежа.

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

Преименуван тунел си остава тунел. Политиката решава и нещо трябва да я налага.