access control properties file(ACL 파일)에는 사용자와 사용자 그룹이 수행할 수 있는 작업을 지정하는 규칙이 포함되어 있습니다. ACL 파일을 편집하여 이런 작업을 특정 사용자 및 그룹으로 제한합니다. 브로커 인스턴스마다 다른 ACL 파일을 사용할 수 있습니다.
ACL 파일은 사용자 정보가 플랫 파일 사용자 저장소에 있는지 또는 LDAP 사용자 저장소에 있는지 여부와 상관 없이 모두 사용할 수 있습니다.브로커는 클라이언트 응용 프로그램이 다음 작업 중 하나를 수행할 때 ACL 파일을 확인합니다.
연결 만들기
생성자 만들기
사용자 만들기
대기열 찾아보기
브로커는 ACL 파일을 확인하여 작업 수행 권한을 요청을 생성한 사용자에게 부여할지 해당 사용자가 속하는 그룹에 부여할지를 결정합니다.
ACL 파일을 편집한 경우 브로커가 다음에 파일을 검사하여 권한 부여를 확인할 때 새로운 설정이 적용됩니다. 파일을 편집한 후 브로커를 다시 시작할 필요가 없습니다.
ACL 파일은 인스턴스에 고유합니다. 브로커 인스턴스를 시작할 때마다 기본 파일 accesscontrol.properties가 인스턴스 디렉토리에 생성됩니다. 파일에 대한 경로 형식은 다음과 같습니다(부록 A, 플랫폼별 Message QueueTM 데이터 위치 참조).
…/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) 대상의 자동 생성은 허용했다면, 브로커는 물리적 대상이 없는 경우 물리적 대상을 만들기는 하지만 메시지를 그 물리적 대상으로 전달하지는 않습니다.