Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Réponse aux incidents et criminalistique

Votre capacité à réagir rapidement à un incident peut contribuer à minimiser les dommages causés par une violation. Disposer d'un système d'alerte fiable capable de vous avertir d'un comportement suspect est la première étape d'un bon plan de réponse aux incidents. En cas d'incident, vous devez rapidement décider s'il faut détruire et remplacer le contenant endommagé ou isoler et inspecter le contenant. Si vous choisissez d'isoler le conteneur dans le cadre d'une enquête médico-légale et d'une analyse des causes profondes, les activités suivantes doivent être suivies :

Exemple de plan de réponse aux incidents

Identifiez le Pod et le nœud de travail incriminés

La première chose à faire est d'isoler les dégâts. Commencez par identifier l'endroit où la faille s'est produite et isolez ce Pod et son nœud du reste de l'infrastructure.

Identifiez les pods et les nœuds de travail incriminés à l'aide du nom de la charge de travail

Si vous connaissez le nom et l'espace de noms du pod incriminé, vous pouvez identifier le nœud de travail qui exécute le pod comme suit :

kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

Si une ressource de charge de travail telle qu'un déploiement a été compromise, il est probable que tous les modules qui font partie de la ressource de charge de travail soient compromis. Utilisez la commande suivante pour répertorier tous les pods de la ressource de charge de travail et les nœuds sur lesquels ils s'exécutent :

selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'

La commande ci-dessus concerne les déploiements. Vous pouvez exécuter la même commande pour d'autres ressources de charge de travail telles que les replicasets, les statefulsets, etc.

Identifiez les Pods et les nœuds de travail incriminés à l'aide du nom du compte de service

Dans certains cas, vous pouvez identifier qu'un compte de service est compromis. Il est probable que les pods utilisant le compte de service identifié soient compromis. Vous pouvez identifier tous les pods à l'aide du compte de service et des nœuds sur lesquels ils s'exécutent à l'aide de la commande suivante :

kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'

Identifiez les pods contenant des images et des nœuds de travail vulnérables ou compromis

Dans certains cas, vous pouvez découvrir qu'une image de conteneur utilisée dans les pods de votre cluster est malveillante ou compromise. Une image de conteneur est malveillante ou compromise s'il s'avère qu'elle contient un logiciel malveillant, s'il s'agit d'une image défectueuse connue ou si elle contient un CVE qui a été exploité. Vous devez considérer que tous les pods utilisant l'image du conteneur sont compromis. Vous pouvez identifier les pods à l'aide de l'image et des nœuds sur lesquels ils s'exécutent à l'aide de la commande suivante :

IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

Isolez le pod en créant une politique réseau qui refuse tout trafic entrant et sortant vers le pod

Une règle interdisant tout le trafic peut aider à stopper une attaque déjà en cours en interrompant toutes les connexions au pod. La politique réseau suivante s'appliquera à un module portant l'étiquetteapp=web.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress

Révoquez les informations d'identification de sécurité temporaires attribuées au pod ou au nœud de travail si nécessaire

Si le nœud de travail s'est vu attribuer un rôle IAM qui permet aux pods d'accéder à d'autres ressources AWS, supprimez ces rôles de l'instance pour éviter de nouveaux dommages dus à l'attaque. De même, si un rôle IAM a été attribué au pod, déterminez si vous pouvez supprimer les politiques IAM du rôle en toute sécurité sans affecter les autres charges de travail.

Bouclez le nœud de travail

En bouclant le nœud de travail concerné, vous informez le planificateur d'éviter de planifier des pods sur le nœud concerné. Cela vous permettra de supprimer le nœud pour une étude médico-légale sans perturber les autres charges de travail.

Activez la protection contre la résiliation sur le nœud de travail concerné

Un attaquant peut tenter d'effacer ses méfaits en mettant fin à un nœud affecté. L'activation de la protection contre les interruptions de service peut empêcher que cela ne se produise. La protection contre le scale-in de l'instance protégera le nœud contre un événement de scale-in.

Étiquetez l'infraction Pod/Node avec une étiquette indiquant qu'elle fait partie d'une enquête en cours

Cela servira d'avertissement aux administrateurs du cluster pour qu'ils ne manipulent pas les personnes concernées Pods/Nodes tant que l'enquête n'est pas terminée.

Capturez les artefacts volatils sur le nœud de travail

Redéployer un pod ou une ressource de charge de travail compromis

Une fois que vous avez collecté des données à des fins d'analyse forensique, vous pouvez redéployer le module ou la ressource de charge de travail compromis.

Déployez d'abord le correctif pour la vulnérabilité qui a été compromise et lancez de nouveaux modules de remplacement. Supprimez ensuite les pods vulnérables.

Si les pods vulnérables sont gérés par une ressource de charge de travail Kubernetes de niveau supérieur (par exemple, un déploiement ou DaemonSet), leur suppression en planifiera de nouveaux. Les pods vulnérables seront donc à nouveau lancés. Dans ce cas, vous devez déployer une nouvelle ressource de charge de travail de remplacement après avoir corrigé la vulnérabilité. Vous devez ensuite supprimer la charge de travail vulnérable.

Recommandations

Consultez le livre blanc AWS Security Incident Response

Bien que cette section donne un bref aperçu ainsi que quelques recommandations pour traiter les failles de sécurité présumées, le sujet est traité de manière exhaustive dans le livre blanc AWS Security Incident Response.

Pratiquez des journées de jeux de sécurité

Divisez vos professionnels de la sécurité en deux équipes : rouge et bleue. L'équipe rouge se concentrera sur l'analyse des vulnérabilités des différents systèmes, tandis que l'équipe bleue sera chargée de les combattre. Si vous ne disposez pas de suffisamment de professionnels de la sécurité pour créer des équipes distinctes, envisagez de faire appel à une entité externe qui connaît les exploits de Kubernetes.

Kubesploit est un framework de tests d'intrusion CyberArk que vous pouvez utiliser pour organiser des journées de jeu. Contrairement à d'autres outils qui analysent les vulnérabilités de votre cluster, kubesploit simule une attaque réelle. Cela donne à votre équipe bleue l'occasion de s'entraîner à réagir à une attaque et d'évaluer son efficacité.

Exécutez des tests d'intrusion sur votre cluster

Attaquer régulièrement votre propre cluster peut vous aider à découvrir des vulnérabilités et des erreurs de configuration. Avant de commencer, suivez les directives relatives aux tests d'intrusion avant d'effectuer un test sur votre cluster.

Outils et ressources