Работая с Big Data и Hadoop, в частности за последние тринадцать лет, я научился тому, что данные действительно являются важным активом любой организации, независимо от ее размера. Любое взаимодействие с внешними объектами (клиентами, устройствами IoT и т. Д.) Приводит к получению данных в необработанном виде, будь то поток данных по кликам, данные транзакций или несколько других типов данных. Во-первых, данные должны быть загружены вверх по течению, а затем каким-то образом подготовлены к тому, чтобы быть доступными для последующих читателей — разработчиков, аналитиков и исследователей данных, которые будут преобразовывать данные в бизнес-идеи, которые могут стимулировать инновации и рост.
Первую часть можно считать решенной проблемой, поскольку многие компании предоставляют решения для надежного переноса данных в озеро данных, будь то файловое или потоковое. Что не так просто, так это вторая часть — обеспечение доступа к данным безопасным и контролируемым образом для тех, кто в них нуждается.
Управление данными для облака
Управление данными — это термин, который относится к структуре процессов, применяемых ко всему жизненному циклу данных в организации. В общем, управление данными начинается, когда данные попадают в систему, и заканчивается, когда они удаляются, с широким диапазоном тем, включая очистку данных, их обработку, каталогизацию данных, обнаружение данных и безопасность данных — последняя из которых является основной задачей этой статьи.
Но попытка применить управление данными, концепцию, возникшую в эпоху хранилищ данных, к более поздним инициативам в области больших данных, таким как озеро данных, не всегда работает с соотношением 1: 1. Имея дело с «маленькими» данными, вы были в состоянии преобразовать данные в то, что было необходимо для определенной группы пользователей. Классический ETL (процесс интенсивного извлечения, преобразования и загрузки данных ввода / вывода) может быть неприменим к большим данным, поскольку только физика отменила этот трудоемкий этап подготовки.
Современные системы считывают данные непосредственно из файлов поэтапных данных после того, как они попадают в жизнеспособный формат озера данных, такой как паркет, и очищаются в процессе. С помощью своего собственного мантры движка озера данных у вас теперь есть полдюжины (или больше!) Нисходящих приложений и вычислительные среды, считывающие данные непосредственно из того места, где они находятся. Напишите один раз, прочитайте много — это идеальный вариант для сегодняшних неизменных, но гипермасштабируемых систем хранения файлов и объектов (то есть Apache HDFS, Amazon S3, Microsoft ADLS Gen1 & 2, Google GFS).
Вы также можете быть заинтересованы в: Маскировка данных на практике — часть 1
Стоимость гибкости
В чем же недостаток? Еще раз, это физика, которая в масштабе запрещает размещение данных много раз для каждого варианта использования. Организация с органически развитой системой разрешений найдет единственную причину комбинаторного вызова, чтобы не создавать файлы для каждой необходимой комбинации разрешений.
Скорее, динамический уровень доступа должен применять разрешение на лету, когда данные читаются аутентифицированным клиентом. И недостаточно просто принять решение «все или ничего» на основе уровня авторизации клиента. Если ваша гранулярность останавливается на файлах, то все, что вы можете применить — это разрешения на уровне файлов, такие как списки контроля доступа (ACL). На практике этого недостаточно, поскольку клиентам требуется доступ на более детальном уровне, включая разрешения на уровне строк и столбцов и даже на уровне ячеек.
Кроме того, предоставление доступа к определенному атрибуту отношения, опять же, является действием «все или ничего». В некоторых ситуациях этого может быть достаточно, например, скрыть столбец, содержащий номера кредитных карт, от группы маркетинга. С другой стороны, аналитик по продажам может захотеть сгруппировать продажи по поставщикам кредитных карт, которые кодируются в первые шесть цифр номера карты и остаются неизменными для всех владельцев конкретной карты и поставщика. Это всего лишь один из примеров информации, позволяющей установить личность (PII), которая имеет интересную ценность, но не должна предоставляться полностью всем, кто хочет проанализировать данные.
Обфускация данных
Это где маскировка данных вступает в игру, которая является задачей преобразования данных таким образом, чтобы их части были изменены в соответствии с политиками управления данными. Например, запутывание данных и анонимизация данных — это методы изменения содержимого чувствительных полей в соответствии с корпоративными правилами конфиденциальности.
Позвольте мне показать вам несколько примеров маскирования данных и в дальнейшем объяснить, где и как они имеют смысл на практике.
Маскировка данных
Самый простой способ запутать данные — это замаскировать или редактировать символы или цифры с фиксированным символом. Это часто используется для номеров кредитных карт, где начальная или конечная цифры перечеркнуты знаком «X». Например, использование маскирующей функции в SQL может выглядеть так:
SQL
xxxxxxxxxx
1
> SELECT mask("5000 4000 3000 1000");
2
XXXXXXXXXXXXXXX1000
Если вы хотите замаскировать переменную часть значения, вы можете использовать функцию mask (), которая также принимает параметры start и length.
SQL
xxxxxxxxxx
1
> SELECT mask("5000400030001000", 7, 13);
2
500040XXXXXXXXXX
Таким образом, вы можете сделать номера кредитных карт частично пригодными для использования пользователями для распознавания своего номера, представив им последние четыре цифры, или составить группу аналитиков по эмитенту карты, который закодирован в упомянутых первых шести цифрах.
Другим вариантом будет «обнулить» или удалить соответствующие детали значений столбцов. Например, оставьте поле STREETNAME доступным для чтения всем; для непривилегированных пользователей это будет установлено NULL для всех записей, в то время как привилегированный пользователь может видеть фактическое значение.
Анонимизация данных
Функции в этой группе изменят значение поля, чтобы оно больше не могло использоваться. Существуют варианты, которые полностью рандомизируют значение или используют исходное значение в качестве начального числа для рандомизации, что означает, что оно всегда будет давать одно и то же случайное значение для конкретного исходного. Это позволяет вам по-прежнему объединять наборы данных или объединять записи на основе общего значения.
SQL
x
1
> -- Execute function _with_ referential integrity twice
2
> SELECT tokenize("5000 4000 3000 1000");
3
5512 7744 8063 9850
4
> SELECT tokenize("5000 4000 3000 1000");
6
5512 7744 8063 9850
SQL
xxxxxxxxxx
1
> -- Execute function _without_ referential integrity twice
2
> SELECT tokenize_no_ref("5000 4000 3000 1000");
3
1013 2461 1514 1969
4
> SELECT tokenize_no_ref("5000 4000 3000 1000");
6
9415 6941 3181 2855
Обе функции сохраняют исходный формат значения, но преобразуют их по-разному; первый дает одинаковый результат для двух вызовов, а второй создает разные случайные значения.
Другой вариант - анонимизировать значение с помощью некриптографической хеш-функции, такой как хеш-функция Jenkins. Это преобразует значение любой длины в хеш фиксированного размера, который не является обратимым, но дает тот же результат для данного исходного значения.
SQL
xxxxxxxxxx
1
> SELECT hash("Jane Doe");
2
-4049133654905739000
Это отличается, например, от шифрования данных, в котором для кодирования значения используется симметричная схема или схема на основе открытого ключа, чтобы его могли декодировать только авторизованные клиенты с соответствующим ключом дешифрования.
Показанные функции являются лишь небольшим подмножеством того, что сервисы доступа обычно предлагают, но служат примером для функций с контекстом, который не превышает первоначальное значение самого столбца. Другими словами, эти функции не могут расширять область охвата столбцов, строк или даже таблиц. Они также дают только фиксированные или случайные значения, которые могут быть или не быть достаточными.
Дифференциальная конфиденциальность
Для более сложной анонимизации нам нужно взглянуть на функции, которые поддерживают нечто, называемое дифференциальной конфиденциальностью. Целью здесь является применение статистических методов для изменения содержимого в более широком масштабе, например на уровне таблицы.
Представьте, скажем, что вам нужно анализировать данные о клиентах, но требовать дня рождения, чтобы сгруппировать клиентов по демографическим показателям. Рандомизация этого фрагмента PII не является хорошей идеей, так как это изменило бы общий состав данных, часто делая его равномерно распределенным по возможному диапазону значений.
Вместо этого нам нужна функция, которая меняет каждый день рождения, поэтому общее распределение остается практически неизменным, но отдельные лица больше не могут быть идентифицированы. Это может означать добавление нескольких дней или нескольких недель к каждой дате, но это фактор общего числа наборов данных.
Механизмы запросов могут предлагать diff_privacy() функцию (или что-то с похожим именем) для этой цели, что позволяет вам вносить неопределенность или дрожание в ваши конфиденциальные данные, чтобы вышеуказанное требование могло быть выполнено. Например, рассмотрим следующий запрос, показывающий исходную и измененную версию значения столбца даты рождения:
SQL
x
1
> -- deviation of 10 days
2
> SELECT uid, dob AS actual_birthday, diff_privacy(dob, 60*60*24*10) as diffpriv_birthday;
Обратите внимание, как измененная дата изменяется в заданных пределах десяти дней. Создание когорт с этими датами даст результаты, очень похожие на результаты, полученные при использовании исходных дат. Это происходит потому, что функция не просто рандомизирует даты, но использует статистическую функцию для распределения изменений, поэтому общее значение остается неизменным.
Дифференциальная конфиденциальность является горячей темой, особенно в контексте недавних законов о конфиденциальности, таких как GDPR ЕС или CCPA в Калифорнии. Конфиденциальность по замыслу является одним из общих строительных блоков для этих правил, который включает в себя необходимость сделать деанонимизацию практически невозможной. Некоторые темы для дальнейших исследований, если вам интересно, включают Epsilon Differential Privacy или k-анонимность . Первый использует бюджетный эпсилон для внесения достаточной неопределенности в данные в целях конфиденциальности при максимально возможном сохранении удобства использования данных.
Даже статистические методы так же хороши, как и их разумное применение. Например, имея достаточный доступ к данным, опытный пользователь может объединить достаточно наборов данных, чтобы воссоздать исходный набор данных из множества измененных. Это может быть обнаружено только центральным слоем; активно ли оно является частью службы контроля доступа, применяемой во время выполнения, или ретроспективно как часть события аудита.
Динамическая безопасность озера данных
Мы обсудили концепцию маскирования данных, которая включает в себя запутывание, редактирование, токенизацию и шифрование значений и может происходить в контексте нескольких наборов данных, объединенных вместе. Но безопасность озера данных - это нечто большее, чем просто защита конфиденциальных значений данных, например фильтрация целого подмножества данных на основе данных пользователя для целей регулирования.
GDPR introduced the concept of “the right to be forgotten.” Subjects — individuals whose data is stored by third-party organizations — can opt-out of having their data used by the organization for business analytics. Within a few days of someone making the request, the business must comply and remove that person’s data, which poses enormous problems for data lakes at scale (back to physics again, which you cannot cheat).
Ideally, you only have to maintain a single copy of the data in full fidelity, accessible only by the data producers, with a data access layer that applies transformations across rows, columns, and even whole datasets dynamically, and only where necessary to avoid undue performance penalties. Only then you can untangle the messy permissions spaghetti presented by heterogeneous permission systems, each with their own idiosyncrasies and levels of granularity. One layer allows for the application of differential privacy across all data sources without risk of unintentional deanonymization (lack of knowledge about what data was joined).
On top of that, one access layer gives you a single audit log for all your access — no need to harmonize logs of different format and richness to answer immediate and pressing questions during the auditing process. One log equals a single source of truth.
TL;DR
For the restless reader, here are my key takeaways about using data obfuscation:
- Anonymization is a spectrum from useless but safe (i.e. randomize every value) to useful but possibly dangerous (i.e. expose PII data).
- Simple approaches that only consider column values in isolation, for example, masking out credit card numbers, are useful only to remove PII or other sensitive data (making data less useful or even useless).
- Statistical data obfuscation considering all rows in a dataset, like k-anonymization or localized differential privacy, is useful only in isolation since it may yield results that are susceptible to deanonymization attacks.
- For true data privacy, only a holistic approach across all users and datasets is able to guard against malicious adversaries.
The last takeaway is especially important and forces Chief Information Security Officers (CISO), CIO, CSO, and CDO to consider new solutions. In our modern world with heterogeneous infrastructure (that is, on- and off-premise) and polyglot persistence (that is, many different storage systems), there are many angles of attack for someone who is determined to get hold of sensitive data. The old adage of battening down the hatches translates in the realm of information technology to locking down data access — and that is the opposite of being data centric. Make access to data a first-class citizen of your IT strategy or forfeit progress that could be made through modern data analytics. Your call 🙂