«Классическая безопасность «крепостью» не работает, потому что периметра больше нет. Но вместо того, чтобы пытаться воссоздать его, Zero Trust предлагает проверять каждый запрос в реальном времени по контексту: кто, с какого устройства, в какое время и что пытается сделать. Это позволяет не блокировать бизнес, а обеспечивать безопасный доступ там, где это нужно. Когда я внедряю отечественный сервис, я не встраиваю его в «доверенную зону», а просто подключаю его к системе контроля доступа, которая проверяет каждую сессию.»
Как Zero Trust убирает барьеры вместо того, чтобы их строить
Классическая модель безопасности была построена на физическом контроле. Данные и приложения находились внутри корпоративной сети, а доступ извне обеспечивался через защищённые каналы вроде VPN. Внутренняя сеть считалась «доверенной зоной». Эта модель работала, пока большинство сотрудников работали в офисе, а бизнес-сервисы располагались в локальных дата-центрах.
Сегодня эта архитектура не просто устарела — она стала фактором риска. Периметр распался. Сотрудники работают из любой точки страны, подключаясь с личных и корпоративных устройств. Сервисы размещаются в частных и публичных облаках, часто у разных поставщиков. Понятия «внутри сети» больше не существует.
VPN превращается в уязвимость. Когда пользователь подключается через VPN, его устройство, по сути, получает пропуск во «внутреннюю крепость». Если это устройство скомпрометировано, злоумышленник получает широкие возможности для горизонтального перемещения по сети. Проблема усугубляется тем, что весь трафик удалённых пользователей принудительно направляется через центральный узел, создавая задержки и снижая производительность работы с облачными сервисами.
Старая модель порождает инерцию. Каждое новое подключение, каждый импортозамещаемый сервис требует ручного настройки правил межсетевого экрана, открытия портов, согласования в комитетах по безопасности. Это занимает недели, пока бизнес ждёт возможности начать работу. В условиях постоянной смены поставщиков и миграции данных такая скорость неприемлема. В итоге администраторы безопасности оказываются перед выбором: либо разрешить доступ с риском, либо заблокировать инициативу бизнеса.
Почему «крепость» с VPN и периметром уже не защищает, а мешает
Архитектура периметральной безопасности основана на предположении, что угроза приходит извне. Но большинство инцидентов сегодня инициируются изнутри — либо действиями инсайдеров, либо через скомпрометированные устройства, которые уже получили доступ в «доверенную» зону. Фактически, VPN и внутренние правила создают ложное чувство безопасности.
Концентрация трафика через VPN-шлюз делает его узким местом и единой точкой отказа. Производительность падает, особенно при работе с графическими интерфейсами или передаче больших файлов. При этом современные облачные приложения часто используют распределённые CDN, и маршрутизация всего трафика через центральный офис противоречит их архитектуре.
При импортозамещении проблемы усугубляются. Новый отечественный CRM может не иметь фиксированных IP-.адресов, использовать динамическое масштабирование или размещаться у провайдера, с которым нет прямого пиринга. Попытка «вписать» такой сервис в старую модель безопасности через статические правила межсетевого экрана обречена на провал или приводит к созданию опасных исключений.
В результате модель «крепости» защищает не данные, а устаревшую инфраструктуру, становясь главным препятствием для цифровой трансформации и перехода на отечественное ПО.
Как Zero Trust работает на практике, а не на бумаге
Концепция Zero Trust отвергает саму идею доверенной сети. Её базовый принцип: «Никогда не доверяй, всегда проверяй». Это не протокол или конкретный продукт, а архитектурный подход, при котором каждый запрос на доступ к ресурсу должен быть аутентифицирован, авторизован и непрерывно проверяем на основе контекстной информации.
Внедрение начинается с отказа от предположения, что внутренняя сеть безопасна. Доступ предоставляется не на основе расположения пользователя (внутри корпоративной сети), а на основе совокупности атрибутов: личности пользователя, состояния устройства, приложения, запрашиваемого ресурса и текущего поведенческого контекста.
От периметра к микросетям
Вместо единой защищённой зоны сеть делится на микросети. Это не просто VLAN, а логические сегменты, построенные вокруг отдельных приложений или групп данных. Например, база данных с персональными данными клиентов находится в изолированном сегменте, куда могут обращаться только определённые серверы приложений, и только по строго определённым портам и протоколам.
Правила доступа между этими микросетями настраиваются детально, по принципу наименьших привилегий. Сервер веб-.приложения может взаимодействовать с сервером приложений, но не может напрямую обращаться к базе данных. Это предотвращает горизонтальное перемещение злоумышленника в случае компрометации одного из компонентов.
Контекстная авторизация вместо статических правил
Ключевой элемент — решение о предоставлении доступа принимается не разово при входе, а непрерывно в течение всей сессии. Система безопасности агрегирует данные из множества источников:
- Системы управления идентификацией и доступом
- Агенты безопасности на конечных точках
- Журналы активности приложений
- Службы информации об угрозах
На основе этих данных вычисляется уровень риска сессии. Например, попытка доступа к финансовой отчётности в 3 часа ночи с нового устройства из другого региона вызовет запрос многофакторной аутентификации или будет полностью заблокирована. В то же время, стандартный доступ к корпоративному порталу в рабочее время с проверенного ноутбука пройдёт незаметно для пользователя.
Этот подход позволяет динамически адаптировать уровень контроля к реальной ситуации, а не полагаться на жёсткие, раз и навсегда установленные правила.
Zero Trust как катализатор импортозамещения, а не его враг
Переход на отечественное программное обеспечение часто воспринимается как дополнительный фактор риска и сложности для отдела информационной безопасности. Новые сервисы могут не иметь встроенных интеграций с корпоративными системами SSO, их API могут быть недокументированы, а архитектура — не соответствовать ожиданиям.
Zero Trust меняет этот парадигму. Вместо того чтобы пытаться «встроить» новый отечественный сервис в старую модель безопасности, вы подключаете его к системе контекстного контроля доступа как ещё один ресурс, не отличая его принципиально от других.
Единая политика для любого ресурса
Неважно, где физически расположен ресурс: в локальном дата1-центре компании, в частном облаке или у российского SaaS-провайдера. Политика доступа к нему формулируется на языке атрибутов, а не сетевых правил.
| Критерий | Пример политики | Применение к импортозамещению |
|---|---|---|
| Пользователь | Должен быть членом группы «Бухгалтерия» в Active Directory. | Работает для любого приложения, интегрированного с корпоративным IDP, независимо от его происхождения. |
| Устройство | Должно иметь установленный агент EDR и последние обновления ОС. | Контролирует доступ с любых устройств к любым ресурсам. |
| Время | Доступ разрешён только с 09:00 до page 18:00 по московскому времени. | Позволяет ограничить использование новых, не до конца проверенных сервисов рабочими часами. |
| Действие | Запрет на массовое скачивание файлов (>100 за сессию). | Снижает риск утечки данных при работе с новыми платформами, где процессы аудита ещё не отлажены. |
внедрение нового CRM или BI-инструмента сводится не к настройке межсетевых экранов, а к добавлению этого приложения в единый каталог ресурсов и назначению ему соответствующих политик доступа. Поставщик может менять свою инфраструктуру, масштабироваться — политики безопасности от этого не пострадают, так как они не привязаны к IP-адресам.
Компенсация недостатков новых решений
Отечественные решения на ранних этапах развития могут иметь уязвимости или недостаточные возможности аудита. Zero Trust позволяет компенсировать эти риски на уровне доступа.
Например, если в новом файловом хранилище нет встроенного DLP, можно настроить политику, запрещающую загрузку файлов с определёнными ключевыми словами в именах или определённых типов (например, архивов). Если система не поддерживает детальное логирование, можно обязать доступ к ней только с устройств, где включена полная запись сессии через агенты EDR.
Это создаёт безопасную «песочницу» для эксплуатации новых, возможно, незрелых решений, не ставя под угрозу всю инфраструктуру.
Что сотрудники получат вместо новых сложностей
Сотрудники часто воспринимают ужесточение мер безопасности как дополнительные препятствия в работе. Zero Trust, при правильной реализации, должен дать обратный эффект — сделать доступ более простым и seamless.
В идеальном сценарии сотрудник видит единый портал приложений. Он один раз входит в систему в начале дня (или даже сессии аутентификации продлевается автоматически). В этом портале собраны все необходимые ему ресурсы: и старые внутренние системы, и новые облачные сервисы, и импортозамещённые платформы. Нажав на иконку, он получает доступ, не задумываясь о VPN, паролях или расположении ресурса.
Это достигается за счёт:
- Единого входа: Интеграция всех систем, в том числе новых отечественных, с корпоративным провайдером идентификации по протоколам SAML или OIDC.
- Прозрачной аутентификации: Использование биометрии, аппаратных ключей или push-уведомлений в мобильном приложении вместо запоминания паролей.
- Адаптивного контроля: Большинство рутинных действий не требует дополнительных подтверждений. Дополнительные проверки включаются только при аномальном поведении, о котором пользователь может даже не знать.
Пользователь перестаёт ощущать границы между «внутренним» и «внешним», между «старым» и «новым» ПО. Он просто работает. При этом его сессия непрерывно оценивается на предмет рисков, а его действия логируются для последующего аудита. Безопасность становится невидимой и ненавязчивой, но при этом более эффективной.
С чего начать внедрение, чтобы не забросить проект
Попытка внедрить Zero Trust «сверху вниз», сразу на всю инфраструктуру, почти гарантированно приведёт к провалу. Это комплексная архитектурная трансформация, которую нужно проводить итеративно, начиная с самых критичных или показательных областей.
Этап 1: Инвентаризация и классификация
Первый шаг — понять, что именно вы защищаете. Составьте полный каталог корпоративных активов: приложения, данные, системы. Классифицируйте их по уровню критичности и чувствительности. Например:
- Уровень 1 (Критичный): Системы финансовой отчётности, базы персональных данных, репозитории с исходным кодом продуктов. Утечка или компрометация приведёт к прямым огромным финансовым потерям или остановке бизнеса.
- Уровень 2 (Важный): Системы управления взаимоотношениями с клиентами, внутренний документооборот, почта. Компрометация нанесёт значительный репутационный и операционный ущерб.
- Уровень 3 (Операционный): Вспомогательные сервисы, тестовые среды, порталы для сотрудников. Риски здесь в основном операционные.
Эта классификация станет основой для расстановки приоритетов в защите.
Этап 2: Выбор пилотной зоны
Не начинайте с самых критичных систем уровня 1. Первая ошибка на них будет слишком дорогой. Выберите для пилота систему уровня 2, которая при этом:
- Активно используется
- Имеет чёткого бизнес-владельца, который заинтересован в улучшениях
- Доступна извне (чтобы отработать сценарии без VPN)
- Интегрируется с корпоративным IDP
Хорошим кандидатом часто становится система электронного документооборота или корпоративный портал.
Этап 3: Внедрение базовых компонентов
Для пилотной зоны разверните и настройте ключевые компоненты:
- Шлюз доступа: Решение, которое будет выступать точкой входа для пользователей, проверяя аутентификацию и контекст перед доступом к приложению.
- Интеграция с IDP: Настройте единый вход для пилотного приложения.
- Сбор контекста: Подключите шлюз к системам, предоставляющим данные о пользователях и устройствах.
- Базовые политики: Создайте начальные правила доступа на основе ролей, времени и состояния устройства.
Запустите пилот для ограниченной группы пользователей. Соберите фидбек об удобстве и производительности.
Этап 4: Расширение и адаптация
На основе опыта пилота доработайте политики и процессы. Затем начинайте постепенно подключать другие приложения, двигаясь от менее к более критичным. Копируйте и адаптируйте успешные политики.
Ключ к успеху — не пытаться заменить всю инфраструктуру разом, а интегрировать новые механизмы контроля с уже существующими системами: Active Directory, VPN, межсетевыми экранами. Zero Trust не должен ломать то, что работает, — он должен добавлять новые, более тонкие слои контроля поверх существующей инфраструктуры, постепенно беря на себя всё больше функций.
Итогом такой итеративной работы становится архитектура, где безопасность не противостоит гибкости и скорости бизнеса, особенно критичным при импортозамещении, а становится их естественным продолжением. Доступ предоставляется быстрее, потому что он точечный и обоснованный. Риски снижаются, потому что контроль непрерывный и контекстный. Вместо того чтобы быть сдерживающим фактором, информационная безопасность начинает работать как катализатор цифровой трансформации.