Sécurité¶

Dernière mise à jour : 8 octobre 2026

Tolk 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 `Host` / `Origin`)
Authentification	RS256 JWT, OAuth 2.1 (Authorization Code + PKCE / Client Credentials) ou les deux
Autorisation	RBAC par produit, par protocole et par opération
Admin Web UI	Port HTTPS dédié, liste blanche d'IP sources, mots de passe bcrypt, verrouillage, RBAC admin, CSRF
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	Approbation explicite des empreintes SSH + vérification des certificats HTTPS par magasin de CA produit
Protection brute-force	Fail2Ban par IP + limitation de débit par fenêtre glissante, par client et globale (par hôte)
Journal d'audit	Journal d'audit JSON structuré — chaque authentification, action, modification admin et anomalie
Intégrité logicielle	Signature RSA-PSS sur manifest SHA-512 — vérifiée au démarrage et périodiquement
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¶

Tolk 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 (et terminaux) que vous configurez explicitement.
Aucun service externe, aucune télémétrie, aucune analytique, aucun mécanisme de rappel à domicile.
L'Admin Web UI ne charge aucune ressource externe (pas de CDN, pas de police web, pas de script tiers).
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¶

Lors d'un déploiement avec Docker, des contrôles de sécurité supplémentaires sont appliqués :

