5.8 Accès

Qui a le droit de se connecter, ce qu'il a le droit de faire, et où ses identifiants sont vérifiés.

Users — /m/auth/user

Les comptes locaux. root existe dès le départ et ne peut pas être supprimé ; tout le reste, c'est vous qui le créez.

Pour chaque compte : l'identifiant et le nom complet, le mot de passe, l'appartenance aux groupes, une date d'expiration facultative, et les privilèges propres au compte. Un compte peut aussi porter une clé publique SSH et une graine de mot de passe à usage unique, là où ces fonctions sont activées.

Donnez à chacun son propre compte. Les connexions partagées rendent le journal d'audit inutile : System → Log Files → Audit enregistre qui a changé quoi, et « root » n'est pas un qui. Créez un compte par administrateur et gardez root pour la récupération.

Groups — /m/auth/group

Les groupes détiennent les privilèges, et les utilisateurs en héritent. Sur un boîtier avec plus de deux administrateurs, c'est la seule façon saine de gérer l'accès : définissez opérateurs réseau, auditeurs, support, puis déplacez les gens d'un groupe à l'autre.

Privileges — /privileges

L'autre sens : pour chaque privilège, quels utilisateurs et quels groupes le détiennent. C'est la page qui répond à « qui peut changer les règles du pare-feu ? » — en partant de la question plutôt que d'une personne.

Un compte en lecture seule se construit ainsi : donnez-lui les privilèges qui consultent et aucun de ceux qui écrivent. Le panneau montre à ces comptes une étiquette read-only dans le menu de compte, pour que personne ne se demande pourquoi Save a disparu.

Servers — /m/auth/authserver

Les annuaires externes auprès desquels le boîtier peut vérifier des identifiants : LDAP ou Active Directory, et RADIUS. Une fois un serveur configuré, un utilisateur peut être authentifié auprès de lui plutôt que par un mot de passe local — y compris les invités du portail captif et les utilisateurs VPN.

Pour LDAP, il vous faut l'adresse du serveur, le DN de base, les identifiants de liaison et l'attribut qui porte le nom d'utilisateur ; pour RADIUS, l'adresse, le port et le secret partagé. Les deux gagnent à être testés avant que quoi que ce soit n'en dépende — c'est la page suivante.

Tester — /auth-tester

Essaie un nom d'utilisateur et un mot de passe contre un serveur d'authentification choisi et rapporte exactement ce qui s'est passé, y compris les groupes revenus. Servez-vous-en avant de pointer le portail ou le VPN sur un nouvel annuaire : un échec ici est bien plus facile à lire qu'une connexion ratée ailleurs.

API Keys — /apikeys

Des identifiants pour machines. Une clé appartient à un utilisateur et hérite des privilèges de celui-ci ; la clé d'un système de supervision doit donc appartenir à un compte en lecture seule, pas à root.

Le secret n'est montré qu'une fois, à la création de la clé — le boîtier n'en garde qu'une empreinte et ne peut pas le remontrer. La liste note la dernière utilisation de chaque clé, et c'est ainsi que vous trouvez les clés dont plus rien ne se sert pour les retirer.

Une clé peut recevoir une date d'expiration. Une clé sans expiration survit à la raison pour laquelle elle a été créée ; une clé qui en a une force la conversation.