ПДн в BI-отчётах и Excel-выгрузках: как маскировать, ограничивать экспорт и контролировать рассылку

Полный практический гид для аналитиков, ИТ- и ИБ-специалистов российских компаний в условиях ужесточения требований 152-ФЗ

Почему BI и Excel стали главной дырой в периметре ПДн

Аналитические отчёты и выгрузки в Excel создавались для скорости бизнес-решений, а не для защиты данных. Маркетолог строит дашборд по клиентской базе, финансовый директор получает сводку с ФИО и окладами сотрудников, операционный менеджер выгружает реестр заказов вместе с адресами и телефонами — и всё это движется по корпоративной почте, Telegram-группам и облачным папкам практически без контроля.

Эта привычная практика давно стала источником системного риска. По данным ГК InfoWatch, объём скомпрометированных персональных данных в России за 2024 год превысил 710 млн записей [2], а эксперты, опрошенные «Известиями», указывают, что свыше 90% утечек провоцируются действиями или ошибками собственных сотрудников [3]. Типичный сценарий — менеджер случайно пересылает таблицу с клиентской базой не тому адресату, стажёр выгружает данные в облачный документ с публичной ссылкой, бухгалтер отправляет платёжку на личную почту [5].

До 2025 года штрафы за нарушения были относительно необременительными, и многие компании сознательно закрывали на проблему глаза. Теперь ситуация изменилась кардинально: с 30 мая 2025 года максимальный штраф за утечку в результате одного инцидента составляет 15–20 млн рублей, а при повторном нарушении — оборотные санкции до 500 млн рублей [1, 6]. В конце 2024 года введена уголовная ответственность по новой статье 272.1 УК РФ [7].

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

Раздел 1. Правовой контекст: что изменилось и чего ждать

1.1 Новый ландшафт штрафов с 30 мая 2025 года

Федеральный закон № 420-ФЗ от 30 ноября 2024 года радикально пересмотрел статью 13.11 КоАП РФ. Теперь санкции дифференцированы по масштабу утечки [6, 1]:

1. За утечку данных от 1 000 до 10 000 физлиц — штраф для организации от 3 до 5 млн рублей.
2. За утечку данных от 10 000 до 100 000 физлиц — от 5 до 10 млн рублей.
3. За утечку данных более 100 000 физлиц — от 10 до 15 млн рублей.
4. За утечку биометрических данных — от 15 до 20 млн рублей.
5. За повторное нарушение любой категории — оборотный штраф от 1 до 3% годовой выручки, не менее 20 и не более 500 млн рублей.
6. За неуведомление Роскомнадзора о факте утечки в течение 24 часов — от 1 до 3 млн рублей.

Принципиально важно: ответственность несёт оператор персональных данных, а не подрядчик, даже если фактический доступ к системе был у последнего [8]. Это означает, что рассылка Excel-файлов с ПДн внешним аналитикам или партнёрам — риск самой компании.

1.2 Обезличивание: новые правила с 1 сентября 2025 года

С 1 сентября 2025 года вступил в силу Приказ Роскомнадзора № 140, устанавливающий требования и методы обезличивания ПДн для всех случаев обработки [4]. Параллельно Постановление Правительства № 1154 регулирует обезличивание данных, передаваемых по запросу Минцифры в ГИС.

Утверждённые методы обезличивания включают: создание идентификаторов (псевдонимизация), изменение состава и семантики, перемешивание (подстановка реалистичных, но ненастоящих значений), декомпозицию (разбиение данных таким образом, чтобы из части невозможно было идентифицировать субъекта) [4]. Ключевое требование — хранить исходные и обезличенные данные отдельно, фиксировать все действия по обезличиванию, и проверять, что идентификация субъекта действительно невозможна.

Для аналитики это прямое руководство к действию: выгрузки в Excel и BI-отчёты, предназначенные для широкой аудитории, должны содержать либо агрегированные показатели, либо обезличенные данные, а не сырые ПДн.

1.3 Уголовная ответственность

С декабря 2024 года действует статья 272.1 УК РФ, предусматривающая уголовную ответственность за использование, передачу или распространение ПДн, полученных незаконно, а также за создание ресурсов для их хранения [7]. Это меняет управленческую логику: речь идёт не только о корпоративных рисках, но и о персональной ответственности конкретных должностных лиц.

