Application des politiques dans les enclaves sécurisées
Note de discussion préalable à la session sur la sémantique des politiques, les propriétés du moniteur de référence, le placement des contrôles, les preuves d’attestation et la gestion des défaillances.
Objet et statut
Cette note cadre PESAEAS Maroc n°2 à Casablanca. C’est un document de travail destiné à la revue technique, et non une norme d’implémentation ni l’affirmation qu’une technologie d’enclave résout à elle seule le problème du confinement.
La question centrale est de savoir comment une politique déclarée devient une frontière applicable dont les décisions peuvent être inspectées indépendamment de la charge autonome.
La politique comme frontière exécutable
Une politique n’est utile que si sa signification est assez précise pour être évaluée à l’exécution. Au minimum, une décision doit identifier le sujet, l’action demandée, l’objet ou la destination, le contexte pertinent et l’effet résultant.
Le modèle doit également définir les priorités, les valeurs par défaut, les limites de temps et de ressources, le traitement des exceptions et le comportement adopté lorsque le contexte requis est indisponible. En pratique, toute ambiguïté sur ces points devient une autorité.
- Sujet : charge, agent, outil, processus ou identité déléguée.
- Action : opération demandée, y compris les paramètres qui influencent le risque.
- Objet : donnée, service, appareil, fichier, destination ou capacité visée.
- Contexte : tâche, environnement, temps, état des ressources, provenance et décisions antérieures.
- Effet : autoriser, refuser, transformer, demander une approbation, terminer ou entrer dans un mode dégradé contrôlé.
Propriétés du moniteur de référence
Le composant qui applique la politique agit comme moniteur de référence. Sa crédibilité dépend moins de son nom que de trois propriétés.
- Médiation complète : toute transition pertinente passe par un point de contrôle.
- Résistance à l’altération : la charge ne peut modifier la politique, la logique de décision ni le chemin de preuve.
- Vérifiabilité : le mécanisme de confiance est assez réduit et explicite pour être inspecté, testé et raisonné.
Application à plusieurs niveaux
Aucun placement unique ne couvre toute la frontière. Une enclave pratique peut combiner plusieurs couches, chacune avec une responsabilité déclarée et une analyse de contournement.
- Couche applicative et outils : contraintes sémantiques sur les opérations, arguments, destinations et circuits d’approbation.
- Système d’exploitation : contrôles des processus, appels système, fichiers, identités, mémoire et ressources.
- Réseau et données : politique de sortie, destinations autorisées, classification des données et filtrage des sorties.
- Couche matérielle : identité de la charge, démarrage mesuré, mémoire protégée et attestation lorsque le modèle de menace l’exige.
- Couche opérationnelle : déploiement des politiques, garde des clés, contrôle d’urgence, retour arrière et conservation des preuves.
Attestation et preuves
L’attestation doit répondre à une question de vérification précise, et non servir de label général. Les preuves doivent relier l’environnement mesuré à la politique ayant gouverné une décision.
- Identité de la charge et de l’environnement, avec la version ou la mesure pertinente.
- Identifiant et empreinte de la politique, reliés à un historique de publication ou d’approbation.
- Décision enregistrée avec la requête, la règle applicable, le résultat et le point d’application.
- Exceptions, approbations humaines, dérogations d’urgence et modifications de l’état de politique.
- Informations d’intégrité et de temps permettant de détecter suppression, réordonnancement ou substitution dans le modèle de menace déclaré.
Modes de défaillance à examiner
Le chemin d’application introduit sa propre surface de défaillance. Il doit figurer dans le modèle de menace plutôt qu’être supposé fiable par définition.
- Conflits de politiques, valeurs par défaut ambiguës ou héritage dangereux.
- Écarts entre vérification et utilisation entre une décision et l’action qui en résulte.
- Chemins non médiatisés via plugins, diagnostics, canaux de mise à jour ou outils opérateur.
- Preuves enregistrant la décision prévue mais pas l’action réellement exécutée.
- Dérogations d’urgence persistant trop longtemps ou accordant trop d’autorité.
Questions pour la session de Casablanca
La session utilisera ces questions pour comparer les modèles de politique et les placements de contrôle.
- Quels champs sont nécessaires à un enregistrement minimal et interopérable d’une décision ?
- Quels contrôles doivent se situer au-dessus du système d’exploitation, et lesquels ne peuvent y rester en sécurité ?
- Que doit précisément prouver une attestation à un examinateur externe ?
- Comment rendre les mises à jour de politiques auditables sans ralentir la réponse aux incidents ?
- Quelles preuves démontrent l’application effective plutôt que la seule configuration ?
Révision
Après la session de Casablanca, la version 0.2 précisera le modèle de décision, identifiera les hypothèses contestées et consignera les questions d’application qui restent propres à chaque implémentation.