Fonctionnalités de sécurité pour Azure Stack HCI, version 23H2

S’applique à : Azure Stack HCI, version 23H2

Azure Stack HCI est un produit sécurisé par défaut qui a plus de 300 paramètres de sécurité activés dès le début. Les paramètres de sécurité par défaut fournissent une base de référence de sécurité cohérente pour garantir que les appareils démarrent dans un état correct connu.

Cet article fournit une brève vue d’ensemble conceptuelle des différentes fonctionnalités de sécurité associées à votre cluster Azure Stack HCI. Les fonctionnalités incluent les paramètres de sécurité par défaut, Windows Defender pour le contrôle d’application (WDAC), le chiffrement de volume via BitLocker, la rotation des secrets, les comptes d’utilisateur locaux intégrés, Microsoft Defender pour le cloud, etc.

Paramètres de sécurité par défaut

Votre instance Azure Stack HCI a des paramètres de sécurité activés par défaut qui fournissent une base de référence de sécurité cohérente, un système de gestion de base de référence et un mécanisme de contrôle de dérive.

Vous pouvez surveiller la base de référence de sécurité et les paramètres de cœur sécurisé pendant le déploiement et l’exécution. Vous pouvez également désactiver le contrôle de dérive pendant le déploiement lorsque vous configurez les paramètres de sécurité.

Une fois le contrôle de dérive appliqué, les paramètres de sécurité sont actualisés toutes les 90 minutes. Cet intervalle d’actualisation garantit la correction de toutes les modifications à partir de l’état souhaité. La surveillance continue et la récupération automatique permettent une posture de sécurité cohérente et fiable tout au long du cycle de vie de l’appareil.

Base de référence sécurisée sur Azure Stack HCI :

  • Améliore la posture de sécurité en désactivant les protocoles et les chiffrements hérités.
  • Réduit les OPEX avec un mécanisme de protection contre la dérive intégré qui permet une surveillance cohérente à grande échelle via la base de référence Azure Arc Hybrid Edge.
  • Vous permet de répondre aux exigences du point de référence du Centre pour la sécurité Internet (CIS) et du Guide d’implémentation technique de sécurité (STIG) de l’Agence d’information de défense (DISA) pour le système d’exploitation et la base de référence de sécurité recommandée.

Pour plus d’informations, consultez Gérer les paramètres de sécurité par défaut sur Azure Stack HCI.

Windows Defender Application Control

WDAC est une couche de sécurité logicielle qui réduit la surface d’attaque en appliquant une liste explicite de logiciels autorisés à s’exécuter. WDAC est activé par défaut et limite les applications et le code que vous pouvez exécuter sur la plateforme principale. Pour plus d’informations, consultez Gérer Windows Defender Contrôle d’application pour Azure Stack HCI, version 23H2.

WDAC fournit deux modes d’opération main, le mode d’application et le mode Audit. En mode d’application, le code non approuvé est bloqué et les événements sont enregistrés. En mode Audit, le code non approuvé est autorisé à s’exécuter et les événements sont enregistrés. Pour en savoir plus sur les événements liés à WDAC, consultez Liste des événements.

Important

Pour réduire les risques de sécurité, exécutez toujours WDAC en mode Application.

À propos de la conception de stratégie WDAC

Microsoft fournit des stratégies signées de base sur Azure Stack HCI pour le mode d’application et le mode Audit. En outre, les stratégies incluent un ensemble prédéfini de règles de comportement de plateforme et de règles de blocage à appliquer à la couche de contrôle d’application.

Composition des stratégies de base

Les stratégies de base Azure Stack HCI incluent les sections suivantes :

  • Métadonnées : les métadonnées définissent des propriétés uniques de la stratégie, telles que le nom de la stratégie, la version, le GUID, etc.
  • Règles d’option : ces règles définissent le comportement de la stratégie. Les stratégies supplémentaires ne peuvent différer que d’un petit ensemble de règles d’option liées à leur stratégie de base.
  • Règles d’autorisation et de refus : ces règles définissent des limites d’approbation de code. Les règles peuvent être basées sur les serveurs de publication, les signataires, le hachage de fichier, etc.

Règles d’option

Cette section a abordé les règles d’option activées par la stratégie de base.

Pour la stratégie appliquée, les règles d’option suivantes sont activées par défaut :

Règle d’option Valeur
activé UMCI
Obligatoire WHQL
activé Autoriser des stratégies supplémentaires
activé Révoqué expiré comme non signé
Désactivé Signature de version d’évaluation
activé Stratégie d’intégrité système non signée (par défaut)
activé Sécurité du code dynamique
activé Menu Options de démarrage avancées
Désactivé Application des scripts
activé Programme d’installation managé
activé Mise à jour de la stratégie Sans redémarrage

La stratégie d’audit ajoute les règles d’option suivantes à la stratégie de base :

Règle d’option Valeur
activé Mode Audit (par défaut)

Pour plus d’informations, consultez la liste complète des règles d’option.

Autoriser et refuser les règles

Les règles d’autorisation dans la stratégie de base permettent à tous les composants Microsoft fournis par le système d’exploitation et les déploiements cloud d’être approuvés. Les règles de refus bloquent les applications en mode utilisateur et les composants du noyau considérés comme non sécurisés pour la posture de sécurité de la solution.

Notes

