Une liste de contrôle d'accès (ACL) dans Access Gate est la table qui répond à une seule question pour chaque session : ce principal est-il autorisé à atteindre cet actif via ce protocole, maintenant ? La table est modifiable par enclave, consultable sur l'ensemble du déploiement, et adossée à votre fournisseur d'identité.
Structure d'une entrée ACL
Chaque ligne relie cinq éléments :
| Champ | Exemple | Notes |
|---|---|---|
| Principal | alice@acme.com, group:ot-ops, asset A | Un utilisateur, un groupe issu de votre IdP, ou un autre actif |
| Actif | plc-42.ot-cell-a, all assets in enclave | Un actif spécifique ou tous les actifs de l'enclave |
| Protocole | rdp, ssh, https, any | Les protocoles autorisés pour la session |
| Permission | allow, block | Par défaut : refus, seules les règles allow ouvrent un chemin |
| Configuration avancée | tls required, VPN allowed, Secured Remote Acces, Access Agreement | Configurations spécifiques appliquées en complément de la permission |
ACL pour les utilisateurs
Ajouter chaque utilisateur individuellement ne passe pas à l'échelle. Access Gate prend en charge les ACL liées à des groupes d'utilisateurs synchronisés depuis votre IdP, Entra ID, Okta ou Microsoft 365.
Ajouter une ACL basée sur un groupe
- Synchronisez d'abord vos groupes IdP : voir Synchroniser l'annuaire utilisateur (Entra ID).
- Accédez à Enclaves → [Your Enclave] → Access Control.
- Cliquez sur Add rule.
- Pour Principal, sélectionnez Group et choisissez le groupe IdP.
- Sélectionnez le ou les actifs et le ou les protocoles.
- Enregistrez.
L'appartenance au groupe est réévaluée à chaque session, l'utilisateur n'a pas besoin de se reconnecter pour qu'un changement de groupe prenne effet.
Ajouter une ACL spécifique à un utilisateur
Si vous préférez gérer les accès au niveau de l'utilisateur, c'est également possible !
Refus par défaut
Access Gate applique un refus par défaut : une session est rejetée sauf si une règle allow correspondante existe. Il n'y a pas de règle implicite « les membres de l'enclave peuvent tout faire », chaque protocole sur chaque actif fait l'objet d'une autorisation explicite.
La configuration initiale d'une enclave est donc volontairement stricte. Prévoyez de :
- Créer l'enclave et y ajouter des membres.
- Activer l'inspection du trafic pour observer ce que les membres tentent réellement de faire.
- Traduire les flux observés en règles ACL.
Le Démarrage rapide décrit cette procédure étape par étape.
Les modifications sont auditées
Toute modification d'ACL est enregistrée dans l'historique des changements de l'enclave (voir Consulter l'historique des modifications d'une enclave), avec l'opérateur, l'horodatage et les valeurs avant/après. Les modifications des permissions d'écran d'accès sont consignées de la même façon.
Récapitulatif
Nous avons écrit des règles ACL par enclave qui accordent à un principal (utilisateur, groupe IdP ou actif) l'accès à des actifs précis via des protocoles précis, selon un principe de refus par défaut.
À privilégier dès que vous avez besoin d'un contrôle fin et adossé aux groupes sur qui atteint quoi et comment, en faisant porter les décisions d'accès par votre fournisseur d'identité plutôt que par des modifications utilisateur par utilisateur.