Auditer en mode événementiel avec Amazon SNS/SQS et des consommateurs Rust : principes, mise en œuvre et enjeux

Par Emmanuel Forgues - 8 septembre 2025

Chapô – La traçabilité des actions étant devenue une exigence réglementaire et opérationnelle majeure, l’audit «<0xE2><0x80><0xAF>event‑driven<0xE2><0x80><0xAF>» s'est imposé comme une alternative aux logs traditionnels. En combinant les services de messagerie asynchrones d’AWS (SNS<0xE2><0x80><0xAF>+<0xE2><0x80><0xAF>SQS) avec des micro‑services écrits en Rust, les organisations peuvent construire un pipeline d’audit résilient, scalable et sécurisé. Cet article détaille le fonctionnement de cette architecture, analyse ses bénéfices et limites, puis propose une feuille de route pour les décideurs souhaitant l’adopter.

Publié initialement le 8 septembre 2025.

Mis à jour le 4 mai 2026.

Migré vers StratoSentry le 29 mai 2026.

Introduction : pourquoi repenser l’audit aujourd’hui ?

Les exigences de conformité (RGPD, PCI‑DSS, ISO<0xE2><0x80><0xAF>27001) imposent la conservation fiable d’événements métier et techniques. Les approches classiques reposent sur des fichiers de log centralisés ou sur des bases de données d’audit synchrones. Elles rencontrent rapidement leurs limites :

• Surcharge des systèmes producteurs – chaque transaction doit attendre que l’écriture du log se termine, impactant la latence.
• Scalabilité limitée – les volumes explosent (millions d’événements par seconde dans les architectures serverless ou IoT), rendant difficile le dimensionnement des serveurs de logs.
• Résilience fragile – une panne du service de collecte entraîne la perte d’événements critiques.

L’«<0xE2><0x80><0xAF>event‑driven auditing<0xE2><0x80><0xAF>» répond à ces problèmes en décorrélant la génération d’événement de son traitement, via un système de messagerie fiable. Amazon Simple Notification Service (SNS) et Simple Queue Service (SQS) offrent ce découplage : SNS diffuse les événements vers plusieurs abonnés, tandis que SQS assure le stockage temporaire, la persistance et le replay en cas d’échec. L’ajout de consommateurs écrits en Rust – langage réputé pour sa sûreté mémoire et ses performances proches du C<0xE2><0x80><0xAF>—<0xE2><0x80><0xAF>permet de traiter ces flux à très haut débit sans compromettre la sécurité.

Le détail de l’architecture cible, les choix techniques, le cadre de gouvernance et les implications organisationnelles sont présentés ci-après.

1. Concepts fondamentaux

1.1 Audit événementiel vs audit traditionnel

• Audit traditionnel : écriture synchrone dans un journal (log file, base SQL). Risque de perte d’événement si la transaction échoue avant l’écriture.
• Audit événementiel : chaque action déclenche un event publié sur un bus de messages. Le consommateur consomme le message, enrichit les métadonnées et persiste l’enregistrement dans une store d’audit (ex. S3, DynamoDB, Elasticsearch). La séparation garantit que la production n’est jamais bloquée.

1.2 Amazon SNS & SQS – comment fonctionnent-ils ?

• SNS (Simple Notification Service) est un service de publish/subscribe qui accepte des messages au format JSON ou texte et les transmet à un ou plusieurs abonnés (HTTP, Lambda, SQS, email…). Il assure la diffusion « fan‑out » avec une latence moyenne de < 100 ms dans la plupart des régions AWS [1].
• SQS (Simple Queue Service) est une file d’attente distribuée offrant au moins‑une‑fois la livraison et le visibility timeout pour éviter les doublons. Les files standards supportent un débit quasi illimité, alors que les files FIFO garantissent l’ordre et l’exactement‑une‑fois [2].

1.3 Rust – pourquoi choisir ce langage pour les consommateurs ?

• Sécurité mémoire grâce au système de possession (ownership) → élimination des dépassements de tampon et des fuites, cruciales en environnement d’audit où la fiabilité est primordiale [3].
• Performances comparables à C/C++ avec un temps de compilation rapide, facilitant le déploiement de micro‑services légers.
• Écosystème async/await mature (Tokio, async‑std) permettant de gérer des milliers de connexions SQS simultanées avec un faible overhead [4].

2. Architecture cible

2.1 Flux de données

2.2 Points de décision architecturaux

3. Mise en œuvre technique détaillée

3.1 Création et configuration du topic SNS

aws sns create-topic --name audit-events \
    --attributes DisplayName="AuditEvents",Policy='{"Version":"2012-10-17","Statement":[...]}'

• Politique IAM : autorise uniquement les services internes (ex. Lambda, EC2) à publier.
• Encryption : active le chiffrement côté serveur avec la CMK KMS alias/audit-key pour garantir la confidentialité des charges utiles.

3.2 Provisionnement des files SQS

aws sqs create-queue --queue-name audit-standard \
    --attributes VisibilityTimeout=30,MessageRetentionPeriod=1209600

aws sqs create-queue --queue-name audit-fifo \
    --attributes FifoQueue=true,ContentBasedDeduplication=true

• DLQ<0xE2><0x80><0xAF>: chaque file possède une file de lettres mortes (audit-standard-dlq) pour capter les messages non traités après 5 tentatives.

3.3 Abonnement SNS → SQS (via console ou CLI)

