6장 액세스 제어 관리

디렉토리 내용에 대한 액세스를 제어하는 것은 디렉토리 보안에 있어 핵심적인 부분입니다. 이 장에서는 디렉토리에 액세스하는 사용자에게 부여할 권한을 결정하는 액세스 제어 명령(ACI)에 대해 설명합니다. Directory Server는 지정된 항목에 대한 특정 사용자의 유효 권한을 볼 수 있는 기능을 제공합니다. 이 기능을 사용하면 복잡하면서도 강력한 액세스 제어 기법을 간단하게 관리할 수 있습니다.

전체 보안 정책을 제공하는 액세스 제어 전략은 디렉토리 배포의 계획 단계에서 정의해야 합니다. 액세스 제어 전략을 계획하는 방법은 Directory Server Deployment Planning Guide의 7장, "Designing Access Control"을 참조하십시오.

액세스 제어 원칙

액세스를 정의하는 기법을 액세스 제어라고 합니다. 요청이 수신되면 서버는 바인드 작업 시 사용자가 제공한 인증 정보와 서버에 정의된 액세스 제어 명령(ACI)을 사용하여 디렉토리 정보에 대한 액세스를 허용하거나 거부합니다. 서버는 읽기, 쓰기, 검색 또는 비교 권한을 허용하거나 거부할 수 있습니다. 사용자에게 부여되는 권한 수준은 제공된 인증 정보에 따라 달라집니다.

액세스 제어를 사용하면 전체 디렉토리, 디렉토리의 하위 트리, 디렉토리의 특정 항목(구성 작업을 정의하는 항목 포함), 항목 속성의 특정 집합 또는 특정 항목 속성 값에 대한 액세스를 제어할 수 있습니다. 특정 사용자, 특정 그룹이나 역할에 속한 모든 사용자 또는 디렉토리에 있는 모든 사용자의 권한을 설정할 수 있습니다. 마지막으로 IP 주소나 DNS 이름으로 식별된 특정 클라이언트에 대해서도 액세스를 정의할 수 있습니다.

ACI 구조

액세스 제어 명령은 항목 속성으로 디렉토리에 저장됩니다. aci 속성은 작동 가능 속성으로, 항목의 객체 클래스에 정의되어 있지 않아도 디렉토리의 모든 항목에서 사용할 수 있습니다. 클라이언트로부터 LDAP 요청이 수신되면 Directory Server는 이 속성을 사용하여 부여하거나 거부할 권한을 평가합니다. 특별한 요청이 있을 경우 aci 속성은 ldapsearch 작업으로 반환됩니다.

ACI의 권한 부분과 바인드 규칙 부분은 한 쌍으로 설정되며 액세스 제어 규칙(ACR)이라고도 합니다. 대상에 대한 액세스 권한은 해당 규칙의 평가 결과에 따라 부여되거나 거부됩니다. 자세한 내용은 ACI 구문을 참조하십시오.

ACI 배치

ACI가 포함된 항목에 자식 항목이 없으면 해당 항목에만 ACI가 적용됩니다. 항목에 자식 항목이 있으면 해당 항목 및 모든 하위 항목에 ACI가 적용됩니다. 따라서 서버는 항목에 대한 액세스 권한을 평가할 때 요청된 항목과 루트 접미어의 기본 항목 사이에 있는 모든 항목에 대해 ACI를 확인합니다.

aci 속성은 여러 값을 가지므로 동일한 항목 또는 하위 트리에 대해 여러 개의 ACI를 정의할 수 있습니다.

해당 항목에 직접 적용되지는 않지만 하위 트리의 일부 또는 모든 항목에 적용되는 ACI를 항목에 작성할 수 있습니다. 이 경우, 실제로 디렉토리 트리의 하위 수준에 있는 항목에 적용되는 일반 ACI를 디렉토리 트리의 상위 수준에 배치할 수 있다는 이점이 있습니다. 예를 들어, organizationalUnit 항목이나 locality 항목 수준에서 inetorgperson 객체 클래스가 있는 항목을 대상으로 하는 ACI를 작성할 수 있습니다.

이 기능을 사용하면 상위 수준 분기점에 일반 규칙을 배치하여 디렉토리 트리의 ACI 수를 최소화할 수 있습니다. 특정 규칙의 범위를 제한하려면 최대한 리프 항목 가까이에 규칙을 배치해야 합니다.

ACI 평가

서버는 특정 항목에 대한 액세스 권한을 평가하기 위해 항목 루트 접미어의 기본 항목에 이르기까지 항목 자체 및 부모 항목에 있는 ACI 목록을 작성합니다. 평가 중에 서버는 이 순서대로 ACI를 처리합니다. ACI는 항목과 루트 접미어의 기본 항목 사이에 있는 모든 접미어 및 하위 접미어에서 평가되지만 다른 서버에 있는 연결 접미어에서는 평가되지 않습니다.


주	DN ""을 가진 루트 DSE 항목에 배치된 ACI는 해당 항목에만 적용됩니다.


주	디렉토리 관리자는 액세스 제어가 적용되지 않는 권한을 가진 유일한 사용자입니다. 클라이언트가 디렉토리 관리자로 디렉토리에 바인드하면 서버는 작업 수행 전에 ACI를 평가하지 않습니다. 따라서 디렉토리 관리자로 LDAP 작업을 수행하면 다른 사용자에 비해 성능이 훨씬 증가하기 때문에 항상 일반 사용자 아이디로 디렉토리 성능을 테스트해야 합니다.

항목에 적용되는 ACI가 없으면 기본적으로 디렉토리 관리자를 제외한 모든 사용자의 액세스가 거부됩니다. 사용자가 서버 항목에 액세스하려면 ACI에서 명시적으로 액세스 권한을 부여해야 합니다. 기본 ACI는 익명 읽기 액세스를 정의하며 사용자가 보안에 필요한 속성을 제외한 자신의 항목을 수정할 수 있도록 허용합니다. 자세한 내용은 기본 ACI를 참조하십시오.

서버는 대상 항목 가까이에 있는 ACI부터 먼저 처리하지만 항목에 적용되는 모든 ACI의 결과는 누적됩니다. 특정 ACI에서 액세스를 거부하지 않으면 ACI에서 부여한 액세스는 모두 허용됩니다. 목록 어디에 있건 동일 자원에 대해 액세스를 허용하는 ACI보다 액세스를 거부하는 ACI가 우선적으로 적용됩니다.

예를 들어, 디렉토리의 루트 수준에서 쓰기 권한을 거부하면 사용자는 자신에게 부여된 특정 권한에 관계 없이 디렉토리에 쓸 수 없습니다. 특정 사용자에게 디렉토리에 대한 쓰기 권한을 부여하려면 이 사용자가 포함되지 않도록 쓰기 권한에 대한 기존 거부 범위를 제한해야 합니다.

ACI 제한

디렉토리 서비스에 대한 액세스 제어 정책을 작성하는 경우 다음과 같은 제한에 주의해야 합니다.

CoS에서 생성된 속성은 일부 ACI 키워드에서만 사용할 수 있습니다. 특히 CoS에서 생성된 속성을 userattr 키워드 및 userdnattr 키워드와 함께 사용하면 액세스 제어 규칙이 작동하지 않습니다. 자세한 내용은 userattr 키워드 사용을 참조하십시오. CoS에 대한 자세한 내용은 5장, "Identity 및 역할 관리"를 참조하십시오.

액세스 제어 규칙은 항상 로컬 서버에서 평가됩니다. ACI 키워드에 사용된 LDAP URL에는 서버의 호스트 이름이나 포트 번호를 지정할 수 없습니다. 이 경우 LDAP URL이 적용되지 않습니다. 자세한 내용은 Directory Server Administration Reference의 6장, "LDAP URL Reference"를 참조하십시오.

프록시 권한을 부여하는 경우 사용자에게 디렉토리 관리자로서의 프록시 권한을 부여하거나 디렉토리 관리자에게 프록시 권한을 부여할 수 없습니다.

기본 ACI

Directory Server를 설치하면 구성 중에 지정한 루트 접미어에 다음과 같은 기본 ACI가 정의됩니다.

모든 사용자는 검색, 비교 및 읽기 작업을 위해 디렉토리에 대한 익명 액세스 권한을 갖습니다(userpassword 속성 제외).

바인드된 사용자는 디렉토리에 있는 자신의 항목을 수정할 수 있지만 삭제할 수는 없습니다. 또한 aci, nsroledn 및 passwordPolicySubentry 속성과 자원 제한 속성, 비밀번호 정책 상태 속성, 계정 잠금 상태 속성 등은 수정할 수 없습니다.

구성 관리자(기본적으로 uid=admin,ou=Administrators, ou=TopologyManagement,o=NetscapeRoot)는 프록시 권한을 제외한 모든 권한을 갖습니다.

구성 관리자 그룹의 모든 구성원은 프록시 권한을 제외한 모든 권한을 갖습니다.

디렉토리 관리자 그룹의 모든 구성원은 프록시 권한을 제외한 모든 권한을 갖습니다.

SIE 그룹의 모든 구성원은 프록시 권한을 제외한 모든 권한을 갖습니다. SIE 그룹은 관리 서버에서 이 디렉토리 서버 그룹의 관리자 그룹입니다.

디렉토리에 새 루트 접미어를 작성하면 해당 기본 항목에는 위에 열거된 기본 ACI(자체 수정 ACI 제외)가 포함됩니다. 보안을 강화하려면 콘솔에서 새 루트 접미어 작성에 설명된 것처럼 이 ACI를 추가해야 합니다.

관리 서버의 NetscapeRoot 하위 트리에는 자체 기본 ACI 집합이 있습니다.

다음 절에서는 이러한 기본 설정을 조직의 요구에 맞게 수정하는 방법에 대해 설명합니다.

ACI 구문

ACI는 다양한 변형이 가능한 복잡한 구조로 이루어져 있습니다. 콘솔 또는 명령줄에서 ACI를 작성하고 수정하는 경우 LDIF 형식의 ACI 구문을 명확히 이해해야 합니다. ACI 구문에 대해서는 다음 절에서 자세히 설명합니다.


팁	ACI는 매우 복잡하기 때문에 Directory Server 콘솔에서 모든 ACI를 시각적으로 편집할 수는 없습니다. 또한 다수의 디렉토리 항목에 대한 액세스 제어를 설정하는 경우 명령줄을 사용하는 것이 훨씬 빠릅니다. 따라서 ACI 구문을 명확히 이해해야만 효과적인 액세스 제어가 설정된 보안 디렉토리를 작성할 수 있습니다.

target은 액세스를 제어할 항목, 속성 또는 항목과 속성 집합을 지정합니다. 고유 이름이나 하나 이상의 속성, 또는 한 개의 LDAP 필터를 대상으로 지정할 수 있습니다. 대상은 선택 사항으로, 대상을 지정하지 않으면 ACI가 정의된 전체 항목과 모든 자식 항목에 해당 ACI가 적용됩니다.

version 3.0은 ACI 버전을 식별하는 필수 문자열입니다.

name은 ACI의 이름입니다. ACI를 식별하는 모든 문자열은 이름이 될 수 있습니다. ACI 이름은 필수이며 ACI의 결과를 설명하는 이름이어야 합니다.



팁	이름에 대한 제한은 없지만 ACI에 고유 이름을 사용하는 것이 좋습니다. 고유 이름을 지정하면 "유효 권한 보기" 컨트롤을 사용하여 적용된 ACI를 확인할 수 있습니다.

permission은 허용 또는 거부되는 권한(예: 읽기 권한이나 검색 권한)을 구체적으로 열거합니다.

bindRules는 액세스 권한을 부여 받기 위해 사용자가 제공해야 하는 자격 증명과 바인드 매개 변수를 지정합니다. 바인드 규칙은 사용자나 그룹 구성원 자격 또는 클라이언트의 연결 등록정보를 기준으로 할 수도 있습니다.

여러 개의 대상과 권한-바인드 규칙 쌍을 지정할 수 있으므로 대상으로 지정되는 항목과 속성을 모두 구체화하여 지정된 대상에 대해 다양한 액세스 제어를 효율적으로 설정할 수 있습니다. 예를 들면 다음과 같습니다.

aci: (target)...(target)(version 3.0;acl "name"; permission bindRule;
permission bindRule; ...; permission bindRule;)

