Cours Aws

6.73 Stratégie de sécurité ELASTICACHE

ElastiCache prend en charge le chiffrement SSL en transit mais ne supporte pas l'authentification IAM côté données. Question piège classique : les politiques IAM sur ElastiCache ne s'appliquent qu'à la couche API AWS (création, modification, suppression du cluster) et non aux commandes envoyées par les applications. L'authentification au niveau Redis se fait par mot de passe (Redis AUTH), défini à la création du cluster. Memcached propose une authentification avancée basée sur SASL.

Modèles de mise en cache

Trois modèles principaux existent. Le lazy loading (chargement passif) : à la première requête, l'application interroge la base, écrit le résultat dans le cache et le sert. Les requêtes suivantes sur la même clé sont servies par le cache. Limite : si la donnée change en base et que le cache n'est pas invalidé, le cache sert une donnée périmée. Le write-through (écriture directe) : toute écriture en base est aussi écrite dans le cache, ce qui garantit la fraîcheur au prix d'un coût d'écriture. Le session store : les sessions utilisateurs sont stockées avec un TTL et purgées à expiration.

  • Chiffrement en transit via SSL/TLS activable à la création
  • Chiffrement au repos via KMS
  • Redis AUTH : mot de passe obligatoire pour les clients
  • SASL pour Memcached (fonctionnalité avancée)
  • Security Groups pour isoler le cluster au sein du VPC
  • IAM uniquement pour les opérations d'administration AWS

Pour illustrer le lazy loading : un utilisateur interroge l'application, qui interroge d'abord ElastiCache. Si la clé est en cache, la réponse vient du cache sans solliciter RDS. Sinon, l'application interroge RDS, écrit le résultat dans le cache, puis répond. À la requête suivante, la donnée est déjà en cache. Comme le dit l'adage, les deux problèmes difficiles en informatique sont l'invalidation du cache et le nommage des choses ; le choix d'un modèle de cache doit prendre cela au sérieux.

En résumé

Cette leçon présente une stratégie de sécurité complète pour ElastiCache, couvrant le cryptage SSL, l'authentification par mot de passe et les groupes de sécurité AWS. Elle explique également les trois modèles de gestion du cache (Lazy Loading, Write-Through et Session Store) et détaille le fonctionnement du chargement passif, où les données manquantes sont interrogées auprès de la base de données puis mises en cache pour les requêtes suivantes.

Points clés

  • Cryptage SSL obligatoire et authentification par mot de passe défini à la création du cluster ElastiCache
  • Les politiques IAM sur ElastiCache ne s'appliquent qu'au niveau AWS (commandes et applications), pas à l'authentification du cache lui-même
  • Modèle Lazy Loading : le cache est alimenté à la demande — les données manquantes sont lues depuis la base de données puis enregistrées dans le cache
  • Modèle Write-Through : toutes les données écrites en base sont automatiquement mises à jour dans le cache pour éviter les données obsolètes
  • Modèle Session Store : stockage temporaire des données de session avec expiration automatique
  • Groupe de sécurité et chiffrement SSL combinés forment la défense périmétrale d'une instance ElastiCache

Questions fréquentes

Pourquoi l'authentification IAM ne peut-elle pas être utilisée directement sur ElastiCache ?

ElastiCache n'intègre pas IAM pour l'authentification du cache lui-même. Les politiques IAM s'appliquent uniquement au niveau AWS pour sécuriser les commandes et les appels d'application. L'authentification du cache repose sur un mot de passe défini à la création du cluster.

Quel est l'inconvénient principal du modèle Lazy Loading ?

Le principal risque est que les données en cache deviennent obsolètes si la base de données est mise à jour sans que le cache soit invalidé. Les utilisateurs obtiendraient alors des données périmées jusqu'à la prochaine requête et rechargement du cache.

En quoi le modèle Write-Through diffère-t-il du Lazy Loading ?

Contrairement au Lazy Loading où le cache est mis à jour à la demande, Write-Through met à jour automatiquement le cache chaque fois qu'une données est écrite en base. Cela garantit que le cache reste toujours synchronisé avec la base de données sans données obsolètes.