👆 Это 421-я неподдельная оригинальная статья. Если вы хотите узнать больше, нажмите на карточку ниже, чтобы подписаться на нас.

1. Общие сведения

Управление и контроль разрешений — одна из наиболее важных базовых возможностей прикладной системы. Обычно разрешения можно разделить на функциональные разрешения и разрешения на данные. Функциональные разрешения в основном используются для управления операциями, которые могут выполнять пользователи, то есть тем, что могут делать пользователи. ; разрешения на данные контролируют, что могут делать пользователи. Здесь область объекта относится к бизнес-данным. Разрешения на данные могут быть дополнительно уточнены до разрешений на уровне строк и разрешений на уровне полей. Например, управляющий пользователь может запрашивать данные своего собственного отдела. но не может просматривать данные других отделов или может просматривать только один элемент информации о некоторых полях бизнес-данных. Разрешения на доступ к данным, с которыми мы сталкиваемся, обычно относятся к контролю бизнес-данных в системе приложений. Эти бизнес-данные генерируются в результате поведенческих действий пользователей, например, данные транзакций в торговом приложении. Обычно пользователи могут просматривать только свои собственные записи транзакций. Это самая простая и распространенная стратегия управления разрешениями на данные. Объем данных, которые необходимо контролировать с помощью системы разрешений на большие данные, намного больше, включая все таблицы в хранилище данных. При этом контролируемыми пользователями являются не обычные пользователи прикладной системы (пользователи, генерирующие данные), а данные. разработчики и аналитики данных и т. д. (пользователи, использующие данные). В этой статье основное внимание будет уделено управлению разрешениями на данные и контролю над системой разрешений на большие данные Zhengcai Cloud.

2. Важность безопасности данных

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

3. Сценарии управления и контроля разрешений на данные

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

• Сценарий анализа/запроса данных, разработанные нашей компанией инструменты анализа в основном включают в себя открытый исходный код. BI инструмент Метабаза, небольшая коллекция собственной системы анализа запросов. ДА. Необходимо запросить таблицу пользователей、Поле Ждем прогресса Разрешенияконтроль。
• сценарий развития данных,В основном для собственной платформы разработки IData, созданной командой data. Каждое направление бизнеса развивает свои собственные операции с данными.,Контролируйте использование исходных таблиц разработчиками.

4. Проблемы, с которыми пришлось столкнуться

Как видно из приведенных выше сценариев управления, нам необходимо контролировать права доступа к данным, когда пользователи используют Metabase, Xiaocai DA и IData. Среди них сама Metabase имеет собственную функцию управления разрешениями, которая может распределять разрешения в зависимости от детализации источников данных, коллекций диаграмм и групп пользователей. Раньше мы также использовали собственную систему разрешений Metabase для управления разрешениями на диаграммах Канбан. В то же время Metabase использует Presto в качестве механизма запросов, поэтому плагин Apache Ranger, основанный на Presto, использует Apache Ranger для более детального управления разрешениями на уровне таблицы.

По прошествии определенного периода использования текущий метод управления разрешениями сталкивается со многими проблемами:

• Metabase и Apache Ranger метод управления из Разрешения больше не может удовлетворить потребности, Метабаза из Разрешения Степень детализации управления относительно грубая, и ее детализация - это источник данных, сбор, уровень группы пользователей. При распределении разрешений также полагается администратор, и эта операция относительно громоздка. такой же Apache Ranger Он также полагается на администратора в управлении и контроле Разрешения, а эффективность настройки Разрешения низкая.
• Управление решениями разбросано по нескольким системам.,Высокие затраты на техническое обслуживание,Если есть новые приложения системы,Такие как Сяокай DA,Необходимо разработать еще один комплект Разрешениясистемы.
• Управление авторизацией данных Разрешения находится в компетенции администратора.,Разрешения Руководство Нагрузка относительно большая,Особенно, когда речь идет о кадровых изменениях или даже корректировках подразделений.,данные Разрешенияиз Рабочая нагрузка руководства будет расти в геометрической прогрессии. При этом администраторы не могут точно управлять всеми.,Склонен к риску превышения своих полномочий.
• Безопасность данных предъявляет растущий спрос на детальное управление Разрешениями, и трудно удовлетворить спрос на усовершенствованный контроль Разрешений.
• независимыйиз Разрешениясистема,Невозможно объединить с другими проблемами безопасности внутри компании.,Например, иданные платформы классификации и классификационной информации открыты, это не способствует централизованному разрешению;,Не удалось авторизоваться один раз,Используется несколькими сторонами (несколько платформ данных). В то же время сложно обеспечить запрос данных и мониторинг во время мероприятия и пост-событийный аудит.

