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.