Sun Java System Message Queue 3.7 UR1 관리 설명서

7장 보안 관리

사용자 인증에 사용할 사용자 저장소를 구성하고 액세스 제어를 정의하며 클라이언트 브로커 통신을 암호화하는 SSL(Secure Socket Layer) 연결 서비스를 구성하고 브로커를 시작할 때 사용할 비밀번호 파일을 설정함으로써 보안을 관리합니다.

이 장은 다음 내용으로 구성되어 있습니다.

사용자 인증

사용자가 브로커에 연결하려고 시도하면 브로커는 제공된 이름과 비밀번호를 검사하여 사용자를 인증합니다. 이름과 비밀번호가 각 브로커가 참조하도록 구성된 브로커별 사용자 저장소의 이름 및 비밀번호와 일치하면 브로커는 연결을 허용합니다.

사용자 저장소에서 사용자 목록, 해당 그룹, 비밀번호를 관리해야 합니다. 브로커 인스턴스마다 다른 사용자 저장소를 사용할 수 있습니다. 이 절에서는 이러한 저장소를 만들고 채우고 관리하는 방법에 대해 설명합니다.

저장소 유형은 다음 중 하나가 될 수 있습니다.

Message Queue^TM와 함께 제공되는 플랫 파일 저장소

이 사용자 저장소 유형은 사용하기가 매우 쉽습니다. 사용자 관리자 유틸리티(imqusermgr)를 사용하면 저장소를 채우고 관리할 수 있습니다. 인증을 사용하려면 각 사용자의 이름, 비밀번호, 사용자 그룹 이름으로 사용자 저장소를 채웁니다.

사용자 저장소의 설정 및 관리에 대한 자세한 내용은 플랫 파일 사용자 저장소 사용을 참조하십시오.
LDAP 서버

LDAP v2 또는 v3 프로토콜을 사용하는 기존 또는 새 LDAP 디렉토리 서버가 될 수 있습니다. 플랫 파일 저장소만큼 사용이 쉽지는 않지만 더 확장 가능하므로 작업 환경에 적합합니다.

LDAP 사용자 저장소를 사용하는 경우에는 LDAP 공급업체에서 제공하는 도구를 사용하여 사용자 저장소를 채우고 관리해야 합니다. 자세한 내용은 사용자 저장소에 LDAP 서버 사용을 참조하십시오.

플랫 파일 사용자 저장소 사용

Message Queue에서는 플랫 파일 사용자 저장소와 플랫 파일 사용자 저장소를 채우고 관리할 때 사용할 수 있는 명령줄 도구인 사용자 관리자 유틸리티(imqusermgr)를 제공합니다. 다음 절에서는 플랫 파일 사용자 저장소에 대해 설명하고 사용자 관리자 유틸리티를 사용하여 해당 저장소를 채우고 관리하는 방법을 설명합니다.

사용자 저장소 만들기

플랫 파일 사용자 저장소는 인스턴스마다 다릅니다. 기본 사용자 저장소(passwd)는 사용자가 시작하는 각 브로커 인스턴스에 대해 자동으로 만들어집니다. 이 사용자 저장소는 저장소와 연관된 브로커 인스턴스의 이름으로 식별되는 디렉토리에 저장됩니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).

   …/instances/instanceName/etc/passwd

저장소는 이 두 항목을 사용하여 만들어집니다. 표 7–1의 각 행은 하나의 항목을 나타냅니다.

표 7–1 사용자 저장소 초기 항목


사용자 이름	비밀번호	그룹	상태
`admin`	`admin`	`admin`	`active`
`guest`	`guest`	`anonymous`	`active`

이러한 초기 항목을 사용하면 관리자가 개입하지 않아도 설치 후 바로 Message Queue 브로커를 사용할 수 있습니다.

초기 guest 사용자 항목을 사용하면 클라이언트가 기본 guest 사용자 이름과 비밀번호를 사용하여 브로커 인스턴스에 연결할 수 있습니다.
초기 admin 사용자 항목을 사용하면 imqcmd 명령을 사용하여 기본 admin 사용자 이름과 비밀번호로 브로커 인스턴스를 관리할 수 있습니다. 비밀번호를 변경하려면 이 초기 항목을 업데이트해야 합니다( 기본 관리자 비밀번호 변경 참조).

다음 절에서는 플랫 파일 사용자 저장소를 채우고 관리하는 방법을 설명합니다.

사용자 관리자 유틸리티

Message Queue 사용자 관리자 유틸리티(imqusermgr)를 사용하면 플랫 파일 사용자 저장소를 편집하거나 채울 수 있습니다. 이 절에서는 사용자 관리자 유틸리티에 대해 소개합니다. 다음 절에서는 imqusermgr 하위 명령을 사용하여 특정 작업을 수행하는 방법에 대해 설명합니다.

imqusermgr 명령에 대한 자세한 내용은 13 장, 명령줄 참조 을 참조하십시오.

사용자 관리자를 사용하기 전에 주의해야 할 사항은 다음과 같습니다.

브로커별 사용자 저장소가 없는 경우 해당 브로커 인스턴스를 시작하여 브로커별 사용자 저장소를 만들어야 합니다.
imqusermgr 명령은 브로커가 설치된 호스트에서 실행해야 합니다.
저장소에 쓸 수 있는 적절한 권한이 필요합니다. 즉, Solaris 및 Linux의 경우 해당 브로커 인스턴스를 처음으로 만든 사용자나 루트 사용자여야 합니다.

주 –

다음 절의 예에서는 기본 브로커 인스턴스인 경우를 가정합니다.

하위 명령

imqusermgr 명령에는 add, delete, list 및 update 하위 명령이 있습니다.

add 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소에 사용자와 관련 비밀번호를 추가하고 선택적으로 사용자 그룹을 지정합니다. 하위 명령의 구문은 다음과 같습니다.

add [-i instanceName] -u userName -p passwd [-g group] [ -s]
delete 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소에서 지정한 사용자를 삭제합니다. 하위 명령의 구문은 다음과 같습니다.

delete [-i instanceName] -u userName [ -s] [-f]
list 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소의 지정한 사용자 또는 모든 사용자에 대한 정보를 표시합니다. 하위 명령의 구문은 다음과 같습니다.

list [ -i instanceName] [-u userName]
update 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소에 있는 지정한 사용자의 비밀번호 및/또는 상태를 업데이트합니다. 하위 명령의 구문은 다음과 같습니다.

update [ -i instanceName] -u userName -p passwd [ -a state] [-s] [ -f]

update [-i instanceName] -u userName -a state [-p passwd] [-s] [-f]

명령 옵션

표 7–2에서는 imqusermgr 명령의 옵션이 나열되어 있습니다.

표 7–2 imqusermgr 옵션


옵션	설명
`-a` `activeState`	사용자 상태의 활성화 여부를 지정합니다(`true`/`false`). `true` 값은 활성화 상태를 나타내며 기본값입니다.
`-f`	사용자의 확인 없이 작업을 수행합니다.
`-h`	사용 도움말을 표시합니다. 명령줄에 있는 명령은 실행되지 않습니다.
`-i` `instanceName`	명령이 적용될 브로커 인스턴스 이름을 지정합니다. 지정하지 않으면 기본 인스턴스 이름 `imqbroker`인 것으로 가정합니다.
`-p` `passwd`	사용자의 비밀번호를 지정합니다.
`-g` `group`	사용자 그룹을 지정합니다. 유효한 값에는 `admin`, `user`, `anonymous`가 있습니다.
`-s`	자동 모드를 설정합니다.
`-u` `userName`	사용자 이름을 지정합니다.
`-v`	버전 정보를 표시합니다. 명령줄에 있는 명령은 실행되지 않습니다.

