View a markdown version of this page

Mettre à jour la solution - Réponse de sécurité automatisée sur AWS
Mise à niveau depuis des versions antérieures à la version 1.4Mise à niveau depuis la version 1.4 et les versions ultérieuresMise à niveau depuis la version 2.0.xMise à niveau depuis la version 2.1.4 ou une version antérieureMise à niveau de la version 2.x vers la version 4.0.0 ou ultérieure

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.

Mettre à jour la solution

Important

  • Mise à niveau vers la version 4.0.0 ou ultérieure : la solution conserve vos paramètres de correction automatique existants tout au long de la mise à niveau. Si vous effectuez une mise à niveau depuis la version 2.x, la solution migre automatiquement les paramètres de correction automatique de vos EventBridge règles v2 vers la nouvelle DynamoDB-backed configuration lors de la mise à jour de la pile. Les contrôles pour lesquels la correction automatique était activée dans la v2 restent activés dans la v4, et les contrôles sans équivalent v3+ sont ignorés et répertoriés dans les journaux Amazon de la fonction de migration AWS Lambda. CloudWatch Si vous effectuez une mise à niveau depuis la version 3.x, vos paramètres de correction automatique se trouvent déjà dans la DynamoDB-backed configuration et restent inchangés. Aucune migration n'est donc requise. Si la migration rencontre un échec par contrôle ou s'arrête avant que les contrôles ne soient écrits, la fonction SO0111-ASR-MigrationAutoRemediation Lambda publie une notification Amazon SNS sur l'existant. SO0111-ASR_Topic Pour recevoir cette notification, vous devez avoir un abonnement confirmé SO0111-ASR_Topic avant de commencer la mise à jour de la pile v4. Reportez-vous à la section Mise à niveau de la version 2.x vers la version 4.0.0 ou ultérieure.

  • Mise à niveau vers la version 3.x depuis la version 2.x : règles de correction Re-enable automatisées manuellement dans le compte administrateur après la mise à jour de la pile. Reportez-vous à la section Activer les mesures correctives entièrement automatisées.

  • Si vous utilisez le Reuse Orchestrator Log Group paramètre pour conserver les journaux, assurez-vous qu'il est correctement défini lors de la mise à jour de la pile afin d'éviter la création de groupes de journaux ou la perte des paramètres de conservation des journaux. Reportez-vous à la section Déployer la solution. Si vous effectuez une mise à jour de pile vers la version 2.3.0+ à partir d'une version antérieure, choisissez « non »

Mise à niveau depuis des versions antérieures à la version 1.4

Si vous avez déjà déployé la solution avant la version 1.4.x, désinstallez-la, puis installez la dernière version :

  1. Désinstallez la solution précédemment déployée. Reportez-vous à la section Désinstaller la solution.

  2. Lancez le dernier modèle. Reportez-vous à la section Déployer la solution.

    Note

    Si vous effectuez une mise à niveau de la version 1.2.1 ou antérieure vers la version 1.3.0 ou ultérieure, définissez surReuse Orchestrator Log Group. No Si vous réinstallez la version 1.3.0 ou une version ultérieure, vous pouvez sélectionner Yes cette option. Cette option vous permet de continuer à vous connecter au même groupe de journaux pour les fonctions d'étape d'Orchestrator.

Mise à niveau depuis la version 1.4 et les versions ultérieures

Si vous effectuez une mise à niveau depuis la version 1.4.x, mettez à jour toutes les piles ou StackSets procédez comme suit :

  1. Mettez à jour la pile dans le compte administrateur de Security Hub à l'aide du modèle le plus récent.

  2. Dans chaque compte de membre, mettez à jour les autorisations à partir du dernier modèle.

  3. Dans chaque compte membre de toutes les régions où il est actuellement déployé, mettez à jour la liste des membres à partir du modèle le plus récent.

  4. Si l'interface utilisateur Web est activée et que vous avez mis à jour des paramètres tels que TicketGenFunctionName l'invalidation du CloudFront cache pour refléter immédiatement les modifications :

    aws cloudfront create-invalidation \
  --distribution-id <distribution-id> \
  --paths "/aws-exports.json"

Mise à niveau depuis la version 2.0.x

Si vous effectuez une mise à niveau depuis la version 2.0.x, passez d'abord à la version 2.3.0. La mise à jour vers les versions 2.1.0—2.1.1 échoue. CloudFormation

