Sécurité · KANAP

Principes

KANAP est conçu pour les DSI qui manipulent des données sensibles. Nous traitons vos données comme nous voulons que nos fournisseurs IT traitent les nôtres, transparentes, isolées, à portée de main quand il le faut.

Transparent par défaut

Tout le code source est sur GitHub sous AGPL v3. Votre équipe sécurité le lit, l'audite ou le fork. Rien n'est caché derrière des binaires propriétaires.

Isolé par conception

La row-level security de la base de données elle-même impose l'isolation des tenants à chaque requête que l'application exécute.

Toujours exportable

Vos données sont à vous. Export CSV sur les listes principales, export documents en PDF, DOCX et ODT. Aucune taxe d'extraction.

Isolation des tenants

KANAP est multi-tenant au niveau base de données. Chaque ligne de chaque table partagée porte un `tenant_id`, et les policies PostgreSQL Row-Level Security appliquent le filtre sur chaque lecture et écriture. La policy fait partie du schéma de la base de données : elle s'applique à chaque requête de l'application.

Policies PostgreSQL RLS sur chaque table qui contient des données de tenant, toutes forcées
Filtrage `tenant_id` imposé au niveau base de données, pas juste dans l'app
Le tenant courant est posé au début de chaque transaction de base de données, et les policies le lisent
Le rôle de base de données de l'application n'a ni droit superutilisateur ni droit de contournement, et l'application refuse de démarrer sinon
Une table de données de tenant sans sa policy d'isolation fait échouer les tests de CI
Tests d'isolation des tenants à chaque exécution CI

Protection des données

Pratiques standards, appliquées rigoureusement. Hachage robuste des mots de passe, secrets chiffrés, jetons hachés et HTTPS sur chaque connexion au cloud.

Cloud : HTTPS pour chaque connexion entre les utilisateurs et la plateforme, avec redirection de HTTP vers HTTPS et Cloudflare qui termine TLS devant nos serveurs. Auto-hébergement : vous terminez TLS avec vos propres certificats
Hachage Argon2id des mots de passe (64 Mio de mémoire) avec sels par utilisateur
Secrets stockés via l'environnement, jamais dans le code
Vos propres clés de fournisseur IA et identifiants d'intégration (GLPI, Netbox) chiffrés au repos en AES-256-GCM
Jetons MCP et jetons de rafraîchissement de session stockés hachés, et révocables
Jeton d'accès conservé en mémoire dans le navigateur, jeton de rafraîchissement dans un cookie HttpOnly

Contrôle d'accès

Permissions fines par module, par rôle. Chaque feature gate et chaque requête d'entité respecte la même matrice RBAC, y compris Plaid et MCP.

Niveaux lecteur, contributeur, membre et administrateur par module
Rôle admin workspace distinct des admins de module
SSO via Microsoft Entra ID (OIDC) en cloud et auto-hébergé
Authentification locale par mot de passe avec Argon2 + flux optionnel de réinitialisation
Les tentatives de connexion sont limitées par adresse IP : 60 demandes de connexion par mot de passe et 60 demandes de connexion Microsoft par minute. Après 5 échecs de mot de passe sur un compte depuis une adresse IP en 15 minutes, cette adresse attend 15 minutes avant de pouvoir réessayer ce compte. Derrière un reverse proxy, les limites comptent l'adresse IP de chaque utilisateur
Les jetons de session ne sont acceptés que dans l'unique algorithme de signature avec lequel KANAP les émet
Plaid et MCP appliquent le même RBAC que l'UI, pas d'escalade de privilèges
Tokens API limités aux utilisateurs individuels, révocables à tout moment

Journal d'audit

Chaque modification significative est enregistrée, tout comme les connexions et les exports. Les administrateurs voient qui a changé quoi et quand, qui s'est connecté ou a échoué à le faire, et qui a exporté des données.

Chronologie d'activité par entité (tâches, projets, documents, etc.)
Créations, modifications et désactivations enregistrées avec l'utilisateur, l'horodatage et les valeurs avant et après
Modifications de rôles et d'autorisations enregistrées avec leur auteur et les valeurs avant et après
Connexions, échecs de connexion, déconnexions, renouvellements de session refusés, réinitialisations de mot de passe et connexions Microsoft enregistrés avec l'adresse IP et le navigateur. Les mots de passe et les jetons ne sont jamais écrits dans le journal
Exports produits par le serveur enregistrés avec qui a exporté quoi
Événements de connexion et de session conservés 365 jours
Les administrateurs consultent et filtrent le journal d'audit dans l'app, et l'exportent en CSV dans un format fixe que les outils de collecte de journaux lisent tel quel (jusqu'à 100 000 entrées par fichier)
Les modifications faites via Plaid sont enregistrées dans le même journal, avec leur origine. Les agents ont leur propre historique d'activité, avec les sources utilisées par chaque agent

