Zero Trust, VPN і перевірка TLS виконують різні завдання

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

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

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

Таку рамку складніше задовольнити, ніж ярлик, і значно складніше підробити під час перевірки. Вона також переносить питання з того, які продукти розгорнуто, на те, які рішення і чим застосовуються.

Де рішення справді застосовується

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

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

Розшифрування — не авторизація

Перехоплення служить вузьким цілям перевірки і несе власний тягар сертифікатів, довірених коренів, огляду приватності та застосунків, які ламаються під ним. Ніщо з цього не є сенсом zero trust, і ніщо з цього не замінює рішення політики. Автентифікувати людину й авторизувати сервіс цілком можливо, не розшифровуючи жодного пакета. Розшифрований потік нічого не каже про те, чи мав користувач право на операцію, яку в ньому переносять.

Політиці потрібен один вид доказу, і розшифрування ним не є. Стан пристрою — це один вхід поряд з ідентичністю, чутливістю ресурсу й контекстом, і одноразове проходження не віддає цій машині решту мережі. Змішування обох перетворює питання авторизації на проєкт сертифікатів.

Коли шлюзу немає ніде на шляху

Перелічіть, що переміщується, не торкаючись віддаленого шлюзу: зв’язки між машинами в локальному сегменті, виклики від одного робочого навантаження до іншого і кінцеві точки, досяжні напряму всередині хмарного облікового запису. Для кожного шляху назвіть метод застосування, який справді можна розгорнути сьогодні. Обладнання, яке не може розмістити агент, усе одно потребує іншого явно підтримуваного контролю, а припущення, що агент з’явиться пізніше, зараз нічого не закриває. Доступ сервіс-сервіс зазвичай краще пасує до ідентичності робочого навантаження й перевірки, написаної проти ресурсу, ніж ще одна накладена мережа.

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

Перейменований тунель залишається тунелем. Політика вирішує, і щось має її застосовувати.