그룹

브로커 인스턴스의 사용자 저장소에 사용자 항목을 추가할 때, 사전 정의된 admin, user 또는 anonymous의 세 가지 그룹 중 하나를 지정할 수 있습니다. 그룹을 지정하지 않으면 기본 그룹인 user가 할당됩니다. 그룹은 다음과 같이 할당해야 합니다.

admin 그룹. 브로커 관리자에 사용됩니다. 이 그룹에 할당된 사용자는 기본적으로 브로커를 구성하고 관리할 수 있습니다. admin 그룹에 사용자를 두 명 이상 할당할 수도 있습니다.
user 그룹. 관리자가 아닌 일반 Message Queue 클라이언트 사용자에 사용됩니다. 대부분의 클라이언트 사용자는 user 그룹에 속합니다. 기본적으로 이 그룹의 사용자는 모든 주제와 대기열에 메시지를 생성하고 모든 주제와 대기열에서 메시지를 사용하고 모든 대기열에서 메시지를 찾아볼 수 있습니다.
anonymous 그룹. 브로커에 알려진 사용자 이름을 사용하지 않는(클라이언트 응용 프로그램에서 사용해야 할 실제 사용자 이름을 모르기 때문일 수 있음) Message Queue 클라이언트에 사용됩니다. 이 계정은 대부분의 FTP 서버에 있는 anonymous 계정과 유사합니다. anonymous 그룹에는 한 번에 한 사용자만 할당할 수 있습니다. user 그룹과 비교하여 이 그룹의 액세스 권한을 제한하거나, 배포 시 그룹에서 사용자를 제거해야 합니다.

사용자의 그룹을 변경하려면, 사용자 항목을 삭제한 후 그 사용자에 다른 항목을 추가하여 새 그룹을 지정해야 합니다.

시스템에서 생성한 그룹의 경우 이름을 변경하거나 삭제할 수 없습니다. 또한 새 그룹을 만들 수도 없습니다. 하지만 해당 그룹의 구성원이 수행할 수 있는 작업을 정의하는 액세스 규칙을 지정할 수 있습니다. 자세한 내용은 사용자 권한 부여: 액세스 제어 등록 정보 파일을 참조하십시오.

사용자 상태

사용자를 저장소에 추가하면 그 사용자는 기본적으로 활성 상태가 됩니다. 사용자를 비활성 상태로 만들려면 update 명령을 사용해야 합니다. 예를 들어, 다음 명령은 사용자 JoeD를 비활성 상태로 만듭니다.

imqusermgr update -u JoeD -a false

비활성 상태인 사용자의 항목은 저장소에 보존되지만, 비활성 상태인 사용자가 새 연결을 열 수는 없습니다. 사용자가 비활성 상태일 때 같은 이름을 가진 다른 사용자를 추가하면 작업이 실패합니다. 비활성 사용자 항목을 삭제하거나, 새 사용자의 이름을 변경하거나, 새 사용자에게 다른 이름을 사용해야 합니다. 그러면 중복되는 사용자 이름을 추가하지 않게 됩니다.

사용자 이름 및 비밀번호 형식

사용자 이름과 비밀번호는 다음과 같은 지침을 따라야 합니다.

사용자 이름에는 별표(*), 쉼표(,), 콜론(:), 줄바꿈 또는 캐리지 리턴 문자가 포함되지 않아야 합니다.
사용자 이름 또는 비밀번호는 한 문자 이상이어야 합니다.
사용자 이름 또는 비밀번호에 공백이 포함된 경우에는 이름 또는 비밀번호 전체를 따옴표로 묶어야 합니다.
명령 쉘에서 명령줄에 입력할 수 있는 최대 문자 수가 제한되어 있는 것 외에는 비밀번호 또는 사용자 이름에 적용되는 길이 제한은 없습니다.

사용자 저장소 채우기 및 관리

저장소에 사용자를 추가하려면 add 하위 명령을 사용합니다. 예를 들어, 다음 명령은 기본 브로커 인스턴스 사용자 저장소에 비밀번호가 sesame인 사용자 Katharine을 추가합니다.

imqusermgr add -u Katharine -p sesame -g user

저장소에서 사용자를 삭제하려면 delete 하위 명령을 사용합니다. 예를 들어, 다음 명령은 Bob이라는 사용자를 삭제합니다.

imqusermgr delete -u Bob

사용자의 비밀번호 또는 상태를 변경하려면 update 하위 명령을 사용합니다. 예를 들어, 다음 명령은 Katharine의 비밀번호를 aladdin으로 변경합니다.

imqusermgr update -u Katharine -p aladdin

한 사용자 또는 모든 사용자에 대한 정보를 나열하려면 list 명령을 사용합니다. 다음 명령은 isa라는 사용자에 대한 정보를 표시합니다.

imqusermgr list -u isa

% imqusermgr list -u isa

User repository for broker instance: imqbroker
----------------------------------
User Name    Group    Active State
----------------------------------
isa          admin    true

다음 명령은 모든 사용자에 대한 정보를 나열합니다.

imqusermgr list

% imqusermgr list

User repository for broker instance: imqbroker
--------------------------------------
User Name    Group        Active State
--------------------------------------
admin        admin        true
guest        anonymous    true
isa          admin        true
testuser1    user         true
testuser2    user         true
testuser3    user         true
testuser4    user         false
testuser5    user         false

기본 관리자 비밀번호 변경

보안을 위해 admin의 기본 비밀번호를 자신만 아는 비밀번호로 변경해야 합니다. 다음 명령은 mybroker 브로커 인스턴스의 기본 관리자 비밀번호 를 admin에서 grandpoobah로 변경합니다.

imqusermgr update mybroker -u admin -p grandpoobah

브로커 인스턴스가 실행 중일 때 명령줄 도구 중 하나를 실행하여 이러한 변경 사항의 적용 여부를 빠르게 확인할 수 있습니다. 예를 들어, 다음 명령은 비밀번호를 묻습니다.

imqcmd list svc mybroker -u admin

새 비밀번호(grandpoobah)가 올바르게 작동해야 하고 이전 비밀번호는 실패해야 합니다.

비밀번호를 변경한 후에 관리 콘솔을 포함한 Message Queue 관리 도구를 사용하려면 새 비밀번호를 입력해야 합니다.

사용자 저장소에 LDAP 서버 사용

사용자 저장소에 LDAP 서버를 사용하려면 다음 작업을 수행합니다.

인스턴스 구성 파일 편집
관리자에 대한 액세스 제어 설정

인스턴스 구성 파일 편집

브로커가 디렉토리 서버를 사용하게 하려면 브로커 인스턴스 구성 파일 config.properties에서 특정 등록 정보의 값을 설정해야 합니다. 이 등록 정보를 사용하면 사용자가 브로커 인스턴스에 연결하거나 메시징 작업을 수행하려 할 때마다 브로커 인스턴스가 LDAP 서버로부터 사용자 및 그룹에 대한 정보를 쿼리할 수 있습니다.

인스턴스 구성 파일은 브로커 인스턴스 디렉토리 아래의 디렉토리에 있습니다. 경로 형식은 다음과 같습니다.

…/instances/instanceName

/props/config.properties

운영 체제별 인스턴스 디렉토리 위치에 대한 자세한 내용은 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오.

LDAP 서버를 사용하도록 구성 파일을 편집하는 방법

다음 등록 정보를 설정하여 LDAP 사용자 저장소를 사용하고 있음을 지정합니다.
imq.authentication.basic.user_repository=ldap

