2017-03-27 5 views
1

Nachstehende Befehle für die Autorisierung in Unix + MQ9. Möchten Sie überprüfen (ist das ein richtiger Ansatz oder nicht?) Sowie Wie können die folgenden Befehle in Windows Server erreicht werden? Autorisierungsbefehle in MQ @windows

setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +connect +dsp +inq 
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n '**' +put +get +browse +dsp +inq 
runmqsc TLSTEST.QM 
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) 
ALTER QMGR CHLAUTH(DISABLED) 
REFRESH SECURITY TYPE(CONNAUTH) 

Aktualisierung am 29-Mar-2017

wird setmqaut kann, wie unten als nur erforderlich ist in Ordnung verwendet werden, anstelle von '**'?

setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +connect +dsp +inq 
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n RECEIVE +put +get +browse +dsp +inq 
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n SEND +put +get +browse +dsp +inq 

unten Befehle sind für mich erforderlich, weil mein jms-Client nicht Benutzerdaten weitergeben Verbindung guten Ansatz request.Is wie unten in Client-Code zu übergeben oder diese Werte externalisieren? MQEnvironment.userID = "mqm";
MQEnvironment.password = "Kennwort";

runmqsc TLSTEST.QM 
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) 
ALTER QMGR CHLAUTH(DISABLED) 
REFRESH SECURITY TYPE(CONNAUTH) 
+0

Ich werde nicht in der Lage, Benutzer/Passwort auf Verbindungsanfrage zu übergeben.Sie sagen CHLAUTH (deaktiviert) ist keine gute Option. CHCKCLNT (OPTIONAL) ist ideal, wenn kein Passwort-Szenario gesendet werden soll. Gibt es irgendein Sicherheitsproblem beim Einstellen des obigen Parameters? –

+0

SSLCIPH wurde für TLSv2 aktiviert. Nur mit dem richtigen key.jks + Zertifikat-Passwort + Chiffre von JMS Client wird mit QMgr verbunden. Also ich glaube, mit SSLCIPH aktiviert, CHCKCLNT (OPTIONAL) + CHLAUTH (deaktiviert) + SSLCAUTH (optional), keine Auswirkungen auf Sicherheitsprobleme? –

+0

könntest du mit antwort als block hinzufügen, so dass ich abstimmen und 'grünes tick mark' geben kann. Ich habe auf SSLCAUTH (erforderlich), aber nicht auf CHLAUTH (deaktiviert). Könntest du anstatt CHLAUTH (BEHINDERT) weiter ausführen, was ich tun sollte? –

Antwort

1

Die Befehle, die Sie in Ihrer Frage zur Verfügung gestellt würde, in den Fenstern ebenso gut funktionieren wie sie in Unix tun.

HINWEIS Die Befehle, die Sie deaktivieren Sicherheit vorzuschlagen, das zu tun, nicht eine gute Sache ist und autorisiert den Benutzer auch „Clientadmin“ an alle Warteschlangen auf dem WS-Manager SYSTEM * Warteschlangen enthält, die dieser Benutzer Verwaltungsbehörde zu nutzen MQ erlaubt .

Befehle von Ihrem Update vom 29. März 2017 sind in Ordnung, um den Warteschlangen SEND und RECEIVE bestimmte Berechtigungen zu erteilen.

Meiner Meinung nach wäre es ein guter Ansatz, die Werte für Benutzer-ID und Passwort extern zu vergeben, so dass Sie die Dinge nicht neu kompilieren müssen, wenn sich diese in der Zukunft ändern.

Eine Anwendung zu verbinden als mqm ist kein guter Ansatz, da mqm über volle Verwaltungsautorität verfügt.

Einstellung CHLAUTH (DISABLED) verhindert nicht die Kennwortüberprüfung, es schaltet nur die normalen CHLAUTH-Regeln aus, die verhindern, dass MQ-Administratoren Verbindungen zu SVRCONN-Kanälen herstellen und die Verwendung von SYSTEM. * -Kanälen verhindern.

Die Einstellung CHCKCLNT (OPTIONAL) vom Standardwert CHCKCLNT (REQDADM) konfiguriert MQ, um zu prüfen, ob ein Kennwort nur gültig ist, wenn ein Kennwort an MQ übergeben wird.

Der Standardwert CHCKCLNT (REQDADM) ist derselbe wie CHCKCLNT (OPTIONAL) mit der zusätzlichen Anforderung, dass die Konten mit der MQ-Verwaltungsautorität ein gültiges Kennwort angeben müssen. Konten ohne MQ-Administratorberechtigung müssen kein gültiges Kennwort vorlegen, aber wenn ein Kennwort angegeben wird, muss es gültig sein.

Wenn Ihre Konfiguration nur mit CHCKCLNT (OPTIONAL) funktioniert, würde dies bedeuten, dass Sie eine Verbindung als Konto mit MQ-Administratorberechtigung herstellen. Es gibt ein Sicherheitsproblem bei der Einstellung von MQ, dass kein gültiges Kennwort gesendet wird, es sei denn, Sie verwenden SSLCIPH und SSLPEER, um eine SVRCONN so zu beschränken, dass nur bestimmte Clientzertifikate eine Verbindung herstellen und Sie sicherstellen, dass alle anderen Kanäle gesperrt sind. Die standardmäßigen CHLAUTH-Regeln sperren alle Kanäle, indem Benutzern mit MQ-Verwaltungsautorität keine Verbindung ermöglicht wird und sie Verbindungen zu allen SYSTEM * -Kanälen blockieren.

Einstellung SSLCAUTH (OPTIONAL) konfiguriert MQ so, dass der Client kein Zertifikat benötigt. Wenn der Client über ein Zertifikat verfügt, überprüft MQ, ob es vertrauenswürdig ist. Wenn Sie einen SSLPEER-Satz haben, wird der DN-Wert des Clientzertifikats sichergestellt Streichhölzer.

SSLCAUTH (REQUIRED) konfiguriert MQ so, dass der Client ein Zertifikat haben muss. Sie möchten dies auch mit der SSLPEER-Einstellung für Kanäle koppeln, um sicherzustellen, dass das Zertifikat nicht nur ein Zertifikat ist, das vom Warteschlangenmanager als vertrauenswürdig eingestuft wird, sondern auch, dass Sie den MCAUSER für einen Benutzer mit niedriger Berechtigung festlegen.

Die Einstellung CHLAUTH (DISABLED) macht wahrscheinlich das System. * Kanäle unsicher.

Wenn Sie keine anderen mildernden Steuerelemente haben, ist die dargestellte Konfiguration unsicher.