Рекомендации по безопасности и соответствию требованиям для пакетной службы

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

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

Доступен ряд функций, которые помогут вам создать более безопасное развертывание пакетной службы Azure. Можно ограничить доступ к узлам и снизить обнаруживаемость узлов из Интернета путем подготовки пула без общедоступных IP-адресов. Чтобы вычислительные узлы пула могли безопасно взаимодействовать с другими виртуальными машинами или с локальной сетью, можно подготовить пул к работе в подсети виртуальной сети Azure. Также можно включить закрытый доступ из виртуальных сетей из службы, работающей с помощью Приватного канала Azure.

Общие рекомендации в отношении безопасности

Конфигурация пула

Пулы можно настроить в одном из двух режимов связи узлов, классических или упрощенных. В классической модели связи между узлами пакетная служба инициирует обмен данными с вычислительными узлами, а вычислительные узлы также требуют взаимодействия с служба хранилища Azure. В упрощенной модели обмена данными с узлами вычислительные узлы инициируют взаимодействие со службой пакетной службы. Из-за ограниченной области входящих и исходящих подключений, а не требуется служба хранилища Azure исходящий доступ для базовой операции, рекомендуется использовать упрощенную модель связи узлов. Классическая модель связи с узлами будет прекращена 31 марта 2026 г.

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

Проверка подлинности учетной записи пакетной службы

Доступ к учетной записи пакетной службы поддерживает два метода проверки подлинности: общий ключ и идентификатор Microsoft Entra.

Настоятельно рекомендуем использовать Microsoft Entra ID для проверки подлинности учетных записей пакетной службы. Для некоторых из возможностей пакетной службы этот метод проверки подлинности обязателен; это относится ко многим возможностям безопасности, обсуждаемым в данной статье. Механизм проверки подлинности API службы для учетной записи пакетной службы может быть ограничен только идентификатором Microsoft Entra с помощью свойства allowAuthenticationModes . Если это свойство задано, вызовы API с использованием проверки подлинности с общим ключом отклоняется.

Режим распределения пула пакетной службы

При создании учетной записи пакетной службы можно выбрать один из двух режимов распределения пула:

• Пакетная служба: параметр по умолчанию, где базовые ресурсы масштабируемого набора виртуальных машин, используемые для выделения узлов пула и управления ими, создаются в подписках пакетной службы и не отображаются непосредственно в портал Azure. Отображаются только пулы и узлы пакетной службы.
• Подписка пользователя: базовые ресурсы масштабируемого набора виртуальных машин создаются в той же подписке, что и учетная запись пакетной службы. Таким образом, эти ресурсы отображаются в подписке, в дополнение к соответствующим ресурсам пакетной службы.

В режиме "Пользовательская подписка" виртуальные машины пакетной службы и другие ресурсы создаются непосредственно в подписке пользователя при создании пула. Режим подписки пользователя необходим, если требуется создать пулы пакетной службы с помощью зарезервированных экземпляров виртуальных машин Azure, использовать Политика Azure в ресурсах масштабируемого набора виртуальных машин и (или) управлять основной квотой для подписки (общая для всех учетных записей пакетной службы в подписке). Чтобы создать учетную запись пакетной службы в режиме пользовательской подписки, необходимо зарегистрировать подписку в пакетной службе Azure и связать учетную запись с Azure Key Vault.

Ограничение доступа к конечной точке сети

Конечные точки сети пакетной службы

По умолчанию конечные точки с общедоступными IP-адресами используются для связи с учетными записями пакетной службы, пулами пакетной обработки и узлами пула.

API-интерфейс учетной записи пакетной службы

При создании учетной записи пакетной службы создается общедоступная конечная точка, которая используется для вызова большинства операций над учетной записью с помощью REST API. У этой конечной точки учетной записи имеется базовый URL-адрес в формате https://{account-name}.{region-id}.batch.azure.com. Доступ к учетной записи пакетной службы защищен, с подключением к конечной точке учетной записи, зашифрованной с помощью HTTPS, и каждый запрос, прошедший проверку подлинности с помощью общего ключа или проверки подлинности Microsoft Entra.

Azure Resource Manager

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

Операции управления пакетной службой с помощью Azure Resource Manager шифруются с помощью HTTPS, и каждый запрос проходит проверку подлинности с помощью проверки подлинности Microsoft Entra.

Вычислительные узлы пула пакетной службы

