Cisco fournit des modèles et des scripts CloudFormation pour le déploiement d’un groupe d’évolutivité automatique de pare-feu ASA virtuel à l’aide de plusieurs services AWS, notamment Lambda, les groupes d’évolutivité automatique, Elastic Load Balancing (ELB, équilibreur de charge élastique), les compartiments Amazon S3, SNS et CloudWatch.

L’évolutivité automatique de l’ASA virtuel dans AWS est une implémentation complète sans serveur (c.-à-d. aucune machine virtuelle d’assistant n’est impliquée dans l’automatisation de cette fonctionnalité) qui ajoute une capacité d’évolutivité automatique horizontale aux instances d’ASA virtuel dans l’environnement AWS. À partir de la version 6.4, la solution d’évolutivité automatique est prise en charge sur gérée par centre de gestion.

La solution d’évolutivité automatique ASA virtuel est un déploiement basé sur un modèle CloudFormation qui fournit :

• La configuration entièrement automatisée s’applique automatiquement aux instances ASA virtuel mises à l’échelle.

• Prise en charge des équilibreurs de charges et des zones de multi-disponibilité.

• Prise en charge de l’activation et de la désactivation de la fonction d’évolutivité automatique.

Le scénario de cette solution d’évolutivité automatique AWS ASA virtuel est illustré dans le diagramme des scénarios. Comme l’équilibreur de charges AWS autorise uniquement les connexions entrantes, seul le trafic externe est autorisé à passer à l’intérieur par le pare-feu ASA virtuel.

Remarque

Les ports sécurisés ont besoin d’un certificat SSL/TLS, comme décrit dans Certificat de serveur SSL dans les conditions préalables.

L’équilibreur de charges Internet peut être un équilibreur de charges réseau ou un équilibreur de charges d’application. Toutes les exigences et conditions d’AWS sont remplies dans tous les cas. Comme indiqué dans le diagramme des scénarios, le côté droit de la ligne pointillée est déployé par l’intermédiaire des modèles ASA virtuel. Le côté gauche est entièrement défini par l’utilisateur.

Remarque

Le trafic sortant initié par l’application ne passera pas par l’ASA virtuel.

La bipolation du trafic basée sur le port est possible. Cela peut être possible en utilisant des règles NAT. Par exemple, le trafic DNS LB sur Internet, Port : 80 peut être acheminé vers Application-1; le trafic Port : 88 peut être acheminé vers Application-2.

Le scénario de la solution d’évolutivité automatique de l’équilibreur de charges de la passerelle (GWLB) AWS d’ASA virtuel est illustré dans le diagramme de scénarios. La GWLB AWS permet les connexions entrantes et sortantes, de sorte que le trafic généré en interne et en externe est autorisé à passer à l’intérieur par le pare-feu Cisco ASA virtuel.

L’équilibreur de charges sur Internet peut être un terminal d’équilibreur de charges de passerelle (GWLBe) AWS. Le GWLBe envoie le trafic à la solution GWLB, puis à ASA virtuel pour inspection. Toutes les exigences et conditions d’AWS sont remplies dans tous les cas. Comme indiqué dans le diagramme de scénarios, le côté droit de la ligne pointillée représente la solution d’évolutivité automatique GWLB d’ASA virtuel déployée via les modèles ASA virtuel. Le côté gauche est entièrement défini par l’utilisateur.

Remarque

Le trafic sortant initié par l’application ne passera pas par l’ASA virtuel.

Pour l’évolutivité à la baisse et à la hausse des instances ASA virtuel, une entité externe appelée Auto Scale Manager supervise les mesures, les commandes et le groupe d’évolutivité automatique pour ajouter ou supprimer les instances ASA virtuel, et configure les instances ASA virtuel.

Auto Scale Manager est implémenté en utilisant l'architecture sans serveur AWS et communique avec les ressources d'AWS et l’ASA virtuel. Nous fournissons des modèles CloudFormation pour automatiser le déploiement des composants d’Auto Scale Manager. Le modèle déploie également d’autres ressources nécessaires pour que la solution complète fonctionne.

