Источник

В начале 2020 года Национальный институт стандартов и технологий США (NIST) опубликовал черновик второй редакции документа, в котором рассматриваются основные логические компоненты архитектуры с нулевым доверием (Zero Trust Architecture, ZTA).

Нулевое доверие (Zero Trust) относится к развивающемуся набору парадигм сетевой безопасности, в основе которых лежит принцип «никому ничего не доверяй». В отличии от классических подходов, уделяющих больше внимания защите периметра, модель Zero Trust акцентируется на безопасности ресурсов, а не сегментов сети предприятия.

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

Zero Trust: начало

Первый проект ZTA от NIST появился в сентябре 2019 года, хотя концепция нулевого доверия существовала в кибербезопасности задолго до появления самого термина «нулевое доверие».

Агентство оборонных информационных систем (DISA) и Министерство обороны США в 2007 года опубликовали работу, посвященную безопасной стратегии предприятия. Данная стратегия, получившая название «Черное ядро», предусматривала переход от модели безопасности на основе периметра к модели, ориентированной на безопасность отдельных транзакций.

В 2010 году главный аналитик Forrester Research Джон Киндерваг для описания различных решений, меняющих фокус восприятия угроз (от безопасности, построенной на стратегии защиты периметра, к контролю над всеми имеющимися данными), сформулировал термин «нулевое доверие».

Модель Zero Trust стала попыткой решения классической проблемы, когда проникнувший в сеть злоумышленник получает доступ ко всем ее компонентам. Достаточно сказать, что, по данным Microsoft Vulnerabilities Report, последствия 88 % критических уязвимостей можно было бы устранить или, как минимум, смягчить, лишив пользователей админских прав.

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

Модель нулевого доверия

Для развертывания модели Zero Trust необходимо распределить минимальные привилегии доступа и максимально детализировать пакеты с данными. В модели с нулевым доверием вы определяете «защищаемое пространство», состоящее из наиболее важных и ценных данных и ресурсов, и фиксируете маршруты трафика по организации с точки зрения их отношения к защищаемым ресурсам.

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

Отличительной особенностью архитектуры Zero Trust является большое внимание к аутентификации и авторизации до предоставления доступа к каждому ресурсу компании. При этом требуется минимизация временных задержек в механизмах аутентификации.

На рисунке представлена абстрактная модель предоставления доступа в ZTA.


В модели пользователю (или устройству) необходимо получить доступ к корпоративному ресурсу через «контрольно-пропускной пункт». Пользователь проходит проверку через точку принятия решения о доступе на основе политики безопасности (Policy Decision Point, PDP) и через точку реализации политики (Policy Enforcement Point, PEP), отвечающую за вызов PDP и правильную обработку ответа.

Идея в том, чтобы переместить точку применения политики как можно ближе к приложению. PDP/PEP не может применять дополнительные политики за пределами своего местоположения в потоке трафика.

Принципы нулевого доверия

Приведем семь основных принципов ZT и ZTA (в сокращенном виде), которые должны учитываться при построении безопасной системы. Данные принципы являются «идеальной целью», однако не все из них могут быть полностью реализованы в каждом конкретном случае.

