Версия сайта для слабовидящих
Data Mesh воплощает децентрализованный подход к построению распределенной архитектуры данных. При всех достоинствах этой модели, которая совмещает потоковую и пакетную парадигмы обработки данных, она еще довольно незрелая и имеет ряд недостатков. Одним из них является проблема с информационной безопасностью, что мы и рассмотрим далее для обучения ИТ-архитекторов и дата-инженеров. Безопасность как код и управление доступом на основе удостоверений.
Проблемы безопасности в архитектуре Data Mesh
Как мы уже писали, Data Mesh предполагает разделение потребителей данных от их продюсеров, чтобы превратить данные в продукты, управляемые доменом, и позволить потребителям выбирать, как они хотят обрабатывать эти данные, не ограничиваясь централизованным и монолитным стеком технологий. Однако, это противоречит текущим принципам информационной безопасности, которая основывается на централизации полномочий и преднамеренном ограничении выбора.
В Data Mesh исполнительный механизм потребителя должен быть инкапсулирован в его ограниченном контексте, чтобы предупредить несанкционированную утечку информации. Поэтому контроль доступа необходимо применять в точке, где данные обслуживаются, а не там, где они потребляются. Контроль доступа и безопасность данных должны осуществляться владельцем данных, чтобы все потребители, независимо от движка, управлялись одинаково. Наконец, потребители будут иметь свободу выбирать любой механизм обработки данных без сложной интеграции безопасности и одобрения центрального органа.
Современные технологии Big Data позволяют добиться этого с помощью примитивных элементов управления доступом на уровне таблиц: почти во всех реализациях озера данных таблицы содержат отдельный набор файловых объектов, а базы данных содержат отдельный набор таблиц. Делегировав ответственность за грубое управление доступом хранилищу объектов, такому как S3, можно использовать его API в качестве общего уровня интеграции для вычислительных движков. Но это не относится к элементам управления доступом к более мелким элементам данных, таким как столбцы, строки или ячейки: во всех популярных форматах файлов структурированных данных эти элементы мультиплексируются внутри объектов и не могут быть адресованы никаким текущим механизмом защиты хранилища объектов. Также они также не могут быть преобразованы в целях маскирования данных. Поэтому базовый слой на уровне таблиц не достаточен для обеспечения информационной безопасности и не может использоваться в качестве общей точки системной интеграции данных.
Таким образом, возникает потребность в новой архитектуре обслуживания данных. Серверы, составляющие эту архитектуру, должны использовать общий протокол обмена данными, основанный на огромных объемах записей, а не на объектах, например, Apache Arrow Flight. Они должны иметь возможность ограничивать доступ на основе базы данных, таблиц, столбцов и метаданных на уровне ячеек, а также маскировать и редактировать данных. Это нужно, чтобы понять, откуда поступают данные и в каком формате, чтобы убедиться, что эти службы сканировать таблицы, выполнять изменения наборов записей и поддерживать транзакции.
Создав хранилище записей с общим уровнем интеграции для всех механизмов обработки, можно выделить уровень потенциального перехвата, где следует применить контроль доступа к данным корпоративного уровня, согласованный с концепцией Data Mesh. При этом важно предусмотреть безопасность потоковой передачи событий. К примеру, большинство API-интерфейсов продюсеров потоковой передачи принимают непроверенные массивы байтов в качестве входных данных для записи, что небезопасно. Кроме того, следует не только повысить безопасность данных, но и контракты продюсер-потребитель, которые работают с более мелкими, высокоуровневыми и семантически полезными элементами данных, т. е. записями и полями. Частично это идея уже где-то реализована. Например, AWS предлагает общий API хранилища на основе записей как часть формирования озера данных, интегрированный с популярными сервисами обработки данных этого облачного провайдера и предлагает точные элементы управления доступом. Некоторые сторонние решения расширяют этот API, например, S3-совместимый API в MinIO, о чем мы писали здесь. Аналогично весной 2022 года вышел BigLake от Google, который содержит API-интерфейс хранилища, создающий наборы записей Arrow и контролирующий доступ и фильтрацию данных перед доставкой в механизмы обработки.
Таким образом, Data Mesh использует децентрализованный восходящий подход к обмену данными между продюсерами и потребителями. Данные, которые раньше обычно находились на дальнем конце разрозненного стека приложений, теперь извлекаются и помещаются на передний план и в центр, представляя собой продукт, чтобы потребители могли потреблять их, используя любые инструменты. Поэтому интеграция данных становится общей обязанностью владельцев данных, которые должны сотрудничать друг с другом для предоставления бизнес-пользователям нужных им данных.
Data Mesh и инфраструктура как код стали сегодня явным трендом развития архитектуры данных. Но из-за отсутствия поддержки IDP-протоколов SAML и OIDC для хранилищ данных организациям очень сложно одновременно быть гибкими, управляемыми данными и безопасными. Как обойти это ограничение, используя подход «Безопасность как код» и управление доступом на основе удостоверений, мы рассмотрим далее.
Механизмы обеспечения безопасности данных
Исторически механизмы SAML и OIDC были разработаны, чтобы пользователи и их разрешения могли управляться в одном центральном поставщике удостоверений, таком как Active Directory. Затем пользователи могли входить в другие приложения, используя свои уже известные удостоверения и разрешения. Это избавляло от расхождения между пользователями и их известными разрешениями в разных сервисах. Например, если пользователь ушел из компании, не использующей SAML или OIDC, его требовалось удалить из Active Directory и корпоративных баз данных. Это создавало высокую рабочую нагрузку на системных администраторов и возможности для ошибок. После централизации личности и разрешений, управление уходом человека из компании стало менее рискованным. В централизованной модели, когда пользователь покидает компанию, удаление его учетной записи в одном месте приводит к каскадному эффекту удаления пользователя из каждой системы, куда он имел доступ. В идеале этот подход не только централизует управление идентификацией, но и связывает аккаунты пользователя в разных системах.
Однако, во многих базах данных по-прежнему отсутствует собственная поддержка SAML или OIDC, т.к. эти два протокола в основном предназначены для шаблонов доступа через Интернет, а базы данных используют запросы, выдаваемые различными пользователями и приложениями. Поэтому управление доступом к Data Mesh весьма актуально: организации обычно предоставляют доступ к базе данных и хранилищу данных пользователям, использующим общие учетные записи. Также есть трудности с созданием и обслуживанием индивидуальных учетных записей пользователей для доступа к базе данных.
BI-системы настраиваются для подключения к базе данных с использованием общего URL-адреса базы данных, имени пользователя и пароля или, по сути, учетной записи службы. Большинство инструментов BI могут передавать удостоверение пользователя в базу данных. Это приводит к тому, что многие пользователи используют одну и ту же учетную запись службы в базе данных. Это создает пробел в контрольном журнале, затрудняя приписывание действий пользователям. Чтобы справиться с этим, организации применяют творческие способы передачи личности пользователя. Для безопасной организации личность пользователя должна быть зарегистрирована, что чаще всего реализуется добавлением SQL-комментария, который включает идентификатор пользователя. Чтобы завершить контрольный журнал, они обеспечивают включение ведения журнала базы данных, что часто сопряжено с собственными проблемами производительности.
Хотя это и решает задачу регистрации идентификатора пользователя, известного BI-инструменту, проблема остается. Чтобы отслеживать активность пользователя, необходимо знать его идентификатор в инструменте. Но, если компания хочет внедрить пользовательскую логику между инструментом и базой данных, это невозможно из-за прямого соединения. Например, обнаружить аномалии, чтобы прервать сеанс пользователя, когда его действия выглядят как утечка данных.
Поскольку учетная запись службы BI-инструмента по существу является общей для всех пользователей, учетные записи часто имеют избыточные разрешения. То есть, когда одна учетная запись используется совместно любыми двумя пользователями, она должна иметь сумму всех разрешений, которые необходимы им обоим. Таким образом, эта учетная запись становится чрезмерно разрешенной и дает любому отдельному пользователю больше прав, чем ему нужно. Это противоречит принципу наименьших привилегий, ключевому элементу политики безопасности во многих организациях.
Несмотря на эти проблемы, многие BI-инструменты по-прежнему реализуют именно такую политику, предоставляя доступ через сервисные учетные записи, что приводит к невозможности централизованного управления доступом для всех пользователей. Таким образом, архитектура Data Mesh небезопасна при использовании традиционных методов защиты данных от несанкционированного доступа. В частности, при традиционном подходе, когда компания запускает собственную локальную базу данных, ее защита обычно настраивается тем же физическим брандмауэром, что и ее пользователей. Иначе можно использовать узел перехода, чтобы разрешить доступ в более безопасную зону. Глубокая проверка пакетов может использоваться для защиты трафика, как и список допустимых источников трафика, таких как разрешенные IP-адреса или сетевые CIDR. Для сохранности и аварийного восстановления данных каждую ночь может создаваться бэкап.
Еще один ценный аспект типичных политик локальных баз данных заключается в том, что они включают в себя проверку безопасности, поэтому для создания новой базы данных требуется много времени для выполнения проверок и аудитов. Но большинство этих традиционных подходов невозможны в динамической облачной среде. Виртуальное частное облако (VPC) интеллектуально похоже на брандмауэр, но ограничения доступа на основе физического местоположения пользователя создать сложнее. Создание новых репозиториев данных выполняется настолько легко и быстро, что количество служб данных может стремительно увеличиваться, что затрудняет принятие соответствующих мер безопасности во время любого этапа жизненного цикла базы данных.
Решением этой проблемы может стать федерация удостоверений путем координации и управления удостоверениями пользователей в репозиториях данных организации и поставщиках удостоверений (IDP). Это позволяет пользователям проходить аутентификацию в конечных точках данных, используя свои учетные данные IDP. Вместо использования имени учетной записи и пароля конечной точки данных федеративная аутентификация опирается на адрес электронной почты пользователя и недолговечный токен доступа, сгенерированный его IDP.
Маркер доступа создается после успешного обмена аутентификацией SAML/OIDC между пользователем и IDP. Впоследствии пользователь может выбрать клиент (интерфейс командной строки, пользовательский интерфейс или BI-инструмент) для подключения к конечной точке данных. По адресу электронной почты и токену пользователя можно проверить их подлинность с помощью IDP и найти группу, членом которой является пользователь, чтобы сопоставить имя группы с учетной записью конечной точки данных, которая должна использоваться для всех членов этой группы. Определив учетную запись, можно найти учетные данные в хранилище секретов, работающем в среде организации, например, экземпляр AWS Secrets Manager или Hashicorp Vault в AWS. Используя эти учетные данные, можно подключиться к конечной точке данных, позволяя пользователю получить доступ, не требуя специальных учетных данных в самой конечной точке данных.
SaaS-приложения и BI-инструменты используют различные методы для обеспечения большей прозрачности выполняемых запросов. Одним из них является аннотация запроса, что включает передачу комментариев, содержащих дополнительную информацию об удостоверении конечного пользователя на языке конечной точки данных. Альтернативой является установка пользовательских переменных сеанса в рамках транзакций базы данных. Комментарии и пользовательские переменные сеанса игнорируются конечными точками данных во время обработки запросов и транзакций. Однако, они полезны для мониторинга активности и отладки производительности, а также помогают отслеживать запросы до конечных пользователей, которые их сгенерировали.
Чтобы создать надежную модель безопасности сетки данных, недостаточно просто развернуть централизованное управление учетными записями и федерацию удостоверений. Привилегированные учетные записи представляют собой частый вектор атак в большинстве организаций. Поэтому следует предоставлять пользователям только своевременный и достаточный доступ к их хранилищам критически важных и конфиденциальных данных с простыми запросами на доступ и утверждениями в существующих приложениях для обмена сообщениями организации. Это устраняет необходимость в долгосрочном привилегированном доступе для пользователей, ужесточает контроль доступа и уменьшает поверхность атаки.
Таким образом, подход «Безопасность как код» позволяет организациям систематизировать свои решения в области безопасности и политик. С этим подходом разработчики, DevOps-инженеры и команды информационной безопасности могут внедрять тестирование и сканирование безопасности непосредственно в свои CI/CD-конвейеры и систематизировать решения по политике доступа.
Резюмируя возможности обеспечения cybersecurity в новой децентрализованной архитектуре Data Mesh, подчеркнем преимущества управления доступом на основе удостоверений:
- упрощенное управление доступом — чтобы предоставить новым пользователям доступ к репозиториям данных, администраторы могут просто использовать свою существующую информацию SSO, без необходимости управлять учетными записями;
- централизованный контроль соответствия и аудиты;
- снижение вероятности возникновения атак.
Подход «Безопасность как код» позволяет легко управлять любым доступом к Data Mesh. Перехватывая запросы к каждой конечной точке данных без сохранения состояния, можно обеспечить федерацию удостоверений во всех хранилищах данных, BI-инструментах, приложениях и провайдерах удостоверений.
Узнайте, как внедрить современные архитектурные модели на базе Apache Kafka в свои ИТ-проекты аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