aws sns subscribe --topic-arn arn:aws:sns:eu-west-1:123456789012:audit-events \
    --protocol sqs --notification-endpoint arn:aws:sqs:eu-west-1:123456789012:audit-standard

• Policy SQS : ajoute la permission sns.amazonaws.com pour publier dans la file.

3.4 Consumer Rust – squelette de code

use aws_sdk_sqs::{Client, Error};
use tokio_stream::StreamExt;
use serde_json::Value;

#[tokio::main]
async fn main() -> Result<(), Error> {
    // Chargement des credentials via le provider par défaut (IAM role / env)
    let cfg = aws_config::load_from_env().await;
    let sqs = Client::new(&cfg);
    let queue_url = std::env::var("SQS_QUEUE_URL").expect("Missing SQS_QUEUE_URL");

// Long polling : 20<0xE2><0x80><0xAF>seconds
    let mut receive = sqs.receive_message()
        .queue_url(&queue_url)
        .max_number_of_messages(10)
        .wait_time_seconds(20)
        .into_stream();

while let Some(resp) = receive.next().await {
        let messages = resp?.messages.unwrap_or_default();
        for msg in messages {
            // Décodage JSON
            if let Ok(payload) = serde_json::from_str::<Value>(&msg.body.unwrap()) {
                process_audit_event(payload).await?;
            }
            // Suppression du message après traitement réussi
            sqs.delete_message()
                .queue_url(&queue_url)
                .receipt_handle(msg.receipt_handle.unwrap())
                .send()
                .await?;
        }
    }

Ok(())
}

async fn process_audit_event(event: Value) -> Result<(), Box<dyn std::error::Error>> {
    // Exemple d’enrichissement : horodatage ISO‑8601, signature HMAC
    let mut enriched = event.clone();
    enriched["processed_at"] = chrono::Utc::now().to_rfc3339().into();

// Persistance dans S3 (simplifié)
    let s3_client = aws_sdk_s3::Client::new(&aws_config::load_from_env().await);
    let key = format!("audit/{}/{}.json",
        enriched["entity_type"], enriched["event_id"]);
    s3_client.put_object()
        .bucket("my-audit-bucket")
        .key(key)
        .body(serde_json::to_string(&enriched)?.into_bytes().into())
        .send()
        .await?;
    Ok(())
}

• Gestion des erreurs : l'opérateur ? transmet l’erreur à la boucle principale. En cas d’échec, le message n'est pas supprimé et sera re-livré après le visibility timeout.
• Scalabilité : plusieurs instances du binaire peuvent être déployées via ECS/Fargate ou Kubernetes sur la même file SQS.

3.5 Sécurisation du pipeline

4. Bénéfices concrets pour l’entreprise

5. Contraintes, risques et points de vigilance

5.1 Gestion des duplications

SNS/SQS offrent au moins‑une‑fois la livraison; les consommateurs doivent être idempotents. La clé primaire (ex. event_id) doit être utilisée comme identifiant unique dans le store d’audit pour éviter les doublons.

5.2 Limites de taille des messages

SNS impose une charge utile maximale de 256 KB [1]; au‑delà, il faut envisager un pre‑upload vers S3 et transmettre uniquement l’URL dans le message (pattern “large payload”).

5.3 Latence de persistance finale

Le délai entre la génération d’un événement et son écriture définitive dans le store dépend du temps de traitement du consumer. Dans les scénarios critiques, il faut dimensionner le nombre d’instances pour respecter un SLA (< 1 s).

5.4 Coût de rétention à long terme

Conserver des billions d’événements pendant plusieurs années peut devenir onéreux en S3/Glacier. Une politique de tiering (Hot → Warm → Cold) doit être mise en place, ainsi qu’une gouvernance de purge conforme aux exigences légales.

5.5 Sécurité du canal inter‑services

Même si le trafic est chiffré TLS, un Man‑in‑the‑Middle interne ou une mauvaise configuration IAM peut exposer les messages. L’usage d’VPC endpoints pour SNS/SQS et de resource policies restrictives réduit ce risque.

5.6 Dépendance au fournisseur cloud

L’architecture repose entièrement sur AWS; la migration vers un autre cloud nécessite le remplacement de SNS/SQS par des équivalents (Google Pub/Sub, Azure Service Bus) et la réécriture du code d’intégration. Une abstraction via une couche « event‑bus » (ex. Kafka, NATS) peut limiter ce lock‑in.

6. Cas d’usage réaliste : audit des transactions financières d’une fintech

Contexte – Une startup de services bancaires en ligne traite plus de 1,2<0xE2><0x80><0xAF>M de paiements par jour et doit respecter les exigences PCI‑DSS 3.2 (journalisation immuable).

Implémentation :

Résultats (période de 30<0xE2><0x80><0xAF>jours) :

• Temps moyen entre paiement et persistance d’audit : 0,68 s (vs 2,4 s avec écriture synchrone).
• Aucun incident de perte d’événement grâce à la réplication multi‑AZ de SQS.
• Coût mensuel du pipeline d’audit : ≈ 850 $, contre ≈ 3 200 $ pour l’ancienne solution log‑centralisée.

7. Décisions opérationnelles et feuille de route

7.1 Étapes clés de déploiement

7.2 Indicateurs de succès (KPIs)

• **% d’événements traités dans le SLA (< 1 s

Poursuivre le parcours : La preuve numérique immuable → Solution → Produit → Demander une démonstration

Retour au blog