Предотвращение утечек данных в HR-аналитике с помощью RLS в MS Power BI и Apache Superset

Данные — это сила в сфере управления персоналом. Это способствует глубокому анализу, стратегическому планированию и принятию обоснованных решений. Однако с этим богатством конфиденциальных данных возникает большая ответственность — обеспечение их безопасности. Учитывая растущую сложность задач HR-аналитики и расширение сферы действия законов о конфиденциальности данных, защита данных HR от несанкционированного доступа никогда не была более важной. Именно здесь вступают в действие передовые инструменты управления данными, такие как Microsoft Power BI и Apache Superset, оснащенные надежными функциями, такими как безопасность на уровне строк (RLS).

В этой статье мы углубимся в безопасность данных в рамках HR-аналитики, изучая, как мы можем использовать RLS как в Power BI, так и в Apache Superset для предотвращения потенциальных утечек данных. С их возможностями RLS мы рассмотрим, как эти инструменты могут обеспечить детальный контроль доступа, гарантируя, что конфиденциальные данные доступны только уполномоченным лицам, тем самым защищая информацию о сотрудниках, обеспечивая соблюдение правил защиты данных и укрепляя доверие внутри организации. Пожалуйста, сопровождайте меня, пока мы приступаем к тщательному исследованию улучшенной безопасности данных в рамках People Analytics.

Понимание необходимости RLS в People Analytics

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

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

Юридическая ответственность вытекает из постоянно меняющейся нормативно-правовой базы со строгими законами о конфиденциальности данных, такими как Общее положение о защите данных (GDPR) в ЕС и Калифорнийский закон о конфиденциальности потребителей (CCPA) в США. Эти правила требуют строгого соблюдения норм конфиденциальности данных и предусматривают суровые наказания за их несоблюдение.

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

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

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

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

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

Учитывая конфиденциальность данных HR и потенциальные риски утечки данных, существует острая необходимость в таких мерах, как RLS в HR-аналитике. Эти меры позволяют детально контролировать доступ к данным, гарантируя, что только уполномоченные лица могут получить доступ к определенным данным, что значительно снижает риск утечки данных.

Глубокое погружение в RLS

Безопасность на уровне строк (RLS) — это метод ограничения доступа к данным на уровне строк в вашей базе данных. Он предлагает способ реализовать контроль доступа к данным, ограничивая видимость данных для конкретных пользователей в зависимости от их ролей. Другими словами, RLS позволяет контролировать, кто что видит при доступе к базам данных или наборам данных.

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

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

1. Улучшенная безопасность данных. Наиболее значительным преимуществом RLS является повышенная безопасность данных. Ограничивая доступ к данным авторизованными пользователями, RLS значительно снижает риск утечки или неправильного использования данных.
2. Соответствие нормативным требованиям. RLS помогает организациям соблюдать различные законы и нормативные акты о конфиденциальности данных. Это позволяет им продемонстрировать, что у них есть строгий контроль доступа к данным, что соответствует требованиям таких нормативных актов, как GDPR или CCPA.
3. Генеральный контроль доступа: RLS позволяет определять доступ на детальном уровне, а не только на уровне базы данных или таблицы. Это означает, что вы можете настроить доступ к данным на основе определенных ролей пользователей или даже отдельных пользователей.
4. Масштабируемость и гибкость. RLS — это масштабируемое и гибкое решение. Это позволяет создавать сложные модели безопасности, которые можно адаптировать по мере роста организации или изменения ее потребностей в безопасности.

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

Внедрение RLS в MS Power BI

Power BI – это набор инструментов бизнес-аналитики, разработанный корпорацией Майкрософт, который позволяет вам анализировать данные и обмениваться информацией. Он обеспечивает 360-градусный обзор наиболее важных показателей в одном месте, обновляется в режиме реального времени и доступен на всех ваших устройствах. Power BI позволяет подключаться к сотням источников данных, упрощает подготовку данных и проводит специальный анализ. Он предлагает надежные инструменты визуализации данных, чтобы превратить несвязанные источники данных в согласованные, визуально захватывающие и интерактивные идеи. Будь то HR-аналитика или отчеты о продажах, Power BI — незаменимый инструмент для многих организаций.

Внедрение RLS в Power BI включает несколько ключевых шагов. Вот основное пошаговое руководство:

