Partager via

Meilleures pratiques en matière de sécurité et de conformité par lots

  • Article

Cet article fournit des conseils et des meilleures pratiques pour améliorer la sécurité lors de l’utilisation de Azure Batch.

Par défaut, les comptes Azure Batch possèdent un point de terminaison public et sont accessibles publiquement. Lorsqu’un pool Azure Batch est créé, le pool est configuré dans un sous-réseau spécifié d’un réseau virtuel Azure. Les machines virtuelles du pool Batch sont accessibles, par défaut, par le biais d’adresses IP publiques créées par Batch. Les nœuds de calcul d’un pool peuvent communiquer entre eux si nécessaire, par exemple pour exécuter des tâches multi-instances, mais les nœuds d’un pool ne peuvent pas communiquer avec les ordinateurs virtuels en dehors du pool.

Diagramme montrant un environnement de traitement par lots classique.

De nombreuses fonctionnalités sont disponibles pour vous aider à créer un déploiement de Azure Batch plus sécurisé. Pour restreindre l’accès à des nœuds et réduire la détectabilité des nœuds à partir d’Internet, en configurant le pool sans adresse IP publiques. Les nœuds de calcul peuvent communiquer en toute sécurité avec d’autres machines virtuelles ou avec un réseau local en configurant le pool dans un sous-réseau d’un réseau virtuel Azure. Vous pouvez également activer l’accès privé à partir de réseaux virtuels à partir d’un service alimenté par Azure Private Link.

Diagramme montrant un environnement de traitement par lots plus sécurisé.

Configuration du pool

Les pools peuvent également être configurés dans l’un des deux modes de communication de nœud, classique ou simplifié. Dans le modèle de communication de nœud classique, le service Batch initie la communication avec les nœuds de calcul, et les nœuds de calcul nécessitent également la communication avec Stockage Azure. Dans le modèle de communication de nœud simplifié, les nœuds de calcul lancent la communication avec le service Batch. En raison de l’étendue réduite des connexions entrantes/sortantes requises et de ne pas nécessiter d’accès sortant stockage Azure pour l’opération de base, il est recommandé d’utiliser le modèle de communication de nœud simplifié. Le modèle classique de communication entre les nœuds sera mis hors service le 31 mars 2026.

Les pools doivent également être configurés avec des paramètres de sécurité renforcée, notamment le lancement fiable (nécessite des images de machine virtuelle Gen2 et une taille de machine virtuelle compatible), ce qui permet le démarrage sécurisé, vTPM et le chiffrement sur l’hôte (nécessite une taille de machine virtuelle compatible).

Authentification de compte Batch

L’accès au compte Batch prend en charge deux méthodes d’authentification : clé partagée et Microsoft Entra ID.

Nous vous recommandons vivement d’utiliser Microsoft Entra ID pour l’authentification par compte Batch. Certaines fonctionnalités Batch nécessitent cette méthode d’authentification, y compris un grand nombre de fonctionnalités liées à la sécurité présentées ici. Le mécanisme d'authentification de l'API de service pour un compte Batch peut être limité à Microsoft Entra ID en utilisant la propriété allowedAuthenticationModes. Lorsque cette propriété est définie, les appels d'API utilisant l'authentification par clé partagée sont rejetés.

Mode d’allocation de pool de compte Batch

Lorsque vous créez un compte Batch, vous pouvez choisir entre deux modes de répartition de pool :

  • Service Batch : L’option par défaut, dans laquelle les ressources du groupe de machines virtuelles identiques sous-jacent utilisées pour allouer et gérer des nœuds de pool sont créées dans des abonnements appartenant à Batch et ne sont pas directement visibles dans le portail Azure. Seuls les pools et les nœuds batch sont visibles.
  • Abonnement utilisateur : Les ressources du groupe de machines virtuelles identiques sous-jacent sont créées dans le même abonnement que le compte Batch. Ces ressources sont donc visibles dans l’abonnement, en plus des ressources Batch correspondantes.