aci: (target="ldap:///uid=bjensen,dc=example,dc=com"
(targetattr="*")(version 3.0; acl "example"; allow (write)
userdn="ldap:///self";)

이 예에서 ACI는 사용자 bjensen이 자신의 디렉토리 항목에 있는 모든 속성을 수정할 수 있는 권한이 있음을 나타냅니다.

다음 절에서는 ACI 각 부분의 구문에 대해 자세히 설명합니다.

대상 정의

대상은 ACI가 어디에 적용되는지 식별합니다. 클라이언트에서 항목의 속성에 대한 작업을 요청하면 서버는 ACI를 평가하여 이 작업을 허용해야 할지 거부해야 할지를 확인하기 위해 대상을 평가합니다. 대상을 지정하지 않으면 ACI는 aci 속성이 있는 항목과 하위 항목의 모든 속성에 적용됩니다.

keyword는 대상 유형을 나타냅니다. 표 6-1의 키워드는 다음과 같은 대상 유형을 정의합니다.

디렉토리 항목이나 하위 트리

항목 속성

LDAP 필터와 일치하는 항목이나 속성 집합

LDAP 필터와 일치하는 속성 값이나 값 조합

같음(=)은 대상이 expression에 지정된 객체임을 나타내며, 같지 않음(!=)은 대상이 expression에 지정된 객체가 아님을 나타냅니다.



주	targattrfilters 키워드에 대해서는 "같지 않음" 연산자를 사용할 수 없습니다.

expression은 키워드를 사용하여 대상을 식별하며, 현재 구현에서는 targetattr=*와 같은 표현식을 허용하지만 구문상 expression을 인용 부호("")로 묶어야 합니다. 그러나 이후 버전에서 구문 검사가 더 엄격해질 수 있으므로 항상 인용 부호를 사용해야 합니다.

표 6-1 LDIF target 키워드
키워드	유효한 표현식	와일드카드 허용 여부
target	ldap:///distinguished_name	예
targetattr	속성	예
targetfilter	LDAP_filter	예
targattrfilters	LDAP_operation:LDAP_filter	예

대상 디렉토리 항목 지정

특정 디렉토리 항목과 하위 항목을 대상으로 지정하려면 LDAP URL에서 DN과 target 키워드를 사용합니다. 지정된 DN은 ACI가 정의된 항목의 하위 트리에 위치해야 합니다. 대상 표현식 구문은 다음과 같습니다.

(target = "ldap:///distinguished_name")
(target != "ldap:///distinguished_name")

고유 이름은 ACI가 정의된 항목이 루트가 되는 하위 트리에 위치해야 합니다. 예를 들어, ou=People,dc=example,dc=com에 대한 ACI에서는 다음과 같은 대상을 사용할 수 있습니다.

DN에 와일드카드를 사용하여 LDAP URL과 일치하는 항목을 모두 대상으로 지정할 수도 있습니다. 다음은 와일드카드를 올바로 사용한 예입니다.


주	항목의 DN은 문자열 표현의 고유 이름이어야 합니다(RFC 2253). 따라서 쉼표와 같이 구문상 DN에 중요한 문자는 단일 역슬래시(\)를 사용하여 이스케이프해야 합니다. 예를 들면 다음과 같습니다. (target="ldap:///uid=cfuentes,o=Example Bolivia\, S.A.")

uid=*,ou=*,dc=example,dc=com에서와 같이 여러 개의 와일드카드를 사용할 수 있습니다. 이 예에서는 example.com 트리에서 uid 및 ou 속성이 포함된 고유 이름을 가진 모든 항목이 대상이 됩니다.

대상 속성 지정

디렉토리 항목을 대상으로 지정하는 것 이외에 대상 항목에 있는 하나 이상의 속성 또는 하나 이상의 속성을 제외한 모든 속성을 대상으로 지정할 수도 있습니다. 이 방법은 부분적인 항목 정보에 대한 액세스를 허용하거나 거부할 경우에 유용합니다. 예를 들어 정해진 항목의 이름, 성, 전화 번호 속성에 대해서만 액세스를 허용할 수 있습니다. 또는 개인 데이터와 같은 중요한 정보에 대한 액세스를 거부할 수 있습니다.


주	고유 이름의 접미어 부분에는 와일드카드를 사용할 수 없습니다. 즉, 디렉토리에 접미어 c=US와 c=GB를 사용한 경우에는 다음과 같은 대상을 사용하여 두 접미어를 참조할 수 없습니다. (target="ldap:///dc=example,c="). uid=bjensen,o=.com과 같은 대상을 사용할 수도 없습니다.

targetattr 규칙이 없으면 기본적으로 어떤 속성도 액세스할 수 없습니다. 모든 속성에 액세스하려면 targetattr="*"와 같이 규칙을 설정해야 합니다.

대상으로 지정한 속성이 대상 항목이나 하위 트리에 반드시 포함될 필요는 없지만 ACI는 이 속성이 포함되어 있을 때 적용됩니다. 대상으로 지정한 속성은 스키마에 정의하지 않아도 됩니다. 스키마 검사를 사용하지 않으면 데이터와 스키마를 가져오기 전에 액세스 제어 정책을 구현할 수 있습니다.

대상 속성을 지정하려면 targetattr 키워드를 사용하고 속성 이름을 지정합니다. targetattr 키워드에 사용되는 구문은 다음과 같습니다.

targetattr 키워드를 아래 구문으로 사용하면 여러 속성을 대상으로 지정할 수 있습니다.

(targetattr = "attribute1 || attribute2 ... || attributen")
(targetattr != "attribute1 || attribute2 ... || attributen")

예를 들어 항목의 이름, 성, uid 속성을 대상으로 지정하려면 다음과 같은 구문을 사용합니다.

대상 속성에는 지정된 속성의 하위 유형이 모두 포함됩니다. 예를 들어, (targetattr = "locality")는 locality;lang-fr도 대상으로 지정합니다. (targetattr = "locality;lang-fr-ca")와 같이 특별히 하위 유형을 대상으로 지정할 수도 있습니다.

targetattr 규칙에 와일드카드를 사용할 수도 있지만, 특별한 의미가 없으며 성능이 저하될 수 있으므로 사용하지 않는 것이 좋습니다.

대상 항목과 속성 모두 지정

기본적으로 targetattr 키워드가 포함된 ACI는 이 ACI가 위치해 있는 항목을 대상으로 지정합니다. 즉, 다음과 같은 ACI를 가정해 보십시오.

위의 ACI를 ou=Marketing, dc=example,dc=com 항목에 배치하면 전체 Marketing 하위 트리에 ACI가 적용됩니다. 하지만 다음과 같이 target 키워드를 사용하여 명시적으로 대상을 지정할 수도 있습니다.

aci: (target="ldap:///uid=*,ou=Marketing,dc=example,dc=com")
(targetattr="uid") (accessControlRules;)

target 키워드와 targetattr 키워드를 지정하는 순서는 관계가 없습니다.

LDAP 필터를 사용한 대상 항목 또는 속성 지정

LDAP 필터를 사용하여 특정 조건에 맞는 항목 집합을 대상으로 지정할 수 있습니다. 이렇게 하려면 targetfilter 키워드를 LDAP 필터와 함께 사용합니다. ACI가 포함된 항목의 하위 트리에서 필터와 일치하는 모든 항목에 ACI가 적용됩니다.

여기서 LDAPfilter는 표준 LDAP 검색 필터입니다. 필터 구문에 대한 자세한 내용은 LDAP 검색 필터를 참조하십시오.

예를 들어, 직원을 나타내는 모든 항목에 정규직이나 계약직 상태가 있고, 근무 시간을 나타내는 속성이 상근직 비율로 표시된다고 가정해 보십시오. 계약 직원이나 파트 타임 직원을 나타내는 모든 항목을 대상으로 지정하려면 다음과 같은 필터를 사용합니다.


주	ACI에서는 국가별 값에 대한 일치 규칙을 설명하는 필터 구문은 지원되지 않습니다. 예를 들어 다음과 같은 대상 필터는 잘못된 것입니다. (targetfilter = "(locality:fr:=<= Quebec)")

대상 필터는 모든 항목을 ACI의 대상으로 선택합니다. targetfilter 키워드와 targetattr 키워드를 결합하여 대상 항목에 포함된 속성의 부분 집합에 적용되는 ACI를 작성할 수 있습니다.

아래의 LDIF 예를 사용하면 Engineering Admins 그룹의 모든 구성원이 Engineering 업종에 속한 모든 항목의 departmentNumber 및 manager 속성을 수정할 수 있습니다. 이 예에서는 LDAP 필터링을 사용하여 businessCategory 속성이 Engineering으로 설정된 모든 항목을 선택합니다.

dn: dc=example,dc=com
objectClass:top
objectClass: organization
aci: (targetattr="departmentNumber || manager")
(targetfilter="(businessCategory=Engineering)")
(version 3.0; acl "eng-admins-write"; allow (write)
groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)

LDAP 필터를 사용한 대상 속성 값 지정

액세스 제어를 사용하여 특정 속성 값을 대상으로 지정할 수 있으므로 속성 값이 ACI에 정의된 조건에 부합되는 경우 속성에 대한 권한을 부여하거나 거부할 수 있습니다. 속성 값을 기준으로 액세스 권한을 부여하거나 거부하는 ACI를 값 기반 ACI라고 합니다.


팁	디렉토리에 분포된 속성과 항목을 대상으로 지정할 경우 LDAP 필터가 유용하긴 하지만 필터는 액세스가 관리되는 객체 이름을 직접 지정하지 않으므로 예측할 수 없는 결과가 발생하기도 합니다. 속성을 추가하거나 삭제하면 필터링된 ACI의 대상 항목 집합이 변경되므로 ACI에서 LDAP 필터를 사용하는 경우에는 ldapsearch 작업에 동일한 필터를 사용하여 필터가 올바른 항목과 속성을 대상으로 지정하는지 확인해야 합니다.

예를 들어, 조직의 모든 사용자에게 자신의 항목에 있는 nsRoleDN 속성을 수정할 수 있는 권한을 부여할 수 있습니다. 하지만 "최상위 수준의 관리자"와 같은 중요 역할은 자신에게 할당할 수 없도록 설정하려고 합니다. 이 경우 LDAP 필터를 사용하여 속성 값 조건을 만족하는지 검사할 수 있습니다.

값 기반 ACI를 작성하려면 targattrfilters 키워드를 다음과 같은 구문으로 사용해야 합니다.

(targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn,
del=attr1:F1 && attr2:F2 ... && attrn:Fn")

항목을 작성하는 경우 필터가 새 항목의 속성에 적용되면 해당 속성의 각 인스턴스가 필터를 만족해야 합니다. 항목을 삭제하는 경우에도 필터가 항목의 속성에 적용되면 해당 속성의 각 인스턴스가 필터를 만족해야 합니다.

항목을 수정하여 속성을 추가하는 경우 해당 속성에 적용되는 추가 필터를 만족해야 하고, 속성을 삭제하는 경우 해당 속성에 적용되는 삭제 필터를 만족해야 합니다. 항목의 개별 속성 값을 바꾸는 경우에는 추가 필터와 삭제 필터를 모두 만족해야 합니다.

(targattrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)")

이 필터를 사용하면 사용자가 superAdmin 역할을 제외한 모든 역할(nsRoleDN 속성)을 자신의 항목에 추가할 수 있으며 123 접두어가 있는 전화 번호를 추가할 수도 있습니다.

한 개의 디렉토리 항목을 대상으로 지정

한 개의 항목을 대상으로 지정하는 명시적인 방법은 없지만 다음과 같은 대체 방법을 사용할 수 있습니다.


주	Directory Server 콘솔에서 값 기반 ACI를 작성할 수는 없습니다.

targetfilter 키워드를 사용하여 원하는 항목에만 표시되는 속성 값을 지정할 수 있습니다. 예를 들어, Directory Server를 설치하는 동안 다음과 같은 ACI가 작성됩니다.

aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))
(version 3.0; acl "Default anonymous access";
allow (read, search) userdn="ldap:///anyone";)

이 ACI는 o 속성이 NetscapeRoot 값을 갖는 o=NetscapeRoot 항목에만 적용됩니다.

이러한 방법을 사용할 경우 나중에 디렉토리 트리가 변경되면 이에 따라 ACI를 수정해야 하는 단점이 있습니다.

매크로를 사용하여 대상 정의

매크로를 사용하여 ACI의 대상 부분에 DN을 지정함으로써 디렉토리에서 사용되는 ACI의 수를 최적화할 수 있습니다. 자세한 내용은 고급 액세스 제어: 매크로 ACI 사용을 참조하십시오.

권한 정의

권한은 허용 또는 거부되는 액세스 유형을 지정합니다. 디렉토리에서 특정 작업을 수행할 수 있는 권한을 허용하거나 거부할 수 있으며, 지정할 수 있는 다양한 작업도 권한이라고 합니다.

액세스 허용 또는 거부

디렉토리 트리에 대한 액세스 권한을 명시적으로 허용하거나 거부할 수 있습니다. 액세스를 허용하는 경우와 거부하는 경우에 대한 자세한 지침은 Directory Server Deployment Planning Guide의 7장, "Designing Access Control"을 참조하십시오.

권한 지정

권한은 사용자가 디렉토리 데이터에 대해 수행할 수 있는 특정 작업을 자세히 설명합니다. 모든 권한을 허용 또는 거부하거나 다음 중 하나 이상의 권한을 지정할 수 있습니다.

읽기. 사용자가 디렉토리 데이터를 읽을 수 있는지 여부를 나타냅니다. 이 권한은 검색 작업에만 적용됩니다.

쓰기. 사용자가 속성을 추가, 수정 또는 삭제하여 항목을 수정할 수 있는지 여부를 나타냅니다. 이 권한은 수정 작업과 modrdn 작업에 적용됩니다.

추가. 사용자가 항목을 작성할 수 있는지 여부를 나타냅니다. 이 권한은 추가 작업에만 적용됩니다.

삭제. 사용자가 항목을 삭제할 수 있는지 여부를 나타냅니다. 이 권한은 삭제 작업에만 적용됩니다.

검색. 사용자가 디렉토리 데이터를 검색할 수 있는지 여부를 나타냅니다. 사용자는 검색 및 읽기 권한이 있어야만 검색 결과의 일부로 반환된 데이터를 볼 수 있습니다. 이 권한은 검색 작업에만 적용됩니다.

비교. 사용자가 자신이 제공한 데이터와 디렉토리에 저장된 데이터를 비교할 수 있는지 여부를 나타냅니다. 비교 권한이 있을 경우 디렉토리에서 조회에 응답하여 성공 또는 실패 메시지를 반환하지만 사용자가 항목이나 속성 값을 볼 수는 없습니다. 이 권한은 비교 작업에만 적용됩니다.

자체 쓰기. 사용자가 대상 항목의 속성에 자신의 DN을 추가하거나 삭제할 수 있는지 여부를 나타냅니다. 이 속성의 구문은 "고유 이름"이어야 합니다. 이 권한은 그룹 관리에만 사용됩니다. 자체 쓰기는 프록시 인증과 함께 작동하여, 바인딩된 사용자의 DN이 아닌 프록시 DN을 그룹 항목에 추가하거나 삭제할 수 있는 권한을 부여합니다.

프록시. 지정된 DN이 다른 항목의 권한을 사용하여 대상에 액세스할 수 있는지 여부를 나타냅니다. 디렉토리 관리자 DN을 제외하고 디렉토리의 모든 사용자 DN을 사용한 프록시 액세스 권한을 부여할 수 있습니다. 디렉토리 관리자에게는 프록시 권한을 부여할 수 없습니다. 프록시 인증 ACI 예에 자세한 예가 나와 있습니다.

모두. 지정된 DN에 프록시 권한을 제외한 대상 항목에 대한 모든 권한(읽기, 쓰기, 검색, 삭제, 비교 및 자체 쓰기)이 있음을 나타냅니다.

권한은 서로 독립적으로 부여됩니다. 예를 들어, 추가 권한을 가진 사용자는 항목을 작성할 수 있지만 삭제 권한이 특별히 부여되지 않은 경우 항목을 삭제할 수는 없습니다. 따라서 디렉토리에 대한 액세스 제어 정책을 계획할 때는 사용자에게 합리적인 방식으로 권한을 부여해야 합니다. 예를 들어, 읽기 권한과 검색 권한을 부여하지 않고 쓰기 권한만 부여하는 것은 합리적이지 않습니다.

LDAP 작업에 필요한 권한

이 절에서는 사용자에게 허용하려는 LDAP 작업 유형에 따라 부여해야 하는 권한에 대해 설명합니다.

예를 통해 살펴보면 사용자가 디렉토리를 검색할 수 있도록 허용하기 위해 설정해야 하는 권한을 명확히 이해할 수 있습니다. 아래 검색을 가정해 보십시오.

ldapsearch -h host -p port -D "uid=bjensen,dc=example,dc=com" \
-w password -b "dc=example,dc=com" \
"(objectclass=*)" mail

bjensen 사용자에게 자신의 항목 검색을 위한 액세스 권한을 부여할 수 있는지 확인하려면 아래 ACI를 사용합니다.