1. Определение ролей. В Power BI Desktop вы можете определить роли на вкладке «Моделирование», выбрав «Управление ролями». Обычно вы определяете роли, соответствующие разным типам пользователей, получающих доступ к вашему отчету (например, менеджер по персоналу, руководитель группы, HR-аналитик).
2. Настройка фильтров ролей. После определения ролей вы можете настроить фильтры на уровне строк для каждой роли. Это включает в себя указание, какие строки данных в ваших таблицах могут просматриваться каждой ролью. Обычно это основано на логическом выражении.
3. Проверьте свои роли. Power BI Desktop позволяет вам проверить эффективность ваших настроек RLS, позволяя вам просматривать данные, как если бы вы были пользователем, которому назначена определенная роль.
4. Публикация и назначение ролей. После публикации отчета Power BI в службе Power BI вы можете назначать пользователям ранее определенные роли в службе Power BI.
5. Настройка безопасности на уровне объектов (необязательно). Чтобы обеспечить более высокие требования к безопасности, вы можете настроить безопасность на уровне объектов (OLS) в Power BI, чтобы контролировать доступ к таблицам и столбцам. ли>

Применение RLS в аналитике Power BI for People можно продемонстрировать на нескольких примерах использования:

1. Доступ к данным сотрудников. Предположим, что менеджер по персоналу должен иметь возможность просматривать все записи сотрудников, тогда как HR-аналитик должен иметь возможность просматривать записи неуправленческого персонала. RLS можно использовать для настройки этих ролей и правил доступа, гарантируя, что при доступе к отчету HR-аналитик будет видеть только те данные, которые ему разрешено просматривать.
2. Данные о зарплате. Данные о зарплате конфиденциальны и не должны быть доступны для всех. С помощью RLS вы можете ограничить доступ к данным о зарплате только для определенных ролей, например менеджера по персоналу, скрыв их от других пользователей.
3. Оценка производительности. Если данные о производительности необходимо предоставить руководителям отделов, но вы хотите убедиться, что каждый руководитель может видеть только данные, относящиеся к его отделу, RLS может помочь в этом. Установив фильтр на основе ролей в поле отдела в ваших данных, вы можете гарантировать, что пользователи при доступе к отчету будут видеть только данные, относящиеся к их роли.

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

Давайте разберем это на конкретном примере.

1. Компания оцифровала процессы и данные о

2. организационная структура

3. обучение,
4. отзывы.

1. В компании есть руководители групп и отдельные участники. В корпоративной культуре по умолчанию тимлид видит все, что происходит с его подчиненными в HR-процессах без исключений.

3. Словарь разрешений позволяет каждому пользователю отображать/скрывать данные определенного отдела.

4. Есть четыре роли:

• Руководитель отдела кадров anlukyanov@sample.com (видит все подразделения компании)
• Руководитель отдела обучения karenpark@sample.com (видит все подразделения компании, кроме HR)
• Руководитель финансового отдела mitchellfox@sample.com (просматривает данные своего подразделения и отдела продаж, находящегося под его руководством)
• Глава казначейства rachelhernandez@sample.com (видит данные только своего отдела)

Таким образом, нам нужно рассмотреть два источника образца для подражания:

• организационная структура (для предоставления руководителям групп доступа к подчиненным данным)
• разрешения (для отображения данных для контролируемых отделов в рамках функции)

Давайте построим схему данных и напишем необходимый DAX.

1. Подготовьте 4 таблицы данных:

2. employee_data (логин, Chain1, isHead, Name, Unit, Department, Age, Experience)

* права доступа (логин, Chain, ShowDpt, где Chain - полный путь к отделу, ShowDpt - показать/скрыть данные отдела)

* training_data (логин, название тренировки, тип тренировки)

* performance_review_data (логин, последняя проверка производительности)

1. Загрузите все четыре таблицы в PowerBI. После этого шага:

2. В редакторе Power Query мы добавляем столбец Chain1 в таблицу employee_data, используя формулу

= Table.AddColumn(#"change_type", "Chain1", each Text.Combine({"SampleCompany",
if [Unit] is null then null else "->",
[Unit],
if [Department] is null then null else "->",
[Department]
}))

Это позволит нам динамически создавать цепочки отделов и использовать их в качестве образца для подражания.

* Создайте новую таблицу исключений с помощью DAX

exception = CROSSJOIN('разрешения',DISTINCT('employee_data'[Chain1]))

Смысл этой процедуры в том, чтобы соединить таблицы employee_data и разрешения

• Создайте столбец RLS в таблице исключений, используя формулу DAX.

RLS = if(CONTAINSSTRING([Chain1],[Chain]),[ShowDpt],blank()) * Создайте столбец eRLS в таблице исключений, используя формулу DAX

javascript eRLS= var mail = 'исключение'[Электронная почта] var cep = 'исключение'[Chain1] var rls = 'исключение'[RLS] возвращаться if(РАСЧЕТ(количество('исключение'[RLS]),фильтр('исключение','исключение'[email]=mail&&'исключение'[Chain1]=cep&&'исключение'[RLS]=" нет"))>0 ,"нет",rls)

