[Серия по созданию промежуточной платформы данных № 5] Разрешения на промежуточную платформу данных
Безопасность данных является основной функцией построения центра обработки данных. В этой статье в основном будет представлен важный модуль безопасности данных — разрешения на данные, включая некоторые идеи дизайна для разрешений на уровне строк данных и разрешений на уровне столбцов. Или. у вас есть этот план, я верю, что эта статья определенно принесет вам новое вдохновение.
Разрешения на данные относятся к активам данных, к которым пользователи могут получить доступ и которыми они могут управлять, например, к определенной таблице данных, полю данных и т. д. Разрешения на данные обеспечивают безопасность и соответствие активов данных. Благодаря управлению разрешениями на данные можно лучше контролировать доступ пользователей к ресурсам данных и операции с ними, что повышает ценность центра обработки данных.
Разрешения на данные в основном включают разрешения на уровне строк и разрешения на уровне столбцов для данных. Путем создания разрешений на уровне строк для данных, когда разные пользователи получают доступ к одной и той же модели данных, из-за разных правил разрешений полученные наборы данных также различаются, а разрешения строк ограничиваются диапазоном. Разрешения на уровне столбца в основном скрывают или делают невидимыми поля в данных, чтобы обеспечить изоляцию данных или снижение чувствительности. Разрешения на уровне столбца ограничивают состояние.
Разрешения на данные в основном состоят из трех частей: уровня приложения, уровня обслуживания и уровня выполнения. Как показано на рисунке ниже:
Основная идея заключается в том, что все разрешения на строки и столбцы действуют на определенный интерфейс API службы данных или модель отчета BI (точнее, SQL), а затем применяются к бизнес-персоналу, который просматривает отчет или вызывает интерфейс API службы данных. соответствующие разрешения на уровне строк и столбцов, поэтому, когда один и тот же отчет или интерфейс API вызываются разными людьми, видимые данные будут противоречивыми, что реализует контроль разрешений на уровне строк данных.
Включая правила настройки разрешений страниц и бизнес-стороны, вызывающие API-интерфейсы службы данных (как описано в главе о службе данных, всем бизнес-сторонам не разрешено напрямую подключаться к хранилищу данных);
Все запросы SQL к базовым данным хранилища данных будут перехватываться службой разрешений данных, а исходный SQL будет переписан посредством проверки разрешений и перехвата SQL;
Хранилище данных реального времени, построенное на базе Apache Doris, служит уровнем исполнения, который выполняет операторы SQL, модифицированные службой разрешений данных, и возвращает результаты выполнения на сторону приложения;
В разрешениях на данные пользователи делятся на три уровня: пользователи белого списка, пользователи правил и другие пользователи.
К пользователям белого списка относятся пользователи, для которых правила неэффективны и имеют наивысший приоритет. Если пользователь одновременно является пользователем правила и пользователем белого списка, то при определении разрешений ему будет присвоен приоритет как пользователю белого списка. Пользователь белого списка может получить доступ ко всем данным в наборе данных, независимо от недействительных правил.
Пользователи, включенные во все правила этого набора данных (тот же SQL). Если пользователь не входит в белый список, то проверка будет производиться согласно имеющимся у него на данный момент правилам разрешений.
«Другие пользователи» относятся ко всем пользователям, кроме пользователей белого списка и пользователей правил. Эта группа пользователей имеет два атрибута разрешений: все разрешения и отсутствие разрешений. Наличие всех разрешений означает, что другие пользователи могут просматривать все данные в наборе данных без каких-либо ограничений. Отсутствие разрешений означает, что на бумаге нет разрешения задачи на просмотр данных в наборе данных.
Разрешения на уровне строка в операторе SQL,Мы можем понимать это как добавлениеWHERE
состояние。Конкретный дизайн страницы конфигурации выглядит следующим образом.:
Объекты расширения полномочий: это могут быть основаны на реальном сценарии развития компании, а также могут быть роли персонала, отделы кадров и т. д.
Правила расширения прав и возможностей: Глубина правил может быть ограничена тремя уровнями (в соответствии с фактическими потребностями), но взаимосвязь между этими тремя уровнями может быть только и-или-и
илиили-и-или
эти два способа,Это иSQLвWHERE
состояние Связанные со сращиванием。
Каждое конкретное правило можно добавить в столбец условий редактирования. Здесь следует отметить, что все поля фильтрации могут быть только полями в модели набора данных (то есть полями после SELECT). В настоящее время существует три способа фильтрации полей: фильтрация перечисления, фильтрация меток и условная фильтрация.
Он перечисляет несколько фиксированных значений для конкретных полей, и пользователи могут получить доступ только к данным, связанным с этими значениями;
Определите набор тегов, и пользователи формируют отношения с тегами. Каждый пользователь имеет другое значение для одного и того же тега. Это также эквивалентно перечислению.
Определено множество методов фильтрации, например: содержит, начинается с, заканчивается на, больше, равно, меньше и т. д.;
Выше описан метод проектирования и процесс настройки разрешений на уровне строк для набора данных. Позвольте мне кратко показать вам два эффекта.:
Сначала мы определяем набор данныхDATASET-A
стандартныйSQL : "SELECT xxx FROM xxx "。
Пользователь может только просматриватьDATASET-A
набор данныхидентификатор базы данных
Поля"2,3,4-дюймовые данные,Правила настроены следующим образом:
После перехвата и перезаписи разрешений на данные фактический SQL для запроса к хранилищу данных становится следующим:
SELECT xxx
FROM
(SELECT xxx
FROM xxx) _D_S_A_
WHERE _D_S_A_.`db_id` IN (2, 3, 4)
Пользователь может просмотретьDATASET-A
набор данныхидентификатор базы данных
Поля"2,3,4-дюймовые данные,Вы также можете просмотретьдвигатель = "Дорис"
иливремя создания> "2021-11-01"
данные,Правила настроены следующим образом:
После перехвата и перезаписи разрешений на данные фактический SQL для запроса к хранилищу данных становится следующим:
SELECT xxx
FROM
(SELECT xxx
FROM xxx) _D_S_A_
WHERE _D_S_A_.`db_id` IN (2, 3, 4)
AND (_D_S_A_.`engine` = 'Doris'
OR _D_S_A_.`create_time` > '2021-11-01')
Я полагаю, что благодаря двум приведенным выше примерам каждый имеет определенное представление о разрешениях данных на уровне строк. Далее мы продолжим рассматривать разрешения данных на уровне столбцов.
Как мы уже говорили выше, разрешения на уровне столбца — это состояние поля, и его основная функция — снизить чувствительность поля или сделать его невидимым. Существует несколько ключевых концепций разрешений на уровне столбца:
Это то же самое, что и разрешения на уровне строк. Если пользователь находится в белом списке, все правила на уровне столбца не вступят в силу, и все поля будут доступны.
Это относится к полям, для которых текущий пользователь не установил правила для всех полей в этом наборе данных. В настоящее время существуют две конфигурации разрешений: «отключить просмотр» и «разрешить просмотр» для других полей.
Например:
Набор данных A имеет четыре поля: «имя, возраст, телефон, адрес». Если администратор устанавливает правило снижения чувствительности для Чжан Саня в поле «телефон» в наборе данных A, то в дополнение к полю телефона добавляется «имя, возраст». , адрес» в настоящее время принадлежат другим полям:
Если в других полях задан запрет на просмотр, то Чжан Сан сможет просматривать только поле «телефон» в наборе данных A, и это поле по-прежнему нечувствительно;
Если для других полей разрешен просмотр, то Чжан Сан может видеть содержимое всех полей в наборе данных A, но поле «телефон» находится в десенсибилизированном состоянии;
Это место немного запутанное, так что вы сможете его лучше понять.
Правило на уровне столбца можно добавить, как показано на рисунке ниже:
На картинке мы видим, что правило на уровне столбца содержит две опции: отключение просмотра и снижение чувствительности данных. Как это правило вступает в силу? В этом разделе перечислены 4 способа вступления в силу:
Эффективный метод | иллюстрировать |
---|---|
Действительно для всех | Это означает, что правило эффективно для всех. |
Действует не для всех | Это правило действует не для всех |
Назначенное лицо вступает в силу | Укажите пользователя, для которого правило вступит в силу |
Назначенное лицо неэффективно | Правило не вступает в силу для указанного пользователя |
Варианты снижения чувствительности также включают в себя множество методов, таких как: снижение чувствительности первых нескольких символов, снижение чувствительности следующих символов, снижение чувствительности средних символов и т. д. Такая идея реализации достигается за счет сегментации, замены и объединения некоторых функций строковых операций в SQL.
Выше приведен общий процесс настройки и идеи реализации разрешений на уровне столбца в разрешениях на данные. Далее давайте рассмотрим этот пример:
Набор данныхDATASET-A
стандартныйSQL : "SELECT xxx FROM xxx ", правила разрешений на уровне столбца для пользователя Чжан Сан следующие:
<u>верно"chinese_name"Поля посередине3немного десенсибилизация,Уменьшите чувствительность поля «charge_person».,верно"engine"Последние тринемного десенсибилизация</u>
После перехвата и перезаписи разрешений на данные фактический SQL для запроса к хранилищу данных становится следующим:
SELECT
_D_S_A_.`tbl_desc` AS `tbl_desc`,
_D_S_A_.`tbl_typ e` AS `tbl_type`,
CONCAT(SUBSTR(`engine`, 1, 3), '***') AS `engine`,
_D_S_A_.`create_time` AS `create_time`,
_D_S_A_.`create_table_sql` AS `create_table_sql`,
CONCAT(SUBSTR( `charge_person`, 1, 1), '**') AS `charge_person`,
CASE
WHEN CHAR_LENGTH(`chinese_name`) <= 3 THEN '***'
ELSE REPLACE(`chinese_name`, SUBSTR(`chinese_name`, 3, CHAR_LENGTH(`chinese_name`)-3), '***')
END AS `chinese_name`,
_D_S_A_.`sec urity_level` AS `security_level`,
_D_S_A_.`create_time` AS `create_time`,
_D_S_A_.`expression_add_field2` AS `expression_add_field2`
FROM
(
SELECT
xxx
FROM
xxx ) _D_S_A_
Эта система разрешений на данные широко используется на предприятии. В настоящее время более тысячи человек получили разрешения на данные, включая службы данных, отчеты BI и другие проекты. Система прошла тестирование в различных бизнес-сценариях. работает стабильно в течение 2 лет. Это система, которая со временем устоялась. В построении промежуточной платформы данных создание прав доступа к данным является очень важной частью. В этой статье подробно представлены общие идеи проектирования и процесс настройки, и мы надеемся, что она будет полезна всем.
Я участвую в последнем конкурсе эссе для специального учебного лагеря Tencent Technology Creation 2024. Приходите и разделите со мной приз!