Risoluzione dei Problemi Comuni di Configurazione della Sicurezza di RabbitMQ

I problemi di configurazione della sicurezza di RabbitMQ di solito si manifestano come login falliti, errori 403 ACCESS_REFUSED o handshake TLS che non si completano mai. La soluzione dipende da dove si verifica il fallimento della connessione: autenticazione, accesso al vhost, permessi delle risorse o validazione del certificato.

Usa questa guida per controllare questi livelli in ordine. Si concentra su comandi pratici di RabbitMQ e punti di configurazione che puoi verificare senza indovinare.

Problemi di Permessi Utente e Controllo Accessi

Il problema di sicurezza più comune deriva da permessi utente errati. RabbitMQ utilizza un sistema di controllo accessi granulare basato su tag e permessi delle risorse (configure, write, read) per exchange, code e binding.

Diagnostica dei Permessi Mancanti

Quando un'applicazione non riesce a connettersi, pubblicare o consumare messaggi, il primo passo è verificare i permessi effettivi dell'utente. Puoi utilizzare l'interfaccia del Plugin di Gestione RabbitMQ o lo strumento a riga di comando rabbitmqctl.

Sintomi comuni:

• La connessione si apre, ma le operazioni di pubblicazione o consumo falliscono con ACCESS_REFUSED.
• L'utente può pubblicare su un exchange esistente ma non può dichiarare una coda.
• Lo stesso nome utente funziona in un vhost ma fallisce in un altro.

Controllo dei Tag e dei Permessi Utente tramite rabbitmqctl

Per controllare i tag e i permessi dell'utente, usa:

rabbitmqctl list_users
# Cerca l'utente e i suoi tag (es., administrator, management)

rabbitmqctl list_user_permissions username
# Mostra i vhost dove l'utente ha permessi di configure, write e read.

rabbitmqctl list_permissions -p /your_vhost
# Mostra i permessi per tutti gli utenti su un vhost.

Risoluzione delle Lacune nei Permessi

I permessi devono essere impostati a livello di Virtual Host (vhost) e spesso necessitano di perfezionamento a livello di Risorsa (exchange/coda).

Esempio: concedi a un utente applicativo l'accesso alle risorse che iniziano con app. su /app_vhost:

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

I permessi di RabbitMQ sono espressioni regolari in questo ordine: configure, write, read. Per la produzione, evita ".*" a meno che l'applicazione non possieda realmente ogni risorsa in quel vhost. Se app_user pubblica solo su orders_exchange e consuma da processing_queue, concedi l'accesso in scrittura al nome dell'exchange e l'accesso in lettura al nome della coda.

Il tag administrator è per gli utenti di gestione di RabbitMQ, non per le applicazioni normali. Concede ampio accesso di gestione e non dovrebbe essere usato come scorciatoia per risolvere i permessi delle app.

Fallimenti di Autenticazione

I fallimenti di autenticazione si verificano quando il broker rifiuta le credenziali dell'utente (nome utente/password) prima che inizino i controlli di accesso.

Cause Comuni

• Password non corrispondenti: Il segreto del client non corrisponde alla password memorizzata in RabbitMQ.
• Nome utente o vhost errato nell'URI: Gli URL AMQP includono il percorso del vhost, quindi / è codificato come %2F.
• Mancata corrispondenza del meccanismo di autenticazione: Ad esempio, un flusso di certificato client TLS può richiedere il meccanismo EXTERNAL, mentre i client con nome utente/password usano tipicamente meccanismi come PLAIN o AMQPLAIN.

Risoluzione dei Problemi di Autenticazione Utilizzando i Log

I fallimenti di autenticazione vengono registrati dal broker. Su molti pacchetti Linux, i log si trovano in /var/log/rabbitmq/; le distribuzioni containerizzate di solito inviano i log a stdout o al driver di log del contenitore.

Cerca righe contenenti:

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

Reimpostazione o Modifica delle Password

Se le credenziali vengono perse o si sospetta che siano state compromesse, reimpostale immediatamente:

# Cambia la password per 'app_user'
rabbitmqctl change_password app_user new_secure_password

Errori di Configurazione SSL/TLS e Certificati

Quando si impone una comunicazione sicura (AMQPS o WebSocket sicuri), i problemi di certificato e trust store sono comuni grattacapi di configurazione della sicurezza.

Sintomi di Fallimento SSL/TLS

• I tentativi di connessione del client scadono o vengono immediatamente rifiutati.
• Il client riporta errori come SSL handshake failed, certificate verify failed o unknown ca.

Controlli Chiave di Configurazione

A. Verifica del Certificato del Server

Assicurati che la catena di certificati presentata dal server RabbitMQ sia valida e attendibile per il client.

1. Verifica la Configurazione del Server: Controlla che i file del certificato corretto (.pem o simile) e della chiave siano referenziati nel file rabbitmq.conf per il listener:

   # Esempio di snippet 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. Controlla il Trust Store del Client: Se il certificato del server è autofirmato o firmato da una CA privata, il client deve fidarsi di quel certificato CA.

B. Mancata Corrispondenza di Cipher e Protocollo

Se il client e il server non riescono a concordare una suite di cifratura comune o una versione TLS (es., il client supporta solo TLS 1.2, ma il server è configurato solo per TLS 1.3), l'handshake fallisce.

Definisci esplicitamente le versioni TLS supportate in rabbitmq.conf se hai bisogno di un'applicazione rigorosa del protocollo. Altrimenti, RabbitMQ dipende dal supporto TLS fornito dal runtime Erlang/OTP sottostante e dalla tua versione di RabbitMQ.

# Definisci esplicitamente le versioni consentite (es., forzando TLS 1.2 e 1.3)
ssl_options.versions.tcp = [tlsv1.2, tlsv1.3]

C. Autenticazione del Certificato Client (mTLS)

Se i client devono presentare certificati:

1. Imposta ssl_options.verify = verify_peer.
2. Imposta ssl_options.fail_if_no_peer_cert = true quando è richiesto un certificato client.
3. Configura ssl_options.cacertfile o ssl_options.cacerts_path in modo che RabbitMQ si fidi della CA che ha firmato i certificati client.
4. Configura l'autenticazione basata su certificato, comunemente con il plugin rabbitmq_auth_mechanism_ssl, e assicurati che l'identità del certificato corrisponda a un nome utente RabbitMQ previsto.

Problemi di Accesso al Virtual Host

Gli utenti possono accedere solo alle risorse all'interno dei vhost a cui è stato esplicitamente concesso l'accesso.

Il Vhost Predefinito (/)

Se un utente viene creato ma non assegnato a nessun vhost, non può connettersi o operare. Se usi il vhost predefinito (/), assicurati che l'utente abbia i permessi lì.

Usa l'interfaccia di gestione o rabbitmqctl per elencare i vhost dove l'utente ha i permessi:

rabbitmqctl list_user_vhosts username

Se l'utente necessita di accesso a un vhost chiamato billing_vhost, assicurati che l'utente sia collegato:

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

Conclusione

Controlla i fallimenti di sicurezza di RabbitMQ in ordine: listener e TLS per primi, poi credenziali, poi accesso al vhost, poi permessi di configure/write/read. Questo ordine ti impedisce di riscrivere i permessi quando il vero problema è un URL AMQP errato, una CA non attendibile o una concessione di vhost mancante.