7장 보안 관리

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

사용자 인증

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

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

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

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

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

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

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

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

사용자 저장소 만들기

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

저장소는 아래의 표 7-1과 같이 두 개의 항목(행)으로 만들어집니다.

표 7-1 사용자 저장소 초기 항목
사용자 아이디	비밀번호	그룹	상태
admin	admin	admin	active
guest	guest	anonymous	active

이러한 초기 항목을 사용하면 관리자가 개입하지 않아도 설치 후 바로 Message Queue 브로커를 사용할 수 있습니다. 초기 아이디/비밀번호 설정은 Message Queue 브로커를 사용하는 데 필요하지 않습니다.

초기 guest 사용자 항목을 사용하면 클라이언트에서 기본 guest 사용자 아이디와 비밀번호를 사용하여 브로커 인스턴스에 연결할 수 있습니다(예를 들어 테스트 목적으로).

초기 admin 사용자 항목을 사용하면 imqcmd 명령을 사용하여 기본 admin 사용자 아이디와 비밀번호로 브로커 인스턴스를 관리할 수 있습니다. 비밀번호를 변경하려면 이 초기 항목을 업데이트해야 합니다(기본 관리자 비밀번호 변경 참조).

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

사용자 관리자 유틸리티(imqusermgr)

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

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

imqusermgr을 사용하기 전에 주의해야 할 사항은 다음과 같습니다.

브로커별 사용자 저장소가 없는 경우 해당 브로커 인스턴스를 시작하여 브로커별 사용자 저장소를 만들어야 합니다.

imqusermgr 명령은 브로커가 설치된 호스트에서 실행해야 합니다.

저장소에 쓸 수 있는 적절한 권한이 있어야 합니다. 즉, Solaris 및 Linux의 경우 해당 브로커 인스턴스를 처음으로 만든 사용자나 루트 사용자여야 합니다.



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

하위 명령

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

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

delete 하위 명령 delete 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소에서 지정한 사용자를 삭제합니다. 하위 명령의 구문은 다음과 같습니다.

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

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

명령 옵션