Remarque

Les scripts d’évolutivité automatique sans serveur ne sont appelés que par les événements CloudWatch. Ils ne s’exécutent donc que lorsqu’une instance est lancée.

Les composants suivants constituent la solution d’évolutivité automatique.

Modèle CloudFormation

Le modèle CloudFormation est utilisé pour déployer les ressources requises par la solution d’évolutivité automatique dans AWS. Le modèle comprend les éléments suivants :

• Groupe d’évolutivité automatique, équilibreur de charges, groupes de sécurité et autres composants divers.

• Le modèle prend en compte les données des utilisateurs pour personnaliser le déploiement.

  Remarque

  Le modèle a des limites pour la validation des entrées des utilisateurs. Il est donc de la responsabilité de l’utilisateur de valider les entrées pendant le déploiement.

Fonctions Lambda

La solution d’évolutivité automatique est un ensemble de fonctions Lambda développées en Python, qui sont déclenchées à partir de crochets de cycle de vie, de SNS et d’événements/alarmes CloudWatch. Voici les fonctionnalités de base :

• Ajouter/Supprimer les interfaces Gig 0/0 et Gig 0/1 à l’instance.

• Enregistrez l’interface Gig 0/1 dans les groupes cibles de l’équilibreur de charges.

• Configurez et déployez un nouveau ASA virtuel avec le fichier de configuration ASA.

Les fonctions Lambda sont fournies au client sous la forme d’un progiciel Python.

Crochets de cycle de vie

• Les crochets de cycle de vie sont utilisés pour obtenir une notification de modification de cycle de vie d’une instance.

• Dans le cas du lancement d’une instance, un crochet de cycle de vie est utilisé pour déclencher une fonction Lambda qui peut ajouter des interfaces à une instance ASA virtuel et enregistrer les adresses IP d’interface externe aux groupes cibles.

• Dans le cas de la résiliation d’une instance, un crochet de cycle de vie est utilisé pour déclencher une fonction Lambda afin d’annuler l’enregistrement d’une instance ASA virtuel du groupe cible.

Service de notification simple (SNS)

• Le service de notification simple (SNS) d’AWS est utilisé pour générer des événements.

• En raison de la limitation liée à l’absence d’orchestrateur adapté aux fonctions Lambda sans serveur dans AWS, la solution utilise SNS comme type de chaînage de fonctions pour orchestrer les fonctions Lambda selon les événements.

Téléchargez les fichiers requis pour lancer l’évolutivité automatique ASA virtuel pour la solution AWS. Les scripts et les modèles de déploiement pour votre version ASA sont disponibles dans le référentiel GitHub.

Attention

Remarque : les scripts et les modèles de déploiement fournis par Cisco pour l’évolutivité automatique sont présentés à titre d’exemples de code source libre et ne font pas l’objet de l’assistance technique du TAC dans sa portée normale. Vérifiez régulièrement GitHub pour connaître les mises à jour et les instructions ReadMe.

Dans un référentiel GitHub cloné/téléchargé, les fichiers infrastructure.yaml se trouvent dans le dossier de modèle. Ce CFT peut être utilisé pour déployer des VPC, des sous-réseaux, des routes, des ACL, des groupes de sécurité, des points terminaux VPC et des compartiments S3 avec des politiques de compartiment. Ce CFT peut être modifié selon vos besoins.

Les sections suivantes fournissent de plus amples renseignements sur ces ressources et leur utilisation dans l’évolutivité automatique. Vous pouvez déployer manuellement ces ressources et les utiliser pour l’évolutivité automatique.

Remarque

Le modèle infrastructure.yaml déploie uniquement des VPC, des sous-réseaux, des ACL, des groupes de sécurité, des compartiments S3 et des points terminaux de VPC. Il ne crée pas le certificat SSL, la couche Lambda ou les ressources de clés KMS.

