Solución de Problemas Comunes de Configuración de Seguridad en RabbitMQ

Los problemas de configuración de seguridad en RabbitMQ suelen manifestarse como inicios de sesión fallidos, errores 403 ACCESS_REFUSED o handshakes TLS que nunca se completan. La solución depende de dónde falla la conexión: autenticación, acceso al vhost, permisos de recursos o validación de certificados.

Utilice esta guía para verificar esas capas en orden. Se centra en comandos prácticos de RabbitMQ y puntos de configuración que puede verificar sin adivinar.

Problemas de Permisos de Usuario y Control de Acceso

El problema de seguridad más común proviene de permisos de usuario incorrectos. RabbitMQ utiliza un sistema de control de acceso granular basado en etiquetas y permisos de recursos (configurar, escribir, leer) para exchanges, colas y bindings.

Diagnóstico de Permisos Faltantes

Cuando una aplicación no puede conectarse, publicar o consumir mensajes, el primer paso es verificar los permisos efectivos del usuario. Puede usar la interfaz del Plugin de Gestión de RabbitMQ o la herramienta de línea de comandos rabbitmqctl.

Síntomas comunes:

• La conexión se abre, pero las operaciones de publicación o consumo fallan con ACCESS_REFUSED.
• El usuario puede publicar en un exchange existente pero no puede declarar una cola.
• El mismo nombre de usuario funciona en un vhost pero falla en otro.

Verificación de Etiquetas y Permisos de Usuario mediante rabbitmqctl

Para verificar las etiquetas y permisos del usuario, use:

rabbitmqctl list_users
# Busque el usuario y sus etiquetas (por ejemplo, administrator, management)

rabbitmqctl list_user_permissions username
# Muestra los vhosts donde el usuario tiene permisos de configurar, escribir y leer.

rabbitmqctl list_permissions -p /your_vhost
# Muestra los permisos de todos los usuarios en un vhost.

Resolución de Brechas de Permisos

Los permisos deben establecerse a nivel de Host Virtual (vhost) y a menudo necesitan refinamiento a nivel de Recurso (exchange/cola).

Ejemplo: conceder a un usuario de aplicación acceso a recursos que comiencen con app. en /app_vhost:

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

Los permisos de RabbitMQ son expresiones regulares en este orden: configurar, escribir, leer. Para producción, evite ".*" a menos que la aplicación realmente posea todos los recursos en ese vhost. Si app_user solo publica en orders_exchange y consume de processing_queue, conceda acceso de escritura al nombre del exchange y acceso de lectura al nombre de la cola.

La etiqueta administrator es para usuarios de gestión de RabbitMQ, no para aplicaciones normales. Concede acceso de gestión amplio y no debe usarse como atajo para corregir permisos de aplicaciones.

Fallos de Autenticación

Los fallos de autenticación ocurren cuando el broker rechaza las credenciales del usuario (nombre de usuario/contraseña) antes de que comiencen las verificaciones de control de acceso.

Causas Comunes

• Contraseñas no coincidentes: El secreto del cliente no coincide con la contraseña almacenada en RabbitMQ.
• Nombre de usuario o vhost incorrecto en la URI: Las URL de AMQP incluyen la ruta del vhost, por lo que / se codifica como %2F.
• Mecanismo de autenticación no coincidente: Por ejemplo, un flujo de certificado de cliente TLS puede requerir el mecanismo EXTERNAL, mientras que los clientes de nombre de usuario/contraseña suelen usar mecanismos como PLAIN o AMQPLAIN.

Solución de Problemas de Autenticación Usando Registros

Los fallos de autenticación son registrados por el broker. En muchos paquetes de Linux, los registros están en /var/log/rabbitmq/; las implementaciones en contenedores suelen enviar los registros a stdout o al controlador de registros del contenedor.

Busque líneas que contengan:

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

Restablecimiento o Cambio de Contraseñas

