Déployer Sophos NDR sur AWS

Sophos NDR s’exécute sur AWS sous la forme d’une appliance d’intégration basée sur EC2. Elle reçoit une copie du trafic VPC sélectionné par l’intermédiaire de VPC Traffic Mirroring, l’analyse de manière passive et envoie les données NDR au Sophos Data Lake. L’appliance n’est pas placée en ligne et ne remplace ni les Security Groups ni un pare-feu.

Voici le processus général fiable : clarifier les licences et les responsabilités, consigner les informations du réseau AWS, créer l’appliance dans Sophos Fusion, télécharger le modèle CloudFormation généré, souscrire à l’offre Marketplace, créer la pile, ajouter une seule Mirror Session contrôlée, restreindre l’accès d’administration et valider chaque couche séparément.

⚠️ Ce runbook n’inclut volontairement aucune procédure de démantèlement complète. L’ordre sûr et les conséquences de la suppression des ressources de la pile, de l’appliance, d’EC2, d’EBS, des ENI, des Security Groups, de l’Elastic IP, de la réplication et de Marketplace n’ont pas été entièrement vérifiés. Un déploiement ayant échoué ne doit donc pas être « nettoyé » au moyen d’une séquence de suppression improvisée.

Architecture et décisions à prendre avant de commencer

CloudFormation crée deux chemins réseau distincts sur le plan logique :

La Management Interface se trouve dans un Public Subnet et utilise une Elastic IP Address attribuée. SSH et l’accès à Sophos Appliance Manager empruntent ce chemin.
La SPAN interface reçoit le trafic répliqué. Le NDR SPAN Target créé par le modèle sert de Mirror Target.
Une Traffic mirror session relie une ENI source sélectionnée à cette cible. Le NDR Traffic Mirror Filter, également créé par le modèle, détermine les paquets qui sont répliqués.
L’appliance traite les copies et envoie les données NDR à Sophos. Les flux d’origine continuent d’emprunter leur chemin de données AWS habituel.

La décision de conception la plus importante n’est donc pas « quel VPC entier devons-nous surveiller ? », mais quelle ENI constitue une Mirror Source pertinente. Commencez par une seule ENI documentée appartenant à un système de test. Vous limiterez ainsi le volume de données, les coûts et l’étendue des erreurs potentielles. N’ajoutez d’autres sources qu’après la recette technique.

Avant le déploiement, consignez au minimum les éléments suivants dans un plan de déploiement :

le compte AWS, la Region, le VPC, l’Availability Zone et les balises de propriétaire ;
l’ID du VPC ainsi que les ID des Management et SPAN Subnets ;
au moins une Elastic IP attribuée dans le compte AWS pour la Management Interface ; il s’agit d’un prérequis au niveau du compte, mais la liste de paramètres documentée ne la propose pas comme entrée de modèle sélectionnable à l’avance ;
les types EC2 actuellement pris en charge par Sophos : c5n.2xlarge, c6i.4xlarge ou c7i.16xlarge avec la virtualisation Nitro ; vérifiez le type réellement utilisé dans le modèle actuel du tenant, puis sur l’instance après le déploiement ;
le nom du SSH Key Pair existant et l’emplacement sécurisé du Private Key ;
un Security Group pour SSH et des réseaux sources d’administration fixes ;
la première ENI servant de Mirror Source et l’équipe en charge de la charge de travail correspondante ;
le trafic de test normal attendu pour cette ENI ;
le centre de coûts, l’alarme budgétaire et l’approbation des coûts d’infrastructure AWS ainsi que des conditions Marketplace affichées pour ce compte.

VPC, Subnets et Elastic IP

Vous pouvez utiliser un VPC et des Subnets existants. Ne vous fiez toutefois pas uniquement à leurs noms pour les sélectionner :

Concevez le Management Subnet comme un Public Subnet. Vérifiez sa Route Table et le chemin Internet prévu avant de le sélectionner.
Indiquez le SPAN Subnet pour la NDR SPAN interface. Consignez le Subnet et l’Availability Zone avec la Mirror Source, plutôt que de déduire ultérieurement ces valeurs à partir des noms des ressources.
L’Elastic IP doit être associée à la Management Interface, et non au côté SPAN. Assurez-vous au préalable qu’au moins une Elastic IP est attribuée dans le compte. N’affirmez pas que la pile utilise une adresse existante particulière : après CREATE_COMPLETE, identifiez et consignez l’adresse réellement créée ou utilisée, ainsi que son association à l’ENI.
Le modèle sélectionne automatiquement l’AMI et la Region en fonction de la Region AWS dans laquelle il est chargé. Ne forcez pas l’utilisation d’une autre AMI en modifiant manuellement le modèle.