Vous devez créer le VPC selon les besoins de votre application. Il est prévu que le VPC ait une passerelle Internet avec au moins un sous-réseau associé à une route vers Internet. Consultez les sections appropriées pour connaître les exigences des groupes de sécurité, des sous-réseaux, etc.

Des sous-réseaux peuvent être créés selon les besoins de l’application. La machine ASA virtuel nécessite 3 sous-réseaux pour fonctionner, comme illustré dans le scénario.

Remarque

Si la prise en charge de plusieurs zones de disponibilité est nécessaire, des sous-réseaux sont nécessaires pour chaque zone, car les sous-réseaux sont des propriétés zonées dans le nuage AWS.

Sous-réseau externe

Le sous-réseau externe doit avoir une route par défaut avec « 0.0.0.0/0 » vers la passerelle Internet. Celui contiendra l‘interface externe de l’ASA virtuel, et le NLB sur Internet se trouvera également dans ce sous-réseau.

Sous-réseau interne

Cela peut être similaire aux sous-réseaux d’application, avec ou sans passerelle NAT/Internet. Veuillez noter que pour les sondes d’intégrité de l’ASA virtuel, il devrait être possible d’atteindre le serveur de métadonnées AWS (169.254.169.254) par le port 80.

Remarque

Dans cette solution d’évolutivité automatique, les sondes d’intégrité de l’équilibreur de charges sont redirigées vers le serveur de métadonnées AWS par l’intermédiaire de l’interface interne/Gig0/0. Cependant, vous pouvez le modifier en utilisant votre propre application pour assurer les connexions de sonde d’intégrité envoyées à l’ASA virtuel à partir de l’équilibreur de charges. Dans ce cas, vous devez remplacer l’objet du serveur de métadonnées AWS par l’adresse IP de l’application respective pour fournir la réponse des sondes d’intégrité.

Management Subnet (Sous-réseau de gestion)

Ce sous-réseau comprend l’interface de gestion de l’ASA virtuel. Il est facultatif d’avoir une route par défaut.

Sous-réseaux Lambda

La fonction AWS Lambda nécessite deux sous-réseaux ayant la passerelle NAT comme passerelle par défaut. Cela rend la fonction Lambda privée pour le VPC. Les sous-réseaux Lambda ne doivent pas être aussi larges que les autres sous-réseaux. Veuillez vous reporter à la documentation d’AWS pour connaître les bonnes pratiques sur les sous-réseaux Lambda.

Sous-réseaux d’application

Aucune restriction n’est imposée sur ce sous-réseau par la solution d’évolutivité automatique, mais si l’application a besoin de connexions sortantes en dehors du VPC, des routes respectives doivent être configurées sur le sous-réseau. En effet, le trafic initié vers la sortie ne passe pas par les équilibreurs de charges. Consultez le Guide de l’utilisateur de l’équilibrage de charges élastiques d’AWS.

Toutes les connexions sont autorisées dans le modèle de groupe d’évolutivité automatique fourni. Vous n’avez besoin que des connexions suivantes pour que la solution d’évolutivité automatique fonctionne.

Amazon Simple Storage Service (Amazon S3) est un service de stockage d’objets qui offre une évolutivité, une disponibilité des données, une sécurité et des performances de pointe. Vous pouvez placer tous les fichiers requis pour le modèle de pare-feu et le modèle d’application dans le compartiment S3.

Lorsque des modèles sont déployés, des fonctions Lambda sont créées en référençant les fichiers zip dans le compartiment S3. Par conséquent, le compartiment S3 devrait être accessible au compte d’utilisateur.

Si l’équilibreur de charge Internet doit prendre en charge TLS/SSL, un ARN de certificat est requis. Consultez les liens suivants pour en savoir plus :

• Travailler avec des certificats de serveur

• Créer une clé privée et un certificat autosigné pour les tests

