| Слушать на Google Podcasts | Слушать на Mave | Слушать на Яндекс Музыке |
Руслан Рахметов, Security Vision
В современном цифровом мире киберугрозы эволюционируют настолько быстро и приобретают такие масштабы, что специалисты и методологи информационной безопасности вынуждены регулярно пересматривать концепции и парадигмы защиты информации. Периодически, раз в 2-3 года, на рынке средств защиты информации появляется новый класс продуктов, обещающий защиту от новейших киберугроз: так было с Next Generation Firewall (межсетевые экраны нового поколения), с системами DLP (решения для предотвращения утечек данных), с SIEM-системами и далее с решениями по защите облачных платформ, системами выявления аномалий, платформами для работы с данными киберразведки.
В нашей текущей публикации речь пойдет об относительно новой концепции "Zero Trust Architecture" («Архитектура нулевого доверия»), подразумевающей доскональную непрерывную проверку всех субъектов доступа (пользователи, сущности, устройства) вне зависимости от их местоположения (корпоративная сеть, интернет, удаленная работа через VPN). Данный подход описан в документе NIST SP 800-207 "Zero Trust Architecture" («Архитектура нулевого доверия»), который содержит описание концепции создания сетевой архитектуры по принципу нулевого доверия и примеры её использования для повышения информационной безопасности предприятия.
Итак, концепция непрерывной проверки и аутентификации всех субъектов сетевого доступа родилась уже достаточно давно - компания Cisco говорила и правильности такого подхода еще в начале 2000-х годов. Со временем многие СЗИ реализовали свои варианты данного подхода, например, в виде «условного доступа» (англ. conditional access), когда для аутентификации и получения доступа к корпоративным ресурсам сотруднику недостаточно ввести корректные логин и пароль: устройство пользователя должно отвечать определенным критериями (версия ОС, установленные обновления безопасности, работающий антивирус), подключаться из определенного географического региона (например, из стран, в которых у компании есть офисы), а также не иметь незакрытых инцидентов информационной безопасности (на данном устройстве или у данного пользователя). Кроме того, может учитываться время подключения (рабочее или неурочное время), история устройства (как давно оно успешно подключалось к корпоративной сети), наличие корректного второго фактора аутентификации (например, цифрового сертификата устройства), данные из систем киберразведки (анализ внешнего IP-адреса и хэшей запущенных исполняемых файлов подключающегося устройства).
В документе NIST SP 800-207 указано, что в архитектуре нулевого доверия (сокращенно ZTA, Zero Trust Architecture) аутентификация и авторизация субъектов доступа выполняется до установления сетевого соединения с корпоративными ресурсами, а применять ZTA можно для эффективного обеспечения кибербезопасности ИТ-активов (данных, сервисов, учетных записей, бизнес-процессов) при удаленной работе, использовании BYOD-концепции и при работе с облачными платформами. Концепция соответствует трендам современного состояния киберпространства, в котором больше нет сетевых периметров, а пользователи получают доступ к рабочим ресурсам с разных устройств и из разных географических точек. При этом субъектам доступа должны быть предоставлены гранулированные, минимально необходимые права доступа, а вся корпоративная сеть может считаться изначально недоверенной, т.е. вероятно ранее скомпрометированной - это допущение помогает выстроить логическую модель угроз в ZTA-концепции. Иначе говоря, для каждого субъекта доступа (пользователи, сущности, устройства) непрерывно выполняются проверки их аутентичности и прав доступа, только после этого устанавливается контролируемое сетевое соединение по определенному порту, протоколу и к определенному IP-адресу назначения внутри корпоративной сети.
В соответствии с публикацией NIST SP 800-207, принципы архитектуры нулевого доверия заключаются в следующем:
1. Все источники данных и вычислительные сервисы считаются ИТ-ресурсами (объектами доступа), включая личные устройства сотрудников, которые подключаются к корпоративной сети.
2. Защите подлежат все коммуникации вне зависимости от их сетевого расположения: нельзя автоматически доверять устройству только потому, что оно находится в пределах корпоративного сетевого периметра. При этом все сетевые взаимодействия должны быть защищены с сохранением конфиденциальности, целостности, аутентичности источника сетевого подключения.
3. Доступ к определенным корпоративным ресурсам предоставляется только в рамках одной сетевой сессии: запрашивающее доступ устройство должно быть проверено перед предоставлением доступа, а сам доступ - предоставлен с минимально необходимыми для выполнения бизнес-задачи правами. Аутентификация и авторизация на одном ресурсе не должна автоматически давать доступ к другому ресурсу.
4. Доступ к ресурсу контролируется динамической политикой, включающей проверку состояния идентификации клиента (субъекта доступа), состояние приложения или сервиса, состояние запрашиваемого ресурса, а также иные поведенческие атрибуты и метаданные. Данные о состоянии субъекта доступа (устройства, подключающегося к ресурсу) могут включать в себя данные о ПО, сетевое расположение устройства, дата и время запроса на доступ к ресурсу, поведенческие характеристики устройства, учетные данные устройства, также могут анализироваться данные об отклонении в поведении устройства от заранее установленного порогового уровня.
5. Производится контроль и мониторинг состояния кибербезопасности всех ИТ-активов, отсутствует доверие «по умолчанию».
6. Все процедуры аутентификации и авторизации субъектов доступа являются обязательными и динамическими, выполняющимися непрерывно на протяжении всего периода доступа.
7. Организация собирает максимум информации об актуальном состоянии активов, сетевой инфраструктуре, сетевом взаимодействии и использует эти данные для повышения уровня киберзащищенности.
В документе NIST SP 800-207 также озвучены и новые киберриски, появляющиеся при внедрении ZTA-концепции, такие как:
1. Подделка процедуры аутентификации и принятия решения о доступе к сети: кибератака или злонамеренные действия инсайдера могут привести к несанкционированному сетевому доступу со стороны вредоносного устройства или сущности.
2. Отказ в обслуживании или сетевой сбой: механизмы аутентификации и принятия решения о доступе к сети могут стать единой точкой отказа в сетевой связности компании.
3. Кража учетных данных может привести к несанкционированному сетевому доступу со стороны вредоносного устройства или сущности; для минимизации данного киберриска можно использовать мультифакторную аутентификацию и поведенческий анализ.
4. Видимость сети: при передаче шифрованного трафика компания не сможет адекватно анализировать передающиеся данные и предотвращать киберугрозы; для повышения качества анализа такого трафика можно применять методы машинного обучения или механизмы SSL/TLS-инспекции.
5. Хранение сетевой и системной информации: компоненты ZTA-архитектуры содержат в себе множество ценной информации, которая может стать целью хакеров.
6. Зависимость от конкретных вендоров и решений: при выходе из строя оборудования для ZTA или при смене вендора компания может столкнуться с серьезными сетевыми сбоями и простоями.
7. Использование служебных (машинных) сущностей при администрировании ZTA приводит к угрозе несанкционированного использования аутентификационных данных (например, API-токенов) таких служебных сущностей.
Для внедрения ZTA-архитектуры документ NIST SP 800-207 рекомендует выполнить следующие действия:
1. Определить всех субъектов доступа (пользователи, сущности, устройства), которым надо будет предоставлять доступ к ИТ-активам с помощью модели ZTA.
2. Определить ИТ-активы компании (провести инвентаризацию).
3. Определить ключевые бизнес-процессы и оценить их киберриски для поэтапного внедрения ZTA от менее критичных процессов к более критичным.
4. Выработать политики аутентификации и принятия решения о доступе к сети для выбранных бизнес-процессов.
5. Выбрать подходящее техническое решение для реализации ZTA-подхода.
6. Провести пилотное внедрение и осуществлять мониторинг работы ZTA-решения для выбранных бизнес-процессов; возможно, провести пилотирование в режиме аудита (без блокировок).
7. Расширить границы проекта внедрения ZTA на другие бизнес-процессы.