Security Groups et SSH Key Pair

Utilisez un AWS Key Pair existant dont le Private Key est déjà stocké de manière sécurisée. CloudFormation requiert le nom du Key Pair ; le Private Key n’est enregistré ni dans Sophos Fusion ni dans le modèle. Sans ce Private Key, l’accès SSH à l’appliance AWS documenté par Sophos ne sera pas disponible par la suite.

Préparez un Security Group qui autorise SSH uniquement depuis le réseau d’accès administratif, par exemple depuis une adresse IP de sortie d’entreprise fixe au format /32 ou par l’intermédiaire d’un Jump Host contrôlé. N’exposez ni SSH ni le port TCP 8443 à 0.0.0.0/0.

Le modèle crée également InternalMgmtSG. Après le déploiement, n’y autorisez le port TCP 8443 que pour les sources d’administration réelles. Si la même appliance héberge aussi un Log Collector, n’autorisez Syslog qu’avec le protocole et le port exigés par le connecteur concerné, et uniquement depuis les réseaux sources internes. VPC Traffic Mirroring ne nécessite pas en soi une règle Syslog générale depuis Internet.

Valider au préalable la connectivité sortante

La présence d’un Public Subnet et d’une Elastic IP ne prouve pas à elle seule qu’un chemin sortant opérationnel existe. Avant de cliquer sur Submit, l’équipe réseau responsable doit confirmer que la Management Interface peut communiquer vers l’extérieur par l’intermédiaire de la route prévue et d’un Internet Gateway, ou du dispositif de sortie centralisé approuvé. Vérifiez la résolution DNS, la Route Table, la Network ACL, les règles de sortie du Security Group ainsi que les règles du proxy et du pare-feu en amont.

Les destinations et les ports requis ne sont pas reproduits dans ce runbook. Au moment du changement, comparez plutôt les exceptions actuelles de ports et de domaines pour les appliances Sophos avec les règles de sortie. Ces autorisations sont nécessaires au démarrage, aux mises à jour, à l’enregistrement et au chargement des données ; la preuve de la connectivité à une seule destination ne remplace pas cette comparaison complète.

Prérequis, rôles, licence et coûts

La configuration nécessite :

un compte AWS doté d’un VPC, de Subnets et d’Availability Zones existants ;
un compte Sophos Fusion ;
en règle générale, le Sophos Network Detection and Response integration license pack ;
au moins une instance EC2 source appropriée ou son ENI ;
au moins une Elastic IP Address attribuée dans le compte AWS ;
un AWS SSH Key Pair conservé de manière sécurisée ;
une approbation de changement en cours de validité pour la réplication réseau et les données ainsi traitées.

Dans la mesure du possible, répartissez les tâches comme suit, sans inventer de noms de stratégies IAM non confirmés :

Un administrateur Sophos Fusion crée la configuration NDR et télécharge le modèle.
Une personne habilitée à effectuer des achats accepte les conditions de Sophos Integration Appliance dans AWS Marketplace.
Un administrateur AWS disposant des autorisations nécessaires pour la pile et les ressources réseau référencées crée les ressources CloudFormation, EC2, VPC Traffic Mirroring, Security Group et Elastic IP.
L’équipe réseau ou l’équipe responsable de la charge de travail confirme la Mirror Source, le comportement du filtre, la fenêtre de test et le trafic attendu.

Sophos n’indique aucun rôle Fusion minimal et distinct, propre à NDR, pour ce processus. Par conséquent, si Add Configuration, Download image ou Open Appliance Manager n’est pas visible, ne faites aucune supposition : un Super Admin doit vérifier les autorisations effectives du tenant et la licence.

La seule exception prise en compte ici est strictement limitée : Sophos indique que les clients MSP Flex disposant d’une licence XDR peuvent intégrer Sophos NDR sans Integration License Pack supplémentaire. Cela ne signifie ni que tout abonnement XDR ou MDR inclut NDR, ni que cette exception s’applique aux licences Term. Confirmez donc les droits précis associés au tenant et à la SKU dans Fusion et, en cas de doute, auprès de Sophos ou du partenaire chargé des achats, en vous appuyant sur les règles actuelles de licence des intégrations Sophos.

