Усиление безопасности браузера контролями нулевого доверия

Переход от периметровой безопасности к архитектуре нулевого доверия теперь необходим для борьбы с современными угрозами. Устаревшая модель «замок и ров», предоставляющая неявное доверие любому устройству или пользователю внутри сети, рухнула с ростом облачных технологий, удаленной работы и BYOD (Bring Your Own Device). Злоумышленники теперь обходят традиционные средства контроля, нацеливаясь на учетные записи, используя фишинг на основе искусственного интеллекта, вторжения в цепочку поставок и продвинутое перехватывание сеансов.

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

NIST SP 800-207 предоставляет модель: отделите доступ от сетевого местоположения с помощью политического движка, администратора политик и точки принудительного применения политик на основе браузера для обеспечения динамической авторизации, учитывающей контекст. NIST SP 800-207A расширяет это до управления в реальном времени в мультиоблачной среде и микросервисах. Одновременно Модель зрелости архитектуры нулевого доверия CISA v2 определяет четкий путь реализации, охватывающий пять направлений и подчеркивая автоматизацию, аналитику и управление как необходимые факторы успеха.

Этот журнал объединяет эти ведущие стандарты с текущими корпоративными практиками, предлагая комплексную архитектуру ZTA, ориентированную на браузер, которая сочетает в себе принцип наименьших привилегий, SSO/MFA, соответствие требованиям устройства и изоляцию сеансов для безопасного и приспособляемого функционирования.

Необходимость архитектуры нулевого доверия, ориентированной на браузер

Поскольку удаленная работа и внедрение облачных технологий становятся стандартной моделью работы, невозможность использования неявного сетевого доверия и устаревших VPN для устранения современных угроз очевидна. Злоумышленники теперь непосредственно нацеливаются на браузер с помощью таких атак, как межсайтовый скриптинг (XSS), перехватывание сеансов с использованием украденных токенов и продвинутый фишинг, который обходит традиционные MFA. Браузерно-ориентированная архитектура ZTA является необходимым ответом, основанным на следующих шести принципах.

1. Контроль доступа с приоритетом для личности

Близость к сети больше не является надежным сигналом доверия. Только федеративные, криптографически проверяемые токены личности, выданные централизованными корпоративными системами управления идентификацией (IdP) с использованием OIDC или SAML, могут использоваться для доступа к корпоративным ресурсам. Этот переход, подробно описанный FIDO Alliance и исследованиями Microsoft, переносит само понятие «внутри» организации из сети в проверенную личность пользователя. Ни один сеанс не запускается без подписанного, кратковременного утверждения о личности.

2. Предоставление доступа с наименьшими привилегиями (LPA)

Устаревшие роли, дающие постоянные привилегии, противоречат принципам архитектуры нулевого доверия. LPA предписывает минимизацию, ограничение по времени и контекстуальную зависимость прав доступа. Применение доступа «по требованию», ограничение области действия JWT-токенов и динамическая оценка рисков гарантирует, что пользователи получают только то, что необходимо для выполнения текущей задачи, и никогда больше. Состояние устройства, ценность ресурса и поведение регулируют привилегии в процессе: несоответствующее устройство или аномальная авторизация мгновенно сокращают область доступа.

3. Непрерывная проверка и адаптивная политика

Архитектура нулевого доверия — это не «аутентификация один раз, доверие навсегда». Это непрерывный цикл проверки. Адаптивные правила политики, выполняемые политическим движком, должны повторно оценивать доступ в режиме реального времени на основе новых телеметрических данных. Этот «сдвиг настроек» может быть вызван множеством сигналов:

• Поведенческий: Если пользователь обычно входит в систему из Техаса в 9 утра, но внезапно аутентифицируется из Восточной Европы в 3 часа ночи («невозможная поездка»), адаптивные правила помечают аномалию и ограничивают доступ.
• Устройство: Агент EDR обнаруживает вредоносный процесс, изменяя состояние здоровья устройства с «соответствующего» на «подверженный риску».
• Сеть: Пользователь переходит из доверенной корпоративной сети в общедоступную точку доступа Wi-Fi. В ответ политический движок может автоматически инициировать отзыв сеанса, потребовать дополнительное подтверждение подлинности (step-up MFA) или снизить сеанс до режима только для чтения.

4. Интегрированная устойчивая к фишингу аутентификация

Для защиты шлюза на основе личности сам метод аутентификации должен быть надежным. Традиционная MFA (например, SMS или одноразовые пароли) подвержена фишингу. Модель ZTA для браузера обязывает использовать устойчивую к фишингу MFA, в первую очередь через FIDO2/WebAuthn passkeys. Как указано в FIDO Alliance, passkeys — это стандарт W3C, который заменяет пароли криптографическими парами ключей. Закрытый ключ никогда не покидает устройство пользователя (например, YubiKey, безопасное хранилище телефона или TPM Windows Hello), что делает его невозможным для фишинга. Пользователь аутентифицируется с помощью простого биометрического сканирования или PIN-кода, обеспечивая беспрецедентную безопасность и превосходный пользовательский опыт. К 2025 году внедрение passkeys перейдет от стадии развития к стадии массового использования, а развертывания покажут время аутентификации менее двух секунд и доказанное снижение убытков, связанных с фишингом.

5. Блокировка доступа, основанная на состоянии устройства

Доверенный пользователь на скомпрометированном устройстве представляет собой критическую угрозу. Модель ZTA должна проверять конечную точку перед выдачей токена доступа. Эта «блокировка доступа на основе состояния устройства» является краеугольным камнем современных решений IdP. Движок политик условного доступа (Conditional Access Policy Engine) запрашивает у устройства сигналы о состоянии, собранные агентом MDM (управление мобильными устройствами) или EDR (обнаружение и реагирование на конечные точки). Как описано в framework условного доступа Microsoft, политики обеспечивают соответствие требованиям перед выдачей токена. Ключевые сигналы:

• Уровень патчей: Полностью ли обновлена операционная система?
• Статус EDR: Работает ли агент EDR (например, CrowdStrike, Defender) и сообщает ли о каких-либо активных угрозах?
• Шифрование диска: Зашифрован ли основной диск (например, BitLocker, FileVault)?
• Состояние устройства: Устройство подверглось взлому или root-доступу? Только устройства, отвечающие этим базовым требованиям, считаются «соответствующими» и имеют право на доступ.

6. Удаленная изоляция браузера (RBI)

Для операций с самым высоким риском мы должны исходить из предположения, что нельзя полностью доверять конечной точке и что веб-контент вреден. RBI решает эту проблему, выполняя рискованные или привилегированные веб-сеансы в изолированных, одноразовых контейнерах в облаке. Конечная точка пользователя никогда не взаимодействует с активным веб-кодом; она получает только поток пикселей (RBI на основе потоковой передачи пикселей) или обработанную версию страницы (RBI на основе реконструкции DOM). Как показано решениями ZTA, такими как Cloudflare RBI, это нейтрализует все эксплойты на основе браузера, предотвращает попадание вредоносного ПО на конечную точку и может обеспечивать предотвращение утечки данных (DLP), отключая копирование/вставку или загрузку из изолированной сессии.

Современные рабочие процессы и шаблоны политик: проект

Современная архитектура ZTA для браузера — это не отдельный продукт, а интегрированная система, которая работает в непрерывном цикле проверки на основе запроса.

Это фундаментальный пользовательский рабочий процесс для всего доступа.