imq.authentication.type 등록 정보를 설정하여 클라이언트에서 브로커로 전달되는 비밀번호를 인코딩하는 데 base-64(basic)를 사용할지 또는 MD5(digest)를 사용할지 여부를 결정합니다. 사용자 저장소에 LDAP 디렉토리를 사용하는 경우에는 인증 유형을 basic으로 설정해야 합니다. 예를 들면 다음과 같습니다.
imq.authentication.type=basic

LDAP 액세스를 제어하는 브로커 등록 정보도 설정해야 합니다. 이러한 등록 정보는 브로커의 인스턴스 구성 파일에 저장됩니다. 등록 정보는 보안 서비스에서 설명되고 보안 등록 정보에 요약되어 있습니다.

Message Queue는 JNDI API를 사용하여 LDAP 디렉토리 서버와 통신합니다. 이러한 등록 정보에 사용되는 구문과 용어에 대한 자세한 내용은 JNDI 설명서를 참조하십시오. Message Queue는 Sun JNDI LDAP 공급자를 사용하며 단순 인증을 사용합니다.

Message Queue는 LDAP 인증 페일오버를 지원하므로 인증을 시도할 LDAP 디렉토리 서버 목록을 지정할 수 있습니다(자세한 내용은 imq.user.repos.ldap.server 등록 정보 참조).

LDAP 사용자 저장소 관련 등록 정보를 설정하는 방법은 브로커의 config.properties 파일을 참조하십시오.

필요한 경우에는 액세스 제어 등록 정보 파일에서 사용자/그룹과 규칙을 편집해야 합니다. 액세스 제어 등록 정보 파일 사용에 대한 자세한 내용은 사용자 권한 부여: 액세스 제어 등록 정보 파일을 참조하십시오.

연결 인증 및 그룹 검색 중 브로커가 SSL을 통해 LDAP 디렉토리 서버와 통신하도록 하려면 LDAP 서버에서 SSL을 활성화한 후 브로커 구성 파일에서 다음 등록 정보를 설정해야 합니다.
- LDAP 서버가 SSL 통신에 사용하는 포트를 지정합니다. 예를 들면 다음과 같습니다.
  imq.user_repository.ldap.server=myhost:7878
- 브로커 등록 정보 imq.user_repository.ldap.ssl.enabled를 true로 설정합니다.
  
  여러 LDAP 디렉토리 서버를 사용하는 경우 ldap://를 사용하여 각 디렉토리 서버를 추가로 지정합니다. 예를 들면 다음과 같습니다.
  
  imq.user_repository.ldap.server = myHost:7878 ldap:// otherHost:7878 …
  
  추가된 각 디렉토리 서버를 공백으로 구분합니다. 목록의 모든 디렉토리 서버는 기타 LDAP 관련 등록 정보에 대해 동일한 값을 사용해야 합니다.

관리자에 대한 액세스 제어 설정

관리자를 만들려면 액세스 제어 등록 정보 파일을 사용하여 ADMIN 연결을 생성할 수 있는 사용자와 그룹을 지정합니다. 이러한 사용자와 그룹을 LDAP 디렉토리에서 사전 정의해야 합니다.

ADMIN 연결을 만들 수 있는 모든 사용자나 그룹은 관리 명령을 실행할 수 있습니다.

관리자 설정 방법

브로커 등록 정보 imq.accesscontrol.enabled를 true(기본값)로 설정하여 액세스 제어 파일을 사용 가능하게 합니다.

imq.accesscontrol.enabled 등록 정보는 액세스 제어 파일을 사용 가능하게 합니다.

액세스 제어 파일 accesscontrol.properties를 엽니다. 파일 위치는 부록 A, 플랫폼별 Message Queue^TM 데이터 위치에 나와 있습니다.

파일에는 다음과 같은 항목이 포함되어 있습니다.

service connection access control##################################connection.NORMAL.allow.user=*connection.ADMIN.allow.group=admin

나열된 항목은 예입니다. admin 그룹은 파일 기반 사용자 저장소에 있지만 기본적으로 LDAP 디렉토리에는 없습니다. LDAP 디렉토리에 정의된 그룹의 이름을 Message Queue 관리자 권한을 부여할 그룹 이름으로 대체해야 합니다.

사용자에게 Message Queue 관리자 권한을 부여하려면 다음과 같이 사용자 이름을 입력합니다.

connection.ADMIN.allow.user= userName[[,userName2] …]

그룹에 Message Queue 관리자 권한을 부여하려면 다음과 같이 그룹 이름을 입력합니다.

connection.ADMIN.allow.group= groupName[[,groupName2] …]

사용자 권한 부여: 액세스 제어 등록 정보 파일

access control properties file(ACL 파일)에는 사용자와 사용자 그룹이 수행할 수 있는 작업을 지정하는 규칙이 포함되어 있습니다. ACL 파일을 편집하여 이런 작업을 특정 사용자 및 그룹으로 제한합니다. 브로커 인스턴스마다 다른 ACL 파일을 사용할 수 있습니다.

ACL 파일은 사용자 정보가 플랫 파일 사용자 저장소에 있는지 또는 LDAP 사용자 저장소에 있는지 여부와 상관 없이 모두 사용할 수 있습니다.브로커는 클라이언트 응용 프로그램이 다음 작업 중 하나를 수행할 때 ACL 파일을 확인합니다.

연결 만들기
생성자 만들기
사용자 만들기
대기열 찾아보기

브로커는 ACL 파일을 확인하여 작업 수행 권한을 요청을 생성한 사용자에게 부여할지 해당 사용자가 속하는 그룹에 부여할지를 결정합니다.

ACL 파일을 편집한 경우 브로커가 다음에 파일을 검사하여 권한 부여를 확인할 때 새로운 설정이 적용됩니다. 파일을 편집한 후 브로커를 다시 시작할 필요가 없습니다.

액세스 제어 등록 정보 파일 작성

ACL 파일은 인스턴스에 고유합니다. 브로커 인스턴스를 시작할 때마다 기본 파일 accesscontrol.properties가 인스턴스 디렉토리에 생성됩니다. 파일에 대한 경로 형식은 다음과 같습니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).

…/instances/brokerInstanceName/etc/accesscontrol.properties

ACL 파일은 Java 등록 정보 파일과 같은 형식으로 구성됩니다. 먼저 파일 버전을 정의하는 것으로 시작하여 다음 세 개 섹션에서 액세스 제어 규칙을 지정합니다.

연결 액세스 제어
물리적 대상 액세스 제어
물리적 대상 자동 생성 액세스 제어

version 등록 정보는 ACL 등록 정보 파일의 버전을 정의하며 이 항목은 변경할 수 없습니다.

version=JMQFileAccessControlModel/100

액세스 규칙의 기본 구문, 권한을 계산하는 방법 및 ACL 파일에서 액세스 제어를 지정하는 세 개의 섹션에 대한 설명이 아래에 나와 있습니다.

액세스 규칙 구문

ACL 등록 정보 파일에서 액세스 제어는 물리적 대상 및 연결 서비스와 같이 보호된 자원에 대해 특정 사용자 또는 그룹이 갖는 액세스 권한을 정의합니다. 액세스 제어는 규칙 또는 규칙 집합으로 나타내며 각 규칙은 Java 등록 정보로 표시됩니다.

이 규칙의 기본 구문은 다음과 같습니다.

resourceType.resourceVariant

.operation.access.
principalType=principals

표 7–3에서는 구문 규칙의 요소에 대해 설명합니다.

표 7–3 액세스 규칙의 구문 요소