Раздел 2. Анатомия проблемы: как ПДн попадают в BI и Excel

2.1 Типичные сценарии утечки через аналитические инструменты

Перечислим наиболее распространённые векторы, с которыми сталкиваются российские компании.

1. Прямые запросы к БД — аналитик имеет доступ к производственной базе данных и выгружает полную таблицу клиентов, включая ФИО, паспортные данные, адреса. Никакого контроля на уровне запроса нет.
2. Неограниченный экспорт из BI — в Power BI или аналогичной системе сотрудник открывает отчёт с видимыми ему данными и нажимает «Экспорт в Excel». Выгрузка уходит на его рабочий стол, а дальше — в мессенджер или на личную почту.
3. Плановые рассылки — автоматические или ручные регулярные рассылки Excel-файлов по спискам получателей. Со временем список расширяется, форматы меняются, и никто не проверяет, нужны ли получателям все поля с ПДн.
4. Тестовые среды — разработчики и аналитики работают с копиями продуктивных БД, не подозревая или игнорируя, что в них содержатся реальные ПДн клиентов. Европейский регулятор (EDPB) в рекомендациях 2024 года прямо указал: использование немаскированных данных в тестовых средах является нарушением принципов обработки [9].
5. Теневые копии — сотрудники создают локальные Excel-файлы как «удобные выписки», не понимая, что каждая такая копия становится отдельной неучтённой базой ПДн.

2.2 Почему классические ИТ-меры не работают

Традиционная защита периметра — межсетевые экраны, антивирусы, шифрование диска — не защищает от описанных сценариев. Сотрудник с легитимным доступом к BI-системе действует в рамках своих полномочий. Проблема не в несанкционированном доступе извне, а в избыточном доступе изнутри и в отсутствии контроля над «последней милей» — экспортом данных.

По данным анализа ГК InfoWatch за 2024 год, более 99% утечек в России носят умышленный характер (в том числе корыстный или из-за халатности), и только 0,5% — случайные [10]. Это означает, что технические меры должны быть направлены прежде всего на контроль того, что делают авторизованные пользователи с данными, а не только на отражение внешних атак.

Раздел 3. Технические методы защиты на уровне источника данных

3.1 Dynamic Data Masking в SQL Server

Динамическое маскирование данных (DDM) — механизм, встроенный в SQL Server начиная с версии 2016, позволяющий скрывать значения столбцов для непривилегированных пользователей без изменения физических данных в БД [11].

Принцип работы: на столбец с ПДн накладывается правило маскирования (например, показывать только первую букву имени или последние четыре цифры номера карты). Пользователь без разрешения UNMASK видит замаскированное значение. Пользователь с разрешением UNMASK — оригинальное.

Доступные функции маскирования в SQL Server [11]:

1. Default — полная замена значения: строки заменяются на «XXXX», числа — на 0, даты — на 1900-01-01.
2. Email — показывает первую букву адреса и домен: «a*@example.com».
3. Random — для числовых полей: заменяет на случайное значение в заданном диапазоне.
4. Partial — гибкая маска: можно показать первые N и последние M символов.

Ограничение, которое важно учитывать: DDM не является полноценной мерой безопасности сам по себе [11]. Пользователь с правом выполнения произвольных запросов может применить различные техники для вывода замаскированных значений. DDM рекомендуется использовать совместно с RLS, аудитом и строгим контролем прав.

С SQL Server 2022 появилась возможность управлять разрешением UNMASK на уровне базы данных, схемы, таблицы или отдельного столбца — это существенно расширяет гибкость настройки [11].

3.2 Маскирование на уровне представлений (Views)

Более традиционный, но надёжный подход — создавать представления (views) в БД, которые уже содержат агрегированные или маскированные данные. Аналитический слой (ETL/BI) подключается именно к этим представлениям, а не к базовым таблицам с ПДн.

Преимущества: работает для любой СУБД, не требует специальных функций DDM, даёт полный контроль над тем, какие данные попадают в аналитику. Недостаток: требует изначально правильного проектирования и дисциплины — аналитикам не должны предоставляться права на прямой доступ к базовым таблицам.

