Comment nous sécurisons
Itamite de l'intérieur.
Il ne suffit pas que les frameworks disent que vous êtes conforme. Nous expliquons ici ce que nous faisons en architecture, cryptographie, opération, hardening, supply chain et réponse aux incidents pour qu'Itamite soit véritablement sécurisé. Sans marketing, avec des détails concrets vérifiables.
Philosophie de sécurité
Itamite gère des inventaires sensibles et permet le contrôle distant sur les endpoints d'organisations critiques : hôpitaux, administrations publiques, banques, fintechs, cabinets comptables. Une brèche dans Itamite n'est pas notre incident ; c'est un incident pour tous les clients simultanément. C'est pourquoi nous opérons selon le principe "secure by design, secure by default, secure by operation" : la conception empêche des catégories entières de défaillances, les paramètres par défaut sont sécurisés, et l'opération est auditée en continu.
L'audit immuable hash-chain qu'Itamite offre à ses clients, nous l'appliquons aussi à notre propre opération interne : chaque accès d'un technicien Itrion à la production est enregistré avec SHA-256 vérifiable. Chaque modification de la configuration d'un tenant est horodatée cryptographiquement. Zéro exception pour les administrateurs. Si Itrion était piraté demain, les logs seraient démontrablement inaltérables.
Nous publions cette page délibérément verbeuse parce que nous croyons que la transparence fait partie de la sécurité. Si nous disons seulement "we take security seriously" sans détails, vous ne pouvez rien vérifier. C'est pourquoi nous expliquons l'architecture, les décisions cryptographiques, l'opération, le hardening du cluster, la supply chain, le programme de pentesting et le processus de réponse aux incidents avec des données concrètes.
Comment est construite la sécurité d'Itamite
Isolation multi-tenant stricte
Chaque tenant dispose d'une base de données logique séparée avec tenant_id dans toutes les tables et RLS (Row Level Security) sur PostgreSQL. Cluster Kubernetes avec NetworkPolicies segmentant le trafic par namespace. Pour Enterprise : option single-tenant avec cluster Kubernetes dédié et BYOK.
Chiffrement au repos et en transit
TLS 1.3 obligatoire sur toutes les communications (agent-serveur, client-serveur, serveur-BDD). Chiffrement AES-256-GCM au repos pour PostgreSQL et MinIO/S3. Pour les données très sensibles (audit logs) : chiffrement au niveau applicatif avec clé par tenant. BYOK optionnel Enterprise.
Sessions distantes E2E
Diffie-Hellman éphémère pour chaque session de contrôle distant. Même Itrion ne peut pas lire le contenu de l'écran, de l'audio ou du clavier pendant une session. Seules les métadonnées (qui a accédé, quand, durée) restent dans les logs. Enregistrement optionnel avec SHA-256 signé stocké dans le MinIO/S3 du client.
Audit immuable hash-chain
Chaque événement (accès, changement de configuration, session distante, inventaire, commande exécutée) est journalisé avec SHA-256 incluant le hash du log précédent. Toute modification rétroactive rompt la chaîne et est détectable. Inaltérable même par les DBA Itrion.
Hardening du cluster Kubernetes
CIS Kubernetes Benchmark v1.8 appliqué intégralement. Pod Security Standards "restricted". NetworkPolicies par namespace. Service Mesh (Istio) avec mTLS automatique. Secrets chiffrés avec sealed-secrets + external-secrets depuis HashiCorp Vault. Ingress avec WAF (ModSecurity + OWASP CRS).
Sécurité de la supply chain
SBOM publié pour chaque release (formats SPDX + CycloneDX). Images Docker signées avec cosign + sigstore. Attestations de provenance SLSA Level 3. Renovate bot pour la détection de dépendances vulnérables. CI/CD qui refuse le merge si des CVE critiques ne sont pas patchées.
Opération et réponse
Programme de pentesting annuel avec BDO Madrid : trois semaines de tests, rapport détaillé, remédiation obligatoire avant publication. Bug bounty public à partir du Q3 2026. SOC interne avec détection 24x7 (Wazuh + Grafana + alertes à l'équipe d'astreinte rotative). RTO <4h, RPO <15 min pour Enterprise. Sauvegardes chiffrées off-site avec réplication MinIO vers trois datacenters UE différents. Processus de réponse aux incidents : détection automatique + analyse de sévérité + escalade au CISO d'Itrion + communication aux clients affectés en <2h pour les incidents confirmés + post-mortem public 7 jours plus tard avec root cause et mesures préventives. Politique transparente : nous communiquons les incidents même lorsque nous ne sommes pas légalement tenus de le faire.
- Pentesting annuel : BDO Madrid (cabinet indépendant)
- SOC interne 24x7 : astreinte rotative permanente
- RTO <4h, RPO <15 min : pour les clients Enterprise
- Sauvegardes chiffrées : répliquées dans 3 datacenters UE
- Politique transparente : communication des incidents en <2h
Questions sur la sécurité de la plateforme
Puis-je demander le dernier rapport de pentesting ?
Que se passe-t-il si Itrion est piraté ?
Le BYOK est-il disponible ?
Êtes-vous conformes ISO 27001 ?
Plus de détails sous NDA
Si vous avez besoin du rapport pentesting complet, de l'architecture technique détaillée ou d'une due diligence de sécurité : contactez-nous.