CloudFormation crée des ressources AWS facturables. L’appliance virtuelle est incluse dans les droits Sophos NDR applicables ; il ne faut en déduire ici ni un prix catalogue public ni une quelconque affirmation concernant l’offre Marketplace propre au compte. Avant de cliquer sur Submit, vérifiez les conditions Marketplace alors affichées. Estimez séparément les coûts AWS associés à EC2, au stockage, à l’adresse IPv4 publique ou Elastic IP, au transfert de données et à VPC Traffic Mirroring. Ce runbook ne fournit volontairement aucun montant fixe : la Region, la durée d’exécution, le volume de données et le modèle tarifaire AWS modifient le calcul. Les balises et une alarme budgétaire doivent figurer dans le changement avant le début de la réplication en production.

1. Créer l’appliance et le modèle CloudFormation dans Sophos Fusion

Dans Sophos Fusion, ouvrez Threat Analysis Center > Integrations > Marketplace.
Ouvrez Sophos Network Detection and Response (NDR).
Sous Data Ingest (Security Alerts), cliquez sur Add Configuration.
Dans Step 1, saisissez un nom et une description uniques, par exemple ndr-aws-prod-eu1 et NDR Sensor für AWS Produktions-VPC eu1.
Dans Step 2, sous Virtual platform, sélectionnez AWS.
Cliquez sur Save. Sophos génère le fichier CloudFormation aws_ndr_cf_latest.json.
Ouvrez Threat Analysis Center > Integrations > Configured, puis l’onglet Integration Appliances.
Recherchez l’appliance que vous venez de créer. Dans la colonne de droite, ouvrez le menu à trois points, sélectionnez Download image, puis enregistrez aws_ndr_cf_latest.json dans le dossier protégé du changement.

Le fichier JSON provient de votre propre tenant Fusion et de l’appliance que vous venez de créer. N’utilisez pas un ancien fichier issu d’un autre tenant ou d’un autre changement. Ne modifiez pas manuellement le modèle pour imposer des types d’instances, des AMI ou des variantes réseau non pris en charge.

2. Souscrire à l’offre Marketplace

Recherchez Sophos Integration Appliance dans AWS Marketplace.
Sur la page Product Overview, cliquez sur Continue to Subscribe.
Sur la page Subscribe to this software, examinez les conditions et ne les acceptez qu’après avoir obtenu l’approbation d’achat prévue. Cliquez ensuite sur Continue to Configuration.
Sur la page Configure this software, vérifiez la version et la Region. Elles doivent correspondre au plan de déploiement. Cliquez sur Continue to Launch.
Sur la page Launch this software, ouvrez d’abord Usage instructions et consignez les instructions d’accès affichées.
Cliquez sur Launch. AWS ouvre Create stack.

La souscription à l’offre Marketplace est indispensable pour qu’AWS accepte le logiciel référencé par le modèle. Si une AMI n’est pas disponible ou si une erreur de droits survient, commencez donc le diagnostic par la souscription, la Region et la version, plutôt que de modifier le fichier JSON.

3. Créer la pile CloudFormation

Avant de remplir le formulaire, examinez les paramètres du modèle qui vient d’être généré depuis ce tenant. S’il propose un paramètre documenté pour le type d’instance EC2, sélectionnez exclusivement un type actuellement pris en charge par Sophos et consignez le nom et la valeur du paramètre. Si aucun paramètre de ce type n’est proposé, le modèle choisit lui-même le type ; ne modifiez pas manuellement le fichier JSON. Dans les deux cas, vérifiez après la création le type EC2 effectivement démarré.

Sous Create stack, laissez l’option Template is ready sélectionnée.
Sous Specify template, sélectionnez Upload a template file.
Cliquez sur Choose file, sélectionnez le fichier aws_ndr_cf_latest.json qui vient d’être généré, puis cliquez sur Next.
Sous Specify stack details, saisissez un Stack name unique, tel que sophos-ndr-prod-eu1.
Sous Network Configuration, indiquez :
- le VPC existant prévu ;
- le Public Subnet destiné à la NDR Management Interface ;
- le Subnet destiné à la NDR SPAN interface ;
- le Security Group préparé pour l’accès SSH administratif.
Sous EC2 Instance Configuration, sélectionnez le SSH Key Pair existant. Vérifiez une nouvelle fois que le Private Key est disponible et protégé.
Cliquez sur Next. Sous Configure stack options, examinez les balises et les autres options AWS. N’acceptez pas aveuglément les valeurs par défaut ; comparez-les avec le changement.
Vérifiez le récapitulatif, puis cliquez sur Submit.
Attendez l’état CREATE_COMPLETE. Selon Sophos, cette opération prend généralement cinq à six minutes ; les événements CloudFormation font foi, et non cette estimation.