3.3 Статическое и динамическое маскирование: в чём разница

Статическое маскирование (Static Data Masking) — необратимое преобразование данных в копии БД. Применяется для тестовых и аналитических сред, где нужно работать с реалистичной структурой, но без реальных ПДн. По рекомендациям EDPB 2024 года, именно такой подход требуется для тестовых окружений [9].

Динамическое маскирование — маскирование «на лету» при запросе. Данные в хранилище не изменяются; трансформация происходит в момент передачи результата пользователю. Применяется в продуктивных системах для разграничения доступа разных ролей.

По данным международного обзора 2024 года, 60% крупных организаций планируют или уже используют технологии маскирования данных в аналитических и облачных средах для защиты чувствительных данных [12].

Раздел 4. Защита на уровне BI-платформы

4.1 Row-Level Security: безопасность на уровне строк

Row-Level Security (RLS) — механизм, ограничивающий доступ пользователя к определённым строкам данных в зависимости от его роли или идентификатора. В Power BI RLS реализуется через DAX-фильтры, применяемые к ролям [13].

Существует два типа RLS:

Статический RLS — для каждой роли задаётся жёстко прописанное условие фильтрации. Например, роль «Регион_Север» видит только строки, где поле Region = "Север". Подходит для небольших организаций с предсказуемой структурой ролей.

Динамический RLS — фильтрация происходит на основе идентификатора текущего пользователя. Используются DAX-функции USERNAME() или USERPRINCIPALNAME(), которые возвращают логин пользователя и сопоставляют его с таблицей разрешений [13]. Динамический RLS масштабируем: для добавления нового пользователя достаточно добавить запись в таблицу маппинга, а не создавать новую роль.

Критически важное ограничение: RLS не применяется к пользователям, у которых есть право редактирования рабочей области (Admin, Member, Contributor) [13]. Для сотрудников ИТ и аналитиков, которые строят отчёты, RLS прозрачен — они видят все данные. Если нужно ограничить и их, следует использовать DDM на уровне источника данных.

Ещё одно ограничение: при добавлении пользователя в несколько ролей фильтры становятся аддитивными (объединение по OR, а не AND) [14]. Это может привести к тому, что пользователь увидит больше данных, чем предполагалось. При проектировании ролей нужно тщательно тестировать граничные случаи.

4.2 Object-Level Security: безопасность на уровне объектов

Object-Level Security (OLS) — дополнение к RLS, позволяющее скрывать от пользователей не строки, а целые таблицы или столбцы [15]. Если к столбцу с номером паспорта применено OLS, пользователь без разрешения не только не видит значений — он не видит само поле в списке доступных полей отчёта.

OLS особенно полезен в сценарии, когда центральная модель данных используется разными командами, которым нужны разные наборы полей. Аналитики по продажам могут видеть поле «город», но не «адрес» или «телефон»; HR-специалисты — наоборот.

Ограничения OLS: оно не наследуется автоматически при подключении к семантической модели через Excel Power Query или «Анализ в Excel», если у пользователя есть права BUILD на семантическую модель [16].

4.3 Метки конфиденциальности Microsoft Purview: защита за пределами BI

Microsoft Purview Information Protection позволяет назначать метки конфиденциальности (Confidential, Highly Confidential и т. д.) непосредственно на семантические модели, отчёты, дашборды в Power BI [17]. Ключевой эффект — метка «путешествует» вместе с данными при экспорте.

Когда пользователь экспортирует отчёт с меткой «Конфиденциально» в Excel или PDF, экспортированный файл автоматически получает ту же метку и связанные с ней политики шифрования [17]. Это означает, что даже если файл попадёт не к тому получателю, открыть его смогут только авторизованные пользователи.

Механизм работает следующим образом: метки создаются в портале Microsoft Purview, публикуются для организации, применяются к артефактам Power BI (вручную или через политику авто-применения), и при экспорте наследуются экспортируемым файлом [17, 18]. Наследование работает и «вниз по потоку»: если метка назначена семантической модели, все отчёты, построенные на её основе, автоматически получают ту же или более строгую метку [18].