1. Все источники данных и услуг считаются ресурсами. Сеть может состоять из нескольких устройств разного класса. Компания вправе классифицировать личные устройства в качестве ресурсов, если они могут получить доступ к данным и услугам, принадлежащим предприятию.
2. Все коммуникации защищены независимо от их местоположения в сети. Доверие не может быть связано с местоположением. Запросы на доступ от пользователей, расположенных в сетевой инфраструктуре предприятия (например, внутри традиционного периметра), должны отвечать тем же требованиям безопасности, что и запросы, поступающие из любой другой сети. Коммуникации должны осуществляться максимально безопасным способом, обеспечивать конфиденциальность и аутентификацию источника.
3. Доступ к отдельным корпоративным ресурсам предоставляется для каждой сессии. Аутентификация и авторизация для одного ресурса не дают доступ к другому.
4. Доступ к ресурсам определяется динамической политикой, включая наблюдаемое состояние идентификации клиента, приложения и других атрибутов (например, измеряемых отклонений в наблюдаемой модели использования). Политика — это набор правил доступа, основанных на атрибутах, которые организация назначает пользователю, ресурсу или приложению.
5. Предприятие гарантирует максимально безопасное состояние всех принадлежащих ему устройств, и отслеживает активы, чтобы гарантировать их максимальную безопасность. «Максимально возможное безопасное состояние» означает, что устройство находится в наиболее практичном безопасном состоянии и все еще выполняет действия, соответствующие его миссии.
6. Все ресурсы аутентификации и авторизации являются динамическими и строго контролируются. Это постоянный цикл получения доступа, мониторинга и оценки угроз, адаптации и переоценки доверия к текущей связи. Предполагается, что предприятие, реализующее ZTA, будет иметь все необходимые системы управления учетными данными, активами и доступом, включая многофакторную аутентификацию.
7. Предприятие собирает максимум информации о текущем состоянии сетевой инфраструктуры и коммуникаций, используя ее для повышения собственной безопасности, а также данные о сетевом трафике и запросах доступа, необходимые для улучшения создания и применения политики.

Компоненты архитектуры

Здесь для удобства приводится не оригинальный рисунок NIST, а версия из статьи Cisco «Making a Deliberate Cybersecurity Lifestyle Choice»

Существует множество логических компонентов, из которых формируется архитектура Zero Trust на предприятии. Эти компоненты могут работать как локальная служба или через облако. На рисунке выше представлена «идеальная модель», демонстрирующая логические компоненты и их взаимодействие.

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

При инициировании пользователем (субъектом) процедуры аутентификации, цифровая идентификация строится вокруг него. На рисунке эта процедура представлена с блока Subject. Еще один термин для такого пользователя — принципал (Principal), то есть клиент, для которого разрешается аутентификация.

Представленная выше схема сети делится на несколько уровней трафика. Уровень управления (Control Plane) отделяется от другой части сети, которая может быть видна пользователю. С точки зрения принципала существует только уровень данных этой сети.

На Control Plane находится точка принятия решения о доступе (PDP), состоящая из двух логических компонентов:

• Policy Engine (PE), отвечающего за решение о предоставлении доступа к ресурсу для данного субъекта. Данный компонент использует политику предприятия, а также входные данные из внешних источников (например, службы анализа угроз) для предоставления, отклонения или отзыва доступа к ресурсу;
• Policy Administrator (PA), отвечающего за установление и/или закрытие канала связи между субъектом и ресурсом. При создании канала связи он связывается с Policy Enforcement Point (PEP), который находится на уровне данных (Data Plane).

PEP отвечает за включение, мониторинг, вызов PDP и правильную обработку его ответа, и, в конечном итоге, за разрыв соединений между субъектом и корпоративным ресурсом. За пределами PEP находится неявная зона доверия, в которой размещен корпоративный ресурс.

Все остальные поля (на рисунке слева и справа) демонстрируют компоненты безопасности, которые могут представлять информацию, необходимую для принятия решения о доступе в PDP/PEP. К ним относится, к примеру, система непрерывной диагностики и мониторинга (CDM), собирающая информацию о текущем состоянии активов предприятия.

Идентификация и микросегментация

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

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

Предприятие может защищать ресурсы в своем собственном сегменте сети устройствами Next-Generation Firewall (NGFW), используя их в качестве Policy Enforcement Point. NGFW динамически предоставляют доступ по отдельным запросам от клиентов. Этот подход применяется к различным случаям использования и моделям развертывания, поскольку защитное устройство действует как PEP, а управление этими устройствами — как компонент PE/PA.

Для реализации ZTA также можно использовать оверлейные сети. Такой подход иногда называют моделью с программно-определяемым периметром (SDP) и часто включает в себя концепции из программно-определяемой сети (SDN). Здесь Policy Administrator действует как сетевой контроллер, который устанавливает и реконфигурирует сеть на основе решений, принятых Policy Engine.