Les règles d’autorisation et de refus de la stratégie de base sont mises à jour régulièrement pour améliorer la fonctionnalité du produit et optimiser la protection de votre solution.

Pour en savoir plus sur les règles de refus, consultez :

Chiffrement BitLocker

Le chiffrement des données au repos est activé sur les volumes de données créés pendant le déploiement. Ces volumes de données incluent à la fois les volumes d’infrastructure et les volumes de charge de travail. Lorsque vous déployez votre cluster, vous pouvez modifier les paramètres de sécurité.

Par défaut, le chiffrement des données au repos est activé pendant le déploiement. Nous vous recommandons d’accepter le paramètre par défaut.

Une fois Azure Stack HCI déployé, vous pouvez récupérer les clés de récupération BitLocker. Vous devez stocker les clés de récupération BitLocker dans un emplacement sécurisé en dehors du système.

Pour plus d’informations sur le chiffrement BitLocker, consultez :

Comptes d’utilisateur intégrés locaux

Dans cette version, les utilisateurs locaux intégrés suivants associés RID 500 à et RID 501 sont disponibles sur votre système Azure Stack HCI :

Nom dans l’image initiale du système d’exploitation Nom après le déploiement Activée par défaut Description
Administrateur ASBuiltInAdmin True Compte intégré pour l’administration de l’ordinateur/domaine.
Invité ASBuiltInGuest False Compte intégré pour l’accès invité à l’ordinateur/domaine, protégé par le mécanisme de contrôle de dérive de la base de référence de sécurité.

Important

Nous vous recommandons de créer votre propre compte d’administrateur local et de désactiver le compte d’utilisateur connu RID 500 .

Création et rotation de secrets

L’orchestrateur dans Azure Stack HCI nécessite plusieurs composants pour maintenir des communications sécurisées avec d’autres ressources et services d’infrastructure. Tous les services s’exécutant sur le cluster sont associés à des certificats d’authentification et de chiffrement.

Pour garantir la sécurité, nous implémentons des fonctionnalités de création et de rotation de secrets internes. Lorsque vous passez en revue vos nœuds de cluster, plusieurs certificats sont créés sous le chemin LocalMachine/Magasin de certificats personnel (Cert:\LocalMachine\My).

Dans cette version, les fonctionnalités suivantes sont activées :

  • Possibilité de créer des certificats pendant le déploiement et après les opérations de mise à l’échelle du cluster.
  • Autorotation automatisée avant l’expiration des certificats et option permettant de faire pivoter les certificats pendant la durée de vie du cluster.
  • Possibilité de surveiller et d’avertir si les certificats sont toujours valides.

Notes

Les opérations de création et de rotation de secrets prennent environ dix minutes, en fonction de la taille du cluster.

Pour plus d’informations, consultez Gérer la rotation des secrets.

Transfert Syslog des événements de sécurité

Pour les clients et les organisations qui ont besoin de leur propre système SIEM (Local Security Information and Event Management), Azure Stack HCI version 23H2 inclut un mécanisme intégré qui vous permet de transférer des événements liés à la sécurité vers un SIEM.

Azure Stack HCI dispose d’un redirecteur syslog intégré qui, une fois configuré, génère des messages syslog définis dans RFC3164, avec la charge utile au format CEF (Common Event Format).

Le diagramme suivant illustre l’intégration d’Azure Stack HCI à un SIEM. Tous les audits, journaux de sécurité et alertes sont collectés sur chaque hôte et exposés via syslog avec la charge utile CEF.

Le diagramme suivant décrit l’intégration d’Azure Stack HCI à un système SIEM (External Security Information and Event Management).

Les agents de transfert Syslog sont déployés sur chaque hôte Azure Stack HCI pour transférer les messages syslog au serveur syslog configuré par le client. Les agents de transfert Syslog fonctionnent indépendamment les uns des autres, mais peuvent être gérés ensemble sur l’un des hôtes.

Le redirecteur syslog dans Azure Stack HCI prend en charge différentes configurations selon que le transfert syslog est avec TCP ou UDP, si le chiffrement est activé ou non et s’il existe une authentification unidirectionnelle ou bidirectionnelle.

Pour plus d’informations, consultez Gérer le transfert syslog.

Microsoft Defender pour le cloud (préversion)

Microsoft Defender pour le cloud est une solution de gestion de la posture de sécurité avec des fonctionnalités avancées de protection contre les menaces. Il vous fournit des outils pour évaluer les status de sécurité de votre infrastructure, protéger les charges de travail, déclencher des alertes de sécurité et suivre des recommandations spécifiques pour corriger les attaques et traiter les menaces futures. Il effectue tous ces services à grande vitesse dans le cloud par le biais de l’autoprovisionnement et de la protection avec les services Azure, sans surcharge de déploiement.

Avec le plan Defender pour le cloud de base, vous obtenez des recommandations sur la façon d’améliorer la posture de sécurité de votre système Azure Stack HCI sans coût supplémentaire. Avec le plan Defender pour serveurs payant, vous bénéficiez de fonctionnalités de sécurité renforcées, notamment des alertes de sécurité pour les serveurs individuels et les machines virtuelles Arc.

Pour plus d’informations, consultez Gérer la sécurité du système avec Microsoft Defender pour le cloud (préversion).

Étapes suivantes