Пакетная служба взаимодействует с агентом узла пакетной службы, который выполняется на каждом из узлов в пуле. Например, служба инструктирует агент узла запустить задачу, остановить задачу или получить файлы для задачи. Связь с агентом узла обеспечивается одним или несколькими балансировщиками нагрузки, количество которых зависит от количества узлов в пуле. Балансировщик нагрузки перенаправляет данные канала связи на нужный узел, причем каждый из узлов адресуется по уникальному номеру порта. По умолчанию с балансировщиками нагрузки связаны их общедоступные IP-адреса. Также удаленный доступ к узлам пула можно получить по протоколам RDP или SSH (этот тип доступа включен по умолчанию, с обменом данными через балансировщики нагрузки).

ОС вычислительного узла пакетной службы

Пакетная служба поддерживает операционные системы Linux и Windows. Пакетная служба поддерживает Linux с выровненным агентом узла для подмножества дистрибутивов ОС Linux. Рекомендуется обновлять операционную систему с последними исправлениями, предоставляемыми издателем ОС.

Рекомендуется включить автоматическое обновление ОС для пулов пакетной службы, что позволяет базовой инфраструктуре Azure координировать обновления в пуле. Этот параметр можно настроить как неразрывную для выполнения задачи. Автоматическое обновление ОС не поддерживает все операционные системы, поддерживающие пакетную службу. Дополнительные сведения см. в таблице поддержки автоматического обновления ОС Масштабируемые наборы виртуальных машин. Для операционных систем Windows убедитесь, что свойство не включается virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates при автоматическом обновлении ОС в пуле пакетной службы.

Поддержка пакетной службы для образов и агентов узлов с течением времени, как правило, соответствует временной шкале поддержки издателя. Рекомендуется избегать использования изображений с датами окончания срока действия (EOL) или изображениями, прошедшими дату EOL. Вы несете ответственность за периодическое обновление представления дат EOL, относящихся к пулам, и переносить рабочие нагрузки до даты EOL. Если вы используете пользовательский образ с определенным (указанным) агентом узла, проследите за соблюдением дат окончания срока поддержки пакетной службы для образа, для которого ваш пользовательский образ является производным или согласованным. Изображение без указанной batchSupportEndOfLife даты указывает, что такая дата еще не определена пакетной службой. Отсутствие даты не означает, что соответствующий образ будет поддерживаться на неопределенный срок. Дата EOL может быть добавлена или обновлена в будущем в любое время. Даты EOL можно обнаружить с помощью ListSupportedImages API, PowerShell или Azure CLI.

Безопасность транспортного уровня ОС Windows (TLS)

Агент пакетного узла не изменяет значения по умолчанию операционной системы для версий SSL/TLS или порядка наборов шифров. В Windows версии SSL/TLS и порядок набора шифров контролируется на уровне операционной системы, поэтому агент пакетного узла принимает параметры, заданные образом, используемым каждым вычислительным узлом. Хотя агент узла пакетной службы пытается использовать наиболее безопасные параметры, доступные по возможности, он по-прежнему может быть ограничен параметрами уровня операционной системы. Рекомендуется просмотреть значения по умолчанию уровня ОС и задать их соответствующим образом для наиболее безопасного режима, который подходит для рабочих процессов и требований организации. Дополнительные сведения см. в разделе "Управление протоколом TLS для принудительного применения порядка шифров" и параметров реестра TLS для управления версиями SSL/TLS для Schannel SSP. Обратите внимание, что некоторые изменения параметров требуют, чтобы перезагрузка вступила в силу. Использование более новой операционной системы с современными параметрами безопасности по умолчанию или пользовательским образом с измененными параметрами рекомендуется вместо применения таких параметров с задачей запуска пакетной службы.

Ограничение доступа к конечным точкам пакетной службы

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

Использование частных конечных точек

Приватный канал Azure обеспечивает доступ к службам PaaS Azure и к размещенным в Azure службам клиентов или партнеров через частную конечную точку в вашей виртуальной сети. С помощью Приватного канала можно ограничить доступ к учетной записи пакетной службы из виртуальной сети или из любой одноранговой виртуальной сети. Ресурсы, сопоставленные с Приватным каналом, также доступны локально по частному пирингу через VPN или Azure ExpressRoute.

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

Создание пулов в виртуальных сетях

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

Чтобы позволить вычислительным узлам безопасно обмениваться данными с другими виртуальными машинами или с локальной сетью, можно настроить пул с размещением в подсети виртуальной сети (VNET) Azure.

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

• Входящий трафик TCP от IP-адресов пакетной службы
• Входящий трафик TCP для удаленного доступа
• Исходящий трафик на любые порты в виртуальной сети (может корректироваться согласно правилам группы безопасности NSG на уровне подсетей).
• Исходящий трафик на любые порты в Интернете (может корректироваться согласно правилам группы безопасности NSG на уровне подсетей).

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

