SSL/TLS e cluster

Quando si configura TLS per i cluster, tenere presente che una definizione di canale CLUSRCVR viene propagata ad altri gestori code come un canale CLUSSDR definito automaticamente. Se un canale CLUSRCVR utilizza TLS, è necessario configurare TLS su tutti i gestori code che comunicano utilizzando il canale.

Per ulteriori informazioni su TLS, vedere Protocolli di sicurezza TLS in IBM MQ. Il consiglio è generalmente applicabile ai canali cluster, ma è possibile considerare in modo particolare quanto segue:

In un cluster IBM MQ una particolare definizione di canale CLUSRCVR viene spesso propagata a molti altri gestori code in cui viene trasformata in un CLUSSDRdefinito automaticamente. Successivamente, il CLUSSDR definito automaticamente viene utilizzato per avviare un canale per CLUSRCVR. Se CLUSRCVR è configurato per la connettività TLS, si applicano le seguenti considerazioni:

  • Tutti i gestori code che desiderano comunicare con questo CLUSRCVR devono avere accesso al supporto TLS. Questo provisioning TLS deve supportare CipherSpec per il canale.
  • I diversi gestori code a cui sono stati propagati i canali mittenti del cluster definiti automaticamente avranno ciascuno un DN differente associato. Se il controllo peer del DN (distinguished name) deve essere utilizzato su CLUSRCVR , deve essere impostato in modo che tutti i DN che possono essere ricevuti corrispondano correttamente.

    Ad esempio, si supponga che tutti i gestori code che ospiteranno i canali mittente del cluster che si connetteranno a un particolare CLUSRCVR, abbiano certificati associati. Si supponga inoltre che i DN (distinguished name) in tutti questi certificati definiscano il paese come Regno Unito, l'organizzazione come IBM, l'unità organizzativa come IBM MQ Development e che tutti abbiano nomi comuni nel formato DEVT.QMnnn, dove nnn è numerico.

    In questo caso, un valore SSLPEER di C=UK, O=IBM, OU=IBM MQ Development, CN=DEVT.QM* su CLUSRCVR consentirà a tutti i canali mittenti del cluster richiesti di connettersi correttamente, ma impedirà la connessione di canali mittenti del cluster indesiderati.

  • Se vengono utilizzate le stringhe CipherSpec personalizzate, tenere presente che i formati delle stringhe personalizzate non sono consentiti su tutte le piattaforme. Un esempio di ciò è che la CipherSpec stringa RC4_SHA_US ha un valore di 05 su IBM i ma non è una specifica valida sui sistemi AIX®, Linux®, and Windows . Quindi, se i parametri SSLCIPH personalizzati vengono utilizzati su un CLUSRCVR, tutti i canali mittenti del cluster definiti automaticamente risultanti devono risiedere su piattaforme su cui il supporto TLS sottostante implementa questo CipherSpec e su cui può essere specificato con il valore personalizzato. Se non è possibile selezionare un valore per il parametro SSLCIPH che verrà compreso in tutto il cluster, sarà necessaria un'uscita di definizione automatica del canale per modificarla in qualcosa che le piattaforme utilizzate comprenderanno. Utilizzare le stringhe di testo CipherSpec dove possibile (ad esempio TLS_RSA_WITH_AES_128_CBC_SHA).

Un parametro SSLCRLNL si applica a un singolo gestore code e non viene propagato ad altri gestori code all'interno di un cluster.