Les politiques d’accès ajoutent des règles basées sur les attributs (ABAC) par-dessus les rôles et les groupes. Une politique examine qui demande, ce qu’il veut faire et dans quel contexte, puis autorise ou refuse. Utilisez les politiques pour restreindre ce que les rôles et les groupes autoriseraient sinon, par exemple « personne ne peut envoyer de commandes critiques depuis l’extérieur du réseau de l’usine » ou « le firmware ne peut être assigné que depuis une session ouverte avec une passkey ». Les politiques sont un outil avancé : la plupart des organisations n’ont besoin que des rôles et des groupes.
Vous avez besoin du rôle Owner. Ouvrez Settings > Access Policies (adresse /admin/access-policies).
Comment une décision est prise
Pour chaque requête soumise à contrôle :
- Toutes les politiques actives dont la cible correspond (ses actions et ses types de ressources) et dont toutes les conditions sont vérifiées sont collectées, par ordre de priorité (la plus basse s’exécute en premier).
- Si l’une d’elles refuse, la requête est rejetée. Le refus l’emporte toujours.
- Sinon, si une politique autorise, la requête est acceptée.
- Si aucune politique ne s’applique, la décision des rôles, des groupes et de la matrice est maintenue (« RBAC fallback »).
Les politiques sont des restrictions cumulatives : écrivez les exigences sous forme de politiques Deny. Une politique Permit dont les conditions ne sont pas vérifiées ne refuse rien ; la requête revient simplement à la décision fondée sur le rôle.
Les requêtes vues par les politiques
Les politiques sont vérifiées sur les routes qui appellent le moteur de politiques. La plupart des pages et des routes API de Hermetry le font ; quelques-unes non, car il n’y a pas de membre connecté à juger (la connexion elle-même, les connexions des appareils, les callbacks de webhooks, les tâches planifiées, les requêtes relevant du contrat propre à une clé API, comme SCIM). La page Coverage indique exactement quelles routes atteignent le moteur et, pour les autres, « What guards it instead ». Vérifiez-la avant de vous fier à une politique.
Important
Les pages IoT et l’API IoT transmettent l’action (la permission) et l’appelant aux politiques, mais aucun attribut d’appareil. Vous ne pouvez pas écrire une politique pour un seul appareil ou un seul site, et un membre autorisé à voir les appareils voit tous les appareils de l’organisation. Si des groupes de personnes ne doivent jamais voir les appareils des autres, placez ces appareils dans des organisations séparées. Testez toujours une politique dans le testeur d’accès et en mode shadow au préalable.
Créer une politique
- Sélectionnez New policy (ou Load examples pour partir de politiques prêtes à l’emploi).
- Saisissez un Name, le Effect (Permit, ou Deny (overrides any permit)) et la Priority (lower runs first). Sélectionnez Create & edit.
- Dans Definition, renseignez :
- Actions (comma-separated, empty = all) : identifiants de permissions, par exemple
iot_rpc.send.critical, iot_ota.assign. - Resource types (comma-separated, empty = all).
- Description : la raison d’être de la politique.
- Status : Active ou Inactive. Sélectionnez Save definition.
- Actions (comma-separated, empty = all) : identifiants de permissions, par exemple
- Sous Conditions, sélectionnez Add condition pour chaque test. « Toutes les conditions doivent être vérifiées (ET) pour que la politique s’applique. » Sélectionnez Save conditions.
Une politique sans condition s’applique à toute requête correspondant à sa cible.
Conditions
Chaque condition se compose d’un Attribute, d’un Operator et d’une Value (ou de Values (comma-separated)).
| Attribut | Signification |
|---|---|
subject.role | Le rôle intégré : OWNER, ADMIN, USER |
subject.roles | Le rôle plus les clés de groupes du membre |
subject.permissions | Les permissions accordées par les groupes du membre |
subject.id, subject.email | Le membre |
subject.department, subject.jobTitle | Issus du profil du membre, lorsqu’ils sont renseignés |
subject.amr | Mode de connexion de la session : pwd, otp, mfa, hwk (passkey), fed:saml, fed:<provider> |
subject.acr | Le niveau d’assurance qui en découle : NONE, LOW (mot de passe ou fédération seule), SUBSTANTIAL (un second facteur vérifié), HIGH (une passkey) |
environment.ip | L’adresse de l’appelant |
environment.now, environment.method, environment.userAgent, environment.host | Heure, méthode HTTP, navigateur, nom d’hôte |
action | La permission contrôlée |
Opérateurs : equals, not equals, in list, not in list, contains, greater than, less than, exists, matches regex, DN equals (RDN).
Un attribut absent est lu comme vide, ce qui satisfait not equals et not in list. C’est pourquoi les règles de refus sont sûres et les règles d’autorisation ne le sont pas.
Exemples
Refuser les commandes critiques et brutes sauf si la session a utilisé un second facteur ou une passkey :
| Champ | Valeur |
|---|---|
| Effet | Deny |
| Actions | iot_rpc.send.critical, iot_rpc.send.raw |
| Condition | subject.acr not in list SUBSTANTIAL, HIGH |
Empêcher les membres d’un groupe contractors d’écrire des attributs ou d’envoyer des commandes, quel que soit leur rôle :
| Champ | Valeur |
|---|---|
| Effet | Deny |
| Actions | iot_device.attributes.write, iot_rpc.send.basic, iot_rpc.send.privileged |
| Condition | subject.roles contains contractors |
Pour accorder un droit à un seul groupe, la matrice Access Rights est généralement plus simple qu’une politique : décochez la permission pour Admin et cochez-la pour le groupe. Voir Groups and permissions.
Mode shadow, testeur d’accès et journal des décisions
| Outil | Emplacement | Usage |
|---|---|---|
| Shadow Mode | Settings sur la page des politiques (Access Control Settings) | « Les politiques sont évaluées et les décisions sont journalisées, mais un refus ne bloque JAMAIS la requête. » Désactivé par défaut. Activez-le avant d’appliquer une nouvelle politique, surveillez le journal, puis désactivez-le. |
| Access tester | Simulator | « Simulez une décision avec les politiques en vigueur — rien n’est enregistré ni journalisé. » Saisissez Subject id, Subject role, Action, Resource type, Resource ownerId, Environment IP et un RBAC fallback role, puis Evaluate. La Policy trace affiche la cible et les règles de chaque politique. |
| Decision log | Decision log | Chaque requête évaluée avec son Effect, son Action, sa Reason (Policy permit, Explicit deny, RBAC fallback, Default deny, Not applicable) et son Subject. Les refus en mode shadow sont marqués Shadow. |
Decision Log Mode (All decisions, Deny only, Off ; par défaut all) et Permit Log Sample Rate (%) déterminent le volume journalisé dans le journal d’audit. Les refus sont toujours journalisés.
Bonnes pratiques
- Commencez par Load examples et lisez-les avant d’écrire vos propres politiques.
- Utilisez des politiques de refus avec des listes d’actions restreintes. Évitez les politiques sans action : elles jugent chaque requête.
- Ne verrouillez jamais les owners : testez chaque politique avec le rôle d’un owner dans le testeur d’accès.
- Les modifications prennent effet immédiatement sur tous les nœuds.