요소	설명
`resourceType`	`connection`, `queue` 또는 `topic` 중 하나입니다.
`resourceVariant`	`resourceType`에서 지정한 유형의 인스턴스입니다. 예를 들면 `myQueue`가 있습니다. 와일드카드 문자(*)를 사용하여 모든 연결 서비스 유형 또는 모든 물리적 대상을 나타낼 수 있습니다.
`operation`	값은 표현할 액세스 규칙의 종류에 따라 달라집니다.
`access`	One of the following: `allow` 또는 `deny` 중 하나입니다.
`principalType`	One of the following: `user` 또는 `group` 중 하나입니다. 자세한 내용은 그룹을 참조하십시오.
`principals`	규칙의 왼쪽에 지정한 액세스를 갖는 사람입니다. `principalType`이 `user`이면 개별 사용자 또는 사용자 목록(쉼표로 구분)이 될 수 있고, `principalType`이 `group`이면 한 그룹 또는 그룹 목록(쉼표로 구분)이 될 수 있습니다. 와일드카드 문자(*)를 사용하여 모든 사용자 또는 모든 그룹을 나타낼 수 있습니다.

다음은 액세스 규칙의 몇 가지 예입니다.

다음 규칙은 모든 사용자가 q1이라는 이름의 대기열에 메시지를 보낼 수 있다는 것을 나타냅니다.
```
queue.q1.produce.allow.user=*
```
다음 규칙은 모든 사용자가 모든 대기열에 메시지를 보낼 수 있다는 것을 나타냅니다.
```
queue.*.produce.allow.user=*
```

주 –

ASCII가 아닌 사용자, 그룹 또는 대상 이름을 지정하려면 유니코드 제어(\\uXXXX) 표기를 사용해야 합니다. ACL 파일을 편집한 후 ASCII 인코딩이 아닌 이름으로 저장한 경우에는 Java native2ascii 도구를 사용해서 해당 파일을 ASCII로 변환할 수 있습니다. 자세한 내용은 다음을 참조하십시오.

http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html

사용 권한 계산 방법

파일에 여러 액세스 규칙이 있는 경우 사용 권한은 다음과 같이 계산됩니다.

구체적인 액세스 규칙은 일반적인 액세스 규칙을 대체합니다. 다음 두 규칙을 적용하고 나면 모든 사용자가 모든 대기열에 전송할 수 있지만 Bob은 tq1에 전송할 수 없습니다.
```
queue.*.produce.allow.user=*
queue.tq1.produce.deny.user=Bob
```
명시된 principal로 지정한 액세스 권한은 * principal로 지정한 액세스 권한을 대체합니다. 다음 규칙은 tq1에서 메시지를 생성할 권한을 Bob에게는 허용하지 않지만 다른 모든 사람에게는 허용합니다.
```
queue.tq1.produce.allow.user=*
queue.tq1.produce.deny.user=Bob
```
사용자에 대한 * principal 규칙은 그룹에 대한 해당 * principal을 대체합니다. 예를 들어, 다음 두 규칙은 인증된 모든 사용자가 tq1에 메시지를 보낼 수 있도록 허용합니다.
```
queue.tq1.produce.allow.user=*
queue.tq1.produce.deny.group=*
```
사용자에게 부여된 액세스 권한은 사용자 그룹에 부여된 액세스 권한을 대체합니다. 다음 예에서 Bob은 User의 구성원이지만 tq1에 메시지를 생성할 수 없습니다. User의 다른 모든 구성원은 메시지를 생성할 수 있습니다.
```
queue.tq1.produce.allow.group=User
queue.tq1.produce.deny.user=Bob
```
액세스 규칙을 통해 명확하게 부여되지 않은 모든 액세스 권한은 거부됩니다. 예를 들어, ACL 파일에 액세스 규칙이 없으면 모든 사용자의 모든 작업이 거부됩니다.
같은 사용자 또는 그룹에 권한을 거부하고 허용하면 설정이 서로 상쇄됩니다. 예를 들어, 다음과 같은 두 규칙이 있으면 Bob은 q1을 찾아볼 수 없습니다.
```
queue.q1.browse.allow.user=Bob
queue.q1.browse.deny.user=Bob
```
다음 두 규칙은 User 그룹이 q5에서 메시지를 사용하지 못하게 합니다.
```
queue.q5.consume.allow.group=User
queue.q5.consume.deny.group=User
```
왼쪽의 같은 규칙이 여러 개 있는 경우에는 마지막 항목만 적용됩니다.

연결 서비스에 대한 액세스 제어

ACL 등록 정보 파일의 연결 액세스 제어 섹션에는 브로커의 연결 서비스에 대한 액세스 제어 규칙이 있습니다. 연결 액세스 제어 규칙의 구문은 다음과 같습니다.

connection.resourceVariant.
access.principalType=
principals

resourceVariant에 정의할 수 있는 값은 NORMAL과 ADMIN 두 가지입니다. 이러한 사전 정의된 값은 사용자가 액세스 권한을 부여할 수 있는 유일한 연결 서비스 유형입니다.

기본 ACL 등록 정보 파일은 모든 사용자에게 NORMAL 연결 서비스에 대한 액세스 권한을 부여하고 admin 그룹에 속하는 사용자에게는 ADMIN 연결 서비스에 대한 액세스 권한을 부여합니다.

connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admin

파일 기반 사용자 저장소를 사용하는 경우 기본 그룹 admin이 사용자 관리자 유틸리티를 통해 만들어집니다. LDAP 사용자 저장소를 사용하는 경우 다음 중 하나를 수행하여 기본 ACL 등록 정보 파일을 사용할 수 있습니다.

LDAP 디렉토리에서 admin 그룹을 정의합니다.
ACL 등록 정보 파일의 이름 admin을 LDAP 디렉토리에 정의된 하나 이상의 그룹 이름으로 교체합니다.

연결 액세스 권한을 제한할 수 있습니다. 예를 들어, 다음 규칙에서는 NORMAL에 대한 Bob의 액세스를 거부하지만 다른 모든 사람은 허용합니다.

connection.NORMAL.deny.user=Bob
connection.NORMAL.allow.user=*

별표(*) 문자를 사용해서 인증된 모든 사용자 또는 그룹을 지정할 수 있습니다.

ACL 등록 정보 파일을 사용하여 ADMIN 연결에 대한 액세스 권한을 부여하는 방법은 파일 기반 사용자 저장소와 LDAP 사용자 저장소에서 다음과 같이 다릅니다.

파일 기반 사용자 저장소
- 액세스 제어가 비활성화된 경우 admin 그룹의 사용자가 ADMIN 연결 권한을 갖습니다.
- 액세스 제어가 활성화된 경우 ACL 파일을 편집합니다. ADMIN 연결 서비스에 대한 액세스 권한을 사용자 또는 그룹에 명시적으로 부여합니다.

LDAP 사용자 저장소. LDAP 사용자 저장소를 사용하는 경우 다음을 모두 수행합니다.
- 액세스 제어를 활성화합니다.
- ACL 파일을 편집하고 ADMIN 연결을 만들 수 있는 사용자 또는 그룹의 이름을 제공합니다. LDAP 디렉토리 서버에 정의된 사용자 또는 그룹을 지정합니다.

물리적 대상에 대한 액세스 제어

액세스 제어 등록 정보 파일의 대상 액세스 제어 섹션에는 물리적 대상 기반 액세스 제어 규칙이 있습니다. 이 규칙은 누가(사용자/그룹) 어디에서(물리적 대상) 무엇을(작업) 할 수 있는지 결정합니다. 이 규칙으로 규제되는 액세스 유형에는 대기열로 메시지 전송, 주제에 메시지 게시, 대기열에서 메시지 수신, 주제에 가입, 대기열에서 메시지 찾아보기가 포함됩니다.

