Résolution des problèmes courants de configuration de sécurité RabbitMQ

Les problèmes de configuration de sécurité RabbitMQ se manifestent généralement par des échecs de connexion, des erreurs 403 ACCESS_REFUSED ou des négociations TLS qui ne se terminent jamais. La solution dépend de l'étape où la connexion échoue : authentification, accès au vhost, permissions des ressources ou validation du certificat.

Utilisez ce guide pour vérifier ces couches dans l'ordre. Il se concentre sur les commandes RabbitMQ pratiques et les points de configuration que vous pouvez vérifier sans deviner.

Problèmes d'autorisations et de contrôle d'accès des utilisateurs

Le problème de sécurité le plus courant provient d'autorisations utilisateur incorrectes. RabbitMQ utilise un système de contrôle d'accès granulaire basé sur des balises et des autorisations de ressources (configurer, écrire, lire) pour les échanges, les files d'attente et les liaisons.

Diagnostic des autorisations manquantes

Lorsqu'une application ne peut pas se connecter, publier ou consommer des messages, la première étape consiste à vérifier les autorisations effectives de l'utilisateur. Vous pouvez utiliser l'interface du plugin de gestion RabbitMQ ou l'outil en ligne de commande rabbitmqctl.

Symptômes courants :

• La connexion s'ouvre, mais les opérations de publication ou de consommation échouent avec ACCESS_REFUSED.
• L'utilisateur peut publier sur un échange existant mais ne peut pas déclarer une file d'attente.
• Le même nom d'utilisateur fonctionne dans un vhost mais échoue dans un autre.

Vérification des balises et autorisations utilisateur via rabbitmqctl

Pour vérifier les balises et autorisations de l'utilisateur, utilisez :

rabbitmqctl list_users
# Recherchez l'utilisateur et ses balises (par exemple, administrator, management)

rabbitmqctl list_user_permissions nom_utilisateur
# Affiche les vhosts où l'utilisateur a des autorisations de configurer, écrire et lire.

rabbitmqctl list_permissions -p /votre_vhost
# Affiche les autorisations pour tous les utilisateurs sur un vhost.

Résolution des lacunes d'autorisations

Les autorisations doivent être définies au niveau du Virtual Host (vhost) et souvent affinées au niveau de la Ressource (échange/file d'attente).

Exemple : accorder à un utilisateur d'application l'accès aux ressources commençant par app. sur /app_vhost :

rabbitmqctl set_permissions -p /app_vhost app_user "^app\\." "^app\\." "^app\\."

Les autorisations RabbitMQ sont des expressions régulières dans cet ordre : configurer, écrire, lire. En production, évitez ".*" sauf si l'application possède vraiment chaque ressource dans ce vhost. Si app_user publie uniquement sur orders_exchange et consomme depuis processing_queue, accordez l'accès en écriture au nom de l'échange et l'accès en lecture au nom de la file d'attente.

La balise administrator est destinée aux utilisateurs de gestion RabbitMQ, pas aux applications normales. Elle accorde un accès de gestion étendu et ne doit pas être utilisée comme raccourci pour corriger les autorisations des applications.

Échecs d'authentification

Les échecs d'authentification se produisent lorsque le courtier rejette les informations d'identification de l'utilisateur (nom d'utilisateur/mot de passe) avant même le début des vérifications de contrôle d'accès.

Causes courantes

• Mots de passe non correspondants : Le secret du client ne correspond pas au mot de passe stocké dans RabbitMQ.
• Mauvais nom d'utilisateur ou vhost dans l'URI : Les URL AMQP incluent le chemin du vhost, donc / est encodé en %2F.
• Mécanisme d'authentification incompatible : Par exemple, un flux de certificat client TLS peut nécessiter le mécanisme EXTERNAL, tandis que les clients nom d'utilisateur/mot de passe utilisent généralement des mécanismes tels que PLAIN ou AMQPLAIN.

Dépannage de l'authentification à l'aide des journaux

Les échecs d'authentification sont enregistrés par le courtier. Sur de nombreux packages Linux, les journaux se trouvent dans /var/log/rabbitmq/ ; les déploiements conteneurisés envoient généralement les journaux vers stdout ou le pilote de journalisation du conteneur.

Recherchez des lignes contenant :

