Sécurité et confiance
Cette page explique comment Fundamentum protège vos appareils, vos utilisateurs et applications, ainsi que la plateforme elle-même. Elle est destinée à vos équipes informatiques et de sécurité.
Appareils
Chaque appareil franchit trois barrières avant d'atteindre ses données.
| Barrière | Ce que cela signifie pour vous |
|---|---|
| Transport chiffré | Les appareils se connectent uniquement via TLS : MQTT 5 sur TLS vers le broker, HTTPS vers la Devices API. |
| Authentification | Chaque appareil possède sa propre identité, basée sur une paire de clés RSA. L'appareil conserve sa clé privée et signe avec elle un jeton de courte durée (un JWT RS256) pour se connecter. Fundamentum ne stocke que la clé publique : aucun secret partagé ne circule donc sur le réseau, et un appareil sans clé enregistrée est rejeté. |
| Autorisation | Un appareil connecté n'accède qu'à ses propres topics. Il ne peut lire ni écrire les topics d'un autre appareil, ni quoi que ce soit dans un autre registre, projet ou client. Cet isolement est aussi ce qui sépare un client d'un autre. |
Derrière ces barrières :
- Clés publiques uniquement. La clé privée est générée sur l'appareil ou par la personne qui le prépare, et n'atteint jamais Fundamentum.
- Les champs sensibles des appareils sont chiffrés au repos.
- Chaque tentative d'authentification est auditée, qu'elle réussisse ou non.
- Fenêtres de provisionnement et quotas. Un registre n'accepte de nouveaux appareils que pendant sa fenêtre de provisionnement, et seulement jusqu'à un quota par type d'appareil.
- Sûr par défaut. Un appareil n'est jamais reprovisionné par accident : le remplacement des informations d'identification d'un appareil déjà provisionné est toujours une étape explicite.
Consultez Mettre en service et sécuriser les appareils et Authentification.
Utilisateurs et applications
Chaque personne et chaque application se connecte via Connect, le serveur OAuth2 de Fundamentum, puis appelle la Public API avec le jeton reçu.
| Qui | Comment la connexion s'effectue |
|---|---|
| Les personnes, dans le Hub ou dans vos propres applications web et mobiles | OAuth2 Authorization Code avec PKCE |
| Vos systèmes back-end, scripts et intégrations | OAuth2 Client Credentials (machine à machine), ou un jeton de compte de service |
La CLI fun |
Connexion par navigateur, puis les mêmes jetons |
- Authentification unique. Les utilisateurs peuvent se connecter avec Google ou Microsoft, de sorte que les politiques d'authentification multifacteur et de mots de passe de votre propre fournisseur d'identité s'appliquent. L'authentification unique peut être imposée par projet, par licence ou par site.
- Connexion personnalisée. La page de connexion de chaque application peut afficher son propre logo et son propre arrière-plan.
- RBAC granulaire. Un rôle est un ensemble nommé de permissions, accordé sur une organisation, un projet ou une licence. Les licences vous permettent de servir vos propres clients, chacun avec ses propres utilisateurs et sites, sans leur donner accès au reste de votre projet.
- Chaque appel est vérifié. La passerelle API vérifie le jeton et la permission de l'appelant à chaque requête, et seuls les appels autorisés atteignent la plateforme.
- Journal d'audit et limitation du débit. Chaque appel à la Public API est enregistré dans un journal d'audit, et le débit des requêtes est limité par utilisateur.
Consultez Gérer les accès et Rôles et permissions.
Plateforme
- Les secrets sont conservés dans un magasin de secrets dédié, scellé par un service de gestion de clés. Les secrets versionnés avec la configuration de la plateforme sont stockés chiffrés.
- Accès opérateur juste-à-temps. Les opérateurs de Dimonoff reçoivent des informations d'identification éphémères en lecture seule pour les systèmes et bases de données de production, émises via l'authentification unique et valables quelques heures.
- TLS sur chaque point d'entrée externe.
- Sauvegardes de base de données chiffrées.
- Analyse continue. La posture de sécurité de l'infrastructure est analysée en continu, et chaque modification de la plateforme passe par une analyse de vulnérabilités avant sa livraison.
- Tout en tant que code. L'infrastructure et les déploiements sont définis dans git et révisés, sans aucune modification manuelle de la production. Consultez Vue d'ensemble de l'architecture.
Page d'état
Fundamentum publie une page d'état publique présentant la santé des composants de la plateforme. Vous pouvez vous y abonner pour être notifié des incidents par courriel, Slack ou Microsoft Teams.
Étapes suivantes
- Vue d'ensemble de l'architecture
- Gérer les accès
- Authentification : obtenir un jeton et appeler l'API.