기본적으로 모든 사용자 또는 그룹은 모든 물리적 대상에 대해 모든 유형의 액세스 권한을 갖습니다. 특정 대상 액세스 규칙을 추가하거나 기본 규칙을 편집할 수 있습니다. 이 절의 나머지 부분에서는 규칙을 직접 작성하기 위해 알아야 하는 물리적 대상 액세스 규칙의 구문에 대해 설명합니다.

대상 규칙의 구문은 다음과 같습니다.

resourceType.resourceVariant.operation.access.principalType=principals

표 7–4에서는 이러한 요소에 대해 설명합니다.

표 7–4 물리적 대상 액세스 제어 규칙의 요소


구성 요소	설명
`resourceType`	`queue` 또는 `topic`일 수 있습니다.
`resourceVariant`	물리적 대상 이름 또는 모든 대기열이나 모든 주제를 나타내는 모든 물리적 대상(*)입니다.
`operation`	`produce`, `consume` 또는 `browse` 중 하나일 수 있습니다.
`access`	`allow` 또는 `deny`일 수 있습니다.
`principalType`	`user` 또는 `group`일 수 있습니다.

하나 이상의 사용자 또는 하나 이상의 그룹에 액세스를 허용할 수 있습니다.

다음 예에서는 다양한 종류의 물리적 대상 액세스 제어 규칙을 보여줍니다.

모든 사용자가 모든 대기열 대상에 메시지를 보낼 수 있도록 허용합니다.
```
queue.*.produce.allow.user=*
```
user 그룹의 모든 구성원에 대해 Admissions 주제에 가입하지 못하게 합니다.
```
topic.Admissions.consume.deny.group=user
```

자동 생성 물리적 대상에 대한 액세스 제어

ACL 등록 정보 파일의 마지막 섹션에는 브로커에서 물리적 대상을 자동 생성하는 사용자 또는 그룹을 지정하는 액세스 규칙이 있습니다.

사용자가 아직 존재하지 않는 물리적 대상에서 생성자 또는 사용자를 만든 경우 브로커의 자동 생성 등록 정보가 활성화되어 있으면 브로커가 해당 대상을 만듭니다.

기본적으로 모든 사용자 또는 그룹은 브로커가 물리적 대상을 자동 생성하도록 할 수 있습니다. 이 권한은 다음과 같은 규칙으로 지정합니다.

queue.create.allow.user=*
topic.create.allow.user=*

ACL 파일을 편집하여 이 유형의 액세스를 제한할 수도 있습니다.

물리적 대상 자동 생성 액세스 규칙의 일반 구문은 다음과 같습니다.

resourceType.create.access.principalType=principals

여기서 resourceType은 queue 또는 topic입니다.

예를 들어, 다음 규칙은 브로커가 Snoopy를 제외한 모든 사람에 대해 주제 대상을 자동 생성하도록 허용합니다.

topic.create.allow.user=*
topic.create.deny.user=Snoopy

물리적 대상 자동 생성 규칙의 효과와 물리적 대상 액세스 규칙의 효과 사이에 모순이 없도록 해야 합니다. 예를 들어, 1) 어떤 사용자도 대상으로 메시지를 보낼 수 없도록 대상 액세스 규칙을 변경했는데 2) 대상의 자동 생성은 허용했다면, 브로커는 물리적 대상이 없는 경우 물리적 대상을 만들기는 하지만 메시지를 그 물리적 대상으로 전달하지는 않습니다.

메시지 암호화

이 절에서는 클라이언트와 브로커 간에 암호화된 메시지를 보내는 SSL(Secure Socket Layer) 표준을 기반으로 연결 서비스를 설정하는 방법에 대해 설명합니다. Message Queue는 다음과 같은 SSL 기반 연결 서비스를 지원합니다.

ssljms 서비스는 TCP/IP 전송 프로토콜을 사용하여 클라이언트와 브로커 간에 암호화된 보안 메시지를 전달합니다.
ssladmin 서비스는 TCP/IP 전송 프로토콜을 사용하여 Message Queue 명령 유틸리티(imqcmd)와 브로커 간에 암호화된 보안 연결을 생성합니다. 관리 콘솔(imqadmin)에서는 암호화된 연결이 지원되지 않습니다.
cluster 서비스는 TCP/IP 전송 프로토콜을 사용하여 클러스터의 브로커 간에 암호화된 보안 통신을 제공합니다.
httpsjms 서비스는 HTTP 전송 프로토콜과 HTTPS 터널 서블릿을 사용하여 클라이언트와 브로커 간에 암호화된 보안 메시지를 전달합니다.

이 절의 나머지 부분에서는 ssljms, ssladmin 및 cluster 연결 서비스를 사용하여 TCP/IP를 통해 보안 연결을 설정하는 방법에 대해 설명합니다. httpsjms 서비스를 사용하여 HTTP를 통해 보안 연결을 설정하는 방법은 부록 C, HTTP/HTTPS 지원을 참조하십시오.

자체 서명된 인증서 사용

TCP/IP를 통해 SSL 기반 연결 서비스를 사용하려면 키 도구 유틸리티(imqkeytool)를 사용하여 공개/개인 키 쌍을 생성합니다. 이 유틸리티는 브로커에 대해 연결을 요청하는 모든 클라이언트로 전달되는 자체 서명된 인증서에 공용 키를 포함합니다. 그러면 클라이언트에서 이 인증서를 사용하여 암호화된 연결을 설정합니다. 이 절에서는 그런 자체 서명된 인증서를 사용하여 SSL 기반 서비스를 설정하는 방법에 대해 설명합니다.

인증 수준을 강화하려면 인증 기관이 확인한 서명된 인증서를 사용할 수 있습니다. 서명된 인증서를 사용하려면 자체 서명된 인증서에 필요한 단계 이외에 몇 가지 추가 단계를 수행해야 합니다. 이 절에서 설명하는 단계를 수행한 다음 서명된 인증서 사용 에 설명된 추가 단계를 수행해야 합니다.

자체 서명된 인증서를 사용한 Message Queue의 SSL 지원은 클라이언트가 알려지고 신뢰할 수 있는 서버와 통신한다는 가정 하에 전송 데이터를 보호하기 위한 것입니다. 다음 절차에서는 자체 서명된 인증서를 사용하도록 SSL 기반 연결 서비스를 설정하는 데 필요한 단계를 보여 줍니다. 다음에 오는 하위 절에서는 각 단계에 대해 자세히 설명합니다.

자체 서명된 인증서를 사용하여 SSL 기반 연결 서비스를 설정하는 방법

자체 서명된 인증서를 생성합니다.

브로커에서 ssljms, ssladmin 또는 cluster 연결 서비스를 활성화합니다.

브로커를 시작합니다.

클라이언트를 구성하고 실행합니다.

이 단계는 ssljms 연결 서비스에만 적용되고 ssladmin 또는 cluster에는 적용되지 않습니다.

자체 서명된 인증서 생성

키 도구 유틸리티(imqkeytool)를 실행하여 브로커에 대한 자체 서명된 인증서를 생성합니다. (UNIX® 시스템에서 키 저장소를 만들 권한을 가지려면 유틸리티를 수퍼유저(root)로 실행해야 할 수도 있음). ssljms, ssladmin 또는 cluster 연결 서비스에 동일한 인증서를 사용할 수 있습니다.

명령 프롬프트에서 다음을 입력합니다.

imqkeytool -broker

키 도구 유틸리티가 키 저장소 비밀번호를 묻습니다.

   Generating keystore for the broker ...
   Enter keystore password:

그런 다음 이 인증서가 속하는 브로커를 식별하는 정보를 묻습니다. 입력한 정보를 기반으로 X.500 고유 이름이 생성됩니다. 표 7–5에서는 프롬프트와 각 프롬프트에 대해 제공할 값을 보여 줍니다. 값은 대소문자가 구분되고 공백을 포함할 수 있습니다.