Mesure	Description
Utilisateur non-root	Le conteneur s'exécute avec un utilisateur non privilégié — `UID` / `GID` `1000` par défaut, configurables (Conteneur Docker) ; `0` (root) est refusé
Filesystem en lecture seule	Le filesystem du conteneur est immuable (`read_only: true`)
Pas d'escalade de privilèges	`no-new-privileges:true` empêche les exploits `setuid`/`setgid`
tmpfs borné	`/tmp` est un tmpfs en mémoire de 256 Mo (rendu transitoire des rapports) — aucune zone inscriptible persistante hors des volumes
Build multi-stage	Les outils de compilation sont absents de l'image de production ; l'image de base est épinglée par digest
Volumes bind-mount	Les données d'exécution (configuration, secrets, données clients, journaux, sauvegardes) sont isolées sur l'hôte, hors de l'image
Health check	`HEALTHCHECK` du conteneur en loopback uniquement (aucun identifiant requis, rien d'exposé)

Sécurité du transport¶

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

Chiffrement obligatoire — Le serveur MCP et l'Admin Web UI n'écoutent qu'en HTTPS.
TLS 1.2+ uniquement — SSL, TLS 1.0 et TLS 1.1 sont refusés.
Gestion des certificats — Certificats signés par une AC ou auto-signés générés automatiquement, génération de CSR et import de certificat depuis la Web UI, alertes d'expiration (voir Certificats TLS).
Protection contre le DNS rebinding — Les en-têtes Host et Origin de chaque requête sont validés par rapport aux hôtes et origines autorisés. Les en-têtes non conformes ou falsifiés sont rejetés et audités (TRANSPORT_BLOCKED).
Reverse proxies — X-Forwarded-For n'est pris en compte que depuis les proxies listés dans TRUSTED_PROXY_IPS (Reverse proxy) ; depuis toute autre source, l'en-tête est ignoré : un client ne peut pas usurper son adresse IP. Les proxies de confiance ne sont jamais mis en liste noire.

Authentification¶

Le mode d'authentification global (AUTH_MODE) se choisit par déploiement dans l'Admin Web UI ; en mode jwt+oauth2, chaque client reçoit son propre mode (voir Modes d'authentification). Le serveur refuse un mode global plus restrictif que les modes déjà attribués aux clients.

Mode JWTMode OAuth 2.1

Les clients s'authentifient avec des JSON Web Tokens signés RS256 par la paire de clés RSA du serveur (4096 bits par défaut).

Tokens longue durée générés pour chaque client et affichés une seule fois dans la Web UI (Voir les identifiants).
Révocation immédiate depuis la Web UI (Réinitialiser les tokens) : le token actif est mis en liste noire (JTI) et un nouveau token est émis.
Liste noire JTI persistée entre les redémarrages, avec nettoyage automatique des entrées expirées.

Flux OAuth 2.1 complet avec deux grants supportés :

Authorization Code + PKCE (RFC 7636 S256) — connexion via navigateur pour les clients interactifs (IDE IA).
Client Credentials (RFC 6749 §4.4) — émission de tokens M2M sans interface.
Tokens d'accès de courte durée (1 heure par défaut) ; secrets clients stockés sous forme de hash bcrypt.
Secret client affiché une seule fois dans la Web UI ; Réinitialiser les tokens le renouvelle immédiatement.
Liste blanche des redirect_uri par client, appliquée en mode strict (voir Liste blanche des redirect URI OAuth).
Révocation de token via /revoke (RFC 7009) — un client ne peut révoquer que ses propres tokens.
Métadonnées du serveur d'autorisation (RFC 8414) et de la ressource protégée (RFC 9728) pour les clients conformes MCP.
Méthodes d'authentification client HTTP Basic et POST.

Paire de clés RSA

La paire de clés RSA signe les tokens JWT et protège les clés des sauvegardes. Elle peut être renouvelée depuis la Web UI (Régénérer la paire) : sauvegarde complète du système, archivage de la paire actuelle, génération d'une nouvelle paire et réémission des tokens de tous les clients (voir Clés RSA).

Autorisation — RBAC¶

Chaque opération MCP 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 — créés et modifiés depuis l'Admin Web UI (Clients → Profils), rechargés à chaud sans redémarrage.
Granularité par produit — chaque client ne voit que les modules produit (CUCM, IMP, CUC) de son profil.
Granularité par protocole — préfixes d'opérations AXL, listes de commandes SSH autorisées, classes RIS, CUPI, opérations sur les terminaux et les rapports.
Contrôle par opération — chaque opération AXL, RIS, SSH, CUPI, xAPI, Serviceability ou de rapport est vérifiée par rapport au profil avant tout appel à une API Cisco UC ; une opération refusée est rejetée et auditée.
Visibilité en libre-service — infra_get_my_permissions renvoie la matrice de permissions effective du client appelant.

Sécurité de l'Admin Web UI¶

L'Admin Web UI est le point unique de configuration du produit. Elle est protégée indépendamment du serveur MCP :

Listener HTTPS dédié — port distinct (9443 par défaut), certificat TLS propre ou partagé ; elle peut être entièrement désactivée (Admin UI).
Liste blanche d'IP sources — ADMIN_UI_TRUSTED_IPS (CIDR) ; vide = tout refuser. Le loopback est toujours autorisé (health check du conteneur, récupération locale).
Liste noire manuelle — un administrateur peut mettre en liste noire une adresse IP ou un sous-réseau CIDR depuis la page Système & reload, par périmètre (Admin Web UI, Client MCP ou les deux).
Mots de passe — hachés avec bcrypt (coût configurable), avec une politique de longueur minimale et de complexité ; jamais stockés dans la configuration. Le premier mot de passe superadmin est défini en ligne de commande, avec une saisie interactive.
Verrouillage des connexions — verrouillage temporaire après des échecs répétés par identifiant et IP source.
Sessions — cookies signés HMAC-SHA256 (HttpOnly, Secure, SameSite=Strict), délai d'inactivité et durée de vie maximale.
Protection CSRF — jeton double-submit sur chaque formulaire.
En-têtes de sécurité stricts — Content Security Policy sans script ni style inline, HSTS, X-Frame-Options: DENY, nosniff, no-referrer, no-store.
RBAC admin — niveau d'accès par page (aucun / lecture seule / lecture-écriture) défini par les profils administrateurs ; le profil superadmin est verrouillé (voir Administrateurs).
Traçabilité — chaque action d'administration est inscrite au journal d'audit avec l'identifiant de l'administrateur et l'IP source.

Contrôle des modifications de configuration¶

Modifications en attente — un paramètre modifié n'est pas appliqué immédiatement ; il est mis en attente, puis appliqué en une fois depuis Système & reload → Appliquer / Redémarrer.
Vérifications avant redémarrage — avant de redémarrer, la page affiche chaque modification (avant / après, auteur) et vérifie l'intégrité du logiciel, les certificats TLS, les clients MCP et les sessions admin actifs.
Contrôles de cohérence — chaque valeur est validée (type, plage, énumération) ; les combinaisons incohérentes, comme un mode d'authentification global incompatible avec un client déclaré, sont refusées.
Instantanés — un instantané horodaté de la configuration, des certificats et des clés RSA est conservé avant chaque modification, et toute modification en attente peut être annulée.
Mode maintenance — draine les clients MCP avant une intervention : les clients nouveaux ou inactifs sont refusés (« réessayer plus tard ») pendant que les clients actifs terminent leur travail (voir Mode maintenance).

Isolation des données par client¶

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

Répertoire dédié avec ses propres secrets, identifiants, rapports et configuration.
Aucun partage de données entre clients — les identifiants et les rapports ne sont jamais accessibles d'un client à l'autre.
Nettoyage automatique — lorsqu'un client est supprimé, 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 seule fois et stocké dans un fichier à accès restreint (mode 600).
Les identifiants ne sont déchiffrés en mémoire qu'au moment de leur utilisation ; ils ne sont jamais écrits en clair sur disque ni dans les journaux.
Les secrets de niveau serveur (mot de passe SFTP des sauvegardes) sont chiffrés avec une clé serveur dérivée de la même manière.

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

Tolk vérifie l'identité de chaque nœud Cisco UC avant d'envoyer le moindre identifiant.

Connexions SSH — L'empreinte (SHA-256) d'un nouveau nœud est présentée et doit être explicitement approuvée (*_os_trust_fingerprint) avant toute connexion. Toutes les connexions suivantes la vérifient — une non-concordance interrompt la connexion avant l'authentification : aucun identifiant n'est envoyé.
Connexions HTTPS (AXL, RIS, CUPI) — La vérification des certificats est activée par défaut, par rapport à un magasin de CA propre à chaque produit, modifiable depuis la Web UI. La désactiver (labo uniquement) génère un événement d'audit critique (SSL_DISABLED).
Terminaux (téléphones IP, codecs RoomOS) — Joints par adresse IP avec des identifiants HTTP Basic par terminal. La vérification de la chaîne de certificats est optionnelle (SERVER_CUCM_PHONES_SSL_VERIFY / SERVER_CUCM_ROOMOS_SSL_VERIFY, désactivée par défaut car les terminaux présentent généralement des certificats MIC / auto-signés) par rapport à des magasins de CA dédiés ; un avertissement est journalisé au démarrage tant qu'elle est désactivée.

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 MCP / OAuth par IP source. Après un nombre configurable d'échecs dans une fenêtre glissante, l'IP est automatiquement bloquée pendant une durée configurable (Protection anti brute-force). Les administrateurs peuvent aussi bloquer ou libérer manuellement une IP ou un sous-réseau. Tous les événements sont enregistrés dans le journal d'audit.

Limitation des connexions admin : Indépendante du mécanisme MCP : les échecs de connexion à la Web UI sont comptés par identifiant et IP source, avec un verrouillage temporaire.

Limitation de débit (par client) : Chaque client authentifié est soumis à des limites de débit par service, à fenêtre glissante, définies dans son profil RBAC. Les requêtes dépassant la limite renvoient HTTP 429 et sont journalisées (RATE_LIMITED).

Limitation de débit globale (tous clients, par hôte de destination) : Une limite cumulative optionnelle protège chaque nœud Cisco individuellement. Indexée par hôte de destination + produit/service et vérifiée après la limite par client, elle se configure dans l'Admin Web UI (onglet Rate limiting et onglet Rate limiting de chaque produit). Un rejet est journalisé en RATE_LIMITED_GLOBAL.

Journal d'audit¶

Chaque événement pertinent pour la sécurité est écrit dans un fichier dédié audit.log au format JSON structuré, consultable depuis la page Audit de la Web UI (liste complète dans la Référence).

Catégorie d'événement	Ce qui est journalisé
Authentification	Vérification des tokens, émission et révocation des codes / tokens OAuth, mise en liste noire et libération d'IP
Appels MCP	Chaque décision RBAC et chaque appel d'outil / prompt / ressource — client, opération, hôte, résultat
Limitation de débit	Rejets par client (`RATE_LIMITED`) et globaux par hôte (`RATE_LIMITED_GLOBAL`)
Identifiants	Opérations d'enregistrement, de mise à jour et de suppression d'identifiants
Confiance des hôtes	Décisions d'approbation des empreintes SSH
Rapports	Écriture des rapports et export PDF
Admin Web UI	Connexions, verrouillages, chaque action de configuration, client, administrateur, licence et système
Serveur	Démarrage, arrêt, état de la licence, contrôles d'intégrité, refus pour maintenance
Transport	Violations des en-têtes `Host` / `Origin` (tentatives de DNS rebinding)

L'injection dans les journaux est empêchée par l'assainissement des caractères de contrôle dans toutes les valeurs journalisées (atténuation CWE-117).

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

Chaque version est signée. L'intégrité du package d'installation / de mise à jour est vérifiée grâce à sa somme de contrôle SHA-512, publiée par l'éditeur dans le DNS, avant l'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, avant tout autre sous-système : le serveur refuse de démarrer en cas de violation.
Un watchdog en arrière-plan la revérifie périodiquement et arrête proprement le serveur si une altération est détectée.

Sauvegardes chiffrées¶

Les sauvegardes sont protégées par un 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 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 authentification par clé SSH ou mot de passe chiffré ; politique de rétention distante configurable.
Vérification obligatoire de la clé d'hôte SFTP (anti-MITM) : la clé d'hôte du serveur SFTP doit être approuvée au préalable (Récupérer les clés du serveur dans la Web UI, empreintes vérifiées hors bande). Si l'hôte est inconnu, le transfert est interrompu avant l'envoi de tout identifiant.

Analyse de sécurité CI¶

Chaque push sur main / develop et chaque pull request 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 tolk-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 : tolk@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é de Tolk 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

La liste complète des standards supportés figure dans la Référence.