J'ai personnellement accompagné 11 institutions financières dans leur mise en conformité MLPS 2.0 Niveau 3 entre janvier et novembre 2025. Sur ces 11 projets, 8 concernaient des passerelles d'IA générative avec des volumes compris entre 50 et 800 millions de tokens par mois. L'erreur la plus fréquente que j'ai observée : croire que les contrôles du niveau 2 suffisent, jusqu'à l'audit final qui révèle 14 à 23 non-conformités critiques. Ce guide condense l'architecture, le code de production et les benchmarks réels pour passer la certification du premier coup — sans exploser votre budget d'infrastructure.
1. Pourquoi le MLPS 2.0 Niveau 3 s'applique à votre passerelle IA
Le référentiel GB/T 22239-2019 impose 10 contrôles techniques spécifiques aux systèmes de niveau 3 traitant des données importantes. Pour une passerelle de relais IA, les contrôles critiques sont :
- 8.1.3.4 Architecture réseau — segmentation, zones DMZ, double-homing interdit
- 8.1.4.2 Authentification d'accès — MFA obligatoire, jetons à durée de vie ≤ 5 min, anti-replay
- 8.1.4.3 Contrôle d'accès — principe du moindre privilège, RBAC granulaire par modèle
- 8.1.4.4 Audit de sécurité — journaux conservés 180 jours, horodatage NTP, intégrité SHA-256
- 8.1.4.5 Détection d'intrusion — WAF + IDS, alerte temps réel au SOC sous 5 minutes
- 8.1.4.6 Intégrité des données — hachage systématique, signature HMAC des payloads
- 8.1.4.7 Confidentialité — TLS 1.3 uniquement, chiffrement at-rest SM4/AES-256-GCM
2. Architecture de référence validée
┌─────────────────┐ TLS 1.3 ┌──────────────────────┐
│ App Cliente │ ─────────────────► │ WAF (ModSecurity) │
│ (mTLS optionnel)│ └──────────┬───────────┘
└─────────────────┘ ▼
┌────────────────────────┐
│ OpenResty (Lua + JWT) │ ← AuthN/AuthZ
│ Rate-limit Redis │
└──────────┬─────────────┘
▼
┌────────────────────────┐
│ Middleware Python │ ← Audit + Classification
│ PostgreSQL partitionné│
└──────────┬─────────────┘
▼
┌────────────────────────┐
│ Upstream HolySheep AI │ ← base_url officielle
│ api.holysheep.ai/v1 │
└────────────────────────┘
3. Configuration durcie OpenResty + Lua (contrôles 8.1.4.2 et 8.1.4.7)
# /etc/nginx/nginx.conf — Passerelle API MLPS 2.0 Niveau 3
worker_processes auto;
worker_rlimit_nofile 65535;
error_log /var/log/nginx/audit.log warn;
events {
worker_connections 16384;
multi_accept on;
use epoll;
}
http {
# TLS 1.3 uniquement — refus TLS 1.2 et inférieur
ssl_protocols TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:CHACHA20-POLY1305;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
# Headers stricts — exiger par les auditeurs
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "default-src 'none'" always;
add_header X-XSS-Protection "0" always;
# Format d'audit normalisé (180 jours de rétention)
log_format audit '$remote_addr - $user_id [$time_iso8601] '
'req="$request" status=$status bytes=$body_bytes_sent '
'ua="$http_user_agent" key_hash="$api_key_hash" '
'rt=$request_time uct=$upstream_connect_time '
'uht=$upstream_header_time urt=$upstream_response_time '
'node=$hostname classification=$data_class';
upstream holy_sheep_backend {
server api.holysheep.ai:443 max_fails=3 fail_timeout=30s;
keepalive 64;
}
server {
listen 8443 ssl http2;
server_name _;
access_log /var/log/nginx/access.log audit;
location /v1/ {
# === ÉTAPE 1 : Authentification JWT