Всем привет! Меня зовут Светлана Анохина, я младший бизнес-партнёр по информационной безопасности в Ozon. Несмотря на небольшой стаж, опыт работы у меня довольно разносторонний, ведь моя роль предполагает участие практически во всех аспектах безопасности (если интересно, кто такие бизнес-партнёры по ИБ, то рекомендую почитать статьи моих коллег Даши или Максима на эту тему).

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

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

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

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

За время своей работы в e-commerce-компаниях я собрала некоторый перечень подходов и инструментов защиты, которые реализую в своём направлении. Сегодня я хочу рассказать о маскировании вам, моим коллегам, которые так же, как и я, стремятся сделать данные безопасными, а жизнь пользователей — спокойной.

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

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

Защита данных — это многослойный процесс, где каждая мера важна.

Начнём с базовых методов.

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

Следующий этап — мониторинг: кто заходит в базу, что делает, какие данные запрашивает. Логирование здесь — инструмент номер один. Оно позволяет не только выявлять подозрительные активности, но и разбираться в причинах возможных инцидентов. Кроме того, важным этапом является защита на сетевом уровне: настройка брандмауэров, использование VPN для защищённого подключения, ограничение IP-адресов, с которых можно получить доступ к системе. Всё это создаёт дополнительный барьер для злоумышленников.

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

И здесь на помощь приходит маскирование данных. Что это такое? По сути, это фильтр, который подменяет реальные данные на фиктивные или обезличенные. Например, разработчики или тестировщики видят подставные данные, которые выглядят как настоящие, но при этом не содержат никакой чувствительной информации.

Почему этот метод так эффективен?

Во-первых, даже если данные утекут, они будут бесполезны для злоумышленников. Во-вторых, это помогает компаниям соблюдать GDPR или ФЗ-152, которые требуют строгого ограничения и минимизации доступа к персональным данным. И, что немаловажно, процесс маскирования довольно просто внедрить, если подойти к нему правильно. Важно лишь, чтобы замаскированные данные могли использоваться для тестирования или анализа. В большинстве случаев этот метод применяется для защиты персональных данных и корпоративных секретов.

Существует множество алгоритмов маскирования, каждый из которых подходит для своих задач.

1.     Начнём с самого популярного — подмена значений. Здесь всё просто: берём реальные данные и заменяем их чем-то похожим. Например, вместо имени «Иван Иванов» подставляем «Алексей Смирнов». Формат сохраняется, данные выглядят правдоподобно, и для тестирования это идеальный вариант. Но здесь стоит учитывать, что при подмене есть вероятность случайно «попасть» в реальные данные другого человека и начать нелегитимно их обрабатывать. Можно минимизировать этот риск, используя вымышленные имена и фамилии, генерируя псевдонимы, частично модифицируя имена «Иван» -> «Ивак» или совмещая этот алгоритм с генерацией синтетических данных.

2.     Дальше идёт обфускация или, проще говоря, зашифровывание данных таким образом, чтобы они стали нечитаемыми. Например, ваш телефон «123-456-7890» превращается в «XXX-XXX-7890» или адрес электронной почты превращается в email@domen.ru. Отличный способ скрыть чувствительные данные, при этом структура остаётся понятной.

3.     Для простых случаев подойдёт редактирование данных — мы просто скрываем или удаляем часть информации. Например, вместо адреса «Москва, ул. Ленина, д. 10» показываем «Москва, ул. Ленина, д. ***». Быстро, просто, но эффективно.

4.     Есть ещё перестановка данных, или «перемешивание». Этот метод особенно полезен, если у вас большие наборы данных. Например, зарплаты сотрудников можно перемешать, чтобы никто не мог понять, какая из них кому принадлежит.

