Сравнение инструментов динамического маскирования данных: какой выбрать?

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

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

В этой статье сравниваются инструменты динамического маскирования данных в базах и средства ограничения видимости информации в браузере. MoreLogin и Island работают с содержимым бизнес-сайтов. SQL Server, Snowflake и DataSunrise управляют значениями, которые возвращаются при обращении к базе данных.

Краткое сравнение инструментов динамического маскирования данных

Где именно сотрудники видят конфиденциальную информацию?

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

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

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

Место хранения данных определяет доступные способы контроля. Обязанности сотрудников определяют, как эти способы применять.

Пять инструментов для разных задач доступа

1. MoreLogin: разные права при работе с общими бизнес-аккаунтами

MoreLogin подходит командам, которые работают в кабинетах магазинов, аккаунтах клиентов и других бизнес-сервисах. Ограничения назначаются выбранным участникам и профилям браузера. Поэтому правила для сотрудника поддержки могут отличаться от правил финансового отдела.

Например, поддержке нужны страницы заказов и сообщений, но не отчёты о выплатах. Финансовый отдел может сохранить доступ к этим отчётам без доступа к управлению товарами.

Для таких задач в MoreLogin предусмотрено несколько настроек:

• Скрытие элементов убирает выбранное содержимое из видимой части страницы, например номер телефона, адрес электронной почты или сведения об аккаунте.

• Блокировка URL запрещает открывать указанные страницы. Остальные остаются доступными.

• Список разрешённых URL позволяет открывать только перечисленные адреса и блокирует все остальные.

• Выбор участников и профилей определяет, на каких сотрудников и рабочие среды распространяются правила.

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

Два режима работы с URL решают разные задачи. Список блокировки может закрыть страницы выплат и администрирования, сохранив доступ к другим разделам магазина. Список разрешённых адресов ограничивает работу конкретным набором страниц. В него нужно включить необходимые страницы входа и адреса, через которые проходят перенаправления.

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

2. Island: частичное маскирование в рабочих веб-приложениях

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

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

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

Маскирование выполнялось локально в браузере. Перерабатывать платёжное приложение компании не пришлось.

Такой подход полезен, когда сотруднику нужен узнаваемый фрагмент значения. Например, последние цифры карты помогают специалисту по возвратам различить две операции. Если скрыть поле целиком, этот ориентир исчезнет.

Island решает эту задачу средствами корпоративного браузера. Стоимость соответствующего внедрения рассчитывается по запросу.

3. SQL Server DDM: маскирование значений в результатах запросов

Динамическое маскирование данных в SQL Server меняет возвращаемые значения столбцов, сохраняя исходные данные в базе.

Функция маскирования электронной почты оставляет первую букву и подставляет фиксированное окончание, например aXXX@XXXX.com. Функция частичного маскирования строк позволяет сохранить выбранные символы, например последние цифры идентификатора. Маски настраиваются для столбцов базы данных.

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

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

Поэтому SQL Server DDM позволяет ограничить раскрытие данных при повседневной работе с записями. Права чтения, изменения и просмотра исходных значений при этом настраиваются отдельно.

4. Snowflake: общие политики маскирования для аналитических данных

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

Например, аналитическая команда интернет-магазина изучает покупки в нескольких магазинах. Аналитикам нужны даты операций, товары и выручка. Их роль может получать замаскированные идентификаторы покупателей, а уполномоченная роль сохранять доступ к исходным значениям.

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

Изменение политики обновляет её поведение без повторного назначения каждому защищённому столбцу.

Для динамического маскирования требуется Enterprise Edition или более высокая редакция. Настройкой занимается команда, которая отвечает за таблицы, роли и политики доступа в Snowflake.

5. DataSunrise: отдельный уровень контроля подключений к базам данных

DataSunrise поддерживает маскирование при работе с PostgreSQL, MySQL, SQL Server, Snowflake и другими системами. При использовании прокси запросы проходят через отдельный уровень контроля. Он применяет правила маскирования до передачи результатов пользователю или приложению.

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

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

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

В DataSunrise маскирование и блокировка операций разделены. Изменение возвращаемого значения относится к маскированию. За запрет операции отвечает межсетевой экран для баз данных.

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

Какая информация нужна разным сотрудникам одного магазина

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

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

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

В MoreLogin настройку можно выполнить в такой последовательности:

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

2. Укажите участника или роль. Назначьте шаблон сотрудникам, которые отвечают за эту работу.

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

4. Выберите элементы для скрытия. Настройте содержимое страниц отдельно от правил доступа по URL.

5. Перезапустите нужный профиль. После изменения правил URL или скрытия элементов перезапуск нужен для проверки результата.

6. Выполните задачу под учётной записью сотрудника. Пройдите обычный путь поиска заказа, работы с сообщениями или просмотра отчёта.

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

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

Чем различаются расходы

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

Более крупные агентства выбирают тариф MoreLogin с учётом нужного количества профилей, участников и периода оплаты.

Island рассчитывает стоимость корпоративного внедрения по запросу.

У Snowflake есть конкретное требование к редакции. Для динамического маскирования нужна Enterprise Edition или выше, помимо обычных расходов на использование платформы. SQL Server DDM настраивается внутри базы, поэтому его использование связано с затратами на саму систему SQL Server.

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

Какой инструмент выбрать?

Для интернет-магазинов и агентств выбор обычно сводится к одной из четырёх ситуаций:

• Сотрудникам нужны разные страницы и разное содержимое в общих бизнес-аккаунтах. MoreLogin объединяет назначение участников и профилей, скрытие элементов и правила URL.

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

• Команда работает непосредственно с данными в SQL Server или Snowflake. Встроенное маскирование применяется к записям и столбцам, которые уже находятся в этих системах.

• Для нескольких поддерживаемых подключений к базам нужен общий уровень маскирования. DataSunrise предоставляет отдельную точку применения правил для таких подключений.

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

Часто задаваемые вопросы

1. Какие инструменты работают без доступа к базе данных платформы?

   MoreLogin и Island работают в браузере и ограничивают отображение информации в управляемой рабочей среде. SQL Server, Snowflake и DataSunrise требуют контроля над соответствующей системой данных или подключениями к ней.

2. Можно ли оставить часть значения видимой?

   Некоторые инструменты поддерживают частичное маскирование. В примере Island остаются видимыми последние четыре цифры карты. У SQL Server есть функция частичного маскирования строк, а политики Snowflake могут возвращать частично скрытые значения. MoreLogin скрывает выбранные элементы страницы.

3. Запрещает ли скрытие информации редактировать или скачивать данные?

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

4. Нужны ли такие ограничения компании с одним аккаунтом магазина?

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

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