Идея этого выражения заключается в объединении информации о доступных отделах из организационной структуры (таблица Employee_data) и словаря разрешений (таблица разрешений)

* Создайте структурированную таблицу со списком уникальных отделов. В редакторе Power Query -> Новый исходный код -> Пустой -> Перейти к расширенному редактору и предыдущему коду:

javascript позволять Источник = Таблица.Объединить({employee_data}), #"Удалить столбцы" = Table.SelectColumns(Source,{"Unit", "Department","Chain1"}), #"Distinct" = Table.Distinct(#"Удалить столбцы") в #"Отдельный"

1. Необходимо написать правила для ролей.

2. Открыть меню Моделирование->Управление ролями

3. Создайте новую роль (например, с именем rls)
4. Для таблицы employee_data (она будет нашей краеугольной) напишите следующий DAX:

```javascript //получаем логин пользователя из системы var usr = userprincipalname()

//создаем таблицу с цепочками и isHead var xtable = добавить столбцы (выбрать столбцы ( CALCULATETABLE('employee_data',filter('employee_data','employee_data'[email]=usr) ), "Цепочка_функция",[Цепочка1],"Голова_функция",[являетсяГолова] ),
"xxx", если (содержит строку ('employee_data' [Chain1], [Chain_feature]) = true (), 1,0) )

var headFeature = SUMX(xtable,[Head_feature]) переменная xfactor = СУММ(xtable,[xxx])

//подчиненные, если руководитель var x = if(headFeature =0, false(), if (xfactor=0, false(), true()))

//добавляем исключения var exc = содержит('разрешения', 'разрешения'[email],usr)

var head_Search = вычислить(firstnonblank('исключение'[eRLS],1),filter('исключение', 'исключение' [Chain1]= 'employee_data'[Chain1]&&'exception'[email]= уср)) вернуться

//результат если(exc=true(),if(head_Search="yes",true(),if(x=true(),true(),false())),if(x=true(),true(), ЛОЖЬ())) ```

* Мы загрузили данные и реализовали объединение словарей доступа. осталось связать основную таблицу employee_data с вторичными данными по обучению и просмотру. Это делается путем организации отношений * структура -> employee_data (количество элементов — ManyToOne, направление перекрестного фильтра — одиночное) * данные_сотрудника -> performance_review_data (количество элементов — ManyToOne, направление перекрестного фильтра — одиночное) * данные_сотрудника -> training_data (количество элементов — ManyToOne, направление кросс-фильтра — одиночное)

Пришло время проверить производительность нашей модели RLS.

1. Исходные данные

1. Руководитель отдела кадров anlukyanov@sample.com (видны все подразделения компании)

Виджет с зарегистрированным пользователем, созданный с помощью меры:

lgn = userprincipalname()  

1. Начальник отдела обучения karenpark@sample.com (видит все подразделения компании, кроме HR)

1. Руководитель финансового отдела mitchellfox@sample.com (просматривает данные своего подразделения и отдела продаж, находящегося под его руководством)

1. Глава казначейства rachelhernandez@sample.com (видит данные только своего отдела)

WITH 
--get user login from system
'{{ current_username() }}' as user_name,

--add permissions
rls_levels as
(SELECT
       login,
       Unit,       Department
       FROM HR.permissions
       WHERE login = user_name and show_or_hide = 1),

--add org structure
manager_levels as     (SELECT
       user_name,
       Unit,       Department
       FROM HR.employee_data
      WHERE login = user_name 
              and is_manager = 1),

--union two dictionaries
included as (
    SELECT groupArray(values)
    FROM ( SELECT CONCAT('SampleCompany',
      ifNull(Unit, ''),
      ifNull(Department, '')) as values

      FROM ( SELECT * FROM rls_levels
                    union all
                    SELECT * FROM manager_levels))
      ),

--add exceptions
exceptions as (
  SELECT groupArray(values)
    FROM ( SELECT CONCAT('SampleCompany',
      ifNull(Unit, ''),
      ifNull(Department, '')) as values
      FROM HR.permissions
      WHERE login = user_name and show_or_hide = 0
)
    )


--employee_data
SELECT * FROM
    (SELECT
        category, email, Name, Unit, Department, isHead, Age, Experience

    FROM HR.employee_data) AS t

--filter
WHERE
    --filter all departments with access
    multiSearchAny(
      --needle
       CONCAT('SampleCompany',ifNull(t.Unit,''),
       ifNull(t.Department,'')),
       --haystack
       (SELECT * FROM included)
    ) > 0
    AND
    --filter out  all departments without access
    multiSearchAny(
       --needle
       CONCAT('SampleCompany',ifNull(t.Unit,''),
       ifNull(t.Department,'')),
       --haystack
       (SELECT * FROM exceptions)
    ) == 0