Конфиденциальность данных для облачной аналитики в Azure
Аналитика в масштабе облака помогает определить оптимальные шаблоны доступа к данным, которые соответствуют вашим требованиям при защите персональных данных на нескольких уровнях. Персональные данные включают любые сведения, которые могут однозначно идентифицировать отдельных лиц, например номера лицензий водителя, номера социального страхования, банковские сведения о счете, номера паспорта и адреса электронной почты. Многие правила существуют для защиты конфиденциальности пользователей.
Чтобы защитить конфиденциальность данных в облачной среде, например Azure, можно создать схему конфиденциальности данных, которая задает политики доступа к данным. Эти политики могут определить базовую архитектуру, в которой находится приложение данных, определить способ авторизации доступа к данным и указать, к каким строкам или столбцам пользователи могут получить доступ.
Создание схемы классификации конфиденциальности данных
| Классификация | Description |
|---|---|
| Общедоступный | Любой пользователь может получить доступ к данным, и его можно отправить любому пользователю. Например, откройте данные для государственных организаций. |
| Только для внутреннего применения | Доступ к данным может получить только сотрудники, и его нельзя отправлять за пределы компании. |
| Конфиденциальная | Данные можно совместно использовать только в том случае, если это необходимо для конкретной задачи. Данные не могут быть отправлены за пределы компании без соглашения о неразглашении. |
| Конфиденциальные (персональные) данные | Данные содержат частную информацию, которая должна быть маскирована и предоставлена только на основе ограниченного времени. Данные не могут быть отправлены несанкционированным сотрудникам или за пределами компании. |
| С ограниченным доступом | Эти данные могут предоставляться только именованным лицам, которые отвечают за защиту. Например, юридические документы или торговые секреты. |
Перед приемом данных необходимо классифицировать их как конфиденциальные, либо ниже, либо чувствительные персональные данные:
- Сортируйте данные в конфиденциальные или ниже, если вам не нужно ограничивать, какие столбцы и строки пользователи могут просматривать.
- Сортируйте данные в конфиденциальные персональные данные, если необходимо ограничить, какие столбцы и строки пользователи могут просматривать.
Внимание
Набор данных может измениться с конфиденциальной или ниже на конфиденциальные персональные данные при объединении данных с другими продуктами данных, которые ранее имели более низкую классификацию. Если вам нужны постоянные данные, переместите его в указанную папку, которая соответствует уровню конфиденциальности и процессу подключения.
Создание набора политик Azure
После классификации данных следует выровнять классификацию с требованиями политики отрасли и внутренними политиками компании. Вы хотите создать набор политик Azure, который управляет развертыванием инфраструктуры, расположением, где его можно развернуть, а также стандартами сетевого и шифрования.
Для регулируемых отраслей можно использовать инициативы политики соответствия нормативным требованиям Майкрософт в качестве базового плана для платформ соответствия требованиям.
Классификация данных соответствует тем же правилам шифрования, разрешенным номерам SKU инфраструктуры и инициативам политики. Таким образом, вы можете хранить все данные в одной посадочной зоне.
Для ограниченных данных следует размещать данные в выделенной целевой зоне данных в группе управления, где можно определить более высокий набор требований к инфраструктуре. Например, можно определить управляемые клиентом ключи для шифрования или ограничения на входящий или исходящий доступ для целевой зоны.
Примечание.
Чувствительные персональные данные и данные конфиденциального и более низкого уровня можно поместить в одной зоне данных на разные учетные записи хранения. Но эта практика может усложнить решение на сетевом уровне, например с группами безопасности сети.
Развернутое решение по управлению данными должно ограничить поиск ограниченных данных в каталоге. Рассмотрите возможность реализации условного доступа Идентификатора Microsoft Entra для всех ресурсов данных и служб. Чтобы повысить безопасность, используйте доступ по требованию к ограниченным данным.
Рассмотрите требования к шифрованию
Помимо определения политик для расположений и разрешенных служб Azure, рассмотрите требования к шифрованию для каждой классификации данных. Рассмотрим требования для следующих областей:
- Управление ключами
- Хранилище ключей
- Шифрование неактивных данных
- Шифрование данных в транзитном режиме
- Шифрование активно используемых данных
Для управления ключами можно использовать ключи шифрования, управляемые платформой или управляемыми клиентом. Дополнительные сведения см. в статье Обзор управления ключами в Azure и Выбор подходящего решения для управления ключами.
Для получения дополнительных сведений о параметрах шифрования см. Шифрование данных Azure на уровне покоя и модели шифрования данных.
Протокол Транспортного уровня Безопасности ( TLS) можно использовать для защиты данных, перемещающихся между облачными службами и клиентами. Дополнительные сведения см. в разделе "Шифрование данных во время передачи".
Если в вашем сценарии требуется, чтобы данные были зашифрованы во время использования, модель угроз конфиденциальных вычислений Azure помогает свести к минимуму доверие. Это сводит к минимуму вероятность того, что операторы поставщика облачных служб или другие субъекты в домене клиента могут получить доступ к коду и данным во время реализации.
Дополнительные сведения см. в продуктах конфиденциальных вычислений Azure.
Реализация управления данными
После определения политик для развертывания разрешенных служб Azure определите, как предоставить доступ к продукту данных.
Если у вас есть решение для управления данными, например Microsoft Purview или каталог Azure Databricks Unity, можно создать ресурсы данных или продукты для обогащенных и курируемых слоев озера данных. Убедитесь, что в каталоге данных заданы разрешения для защиты этих объектов данных.
Используйте Microsoft Purview для централизованного управления, защиты и управления следующими областями:
- Доступ к данным
- Жизненный цикл данных
- Внутренние и внешние политики и нормативные правила.
- Политики общего доступа к данным.
- Определение конфиденциальных данных
- Аналитика безопасности и соответствия требованиям
- Политики для отчетов по защите данных
Дополнительные сведения об использовании Microsoft Purview для управления доступом для чтения или изменения см. в статье Основные понятия для политик владельца данных Microsoft Purview.
Независимо от того, решите ли вы реализовать Microsoft Purview или другое решение по управлению данными, используйте группы идентификаторов Microsoft Entra для применения политик к продуктам данных.
Используйте REST API решения для управления данными, чтобы подключить новый набор данных. Команды приложений данных создают продукты данных и регистрируют их в решении для управления данными, чтобы помочь определить конфиденциальные данные. Решение по управлению данными импортирует определение и запрещает доступ ко всем данным, пока ваши команды не настроили свои политики доступа.
Использование шаблонов защиты данных
Чтобы защитить конфиденциальные данные, выберите шаблон защиты данных на основе данных, служб и политик, которые вы реализуете.
Несколько копий
Конвейер обработки данных для каждого продукта с классификацией чувствительными персональными данными создает две копии. Конвейер классифицирует первый объект как конфиденциальный или ниже уровня конфиденциальности. Эта копия не включает столбцы конфиденциальных персональных данных. Он создается в папке уровня "конфиденциально или ниже" для данного продукта данных. Другая копия создается в папке конфиденциальных персональных данных. Эта копия включает конфиденциальные данные. Каждая папка назначается средству чтения идентификаторов Microsoft Entra и группе безопасности записи идентификаторов Майкрософт.
При использовании Microsoft Purview можно зарегистрировать обе версии продукта данных и использовать политики для защиты данных.
Шаблон множественных копий отделяет чувствительные персональные данные от данных уровня "конфиденциально" и ниже. Но если вы предоставляете пользователю доступ к конфиденциальным персональным данным, они могут запрашивать все строки. Вашей организации может потребоваться рассмотреть другие решения, обеспечивающие безопасность на уровне строк для фильтрации строк.
Безопасность на уровне строк и на уровне столбцов
Если вам нужно фильтровать строки, которые пользователи могут просматривать, вы можете переместить данные в вычислительное решение, использующее безопасность на уровне строк.
Чтобы предотвратить повторную разработку, выберите соответствующую службу Azure или решение Microsoft Fabric для конкретного варианта использования. Различные типы баз данных предназначены для различных целей. Например, для расширенной аналитики не следует использовать базу данных обработки транзакций (OLTP). И если вы используете приложение электронной коммерции, вам не следует использовать решение, которое предназначено для аналитики больших данных, так как оно не может достичь требуемого времени отклика миллисекунда.
Если вы реализуете решения, поддерживающие безопасность на уровне строк, группы приложений данных должны создавать разные группы идентификаторов Microsoft Entra и назначать разрешения на основе конфиденциальности данных.
Помимо безопасности на уровне строк, можно ограничить доступ к определенным столбцам. В следующей таблице показан пример четырех групп идентификаторов Microsoft Entra, имеющих доступ только для чтения:
| Группа | Разрешение |
|---|---|
DA-AMERICA-HRMANAGER-R |
Просмотр ресурса данных о персонале в Северной Америке с информацией о зарплате. |
DA-AMERICA-HRGENERAL-R |
Просмотр ресурса данных о персонале в Северной Америке без информации о зарплате. |
DA-EUROPE-HRMANAGER-R |
Просмотр ресурса данных о персонале в Европе с информацией о зарплате. |
DA-EUROPE-HRGENERAL-R |
Просмотр ресурса данных о персонале в Европе без информации о зарплате. |
Первый уровень ограничений поддерживает динамическое маскирование данных, которое скрывает конфиденциальные данные от пользователей, у которых нет привилегий. С помощью REST API можно интегрировать этот подход в подключение набора данных.
Второй уровень ограничений добавляет защиту на уровне столбца, чтобы ограничить доступ к просмотру зарплат для менеджеров, не относящихся к отделу кадров. Он также добавляет безопасность на уровне строк, чтобы ограничить, какие строки могут просматривать европейские и североамериканские члены команды.
Шифрование столбцов
Динамическое маскирование данных маскирует данные в точке представления, но в некоторых случаях использования требуется, чтобы решение никогда не имело доступа к незашифрованным данным.
Функция SQL Always Encrypted повышает безопасность конфиденциальных данных в базах данных SQL Server. SQL Always Encrypted помогает обеспечить безопасность конфиденциальных данных в базах данных SQL Server и защиту от несанкционированного доступа. Эта функция шифрует данные в состоянии покоя и в процессе передачи, что помогает обеспечить максимальную конфиденциальность данных и соответствие нормативным требованиям. SQL Always Encrypted выполняет операции шифрования и расшифровки на стороне клиента. Интегрируйте эту функцию, чтобы защитить наиболее ценные ресурсы данных.