Zerotrust по-пацански

Вводная

Мне очень нравится концепция защиты инфраструктуры, в которой нет сторон, которые доверяют друг другу просто так. Все друг друга проверяют, проверяют каждое действие. Такая концепция называется Zerotrust. 

Какие основные идеи лежат в ее основе?

1. Всегда проверяй явно

2. Отсутствие любых “доверенных” зон

3. Проектирование с мыслью “нас уже взломали”

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

Три постулата zerotrust

Всегда проверяй явно

Говоря формальным языком нам необходима обоюдная аутентификация и авторизация сторон при взаимодействии. Из чего обычно состоит сеть предприятия? Серверный сегмент, пользовательский сегмент. Как чаще всего утекают данные? Внутри vpn сети сидит злодей, который находит учетку/ фишит двухфакторку для внутренних админок и сливает оттуда данные. Почему так происходит?

Потому что мы считаем, что внутри vpn у нас все получше защищено, и “Я же уже ввел двухфакторку на входе в VPN, зачем мне еще дополнительная аутентификация”. Этот подход устарел. 

Необходимо в явном виде удостовериться, кто к тебе пришел (со стороны сервера) и к кому ты пришел (со стороны клиента). Наиболее проверенный метод тут - mTLS. Обе стороны криптографически надежно проверяют друг друга. 

Вот так выглядит работа mTLS. Клиент и сервер обмениваются сертификатами, валидируют их и устанавливают защищенное соединение. Задача явной проверки решена. 

А что если мы не только хотим знать, кто к нам пришел, но и узнать насколько пришедшее устройство защищено? В таком случае нам нужно использовать сертификат не для аутентификации пользователя, а для аутентификации устройства.

То есть для полноценной защиты наших админок нужно делать две вещи:

1. Аутентифицировать устройство

2. Аутентифицировать пользователя

Надежно аутентифицировать устройство можно, сгенерировав сертификат в неизвлекаемом хранилище. Для этого подходит Secure Enclave в устройствах Apple и TPM для остальных устройств. Аутентифицировать пользователя можно стандартными способами - подойдет, например ldap или OIDC. Подробнее про проблематику проверки устройств и пользователя поговорим в отдельном материале.

Отсутствие любых “доверенных” зон

Проектировку сервиса нужно делать так, будто у вас все сервера и клиенты выставлены всеми портами в интернет. При этом нужно учесть, что у  каждой компании свой уровень зрелости, и свой темп развития бизнеса. Нужны будут компромиссы, например для исключительно межсерверного взаимодействия (поход в СУБД бекендом веб-приложения) срочное внедрение ZT будет избыточным. Тем не менее проектирование новых, или перенос архитектуры старых сервисов на новые рельсы даст весомые плоды с точки зрения ИБ в долгосрочной перспективе.

Возвращаясь к насущной проблеме защиты админок - самым простым и эффективным методом будет прокси. Или по шагам:

1. Реализуем прокси, осуществляющую проверку устройства

2. Реализуем механизм проверки пользователя - например, OIDC

3. Переносим существующую админку за нашу защищенную прокси

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

Как конкретно реализовать прокси технически поговорим в отдельном материале.

Проектирование с мыслью “нас уже взломали”

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

Так как прикладная проблема, которую мы решаем, это защита веб-админок, основным обьектом защиты для нас станут клиентские ноутбуки, так как наша прокси пускает в админку только известные нам устройства. Мы отдаем себе отчет, что ноутбук всегда будет взломан, поэтому мы:

а) накручиваем на нем средства защиты и мониторинга - edr агент, правильно настроенное логгирование.

б) убеждаемся, что наш Security Operation Center умеет распознавать все современные типы атак на конечные устройства. Для этого мы постоянно изучаем новые TTP, проводим учения, и пишем новые правила в SIEM.

Про то, как защищать эндпоинты мы также поговорим отдельно.

Короткие итоги

Итак, что мы для себя вынесли. Для получения MVP решения Zetotrust по защите веб-админки нам нужно:

1. Реализовать инфраструктуру по доставке и валидации сертификатов для конечных устройств

2. Реализовать прокси, способную устанавливать защищенное mtls соединение, в перспективе проверяя уровень защищенности подключающегося устройства

3. Наладить защиту и мониторинг конечных устройтсв

Высокоуровнево выглядит примерно так:

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

Историческая справка

Точно сказать, кто придумал ZT и как именно не представляется возможным. Нас больше интересует практическая сторона вопроса. И вот по ней ряд материалов есть. 

1. Google BeyondCorp. Цикл статей, из которых родился сначала внутренний, а потом и коммерческий продукт. В статьях обстоятельно прописана теория, схема работы и ряд ключевых технических и управленческих аспектов. Must read.

2. Project Zero Trust. Книга двух идеологов идеи Zerotrust, которые десять лет ездят по разным компаниям и рассказывают, как его внедрять. Технического очень мало, но советы по “продаже” идеи бизнесу встречаются толковые.

3. Cloudflare ONE. Коммерческое решение от Cloudflare, в документации довольно подробно расписаны технические аспекты, из которых можно понять и аспекты организационные. Является *AAS решением, лично мне завязываться на готовые решения такого масштаба не видится разумным. Хорошо подходит для того, чтобы взять идеи для собственной разработки.