Ограничения для российских компаний: Microsoft Purview — экосистема Microsoft 365, требующая соответствующего лицензирования (E3/E5 или E5 Compliance) и облачной инфраструктуры. Для организаций, работающих в on-premise-окружении или использующих российские BI-платформы, этот инструментарий напрямую неприменим.

4.4 Политики DLP для Power BI

Microsoft 365 Data Loss Prevention (DLP) позволяет центральным службам безопасности определять политики, которые срабатывают при работе с данными Power BI [17]. Например, политика может блокировать экспорт данных с определённой меткой конфиденциальности или генерировать уведомление администратору при попытке выгрузки. В сочетании с метками Purview это создаёт управляемый, аудитируемый контур экспорта.

Раздел 5. Контроль экспорта и рассылки Excel-файлов

5.1 Административные настройки экспорта в Power BI

Администраторы Power BI Service (Fabric) имеют возможность централизованно управлять настройками экспорта для всей организации или для отдельных групп пользователей [19]. В разделе Tenant Settings > Export and Sharing можно независимо включать или отключать:

1. Экспорт в Excel — разрешить или запретить выгрузку данных из визуализаций в .xlsx.
2. Экспорт в CSV — аналогично для формата .csv.
3. Экспорт в PDF и PowerPoint — для форматов представления.
4. Копирование визуальных элементов — вставку изображений дашбордов во внешние приложения.
5. Публикацию в интернете (Publish to Web) — категорически не рекомендуется при работе с ПДн.

Рекомендуемый подход для работы с ПДн: запрещать экспорт на уровне tenant для всех пользователей, а затем создавать исключения для конкретных групп безопасности, которым экспорт необходим по бизнес-задачам.

5.2 Маскирование через вычисляемые поля и Calculation Groups

В случаях, когда полный запрет экспорта невозможен (например, аналитики должны иметь возможность выгрузки агрегированных данных, но не детальных ПДн), можно применять маскирование на уровне мер DAX.

Техника с Calculation Groups позволяет создать элемент вычисления, который при определённом условии (роль пользователя, применённый фильтр) подменяет реальное значение маской [20]. По результатам тестирования, проведённого разработчиком Sam Campitiello, использование Calculation Groups для маскирования примерно в 1,5 раза эффективнее по производительности по сравнению с фильтр-мерами [20].

Ограничение: метод работает только с мерами DAX, не с прямыми столбцами. Если в визуализации используется «сырое» поле из таблицы (без агрегирующей меры), Calculation Groups не применяются.

5.3 Организационные меры контроля рассылки

Технические меры необходимы, но недостаточны. Нужны регламенты, определяющие, кто, кому, с какой периодичностью и какие данные может рассылать.

Ключевые элементы регламента рассылки ПДн через Excel:

1. Реестр регулярных рассылок — перечень всех плановых выгрузок с указанием: источника данных, состава полей, списка получателей, цели рассылки, правового основания, ответственного лица.
2. Принцип минимальной достаточности — получатель должен видеть только те поля ПДн, которые необходимы для его конкретной задачи. Аналитик по маркетингу не нуждается в паспортных данных клиентов.
3. Процедура согласования новых рассылок — добавление новых получателей или полей с ПДн должно проходить через ответственного за ПДн.
4. Срок хранения рассылок — регламент должен определять, сколько времени получатели могут хранить Excel-файлы с ПДн, и требовать их уничтожения после истечения срока.
5. Запрет пересылки — регламент должен запрещать перенаправление файлов с ПДн третьим лицам без согласования.

5.4 Шифрование Excel-файлов

Для файлов, которые необходимо рассылать, можно применять защиту паролем или шифрование. Excel поддерживает встроенную защиту документа паролем; при использовании меток Purview шифрование применяется автоматически с управлением ключами через Azure Rights Management [17].

Важное ограничение: пароль на Excel-файл — слабая защита. Она легко обходится специализированными инструментами и не обеспечивает управление доступом, аудит или отзыв доступа. Это мера временного сдерживания, а не полноценная защита. Предпочтительный подход — вместо рассылки файлов предоставлять доступ к защищённому BI-отчёту, который не содержит детальных ПДн.

Раздел 6. Обезличивание данных в выгрузках: методы и практика