aci: (targetattr = "mail")(version 3.0; acl "self access to
mail"; allow (read, search) userdn = "ldap:///self";)

이 ACI는 objectclass 속성에 대한 검색 권한을 bjensen에 부여하지 않기 때문에 빈 검색 결과 목록이 표시됩니다. 위에서 설명한 검색 작업이 성공하려면 ACI를 다음과 같이 수정해야 합니다.

aci: (targetattr = "mail || objectclass")(version 3.0; acl "self
access to mail"; allow (read, search) userdn = "ldap:///self";)

권한 구문

여기서 rights는 쉼표로 구분된 1-8자의 키워드 목록으로 각 키워드는 괄호로 묶여 있습니다. 유효한 키워드는 read, write, add, delete, search, compare, selfwrite, proxy 또는 all입니다.

아래 예에서는 바인드 규칙이 true일 경우 읽기, 검색 및 비교 액세스가 허용됩니다.

aci: (target="ldap:///dc=example,dc=com") (version 3.0;acl
"example"; allow (read, search, compare) bindRule;)

바인드 규칙

특정 작업의 경우 디렉토리에 정의된 ACI에 따라 디렉토리에 바인드해야 합니다. 바인딩이란 바인드 DN과 비밀번호(SSL을 사용하는 경우에는 인증서)를 제공하여 디렉토리에 로그인하거나 자체 인증하는 것을 의미합니다. 바인드 작업에 제공된 자격 증명과 바인드 환경에 따라 디렉토리에 대한 액세스의 허용 여부가 결정됩니다.

ACI에 설정된 각 권한에는 필수 인증서와 바인드 매개 변수를 자세히 설명하는 해당 바인드 규칙이 있습니다.

단순한 바인드 규칙은 디렉토리에 액세스하는 사람이 특정 그룹에 속해야 한다고 지정할 수 있습니다. 복잡한 바인드 규칙은 이 사람이 특정 그룹에 속해야 하며 오전 8시부터 오후 5시 사이에 특정 IP 주소의 시스템에서 로그인해야 한다고 지정할 수 있습니다.

바인드 규칙은 디렉토리에 액세스할 수 있는 사람, 액세스 시기 및 장소를 정의합니다. 보다 구체적으로, 바인드 규칙은 다음과 같은 항목을 지정할 수 있습니다.

또한 부울 연산자로 이러한 조건을 결합하여 복잡한 바인드 규칙을 구성할 수 있습니다. 자세한 내용은 부울 바인드 규칙 사용을 참조하십시오.

서버는 RFC 2251 Lightweight Directory Access Protocol (v3)에 설명된 것처럼 LDAP 필터 평가에 사용되는 논리와 유사한 3개 값 논리에 따라 ACI에 사용된 논리 표현식을 평가합니다. 즉, 자원 제한으로 인해 표현식 평가가 중단된 경우처럼 표현식의 구성 요소가 "정의되지 않음"으로 평가되어도 서버에서 이를 올바로 처리합니다. "정의되지 않음" 값이 복잡한 부울 표현식에서 발생했으므로 액세스 권한이 잘못 부여되지는 않습니다.

바인드 규칙 구문

액세스 허용 여부는 ACI의 바인드 규칙이 true인지 여부에 따라 결정됩니다. 바인드 규칙은 다음 두 가지 패턴 중 하나를 사용합니다.

여기서 같음(=)은 바인드 규칙이 true가 되려면 keyword와 expression이 일치해야 한다는 것을 나타내고, 같지 않음(!=)은 keyword와 expression이 일치하지 않아야 한다는 것을 나타냅니다.


주	timeofday 키워드는 부등식(<, <=, >, >=)도 지원합니다. 부등식은 이 키워드에서만 지원됩니다.

expression은 인용 부호("")로 묶고 세미콜론(;)으로 구분해야 합니다. 사용할 수 있는 표현식은 관련 keyword에 따라 달라집니다.

아래 표에는 각 키워드 및 관련 표현식이 나와 있으며 표현식에 와일드카드를 사용할 수 있는지 여부도 표시되어 있습니다.

표 6-2 LDIF 바인드 규칙 키워드
키워드	유효한 표현식	와일드카드 허용 여부
userdn	ldap:///distinguished_name ldap:///all ldap:///anyone ldap:///self ldap:///parent ldap:///suffix??sub?(filter)	예(DN에서만)
groupdn	[ldap:///DN]	아니요
roledn	[ldap:///DN]	아니요
userattr	attribute#bindType 또는 attribute#value	아니요
ip	IP_address	예
dns	DNS_host_name	예
dayofweek	sun mon tue wed thu fri sat	아니요
timeofday	0 - 2359	아니요
authmethod	none simple ssl sasl authentication_method	아니요

다음 절에서는 각 키워드의 바인드 규칙 구문에 대해 자세히 설명합니다.

사용자 액세스 정의 - userdn 키워드

사용자 액세스는 userdn 키워드를 사용하여 정의됩니다. userdn 키워드에는 다음 형식의 유효한 고유 이름이 하나 이상 있어야 합니다.

userdn = "ldap:///dn [|| ldap:///dn]..."
userdn != "ldap:///dn [|| ldap:///dn]..."

여기서 dn은 DN일 수도 있고 anyone, all, self 또는 parent 표현식 중 하나일 수도 있습니다. 표현식은 다음과 같은 사용자를 참조합니다.

userdn 키워드는 다음과 같은 형식의 LDAP 필터로 표현할 수도 있습니다.

익명 액세스(anyone 키워드)


주	쉼표와 같이 구문상 DN에 중요한 문자는 단일 역슬래시(\)를 사용하여 이스케이프해야 합니다.

디렉토리에 대한 익명 액세스를 부여하면 바인드 DN이나 비밀번호를 제공하지 않아도 바인드 상황에 관계 없이 모든 사람이 디렉토리에 액세스할 수 있습니다. 익명 액세스를 특정 유형의 액세스(예: 읽기 액세스 또는 검색 액세스)로 제한하거나 디렉토리의 개별 항목이나 특정 하위 트리로 제한할 수 있습니다. anyone 키워드를 사용한 익명 액세스는 인증된 모든 사용자의 액세스도 허용합니다.

예를 들어, 전체 example.com 트리에 대한 익명 읽기 및 검색 액세스를 허용하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (version 3.0; acl "anonymous-read-search";
allow (read, search) userdn = "ldap:///anyone";)

일반 액세스(all 키워드)

바인드 규칙을 사용하여 특정 권한이 디렉토리에 성공적으로 바인드한 모든 사람에게 적용됨을 나타낼 수 있습니다. 이 경우 all 키워드는 인증된 모든 사용자의 액세스를 허용하므로 익명 액세스를 방지하는 동시에 일반 액세스를 허용할 수 있습니다.

예를 들어, 모든 인증된 사용자에게 전체 트리에 대한 읽기 액세스 권한을 부여하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

자체 액세스(self 키워드)

사용자에게 자신의 항목에 대한 액세스 권한이 부여되거나 거부되도록 지정합니다. 이 경우 바인드 DN이 대상 항목의 DN과 일치하면 액세스 권한이 부여되거나 거부됩니다.

예를 들어, example.com 트리의 모든 사용자에게 userPassword 속성에 대한 쓰기 액세스 권한을 부여하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (targetattr = "userPassword") (version 3.0; acl
"modify own password"; allow (write) userdn = "ldap:///self";)

부모 액세스(parent 키워드)

바인드 DN이 대상 항목의 부모인 경우에만 사용자에게 항목에 대한 액세스 권한이 부여되거나 거부되도록 지정합니다. parent 키워드를 사용하려면 서버 콘솔에서 수동으로 ACI를 편집해야 합니다.

예를 들어, 사용자가 바인드 DN의 모든 자식 항목을 수정할 수 있게 하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

LDAP URL

다음과 같이 URL을 필터와 함께 사용하여 ACI에서 동적으로 사용자를 지정할 수 있습니다.

예를 들어, example.com 트리의 accounting 분기와 engineering 분기에 있는 모든 사용자는 다음 URL을 기준으로 대상 자원에 대한 액세스 권한이 동적으로 부여되거나 거부됩니다.


주	LDAP URL에 호스트 이름이나 포트 번호를 지정하지 마십시오. LDAP URL은 항상 로컬 서버에 적용됩니다.

LDAP URL에 대한 자세한 내용은 Directory Server Administration Reference의 6장, "LDAP URLs Reference"를 참조하십시오.

와일드카드

와일드카드 문자(*)를 사용하여 사용자 집합을 지정할 수도 있습니다. 예를 들어, 사용자 DN을 uid=b*,dc=example,dc=com으로 지정하면 바인드 DN이 b 문자로 시작하는 사용자에게만 설정된 권한을 기준으로 액세스 권한이 부여되거나 거부됩니다.

LDAP URL의 논리적 OR

사용자 접근에 대한 복잡한 규칙을 작성하려면 여러 개의 LDAP URL이나 키워드 표현식을 지정합니다. 예를 들면 다음과 같습니다.

사용자가 DN 패턴 중 하나를 사용하여 바인드하면 바인드 규칙은 true가 됩니다.

특정 LDAP URL 제외

같지 않음(!=) 연산자를 사용하여 특정 URL이나 DN을 제외하는 사용자 접근을 정의합니다. 예를 들면 다음과 같습니다.

클라이언트가 accounting 하위 트리에 있는 UID 기반의 고유 이름으로 바인드하지 않으면 바인드 규칙은 true가 됩니다. 이 바인드 규칙은 대상 항목이 디렉토리 트리에서 accounting 분기 이외의 위치에 있는 경우에만 적용됩니다.

그룹 액세스 정의 - groupdn 키워드

특정 그룹의 구성원이 대상 자원에 액세스하는 것을 그룹 액세스라고 합니다. 사용자가 특정 그룹에 속한 DN을 사용하여 바인드할 경우 대상 항목에 대한 액세스가 부여되거나 거부되도록 지정하려면 groupdn 키워드를 사용하여 그룹 액세스를 정의합니다.

groupdn 키워드에는 한 개 이상 그룹의 고유 이름이 다음과 같은 형식으로 필요합니다.

바인드 DN이 groupDNs으로 지정된 그룹에 속하면 바인드 규칙은 true가 됩니다. 다음 절에서는 groupdn 키워드를 사용한 예를 제공합니다.

단일 LDAP URL


주	쉼표와 같이 구문상 DN에 중요한 문자는 단일 역슬래시(\)를 사용하여 이스케이프해야 합니다.

바인드 DN이 Administrators 그룹에 속하면 바인드 규칙은 true가 됩니다. Administrators 그룹에 전체 디렉토리 트리에 대한 쓰기 권한을 부여하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (version 3.0; acl "Administrators-write"; allow (write)
groupdn="ldap:///cn=Administrators,dc=example,dc=com";)

LDAP URL의 논리적 OR

groupdn = "ldap:///cn=Administrators,dc=example,dc=com ||
ldap:///cn=Mail Administrators,dc=example,dc=com";

바인드 DN이 Administrators 그룹이나 Mail Administrators 그룹에 속하면 바인드 규칙은 true가 됩니다.

역할 액세스 정의 - roledn 키워드

특정 역할의 구성원이 대상 자원에 액세스하는 것을 역할 액세스라고 합니다. 사용자가 특정 역할에 속한 DN을 사용하여 바인드하는 경우 대상 항목에 대한 액세스 권한이 부여되거나 거부되도록 지정하려면 roledn 키워드를 사용하여 역할 액세스를 정의합니다.

roledn 키워드에는 다음 형식의 유효한 고유 이름이 하나 이상 있어야 합니다.

바인드 DN이 지정된 역할에 속하면 바인드 규칙은 true가 됩니다.


주	쉼표와 같이 구문상 DN에 중요한 문자는 단일 역슬래시(\)를 사용하여 이스케이프해야 합니다.

roledn 키워드는 groupdn 키워드와 동일한 구문으로 사용됩니다.

값 일치에 따른 액세스 정의

디렉토리에 바인드하는 데 사용되는 항목의 속성 값이 대상 항목의 속성 값과 일치하도록 지정하는 바인드 규칙을 설정할 수 있습니다.

예를 들어, 바인드 DN이 사용자 항목의 manager 속성에 있는 DN과 일치할 경우에만 ACI를 적용하도록 지정할 수 있습니다. 이 경우 사용자의 관리자만 항목에 액세스할 수 있습니다.

이 예는 DN 일치를 기준으로 하지만 바인드에 사용된 항목의 모든 속성을 대상 항목과 일치시킬 수 있습니다. 예를 들어, favoriteDrink 속성이 "beer"인 사용자가 동일한 favoriteDrink 값을 갖는 다른 사용자의 모든 항목을 읽을 수 있도록 허용하는 ACI를 작성할 수 있습니다.

userattr 키워드 사용

userattr 키워드를 사용하여 바인드에 사용된 항목과 대상 항목 간에 일치시킬 속성 값을 지정할 수 있습니다.

사용자 DN, 그룹 DN, 역할 DN이나 LDAP 필터 이외의 값이 필요한 속성 유형을 사용하는 경우 LDIF 구문은 다음과 같습니다.


주	서비스 클래스(CoS) 정의에서 생성된 속성은 userattr 키워드와 함께 사용할 수 없습니다. 이 경우 CoS에서 생성된 속성 값을 사용하는 바인드 규칙이 포함된 ACI가 작동하지 않습니다.

다음 절에는 userattr 키워드를 다양한 바인드 유형과 함께 사용하는 예를 소개합니다.

USERDN 바인드 유형을 사용한 예

사용자 DN을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

바인드 DN이 대상 항목의 manager 속성 값과 일치하면 바인드 규칙은 true가 됩니다. 이 기법을 사용하면 사용자의 관리자가 직원의 속성을 수정할 수 있습니다. 이 기법은 대상 항목의 manager 속성이 전체 DN으로 표시된 경우에만 작동합니다.

아래 예에서는 관리자에게 직원 항목에 대한 전체 액세스 권한을 부여합니다.

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0;acl "manager-write";
allow (all) userattr = "manager#USERDN";)

GROUPDN 바인드 유형을 사용한 예

그룹 DN을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

바인드 DN이 대상 항목의 owner 속성에 지정된 그룹의 구성원이면 바인드 규칙은 true가 됩니다. 예를 들어, 이 기법을 사용하여 그룹이 직원의 상태 정보를 관리하도록 허용할 수 있습니다. 속성에 그룹 항목의 DN이 포함되어 있으면 owner 이외의 속성을 사용할 수도 있습니다.

사용자가 가리키는 그룹은 동적 그룹일 수 있으며, 그룹 DN은 디렉토리의 모든 접미어에 위치할 수 있습니다. 하지만 서버에서 이 유형의 ACI를 평가하려면 많은 자원이 필요합니다.

대상 항목과 동일한 접미어에 있는 정적 그룹을 사용하는 경우 다음과 같은 표현식을 사용할 수 있습니다.

이 예에서 그룹 항목은 dc=example,dc=com 접미어에 있습니다. 이 유형의 구문은 이전 예보다 서버에서 빨리 처리될 수 있습니다.

ROLEDN 바인드 유형을 사용한 예

역할 DN을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

바인드 DN이 대상 항목의 exampleEmployeeReportsTo 속성에 지정된 역할에 속하면 바인드 규칙은 true가 됩니다. 예를 들어, 회사의 모든 관리자에 대해 중첩된 역할을 작성할 경우 이 기법을 사용하여 모든 수준의 관리자가 자신보다 등급이 낮은 직원에 대한 정보에 액세스할 수 있도록 액세스 권한을 부여할 수 있습니다.

역할 DN은 디렉토리의 모든 접미어에 위치할 수 있습니다. 또한 필터링된 역할을 사용하는 경우 이 유형의 ACI를 평가하려면 많은 서버 자원이 필요합니다.

LDAPURL 바인드 유형을 사용한 예

LDAP 필터를 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

바인드 DN이 대상 항목의 myfilter 속성에 지정된 필터와 일치하면 바인드 규칙은 true가 됩니다. myfilter 속성을 LDAP 필터가 포함된 속성으로 바꿀 수 있습니다.

속성 값이 있는 예

속성 값을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

바인드 DN과 대상 DN에 포함된 favoriteDrink 속성 값이 Beer이면 바인드 규칙은 true가 됩니다.

상속 기능과 함께 userattr 키워드 사용

userattr 키워드를 사용하여 바인드에 사용된 항목을 대상 항목과 연결하면 ACI는 지정된 대상에만 적용되고 하위 항목에는 적용되지 않습니다. ACI의 응용을 대상 항목보다 몇 수준 아래까지 확장하려는 경우 parent 키워드를 사용하고 ACI를 상속할 대상 아래의 수준 수를 지정합니다.

userattr 키워드를 parent 키워드와 함께 사용하는 구문은 다음과 같습니다.

바인드 DN이 대상 항목의 manager 속성과 일치하면 이 바인드 규칙은 true가 됩니다. 바인드 규칙이 true로 평가될 때 부여된 권한은 대상 항목 및 바로 아래의 모든 항목에 적용됩니다.

userattr 상속을 사용한 예

아래 그림의 예에서는 bjensen 사용자가 cn=Profiles 항목 및 cn=mail과 cn=news가 포함된 첫 수준의 자식 항목을 읽고 검색할 수 있음을 나타냅니다.

이 예에서 상속을 사용하지 않은 경우 동일한 결과를 얻으려면 다음 중 하나를 수행해야 합니다.

userattr 키워드를 사용한 추가 권한 부여

userattr 키워드를 all 또는 add 권한과 함께 사용하면 서버가 예상과 달리 작동할 수 있습니다. 일반적으로 Directory Server는 디렉토리에 새 항목을 작성할 때 부모 항목이 아닌 작성되는 항목에 대한 액세스 권한을 평가합니다. 하지만 userattr 키워드를 사용하는 ACI의 경우 이 동작으로 인해 보안 허점이 생길 수 있으므로 정상적인 서버 동작이 수정됩니다.

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "manager-write"; allow (all)
userattr = "manager#USERDN";)

이 ACI는 관리자에게 보고하는 직원 항목에 대한 모든 권한을 관리자에게 부여합니다. 하지만 이 ACI 유형을 사용할 경우 작성되는 항목에 대해서만 액세스 권한이 평가되므로 모든 직원이 자신의 DN으로 설정된 manager 속성을 가진 항목을 작성할 수도 있습니다. 예를 들어, 불만을 품은 직원인 Joe(cn=Joe,ou=eng,dc=example,dc=com)는 트리의 Human Resources 분기에 항목을 작성하여 Human Resources 직원에게 부여된 권한을 사용(또는 남용)할 수 있습니다.

dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com
objectclass: top
...
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=example,dc=com

이러한 보안 문제를 방지하기 위해 ACI 평가 프로세스는 수준 0, 즉 항목 자체에 대한 추가 권한을 부여하지 않습니다. 하지만 parent 키워드를 사용하여 기존 항목 아래에 추가 권한을 부여할 수 있습니다. 이 경우 추가 권한에 대한 부모 아래의 수준 수를 지정해야 합니다. 예를 들어, 아래 ACI에서는 manager 속성이 바인드 DN과 일치하는 dc=example,dc=com의 모든 항목에 자식 항목을 추가할 수 있습니다.

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "parent-access"; allow (add)
userattr = "parent[0,1].manager#USERDN";)

이 ACI를 사용하면 바인드 DN이 부모 항목의 manager 속성과 일치하는 사용자에게만 추가 권한이 부여됩니다.

특정 IP 주소로부터의 액세스 정의

바인드 규칙을 사용하여 바인드 작업이 반드시 특정 IP 주소로부터 시작되도록 지정할 수 있습니다. 이 액세스 정의는 주로 특정 시스템이나 네트워크 도메인에서 모든 디렉토리 업데이트를 수행하도록 강제하는 데 사용됩니다.

IP 주소를 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

IPaddressList는 다음 중 하나 이상의 요소가 쉼표로 구분된 목록입니다.

디렉토리에 액세스하는 클라이언트가 지정된 IP 주소에 위치해 있으면 바인드 규칙은 true가 됩니다. 이 기법은 특정 서브넷 또는 시스템으로부터의 특정 디렉토리 액세스만 허용하는 경우에 유용합니다. 사용자가 인증하는 IP 주소는 위조될 수 있으므로 신뢰할 수 없습니다. 이 정보에만 기반하여 ACI를 작성하지 마십시오.

서버 콘솔의 액세스 제어 편집기를 사용하여 ACI가 적용되는 특정 시스템을 정의할 수 있습니다. 자세한 내용은 콘솔에서 ACI 작성을 참조하십시오.

특정 도메인으로부터의 액세스 정의

바인드 규칙은 바인드 작업이 반드시 특정 도메인이나 호스트 시스템으로부터 시작되도록 지정할 수 있습니다. 이 액세스 정의는 주로 특정 시스템이나 네트워크 도메인에서 모든 디렉토리 업데이트를 수행하도록 강제하는 데 사용됩니다.

DNS 호스트 이름을 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.


주의	dns 키워드를 사용하려면 시스템에서 DNS를 이름 지정 서비스로 사용해야 합니다. DNS를 이름 지정 서비스로 사용하지 않는 경우에는 ip 키워드를 사용해야 합니다.

dns 키워드에는 전체 DNS 도메인 이름을 지정해야 합니다. 도메인을 지정하지 않고 호스트에 대한 액세스 권한을 부여하면 보안 문제가 발생할 수 있습니다. 예를 들어, 아래 표현식은 사용할 수는 있지만 바람직하지 않습니다.

dns 키워드에는 와일드카드를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

디렉토리에 액세스하는 클라이언트가 지정된 도메인에 위치해 있으면 바인드 규칙은 true가 됩니다. 이 기법은 특정 도메인으로부터의 액세스만 허용하는 경우에 유용합니다. 시스템에서 DNS 이외의 이름 지정 서비스를 사용하면 와일드카드는 작동하지 않습니다. 이 경우 액세스를 특정 도메인으로 제한하려면 특정 IP 주소로부터의 액세스 정의에 설명된 것처럼 ip 키워드를 사용합니다.

특정 시간 또는 요일의 액세스 정의

특정 시간이나 특정 요일에만 바인드할 수 있도록 바인드 규칙을 지정할 수 있습니다. 예를 들어, 월요일부터 금요일까지 오전 8시와 오후 5시 사이에만 액세스를 허용하는 규칙을 설정할 수 있습니다. 액세스 권한 평가에 사용되는 시간은 클라이언트 시간이 아닌 디렉토리 서버 시간입니다.

시간을 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

여기서 operator는 같음(=), 같지 않음(!=), 보다 큼(>), 크거나 같음(>=), 보다 작음(<), 작거나 같음(<=) 중 하나입니다. time은 24시간 시계의 시간과 분을 나타내는 4자리로 표현됩니다(0 - 2359). 예를 들면 다음과 같습니다.

timeofday = "1200";은 시스템 클럭이 정오를 가리키는 1분 동안 클라이언트가 디렉토리에 액세스할 때 true가 됩니다.

timeofday != "0100";은 오전 1시 이외의 시간에 액세스할 때 true가 됩니다.

timeofday > "0800";은 오전 8:01부터 오후 11:59까지의 시간에 액세스할 때 true가 됩니다.

timeofday >= "0800";은 오전 8:00부터 오후 11:59까지의 시간에 액세스할 때 true가 됩니다.

timeofday < "1800";은 자정 12:00부터 오후 5:59까지의 시간에 액세스할 때 true가 됩니다.



주	timeofday 및 dayofweek 바인드 규칙의 평가에 사용되는 시간과 날짜는 클라이언트 시간이 아닌 디렉토리 서버 시간입니다.

요일을 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

dayofweek 키워드에는 요일을 나타내는 3자의 영문 약어(sun, mon, tue, wed, thu, fri, sat)를 지정합니다. 액세스를 부여하려는 요일을 모두 지정합니다. 예를 들면 다음과 같습니다.

열거된 요일 중 하나에 디렉토리를 액세스하면 바인드 규칙은 true가 됩니다.

인증 방법에 따른 액세스 정의

클라이언트가 특정 인증 방법을 사용하여 디렉토리에 바인드하도록 바인드 규칙을 설정할 수 있습니다. 사용할 수 있는 인증 방법은 다음과 같습니다.

인증 기반의 바인드 규칙은 액세스 제어 편집기에서 설정할 수 없습니다.

인증 방법에 따라 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

여기서 authentication_method는 none, simple, ssl 또는 sasl sasl_mechanism입니다. 예를 들면 다음과 같습니다.

예

부울 바인드 규칙 사용

부울 연산자인 AND, OR, NOT을 사용하여 세부적인 액세스 규칙을 설정하는 복잡한 바인드 규칙을 작성할 수 있습니다. 서버 콘솔에서는 부울 바인드 규칙이 아닌 LDIF 명령문을 작성해야 합니다.

예를 들어, 바인드 DN이 administrators 그룹이나 mail administrators 그룹 중 하나의 구성원이고 클라이언트가 example.com 도메인에서 실행되면 아래 바인드 규칙은 true가 됩니다.

(groupdn = "ldap:///cn=administrators,dc=example,dc=com" or
groupdn = "ldap:///cn=mail administrators,dc=example,dc=com" and
dns = "*.example.com";)

뒤에 있는 세미콜론(;)은 필수 구분 기호로 최종 바인드 규칙 뒤에 반드시 입력해야 합니다.

부울 표현식은 왼쪽에서 오른쪽으로 평가하기 때문에 첫 번째 경우에서는 바인드 규칙 A를 평가한 후 바인드 규칙 B를 평가하고, 두 번째 경우에서는 바인드 규칙 B를 평가한 후 바인드 규칙 A를 평가합니다.

하지만 부울 연산자 OR과 AND를 평가하기 전에 부울 연산자 NOT을 먼저 평가합니다. 아래의 예를 가정해 보십시오.

이 경우에는 왼쪽에서 오른쪽으로 평가한다는 규칙에 위배되지만 바인드 규칙 B를 먼저 평가한 후에 바인드 규칙 A를 평가합니다.

명령줄에서 ACI 작성

LDIF 명령문을 사용하여 수동으로 액세스 제어 명령을 작성한 다음 ldapmodify 명령을 사용하여 디렉토리 트리에 추가할 수 있습니다. ACI 값은 매우 복잡할 수 있으므로 기존 값을 보고 이를 복사하여 새 값을 작성하는 것이 좋습니다.

aci 속성 값 보기

ACI는 하나 이상의 aci 속성 값으로 항목에 저장됩니다. aci 속성은 디렉토리 사용자가 읽고 수정할 수 있는 여러 값을 갖는 작동 가능 속성으로, 이 속성 자체도 ACI로 보호해야 합니다. 대체로 관리자 사용자는 aci 속성에 대한 전체 액세스 권한을 가지며 다음 중 한 가지 방법으로 속성 값을 볼 수 있습니다.

일반 편집기에서 다른 값과 같은 방식으로 aci 속성 값을 볼 수 있습니다. Directory Server 콘솔의 최상위 수준 디렉토리 탭에서 ACI가 있는 항목을 마우스 오른쪽 버튼으로 누르고 일반 편집기로 편집 메뉴 항목을 선택합니다. 하지만 aci 값은 대체로 긴 문자열이기 때문에 이 대화 상자에서 보고 편집하기는 어렵습니다.

이 경우에는 디렉토리 트리에서 해당 항목을 마우스 오른쪽 버튼으로 누르고 액세스 권한 설정 메뉴 항목을 선택하여 액세스 제어 편집기를 실행할 수 있습니다. ACI 를 선택하고 편집을 누른 다음 수동으로 편집을 눌러 해당 aci 값을 표시합니다. ACI 수동 편집기와 시각 편집기를 전환하여 aci 값 구문을 구성과 비교할 수 있습니다.

사용 중인 운영 체제에 따라 일반 편집기나 수동 액세스 제어 편집기에서 aci 값을 복사하여 LDIF 파일에 붙여넣을 수 있습니다. 관리자 사용자는 아래의 ldapsearch 명령을 실행하여 항목의 aci 속성을 볼 수도 있습니다.

ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
-b entryDN -s base "(objectclass=*)" aci

결과는 LDIF 텍스트로 표시되며, 이 텍스트를 새 LDIF ACI 정의에 복사하여 편집할 수 있습니다. ACI 값이 긴 문자열이기 때문에 ldapsearch 작업의 출력은 여러 줄에 걸쳐 표시되며, 첫 칸의 공백으로 연속된 줄을 나타냅니다. 이를 고려해서 LDIF 출력을 복사하여 붙여넣습니다.


주	aci 값에 따라 부여되거나 거부되는 권한을 확인하려면 유효 권한 보기를 참조하십시오.

콘솔에서 ACI 작성

디렉토리에서 aci 속성이 있는 항목을 표시하도록 Directory Server 콘솔을 구성할 수 있습니다. 이 디스플레이를 전환하려면 보기 > 표시 > ACI 개수 메뉴 항목을 선택하거나 선택 취소합니다. 최상위 수준 디렉토리 탭에 열거된 각 항목 뒤에 해당 aci 속성에 정의된 ACI 수가 표시됩니다. 그런 후에 Directory Server 콘솔을 사용하여 디렉토리에 대한 액세스 제어 명령을 보거나 작성하고 편집 및 삭제할 수 있습니다.

Directory Server 보안 정책에서 일반적으로 사용되는 액세스 제어 규칙 모음과 Directory Server 콘솔을 사용하여 액세스 제어 규칙을 작성하는 단계별 지침은 액세스 제어 사용 예를 참조하십시오.

일부 복잡한 ACI는 시각적 편집 모드의 액세스 제어 편집기에서 구성할 수 없습니다. 특히 액세스 제어 편집기에서 다음과 같은 작업은 수행할 수 없습니다.

항목의 ACI 보기


팁	액세스 제어 편집기에서 수동으로 편집 버튼을 클릭하면 언제든지 그래픽 인터페이스를 통해 변경한 사항을 LDIF 표시로 확인할 수 있습니다.

Directory Server 콘솔의 최상위 수준 디렉토리 탭에서 디렉토리 트리를 탐색하여 액세스 제어를 설정할 항목을 표시합니다. ACI를 편집하려면 디렉토리 관리자(directory administrator) 또는 디렉토리 관리자(directory manager) 권한이 있어야 합니다.

항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택합니다. 또는 항목을 왼쪽 마우스 버튼으로 눌러 선택한 다음 객체 메뉴에서 액세스 권한 설정을 선택합니다.

아래 그림과 같이 액세스 제어 관리 대화 상자가 표시됩니다. 이 대화 상자에는 선택한 항목에 정의된 모든 ACI에 대한 설명이 표시되며 ACI를 편집하거나 제거하고 새 ACI를 작성할 수 있습니다.

그림 6-2 액세스 제어 관리 대화 상자
ou=People,dc=example,dc=com에 대한 액세스 제어 관리 창 및 이 항목에서 정의된 ACI의 설명 문자열 목록

상속된 ACI 표시 확인란을 선택하면 선택한 항목의 부모에 의해 정의된 ACI와 선택한 항목에 적용되는 ACI가 모두 표시됩니다. 상속된 ACI는 편집하거나 제거할 수 없으므로 해당 ACI가 정의된 항목에서 관리해야 합니다.

선택한 객체와 전체 하위 트리에 대한 새 액세스 권한을 정의하려면 새로 만들기를 누릅니다. 그림 6-3과 같이 ACI 편집기가 표시됩니다.

그림 6-3 ACI 편집기 대화 상자
ou=People,dc=example,dc=com에 대한 ACI 편집 창 및 ACI를 정의하는 그래픽 인터페이스

이 대화 상자의 맨 위에 있는 ACI 이름은 ACI에 대한 설명으로 액세스 제어 관리 대화 상자에 표시됩니다. ACI를 설명하는 이름을 지정하면 디렉토리에서, 특히 리프 항목에서 상속된 ACI를 볼 때 쉽게 ACI를 관리할 수 있습니다.

액세스 제어 편집기의 탭을 사용하면 액세스 권한이 부여되거나 거부된 사용자, 액세스 중이거나 액세스가 제한된 대상, 허용된 호스트 이름 및 작동 시간과 같은 고급 매개 변수를 지정할 수 있습니다. 액세스 제어 탭의 개별 필드에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

ACI 편집기의 탭은 ACI 값의 내용을 그래픽으로 표시합니다. 텍스트로 ACI 값을 보고 편집하려면 수동으로 편집을 누릅니다. 텍스트 편집기에서는 탭에서 정의할 수 없는 고급 ACI를 정의할 수 있습니다. 하지만 ACI 값을 편집한 후에는 고급 기능을 사용하지 않더라도 더 이상 시각적으로 ACI를 편집할 수 없습니다.

새 ACI 작성

액세스 제어 편집기를 표시합니다.

이 작업에 대해서는 항목의 ACI 보기에서 설명합니다.

그림 6-3과 다르게 표시되면 시각적으로 편집 버튼을 누릅니다.

ACI 이름 텍스트 상자에 이름을 입력하여 ACI를 지정합니다.

ACI를 고유하게 식별하는 문자열을 이름으로 사용할 수 있습니다. 이름을 입력하지 않으면 서버는 unnamed ACI를 사용합니다.

사용자/그룹 탭에서 모든 사용자를 강조 표시하거나 추가 버튼을 눌러 디렉토리에서 추가할 사용자를 검색하여 액세스 권한을 부여할 사용자를 선택합니다.

사용자 및 그룹 추가 창에서 다음을 수행합니다.

드롭다운 목록에서 검색 영역을 선택하고 검색 필드에 검색 문자열을 입력한 다음 검색 버튼을 누릅니다.

아래 목록에 검색 결과가 표시됩니다.

검색 결과 목록에서 원하는 항목을 강조 표시한 다음 추가 버튼을 눌러 액세스 권한이 있는 항목 목록에 추가합니다.

확인을 눌러 사용자 및 그룹 추가 창을 닫습니다.

이제 선택한 항목이 ACI 편집기의 사용자/그룹 탭에 표시됩니다.

액세스 제어 편집기에서 권한 탭을 누르고 확인란을 사용하여 부여할 권한을 선택합니다.

대상 탭을 누른 다음 이 항목을 눌러 ACI 대상 노드를 표시합니다.

대상 DN 값을 변경할 수는 있지만 새 DN은 선택한 항목의 직접 또는 간접 자식이어야 합니다.

이 노드의 하위 트리에 있는 일부 항목에만 ACI를 적용하려면 하위 항목의 필터 필드에 필터를 입력해야 합니다.

또한 속성 목록에서 대상 속성을 선택하면 특정 속성에만 ACI가 적용되도록 범위를 제한할 수 있습니다.

호스트 탭을 누른 다음 추가 버튼을 눌러 호스트 필터 추가 대화 상자를 표시합니다.

호스트 이름이나 IP 주소를 지정할 수 있습니다. IP 주소를 지정할 경우 와일드카드 문자(*)를 사용할 수 있습니다.

시간 탭을 눌러 액세스 허용 시간을 나타내는 테이블을 표시합니다.

기본적으로 항상 액세스가 허용됩니다. 테이블을 누른 상태에서 커서를 끌어 액세스 시간을 변경할 수 있습니다. 시간 블록을 개별적으로 선택할 수는 없습니다.

ACI 편집이 끝나면 확인을 누릅니다.

ACI 편집기가 닫히고 ACI 관리자 창에 새 ACI가 표시됩니다.



주	ACI 작성 중에 언제든지 수동으로 편집 버튼을 눌러 입력 내용에 해당하는 LDIF 명령문을 표시할 수 있습니다. 이 명령문을 수정할 수는 있지만 변경 사항이 그래픽 인터페이스에 항상 표시되는 것은 아닙니다.

ACI 편집

디렉토리 탭의 하위 트리에서 최상위 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택합니다.

액세스 제어 관리자 창이 표시됩니다. 이 창에는 해당 항목에 속하는 ACI 목록이 포함되어 있습니다.

액세스 제어 관리자 창에서 편집할 ACI를 강조 표시한 다음 편집을 누릅니다.

액세스 제어 편집기가 표시됩니다. 이 대화 상자를 사용하여 편집할 수 있는 정보에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

액세스 제어 편집기의 여러 탭에서 원하는 항목을 변경합니다.

ACI 편집이 끝나면 확인을 누릅니다.

ACI 편집기가 닫히고 ACI 관리자 창에 수정된 ACI가 표시됩니다.

ACI 삭제

액세스 제어 사용 예

이 절에서는 가상의 ISP 업체인 example.com에서 액세스 제어 정책을 구현하는 예를 제공합니다. 모든 예는 콘솔 및 LDIF 파일을 사용하여 지정된 작업을 수행하는 방법에 대해 설명합니다.

example.com은 웹 호스팅 서비스와 인터넷 액세스를 제공하며 웹 호스팅 서비스의 일부로 클라이언트 기업의 디렉토리를 호스팅합니다. example.com은 실제로 두 개 중소 기업(Company333과 Company999)의 디렉토리를 호스팅하고 있으며 일부 관리 작업도 수행합니다. 또한 다수의 개인 가입자에게 인터넷 액세스를 제공합니다.

example.com에서 적용하려는 액세스 제어 규칙은 다음과 같습니다.

example.com 직원들에게 전체 example.com 트리를 읽고, 검색 및 비교할 수 있는 익명 액세스 권한 부여(익명 액세스 부여 참조)

example.com 직원들에게 homeTelephoneNumber, homeAddress 등의 개인 정보에 대한 쓰기 권한 부여(개인 항목에 대한 쓰기 액세스 권한 부여 참조)

example.com 직원들에게 중요한 특정 역할을 제외한 모든 역할을 자신의 항목에 추가할 수 있는 권한 부여(중요 역할에 대한 액세스 제한 참조)

example.com Human Resources 그룹에 People 분기의 항목에 대한 모든 권한 부여(그룹에 접미어에 대한 전체 액세스 권한 부여 참조)

example.com 직원들에게 디렉토리의 Social Committee 분기에 그룹 항목을 작성할 수 있는 권한과 소유한 그룹 항목을 삭제할 수 있는 권한 부여(그룹 항목 추가 및 삭제 권한 부여 참조)

example.com 직원들에게 디렉토리의 Social Committee 분기의 그룹 항목에 자신을 추가할 수 있는 권한 부여(사용자가 그룹에 자신을 추가 또는 제거할 수 있도록 허용 참조)

SSL 인증, 시간 및 날짜 제한, 지정된 위치와 같은 특정 조건을 사용하여 Company333 및 Company999의 디렉토리 관리자(역할)에게 디렉토리 트리의 해당 분기에 대한 액세스 권한 부여(그룹이나 역할에 조건부 액세스 권한 부여 참조)

개인 가입자에게 자신의 항목에 대한 액세스 권한 부여(개인 항목에 대한 쓰기 액세스 권한 부여 참조)

개인 가입자가 자신의 항목에 있는 결제 정보에 액세스하지 못하도록 거부(액세스 거부 참조)

특별히 목록에 표시하지 않도록 요청한 가입자를 제외하고 개인 가입자 하위 트리에 대한 익명 액세스 권한 부여. 디렉토리에서 이 부분은 방화벽 외부의 슬레이브 서버로 하루에 한 번 업데이트될 수 있습니다. 익명 액세스 부여 및 필터링을 사용한 대상 설정을 참조하십시오.

익명 액세스 부여

대부분의 디렉토리는 읽기, 검색 또는 비교를 위해 하나 이상의 접미어에 익명으로 액세스할 수 있도록 허용합니다. 예를 들어, 전화 번호부 등 직원들이 검색할 수 있는 인사 디렉토리를 실행하는 경우 이러한 권한을 설정할 수 있습니다. example.com 내부의 경우가 이에 해당하며 ACI "Anonymous example.com" 예에서 자세히 설명합니다.

또한 example.com은 ISP로서 누구든지 이용할 수 있는 공공 전화 번호부를 작성하여 모든 가입자의 연락처 정보를 제공하려고 합니다. 여기에 대해서는 ACI "Anonymous World" 예에서 설명합니다.

ACI "Anonymous example.com"

example.com 직원들에게 전체 example.com 트리에 대한 읽기, 검색 및 비교 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous
example"; allow (read, search, compare)
userdn= "ldap:///anyone" and dns="*.example.com";)