5.     Отдельно стоит упомянуть генерацию фейковых данных. Здесь вообще всё заменяется синтетическими значениями. Это идеальный вариант, если вам нужно создать абсолютно безопасный тестовый набор данных. Например, генерируем вымышленные адреса, телефоны и всё остальное. Ещё один значимый плюс этого способа: можно генерировать значения с помощью детерминированных алгоритмов. То есть если один и тот же алгоритм используется в разных системах с одним и тем же ключом или правилами, то результат преобразований будет одинаковым. Благодаря этому исходные данные будут всегда иметь идентичные значения, что позволяет идентифицировать совпадения в разных системах, не раскрывая реальные данные.

6.     А вот токенизация — это уже уровень посложнее. Мы заменяем реальные данные токенами, то есть уникальными идентификаторами, а связь с исходной информацией хранится отдельно. Это особенно полезно для работы с кредитными картами и другой финансовой информацией. Например, вместо номера карты «1234-5678-9012-3456» видим что-то вроде «ABC123DEF456».

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

Как же выбрать алгоритм?
Всё зависит от задачи.

Если нужно сохранить формат — выбирайте подмену или генерацию фейковых данных. Для высоких требований безопасности — токенизацию или обфускацию. А для аналитики подойдёт дифференциальная приватность. Всё это — инструменты, которые можно и нужно комбинировать. Нет единственного «идеального» алгоритма, но правильно подобранное маскирование позволяет защищать данные без ущерба для их использования.

С алгоритмами стало более-менее понятно. Но как именно внедрить маскирование правильно и безболезненно для бизнес-процессов компании?

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

Давайте поговорим о статическом маскировании данных.

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

Итак, что это такое?

Статическое маскирование (SDM) — это процесс, при котором мы берём реальные данные, модифицируем их (заменяем, обфусцируем или редактируем) и сохраняем в этой изменённой форме в новой базе. То есть у нас получается отдельная копия данных, которая выглядит как настоящая, но на самом деле не содержит ничего чувствительного.

Какие у этого метода преимущества?

1. Безопасность на уровне среды: когда данные уже замаскированы, даже если кто-то получит доступ к копии базы, ничего критичного он из неё не извлечёт.

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

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

Как это реализовать?

В большинстве СУБД, таких как Oracle, SQL Server или PostgreSQL, есть инструменты для статического маскирования:

• в Oracle это можно сделать с помощью Data Masking Pack;

• в SQL Server есть специальные функции для генерации псевдонимов и обработки данных;

• в PostgreSQL можно использовать сторонние инструменты вроде pgmask или писать свои скрипты.

Главный нюанс здесь — нужно понимать, какие данные маскировать. Например, если это паспортные данные или номера карт, то важно, чтобы они выглядели реалистично. Иначе тестовые системы могут просто не принять их.

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

Что же такое динамическое маскирование данных?

Динамическое маскирование (DDM) — это процесс, при котором данные остаются в своей оригинальной форме в базе, но при обращении к ним система автоматически подменяет или скрывает определённые значения в зависимости от настроек доступа. То есть пользователь, который запрашивает данные, видит только маскированную версию, в то время как сами данные остаются нетронутыми.

Как это работает на практике?

Допустим, у вас есть база клиентов интернет-магазина.

Специалист службы поддержки видит только часть данных: например, вместо полного ФИО отображается «Иванов К.».

А вот администратор системы, обладающий соответствующими правами, видит эти данные полностью.

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

Пример реализации

В SQL Server динамическое маскирование данных уже встроено. Вы можете настроить маскирование на уровне базы, используя специальные политики. Например:

CREATE TABLE Customers (
    CustomerID INT PRIMARY KEY,
    FullName NVARCHAR(50) MASKED WITH (FUNCTION = 'default()'),
    CreditCardNumber NVARCHAR(20) MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)')
);

В этом случае пользователи без особых прав доступа будут видеть замаскированное имя и часть номера карты.

В PostgreSQL и MySQL динамическое маскирование можно реализовать с помощью триггеров, представлений или расширений. Например, вы можете создать представление, которое возвращает маскированные данные в зависимости от пользователя:

