Sun ONE logo      이전      목차      색인      다음     

Sun ONE Web Server 6.1 관리자 설명서

9 장
서버 액세스 제어

이 장에서는 Administration Server와 웹 사이트의 파일 또는 디렉토리에 대한 액세스를 제어하는 다양한 방법에 대하여 설명합니다. 예를 들어 Administration Server의 경우 컴퓨터에 설치된 모든 서버를 모두 제어할 수 있는 사람과 하나 이상의 서버를 부분적으로 제어할 수 있는 사람을 지정할 수 있습니다. Administration Server에 대한 액세스 제어를 사용하기 전에 반드시 분산 관리를 사용하도록 설정하고 LDAP 데이터베이스에 관리 그룹을 설정해야 합니다. 이 장에서는 이미 분산 관리를 구성했으며 LDAP 데이터베이스에 사용자 및 그룹을 정의한 것으로 가정합니다.

또한 제 4장, "웹 컨테이너 및 웹 응용 프로그램용 J2EE 기반 보안"과 제 6장, "인증서 및 키 사용"에 설명한 것과 같이 웹 서버가 보안되었는지 확인해야 합니다.

이 장의 내용:

액세스 제어 설명

액세스 제어를 사용하여 다음을 결정할 수 있습니다.

서버의 전체 또는 일부, 또는 웹 사이트의 파일 또는 디렉토리에 대한 액세스를 제어할 수 있습니다. ACE(Access Control Entry)라는 규칙의 계층을 만들어 액세스를 허용하거나 거부할 수 있습니다. 각 ACE는 서버가 계층의 다음 ACE를 확인할 것인지의 여부를 지정합니다. 만드는 ACE의 컬렉션은 ACL(Access-control List)이라고 합니다.

기본으로 서버에는 하나의 ACL 파일이 있으며 여기에는 여러 개의 ACL이 있습니다. 입중계 요청용 가상 서버가 결정된 후, Sun ONE Web Server는 해당 가상 서버용으로 구성된 ACL이 있는지 확인합니다. 현재 요청에 대하여 적용되는 ACL이 있는 경우 Sun ONE Web Server는 ACE를 평가하여 액세스를 허용할 것인지 또는 거부할 것인지 결정합니다.

다음을 기준으로 액세스를 허용 또는 거부합니다.

사용자-그룹용 액세스 제어 설정

웹 서버에 대한 액세스를 특정 사용자 또는 그룹으로 제한할 수 있습니다. 사용자-그룹 액세스 제어를 사용하려면 사용자가 해당 서버에 액세스하기 전에 사용자 이름과 비밀번호를 입력해야 합니다. 서버는 클라이언트 인증서에 있는 정보, 또는 클라이언트 인증서 자체를 디렉토리 서버 항목과 비교합니다.

Administration Server는 오직 기본 인증만 사용합니다. Administration Server에 클라이언트 인증이 필요하도록 하려면 반드시 obj.conf의 ACL 파일을 직접 편집하여 방법을 SSL로 변경해야 합니다.

서버 인스턴스용 사용자-그룹 인증 방법:

이들 방법에는 모두 디렉토리 서버가 필요합니다.

사용자-그룹 인증의 경우 사용자가 Administration Server에 액세스하거나 웹 사이트의 파일 및 디렉토리에 액세스하기 전에 자신의 신분을 증명해야 합니다. 인증 과정에서 사용자는 사용자 이름과 비밀번호를 입력하거나 클라이언트 인증서 또는 다이제스트 인증 플러그인을 사용하여 자신의 신분을 증명합니다. 클라이언트 인증서를 사용하려면 암호화가 필요합니다. 암호화 및 클라이언트 인증서 사용에 대한 자세한 내용은 제 4장, "웹 컨테이너 및 웹 응용 프로그램용 J2EE 기반 보안""을 참조하십시오

Default 인증

Default 인증은 가장 많이 사용되는 방법입니다. Default 설정은 obj.conf에 지정한 기본 방법을 사용하거나, obj.conf에 설정이 없는 경우에는 "Basic"을 사용합니다. Default를 선택하는 경우 ACL 규칙은 ACL 파일에 메소드를 지정하지 않습니다. Default를 선택하는 경우 obj.conf 파일에서 한 줄만 편집하면 모든 ACL에 대한 메서드를 쉽게 변경할 수 있습니다.

Basic 인증

Basic 인증의 경우 사용자가 웹 서버 또는 웹 사이트에 액세스하기 위한 사용자 이름과 암호를 입력해야 합니다. 이 설정이 기본값입니다. 반드시 사용자 및 그룹의 목록을 만들고 이를 Sun ONE Directory Server 등의 LDAP 데이터베이스에 저장해야 합니다. 반드시 웹 서버와 다른 루트 디렉토리에 설치된 디렉토리 서버 또는 원격 컴퓨터에 설치된 디렉토리 서버를 사용해야 합니다.

Administration Server 또는 웹 사이트에서 사용자-그룹 인증이 있는 리소스에 액세스하려는 경우 웹 브라우저에 사용자 이름과 비밀번호를 입력하라는 대화 상자가 표시됩니다. 서버에서 암호화 기능이 사용되는지의 여부에 따라 이 정보는 암호화 또는 암호화되지 않은 형태로 서버에 입력됩니다.

참고

SSL 암호화가 없는 Basic 인증을 사용하는 경우 사용자 이름과 비밀번호가 암호화되지 않은 텍스트로 네트워크에 전송됩니다. 이 네트워크 패킷은 포착될 수 있으며 사용자 이름과 암호가 도용될 수 있습니다. Basic 인증은 SSL 암호화나 Host-IP 인증, 또는 이 둘 모두와 함께 사용할 때 가장 효과적입니다. Digest 인증을 사용하면 이 문제를 피할 수 있습니다.

사용자가 서버에 자신의 신분을 인증하면 다음 대화상자가 표시됩니다.

확인을 누르면 다음이 표시됩니다.

Access Denied Response 페이지에서 허가되지 않은 사용자에게 표시되는 액세스 거부 메시지를 사용자 정의할 수 있습니다.

SSL 인증

서버가 보안 인증서가 있는 사용자의 신분을 확인하는 방법은 두 가지입니다.

서버가 클라이언트 인증용으로 인증서 정보를 사용하도록 설정하면 서버는 다음의 작업을 합니다.

특정 리소스에 대한 액세스를 제어하는 용도로 필요한 클라이언트 인증은 서버에 대한 모든 연결에 대하여 클라이언트 인증을 요구하는 것과 다릅니다. 모든 연결에 대하여 서버가 클라이언트 인증을 요구하도록 설정한 경우 클라이언트는 단지 신뢰된 CA가 발행한 유효한 인증서만 제시하면 됩니다. 서버의 액세스 제어가 사용자 및 그룹 인증용 SSL 방법을 사용하도록 설정하는 경우 클라이언트는 다음의 작업을 해야 합니다.

액세스 제어와 함께 클라이언트 인증을 요구하는 경우 웹 서버용 SSL 암호를 사용하도록 설정해야 합니다. SSL을 사용하도록 하는 방법은 제 6장, "인증서 및 키 사용"을 참조하십시오.

SSL 인증이 요구되는 리소스에 성공적으로 액세스하려면 반드시 웹 서버가 신뢰하는 CA로부터 클라이언트 인증서를 발행되어야 합니다. 서버의 certmap.conf 파일이 브라우저에 있는 클라이언트 인증서를 디렉토리 서버에 있는 클라이언트 인증서와 비교하도록 구성된 경우에는 클라이언트 인증서가 디렉토리 서버 내에 게시되어야 합니다. 그러나 certmap.conf 파일은 인증서의 선택된 정보만 디렉토리 서버 항목과 비교되도록 구성할 수 있습니다. 예를 들어 브라우저 인증서에 있는 사용자 아이디와 메일 주소만 디렉토리 서버 항목과 비교하도록 certmap.conf 파일을 구성할 수 있습니다. certmap.conf와 인증서 매핑에 대한 자세한 내용은 제 6장, "인증서 및 키 사용"을 참조하십시오.

참고

오직 SSL 인증 방법의 경우에는 인증서가 LDAP 디렉토리에 대하여 확인되므로, 이 방법의 경우에만 certmap.conf 파일을 변경해야 합니다. 서버로의 모든 연결에 대하여 클라이언트 인증이 요구되는 경우에는 이 파일을 변경할 필요가 없습니다. 클라이언트 인증서를 사용하도록 선택한 경우 magnus.conf의 AcceptTimeout 지시문 값을 올려야 합니다.

Digest 인증

Digest 인증을 사용하면 사용자 이름과 비밀번호를 보통 텍스트로 보내지 않고 사용자 이름 및 비밀번호를 기반으로 인증할 수 있습니다. 브라우저는 MD5 알고리즘을 이용하여 Web Server가 제공하는 사용자의 비밀번호 및 일부 정보를 사용하는 다이제스트 값을 만듭니다. 다이제스트 값은 또한 Digest Authentication 플러그인을 사용하는 서버 측에서도 계산되며 이 값은 클라이언트가 제공하는 다이제스트 값과 비교됩니다. 다이제스트 값이 일치하면 사용자가 인증됩니다.

이렇게 하려면 디렉토리 서버가 보통 텍스트의 사용자 비밀번호에 액세스해야 합니다. Sun ONE Directory Server에는 역변환 가능한 비밀번호 플러그인이 있으며, 이는 데이터를 암호화된 형태로 저장하여 나중에 원래의 형태로 해독할 수 있는 대칭 암호화 알고리즘을 사용합니다. 오직 Directory Server만이 데이터의 키를 보유합니다.

Digest 인증의 경우 Sun ONE Web Server 6.1에 포함된 역전환 가능 비밀번호 플러그인과 disgestauth 특정 플러그인을 사용하도록 설정해야 합니다. 서버가 다이제스트 인증을 처리하도록 구성하려면 dbswitch.conf에 있는 데이터베이스의 digestauth 속성을 설정해야 합니다.

서버는 그림 에 보이는 것과 같이 지정된 ACL 방법에 기반하여 LDAP 데이터베이스에 대한 인증을 시도합니다. ACL 방법을 지정하지 않으면, 서버는 인증이 요구되는 경우 digest 또는 basic을 사용하며 인증이 요구되지 않는 경우 basic을 사용합니다. 이것이 가장 많이 사용되는 방법입니다.