Avant de créer la Mirror Session, vous devez pouvoir trouver, dans la pile ou parmi les ressources AWS associées, au minimum l’appliance Sophos attendue, son type EC2 réel, les ENI de Management et de SPAN, le NDR SPAN Target, le NDR Traffic Mirror Filter, InternalMgmtSG, ainsi que l’Elastic IP réellement utilisée et son association. Si l’un de ces éléments manque ou si la pile n’atteint pas l’état CREATE_COMPLETE, ne créez aucune Mirror Session.

4. Créer une Traffic Mirror Session

Toutes les ENI ou topologies EC2 ne peuvent pas nécessairement servir de Mirror Source. Avant de créer la session, consultez la documentation AWS à jour pour vérifier les types d’instances sources pris en charge, les prérequis et restrictions applicables au Mirror Target, ainsi que la topologie Source/Target, Region et Availability Zone concernée. Consultez également Service Quotas et les quotas AWS de Traffic Mirroring afin de confirmer que les quotas sont suffisants pour les sources, les sessions, les cibles et les filtres. Cette vérification AWS constitue un point d’approbation distinct ; la liste Sophos des types d’appliances pris en charge ne confirme pas qu’une ENI de charge de travail quelconque prend en charge la réplication.

Ouvrez VPC > Traffic mirror sessions > Create traffic mirror session et renseignez soigneusement les champs :

Name Tag: un nom explicite, tel que ndr-prod-app01 ;
Description: l’objectif et la référence du changement, par exemple Mirror app01 ENI to Sophos NDR - CHG-1234 ;
Mirror Source: l’ENI du système de test approuvé, et non une simple instance EC2 portant un nom similaire ;
Mirror Target: le NDR SPAN Target créé par la pile ;
Session number: un numéro adapté à cette Source. AWS l’utilise pour définir l’ordre lorsque la même Source comporte plusieurs sessions. Inventoriez les sessions existantes avant de le choisir ;
VNI: 1 ;
Filter: le NDR Traffic Mirror Filter créé par la pile.

Ne cliquez sur Create qu’après un contrôle croisé par deux personnes de la Source, de la Target, du Session number, du VNI et du Filter. VNI = 1 et l’utilisation du filtre généré sont des exigences du produit. En revanche, la Source, le nom, la description et le Session number doivent correspondre à votre propre environnement AWS.

N’ajoutez pas d’autres sources « au cas où » pendant le premier test. Une Mirror Session supplémentaire augmente le volume de données, les coûts et le périmètre d’investigation ; elle requiert donc sa propre approbation technique.

5. Configurer l’accès d’administration et les identifiants

Dans la console AWS, recherchez le nom de l’appliance, sélectionnez l’onglet EC2, puis ouvrez l’instance Sophos Appliance.
Dans Instance Summary, ouvrez l’onglet Security, puis InternalMgmtSG.
Sous Inbound rules, ajoutez le port TCP 8443 uniquement pour les CIDR d’administration approuvés. Consignez le Rule ID, la source et la référence du changement.
Dans Sophos Fusion, ouvrez Threat Analysis Center > Integrations > Configured > Integration Appliances.
Ouvrez le menu à trois points de l’appliance et sélectionnez Open Appliance Manager.
Dans la boîte de dialogue de confirmation, cliquez sur reset it pour définir le mot de passe.
Connectez-vous avec le nom d’utilisateur fixe zadmin et le mot de passe que vous avez défini.

Traitez le mot de passe zadmin comme un secret privilégié. Enregistrez-le dans le coffre-fort de mots de passe approuvé, et non dans le modèle CloudFormation, un ticket ou une capture d’écran. Tous les administrateurs utilisent le même mot de passe Appliance Manager. En cas de perte, réinitialisez-le via Open Appliance Manager > reset it.

Valider le déploiement et l’enregistrement initial

Le seul fait que l’instance EC2 soit en cours d’exécution ne prouve ni le bon fonctionnement du chemin de réplication ni l’enregistrement. Effectuez les contrôles dans l’ordre suivant :

