Конфиденциальность данных для облачной аналитики в Azure
Аналитика в масштабе облака позволяет организациям определять оптимальные шаблоны доступа к данным в соответствии с их требованиями при защите персональных данных на нескольких уровнях. Персональные данные включают любые сведения, которые могут однозначно идентифицировать отдельных лиц, например номера лицензий водителя, номера социального страхования, банковские данные, номера паспорта, адреса электронной почты и многое другое. Сегодня существует множество нормативных требований по защите конфиденциальности данных пользователей.
Чтобы защитить конфиденциальность данных с помощью облачной среды, например Azure, можно начать с создания схемы конфиденциальности данных, указывающей политики доступа к данным. Эти политики могут определить базовую архитектуру, в которой находится приложение данных, определить, как авторизован доступ к данным, и указать, какие строки или столбцы можно получить после предоставления.
Создание схемы классификации конфиденциальности данных
| Классификация | Description |
|---|---|
| Общедоступный | Любой пользователь может получить доступ к данным, и его можно отправить любому пользователю. Например, откройте данные для государственных организаций. |
| Только для внутреннего применения | Доступ к данным может получить только сотрудники, и его нельзя отправлять за пределы компании. |
| Конфиденциальная | Данные можно совместно использовать только в том случае, если это необходимо для конкретной задачи. Данные не могут быть отправлены за пределы компании без соглашения о неразглашении. |
| Конфиденциальные (персональные) данные | Данные содержат частную информацию, которая должна быть маскирована и предоставлена только на основе ограниченного времени. Данные не могут быть отправлены несанкционированным сотрудникам или за пределами компании. |
| С ограниченным доступом | Эти данные могут предоставляться только именованным лицам, которые отвечают за защиту. Например, юридические документы или торговые секреты. |
Перед приемом данных необходимо классифицировать данные как конфиденциальные или конфиденциальные (персональные данные):
- Данные можно сортировать по конфиденциальным или ниже , если для разных пользователей отсутствуют ограничения, для которых отображаются столбцы и строки.
- Данные можно сортировать по конфиденциальным (личным данным), если существуют ограничения, для которых столбцы и строки видны разным пользователям.
Внимание
Набор данных может измениться с конфиденциальных или ниже на конфиденциальные (персональные данные), если данные объединяются с другими продуктами данных, которые ранее имели более низкую классификацию. Если данные должны быть постоянными, его следует переместить в указанную папку, которая соответствует уровню конфиденциальности и процессу подключения.
Создание набора политик Azure
После сопоставления классификации данных следует выровнять классификацию с требованиями локальной политики отрасли и внутренними политиками компании. На этом шаге вы можете создать набор политик Azure, который управляет развертыванием инфраструктуры, расположением, где его можно развернуть, и определяет стандарты сети и шифрования.
Для регулируемых отраслей корпорация Майкрософт разработала множество инициатив политики соответствия нормативным требованиям, которые служат основой для платформ соответствия требованиям.
Для классификации данных, которая соответствует тем же правилам шифрования и разрешенным номерам SKU инфраструктуры, а также инициативам политики данные могут находиться в одной целевой зоне.
Для ограниченных данных рекомендуется размещать данные в выделенной целевой зоне данных в группе управления, где можно определить более высокий набор требований для инфраструктуры, например управляемых клиентом ключей для шифрования, и ограничений для входящего или исходящего трафика, применяемых к целевой зоне.
Примечание.
В этом руководстве оценивается размещение конфиденциальных (персональных данных) и конфиденциальных или ниже данных в одной целевой зоне данных, но разные учетные записи хранения. Однако это может сделать решение сложным на сетевом уровне, например с группами безопасности сети.
Любое развернутые решение по управлению данными должно ограничить поиск ограниченных данных в каталоге.
Кроме того, следует рассмотреть возможность реализации условного доступа Идентификатора Microsoft Entra для всех ресурсов данных и служб, а также JIT-доступа для ограниченных данных для повышения безопасности.
Шифрование
Помимо определения политик расположения и разрешенных служб Azure следует учитывать требования к шифрованию для каждой классификации данных.
- Каковы ваши требования к управлению ключами?
- Каковы ваши требования к хранению этих ключей?
- Каковы ваши требования для классификации неактивных данных?
- Каковы ваши требования для классификации данных при передаче шифрования?
- Каковы ваши требования для классификации данных, используемых для шифрования?
Для управления ключами ключи можно управлять платформой или управлять клиентом. Корпорация Майкрософт задокументировано управление ключами в Azure, чтобы помочь вам выбрать решение по управлению ключами. Дополнительные сведения см. в разделе "Обзор управления ключами" в Azure и выбор подходящего решения для управления ключами.
Опубликованная корпорацией Майкрософт документация, объясняющая неактивное шифрование данных Azure и модели шифрования данных, которые помогут вам понять доступные параметры шифрования.
Корпорация Майкрософт предоставляет клиентам возможность использовать протокол TLS для защиты данных при перемещении между облачными службами и клиентами. Дополнительные сведения см. в разделе "Шифрование данных во время передачи".
Если в сценарии требуется, чтобы данные оставались зашифрованными, модель угроз конфиденциальных вычислений Azure направлена на минимизацию доверия или удаление возможности оператора поставщика облачных служб или других субъектов в домене клиента, обращающийся к коду и данным во время выполнения.
Последние предложения конфиденциальных вычислений 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.
Второй уровень ограничений заключается в добавлении безопасности на уровне столбцов, чтобы ограничить не hr-менеджеров от просмотра заработной платы и безопасности на уровне строк, чтобы ограничить строки европейских и Северная Америка n участников команды.
Шифрование столбцов
Хотя динамическое маскирование данных маскирует данные в точке представления, некоторые варианты использования требуют, чтобы решение никогда не было доступа к данным обычного текста.
SQL Always Encrypted — это мощная функция, представленная корпорацией Майкрософт, которая повышает безопасность конфиденциальных данных, хранящихся в базах данных SQL Server. SQL Always Encrypted гарантирует, что конфиденциальные данные, хранящиеся в базах данных SQL Server, остаются безопасными и защищены от несанкционированного доступа. Эта функция помогает обеспечить максимальную конфиденциальность данных и соответствие нормативным требованиям, зашифровав данные как неактивных, так и передаваемых данных.
Выполняя операции шифрования и расшифровки на стороне клиента, Always Encrypted гарантирует, что конфиденциальные данные остаются защищенными от несанкционированного доступа. Его удобство интеграции и соответствия требованиям делает его важным инструментом для организаций, стремящихся защитить свои самые ценные ресурсы данных.