Конфиденциальность данных для облачной аналитики в Azure

Статья
10/10/2023

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

Схема классификации конфиденциальности данных

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

Перед приемом данных необходимо классифицировать данные как конфиденциальные или ниже или конфиденциальные (персональные данные).

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

Важно!

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

Конфиденциально или ниже

Для каждого подключенного продукта данных мы создадим две папки озера данных в обогащенных и курируемых слоях, конфиденциальных или конфиденциальных(персональных данных) и используйте списки управления доступом для включения сквозной проверки подлинности каталога Microsoft Azure (Идентификатор Microsoft Entra).

Если группа приложений данных подключена к конфиденциальному или приведенному ниже ресурсу данных, имена субъектов-пользователей и объекты субъекта-службы можно добавить в две группы Microsoft Entra (один для доступа для чтения и записи и другой для доступа только для чтения). Эти две группы Microsoft Entra должны быть созданы во время процесса подключения и отсортированы в соответствующей папке продукта данных с конфиденциальными или ниже контейнерами для необработанных и обогащенных данных.

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

Рекомендации по макету озера данных см. в статье "Подготовка трех Azure Data Lake Storage 2-го поколения учетных записей для каждой целевой зоны данных".

Примечание.

Примерами вычислительных продуктов являются пулы Azure Databricks, Azure Synapse Analytics, Apache Spark и Azure Synapse SQL по запросу с поддержкой сквозной проверки подлинности Microsoft Entra.

Конфиденциальные данные (персональные данные)

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

Пример сценария

В следующем примере описываются варианты защиты конфиденциальных (персональных) данных.

Приложение данных выполняет прием продукта данных о персонале (HR) для Северная Америка и Европы. В примере использования требуется, чтобы европейские пользователи видели только записи о персонале из Европы, а пользователи из Северной Америки — только записи о персонале из Северной Америки. Дополнительное ограничение состоит в том, что только менеджеры по персоналу могут видеть столбцы, содержащие данные о зарплате.

Вариант 1. Подсистема политик (рекомендуется)

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

Доступ к данным
Управление жизненным циклом данных.
Внутренние и внешние политики и нормативные правила.
Политики общего доступа к данным.
Идентификация конфиденциальных (персональных) данных
Аналитика безопасности и соответствия требованиям
Политики для отчетов по защите данных

Как правило, подсистема политик интегрируется в каталог данных, такой как Azure Purview. В Azure Marketplace представлены решения сторонних поставщиков, а некоторые поставщики работают с Azure Synapse и Azure Databricks, позволяя шифровать и расшифровывать информацию, а также обеспечивая безопасность на уровне строк и столбцов. Как и в январе 2022 года, Azure Purview запустил общедоступную предварительную версию политик доступа для управления доступом к данным, хранящимся в BLOB-объекте и Azure Data Lake служба хранилища (ADLS) 2-го поколения. См. статью Подготовка набора данных владельцем данных для службы хранилища Azure (предварительная версия).

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

Как уже упоминалось ранее, для использования подсистемы политик важно интегрировать ее в каталог данных и в DevOps, чтобы использовать REST API для подключения нового набора данных. Когда команды приложений данных создают источники данных для чтения, они будут зарегистрированы в каталоге данных и помогают определить конфиденциальные (персональные данные). Подсистема политики должна импортировать определение и запрещать доступ к данным до тех пор, пока команды не настроят политики доступа. Все это должно выполняться с помощью рабочего процесса REST API из решения по управлению ИТ-услугами.

Вариант 2. Конфиденциальные или указанные ниже версии (персональные данные)

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

Хотя это выполняет разделение конфиденциальных (персональных данных) и конфиденциальных или ниже, пользователь предоставил пользователю доступ через сквозную проверку подлинности Active Directory к конфиденциальным (личным данным) сможет запрашивать все строки. Если требуется безопасность на уровне строк, необходимо использовать параметр 1: подсистема политик (рекомендуется) или вариант 3: База данных SQL Azure, Управляемый экземпляр SQL или пулы SQL Azure Synapse Analytics.

Вариант 3. База данных SQL Azure, Управляемый экземпляр SQL или пулы SQL Azure Synapse Analytics

Приложение данных использует База данных SQL, Управляемый экземпляр SQL или пулы SQL Azure Synapse Analytics для загрузки продуктов данных в базу данных, которая поддерживает безопасность на уровне строк, безопасность на уровне столбцов и динамическое маскирование данных. Команды приложений данных создают разные группы Microsoft Entra и назначают разрешения, поддерживающие конфиденциальность данных.