=ERROR REPORT==== AAAA-MM-JJ HH:MM:SS ===
Error in server: {auth_failed,<<...>>}

Réinitialisation ou changement de mots de passe

Si les informations d'identification sont perdues ou suspectées d'être compromises, réinitialisez-les immédiatement :

# Changez le mot de passe pour 'app_user'
rabbitmqctl change_password app_user nouveau_mot_de_passe_sécurisé

Erreurs de configuration SSL/TLS et de certificat

Lors de l'application d'une communication sécurisée (AMQPS ou WebSockets sécurisés), les problèmes de certificat et de magasin de confiance sont des maux de tête courants de configuration de sécurité.

Symptômes d'échec SSL/TLS

• Les tentatives de connexion du client expirent ou sont immédiatement rejetées.
• Le client signale des erreurs telles que SSL handshake failed, certificate verify failed ou unknown ca.

Vérifications clés de la configuration

A. Vérification du certificat serveur

Assurez-vous que la chaîne de certificats présentée par le serveur RabbitMQ est valide et approuvée par le client.

1. Vérifiez la configuration du serveur : Vérifiez que les fichiers de certificat (.pem ou similaire) et de clé corrects sont référencés dans le fichier rabbitmq.conf pour l'écouteur :

   # Exemple d'extrait rabbitmq.conf
   listeners.ssl.default = 5671
   ssl_options.cacertfile = /chemin/vers/ca_certificate.pem
   ssl_options.certfile = /chemin/vers/server_certificate.pem
   ssl_options.keyfile = /chemin/vers/server_key.pem
   

2. Vérifiez le magasin de confiance du client : Si le certificat du serveur est auto-signé ou signé par une AC privée, le client doit approuver ce certificat d'AC.

B. Incompatibilités de chiffrement et de protocole

Si le client et le serveur ne peuvent pas s'accorder sur une suite de chiffrement ou une version TLS commune (par exemple, le client ne prend en charge que TLS 1.2, mais le serveur est configuré uniquement pour TLS 1.3), la négociation échoue.

Définissez explicitement les versions TLS prises en charge dans rabbitmq.conf si vous avez besoin d'une application stricte du protocole. Sinon, RabbitMQ dépend de la prise en charge TLS fournie par l'environnement d'exécution Erlang/OTP sous-jacent et votre version de RabbitMQ.

# Définissez explicitement les versions autorisées (par exemple, forcer TLS 1.2 et 1.3)
ssl_options.versions.tcp = [tlsv1.2, tlsv1.3]

C. Authentification par certificat client (mTLS)

Si les clients doivent présenter des certificats :

1. Définissez ssl_options.verify = verify_peer.
2. Définissez ssl_options.fail_if_no_peer_cert = true lorsqu'un certificat client est requis.
3. Configurez ssl_options.cacertfile ou ssl_options.cacerts_path pour que RabbitMQ approuve l'AC qui a signé les certificats clients.
4. Configurez l'authentification basée sur les certificats, généralement avec le plugin rabbitmq_auth_mechanism_ssl, et assurez-vous que l'identité du certificat correspond à un nom d'utilisateur RabbitMQ attendu.

Problèmes d'accès au Virtual Host

Les utilisateurs ne peuvent accéder qu'aux ressources des vhosts auxquels ils ont explicitement accès.

Le vhost par défaut (/)

Si un utilisateur est créé mais n'est attribué à aucun vhost, il ne peut pas se connecter ni opérer. Si vous utilisez le vhost par défaut (/), assurez-vous que l'utilisateur y a des autorisations.

Utilisez l'interface de gestion ou rabbitmqctl pour lister les vhosts où l'utilisateur a des autorisations :

rabbitmqctl list_user_vhosts nom_utilisateur

Si l'utilisateur a besoin d'accéder à un vhost nommé billing_vhost, assurez-vous que l'utilisateur est lié :

rabbitmqctl set_permissions -p billing_vhost app_user "^billing\\." "^billing\\." "^billing\\."

À retenir

Vérifiez les échecs de sécurité RabbitMQ dans l'ordre : écouteur et TLS d'abord, puis informations d'identification, puis accès au vhost, puis autorisations de configurer/écrire/lire. Cet ordre vous évite de réécrire les autorisations alors que le vrai problème est une mauvaise URL AMQP, une AC non approuvée ou une autorisation de vhost manquante.