Ключевым звеном в zt является прокси. Именно с ней взаимодействуют все клиенты, от нее они получают вердикт - пустят их в админку или нет.

Что должна уметь прокси в первую очередь:

Устанавливать mTLS соединение с клиентом
Корректно проксировать запросы от клиента в защищаемый сервис и обратно
Работать с другими сервисами - Certification Authority и его middleware, OIDС, системой принятия решений (которая принимает решение пускать/не пускать)

Схема работы получается такая:

Что должна уметь прокси во вторую очередь:

Работать не только с HTTP протоколом
В режиме реального времени разрывать соединение
Поддерживать гранулярную настройку доступа per route для HTTP. Например на /admin пускать только определенных пользователей.
Обеспечивать поддержку machine-2-machine взаимодействия
Иметь breaking glass механизм

Посмотрим, есть ли готовые решения для этих задач, что нужно допиливать самим, и подумаем, что нам нужно сделать в пост-MVP период.

Выбор решения из готовых

Первым критерием для выбора является открытые исходники. Готовые вендорские решения не подходят - у них очень специфичные требования, продукты сырые, вендор всегда бежит медленнее чем ты. При выборе опенсорс ориентируемся на стек, так как решение планируем поддерживать, дописывать и переписывать.
Второй критерий - соответствие нашим требованиям к функционалу.

Из более-менее готовых решений можно выделить: ORY, Pomerium, Teleport. Каждый может оценить, что ему ближе. Нужно просто сразу принять, что на второй год эксплуатации всё придется поменять и переписать.

Поддержка MVP Функционала

Установка mTLS соединения

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

Корректное проксирование соединения

Так как наша прокси стоит вразрез, к ней предъявляются высокие требования к стабильности. Также большое внимание нужно уделить процессу перевоза админок за нашу прокси. Разбрем на примере:

Существующая админка использует самописную систему авторизации и аутентификации пользователей. Пользователь идет в самописную систему, авторизуется в ней, она ставит ему HTTP заголовки и куки, после чего админка пользователя пропускает. При перевозе на единую OIDC это создает проблему - админка ждет определенные заголовки от пользователя, иначе его просто не пустит. Поэтому нам необходимо реализовать доработки на нашем едином OIDC и на нашей прокси, чтобы они прокидывали те заголовки, которые админка ожидает. Возможно, со стороны админки также потребуются доработки, но нам нужно свести их к минимуму. Это очень важный момент - чем легче ресурсу переехать на zt, тем быстрее и проще пройдет переезд других ресурсов, а в последствии и всей компании. В идеале мы должны сделать схему более удобной, чем она была. Пользователи получат удобство в доступе и работе, а мы получим более безопасную и технически зрелую инфраструктуру.

Взаимодействие с Certification Authority, OIDC, Системой принятия решений

Взаимодействие с CA реализуется в рамках задачи по mTLS соединению, с ней сложностей возникнуть не должно.

С OIDC также - после проверки устройства мы должны редиректить пользователя на страницу ввода его логина и пароля / второго фактора, после чего корректно это обрабатывать и хранить его сессию.

Взаимодействие с Системой принятия решений. В СПР мы заложим функционал по анализу степени защищенности устройства, установки к ним требованиям и управления этими сущностями. На ней остановимся подробнее в следующих материалах, главное что отметим для себя тут - СПР должно иметь API, по которому прокси будет его опрашивать, а сама прокси должна поддерживать механизм кеширования, чтобы на каждый запрос пользователя не дергать СПР. Отмечу, что в рамках MVP мы только проектируем эту часть, самое решение “пускать/ не пускать” пока что будет приниматься на уровне наличия и доверия сертификату.

Следующие шаги. Post MVP

Даже в процессе MVP после подключения нескольких админок у нас уже будет расти и множиться спискок функций, которые нам понадобятся. Перечислю и прокомментирую некоторые из них:

Поддержка не-HTTP протоколов. Было бы круто, если бы мы ходили админить наши сервера по ssh с zt функционалом - проверка устройства, единая удобная авторизация и так далее.
Разрыв соединения в реальном времени. При инциденте или выходе нового 0day в Chrome мы хотим понижать уровень доверия устройств и разрывать их соединение с админками.
Гранулярная настройка маршрутов внутри приложения позволит нам быстро и удобно подключать legacy админки и на уровне zt контролировать доступ к чувствительному функционалу внутри них.
Machine-2-machine. Это очевидная и очень важная вещь - почти в любую админку ходят не только люди, но и другие сервисы, и их тоже нужно как-то проверять и авторизовывать. Тема сильно пересекается с проблемой межсервисной аутентификации, интегрировать эти две технологии в одну - сложная и интересная задача.
Breaking glass. В некоторых случаях мы все-таки пускать non-compliant клиентов к нашим ресурсам. А в некоторых ситуациях наша zt инфраструктура может дать сбой, и нам нужно дать возможность пользователям продолжить работу при сбое.

Прокси - постоянно растущий и изменяющейся сервис. Важно определить для себя, что мы хотим в первую очередь, реализовать это, обеспечить надежность, а потом продолжить развитие.

Zerotrust по-пацански #4. Единая прокси