• Créer AWS ELB avec un certificat SSL autosigné (lien tiers)

Exemple d’ARN : arn:aws:iam::[Compte AWS]:server-certificate/[Nom du certificat]

Le fichier autoscale_layer.zip peut être créé dans un environnement Linux, comme Ubuntu 18.04 sur lequel Python 3.9 est installé.

Le fichier autoscale_layer.zip résultant doit être copié dans le dossier lambda-python-files.

Cela est nécessaire si les mots de passe ASA virtuel sont dans un format chiffré. Sinon, ce composant n’est pas obligatoire. Les mots de passe doivent être chiffrés uniquement à l’aide du KMS fourni ici. Si l’ARN KMS est saisi sur CFT, les mots de passe doivent être chiffrés. Sinon, les mots de passe doivent être en texte brut.

Pour en savoir plus à propos des clés principales et du chiffrement, consultez le document AWS Création de clés et la Référence de commande de l’interface de ligne de commande AWS sur le chiffrement des mots de passe et KMS.

Exemple :

$ aws kms encrypt --key-id <KMS-ARN> --plaintext 'MyC0mplIc@tedProtect1oN'
{
    "KeyId": "KMS-ARN", 
    "CiphertextBlob": 
"AQICAHgcQFAGtz/hvaxMtJvY/x/rfHnKI3clFPpSXUU7HQRnCAFwfXhXHJAHL8tcVmDqurALAAAAajBoBgkqhki
G9w0BBwagWzBZAgEAMFQGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQM45AIkTqjSekX2mniAgEQgCcOav6Hhol
+wxpWKtXY4y1Z1d0z1P4fx0jTdosfCbPnUExmNJ4zdx8="
}
$

La valeur de la clé CiphertextBlob doit être utilisée comme mot de passe.

Un fichier make.py se trouve dans le répertoire supérieur du référentiel cloné. Cela compressera les fichiers python dans un fichier zip et les copiera dans un dossier cible. Afin d’effectuer ces tâches, l’environnement Python 3 doit être disponible.

Une fois que toutes les conditions préalables pour le déploiement sont terminées, vous pouvez créer la pile AWS CloudFormation.

Utilisez le fichier deploy_autoscale.yaml dans le répertoire target (cible).

Utilisez le fichier deploy_ngfw_autoscale_with_gwlb.yaml dans le répertoire target (cible) pour Geneve Autoscale.

Remarque

Avant de déployer le fichier deploy_ngfw_autoscale_with_gwlb.yaml , vous devez déployer le fichier infrastructure_gwlb.yaml pour la solution d’évolutivité automatique AWS GWLB. Vous devez créer le point terminal de l’équilibreur de charge de passerelle (GWLB-E) en sélectionnant le GWLB qui est créée lors du déploiement du modèle deploy_autoscale_with_gwlb.Yaml. Après avoir créé le GWLBe, vous devez mettre à jour le routeur par défaut pour utiliser GWLBe pour le sous-réseau d’application et le tableau de routage par défaut. Pour en savoir plus, consultez https://docs.amazonaws.cn/en_us/vpc/latest/privatelink/create-endpoint-service-gwlbe.html.

Fournissez les paramètres comme collectés dans Paramètres d’entrée.

Une fois le déploiement du modèle réussi, vous devez valider que les fonctions Lambda et les événements CloudWatch sont créés. Par défaut, le groupe d’évolutivité automatique a le nombre minimal et maximal d’instances à zéro. Vous devez modifier le groupe d’évolutivité automatique dans la console AWS EC2 avec le nombre d'instances que vous souhaitez. Cela déclenchera les nouvelles instances ASA virtuel.

Nous vous recommandons de lancer une seule instance, de vérifier son flux de travail et de valider son comportement pour savoir si elle fonctionne comme prévu. Une fois que les exigences réelles de l’ASA virtuel peuvent être déployées, elle peuvent également vérifier le comportement. Le nombre minimal d’instances ASA virtuel peut être marqué comme protégé contre une évolutivité à la baisse pour éviter que ces dernières soient supprimées par les politiques d’évolutivité AWS.