Avec le mode d’abonnement utilisateur, des machines virtuelles Batch et autres ressources sont créées directement dans l’abonnement lors de la création d’un pool. Le mode abonnement utilisateur est requis si vous souhaitez créer des pools Batch à l’aide de Azure Reserved VM Instances, utiliser Azure Policy sur des ressources de Virtual Machine Scale Set et/ou gérer le quota principal de l’abonnement (partagé par tous les comptes Batch de l’abonnement). Pour créer un compte Batch dans le mode abonnement utilisateur, vous devez également inscrire votre abonnement auprès d’Azure Batch et associer le compte avec une Azure Key Vault.

Restreindre l’accès au point de terminaison public

Points de terminaison de réseau Batch

Par défaut, les points de terminaison avec des adresses IP publiques sont utilisés pour communiquer avec les comptes Batch, les pools Batch et les nœuds de pool.

API du compte Batch

Lorsqu’un compte Batch est créé, un point de terminaison public est créé et utilisé pour appeler la plupart des opérations du compte à l’aide d’une API REST. Le point de terminaison du compte a une URL de base à l’aide du format https://{account-name}.{region-id}.batch.azure.com. L’accès au compte Batch est sécurisé, avec la communication vers le point de terminaison de compte chiffré à l’aide du protocole HTTPS et chaque requête authentifiée à l’aide de l’authentification par clé partagée ou Microsoft Entra.

Azure Resource Manager

En plus des opérations spécifiques à un compte Batch, les opérations de gestion s’appliquent à des comptes Batch uniques et multiples. Ces opérations de gestion sont accessibles via Azure Resource Manager.

Les opérations de gestion par lots via Azure Resource Manager sont chiffrées à l’aide du protocole HTTPS et chaque requête est authentifiée à l’aide de l’authentification Microsoft Entra.

Nœuds de calcul du pool Batch

Le service Batch communique avec un agent de nœud Batch qui s’exécute sur chaque nœud du pool. Par exemple, le service demande à l’agent de nœud d’exécuter une tâche, d’arrêter une tâche ou d’obtenir les fichiers d’une tâche. La communication vers l’agent de nœud est activée par un ou plusieurs équilibreurs de charge, dont le nombre dépend du nombre de nœuds dans un pool. L’équilibreur de charge transmet la communication vers le nœud souhaité, chaque nœud étant adressé par un numéro de port unique. Par défaut, les équilibreurs de charge ont des adresses IP publiques qui leur sont associées. Vous pouvez également accéder à distance aux nœuds de pool via RDP ou SSH (cet accès est activé par défaut, avec communication via les équilibreurs de charge).

Système d’exploitation de nœud de calcul Batch

Batch prend en charge les systèmes d'exploitation Linux et Windows. Batch prend en charge Linux avec un agent de nœud aligné pour un sous-ensemble de distributions de système d’exploitation Linux. Il est recommandé de maintenir le système d’exploitation à jour avec les derniers patchs fournis par l’éditeur du système d’exploitation.

Il est recommandé d’activer la Mise à niveau automatique du système d’exploitation des pools Batch, ce qui permet à l’infrastructure Azure sous-jacente de coordonner les mises à jour sur le pool. Cette option peut être configurée pour ne pas perturber l’exécution des tâches. La mise à niveau automatique du système d’exploitation ne prend pas en charge tous les systèmes d’exploitation pris en charge par Batch. Pour plus d’informations, consultez la Matrice de support de la mise à niveau automatique des systèmes d'exploitation des groupes de machines virtuelles identiques. Pour les systèmes d’exploitation Windows, vérifiez que vous n’activez pas la propriété virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates lors de l’utilisation de la mise à niveau automatique du système d’exploitation sur le pool Batch.

