Zerotrust по-пацански
Вводная
Мне очень нравится концепция защиты инфраструктуры, в которой нет сторон, которые доверяют друг другу просто так. Все друг друга проверяют, проверяют каждое действие. Такая концепция называется Zerotrust.
Какие основные идеи лежат в ее основе?
Всегда проверяй явно
Отсутствие любых “доверенных” зон
Проектирование с мыслью “нас уже взломали”
Давайте пройдемся по постулатам подробнее и более технически. По ходу дела будем решать насущную проблему - защита веб-админок от кражи данных. По итогам хотим получить понимание, как сделать MVP решения, построенного по принципам zerotrust.
Три постулата zerotrust
Всегда проверяй явно
Говоря формальным языком нам необходима обоюдная аутентификация и авторизация сторон при взаимодействии. Из чего обычно состоит сеть предприятия? Серверный сегмент, пользовательский сегмент. Как чаще всего утекают данные? Внутри vpn сети сидит злодей, который находит учетку/ фишит двухфакторку для внутренних админок и сливает оттуда данные. Почему так происходит?
Потому что мы считаем, что внутри vpn у нас все получше защищено, и “Я же уже ввел двухфакторку на входе в VPN, зачем мне еще дополнительная аутентификация”. Этот подход устарел.
Необходимо в явном виде удостовериться, кто к тебе пришел (со стороны сервера) и к кому ты пришел (со стороны клиента). Наиболее проверенный метод тут - mTLS. Обе стороны криптографически надежно проверяют друг друга.

Вот так выглядит работа mTLS. Клиент и сервер обмениваются сертификатами, валидируют их и устанавливают защищенное соединение. Задача явной проверки решена.
А что если мы не только хотим знать, кто к нам пришел, но и узнать насколько пришедшее устройство защищено? В таком случае нам нужно использовать сертификат не для аутентификации пользователя, а для аутентификации устройства.
То есть для полноценной защиты наших админок нужно делать две вещи:
Аутентифицировать устройство
Аутентифицировать пользователя
Надежно аутентифицировать устройство можно, сгенерировав сертификат в неизвлекаемом хранилище. Для этого подходит Secure Enclave в устройствах Apple и TPM для остальных устройств. Аутентифицировать пользователя можно стандартными способами - подойдет, например ldap или OIDC. Подробнее про проблематику проверки устройств и пользователя поговорим в отдельном материале.
Отсутствие любых “доверенных” зон
Проектировку сервиса нужно делать так, будто у вас все сервера и клиенты выставлены всеми портами в интернет. При этом нужно учесть, что у каждой компании свой уровень зрелости, и свой темп развития бизнеса. Нужны будут компромиссы, например для исключительно межсерверного взаимодействия (поход в СУБД бекендом веб-приложения) срочное внедрение ZT будет избыточным. Тем не менее проектирование новых, или перенос архитектуры старых сервисов на новые рельсы даст весомые плоды с точки зрения ИБ в долгосрочной перспективе.
Возвращаясь к насущной проблеме защиты админок - самым простым и эффективным методом будет прокси. Или по шагам:
Реализуем прокси, осуществляющую проверку устройства
Реализуем механизм проверки пользователя - например, OIDC
Переносим существующую админку за нашу защищенную прокси
После реализации этих пунктов нам будет неважно в какой зоне доверия располагать нашу админку - внутри VPN, внутри отдельной защищенной подсети внутри VPN, или в интернете. Привязку к доверенным зонам мы убрали.
Как конкретно реализовать прокси технически поговорим в отдельном материале.
Проектирование с мыслью “нас уже взломали”
Этот пункт несколько менее технически-прикладной, но он очень важен. При построении инфраструктуры необходимо приучить себя к мысли, что каждый элемент уже взломан - будь то клиентский ноутбук, сервер, или сетевая железка. Так мы сможем четко понять, какие риски возникнут при взломе, например, клиентского ноутбука, и какие меры нужно предпринять для митигации либо предотвращения атак.
Так как прикладная проблема, которую мы решаем, это защита веб-админок, основным обьектом защиты для нас станут клиентские ноутбуки, так как наша прокси пускает в админку только известные нам устройства. Мы отдаем себе отчет, что ноутбук всегда будет взломан, поэтому мы:
а) накручиваем на нем средства защиты и мониторинга - edr агент, правильно настроенное логгирование.
б) убеждаемся, что наш Security Operation Center умеет распознавать все современные типы атак на конечные устройства. Для этого мы постоянно изучаем новые TTP, проводим учения, и пишем новые правила в SIEM.
Про то, как защищать эндпоинты мы также поговорим отдельно.
Короткие итоги
Итак, что мы для себя вынесли. Для получения MVP решения Zetotrust по защите веб-админки нам нужно:
Реализовать инфраструктуру по доставке и валидации сертификатов для конечных устройств
Реализовать прокси, способную устанавливать защищенное mtls соединение, в перспективе проверяя уровень защищенности подключающегося устройства
Наладить защиту и мониторинг конечных устройтсв
Высокоуровнево выглядит примерно так:

