Activer les actions de neutralisation des attaques sur AWS avec Microsoft Sentinel (préversion)

Cet article explique comment configurer votre environnement AWS afin que Microsoft Sentinel puissent effectuer des actions automatisées sur un utilisateur qui assume un rôle SAML ou sur un compte AWS IAM lorsqu’une alerte est déclenchée. La perturbation automatique des attaques dans Microsoft Defender XDR utilise des signaux de haute confiance pour contenir les actifs compromis et limiter les dégâts causés par les attaques, y compris les actions sur les identités dans AWS. Avant de commencer, vérifiez que les conditions préalables requises pour AWS et Microsoft Sentinel sont en place.

Prérequis

Avant de commencer, vous avez besoin des prérequis suivants :

  • Vous disposez d’un compte AWS actif avec des privilèges d’administrateur.
  • Votre espace de travail analytique Microsoft Sentinel est connecté au portail unifié des opérations de sécurité.
  • Le AWS Connector pour Microsoft Sentinel est déployé et activé.
  • Les journaux AWS CloudTrail sont ingérés dans Microsoft Sentinel ; voir Connecter Microsoft Sentinel à Amazon Web Services pour ingérer les données des journaux de service AWS.
  • Les rôles et autorisations IAM appropriés sont configurés dans AWS pour permettre aux Microsoft Sentinel d’effectuer des actions sur les comptes IAM.
  • La solution Amazon Web Services est installée depuis Content Hub dans Microsoft Sentinel afin que le connecteur Amazon Web Services S3 apparaisse dans la galerie des connecteurs de données.

Étape 1 : Préparer AWS pour l’intégration

Effectuez les tâches suivantes pour préparer votre environnement AWS pour l’intégration de Microsoft Sentinel.

1.1 Créer un rôle IAM dédié pour Microsoft Sentinel

Créez un rôle IAM dans AWS Management Console.

  1. Sélectionnez le service AWS comme entité approuvée et choisissez EC2 comme espace réservé temporaire. Vous remplacez cette relation d’approbation par le principal de Microsoft Sentinel approprié dans Configurer la relation d’approbation.

  2. Attachez la stratégie IAM suivante au rôle. Cette stratégie accorde Microsoft Sentinel les autorisations nécessaires pour gérer les stratégies d’utilisateur et de rôle IAM pour les actions d’interruption d’attaque. Remplacez <YOUR_ACCOUNT_ID> si nécessaire :

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "iam:GetUserPolicy",
            "iam:DeleteRolePolicy",
            "iam:PutUserPolicy",
            "iam:AttachUserPolicy",
            "iam:ListUserPolicies",
            "iam:PutRolePolicy",
            "iam:GetUser",
            "iam:DetachUserPolicy",
            "iam:GetRolePolicy",
            "iam:DeleteUserPolicy", 
         ],
         "Resource": "*"
        }
      ]
    }
    

1.2 Configurer la relation de confiance

Créez une politique de confiance personnalisée pour le rôle IAM.

Utilisez la stratégie d’approbation suivante, en spécifiant le principal d’intégration Microsoft Sentinel (remplacez par <YOUR_AZURE_SUBSCRIPTION_ID> votre ID d’abonnement Azure réel) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com",
        "AWS": "arn:aws:iam::<YOUR_AZURE_SUBSCRIPTION_ID>:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Étape 2 : Activer CloudTrail

Activez la journalisation CloudTrail dans toutes les régions AWS afin que Microsoft Sentinel puissent recevoir les données d’activité requises.

  1. Dans la console AWS, accédez à CloudTrail.

  2. Vérifiez qu’un CloudTrail est activé et que la journalisation est active pour toutes les régions.

Étape 3 : Déployer et activer le connecteur AWS dans Microsoft Sentinel

Déployez et activez le connecteur de données AWS S3 dans Microsoft Sentinel afin qu’il puisse recevoir des données de journal à partir de votre environnement AWS. Avant de commencer, vérifiez que la solution Amazon Web Services est installée à partir du hub de contenu dans Microsoft Sentinel afin que le connecteur Amazon Web Services S3 apparaisse dans la galerie de connecteurs de données.

  1. Dans le Portail Azure, accédez à Microsoft Sentinel > Connecteurs de données.

  2. Sélectionnez Amazon Web Services S3 dans la galerie de connecteurs de données.

  3. Suivez les instructions de Connect Microsoft Sentinel à Amazon Web Services pour ingérer des données de journal de service AWS pour configurer votre environnement AWS et le connecter à Microsoft Sentinel.

  4. Fournissez l’ARN du rôle IAM et l’URL de file d’attente Amazon SQS qui reçoit les notifications de journal S3 de votre environnement AWS. Ces valeurs sont créées lorsque vous configurez le connecteur en suivant Connect Microsoft Sentinel vers Amazon Web Services pour ingérer les données du journal de service AWS.

Étape 4 : Valider l’intégration

