amzshar

2007年12月16日 星期日

.
. IBM WebSphere MQ v6.0
. Chapter 6.3 - IBM WebSphere Security
.

=== WebSphere MQ Security Implementations ===
1. Object Authority Manager (OAM) facility.
2. CHANNEL Security using Secure-Sockets-Layer (SSL).

(※ MQ 只有授權Authorization, 沒有認證Authentication)


=== WebSphere MQ Access Control Overview ===
1. WebSphereMQ access control at user and/or group level :
　- UNIX use groups only (Username must exist, everyone is in nobody.)
　- Windows uses userids and/or groups.
　- System-level userids only are supported
　　(No support for DCE principals, TXSeries userids, and so forth.)
2. Firsy level name only is controlled :
　- Alias Queues, Remote Queues.
　- Resolved name is not significant.


=== Object Authority Manager Installable Service ===
1. [ WebSphereMQ QMgr <---> Object Authority Manager (OAM) Access Control Lists ]
2. Access Control for WebSphereMQ objects :
　- Queue Manager　　　- Queues
　- Processes　　　　　- Namelists
　- Channels　　　　　　- Authentication information objects
　- Listeners　　　　　　- Services
3. OAM can be disabled :
　- Remove entry from mqs.ini or Windows Registry
　- Not recommended
　- Very difficult to re-establish uniform authority checking


=== Object Authority Manager : Access Control Lists ===
1. One authority file per object :
　- lus global permissions files.
2. Each file has one stanza per principle :
　- Principal (User)
　- Authority='bit pattern'
3. Windows OAM bypasses auth files for certain classes of principal
　- SYSTEM, local Administrators group, local mqm group


=== Security Management : setmqaut ===
1. Change the authorizations :
　- Queue Manager　　　- Queues
　- Processes　　　　　- Namelists
　- Channels　　　　　　- Authentication information objects
　- Listeners　　　　　　- Services
2. Principal or group level control
3. Granular control of access
　- No generic functions
　- Supports generic profiles

　# setmqaut -m QMgr -t Objtype -n Profile [-p Principale -g Group] permissions
　Example :
　# setmqaut -m QM1 -t queue -n MOON.* -g GP1 browse + get

4. Note that there are certain principals/groups which are granted automatic access to resources. These are :
　- mqm (user/group)
　- For Windows :
　　a. Administrator (user/local group)
　　b. SYSTEM (userid)
　　c. The user (or principal group) which creates a resource.


=== Security Management : dspmqaut ===
1. Display current authorizations :
　- Queue Manager　　　- Queues
　- Processes　　　　　- Namelists
　- Channels　　　　　　- Authentication information objects
　- Listeners　　　　　　- Services
2. Principal or group level control.

　# dspmqaut -m QMgr -t ObjType -n ObjName [-p Principal -g Group ]
　Example :
　# dspmqaut -m QM1 -t q -n QL.Q1 -p mquser
　Entity mquser has the following authorizations for object QL.Q1 :
　get
　browse
　put ...


=== Security Managemnet : dmpmqaut ===
1. Dump current authorizations :
　- QMGR
　- Queues
　- Processes
　- Namelists
　- Authinfo (SSL CHANNEL Security)
　- Channels
　- Listeners
　- Services
2. Principal or group level control.

　# dmpmqaut -m QMgr -t ObjType -n Profile [-p Principal -g Group ]
　Example :
　# dmpmqaut -m QM1 -n a.b.c -t q -p mquser
　The resulting dump would display :
　profile : a.b.*
　object type : queue
　entity : user1
　type : principal
　authority : get, browse, put, inq


=== Access Control for WebSphereMQ Control Program ===
1. Most WebSphereMQ control programs
　- Such as crtmqm, strmqm, runmqsc, setmqaut, dspmqaut, dmpmqaut
2. Have restricted access :
　- UNIX/Linux restricts users to the mqm group
　　a. Configuration as a part of WebSphereMQ installation.
　　b. Control imposed by the O.S. not OAM.
　- Windows allows :
　　a. mqm group
　　b. Administrators group
　　c. System userid
　- OpenVMS restricts users to those granted the MQM identifier.
　- Compaq NSK allows :
　　a. MQM group
　　b. SUPER.SUPER ID