1. Запрос: Пользователь в управляемом браузере (например, Chrome Enterprise) пытается получить доступ к защищенному приложению (например, test.company.com).
2. Перехват и перенаправление: Прокси-сервер доступа (ZTNA/PEP) перехватывает запрос. Увидев отсутствие допустимого токена сеанса, он перенаправляет браузер в корпоративный IdP (например, Okta, Entra ID) для начала потока аутентификации OIDC или SAML.
3. Аутентификация: IdP аутентифицирует пользователя. На основе политики он требует шаг дополнительной аутентификации с использованием устойчивого к фишингу MFA с помощью passkey FIDO2/WebAuthn. Пользователь касается своего YubiKey или использует Windows Hello.
4. Контекстная оценка: Движок политик (PE) IdP оценивает запрос. Он запрашивает у Microsoft Intune или интеграции CrowdStrike ZTA состояние устройства. Политика такова: РАЗРЕШИТЬ, если (user_group == «Sales») И (device_status == «Compliant») И (auth_method == «FIDO2»).
5. Выдача токена: После успешного завершения IdP генерирует подписанный JSON Web Token (JWT). Этот токен содержит важные утверждения: идентификатор (sub) пользователя, их роли (группы), метод аутентификации (amr) и кратковременное время истечения срока действия (exp).
6. Разрешен доступ: Браузер предоставляет JWT прокси-серверу, прокси-сервер предоставляет прямой, безопасный доступ к приложению.

B. Адаптивное управление сеансами и принцип наименьших привилегий

Этот рабочий процесс демонстрирует принцип «непрерывной проверки».

• Сдвиг состояния: Пользователь аутентифицирован и работает. В середине сеанса агент EDR обнаруживает угрозу высокого приоритета (например, выполнение вредоносного ПО). Агент EDR мгновенно обновляет состояние здоровья устройства. Действие Conditional Access IdP, которое использует протокол непрерывной оценки доступа (CAEP), получает этот сигнал и мгновенно отзывает все активные токены сеанса для этого устройства, выключая его и требуя устранения неполадок.
• Дополнительная аутентификация: Пользователь с действующим сеансом для приложения с низким уровнем риска (например, вики) нажимает ссылку на приложение с высоким уровнем риска (например, консоль администратора SAP). Прокси-сервер ZTNA (PEP) перехватывает этот новый запрос, распознает «Tier 0» чувствительность приложения и повторно вызывает пользователя, заставляя провести новую аутентификацию, используя passkey с аппаратным обеспечением, прежде чем продолжить, даже если у них уже есть активная сессия SSO.

C. Привилегированные и конфиденциальные операции через изоляцию

Этот рабочий процесс предназначен для защиты активов «Tier 0» типа администраторских консолей.

1. Запрос: Администратор пытается получить доступ к консоли администратора Okta или внутренней панели управления Kubernetes.
2. Принудительное применение политики: После успешной аутентификации FIDO2 политика (PEP) для этого приложения «Tier 0» настроена не на «Разрешить» действие, а на «Изолировать» действие.
3. Изоляция: Пользователь прозрачно перенаправляется в сервис RBI. Весь сеанс администратора выполняется в безопасном, одноразовом контейнере в облаке. На конечную точку пользователя передается только безопасный поток пикселей.
4. DLP и нейтрализация угроз: Это смягчает два критических риска:
   • Вредоносное ПО на конечной точке: если рабочая станция администратора скомпрометирована, кейлоггеры или вредоносное ПО для кражи токенов не могут получить доступ к привилегированной сессии, поскольку она не работает локально.
   • Утечка данных: Применяются политики RBI, обеспечивающие гранулярность: копирование/вставка, загрузка файлов и печать отключены для этой сессии, предотвращая случайную или злонамеренную утечку учетных данных или данных.

D. Дальновидное SCIM-предоставление

Этот рабочий процесс — это автоматизированный оплот, который делает LPA жизнеспособной в масштабе.

