Ce que signifie « politique » dans Fundamentum
Dans Fundamentum, une politique définit quels rôles peuvent effectuer quelles actions, sur quelles catégories d’appareils, dans quels états de cycle de vie, sous quelles conditions. Les politiques sont versionnées, auditables et testables — elles peuvent être revues par un responsable conformité, approuvées dans un flux de gestion du changement, et validées contre une flotte de test avant la mise en production.
- Les règles vivent dans le code — cassées quand un développeur oublie l’appel
- Aucun historique de version — « quelle était la règle mardi dernier ? » reste sans réponse
- Non testable isolément — exige un déploiement applicatif complet
- Un nouvel équipier peut contourner une règle dont il ignore l’existence
- Les auditeurs n’ont rien à inspecter sinon les logs applicatifs
- Règles appliquées par la couche de gouvernance — un contournement exige un changement de configuration, lui-même journalisé
- Historique de version complet — chaque changement est un événement gouverné et auditable
- Testable contre une flotte de préproduction avant la mise en production
- Les nouveaux équipiers héritent de la politique — ils n’ont pas besoin de connaître la règle pour s’y conformer
- Les auditeurs inspectent le magasin de politiques — pas des revues de code
Contrôle d’accès fondé sur les rôles (RBAC)
Le modèle RBAC de Fundamentum définit les rôles selon trois dimensions : quelle classe d’action, sur quelle catégorie d’appareils, dans quel état de cycle de vie. L’intersection de ces trois dimensions détermine ce qui est permis — pas une liste de permissions à plat qui devient ingouvernable à l’échelle.
| Exemple de rôle | Classe d’action | Catégorie d’appareils | Restriction d’état |
|---|---|---|---|
| Opérateur de flotte | Lire la télémétrie, envoyer des commandes non destructives | Tous les appareils activés | Activé seulement |
| Ingénieur micrologiciel | Lancer une mise à jour OTA | Classe d’appareils assignée | Activé + Maintenance |
| Administrateur sécurité | Révoquer des identifiants, forcer le mode maintenance | Tous les appareils | Tout état |
| Autorité de décommissionnement | Décommissionner des appareils | Tous les appareils | Doit être en Maintenance |
| Auditeur en lecture seule | Lire la piste d’audit et la télémétrie | Tous les appareils | Tout état, lecture seule |
Encodage des exigences réglementaires
Les politiques Fundamentum peuvent encoder les exigences réglementaires comme une application au niveau de l’infrastructure — et non comme de la documentation de conformité que les développeurs sont censés lire et implémenter.
- RGPD / LPRPDE : Des politiques d’accès aux données qui appliquent les flux de droit à l’effacement au niveau de la gouvernance. Une demande de suppression déclenche un flux de décommissionnement gouverné, pas une opération manuelle en base de données.
- CCPA : Des politiques de minimisation des données appliquées à l’ingestion de télémétrie. Les appareils qui tentent de transmettre des champs hors de leur schéma déclaré sont refusés.
- IEC 62443 (industriel) : Modèles de zones et conduits encodés en restrictions de catégorie d’appareils. Les commandes inter-zones exigent une autorisation élevée.
- Santé (FDA, Santé Canada) : Les exigences de piste d’audit pour toutes les interactions avec les appareils sont nativement satisfaites par le journal inviolable de Fundamentum. Aucune couche de journalisation supplémentaire requise.
- Défense (ITAR/EAR, CPCSC) : Restrictions d’accès géographiques, exigences d’autorisation élevées pour les classes de commandes sensibles. Disponible pour les déploiements Stratys.