Protéger vos ressources Azure contre des cyberattaques destructrices
Cet article fournit des étapes pour appliquer les principes de Confiance Zéro afin de protéger vos ressources Microsoft Azure contre les cyberattaques destructrices. Vous pouvez y parvenir de la manière suivante :
Principe de Confiance Zéro | Définition |
---|---|
Vérifier explicitement | Toujours s'authentifier et autoriser en fonction de tous les points de données disponibles. |
Utiliser le droit d'accès minimal | Limitez l'accès utilisateur avec l'accès juste-à-temps et juste suffisant (JIT/JEA), des stratégies adaptatives basées sur les risques et une protection des données. |
Supposer une violation | Réduisez le rayon d'explosion et segmentez l'accès. Vérifiez le chiffrement de bout en bout et utilisez l’analyse pour obtenir une visibilité, détecter les menaces et améliorer les défenses. Améliorez les défenses avec les verrous de ressources, la sauvegarde et la récupération d’urgence pour les machines virtuelles, les services de protection et de disponibilité des données, ainsi que la protection de votre infrastructure de récupération, les services basés sur la configuration, ainsi que l’automatisation de plateforme et d’outils DevOps. Pour la détection des menaces, utilisez Microsoft Sentinel et la détection multi-étage avancée, tout en préparant vos plans de réponse aux incidents pour les ressources Azure. |
Cet article contient un aide sur la procédure pour :
- Protéger vos ressources Microsoft Azure contre des cyberattaques destructrices.
- Détecter les cyberattaques lorsqu’elles surviennent.
- Comment y répondre.
Cet article est destiné à permettre aux implémenteurs techniques de prendre en charge le scénario d’entreprise de Confiance Zéro pour Implémenter la prévention des violations de sécurité et de récupération.
Architecture de référence
La figure suivante montre l’architecture de référence pour cet aide de Confiance Zéro avec des regroupements pour chaque catégorie de protection.
Cet environnement Azure comprend :
Composant | Description |
---|---|
A | Des machines virtuelles et leurs fichiers |
G | Des services de données et leurs données |
C | Infrastructure de récupération, y compris les fichiers, les modèles et les scripts d’automatisation |
D | Services basés sur la configuration |
E | Automatisation de plateforme et outils DevOps (non affichés) |
Les tâches de protection de chaque type de ressource sont décrites en détail à l’Étape 1 de cet article.
Que contient cet article ?
Cet article décrit les étapes à suivre pour appliquer les principes de Confiance Zéro dans l'architecture de référence.
Step | Task |
---|---|
1 | Configurez la protection contre les cyberattaques. |
2 | Configurez la détection des cyberattaques. |
3 | Préparez vos plans de réponse aux incidents. |
Étape 1 : Configurer la protection contre les cyberattaques
De nombreuses organisations implémentent des solutions de sauvegarde et de récupération d’urgence pour leurs machines virtuelles Azure dans le cadre d’un effort de migration. Par exemple, vous pouvez utiliser des solutions natives Azure ou choisir d’utiliser vos propres solutions pour votre écosystème cloud.
Bien que la protection des machines virtuelles, de leurs applications et de leurs données soit importante, il est également essentiel d’étendre l’étendue de la protection au-delà des machines virtuelles. Cette section fournit une répartition des considérations et des recommandations sur la façon de protéger différents types de ressources (dans Azure) contre une cyber-attaque destructrice.
En plus des considérations spécifiques au service, vous devez envisager l’utilisation des Verrous de ressources pour empêcher la suppression des services en protégeant leur plan de gestion. Vous pouvez également utiliser des verrous de ressources pour afficher les ressources en lecture seule. Les verrous de ressources fonctionnent avec un accès contrôlé pour réduire le risque de destruction des ressources Azure lors d’une cyberattaque en empêchant leur modification ou leur destruction.
Pour empêcher la production de résultats inattendus par les verrous de ressources, vous devez passer en revue les considérations avant d’appliquer vos verrous pour vous assurer d’appliquer les verrous aux ressources appropriées d’une manière qui leur permet toujours de fonctionner. Par exemple, le verrouillage d’un réseau virtuel (VNet) plutôt qu’un groupe de ressources entier peut empêcher le verrou d’être trop restrictif envers d’autres ressources au sein du groupe de ressources. En raison de ces considérations, vous devez classer par ordre de priorité les ressources qui, si elles ont été modifiées ou supprimées, peuvent entraîner la plus grande perturbation.
Les verrous peuvent également prendre en compte les objectifs de temps de récupération pour les charges de travail basculées. Votre plan de récupération d’urgence doit prendre en compte les verrous et vous devez disposer d’une procédure testée pour une suppression contrôlée des verrous. Vous devez former vos administrateurs et l’équipe SecOps sur la gestion des verrous dans le cadre des opérations quotidiennes et des scénarios d’urgence.
Les administrateurs disposant d’un accès pour supprimer les verrous doivent être limités et ils doivent impliquer un accès JIT tel que fourni avec Microsoft Entra Privileged Identity Management. L’accès aux verrous de modification des ressources est contrôlé avec l’étendue Microsoft.Authorization/locks/* et ne doit pas être accordé dans le cadre d’un accès permanent.
A. Protection des machines virtuelles
Pour les charges de travail basées sur les machines virtuelles ( notamment les groupes identiques et les clusters Kubernetes), vous devez planifier deux couches de protection en plus de l’utilisation de verrous de ressources dans le plan de gestion.
Vous devez au préalable planifier la sauvegarde des données à partir des machines virtuelles afin de pouvoir restaurer des données perdues si une attaque se produit, ce qui comprend Azure Kubernetes Service (AKS). Vous devez également protéger les données sauvegardées contre les attaques au moyen des contrôles de la suppression réversible. Pour obtenir des informations sur la configuration des sauvegardes, consultez l’article :
- Créer et configurer un coffre Recovery Services
- Sauvegarder une machine virtuelle dans Azure
- Configurer une sauvegarde pour un cluster Azure Container Service
- Sauvegarde et récupération pour AKS
- Plan de sauvegarde et de restauration pour la protection contre le rançongiciel
- Suppression réversible pour la Sauvegarde Azure
Vous devez ensuite planifier la possibilité de restaurer un serveur dans un nouvel emplacement lorsque l’infrastructure sous-jacente de votre région est attaquée. Pour plus d’informations sur la configuration de la réplication sur des machines virtuelles, consultez Configurer la récupération d’urgence pour les machines virtuelles Azure. Cela inclut la configuration des applications et des paramètres pour les ressources utilisées pendant le basculement.
Important
Lorsque vous utilisez Azure Site Recovery pour des machines virtuelles faisant partie d’un groupe de machines virtuelles identiques, vous pouvez répliquer l’état de la machine virtuelle. Toutefois, les appareils répliqués ne prennent pas en charge la mise à l’échelle.
Pour certaines charges de travail basées sur les machines virtuelles (telles que les clusters Kubernetes), l’état réel des serveurs ne peut pas être répliqué au travers d’Azure Site Recovery. Vous avez peut-être besoin d’autres solutions comme la configuration active/passive.
B. Protection des services de données
Les services de données sont une collection informelle de services contenant des données essentielles pour les opérations, mais la ressource elle-même n’est pas aussi importante. Par exemple, il existe peu de différences entre deux comptes de stockage configurés de la même façon et hébergeant les mêmes données.
Les services de données sont différents des machines virtuelles qui peuvent avoir des configurations de système d’exploitation distinctes des applications exécutées et séparées de la configuration du plan de gestion. Par conséquent, ces services :
- Contiennent souvent leurs propres outils de basculement, dont la capacité de réplication dans une autre région d’un compte de stockage dans le cadre des niveaux de stockage géoredondant (GRS).
- Prennent en compte leurs propres considérations sur la façon de protéger les données contre les attaques et de les rendre à nouveau disponibles en cas d’attaque.
Le tableau suivant fournit des références sur la disponibilité et la protection des données pour les services couramment utilisés, mais vous devez examiner la documentation sur le produit de chaque service pour comprendre les options disponibles.
Avertissement
Certains scénarios de récupération du compte de stockage ne sont pas pris en charge. Pour plus d’informations, consultez Récupération de stockage non prise en charge.
C. Protection de l’infrastructure de récupération
Outre la protection des ressources sur vos charges de travail, vous devez également protéger les ressources utilisées pour restaurer des fonctionnalités après une interruption, comme la documentation sur les procédures de récupération, mais aussi les scripts de configuration et les modèles. Si des attaquants peuvent cibler et perturber votre infrastructure de récupération, votre environnement entier peut être compromis, entraînant des retards considérables dans la récupération de l’attaque et laissant votre organisation vulnérable aux scénarios de rançongiciel.
Pour les données protégées par Sauvegarde Azure, l’utilisation de la suppression réversible pour la sauvegarde Azure vous permet de récupérer des données de sauvegarde (même si elles sont supprimées). En outre, la suppression réversible améliorée applique l’affectation de la suppression réversible et vous permet de définir une période de rétention.
Pour améliorer la sécurité, implémentez l’autorisation multi-utilisateur (MUA) pour les opérations critiques, ce qui nécessite l’approbation des opérations critiques par deux utilisateurs avant leur exécution. Cela ajoute une couche de sécurité supplémentaire en s’assurant qu’aucun utilisateur unique (et par conséquent un attaquant avec un seul compte d’utilisateur) ne peut compromettre l’intégrité de la sauvegarde. Activez et configurez MUA pour protéger vos stratégies de sauvegarde contre des modifications et des suppressions non autorisées.
Vous pouvez protéger Azure Site Recovery avec des verrous de ressources et un accès JEA/JIT pour empêcher une détection ou un accès non autorisés lorsque des ressources sont à risque.
Lors de la réplication de machines virtuelles au moyen d’un Azure Site Recovery chiffrées avec Azure Disk Encryption (ADE) ou des clés gérées par le client (CMK), vérifiez que les clés de chiffrement sont stockées dans Azure Key Vault pour la région cible. Le stockage des clés dans la région cible facilite l’accès transparent aux clés après le basculement, tout en maintenant la continuité de la sécurité des données. Pour protéger Azure Key Vault contre les cyberattaques destructrices, activez des fonctionnalités de détection avancée des menaces telles que la suppression réversible et la protection contre la suppression définitive.
Pour obtenir une aide sur la réplication pas à pas pour les machines virtuelles chiffrées, consultez les éléments suivants :
- Réplication des machines virtuelles protégées par ADE
- Réplication de machines virtuelles avec des disques CMK
D. Protection des services basés sur la configuration
Les services basés sur la configuration sont des services Azure sans données en dehors de leur configuration dans le plan de gestion. Ces ressources sont généralement basées sur l’infrastructure. Ce sont également des services de base qui prennent en charge les charges de travail. Par exemple, les réseaux virtuels, les équilibreurs de charge, les passerelles réseau et les passerelles d’application.
Ces services étant sans état, il n’existe aucune donnée d’exploitation à protéger. La meilleure option pour protéger ces services consiste à avoir des modèles de déploiement d’Infrastructure en tant que code (IaC) (comme Bicep) qui peuvent restaurer l’état de ces services après une attaque destructrice. Vous pouvez également utiliser des scripts pour les déploiements, mais les déploiements IaC fonctionnent mieux pour restaurer des fonctionnalités dans un environnement existant dans lequel seuls quelques services sont affectés.
Tant qu’une ressource configurée de cette façon peut être déployée, les services peuvent continuer à fonctionner. Au lieu d’essayer de sauvegarder et de gérer des copies de ces ressources, vous pouvez utiliser le déploiement par programmation pour récupérer à partir d’une attaque.
Pour plus d’informations sur l’utilisation d’une IaC, consultez Recommandations relatives à l’utilisation de l’infrastructure en tant que code.
E. Protection de l’automatisation de plateforme et outils DevOps
Si vous utilisez des déploiements par programmation ou d’autres types d’automatisation, les ressources d’automatisation de plateforme et d’outils DevOps doivent également être sécurisées. Pour obtenir des exemples de protection de votre infrastructure de déploiement, consultez Sécurisation des pipelines CI/CD DevOps et Recommandations pour la sécurisation d’un cycle de vie de développement.
Toutefois, vous devez également planifier la protection du code lui-même, lequel varie en fonction des outils de contrôle du code source utilisés. Par exemple, GitHub contient des instructions pour la Sauvegarde d’un référentiel pour vos référentiels de code source.
Vous devez également passer en revue vos services spécifiques pour déterminer comment mieux protéger votre code source et vos pipelines contre les attaques et les destructions.
Pour les composants comme les agents de build hébergés sur des machines virtuelles, vous pouvez utiliser le plan de protection approprié basé sur des machines virtuelles pour vous assurer que vos agents sont disponibles si nécessaire.
Étape 2 : configurez la détection des cyberattaques
Pour la détection des attaques sur votre infrastructure Azure, commencez par Microsoft Defender pour le cloud, une plateforme de protection des applications native cloud (CNAPP) composée de mesures et de pratiques de sécurité conçues pour protéger les applications cloud contre diverses cyberattaques et vulnérabilités.
Defender pour le cloud, conjointement aux plans supplémentaires pour les composants Azure, collecte les signaux des composants Azure et fournit des protections spécifiques pour les serveurs, les conteneurs, le stockage, les bases de données et autres charges de travail.
Le diagramme suivant montre le flux d’informations sur les événements de sécurité provenant des services Azure au travers de Defender pour le cloud et Microsoft Sentinel.
Dans la figure :
- Les services Azure envoient des signaux à Microsoft Defender pour le cloud.
- Microsoft Defender pour le cloud, avec des plans supplémentaires tels que Defender pour serveurs, analyse les signaux pour la détection améliorée des menaces et envoie des données de la Gestion des informations et des événements de sécurité (SIEM) à Microsoft Sentinel.
- Microsoft Sentinel utilise les données SIEM pour la détection, l’investigation, la réponse et le repérage proactif.
Une fois vos ressources Azure mieux protégées avec les recommandations de l’Étape 1 de cet article, vous devez disposer d’un plan pour détecter les cyberattaques destructrices à l’aide de Microsoft Sentinel. Un point de départ consiste à utiliser la Détection avancée des attaques multi-étages dans Microsoft Sentinel. Cela vous permet de créer des détections de build pour des scénarios spécifiques tels que la destruction des données, le déni de service, une activité administrative malveillante, etc.
Dans le cadre de la préparation de vos charges de travail pour la réponse, vous devez :
- Déterminer de quelle manière vous allez déterminer si une ressource est attaquée.
- Déterminer comment capturer et déclencher un incident en tant que résultat.
Étape 3 : préparer vos plans de réponse aux incidents
Vous devez disposer de plans de réponse aux incidents bien définis et prêts à être mis en œuvre pour les cyberattaques destructrices avant la survenue des incidents. Pendant un incident, vous n’allez pas avoir le temps de déterminer comment contrecarrer les attaques en cours ou restaurer des données et des services endommagés.
Les applications Azure et les services partagés doivent tous disposer de plans de réponse et de récupération qui comprennent des playbooks pour restaurer des machines virtuelles, des services de données, des services de configuration et des services d’automatisation/DevOps. Chaque application ou zone de service doit disposer de ses définitions et ses dépendances bien définies.
Vos playbooks doivent :
Inclure vos processus pour les scénarios suivants :
- Basculer des machines virtuelles Azure vers une région secondaire
- Comment restaurer des données d’une machine virtuelle Azure dans le Portail Azure
- Restaurer des fichiers sur une machine virtuelle dans Azure
- Récupérer des données supprimées de manière réversible et des points de récupération à l’aide de la suppression réversible améliorée dans Sauvegarde Azure
- Restaurer l’état des clusters Kubernetes après un sinistre
- récupérer un compte de stockage supprimé
- Récupérer un coffre de clés supprimé de manière réversible
- Récupérer les secrets, les clés et les certificats supprimés de manière réversible à partir d’un coffre de clés
- Aide sur la récupération d’urgence pour Azure SQL Database
Inclure le processus de restauration pour toutes les autres ressources composant ce service.
Être testés régulièrement dans le cadre de vos processus de maintenance SecOps.
Entraînement recommandé
- Implémenter Privileged Identity Management
- Concevoir une solution de sauvegarde et de récupération d’urgence
- Améliorer votre posture de sécurité cloud avec Microsoft Defender pour le cloud
- Créer des détections et effectuer des enquêtes à l’aide de Microsoft Sentinel
Étapes suivantes
Poursuivre l’implémentation de votre Infrastructure de prévention des violations de sécurité et de récupération.
Références
Reportez-vous à ces liens pour en savoir plus sur les différents services et technologies mentionnés dans cet article.