Gouvernance des agents

Les agents agissent sous les mêmes contrôles que tout le reste, plus des limites propres au travail autonome. Chaque action d'agent est enregistrée et limitée à ce que vous avez autorisé, et vous pouvez arrêter un agent à tout moment. Chaque agent démarre avec tous ses types d'action soumis à votre approbation. Vous décidez quand un type passe en automatique, avec le bilan de l'agent (propositions examinées, taux d'acceptation, jours d'activité) affiché à côté du choix.

Les agents n'agissent qu'à travers des opérations définies, sans accès direct à la base de données ni au shell
Chaque agent limité aux opérations que vous autorisez. Qui peut configurer les agents ou examiner leur travail suit les mêmes rôles que le reste de l'application
Chaque action d'agent enregistrée dans l'historique d'activité de l'agent, conservé 30 jours par défaut et réglable de 7 à 90 jours
Les réponses portent les sources utilisées par l'agent, pour qu'une décision puisse être vérifiée
Mettez n'importe quel agent en pause immédiatement, un par un ou tous à la fois
Des plafonds de dépense par agent maintiennent le coût de fonctionnement borné
Les fonctions d'IA sont désactivées par défaut. Dans le cloud, le modèle intégré ne reçoit aucune donnée tant que le workspace n'a pas accepté son fournisseur et son lieu de traitement, tous deux indiqués dans l'application. Un administrateur les confirme, et une nouvelle confirmation est demandée si l'un des deux change. Vous pouvez utiliser votre propre fournisseur de modèle à la place

Chaîne d'approvisionnement logicielle

KANAP est construit à partir du code source public, et sa construction est contrôlée à chaque modification. Vous pouvez vérifier ce qui est livré.

L'image de l'API qui s'exécute contient seulement l'application compilée et ses dépendances de production, sans sources ni outils de développement
Les conteneurs tournent avec des privilèges réduits : l'API s'exécute sous un utilisateur sans privilège, et les conteneurs abandonnent les capacités Linux dont ils n'ont pas besoin sans pouvoir en acquérir de nouvelles
Le conteneur web envoie les en-têtes de sécurité standard (Content Security Policy, X-Frame-Options et d'autres) et n'annonce pas sa version de nginx
Les images de base sont épinglées sur un condensat (digest) fixe. Les mises à jour arrivent sous forme de pull requests qui passent les mêmes contrôles que toute autre modification
Chaque version publiée est accompagnée d'un inventaire des composants (CycloneDX) du backend, du frontend et du site web, de la liste des paquets de l'image de l'API et d'un fichier de notices tierces
Les licences des dépendances de production sont vérifiées à chaque fusion, et une dépendance sans licence ou avec une licence non acceptée bloque la fusion
Les actions de CI sont épinglées sur des hachages de commit complets, et le jeton des workflows est en lecture seule par défaut

Déploiement et exploitation

Les déploiements cloud tournent sur des hôtes Linux en Allemagne, dans l'Union européenne, avec Cloudflare en frontal. Les déploiements auto-hébergés tournent où vous décidez. Les deux embarquent le même modèle de sécurité.

Hébergement cloud chez Hetzner Online GmbH à Nuremberg, en Allemagne (UE), avec Cloudflare en frontal pour le CDN, la terminaison TLS et la protection
Auto-hébergement : le code source complet est public, et vous le construisez et l'exécutez vous-même avec Docker Compose
Auto-hébergement : aucun appel sortant obligatoire pour les fonctions de base, KANAP peut donc tourner sans accès internet
Auto-hébergement : vous choisissez où il tourne et comment il est sauvegardé
Auto-hébergement : les fonctions d'IA n'utilisent que le fournisseur de modèle configuré par votre administrateur
Auto-hébergement : au démarrage, KANAP avertit quand le secret de signature est court ou que le mot de passe du premier administrateur est encore une valeur d'exemple ou trop court
Auto-hébergement : la santé des conteneurs API et web apparaît dans la sortie de docker ps, et les journaux Docker sont plafonnés à environ 50 Mo par conteneur

Des questions sur la sécurité ?

Nous partageons volontiers les détails d'architecture et passons en revue un modèle de menaces avec votre équipe sécurité.

Parlons-en Auto-hébergez et auditez le code