Вопросы безопасности при перемещении данных в фабрике данных Azure
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
Фабрика данных Azure Azure Synapse Analytics
Совет
Попробуйте использовать фабрику данных в Microsoft Fabric, решение для аналитики с одним интерфейсом для предприятий. Microsoft Fabric охватывает все, от перемещения данных до обработки и анализа данных в режиме реального времени, бизнес-аналитики и отчетности. Узнайте, как бесплатно запустить новую пробную версию !
В этой статье описывается базовая инфраструктура безопасности, используемая службами перемещения данных в фабрике данных Azure для помощи в защите данных. Ресурсы управления фабрики данных созданы на основе инфраструктуры безопасности Azure и используют все возможные меры безопасности, предлагаемые Azure.
С помощью фабрики данных можно создать один или несколько конвейеровданных. Конвейеры — это логические группы действий, которые вместе отвечают за выполнение задачи. Эти конвейеры реализуются в регионе, где была создана фабрика данных.
Хотя служба "Фабрика данных" доступна только в нескольких регионах, служба перемещения данных доступна глобально для обеспечения соответствия данным и эффективности, а также снижения затрат на исходящий трафик.
Фабрика данных Azure, включая Azure Integration Runtime и локальную среду выполнения интеграции, не сохраняет временные данные, данные кэша или журналы, за исключением учетных данных связанной службы для облачных хранилищ данных, которые шифруются с помощью сертификатов. Используя фабрику данных, можно создать управляемые данными рабочие процессы, чтобы организовать перемещение данных между поддерживаемыми хранилищами данных и обработку данных с помощью служб вычислений в других регионах или локальной среде. Кроме того, можно отслеживать рабочие процессы и управлять ими с помощью пакетов SDK и Azure Monitor.
Фабрика данных прошла такую сертификацию:
| Сертификация CSA STAR |
|---|
| ISO 20000-1:2011 |
| ISO 22301:2012 |
| ISO 27001:2013 |
| ISO 27017:2015 |
| ISO 27018:2014 |
| ISO 9001:2015 |
| SOC 1, 2, 3 |
| HIPAA BAA |
| HITRUST. |
Если вас интересует, как Azure обеспечивает соответствие требованиям и защищает собственную инфраструктуру, посетите центр управления безопасностью Майкрософт. Самый актуальный список всех предложений для соответствия требованиям Azure см. на странице https://aka.ms/AzureCompliance.
В этой статье мы рассмотрим вопросы безопасности в следующих двух сценариях перемещения данных:
- Облачный сценарий, в котором источник и приемник являются общедоступными через Интернет. Эти источники данных включают управляемые службы облачного хранения, например служба хранилища Azure, Azure Synapse Analytics, база данных SQL Azure, Azure Data Lake Store, Amazon S3, Amazon Redshift, службы SaaS (Salesforce) и такие веб-протоколы, как FTP и OData. Полный список поддерживаемых источников данных можно найти в разделе Поддерживаемые хранилища данных и форматы.
- Гибридный сценарий, в котором источник или приемник находится за брандмауэром или внутри локальной корпоративной сети. Или хранилище данных находится в частной или виртуальной сети (чаще всего это актуально для источника) и не является общедоступным. Этот сценарий также охватывает серверы базы данных, расположенные на виртуальных машинах.
Примечание.
Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Сведения о начале работы см. в статье "Установка Azure PowerShell". Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.
Облачные сценарии
Защита учетных данных хранилища данных
- Хранение зашифрованных учетных данных в управляемом хранилище фабрики данных Azure. Фабрика данных помогает защитить учетные данные хранилища данных, выполняя их шифрование с помощью сертификатов, управляемых корпорацией Майкрософт. Эти сертификаты меняются каждые два года. Изменения включают продление сертификата и перемещение учетных данных. Дополнительные сведения о безопасности службы хранилища Azure см. в этой статье.
- Хранение учетных данных в Azure Key Vault. Учетные данные хранилища также можно хранить в Azure Key Vault. Фабрика данных получает учетные данные во время выполнения действия. Дополнительные сведения см. в статье Хранение учетных данных в Azure Key Vault.
Централизованное хранение секретов приложения в Azure Key Vault позволяет управлять их распространением. Key Vault значительно снижает вероятность случайной утечки секретов. Вместо хранения строки подключения в коде приложений она безопасно хранится в Key Vault. Ваши приложения могут безопасно получить необходимые сведения, используя URI. Эти URI позволяют приложениям получить определенные версии секрета. Нет необходимости писать специальный код для защиты любых секретных данных, хранящихся в Key Vault.
Шифрование данных при передаче
Если облачное хранилище данных поддерживает протоколы HTTPS или TLS, то передача всех данных между службами перемещения данных в Фабрике данных и облачным хранилищем данных выполняется через эти защищенные каналы.
Примечание.
Во время передачи данных в базу данных и из нее все подключения к Базе данных SQL Azure и Azure Synapse Analytics должны быть зашифрованы (с помощью SSL или TLS). Разрабатывая конвейер с помощью JSON, добавьте свойство "encryption" и в строке подключения задайте для него значение true. Для службы хранилища Azure вы можете использовать в строке подключения протокол HTTPS.
Примечание.
Чтобы включить шифрование при передаче данных из Oracle, следуйте одному из следующих вариантов:
- На сервере Oracle перейдите к Oracle Advanced Security (OAS) и задайте настройки шифрования, которые поддерживают шифрование Triple-DES (3DES) и Advanced Encryption Standard (AES). Подробности см. здесь. ADF автоматически согласовывает метод шифрования таким образом, чтобы при установлении соединения с Oracle использовался тот метод шифрования, который вы настроили в OAS.
- В ADF вы можете добавить EncryptionMethod = 1 в строке подключения (в связанной службе). В таком случае в качестве метода шифрования будут использоваться протоколы SSL/TLS. Чтобы использовать эту функцию, необходимо отключить параметры шифрования без SSL в OAS на стороне сервера Oracle, чтобы избежать конфликтов шифрования.
Примечание.
Для TLS используется версия 1.2.
Шифрование неактивных данных
Некоторые хранилища данных поддерживают шифрование неактивных данных. Мы рекомендуем включить механизм шифрования данных для этих хранилищ данных.
Azure Synapse Analytics
Прозрачное шифрование данных (TDE) в Azure Synapse Analytics помогает защититься от вредоносных атак благодаря шифрованию и расшифровке неактивных данных в реальном времени. Этот процесс является прозрачным для клиента. Дополнительные сведения см. в статье Защита базы данных в Azure Synapse Analytics.
База данных SQL Azure
База данных SQL Azure также поддерживает прозрачное шифрование данных, которое помогает защитить от угрозы вредоносных атак за счет шифрования и расшифровки данных в реальном времени, не внося изменения в само приложение. Этот процесс является прозрачным для клиента. Дополнительные сведения см. в статье Прозрачное шифрование данных для хранилища данных и базы данных SQL Azure.
Azure Data Lake Store
В Azure Data Lake Store можно также включить шифрование данных, хранящихся в учетной записи. При включении Data Lake Store автоматически шифрует данные перед сохранением и расшифровывает их до извлечения. Таким образом данные полностью прозрачны для клиента, который получает к ним доступ. Дополнительные сведения см. в статье Обеспечение безопасности в хранилище озера данных Azure.
Хранилище BLOB-объектов Azure и хранилище таблиц Azure
Хранилище BLOB-объектов Azure и хранилище таблиц Azure поддерживают функцию шифрования службы хранилища, которая автоматически шифрует данные перед их сохранением в хранилище и расшифровывает их до извлечения. Дополнительные сведения см. в статье Шифрование службы хранилища Azure для неактивных данных (предварительная версия).
Amazon S3
Amazon S3 поддерживает шифрование неактивных данных для сервера и клиента. Дополнительные сведения см. в документации Protecting Data Using Encryption (Защита данных с помощью шифрования).
Amazon Redshift
Amazon Redshift поддерживает шифрование неактивных данных кластера. Дополнительные сведения см. в документации Amazon Redshift Database Encryption (Шифрование базы данных Amazon Redshift).
Salesforce
Salesforce поддерживает шифрование Shield Platform Encryption, которое позволяет зашифровать все файлы, вложения и настраиваемые поля. Дополнительные сведения см. в статье Understanding the Web Server OAuth Authentication Flow (Основные сведения о потоке проверки подлинности OAuth веб-сервера).
Гибридные сценарии
Для реализации гибридных сценариев необходимо установить локальную среду выполнения интеграции в локальной сети, виртуальной сети (Azure) или виртуальном частном облаке (Amazon). У локальной среды выполнения интеграции должен быть доступ к локальным хранилищам данных. Дополнительные сведения о локальной среде выполнения интеграции см. в статье Создание и настройка локальной среды выполнения интеграции.
Канал команд обеспечивает взаимодействие между службами перемещения данных в фабрике данных и локальной среде выполнения интеграции. Этот коммуникационный канал содержит сведения, связанные с действиями. Канал данных используется для передачи данных между локальными хранилищами данных и облачными хранилищами.
Учетные данные локального хранилища данных
При выполнении из Azure Key Vault учетные данные могут храниться или использоваться по ссылке в фабрике данных. Если учетные данные хранятся в фабрике данных, они всегда зашифрованы в локальной среде выполнения интеграции.
Хранение учетных данных в локальной среде. При непосредственном использовании командлета Set-AzDataFactoryV2LinkedService со строками подключения и учетными данными, содержащимися в JSON, связанная служба зашифровывается и сохраняется в локальной среде выполнения интеграции. В этом случае учетные данные проходят через серверную службу Azure с очень высоким уровнем защиты на компьютер с локальной средой выполнения интеграции, где в итоге шифруются и сохраняются. Локальная среда выполнения интеграции использует Windows DPAPI для шифрования конфиденциальных данных и учетных данных.
Хранение учетных данных в Azure Key Vault. Учетные данные хранилища также можно хранить в Azure Key Vault. Фабрика данных получает учетные данные во время выполнения действия. Дополнительные сведения см. в статье Хранение учетных данных в Azure Key Vault.
Храните учетные данные локально, не передавая их через серверную часть Azure в локальную среду выполнения интеграции. Чтобы зашифровать и сохранить учетные данные в локальной среде выполнения интеграции без их отправки через серверную часть фабрики данных, воспользуйтесь инструкциями из статьи Шифрование учетных данных для локальных хранилищ данных в фабрике данных Azure. Этот вариант поддерживают все соединители. Локальная среда выполнения интеграции использует Windows DPAPI для шифрования конфиденциальных данных и учетных данных.
Для шифрования учетных данных связанной службы и конфиденциальных данных в связанной службе используйте командлет New-AzDataFactoryV2LinkedServiceEncryptedCredential. Затем возвращаемое значение JSON (с элементом EncryptedCredential в строке подключения) можно использовать для создания связанной службы с помощью командлета Set-AzDataFactoryV2LinkedService.
Порты, используемые для шифрования связанной службы в локальной среде выполнения интеграции
По умолчанию при включенном удаленном доступе из интрасети PowerShell использует для безопасного обмена данными порт 8060 на компьютере с локальной средой выполнения интеграции. При необходимости этот порт можно изменить в Integration Runtime Configuration Manager на вкладке "Параметры":
Шифрование при передаче
Все передачи данных выполняются через защищенный канал HTTPS и TLS через TCP, чтобы предотвратить атаки "злоумышленник в середине" во время взаимодействия со службами Azure.
Вы также можете использовать VPN-подключение IPSec или Azure ExpressRoute, чтобы в дальнейшем обеспечить безопасность коммуникационного канала между локальной сетью и Azure.
Виртуальная сеть Azure— это логическое представление сети в облаке. Вы можете подключить локальную сеть к виртуальной сети, настроив VPN-подключение IPSec "сеть — сеть" или ExpressRoute (частный пиринг).
В таблице ниже представлены общие рекомендации для настройки локальной среды выполнения интеграции и сети на основе различных комбинаций исходного и целевого расположений для гибридного перемещения данных.
| Источник | Назначение | Сетевая конфигурация | Настройка среды выполнения интеграции |
|---|---|---|---|
| Локально | Виртуальные машины и облачные службы, развернутые в виртуальных сетях | VPN-подключение IPSec (типа "точка — сеть" или "сеть — сеть") | Вы можете установить локальную среду выполнения интеграции на виртуальной машине Azure в виртуальной сети. |
| Локально | Виртуальные машины и облачные службы, развернутые в виртуальных сетях | ExpressRoute (частный пиринг) | Вы можете установить локальную среду выполнения интеграции на виртуальной машине Azure в виртуальной сети. |
| Локально | Службы на базе Azure, у которых есть общедоступная конечная точка | ExpressRoute (с пирингом Майкрософт) | Вы можете установить локальную среду выполнения интеграции локально или на виртуальной машине Azure. |
На изображениях ниже показано, как использовать локальную среду выполнения интеграции для перемещения данных между локальной базой данных и службами Azure с помощью ExpressRoute и VPN-подключения IPSec (с помощью виртуальной сети Azure).
ExpressRoute
VPN-подключение IPSec
Настройки брандмауэра и списка разрешенных IP-адресов
Примечание.
Иногда возникает необходимость настроить порты или создать список разрешенных доменов на уровне корпоративного брандмауэра в соответствии с определенными источниками данных. В этой таблице в качестве примеров используются база данных SQL Azure, Azure Synapse Analytics и Azure Data Lake Store.
Примечание.
Дополнительные сведения о стратегиях доступа к данным с помощью Фабрики данных Azure см. в этой статье.
Требования к брандмауэру для локальной или частной сети
На предприятии корпоративный брандмауэр работает на центральном маршрутизаторе организации. Брандмауэр Windows работает как управляющая программа на локальном компьютере, на котором установлена локальная среда выполнения интеграции.
В таблице ниже представлены исходящий порт и требования к домену для корпоративных брандмауэров.
| Имена доменов | Исходящие порты | Description |
|---|---|---|
*.servicebus.windows.net |
443 | Требуется локальной среде выполнения интеграции для интерактивной разработки. |
{datafactory}.{region}.datafactory.azure.netили *.frontend.clouddatahub.net |
443 | Требуется локальной среде выполнения интеграции для подключения к службе фабрики данных. Для нового экземпляра Фабрики данных найдите полное доменное имя из ключа локальной среды IR в формате {datafactory}.{region}.datafactory.azure.net. Для старого экземпляра Фабрики данных, если полное доменное имя не отображается в ключе локальной среды IR, используйте *.frontend.clouddatahub.net. |
download.microsoft.com |
443 | Требуется локальной среде выполнения интеграции для скачивания обновлений. Если автоматическое обновление отключено, можно пропустить настройку этого домена. |
*.core.windows.net |
443 | Используется локальной средой выполнения интеграции для подключения к учетной записи хранения Azure при помощи функции промежуточного копирования. |
*.database.windows.net |
1433 | Требуется только при двунаправленном копировании с участием Базы данных SQL Azure или Azure Synapse Analytics. Используйте функцию промежуточного копирования для копирования данных в Базу данных SQL или Azure Synapse Analytics, не открывая порт 1433. |
*.azuredatalakestore.netlogin.microsoftonline.com/<tenant>/oauth2/token |
443 | Требуется только при двунаправленном копировании с участием Azure Data Lake Store. |
Примечание.
Иногда возникает необходимость настроить порты или создать список разрешенных доменов на уровне корпоративного брандмауэра в соответствии с определенными источниками данных. В этой таблице в качестве примеров используются база данных SQL Azure, Azure Synapse Analytics и Azure Data Lake Store.
В следующей таблице представлены требования к входящему порту для брандмауэра Windows.
| Входящие порты | Description |
|---|---|
| 8060 (TCP) | Требуется для командлета шифрования PowerShell, как описано в статье Шифрование учетных данных для локальных хранилищ данных в фабрике данных Azure, или для приложения диспетчера учетных данных, чтобы обеспечить безопасную настройку учетных данных для локальных хранилищ данных в локальной среде выполнения интеграции. |
Настройка IP-адресов и списка разрешенных в хранилищах данных
Некоторые хранилища данных в облаке также требуют, чтобы IP-адрес компьютера, который к ним обращается, был добавлен в список разрешенных. IP-адрес компьютера локальной среды выполнения интеграции должен быть добавлен в список разрешений или корректно настроен в брандмауэре.
Ниже перечислены облачные хранилища данных, которым необходим разрешенный IP-адрес компьютера локальной среды выполнения интеграции. Некоторым из этих хранилищ данных по умолчанию это может не потребоваться.
Часто задаваемые вопросы
Может ли локальная среда выполнения интеграции совместно использоваться разными фабриками данных?
Да. Дополнительные сведения см. здесь.
Каковы требования к портам для работы локальной среды выполнения интеграции?
Локальная среда выполнения интеграции устанавливает HTTP-подключения для доступа к Интернету. Для установки этих подключений для локальной среды выполнения интеграции должны быть открыты исходящие порты 443. Откройте входящий порт 8060 только на уровне компьютера (не на уровне корпоративного брандмауэра) для приложения диспетчера учетных данных. Если база данных SQL Azure или Azure Synapse Analytics используются в качестве исходного или целевого объектов, вам также необходимо открыть порт 1433. Дополнительные сведения см. в разделе о настройке брандмауэра и списка разрешенных IP-адресов.
Связанный контент
Дополнительные сведения о производительности действия копирования для фабрики данных Azure см. в статье Руководство по настройке производительности действия копирования.