Дополнительные сведения см. в разделе Создание пула пакетной службы Azure в виртуальной сети.

Создание пулов со статическими общедоступными IP-адресами

По умолчанию общедоступные IP-адреса, связанные с пулами, являются динамическими; они создаются при создании пула, а IP-адреса можно добавлять или удалять при изменении размера пула. Если приложениям задач, которые выполняются на узлах пула, необходим доступ к внешним службам, может потребоваться ограничить доступ к этим службам лишь конкретными IP-адресами. В этом случае динамические IP-адреса не будут управляться.

Вместо этого можно создать ресурсы со статическими общедоступными IP-адресами в той же подписке, что и учетная запись пакетной службы, перед созданием пула. Затем эти адреса можно указать при создании пула.

Дополнительные сведения см. в статье Создание пула пакетной службы Azure с указанными общедоступными IP-адресами.

Создание пулов без общедоступных IP-адресов

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

Чтобы ограничить доступ к этим узлам и уменьшить возможность обнаружения этих узлов из Интернета, вы можете подготовить пул без общедоступных IP-адресов.

Дополнительные сведения см. в разделе Создание пула без общедоступных IP-адресов.

Ограничение удаленного доступа к узлам пула

По умолчанию пакетная служба позволяет пользователю узла с возможностью подключения к сети подключаться извне к вычислительному узлу в пуле пакетной службы, используя протоколы RDP или SSH.

Чтобы ограничить удаленный доступ к узлам, используйте один из следующих способов.

• Настройте конфигурацию PoolEndpointConfiguration на отказ в доступе. С пулом будет связана соответствующая группа безопасности сети (NSG).
• Создайте пул без общедоступных IP-адресов. По умолчанию к таким пулам нельзя получить извне виртуальной сети.
• Свяжите группу NSG с виртуальной сетью, чтобы запретить доступ к портам RDP и SSH.
• Не создавайте пользователей на узле. Если на узле нет пользователей, удаленный доступ к нему будет невозможен.

Шифрование данных

Шифрование передаваемых данных

Все соединения с конечной точкой учетной записи пакетной службы (или соединения через Azure Resource Manager) должны использовать протокол HTTPS. В URL-адресах учетной записи пакетной службы, указываемых в API при подключении к пакетной службе, необходимо использовать префикс https://.

Клиенты, взаимодействующие с пакетной службой, должны быть настроены на использование протокола TLS 1.2.

Шифрование неактивных данных пакетной службы

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

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

Шифрование дисков узлов вычислений

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

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

• Шифрование управляемых неактивных дисков с помощью ключей, управляемых платформой
• Шифрование на узле с использованием ключей, управляемых платформой
• Дисковое шифрование Azure

Безопасный доступ к службам с узлов вычислений

Используйте управляемые удостоверения пула с соответствующими разрешениями доступа, настроенными для управляемого удостоверения, назначаемого пользователем, для доступа к службам Azure, поддерживающим управляемое удостоверение, включая Azure Key Vault. Если необходимо подготовить сертификаты на узлах пакетной службы, используйте доступное расширение виртуальной машины Azure Key Vault с управляемым удостоверением пула для установки сертификатов и управления ими в пуле пакетной службы. Дополнительные сведения о развертывании сертификатов из Azure Key Vault с управляемым удостоверением в пулах пакетной службы см. в статье "Включить автоматическую смену сертификатов в пуле пакетной службы".

Система управления и соответствие требованиям

Соответствие нормативным требованиям

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

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

Политика Azure

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

В зависимости от режима распределения пула и ресурсов, к которым должна применяться политика, применяйте Политику Azure к пакетной службе одним из следующих способов.

• Напрямую, с использованием ресурса Microsoft.Batch/batchAccounts. Можно использовать подмножество свойств для учетной записи пакетной службы. Например, политика может включать допустимые регионы для учетной записи пакетной службы, разрешенный режим распределения пула, а также разрешать или запрещать общедоступные сети для учетных записей.
• Косвенно, с использованием ресурса Microsoft.Compute/virtualMachineScaleSets. Учетные записи пакетной службы с режимом выделения пула подписок пользователей могут иметь политику для ресурсов масштабируемого набора виртуальных машин, созданных в подписке учетной записи пакетной службы. Например, так можно задавать разрешенные размеры виртуальных машин или гарантировать выполнение на каждом из узлов пула определенных расширений.

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

• Ознакомьтесь с базовым планом безопасности Azure для пакетной службы.
• Ознакомьтесь с рекомендациями по использованию пакетной службы Azure.