Architecture de Sécurité
La solution de cashback nouvelle génération
INTRODUCTION
1.1 Objectif du Document
Ce document décrit l'architecture de sécurité globale de la plateforme REWAPP. Il présente les différentes couches de protection mises en œuvre pour garantir la confidentialité, l'intégrité et la disponibilité des données et des services.
DÉFENSE EN PROFONDEUR
L'architecture de sécurité REWAPP est conçue selon le principe de défense en profondeur, avec des mesures de protection à chaque niveau de l'infrastructure et des applications.
1.2 Périmètre
Cette architecture couvre l'ensemble de l'écosystème REWAPP :
- Application Mobile (iOS/Android) : interface utilisateur pour les clients finaux
- Site Vitrine (Next.js) : présentation de l'offre et inscription
- Dashboard Admin (React) : gestion globale de la plateforme
- Dashboard Partenaire (React PWA) : interface pour les commerçants
- Backend API (NestJS) : services métier et gestion des données
- Infrastructure Cloud (AWS) : hébergement et services managés
1.3 Documents de Référence
Documents Connexes
| Référence | Titre | Description |
|---|---|---|
6.1 |
Document de Sécurité | Vue d'ensemble sécurité, menaces, contre-mesures |
6.2.1 |
Authentification et Autorisation | Mécanismes d'authentification, RBAC, sessions |
6.2.2 |
Protection des Données (CSRF/XSS) | Protection contre les attaques web |
6.2.3 |
Rate Limiting et Throttling | Contrôle du trafic et protection contre les abus |
6.3 |
Conformité RGPD | Traitements, consentements, droits utilisateurs |
6.4 |
Conformité PCI DSS | Exigences bancaires et tokenisation |
6.5 |
Politique de Gestion des Données | Rétention, suppression, archivage |
6.6 |
Sécurité QR Codes | Signature, validation, anti-fraude |
VUE D'ENSEMBLE DE L'ARCHITECTURE DE SÉCURITÉ
2.1 Principes Fondamentaux
L'architecture de sécurité REWAPP repose sur les principes suivants :
Principes de Sécurité
| Principe | Description | Application REWAPP |
|---|---|---|
| Défense en profondeur | Plusieurs couches de sécurité indépendantes | Firewall → WAF → API Gateway → Auth → Validation |
| Moindre privilège | Accès minimum nécessaire pour chaque rôle | RBAC strict, scopes OAuth2 limités |
| Séparation des responsabilités | Isolation des composants critiques | Microservices isolés, VPC segmentée |
| Sécurité par défaut | Configuration sécurisée par défaut | HTTPS obligatoire, headers de sécurité |
| Traçabilité complète | Audit trail de toutes les actions | Logs centralisés, audit des accès sensibles |
| Fail-safe | Comportement sécurisé en cas d'erreur | Deny by default, circuit breakers |
2.2 Modèle de Défense en Profondeur
Le modèle de défense en profondeur REWAPP comprend 6 couches de sécurité :
Couches de Sécurité
| Couche | Niveau | Technologies | Protection |
|---|---|---|---|
| 1. Périmétrique | Externe | AWS Shield, CloudFront WAF |
DDoS, attaques volumétriques |
| 2. Réseau | Infrastructure | VPC, Security Groups, NACLs |
Accès non autorisés, segmentation |
| 3. Application | Services | NestJS Guards, Middleware |
Auth, validation, injection |
| 4. Données | Stockage | AES-256, TLS 1.3, KMS |
Confidentialité, intégrité |
| 5. Identité | Accès | JWT RS256, 2FA, Biométrie |
Usurpation, accès non autorisé |
| 6. Monitoring | Détection | CloudWatch, Sentry, WAF Logs |
Intrusion, anomalies |
2.3 Schéma Conceptuel
Architecture de sécurité en couches :
[INTERNET]
|
v
+------------------------+
| AWS Shield (DDoS) | ← Couche 1 : Protection périmétrique
+------------------------+
|
v
+------------------------+
| CloudFront + WAF | ← Filtrage des requêtes malveillantes
+------------------------+
|
v
+------------------------+
| API Gateway (Kong) | ← Couche 2 : Rate limiting, auth
+------------------------+
|
v
+------------------------+
| VPC Privée | ← Couche 3 : Isolation réseau
| +------------------+ |
| | NestJS Backend | | ← Couche 4 : Validation applicative
| +------------------+ |
| +------------------+ |
| | PostgreSQL (RDS) | | ← Couche 5 : Chiffrement données
| +------------------+ |
+------------------------+
SÉCURITÉ PÉRIMÉTRIQUE
3.1 Firewall et WAF (Web Application Firewall)
AWS WAF est déployé au niveau de CloudFront et de l'API Gateway pour filtrer le trafic malveillant.
Règles WAF
| Règle WAF | Description | Action |
|---|---|---|
| SQL Injection | Détection des patterns d'injection SQL | Block |
| XSS | Détection des scripts malveillants | Block |
| Path Traversal | Tentatives d'accès aux fichiers système | Block |
| Bad Bots | Blocage des bots malveillants connus | Block |
| Geo Blocking | Restriction géographique (France, Belgique, Suisse) | Allow/Block |
| Rate-Based | Limitation par IP (1000 req/5min) | Block temp. |
| Custom Rules | Règles métier spécifiques REWAPP | Configurable |
// Configuration WAF AWS
{
"Name": "REWAPP-WAF-Rules",
"Rules": [
{
"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 1,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet"
}
},
"OverrideAction": { "None": {} }
},
{
"Name": "AWSManagedRulesSQLiRuleSet",
"Priority": 2,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesSQLiRuleSet"
}
},
"OverrideAction": { "None": {} }
}
]
}
3.2 Protection DDoS
AWS Shield Advanced est activé pour protéger contre les attaques DDoS.
Protection DDoS
| Type d'Attaque | Protection | Temps de Réponse |
|---|---|---|
| Volumetric (UDP/TCP flood) | AWS Shield Standard |
Automatique |
| Protocol attacks (SYN flood) | AWS Shield Advanced |
< 1 minute |
| Application layer (HTTP flood) | WAF + Rate limiting |
Automatique |
Capacités de mitigation :
- Absorption jusqu'à plusieurs Tbps de trafic
- Détection automatique des patterns d'attaque
- Notification en temps réel via CloudWatch
- Support 24/7 de l'équipe DDoS Response Team AWS
3.3 CDN et Edge Security
CloudFront est utilisé comme CDN pour :
- Distribuer les assets statiques (app web, images)
- Terminer le TLS au plus proche des utilisateurs
- Appliquer les règles WAF en edge
- Cacher les réponses non sensibles
Configuration TLS
| Paramètre | Configuration | Justification |
|---|---|---|
| Protocole | TLS 1.2 minimum, TLS 1.3 recommandé |
Sécurité des communications |
| Ciphersuites | AES-GCM, ChaCha20-Poly1305 |
Chiffrement fort |
| OCSP Stapling | Activé | Performance validation certificat |
| HTTP/2 | Activé | Performance et multiplexage |
| Origin Shield | Activé | Protection de l'origine |
SÉCURITÉ RÉSEAU
4.1 Architecture VPC (Virtual Private Cloud)
L'infrastructure REWAPP est déployée dans une VPC AWS avec isolation réseau complète.
Architecture Réseau VPC
| Subnet | Type | CIDR | Composants |
|---|---|---|---|
| Public Subnet A | Public | 10.0.1.0/24 |
NAT Gateway, Load Balancer |
| Public Subnet B | Public | 10.0.2.0/24 |
NAT Gateway (redondance) |
| Private Subnet A | Privé | 10.0.10.0/24 |
ECS Services, Applications |
| Private Subnet B | Privé | 10.0.11.0/24 |
ECS Services (redondance) |
| Data Subnet A | Isolé | 10.0.20.0/24 |
RDS PostgreSQL, ElastiCache |
| Data Subnet B | Isolé | 10.0.21.0/24 |
RDS (Multi-AZ), ElastiCache (réplica) |
4.2 Security Groups et ACL
Security Groups (niveau instance)
Security Groups
| Security Group | Source | Port | Description |
|---|---|---|---|
sg-alb |
0.0.0.0/0 | 443 | HTTPS depuis Internet |
sg-api |
sg-alb | 3000 | API depuis ALB uniquement |
sg-rds |
sg-api | 5432 | PostgreSQL depuis API uniquement |
sg-redis |
sg-api | 6379 | Redis depuis API uniquement |
sg-admin |
IP Admin VPN | 22 | SSH administration uniquement |
Network ACLs (niveau subnet)
Network ACLs
| Subnet | Règle Entrante | Règle Sortante |
|---|---|---|
| Public | Allow 443 (HTTPS), Deny reste | Allow all |
| Private | Allow depuis Public subnet | Allow vers Data subnet |
| Data | Allow depuis Private uniquement | Deny sortant Internet |
4.3 Segmentation Réseau
Principe de segmentation appliqué :
- Zone DMZ (Public) : seul le Load Balancer est exposé
- Zone Application (Private) : services backend isolés
- Zone Données (Data) : bases de données sans accès Internet direct
RÈGLE ABSOLUE
Les bases de données n'ont JAMAIS d'accès Internet direct.
4.4 VPN et Connexions Privées
Connexions Sécurisées
| Connexion | Type | Usage |
|---|---|---|
| AWS Site-to-Site VPN | IPSec |
Administration, accès depuis bureaux |
| AWS Client VPN | OpenVPN |
Accès développeurs, support |
| PrivateLink | AWS PrivateLink |
Connexion aux services AWS sans Internet |
| Direct Connect | Fibre dédiée |
(Prévu Phase 3) Connexion haute performance |
SÉCURITÉ APPLICATIVE
5.1 Authentification
RÉFÉRENCE
Voir document 6.2.1 Authentification et Autorisation pour les détails complets.
Mécanismes d'Authentification
| Mécanisme | Technologie | Contexte d'Utilisation |
|---|---|---|
| Email/Mot de passe | Bcrypt (12 rounds) |
Inscription classique |
| OAuth2/OIDC | JWT RS256 |
Single Sign-On, API |
| Biométrie | FaceID, TouchID |
App mobile (authentification secondaire) |
| 2FA | TOTP (Google Authenticator) |
Dashboard Admin (OBLIGATOIRE) |
| Magic Link | Token JWT 15min |
Récupération mot de passe |
Exigences mots de passe
- Longueur minimum : 8 caractères
- Au moins 1 majuscule, 1 minuscule, 1 chiffre
- Au moins 1 caractère spécial recommandé
- Vérification contre liste des mots de passe compromis (HaveIBeenPwned)
- Expiration : 90 jours pour les admins, illimité pour les utilisateurs
Gestion des tokens JWT
Tokens JWT
| Type de Token | Durée de Vie | Stockage | Révocation |
|---|---|---|---|
| Access Token | 15 minutes | Memory (app) | Automatique à expiration |
| Refresh Token | 7 jours | Secure Storage | Blacklist Redis |
| API Key (partenaires) | 1 an | Base de données | Révocation manuelle |
5.2 Autorisation (RBAC)
Modèle RBAC (Role-Based Access Control) :
Rôles et Permissions
| Rôle | Plateforme | Permissions |
|---|---|---|
| Super Admin | Dashboard Admin | Accès total, configuration système |
| Admin | Dashboard Admin | Gestion utilisateurs, partenaires, transactions |
| Support | Dashboard Admin | Consultation seule, support utilisateurs |
| Partenaire Owner | Dashboard Partenaire | Toutes les fonctionnalités commerçant |
| Partenaire Staff | Dashboard Partenaire | Scan QR, consultation statistiques |
| Client | App Mobile | Gestion compte, QR code, historique |
// Exemple de Guard d'autorisation NestJS
@Injectable()
export class RolesGuard implements CanActivate {
constructor(private reflector: Reflector) {}
canActivate(context: ExecutionContext): boolean {
const requiredRoles = this.reflector.get<Role[]>('roles', context.getHandler());
if (!requiredRoles) return true;
const request = context.switchToHttp().getRequest();
const user = request.user;
return requiredRoles.some(role => user.roles?.includes(role));
}
}
5.3 Protection contre les Attaques Web
RÉFÉRENCE
Voir document 6.2.2 Protection des Données (CSRF/XSS) pour les détails complets.
Protections Contre les Attaques
| Attaque | Protection | Implémentation |
|---|---|---|
| XSS (Cross-Site Scripting) | CSP, Échappement, Validation | Helmet.js, DOMPurify |
| CSRF (Cross-Site Request Forgery) | Tokens CSRF, SameSite cookies | csurf middleware |
| SQL Injection | Requêtes paramétrées, ORM | Prisma ORM |
| NoSQL Injection | Validation schema, sanitization | class-validator |
| Path Traversal | Validation chemins, whitelist | path.normalize |
| Clickjacking | X-Frame-Options, CSP frame-ancestors | Helmet.js |
// Configuration Helmet.js - Headers de sécurité HTTP
app.use(helmet({
contentSecurityPolicy: {
directives: {
defaultSrc: ["'self'"],
scriptSrc: ["'self'", "https://cdn.rewapp.fr"],
styleSrc: ["'self'", "'unsafe-inline'"],
imgSrc: ["'self'", "data:", "https:"],
connectSrc: ["'self'", "https://api.rewapp.fr"],
frameSrc: ["'none'"],
objectSrc: ["'none'"]
}
},
hsts: { maxAge: 31536000, includeSubDomains: true, preload: true },
referrerPolicy: { policy: 'strict-origin-when-cross-origin' }
}));
5.4 Validation des Entrées
Toutes les entrées utilisateur sont validées côté serveur :
// Exemple de DTO avec validation
export class CreateUserDto {
@IsEmail()
@Transform(({ value }) => value.toLowerCase().trim())
email: string;
@IsString()
@MinLength(8)
@Matches(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)/)
password: string;
@IsString()
@MinLength(2)
@MaxLength(50)
@Matches(/^[a-zA-ZÀ-ÿ\s'-]+$/)
firstName: string;
@IsOptional()
@IsPhoneNumber('FR')
phone?: string;
}
SÉCURITÉ DES DONNÉES
6.1 Chiffrement en Transit
TLS OBLIGATOIRE
Toutes les communications utilisent TLS 1.3 (minimum TLS 1.2)
Chiffrement des Communications
| Connexion | Protocole | Certificat |
|---|---|---|
| Client → CloudFront | TLS 1.3 |
AWS Certificate Manager |
| CloudFront → ALB | TLS 1.2 |
Certificat interne |
| ALB → API | TLS 1.2 |
Certificat interne |
| API → RDS | TLS 1.2 |
Certificat RDS |
| API → Redis | TLS 1.2 |
Certificat ElastiCache |
| API → Services tiers | TLS 1.3 |
Certificats publics |
Configuration TLS recommandée :
- Ciphersuites : TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
- Perfect Forward Secrecy (PFS) : ECDHE obligatoire
- Désactivation : SSLv3, TLS 1.0, TLS 1.1
6.2 Chiffrement au Repos
Chiffrement des Données Stockées
| Donnée | Algorithme | Gestion Clé | Stockage |
|---|---|---|---|
| Base de données (RDS) | AES-256 |
AWS KMS | Amazon RDS |
| Fichiers (S3) | AES-256-GCM |
AWS KMS | Amazon S3 |
| Cache (Redis) | AES-256 |
AWS KMS | ElastiCache |
| Backups | AES-256 |
AWS KMS | S3 (cross-region) |
| Mots de passe | Bcrypt (12 rounds) |
N/A (hash) | PostgreSQL |
| Tokens sensibles | HMAC-SHA256 |
Secret interne | PostgreSQL |
6.3 Gestion des Clés (KMS)
AWS KMS (Key Management Service) est utilisé pour la gestion centralisée des clés :
Clés de Chiffrement
| Clé | Usage | Rotation | Accès |
|---|---|---|---|
rewapp-db-key |
Chiffrement RDS | Annuelle (automatique) | Service API uniquement |
rewapp-s3-key |
Chiffrement fichiers S3 | Annuelle (automatique) | Service API uniquement |
rewapp-secrets-key |
Secrets Manager | Annuelle (automatique) | CI/CD, Services |
rewapp-qr-signing |
Signature QR codes | Trimestrielle (manuelle) | Service QR uniquement |
RÈGLE DE SÉCURITÉ
Aucune clé en clair dans le code source ou les variables d'environnement.
6.4 Tokenisation des Données Bancaires
RÉFÉRENCE
Voir document 6.4 Conformité PCI DSS pour les détails complets.
RÈGLE FONDAMENTALE
REWAPP ne stocke JAMAIS les données de carte bancaire en clair.
Stockage des Données Bancaires
| Donnée | Stockage REWAPP | Stockage Partenaire Bancaire |
|---|---|---|
| Numéro de carte | Jamais | Token uniquement |
| Date d'expiration | Jamais | Chez le partenaire |
| CVV | Jamais | Jamais stocké |
| Token bancaire | Token référence | Données complètes |
Flux de tokenisation
-
1
Saisie
Utilisateur saisit ses coordonnées bancaires
-
2
Transmission directe
L'app envoie directement au partenaire bancaire (Budget Insight)
-
3
Tokenisation
Le partenaire retourne un token opaque
-
4
Stockage sécurisé
REWAPP stocke uniquement ce token
-
5
Utilisation
Les transactions utilisent le token, jamais les données brutes
SÉCURITÉ DES API
7.1 API Gateway
Kong API Gateway est déployé comme point d'entrée unique pour toutes les API :
Fonctionnalités API Gateway
| Fonctionnalité | Configuration | Description |
|---|---|---|
| Authentication | JWT Plugin |
Validation des tokens JWT RS256 |
| Rate Limiting | Rate Limiting Plugin |
Contrôle du débit par utilisateur/IP |
| Logging | File Log, HTTP Log |
Audit trail des requêtes |
| Request Transform | Request Transformer |
Normalisation des requêtes |
| CORS | CORS Plugin |
Contrôle des origines autorisées |
| IP Restriction | IP Restriction Plugin |
Whitelist admin (VPN) |
7.2 Rate Limiting et Throttling
RÉFÉRENCE
Voir document 6.2.3 Rate Limiting et Throttling pour les détails complets.
Limites par Endpoint
| Endpoint | Limite | Fenêtre | Action si Dépassement |
|---|---|---|---|
/api/auth/login |
5 requêtes | 1 minute | Block 15 min |
/api/auth/register |
3 requêtes | 1 heure | Block 1 heure |
/api/qr/generate |
10 requêtes | 1 minute | Block 5 min |
/api/transactions |
100 requêtes | 1 minute | Throttle + Warning |
/api/* (authenticated) |
300 requêtes | 1 minute | Throttle |
/api/* (anonymous) |
60 requêtes | 1 minute | Block temporaire |
// Configuration Rate Limiting avec Redis
ThrottlerModule.forRoot([
{
name: 'short',
ttl: 1000, // 1 seconde
limit: 3, // 3 requêtes max
},
{
name: 'medium',
ttl: 60000, // 1 minute
limit: 100, // 100 requêtes max
},
{
name: 'long',
ttl: 3600000, // 1 heure
limit: 1000, // 1000 requêtes max
},
])
7.3 Authentification API
Méthodes d'Authentification API
| Type de Client | Méthode d'Auth | Token | Durée |
|---|---|---|---|
| App Mobile | Bearer JWT |
Access + Refresh | 15min / 7j |
| Dashboard Web | Bearer JWT + Cookie |
Access + Refresh | 15min / 7j |
| Webhooks entrants | HMAC Signature |
Header X-Signature | Par requête |
| Services internes | mTLS + API Key |
Certificat client | Illimité |
7.4 Validation des Requêtes
Toutes les requêtes API sont validées :
- Content-Type : application/json uniquement (sauf upload)
- Taille maximale : 10 MB pour les requêtes standard
- Encoding : UTF-8 obligatoire
- Schema validation : OpenAPI 3.0 stricte
SÉCURITÉ MOBILE
8.1 Sécurisation de l'Application
Mesures de Sécurité Mobile
| Mesure | iOS | Android | Description |
|---|---|---|---|
| Code Obfuscation | Activé (release) | ProGuard/R8 | Protection contre reverse engineering |
| Certificate Pinning | Prévention MITM | ||
| Jailbreak/Root Detection | Blocage appareils compromis | ||
| Debugger Detection | Protection runtime | ||
| Screenshot Prevention | Écrans sensibles | Écrans sensibles | FLAG_SECURE |
8.2 Stockage Sécurisé
Stockage Sécurisé par Plateforme
| Donnée | iOS | Android |
|---|---|---|
| Access Token | Keychain (kSecAttrAccessibleWhenUnlocked) |
EncryptedSharedPreferences |
| Refresh Token | Keychain (kSecAttrAccessibleAfterFirstUnlock) |
Android Keystore |
| Biometric Key | Secure Enclave |
Hardware Keystore (TEE) |
| Données utilisateur | Core Data (chiffré) |
Room (SQLCipher) |
8.3 Communications Sécurisées
- TLS 1.3 pour toutes les communications
- Certificate Pinning sur les domaines REWAPP
- Pas de données sensibles en cache HTTP
- Timeout agressif sur les connexions (30 secondes)
8.4 Authentification Biométrique
L'authentification biométrique est proposée comme facteur secondaire :
Biométrie
| Fonctionnalité | Comportement |
|---|---|
| Activation | Optionnelle, proposée après première connexion |
| Usage | Déverrouillage app, validation paiement QR |
| Fallback | Code PIN 6 chiffres si biométrie indisponible |
| Sécurité | Clé stockée dans Secure Enclave / TEE |
MONITORING ET DÉTECTION
9.1 Logs de Sécurité
Tous les événements de sécurité sont centralisés dans CloudWatch Logs :
Événements de Sécurité
| Événement | Niveau | Rétention | Alerte |
|---|---|---|---|
| Connexion réussie | INFO | 90 jours | Non |
| Échec connexion | WARN | 1 an | Si > 5 en 5 min |
| Changement mot de passe | INFO | 1 an | Notification utilisateur |
| Accès admin | INFO | 2 ans | Audit trail |
| Erreur authentification JWT | WARN | 1 an | Si > 10 en 1 min |
| Tentative SQL injection | ERROR | 2 ans | Immédiate |
| Accès données sensibles | INFO | 2 ans | Audit trail |
| Modification permissions | WARN | 2 ans | Immédiate (admin) |
9.2 Détection d'Intrusion
Outils de Détection
| Outil | Fonction | Alertes |
|---|---|---|
| AWS GuardDuty | Détection menaces AWS | CloudWatch → PagerDuty |
| WAF Logs | Requêtes bloquées | Dashboard temps réel |
| Application Logs | Comportements anormaux | Sentry → Slack |
| CloudTrail | Actions API AWS | Audit compliance |
Règles de détection personnalisées
- Connexion depuis nouveau pays : notification + 2FA obligatoire
- Nombre excessif de génération QR : blocage temporaire
- Tentative d'accès à ressource non autorisée : log + alerte
- Volume anormal de transactions : review manuel
9.3 Alertes et Escalade
Matrice d'Escalade
| Sévérité | Temps de Réponse | Canal | Escalade |
|---|---|---|---|
| Critique | < 15 min | PagerDuty + Téléphone | CTO immédiat |
| Haute | < 1 heure | Slack #security | Lead Dev |
| Moyenne | < 4 heures | Slack #security | Équipe sécurité |
| Basse | < 24 heures | Revue hebdomadaire |
GESTION DES INCIDENTS
10.1 Plan de Réponse aux Incidents
Étapes de réponse aux incidents de sécurité :
Étape 1 : Détection
Identification de l'incident via monitoring ou signalement
Étape 2 : Containment
Isolation des systèmes affectés (blocage IP, révocation tokens)
Étape 3 : Investigation
Analyse des logs, identification de la cause racine
Étape 4 : Eradication
Correction de la vulnérabilité, patch de sécurité
Étape 5 : Recovery
Restauration des services, vérification intégrité
Étape 6 : Post-mortem
Documentation, amélioration des contrôles
10.2 Procédures d'Escalade
Chaîne d'Escalade
| Type d'Incident | Responsable Initial | Escalade N+1 | Escalade N+2 |
|---|---|---|---|
| Attaque en cours | Équipe Ops | CTO | Direction |
| Fuite de données | DPO | CTO + Direction | CNIL (si applicable) |
| Indisponibilité service | Équipe Ops | CTO | Direction |
| Fraude détectée | Équipe Support | Équipe Sécurité | Direction + Juridique |
10.3 Communication de Crise
Plan de Communication
| Audience | Canal | Délai | Contenu |
|---|---|---|---|
| Équipe interne | Slack #incident | Immédiat | Statut technique |
| Utilisateurs affectés | Email + Push | < 24h | Impact et actions |
| Tous utilisateurs | Blog + App | < 48h | Communication transparente |
| Autorités (CNIL) | Formulaire officiel | < 72h | Notification RGPD si breach |
SYNTHÈSE DES MESURES DE SÉCURITÉ
11.1 Tableau Récapitulatif
Conformité des Mesures de Sécurité
| Exigence | Mesure Implémentée | Conformité |
|---|---|---|
| Chiffrement en transit | HTTPS/TLS 1.3 obligatoire | |
| Chiffrement au repos | AES-256 (RDS, S3, Redis) | |
| Hashage mots de passe | Bcrypt (12 rounds) | |
| Tokens d'authentification | JWT RS256, expiration courte | |
| Signature QR Code | HMAC-SHA256, validité 60s | |
| Données bancaires | Tokenisation PCI DSS via partenaire | |
| Protection API | Rate limiting + WAF + CORS | |
| 2FA Admin | TOTP obligatoire pour tous les admins | |
| Audit trail | Logs centralisés, rétention 2 ans | |
| Conformité RGPD | Consentement, droits, DPO |
11.2 Certifications et Audits
Certifications
| Certification/Audit | Statut | Fréquence |
|---|---|---|
| PCI DSS (via partenaire bancaire) | Conforme | Continue |
| RGPD | Conforme | Audit annuel |
| Pentest externe | Prévu Phase 2 | Annuel |
| Audit de code | À chaque release majeure | Continue |
| Revue architecture sécurité | Document présent | Trimestrielle |
11.3 Points de Contact Sécurité
Contacts
| Rôle | Responsabilité | Contact |
|---|---|---|
| CTO | Responsable sécurité technique | cto@rewapp.fr |
| DPO | Protection des données personnelles | dpo@rewapp.fr |
| Équipe Sécurité | Opérations de sécurité | security@rewapp.fr |
| Support | Signalement incidents utilisateurs | support@rewapp.fr |
CONCLUSION
Cette architecture de sécurité assure une protection complète de l'écosystème REWAPP, avec une défense en profondeur couvrant tous les aspects : périmétrique, réseau, applicatif, données, et monitoring. Les mesures implémentées respectent les standards de l'industrie (OWASP, PCI DSS, RGPD) et sont régulièrement auditées.