5. Цели создания новой разрешительной системы

Исходя из вышеизложенного, мы предложили новые цели построения системы управления властью:

• Сократить затраты на управление,Переход от выделения Разрешенияиз администратором к собственному приложению пользователя по требованию для Разрешения данных (минимизация принципа Разрешения).,Процесс утверждения в сочетании с классификацией данных,Пригласите несколько сторон для участия в рассмотрении и утверждении,Содержит пользовательские команды руководитель (ответственный за данную заявку), стороны, связанные с данными (подверженные воздействию данных)、Команда безопасности (высокая конфиденциальность и высокая ценность данных).
• Разрешения Централизованное управление и унифицированная аутентификация,Другие приложения из Разрешения управления и контроля единой док-станции Разрешениясистемы. Авторизоваться один раз,Используется несколькими сторонами (несколько платформ данных). В то же время он может удовлетворить потребности в аудите и отслеживании после событий.
• Поддержка уровня таблицы, уровня поля, уровня строки, метабазы Различная степень детализации управления и контроля, такая как Канбан и отчеты, а также открывают классификацию и классификацию информации для каждого элемента.

6. Проектирование и внедрение разрешительной системы

модель разрешения

В процессе проектирования больших данных Разрешениясистемы,В основном мы исследуем два типа Понятной модели разрешения., один более знаком всем из RBAC модель (модель управления разрешениями на основе ролей), одна из них ABAC Модель (на основе атрибутов) Access Управление, модель управления разрешениями на основе атрибутов).

RBAC

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

ABAC

Управление разрешениями на основе атрибутов Access Контроль, короче ABAC), очень гибкая модель авторизации. АБАК Модель больше подходит для сценариев динамического распределения разрешений и позволяет гибко управлять разрешениями доступа пользователей. но ABAC Систему разрешений модели относительно сложно реализовать. Основываясь на наших собственных реальных потребностях, мы извлекли уроки из ABAC Модель идея, дизайн Понятно отвечает нашим реальным потребностям изданные модели разрешения。

Модель разрешения разрешения в основном разделена на несколько частей:

Авторизованный субъект：Авторизованный субъект, т.е. разрешение гранта из объекта,Наша авторизация основана на пользователях и группах пользователей.,То есть разрешение данных Разрешения может быть напрямую разрешено пользователю.,Также упростите заявку на разрешение данных для Понятно.,Мы можем создать группу пользователей,Администратор этой группы пользователей подает заявку на участие в группе пользователей. Разрешения,После применения,По умолчанию все пользователи в группе пользователей подали заявку на из Разрешения.

Авторизованные ресурсы：мы будемданные Разрешенияконтрольв пределах досягаемостиизповерхность、Поле、уровень строкиданные、Канбан и другие абстракции для Авторизованных ресурс. Пользовательское приложение для Разрешения - это приложение для этих ресурсов из Разрешения.

Операция авторизации：Операция авторизация означает, что пользователи могут работать с ресурсами, например, читать, писать и т. д.

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

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

Метаданные и классификация данных

Создание системы разрешений на данные неотделимо от создания метаданных хранилища данных. Участие этих метаданных необходимо в процессе подачи заявок на получение разрешений на данные и аутентификации. Для классификации данных мы делим данные на три уровня: высокий, средний и низкий. Различные уровни безопасности означают разную конфиденциальность и ценность данных. В то же время в таких сценариях, как применение разрешений на данные и использование данных, разная безопасность. уровни полномочий определяются по-разному.

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

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

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

Процесс определения наследования уровня безопасности:

Проверка разрешения на данные

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

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

7. Резюме

Подводя итог, мы кратко описали предысторию создания, цели, проектирование и внедрение системы разрешений на большие данные Zhengcai Cloud.