CloudFormation: La pile affiche CREATE_COMPLETE ; les ressources attendues sont présentes et aucun événement n’a été ignoré ou n’a échoué.
Association réseau: Le VPC, le Management Subnet, le SPAN Subnet, l’Elastic IP, les deux ENI et le SSH Key Pair correspondent au plan de déploiement.
Exposition: SSH et le port TCP 8443 ne sont accessibles que depuis les réseaux d’administration approuvés. Aucune nouvelle règle de gestion définie sur 0.0.0.0/0 n’existe.
Configuration de la réplication: La session pointe exactement vers la Source ENI approuvée, le NDR SPAN Target, le VNI 1 et le NDR Traffic Mirror Filter. Le Session number et les éventuelles sessions parallèles existantes sont documentés.
Connexion à Sophos: L’appliance est visible sous Integration Appliances ; son état NDR dans Sophos Fusion est vert, Open Appliance Manager ouvre la destination attendue et la connexion avec zadmin fonctionne.
Chemin de données préliminaire: Pendant la fenêtre de test approuvée, générez du trafic normal et sans danger sur la Mirror Source ENI. Dans l’onglet NDR d’Appliance Manager, vérifiez le pourcentage de chargement, le pourcentage de capture du port SPAN configuré et le graphique Total flows. Consignez l’heure et les valeurs de la mesure. Aucune Detection n’est requise pour ce test d’infrastructure.
Contrôle négatif: Une source d’administration non approuvée ne doit pas pouvoir accéder au port TCP 8443. Ce contrôle confirme la restriction de la gestion, et non la détection NDR.

Consignez le Stack ID, le nom de l’appliance, l’ID et le type de l’instance, les ENI de Management et de SPAN, l’association EIP réelle, le Mirror Session ID, la Source ENI, la Target, le Filter, le VNI, les Security Group Rule IDs, les mesures NDR et la fenêtre de recette. Aucun secret ne doit figurer dans ce relevé. Cette recette confirme uniquement le déploiement et l’enregistrement initial. Validez ensuite l’intégralité du chemin des données répliquées avec Configurer et valider Traffic Mirroring pour Sophos NDR, puis effectuez un test de détection de bout en bout sûr. Ni une connexion réussie ni du trafic de test ordinaire ne prouvent à eux seuls que la chaîne de détection fonctionne.

Résolution des problèmes par symptôme

La pile n’atteint pas l’état `CREATE_COMPLETE`

Ouvrez d’abord l’onglet Events de la pile et partez du premier événement ayant échoué, plutôt que de remonter depuis la dernière erreur qui en découle.

En cas d’erreur de droits Marketplace ou AMI : vérifiez la souscription, les conditions acceptées, la version et la Region.
En cas d’erreur d’autorisation : demandez à l’administrateur AWS de vérifier l’action et la ressource citées dans l’événement concerné. N’attribuez pas une stratégie d’administration générale comme solution rapide.
En cas d’erreur portant sur les paramètres réseau : comparez les ID du VPC et des Subnets, l’Elastic IP attribuée ou le quota EIP disponible, le Security Group et le SSH Key Pair avec le plan de déploiement.
En cas d’erreur de capacité ou de quota : vérifiez le type d’instance pris en charge qui a été sélectionné et le message d’erreur AWS exact. Ne choisissez pas un type que le modèle ne propose pas.

Tant que la pile est incomplète, ne créez ni Mirror Session ni Inbound Rules supplémentaires.

L’appliance s’exécute, mais ne reçoit aucun trafic répliqué

Vérifiez la chaîne dans l’ordre suivant :

La Mirror Source est-elle bien l’ENI par laquelle transite le trafic de test ?
Le Mirror Target est-il bien le NDR SPAN Target de cette pile, et non une cible portant un nom similaire dans un autre environnement ?
Le VNI est-il défini sur 1 ?
Le NDR Traffic Mirror Filter est-il sélectionné ?
Le Session number entre-t-il en conflit avec l’ordre d’évaluation prévu pour d’autres sessions de la même Source ?
Du trafic a-t-il réellement transité par cette ENI pendant la fenêtre documentée ?

Ne modifiez qu’une seule de ces variables à la fois, puis répétez le même test. Élargir le filtre ou la sélection de la Source ne remplace pas l’analyse de la cause première.

Impossible de créer la Mirror Session