이 예에서는 dc=example,dc=com 항목에 aci를 추가한다고 가정합니다. userPassword 속성은 ACI 범위에서 제외됩니다.

디렉토리 탭의 왼쪽 탐색 트리에서 example.com 노드를 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택하여 액세스 제어 관리자를 표시합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Anonymous example.com"을 입력합니다. 액세스 권한이 부여된 사용자 목록에 모든 사용자가 표시되어 있는지 확인합니다.

권한 탭에서 읽기, 비교 및 검색 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

대상 탭에서 이 항목을 눌러 대상 디렉토리 항목 필드에 dc=example,dc=com 접미어를 표시합니다. 속성 테이블에서 userPassword 속성을 찾아 해당 확인란을 선택 취소합니다.

다른 확인란은 모두 선택해야 합니다. 간편하게 이 작업을 수행하려면 이름 머리글을 눌러 속성 목록을 알파벳순으로 정렬합니다.

호스트 탭에서 추가를 누른 다음 DNS 호스트 필터 필드에 *.example.com을 입력합니다. 확인을 눌러 대화 상자를 닫습니다.

액세스 제어 편집기 창에서 확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

ACI "Anonymous World"

모든 사람에게 개인 가입자 하위 트리에 대한 읽기 및 검색 권한을 부여하는 동시에 목록에 없는 가입자 정보에 대한 액세스를 거부하려면 LDIF로 아래 명령문을 작성합니다.