Основные сценарии развертывания

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

В этой схеме сотрудникам, работающим удаленно, по-прежнему требуется полноценный доступ к корпоративным ресурсам, и блок PE/PA часто развертывается в виде облачной службы.


По мере перехода предприятия на большее количество облачных приложений и сервисов, подход с нулевым доверием требует размещения PEP в точках доступа каждого приложения и источника данных. PE и PA могут быть расположены в облаке, либо даже у третьего облачного провайдера (за пределами Cloud Provider A и Cloud Provider B).


Другой распространенный сценарий — предприятие с посетителями и/или контрактниками, которым требуется ограниченный доступ к корпоративным ресурсам. В этом примере организация также имеет конференц-центр, где посетители взаимодействуют с сотрудниками.

С помощью подхода ZTA Software-Defined Protection посетители могут выйти в интернет, но не могут получить доступ к корпоративным ресурсам. Порой они даже не имеют возможности обнаруживать корпоративные сервисы посредством сканирования сети.

Здесь PE и PA могут быть размещены в виде облачной службы или в локальной сети. PA гарантирует, что все активы, не принадлежащие предприятию, получат доступ к интернету, но не к локальным ресурсам.

Семь рисков реализации Zero Trust

Воздействие на процесс принятия решений

В ZTA компоненты Policy Engine и Policy Administrator являются ключевыми для всего предприятия. Любой администратор, имеющий доступ к настройкам правил PE, может вносить несанкционированные изменения или совершать ошибки, которые нарушат работу. Скомпрометированный PA может предоставить доступ ко всем защищенным ресурсам. Для снижения рисков компоненты PE и PA должны быть правильно настроены и проверены.

Отказ в обслуживании

PA является ключевым компонентом для доступа к ресурсам — без его разрешения невозможно установить связь. Если в результате DoS-атаки или перехвата трафика злоумышленник нарушает или запрещает доступ к PEP или PA, это может отрицательно повлиять на работу предприятия. У предприятия есть возможность смягчить угрозу, разместив PA в облаке или реплицировав его в нескольких местах.

Украденные учетные данные

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

Видимость в сети

Часть трафика (возможно, бoльшая) в сети предприятия может быть непрозрачной для традиционных инструментов сетевого анализа. Это не означает, что предприятие не в силах анализировать зашифрованный трафик — можно собирать метаданные и использовать их для обнаружения подозрительной активности. Методы машинного обучения позволяют исследовать трафик на глубоком уровне.

Хранение сетевой информации

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

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

Опора на собственные форматы данных

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

Как и DoS-атаки, этот риск не является уникальным для ZTA, но поскольку ZTA сильно зависит от динамического доступа к информации, нарушение может повлиять на основные бизнес-функции. Для снижения рисков предприятиям следует оценивать поставщиков услуг на комплексной основе.

Допуск объектов, не являющихся физическим лицом (Non-Person Entity, NPE), к компонентам управления

Нейросети и другие программные агенты используются для управления проблемами безопасности в корпоративных сетях и могут взаимодействовать с критически важными компонентами ZTA (например, Policy Engine и Policy Administrator). Остается открытым вопрос аутентификации NPE на предприятии с ZTA. Предполагается, что большинство автоматизированных технологических систем для доступа к API все же будут использовать какие-то средства аутентификации (например, код API Key).

Наибольший риск при использовании автоматизированной технологии для настройки и применения политик — это вероятность ложноположительных (безобидные действия, ошибочно принятые за атаки) и ложноотрицательных (атаки, ошибочно принятые за нормальную активность) реакций. Их число можно уменьшить с помощью регулярного анализа реакций.

Заключение

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

Для дальнейшего изучения темы применения концепции Zero Trust обратите внимание на следующие материалы:

• «Zero Trust Networks: Building Secure Systems in Untrusted Networks»;
• «Building Zero Trust networks withMicrosoft 365»;
• «Insider Threat Monitoring for Zero Trust with Microsoft Azure»;
• и, конечно, Draft (2nd) SP 800-207, Zero Trust Architecture.