Я протестировал zero trust на одном отделе, а не на всем бизнесе
«Я не понимаю, как можно сразу внедрить такую концепцию во всей компании. Слишком дорого, слишком сложно, слишком много перемен. Мне нужно было что-то, что я могу пощупать прямо сейчас, увидеть конкретный результат и доказать его стоимость. Поэтому я развернул архитектуру нулевого доверия не на всей компании, а на одном отделе разработки, который уже сидел в облаке и работал с микросервисами. Это была лаборатория под реальными нагрузками. Результат оказался настолько неочевидным, что я бы никогда не решился на такой эксперимент, если бы мне заранее рассказали о всех подводных камнях».
Почему вся компания, это плохая точка старта
Стандартный путь для внедрения новых технологий в инфобезе, это пилотный проект. Но zero trust, это не просто новая коробка с софтом, это смена парадигмы аутентификации и доступа. Пилот, ограниченный одним приложением или группой пользователей, часто не раскрывает всей глубины организационных проблем, которые становятся критичными при масштабировании. Регуляторные требования ФСТЭК России к сегментации и управлению доступом, например, создают дополнительный слой сложности. Начинать с пилотного внедрения на всю организацию — значит сразу столкнуться с сопротивлением всех служб, проблемами совместимости со старыми MES-системами на заводе, сложностями интеграции с Active Directory для бухгалтерии и необходимостью переписать сотни правил межсетевых экранов.
Выбор в качестве полигона целого отдела, это шаг в сторону от абстрактного пилота. Это законченный бизнес-контур с реальными процессами, своими приложениями, данными и пользователями. Успех или провал здесь будет иметь измеримые последствия для бизнеса, а не просто для отчета по пилоту.
Кого выбирать на роль «подопытных»
Ключевой критерий — готовность инфраструктуры отдела к переменам. Идеальный кандидат уже живет в логике, близкой к zero trust, даже если не называет её так. Ищите признаки:
- Преобладание облачных и SaaS-сервисов. Отдел, который уже использует корпоративную почту в облаке, CRM и таск-трекеры, не привязан к внутреннему периметру сети. Для них концепция «сеть = доверие» уже не работает.
- Современный стек разработки и администрирования. Команды, работающие с контейнерами, оркестраторами вроде Kubernetes и CI/CD-цепочками, привыкли к декларативному описанию политик и автоматизации. Им проще принять идею политик доступа, описанных как код.
- Высокая мобильность и необходимость внешнего доступа. Отдел продаж, постоянно в разъездах, или команда разработки, часть которой работает удаленно, — отличные кандидаты. Их боль — сложный VPN, двухфакторная аутентификация через СМС и ограниченный доступ к ресурсам с личных устройств. Zero trust решает эти проблемы напрямую.
- Относительная простота инфраструктуры. Лучше начать не с отдела, который держит критическую унаследованную ERP-систему на старом сервере. Начните с тех, у кого меньше legacy-активов.
В моем случае это был отдел разработки. Они уже использовали GitLab, Jira, развертывали тестовые стенды в облаке, а их ключевые данные — исходный код — и так были защищены механизмами контроля версий и проверки кода.
Собираем базовые кирпичи: что реально нужно развернуть
Не нужно покупать «волшебную» платформу zero trust с сотней функций. Для изолированного отдела достаточно нескольких компонентов, которые лягут поверх существующей инфраструктуры.
- Шлюз приложений (ZTNA, заменяет VPN). Это ядро. Шлюз, подобный Cloudflare Access или аналогичным отечественным решениям, становится единственной точкой входа для пользователей отдела ко всем его приложениям — как облачным, так и оставшимся on-premise. VPN для этого отдела отключается полностью.
- Сервис идентификации (IdP) с поддержкой контекстных проверок. Обычная Active Directory не подойдет. Нужна система, которая может проверять не только логин-пароль и сертификат, но и контекст запроса: тип устройства, его состояние (заблокирован ли, есть ли антивирус), географическое расположение, сеть. Это позволяет создавать политики вида: «Разработчик может получить доступ к GitLab только со служебного ноутбука, на котором установлен агент EDR, и только в рабочее время».
- Агенты на конечных устройствах. Небольшие программы, которые собирают телеметрию о состоянии устройства (запущенные процессы, обновления, наличие угроз) и передают её в сервис идентификации для принятия решения о доверии.
- Простейшая система микросервисных политик (опционально). Если отдел использует Kubernetes, можно добавить сетевое взаимодействие между подами на основе identity, а не IP-адресов, с помощью, например, сервис-мешей вроде Istio или Cilium.
Самое сложное: переписать политики доступа с нуля
Это тот этап, где большинство спотыкается. Вы не можете автоматически перенести старые правила из Active Directory или файрвола. Zero trust требует начать с модели наименьших привилегий для каждой роли в отделе. Процесс выглядит так:
- Инвентаризация всех приложений и данных отдела. Что использует разработчик, тестировщик, тимлид?
- Определение «рабочих заданий» (job functions). Вместо абстрактных групп «Разработчики» нужно описать конкретные задачи: «Разработчик backend-сервиса A», «Тестировщик мобильного приложения B».
- Сопоставление заданий с минимально необходимыми правами. Какой именно доступ к GitLab, Jira, окружению сборки, логам, базам тестовых данных нужен для выполнения задачи?
- Формулировка политик на естественном языке, а затем — как код. Например: «Разработчик Сервиса А имеет право на запись в репозиторий service-a.git, на чтение тикетов в проекте Project-X, на доступ по SSH к тестовому стенду staging-a только с ПК, внесенного в реестр корпоративных устройств».
Это муторная работа, которую невозможно автоматизировать. Но именно она дает главное преимущество — полное понимание, кто и к чему имеет доступ в вашем отделе. Часто это приводит к шоку: обнаруживаются учетные записи с избыточными правами, оставшиеся с прошлых проектов, или сервисы, открытые для всех в сети «на всякий случай».
Неочевидные результаты и скрытые выгоды
После нескольких недель работы отдела в новой модели проявились последствия, о которых я не думал вначале.
- Исчезла «сетевая локация» как фактор доверия. Разработчики могли так же безопасно работать из дома, коворкинга или офиса. Это сняло напряжение по поводу удаленки и повысило гибкость команды.
- Быстрое подключение новых сотрудников и увольнение старых. Онбординг свелся к выдаче устройства с агентом и добавлению человека в нужные политики доступа в IdP. При увольнении доступ ко всем системам отключался централизованно в момент удаления его из политик, а не путем отзыва десятков отдельных учетных записей.
- Упрощение аудита для регуляторов. Когда ФСТЭК или служба внутреннего контроля запрашивают список лиц, имеющих доступ к критичным ресурсам, ответ формируется одним запросом к системе политик, а не полугодовым исследованием логов AD, VPN и файрволов.
- Выросла осведомленность о безопасности внутри команды. Разработчики начали сами интересоваться, почему доступ к новому инструменту требует отдельной политики. Это породило внутреннюю культуру «безопасность по умолчанию».
- Обнаружение теневого IT. Политика «запрещено все, что не разрешено явно» быстро выявила попытки использовать несанкционированные облачные хранилища или мессенджеры для работы — к ним просто не было доступа через корпоративные политики.
С какими подводными камнями я столкнулся
Не все было гладко. Вот главные проблемы, к которым стоит быть готовым:
- Сопротивление удобству. Первые дни команда роптала: «Раньше я просто подключался по VPN и все работало. А теперь надо ждать, пока система проверит мой ноутбук». Важно объяснять, что это плата за безопасность без компромиссов в любом месте.
- Проблемы с легаси-приложениями. Одно внутреннее приложение для отчетности отказывалось работать через современный прокси-шлюз, требуя прямой видимости IP-адреса клиента в локальной сети. Пришлось выносить его в исключения и строить для него отдельную, более жесткую политику доступа с устройствами только из офиса.
- Зависимость от интернета и провайдера IdP. Если у сотрудника дома упал интернет или временно недоступен сервис идентификации, доступ ко всем ресурсам пропадает. Нужен продуманный план аварийного доступа для критичных ролей.
- Невозможность частичного внедрения на некоторых направлениях. Отказаться от zero trust для одного приложения — значит создать дыру в концепции. Либо всё для отдела, либо ничего.
Как масштабировать успех на другие отделы
Успешный эксперимент на одном отделе, это не готовый план для всей компании, а мощный аргумент и детальная инструкция. Следующие шаги:
- Подготовить отчет с измеримыми метриками. Сократилось ли количество инцидентов безопасности в отделе? Насколько ускорился процесс онбординга? Как изменилась удовлетворенность сотрудников от работы из дома? Цифры убедят руководство лучше любых теорий.
- Создать «дорожную карту» внедрения. На основе опыта с отделом разработки спланируйте переход других департаментов в порядке возрастания сложности: отдел маркетинг (много SaaS) → отдел продаж (высокая мобильность) → финансы (строгие требования, но стабильные процессы). Отделы с промышленным оборудованием или критичными legacy-системами оставьте на последний этап.
- Сформировать внутреннюю команду внедрения. Включите в нее представителей успешного «пилотного» отдела, чтобы они делились опытом и снимали страхи коллег.
- Рассмотреть консолидацию инфраструктуры. Тот же шлюз приложений и сервис идентификации, скорее всего, сможет обслуживать несколько отделов. Это снизит удельную стоимость внедрения.
Главный вывод: zero trust, это не бинарное состояние «включено/выключено» для всей компании. Это постепенное движение от наиболее подготовленных и мотивированных ячеек организации к остальным, с постоянным накоплением знаний, упрощением процессов и снижением совокупной стоимости владения за счет роста безопасности и гибкости бизнеса.