Сразу отмечу, что схема заведомо упрощена, в каждом новом материале она будет обновляться и усложняться. Будет подробно расписана схема mTLS и система валидации сертификатов, включение SOC не только в работу с самим ноутбуком, но и в мониторинг самой админки, проверка защищенности конечных устройств, то есть каждый новый элемент будет отражен на схеме по мере его подробного обсуждения. Финальная схема будет доступна позднее.
Историческая справка
Точно сказать, кто придумал ZT и как именно не представляется возможным. Нас больше интересует практическая сторона вопроса. И вот по ней ряд материалов есть.
Google BeyondCorp. Цикл статей, из которых родился сначала внутренний, а потом и коммерческий продукт. В статьях обстоятельно прописана теория, схема работы и ряд ключевых технических и управленческих аспектов. Must read.
Project Zero Trust. Книга двух идеологов идеи Zerotrust, которые десять лет ездят по разным компаниям и рассказывают, как его внедрять. Технического очень мало, но советы по “продаже” идеи бизнесу встречаются толковые.
Cloudflare ONE. Коммерческое решение от Cloudflare, в документации довольно подробно расписаны технические аспекты, из которых можно понять и аспекты организационные. Является *AAS решением, лично мне завязываться на готовые решения такого масштаба не видится разумным. Хорошо подходит для того, чтобы взять идеи для собственной разработки.
Комментарии (13)
eimrine
31.05.2025 16:45Надежно аутентифицировать устройство можно, сгенерировав сертификат в неизвлекаемом хранилище. Для этого подходит Secure Enclave в устройствах Apple и TPM для остальных устройств.
Я, конечно, не настоящий сварщик, но доверять закрытым продуктам и называть это нулевым доверием это как-то не по-Столлмановски. Получается, с вашей точки зрения нельзя доверять железякам у которых 100% FOSS.
sukharichev
31.05.2025 16:45Вот все так красиво поют про этот Zero Trust уже много лет, я читаю эти статьи, и нигде нет никакой конкретики. Что делать админу, а не разработчику? Можно ли обойтись без отдела безопасности хотя бы для минимального внедрения? Какой набор инструментов внедрить хотя бы на уровне тестового стенда? Есть ли такой набор в виде open-source и бесплатно, чтобы начать осваивать концепцию без вложения триллионов денег? Какой смысл писать руками правила для siem, когда угроз в минуту появляется больше, чем минут в моем рабочем дне? И главное, вот мы увнедрялись и упроверялись, а на ноуте разраба еще до всех наших внедрений сидел легитимный инструмент, переделанный под RAT и от его имени все наши zerotrust операторы этого RAT будут иметь и посмеиваться над гигантскими усилиями, которые они обошли.
Вот я поставил Wazuh или AlienVault. реализовал двойную проверку при подключениях Vpn (девайса и пользователя), антивирусы-шмантивирусы, а потом оказывается, что в моем nextgen-файрволле RCE и опять над моими усилиями будет смеяться школота, которая только и сделала, что скачала и запустила эксплоит с гитхаба.
Я не утверждаю, что эта концепция неправильная, или эти усилия не нужны, но это приблизительно милионная статья целиком из воды на эту тему. Дайте пошаговое руководство и примеры внедрения в реальных компаниях среднего размера. А перетирать про абстракции который год подряд смысла нет.
Извините, накипело.
hollow1 Автор
31.05.2025 16:45Большое спасибо за комментарий, статей будет несколько, в следующих расскажу и дам ссылки на опенсорсный софт.
firegurafiku
31.05.2025 16:45А что если мы не только хотим знать, кто к нам пришел, но и узнать насколько пришедшее устройство защищено?
Это называется «аппаратная аттестация» и невозможно без аппаратных зондов, заложенных настолько глубоко, что без атомного микроскопа не дотянуться. Эппл такое любит и давно практикует в мобильных устройствах, но начиная с M-серии оно просочилось на десктоп. И хоть оно секьюрно просто до невозможности, мне почему-то ужасно не хочется торопиться в это светлое будущее.
pnmv
запуск любого антивируса, и что там еще может быть, по запросу удаленного агента, на этапе взаимного удостоверения? а если тот сам уже взломан и просит явно лишнее?
hollow1 Автор
Антивирус, кажется, довольно долго и дорого запускать. А запрос излишних прав - логгируем и отправляем в SOC для истории. В нормальном режиме запрос новых прав - редирект в IDM и проход по процессу получения доступов.
pnmv
запуск антивируса, как и любого "более прикладного программного обеспечения", это всегда слишком дорого.
max9
все проще - это надо делать на уровне подключения VPN. те хост репортит, что соответсвует комплаенсу того сегмента, к которому подключается. что AV стоит, что базы там актуальные, что патчи в ОС тоже стоят. если нет то попадает в гетто, где доступна только установка АВ, обновления баз и тд.
cisco так умеет, например
ki11j0y
Vpn перестал быть точкой безопасного входа. В нем так же есть уязвимости.
firegurafiku
А про какой именно вы VPN и какие именно уязвимости имеете в виду?
Просто, знаете, реализации TLS тоже не застрахованы от уязвимостей. И в SSH. Но почему-то «перестал быть точкой безопасного входа» именно VPN, построенный ровно на тех же самых криптографических принципах.
ki11j0y
Сразу могу вспомнить кучу дыр в vpn шлюзах cisco и palo alto, про наши гост шлюзы ни кто не напишет. Но и там они есть. Самое надежное это открытое ПО с открытым аудитом. Потому что как показала практика, владельцам закрытого ПО как то все равно на продукт. В лучшем случае обновят, в так себе будут отрицать, потом обновят, в худшем скажут оборудование устарело, купи новое, привет dlink.
firegurafiku
А, вы про такие VPN. В моей голове дефолтные VPN-протоколы — это OpenVPN и Wireguard, и я очень удивился узнать, что они вдруг стали потенциально опасными.