aci: (targetfilter= "(!(unlistedSubscriber=yes))")
(targetattr="homePostalAddress || homePhone || mail")
(version 3.0; acl "Anonymous World"; allow (read, search)
userdn="ldap:///anyone";)

이 예에서는 ou=subscribers,dc=example, dc=com 항목에 ACI를 추가한다고 가정합니다. 또한 모든 가입자 항목에 예나 아니요로 설정된 unlistedSubscriber 속성이 있다고 가정합니다. 대상 정의는 이 속성 값을 기준으로 목록에 없는 가입자를 필터링합니다. 필터 정의에 대한 자세한 내용은 필터링을 사용한 대상 설정을 참조하십시오.

디렉토리 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Subscribers 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택하여 액세스 제어 관리자를 표시합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Anonymous World"를 입력합니다. 액세스 권한이 부여된 사용자 목록에 모든 사용자가 표시되어 있는지 확인합니다.

권한 탭에서 읽기 및 검색 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

대상 탭에서 이 항목을 눌러 대상 디렉토리 항목 필드에 dc=subscribers, dc=example,dc=com 접미어를 표시합니다.

하위 항목 필터 필드에 아래 필터를 입력합니다.

(!(unlistedSubscriber=yes))

속성 테이블에서 homePhone, homePostalAddress 및 mail 속성에 해당하는 확인란을 선택합니다.

다른 확인란은 모두 선택 취소해야 합니다. 간편하게 이 작업을 수행하려면 선택 안 함 버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, 이름 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

개인 항목에 대한 쓰기 액세스 권한 부여

대부분의 디렉토리 관리자는 내부 사용자가 자신의 항목에 있는 일부 속성만 변경할 수 있도록 설정합니다. example.com의 디렉토리 관리자도 사용자가 자신의 비밀번호, 집 전화 번호 및 집 주소만 변경할 수 있도록 설정하려고 합니다. 여기에 대해서는 ACI "Write example.com" 예에서 설명합니다.

또한 example.com의 정책은 가입자가 SSL을 통해 디렉토리에 연결하면 example.com 트리에서 자신의 개인 정보를 업데이트할 수 있도록 허용합니다. 여기에 대해서는 ACI "Write Subscribers" 예에서 설명합니다.

ACI "Write example.com"

example.com 직원들에게 비밀번호, 집 전화 번호 및 집 주소를 업데이트할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


주	이 권한을 설정하면 사용자에게 속성 값을 삭제할 수 있는 권한도 부여하게 됩니다.

aci: (targetattr="userPassword || homePhone ||
homePostalAddress")(version 3.0; acl "Write example.com";
allow (write) userdn="ldap:///self" and dns="*.example.com";)

이 예에서는 ou=People,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

디렉토리 탭의 왼쪽 탐색 트리에서 ou=People,dc=example,dc=com 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택하여 액세스 제어 관리자를 표시합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Write example.com"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

검색 영역을 특수 권한으로 설정하고 검색 결과 목록에서 자신을 선택합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 자신을 추가합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 쓰기 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

대상 탭에서 이 항목을 눌러 대상 디렉토리 항목 필드에 ou=People,dc=example,dc=com을 입력합니다. 속성 테이블에서 homePhone, homePostalAddress 및 userPassword 속성에 해당하는 확인란을 선택합니다.버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, 이름 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