표 7-2 imqusermgr 옵션
옵션	설명
-a active_state	사용자 상태의 활성화 여부를 지정합니다(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를 비활성 상태로 만듭니다.

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

사용자 아이디 및 비밀번호 형식

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

사용자 이름은 별표(*), 쉼표(,), 콜론(:), 줄바꿈 또는 캐리지 리턴을 포함할 수 없습니다.

사용자 아이디 또는 비밀번호는 한 문자 이상이어야 합니다.

사용자 아이디 또는 비밀번호에 공백이 포함된 경우에는 아이디 또는 비밀번호 전체를 따옴표로 묶어야 합니다.

명령 쉘에서 명령줄에 입력할 수 있는 최대 문자 수가 제한되어 있는 것 외에는 비밀번호 또는 사용자 아이디에 적용되는 길이 제한은 없습니다.

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

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

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

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

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

% imqusermgr list -u isa

User repository for broker instance: imqbroker

----------------------------------

User Name Group Active State

----------------------------------

isa admin true

% 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의 기본 비밀번호를 혼자만 아는 값으로 변경해야 합니다. 그러려면 imqusermgr 도구를 사용해야 합니다.

다음 명령은 mybroker 브로커 인스턴스의 기본 관리자 비밀번호를 admin에서 grandpoobah로 변경합니다.

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

새 비밀번호(grandpoobah)를 입력할 수 있어야 하고 이전 비밀번호는 실패해야 합니다.

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

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

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

인스턴스 구성 파일 편집

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

인스턴스 구성 파일 편집

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

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

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

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

imq.authentication.basic.user_repository=ldap

imq.authentication.type 등록 정보를 설정하여 클라이언트에서 브로커로 전달되는 비밀번호를 base64 인코딩(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로 설정합니다.

imq.user_repository.ldap.server. LDAP 서버의 host:port

imq.user_repository.ldap.principal. 브로커에서 검색할 디렉토리 서버에 바인드할 때 사용하는 고유 이름입니다.

imq.user_repository.ldap.password. 브로커에서 사용하는 고유 이름에 연결된 비밀번호입니다.

imq.user_repository.ldap.base. 사용자 항목에 사용되는 디렉토리 기반입니다.

imq.user_repository.ldap.uidattr. 사용자를 고유하게 식별하는 값을 가진 공급자별 속성 식별자입니다. uid, cn 등이 있습니다.

imq.user_repository.ldap.usrfilter. 사용자에 사용할 JNDI 검색 필터입니다.

imq.user_repository.ldap.grpsearch. 그룹 검색의 사용 여부를 지정하는 부울 값입니다.

imq.user_repository.ldap.grpbase. 그룹 항목에 사용되는 디렉토리 기반입니다.

imq.user_repository.ldap.gidattr. 그룹 이름을 값으로 가진 공급자별 속성 식별자입니다.

imq.user_repository.ldap.memattr. 그룹 구성원의 고유 이름을 값으로 가진 그룹 항목 내의 속성 식별자입니다.

imq.user_repository.ldap.grpfiltler. 그룹에 사용할 JNDI 검색 필터입니다.

imq.user_repository.ldap.timeout. 검색의 시간 제한(초)을 지정하는 정수입니다.

imq.user_repository.ldap.ssl.enabled. 브로커가 LDAP 서버와 통신할 때 SSL 프로토콜을 사용해야 하는지 여부를 지정하는 부울 값입니다.

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

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

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

▶ 관리 사용자 설정 방법

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

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

액세스 제어 파일 accesscontrol.properties를 엽니다. 파일 위치는 부록 A, "운영 체제별 Message Queue 데이터의 위치."에 나와 있습니다.

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

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,..]

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

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

브로커는 클라이언트 응용 프로그램이 다음 작업 중 하나를 수행할 때 ACL 파일을 확인합니다.

연결 만들기

생성자 만들기

사용자 만들기

대기열 찾아보기

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

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

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

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

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

연결 액세스 제어

물리적 대상 액세스 제어

물리적 대상 자동 작성 액세스 제어

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

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

액세스 규칙 구문

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

표 7-3 액세스 규칙의 구문 요소
요소	설명
resourceType	connection, queue 또는 topic 중 하나입니다.
resourceVariant	resourceType에서 지정한 유형의 인스턴스입니다. 예를 들면 myQueue가 있습니다. 와일드카드 문자(*)를 사용하여 모든 연결 서비스 유형 또는 모든 물리적 대상을 나타낼 수 있습니다.
operation	값은 표현할 액세스 규칙의 종류에 따라 달라집니다.
access	allow 또는 deny 중 하나입니다.
principalType	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

왼쪽의 같은 규칙이 여러 개 있는 경우에는 마지막 항목만 적용됩니다.

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

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

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

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

파일 기반 사용자 저장소를 사용하는 경우 기본 그룹 admin이 imqusermgr에 의해 생성됩니다. LDAP 사용자 저장소를 사용하는 경우 다음 중 하나를 수행하여 기본 ACL 등록 정보 파일을 사용할 수 있습니다.

LDAP 디렉토리에서 admin 그룹을 정의합니다.

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

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

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

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

파일 기반 사용자 저장소

액세스 제어가 비활성화된 경우 admin 그룹의 사용자가 ADMIN 연결 권한을 갖습니다.

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

LDAP 사용자 저장소. LDAP 사용자 저장소를 사용하는 경우 다음을 모두 수행합니다.

액세스 제어를 활성화합니다.

ACL 파일을 편집하고 ADMIN 연결을 만들 수 있는 사용자 또는 그룹의 이름을 제공합니다. LDAP 디렉토리 서버에 정의된 사용자 또는 그룹을 지정합니다.

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

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

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

표 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 등록 정보 파일의 마지막 섹션에는 브로커에서 물리적 대상을 자동 작성하는 사용자 또는 그룹을 지정하는 액세스 규칙이 있습니다.

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

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

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

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

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

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

SSL 기반 서비스 작업

SSL(Secure Socket Layer) 표준을 기반으로 하는 연결 서비스에서는 클라이언트와 브로커가 주고 받는 암호화된 메시지를 보냅니다. 이 절에서는 SSL 기반 연결 서비스 설정 방법에 대해 설명합니다.

Message Queue는 SSL(Secure Socket Layer) 표준을 기반으로 하는 다음과 같은 연결 서비스를 지원합니다.

ssljms, ssladmin 및 cluster가 TCP/IP를 통해 사용됩니다.

httpsjms는 HTTP를 통해 사용됩니다.

이러한 연결 서비스를 사용하면 클라이언트와 브로커가 주고 받는 메시지를 암호화할 수 있습니다. Message Queue는 자체 서명된 서버 인증서나 서명된 인증서를 기반으로 SSL 암호화를 지원합니다.

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

Message Queue의 SSL 기반 연결 서비스가 개념은 비슷하지만, 설정 방법에는 몇 가지 차이점이 있습니다.

이 절의 나머지 부분에서는 TCP/IP를 통해 보안 연결을 설정하는 방법에 대해 설명합니다.

HTTP를 통한 SSL 기반 연결 서비스(httpsjms)를 사용하면 클라이언트와 브로커가 HTTPS 터널 서블릿을 통해 보안 연결을 설정할 수 있습니다. HTTP를 통한 보안 연결 설정에 관한 자세한 내용은 부록 C, "HTTP/HTTPS 지원"을 참조하십시오.

TCP/IP에 대한 보안 연결 서비스

다음 SSL 기반 연결 서비스는 TCP/IP를 통해 직접 보안 연결을 제공합니다.

ssljms 서비스는 클라이언트와 브로커 간에 암호화된 보안 연결을 통해 메시지를 전달합니다.

ssladmin 서비스는 Message Queue 명령 유틸리티(imqcmd)와 브로커 사이에서 암호화된 보안 연결을 생성합니다. 관리 콘솔(imqadmin)에서는 보안 연결이 지원되지 않습니다.

cluster 서비스는 동일 클러스터의 브로커 간에 암호화된 보안 연결을 통해 메시지를 전달하고 브로커 간 통신을 제공합니다(브로커 간 보안 연결 참조).

자체 서명된 인증서 사용 구성

이 절에서는 자체 서명된 인증서를 사용하여 SSL 기반 서비스를 설정하는 방법을 설명합니다.

인증 수준을 강화하려면 인증 기관이 확인한 서명된 인증서를 사용할 수 있습니다. 이 절의 단계를 수행한 다음 서명된 인증서 사용 구성으로 이동하여 추가 단계를 수행하십시오.

▶ SSL 기반 연결 서비스를 설정하는 방법

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

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

브로커를 시작합니다.

클라이언트를 구성하고 실행합니다(ssljms 연결 서비스에만 적용).

ssljms와 ssladmin 연결 서비스를 설정하는 절차는 4단계의 클라이언트 구성 및 실행을 제외하면 서로 같습니다.

1단계. 자체 서명된 인증서 생성

Message Queue 자체 서명된 인증서를 사용한 SSL 지원은 클라이언트가 알려지고 신뢰할 수 있는 서버와 통신한다는 가정 하에 전송 데이터를 보호하기 위한 것입니다.

imqkeytool 명령을 실행하여 브로커에 자체 서명된 인증서를 생성합니다. Unix 시스템에서 키 저장소를 만들 권한을 가지려면 imqkeytool을 수퍼유저(root)로 실행해야 할 수 있습니다.

ssljms, ssladmin 또는 cluster 연결 서비스에 동일한 인증서를 사용할 수 있습니다.

그런 다음 유틸리티가 인증서를 소유하는 브로커를 식별하기 위해 정보를 묻는 메시지를 표시합니다. 입력한 정보를 기반으로 X.500 고유 이름이 생성됩니다. 다음 표에서는 프롬프트를 나열 및 설명하고 각 프롬프트에 대한 예를 제공합니다. 값은 대소문자가 구분되고 공백을 포함할 수 있습니다.

표 7-5 자체 서명된 인증서에 필요한 고유 이름 정보
프롬프트	설명	예
성과 이름은 무엇입니까?	X.500 commonName(CN). 브로커를 실행하는 서버의 정규화된 이름을 입력합니다.	myhost.sun.com
조직 단위의 이름은 무엇입니까?	X.500 organizationalUnit(OU). 부서 이름을 입력합니다.	purchasing
조직의 이름은 무엇입니까?	X.500 organizationName(ON). 회사, 정부 기관 등과 같이 더 큰 조직의 이름을 입력합니다.	My Company, Inc.
구/군/시 이름은 무엇입니까?	X.500 localityName(L).	San Francisco
시/도 이름은 무엇입니까?	X.500 stateName(ST). 약어를 사용하지 않고 시/도의 전체 이름을 입력합니다.	California
이 단위에 대한 2자 국가 코드는 무엇입니까?	X.500 country(C).	US

정보 입력이 끝나면 imqkeytool이 확인을 위해 해당 정보를 표시합니다. 예를 들면 다음과 같습니다.

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

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

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


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

imqkeytool을 실행하면 JDK keytool 유틸리티가 실행되어 자체 서명된 인증서를 생성하고 생성된 인증서를 부록 A, "운영 체제별 Message Queue 데이터의 위치."에 표시된 대로 운영 체제에 따라 다른 디렉토리에 있는 Message Queue의 키 저장소에 넣습니다.

키 저장소의 형식은 JDK1.2 keytool 유틸리티에서 지원하는 것과 같습니다.

Message Queue 키 저장소에 대해 구성 가능한 등록 정보는 다음과 같습니다.

imq.keystore.file.dirpath. SSL 기반 서비스의 경우: 키 저장소 파일이 있는 디렉토리의 경로를 지정합니다. 기본값은 부록 A, "운영 체제별 Message Queue 데이터의 위치."를 참조하십시오.

imq.keystore.file.name. SSL 기반 서비스의 경우: 키 저장소 파일의 이름을 지정합니다.

imq.keystore.password. SSL 기반 서비스의 경우: 키 저장소 비밀번호를 지정합니다.

특정 문제를 해결하기 위해 키 쌍을 다시 생성해야 할 수도 있습니다. 예를 들면 다음과 같습니다.

키 저장소 비밀번호를 잊은 경우

브로커를 시작할 때 SSL 기반 서비스가 시작되지 않고 java.security.UnrecoverableKeyException: Cannot recover key 예외가 발생합니다.

▶ 키 쌍을 다시 생성하는 방법

부록 A, "운영 체제별 Message Queue 데이터의 위치."에 나와 있는 위치에 있는 브로커의 키 저장소를 제거합니다.

imqkeytool을 다시 실행하여 1단계. 자체 서명된 인증서 생성의 설명과 같이 키 쌍을 생성합니다.

2단계. 브로커에서 SSL 기반 서비스 활성화

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


주	SSL 기반 클러스터 연결 서비스는 imq.service.activelist 등록 정보 대신 imq.cluster.transport 등록 정보를 사용하여 활성화합니다. 브로커 간 보안 연결을 참조하십시오.

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

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

인스턴스 구성 파일은 구성 파일이 연관된 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 있습니다(부록 A, "운영 체제별 Message Queue 데이터의 위치" 참조).

.../instances/instanceName/props/config.properties

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

기본적으로 이 등록 정보에는 jms 및 admin 연결 서비스가 포함됩니다. 활성화할 서비스에 따라 ssljms 및/또는 ssladmin 연결 서비스를 추가해야 합니다.

imq.service.activelist=jms,admin,ssljms,ssladmin

3단계. 브로커 시작

브로커를 시작하며 키 저장소 비밀번호를 제공합니다. 비밀번호는 다음 중 한 가지 방법으로 제공할 수 있습니다.

브로커를 시작할 때 비밀번호를 묻는 프롬프트가 표시되게 합니다.

imqbrokerd
Please enter Keystore password: mypassword

Passfile 사용에서 설명한 대로 passfile에 비밀번호를 저장합니다. passfile에 비밀번호를 저장하고 등록 정보 imq.passfile.enabled=true를 설정한 경우 다음 중 하나를 수행합니다.

passfile의 위치를 imqbrokerd 명령에 전달합니다.

imqbrokerd -passfile /tmp/mypassfile

-passfile 옵션 없이 브로커를 시작하되, 다음의 두 브로커 구성 등록 정보를 사용하여 passfile의 위치를 지정합니다.

imq.passfile.dirpath=/tmp

imq.passfile.name=mypassfile

SSL을 사용하는 브로커나 클라이언트를 시작할 때 몇 초간 CPU 사이클을 과도하게 사용하는 경우가 있을 수 있습니다. 이것은 Message Queue에서 SSL 구현에 JSSE(Java Secure Socket Extension)를 사용하기 때문입니다. JSSE에서는 java.security.SecureRandom()을 사용하여 난수를 생성합니다. 이 방법은 초기 난수 시드를 만드는 동안 상당한 시간을 소비하기 때문에 CPU 사용량이 많아지게 됩니다. 시드를 만들고 나면 CPU 수준이 정상으로 돌아갑니다.

4단계. SSL기반 클라이언트 구성 및 실행

마지막으로 보안 연결 서비스를 사용하도록 클라이언트를 구성합니다. TCP/IP를 통한 보안 연결 시나리오의 유형은 다음 두 가지입니다.

ssljms를 사용하는 응용 프로그램 클라이언트

ssladmin을 사용하는 Message Queue 관리 클라이언트(예: imqcmd)

ssljms를 사용하는 응용 프로그램 클라이언트

클라이언트의 클래스 경로에 필요한 Secure Socket Extension(JSSE) jar 파일이 있는지 확인하고 ssljms 연결 서비스를 사용하도록 지정해야 합니다.

클라이언트에서 (JSSE 및 JNDI 지원이 기본적으로 제공되는) J2SDK1.4를 사용하지 않는 경우에는 클라이언트의 클래스 경로에 다음 jar 파일이 있는지 확인합니다.

jsse.jar, jnet.jar, jcert.jar, jndi.jar

클라이언트의 클래스 경로에 다음 Message Queue jar 파일이 있는지 확인합니다.

imq.jar, jms.jar

클라이언트를 시작하고 브로커의 ssljms 서비스에 연결합니다. 이 작업을 수행하는 방법 중 하나는 다음과 같은 명령을 입력하는 것입니다.

java -DimqConnectionType=TLS clientAppName

imqConnectionType을 설정하면 연결에서 SSL을 사용하게 됩니다.

클라이언트 응용프로그램에서의 ssljms 연결 서비스 사용에 대한 자세한 내용은 Message Queue Developer’s Guide for Java Clients의 관리 대상 객체 사용에 대한 장을 참조하십시오.

ssladmin을 사용하는 관리 클라이언트(imqcmd)

imqcmd를 사용할 때 -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.

서명된 인증서 사용 구성

서명된 인증서는 자체 서명된 인증서보다 더 높은 수준의 서버 인증을 제공합니다. 서명된 인증서를 구현하려면 키 저장소에 서명된 인증서를 설치한 다음 imqbrokerd에 SSL 연결을 설정할 때 서명된 인증서를 요구하도록 Message Queue 클라이언트를 구성합니다.

서명된 인증서는 클라이언트와 브로커 간에만 구현 가능하고 동일 클러스터 내의 브로커 간에는 구현할 수 없습니다.

아래 지침에서는 자체 서명된 인증서 사용 구성에서 설명한 단계를 이미 수행한 것으로 가정합니다. 지침을 따르면 http://java.sun.com에서 J2SE 키 도구 및 X.509 인증서에 대한 정보에 액세스하는 데 도움이 됩니다.

1단계: 서명된 인증서 가져오기 및 설치

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

J2SE 키 도구를 사용하여 방금 생성한 자체 서명된 인증서에 대한 CSR(Certificate Signing Request)을 생성합니다.

예를 들면 다음과 같습니다.

keytool -certreq -keyalg RSA -alias imq -file certreq.csr
-keystore /etc/imq/keystore -storepass myStorePassword

CSR은 certreq.csr 파일에서 인증서를 캡슐화합니다.

다음 중 하나의 방법으로 서명된 인증서를 생성하거나 요청합니다.

Thawte 또는 Verisign과 같이 공신력 있는 인증 기관(CA)에서 서명한 인증서를 가져옵니다. 이 프로세스에 대한 자세한 내용은 해당 CA의 설명서를 참조하십시오.

SSL 서명 소프트웨어 패키지를 사용하여 인증서에 직접 서명합니다.

결과적으로 만들어지는 서명된 인증서는 ASCII 문자 시퀀스입니다. CA로부터 서명된 인증서를 받을 때 해당 인증서는 전자 메일 첨부 파일이나 메시지 텍스트로 전달될 수 있습니다.

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

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

▶ 서명된 인증서 설치 방법

다음과 같이 $JAVA_HOME/lib/security/cacerts를 검사하여 J2SE가 기본적으로 사용자 CA를 지원하는지 여부를 확인합니다.

keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts

이 명령은 시스템 키 저장소에 있는 루트 CA를 나열합니다.

해당 CA가 목록에 있는 경우 다음 단계를 건너뜁니다.

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

예를 들면 다음과 같습니다.

keytool -import -alias ca -file ca.cer -noprompt -trustcacerts
-keystore /etc/imq/keystore -storepass myStorePassword

ca.cer 값은 CA에서 가져온 CA 루트 인증서입니다.

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

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

예를 들면 다음과 같습니다.

keytool -import -alias imq -file broker.cer -noprompt -trustcacerts
-keystore /etc/imq/keystore -storepass myStorePassword

broker.cer 값은 CA로부터 받은 서명된 인증서가 들어 있는 파일입니다.

이제 imqbrokerd 키 저장소에 SSL 연결에 사용할 서명된 인증서가 있습니다.

2단계: 서명된 인증서를 요구하도록 클라이언트 런타임 구성

▶ Java 클라이언트 런타임 구성 방법

기본적으로 Message Queue 클라이언트 런타임은 imqbrokerd를 신뢰하므로 제시하는 모든 인증서를 승인합니다. 이제 서명된 인증서를 요구하도록 클라이언트 런타임을 구성하고 클라이언트가 인증서를 서명한 CA를 신뢰하는지 확인합니다.

클라이언트가 imqbrokerd로부터 유효한 서명된 인증서를 요구하도록 구성하려면 클라이언트의 ConnectionFactory 객체에 대해 imqSSLIsHostTrusted 속성을 false로 설정합니다.

4단계. SSL기반 클라이언트 구성 및 실행에서 설명한 대로 imqbrokrd에 SSL 연결을 설정해 봅니다.

브로커의 인증서가 공신력 있는 CA에 의해 서명된 경우 연결에 성공할 것이므로 다음 단계를 건너뛸 수 있습니다. 인증서 검증 오류로 인해 연결에 실패할 경우 다음 단계를 수행합니다.

다음 절에서 설명한 대로 클라이언트의 truststore에 서명 CA의 루트 인증서를 설치합니다.

truststore를 사용하여 클라이언트를 구성하는 세 가지 옵션이 있습니다.

기본 시스템 cacerts 파일에 루트 CA를 설치합니다.

대체 시스템 파일 jssecacerts에 루트 CA를 설치합니다. 이 방법이 권장 옵션입니다.

키 저장소 파일에 루트 CA를 설치하고 해당 CA를 truststore로 사용하도록 클라이언트를 구성합니다.

다음 절에서는 이러한 옵션을 사용하여 Verisign Test Root CA를 설치하는 방법을 예를 들어 설명합니다. 루트 CA는 testrootca.cer 파일에 포함되어 있습니다. 이 예에서는 J2SE가 /usr/j2se에 설치되어 있다고 가정합니다.

기본 시스템 cacerts 파일에 설치

이 예에서는 루트 CA를 $JAVA_HOME/usr/jre/lib/security/cacerts 파일에 설치합니다.

keytool -import -keystore /usr/j2se/jre/lib/security/cacerts
-alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword

기본적으로 클라이언트가 이 키 저장소를 검색하기 때문에 추가 클라이언트 구성은 필요하지 않습니다.

jssecacerts에 설치

이 예에서는 루트 CA를 $JAVA_HOME/usr/jre/lib/security/jssecacerts 파일에 설치합니다.

keytool -import -keystore /usr/j2se/jre/lib/security/jssecacerts
-alias VerisignTestCA -file testrootca.cer -noprompt
-trustcacerts -storepass myStorePassword

기본적으로 클라이언트가 이 키 저장소를 검색하기 때문에 추가 클라이언트 구성은 필요하지 않습니다.

다른 파일에 설치

keytool -import -keystore /home/smith/.keystore
-alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword

기본적으로 클라이언트는 이 키 저장소를 검색하지 않기 때문에 클라이언트에 truststore 위치를 직접 제공해야 합니다. 그렇게 하려면 클라이언트가 실행된 다음 Java 시스템 등록 정보 javax.net.ssl.trustStore를 설정합니다. 예를 들면 다음과 같습니다.

Passfile 사용

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

표 7-6 비밀번호를 사용하는 명령
명령	목적	비밀번호의 목적
imqbrokerd	브로커를 시작합니다.	플러그 인 지속성 데이터 저장소, SSL 인증서 키 저장소 또는 LDAP 사용자 저장소에 액세스합니다.
imqcmd	브로커를 관리합니다.	명령 사용 권한이 있는 관리 사용자를 인증합니다.
imqdbmgr	플러그 인 데이터 저장소를 관리합니다.	데이터 저장소에 액세스합니다.

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

보안 문제

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

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

Passfile 내용

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


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

passfile에는 표 7-7에 있는 것과 같은 비밀번호를 포함할 수 있습니다.

표 7-7 Passfile의 비밀번호
비밀번호	영향 받는 명령	설명
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는 엔터프라이즈판에서만 감사 로깅을 지원합니다. 감사 로깅이 활성화되면 Message Queue는 다음과 같은 이벤트 유형에 대한 레코드를 생성합니다.

브로커 인스턴스 시작, 종료, 재시작 및 제거

사용자 인증 및 권한 부여

영구 저장소 재설정

물리적 대상 만들기, 제거 및 완전 삭제

관리상 영구 가입자 완전 삭제

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

이전 목차 색인 다음
Sun Java System Message Queue 3 2005Q1 관리 설명서