La prise en charge des images et des agents de nœud par Batch est progressivement obsolète au fil du temps, généralement alignée sur les chronologies de prise en charge de l’éditeur. Il est recommandé d’éviter d’utiliser des images avec des dates de fin de vie (EOL) imminentes ou des images qui ont atteint leur date de fin de vie. Il vous incombe d’actualiser régulièrement votre affichage des dates de fin de vie pertinentes pour vos pools, et de migrer vos charges de travail avant la date de fin de vie. Si vous utilisez une image personnalisée avec un agent de nœud spécifié, veillez à suivre les dates de fin de vie de prise en charge de Batch pour l’image pour laquelle votre image personnalisée est dérivée ou avec laquelle elle est alignée. Une image sans date spécifiée batchSupportEndOfLife indique qu’une telle date n’a pas encore été déterminée par le service Batch. L’absence d’une date n’indique pas que l’image respective sera prise en charge indéfiniment. Une date de fin de vie peut être ajoutée ou mise à jour à l’avenir à tout moment. Vous pouvez découvrir ces dates via l’API ListSupportedImages, PowerShell ou Azure CLI.

TLS (Transport Layer Security) du système d’exploitation Windows

L’agent de nœud Batch ne modifie pas les valeurs par défaut au niveau du système d’exploitation pour les versions SSL/TLS ou l’ordre de suite de chiffrement. Dans Windows, les versions SSL/TLS et l’ordre de la suite de chiffrement sont contrôlés au niveau du système d’exploitation. Par conséquent, l’agent de nœud Batch adopte les paramètres définis par l’image utilisée par chaque nœud de calcul. Bien que l’agent de nœud Batch tente d’utiliser les paramètres les plus sécurisés disponibles lorsque cela est possible, il peut toujours être limité par les paramètres au niveau du système d’exploitation. Nous vous recommandons de passer en revue les valeurs par défaut de votre système d’exploitation et de les définir de manière appropriée pour le mode le plus sécurisé qui soit adapté à vos exigences de workflow et d’organisation. Pour plus d’informations, consultez Gérer TLS pour l’application de l’ordre de suite de chiffrement et Paramètres de Registre TLS pour le contrôle de version SSL/TLS pour SSP Schannel. Notez que certaines modifications de paramètres nécessitent un redémarrage pour prendre effet. L’utilisation d’un système d’exploitation plus récent avec des valeurs de sécurité modernes ou une image personnalisée avec des paramètres modifiés est recommandée au lieu d’une application de ces paramètres avec une tâche de démarrage Batch.

Restriction de l’accès aux points de terminaison Batch

Plusieurs fonctionnalités sont disponibles pour limiter l’accès aux différents points de terminaison Batch, en particulier lorsque la solution utilise un réseau virtuel.

Utiliser des points de terminaison privés

Azure Private Link permet d’accéder aux services Azure PaaS ainsi qu’aux services de partenaires ou de clients hébergés par Azure sur un point de terminaison privé dans votre réseau virtuel. Vous pouvez utiliser Private Link pour limiter l’accès des utilisateurs à un compte Batch à partir du réseau virtuel ou de tout réseau virtuel appairé. Les ressources mappées à Private Link sont également accessibles localement via un Peering privé par le biais d’un VPN ou d’Azure ExpressRoute.

Pour utiliser des points de terminaison privés, un compte Batch doit être configuré de manière appropriée lors de sa création ; la configuration de l’accès au réseau public doit être désactivée. Une fois créés, les points de terminaison privés peuvent être créés et associés au compte Batch. Pour plus d’informations, consultez Utiliser des points de terminaison privés avec des comptes Azure Batch.

Créer des pools dans des réseaux virtuels

Les nœuds de calcul d’un pool Batch peuvent communiquer entre eux, par exemple pour exécuter des tâches multi-instances, sans nécessiter de réseau virtuel (VNET). Toutefois, par défaut, les nœuds d’un pool ne peuvent pas communiquer avec les machines virtuelles qui se trouvent en dehors du pool sur un réseau virtuel et ont des adresses IP privées, telles que les serveurs de licences ou les serveurs de fichiers.

Pour autoriser les nœuds de calcul à communiquer de façon sécurisée avec d’autres machines virtuelles ou avec un réseau local, vous pouvez configurer un pool en tant que sous-réseau d’un réseau virtuel Azure.

