Sécurité¶

Dernière mise à jour : 6 juin 2026

AI-Bridge for Cisco UC est conçu dès le départ pour les environnements réglementés, les infrastructures critiques et les organisations soucieuses de leur souveraineté des données. La sécurité n'est pas une couche ajoutée en surface — c'est le fondement même de l'architecture.

Chaque composant suit une architecture de défense en profondeur : plusieurs contrôles indépendants sont superposés de sorte qu'aucune défaillance isolée ne puisse ouvrir une brèche.

Sécurité en un coup d'œil¶

Couche	Rôle
Air-gapped	Aucun cloud, aucune télémétrie, aucune connexion sortante — jamais
Durcissement Docker	Conteneur non-root, filesystem en lecture seule, no-new-privileges, build multi-stage
Transport	TLS 1.2+ obligatoire, protection DNS rebinding, validation stricte des en-têtes
Authentification	RS256 JWT (RSA-4096) ou OAuth 2.1 complet (Authorization Code + PKCE / Client Credentials)
Autorisation	RBAC avec application par outil, par produit et par protocole
Isolation des données	Répertoire chiffré par client — les secrets ne franchissent jamais les frontières entre clients
Identifiants au repos	AES-128-CBC + HMAC-SHA256 (Fernet), clé par client via PBKDF2-SHA512
Vérification d'hôte	Confiance par empreinte SSH + épinglage de certificat HTTPS vers les nœuds Cisco UC
Protection brute-force	Fail2Ban par IP + limitation de débit par fenêtre glissante par client
Journal d'audit	Journal d'audit JSON structuré — chaque authentification, action et anomalie est enregistrée
Intégrité logicielle	Signature RSA-PSS sur manifest SHA-512 — vérifiée au démarrage
Sauvegardes chiffrées	Hybride RSA-OAEP-SHA512 + AES-256-GCM — déchiffrable uniquement avec votre clé privée
Analyse CI	SAST automatisé, scan de secrets, audit CVE, scan YARA MCP + SBOM signé à chaque push

Conception Air-Gapped & Souveraine¶

AI-Bridge for Cisco UC ne contient aucune dépendance cloud :

Conçu pour les réseaux classifiés, gouvernementaux et d'infrastructure critique.
Modèle air-gapped : l'ensemble de la chaîne opérationnelle peut fonctionner sans aucune connectivité internet.
Le serveur ne se connecte qu'aux nœuds Cisco UC que vous configurez explicitement.
Aucun service externe, aucune télémétrie, aucune analytique, aucun mécanisme de rappel à domicile.
La licence est hors ligne — les licences sont des fichiers JWT signés RS256 installés localement. Aucun serveur de licences, aucune activation en ligne.

Durcissement de la sécurité Docker¶

Lorsqu'il est déployé avec Docker, des contrôles de sécurité supplémentaires sont appliqués :

Mesure	Description
Utilisateur non-root	Le container tourne sous `mcpadmin` (UID 1000) — jamais en root
Système de fichiers en lecture seule	Le filesystem du container est immuable (`read_only: true`)
Pas d'escalade de privilèges	`no-new-privileges:true` empêche les exploits `setuid`/`setgid`
tmpfs minimal	`/tmp` est un tmpfs de 64 Mo — aucune zone persistante en écriture hors volumes
Build multi-stage	Les outils de compilation sont absents de l'image de production
Volumes bind-mount	Les données d'exécution sont isolées sur l'hôte ; `.env` est monté en lecture seule

Sécurité du transport¶

Toutes les communications client-serveur sont chiffrées et strictement validées.

Chiffrement obligatoire — Toutes les communications sont chiffrées via HTTPS.
TLS 1.2+ uniquement — SSL, TLS 1.0 et TLS 1.1 sont explicitement désactivés.
Gestion des certificats — Certificats signés par une CA ou auto-signés générés automatiquement pris en charge.
Protection DNS rebinding — Chaque requête est validée par rapport aux origines autorisées configurées. Les requêtes avec des en-têtes Host non concordants ou falsifiés sont rejetées.
Validation stricte des en-têtes — Origin, Content-Type et les en-têtes personnalisés sont appliqués sur tous les points de terminaison HTTP.

Authentification¶

Deux modes d'authentification sont pris en charge, sélectionnables par déploiement :

Mode JWTMode OAuth 2.1

Les clients s'authentifient avec des JSON Web Tokens signés RS256 en utilisant une paire de clés RSA-4096 générée automatiquement.

Tokens de longue durée distribués aux clients enregistrés lors du provisionnement.
Révocables via le point de terminaison /revoke (RFC 7009).
Révocation active des tokens avec liste noire JTI et nettoyage automatique à expiration.

Flux OAuth 2.1 complet avec deux grants supportés :

