Comme les précédentes années, Ippon Technologies participe à AWS re:invent. Nous étions cette année huit à parcourir les allées du re:invent pour rencontrer nos clients et partenaires et participer aux conférences.
Nous vous proposons un overview des sessions les plus intéressantes auxquelles nous avons participé.
Le chiffrement dans S3: comment ça marche?
Écrit par Chimon Sultan
Lors d’un Chalk Talk consacré aux mécanismes de chiffrement de S3, Sally Guo (Senior Development Engineer sur S3) et Will Cavin (Product Manager sur S3) ont présenté un tour d’horizon des options de chiffrement disponibles dans S3 et ont expliqué les mécanismes internes du système.
Depuis près de deux ans, tous les objets déposés sur S3 sont chiffrés par défaut. Si aucune méthode de chiffrement spécifique n’est précisée, l’objet est automatiquement chiffré avec une clé gérée par le service S3. Ce mécanisme est entièrement transparent pour l’utilisateur.
Mais ceci n’est qu’une des options de chiffrement offertes par le service. Le tableau ci-dessous présente les principales options proposées (il n’est pas exhaustif) :
Cependant, pour des données sensibles, il est préférable d’utiliser KMS et, dans ce cadre, de privilégier une Customer Managed Key plutôt qu’une AWS Managed Key. Bien que cette dernière bénéficie d’une rotation automatique par AWS, elle complique fortement les opérations, notamment lorsqu’il s’agit de partager des données. De plus, l’absence de contrôle sur les policies limite son intérêt.
Comment sont chiffrés les objets avec KMS ?
Détaillons les étapes opérées par le service S3 à chaque écriture d’un objet:
- Le client envoie une requête de type PUT à Amazon S3 pour stocker un objet avec le chiffrement KMS
- S3 envoie une requête à AWS KMS pour générer une clé de données. KMS génère une plaintext data key (clé en clair) et sa version chiffrée (ciphertext data key) en utilisant la clé KMS choisie.
- La plaintext data key est utilisée pour chiffrer directement les données de l'objet, produisant un ciphertext object (objet chiffré).
- La clé de données en clair (plaintext data key) est ensuite détruite.
- L’objet chiffré (ciphertext object) est stocké dans le bucket S3, accompagné de la ciphertext data key. Cette dernière sera nécessaire pour déchiffrer l'objet à l'avenir
- Lorsque le client demande à récupérer l’objet, S3 extrait la ciphertext data key associée et l’envoie à AWS KMS.
- AWS KMS déchiffre la ciphertext data key à l’aide de la clé principale KMS, récupérant la plaintext data key.
- La plaintext data key est utilisée pour déchiffrer l’objet, et les données en clair sont renvoyées au client.
Ce mécanisme permet de réduire les opérations de chiffrement prises en charge par KMS. Concrètement, KMS se limite à générer une clé et à la déchiffrer si nécessaire, tandis que le chiffrement et le déchiffrement de l’objet sont entièrement gérés par le service S3.
Cependant, ce fonctionnement par défaut présente un piège qui peut vite coûter cher : pour chaque nouveau fichier, S3 effectue un appel à KMS pour générer une data key. Or, ces appels à KMS sont très chers. Dans la plupart des cas, il est conseillé d’activer la fonctionnalité “bucket key” de S3. Cette option permet de mettre en cache la clé KMS dans S3, réduisant ainsi considérablement le nombre d’appels à KMS, ce qui diminue les coûts et améliore les performances.
On fera exception à cette recommandation dans les situation ou de strictes contraintes de conformité ou d’audit nécessitent la traçabilité offerte par KMS ou des rotations de clés très fréquentes.
Protégez vos ressources Cloud et On premise avec AWS Backup
Écrit par Tristan MICHE
Dans cette session de type Chalk Talk, nous avons revu la nécessité de disposer d’une stratégie de résilience et de protection de ses données pour couvrir les risques suivants:
- Défaillance techniques
- Catastrophe naturelle
- Actions humaines, erreurs ou malveillance
La suite AWS backup qui offre nativement une solution de protection centralisé pour les ressources sur AWS mais aussi on premise ce qui permet la mise en place d’une stratégie centralisée hybride. Celle-ci n’échappera pas au principe d’augmentation de la complexité conjointement à l’augmentation des bénéfices techniques de la solution. On recommandera une approche en plusieurs étapes:
- Etape “Baseline”
- Planification automatique de backup
- Alignement avec les objectifs de RPO
- Conservation de sauvegarde en local pour une restauration simple et rapide
- Etape “Advanced”
- Ajout d’une copie dans un autre compte et/ou dans une autre région
- Gestion centralisée de la solutions de backup ( Compte d’administration délégué, SCP, utilisation de l’intégration avec AWS Organization,...), protection des clés KMS.
- Etape “Advanced Plus”
- Automatisation des tests de restauration
- Auditabilité de la conformité des sauvegardes
- Utilisation d’un coffre de sauvegarde complémentaire de type Logically Air- gapped vault.
Quelques détails sur cette dernière fonctionnalité d’AWS backup. Les coffres Logically Air-gapped offre une sécurité renforcée et une protection accrue pour vos données de sauvegarde. Les principaux points à connaitre:
- Sécurité améliorée
- Données chiffrées automatiquement à l'aide de clés de chiffrement gérées par AWS, les sauvegardes doivent par contre être chiffrée par une CMK KMS.
- Vault Lock activée par défaut, garantissant des sauvegardes immuables.
- Sauvegardes protégées contre la suppression pendant toute leur période de rétention.
- Contrôles de rétention
- Définition obligatoire d’une périodes de rétention minimale et maximale.
- La période de rétention minimale doit être d'au moins 7 jours.
- Centralisation des accès
- Partage possible entre comptes AWS avec RAM
- Restauration directe des sauvegardes depuis les comptes partagés, réduisant le temps de restauration et évitant les copies intermédiaires.
Dernier point de cette session: les tests de restauration. AWS offre la possibilité de mettre en place une orchestration de ces tests souvents délaissés par la complexité engendrée. Voici les grandes étapes:
- Création de job de restauration: scope et planification
- Injection de paramètres depuis SSM directement dans les points de restauration
- Lancement de tests post-restauration, génration de reporting de conformité.
Retour d’expérience de l’équipe Incident Response d’AWS
Écrit par Chimon Sultan
La résilience et la gestion des incidents en production sont des sujets qui me passionnent. J’ai donc été ravi de participer à une discussion avec James Beaumont et Paul Moran d’AWS Enterprise Support sur leur approche pour gérer les incidents en production.
Nous avons exploré les 4 étapes clés du cycle de vie d’un incident : préparation, déclaration, réponse et enseignement.
Préparation
La préparation commence par la création d’applications robustes, mais elle inclut aussi la mise en place d’un monitoring et d’un alerting efficaces (gare au watermelon effect), mais aussi la répétition des procédures de gestion d’incidents.
Lors du lancement d’un service AWS, toutes les métriques sont centralisées. Certaines sont standards, communes à tous les services, tandis que d’autres sont spécifiques.
Pro tip 1 : Les meilleures métriques de monitoring pour détecter un incident mesurent soit l’impact utilisateur, soit les écarts par rapport aux valeurs normales. C’est des indicateurs métier comme le nombre de tickets support, les accès au health dashboard ou le volume de commandes, mais aussi des métriques techniques comme le nombre d’instances EC2 en fonctionnement.
Pro tip 2 : Exercez-vous à la résolution d’incidents et à la communication. Chez AWS, des exercices d’incidents sont réalisés, un peu comme les exercices d’évacuation incendie. L’alarme est déclenchée manuellement, et la réaction des équipes est observée, puis analysée.
L’introduction de Chaos Engineering aide aussi à s’exercer: cela permet de simuler des défaillances et d’habituer les équipes à les gérer.
Déclaration
Quand faut-il déclarer un incident ? Est-ce qu’un déploiement qui échoue et fait un rollback automatiquement est un incident ? Et une instance qui tombe mais redémarre grâce à l’autoscaling ? L’impact utilisateur est-il le seul critère ?
Pour l’équipe Incident Response d’AWS, un incident est tout événement qui perturbe de façon urgente le travail planifié. Par exemple, un release rollback entre dans cette définition, mais pas une perte d’instance si les mécanismes d’auto-rémédiation ont fonctionné comme prévu.
Chez AWS, l’équipe Incident Response coordonne la résolution de l’incident et gère la communication interne et externe. Elle déclenche les astreintes (on-call) des équipes services concernées.
Réponse
La réponse à un incident vise d’abord à réduire l’impact utilisateur, avec pour objectif une résolution rapide. Mais dans cette course, la communication ne doit pas être négligée.
La première erreur à éviter : paniquer. Cela peut conduire à des décisions précipitées. C’est là qu’une équipe dédiée est cruciale : elle est entraînée et diffuse les bonnes pratiques aux équipes impliquées.
Dès que des informations sont disponibles, elles sont communiquées au support. L’objectif est de répondre à la question clé des utilisateurs : Quand mon service sera-t-il rétabli ?
Enseignement
Une fois l’incident résolu, place à la rétrospective. L’objectif : identifier la cause racine (root cause) pour éviter une répétition et améliorer la réponse des équipes.
Pour cela, AWS utilise la méthode des 5 Whys : on pose successivement la question Pourquoi? jusqu’à remonter à la cause racine.
Voici un exemple simple des 5 Pourquoi :
Problème : Le site en production est tombé.
- Pourquoi ? L’instance de base de données est devenue inaccessible.
- Pourquoi ? Elle a manqué d’espace de stockage.
- Pourquoi ? L’auto-scaling du stockage n’était pas activé.
- Pourquoi ? Cela n’a pas été configuré lors de la création de la base.
- Pourquoi ? Il n’y avait pas de checklist pour configurer les ressources critiques.
Root cause : L’absence de checklist a entraîné une configuration incomplète, provoquant la panne.
Plan d’action :
- Créer et appliquer une checklist pour les ressources critiques AWS.
- Mettre en place des alertes sur les seuils d’utilisation du stockage.
- Revoir régulièrement les configurations AWS pour garantir leur conformité aux bonnes pratiques.
Les deux dernières actions ne découlent pas directement des Pourquoi mais répondent à des failles secondaires identifiées dans le processus.
Cette approche factuelle est essentielle pour instaurer une culture d’apprentissage et d’amélioration continue. Ici, on ne cherche pas à blâmer une personne ou une équipe, mais à identifier des failles dans le processus. Cette démarche, appelée blameless post-mortem, commence toujours par un rappel de ces principes pour garantir une coopération optimale et favoriser un retour constructif.
