Solução de Problemas Comuns de Configuração de Segurança no RabbitMQ

Problemas de configuração de segurança no RabbitMQ geralmente se manifestam como logins falhos, erros 403 ACCESS_REFUSED ou handshakes TLS que nunca são concluídos. A correção depende de onde a conexão falha: autenticação, acesso ao vhost, permissões de recursos ou validação de certificado.

Use este guia para verificar essas camadas em ordem. Ele foca em comandos práticos do RabbitMQ e pontos de configuração que você pode verificar sem adivinhar.

Problemas de Permissão de Usuário e Controle de Acesso

O problema de segurança mais comum decorre de permissões de usuário incorretas. O RabbitMQ usa um sistema de controle de acesso granular baseado em tags e permissões de recursos (configurar, escrever, ler) para exchanges, filas e bindings.

Diagnosticando Permissões Ausentes

Quando um aplicativo não consegue conectar, publicar ou consumir mensagens, o primeiro passo é verificar as permissões efetivas do usuário. Você pode usar a interface do Plugin de Gerenciamento do RabbitMQ ou a ferramenta de linha de comando rabbitmqctl.

Sintomas comuns:

• A conexão é aberta, mas as operações de publicar ou consumir falham com ACCESS_REFUSED.
• O usuário pode publicar em uma exchange existente, mas não pode declarar uma fila.
• O mesmo nome de usuário funciona em um vhost, mas falha em outro.

Verificando Tags e Permissões do Usuário via rabbitmqctl

Para verificar as tags e permissões do usuário, use:

rabbitmqctl list_users
# Procure pelo usuário e suas tags (ex.: administrator, management)

rabbitmqctl list_user_permissions username
# Mostra os vhosts onde o usuário tem permissões de configurar, escrever e ler.

rabbitmqctl list_permissions -p /seu_vhost
# Mostra as permissões de todos os usuários em um vhost.

Resolvendo Lacunas de Permissão

As permissões devem ser definidas no nível do Host Virtual (vhost) e muitas vezes precisam de refinamento no nível do Recurso (exchange/fila).

Exemplo: conceder a um usuário de aplicativo acesso a recursos que começam com app. em /app_vhost:

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

As permissões do RabbitMQ são expressões regulares nesta ordem: configurar, escrever, ler. Para produção, evite ".*" a menos que o aplicativo realmente possua todos os recursos naquele vhost. Se app_user apenas publica em orders_exchange e consome de processing_queue, conceda acesso de escrita ao nome da exchange e acesso de leitura ao nome da fila.

A tag administrator é para usuários de gerenciamento do RabbitMQ, não para aplicativos normais. Ela concede amplo acesso de gerenciamento e não deve ser usada como atalho para corrigir permissões de aplicativos.

Falhas de Autenticação

Falhas de autenticação ocorrem quando o broker rejeita as credenciais do usuário (nome de usuário/senha) antes que as verificações de controle de acesso comecem.

Causas Comuns

• Senhas incompatíveis: O segredo do cliente não corresponde à senha armazenada no RabbitMQ.
• Nome de usuário ou vhost errado na URI: URLs AMQP incluem o caminho do vhost, então / é codificado como %2F.
• Incompatibilidade de mecanismo de autenticação: Por exemplo, um fluxo de certificado TLS do cliente pode exigir o mecanismo EXTERNAL, enquanto clientes de nome de usuário/senha normalmente usam mecanismos como PLAIN ou AMQPLAIN.

Solucionando Problemas de Autenticação Usando Logs

Falhas de autenticação são registradas pelo broker. Em muitos pacotes Linux, os logs estão em /var/log/rabbitmq/; implantações em contêineres geralmente enviam logs para stdout ou o driver de log do contêiner.

Procure por linhas contendo:

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

Redefinindo ou Alterando Senhas

Se as credenciais forem perdidas ou suspeitas de estarem comprometidas, redefina-as imediatamente:

# Altere a senha para 'app_user'
rabbitmqctl change_password app_user nova_senha_segura

Erros de Configuração SSL/TLS e Certificado

Ao impor comunicação segura (AMQPS ou WebSockets seguros), problemas de certificado e armazenamento de confiança são dores de cabeça comuns na configuração de segurança.

Sintomas de Falha SSL/TLS

• Tentativas de conexão do cliente expiram ou são imediatamente rejeitadas.
• O cliente relata erros como SSL handshake failed, certificate verify failed ou unknown ca.

Principais Verificações de Configuração

A. Verificação do Certificado do Servidor

Certifique-se de que a cadeia de certificados apresentada pelo servidor RabbitMQ seja válida e confiável para o cliente.

1. Verificar Configuração do Servidor: Verifique se os arquivos de certificado (.pem ou similar) e chave corretos estão referenciados no arquivo rabbitmq.conf para o listener:

   # Exemplo de trecho rabbitmq.conf
   listeners.ssl.default = 5671
   ssl_options.cacertfile = /caminho/para/ca_certificate.pem
   ssl_options.certfile = /caminho/para/server_certificate.pem
   ssl_options.keyfile = /caminho/para/server_key.pem
   

2. Verificar Armazenamento de Confiança do Cliente: Se o certificado do servidor for autoassinado ou assinado por uma CA privada, o cliente deve confiar nesse certificado CA.

B. Incompatibilidades de Cipher e Protocolo

Se o cliente e o servidor não conseguirem concordar com um conjunto de cifras comum ou versão TLS (por exemplo, cliente suporta apenas TLS 1.2, mas o servidor está configurado apenas para TLS 1.3), o handshake falha.

Defina explicitamente as versões TLS suportadas em rabbitmq.conf se precisar de uma aplicação estrita do protocolo. Caso contrário, o RabbitMQ depende do suporte TLS fornecido pelo runtime Erlang/OTP subjacente e pela sua versão do RabbitMQ.

# Defina explicitamente as versões permitidas (por exemplo, forçando TLS 1.2 e 1.3)
ssl_options.versions.tcp = [tlsv1.2, tlsv1.3]

C. Autenticação por Certificado do Cliente (mTLS)

Se os clientes devem apresentar certificados:

1. Defina ssl_options.verify = verify_peer.
2. Defina ssl_options.fail_if_no_peer_cert = true quando um certificado de cliente for necessário.
3. Configure ssl_options.cacertfile ou ssl_options.cacerts_path para que o RabbitMQ confie na CA que assinou os certificados do cliente.
4. Configure a autenticação baseada em certificado, comumente com o plugin rabbitmq_auth_mechanism_ssl, e certifique-se de que a identidade do certificado mapeie para um nome de usuário RabbitMQ esperado.

Problemas de Acesso ao Host Virtual

Os usuários só podem acessar recursos dentro dos vhosts aos quais foram explicitamente concedidos acesso.

O VHost Padrão (/)

Se um usuário for criado, mas não atribuído a nenhum vhost, ele não poderá conectar ou operar. Se você usar o vhost padrão (/), certifique-se de que o usuário tenha permissões lá.

Use a interface de gerenciamento ou rabbitmqctl para listar os vhosts onde o usuário tem permissões:

rabbitmqctl list_user_vhosts username

Se o usuário precisar de acesso a um vhost chamado billing_vhost, certifique-se de que o usuário esteja vinculado:

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

Conclusão

Verifique as falhas de segurança do RabbitMQ em ordem: listener e TLS primeiro, depois credenciais, depois acesso ao vhost, depois permissões de configurar/escrever/ler. Essa ordem evita que você reescreva permissões quando o problema real é uma URL AMQP ruim, uma CA não confiável ou uma concessão de vhost ausente.