호스트 탭에서 추가를 눌러 호스트 필터 추가 대화 상자를 표시합니다. DNS 호스트 필터 필드에 *.example.com을 입력합니다. 확인을 눌러 대화 상자를 닫습니다.

액세스 제어 편집기 창에서 확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

ACI "Write Subscribers"

example.com 가입자에게 비밀번호, 집 전화 번호를 업데이트할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


주	이 권한을 설정하면 사용자에게 속성 값을 삭제할 수 있는 권한도 부여하게 됩니다.

aci: (targetattr="userPassword || homePhone")
(version 3.0; acl "Write Subscribers"; allow (write)
userdn= "ldap://self" and authmethod="ssl";)

이 예에서는 ou=subscribers,dc=example, dc=com 항목에 aci를 추가한다고 가정합니다.

example.com 가입자에게는 집 주소에 대한 쓰기 액세스 권한이 없습니다. 이 속성은 example.com의 필수 결제 정보로 업무상 중요하기 때문에 가입자가 삭제하지 못하도록 액세스가 거부됩니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Write Subscribers"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

검색 영역을 특수 권한으로 설정하고 검색 결과 목록에서 자신을 선택합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 자신을 추가합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

대상 탭에서 이 항목을 눌러 대상 디렉토리 항목 필드에 dc=subscribers, dc=example,dc=com 접미어를 표시합니다.

하위 항목 필터 필드에 아래 필터를 입력합니다.

(!(unlistedSubscriber=yes))

속성 테이블에서 homePhone, homePostalAddress 및 mail 속성에 해당하는 확인란을 선택합니다.

SSL을 사용하여 사용자를 인증하려면 수동으로 편집 버튼을 눌러 수동 편집으로 전환하고 다음과 같이 LDIF 명령문에 authmethod=ssl을 추가합니다.

(targetattr="homePostalAddress || homePhone || mail")
(version 3.0; acl "Write Subscribers"; allow (write)
(userdn= "ldap:///self") and authmethod="ssl";)

가독성을 위해 분리되었을 뿐 사실은 연속된 줄입니다.

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

중요 역할에 대한 액세스 제한

디렉토리에서 역할 정의를 사용하여 업무상 중요한 기능이나 네트워크 및 디렉토리 관리 또는 다른 용도를 식별할 수 있습니다.

예를 들어, 특정 시간과 요일에 전세계 기업 사이트에서 사용할 수 있는 시스템 관리자의 부분 집합을 식별하여 superAdmin 역할을 작성할 수 있습니다. 또는 응급 조치 교육을 이수한 특정 사이트의 직원들이 모두 포함된 First Aid 역할을 작성할 수 있습니다. 역할 정의를 작성하는 방법은 역할 할당을 참조하십시오.

중요한 기업 또는 비즈니스 기능에 대한 사용자 권한을 부여하는 역할이 있을 경우 이 역할에 대한 액세스를 제한해야 합니다. 예를 들어, example.com의 직원들은 superAdmin 역할을 제외한 모든 역할을 자신의 항목에 추가할 수 있습니다. 여기에 대해서는 ACI "Roles" 예에서 설명합니다.

ACI "Roles"