• System for cross-domain identity management (SCIM) — это открытый стандарт (RFC 7643) для автоматизации обмена информацией об идентификации пользователя между системами. Протокол SCIM (RFC 7643) определяет REST API и схему для управления ресурсами пользователя и группы.
• Рабочий процесс (Новоприбывший/Переезд/Уход):
  1. Источник события: Менеджер в HRIS (например, Workday) меняет роль сотрудника с «Менеджер по продажам» на «Старший менеджер по продажам».
  2. SCIM push: HRIS (или интеграционный слой) автоматически инициирует SCIM PATCH запрос в IdP.
  3. Обновление IdP: IdP обновляет атрибуты пользователя, удаляя их из группы:sales-rep и добавляя их в группу:sales-manager.
  4. Распространение политики: Движок политик (PE) IdP немедленно использует эти новые данные атрибутов.
  5. Повторная оценка: В следующий раз, когда пользователь аутентифицируется (или истекает срок действия токена), его доступ переоценивается. Их старый доступ к инструментам уровня отдела продаж прекращен, а новый доступ к панелям управления менеджеров автоматически предоставлен. Этот «доступ по требованию» предотвращает «накапливание привилегий» и гарантирует, что все решения о доступе основаны на точных, актуальных данных об идентификации.

Пути зрелости: дорожная карта к оптимальному состоянию

Эта дорожная карта, соответствующая CISA ZTMM v2, позволяет организациям достигать измеримого и постепенного прогресса.

• Начальный: На этом этапе организация выходит за рамки «Традиционной» границы. Все приложения, доступ к которым осуществляется через браузер, связаны с централизованным IdP и защищены прокси-сервером доступа (ZTNA). SSO и MFA на основе passkey FIDO2/WebAuthn обязательны для всех пользователей. Все журналы доступа централизуются в SIEM. Это обеспечивает основы идентичности и сети.
• Продвинутый: Организация строит на основе первоначального фундамента более богатый контекст. Принудительное соответствие требованиям устройства (через Intune/CrowdStrike) обеспечивается для всех сеансов. Решения политик становятся адаптивными, используя телеметрические данные в режиме реального времени от EDR и поведенческой аналитики пользователя (UBA). SCIM полностью реализован для автоматизированного предоставления из единого источника истины об идентичности (например, HRIS). Это демонстрирует зрелость в возможностях устройства и автоматизации.
• Оптимальный: На самом высоком уровне зрелости доступ определяется на основе запроса, с наименьшими привилегиями, полностью соответствуя NIST 800-207A. RBI автоматически и прозрачно применяется для всех привилегированных, неуправляемых или операций с высоким уровнем риска. Вся экосистема автоматизирована, при этом пост-аутентификационная безопасность (например, обнаружение кражи токенов и CAEP) полностью интегрирована. Это представляет собой оптимальное состояние по всем направлениям CISA, которое обусловлено надежной автоматизацией и управлением.

Практическое применение ZTA для безопасности браузера

Реализация этой архитектуры требует изменения операционного мышления.

• Проектирование политики: Перейдите от сетевых правил к логической модели «кто, что, где, когда, почему». Политики должны быть читаемыми утверждениями: ПРЕДОСТАВИТЬ доступ, если (user_group == «Finance») И (app == «SAP») И (device_status == «Compliant») И (auth_method == «FIDO2»). Начните с политики «запрета» и создавайте явные правила «разрешения», создавая матрицу политик, которая сопоставляет персонажи пользователей с данными и приложениями.
• Динамический доступ: Утверждения токена должны быть привязаны к контексту и иметь кратковременное действие. Токен, выданный для вики только для чтения, не должен быть действителен для доступа к финансовому приложению. Истинная устойчивость к фишингу требует исключения всех методов восстановления, подверженных фишингу. Это означает отказ от SMS, ссылок по электронной почте и вопросов безопасности в пользу восстановления на основе passkey или идентификации лично.
• Автоматизация рисков: Адаптация сеанса (дополнительное подтверждение, отзыв) должна запускаться автоматизированной аналитикой. Интегрируйте IdP и решение ZTNA с вашей SIEM/SOAR платформой. Сообщение EDR (например, «вредоносное ПО высокого приоритета») или сообщение UBA (например, «невозможная поездка») должны автоматически запускать плейбук SOAR, который вызывает API IdP для отзыва токенов сеанса пользователя.
• Управление политикой как код: Политики не должны управляться вручную через GUI «клик-операции». Все правила доступа ZTNA, политики условного доступа IdP и конфигурации RBI должны быть определены как код (например, с использованием Terraform, HCL или JSON). Это позволяет управлять версиями, проводить проверки с помощью одноранговых запросов и автоматизировать конвейеры CI/CD, что соответствует требованиям CISA к управлению и автоматизации.