6.1 Что такое обезличивание и как его применять к выгрузкам

Согласно статье 3 Федерального закона № 152-ФЗ, обезличивание — это действия, в результате которых становится невозможным без дополнительной информации определить принадлежность персональных данных конкретному субъекту [21]. Обезличенные данные не признаются персональными и не подпадают под большинство ограничений 152-ФЗ — что делает их идеальным форматом для аналитических выгрузок.

На практике для Excel-отчётов и BI применяются следующие методы:

1. Замена идентификаторами — вместо ФИО клиента используется числовой ID или хэш. Например, «Иванов Иван Иванович» заменяется на «Клиент_4891». Ключ соответствия хранится отдельно и доступен ограниченному числу сотрудников [4].
2. Обобщение — вместо точного адреса указывается только город или регион; вместо точного возраста — возрастная группа (25–34 года).
3. Агрегирование — вместо детальных данных о каждом клиенте выгружаются только сводные показатели (количество клиентов по регионам, средний чек по категории товаров).
4. Перемешивание — значения одного поля случайным образом переназначаются другим записям, сохраняя статистическое распределение, но разрывая связь данных с конкретной личностью.
5. Шумовое добавление (noise injection) — к числовым полям (оклад, сумма транзакции) добавляется случайное отклонение в допустимых пределах.

Требование Приказа РКН № 140: исходные и обезличенные данные должны храниться раздельно; все операции обезличивания должны фиксироваться в журнале с указанием даты, метода и лиц, которым переданы обезличенные данные [4].

6.2 k-анонимность и l-разнообразие: почему простое удаление полей не работает

Распространённая ошибка — думать, что удаление поля «ФИО» из выгрузки делает данные обезличенными. Это не так. Если в выгрузке остаются поля «возраст», «должность», «город» и «отдел», то комбинация этих атрибутов может однозначно идентифицировать конкретного человека — особенно в небольших коллективах.

Концепция k-анонимности требует, чтобы каждая запись в датасете была неотличима как минимум от k−1 других записей по квазиидентификаторам. На практике для кадровой аналитики это означает, например, что нельзя публиковать данные о зарплатах в разрезе должность+город, если в такой комбинации менее 5 человек — иначе данные деанонимизируются по умолчанию.

Раздел 7. Особые риски и типичные ошибки

7.1 Тестовые и аналитические окружения

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

EDPB (Европейский комитет по защите данных) в руководстве 2024 года прямо квалифицировал использование немаскированных ПДн в тестовых средах как нарушение принципа законности, справедливости и прозрачности по статье 5(1)(a) GDPR, если данные не были псевдонимизированы или анонимизированы [9]. В российской практике прямого эквивалента этой нормы пока нет, но такой подход противоречит принципу минимизации данных по статье 5 Федерального закона № 152-ФЗ.

Правильный подход: для тестовых сред использовать синтетические (сгенерированные) данные или статически маскированные копии. Инструменты статического маскирования (IRI FieldShield, IBM Guardium, собственные ETL-скрипты) позволяют создать реалистичную по структуре, но полностью обезличенную копию БД.

7.2 Теневые IT и неучтённые базы ПДн

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

По данным исследования Роскомнадзора, в обзоре наиболее часто выявляемых нарушений одно из ключевых — отсутствие актуального учёта мест хранения ПДн [21]. Это означает, что при проверке или инциденте компания не может ответить на вопрос «где у нас хранятся персональные данные?» — и это само по себе является нарушением.

7.3 Автоматические рассылки без ревизии

Автоматические отчёты, настроенные «когда-то давно» и рассылаемые по расписанию, — отдельная категория риска. Список получателей устаревает (сотрудники увольняются, переходят в другие отделы), состав полей расширяется (кто-то добавил новый столбец в запрос), а контроль за рассылкой не ведётся.

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

7.4 Избыточные права разработчиков и администраторов BI

Как было отмечено выше, администраторы, участники и соавторы рабочих областей Power BI автоматически обходят все настройки RLS и OLS [13, 16]. Аналогичная ситуация в большинстве других BI-платформ. Если разработчик BI-системы имеет доступ ко всем данным, это означает, что в случае его компрометации (взлом аккаунта, инсайдерская угроза) злоумышленник получает полный доступ к ПДн без каких-либо технических барьеров.