example.com 직원들에게 superAdmin 역할을 제외한 모든 역할을 자신의 항목에 추가할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (targetattr="*") (targattrfilters="add=nsRoleDN:
(nsRoleDN !="cn=superAdmin, dc=example, dc=com")")
(version 3.0; acl "Roles"; allow (write)
userdn= "ldap:///self" and dns="*.example.com";)

이 예에서는 ou=People,dc=example, dc=com 항목에 ACI를 추가한다고 가정합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Roles"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

사용자 및 그룹 추가 대화 상자에서 검색 영역을 특수 권한으로 설정하고 검색 결과 목록에서 자신을 선택합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 자신을 추가합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

역할에 대한 값 기반의 필터를 작성하려면 수동으로 편집 버튼을 눌러 수동 편집으로 전환합니다. LDIF 명령문의 시작 부분에 아래 명령을 추가합니다.

(targattrfilters="add=nsRoleDN:
(nsRoleDN != "cn=superAdmin, dc=example,dc=com")")

LDIF 명령문이 다음과 같이 표시됩니다.

(targetattr="*") (targattrfilters="add=nsRoleDN:
(nsRoleDN != "cn=superAdmin, dc=example,dc=com")")
(target = "ldap:///dc=example,dc=com")
(version 3.0; acl "Roles"; allow (write)
(userdn = "ldap:///self") and (dns="*.example.com");)

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

그룹에 접미어에 대한 전체 액세스 권한 부여

대부분의 디렉토리에는 기업의 특정 기능을 식별하는 그룹이 있습니다. 이러한 그룹에 디렉토리의 모두 또는 일부에 대한 전체 액세스 권한을 부여할 수 있습니다. 그룹에 액세스 권한을 적용하면 각 구성원에 대해 개별적으로 액세스 권한을 설정할 필요가 없습니다. 사용자를 그룹에 추가하기만 하면 액세스 권한을 부여할 수 있습니다.

예를 들어, 일반 설치 프로세스를 사용하여 Directory Server를 설치하면 디렉토리에 대한 전체 액세스 권한을 가진 관리자 그룹이 기본적으로 작성됩니다.

example.com의 경우 Human Resources 그룹은 디렉토리의 ou=People 분기에 대한 전체 액세스 권한을 갖고 있으므로 직원 디렉토리를 업데이트할 수 있습니다. 여기에 대해서는 ACI "HR" 예에서 설명합니다.

ACI "HR"

디렉토리의 employee 분기에 대한 모든 권한을 HR 그룹에 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (targetattr="*") (version 3.0; acl "HR"; allow (all)
userdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)

이 예에서는 ou=People, dc=example, dc=com 항목에 ACI를 추가한다고 가정합니다.

디렉토리 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 example.com-people 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택하여 액세스 제어 관리자를 표시합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "HR"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

검색 영역을 사용자 및 그룹으로 설정하고 검색 대상 필드에 "Hrgroup"을 입력합니다.

이 예에서는 HR 그룹이나 역할이 작성되어 있다고 가정합니다. 그룹 및 역할에 대한 자세한 내용은 5장, "Identity 및 역할 관리"를 참조하십시오.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 HR 그룹을 표시합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 모두 선택 버튼을 누릅니다.

프록시 권한을 제외한 모든 확인란이 선택됩니다.

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

그룹 항목 추가 및 삭제 권한 부여

일부 기업은 직원들이 효율성을 높이고 기업의 활력소 역할을 하는 항목을 트리에 작성할 수 있도록 허용합니다.

예를 들어 example.com에는 테니스, 수영, 스키, 롤 플레잉 등 여러 클럽으로 구성된 활동적인 사교 모임이 있으며 example.com의 직원이라면 누구든지 새 클럽을 나타내는 그룹 항목을 작성할 수 있습니다. 여기에 대해서는 ACI "Create Group" 예에서 설명합니다. example.com의 모든 직원은 이러한 그룹 중 하나의 구성원이 될 수 있습니다. 여기에 대해서는 사용자가 그룹에 자신을 추가 또는 제거할 수 있도록 허용의 ACI "Group Members"에서 설명합니다. 하지만 그룹 소유자만 그룹 항목을 수정하거나 삭제할 수 있습니다. 여기에 대해서는 ACI "Delete Group" 예에서 설명합니다.

ACI "Create Group"

example.com 직원들에게 ou=Social Committee 분기에 그룹 항목을 작성할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (target="ldap:///ou=social committee,dc=example,dc=com")
(targetattr="*")(targattrfilters="add=objectClass:
(|(objectClass=groupOfNames)(objectClass=top))")
(version 3.0; acl "Create Group"; allow (read,search,add)
userdn= "ldap:///uid=*,ou=People,dc=example,dc=com")
and dns="*.example.com";)


주	이 ACI는 쓰기 권한을 부여하지 않기 때문에 항목 작성자가 항목을 수정할 수 없습니다. 서버가 이면에서 "top" 값을 추가하므로 targattrfilters 키워드에 objectclass=top을 지정해야 합니다.

이 예에서는 ou=social committee, dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

디렉토리 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Social Committee 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택하여 액세스 제어 관리자를 표시합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Create Group"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

검색 영역을 특수 권한으로 설정하고 검색 결과 목록에서 모든 인증된 사용자를 선택합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 모든 인증된 사용자를 추가합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 읽기, 검색 및 추가 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

대상 탭에서 이 항목을 눌러 대상 디렉토리 항목 필드에 ou=social committee, dc=example,dc=com 접미어를 표시합니다.

직원들이 이 하위 트리에 그룹 항목만 추가할 수 있도록 값 기반의 필터를 작성하려면 수동으로 편집 버튼을 눌러 수동 편집으로 전환합니다. LDIF 명령문의 시작 부분에 아래 명령을 추가합니다.

(targattrfilters="add=objectClass:(objectClass=groupOfNames)
|(objectClass=top)")

LDIF 명령문이 다음과 같이 표시됩니다.

(targetattr = "*") (targattrfilters="add=objectClass:(objectClass=groupOfNames)
|(objectClass=top)") (target="ldap:///ou=social committee,dc=example,dc=com) (version 3.0; acl "Create Group";
allow (read,search,add) (userdn= "ldap:///all") and
(dns="*.example.com"); )

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

ACI "Delete Group"

example.com 직원들에게 ou=Social Committee 분기에서 그룹 항목을 수정하거나 삭제할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (target="ou=social committee,dc=example,dc=com)(targetattr
"*")
(targattrfilters="del=objectClass:(objectClass=groupOfNames)")
(version 3.0; acl "Delete Group"; allow (write,delete)
userattr="owner#GROUPDN";)

이 예에서는 ou=social committee, dc=example,dc=com 항목에 aci를 추가한다고 가정합니다.

콘솔을 사용할 경우 수동 편집 모드로 대상 필터를 작성하고 그룹 소유권을 확인해야 하기 때문에 이 ACI를 작성하는 데는 효과적인 방법이 아닙니다.

그룹이나 역할에 조건부 액세스 권한 부여

일반적으로 그룹이나 역할에 디렉토리에 대한 액세스 권한을 부여하는 경우 권한이 있는 사용자를 사칭하는 침입자들로부터 해당 권한을 보호해야 합니다. 따라서 그룹이나 역할에 중요한 액세스 권한을 부여하는 액세스 제어 규칙에는 많은 조건이 따릅니다.

예를 들어, example.com은 자사가 호스팅 서비스를 제공하는 두 회사인 Company333과 Company999에 대해 각각 디렉토리 관리자 역할을 작성했습니다. example.com은 두 회사가 자사 데이터를 관리하고 액세스 제어 규칙을 구현할 수 있는 동시에 침입자로부터 데이터를 보호할 수 있기를 원합니다. 이런 이유로 Company333과 Company999는 다음과 같은 조건에 부합될 경우 디렉토리 트리의 해당 분기에 대한 전체 권한을 갖습니다.

이러한 조건에 대해서는 각 회사별 ACI(ACI "Company333" 및 ACI "Company999")에서 설명합니다. 두 ACI의 내용이 같기 때문에 아래 예에서는 "Company333" ACI에 대해서만 설명합니다.

ACI "Company333"

위에 명시된 조건을 전제로 Company333에 디렉토리의 분기에 대한 전체 액세스 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (target="ou=Company333,ou=corporate-clients,dc=example,dc=com")
(targetattr = "*") (version 3.0; acl "Company333"; allow (all)
(roledn="ldap:///cn=DirectoryAdmin,ou=Company333,
ou=corporate-clients,dc=example,dc=com") and (authmethod="ssl")
and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
timeofday <= "1800") and (ip="255.255.123.234"); )

이 예에서는 ou=Company333, ou=corporate-clients,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

디렉토리 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Company333 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 액세스 권한 설정을 선택하여 액세스 제어 관리자를 표시합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Company333"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

검색 영역을 사용자 및 그룹으로 설정하고 검색 대상 필드에 "DirectoryAdmin"을 입력합니다.

이 예에서는 cn이 DirectoryAdmin인 관리자 역할이 작성되어 있다고 가정합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 관리자 역할을 표시합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 모두 선택 버튼을 누릅니다.

대상 탭에서 이 항목을 눌러 대상 디렉토리 항목 필드에 ou=Company333,ou=corporate-clients,dc=example,dc=com 접미어를 표시합니다.

호스트 탭에서 추가를 눌러 호스트 필터 추가 대화 상자를 표시합니다. IP 주소 호스트 필터 필드에 255.255.123.234를 입력합니다. 확인을 눌러 대화 상자를 닫습니다.

IP 주소는 Company333 관리자가 example.com 디렉토리에 연결할 때 사용하는 호스트 시스템의 유효한 IP 주소여야 합니다.

시간 탭에서 월요일에서 목요일까지, 오전 8시에서 오후 6시까지에 해당하는 시간 블록을 선택합니다.

선택한 시간 블록을 지정하는 메시지가 테이블 아래에 나타납니다.

Company333 관리자로부터의 SSL 인증을 실행하려면 수동으로 편집 버튼을 눌러 수동 편집으로 전환합니다. LDIF 명령문의 끝 부분에 아래 명령을 추가합니다.

and (authmethod="ssl")

LDIF 명령문이 다음과 같이 표시됩니다.

aci: (targetattr = "*")(target="ou=Company333,
ou=corporate-clients,dc=example,dc=com") (version 3.0; acl
"Company333"; allow (all) (roledn="ldap:///cn=DirectoryAdmin,
ou=Company333,ou=corporate-clients, dc=example,dc=com") and
(dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
timeofday <= "1800") and (ip="255.255.123.234") and
(authmethod="ssl"); )

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

액세스 거부

디렉토리에 업무상 중요한 정보가 있으면 디렉토리에 대한 액세스를 구체적으로 거부할 수 있습니다.

예를 들어, example.com은 모든 가입자가 자신의 항목에서 연결 시간이나 계좌 잔고와 같은 결제 정보를 읽을 수 있도록 허용하지만 이 정보에 대한 쓰기 액세스는 명시적으로 거부합니다. 여기에 대해서는 ACI "Billing Info Read" 및 ACI "Billing Info Deny"에서 각각 설명합니다.

ACI "Billing Info Read"

가입자에게 자신의 항목에서 결제 정보를 읽을 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (targetattr="connectionTime || accountBalance")
(version 3.0; acl "Billing Info Read"; allow (search,read)
userdn="ldap:///self";)

이 예에서는 스키마에 해당 속성이 작성되어 있으며 ou=subscribers,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Billing Info Read"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

사용자 및 그룹 추가 대화 상자에서 검색 영역을 특수 권한으로 설정하고 검색 결과 목록에서 자신을 선택합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 자신을 추가합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 검색 및 읽기 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

대상 탭에서 이 항목을 눌러 대상 디렉토리 항목 필드에 ou=subscribers, dc=example,dc=com 접미어를 표시합니다. 속성 테이블에서 connectionTime 속성과 accountBalance 속성에 해당하는 확인란을 선택합니다.

이 예에서는 connectionTime 속성과 accountBalance 속성이 스키마에 추가되어 있다고 가정합니다.

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

ACI "Billing Info Deny"

가입자에게 자신의 항목에서 결제 정보를 수정할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (targetattr="connectionTime || accountBalance")
(version 3.0; acl "Billing Info Deny";
deny (write) userdn="ldap:///self";)

이 예에서는 스키마에 해당 속성이 작성되어 있으며 ou=subscribers,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Billing Info Deny"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

사용자 및 그룹 추가 대화 상자에서 검색 영역을 특수 권한으로 설정하고 검색 결과 목록에서 자신을 선택합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 자신을 추가합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

수동으로 편집 버튼을 누르고 표시된 LDIF 명령문에서 allow를 deny로 변경합니다.

이 예에서는 connectionTime 속성과 accountBalance 속성이 스키마에 추가되어 있다고 가정합니다.

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

필터링을 사용한 대상 설정

디렉토리에 분산된 여러 항목에 대한 액세스를 허용하는 액세스 제어를 설정하려면 필터를 사용하여 대상을 설정할 수 있습니다. 검색 필터는 액세스가 관리되는 객체의 이름을 직접 지정하지 않으므로 특히 디렉토리가 복잡할수록 실수로 잘못된 객체에 대한 액세스 권한을 부여하거나 거부할 수 있습니다. 또한 필터를 사용할 경우 디렉토리 내의 액세스 제어 문제점을 해결하기 어렵다는 단점이 있습니다.

사용자가 그룹에 자신을 추가 또는 제거할 수 있도록 허용

대부분의 디렉토리는 사용자가 그룹에 자신을 추가하거나 제거할 수 있도록 허용하는 ACI를 설정합니다. 예를 들어, 사용자가 우편 목록에 자신을 추가하거나 제거할 수 있도록 허용할 경우 이러한 ACI를 설정할 수 있습니다.

example.com 직원들은 ou=social committee 하위 트리의 모든 그룹 항목에 자신을 추가할 수 있습니다. 여기에 대해서는 ACI "Group Members" 예에서 설명합니다.

ACI "Group Members"

example.com 직원들에게 그룹에 자신을 추가하거나 삭제할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.

aci: (targettattr="member")(version 3.0; acl "Group Members";
allow (selfwrite)
(userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)

이 예에서는 ou=social committee, dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

디렉토리 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 People 항목을 마우스 오른쪽 버튼으로 누른 다음 팝업 메뉴에서 액세스 권한 설정을 선택하여 액세스 제어 관리자를 표시합니다.

새로 만들기를 눌러 액세스 제어 편집기를 표시합니다.

사용자/그룹 탭의 ACI 이름 필드에 "Group Members"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

모든 사용자를 선택하여 제거한 다음 추가를 누릅니다.

사용자 및 그룹 추가 대화 상자가 표시됩니다.

사용자 및 그룹 추가 대화 상자에서 검색 영역을 특수 권한으로 설정하고 검색 결과 목록에서 모든 인증된 사용자를 선택합니다.

추가 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 모든 인증된 사용자를 추가합니다.

확인을 눌러 사용자 및 그룹 추가 대화 상자를 닫습니다.

권한 탭에서 자체 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

대상 탭의 대상 디렉토리 항목 필드에 dc=example,dc=com 접미어를 입력합니다. 속성 테이블에서 member 속성에 해당하는 확인란을 선택합니다.

확인을 누릅니다.

액세스 제어 관리자 창의 목록에 새 ACI가 추가됩니다.

쉼표가 있는 DN에 대한 권한 정의

쉼표가 있는 DN은 LDIF ACI 명령문에서 특별히 처리해야 합니다. ACI 명령문의 대상 및 바인드 규칙 부분에서 역슬래시(\)를 사용하여 쉼표를 이스케이프해야 합니다. 아래 예에서는 이 구문에 대해 설명합니다.

dn: o=example.com Bolivia\, S.A.
objectClass: top
objectClass: organization
aci: (target="ldap:///o=example.com Bolivia\,S.A.")
(targetattr="*") (version 3.0; acl "aci 2"; allow (all)
groupdn = "ldap:///cn=Directory Administrators,
o=example.com Bolivia\, S.A.";)

프록시 인증 ACI 예

프록시 인증 방법은 자신의 아이디를 사용하여 디렉토리에 바인드하는 사용자에게 프록시 인증을 통해 다른 사용자의 권한을 부여하는 특별한 인증 형식입니다.

클라이언트 응용 프로그램이 계정 관리자와 동일한 액세스 권한을 사용하여 Accounting 하위 트리에 액세스하려면 다음과 같은 조건을 만족해야 합니다.

이 ACI가 디렉토리에 있으면 MoneyWizAcctSoftware 클라이언트 응용 프로그램은 디렉토리에 바인드하여 프록시 DN의 액세스 권한이 필요한 ldapsearch 또는 ldapmodify와 같은 LDAN 명령을 전송할 수 있습니다.

위의 예에서 클라이언트가 ldapsearch 명령을 수행하려면 명령에 다음과 같은 컨트롤이 포함됩니다.

ldapsearch \
-D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" \
-w password\
-y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com"\ ...

클라이언트는 자신으로 바인드하지만 프록시 항목의 권한이 부여되며 프록시 항목의 비밀번호를 제공할 필요가 없습니다.


주	디렉토리 관리자의 DN은 프록시 DN으로 사용할 수 없으며 디렉토리 관리자에게 프록시 권한을 부여할 수도 없습니다. 또한 Directory Server가 한 개의 바인드 작업에서 프록시 인증 제어를 둘 이상 수신하면 클라이언트 응용 프로그램에 오류가 반환되고 바인드 시도는 실패합니다.

유효 권한 보기

디렉토리 항목에 대한 액세스 정책을 유지 관리할 때 정의한 ACI의 보안에 미치는 영향을 확인할 수 있다면 큰 도움이 됩니다. Directory Server에서는 기존 ACI를 평가하고 지정된 항목의 특정 사용자에게 부여되는 유효 권한을 보고할 수 있습니다.

Directory Server는 검색 작업에 포함할 수 있는 "유효 권한 보기" 컨트롤에 응답하여 항목과 속성에 대한 유효 권한 정보를 검색 결과로 반환합니다. 이 추가 정보에는 각 항목 및 항목에 있는 각 속성에 대한 읽기 및 쓰기 권한이 포함됩니다. 검색에 사용된 바인드 DN이나 임의 DN에 대한 권한을 요청할 수 있으므로 관리자는 디렉토리 사용자의 권한을 테스트할 수 있습니다.


주의	유효 권한 보기는 그 자체가 디렉토리 작업이므로 보호 및 적절한 제한이 필요합니다. 이 정보에 대한 디렉토리 사용자의 액세스를 제한하려면 aclRights 및 aclRightsInfo 속성에 대한 ACI를 추가로 작성합니다.

유효 권한 기능은 LDAP 컨트롤을 사용합니다. 연결 접미어에 대한 유효 권한을 보려면 연결 정책 구성에 설명된 것처럼 연결 정책에서 이 컨트롤을 활성화해야 합니다. 원격 서버에 바인드할 때 사용한 프록시 아이디도 유효 권한 속성에 액세스할 수 있어야 합니다.

유효 권한 보기 컨트롤 사용

ldapsearch 명령을 -J "1.3.6.1.4.1.42.2.27.9.5.2" 옵션과 함께 사용하여 "유효 권한 보기" 컨트롤을 지정합니다. 기본적으로 이 컨트롤은 항목과 속성에 대한 바인드 DN 항목의 유효 권한을 검색 결과로 반환합니다. 기본 동작을 변경하려면 다음과 같은 옵션을 사용합니다.

-c 및 -X 속성 중 한 개나 둘 모두를 사용할 경우 "유효 권한 보기" 컨트롤의 OID에 -J 옵션이 암묵적으로 지정되므로 별도로 지정할 필요가 없습니다. 유효 권한 컨트롤에 NULL 값을 지정하면 현재 사용자에 대한 권한과 현재 ldapsearch 작업에서 반환하는 속성 및 항목에 대한 권한이 검색됩니다.

그런 다음, 간단히 권한만 볼 것인지 아니면 이러한 권한이 어떻게 부여 또는 거부되는지 설명하는 자세한 로깅 정보를 볼 것인지 선택합니다. 각각 aclRights 또는 aclRightsInfo를 검색 결과로 반환할 속성에 추가하여 정보 유형을 결정합니다. 간단한 권한 정보는 자세한 로깅 정보의 내용과 중복되지만 두 속성을 모두 요청하여 유효 권한 정보를 모두 받을 수도 있습니다.

유효 권한 기능은 검색 작업을 시작한 사용자로부터 액세스 제어에 영향을 주는 기타 매개 변수(시간, 인증 방법, 시스템 주소, 이름 등)를 상속합니다.


주	aclRights 및 aclRightsInfo 속성은 가상의 작동 가능 속성으로 동작합니다. 두 속성은 디렉토리에 저장되지 않으므로 명시적으로 요청해야만 반환됩니다. Directory Server는 "유효 권한 보기" 컨트롤에 응답하여 두 속성을 생성합니다. 이런 이유로 두 속성은 모든 종류의 검색 작업이나 필터에 사용할 수 없습니다.

아래 예에서는 어떻게 사용자가 디렉토리에서 자신의 권한을 볼 수 있는지 보여줍니다. 결과에서 1은 권한이 부여된 것을, 0은 권한이 거부된 것을 의미합니다.

ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2" \
           -h rousseau.example.com -p 389 \
           -D "uid=cfuente,ou=People,dc=example,dc=com" \
           -w password -b "dc=example,dc=com" \
           "(objectclass=*)" aclRights

dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

이 결과는 Carla Fuente에게 최소한 읽기 권한이 있는 디렉토리 항목을 보여주며 자신의 항목을 수정할 수 있음을 표시합니다. 유효 권한 컨트롤은 일반 액세스 권한을 무시하지 않으므로 사용자는 읽기 권한이 없는 항목을 볼 수 없습니다. 아래 예에서 디렉토리 관리자는 Carla Fuente에게 읽기 권한이 없는 항목을 볼 수 있습니다.

ldapsearch -h rousseau.example.com -p 389 \
           -D "cn=Directory Manager" -w password \
           -c "dn: uid=cfuente,ou=People,dc=example,dc=com" \
           -b "dc=example,dc=com" \
           "(objectclass=*)" aclRights

dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=Directory Administrators, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0

dn: ou=Special Users,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0

dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

위의 결과에서 디렉토리 관리자는 Carla Fuente가 디렉토리 트리의 Special Users나 Directory Administrators 분기를 볼 수도 없다는 것을 확인할 수 있습니다. 아래 예에서 디렉토리 관리자는 Carla Fuente가 자신의 항목에 있는 mail 속성과 manager 속성을 수정할 수 없다는 것을 확인할 수 있습니다.

ldapsearch -h rousseau.example.com -p 389 \
           -D "cn=Directory Manager" -w password \
           -c "dn: uid=cfuente,ou=People,dc=example,dc=com" \
           -b "dc=example,dc=com" \
           "(uid=cfuente)" aclRights "*"

aclRights;attributeLevel;mail: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@example.com

aclRights;attributeLevel;uid: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente

aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla

aclRights;attributeLevel;sn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente

aclRights;attributeLevel;cn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente

aclRights;attributeLevel;userPassword: search:0,read:0,
compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==

aclRights;attributeLevel;manager: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com

aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898

aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson

유효 권한 결과 이해

유효 권한 요청은 지정한 옵션에 따라 다음 정보를 반환합니다.

권한 정보

aclRights;entrylevel	항목 수준의 권한 정보 제공
aclRights;attributelevel	속성 수준의 권한 정보 제공
aclRightsInfo;entrylevel	항목 수준의 로깅 정보 제공
aclRightsInfo;attributelevel	속성 수준의 로깅 정보 제공

가능한 항목 수준 권한에는 add, delete, read, write 및 proxy가 있습니다. 가능한 속성 수준 권한에는 read, search, compare, write, selfwrite_add, selfwrite_delete 및 proxy가 있습니다.

Write, Selfwrite_add 및 Selfwrite_delete 권한

Directory Server 5.2에서는 write 속성 수준 권한만 "?" 값을 가질 수 있습니다. add 및 delete 권한을 사용하여 추가하고 삭제할 수 있는 항목은 해당 항목의 속성 값에 따라 달라집니다. "?"를 반환하는 대신, ldapsearch 작업에서와 같이 항목에 대한 권한(0 또는 1)이 반환됩니다.

write 권한 값이 1이면 인증 dn 값을 제외한 모든 값에 대해 추가 및 삭제 ldapmodify 작업을 수행할 수 있습니다. write 권한 값이 0이면 인증 dn 값을 제외한 모든 값에 대해 추가 또는 삭제 ldapmodify 작업을 수행할 수 없습니다. 인증 dn 값에 적용되는 권한은 selfwrite 권한 중 하나인 selfwrite_add 또는 selfwrite_delete를 통해 명시적으로 반환됩니다.

ACI에는 이러한 기능을 수행하는 selfwrite-add 및 selfwrite-delete 속성 수준 권한이 없으므로 ACI 집합은 수정 작업의 오직 추가 부분이나 오직 삭제 부분에 대한 selfwrite 권한만 사용자에게 부여할 수 있습니다. selfwrite 권한을 사용하여 수정하는 속성 값이 인증 dn입니다. write 권한의 경우 수정하는 속성 값이 정의되어 있지 않으므로 이런 방법으로 차별화할 수 없습니다.

targattrfilters ACI에 따라 유효 권한이 결정될 때 "?" 값이 표시되면 로깅 정보에서 자세한 권한 정보를 확인해야 합니다. write, selfwrite_add 및 selfwrite_delete 권한 간의 복잡한 상호 종속성 관계를 고려하여, 표 6-3에서는 세 권한의 각 조합이 의미하는 바를 설명합니다.

표 6-3 유효 권한 상호 종속성
write	selfwrite_ add	selfwrite_ delete	유효 권한 설명
0	0	0	이 속성의 어떤 값도 추가하거나 삭제할 수 없습니다.
0	0	1	인증 dn 값만 삭제할 수 있습니다.
0	1	0	인증 dn 값만 추가할 수 있습니다.
0	1	1	인증 dn 값만 추가하거나 삭제할 수 있습니다.
1	0	0	인증 dn을 제외한 모든 값을 추가하거나 삭제할 수 있습니다.
1	0	1	인증 dn을 포함한 모든 값을 삭제할 수 있으며, 인증 dn을 제외한 모든 값을 추가할 수 있습니다.
1	1	0	인증 dn을 포함한 모든 값을 추가할 수 있으며, 인증 dn을 제외한 모든 값을 삭제할 수 있습니다.
1	1	1	이 속성의 모든 값을 추가하거나 삭제할 수 있습니다.
?	0	0	인증 dn 값을 추가하거나 삭제할 수는 없지만, 다른 값을 추가하거나 삭제할 수 있습니다. write 권한에 대한 자세한 내용은 로깅 정보를 참조하십시오.
?	0	1	인증 dn 값을 삭제할 수만 있고 추가할 수 없으며, 다른 값을 추가하거나 삭제할 수 있습니다. write 권한에 대한 자세한 내용은 로깅 정보를 참조하십시오.
?	1	0	인증 dn 값을 추가할 수만 있고 삭제할 수 없으며, 다른 값을 추가하거나 삭제할 수 있습니다. write 권한에 대한 자세한 내용은 로깅 정보를 참조하십시오.
?	1	1	인증 dn 값을 추가하고 삭제할 수 있으며, 다른 값의 추가를 수정하거나 삭제를 수정할 수 있습니다. write 권한에 대한 자세한 내용은 로깅 정보를 참조하십시오.

로깅 정보

유효 권한 로깅 정보를 사용하여 액세스 제어 문제점을 파악하고 디버그할 수 있습니다. 로깅 정보에는 액세스 제어가 허용 또는 거부된 이유를 나타내는 액세스 제어 요약문이 포함되어 있으며, 이를 acl_summary라고 합니다. 액세스 제어 요약문은 다음 정보를 제공합니다.

액세스가 허용 또는 거부되었는지 여부

부여된 권한

권한의 대상 항목

대상 속성의 이름

요청되는 권한의 주제

프록시에 의해 요청된 것인지 여부, 프록시에 의해 요청된 경우 프록시 인증 DN

액세스를 허용 또는 거부하는 이유(디버깅 시 중요함) 가능한 이유는 표 6-4에 열거되어 있습니다.

표 6-4 유효 권한 로깅 정보 이유 및 설명
로깅 정보 이유	설명
no reason available	액세스가 허용 또는 거부된 이유를 설명하기 위해 사용할 수 있는 이유가 없습니다.
no allow acis	ACI가 허용되지 않으므로 액세스가 거부됩니다.
result cached deny	캐시된 정보를 통해 액세스 거부가 결정되었습니다.
result cached allow	캐시된 정보를 통해 액세스 허용이 결정되었습니다.
evaluated allow	ACI 평가를 통해 액세스 허용이 결정되었습니다. ACI 이름은 로그 정보에 포함되어 있습니다.
evaluated deny	ACI 평가를 통해 액세스 거부가 결정되었습니다. ACI 이름은 로그 정보에 포함되어 있습니다.
no acis matched the resource	자원 또는 대상과 일치하는 ACI가 없으므로 액세스가 거부됩니다.
no acis matched the subject	액세스 제어를 요청하는 주제와 일치하는 ACI가 없으므로 액세스가 거부됩니다.
allow anyone aci matched anon user	userdn = "ldap:///anyone" 주제를 가진 ACI가 익명 사용자에게 액세스를 허용했습니다.
no matching anyone aci for anon user	userdn= "ldap:///anyone" 주제를 가진 ACI를 찾을 수 없으므로 익명 사용자의 액세스가 거부되었습니다.
user root	사용자가 루트 DN이므로 액세스가 허용됩니다.



주	가상 속성은 업데이트할 수 없으므로 가상 속성에 대한 write 권한이나 관련된 로깅 평가 정보는 제공되지 않습니다.

고급 액세스 제어: 매크로 ACI 사용

반복 디렉토리 트리 구조를 사용하는 조직에서는 매크로를 사용하여 디렉토리에 사용되는 ACI 수를 최소화할 수 있습니다. 디렉토리 트리의 ACI 수를 줄이면 액세스 제어 정책의 관리가 용이해지며 ACI 메모리를 효율적으로 사용할 수 있습니다.

매크로는 ACI에서 DN 또는 DN의 일부분을 나타내는 자리 표시자입니다. 매크로를 사용하여 ACI의 대상 부분, 바인드 규칙 부분 또는 두 부분에서 모두 DN을 나타낼 수 있습니다. 실제로 LDAP 작업이 수신되면 Directory Server는 ACI 매크로를 LDAP 작업의 대상 자원과 비교하여 일치하는 하위 문자열이 있는지 확인합니다. 일치하는 하위 문자열이 있으면 이 문자열을 사용하여 바인드 규칙측 매크로를 확장하고 확장된 바인드 규칙을 평가하여 자원에 대한 액세스를 결정합니다.

매크로 ACI 예

예를 통해 살펴보면 매크로 ACI의 이점과 작동 방식을 명확히 이해할 수 있습니다. 그림 6-4에서는 매크로 ACI를 사용하여 효과적으로 전체 ACI 수를 줄일 수 있는 디렉토리 트리를 보여줍니다.

이 그림에서는 하위 도메인의 반복 패턴이 동일한 트리 구조(ou=groups,ou=people)를 갖습니다. example.com 디렉토리 트리에 dc=hostedCompany2,dc=example,dc=com 및 dc=hostedCompany3,dc=example,dc=com 접미어가 저장되기 때문에 이 패턴은 트리 전체에도 반복됩니다.

디렉토리 트리에 적용되는 ACI에도 반복 패턴이 있습니다. 예를 들어 dc=hostedCompany1,dc=example,dc=com 노드에는 아래 ACI가 있습니다.

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))(version 3.0;
acl "Domain access"; allow (read,search) groupdn=
"ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,
dc=example,dc=com";)

이 ACI는 DomainAdmins 그룹에 dc=hostedCompany1,dc=example,dc=com 트리의 모든 항목에 대한 읽기 및 검색 권한을 부여합니다.

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,
dc=example,dc=com";)

dc=subdomain1,dc=hostedCompany1, dc=example,dc=com 노드에는 아래 ACI가 있습니다.

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,
dc=hostedCompany1,dc=example,dc=com";)

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2,
dc=example,dc=com";)

dc=subdomain1,dc=hostedCompany2, dc=example,dc=com 노드에는 아래 ACI가 있습니다.

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,
dc=hostedCompany2,dc=example,dc=com";)

네 개의 ACI에서 유일한 차이점은 groupdn 키워드에 지정된 DN입니다. 이 경우 DN에 매크로를 사용하여 dc=example,dc=com 노드에서 트리의 루트에 있는 한 개의 ACI로 네 개의 ACI를 대체할 수 있습니다. 이 ACI는 다음과 같이 표시됩니다.

aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
(targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search) groupdn=
"ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

이 경우 앞에서 사용하지 않았던 target 키워드가 사용되었습니다.

위의 예에서는 ACI 수가 4개에서 1개로 줄었습니다. 하지만 전체 디렉토리 트리의 반복 패턴 수가 줄어든다는 것에 가장 큰 이점이 있습니다.

매크로 ACI 구문

이 절에서는 설명을 간소화하기 위해 userdn, roledn, groupdn, userattr 등의 바인드 자격 증명을 제공하는 ACI 키워드를 모두 ACI의 주제라고 부릅니다. 주제는 ACI의 적용 대상을 결정합니다.

매크로 ACI에는 DN 또는 DN의 일부분을 대체하는 다음과 같은 유형의 표현식이 포함됩니다.

표 6-5에는 ACI에서 DN 매크로를 사용할 수 있는 부분이 나와 있습니다.

대상의 ($dn) 일치

표 6-5 ACI 키워드의 매크로
매크로	ACI 키워드
($dn)	target, targetfilter, userdn, roledn, groupdn, userattr
[$dn]	targetfilter, userdn, roledn, groupdn, userattr
($attr.attrName)	userdn, roledn, groupdn, userattr

ACI의 대상에 있는 ($dn) 매크로는 LDAP 요청의 대상 항목에 따라 대체 값을 결정합니다. 예를 들어, cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,dc=example,dc=com 항목을 대상으로 하는 LDAP 요청과 대상을 다음과 같이 정의하는 ACI가 있습니다.

($dn) 매크로는 "dc=subdomain1, dc=hostedCompany1"과 일치하므로 ACI 주제에 이 하위 문자열이 대체됩니다.

주제의 ($dn) 대체

ACI 주제에 있는 ($dn) 매크로는 대상에서 일치하는 전체 하위 문자열로 대체됩니다. 예를 들면 다음과 같습니다.

groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,
dc=hostedCompany1,dc=example,dc=com"

매크로가 확장되면 Directory Server는 일반 프로세스에 따라 ACI를 평가하여 액세스 권한을 부여할지 여부를 결정합니다.

주제의 [$dn] 대체


주	매크로 대체를 사용하는 ACI는 표준 ACI와 달리 반드시 대상 항목의 자식에 대한 액세스 권한을 부여하지는 않습니다. 이는 자식의 DN이 대상일 경우 대체로 인해 주제 문자열에 잘못된 DN이 작성될 수 있기 때문입니다.

[$dn]의 대체 기법은 ($dn)의 경우와 약간 다릅니다. 일치를 발견할 때까지 대상 자원의 DN을 여러 번 검사하며 매번 가장 왼쪽의 RDN 구성 요소를 삭제합니다.

예를 들어, cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com 하위 트리를 대상으로 하는 LDAP 요청과 다음과 같은 ACI가 있습니다.

aci: (targetattr="*")
(target="ldap:///ou=Groups,($dn),dc=example,dc=com")
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],
dc=example,dc=com";)

대상의 ($dn)은 dc=subdomain1,dc=hostedCompany1과 일치합니다.

주제의 [$dn]을 dc=subdomain1,dc=hostedCompany1로 대체합니다.

따라서 주제는 groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"이 됩니다. 바인드 DN이 이 그룹의 구성원이어서 액세스 권한이 부여되면 매크로 확장이 중단되고 ACI 평가가 수행됩니다. 바인드 DN이 그룹의 구성원이 아니면 프로세스가 계속됩니다.

주제의 [$dn]을 dc=hostedCompany1로 대체합니다.

따라서 주제는 groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com"이 됩니다. 다시 바인드 DN이 이 그룹의 구성원인지 테스트하여, 구성원일 경우 ACI를 완전히 평가합니다. 그룹의 구성원이 아니면 일치한 값의 마지막 RDN에서 매크로 확장이 중단되고 이 ACI에 대한 평가가 완료됩니다.

[$dn] 매크로를 사용할 경우 도메인 수준 관리자에게 디렉토리 트리의 모든 하위 도메인에 대한 액세스 권한을 유연성 있게 부여할 수 있다는 장점이 있습니다. 따라서 이 매크로는 도메인간 계층 관계를 표시할 때 유용합니다.

aci: (target="ldap:///ou=*,($dn),dc=example,dc=com")
(targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search) groupdn=
"ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

이 ACI는 cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com 구성원에게 dc=hostedCompany1의 모든 하위 도메인에 대한 액세스 권한을 부여하므로 이 그룹에 속한 관리자는 하위 트리(예: ou=people,dc=subdomain1.1,dc=subdomain1)에 액세스할 수 있습니다.

하지만 이와 동시에 cn=DomainAdmins,ou=Groups, dc=subdomain1.1의 구성원에게는 ou=people,dc=subdomain1, dc=hostedCompany1 및 ou=people,dc=hostedCompany1 노드에 대한 액세스가 거부됩니다.

($attr.attrName)의 매크로 일치

($attr.attrname) 매크로는 항상 DN의 주제 부분에서 사용됩니다. 예를 들어 다음과 같은 roledn을 정의할 수 있습니다.

roledn = "ldap:///cn=DomainAdmins,($attr.ou),dc=HostedCompany1,
dc=example,dc=com"

이제 서버가 아래 항목을 대상으로 하는 LDAP 작업을 수신한다고 가정해 보십시오.

dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com
cn: Babs Jensen
sn: Jensen
ou: Sales
...

ACI의 roledn 부분을 평가하기 위해 서버는 대상 항목에 저장된 ou 속성 값을 읽고 주제에 이 값을 대체하여 매크로를 확장합니다. 이 예에서 roledn은 다음과 같이 확장됩니다.

roledn = "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,
dc=example,dc=com"

그런 다음 Directory Server는 일반 ACI 평가 알고리즘에 따라 ACI를 평가합니다.

매크로에 지정된 속성이 여러 값을 갖는 경우 각 값을 차례로 사용하여 매크로를 확장하며 처음 일치하는 항목을 제공한 값이 사용됩니다.

액세스 제어 및 복제

ACI는 항목의 속성으로 저장되므로 ACI가 포함된 항목이 복제된 접미어의 일부일 경우 ACl도 다른 속성과 마찬가지로 복제됩니다.

ACI는 항상 받는 LDAP 요청을 처리하는 디렉토리 서버에서 평가됩니다. 따라서 업데이트 요청이 수신되면 소비자 서버는 마스터 서버에서 이 요청을 처리할 수 있는지 여부를 평가하기 전에 마스터 서버에 대한 참조를 반환합니다.

액세스 제어 및 연결

연결을 사용하여 여러 서버에 디렉토리 트리를 배포하는 경우 액세스 제어 명령문에서 사용할 수 있는 키워드에 몇 가지 제한이 적용됩니다. 자세한 내용은 ACI 제한을 참조하십시오.

인증된 사용자가 연결 접미어에 액세스하면 서버는 이 사용자의 아이디를 원격 서버로 보냅니다. 액세스 제어는 항상 원격 서버에서 평가됩니다. 원격 서버에서 평가되는 모든 LDAP 작업은 프록시 인증 제어를 통해 전달된 클라이언트 응용 프로그램의 원래 아이디를 사용합니다. 사용자에게 원격 서버의 하위 트리에 대한 올바른 액세스 제어가 있을 경우에만 원격 서버 작업이 제대로 수행됩니다. 따라서 다음과 같은 몇 가지 제한을 고려하여 원격 서버에 일반적인 액세스 제어를 추가할 필요가 있습니다. 자세한 내용은 연결 접미어를 통한 액세스 제어를 참조하십시오.

액세스 제어 로깅 정보

오류 로그에서 액세스 제어에 대한 정보를 얻으려면 적절한 로그 수준을 설정해야 합니다.

이전 릴리스와의 호환성

Directory Server의 이전 릴리스에서 사용되었던 일부 ACI 키워드는 Directory Server 5.2에서 더 이상 사용되지 않습니다. 하지만 이전 버전과의 호환성을 위해 이러한 키워드도 계속 지원됩니다. 예를 들면 다음과 같습니다.

따라서 레거시 공급업체 서버와 소비자 Directory Server 5.2 간에 복제 계약을 설정한 경우에도 ACI 복제 시 문제가 발생하지 않습니다.

하지만 값 일치에 따른 액세스 정의에 설명된 것처럼 이러한 키워드는 userattr 키워드의 기능으로 바꾸는 것이 좋습니다.

이전 목차 색인 다음
Sun Java(TM) System Directory Server 5 2004Q2 관리 설명서