Mise en place d'une stack entière de gestion des patchs sur votre infrastructure.
Partie 1/2 - Mise en place
Notion
AWS Systems Manager (SSM) patch management est une fonctionnalité du service AWS Systems Manager vous permettant de gérer le déploiement de correctifs sur votre infrastructure.
Pre-requis :
Les différentes instances EC2 doivent posséder l'agent SSM. A noter que les agents sont déjà installés dans les images amazon linux.
Elles doivent aussi avoir un rôle (lié à un profile instance) contenant une policy donnant droit à l'utilisation de SSM (AmazonEC2RoleforSSM (rôle) deprecated - AmazonSSMManagedInstanceCore (Policy))
Fonctionnement (2 composants principaux):
Maintenance Windows
La maintenance windows comprend 3 paramètres :
- La maintenance windows elle même, qui renseigne le moment à laquelle les mises à jour vont être lancées.
- Les targets qui sont les cibles de la maintenance windows, déterminées si elles matchent avec des tags que l’on va définir (key : Patch Group ; value : ${name patch group}).
- La task qui peut être un “scan” ou une “install” (d'autres tasks “pré-install” ou “post” existent également mais ne seront pas détaillées dans cet article).
Patch Baseline
Un patch baseline est la configuration des patchs que l'on veut appliquer. Il ne peut contenir qu'un seul OS.
Celui-ci comporte 4 paramètres :
- La classification, qui est la catégorie de patch que l'on veut appliquer (“security”, “applicatif” par exemple).
- La sévérité des différents correctifs (critical, medium, low etc).
- L'approbation automatique correspondant au délai d'attente avant l'application du patch à partir de sa date de sortie sur AWS.
- Le niveau de conformité qui se rapporte au service Config notamment. Cela nous permettra de définir à quel point une ressource est non conforme si des patches seraient manquants (critical, high, medium...).
Le Patch Baseline est ensuite rattaché à un Patch Group (que l'on défini ensuite dans les tags de la Maintenance Windows)
On retrouve ici :
Maintenance Windows : CRON
Target : Tag
Task: Patching (scan/install, ou d’autre tâche en exemple, à ordonnancer)
Le Patch Baseline : Caractéristique du correctif.
Le Patch Group : Rattaché au patch baseline. Son nom doit être le même que la valeur du tag “Patch Group” sur l’instance.
Diagramme séquentiel
Tout d'abord la Maintenance Windows se lance à l'heure et la date renseignée, puis elle entame les différentes tâches dans l'ordre en suivant les différentes options. Ces tâches se lancent sur les targets qui matchent les tags positionnés sur les instances EC2.
Par exemple pour l'OS windows, dans la tâche “Run-PatchBaseline”, lancée par la maintenance windows (cron), les targets sont les instances qui ont le tag "windows-prod". Le “Run-PatchBaseline” va appliqué le patch group qui aura le même nom. Celui-ci est rattaché à une Baseline qui va appliquer les patchs. Une fois les patchs passés, les statuts qui en émanent sont stockés dans le "System Manager Inventory" et le niveau de conformité peut être envoyé dans le service "AWS Config", à condition que la “rule” soit activée (ils existent des règles sur AWS Config pré-écrite par AWS, par défaut celles-ci ne sont pas actives).
Planification
Nous pouvons prévoir un planning par défaut, ainsi que des fenêtres de maintenance spécifiques pour des stacks particulières.
Partons du principe que nous avons plusieurs environnements, la PRODUCTION et la HORS PRODUCTION.
Les patchs peuvent avoir une influence sur le fonctionnement des vos instances et impacter les services qui s'y trouvent. Il est donc important de bien choisir la catégorie de correctif que vous voulez appliquer. Ici on se concentre seulement sur les correctifs de sécurité qui dans des rares cas impactent les applications.
A l’heure d’appliquer les patches, deux types de tâches existent. Il y a les “Scan” et les “Install”.
- Le Scan consiste simplement à lister les packages manquant de la catégorie et la sévérité demandée en y associant un niveau de conformité.
- L’Install permet l'application de ces correctifs. En toute circonstance il est possible de choisir l'auto-reboot (obligatoire ou "si nécessaire").
En linux ou sous windows, après un patching, un redémarrage peut être requis pour la prise en compte de certains correctifs. Par défaut l’auto-reboot n’est pas conseillé, il se fait à l'appréciation de chaque équipe de soit créer une fenêtre de maintenance personnalisée avec auto-reboot soit de redémarrer à la main aux heures qui conviennent.
Les scans eux, peuvent être lancés tous les jours afin d'avoir le niveau de conformité le plus exact possible.
Par précaution, les correctifs seront appliqués dans un premier temps sur la hors-production, et ensuite sur la production. Pour ce faire, ils sont appliqués du lundi au vendredi sur la hors-production, tous les lundis sur la production sous linux et tous les mercredis sous windows (les correctifs sortent les mercredis généralement sous windows).
Pour s'assurer qu'un correctif sorti le vendredi sur la hors-production ne s'applique pas le lundi sur la production, on combine avec l’approbation automatique mit à 7 jours (à changer selon votre propre appréciation), ainsi il y aura forcément un délai d'une semaine avant d’appliquer ce correctif en production.
Il peut y avoir des divergences d'opinion sur le fait de mettre des jours d'attente avant l'application d'un correctif de sécurité de type critique, c'est pourquoi il est bon de vous mettre d'accord sur la politique de mise à jour que vous voulez mettre en place.
Pour aller plus loin
L’auto-approbation ne fonctionne pas pour certains OS ce qui fait que les correctifs seront appliqués immédiatement. Documentation AWS
Les logs liés au patching peuvent être déposés dans un bucket S3. A noter cependant qu’il n'est pas aisé de faire des recherches directement dedans car les chemins ont des noms hasardeux qui ne sont pas datés. Il est suggéré de mettre en place un système d'ingestion de logs sur un outil plus “user friendly”.
Patch group par défaut : Pour une instance, si vous ne créez pas de patch group personnalisé qui match avec le tag approprié, celle-ci se verra appliquer le patch group par défaut d'AWS qui contient sa propre configuration en termes de catégorie et de sévérité.
CentOS ne gère pas la catégorisation et la sévérité de correctif, ainsi même si vous filtrez sur des catégories ou sévérités de correctif, tous les correctifs seront appliqués.
Si vous optez pour la création d'images avant patching, il faut mettre en place un système de rétention (via une lambda par exemple) afin d’éviter les surcoûts. Les images sont liées à des snapshots et chacun est lié à un volume, ce qui rend très cher le stockage.
Nous verrons dans un prochain article la façon dont on peut superviser l’implémentation et le bon déroulement de cette nouvelle stack de patch management.