표 7–5 자체 서명된 인증서에 필요한 고유 이름 정보


프롬프트	X.500 속성	설명	예
`What is your first and last name?`	`commonName` (`CN`)	브로커를 실행하는 서버의 정규화된 이름	`mqserver.sun.com`
`What is the name of your organizational unit?`	`organizationalUnit` (`OU`)	부서 이름	`purchasing`
`What is the name of your organization?`	`organizationName` (`ON`)	회사, 정부 기관 등과 같이 더 큰 조직의 이름	`My Company, Inc.`
`What is the name of your city or locality?`	`localityName` (`L`)	구/군/시 이름	`San Francisco`
`What is the name of your state or province?`	`stateName` (`ST`)	약어를 사용하지 않은 시/도의 전체 이름	`California`
`What is the two-letter country code for this unit?`	`country` (`C`)	표준 2자 국가 코드	`US`

정보 입력이 끝나면 키 도구 유틸리티에서 확인을 위해 해당 정보를 표시합니다. 예를 들면 다음과 같습니다.

   Is CN=mqserver.sun.com, OU=purchasing, ON=My Company, Inc.,
   L=San Francisco, ST=California, C=US correct?

현재 값을 적용하고 계속하려면 yes를 입력하고, 값을 다시 입력하려면 기본값을 적용하거나 no를 입력합니다. 확인이 끝난 후 키 쌍이 생성되는 동안 유틸리티가 일시 중지됩니다.

그런 다음 키 쌍을 잠글 비밀번호(키 비밀번호)를 묻습니다. 키 비밀번호 및 키 저장소 비밀번호와 동일한 비밀번호를 사용하려면 이 프롬프트에서 Return 키를 누릅니다.

주 –

지정한 비밀번호를 기억해 두십시오. 브로커를 시작할 때 이 비밀번호를 입력해야 브로커가 키 저장소를 열 수 있습니다. 비밀번호 파일에 키 저장소 비밀번호를 저장할 수 있습니다( 비밀번호 파일 참조).

키 도구 유틸리티는 자체 서명된 인증서를 생성한 다음 Message Queue의 키 저장소에 넣습니다. 부록 A, 플랫폼별 Message Queue^TM 데이터 위치에 표시된 것처럼 키 저장소는 운영 체제에 따라 다른 디렉토리에 있습니다.

SSL 기반 연결 서비스의 Message Queue 키 저장소에 대해 구성 가능한 등록 정보는 다음과 같습니다.

imq.keystore.file.dirpath: 키 저장소 파일을 포함하는 디렉토리 경로입니다. 기본값은 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오.
imq.keystore.file.name: 키 저장소 파일의 이름입니다.
imq.keystore.password: 키 저장소 비밀번호입니다.

특정 문제를 해결하기 위해 키 쌍을 재생성해야 하는 경우도 있습니다. 예를 들어, 키 저장소 비밀번호를 잊은 경우나 브로커를 시작할 때 SSL 기반 서비스가 초기화되지 않고 예외가 발생되는 경우가 있습니다.

java.security.UnrecoverableKeyException:Cannot recover key

이 예외는 자체 서명된 인증서를 생성할 때의 키 저장소 비밀번호가 지정한 키 비밀번호와 다른 경우 발생할 수 있습니다.

키 쌍을 다시 생성하는 방법

부록 A, 플랫폼별 Message Queue^TM 데이터 위치에 나와 있는 위치에 있는 브로커의 키 저장소를 제거합니다.

위에서 설명한 것처럼 imqkeytool을 다시 실행하여 새 키 쌍을 생성합니다.

SSL 기반 연결 서비스 활성화

브로커에서 SSL 기반 연결 서비스를 활성화하려면 ssljms 또는 ssladmin을 imq.service.activelist 등록 정보에 추가해야 합니다.

브로커에서 SSL 기반 서비스를 활성화하는 방법

브로커의 인스턴스 구성 파일을 엽니다.

인스턴스 구성 파일은 구성 파일이 연결되어 있는 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 있습니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).
```
   .../instances/instanceName/props/config.properties
```

imq.service.activelist 등록 정보에 항목을 추가하고(항목이 아직 없는 경우) 목록에 원하는 SSL 기반 서비스를 포함시킵니다.

기본적으로 이 등록 정보에는jms 및 admin 연결 서비스가 포함됩니다. 활성화할 SSL 기반 서비스(ssljms, ssladmin 또는 둘 다)를 추가합니다.
```
imq.service.activelist=jms,admin,ssljms,ssladmin
```
주 –
SSL 기반 cluster 연결 서비스는 imq.cluster.transport 등록 정보를 imq.service.activelist 등록 정보 대신 사용하여 활성화합니다. 자세한 내용은 브로커 연결을 참조하십시오.

인스턴스 구성 파일을 저장하고 닫습니다.

브로커 시작

브로커를 시작하고 키 저장소 비밀번호를 제공합니다. 다음과 같은 두 가지 방법으로 비밀번호를 제공할 수 있습니다.

브로커를 시작할 때 비밀번호를 묻는 프롬프트가 표시되게 합니다.
```
   imqbrokerd
   Please enter Keystore password:
```
비밀번호 파일에서 설명한 대로 비밀번호 파일에 비밀번호를 입력합니다. 그런 다음 imq.passfile.enabled 등록 정보를 true로 설정하고 다음 중 하나를 수행합니다.
- 비밀번호 파일의 위치를 imqbrokerd 명령에 전달합니다.
```
imqbrokerd -passfile /passfileDirectory/passfileName
```
- -passfile 옵션 없이 브로커를 시작하되, 다음의 두 브로커 구성 등록 정보를 사용하여 비밀번호 파일의 위치를 지정합니다.
```
imq.passfile.dirpath=/passfileDirectory

imq.passfile.name=passfileName
```

주 –

SSL을 사용하는 브로커나 클라이언트를 시작할 때 몇 초간 CPU 사용량이 갑자기 증가하는 경우가 있을 수 있습니다. 이것은 Message Queue에서 난수를 생성하는 데 사용하는 JSSE(Java Secure Socket Extension) 메서드 java.security.SecureRandom이 초기 난수 시드를 생성하는 데 많은 시간이 소요되기 때문입니다. 시드를 만들고 나면 CPU 사용 수준이 정상으로 돌아갑니다.

SSL 기반 클라이언트 구성 및 실행

SSL 기반 연결 서비스를 사용하도록 클라이언트를 구성하는 절차는 ssljms 연결 서비스를 사용하는 응용 프로그램 클라이언트인지 ssladmin 연결 서비스를 사용하는 Message Queue 관리 클라이언트(예: imqcmd)인지 여부에 따라 다릅니다.

응용 프로그램 클라이언트

응용 프로그램 클라이언트의 경우 다음과 같은 .jar 파일이 CLASSPATH 변수에 지정되어 있어야 합니다.

imq.jar

jms.jar

Java 2 Software Development Kit(J2SDK) 1.4 이전 버전을 사용할 경우 다음과 같은 JSSE(Java Secure Socket Extension) 및 JNDI(Java Naming and Directory Interface) .jar 파일을 포함시켜야 합니다.

jsse.jar

jnet.jar

jcert.jar

jndi.jar

J2SDK 1.4 이상에서는 JSSE 및 JNDI를 기본적으로 지원하므로 이러한 파일을 포함시킬 필요가 없습니다.

CLASSPATH 파일을 제대로 지정한 경우 다음과 같은 명령을 입력하여 클라이언트를 시작하고 브로커의 ssljms 연결 서비스에 연결할 수 있습니다.

java -DimqConnectionType=TLS clientAppName