Lorsque les pools ont des points de terminaison d’adresses IP publiques, le sous-réseau doit autoriser des communications entrantes issues du service Batch pour pouvoir planifier des tâches et exécuter d’autres opérations sur les nœuds de calcul et également des communications sortantes pour communiquer avec le stockage Azure ou d’autres ressources en fonction des besoins de votre charge de travail. Pour les pools dans la configuration de machines virtuelles, Batch ajoute des groupes de sécurité réseau (NSG) au niveau de l’interface réseau attaché aux nœuds de calcul. Ces groupes de sécurité réseau ont des règles pour activer :

  • le trafic TCP entrant à partir des adresses IP du service Batch
  • le trafic TCP entrant pour l’accès à distance
  • le trafic sortant sur n’importe quel port vers le réseau virtuel (peut être modifié par les règles NSG au niveau du sous-réseau)
  • le trafic sortant sur n’importe quel port vers l’Internet (peut être modifié par les règles NSG au niveau du sous-réseau)

Vous n’avez pas besoin de spécifier des groupes de sécurité réseau au niveau du sous-réseau du réseau virtuel, car Batch configure ses propres groupes de sécurité réseau. Si vous avez un groupe de sécurité réseau associé au sous-réseau dans lequel les nœuds de calcul Batch sont déployés ou si vous souhaitez appliquer des règles de groupe de sécurité réseau personnalisées pour remplacer celles appliquées par défaut, vous devez configurer ce groupe de sécurité réseau avec au moins les règles de sécurité entrantes et sortantes afin d’autoriser la communication vers le service Batch aux nœuds de pool et la communication vers le nœud de pool au Stockage Azure.

Pour plus d’informations, consultez l’article Créer un pool Azure Batch dans un réseau virtuel.

Créer des pools avec une adresse IP publique statique

Par défaut, les adresses IP publiques associées aux pools sont dynamiques. Elles sont créées lors de la création d’un pool et des adresses IP peuvent être ajoutées ou supprimées lorsqu’un pool est redimensionné. Lorsque les applications de tâche s’exécutant sur des nœuds de pool doivent accéder à des services externes, l’accès à ces services peut nécessiter une restriction à des adresses IP spécifiques. Dans ce cas, les adresses IP dynamiques ne seront pas gérées.

Vous pouvez créer des ressources d’adresses IP publiques statiques dans le même abonnement que le compte Batch avant la création du pool. Vous pouvez ensuite spécifier ces adresses lors de la création de votre pool.

Pour plus d’informations, consultez Créer un pool Azure Batch avec des adresses IP publiques spécifiées.

Créer des pools sans adresse IP publique

Par défaut, une ou plusieurs adresses IP publiques sont attribuées à tous les nœuds de calcul dans un pool de configuration de machines virtuelles Azure Batch. Ces points de terminaison sont utilisés par le service Batch pour planifier des tâches et pour communiquer avec les nœuds de calcul, notamment dans le cadre de l’accès sortant à Internet.

Pour restreindre l’accès à ces nœuds et réduire la détectabilité de ces nœuds à partir d’Internet, vous pouvez provisionner le pool sans adresses IP publiques.

Pour plus d’informations, consultez Créer un pool sans adresse IP publique.

Limiter l’accès à distance aux nœuds de pool

Par défaut, Batch autorise un utilisateur du nœud disposant d’une connectivité réseau à se connecter en externe à un nœud de calcul dans un pool Batch en utilisant RDP ou SSH.

Pour limiter l’accès à distance aux nœuds, utilisez l’une des méthodes suivantes :

  • Configurez le PoolEndpointConfiguration pour refuser l’accès. Le groupe de sécurité réseau approprié (NSG) approprié sera associé au pool.
  • Créez votre pool sans adresse IP publique. Par défaut, ces pools ne sont pas accessibles en dehors du réseau virtuel.
  • Associez un groupe de sécurité réseau au réseau virtuel pour refuser l’accès aux ports RDP ou SSH.
  • Ne créez aucun utilisateur sur le nœud. Sans aucun utilisateur de nœud, l’accès à distance n’est pas possible.

Chiffrer les données

Chiffrer les données en transit