표 9-1) Digest 인증 질문 생성

ACL 방법

인증 데이터베이스가 지원하는 다이제스트 인증

인증 데이터베이스가 지원하지 않는 다이제스트 인증

"default"

지정된 사항 없음

digest 및 basic

basic

"basic"

basic

basic

"digest"

digest

ERROR

method=digest로 설정된 ACL을 처리하는 경우 서버는 다음과 같이 인증을 시도합니다.

UNIX에 Digest Authentication 플러그인 설치

Digest Authentication 플러그인은 다음의 모두에 있는 공유 라이브러리로 구성됩니다.

UNIX에 Digest Authentication 플러그인을 설치하려면 다음과 같이 합니다.

  1. 이 공유 라이브러리가 Sun ONE Directory Server를 설치한 동일한 서버 컴퓨터에 있는지 확인합니다.
  2. Directory Manager 비밀번호가 올바른지 확인합니다.
  3. libdigest-plugin.ldif 파일의 /path/to에 대한 모든 참조를 다이제스트 플러그인 공유 라이브러리를 설치한 위치로 변경합니다.
  4. 플러그인을 설치하려면 다음 명령을 입력합니다.

    5. % ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif

Windows에 Digest Authentication 플러그인 설치

Sun ONE Directory Server가 Digest 플러그인과 함께 적절히 시작되려면 여러 개의 .dll 파일을 Sun ONE Web Server 설치 위치에서 Sun ONE Directory Server 컴퓨터로 복사해야 합니다.

Windows에 Digest Authentication 플러그인을 설치하려면 다음과 같이 합니다.

  1. 다음의 Sun ONE Web Server 설치 위치에 있는 공유 라이브러리에 액세스합니다.

    2. [server_root]\bin\https\bin

  2. 다음 파일을 복사합니다.
    • nsldap32v50.dll
    • libspnr4.dll
    • libplds4.dll
  3. 복사한 하일을 다음 중 한 곳에 붙여넣습니다.
    • \Winnt\system32
    • Sun ONE Directory Server 설치 디렉토리: [server_root]\bin\sldap\server
DES 알고리즘 사용을 위한 Sun ONE Directory Server 설정

다이제스트 비밀번호가 저장된 위치의 속성을 암호화하려면 DES 알고리즘이 필요합니다.

DES 알고리즘을 사용하도록 Sun ONE Directory Server를 설정하려면 다음과 같이 합니다.

  1. Sun ONE Directory Server Console을 시작합니다.
  2. iDS 5.0 인스턴스를 엽니다.
  3. Configuration 탭을 선택합니다.
  4. 플러그인 옆의 + 기호를 누릅니다.
  5. DES 플러그인을 선택합니다.
  6. Add를 선택하여 새 속성을 추가합니다.
  7. iplanetReversiblePassword를 입력합니다.
  8. Save를 누릅니다.
  9. Sun ONE Directory Server 인스턴스를 재시작합니다.

    참고

    사용자용 iplanetReversiblePassword 속성의 다이제스트 인증 비밀번호를 설정하려면 항목에 반드시 iplanetReversiblePasswordobject 개체가 포함되어야 합니다.

Other 인증

액세스 컨트롤 API를 사용하여 사용자 정의 메소드를 만들 수 있습니다.

Host-IP용 액세스 제어 설정

Administration Server 또는 웹 사이트의 파일 및 디렉토리를 특정 컴퓨터를 이용하는 사용자만 사용할 수 있도록 설정하여 이에 대한 액세스를 제한할 수 있습니다. 허용 또는 거부하려는 컴퓨터용 호스트이름 또는 IP 주소를 지정합니다. 여러 대의 컴퓨터 또는 전체 네트워크를 지정하려면 와일드카드 패턴을 사용합니다. Host-IP 인증을 사용하는 파일 또는 디렉토리 액세스는 사용자가 알 수 없게 진행됩니다. 사용자는 사용자이름이나 비밀번호를 입력하지 않고 즉시 파일과 디엑토리에 액세스할 수 있습니다.

여러 사람이 특정 컴퓨터를 사용할 수 있으므로 Host-IP 인증은 사용자-그룹 인증과 함께 사용할 때 더욱 효과적입니다. 두 가지 인증 방법이 모두 사용되는 경우 액세스할 때 사용자이름과 비밀번호가 필요합니다.

Host-IP 인증의 경우 서버에서 DNS를 구성할 필요가 없습니다. Host-IP 인증을 선택한 경우 반드시 DNS가 네트워크에서 실행되어야 하며 서버가 이를 사용하도록 구성되어야 합니다. 서버의 DNS는 Server Manager의 Preferences 탭에 있는 Performance Tuning 페이지에서 사용하도록 설정할 수 있습니다.

DNS를 사용하도록 설정하면 서버가 DNS 조회를 수행해야 하므로 Sun ONE Web Server의 성능이 낮아집니다. DNS 조회가 서버 성능에 미치는 영향을 낮추려면 모든 요청의 IP 주소를 변환하는 대신 오직 액세스 제어 및 CGI용 IP 주소만 변환합니다. 이렇게 하려면 obj.conf 파일에 있는 "AddLog fn="flex-log" name="access"의 iponly=1로 설정합니다.

액세스 제어 파일 사용

Administration Server 또는 웹 사이트의 파일이나 디렉토리에서 액세스 제어를 사용하는 경우 해당 설정은 확장자가 .acl인 파일에 저장됩니다. 액세스 제어 파일은 install_dir/httpacl에 저장되며 install_dir은 서버가 설치된 위치입니다. 예를 들어 서버를 /user/Sun/Servers에 설치한 경우 Administration Server와 서버에 구성된 각 서버 인스턴스용 ACL 파일의 위치는 /usr/Sun/Servers/httpacl/입니다.

기본 ACL 파일 이름은 generated-htpps-server-id.acl이며, 임시 작동 파일의 이름은 genwork-https-server-id.acl. Sun ONE Administration Server를 사용하여 액세스를 구성하는 경우 이 두 파일이 만들어집니다. 그러나 제한을 더욱 복잡하게 하려면 여러 개의 파일을 만들고 server.xml 파일에서 이들 파일을 참조합니다. 또한 하루 중 시간 또는 요일을 기준으로 서버에 대한 액세스를 제한하는 등, 파일을 편집할 때에만 사용할 수 있는 몇 가지 기능이 있습니다.

또한 직접 .acl 파일을 만들고 편집하여 API를 사용하는 액세스 제어를 사용자 정의할 수 있습니다. 액세스 제어 API를 사용하는 데 대한 자세한 내용은 Programmer's Guide를 참조하십시오.

액세스 제어 파일과 구문에 대한 자세한 정보는 부록 C, ""을 참조하십시오.

ACL 사용자 캐시 구성

기본적으로 Sun ONE Web Server는 사용자 및 그룹 인증 결과를 ACL 사용자 캐시에 캐시합니다. magnus.conf 파일의 ACLCacheLifetime 지시문을 사용하여 ACL 사용자 캐시의 유효 시간을 조정할 수 있습니다. 캐시에 있는 항목이 참조될 때마다 시간이 계산되고 ACLCacheLifetime과 비교됩니다. 항목의 시간이 ACLCacheLifetime과 같거나 크면 해당 항목은 사용되지 않습니다. 디폴트 값은 120 초입니다. 값을 0으로 설정하면 캐시가 Off로 설정됩니다. 이 값에 큰 값을 사용하면 LDAP 항목을 변경할 때마다 Sun ONE Web Server를 다시 시작해야 합니다. 예를 들어 이 값을 120초로 설정하는 경우 최대 2분까지 Sun ONE Web Server가 LDAP 디렉토리와 동기화되지 않을 수 있습니다. LDAP 디렉토리가 자주 변경되지 않는 경우에만 큰 값을 사용하십시오.

ACLUserCacheSize의 magnus.conf 매개변수를 사용하여 캐시에 유지할 항목의 최대 수를 구성할 수 있습니다. 이 매개 변수의 기본값은 200입니다. 새 항목은 목록의 앞에 추가되며 목록의 끝에 있는 항목은 재활용되어 캐시가 최대 크기에 도달하면 새로운 항목이 됩니다.

또한 magnus.conf 매개변수 ACLGroupCacheSize를 사용하여 각 사용자 항목마다 캐시될 수 있는 그룹 구성원의 최대 수를 설정할 수 있습니다. 이 매개 변수의 기본값은 4입니다. 유감스럽게도 그룹에 있는 사용자가 구성원이 아닌 경우 캐시되지 않으며, 요청마다 여러 LDAP 디렉토리 액세스가 발생하게 됩니다.

ACL 파일 지시문에 대한 자세한 내용은 NSAPI Programmer's Guide를 참조하십시오.

액세스 제어 작동 원리

서버에 페이지에 대한 요청이 수신되면 서버는 ACL 파일에 있는 규칙을 사용하여 액세스를 허용할지 결정합니다. 규칙은 요청을 보내는 컴퓨터의 호스트이름 또는 IP 주소를 참조할 수 있습니다. 또한 LDAP 디렉토리에 저장된 사용자 및 그룹을 참조할 수 있습니다.

예를 들어 ACL 파일에 Administration Server(admin-serv)용 기본 항목이 두 개이며, 이에 더하여 admin-reduced 그룹에 있는 사용자가 Administration Server의 Preferences 탭에 액세스하도록 허용하는 경우를 들 수 있습니다.

 

version 3.0;

# The following "es-internal" rules protect files such

# as icons and images related to Sun ONE Web Server.

# These "es-internal" rules should not be modified.

  acl "es-internal";

  allow (read, list, execute,info) user = "anyone";

  deny (write, delete) user = "anyone";

# The following "default" rules apply to the entire document

# directory of Sun ONE Web Server. In this example, the rules

# are set up so that "all" users in the directory server are

# allowed to read, execute, list, and get information.

# The "all" users are not allowed to write to or delete any files.

# All clients that accesses the document directory of the web

# server will be required to submit a username and password

# since this example is using the "basic" method of

# authentication. A client must be in the directory server

# to gain access to this default directory since "anyone"

# not in the directory server is denied, and "all" in the

# directory server are allowed.

  acl "default";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (user = "all");

# The following rules deny access to the directory "web"