그러면 연결에서 SSL 기반 연결 서비스를 사용하게 됩니다.

관리 클라이언트

관리 클라이언트의 경우 imqcmd 명령을 호출할 때 -secure 옵션을 포함시켜 보안 연결을 설정할 수 있습니다. 예를 들면 다음과 같습니다.

imqcmd list svc -b hostName:portNumber -u adminName -secure

여기서 adminName은 Message Queue 사용자 저장소에 유효한 항목입니다. 이 명령은 비밀번호를 묻는 프롬프트를 표시합니다(플랫 파일 저장소를 사용하는 경우 기본 관리자 비밀번호 변경 참조).

연결 서비스를 나열하는 것은 ssladmin 서비스가 실행 중이며 다음 출력과 같이 보안 관리 연결을 성공적으로 설정할 수 있다는 것을 확인하는 방법입니다.

Listing all the services on the broker specified by:

Host                 Primary Port
localhost            7676

Service Name     Port Number       Service State
admin            33984 (dynamic)   RUNNING
httpjms          -                 UNKNOWN
httpsjms         -                 UNKNOWN
jms              33983 (dynamic)   RUNNING
ssladmin         35988 (dynamic)   RUNNING
ssljms           dynamic           UNKNOWN

Successfully listed services.

서명된 인증서 사용

서명된 인증서는 자체 서명된 인증서보다 더 높은 수준의 서버 인증을 제공합니다. 서명된 인증서는 클라이언트와 브로커 간에만 구현 가능하고 동일 클러스터 내의 브로커 간에는 구현할 수 없습니다. 그럴 경우 위에서 설명한 자체 서명된 인증서 구성 단계 이외에 다음과 같은 추가 단계를 수행해야 합니다. 이러한 단계에 대해서는 다음에 나오는 하위 절에 자세히 설명되어 있습니다.

서명된 인증서를 사용하는 방법

키 저장소에 인증서를 설치합니다.

브로커에 SSL 기반 연결을 설정할 때 서명된 인증서를 요구하도록 Message Queue 클라이언트를 구성합니다.

서명된 인증서 가져오기 및 설치

다음 절차에서는 서명된 인증서를 가져와서 설치하는 방법에 대해 설명합니다.

서명된 인증서를 가져오는 방법

J2SE keytool 명령을 사용하여 이전 절에서 생성한 자체 서명된 인증서에 대한 CSR(Certificate Signing Request)을 생성합니다.

keytool 명령에 대한 자세한 내용은 을 참조하십시오.

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html

예를 들면 다음과 같습니다.
keytool -certreq -keyalg RSA -alias imq -file certreq.csr -keystore /etc/imq/keystore -storepass myStorePassword
이 명령은 지정된 파일(이 예의 경우 certreq.csr)에서 인증서를 캡슐화하는 CSR을 생성합니다.

CSR을 사용하여 서명된 인증서를 생성하거나 요청합니다.

이 작업은 다음 중 한 가지 방법으로 수행할 수 있습니다.
- Thawte 또는 Verisign과 같이 공신력 있는 인증 기관(CA)에서 서명한 인증서를 가져옵니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 CA의 설명서를 참조하십시오.
- SSL 서명 소프트웨어 패키지를 사용하여 인증서에 직접 서명합니다.
  
  결과적으로 만들어지는 서명된 인증서는 ASCII 문자 시퀀스입니다. CA로부터 서명된 인증서를 받을 때 해당 인증서는 전자 메일 첨부 파일이나 메시지 텍스트로 전달될 수 있습니다.

서명된 인증서를 파일에 저장합니다.

아래 지침에서는 broker.cer이라는 이름 예를 사용하여 브로커 인증서를 나타냅니다.

서명된 인증서 설치 방법

J2SE가 기본적으로 인증 기관을 지원하는지 여부를 확인합니다.

다음 명령은 시스템 키 저장소에 있는 루트 CA를 나열합니다.
```
keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts
```
해당 CA가 목록에 있는 경우 다음 단계를 건너뜁니다.

인증 기관이 J2SE에서 지원되지 않는 경우 CA의 루트 인증서를 Message Queue 키 저장소로 가져옵니다.

예를 들면 다음과 같습니다.
```
keytool -import -alias ca -file ca.cer -noprompt -trustcacerts
        -keystore /etc/imq/keystore -storepass myStorePassword
```
여기서 ca.cer은 CA에서 가져온 루트 인증서가 들어 있는 파일입니다.

CA 테스트 인증서를 사용하는 경우 테스트 CA 루트 인증서를 가져와야 할 수 있습니다. CA에는 복사본을 가져오는 방법에 대한 지침이 있어야 합니다.

서명된 인증서를 키 저장소로 가져와서 자체 서명된 원본 인증서를 대체합니다.

예를 들면 다음과 같습니다.
```
keytool -import -alias imq -file broker.cer -noprompt -trustcacerts
        -keystore /etc/imq/keystore -storepass myStorePassword
```
여기서 broker.cer은 CA로부터 받은 서명된 인증서가 들어 있는 파일입니다.

Message Queue 키 저장소에는 이제 SSL 연결에 사용할 서명된 인증서가 포함되어 있습니다.

서명된 인증서를 요구하도록 Message Queue 클라이언트 런타임 구성

서명된 인증서를 요구하도록 Message Queue 클라이언트 런타임을 구성하고 인증서에 서명한 인증 기관을 신뢰하는지를 확인해야 합니다.

서명된 인증서를 요구하도록 클라이언트 런타임을 구성하는 방법

연결 팩토리의 imqSSLIsHostTrusted 속성을 false로 설정합니다.

기본적으로 클라이언트가 브로커 연결을 설정하는 데 사용할 연결 팩토리 객체의 imqSSLIsHostTrusted 속성은 true로 설정되어 있습니다. 즉, 클라이언트 런타임에서 제공된 인증서를 수용합니다. 클라이언트 런타임이 제공되는 모든 인증서를 검증하도록 이 값을 false로 변경해야 합니다. 인증서 서명자가 클라이언트의 트러스트 저장소에 없는 경우 검증이 실패합니다.

서명 기관이 클라이언트의 트러스트 저장소에 등록되어 있는지 여부를 확인합니다.

클라이언트가 인증 기관에서 서명한 인증서를 수용하는지 여부를 테스트하려면 SSL 기반 클라이언트 구성 및 실행에서 설명한 것처럼 SSL 연결 설정을 시도합니다. CA가 클라이언트의 트러스트 저장소에 있으면 성공적으로 연결되고 다음 단계를 건너뛸 수 있습니다. 연결이 실패하고 인증서 검증 오류가 발생하면 다음 단계로 이동합니다.

서명 CA의 루트 인증서를 클라이언트의 트러스트 저장소에 설치합니다.