Utilisez les vérifications suivantes pour vérifier que l’intégration du connecteur AWS fonctionne correctement.

  1. Dans Microsoft Sentinel, vérifiez que le connecteur status est Connecté.

  2. Vérifiez l’ingestion des journaux et l’intégrité du connecteur à l’aide de la table de diagnostic SentinelHealth, qui signale l’état d’intégrité du connecteur et de l’ingestion dans votre espace de travail Log Analytics. Vérifiez également l’état de la file d’attente AWS SQS pour vérifier que les notifications de journal sont en cours de traitement.

  3. Dans AWS, vérifiez que les événements CloudTrail et GuardDuty sont envoyés à Microsoft Sentinel.

Étape 5 : Tester l’intégration

Effectuez le test suivant pour vérifier que les actions de réponse aux interruptions d’attaque automatisées fonctionnent comme prévu.

  1. Déclenchez une alerte de test dans AWS (par exemple, compromission simulée des informations d’identification).

  2. Vérifiez que Microsoft Sentinel peut exécuter les actions configurées sur le compte IAM concerné.

  3. Passez en revue les journaux d’audit dans AWS et Microsoft Sentinel pour vérifier la réussite de l’exécution.

Étape 6 : Surveiller et gérer

Utilisez les pratiques suivantes pour surveiller et maintenir l’intégration au fil du temps.

  • Passez régulièrement en revue les autorisations de rôle IAM et les journaux d’audit dans AWS.
  • Mettez à jour Microsoft Sentinel les règles analytiques et les playbooks d’automatisation en fonction des besoins pour refléter les modifications apportées à votre environnement AWS.
  • Surveillez les alertes et les actions de réponse dans le portail Microsoft Sentinel.

Les scripts suivants automatisent le rôle AWS IAM et la configuration du fournisseur OIDC pour intégrer Microsoft Sentinel à AWS afin d’activer l’interruption des attaques :

Le script Bash suivant automatise la configuration du fournisseur AWS OIDC et la création de rôles IAM pour l’intégration de Microsoft Sentinel. Avant de l’exécuter, vérifiez que l’interface CLI AWS est installée et authentifiée avec un compte disposant d’autorisations d’administration IAM. Enregistrez l’extrait de code en tant que fichier bash et exécutez-le.

#!/bin/bash
# AWS Sentinel OIDC Setup Script
# Configures IAM roles and policies for Microsoft Sentinel integration

set -e  # Exit on error

# Color codes for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
NC='\033[0m' # No Color

ms_federated_endpoint="sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d"
actions_audience="api://b7c1e142-0933-4310-ba00-8b28878bfece"
role_name="OIDC_Actions_Sentinel"
policy_name="SentinelActionsPolicy"

# Verify AWS credentials are configured
echo -e "${CYAN}Verifying AWS credentials...${NC}"
if ! account_id=$(aws sts get-caller-identity --query Account --output text 2>&1); then
    echo -e "\n${RED}ERROR: AWS credentials not configured or invalid${NC}"
    echo -e "${RED}Details: $account_id${NC}"
    echo -e "\n${YELLOW}Please authenticate using one of these methods:${NC}"
    echo -e "${YELLOW}  1. Run 'aws configure' to set up credentials${NC}"
    echo -e "${YELLOW}  2. Set AWS environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)${NC}"
    echo -e "${YELLOW}  3. Use 'aws sso login --profile <profile-name>' for SSO${NC}"
    exit 1
fi
echo -e "${GREEN}✓ AWS authenticated (Account: $account_id)${NC}"
trust_policy_document=$(cat << EOM
{
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::$account_id:oidc-provider/$ms_federated_endpoint/"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "$ms_federated_endpoint/:aud": "$actions_audience",
                    "sts:RoleSessionName": "MicrosoftSentinel_$account_id"
                }
            }
        }
    ]
}
EOM
)
permissions_policy_document=$(cat << EOM
{
  "Statement": [
    {
      "Sid": "SentinelActionsPermissions",
      "Effect": "Allow",
      "Action": [
        "iam:GetUserPolicy",
        "iam:DeleteRolePolicy",
        "iam:PutUserPolicy",
        "iam:AttachUserPolicy",
        "iam:ListUserPolicies",
        "iam:PutRolePolicy",
        "iam:GetUser",
        "iam:DetachUserPolicy",
        "iam:GetRolePolicy",
        "iam:DeleteUserPolicy",
        "s3:PutBucketPublicAccessBlock"
      ],
      "Resource": "*"
    }
  ]
}
EOM
)

aws iam add-client-id-to-open-id-connect-provider --open-id-connect-provider-arn arn:aws:iam::$account_id:oidc-provider/$ms_federated_endpoint/ --client-id $actions_audience
aws iam create-role --role-name $role_name --assume-role-policy-document "$trust_policy_document" || aws iam update-assume-role-policy --role-name $role_name --policy-document "$trust_policy_document"
aws iam put-role-policy --role-name $role_name --policy-name $policy_name --policy-document "$permissions_policy_document"