Examiner les menaces de conteneur et y répondre dans le portail Microsoft Defender
Importante
Certaines informations contenues dans cet article concernent un produit pré-publié, qui peut être considérablement modifié avant sa commercialisation. Microsoft n’offre aucune garantie expresse ou implicite en ce qui concerne les informations fournies ici
Les opérations de sécurité peuvent désormais examiner et répondre aux alertes liées aux conteneurs en quasi-temps réel, et rechercher les activités associées avec l’intégration d’actions de réponse natives cloud et de journaux d’investigation dans le portail Microsoft Defender. La disponibilité des chemins d’attaque peut également aider les analystes à examiner et à résoudre immédiatement les problèmes de sécurité critiques afin d’éviter une violation potentielle.
Comme les organisations utilisent des conteneurs et Kubernetes sur des plateformes telles que Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) et Amazon Elastic Kubernetes Service (EKS), la surface d’attaque s’étend, ce qui augmente les défis de sécurité. Les conteneurs peuvent également être ciblés par des acteurs de menace et utilisés à des fins malveillantes.
Les analystes soc (Security Operations Center) peuvent désormais facilement suivre les menaces de conteneur avec des alertes en quasi-temps réel et répondre immédiatement à ces menaces en isolant ou en mettant fin aux pods de conteneur. Cette intégration permet aux analystes d’atténuer instantanément une attaque de conteneur à partir de leur environnement en un clic.
Les analystes peuvent ensuite examiner l’étendue complète de l’attaque avec la possibilité de rechercher des activités connexes dans le graphique d’incident. Ils peuvent également appliquer des actions préventives avec la disponibilité des chemins d’attaque potentiels dans le graphique des incidents. L’utilisation des informations des chemins d’attaque permet aux équipes de sécurité d’inspecter les chemins d’accès et d’empêcher les violations possibles. En outre, des rapports d’analyse des menaces spécifiques aux menaces et aux attaques de conteneur sont disponibles pour permettre aux analystes d’obtenir plus d’informations et d’appliquer des recommandations pour la réponse et la prévention des attaques de conteneur.
Configuration requise
Les utilisateurs sur les plateformes AKS, EKS et GKE peuvent tirer parti des actions de réponse cloud, des journaux d’investigation liés au cloud et des chemins d’attaque dans le portail Microsoft Defender avec les licences suivantes :
| Licence requise | Actions |
|---|---|
| Microsoft Defender pour conteneurs | Afficher les alertes liées aux conteneurs Afficher les données liées au conteneur pour une investigation dans la chasse avancée Isoler le pod Terminate pod |
| Microsoft Defender pour la gestion de la posture de sécurité cloud | Afficher les chemins d’attaque dans le graphique des incidents |
| Sécurité Microsoft Copilot | Afficher et appliquer des réponses guidées pour examiner et corriger les menaces de conteneur |
Les Microsoft Defender suivantes pour les conteneurs sont requises pour les actions de réponse cloud dans le portail Microsoft Defender :
- Capteur Defender
- Accès à l’API Kubernetes
Pour plus d’informations sur ces composants, consultez Configurer des composants Microsoft Defender pour conteneurs.
Configuration requise pour la stratégie réseau
L’action isoler la réponse du pod prend en charge le cluster Kubernetes version 1.27 et ultérieure. Les plug-ins réseau suivants sont également requis :
| Plug-in réseau | Version minimale requise |
|---|---|
| Azure-NPM | 1.5.34 |
| Calicot | 3.24.1 |
| Cil | 1.13.1 |
| Nœud AWS | 1.15.1 |
L’action isoler la réponse de pod nécessite un application de stratégie réseau pour votre cluster Kubernetes. La documentation suivante fournit des étapes spécifiques pour installer et case activée des stratégies réseau en fonction de votre plateforme :
- Azure Kubernetes Service : Sécuriser le trafic entre les pods à l’aide de stratégies réseau dans AKS
- Moteur Google Kubernetes : contrôler la communication entre les pods et les services à l’aide de stratégies réseau
- Amazon Kubernetes Engine : Limiter le trafic des pods avec des stratégies réseau Kubernetes
Pour vérifier que vos plug-ins réseau sont pris en charge, suivez les étapes pour accéder aux Cloud Shell de votre plateforme et case activée vos plug-ins réseau dans la section Résoudre les problèmes.
L’action de réponse d’arrêt du pod fonctionne indépendamment de la présence d’une stratégie réseau.
Autorisations
Pour effectuer l’une des actions de réponse, les utilisateurs doivent disposer des autorisations suivantes pour Microsoft Defender pour le cloud dans le Microsoft Defender XDR contrôle d’accès en fonction du rôle unifié :
| Nom de l’autorisation | Level |
|---|---|
| Alertes | Gestion |
| Réponse | Gestion |
Pour plus d’informations sur ces autorisations, consultez Autorisations dans Microsoft Defender XDR contrôle d’accès en fonction du rôle unifié (RBAC).
Examiner les menaces de conteneur
Pour examiner les menaces de conteneur dans le portail Microsoft Defender :
- Sélectionnez Investigation & response > Incidents et alertes dans le menu de navigation de gauche pour ouvrir les files d’attente d’incidents ou d’alertes.
- Dans la file d’attente, sélectionnez Filtrer et choisissez Microsoft Defender pour cloud > Microsoft Defender pour conteneurs sous Source de service.
- Dans le graphique d’incident, sélectionnez l’entité pod/service/cluster que vous devez examiner. Sélectionnez Détails du service Kubernetes, Détails du pod Kubernetes, Détails du cluster Kubernetes ou Détails du registre de conteneurs pour afficher les informations pertinentes sur le service, le pod ou le registre.
À l’aide des rapports d’analyse des menaces, les analystes peuvent utiliser le renseignement sur les menaces des chercheurs en sécurité Microsoft experts pour en savoir plus sur les acteurs et les campagnes de menaces actifs qui exploitent des conteneurs, les nouvelles techniques d’attaque susceptibles d’affecter les conteneurs et les menaces courantes qui affectent les conteneurs.
Accédez aux rapports d’analyse des menaces à partir de Renseignement sur les menaces > Analyse des menaces. Vous pouvez également ouvrir un rapport spécifique à partir de la page d’incident en sélectionnant Afficher le rapport d’analyse des menaces sous Menaces associées dans le volet latéral de l’incident.
Les rapports d’analyse des menaces contiennent également des méthodes d’atténuation, de récupération et de prévention pertinentes que les analystes peuvent évaluer et appliquer à leur environnement. L’utilisation des informations dans les rapports d’analyse des menaces permet aux équipes SOC de défendre et de protéger leur environnement contre les attaques de conteneurs. Voici un exemple de rapport d’analyste sur une attaque de conteneur.
Répondre aux menaces de conteneur
Vous pouvez isoler ou arrêter un pod une fois que vous avez déterminé qu’un pod est compromis ou malveillant. Dans le graphique d’incident, sélectionnez le pod, puis accédez à Actions pour afficher les actions de réponse disponibles. Vous pouvez également trouver ces actions de réponse dans le volet latéral de l’entité.
Vous pouvez libérer un pod de l’isolation avec l’action release from isolation une fois votre investigation terminée. Cette option apparaît dans le volet latéral pour les pods isolés.
Les détails de toutes les actions de réponse peuvent être consultés dans le Centre de notifications. Dans la page Centre de notifications, sélectionnez l’action de réponse que vous souhaitez inspecter pour afficher plus d’informations sur l’action, comme l’entité sur laquelle l’action a été effectuée, la date à laquelle l’action a été effectuée et afficher les commentaires sur l’action. Pour les pods isolés, la libération de l’action d’isolation est également disponible dans le volet d’informations du centre de notifications.
Rechercher les activités liées aux conteneurs
Pour déterminer l’étendue complète d’une attaque de conteneur, vous pouvez approfondir votre investigation avec l’action De chasse Go disponible dans le graphique d’incident. Vous pouvez afficher immédiatement tous les événements et activités de processus liés aux incidents liés aux conteneurs à partir du graphique des incidents.
Dans la page Repérage avancé , vous pouvez étendre votre recherche d’activités liées aux conteneurs à l’aide des tables CloudProcessEvents et CloudAuditEvents .
La table CloudProcessEvents contient des informations sur les événements de processus dans les environnements hébergés multicloud, tels que Azure Kubernetes Service, Amazon Elastic Kubernetes Service et Google Kubernetes Engine.
La table CloudAuditEvents contient des événements d’audit cloud provenant de plateformes cloud protégées par Microsoft Defender pour le cloud. Il contient également des journaux Kubeaudit, qui contiennent des informations sur les événements liés à Kubernetes.
Résoudre des problèmes
La section suivante traite des problèmes que vous pouvez rencontrer lors de l’examen et de la réponse aux menaces de conteneur.
L’action isoler le pod n’est pas disponible
Si l’action Isoler le pod est grisée, vous devez vérifier que vous disposez des autorisations nécessaires pour effectuer cette action. Reportez-vous à la section Autorisations pour case activée et vérifier que vous disposez des autorisations appropriées.
Pour plus d’informations, consultez Autorisations dans Microsoft Defender XDR contrôle d’accès en fonction du rôle (RBAC) unifié.
Échec de l’action isoler le pod
- Vérifiez la version du cluster Kubernetes. L’action isoler le pod prend en charge les clusters Kubernetes à partir de la version 1.27 et des versions ultérieures.
- Vérifiez que vous utilisez les plug-ins réseau requis et qu’ils correspondent aux versions minimales prises en charge. Pour case activée vos plug-ins, accédez aux Cloud Shell dans votre plateforme et exécutez la commande pour case activée vos plug-ins réseau.
- Vérifiez que le pod cible est dans un état valide ou actif.
Découvrez comment accéder aux Cloud Shell et case activée vos plug-ins réseau en procédant comme suit en fonction de votre plateforme :
Sur Microsoft Azure
Connectez-vous au Portail Azure puis accédez à votre cluster.
Au-dessus des informations essentielles , sélectionnez le bouton Se connecter et suivez les instructions.
Le Cloud Shell s’ouvre en bas de votre navigateur. Dans l’interface de ligne de commande, exécutez la commande suivante pour case activée vos plug-ins réseau :
kubectl get pods --all-namespaces -o json | jq -r '.items[].metadata.labels["k8s-app"]' | uniq | grep -E 'azure-npm|calico-node|cilium|aws-node' | head -n 1
Les résultats doivent mention l’un des plug-ins spécifiés dans l’exigence de stratégie réseau. Une ligne vide signifie que le plug-in pris en charge n’est pas installé.
Sur Google Cloud Platform
Accédez à votre cluster dans le portail Google Cloud.
Sélectionnez Se connecter au-dessus du nom du cluster. Dans la petite fenêtre qui s’affiche, copiez la commande suivante et exécutez-la dans votre terminal local.
kubectl get pods --all-namespaces -o json | jq -r '.items[].metadata.labels["k8s-app"]' | uniq | grep -E 'azure-npm|calico-node|cilium|aws-node' | head -n 1
Vous pouvez également choisir Exécuter dans Cloud Shell pour exécuter une session shell qui s’ouvre en bas de votre navigateur. Vous pouvez copier la commande dans l’interface pour case activée vos plug-ins réseau.
Les résultats doivent mention l’un des plug-ins spécifiés dans l’exigence de stratégie réseau. Une ligne vide signifie que le plug-in pris en charge n’est pas installé.
Sur Amazon Web Services
Accédez à votre cluster dans AWS Cloud Portal.
Sélectionnez CloudShell en haut à droite. Une session Cloud Shell s’ouvre en bas de votre navigateur, qui fournit une interface de ligne de commande pour gérer vos ressources AWS.
Connectez-vous à votre cluster en exécutant la commande suivante :
aws eks --region <cluster region> update-kubeconfig --name cluster <name>**
Remarque
Vérifiez que le nœud aws est supprimé ou désactivé pour les plug-ins Calico et Cilium.
Échec de l’action d’arrêt du pod
Vous devez vérifier que l’état du pod cible est actif ou valide. Pour case activée si le pod est actif, exécutez la commande suivante dans le Cloud Shell :
kubectl get pod-name <>