Nex Docs

Appearance

StableAudienceOpsSécuritéAudit banqueOwner@platform-opsDernière revue2026-05-22

Infra de base — Data ​

Phases 4 à 6 du déploiement infrastructure : RDS PostgreSQL, ElastiCache Redis, S3 buckets. Pour la vue d'ensemble, voir Infra de base — overview.

PHASE 4 — RDS POSTGRESQL ​

Objectif ​

Base de données relationnelle pour les 10 services qui en ont besoin (tous sauf logs-reporting).

Instructions pour l'agent ​

Créer le module infrastructure/terraform/modules/rds/.

Instance RDS :

  • Engine : PostgreSQL 16.13
  • Instance class : db.t3.small (staging)
  • Stockage : 20 Go gp3, auto-scaling jusqu'à 100 Go
  • Multi-AZ : non en staging, oui en production
  • Subnet group : subnets data_a et data_b
  • Security group : sg-rds
  • Backup : automatique, rétention 30 jours, fenêtre 03:00-04:00 UTC
  • Maintenance : dimanche 04:00-05:00 UTC
  • Encryption at rest : activé (KMS par défaut)
  • Public accessible : non
  • Deletion protection : activé
  • Performance Insights : activé (7 jours de rétention, gratuit sur db.t3.small)
  • Master username : nex_admin
  • Master password : généré par Terraform (random_password), stocké dans Doppler

Parameter Group PostgreSQL 16 (nex-staging-postgres16) :

  • log_statement = 'all' (staging seulement — pour le debug). En production : 'ddl'
  • log_min_duration_statement = 1000 (log les requêtes lentes > 1s)
  • shared_preload_libraries = 'pg_stat_statements' (monitoring des requêtes)
  • max_connections = 200 (11 services × ~10 connexions + marge)

Post-création — initialisation :

L'agent doit générer un script infrastructure/scripts/seed-database.sh qui :

  1. Se connecte via kubectl port-forward (pas de bastion)
  2. Crée un utilisateur applicatif nex_app avec un mot de passe depuis Doppler
  3. Crée la base nex_staging
  4. Accorde les droits SELECT, INSERT, UPDATE, DELETE à nex_app (pas de DROP, pas de ALTER schema — moindre privilège)
  5. Configure les default privileges pour les futures tables

Note : En l'état actuel du déploiement, les services se connectent avec nex_admin (le master user). La migration vers nex_app est prévue mais pas encore effectuée. Le script seed-database.sh existe dans infrastructure/scripts/ et doit être exécuté pour créer le user applicatif, puis les variables Doppler POSTGRES_USER et POSTGRES_PASSWORD doivent être mises à jour.

Recommandations :

  • Une seule instance RDS pour tous les services en staging. Chaque service utilise son propre schema dans la même base pour l'isolation logique (ex: auth, orchestrator, notification, ledger_wallets, etc.).
  • Le master user nex_admin ne doit jamais être utilisé par les applications en production. Uniquement pour l'administration et les migrations.
  • Activer Performance Insights (gratuit sur db.t3.small avec 7 jours de rétention) pour monitorer les requêtes lentes.

Validation ​

bash
# Instance disponible
aws rds describe-db-instances --db-instance-identifier nex-staging-postgres \
  --query "DBInstances[0].DBInstanceStatus" --region eu-west-3
# Attendu : available

# Encryption activée
aws rds describe-db-instances --db-instance-identifier nex-staging-postgres \
  --query "DBInstances[0].StorageEncrypted" --region eu-west-3
# Attendu : True

# Connexion depuis un pod (après EKS déployé) — nécessite SSL
kubectl run pg-test --rm -it --image=postgres:16-alpine -n nex-staging -- \
  psql "host=<RDS_ENDPOINT> user=nex_admin dbname=nex_staging sslmode=require" -c "SELECT version();"

PHASE 5 — ELASTICACHE REDIS ​

Objectif ​

Cache pour auth (sessions, tokens), notifications (BullMQ queues) et service-catalog (cache réponses). Aussi utilisable comme messaging léger via Redis Streams si besoin.

Instructions pour l'agent ​

Créer le module infrastructure/terraform/modules/redis/.

Replication Group :

  • Engine : Redis 7.1
  • Node type : cache.t3.micro (staging)
  • Nombre de nœuds : 1 en staging, 2 en production (Multi-AZ)
  • Automatic failover : désactivé en staging, activé en prod
  • Transit encryption (TLS) : activé
  • At-rest encryption : activé
  • Auth token : généré (64 chars, pas de caractères spéciaux), stocké dans Doppler
  • Subnet group : subnets data_a et data_b
  • Security group : sg-redis
  • Maintenance : dimanche 05:00-06:00 UTC
  • Snapshot window : 02:00-03:00 UTC
  • Snapshot retention : 7 jours

Recommandations :

  • Même si seuls auth, notifications (BullMQ) et service-catalog utilisent Redis aujourd'hui, d'autres services pourraient en avoir besoin (rate limiting, cache de config, queues). L'instance est partagée — utiliser des prefixes de clés par service (auth:session:xxx, catalog:cache:xxx).
  • Le TLS est important : les tokens de session transitent par Redis. Sans TLS un attaquant sur le réseau pourrait les intercepter.

Validation ​

bash
# Instance disponible
aws elasticache describe-replication-groups --replication-group-id nex-staging-redis \
  --query "ReplicationGroups[0].Status" --region eu-west-3
# Attendu : available

# Connexion depuis un pod (après EKS déployé) — nécessite TLS + auth token
kubectl run redis-test --rm -it --image=redis:7-alpine -n nex-staging -- \
  redis-cli -h <REDIS_ENDPOINT> -p 6379 --tls -a <AUTH_TOKEN> PING
# Attendu : PONG

PHASE 6 — S3 BUCKETS ​

Objectif ​

Stockage pour les backups de base de données et l'archivage réglementaire. Les fichiers utilisateurs restent sur Firebase Storage (géré par file-service).

Instructions pour l'agent ​

Créer le module infrastructure/terraform/modules/s3/.

Bucket nex-staging-backups :

  • Encryption : AES-256
  • Versioning : activé
  • Block public access : tout bloqué (4 flags à true)
  • Lifecycle rules :
    • Objets > 30 jours → transition vers S3 Glacier
    • Objets > 365 jours → transition vers S3 Glacier Deep Archive
    • Versions non-courantes > 90 jours → supprimées

Bucket nex-terraform-state-<ACCOUNT_ID> (déjà créé en phase 1 — vérifier la config).

Recommandations :

  • Pas de bucket uploads côté AWS — les fichiers utilisateurs sont sur Firebase Storage. Ça évite de dupliquer les coûts et la complexité.
  • En production, activer la réplication cross-région du bucket backups vers eu-west-1 (Irlande). En staging ce n'est pas nécessaire.
  • Créer un rôle IAM dédié pour les backups RDS qui écrivent dans ce bucket (IRSA — IAM Roles for Service Accounts).

Validation ​

bash
aws s3 ls | grep nex-staging-backups
# Le bucket existe

aws s3api get-bucket-encryption --bucket nex-staging-backups --region eu-west-3
# AES256

aws s3api get-public-access-block --bucket nex-staging-backups --region eu-west-3
# Tout à true

Nex — Plateforme fintech CEMAC