Si las credenciales se pierden o se sospecha que están comprometidas, restablézcalas inmediatamente:

# Cambiar la contraseña de 'app_user'
rabbitmqctl change_password app_user new_secure_password

Errores de Configuración SSL/TLS y de Certificados

Al imponer comunicación segura (AMQPS o WebSockets seguros), los problemas de certificados y almacenes de confianza son dolores de cabeza comunes en la configuración de seguridad.

Síntomas de Fallo SSL/TLS

• Los intentos de conexión del cliente se agotan o son rechazados inmediatamente.
• El cliente reporta errores como SSL handshake failed, certificate verify failed o unknown ca.

Verificaciones Clave de Configuración

A. Verificación del Certificado del Servidor

Asegúrese de que la cadena de certificados presentada por el servidor RabbitMQ sea válida y confiable para el cliente.

1. Verificar Configuración del Servidor: Verifique que los archivos de certificado (.pem o similar) y clave correctos estén referenciados en el archivo rabbitmq.conf para el listener:

   # Ejemplo de fragmento de rabbitmq.conf
   listeners.ssl.default = 5671
   ssl_options.cacertfile = /path/to/ca_certificate.pem
   ssl_options.certfile = /path/to/server_certificate.pem
   ssl_options.keyfile = /path/to/server_key.pem
   

2. Verificar Almacén de Confianza del Cliente: Si el certificado del servidor es autofirmado o está firmado por una CA privada, el cliente debe confiar en ese certificado de CA.

B. Discrepancias de Cifrado y Protocolo

Si el cliente y el servidor no pueden acordar un conjunto de cifrado común o una versión de TLS (por ejemplo, el cliente solo admite TLS 1.2, pero el servidor está configurado solo para TLS 1.3), el handshake falla.

Defina explícitamente las versiones de TLS admitidas en rabbitmq.conf si necesita una aplicación estricta del protocolo. De lo contrario, RabbitMQ depende del soporte TLS proporcionado por el entorno de ejecución Erlang/OTP subyacente y su versión de RabbitMQ.

# Definir explícitamente las versiones permitidas (por ejemplo, forzar TLS 1.2 y 1.3)
ssl_options.versions.tcp = [tlsv1.2, tlsv1.3]

C. Autenticación de Certificado de Cliente (mTLS)

Si los clientes deben presentar certificados:

1. Establezca ssl_options.verify = verify_peer.
2. Establezca ssl_options.fail_if_no_peer_cert = true cuando se requiera un certificado de cliente.
3. Configure ssl_options.cacertfile o ssl_options.cacerts_path para que RabbitMQ confíe en la CA que firmó los certificados de cliente.
4. Configure la autenticación basada en certificados, comúnmente con el plugin rabbitmq_auth_mechanism_ssl, y asegúrese de que la identidad del certificado se asigne a un nombre de usuario de RabbitMQ esperado.

Problemas de Acceso a Hosts Virtuales

Los usuarios solo pueden acceder a los recursos dentro de los vhosts a los que se les ha concedido acceso explícitamente.

El VHost Predeterminado (/)

Si se crea un usuario pero no se asigna a ningún vhost, no puede conectarse ni operar. Si usa el vhost predeterminado (/), asegúrese de que el usuario tenga permisos allí.

Use la interfaz de gestión o rabbitmqctl para listar los vhosts donde el usuario tiene permisos:

rabbitmqctl list_user_vhosts username

Si el usuario necesita acceso a un vhost llamado billing_vhost, asegúrese de que el usuario esté vinculado:

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

Conclusión

Verifique los fallos de seguridad de RabbitMQ en orden: primero el listener y TLS, luego las credenciales, luego el acceso al vhost, y luego los permisos de configurar/escribir/leer. Ese orden evita que reescriba permisos cuando el problema real es una URL AMQP incorrecta, una CA no confiable o una concesión de vhost faltante.