Решение: применять DDM на уровне источника данных (SQL Server, DWH) для тех сотрудников, которым не нужен доступ к немаскированным данным даже при разработке. Разработчику следует подключаться к маскированной схеме, а продуктивной модели — к немаскированной.

Раздел 8. Практический чек-лист

Шаг 1: Инвентаризация

1. Составить реестр всех источников данных, из которых строятся BI-отчёты и Excel-выгрузки.
2. Для каждого источника определить, какие поля содержат ПДн (прямые идентификаторы: ФИО, телефон, email, паспорт; квазиидентификаторы: дата рождения, должность, город; специальные категории: данные о здоровье, биометрия).
3. Составить список всех регулярных и разовых рассылок с Excel-файлами: кто отправляет, кому, что содержат.
4. Провести аудит прав доступа: кто имеет возможность выгрузить полные таблицы ПДн напрямую из БД или через BI.

Шаг 2: Классификация и приоритизация

1. Ранжировать источники по уровню чувствительности данных (общие ПДн, специальные категории, биометрия).
2. Определить для каждого BI-отчёта и рассылки: нужны ли в нём детальные ПДн или достаточно агрегатов и идентификаторов?

Шаг 3: Технические меры

1. Настроить DDM в SQL Server или аналогичные механизмы в используемой СУБД для полей с ПДн.
2. Реализовать RLS в BI-платформе, разграничив видимость строк по ролям пользователей.
3. Настроить OLS для скрытия столбцов с ПДн от пользователей, которым они не нужны.
4. Ограничить или отключить возможность экспорта данных в Excel/CSV для групп пользователей, не имеющих обоснованной потребности в выгрузке.
5. Внедрить метки конфиденциальности (если используется Microsoft 365) для автоматического шифрования экспортируемых файлов.
6. Для тестовых сред создать статически маскированные или синтетические датасеты; запретить доступ к продуктивным ПДн из тестового окружения.

Шаг 4: Организационные меры

1. Создать и утвердить реестр регулярных рассылок с ПДн; назначить ответственного владельца каждой рассылки.
2. Установить срок хранения Excel-файлов с ПДн у получателей; ввести процедуру уничтожения после истечения срока.
3. Внедрить процедуру согласования новых рассылок или расширения состава полей.
4. Провести обучение сотрудников по правилам работы с ПДн в Excel и BI: принцип минимальной необходимости, запрет пересылки личных данных через мессенджеры.

Шаг 5: Мониторинг и аудит

1. Включить аудит действий пользователей в BI-платформе (Power BI Activity Log, Fabric Audit Log) и в СУБД (SQL Server Audit, Extended Events).
2. Настроить алерты на аномальные выгрузки: экспорт большого объёма данных, частый экспорт ПДн, экспорт вне рабочего времени.
3. Проводить регулярный (ежеквартальный) пересмотр прав доступа и актуальности рассылок.

Раздел 9: Взгляд в будущее — тренды 2025–2026

9.1 Рост требований к обезличиванию

С введением Приказа РКН № 140 и созданием ГИС Минцифры с обезличенными данными граждан государство формирует инфраструктуру, при которой обезличивание становится не просто лучшей практикой, а обязательным стандартом. Вероятно, в ближайшие 1–2 года появятся методические рекомендации, уточняющие требования к обезличиванию данных в аналитических системах организаций [4].

9.2 Privacy-Enhancing Technologies в аналитике

В мире активно развиваются PET (Privacy-Enhancing Technologies) — технологии, позволяющие проводить анализ данных без раскрытия ПДн. К ним относятся дифференциальная приватность (Differential Privacy), федеративное обучение, вычисления в доверенной среде (Trusted Execution Environment). Платформы, такие как Immuta, используют динамическое маскирование совместно с PET для выполнения аналитики без передачи сырых данных [9]. По прогнозу аналитиков, 60% крупных организаций планируют использовать подобные технологии в аналитических средах [12].

9.3 Artificial Intelligence и автоматическая классификация ПДн