# to everyone not in the directory server and deny everyone

# in the directory server who is not in GroupB.

# Only the users in GroupB are allowed read, execute, list,

# and info permissions. GroupA can not gain access to the

# directory "web" even though (in the ACL rule below) they

# can access the directory “my_stuff”. Furthermore, members

# of GroupB can not write or delete files.

  acl "path=/export/user/990628.1/docs/my_stuff/web/";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

 

  allow (read,execute,list,info)

  (group = "GroupB");

 

# The following rule denies everyone not in the directory

# server and denies everyone in the directory server except

# user with the 아이디 of "SpecificMemberOfGroupB". The ACL rule

# in this setting also has a requirement that the user

# connect from a specific IP address. The IP address setting

# in the rule is optional; it has been added to for extra

# security. Also, this ACl rule has a Customized prompt

# of "Presentation Owner". This Customized prompt appears

# in the username and password dialog box in the client's

# browser.

 

  acl "path=/export/user/990628.1/docs/my_stuff/web/presentation.html";

  authenticate (user,group) {

     database = "default";

     method = "basic";

     prompt = "Presentation Owner";

  };

  deny (all)

  (user = "anyone" or group = "my_group");

  allow (all)

  (user = "SpecificMemberOfGroupB") and

  (ip = "208.12.54.76");

 

# The following ACL rule denies everyone not in the directory

# server and everyone in the directory server except for

# GroupA and GroupB access to the directory “my_stuff”

  acl "path=/export/user/990628.1/docs/my_stuff/";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (group = "GroupA,GroupB");

 

예를 들어 사용자가 다음 URL을 요청하는 경우, http://server_name/my_stuff/web/presentation.html

Sun ONE Web Server는 우선 전체 서버에 대한 액세스 제어를 확인합니다. 전체 서버용 ACL이 계속으로 설정된 경우 서버는 my_stuff 디렉토리용 ACL을 확인합니다. ACL이 존재하면 서버는 ACL에 있는 ACE를 확인한 후, 다음 디렉토리로 이동합니다. 이 프로세스는 액세스를 거부하는 ACL이 발견되거나 요청된 URL에 대한 마지막 URL(이 경우에는 presentation.html 파일)에 도달할 때까지 계속됩니다.

Server Manager를 이용하여 이 예제의 액세스 제어를 설정하려면 파일 전용 또는 파일로 유도되는 각 리소스용 ACL을 만들 수 있습니다. 즉, 전체 서버용 1개, my_stuff 디렉토리용 1개, my_stuff/web 디렉토리용 1개 및 해당 파일용 1개를 만들 수 있습니다.

참고

일치되는 ACL이 하나 이상인 경우 서버는 일치되는 마지막 ACL문을 사용합니다. 일치되는 ACL이 uri이므로 default ACL은 무시됩니다.

액세스 제어 설정

여기에서는 웹 사이트의 파일 또는 디렉토리에 대한 액세스를 제한하는 프로세스에 대하여 설명합니다. 모든 서버에 대한 전역 액세스 제어 규칙을 만들 수 있으며, 또한 특정 서버에 대한 개별 규칙을 만들 수 있습니다. 예를 들어 인력관리 부서에서는 모든 인증된 사용자가 자신의 연봉 데이터를 볼 수 있으나 오직 인력관리 부서의 연봉을 담당하는 직원만 데이터를 액세스할 수 있도록 제한하는 ACL을 만들 수 있습니다.

Administration Server를 통하여 모든 서버에 대한 액세스를 전역적으로 제어할 수 있습니다. 각 옵션은 뒤의 액세스 제어 옵션 선택 부분에서 자세히 설명합니다.

참고

전역 액세스 제어를 만들기 전에 반드시 분산 관리를 구성하고 사용해야 합니다.

전역적 액세스 제어 설정

모든 서버에 대한 액세스 제어를 전역적으로 만들고 편집하려면 다음과 같이 합니다.

  1. Administration Server에 액세스하고 Global Settings 탭을 선택합니다.
  2. Restrict Access 링크를 누릅니다.
  3. 드롭 다운 목록에서 administration server(https-admserv)를 선택합니다.
  4. Create ACL을 누르고 Go 버튼을 누릅니다.

    5. uri=/https-admserv/용 Access Control Rules 페이지가 표시됩니다.

    Access Control Rules 페이지.



    Administration Server에는 편집할 수 없는 기본 액세스 제어 규칙이 두 줄 있습니다.

  5. Access 제어가 아직 선택되지 않았으면 ON으로 선택합니다.
  6. 표의 하단에 기본 ACL 규칙을 추가하려면 New Line 버튼을 누릅니다.

    7. 액세스 제어 제한이 앞에 오도록 액세스 제어 제한을 스왑하려면 위쪽 화살표 그림을 누릅니다.

    액세스 제어 제한이 뒤에 오도록 액세스 제어 제한을 스왑하려면 아래쪽 화살표 그림을 누릅니다.

  7. Users/Groups 열에서 임의의 항목을 누릅니다.

    8. User/Group 페이지가 아래 창에 표시됩니다.

    User/Group 페이지


    User/Group 페이지는 그림에 보이는 것과 같습니다.

  8. 액세스를 허용할 사용자 및 그룹을 선택하고 Update를 누릅니다.

    9. List for Group and User를 누르면 선택할 수 있는 목록이 표시됩니다.

  9. From Host 열에서 아무 곳이나 누릅니다.
  10. 액세스가 허용된 Host Name 및 IP Address를 입력한 후 Update를 누릅니다.
  11. Programs 열의 프로그램을 모두 누릅니다.

    12. Programs


    Programs 페이지는 그림에 보이는 것과 같습니다.

  12. 액세스를 허용할 Program Groups를 선택하거나 Program Items 필드에 특정 파일 이름을 입력합니다.
  13. (선택) 사용자 정의 ACL 표현식을 추가하려면 Extra 열 아래의 x를 누릅니다.
  14. Continue 열이 아직 선택되지 않았으면 이 열의 선택란을 선택합니다.

    15. 서버는 사용자의 액세스가 허용되었는지 결정하기 전에 다음 줄을 확인합니다. 여러 줄을 만드는 경우에는 가장 일반적인 제한에서 가장 국부적인 제한으로 진행합니다.

  15. (선택) 거부된 경우 사용자를 다른 URL 또는 URI로 재설정하려면 Response를 누릅니다.
  16. 절대 URL 또는 상대 URI에 대한 경로를 입력하고 Update를 누릅니다.
  17. Submit를 눌러 새 액세스 제어 규칙을 ACL 파일에 저장합니다.

    참고

    Revert를 누르면 지금 만든 모든 설정이 제거됩니다.

서버 인스턴스용 액세스 제어 설정

Server Manager를 사용하여 특정 서버 인스턴스용 액세스 제어를 만들거나 편집 또는 삭제할 수 있습니다.

참고

삭제하는 경우 ACL 파일에서 ACL 규칙을 모두 삭제하면 안 됩니다. 서버를 시작하려면 ACL 규칙을 한 개 이상 포함하는 ACL 파일이 적어도 하나 이상 있어야 합니다. ACL 규칙을 모두 삭제하고 서버를 재시작하면 구문 오류가 발생합니다.