Authorization Code + PKCE (RFC 7636 S256) — connexion interactive via navigateur pour les clients AI IDE
Client Credentials (RFC 6749 §4.4) — émission de tokens M2M sans interface
Révocation de tokens via /revoke (RFC 7009)
Métadonnées du serveur d'autorisation : /.well-known/oauth-authorization-server (RFC 8414)
Métadonnées de la ressource protégée : /.well-known/oauth-protected-resource (RFC 9728) — requis par les clients conformes MCP 2025-03-26
Prise en charge de l'authentification HTTP Basic et des méthodes d'authentification client POST
Mode hybride JWT + OAuth 2.1 pris en charge pour les environnements clients mixtes

Autorisation — RBAC¶

Chaque invocation d'outil est autorisée par un moteur de contrôle d'accès basé sur les rôles avant exécution.

Profils prédéfinis : admin, operator, auditor — chacun avec un périmètre spécifique d'opérations autorisées.
Profils personnalisés — les organisations peuvent définir leurs propres profils sous forme de fichiers JSON pour un contrôle fin.
Granularité par produit — permissions séparées par module produit.
Granularité par protocole — filtrage de préfixe d'opérations AXL, listes blanches de commandes SSH, restrictions de classes d'API RIS.
Application par outil — chaque outil MCP déclare le niveau de profil requis ; les appels non autorisés sont rejetés avant tout contact avec une API UC.

Isolation des données par client¶

Chaque client enregistré opère dans un environnement totalement isolé :

Répertoire dédié avec ses propres secrets, identifiants, rapports et configuration.
Aucun partage de données entre clients — les identifiants et rapports ne sont jamais accessibles entre clients.
Nettoyage automatique — lorsqu'un client est désactivé, son répertoire et toutes les données associées sont purgés.

Chiffrement des identifiants au repos¶

Tous les identifiants Cisco UC stockés sont chiffrés avec Fernet (AES-128-CBC + HMAC-SHA256).

Les clés de chiffrement sont dérivées par client à partir de l'UUID du client + un sel côté serveur via PBKDF2-SHA512 avec 600 000 itérations (conforme NIST SP 800-132).
Le sel serveur est généré une fois et stocké dans un fichier à accès restreint.
Aucun identifiant n'est jamais stocké en clair — ni dans le cache mémoire après délai d'inactivité, ni sur le disque.

Vérification de l'identité des hôtes¶

AI-Bridge vérifie l'identité de chaque nœud Cisco UC avant d'envoyer des données.

Connexions SSH — Modèle Trust-On-First-Use (TOFU) : l'empreinte de l'hôte distant est capturée et stockée lors de la première connexion. Toutes les connexions suivantes vérifient l'empreinte — une discordance déclenche une alerte et bloque l'opération.
Connexions HTTPS — La vérification des certificats est appliquée pour tous les appels d'API AXL. L'épinglage de certificat est pris en charge pour une assurance maximale.

Protection contre les attaques par force brute et la limitation de débit¶

Des mécanismes indépendants protègent contre les abus :

Fail2Ban (par IP) : Suit les échecs d'authentification par IP source. Après un nombre configurable d'échecs dans une fenêtre glissante, l'IP est automatiquement bloquée pour une durée configurable. Tous les événements sont enregistrés dans le journal d'audit.

Limitation de débit (par client) : Chaque client authentifié est soumis à une limitation de débit par fenêtre glissante par catégorie d'outil. Les requêtes dépassant la limite retournent HTTP 429 et sont journalisées.

Journal d'audit¶

Chaque événement de sécurité pertinent est écrit dans un fichier audit.log dédié au format JSON structuré.

Catégorie d'événement	Ce qui est journalisé
AUTH	Succès/échec de connexion, token émis/révoqué, adresse IP, identité du client
ACTIONS	Chaque appel d'outil MCP — client, nom de l'outil, hôte, statut du résultat
RATE_LIMITED	Événements de limitation de débit par client et par IP
CREDENTIAL	Opérations de stockage, mise à jour et suppression d'identifiants
TRUSTED	Décisions de confiance d'empreinte SSH
WRITTEN/EXPORTED	Génération de rapports et export PDF
SERVER	Démarrage, arrêt, changements d'état de licence
TRANSPORT	Alertes TLS, violations d'en-têtes, tentatives de DNS rebinding