Всё больше BI-платформ и инструментов управления данными интегрируют AI для автоматического обнаружения и классификации полей с ПДн. Microsoft Purview поддерживает авто-маркировку на основе правил и ML-моделей. Это важный тренд: при постоянно меняющемся ИТ-ландшафте ручное отслеживание всех источников ПДн становится нереалистичным.

9.4 Zero Trust и принцип минимальных привилегий

Концепция Zero Trust («нулевого доверия»), описанная в ряде российских академических работ как один из ключевых трендов [22], предполагает, что ни один пользователь и ни одна система не получают доступа больше, чем необходимо для конкретной задачи, — и что каждый доступ проверяется. Применительно к BI это означает, что доступ к отчётам с ПДн должен быть явно авторизован, регулярно пересматриваться и сопровождаться аудитом.

Раздел 10. Как «Пятый фактор» помогает решить проблему невидимости ПДн

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

На практике большинство организаций не знают ответа. ИТ-ландшафт постоянно меняется: появляются новые поля в базах данных, новые источники данных, новые интеграции, новые аналитические витрины. Без непрерывного мониторинга компания узнаёт о том, что в каком-то BI-отчёте или Excel-рассылке появились ПДн, только при инциденте или проверке.

Именно эту проблему решает платформа Пятый фактор. Это on-premise решение для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: базах данных, хранилищах, почте, Active Directory/LDAP, CRM, 1С, API. Система работает с метаданными, структурой данных и агрегатами — без передачи и хранения сырых значений ПДн. Это принципиально важно: платформа сама не становится источником риска.

В результате компания получает:

1. Живую «карту ПДн» — актуальную картину того, где именно и какие персональные данные хранятся, кто является владельцем данных, что изменилось с момента последней проверки.
2. Раннее обнаружение новых рисков — появление нового поля с ПДн в БД, нового источника данных или новой интеграции фиксируется автоматически, до того как данные попадут в BI-отчёты и Excel-рассылки.
3. Ускорение аудита и подготовки к проверкам — вместо недель ручного сбора информации о том, где хранятся ПДн, ответственный офицер получает актуальный реестр за минуты.
4. Контроль как непрерывный процесс — вместо разовых проверок раз в год система обеспечивает постоянный мониторинг, выявляя нарушения и отклонения в режиме реального времени.

В контексте данной статьи это означает: прежде чем настраивать RLS и DDM, нужно знать, в каких таблицах есть ПДн и какие из этих таблиц используются в ваших BI-отчётах. «Пятый фактор» даёт именно эту картину — и позволяет приоритизировать технические меры там, где они действительно нужны.

Заключение: что делать дальше

Работа с ПДн в BI-отчётах и Excel-выгрузках — не разовая задача, а непрерывный процесс. ИТ-ландшафт меняется, требования регулятора ужесточаются, а число каналов распространения данных только растёт.

Практические шаги, которые стоит предпринять уже сейчас:

1. Провести инвентаризацию — выяснить, какие BI-отчёты и рассылки содержат ПДн. Без этого шага любые технические меры будут неполными.
2. Ввести минимальный регламент рассылки — даже простой список «кто, кому и что рассылает» уже снижает риск случайных утечек.
3. Настроить RLS и OLS в существующих BI-инструментах — это доступно бесплатно в рамках Power BI Service и большинстве корпоративных BI-платформ.
4. Ограничить экспорт — отключить возможность выгрузки в Excel для групп пользователей, которым она не нужна для работы.
5. Запланировать переход к агрегированным отчётам — для большинства бизнес-задач детальные ПДн не нужны; достаточно агрегатов. Это самая надёжная защита от утечки через выгрузку.

Штрафы растут, регулятор ужесточает контроль, а инциденты происходят регулярно. По данным Роскомнадзора, только в 2024 году зафиксировано 135 утечек баз данных, в результате которых скомпрометировано более 710 млн записей [2]. Ни одна из организаций, допустивших эти утечки, не планировала их заранее. Разница между теми, кто понесёт последствия, и теми, кто минимизирует риски, — в системном подходе к управлению данными.

Источники

[1] Консультант Плюс. Новые штрафы за утечку персональных данных и другие нарушения. — https://www.consultant.ru/legalnews/28492/