=== Authority Checking in the MQI ===
1. MQI calls with security checking :
　- MQCONN / MQCONNX
　- MQOPEN
　- MQPUT1 (implicit MQOPEN)
　- MQCLOSE 　(For Dynamic Queues).
2. WebSphereMQ events as audit records :
　- Events written to SYSTEM.ADMIN.QMGR.EVENT Queue.
　- Documented in Monitoring WebSphereMQ manual.
3. Reason code MQRC_NOT_AUTHORIZED (2035) returned if not authorized.
4. The MQCLOSE is generally not checked because the close options are usually none.
5. If the close options are set to MQCO_DELETE or MQCO_DELETE_PURGE (this is only for permanent
　 Dynamic Queues) then, unless the Queue was created using the current handle, there is a check to
　determine if the user is authorized to delete the Queue.


=== Security and Distributed Queuing === ☆
1. Put authority :
　- Option for the receiving end of a message CHANNEL.
　　a. Default user identifier is used.
　　b. Context user identifier is used.
2. Transmission Queue :
　- Messages destined for a Remote Queue Manager are put on a Transmission Queue by the
　　Local Queue manager
　　a. An application should not notmally need to put messages directly on a Transmission Queue,
　　　or need authority to do so.
　- Only special system programs should put messages directly on a Transmission Queue should
　　have the authority to do so.

=== Message Context ===
1. Information about source of message :
　- Identity section　(user related)
　- origin section　(program related)
2. Part of message Descriptor.
3. Can be passwd in related message.
4. Message context information allows for the application that retrieves a message to find out about
　the Originator of the message.The retrieving application may want to :
　a. Check that the sending application has the corrent level of authority.
　b. Keep an audit of all the messages it has worked with.
　c. The information is held in two field : Identify context and Origin context.


=== The Context Fields ===
An application can request the Queue Manager to set the context fields of a message by using the put message option MQPMO_DEFAULT_CONTEXT on an MQPUT or MQPUT1 call. This is the default action if no context if specified.