L'injection de journaux est prévenue par l'assainissement des caractères de contrôle dans toutes les valeurs journalisées (mesure d'atténuation CWE-117).

Vérification de l'intégrité logicielle¶

Chaque version est signée. L'intégrité des paquets d'installation/mise à niveau est vérifiée via des sommes de contrôle SHA-512 avant installation.

De plus, l'intégrité de tous les fichiers du projet est vérifiable à tout moment. - Un manifest SHA-512 (manifest.json) couvre chaque fichier source. - Le manifest est signé avec RSA-PSS sur SHA-512 (RSA-4096), produisant manifest.sig. - L'intégrité est vérifiée au démarrage et surveillée périodiquement par un watchdog en arrière-plan. - Toute altération des fichiers source sera détectée et signalée avant que le serveur n'opère.

Sauvegardes chiffrées¶

Les sauvegardes des données client sont protégées par chiffrement hybride :

Une clé de session AES-256-GCM aléatoire chiffre l'archive de sauvegarde.
La clé de session est enveloppée avec votre clé publique RSA-4096 via RSA-OAEP avec SHA-512 (MGF1-SHA512).
Seul le détenteur de la clé privée peut déchiffrer — le serveur lui-même ne peut pas lire ses propres sauvegardes sans la clé.
Un fichier sidecar SHA-512 garantit l'intégrité de la sauvegarde avant toute tentative de restauration.
Export SFTP optionnel avec clé SSH ou authentification par mot de passe chiffré ; politique de rétention distante configurable.
Vérification obligatoire de la hostkey SFTP (anti-MITM) : la hostkey du serveur distant doit être pré-enregistrée dans BACKUP_SFTP_KNOWN_HOSTS (format OpenSSH known_hosts, alimenté via ssh-keyscan). Si le fichier est absent ou l'hôte inconnu, le transfert est abandonné avant tout envoi d'identifiants.

Analyse de sécurité CI¶

Chaque push sur main déclenche un pipeline de sécurité automatisé. Le CI échoue sur tout résultat non sûr non explicitement documenté dans la liste blanche.

Étape	Outil	Périmètre / Moteur
Scan YARA MCP	`cisco-ai-mcp-scanner` par Cisco AI Defense	Statique / hors ligne (aucun serveur actif, aucune clé API) — règles YARA couvrant l'injection de prompts, l'exfiltration de données et les patterns d'abus d'outils sur tous les outils, prompts et ressources MCP
SAST	`bandit`	Analyse du code source Python sur `lib/`, `servers/`, `scripts/`
Lint / vérifications	`ruff` + `mypy`	Style, patterns de bugs courants et vérification statique des types
Détection de secrets	`gitleaks`	Historique Git complet analysé à la recherche d'identifiants / tokens commités
Scan d'image conteneur	`trivy image`	Paquets OS + dépendances Python de l'image Docker publiée (CVE + misconfigurations)
Audit CVE des dépendances	`pip-audit`	Arbre de dépendances runtime + dev résolu (depuis `uv export --no-dev`)
SBOM	`cyclonedx-py`	SBOM CycloneDX 1.5 JSON publié comme artefact CI, signé hors ligne (RSA-PSS / SHA-512) avec la clé privée de l'éditeur, vérifiable avec `lib/editor_public.pem` intégré
Tests unitaires & couverture	`pytest` + `pytest-cov`	Suite complète de tests unitaires avec un seuil de couverture ≥ 88 % (`lib/`, `servers/`, `scripts/`)

Reproductible en local

Tous les scanners ci-dessus sont fournis dans le groupe de dépendances dev de pyproject.toml et peuvent être ré-exécutés sur un poste développeur avec uv sync puis bandit, pip-audit, gitleaks detect, trivy image ai-bridge-for-cisco-uc:latest, pytest, et python tests/tests_check_mcp_scan.py (qui valide la sortie JSON de MCP-scanner par rapport à la liste blanche des faux positifs connus).

Signalement de vulnérabilités¶

Si vous découvrez une vulnérabilité de sécurité, veuillez la signaler en privé :

Email : security@sourdeau.com
Délai de réponse : 48 heures

La divulgation responsable est appréciée. Tous les signalements sont traités avec confidentialité.

Nous remercions sincèrement chaque chercheur et utilisateur qui prend le temps de signaler une vulnérabilité — votre contribution renforce directement la sécurité d'AI-Bridge for Cisco UC et des organisations qui s'y fient.

Standards & Conformité¶

Standard / Framework	Couverture
RFC 6749	OAuth 2.0 Authorization Framework
RFC 7009	Token Revocation
RFC 7636	Proof Key for Code Exchange (PKCE) — méthode S256
RFC 7519	JSON Web Tokens (JWT)
RFC 8414	OAuth 2.0 Authorization Server Metadata
RFC 9728	OAuth 2.0 Protected Resource Metadata
NIST SP 800-132	Dérivation de clé PBKDF2 (600k itérations, SHA-512)
OWASP Top 10	Validation des entrées, injection de journaux (CWE-117), sécurité transport
CWE-117	Prévention de l'injection de journaux par assainissement des caractères de contrôle