[2] Роскомнадзор / ТАСС. Число утечек персональных данных в России в 2024 году — 135 инцидентов, более 710 млн записей. — https://www.tadviser.ru/index.php/Статья:Утечки_данных_в_России

[3] Известия. Свыше 90% утечек — вина сотрудников, данные экспертов по кибербезопасности. — https://iz.ru/1334130/ekaterina-korinenko/vas-slivaiut-90-utechek-sprovotcirovany-chelovecheskim-faktorom

[4] Клерк.ру. Обезличивание персональных данных: новые правила с 1 сентября 2025 года. Приказ Роскомнадзора № 140. — https://www.klerk.ru/blogs/data-sec/662273/

[5] SEOnews. Риски для бизнеса: чем опасны утечки персональных данных. — https://m.seonews.ru/analytics/utechka-dannykh-kak-odna-oshibka-mozhet-stoit-kompanii-milliony-rubley/

[6] Арбитр-практика. Штрафы за персональные данные с 30 мая 2025 года. — https://www.arbitr-praktika.ru/article/2742-shtrafy-za-personalnye-dannye

[7] Правовест Аудит. Изменения в обработке персональных данных с 30 мая 2025 года. Статья 272.1 УК РФ. — https://pravovest-audit.ru/nashi-statii-nalogi-i-buhuchet/izmeneniya-v-obrabotke-personalnykh-dannykh-s-30-maya-2025-goda/

[8] Case Group. Утечка персональных данных: новые штрафы до 500 млн рублей с 2025 года. Ответственность оператора. — https://case-group.ru/posts/otvetstvennost-za-utechku-personalnyh-dannyh/

[9] Accutive Security. GDPR Data Masking: PII Protection & Compliance Guide 2025. Рекомендации EDPB 2024. — https://accutivesecurity.com/how-to-implement-gdpr-data-masking-without-sacrificing-usability/

[10] ГК InfoWatch. Количество слитых персональных данных в 2024 году выросло на треть. — https://www.infowatch.ru/company/presscenter/news/kolichestvo-slitykh-personalnykh-dannykh-v-dve-tysyachi-dvadtsat-chetvertom-godu-vyroslo-na-tret

[11] Microsoft Learn. Dynamic Data Masking — SQL Server. — https://learn.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking

[12] OvalEdge. Best Data Masking Tools for Secure Data in 2026. Отчёт Eviden 2024. — https://www.ovaledge.com/blog/data-masking-tools/

[13] Microsoft Learn. Row-level security (RLS) with Power BI — Microsoft Fabric. — https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security

[14] Microsoft Learn. Row-level security (RLS) guidance in Power BI Desktop. — https://learn.microsoft.com/en-us/power-bi/guidance/rls-guidance

[15] Microsoft Learn. Object-Level Security (OLS) with Power BI — Microsoft Fabric. — https://learn.microsoft.com/ru-ru/fabric/security/service-admin-ols

[16] Abylon. Data Masking in Power BI in 2025 — Part 2. OLS и RLS: ограничения. — https://abylon.io/blog/data-masking-in-power-bi-in-2025-part-2/

[17] Microsoft Learn. Data protection in Power BI — Microsoft Purview sensitivity labels, DLP. — https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-security-data-protection-overview

[18] Power BI Consulting. Power BI Sensitivity Labels and Information Protection: Enterprise Guide for 2026. — https://powerbiconsulting.com/blog/power-bi-sensitivity-labels-information-protection-2026

[19] Microsoft Learn. Export and sharing settings — Microsoft Fabric Admin Portal. — https://learn.microsoft.com/ru-ru/fabric/admin/service-admin-portal-export-sharing

[20] Sam Campitiello / Medium. Dynamic Data Masking and Row Level Security using Power BI Calculation Groups. — https://medium.com/@sam.campitiello/dynamic-data-masking-and-row-level-security-using-power-bi-calculation-groups-d844b5c8ccbe

[21] Роскомнадзор. В сфере обработки персональных данных: обзор нарушений, обезличивание ПДн. — https://70.rkn.gov.ru/directions/p1892/p5730/

[22] КиберЛенинка. Утечки конфиденциальных данных: главный враг внутри. — https://cyberleninka.ru/article/n/utechki-konfidentsialnyh-dannyh-glavnyy-vrag-vnutri