В случае использования этого сценария командам приложений данных потребуется создать следующие четыре группы Microsoft Entra с доступом только для чтения:

Групповой	Разрешение
`DA-AMERICA-HRMANAGER-R`	Просмотр ресурса данных о персонале в Северной Америке с информацией о зарплате.
`DA-AMERICA-HRGENERAL-R`	Просмотр ресурса данных о персонале в Северной Америке без информации о зарплате.
`DA-EUROPE-HRMANAGER-R`	Просмотр ресурса данных о персонале в Европе с информацией о зарплате.
`DA-EUROPE-HRGENERAL-R`	Просмотр ресурса данных о персонале в Европе без информации о зарплате.

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

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

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

Таблицы можно сделать доступными для Azure Databricks с помощью соединителя Apache Spark для SQL Server и Базы данных SQL Azure.

Вариант 4. Azure Databricks

Четыре варианта — использовать Azure Databricks для изучения конфиденциальных (персональных данных)). Использование сочетания библиотек шифрования Fernet, определяемых пользователем функций (UDF), секретов Databricks, управления доступом к таблицам и функций динамических представлений позволяет шифровать и расшифровывать столбцы.

Описание из записи блога Принудительное шифрование на уровне столбцов и предотвращение дублирования данных:

Первым шагом в этом процессе является защита данных путем их шифрования во время приема и одним из возможных решений является библиотека Fernet на языке Python. Fernet использует симметричное шифрование, которое построено на основе нескольких стандартных криптографических примитивов. Эта библиотека используется в определяемой пользователем функции шифрования, которая позволяет шифровать любой заданный столбец в кадре данных. Для хранения ключа шифрования мы будем использовать секреты Databricks с элементами управления доступом, чтобы разрешить доступ к нему только процессу приема данных. После записи данных в таблицы Delta Lake неавторизованные пользователи не смогут считать столбцы персональных данных, содержащие такие значения, как номер социального страхования, номер телефона, номер кредитной карты и другие идентификаторы.

После того как конфиденциальные данные написаны и защищены, необходимо настроить для привилегированных пользователей способ чтения конфиденциальных данных. Первое, что необходимо сделать, — это создать постоянную определяемую пользователем функцию (UDF) для добавления ее в экземпляр Hive, выполняющийся в Databricks. Чтобы функция UDF была постоянной, она должна быть написана на Scala. К счастью, Fernet также имеет реализацию Scala, которую можно использовать для расшифровывающих операций чтения. Для расшифровки эта UDF также обращается к тому же секрету, который использовался в зашифровывающей операции записи, и в этом случае он добавляется в конфигурацию Spark кластера. Для этого необходимо добавить элементы управления доступом к кластеру для привилегированных и непривилегированных пользователей, чтобы контролировать их доступ к ключу. После создания UDF можно использовать ее в определениях представлений для привилегированных пользователей для просмотра расшифрованных данных.

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

В предыдущем примере мы бы создали две функции динамического представления: одна для Северной Америки и другая для Европы, и реализовали бы методы шифрования в этой записной книжке.

Представление для Северной Америки

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Представление для Европы

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

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

Предоставление DA-AMERICA-HRMANAGER-R доступа к представлению vhr_us и DA-AMERICA-HRGENERAL-R групп Microsoft Entra.
Предоставление DA-EUROPE-HRMANAGER-R доступа к представлению vhr_eu и DA-EUROPE-HRGENERAL-R групп Microsoft Entra.

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

Когда используется доступ к таблицам, команды, требующие доступа, добавляются в рабочую область Azure Databricks. Azure Databricks использует субъекты-службы для сопоставления Azure Data Lake Storage, но данные защищаются с помощью управления доступом к таблицам Azure Databricks.

При развертывании новых продуктов данных часть процесса DevOps потребуется запустить скрипты, чтобы настроить разрешения таблицы в рабочей области Azure Databricks и добавить правильные группы Microsoft Entra в эти разрешения.

Примечание.

Управление доступом к таблицам Azure Databricks невозможно объединить сквозную проверку подлинности Microsoft Entra. Поэтому вместо этого можно использовать только одну рабочую область Azure Databricks и управление доступом к таблицах.

Данные с ограниченным доступом

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

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

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

Следующие шаги

Управление доступом к данным

Share via