CREATE VIEW Masked_Customers AS
SELECT
    CustomerID,  
    CASE WHEN current_user = 'admin' THEN FullName ELSE '***' END AS FullName
FROM Customers;

Когда это особенно полезно?

1. Если у вас много пользователей с разными уровнями доступа к базе — что очень актуально для больших компаний с огромным количеством сервисов и бизнес-процессов.

2. Когда важна защита данных в реальном времени, например, в CRM-системах.

3. Если нужно минимизировать риски утечки данных через UI систем.

Если вдруг вам всё ещё не до конца понятно, как это работает, и остались вопросы, предлагаю рассмотреть следующий сценарий применения динамического маскирования в компании.

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

Реализация

1. Создание политики маскирования

Настраиваем маскирование для столбцов, содержащих данные:

CREATE TABLE Clients (
    ClientID INT IDENTITY PRIMARY KEY,
    FullName NVARCHAR(50),
    Email NVARCHAR(50) MASKED WITH (FUNCTION = 'email()'),
    Phone NVARCHAR(15) MASKED WITH (FUNCTION = 'custom('XXX-XXX-XXXX')'),
    CreditCard NVARCHAR(16) MASKED WITH (FUNCTION = 'default()')
);

2. Управление правами доступа

Менеджеры получают доступ к маскированным данным:

CREATE USER SalesManager FOR LOGIN SalesLogin;
DENY UNMASK TO SalesManager;

Аналитики и администраторы имеют полный доступ:

CREATE USER Analyst FOR LOGIN AnalystLogin;
GRANT UNMASK TO Analyst;

3. Пример запросов:

Запрос от имени менеджера:

SELECT Email, Phone, CreditCard FROM Clients;

Результат:

Запрос от имени администратора:

SELECT Email, Phone, CreditCard FROM Clients;

Результат:

Вот так это работает в Microsoft SQL Server, где настройки довольно интуитивны и встроены в базовый функционал.

Oracle

Теперь давайте посмотрим, как DDM реализуется в Oracle.

Oracle предлагает ещё больше гибкости, позволяя настраивать политики маскирования через мощный пакет DBMS_REDACT. Эта технология позволяет не только подменять данные «на лету», но и задавать сложные условия, при которых маскирование будет применяться. Перейдём к конкретному примеру, чтобы увидеть, как это работает.

1. Создаём таблицу Clients, где храним персональные данные клиентов:

CREATE TABLE Clients (
    ClientID NUMBER PRIMARY KEY,
    FullName VARCHAR2(50),
    Phone VARCHAR2(15),
    Email VARCHAR2(50),
    CreditCard VARCHAR(16)
);
INSERT INTO Clients (ClientID, FullName, Phone, Email, CreditCard)
VALUES (1, 'Johny Jo', '555-123-4567', 'johny.jo@example.com',1234567890987654);

