Эта статья — продолжение серии статей, опубликованных в этом блоге, в которых мы пытаемся отслеживать влияние новых технологических трендов на пересечении кибербезопасности и искусственного интеллекта на основной бизнес нашей компании — удостоверение персональных данных (ПД). Продумывая перспективы использования ИИ-агентов для наших задач, включая борьбу с фродом и ИИ-фродом, мы пришли к выводу, что перестройка нашей собственной системы невозможна без учета архитектурных изменений, происходящих в ИТ системах наших клиентов.
Самые радикальные изменения в архитектуре корпоративных систем компаний, предоставляющих массовые услуги, которые требуют удостоверения ПД, связаны с чуть менее, чем полной переменой взглядов на кибербезопасность корпоративных систем.
В «клиент-серверной» архитектуре предыдущего поколения наши услуги по удостоверению персональных данных помогали выявлять фрод, связанный с использованием чужих ПД из похищенных баз данных, которые стыдливо называют утечками, а также ПД, добытых обманом по так называемой «технологии социального инжиниринга». При этом предполагалось, что охрана своих собственных систем остается в руках наших клиентов. Если злоумышленникам удалось собрать набор ПД, который достаточен для получения товаров или услуг от чужого имени, наши проверки уже не помогают. ПД — правильные, просто они уже находятся в чужих руках. С этого момента сервис-провайдер доверяет предъявителю ПД и предоставляет ему доступ с привилегиями и полномочиями, статически приписанными этим ПД.
Идеология сравнительно новой архитектуры с нулевым доверием (Zero Trust Architecture) определяет несколько простых базовых принципов, принятие которых влечет наступление очень непростых последствий для настоящего и будущего корпоративных систем предоставления массовых услуг. Переход к ZTA влечет за собой трансформацию цифровой среды бизнеса, а за ней и серьезные изменения бизнес процедур и операционных воркфлоу.
В первую очередь, это признание утраты охраняемым периметром системы статуса священной коровы кибербезопасности предыдущего поколения. Разделение корпоративных систем на «интранет», в котором взаимодействуют сотрудники компании, и «экстранет», в котором происходит взаимодействие с клиентами компании, конечными пользователями ее услуг, больше не отражает объективной реальности в связи с повсеместным распространением облачных технологий.
Принятие «облака» в качестве источника ресурсов и сервисов для корпоративных систем не было мгновенным или даже скоротечным. Еще пятнадцать лет назад большие вендоры собирались в фокус-группах различных международных стандартизирующих организаций, чтобы определить как им относиться к прорыву AWS и последующим ответом конкурентов — Microsoft Azure и Google Cloud. Какие программно-аппаратные решения следует предлагать владельцам облаков, а какие — клиентам. Как часто бывает в случае таких технологических прорывов, информационная безопасность облачных решений развивалась в догоняющем режиме, в основном благодаря усилиям отраслевых консорциумов (Cloud Security Aliance, в данном случае) и национальных институтов стандартов (NIST наиболее адекватно представлял позицию американского экспертного сообщества).
Основные идеи ZTA сложились уж к началу нынешнего десятилетия и были оформлены, например, в документах NIST, внимательное чтение которых и послужило поводом для написания этой статьи. Я буду опираться на сведения, полученные из шести документов NIST:
NIST Special Publication 800-204A «Building Secure Microservices-based Applications Using Service-Mesh Architecture.» Май 2020 г.
NIST Special Publication 800-207 «Zero Trust Architecture» Август 2020 г.
NIST Special Publication 800-204B «Attribute-based Access Control for Microservices-based Applications Using a Service Mesh» Август 2021 г.
NIST Special Publication 800-204C «Implementation of DevSecOps for a Microservices-based Application with Service Mesh» Март 2022 г.
NIST Special Publication 800-204D «Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines»
NIST Special Publication NIST SP 800-207A «A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments». Сентябрь 2023 г.
Я всегда предпочитаю начинать со стандартов, даже если их оформление задерживается по сравнению с появлением первых вендорских продуктов и решений. К тому же документы стандартизирующих организаций менее «ангажированные» в отношении конкретных продуктов, как бывает в презентациях консультантов. Хотя, даже и здесь в иллюстрациях нет-нет да и мелькнет какой-нибудь K8s, из чего становится ясно, на каком стеке собрали полигон в лаборатории NISTа.
В приведенном списке документов в порядке их появления первым следует читать NIST SP 800-207, хотя он и появился на три месяца позже. Здесь впервые сформулированы базовые принципы ZTA. Итак, периметра больше нет, что же есть, что будем охранять и защищать.
Все источники данных и вычислительные мощности рассматриваются как ресурсы.
Все коммуникации должны быть защищены, независимо от сетевых локаций участников коммуникации. Запросы на доступ к ресурсам, поступающим из собственной корпоративной сети (то есть внутри бывшего периметра), должны удовлетворять тем же требованиям безопасности, что и запросы, поступающие извне, из сетей, не принадлежащих предприятию. Доверие больше не может быть автоматически предоставлено только на основании положения устройства в сети.
Доступ к каждому отдельному ресурсу предоставляется посессионно (если есть такое слово в русском языке).
Права доступа к ресурсам определяются динамическими политиками, которые включают наблюдаемое состояние ID клиента, выбор приложения или услуги, природу запрашивающего и запрашиваемого ресурсов, а также могут включать другие поведенческие характеристики и атрибуты среды.
Предприятие мониторит и измеряет целостность и статус безопасности всех своих и ассоциированных активов.
Все процедуры аутентификации и авторизации становятся динамическими и выполняются строго до разрешения доступа.
Предприятие собирает максимально возможное количество информации о текущем состоянии активов, сетей, коммуникаций и использует эту информацию для улучшения своего статуса безопасности.
Вот эти простые с виду принципы положены в основу архитектуры ZTA. Каждое в отдельности выглядит вполне разумным, все вместе в совокупности заставляют задуматься о затратах на организацию этих мер безопасности и их достижимость в каждом отдельном бизнес сценарии. (Я знаю, что они уже публиковались на Хабре, как минимум в одной публикации, привожу их здесь для удобства в своем переводе).
Забегая вперед, скажу, что принцип номер четыре в этом списке подтолкнул нас к к переоценке наших собственных инициатив в использовании т.н. «цифрового следа клиента» для задач борьбы с фродом.
Еще более серьезный вопрос, который стоит перед нами — есть ли что-то общее между удостоверением персональных данных (аутентификация) по эталонным источниками и непрерывной, динамической, шифрованной аутентификацией в составе архитектуры ZTA. Можем ли мы со своими компетенциями и квалификациями сделать новое сервисное или продуктовое предложение новому складывающемуся рынку систем, построенных на принципах ZTA или мигрировавших к этому виду. Но это я забежал вперед еще дальше.
Вернемся к публикациям NIST, которые все еще дают пищу для анализа. Интересно сравнить, как развивалась мысль двух групп авторов в этих двух группах публикаций с номером 204 и с номером 207. В самом раннем документе 800-204A принципы Zero Trust вообще не упоминаются. Микросервисную архитектуру можно прекрасно выстроить и без них. В последовавшем за ним документе 800-207 микросервисы упоминаются дважды, через запятую с другими ресурсами и как часть архитектуры защищенного анклава, то есть ZTA принципы можно реализовать и без микро-сервисов и service mesh. Появившиеся вслед за этим 800-204B, 800-204C и 800-204D продолжают описывать специфические вопросы обеспечения безопасности микросервисной архитектуры, в том числе с использованием технологий DevSecOps. И только в документе 800-207A две эти архитектурные концепции — ZTA и микро-сервисная архитектура явно сливаются в общую модель, но даже здесь микро-сервисы зачем-то скрываются под псевдонимом «нативных облачных приложений» (cloud-native applications), что приводит просто к неточному употреблению термина — ставится знак равенства между нативной облачностью и микро-сервисной организацией, что, как мы знаем, не соответствует действительности.
Интересная жизнь у них там в лаборатории информационных технологий дивизиона компьютерной безопасности NIST под руководством Рамасвами Чандрамули. Впрочем, что нам в чужом пиру похмелье, нам надо пересматривать наши собственные взгляды на управление доступом вообще и непрерывную динамическую аутентификацию в частности. Мы пока не можем предсказать, как быстро ZTA станет ведущей архитектурной концепцией во всем мире, зато мы знаем, что в некоторых странах она уже принята в качестве национального стандарта для некоторых классов систем, как правило, работающих с государственными платформами. Пример — GovZTA в Сингапуре. В Австралии также активно развиваются ZTA подходы. Примем в качестве рабочей гипотезы, что ZTA будет в какой-то момент адаптирована к российским национальным стандартам безопасности, поэтому лучше быть к этому готовыми.
Чтобы не разбрасываться, пока ограничимся вариантом ZTA, реализованном для микро-сервисной архитектуры с использованием service mesh. Потом надо будет посмотреть на варианты реализации без использования service mesh для более компактных сценариев, а затем, возможно и без микро-сервисной организации облачных приложений. Альтернативы двум этим архитектурным выборам понятны, но сходу сказать, будет ли реализуема ZTA в полном объеме, пока трудно.
Итак, посмотрим на логическую архитектуру ZTA и особенности реализации управления доступом на service mesh. Собственно, об этом весь документ 800-204A, в котором описывается обеспечение безопасности микросервисных приложений средствами service mesh.
В этом документе service mesh представляется как communication middleware, и это оказалось очень полезной метафорой для нашего понимания, как встраивать сервисы аутентификации и авторизации в ткань service mesh.
Цитата:
"До появления Service Mesh, для обеспечения инфраструктурной функциональности (например, обнаружения сервисов, балансировки нагрузки, размыкания цепи (circuit breaking), внедрения отказов (fault injection), мониторинга безопасности, авторизации и распределенной трассировки для распределенных систем, таких как приложения на основе микросервисов), необходимо было тщательно выбирать набор компонентов и фреймворков, предоставляющих эту функциональность. Некоторые компоненты работают только в определенных фреймворках, а сами фреймворки привязаны к конкретным языкам программирования. Кроме того, код прикладного сервиса должен был модифицироваться для работы с этими компонентами или интеграции в них [8].»
Ссылка в этой цитате ведет на очень любопытную сетевую публикацию еще 2017 года на сайте Medium. Medium —это платформа для публикации всего на свете, во многом похожая на Хабр, появившаяся на пять лет позже. В этой публикации объясняется что такое Service Mesh и приводится еще одна неожиданная метафора, которую оценят только ветераны программирования. Service Mesh сопоставляется с аспектно-ориентированным программированием (Aspect-Oriented Programming — AOP), парадигмой программирования, которая поднялась на вторичной волне после ООП. Чтобы не утяжелять изложение глубиной ссылок, продолжу эту цитату примером того, как строились микросервисные приложения до появления service mesh.
"Netflix OSS, например, действительно легко начать использовать в связке с Spring Cloud Netflix. Просто добавив несколько аннотаций к Spring Boot приложению, вы можете запустить Zuul прокси и Eureka сервер. Добавив другой набор аннотаций, вы помечаете свой микросервис как Eureka Client, и вот он уже регистрируется, делая себя доступным. Если вам нужно вызвать нижестоящий сервис, вы используете Feign. А защитить свои вызовы к нижестоящим сервисам можно с помощью Hystrix.
Однако как только вы покидаете область Java / Spring Boot, все становится гораздо сложнее. Если вам нужно добавить сервис, написанный на C++ или Go, вы должны самостоятельно создать интеграцию с Netflix OSS. Это еще больше шаблонного кода, и вам придется делать это каждый раз, когда вы добавляете новый язык в стек.»
Этот текст отлично иллюстрирует проблему языковой привязки, о которой говорилось в предыдущей цитате - Netflix OSS работает "из коробки" только в Java-экосистеме, а для других языков требует ручной интеграции.
«Появление контейнеров и технологий оркестрации контейнеров сделало возможным новый тип инфраструктуры, который позволяет нам освободиться от фреймворков обнаружения сервисов/балансировки нагрузки/размыкания цепи» — продолжают авторы публикации на Medium.
Service mesh — это инфраструктурный вариант АОП. Многочисленные прокси, образующие ткань service mesh, заменяют конструкцию Aspect в АОП. Они обертывают контейнизированный микросервис подобно тому, как AspectJ может оборачивать и оснащать java метод.»
Извините, не мог пропустить этот исторический экскурс, мне нравится, когда видны корни каждой инновации, хотя судя по дате публикации — 2017 год — service mesh в наше время уже не новость, хотя мы все еще пытаемся его освоить для наших задач.
В общем виде инфраструктура для управления доступом с использованием service mesh выглядит следующим образом:
В административной плоскости (management plane) реализованы пользовательские интерфейсы, например CLI и API для взаимодействия с управляющей плоскостью, которая показана как декомпозиция на глобальную и локальные управляющие плоскости (для каждого кластера географически распределенной системы), каждая со своим экземпляром service mesh, управляющим набором прокси, которые относятся уже к плоскости данных (data plane) и каждый занимается своим делом:
Ingress обрабатывает обращения из внешних клиентских приложений за пределами кластера к любым сервисам в составе кластера;
Egress обрабатывает запросы от любого сервиса в кластере к внешним приложениями за пределами кластера;
Sidecars реализует политики доступа между сервисами внутри кластера.
В терминах логической архитектуры ZTA приведенные на схеме компоненты выполняют функции и Policy Decision Point (PDP) и Policy Execution Point (PEP) для управления политиками доступа и их исполнением. В этой же терминологии говорят, что прокси типа Ingress и Egress управляют политиками доступа в направлении «Север-Юг», а «прицепные вагончики» Sidecars — делают то же самое в направлениях «Запад-Восток».
Теперь для каждого конкретного приложения все, желающие предложить свои компоненты service mesh увиденного как communication middleware, могут приступать к производству свои специализированных прокси компонентов service mesh. Понятно, что с учетом значительного количества микро-сервисов и объема трафика «запад-восток» все решения для обмена между ними должны быть «легкими» в отличие от традиционных платформ middleware. Открытым остается вопрос, удастся ли в такой конфигурации организовать обмен данным (по обоим направлениям) по модели Zero Knowledge Proof (ZKP), для пущей секретности, и какова будет вычислительная нагрузка для реализации выбранных разновидностей сигма-протоколов.
Что касается участия ПД в этой среде коммуникаций, то они, по-видимому, будут в основном циркулировать в трафике «север-юг», представляя традиционных конечных пользователей (людей), а также их ИИ-агентов. Эти ИИ-агенты будут самостоятельно распоряжаться ПД своих принципалов на основании полученных инструкций и вмененных правил и критериев, и нам, как минимум, надо научиться отличать ИИ-агентов от злоумышленников.
Таким образом, общий взгляд на логическую схему ZTA и наполняющие ее компоненты позволяет нам сделать разумные предположения о встраивании в этот стек с функциями аутентификации и авторизации в расширенном понимании. И первым шагом стоит сделать это расширение на агентов владельца ПД, в том числе и на ИИ-агентов.
Следующая большая проблема, которую предстоит решить — это встраивание наших усилий сразу в несколько процессов трансформации ИТ и ИБ среды корпоративных клиентов, которым мы предоставляем услуги. Мы предполагаем, что, как правило, корпоративные системы будут находиться в стадии перехода к новым, более безопасным и более эффективным решениям. Эти процессы трансформации происходят без остановки основных производительных бизнес процессов. Раньше (2009-2015) считалось, что с этими задачами трансформации можно справиться с использованием фреймворков DevOps для автоматизации процессов непрерывной разработки и интеграции с переходом к эксплуатации. За последние десять лет произошла естественная эволюция DevOps к DevSecOps (2015-2020). Параллельно развивались MLOps — концепции поддержания жизненного цикла ML моделей (с 2015 года). И вот, примерно с 2020 года начался следующий этап эволюции, переход к подходу MLSecOps, который развивает как DevSecOps, так и MLOps.
Применимость технологий MLSecOps для развертывания встроенных средств аутентификации и авторизации в рамках систем управления доступом — тема следующей публикации.