Zero Trust, VPN и проверка TLS решают разные задачи

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

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

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

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

Где решение действительно применяется

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

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

Расшифровка — не авторизация

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

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

Когда шлюза нет нигде на пути

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

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

Переименованный туннель остаётся туннелем. Политика решает, и что-то должно её применять.