INSERT INTO Clients (ClientID, FullName, Phone, Email, CreditCard)
VALUES (2, 'Jenny Je, '555-987-6543', 'jenny.je@example.com', 0987654321234567);

2. Настраиваем политики динамического маскирования

Используем пакет DBMS_REDACT, чтобы замаскировать контактные данные (номер телефона, email) и финансовую информацию.

Маскирование номера телефона: показываем только последние 4 цифры.

BEGIN
    DBMS_REDACT.ADD_POLICY(
        object_schema  => 'Customer',
        object_name    => 'Clients',
        column_name    => 'Phone',
        policy_name    => 'MASK_Phone',
        function_type  => DBMS_REDACT.PARTIAL,
        function_parameters => '0, ''*-*-'', 4',
        expression     => '1=1'
    );
END;

Маскирование email: скрываем часть адреса, оставляя первую букву и домен.

BEGIN
    DBMS_REDACT.ADD_POLICY(
        object_schema  => 'Customer',
        object_name    => 'Clients',
        column_name    => 'Phone',
        policy_name    => 'MASK_Phone',
        function_type  => DBMS_REDACT.PARTIAL,
        function_parameters => '0, ''*-*-'', 4',
        expression     => '1=1'
    );
END;

Маскирование номера карты: показываем нулевые значения вместо реального баланса.

BEGIN
    DBMS_REDACT.ADD_POLICY(
        object_schema  => 'Customer',
        object_name    => 'Clients',
        column_name    => 'CreditCard',
        policy_name    => 'MASK_CreditCard',
        function_type  => DBMS_REDACT.FULL,
        expression     => '1=1'
    );
END;
---

3. Проверка политики

Запрос от сотрудника отдела маркетинга (без привилегий):

SELECT FullName, Phone, Email, CreditCard FROM Clients;

Результат:

Запрос от аналитика или администратора (с привилегиями): аналитики и администраторы видят данные без маскирования. Для этого им предоставляется привилегия EXEMPT REDACTION POLICY:

GRANT EXEMPT REDACTION POLICY TO analyst_user;

Результат:

4. Удаление политики (при необходимости)

Если потребуется удалить политику маскирования:

BEGIN

    DBMS_REDACT.DROP_POLICY(

        object_schema  => 'Customer',

        object_name    => 'Clients',

        policy_name    => 'MASK_Phone'

    );

    DBMS_REDACT.DROP_POLICY(

        object_schema  => 'Customer',

        object_name    => 'Clients',

        policy_name    => 'MASK_Email'

    );

    DBMS_REDACT.DROP_POLICY(

        object_schema  => 'Customer',

        object_name    => 'Clients',

        policy_name    => 'MASK_CreditCard'

    );

END;

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

Почему DDM — это круто?

1. Простота реализации. Экономия времени и ресурсов. Это, пожалуй, самый сильный аргумент. Вам не нужно переписывать код приложения, добавлять сложные процедуры или создавать отдельные базы. За счёт того, что маскирование можно внедрять в уже готовые решения, оно помогает очень легко скрыть критичные данные, не переделывая ролевую модель и не ломая бизнес-процессы.

2. Гибкость. Представьте, что один и тот же набор данных видят разные пользователи по-разному. Например, аналитик видит только обрезанные номера карт, а администратор с доступом — всё, что нужно. Это реально удобно, когда в системе много ролей.

3. Снижение риска утечек реальных данных через UI. Даже если произойдёт что-то неприятное, например, SQL-инъекция, злоумышленник получит только замаскированные данные. Да и при ошибках в конфигурации системы это тоже дополнительный уровень защиты.

4. Соответствие стандартам. DDM может закрыть сразу несколько пунктов в требованиях к безопасности, будь то ФЗ-152, GDPR или PCI DSS. Это не то чтобы панацея, но настроить — проще простого.

Звучит это всё слишком сказочно. В чем же подвох?

1. DDM не защищает от «своих» с доступом UNMASK. Если у кого-то есть права «видеть всё», то никакое маскирование уже не поможет. Поэтому таких людей должно быть минимум, и каждый должен знать, зачем ему этот доступ.

2. Не заменяет шифрование. Тут нужно быть честными: DDM маскирует только на уровне визуализации. Данные в базе остаются в исходной форме, и, если кто-то получит прямой доступ к ней, он их увидит.

3. Не работает на резервных копиях. Если кто-то украл вашу бэкап-базу, маскирование на ней работать не будет. Это важно учитывать, особенно если у вас нет политики шифрования бэкапов.

Итого мы получаем следующее.

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

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

Кажется, что динамическое маскирование превосходит статическое по всем параметрам: гибкость, защита данных в реальном времени, минимальные затраты на поддержку. Но все же в ситуациях, когда необходимо обезличить чувствительные данные для всех пользователей (к примеру, на DEV/STG-средах), SDM безусловно выигрывает. Не стоит ограничиваться одним методом, следует адекватно оценить процессы и чувствительность данных и применять разные виды маскирования в зависимости от ваших потребностей.

Заключение

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

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

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