Cette rubrique explique comment suspendre puis reprendre un ou plusieurs des processus d’évolutivité pour votre groupe d’évolutivité automatique.

Actions de début et de fin d’évolutivité

Pour commencer et arrêter les actions d’évolutivité à la hausse/baisse, procédez comme suit.

• Pour l’évolutivité dynamique d’AWS, consultez le lien suivant pour obtenir des renseignements afin d’activer ou de désactiver les actions d’évolutivité à la hausse :

  Suspension et reprise des processus d’évolutivité

Toutes les 60 minutes, une tâche CloudWatch Cron déclenche le gestionnaire d’évolutivité automatique Lambda pour le module d’intégrité

• S’il y a des adresses IP non intègres qui appartiennent à une machine virtuelle ASA virtuel valide, cette instance est supprimée si ASA virtuel date de plus d’une heure.

• Si ces adresses IP ne proviennent pas d’une machine ASA virtuel valide, seules les adresses IP sont supprimées du groupe de cibles.

Désactiver le moniteur d’intégrité

Pour désactiver un moniteur d’intégrité, dans constant.py, définissez la constante sur « True ».

Activer le moniteur d’intégrité

Pour activer un moniteur d’intégrité, dans constant.py, définissez la constante sur « False ».

Dans le cas peu probable où le crochet de cycle de vie doit être désactivé, s’il est désactivé, il n’ajoutera pas d’interfaces supplémentaires aux instances. Cela peut également entraîner une série d’échecs du déploiement des instances ASA virtuel.

Pour désactiver le gestionnaire d’évolutivité automatique Auto Scale Manager, les événements CloudWatch Events « notify-instance-lancement » et « notify-instance-terminal » doivent être désactivés. Cette désactivation ne déclenchera pas Lambda pour de nouveaux événements. Mais l’exécution des actions Lambda se poursuivra déjà. Il n’y a pas d’arrêt brutal d’Auto Scale Manager. La tentative d’arrêt brut par la suppression de la pile ou la suppression des ressources peut entraîner un état indéfini.

Comme l’équilibreur de charge AWS n’autorise pas les cibles de type instance pour les instances ayant plusieurs interfaces réseau, l’adresse IP de l’interface Gigabit0/1 est configurée comme cible sur les groupes de cibles. Pour l’instant, cependant, les contrôles d’intégrité de l’évolutivité automatique d’AWS ne fonctionnent que pour les cibles de type d’instance, et non pour les adresses IP. En outre, ces adresses IP ne sont pas automatiquement ajoutées ou supprimées des groupes cibles. Par conséquent, notre solution d’évolutivité automatique gère ces deux tâches de manière programmatique. Mais dans le cas d’une maintenance ou d’un dépannage, il pourrait y avoir une situation nécessitant un effort manuel.

Enregistrer une cible dans un groupe de cibles

Pour enregistrer l’instance ASA virtuel sur l’équilibreur de charge, son adresse IP d’instance Gigabit0/1 (sous-réseau externe) doit être ajoutée en tant que cible dans le ou les groupes de cibles. Consultez Enregistrer ou annuler l’enregistrement des cibles par adresse IP.

Annuler l’enregistrement d’une cible d’un groupe de cibles

Pour annuler l’enregistrement de l’instance ASA virtuel de l’équilibreur de charge, son adresse IP d’instance Gigabit0/1 (sous-réseau externe) doit être supprimée en tant que cible dans le ou les groupes de cibles. Consultez Enregistrer ou annuler l’enregistrement des cibles par adresse IP.

AWS n’autorise pas le redémarrage d’instance dans le groupe d’évolutivité automatique, mais il permet à un utilisateur de mettre une instance en veille et d’effectuer de telles actions. Cependant, cela fonctionne mieux lorsque les cibles de l’équilibreur de charges sont de type instance. Cependant, les machines ASA virtuel ne peuvent pas être configurées en tant que cibles de type instance, en raison de plusieurs interfaces réseau.