클라이언트는 기본적으로 키 저장소 파일 cacerts 및 jssecacerts를 검색하므로 인증서를 이러한 파일에 설치할 때 추가 구성이 필요하지 않습니다. 다음 예에서는 Verisign 인증 기관의 테스트 루트 인증서를 testrootca.cer 파일에서 기본 시스템 인증서 파일 cacerts에 설치합니다.이 예제에서는 J2SE가 $JAVA_HOME/usr/j2se 디렉토리에 설치된다고 가정합니다.
```
keytool -import -keystore /usr/j2se/jre/lib/security/cacerts
        -alias VerisignTestCA -file testrootca.cer -noprompt
        -trustcacerts -storepass myStorePassword
```
대체(권장) 옵션으로 루트 인증서를 대체 시스템 인증서 파일 jssecacerts에 설치할 수 있습니다.
```
keytool -import -keystore /usr/j2se/jre/lib/security/jssecacerts
        -alias VerisignTestCA -file testrootca.cer -noprompt
        -trustcacerts -storepass myStorePassword
```
세 번째 방법으로 루트 인증서를 다른 키 저장소 파일에 설치하고 해당 저장소 파일을 트러스트 저장소로 사용하도록 클라이언트를 구성할 수 있습니다. 다음 예에서는 /home/smith/.keystore 파일에 설치합니다.
```
keytool -import -keystore /home/smith/.keystore
        -alias VerisignTestCA -file testrootca.cer -noprompt
        -trustcacerts -storepass myStorePassword
```
클라이언트는 기본적으로 이 키 저장소를 검색하지 않기 때문에 클라이언트에서 트러스트 저장소로 사용하도록 해당 위치를 명시적으로 지정해야 합니다. 이 작업은 클라이언트가 다음을 실행 중일 때 Java 시스템 등록 정보 javax.net.ssl.trustStore를 설정하여 수행합니다.
```
javax.net.ssl.trustStore=/home/smith/.keystore
```

비밀번호 파일

여러 가지 명령 유형에 비밀번호가 필요합니다. 표 7–6에서 첫 번째 열에는 비밀번호가 필요한 명령이 나열되고 두 번째 열에는 비밀번호가 필요한 이유가 나열됩니다.

표 7–6 비밀번호를 사용하는 명령


명령	목적	비밀번호의 목적
`imqbrokerd`	브로커를 시작합니다.	JDBC 기반 영구 데이터 저장소, SSL 인증서 키 저장소 또는 LDAP 사용자 저장소에 액세스합니다.
`imqcmd`	브로커 관리	명령 사용 권한이 있는 관리자를 인증합니다.
`imqdbmgr`	JDBC 기반 데이터 저장소 관리	데이터 저장소에 액세스합니다.

비밀번호 파일에 이러한 비밀번호를 지정하고 -passfile 옵션을 사용하여 파일의 이름을 지정할 수 있습니다. -passfile 옵션의 형식은 다음과 같습니다.

imqbrokerd -passfile myPassfile

주 –

이전 릴리스에서는 -p, -password, -dbpassword 및 -ldappassword 옵션을 사용하여 명령줄에서 비밀번호를 지정할 수 있었습니다. 이러한 옵션은 더 이상 사용되지 않으며 향후 릴리스에서는 제거됩니다. 현재 릴리스에서는 이러한 옵션 중 하나에 대한 명령줄의 값이 비밀번호 파일의 관련 값보다 우선합니다.

보안 문제

모니터를 다른 사람이 보고 있지 않다면 프롬프트에 응답하여 비밀번호를 대화식으로 지정하는 것이 가장 안전한 비밀번호 지정 방법입니다. 명령줄에서 비밀번호 파일을 지정할 수도 있습니다. 명령을 비대화식으로 사용할 경우 비밀번호 파일을 사용해야 합니다.

비밀번호 파일은 암호화되지 않기 때문에 사용 권한을 설정하여 인증되지 않은 액세스로부터 보호해야 합니다. 브로커를 시작하는 사용자가 파일을 볼 수 있지만 읽기 액세스만 허용되도록 사용 권한을 설정합니다.

비밀번호 파일 내용

비밀번호 파일은 일련의 등록 정보와 값이 들어 있는 간단한 텍스트 파일입니다. 각 값은 명령에 사용되는 비밀번호입니다.

비밀번호 파일에는표 7–7에 표시된 비밀번호를 포함할 수 있습니다.

표 7–7 비밀번호 파일의 비밀번호

비밀번호

영향 받는 명령

설명

imq.imqcmd.password

+-imqcmd

imqcmd 명령줄에 대한 관리자 비밀번호를 지정합니다. 비밀번호는 각 명령에 대해 인증됩니다.

imq.keystore.password

imqbrokerd

SSL 기반 서비스의 키 저장소 비밀번호를 지정합니다.

imq.persist.jdbc.password

imqbrokerd
imdbmgr

필요한 경우 데이터베이스 연결을 여는 비밀번호를 지정합니다.

imq.user_repository.ldap.password

imqbrokerd

구성된 LDAP 사용자 저장소에 바인드할 수 있도록 브로커에 할당한 고유 이름에 연결되는 비밀번호를 지정합니다.

샘플 비밀번호 파일은 Message Queue 제품의 일부입니다. 샘플 파일의 위치는 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오.

방화벽을 통해 연결

방화벽을 사용하여 클라이언트 응용 프로그램을 브로커와 분리하면 연결 설정을 위해 특별한 조치가 필요합니다. 한 가지 방법으로 httpjms 또는 httpsjms 연결 서비스를 사용하여 방화벽을 통해 "터널"을 생성할 수 있습니다. 자세한 내용은 부록 C, HTTP/HTTPS 지원을 참조하십시오. HTTP 연결은 다른 연결 서비스보다 더 느립니다. 그러나 그 보다 빠른 방법은 Message Queue 포트 매퍼를 우외하고 원하는 연결 서비스에 정적 포트 주소를 명시적으로 할당한 다음 방화벽에서 해당 포트를 여는 것입니다. 이 방법을 사용하면 jms 또는 ssljms 연결 서비스(또는 admin 또는 ssladmin)를 사용하여 방화벽을 통해 연결할 수 있습니다.

표 7–8 정적 포트 주소에 대한 브로커 구성 등록 정보


연결 서비스	구성 등록 정보
`jms`	`imq.jms.tcp.port`
`ssljms`	`imq.ssljms.tls.port`
`admin`	`imq.admin.tcp.port`
`ssladmin`	`imq.ssladmin.tls.port`

방화벽을 통해 브로커 연결을 활성화하는 방법

사용할 연결 서비스에 정적 포트 주소를 할당합니다.

포트 매퍼를 우회하고 연결 서비스에 정적 포트 번호를 직접 할당하려면 브로커 구성 등록 정보 imq.serviceName. protocolType.port를 설정합니다. 여기서 serviceName은 연결 서비스의 이름이고 protocolType은 해당 프로토콜 유형입니다(표 7–8 참조). 브로커 구성 등록 정보와 마찬가지로 브로커를 시작할 때 명령줄에서 또는 브로커의 인스턴스 구성 파일에서 이 등록 정보를 지정할 수 있습니다. 예를 들어, 포트 번호 10234를 jms 연결 서비스에 할당하려면
```
   imq.jms.tcp.port=10234
```
행을 구성 파일에 포함시키거나 다음 명령을 사용하여 브로커를 시작합니다.
```
   
imqbrokerd  -name myBroker  -Dimq.jms.tcp.port=10234
```

연결 서비스에 할당된 포트 번호에 연결할 수 있도록 방화벽을 구성합니다.

또한 방화벽을 통해 Message Queue의 포트 매퍼 포트(포트 매퍼를 다른 포트에 다시 할당하지 않은 경우 일반적으로 7676)에 연결할 수 있어야 합니다. 위 예에서 포트 10234 및 7676에 대해 방화벽을 열어야 합니다.

감사 기록

Message Queue는 엔터프라이즈판에서만 감사 기록을 지원합니다. 감사 로깅이 활성화되면 Message Queue는 다음과 같은 이벤트 유형에 대한 레코드를 생성합니다.

브로커 인스턴스 시작, 종료, 다시 시작 및 제거
사용자 인증 및 권한 부여
영구 저장소 재설정
물리적 대상 생성, 제거 및 완전 삭제
관리상 영구 가입자 완전 삭제

Message Queue 브로커 로그 파일에 감사 레코드를 기록하려면 imq.audit.enabled 브로커 등록 정보를 true로 설정합니다. 로그의 모든 감사 레코드에는 AUDIT 키워드가 있습니다.