1 Contrôle d'accès

Vue d’ensemble

Cette section contient les bonnes pratiques pour configurer le contrôle d’accès de manière sécurisée.

Principe du moindre privilège

Les comptes utilisateur doivent, à tout moment, fonctionner avec le moins de privilèges possible. Cela signifie que les comptes utilisateur dans le frontend Zabbix, les utilisateurs de la base de données ou l’utilisateur des processus Zabbix server/proxy/agent ne doivent disposer que des privilèges strictement nécessaires à l’exécution des fonctions prévues.

Accorder des privilèges supplémentaires à l’utilisateur « zabbix » lui permettra d’accéder aux fichiers de configuration et d’exécuter des opérations susceptibles de compromettre la sécurité de l’infrastructure.

Lors de la configuration des privilèges des comptes utilisateur, les types d’utilisateur du frontend de Zabbix doivent être pris en compte. Notez que, bien que le type d’utilisateur Admin dispose de moins de privilèges que le type d’utilisateur Super Admin, il peut toujours gérer la configuration et exécuter des scripts personnalisés.

Certaines informations sont disponibles même pour les utilisateurs non privilégiés. Par exemple, bien que Alerts → Scripts soit disponible uniquement pour les utilisateurs Super Admin, les scripts peuvent également être récupérés via l’API Zabbix. Dans ce cas, limiter les autorisations des scripts et exclure des scripts les informations sensibles (par exemple, les identifiants d’accès) peut aider à éviter l’exposition d’informations sensibles présentes dans les scripts globaux.

Utilisateur sécurisé pour l'agent Zabbix

Par défaut, les processus du serveur Zabbix, du proxy et de l'agent (ou agent 2) partagent un même utilisateur zabbix. Pour empêcher l'agent Zabbix/agent 2 (s'exécutant sur la même machine que le serveur/proxy) d'accéder à des informations sensibles dans la configuration du serveur/proxy (par exemple, les identifiants de la base de données), l'agent doit être exécuté sous un utilisateur différent :

Pour l'agent Zabbix :

  1. Créez un groupe et un utilisateur sécurisés (par exemple, zabbix-agent).
  2. Définissez cet utilisateur dans le paramètre User du fichier de configuration de l'agent.
  3. Redémarrez l'agent afin d'abandonner les privilèges au profit du nouvel utilisateur.

Pour l'agent Zabbix 2, la configuration doit être appliquée au niveau du service, car le fichier de configuration de l'agent 2 ne prend pas en charge le paramètre User. Pour un exemple, voir ZBX-26442.

Révoquer l'accès en écriture à la configuration SSL (Windows)

Si vous avez compilé l'agent Zabbix sous Windows, avec OpenSSL situé dans un répertoire non protégé (par exemple, C:\zabbix, c:\openssl-64bit, C:\OpenSSL-Win64-111-static ou C:\dev\openssl), veillez à révoquer l'accès en écriture à ce répertoire pour les utilisateurs non administrateurs. Dans le cas contraire, l'agent charge les paramètres SSL depuis un chemin pouvant être modifié par des utilisateurs non privilégiés, ce qui entraîne une vulnérabilité de sécurité potentielle.

Renforcement de la sécurité des composants Zabbix

Certaines fonctionnalités peuvent être désactivées afin de renforcer la sécurité des composants Zabbix :

  • l’exécution globale de scripts sur le serveur Zabbix peut être désactivée en définissant EnableGlobalScripts=0 dans la configuration du serveur ;
  • l’exécution globale de scripts sur le proxy Zabbix est désactivée par défaut (elle peut être activée en définissant EnableRemoteCommands=1 dans la configuration du proxy) ;
  • l’exécution globale de scripts sur les agents Zabbix est désactivée par défaut (elle peut être activée en ajoutant un paramètre AllowKey=system.run[<command>,*] pour chaque commande autorisée dans la configuration de l’agent) ;
  • l’authentification HTTP des utilisateurs peut être désactivée en définissant $ALLOW_HTTP_AUTH=false dans le fichier de configuration du frontend (zabbix.conf.php). Notez que la réinstallation du frontend (exécution de setup.php) supprimera ce paramètre.

Accès aux chemins UNC sous Windows par l'agent Zabbix

Les agents Zabbix sous Windows suivent les chemins UNC (partages SMB comme \\server\share\file.txt) dans des éléments tels que vfs.file.*, vfs.dir.*, modbus.get et perf_counter*. Cela peut représenter un risque de sécurité dans certains contextes.

Lorsque Windows est invité à accéder à un chemin UNC, il tente de s'authentifier sur ce serveur. Cela signifie qu'une requête malveillante adressée à l'agent Zabbix peut exposer le hachage NTLM au serveur du demandeur. Les utilisateurs peuvent atténuer ce risque à l'aide des paramètres de configuration AllowKey et DenyKey si nécessaire.