Commencez par lire l’erreur précise de l’API ou de la console AWS ; ne modifiez pas simultanément la Source, la Target et le Filter.
Vérifiez de nouveau la Source ENI et son type d’instance EC2 au regard des prérequis et restrictions AWS actuels de Traffic Mirroring.
Comparez la topologie Source/Target et la sélection de la Region et de l’Availability Zone avec la documentation AWS à jour.
Vérifiez les quotas Traffic Mirroring concernés dans Service Quotas. Demandez leur augmentation ou modifiez la conception au moyen du processus de changement AWS habituel, plutôt que de supprimer des sessions existantes sans contrôle.

Échec de l’enregistrement ou du chargement NDR

Commencez par vérifier le chemin défini dans la section Valider au préalable la connectivité sortante. Le DNS, la Route Table, l’Internet Gateway ou le dispositif de sortie approuvé, la Network ACL, les règles de sortie du Security Group, le proxy et le pare-feu en amont doivent notamment être cohérents. Comparez une nouvelle fois les règles avec les exceptions actuelles de ports et de domaines Sophos. Selon Sophos, une erreur de chargement faisant intervenir une URL S3 présignée indique souvent que le proxy ou le pare-feu bloque le trafic Internet sortant. N’élargissez pas les règles de sortie sans discernement ; consignez la destination précise qui est bloquée et n’autorisez que l’exception actuellement requise par Sophos.

Appliance Manager n’est pas accessible sur le port TCP 8443

Vérifiez si InternalMgmtSG autorise l’adresse source publique actuelle de l’administrateur.
Vérifiez l’association de l’Elastic IP avec la Management Interface et le Public Subnet sélectionné.
Assurez-vous que Open Appliance Manager ouvre l’appliance attendue.
Si une règle a été temporairement élargie à 0.0.0.0/0, restreignez-la de nouveau immédiatement ; un accès étendu ne constitue pas une étape de diagnostic.

N’examinez un éventuel problème de mot de passe qu’une fois le chemin réseau opérationnel.

Échec de la connexion avec `zadmin` ou verrouillage d’Appliance Manager

Si le mot de passe est inconnu, utilisez Open Appliance Manager > reset it dans Sophos Fusion. Si l’appliance affiche explicitement un message de verrouillage, Sophos documente l’intervention SSH suivante pour AWS :

redis-cli --no-auth-warning -h redis-master.default.svc.cluster.local -p 6379 -a $(jq -r .RedisPassword /etc/dragonfly/sensorapi_config.json) SET userlockout '{"attempt":0,"locked":false}'

Exécutez cette commande uniquement dans la session SSH de l’instance EC2 Sophos NDR concernée, à l’aide du Private Key sélectionné lors du déploiement. Ce runbook ne fournit volontairement ni nom d’utilisateur du système d’exploitation ni syntaxe SSH complète, car la page Sophos examinée ne les documente pas. Relevez l’identité de connexion actuelle dans les Usage instructions de l’offre Marketplace souscrite ou demandez-la à Sophos Support ; ne la devinez pas. Avant de vous connecter, comparez l’adresse de destination, l’ID de l’instance et l’empreinte de l’hôte avec l’inventaire AWS. La commande modifie l’état de verrouillage, mais ne définit pas de nouveau mot de passe. Ne l’utilisez que lorsqu’un verrouillage est explicitement signalé, et non comme solution générale à un problème de connexion. Testez ensuite le mot de passe existant ; s’il ne fonctionne pas, réinitialisez-le dans Sophos Fusion. Consignez la commande et son résultat dans le relevé du changement, sans y inclure le mot de passe ni le Private Key.

Retour arrière limité plutôt qu’un démantèlement non vérifié

Avant toute modification manuelle d’un Security Group, exportez l’état initial ou documentez-le à l’aide des Rule IDs. Si la nouvelle règle TCP 8443 ou Syslog provoque un problème, vous pouvez supprimer précisément cette règle ajoutée manuellement, puis vérifier l’état initial documenté. Il s’agit d’un retour arrière limité pour votre propre modification des règles entrantes, et non du démantèlement de l’appliance NDR.

Aucune séquence de suppression complète n’est volontairement fournie ici pour la pile, la souscription Marketplace, l’objet appliance, EC2/EBS, les ENI, l’Elastic IP, la Traffic Mirror Session, la Target, le Filter et les Security Groups. Ce runbook n’affirme pas non plus que la suppression de la pile CloudFormation supprime toutes les ressources associées, met fin à tous les coûts, supprime tous les objets Sophos ou règle toutes les conséquences sur les données. Tant que ces dépendances n’ont pas été vérifiées à l’aide de la documentation actuelle du fournisseur et de tests, ne supprimez les ressources que dans le cadre d’un changement de retrait examiné séparément.