Mettre une instance en veille

Si une instance est mise en veille, son adresse IP dans les groupes de cibles continuera toujours d’être dans le même état jusqu’à ce que les sondes d’intégrité échouent. Pour cette raison, il est recommandé de désinscrire les adresses IP respectives du groupe cible avant de mettre l’instance en état de veille; consultez Annuler l’enregistrement d’une cible d’un groupe de cibles pour en savoir plus.

Une fois les IP supprimées, consultez Supprimer temporairement les instances de votre groupe d’évolutivité automatique.

Supprimer une instance de la mise en veille

De même, vous pouvez déplacer une instance de l’état de veille à l’état d’exécution. Après sa suppression de l’état de veille, l’adresse IP de l’instance doit être enregistrée sur les cibles du groupe cible. Consultez Enregistrer une cible dans un groupe de cibles.

Pour en savoir plus sur la mise en veille des instances à des fins de dépannage ou de maintenance, consultez le blogue d’actualités AWS.

Supprimer/dissocier l’instance du groupe d’évolutivité automatique

Pour supprimer une instance du groupe d’évolutivité automatique, vous devez d’abord la mettre en mode veille. Consultez la section « Mettre des instances en veille ». Une fois que l’instance est en état de veille, elle peut être supprimée ou dissociée. Consultez Dissocier les instances EC2 de votre groupe d’évolutivité automatique.

Pour mettre fin à une instance, elle doit être mise en veille; voir Instance en attente. Une fois que l’instance est en veille, vous pouvez procéder à la résiliation.

Pour éviter la suppression accidentelle d’une instance particulière du groupe d’évolutivité automatique, elle peut être protégée par l’évolutivité à la baisse. Si une instance est protégée par l’évolutivité à la baisse, elle ne sera pas résiliée en raison d’un événement d’évolutivité à la baisse.

Veuillez vous reporter au lien suivant pour mettre une instance en état protégé par l’évolutivité à la baisse.

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html

Important

Il est recommandé de faire en sorte que le nombre minimal d’instances qui sont intègres (l’adresse IP cible doit être intègre, pas seulement l’instance EC2) soit protégé par l’évolutivité à la baisse.

Toute modification de la configuration ne sera pas automatiquement reflétée sur les instances déjà en cours d’exécution. Ces modifications ne seront reflétées que sur les prochains périphériques intégrés. Toutes les modifications de ce type doivent être transférées manuellement vers les périphériques existants.

Si vous rencontrez des problèmes lors de la mise à jour manuelle de la configuration sur les instances existantes, nous vous recommandons de supprimer ces instances du groupe d’évolutivité et de les remplacer par de nouvelles.

Modifier le mot de passe d’administrateur ASA Virtuel

Une modification du mot de passe ASA virtuel oblige l’utilisateur à le modifier sur chaque périphérique manuellement pour les instances en cours d’exécution. Pour les nouveaux périphériques ASA virtuel à intégrer, le mot de passe ASA virtuel sera tiré des variables d'environnement Lambda. Consultez la section sur l’utilisation des variables d’environnement AWS Lambda.

Vous pouvez modifier de nombreuses choses dans AWS après le déploiement, telles que le groupe d’évolutivité automatique, la configuration de lancement, les événements CloudWatch, les politiques d’évolutivité, etc. Vous pouvez importer vos ressources dans une pile CloudFormation ou créer une nouvelle pile à partir de vos ressources existantes.

Consultez la section sur l’importation de ressources existantes dans Cloud Formation Management pour en savoir plus sur la gestion des modifications effectuées sur les ressources d’AWS.

Afin d’exporter les journaux CloudWatch, consultez la section Exporter les données du journal vers Amazon S3 à l’aide de l’interface de ligne de commande d’AWS.