( ps : 用 # amqsbcg Queue QMgr 可以看到 )

1. Identify context :
　- UserIdentifier　(user that originated the message.)
　- AccountingToken
　　a. Windows　(SID, Security ID in compressed format)
　　b. i5/OS　(Job accounting code)
　　c. UNIX　(Numberic user ID in ASCII characters)
　- ApplIdentityData　(Blank)
2. Orign context :
　- PutApplType　(MQAT_AIX, MQAT_CICS...etc.)
　- PutApplName
　- PutDate　( YYYYMMDD(GMT) )
　- PutTime　( HHMMSSTH(GMT) )
　- ApplOriginData　(Blank)


=== No Context ===
1. Requested by a put message option :
　- MQPMO_NO_CONTEXT
　- Queue Manager clears all the context fields, specifically.
　- PutApplType is set to MQAT_NO_CONTEXT
2. To request "Default Context" or "No Context" requires no more authority than that required to put the message on the Queue.


=== Passing Context ===
A → [Queue1] → B → [Queue2] → C

1. Put messages on Queue2 with same Identity context as message taken from Queue1
2. Open Queue1 as "Save All Context"
3. Put messages with "Pass Identity Context"
4. Or transfer "No Context"


=== Alternate User Authority ===
A → [Queue1] → B → [Queue2] → C

1. Put messages with A's authority :
　- B needs appropriate authority.
　- UserID taken from message Context.
2. How it is requested ? :
　- AlternateUserID field in Object Descriptor.
　- Option on MQOPEN or MQPUT1


=== Setting Context ===
1. Two open options that require authority to use :
　- MQOO_SET_IDENTITY_CONTEXT
　- MQOO_SET_ALL_CONTEXT
2. Two corresponding put message options :
　- MQPMO_SET_IDENTITY_CONTEXT
　- MQPMO_SET_ALL_CONTEXT
3. Normally used by special programs only :
　- Message CHANNEL agents
　- System utilities


=== CHANNEL Exit Programs ===
MQPUT → TransmissionQueue → [Message] → MCA → Send →
　　　　　　　　　　　　　　　　　　　　　
MQGET ← DestinationQueue ← [Message(retry)] ← MCA ← Receive ←
　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　

1. The uses of CHANNEL Exit programs are :
　- Auto-definition Exit　can be used to modify the CHANNEL definition derived from
　　　　　　　　　the model SYSTEM.AUTO.RECEIVER
　- Security Exit　is primarily used by the MCA at each end of a message CHANNEL
　　　　　　　　　to authenticate its partner.
　- Send and Receiver Exites　can be used for purposes such as data compression
　　　　　　　　　/ decompression and data encryption / decryption.
　- Message Exit　can be used for any purpose which makes sense at the message
　　　　　　　　　level. The following are some examples :
　　　　　a. Application data conversion
　　　　　b. Encryption / decryption
　　　　　c. Journaling　(日誌)
　　　　　d. Additional security checks such as validating an incoming user identifier.
　　　　　e. Substitution of one user identifier for another as a message enters a new
　　　　　　security domain.
　　　　　f. Reference message handing.
　- Message-retry Exit　is called an attempt to open a destination Queue, or put a
　　　　　　　　　　message on a destination Queue, has been unsuccessful. The
　　　　　　　　　　exit can be used to determine under what circumstances the
　　　　　　　　　　MCA should continue to retry, how many times it should retry,
　　　　　　　　　　and how frequently.
2. The Auto-Definition Exit is only supported on WebSphereMQ for AIX. HP-UX, iSeries,
　Solaris, and Windows, and MQSeries for Compaq Tru64 UNIX and OS/2 Warp V5.1


=== CHANNEL Exit Programs on MQI CHANNELs ===
　　　　　　　　　　　　　　　　　　　　　　　 [Auto-Definition]
　　　　　　　　　　[Security]　　　　　　　　　 [Security]
　MQCONN ←→　　　　　　　　Send　Receive
　MQOPEN ←→　CLNTCONN ←——————→ SVRCONN
　　MQPUT ←→　

1. No CHANNEL Exit Programs can be called on a client system if the MQSERVER
　environment variable is used to define a simple client conenction.
2. The Auto-Definiition Exit can be used to modify the CHANNEL definition derived
　from the model SYSTEM.AUTO.SVRCONN


=== Secure Sockets Layer ===
1. Protocol to allow transmission of secure data over an insecure network.
2. Combines these techniques :
　- Symmetric / Secret Key encryption
　- Asymmetric / Public Key encryption
　- Digital Signature
　- Digital Certificates
3. Protection :
　- Client / Server
　- Qmgr / QMgr CHANNELs
4. To combat Security Problems :
　- Eavesdropping　(竊聽)　← Encryption techniques
　- Tampering　(竄改、瞎搞)　← Digital Signature
　- Impersonation　(偽裝)　← Digital Certificates


=== QMGR Attributes for SSL ===
1. ALTER QMGR command :
　- SSLKEYR 　Sets the SSLKeyRepository.
　- SSLCRLNL 　Sets the SSLCRLNamelist.
　- SSLCRYP 　Sets the SSLCryptoHardware.
　- SSLTAKS 　Sets the SSLTasks.
　- SSLEV 　　Enables or Disables SSL event messages.
　- SSLFIPS 　Specifies if only FIPS-certified algorithms can be used.

ps : CRL (Certificate Re )

=== QMGR Authentication Object ===
1. ALTER AUTHINFO
2. DEFINE AUTHINFO
3. DELETE AUTHINFO
4. DISPLAY AUTHINFO


=== Channel Attributes for SSL ===
1. DEFINE or ALTER CHANNEL
　- SSLCIPH　(Cipher 譯文)
　- SSLPEER
　- SSLCAUTH


=== Access Control for a WebSphereMQ Client ===
1. Access control is based on a user ID used by the server connection process :
　- Value of MCAUserIdentifier in MQCD determines this user ID
2. Security Exits at both ends of the MQI CHANNEL :
　- Client Security Exit can flow a user ID and password
　- Server Security Exit can authenticate the user ID and set MCAUserIdentifier
3. No security Exit at the client end of the MQI CHANNEL :
　- Value of logged_in USERID flows to the server system.
　- Server Secutiry Exit can authenticate the user ID and set MCAUserIdentifier
4. No Security Exit at either end of the MQI CHANNEL :
　- MCAUserIdentifier has the value of MCAUSER if it is nonblank.
　- MCAUserIdentifier has the value of flowed user ID otherwise.


=== Remote Queuing and Clients ===
1. CHANNEL Exits :
　- A number of CHANNEL Exits are available in the product and as SupportPacs
　- Serveral vendors in this market too.
2. MCAUSER :
　- The default setting is wide open, especially for client attach.
　- May want to set this to restrict who can access your Queue Manager.
3. MQ_USER_ID environment variable :
　- This war removed for WindowsNY and UNIX in the 5.1 release client env.
　- The logged-in username is now automatically used.
　- But this is not authenticated at the server ; you may still need security Exits.