Toutes les communications vers le point de terminaison du compte Batch (ou via Azure Resource Manager) doivent utiliser le protocole HTTPS. Vous devez utiliser https:// dans les URL de compte Batch spécifiées dans les API lors de la connexion au service Batch.

Les clients qui communiquent avec le service Batch doivent être configurés pour utiliser le protocole TLS (Transport Layer Security) 1.2.

Chiffrer Batch des données au repos

Certaines des informations spécifiées dans les API Batch, telles que les certificats de compte, les métadonnées de tâche et de travail et les lignes de commande de tâche, sont automatiquement chiffrées lorsqu’elles sont stockées par le service Batch. Par défaut, ces données sont chiffrées à l’aide des clés gérées par la plateforme Azure Batch propres à chaque compte Batch.

Vous pouvez également chiffrer ces données avec des clés gérées par le client. Azure Key Vault est utilisé pour générer et stocker la clé, avec l’identificateur de clé inscrit avec votre compte Batch.

Chiffrer des disques de nœud de calcul

Les nœuds de calcul Batch ont deux disques par défaut : un disque de système d’exploitation et le disque SSD temporaire local. Les fichiers et répertoires gérés par Batch se trouvent sur le disque SSD temporaire, qui est l’emplacement par défaut des fichiers tels que les fichiers de sortie des tâches. Les applications de tâche Batch peuvent utiliser l’emplacement par défaut sur le disque SSD ou le disque du système d’exploitation.

Pour une sécurité accrue, chiffrez ces disques à l’aide de l’une de ces fonctionnalités de chiffrement de disque Azure :

Services d’accès sécurisé à partir de nœuds de calcul

Utilisez des identités managées de pool avec les autorisations d’accès appropriées configurées pour l’identité managée affectée par l’utilisateur afin d’accéder aux services Azure qui prennent en charge l’identité managée, y compris Azure Key Vault. Si vous devez provisionner des certificats sur des nœuds Batch, utilisez l’extension de machine virtuelle Azure Key Vault disponible avec l’identité managée de pool pour installer et gérer les certificats sur votre pool Batch. Pour plus d’informations sur le déploiement de certificats à partir d’Azure Key Vault avec une identité managée sur des pools Batch, consultez Activer la rotation automatique des certificats dans un pool Batch.

Gouvernance et conformité

Compatibilité

Pour aider les clients à répondre à leurs propres obligations de conformité dans les secteurs et marchés réglementés dans le monde entier, Azure gère un large éventail d’offres de conformité.

Ces offres sont basées sur divers types de garanties, notamment des certifications, attestations, validations, autorisations et évaluations officielles créées par des sociétés d’audit tierces indépendantes, ainsi que des modifications contractuelles, des auto-évaluations et des documents d’aide pour les clients créés par Microsoft. Consultez la vue d’ensemble complète des offres de conformité pour déterminer celles qui peuvent être pertinentes pour vos solutions Batch.

Azure Policy

Azure Policy aide à appliquer les normes organisationnelles et à évaluer la conformité à grande échelle. Les cas d’usage courants pour Azure Policy incluent la mise en œuvre de la gouvernance pour la cohérence des ressources, la conformité réglementaire, la sécurité, le coût et la gestion.

Selon le mode d’allocation de pools et les ressources auxquelles une stratégie doit s’appliquer, utilisez Azure Policy avec Batch de l’une des manières suivantes :

  • Directement, à l’aide de la ressource Microsoft.Batch/batchAccounts. Vous pouvez utiliser un sous-ensemble des propriétés d’un compte Batch. Par exemple, votre stratégie peut inclure des régions de compte Batch valides, le mode d’allocation de pools autorisé et si un réseau public est activé pour les comptes.
  • Indirectement, à l’aide de la ressource Microsoft.Compute/virtualMachineScaleSets. Les comptes Batch avec le mode d’allocation de pools d’abonnements utilisateur peuvent avoir une stratégie définie selon les ressources du Virtual Machine Scale Set, créées dans l’abonnement au compte Batch. Par exemple, les tailles de machine virtuelle autorisées et la garantie que certaines extensions sont exécutées sur chaque nœud de pool.

Étapes suivantes