Mise à niveau depuis la version 2.1.4 ou une version antérieure

Si vous effectuez une mise à niveau depuis la version 2.1.4 ou une version antérieure, vous devez effectuer la mise à niveau vers la version 2.3.0 avant de passer à une version supérieure à la version 2.3.0. Sinon, l'opération de mise à jour de la pile échouera. Vous pouvez également supprimer et redéployer les piles de la solution plutôt que de procéder à une mise à jour des piles.

Mise à niveau de la version 2.x vers la version 4.0.0 ou ultérieure

À partir de la version 4.0.0, la solution préserve vos paramètres de correction automatique lors de la mise à niveau de la v2 vers la v4. Dans la version 2, les EventBridge règles Amazon par contrôle stockaient l'état de correction automatique. Dans la version 3 et les versions ultérieures, la solution le stocke dans la table Amazon DynamoDB de configuration de remédiation du compte administrateur. Lors de la mise à jour de la pile v4, une ressource personnalisée analyse vos _AutoTrigger règles v2 existantes, traduit l'ID de contrôle spécifique à chaque règle en l'ID de contrôle de sécurité correspondant et écrit les contrôles précédemment activés dans la table DynamoDB.

La migration couvre les cinq playbooks v2 :

  • SC(Contrôles de sécurité AWS Service-managed Security Hub) : les ID de contrôle sont écrits dans DynamoDB sans modification.

  • AFSBP(AWS Foundational Security Best Practices) : les ID de contrôle sont écrits dans DynamoDB sans modification.

  • NIST80053R5(NIST 800-53 Revision 5) : les ID de contrôle sont écrits dans DynamoDB sans modification.

  • PCI(PCI DSS v3.2.1) : le PCI. préfixe principal est supprimé (par exemple, devient). PCI.S3.5 S3.5

  • CIS(CIS AWS Foundations Benchmark v1.2.0, v1.4.0 et v3.0.0) : chaque ID de contrôle CIS est mappé au contrôle de sécurité auquel son document de correction SSM v2 cible.

Résultats de la migration :

  • Les contrôles migrés avec succès ne nécessitent aucune action : la correction automatique est activée dans la v4 de la même manière que dans la v2.

  • Les contrôles ignorés par la migration se répartissent en deux catégories : les règles CIS sans correction ASR dans la v2 et les contrôles v3+ qui ne sont pas fournis. Les contrôles ignorés sont répertoriés dans les journaux Amazon CloudWatch de la fonction SO0111-ASR-MigrationAutoRemediation AWS Lambda.

  • Si la migration rencontre un échec par contrôle (par exemple, une erreur de limitation transitoire lors de la mise à jour de DynamoDB) ou s'arrête avant que les contrôles ne soient écrits, SO0111-ASR-MigrationAutoRemediation publie une notification Amazon SNS dans la rubrique existante. SO0111-ASR_Topic Le corps de notification répertorie les ID de contrôle concernés et est préfixé par[ASR v2 → v3/v4 migration].

  • La ressource personnalisée ne s'exécute que lors de la mise à jour initiale de la v3/v4 pile. Les mises à jour ultérieures de la pile ne relancent pas la migration.

Note

Abonnez-vous à la rubrique SNS avant de procéder à la mise à niveau. Les notifications d'échec de migration sont publiées dans la rubrique SO0111-ASR_Topic Amazon SNS existante de la solution. Si vous n'avez pas d'abonnement confirmé à ce sujet avant la mise à niveau, la notification d'échec ne vous parvient pas. Dans ce cas, l'échec s'affiche uniquement dans les CloudWatch journaux Amazon de la fonction SO0111-ASR-MigrationAutoRemediation AWS Lambda. Pour abonner un endpoint, récupérez l'ARN de la rubrique dans le magasin de paramètres AWS Systems Manager à l'adresse /Solutions/SO0111/SNS_Topic_ARN et ajoutez un abonnement SNS (e-mail, SQS, fonction AWS Lambda ou tout autre protocole pris en charge) avant de démarrer la mise à jour de la pile v4. Confirmez tous les abonnements par e-mail via l'e-mail de confirmation AWS afin que le sujet soit prêt à être diffusé avant le lancement de la migration.

Si la migration ne permet pas d'écrire un contrôle que vous souhaitez corriger automatiquement dans la version 4, activez-le manuellement dans le tableau DynamoDB de configuration de correction. Reportez-vous à la section Activer les mesures correctives entièrement automatisées.