Liste de contrôle d'accès (ACL) : définition, types, exemples

Qu'est-ce qu'une liste de contrôle d'accès (ACL) ?

Une liste de contrôle d'accès (ACL, pour access control list) est une liste attachée à une ressource, comme un fichier, un sous-réseau ou un bucket, qui indique qui peut faire quoi avec elle. Chaque entrée désigne un sujet (utilisateur, groupe ou plage d'IP) et les droits autorisés ou refusés. Le système consulte la liste à chaque accès.

Comment fonctionne une ACL

Chaque ligne de la liste est une entrée de contrôle d'accès (ACE). Elle associe un sujet (qui), un droit comme lire, écrire ou exécuter (quoi) et, dans beaucoup de systèmes, une décision d'autoriser ou de refuser. Quand une requête arrive, le système cherche le sujet dans la liste. Certains systèmes s'arrêtent à la première entrée qui correspond, d'autres combinent toutes celles qui s'appliquent : la règle d'évaluation compte autant que les entrées.

Une ACL répond à la question « pour cette ressource, qui peut faire quoi ? ». C'est le point de vue inverse du contrôle d'accès basé sur les rôles, qui part de l'utilisateur et demande quels rôles il détient.

Exemple : une ACL POSIX de fichier

Sous Linux, la page de manuel acl(5) définit les types d'entrée : le propriétaire, des utilisateurs nommés, le groupe propriétaire, des groupes nommés, un masque et « other ». Voici l'ACL d'un fichier sous la forme courte qu'affiche getfacl :

user::rwx
user:alice:rw-
group::r-x
group:engineering:rwx
mask::rwx
other::r--

Alice peut lire et écrire sans être propriétaire. Le masque plafonne ce que les utilisateurs et groupes nommés peuvent réellement faire : avec un masque r--, Alice serait ramenée en lecture seule sans aucun avertissement.

Types d'ACL

• ACL de système de fichiers : elles complètent les droits du propriétaire, du groupe et des autres par des utilisateurs et groupes nommés. Les systèmes de fichiers Linux et NTFS sous Windows les prennent en charge.
• ACL réseau : elles autorisent ou refusent le trafic selon l'adresse, le port et le protocole. Dans AWS, une ACL réseau s'applique au niveau du sous-réseau, ses règles numérotées sont évaluées à partir du plus petit numéro, et elle est sans état (stateless) : le trafic retour demande sa propre règle. Les groupes de sécurité, eux, conservent l'état.
• ACL de stockage d'objets : elles accordent des droits de lecture et d'écriture de base sur un bucket ou un objet. Amazon S3 désactive les ACL par défaut sur les nouveaux buckets et recommande de les laisser désactivées, car les politiques de bucket sont plus expressives.
• ACL applicatives : des listes de permissions qu'une application SaaS ou un CMS tient par document, projet ou enregistrement.

ACL, RBAC et IAM

Une ACL est attachée à la ressource et convient à peu de ressources avec des exceptions inhabituelles. Le RBAC attribue les droits à des rôles et passe mieux à l'échelle quand beaucoup d'utilisateurs ont les mêmes fonctions. La gestion des identités et des accès (IAM) est la discipline plus large qui gère identités, rôles et politiques, et s'appuie souvent sur des ACL en dessous. En pratique on les combine : des rôles pour l'essentiel des accès, des ACL pour les exceptions.

Erreurs courantes avec les ACL

• Mauvais ordre des règles. Dans les systèmes où la première correspondance l'emporte, une autorisation large placée au-dessus d'un refus précis rend ce refus inopérant.
• Oublier le chemin retour. Sur une ACL réseau sans état, autoriser les requêtes entrantes sans la règle sortante correspondante laisse les connexions en suspens.
• Donner l'accès à « tout le monde ». Un groupe public sur un bucket expose son contenu à n'importe qui. Vérifiez d'abord ces autorisations lors d'un audit.
• Ignorer le masque. Une entrée POSIX peut sembler généreuse et pourtant être plafonnée par le masque.
• Laisser les entrées s'accumuler. Personne ne sait pourquoi une ancienne entrée existe et la supprimer semble risqué. Passez les ACL en revue régulièrement et attribuez un responsable à chaque entrée.

ACL, tests de charge et supervision

Un changement d'ACL est une cause classique d'erreurs 401, 403 ou de délai dépassé soudaines. Une ACL réseau ou un pare-feu qui rejette le trafic d'adresses inconnues bloquera aussi un test de charge : LoadFocus démarre des instances cloud à la demande, donc autorisez ses plages d'adresses IP publiées avant de tester. Si les erreurs n'apparaissent que sous charge, la limitation de débit en bordure peut en être la cause plutôt que l'application.

Pour repérer tôt une dérive de permissions, planifiez un contrôle sur un endpoint protégé avec la surveillance d'API en attendant le code de statut prévu, ou faites une vérification ponctuelle avec le vérificateur de statut d'API. Notre guide sur la sécurité des tests dans le cloud (en anglais) traite du contrôle d'accès des environnements de test, et la sécurité des API comme l'accès aux API couvrent le volet identifiants.

Questions fréquentes sur les ACL

Que signifie ACL ?

ACL signifie access control list, en français liste de contrôle d'accès. En réseau, on parle aussi d'ACL réseau (NACL).

Quelle différence entre une ACL et un pare-feu ?

Un pare-feu est un équipement ou un service qui filtre le trafic. Une ACL est la liste de règles avec laquelle il, ou un routeur, décide de ce qui passe. Beaucoup de pare-feu se configurent avec des règles de type ACL.

Une ACL, est-ce la même chose que le RBAC ?

Non. Une ACL liste des droits par ressource, le RBAC attribue des droits à des rôles que les utilisateurs détiennent. On les utilise souvent ensemble.

Faut-il utiliser les ACL S3 ?

En général non. Amazon S3 désactive les ACL par défaut et recommande plutôt les politiques. N'utilisez les ACL que si vous devez contrôler l'accès objet par objet.

Les ACL réseau conservent-elles l'état ?

Dans AWS, non. Une ACL réseau évalue chaque paquet séparément, il faut donc des règles dans les deux sens. Les groupes de sécurité conservent l'état et autorisent les réponses automatiquement.