Architecture Overview - ProbatioVault Backend¶

Architecture modulaire hexagonale avec NestJS

← Retour refs

Vue d'ensemble¶

Le backend ProbatioVault est construit avec NestJS et suit une architecture modulaire hexagonale. Chaque module est indépendant et communique via des interfaces bien définies.

Architecture globale¶

┌─────────────────────────────────────────────────────────────┐
│                     API Gateway (NestJS)                     │
│                  REST API + Swagger + JWT                    │
└────────────────────────┬────────────────────────────────────┘
                         │
         ┌───────────────┼───────────────┐
         │               │               │
┌────────▼────────┐ ┌───▼────────┐ ┌───▼────────┐
│  Auth Module    │ │  Documents │ │   Crypto   │
│  (SRP-6a+JWT)   │ │   Module   │ │   Module   │
└─────────────────┘ └────┬───────┘ └────┬───────┘
                         │               │
         ┌───────────────┼───────────────┼───────────┐
         │               │               │           │
┌────────▼────────┐ ┌───▼────────┐ ┌───▼────────┐ ┌▼────────┐
│  Audit Module   │ │  Storage   │ │ Blockchain │ │  Jobs   │
│  (Append-only)  │ │  (S3/Glac) │ │  (Merkle)  │ │ (BullMQ)│
└─────────────────┘ └────────────┘ └────────────┘ └─────────┘
         │               │               │           │
         └───────────────┼───────────────┼───────────┘
                         │               │
                ┌────────▼────────┐ ┌───▼────────┐
                │   PostgreSQL    │ │   Redis    │
                │   (Metadata)    │ │  (Cache)   │
                └─────────────────┘ └────────────┘
                         │
                ┌────────▼────────┐
                │  OVH S3 / AWS   │
                │  Object Storage │
                └─────────────────┘

Modules principaux¶

1. Auth Module¶

• Responsabilité : Authentification Zero-Knowledge (SRP-6a) + JWT
• Technologies : Passport.js, JWT
• Dépendances : Crypto Module
• Endpoints : /auth/register, /auth/login

2. Crypto Module¶

• Responsabilité : Services cryptographiques (hash, encryption, HKDF, keys)
• Technologies : js-sha3, Node.js crypto
• Conformité : NIST FIPS 202 (SHA3-256)
• Services :
• HashService : Hash probatoire SHA3-256
• EncryptionService : AES-256-GCM
• HkdfService : Dérivation de clés
• KeysService : Gestion clés

3. Documents Module¶

• Responsabilité : CRUD documents probatoires
• Technologies : TypeORM, PostgreSQL
• Dépendances : Crypto, Storage, Audit
• Endpoints : /documents/*

4. Audit Module¶

• Responsabilité : Journalisation immuable (append-only)
• Technologies : TypeORM, PostgreSQL
• Conformité : NF Z42-013

5. Storage Module¶

• Responsabilité : Interface S3/Glacier
• Technologies : AWS SDK
• Providers : OVH Object Storage, AWS Glacier

6. Blockchain Module¶

• Responsabilité : Arbres de Merkle + ancrage blockchain
• Technologies : SHA3-256, Web3 (futur)
• Services :
• MerkleService : Construction arbres + preuves
• AnchorService : Ancrage blockchain

7. Jobs Module¶

• Responsabilité : Tâches asynchrones
• Technologies : BullMQ, Redis
• Use cases : Archivage, ancrage, nettoyage

Flux de données typique¶

Upload d'un document¶

Client → Upload doc.enc
    ↓
Controller (validation JWT)
    ↓
DocumentsService
    ├→ HashService.hashDocument(doc.enc) → hash_doc
    ├→ StorageService.upload(doc.enc) → s3_key
    ├→ AuditService.logEvent("UPLOAD")
    └→ PostgreSQL.save(metadata + hash_doc)
    ↓
Response: { doc_id, hash_doc }

Vérification d'intégrité¶

Client → GET /documents/:id/verify
    ↓
DocumentsService.verifyIntegrity()
    ├→ PostgreSQL.getDocument(id) → hash_doc_stored
    ├→ StorageService.download(s3_key) → doc.enc
    ├→ HashService.hashDocument(doc.enc) → hash_doc_computed
    └→ Compare hash_doc_stored === hash_doc_computed
    ↓
Response: { isValid: true/false }

Principes d'architecture¶

1. Separation of Concerns¶

• Chaque module a une responsabilité unique
• Pas de couplage fort entre modules
• Communication via interfaces

2. Dependency Injection¶

• Injection native de NestJS
• Testabilité maximale
• Découplage des dépendances

3. Security by Design¶

• Validation stricte des inputs (class-validator)
• Guards pour protection des routes
• Audit trail pour traçabilité
• Pas de données sensibles en logs

4. Scalability¶

• Architecture modulaire permettant microservices
• Jobs asynchrones (BullMQ)
• Cache Redis pour performances
• Streaming pour gros fichiers

5. Testability¶

• 100% des services mockables
• Tests unitaires + intégration + E2E
• Couverture > 85%

Technologies utilisées¶

Stockage : Redis vs DynamoDB¶

Le projet utilise deux systèmes de stockage clé-valeur pour des usages distincts :

Pourquoi DynamoDB pour le HSM Monitor ?¶

La Lambda AWS HSM Monitor (PD-36) ne peut pas accéder au Redis du VPS OVH car :

• Lambda s'exécute dans le VPC AWS, isolé du réseau OVH
• Exposer Redis sur Internet serait un risque de sécurité
• DynamoDB est accessible depuis Lambda ET depuis CI/CD via AWS CLI
• Coût négligeable (~$0.25/mois) pour un usage faible

Références :

• Documentation DynamoDB
• User Story PD-36

Conformité & Standards¶

• NIST FIPS 202 : SHA3-256 pour hash probatoires
• NF Z42-013 : Archivage électronique
• ISO 14641 : Conservation de l'information
• RGPD : Protection données personnelles
• OWASP Top 10 : Sécurité applicative

Prochaines évolutions¶

• Migration vers microservices (si nécessaire)
• Support GraphQL (optionnel)
• WebSockets pour notifications temps réel
• Clustering pour haute disponibilité
• Kubernetes deployment

Références¶

• Database Configuration
• Cryptographie
• Architecture Decision Records
• User Stories

← Retour refs