서버 인스턴스용 액세스 제어를 만들려면 다음과 같이 합니다.

  1. Server Manager에 액세스하고 ACL을 만들거나 편집하려는 서버 인스턴스를 선택합니다.
  2. Server Manager에서 Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. Option 열 아래에서 다음 중 한 가지를 선택합니다.
    • ACL 파일 위치 추가 및 입력
    • 드롭다운 목록에서 ACL 파일 편집 및 선택
    • 드롭다운 목록에서 ACL 파일 삭제 및 선택

      • Access Control List Management 페이지에 제공되는 옵션은 세 가지입니다.

      Access Control List Management 페이지


      Access Control List Management 페이지 창은 그림에 보이는 것과 같습니다.

  5. 다음 중 한 가지를 선택합니다.
    • 파일 또는 디렉토리용 와일드카드 패턴(*.html 등)을 지정하는 리소스를 선택하거나, 제한할 디렉토리 또는 파일 이름을 선택하거나, 파일 또는 디렉토리를 찾습니다.
    • 사용하도록 설정한 모든 ACL 목록에서 기존 ACL을 선택합니다. 사용하도록 설정하지 않은 기존 ACL은 목록에 표시되지 않습니다.
    • Enter the ACL name을 사용하여 이름이 지정된 ACL을 만들 수 있습니다. 이 옵션은 ACL 파일에 익숙한 경우에만 사용하십시오. 이름이 지정된 ACL을 리소스에 적용하려는 경우에는 obj.conf를 직접 편집해야 합니다.

      • 사용할 수 있는 리소스 와일드카드는 표8-2에 설명된 것과 같습니다.

      표 9-2) 서버 리소스 와일드카드

      리소스 와일드카드

      의미

      default

      설치시 만들어진 이름이 지정된 ACL로 쓰기 액세스를 제한하므로 오직 LDAP 디렉토리에 있는 사용자만 문서를 게시할 수 있습니다.

      Entire Server

      전체 웹 사이트에 대한 액세스를 결정하는 규칙 세트로 실행하는 모든 가상 서버가 포함됩니다. 가상 서버에 대한 액세스를 제한하려면 해당 문서 루트의 경로를 지정합니다.

      /usr/sun/server4/docs/cgi-bin/*

      cgi-bin 디렉토리의 모든 파일 및 디렉토리에 대한 액세스를 제어합니다. 반드시 절대 경로를 지정해야 합니다. Windows의 경우 경로에 반드시 드라이브 문자가 포함되어야 합니다.

      uri=“/sales”

      문서 루트의 sales 디렉토리에 대한 액세스를 제어합니다. URI를 지정하려면 이름이 지정된 ACL을 만듭니다.

  6. Edit Access Control을 누릅니다.

    7. (서버 인스턴스)용 Access Control Uules가 표시됩니다.

    Access Control Rules 페이지


    액세스 제어 규칙 페이지는 그림에 보이는 것과 같습니다.

  7. Access 제어가 아직 선택되지 않았으면 ON으로 선택합니다.
  8. 이 서버 인스턴스용 ACL을 만들거나 편집하려면 Action 열의 Deny를 누릅니다.

    9. Allow/Deny 페이지가 아래의 창에 표시됩니다.

    Allow/Deny 페이지


    Allow/Deny 페이지는 그림에 보이는 것과 같습니다.

  9. Allow가 아직 기본값으로 선택되지 않았으면 선택하고 Update를 누릅니다.
  10. Users/Groups 열에서 임의의 항목을 누릅니다.

    11. User/Group 페이지가 아래 창에 표시됩니다.

    User/Group 페이지


    User/Group 페이지는 그림에 보이는 것과 같습니다.

  11. 액세스를 허용할 사용자 및 그룹을 선택하고 Update를 누릅니다.

    12. List for Group and User를 누르면 선택할 수 있는 목록이 표시됩니다.

  12. From Host 열에서 아무 곳이나 누릅니다.
  13. 액세스가 허용된 Host Name 및 IP Address를 입력한 후 Update를 누릅니다.
  14. Rights 열의 항목을 모두 누릅니다.

    15. Access Rights 페이지


    Access Rights 페이지는 그림에 보이는 것과 같습니다.

  15. 다음 중 한 가지를 선택하고 Update를 누릅니다.
    • All Access Rights
    • Only the following rights - 사용자에게 적절한 모든 권한을 선택
  16. (선택) 사용자 정의 ACL 표현식을 추가하려면 Extra 열 아래의 x를 누릅니다.
  17. Continue 열이 아직 선택되지 않았으면 이 열의 선택란을 선택합니다.

    18. 서버는 사용자의 액세스가 허용되었는지 결정하기 전에 다음 줄을 확인합니다. 여러 줄을 만드는 경우에는 가장 일반적인 제한에서 가장 국부적인 제한으로 진행합니다.

  18. (선택) 거부된 경우 사용자를 다른 URL 또는 URI로 재설정하려면 Response를 누릅니다.
  19. 절대 URL 또는 상대 URI에 대한 경로를 입력하고 Update를 누릅니다.
  20. Submit를 눌러 새 액세스 제어 규칙을 ACL 파일에 저장합니다.

    21. 참고

    Revert를 누르면 지금 만든 모든 설정이 제거됩니다.

  21. 액세스 제어를 설정하려는 각 서버 인스턴스마다 위의 단계를 반복합니다.
  22. 작업이 완료되면 Apply를 누릅니다.
  23. 하드 스타트/리스타트를 선택하거나 동적으로 적용합니다.

ACL 설정은 가상 서버 단위로 사용 설정할 수 있습니다. 이에 대한 방법은 "가상 서버용 액세스 제어 목록 편집"을 참조하십시오.

액세스 제어 옵션 선택

다음에서는 액세스 제어를 설정할 때 선택할 수 있는 다양한 옵션에 대하여 설명합니다. Administration Server의 경우 첫 두 줄은 기본으로 설정되며 편집할 수 없습니다.

작동 설정

요청이 액세스 제어 규칙과 일치할 때 서버의 작동을 지정할 수 있습니다.

서버는 ACE(access control expression) 목록 전체를 확인하여 액세스 권한을 판단합니다. 예를 들어 첫 번째 ACE는 보통 모든 사용자를 거부합니다. 첫 번째 ACE가 "continue"로 설정된 경우 서버는 목록의 두 번째 ACE를 확인하며, 일치되는 경우 다음 ACE를 사용합니다. continue가 선택되지 않은 경우 리소스에 대한 모든 사용자의 액세스가 거부될 것입니다. 서버는 일치되지 않는 ACE가 발견되거나 일치되지만 continue가 설정되지 않은 ACE를 발견할 때까지 계속합니다. 마지막으로 일치되는 ACE에 따라 액세스의 허용 또는 거부가 결정됩니다.

사용자 및 그룹 지정

사용자 및 그룹 인증을 사용하면 사용자가 액세스 제어 규칙에 지정된 리소스에 액세스하기 전에 사용자이름 및 비밀번호를 입력하라는 프롬프트가 표시됩니다.

Sun ONE Web Server는 Sun ONE Directory Server 등의 LDAP 서버에 저장된 사용자 및 그룹 목록을 확인합니다.

데이터베이스에 있는 모든 사용자의 액세스를 허용 또는 거부할 수 있으며, 와일드카드 패턴을 사용하여 특정 사용자를 허용 또는 거부할 수 있습니다. 또한 사용자 및 그룹 목록에서 허용 또는 거부할 사용자를 선택할 수 있습니다.

송신 호스트 지정

요청을 보내는 컴퓨터를 기준으로 Administration Server 또는 웹 사이트에 대한 액세스를 제한할 수 있습니다.

Only from 옵션을 선택하면 Host Names 또는 IP Address 필드에 와일드카드 패턴 또는 쉼표로 분리된 목록을 입력합니다. 호스트이름을 기준으로 제한하는 것이 IP 주소를 기준으로 하는 것 보다 유연성이 많습니다. 사용자의 IP 주소가 변경되는 경우 목록을 업데이트할 필요가 없습니다. 그러나 IP 주소를 기준으로 제한하는 것이 더욱 안전한데, 연결된 클라이언트에 대한 DNS 조회가 실패하는 경우 호스트이름 제한은 사용할 수 없습니다.

컴퓨터의 호스트 이름 또는 IP 주소를 검색하는 와일드카드 패턴에는 오직 * 와일드카드만 사용할 수 있습니다. 예를 들어, 특정 도메인에 있는 모든 컴퓨터를 허용 또는 거부하려면 *.sun.com과 같이 해당 도메인의 모든 호스트에 일치하는 와일드카드 패턴을 입력합니다. Administration Server에 액세스하는 수퍼유저용으로 다른 호스트이름 및 IP 주소를 설정할 수 있습니다.

호스트이름의 경우 *는 반드시 이름의 구성요소 전체로 대체되어야 합니다. 즉, *.sun.com은 사용 가능하지만 *users.sun.com은 사용할 수 없습니다. 호스트이름에 *이 있는 경우 반드시 가장 왼쪽 문자이어야 합니다. 예를 들어 *.sun.com은 사용 가능하지만 users.*.com은 사용할 수 없습니다.

IP 주소의 경우 *은 반드시 주소의 전체 바이트로 대체되어야 합니다. 예를 들어 198.95.251.*는 사용 가능하지만 198.95.251.3*는 사용할 수 없습니다. IP 주소에에 *가 있는 경우 반드시 가장 오른쪽 문자이어야 합니다. 예를 들어 198.*는 사용 가능하지만 198.*.251.30은 사용할 수 없습니다.

프로그램에 대한 액세스 제한

프로그램에 대한 액세스는 오직 Administration Server에 의하여 제한될 수 있습니다. 프로그램에 대한 액세스를 제한하면 오직 지정된 사용자만 Server Manager 페이지를 볼 수 있으며 페이지가 해당 서버용으로 구성되었는지 판단할 수 있습니다. 예를 들어 일부 관리자에게 Administration Server의 Users & Groups 부분을 구성할 수는 있으나 Global Settings에는 액세스할 수 없도록 설정할 수 있습니다.

서로 다른 사용자가 서로 다른 기능 영역에 액세스하도록 구성할 수 있습니다. 사용자가 몇 가지 선택된 기능 영역에 액세스하도록 설정되고 해당 사용자가 로그인하면, 오직 해당 사용자에게 액세스를 허용한 기능 영역의 Administration Server만 볼 수 있습니다.

액세스 권한 설정

액세스 권한은 오직 Server Manager가 서버 인스턴스에 대하여 설정합니다. 액세스 권한은 웹 사이트의 파일 및 디렉토리에 대한 액세스를 제한합니다. 액세스 권한의 허용 또는 거부에 더하여 부분적인 액세스 권한을 허용 또는 거부하는 규칙을 지정할 수 있습니다. 예를 들어 사용자에게 파일에 대한 읽기 전용 액세스 권한을 부여하여 정보를 볼 수 있으나 파일을 변경할 수 없도록 합니다.

사용자 정의 표현식 작성

ACL용 사용자 정의 표현식을 입력할 수 있습니다. 오직 ACL 파일의 구문과 구조에 익숙한 경우에만 이 옵션을 선택하십시오. ACL 파일을 편집하거나 사용자 정의 표현식을 만들 때에만 사용할 수 있는 몇 가지 기능이 있습니다. 예를 들어 하루 중 시간, 요일 또는 이 둘 모두를 기준으로 서버에 대한 액세스를 제한할 수 있습니다.

하루 중 시간 및 요일을 기준으로 액세스를 제한하는 사용자 정의 표현식의 예는 다음과 같습니다. 이 예에서는 LDAP 디렉토리에 두 개의 그룹이 있는 것으로 가정하며, "regular" 그룹은 월요일에서 금요일까지 오전8:00에서 오후 5:00 사이에 액세스할 수 있습니다. "critical" 그룹은 항상 액세스할 수 있습니다.

allow (read)
{
(group=regular and dayofweek=”mon,tue,wed,thu,fri”);
(group=regular and (timeofday>=0800 and timeofday<=1700));
(group=critical)
}

유효한 구문과 ACL 파일에 대한 자세한 내용은 부록 C, """과 "obj.conf 내의 ACL 파일 참조" 페이지 460를 참조하십시오.

엑세스 제어 사용 중지

"Access control is on"이라는 옵션을 선택하지 않으면 ACL의 기록을 삭제할 것인지 묻는 프롬프트가 표시됩니다. 확인을 누르면 서버는 ACL 파일에서 해당 리소스용 ACL 항목을 삭제합니다.

ACL을 사용하지 않도록 설정하는 경우 generated-https-server-id.acl 파일의 각 ACL 줄 앞에 # 기호를 삽입하여 이를 주석으로 만듭니다.

Administration Server에서 특정 서버 인스턴스에 대한 액세스 제어를 만들어 사용하며 기타 서버에 대하여는 사용하지 않도록(기본값) 할 수 있습니다. 예를 들어 Administration Server의 Server Manager 페이지에서 모든 액세스를 거부할 수 있습니다. 기타 서버는 기본적으로 분산 관리를 사용하며 액세스 제어는 사용하지 않으므로 관리자는 다른 서버에 액세스하여 구성할 수 있으나 Administration Server는 구성할 수 없습니다.

참고

이 액세스 제어는 분산 관리용으로 설정된 관리자 그룹에 속한 사용자에 추가되는 기능입니다. Administration Server는 우선 해당 사용자(수퍼유저 아님)가 관리자 그룹에 있는지 확인한 후, 액세스 제어 규칙을 평가합니다.

액세스가 거부된 경우의 응답

Sun ONE Web Server에는 액세스가 거부된 경우 "FORBIDDEN: Your client is not allowed access to the restricted object"이라는 기본 메시지가 제공됩니다. 액세스가 거부된 경우 다른 응답 메시지를 선택할 수 있습니다. 또한 각 액세스 제어 개체마다 서로 다른 메시지를 만들 수 있습니다.

특정 ACL용으로 송신하는 메시지를 변경하려면 다음과 같이 합니다.

  1. ACL 페이지의 Response when denied 링크를 누릅니다.
  2. 아래 창에서 Respond with the following file을 선택합니다.
  3. 절대 URL 또는 상대 URI에 대한 경로를 입력하고 Update를 누릅니다.

    4. 반드시 제설정된 URL 또는 URI에 대한 액세스 권한이 있어야 합니다.

  4. Update를 누릅니다.
  5. 위 창에 있는 Submit을 눌러 액세스 제어 규칙을 제출합니다.

서버의 영역에 대한 액세스 제한

여기에서는 웹 서버 및 해당 컨텐츠에 대한 액세스를 제한하는 데 일반적인 제한에 대하여 설명합니다. 각 절차에 대하여 필요한 작업을 단계별로 설명했으나, "서버 인스턴스용 액세스 제어 설정"에 설명한 모든 단계를 완료해야 합니다.

여기에서는 다음 항목에 대해 설명합니다.

전체 서버에 대한 액세스 제한

하위 도메인의 컴퓨터에서 서버에 액세스하도록 호출된 그룹의 사용자에게 액세스를 허용할 하는 경우가 있습니다. 예를 들어 회사 부서의 서버의 경우 사용자가 오직 네트워크의 특정 도메인의 컴퓨터에서 액세스하도록 할 수 있습니다.

서버 인스턴스에 대한 액세스 제어를 설정하는 방법을 사용하여 다음과 같이 설정할 수 있습니다.

  1. Server Manager를 사용하여 서버 인스턴스를 선택합니다.
  2. Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. 편집할 ACL 파일을 선택합니다.
  5. 전체 서버 리소스를 선택하고 Edit Access Control을 누릅니다.
  6. 모두의 액세스를 거부할 새 규칙을 추가합니다.
  7. 특정 그룹의 액세스를 허용하는 다른 규칙을 새로 추가합니다.
  8. 허용할 컴퓨터의 호스트 이름용 와일드카드 패턴을 입력합니다.

    9. 예: *.employee.sun.com

  9. Continue의 선택을 취소합니다.
  10. 변경 사항을 Submit 및 Apply합니다.

디렉토리(경로)에 대한 액세스 제한

사용자가 디렉토리, 또는 그룹의 소유자가 제어하는 해당 하위 디렉토리 및 파일에서 응용 프로그램을 읽거나 실행하도록 허용할 수 있습니다. 예를 들어 프로젝트 관리자는 프로젝트 팀이 검토할 수 있도록 상태 정보를 업데이트할 수 있습니다.

서버의 디렉토리에 대한 액세스를 제한하려면 서버 인스턴스에 대한 액세스 제어 설정 방법을 이용합니다.

  1. Server Manager를 사용하여 서버 인스턴스를 선택합니다.
  2. Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. 편집할 ACL 파일을 선택합니다.
  5. Pick a Resource 부분을 찾아 제한하려는 디렉토리를 선택합니다.

    6. 서버의 문서 루트에 있는 디렉토리가 표시됩니다. 선택하면 Editing 드롭 다운 목록에 해당 디렉토리의 절대 경로가 표시됩니다.

    참고

    서버 루트의 모든 파일을 보려면 Options를 누르고 List files as well as directories를 선택합니다.

  6. Edit Access Control을 누릅니다.
  7. 새 규칙을 만들고 기본 값을 유지하여 기타 위치로부터의 사용자 액세스를 거부합니다.
  8. 특정 그룹의 사용자에게 오직 읽기 및 실행 권한만 허용하는 새 규칙을 만듭니다.
  9. 특정 사용자에게 모든 권한을 허용하는 세 번째 줄을 만듭니다.
  10. 두 번째 및 세 번째 줄의 Continue의 선택을 해제하고 Update를 누릅니다.
  11. 변경 사항을 Submit 및 Apply합니다.

파일 또는 디렉토리의 절대 경로가 docroot 디렉토리에 만들어집니다. ACL 파일의 항목은 다음과 같이 표시됩니다. acl “path=d:\sun\suitespot\docroot1\sales/”;

URI(경로)에 대한 액세스 제한

URI를 사용하여 웹 서버에 있는 단일 사용자의 컨텐츠에 대한 액세스를 제어할 수 있습니다. URI는 서버의 문서 루트 디렉토리에 상대적인 경로 및 파일입니다. 서버의 컨텐츠를 모두(예를 들어 디스크 공간) 자주 옮기거나 이름을 변경하는 경우 URI를 사용하면 해당 컨텐츠를 쉽게 관리할 수 있습니다. 또한 추가의 문서 루트가 있는 경우 액세스 제어를 처리하는 좋은 방법입니다.

URI에 대한 액세스를 제한하려면 서버 인스턴스에 대한 액세스 제어 설정 방법을 이용합니다.

  1. Server Manager를 사용하여 서버 인스턴스를 선택합니다.
  2. Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. ACL 이름 부분의 Type에 제한하려는 URI를 입력합니다.

    5. 예: uri=/my_directory.

  5. Edit Access Control을 누릅니다.
  6. 모든 사용자에게 읽기 액세스를 허용하는 새 규칙을 만듭니다.
  7. 디렉토리의 사용자에게 액세스를 허용하는 새 규칙을 추가로 만듭니다.
  8. 첫 번째 및 두 번째 줄 모두의 Continue를 선택 해제 합니다.
  9. 변경 사항에 대하여 Submit 및 Apply를 누릅니다.

문서 루트에 상대적인 URI용 경로가 만들어집니다. ACL 파일의 항목은 다음과 같이 표시됩니다. acl “uri=/my_directory”;

파일 유형에 대한 액세스 제한

서버 또는 웹 사이트의 파일 유형에 대한 액세스를 제한할 수 있습니다. 예를 들어 오직 지정된 사용자만 서버에서 실행되는 프로그램을 만들 수 있도록 허용할 수 있습니다. 모든 사람이 프로그램을 실행할 수 있으나 오직 그룹의 지정된 사용자만 프로그램을 만들거나 삭제할 수 있습니다.

파일 유형I에 대한 액세스를 제한하려면 서버 인스턴스에 대한 액세스 제어 설정 방법을 이용합니다.

  1. Server Manager를 사용하여 서버 인스턴스를 선택합니다.
  2. Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. Pick a resource 부분에서 Wildcard를 누르고 와일드카드 패턴을 입력합니다.

    5. 예: *.cgi.

  5. Edit Access Control을 누릅니다.
  6. 모든 사용자에게 읽기 액세스를 허용하는 새 규칙을 만듭니다.
  7. 오직 지정된 그룹에게 쓰기 및 삭제 액세스를 허용하는 다른 규칙을 만듭니다.
  8. 변경 사항을 Submit 및 Apply합니다.

파일 유형 제한의 경우 두 줄의 continue 선택란을 모두 선택합니다. 파일에 대한 요청이 수신되면 서버는 우선 해당 하일 유형에 대한 ACL을 확인합니다.

Patchcheck 기능이 obj.conf에 만들어지며, 여기에는 파일 또는 디렉토리용 와일드카드 패턴이 포함될 수 있습니다. ACL 파일의 항목은 다음과 같이 표시됩니다. acl “*.cgi”;

하루 중 시간을 기준으로 액세스 제한

특정 서버에 대하여 또는 지정된 시간 또는 일자 동안 쓰기 및 삭제 액세스를 제한할 수 있습니다. 이 기능을 사용하여 다른 사용자가 파일에 액세스하는 업무 시간 동안 해당 문서가 게시되지 않도록 방지할 수 있습니다.

하루 중 시간을 기준으로 액세스를 제한하려면 서버 인스턴스에 대한 액세스 제어 설정 방법을 이용합니다.

  1. Server Manager를 사용하여 서버 인스턴스를 선택합니다.
  2. Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. Pick a Resource의 드롭 다운 목록에서 전체 서버를 선택하고 Edit Access Control을 누릅니다.
  5. 모든 사용자에게 읽기 및 실행 권한을 허용하는 새 규칙을 만듭니다.

    6. 이렇게 하면 사용자가 파일이나 디렉토리를 추가, 업데이트 또는 삭제하려 할 때 이 규칙이 적용되지 않으며 서버는 일치되는 다른 규칙을 검색합니다.

  6. 모든 사용자의 쓰기 및 삭제 권한을 거부하는 다른 규칙을 만듭니다.
  7. X 링크를 눌러 사용자 정의 표현식을 만듭니다.
  8. 허용할 주 중 요일과 하루 중 시간을 입력합니다.

    9. 예:

    user = "anyone" and
    dayofweek = "sat,sun" or
    (timeofday >= 1800 and
    timeofday <= 600)

    사용자 정의 표현식을 만들면 Users/Groups 및 From Host 필드에 "Unrecognized expressions" 메시지가 표시될 것입니다.

  9. 변경 사항을 Submit 및 Apply합니다.

사용자 정의 표현식에 오류가 있는 경우 오류 메시지가 생성됩니다. 오류를 수정하고 다시 제출하십시오.

보안을 기준으로 액세스 제한

Sun ONE Web Server 6.1의 경우 동일한 서버 인스턴스에 대하여 SSL 청취 소켓과 SSL이 아닌 청취 소켓을 구성할 수 있습니다. 보안을 기준으로 액세스를 제한하면 오직 보안 채널을 통하여 전송되어야 하는 리소스를 보호할 수 잇습니다.

보안을 기준으로 액세스를 제한하려면 서버 인스턴스에 대한 액세스 제어 설정 방법을 이용합니다.

  1. Server Manager를 사용하여 서버 인스턴스를 선택합니다.
  2. Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. Pick a Resource의 드롭 다운 목록에서 전체 서버를 선택하고 Edit Access Control을 누릅니다.
  5. 모든 사용자에게 읽기 및 실행 권한을 허용하는 새 규칙을 만듭니다.

    6. 이렇게 하면 사용자가 파일이나 디렉토리를 추가, 업데이트 또는 삭제하려 할 때 이 규칙이 적용되지 않으며 서버는 일치되는 다른 규칙을 검색합니다.

  6. 모든 사용자의 쓰기 및 삭제 권한을 거부하는 다른 규칙을 만듭니다.
  7. X 링크를 눌러 사용자 정의 표현식을 만듭니다.
  8. ssl="on"을 입력합니다.

    9. 예:

    user = "anyone" and ssl=”on”

  9. 변경 사항을 Submit 및 Apply합니다.

사용자 정의 표현식에 오류가 있는 경우 오류 메시지가 생성됩니다. 오류를 수정하고 다시 제출하십시오.

분산 관리로 액세스 제어 보안

이 부분에는 분산 관리를 사용하도록 설정한 후 Sun ONE Web Server 6.1의 액세스 제어를 보안하기 위하여 수행해야 하는 추가 작업 목록이 있습니다.

리소스에 대한 액세스 보안

generated.https-server-id.acl 파일의 https-server-id 개체 태그에 표시되는 PathCheck 지시문의 순서에 따라 리소스에 대한 원하지 않는 액세스가 허용될 수 있습니다. 이를 방지하려면 아래에 보이는 것과 같이 <server-root>/generated.https-server-id.acl 파일을 편집하여 액세스 제어가 필요한 프로그램 그룹을 쉼표로 분리하여 지정합니다.

시작 라인 위치:

allow (all)

user=<username> and program=<program group, program group...>;

다음 줄 추가:

deny absolute (all)

user=<username> and program!=<program group, program group...>;

서버 인스턴스에 대한 액세스 보안

Sun ONE Web Server 6.1이 서버 인스턴스에 대한 액세스를 제어하도록 구성하려면 <server-root>/httpacl/*.https-admserv.acl 파일을 편집하여 액세스 제어 권한을 부여하려는 사용자를 지정합니다. 예:

acl "https-<instance>";

authenticate (user,group) {

database = "default";

method = "basic";

};

deny absolute (all) user != "UserA";

IP 기반 액세스 제어 사용

ip 속성을 참조하는 액세스 제어 항목이 ACL 파일(gen*.https-admserv.acl)에 관련된 Administration Server 안에 있는 경우 아래의 단계(1)과 단계(2)를 완료합니다.

ip 속성을 참조하는 액세스 제어 항목이 서버 인스턴스에 관련된 ACL 파일 안에 있는 경우 해당 ACL에 대하여 단계(1)만 완료합니다.

  1. 아래에 보이는 것과 같이 <server-root>/httpacl/gen*.https-admserv.acl 파일을 편집하여 user 및 group에 추가로 인증 목록에 ip를 추가합니다.

    2. acl "https-admserv";

    authenticate (user,group,ip) {

    database = "default";

    method = "basic";

    };

  2. 다음 액세스 제어 항목을 추가합니다.

    3. deny absolute (all) ip !="ip_for_which_access_is_allowed";

    예:

    acl "https-admserv";

    authenticate (user,group,ip) {

    database = "default";

    method = "basic";

    };

    deny absolute (all) ip !="205.217.243.119";

동적 액세스 제어 파일 작업

서버 컨텐츠가 전적으로 한 사람에 의하여 관리되는 경우는 거의 없습니다. Sun ONE Web Server에 대한 액세스를 허용하지 않고 최종 사용자가 구성 옵션의 일부에 액세스하여 필요한 사항을 구성할 수 있도록 해야 할 경우가 있습니다. 구성 옵션의 일부는 동적 구성 파일에 저장됩니다.

여기에서는 다음 항목에 대해 설명합니다.

.htaccess 파일 사용

Sun ONE Web Server는 .htaccess 동적 구성 파일을 지원합니다. .htaccess 파일은 사용자 인터페이를 이용하거나 구성 파일을 직접 변경하여 사용하도록 설정합니다. .htaccess를 지원하는 파일은 server_root/plugins/htaccess 디렉토리에 있습니다. 이 파일에는 .htaccess 파일을 사용할 수 있는 플러그인과 .nsconfig 파일을 .htaccess 파일로 변환하는 스크립트가 포함됩니다.

.htaccess 파일은 서버의 표준 액세스 제어와 조합하여 사용할 수 있습니다. PathCheck 지시문의 순서에 상관 없이 표준 액세스 제어는 모든 .htaccess 액세스 제어에 우선하여 적용됩니다. 사용자-그룹 인증이 "Basic" 인 경우에는 사용자 인증에 표준과 .htaccess 액세스 제어를 모두 요구하면 안 됩니다. 표준 서버 액세스 제어를 통하여 SSL 클라이언트 인증을 사용하는 동시에 .htaccess 파일을 통하여 HTTP "Basic" 인증을 요구할 수 있습니다.

이 부분에서는 다음 항목에 대해 설명합니다.

사용자 인터페이스에서 .htaccess 사용 설정

Sun ONE Web Server가 .htaccess를 사용하도록 구성하려면 다음과 같이 합니다.

  1. Server Manager에 액세스하고 .htaccess를 사용으로 설정할 서버 인스턴스를 선택합니다.
  2. 화면 상단의 Class Manager 링크를 누릅니다.
  3. Content Mgmt 탭을 선택합니다.
  4. .htaccess Configuration 링크를 누릅니다.
  5. 다음의 방법으로 편집하려는 서버를 선택합니다.
    • 전체 서버를 선택하거나 드롭 다운 목록에서 특정 서버 선택
    • Browse를 눌러 편집하려는 디렉토리 및 파일 선택
    • Wildcard를 눌러 편집하려는 와일드카드 패턴 선택
  6. Yes를 선택하여 .htaccess를 사용합니다.
  7. .htaccess 구성이 추가될 파일 이름을 입력합니다.
  8. 확인을 누릅니다.
  9. 작업이 완료되면 Apply를 누릅니다.
  10. 하드 스타트/리스타트를 선택하거나 동적으로 적용합니다.

magnus.conf에서 .htaccess 사용 설정

서버가 .htaccess를 사용하도록 직접 설정하려면 우선 서버의 magnus.conf 파일을 수정하여 플러그인을 로드, 초기화 및 사용하도록 해야 합니다.

  1. server_root/https-server_name/config 파일의 magnus.conf를 엽니다.
  2. 다른 Init 지지문 뒤에 다음 줄을 추가합니다.
    • UNIX/Linux:

      • Init fn=”load-modules” funcs=”htaccess-init,htaccess-find”
      shlib=”      server_root/plugins/htaccess/htaccess.so” NativeThread=”no”
      Init fn=”htaccess-init”

    • Windows:

      • Init fn=”load-modules” funcs=”htaccess-init,htaccess-find,htaccess-register”
      shlib=”      server_root/plugins/htaccess/htaccess.dll” NativeThread=”no”
      Init fn=”htaccess-init”

    • HP:

      • Initfn=”load-modules” funcs=”htaccess-init,htaccess-find,htaccess-register” shlib=”<server_root>/plugins/htaccess/htaccess.sl” NativeThread=”no”

      Init fn=”htaccess-init”

  3. (선택) 마지막 줄을 다음과 같이 수정합니다.

    4. Init fn=”htaccess-init”[groups-with-users=yes]

  4. File/Save를 누릅니다.
  5. obj.conf를 엽니다.
  6. 개체의 마지막 지시문으로 PathCheck 지시문을 추가합니다.
    1. 가상 서버가 관리하는 모든 디렉토리를 처리하는 .htaccess를 사용하려면 object.conf 파일의 기본 개체에 PathCheck 지시문을 추가합니다.

      2. <Object name="default">

      ...

      PathCheck fn="htaccess-find"

      </Object>

      .htaccess 처리는 개체의 마지막 PathCheck 지시문이어야 합니다.

    2. 특정 서버 디렉토리용 .htaccess 파일 처리를 사용하려면 magnus.conf에 있는 해당 정의에 PathCheck 지시문을 삽입합니다.
  7. .htaccess 파일의 이름을 .htaccess가 아닌 다른 이름으로 지정하려면 반드시 다음 형식을 사용하여 PathCheck 지시문에 파일 이름을 지정해야 합니다.

    8. PathCheck fn="htaccess-find" filename="filename"

    참고

    다음에 Administration Server를 사용하면 수동 편집이 적용되었다는 경고가 표시됩니다. Apply를 눌러 변경 사항을 적용합니다.

이 후 서버에 액세스하면 지정된 디렉터리의 .htaccess 액세스 제어의 대상이 됩니다. 예를 들어 .htaccess 파일에 대한 쓰기 액세스를 제한하려면 이에 대한 구성 스타일을 만들고 해당 구성 스타일에 액세스 제어를 적용합니다. 자세한 내용은 제 17장, "구성 스타일 적용""을 참조하십시오.

기존 .nsconfig 파일을 .htaccess 파일로 변환

Sun ONE Web Server 6.1에는 기존 .nsconfig 파일을 .htaccess 파일로 변환할 수 있는 htconvert 플러그인이 있습니다. nsconfig 파일은 더 이상 지원되지 않습니다. 이제까지 .nsconfig 파일을 사용한 경우에는 이를 .htaccess 파일로 변환해야 합니다.

htconvert를 시작하면 server.xml 파일에서 pfx2dir과 document-root 지시문을 검색합니다. 검색된 각 .nsconfig 파일은 .htaccess 파일로 변환됩니다. 구성에 따라 여러 개의 obj.conf 파일이 변환될 수 있습니다.

참고

기존 .htaccess 파일이 있는 경우 htconvert는 htaccess.new 파일을 만들고 경고가 표시됩니다. .htaccess와 .htaccess.new 파일이 모두 있는 경우 새 파일의 이름은 htaccess.new.new가 됩니다. .new는 반복적으로 추가됩니다.

htconvert 플러그인은 현재 restrictAccess 및 RequireAuth 지시문과 <Files> 래퍼 함수만 지원합니다. <Files*>가 아닌 <Files>이 있는 경우 스크립트는 경고를 표시하며 해당 디렉토리의 모든 파일에 액세스 제어가 적용된 것처럼 작동합니다.

파일을 변환하려면 명령 프롬프트에서 시스템의 Perl 경로, 플러그인 스크립트의 경로, 및 serer.xml 파일의 경로를 입력합니다. 예:

모든 .nsconfig 파일은 .htaccess 파일로 변환되지만 삭제되지는 않습니다.

groups-with-users 옵션을 사용하면 그룹의 사용자가 많은 경우 쉽게 처리할 수 있습니다. 그룹의 사용자가 많은 경우 다음과 같이 합니다.

  1. 사용자 파일 형식을 다음과 같이 사용자가 속한 그룹 목록으로 수정합니다.

    2. username:password:group1,group2,group3,...groupn

  2. AuthGroupFile 지시문이 AuthUserFile과 동일한 파일을 가리키도록 수정합니다.

다른 방법으로 다음과 같이 할 수 있습니다.

  1. AuthGroupFile 지시문 전체를 제거합니다.
  2. 다음을 magnus.conf 파일의 Init fn=htaccess-init 줄에 추가합니다.

htaccess-register 사용

htaccess-register은 새로운 기능으로 사용자가 자신의 인증 방법을 만들 수 있습니다. Apache와 마찬가지로 외부 인증 모듈을 만들고 이를 htaccess-register를 통하여 .htaccess 모듈에 삽입할 수 있습니다. server_root/plugins/nsapi/htaccess에 두 가지 예제 모델이 있습니다.

외부 모듈을 사용하여 하나 이상의 새 지시문을 만들 수 있습니다. 예를 들어 인증용 사용자 데이터베이스를 지정할 수 있습니다. 지시문은 <Limit> 또는 <LimitExcept> 태그에 표시되지 않을 수도 있습니다.

.htaccess 파일 예제

다음은 .htaccess 파일의 예입니다.

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName mxyzptlk.kawaii.com
AuthUserFile /server_root/mxyz-docs/service.pwd
AuthGroupFile /server_root/mxyz-docs/service.grp

지원되는 .htaccess 지시문

이 릴리스에서는 다음의 .htaccess 지시문을 지원합니다.

allow

구문

다음의 호스트를 허용합니다.

보통 <Limit> 또는 <LimitExcept> 범위에 포함시키지만 반드시 그렇게 해야 하는 것은 아닙니다.

효과

지정된 호스트로의 액세스를 허용합니다. 보통 <Limit> 범위 안에 표시됩니다.

deny

구문

다음 위치의 호스트를 거부합니다.

보통 <Limit> 또는 <LimitExcept> 범위에 포함시키지만 반드시 그렇게 해야 하는 것은 아닙니다.

효과

지정된 호스트로의 액세스를 거부합니다. 보통 <Limit> 범위 안에 표시됩니다.

AuthGroupFile

구문

AuthGroupFile filename으로 여기에서 filename은 groupname:user user 형식의 그룹 정의를 포함하는 파일의 이름입니다.

<Limit> 또는 <LimitExcept> 범위 내에 표시되면 안 됩니다.

효과

해당 이름의 그룹 파일이 필요한 group 지시문에서 참조된 그룹 정의용으로 사용되도록 지정합니다. 참고로, AuthGroupFile 지지문에 지정된 filename이 AuthUserFile 지시문에 지정된 filename과 동일한 경우 파일에 다음 형식의 사용자 및 그룹이 있는 것으로 가정합니다.

username:DES-encrypted-password:comma-separated-list-of-groups

AuthUserFile

구문

AuthUserFile filename. 여기에서,

<Limit> 또는 <LimitExcept> 범위 내에 표시되면 안 됩니다.

효과

해당 이름의 파일이 필요 user 또는 필요한 valid-user 지시문에서 참조되는 사용자 이름용으로 사용되도록 지정합니다.

obj.conf의 Init fn=htaccess-init 지시문 내의 groups-with-users=yes를 사용하거나 AuthGroupFile 지시문을 지정하면 파일의 형식이 다음과 같은 것으로 가정합니다.

username:DES-encrypted-password:comma-separated-list-of-groups

AuthName

구문

AuthName 인증 영역. 여기에서 인증 영역은 임의의 사용자 인증용 요청과 연결되는 인증 영역을 구분하는 문자열입니다.

<Limit> 또는 <LimitExcept> 범위 내에 표시되면 안 됩니다.

효과

인증 영역 문자열은 보통 클라이언트 측의 사용자이름 및 비밀번호를 묻는 프롬프트에 표시됩니다. 해당 클라이언트에서 사용자이름 및 비밀번호를 캐시하는 데 영향을 미칠 수 있습니다.

AuthType

구문

AuthType Basic. <Limit> 또는 <LimitExcept> 범위 내에 표시되면 안 됩니다.

효과

사용자 인증을 HTTP Basic Authentication으로 지정하며, 현재 유일하게 지원되는 방법입니다.

<Limit>

구문

<Limit method method ...>

allow, deny, order, or require directives

</Limit>

여기에서 method는 GET, POST 또는 PUT 등의 HTTP 메소드입니다. 여기에는 서버가 알 수 있는 모든 메소드를 사용할 수 있습니다.

효과

지정된 HTTP 메소드를 사용하는 요청에만 포함된 지시문을 적용합니다.

<LimitExcept>

구문

<LimitExcept method method ...>

allow, deny, order, or require directives

</LimitExcept>

여기에서 method는 GET, POST 또는 PUT 등의 HTTP 메소드입니다. 여기에는 서버가 알 수 있는 모든 메소드를 사용할 수 있습니다.

효과

지정된 HTTP 메소드와 일치하지 않는 요청 유형에만 포함된 지시문을 적용합니다.

order

구문

Order 순서. 여기에서 순서는 다음 중 한 가지입니다.

보통 <Limit> 또는 <LimitExcept> 범위에 포함시키지만 반드시 그렇게 해야 하는 것은 아닙니다.

효과

require

구문

보통 <Limit> 또는 <LimitExcept> 범위에 포함시키지만 반드시 그렇게 해야 하는 것은 아닙니다.

효과

.htaccess 보안 고려사항

기본적으로 HTTP PUT용 서버 지원은 사용하지 않습니다. Class Manager에 있는 Content Mgmt의 Remote File Manipulation 페이지를 사용하여 HTTP PUT을 사용하도록 설정할 수 있습니다. .htaccess 파일을 포함하는 디렉토리에 PUT 액세스를 허용하는 경우 해당 파일이 변경될 수 있으므로 매우 신중해야 합니다. 액세스를 제한하여 디렉토리의 모든 파일에 대하여 PUT 액세스를 금지할 수 있습니다. "디렉토리(경로)에 대한 액세스 제한"을 참조하십시오.

가상 서버용 액세스 제어

Sun ONE Web Server 6.1의 액세스 제어 정보는 각 가상 서버 ACL 파일과 문서 디렉토리의 .htaccess 파일에서 찾을 수 있습니다. .htaccess 시스템은 iPlanet Web Server 4.x부터 변경되지 않았습니다.

server.xml 파일에는 하나 이상의 ACLFILE 태그가 있을 수 있으며, 이 태그는 특정 표준 Sun ONE Web Server 6.x ACL 파일에 연결된 아이디를 정의합니다. 예:

<ACLFILE id="standard" file="standard.acl">

가상 서버에서 액세스 제어를 사용하려면 반드시 해당 "aclids" 등록 정보에 있는 하나 이상의 ACL 파일 아이디에 대한 참조를 만들어야 합니다. 예:

<VS aclids=”standard”>

이 구성을 사용하면 여러 대의 가상 서버가 동일한 ACL 파일을 공유할 수 있습니다. 가상 서버용으로 사용자-그룹 인증을 요구하도록 하려면 하나 이상의 USERDB 태그를 해당 정의에 추가해야 합니다. USERDB 태그는 ACL 파일의 데이터베이스 이름과 dbswitch.conf 파일에 있는 실제 데이터베이스 사이를 연결합니다.

다음 예제에서는 "database" 속성이 없는 ACL을 dbswitch.conf의 "default" 데이터베이스로 매핑합니다.

<VS>

<USERDB id=”default” database=”default”/>

</VS>

가상 서버에서 데이터베이스 액세스

dbswitch.conf 파일에 전역적으로 사용자 인증 데이터베이스를 정의할 수 있습니다. 오직 서버가 시작할 때에만 이 파일을 읽습니다.

dbswitch.conf에 있는 LDAP URL의 baseDN은 데이터베이스로의 모든 액세스에 대한 전역 루트를 정의합니다. 따라서 역방향 호환성이 유지됩니다. 신규 설치의 경우 대부분 baseDN은 비어있습니다.

dcsuffix는 dbswitch.conf에 있는 LDAP 데이터베이스용의 새로운 속성으로 Sun ONE LDAP 스키마에 따라 DC 트리의 루트를 정의합니다. 이는 LDAP URL의 baseDN에 상대적입니다. dcsuffix 속성이 있는 경우 LDAP 데이터베이스는 Sun ONE LDAP 스키마와 호환되며 일부 운영의 작동이 변경됩니다. Sun ONE LDAP 스키마에 대한 자세한 내용과 예제는 Sun ONE Web Server 6.1 Administrator's Configuration Reference의 제2장에 있는 "The Sun ONE LDAP Schema"를 참조하십시오.

모든 가상 서버에 대하여 디렉토리 중 하나를 가리키는 USERDB 블록을 하나 이상 정의할 수 있으며 추가 정보를 정의할 수 있습니다. USERDB 블록 아이디는 ACL의 데이터베이스 매개 변수에서 참조할 수 있습니다. 가상 서버에 USERDB 블록이 없는 경우 사용자 또는 그룹 기반 ACL은 실패합니다.

USERDB 태그는 ACL의 데이터베이스 속성과 dbswitch.conf 사이에 추가의 간접 레이어를 정의합니다. 이 간접 레이어는 서버 관리자가 가상 서버 관리자에 의하여 액세스되는 데이터베이스를 완전히 제어할 수 있도록 필요한 보호를 추가합니다.

USERDB에 대한 자세한 내용은 Sun ONE Web Server 6.1 Administrtor's Configuration Reference의 제2장에 있는 "User Database Selection"을 참조하십시오.

사용자 인터페이스에서 LDAP 데이터베이스 지정

dbswitch.conf에 하나 이상의 사용자 인증 데이터베이스를 정의한 후, Class Manager를 사용하여 각 가상 서버가 인증용으로 사용할 데이터베이스를 구성할 수 있습니다. 또한 Class Manager를 사용하여 dbswitch.conf에서 새로 만들어진 데이터베이스 정의를 추가하여 가상 서버가 인증에 사용하도록 할 수 있습니다.

가상 서버가 사용할 LDAP 데이터베이스를 지정하려면 다음과 같이 합니다.

  1. Server Manager에 액세스하고 Virtual Server Class 탭을 선택합니다.
  2. Server의 Tree View에 있는 LDAP 데이터베이스 목록에서 데이터베이스를 지정할 가상 서버 클래스 링크를 누릅니다.
  3. Virtual Servers 탭이 표시되지 않았으면 선택하여 표시합니다.
  4. ACL Settings 링크를 누릅니다.

    5. ACL Settings for Virtual Servers 페이지가 표시됩니다.

  5. Option 열의 드롭 다운 목록에 Edit이 표시되어 있지 않으면 지금 선택합니다.
  6. 편집하는 가상 서버의 Database 열에 있는 드롭 다운 목록에서 데이터베이스 구성을 선택합니다.
  7. 확인을 누릅니다.
  8. Edit ACL Files 창을 닫습니다.
  9. Apply를 누릅니다.
  10. Dynamically Apply를 선택합니다.

가상 서버용 액세스 제어 목록 편집

가상 서버용 ACL은 가상 서버가 상주하는 서버 인스턴스용으로 만들어집니다. 가성 서버 ACL 설정은 해당 서버 인스턴스용으로 만들어진 ACL의 기본값이 됩니다. 그러나 각 가상 서버의 액세스 제어는 Class Manager에서 변경할 수 있습니다. 또한 이 방법을 사용하여 가상 서버에 새로 만든 ACL 파일을 추가할 수 있습니다.

가상 서버용 ACL 설정을 변경하려면 다음과 같이 합니다.

  1. Server Manager에 액세스하고 Virtual Server Class 탭을 선택합니다.
  2. Server의 Tree View에 있는 LDAP 데이터베이스 목록에서 데이터베이스를 지정할 가상 서버 클래스 링크를 누릅니다.
  3. Virtual Servers 탭이 표시되지 않았으면 선택하여 표시합니다.
  4. ACL Settings 링크를 누릅니다.
  5. 변경하려는 각 가상 서버에 대하여 Option 필드에 있는 드롭 다운 목록에서 Edit 또는 Delete를 선택합니다.
  6. 사용 가능한 ACL 파일을 표시하려면 ACL File 필드에서 Edit 링크를 누릅니다.
  7. 해당 가상 서버에 추가 또는 삭제할 ACL 파일을 하나 이상 선택합니다.

    8. 가상 서버의 문서 루트는 여러 개일 수 있으므로 ACL 파일 또한 여러 개가 있을 수 있습니다.

  8. 드롭 다운 목록에서 ACL 목록에 연결할 데이터베이스를 선택합니다.
  9. (선택) BaseDN을 입력합니다.
  10. 변경을 완료했으면 확인을 누릅니다.
  11. Apply를 누릅니다.
  12. Dynamically Apply를 선택합니다.

파일 기반 인증용 ACL 생성

Sun ONE Web Server 6.1에서는 파일 기반 인증 데이터베이스를 사용할 수 있으며, 이 파일은 보통 파일로 텍스트 형식으로 사용자 및 그룹 정보를 저장합니다. ACL 프레임워크는 파일 인증 데이터베이스와 함께 작동하도록 디자인되었습니다.

참고

Sun ONE Web Server 6.1은 동적 보통 파일을 지원하지 않습니다. 보통 파일 데이터베이스는 서버가 시작할 때 로드됩니다. 파일이 변경되는 경우 오직 서버가 재식작되어야 적용됩니다.

ACL 항목은 database 키워드를 사용하여 사용자 데이터베이를 참조할 수 있습니다. 예:

acl "default";

authenticate (user) {

...

database="myfile";

...

};

myfile 데이터베이스는 server.xml에 있는 VS의 USERDB 요소에서 참조될 수 있으며, 이 경우 server-root/userdb/dbswitch.conf 파일과 연결됩니다. 예:

<VS>

...

<USERDB id="myfile" database="myfiledb">

...

</VS>

server-root/userdb/dbswitch.conf 파일에는 파일 auth-db와 해당 구성을 정의하는 항목이 있습니다. 예:

directory myfiledb file

myfiledb:syntax keyfile

myfiledb:keyfile /path/to/config/keyfile

아래의 표

파일 인증을 기반으로 디렉토리 서비스용 ACL 생성

파일 인증을 기반으로 디렉토리 서비스용 ACL 항목을 만들려면 다음과 같이 합니다.

  1. Server Manager에 액세스하고 ACL을 만들거나 편집하려는 서버 인스턴스를 선택합니다.
  2. Server Manager에서 Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. Option 열의 드롭 다운 목록에서 ACL 파일을 선택하고 Edit ACL을 클릭합니다.
  5. 상단 창의 Access Control Rules 페이지에서 편집하려는 ACL의 Users/Groups 링크를 누릅니다.
  6. 하단 창의 User/Group 페이지의 Authentication 데이터베이스 드롭 다운 목록에서 keyfile을 선택합니다.
  7. Update를 누릅니다.

    8. 아래의 예제와 같이 키파일 기반 파일 인증 데이터베이스에 대한 ACL을 설정하는 경우 dbswitch.conf 파일이 ACL 항목을 포함하여 업데이트됩니다.

    version 3.0;

    acl "default";

    authenticate (user) {

    prompt = "Sun One Web Server 6.1";

    database = "mykeyfile";

    method = "basic";

    };

    deny (all) user = "anyone";

    allow (all) user = "all";

htaccess 인증을 기반으로 디렉토리 서비스용 ACL 생성

Sun ONE Web Server에서 .htaccess 기반 보통 파일 인증을 지원합니다. 이제까지 .htaccess 인증을 사용한 경우에는 기존 데이터파일을 변경 없이 파일 인증 데이터파일로 이전할 수 있습니다. .htaccess 파일 사용에 언급한 것과 같이 .htaccess 사용자 및 그룹 데이터는 단일 파일 또는 두 개의 별도 파일(사용자 데이터용 한 개 및 그룹 데이터용 한 개)에 저장됩니다. 파일 인증 데이터베이스는 기존 형식 두 가지를 모두 지원합니다.

htaccess 인증을 기반으로 디렉토리 서비스용 ACL 항목을 만들려면 다음과 같이 합니다.

  1. Server Manager에 액세스하고 ACL을 만들거나 편집하려는 서버 인스턴스를 선택합니다.
  2. Server Manager에서 Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. Option 열의 드롭 다운 목록에서 ACL 파일을 선택하고 Edit ACL을 클릭합니다.
  5. 상단 창의 Access Control Rules 페이지에서 편집하려는 ACL의 Users/Groups 링크를 누릅니다.
  6. 하단 창의 User/Group 페이지의 Authentication 데이터베이스 드롭 다운 목록에서 htaccess를 선택합니다.
  7. Update를 누릅니다.

    8. htaccess 기반 파일 인증 데이터베이스에 대한 ACL을 설정하는 경우 dbswitch.conf 파일이 아래의 예제와 같은 ACL 항목을 포함하여 업데이트됩니다.

    version 3.0;

    acl "default";

    authenticate (user) {

    prompt = "Sun One Web Server 6.1";

    database = "myhtaccessfile";

    method = "basic";

    };

    deny (all) user = "anyone";

    allow (all) user = "all";

기존 .htaccess 정보를 파일 인증 데이터베이스로 이전

기존 .htaccess 정보를 Sun ONE Web Server 6.1의 파일 인증 데이터베이스로 이전하려면 다음과 같이 합니다.

사용자 파일 형식:

#user:password

그룹 파일 형식:

#group1:user1 user2

#group2:user3 user4

참고

구성원 이름은 공백으로 분리합니다.

userfile과 groupfile의 이름이 동일한 경우 파일이 조합되며 조합된 파일의 각 줄은 아래에 보이는 것과 같은 구문을 따릅니다.

#user:password:group1,group2

참고

열은 콜론(:)으로 분리합니다.

htaccess 데이터베이스 예제

예제 1

#sample userfile (user/password "j2ee/j2eepwd" user/password "user1/user1pwd" )

j2ee:9hmjfRwNxvJLU

user1:wvQirF86BsjSk

Sample 2

#sample group file

staff:j2ee user1

eng:j2ee

Sample 3

#sample user/group file (username "j2ee", user password "j2eepwd")

j2ee:9hmjfRwNxvJLU:staff,eng

다이제스트 인증을 기반으로 디렉토리 서비스용 ACL 생성

파일 인증 데이터베이스는 또한 각 암호 기반 RFC 2617.A 해시 다이제스트 인증을 사용하기 적합한 파일 형식을 지원하며, 영역은 저장됩니다. 보통 텍스트 비밀번호는 보관되지 않습니다.

다이제스트 인증을 기반으로 디렉토리 서비스용 ACL 항목을 만들려면 다음과 같이 합니다.

  1. Server Manager에 액세스하고 ACL을 만들거나 편집하려는 서버 인스턴스를 선택합니다.
  2. Server Manager에서 Preferences 탭을 선택합니다.
  3. Restrict Access 링크를 누릅니다.
  4. Option 열의 드롭 다운 목록에서 ACL 파일을 선택하고 Edit ACL을 클릭합니다.
  5. 상단 창의 Access Control Rules 페이지에서 편집하려는 ACL의 Users/Groups 링크를 누릅니다.
  6. 하단 창의 User/Group 페이지의 Authentication 데이터베이스 드롭 다운 목록에서 digest를 선택합니다.
  7. Update를 누릅니다.

    8. digestauth 기반 파일 인증 데이터베이스에 대한 ACL을 설정하는 경우 dbswitch.conf 파일이 아래의 예제와 같은 ACL 항목을 포함하여 업데이트됩니다.

    version 3.0;

    acl "default";

    authenticate (user) {

    prompt = "filerealm";

    database = "mydigestfile";

    method = "digest";

    };

    deny (all) user = "anyone";

    allow (all) user = "all";



이전      목차      색인      다음     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.