Sécurité & isolation multi-clients
Les couches d'isolation
Une donnée n'est accessible que si toutes ces couches concordent. Il n'existe pas de chemin applicatif permettant à une structure d'interroger les données d'une autre.
Détail par couche
1. Identité. Les rôles d'un utilisateur ne portent que sur les applications de son organisation. Une URL appartenant à une autre structure renvoie un refus d'accès, pas une page de connexion exploitable.
2. Application. Les outils dédiés sont des instances distinctes. Les services mutualisés (messagerie, signature, Git, visio) reposent sur un cloisonnement par organisation, dont l'appartenance est vérifiée à chaque requête.
3. Exécution. Chaque client dispose d'un espace d'exécution dédié dans l'orchestrateur, avec ses propres identités de service et ses propres politiques réseau.
4. Données. Chaque application possède son rôle de base de données et son mot de passe, générés à la création et jamais réutilisés d'un client à l'autre. Aucun composant applicatif ne se connecte avec un compte d'administration.
5. Stockage. Les volumes sont dédiés, répliqués sur plusieurs nœuds et chiffrés au repos.
6. Sauvegarde. Chaque structure a une clé AES-256 qui lui est propre. Une sauvegarde extraite du stockage sans la clé correspondante est inexploitable.
Chiffrement
| Où | Quoi |
|---|---|
| En transit, côté public | HTTPS obligatoire, certificats publics renouvelés automatiquement |
| En transit, entre sites d'infrastructure | Tunnels chiffrés |
| Au repos, volumes | Chiffrement des volumes de données |
| Au repos, sauvegardes | AES-256, clé par client |
| Coffre-fort de mots de passe | Chiffrement de bout en bout, clé dérivée côté navigateur |
| E-mails sortants | TLS opportuniste, signature DKIM |
Gestion des accès d'exploitation
- L'accès d'administration à l'infrastructure est réservé à l'équipe d'exploitation, via des canaux d'administration privés, non exposés publiquement.
- Les secrets d'exploitation sont stockés hors des dépôts de code.
- Les déploiements passent par le pipeline GitOps : les changements sont versionnés et traçables.
Cycle de vie et effacement
La suppression d'une structure est destructive et complète : espaces d'exécution, bases, volumes (y compris les réplicas sur disque), boîtes mail et leur contenu sur disque, zone DNS, comptes et organisations sur les services mutualisés, ainsi que les sauvegardes chiffrées et la clé associée.
Il n'existe ni corbeille, ni état « désactivé » conservant les données. Cette exigence est volontaire : un identifiant de structure peut être réattribué, tout résidu constituerait une fuite entre clients. Un contrôle automatisé vérifie l'absence de résidus après suppression.
Ce que nous vous demandons de faire
| Recommandation | Pourquoi |
|---|---|
| Utiliser le coffre-fort plutôt qu'un tableur partagé | Les secrets circulent moins |
| Retirer un collaborateur dès son départ | Un clic suffit et coupe tout |
| Activer la fédération Microsoft si vous avez déjà une politique MFA | Vous héritez de vos contrôles |
| Conserver la clé de sauvegarde hors ligne | Elle ne vous est remise qu'une fois |
| Réserver le rôle Administrateur au strict nécessaire | Il donne les pleins droits sur tous les outils |
Signalement de vulnérabilité
Si vous pensez avoir découvert une faille, contactez-nous via la page de contact en décrivant la vulnérabilité et sa reproduction. Nous accusons réception et vous tenons informés du traitement. Merci de ne pas divulguer publiquement avant correction.