Шаблоны конфигурации (последние, 2025 г.)

• Chrome Enterprise: Используйте Chrome Browser Cloud Management для обеспечения безопасной базовой конфигурации на всех корпоративных браузерах. Принудительно применяйте политики, такие как BrowserSignin (чтобы принудительно выполнить вход в управляемый профиль), PasswordManagerEnabled (установите значение false, чтобы обязать использовать корпоративный менеджер паролей), SafeBrowsingProtectionLevel (установите значение Enhanced) и BuiltInDnsClientEnabled (чтобы принудительно применять безопасный DNS). Политики Chrome Enterprise от Google предоставляют полный список элементов управления для управления расширениями, утечкой данных и настройками безопасности.
• Intune/условный доступ: Создайте «базовую» политику, которая не подлежит обсуждению: требуется соответствующее устройство и требуется устойчивая к фишингу MFA для всех пользователей, получающих доступ ко всем облачным приложениям. Затем создайте более гранулярные политики. Например, полностью заблокируйте доступ из стран с высоким уровнем риска или потребуйте «Соответствующее + гибридное подключенное» устройство для доступа к устаревшим приложениям на месте.
• FIDO2/WebAuthn passkeys: Развертывайте passkeys (платформенно-зависимые, такие как Windows Hello, и аппаратно-зависимые, такие как YubiKeys) в качестве основного аутентификатора. Начните с привилегированных пользователей (администраторов) и целевых пользователей с высокой ценностью (руководители, финансы), а затем распространите это на всех остальных пользователей.
• Cloudflare RBI/ZTNA: Настройте ZTNA без агента для защиты доступа сторонних и BYOD без требования агента. Используйте политики Service Auth (на основе сертификатов mTLS или сервисных токенов) для защиты доступа к веб-приложениям непрофессиональными (RPA-ботами). Настройте политику «изоляции по умолчанию», которая автоматически направляет весь трафик в неклассифицированные или рискованные веб-домены через сервис RBI.
• SCIM-автоматизация: Подключите свой IdP (Okta, Entra ID) к источнику истины (например, Workday) с помощью предварительно созданного коннектора SCIM. Сопоставьте атрибуты HR (например, Отдел, Должность, Статус занятости) с атрибутами IdP. Используйте эти атрибуты для управления динамическим членством в группах, которое, в свою очередь, управляет всеми доступом к приложениям и политиками ZTNA.

Браузер теперь как меч и щит

Безопасность браузера является краеугольным камнем архитектуры нулевого доверия и организационной устойчивости. Объединяя проверенную личность, строгую осанку устройства, адаптивные политики доступа, автоматизированное предоставление и изоляцию сеансов, мы не только защищаемся от сложных угроз 2025 года, но и создаем основу для масштабируемого и измеримого управления.

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

Внедрение этой архитектуры — это путешествие: начните с SSO и надежной MFA, обеспечьте соответствие требованиям устройства, автоматизируйте предоставление и интегрируйте RBI, когда риск оправдывает изоляцию. Кодируйте политику, автоматизируйте телеметрию и разрабатывайте управление как код. Откажитесь от мифа о «доверенной сети». Архитектура нулевого доверия здесь, и браузер теперь как меч и щит.

Эта статья опубликована в рамках сети экспертов Foundry Contributor Network.
Хотите присоединиться?