Sun Java logo     이전      목차      색인      다음     

Sun logo
Sun Java System Web Proxy Server 4 .0.1 관리 설명서 

8 장
서버 액세스 제어

이 장에서는 Administration Server에 대한 액세스 및 Proxy Server에 의해 서비스되는 데이터에 대한 액세스를 제어하는 방법에 대해 설명합니다. 서버에서 서비스하는 모든 데이터 또는 특정 URL에 대한 액세스를 제어할 수 있습니다. 예를 들어 지정한 사람만 특정 URL에 액세스할 수 있게 하거나, 또는 지정한 사람을 제외한 모든 사람이 파일을 볼 수 있도록 할 수 있습니다. HTTP에 대한 URL에 모든 클라이언트가 액세스할 수 있도록 하면서 FTP에 대해서는 제한적으로 액세스를 허용할 수도 있습니다. 또한 예를 들어 Proxy Server가 많은 내부 웹 서버를 서비스하고 있는 상태에서 이 중 한 서버에 저장되어 있는 비밀 연구 프로젝트에는 특정한 사람들만 액세스하도록 하려면 호스트 이름과 도메인 이름을 기반으로 URL을 제한할 수 있습니다.

Administration Server에서 액세스 제어를 사용하기 전에 반드시 분산 관리를 사용하도록 설정하고 LDAP 데이터베이스에 관리 그룹을 구성해야 합니다. 이 장에서는 사용자와 이와 같은 작업을 수행한 것으로 가정하고 설명합니다.

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

액세스 제어 설명

액세스 제어를 통해 Proxy Server에 액세스할 수 있는 사용자 및 이들이 서버에서 액세스할 수 있는 부분을 지정할 수 있습니다. 전체 서버에 대한 액세스를 제어하거나, 또는 서버의 일부분(디렉토리, 파일, 파일 유형 등)에 대해서만 액세스를 제어할 수 있습니다. 수신 요청을 평가하는 경우 ACE(Access Control Entry)라는 규칙의 계층을 기반으로 액세스가 결정됩니다. Proxy Server는 일치하는 항목을 찾아 액세스를 허용할지 거부할지 결정합니다. 각 ACE는 서버가 계층의 다음 항목으로 계속할 것인지의 여부를 지정합니다. ACE의 컬렉션을 ACL(Access-Control List)이라고 합니다. 요청이 수신되면 ACL에 대한 참조를 위해 obj.conf 파일이 확인되며, ACL은 액세스 여부를 결정하는 데 사용됩니다. 기본으로 서버에는 하나의 ACL 파일이 있으며 여기에는 여러 개의 ACL이 있습니다.

액세스를 허용 또는 거부하는 기준은 다음과 같습니다.

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

사용자 그룹용 액세스 제어

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

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

사용자 그룹 인증은 서버용으로 구성된 디렉토리 서비스가 수행합니다. 자세한 내용은 디렉토리 서비스 구성을 참조하십시오.

디렉토리 서비스가 액세스 제어를 구현하는 데 사용하는 정보는 다음 중 한 가지 소스에서 구합니다.

서버가 외부 LDAP 기반 디렉토리 서비스를 사용하는 경우 서버 인스턴스용으로 다음 유형의 사용자 그룹 인증 방법을 지원합니다.

서버가 내부 파일 기반 디렉토리 서비스를 사용하는 경우 서버 인스턴스용으로 다음 유형의 사용자 그룹 인증 방법을 지원합니다.

사용자 그룹 인증에서는 사용자가 액세스를 허용 받으려면 먼저 자신을 인증해야 합니다. 인증 과정에서 사용자는 아이디와 비밀 번호를 입력하거나 클라이언트 인증서 또는 Digest 인증 플러그인을 사용하여 자신의 신분을 증명합니다. 클라이언트 인증서를 사용하려면 암호화가 필요합니다.

Default 인증

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

Basic 인증

Basic 인증의 경우 사용자가 서버에 액세스하려면 아이디와 비밀 번호를 입력해야 합니다. 이 설정이 기본값입니다. 반드시 사용자 및 그룹의 목록을 만들고 이를 Sun Java System Directory Server 등의 LDAP 데이터베이스 또는 파일에 저장해야 합니다. 반드시 Proxy Server와 다른 서버 루트에 설치된 디렉토리 서버 또는 원격 컴퓨터에 설치된 디렉토리 서버를 사용해야 합니다.

사용자가 사용자 그룹 인증을 사용하는 리소스에 액세스를 시도하면 아이디와 비밀 번호를 입력하라는 메시지가 표시됩니다. 서버에서 암호화 기능(SSL 사용)이 사용되는지 여부에 따라 이 정보는 암호화 또는 암호화되지 않은 형태로 서버에 입력됩니다.

주의

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

인증 과정이 완료되면 다음이 표시됩니다.

권한이 없는 사용자가 받는 메시지를 사용자 정의할 수 있습니다. 자세한 내용은 액세스가 거부된 경우의 응답을 참조하십시오.

SSL 인증

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

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

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

액세스 제어와 함께 클라이언트 인증을 요구하는 경우 Proxy Server용 SSL 암호를 사용하도록 설정해야 합니다. SSL 사용에 대한 자세한 내용은 인증서 및 키 사용을 참조하십시오.

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

Digest 인증

LDAP 기반 또는 파일 기반 디렉토리 서버스를 사용하여 Digest 인증을 수행하도록 Proxy Server를 구성할 수 있습니다.

Digest 인증을 사용하면 아이디와 비밀 번호를 보통 텍스트로 보내지 않고 아이디 및 비밀 번호를 기반으로 인증할 수 있습니다. 브라우저는 MD5 알고리즘을 사용하여 Proxy Server가 제공하는 사용자의 비밀 번호 및 일부 정보를 사용하는 다이제스트 값을 만듭니다.

서버가 LDAP 기반 디렉토리 서비스를 사용하여 Digest 인증을 수행하는 경우 이 다이제스트 값은 Digest 인증 플러그인을 사용하는 서버에서도 계산되고 클라이언트가 제공하는 다이제스트 값과 비교됩니다. 다이제스트 값이 일치하면 사용자가 인증됩니다. 이렇게 하려면 디렉토리 서버가 보통 텍스트의 사용자 비밀 번호에 액세스해야 합니다. Sun Java System Directory Server에는 역변환 가능 비밀 번호 플러그인이 있으며, 이는 데이터를 암호화된 형태로 저장하여 나중에 원래의 형태로 해독할 수 있는 대칭 암호화 알고리즘을 사용합니다. 오직 Directory Server만이 데이터의 키를 보유합니다.

LDAP 기반 인증의 경우 Proxy Server에 포함된 역변환 가능 비밀 번호 플러그인과 Digest 인증별 플러그인을 사용하도록 설정해야 합니다. Proxy Server가 Digest 인증을 처리하도록 구성하려면 server_root/userdb/에 있는 dbswitch.conf 파일에서 데이터베이스 정의의 digestauth 등록 정보를 설정해야 합니다.

서버는 표 8-1에서와 같이 지정된 ACL 방법에 기반하여 LDAP 데이터베이스에 대한 인증을 시도합니다. ACL 방법을 지정하지 않은 경우 서버는 인증이 요구되는 경우 Digest 또는 Basic을 사용하며, 인증이 요구되지 않는 경우에는 Basic을 사용합니다.

인증 데이터베이스에서 지원 및 지원하지 않는 Digest 인증은 다음 표의 목록을 참조하십시오.

표 8-1
Digest 인증 챌린지 생성

ACL 방법

인증 데이터베이스에서 지원

인증 데이터베이스에서 지원되지 않음

Default

지정된 사항 없음

Digest 및 Basic

Basic

Basic

Basic

Basic

Digest

Digest

ERROR

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

Digest 인증 플러그인 설치

LDAP 기반 디렉토리 서비스를 사용하는 Digest 인증의 경우 Digest 인증 플러그인을 설치해야 합니다. 이 플러그인은 서버 측의 다이제스트 값을 계산하고 이를 클라이언트가 제공한 다이제스트 값과 비교합니다. 다이제스트 값이 일치하면 사용자가 인증됩니다.

파일 기반 인증 데이터베이스를 사용하는 경우 Digest 인증 플러그인을 설치할 필요가 없습니다.

UNIX에 Digest 인증 플러그인 설치

Digest 인증 플러그인은 다음 공유 라이브러리로 구성됩니다.

UNIX에 Digest 인증 플러그인을 설치하려면 다음을 수행합니다.

  1. 이 공유 라이브러리가 Sun Java System 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 인증 플러그인 설치

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

Windows에 Digest 인증 플러그인을 설치하려면 다음을 수행합니다.

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

    2. server_root\bin\proxy\bin

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

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

DES 알고리즘 사용을 위해 Directory Server를 설정하려면 다음을 수행합니다.

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

    참고

    사용자에 대한 iplanetReversiblePassword 속성의 Digest 인증 비밀 번호를 설정하려면 항목에 iplanetReversiblePasswordobject 개체를 포함시켜야 합니다.

Other 인증

액세스 제어 API를 사용하여 사용자 정의 인증 방법을 만들 수 있습니다.

Host-IP용 액세스 제어

Administration Server 및 해당 파일과 디렉토리를 특정 컴퓨터를 이용하는 클라이언트만 사용할 수 있도록 설정하여 이에 대한 액세스를 제한할 수 있습니다. 액세스를 허용 또는 거부하려는 컴퓨터의 호스트 이름 또는 IP 주소를 지정합니다. Host-IP 인증을 사용하는 파일 또는 디렉토리에 대한 액세스는 사용자도 모르게 진행됩니다. 사용자는 아이디 또는 비밀 번호를 입력하지 않고 즉시 파일과 디렉토리에 액세스할 수 있습니다.

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

Host-IP 인증의 경우 서버에서 DNS(Domain Name Service)를 구성할 필요가 없습니다. Host-IP 인증을 선택한 경우 반드시 DNS가 네트워크에서 실행되어야 하며 서버가 이를 사용하도록 구성되어야 합니다. DNS를 사용하도록 설정하려면 서버의 Server Manager에 액세스한 다음 Preferences 탭을 누르고 Configure System Preferences를 누릅니다. DNS 설정이 표시됩니다.

DNS를 사용하면 서버가 DNS 조회를 수행해야 하므로 Proxy Server의 성능이 낮아집니다. DNS 조회가 서버 성능에 미치는 영향을 낮추려면 모든 요청의 IP 주소를 변환하는 대신 오직 액세스 제어 및 CGI용 IP 주소만 변환합니다. 이렇게 하려면 obj.conf에서 다음을 지정합니다.

AddLog fn="flex-log" name="access" iponly=1

액세스 제어 파일 사용

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

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

액세스 제어 파일 및 구문에 대한 자세한 내용은 ACL 파일 구문을 참조하십시오. server.xml에 대한 자세한 내용은 Proxy Server Configuration File Reference를 참조하십시오.

ACL 사용자 캐시 구성

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

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

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

클라이언트 인증서로 액세스 제어

서버에서 SSL을 사용하도록 설정한 경우 액세스 제어와 관련하여 클라이언트 인증서를 사용할 수 있습니다. 이를 위해서는 특정 리소스에 액세스하려면 클라이언트 인증서가 필요하도록 지정해야 합니다. 서버에서 이 기능을 사용하도록 설정하면 인증서가 있는 사용자는 제한된 리소스에 처음 액세스를 시도할 때만 아이디와 비밀 번호를 입력하면 됩니다. 신분이 설정되면 서버는 사용자의 로그인 이름과 비밀 번호를 해당 특정 인증서에 매핑합니다. 이후 사용자는 클라이언트 인증이 필요한 리소스에 액세스할 때 로그인 이름이나 비밀 번호를 입력할 필요가 없습니다. 사용자가 제한된 리소스에 대한 액세스를 시도하면 클라이언트는 서버에 클라이언트 인증서를 보내고, 서버는 이 인증서를 매핑 목록과 비교 확인합니다. 이 인증서가 액세스 권한이 허용된 사용자에게 속한 경우 리소스를 해당 사용자에게 서비스합니다.

참고

특정 리소스에 대한 액세스를 제어하는 데 필요한 클라이언트 인증은 서버에 대한 모든 연결에 대해 클라이언트 인증을 요구하는 것과 다릅니다. 또한 모든 SSL 연결에 대해 클라이언트 인증서를 요구한다고 해서 인증서가 자동으로 데이터베이스에 있는 사용자에게 매핑되지는 않는다는 점을 유의하십시오. 이를 위해서는 클라이언트 인증서가 특정 리소스에 액세스하는 데 필요하도록 지정해야 합니다.

액세스 제어 작동 원리

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

다음 예는 ACL 파일의 내용 예와 액세스 제어 규칙 예를 보여 줍니다.

 

version 3.0;

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

# as icons and images related to Sun Java System Web Proxy 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 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 cannot gain access to the

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

# can access the directory "my_stuff". Furthermore, members

# of GroupB cannot 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

# users with the ID 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, and has been added 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

Proxy 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을 만들 수 있습니다.

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

참고

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

전역 액세스 제어 설정

모든 서버에 대한 액세스 제어를 설정하려면 다음을 수행합니다.
  1. Administration Server에 액세스하고 Global Settings 탭을 누릅니다.
  2. Administer Access Control 링크를 누릅니다.
  3. 드롭다운 목록에서 administration server(proxy-admserv)를 선택하고 Go를 눌러 데이터를 로드한 다음 New ACL 또는 Edit ACL을 누릅니다.
  4. 메시지가 표시되면 인증합니다. Access Control Rules For 페이지가 표시됩니다. Administration Server에는 편집할 수 없는 기본 액세스 제어 규칙이 두 줄 있습니다.
  5. Access Control Is On이 아직 선택되지 않았으면 선택합니다.
  6. 표의 하단에 기본 ACL 규칙을 추가하려면 New Line 버튼을 누릅니다. 액세스 제어 제한의 위치를 변경하려면 위/아래 화살표를 누릅니다.
  7. Users/Groups 열에서 Anyone을 누릅니다. User/Group 페이지가 아래 창에 표시됩니다.
  8. 액세스를 허용할 사용자 및 그룹을 선택하고 Update를 누릅니다. Group 또는 User에 대한 List 버튼을 누르면 선택할 수 있는 목록이 표시됩니다. 설정에 대한 자세한 내용은 온라인 도움말 및 사용자 및 그룹 지정을 참조하십시오.
  9. From Host 열에서 Anyplace를 누릅니다. From Host 페이지가 아래 창에 표시됩니다.
  10. 액세스가 허용된 호스트 이름과 IP 주소를 지정하고 Update를 누릅니다. 설정에 대한 자세한 내용은 온라인 도움말 및 From Host 지정을 참조하십시오.
  11. Programs 열에서 All을 누릅니다. Programs 페이지가 아래 창에 표시됩니다.
  12. 액세스를 허용할 Program Groups를 선택하거나 Program Items 필드에 특정 파일 이름을 입력한 다음 Update를 누릅니다. 설정에 대한 자세한 내용은 온라인 도움말 및 프로그램에 대한 액세스 제한을 참조하십시오.
  13. (선택 사항) 사용자 정의 ACL 표현식을 추가하려면 Extra 열에서 X를 누릅니다. Customized Expressions 페이지가 아래 창에 표시됩니다. 자세한 내용은 사용자 정의 표현식 작성을 참조하십시오.
  14. Continue 열에 확인란이 선택되지 않았으면 선택합니다. 서버는 사용자의 액세스가 허용되었는지 결정하기 전에 다음 줄을 확인합니다. 여러 줄을 만드는 경우에는 가장 일반적인 제한에서 가장 구체적인 제한으로 진행합니다.
  15. (선택 사항) 휴지통 아이콘을 누르면 액세스 제어 규칙에서 해당 줄을 삭제합니다.
  16. (선택 사항) 액세스가 거부되었을 때 사용자가 수신하는 응답을 지정하려면 Response When Denied 링크를 누릅니다. Access Deny Response 페이지가 아래 창에 표시됩니다. 원하는 응답을 선택한 다음 필요한 경우 추가 정보를 지정하고 Update를 누릅니다. 설정에 대한 자세한 내용은 액세스가 거부된 경우의 응답을 참조하십시오.
  17. Submit를 눌러 ACL 파일에 새 액세스 제어 규칙을 저장하거나 Revert를 눌러 페이지의 요소를 변경하기 전에 포함된 값으로 재설정합니다.

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

Server Manager를 사용하여 특정 서버 인스턴스용 액세스 제어를 만들거나 편집 또는 삭제할 수 있습니다. 삭제하는 경우 ACL 파일의 모든 ACL 규칙을 삭제하면 안 됩니다. 서버를 시작하려면 ACL 규칙을 한 개 이상 포함하는 ACL 파일이 적어도 하나 이상 있어야 합니다. ACL 규칙을 모두 삭제하고 서버를 재시작하면 구문 오류가 발생합니다.

서버 인스턴스에 대한 액세스 제어를 설정하려면 다음을 수행합니다.
  1. 서버 인스턴스에 대한 Server Manager에 액세스하고 Preferences 탭을 누릅니다.
  2. Administer Access Control 링크를 누릅니다.
  3. 다음 중 한 가지 방법을 사용하여 ACL을 선택합니다.
    • Select A Resource는 ACL을 사용하여 액세스를 제한하는 리소스를 표시합니다. 드롭다운 목록에서 리소스를 선택하거나 Regular Expression을 눌러 정규식을 지정합니다. 자세한 내용은 Proxy Server 관리자 설명서의 템플릿 및 리소스 관리를 참조하십시오.
    • Select An Existing ACL은 사용하도록 설정된 모든 ACL을 표시합니다. 사용하도록 설정되지 않은 기존 ACL은 이 목록에 표시되지 않습니다. 드롭다운 목록에서 선택합니다.
    • Type In The ACL Name을 사용하여 named ACL을 만들 수 있습니다. 이 옵션은 ACL 파일에 익숙한 경우에만 사용하십시오. named ACL을 리소스에 적용하려는 경우에는 obj.conf를 직접 편집해야 합니다. 자세한 내용은 ACL 파일 구문을 참조하십시오.
  4. 해당 Edit 버튼을 누릅니다. Access Control Rules For 페이지가 표시됩니다.
  5. Access Control Is On이 아직 선택되지 않았으면 선택합니다.
  6. 표의 하단에 기본 ACL 규칙을 추가하려면 New Line 버튼을 누릅니다. 액세스 제어 제한의 위치를 변경하려면 위/아래 화살표를 누릅니다.
  7. 이 서버 인스턴스용 ACL을 편집하려면 Action 열에서 해당 작업을 누릅니다. Allow/Deny 페이지가 아래 창에 표시됩니다.
  8. Allow가 아직 기본값으로 선택되지 않았으면 선택하고 Update를 누릅니다. Allow 또는 Deny에 대한 자세한 내용은 작동 설정을 참조하십시오.
  9. Users/Groups 열에서 Anyone을 누릅니다. User/Group 페이지가 아래 창에 표시됩니다.
  10. 액세스를 허용할 사용자 및 그룹을 선택하고 인증 정보를 지정한 다음 Update를 누릅니다. Group 또는 User에 대한 List 버튼을 누르면 선택할 수 있는 목록이 표시됩니다. 설정에 대한 자세한 내용은 온라인 도움말 및 사용자 및 그룹 지정을 참조하십시오.
  11. From Host 열에서 Anyplace를 누릅니다. From Host 페이지가 아래 창에 표시됩니다.
  12. 액세스가 허용된 호스트 이름과 IP 주소를 지정하고 Update를 누릅니다. 설정에 대한 자세한 내용은 온라인 도움말 및 From Host 지정을 참조하십시오.
  13. Rights 열에서 All을 누릅니다. Access Rights 페이지가 아래 창에 표시됩니다.
  14. 이 사용자에 대한 액세스 권한을 지정한 다음 Update를 누릅니다. 자세한 내용은 프로그램에 대한 액세스 제한을 참조하십시오.
  15. (선택 사항) 사용자 정의 ACL 표현식을 추가하려면 Extra 열 아래의 X를 누릅니다. Customized Expressions 페이지가 아래 창에 표시됩니다. 자세한 내용은 사용자 정의 표현식 작성을 참조하십시오.
  16. Continue 열에서 확인란이 선택되지 않았으면 선택합니다. 서버는 사용자의 액세스가 허용되었는지 결정하기 전에 다음 줄을 확인합니다. 여러 줄을 만드는 경우에는 가장 일반적인 제한에서 가장 구체적인 제한으로 진행합니다.
  17. (선택 사항) 휴지통 아이콘을 누르면 액세스 제어 규칙에서 해당 줄을 삭제합니다. ACL 파일의 모든 ACL 규칙을 삭제하면 안 됩니다. 서버를 시작하려면 ACL 규칙을 최소한 한 개 이상 포함하는 ACL 파일이 적어도 하나 이상 있어야 하기 때문입니다. ACL 파일에서 ACL 규칙을 모두 삭제하고 서버를 재시작하면 구문 오류가 발생합니다.
  18. (선택 사항) 액세스가 거부되었을 때 사용자가 수신하는 응답을 지정하려면 Response When Denied 링크를 누릅니다. Access Deny Response 페이지가 아래 창에 표시됩니다. 원하는 응답을 선택한 다음 필요한 경우 추가 정보를 지정하고 Update를 누릅니다. 설정에 대한 자세한 내용은 액세스가 거부된 경우의 응답을 참조하십시오.
  19. Submit를 눌러 ACL 파일에 새 액세스 제어 규칙을 저장하거나 Revert를 눌러 페이지의 요소를 변경하기 전에 포함된 값으로 재설정합니다.

액세스 제어 옵션 선택

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

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

작동 설정

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

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

사용자 및 그룹 지정

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

Proxy Server는 Sun Java System Directory Server 등의 LDAP 서버 또는 내부 파일 기반 인증 데이터베이스에 저장된 사용자 및 그룹 목록을 확인합니다.

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

사용자 인터페이스의 Access Control Rules For 페이지에서 Users/Groups에 대해 다음 요소가 표시됩니다.

From Host 지정

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

사용자 인터페이스의 Access Control Rules For 페이지에서 From Host에 대해 다음 요소가 표시됩니다.

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

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

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

IP 주소의 경우 *는 반드시 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 페이지만 사용할 수 있습니다.

사용자 인터페이스의 Access Control Rules For 페이지에서 Programs에 대해 다음 요소가 표시됩니다.

액세스 권한 설정

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

사용자 인터페이스의 Access Control Rules For 페이지에서 Rights에 대해 다음 요소가 표시됩니다.

사용자 정의 표현식 작성

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

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

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

유효한 구문과 ACL 파일에 대한 자세한 내용은 ACL 파일 구문을 참조하십시오.

엑세스 제어 사용 중지

Access Control Rules For 페이지에서 Access Control Is On 옵션의 선택을 취소하면 ACL의 기록을 삭제할 것인지 묻는 메시지가 표시됩니다. OK를 누르면 해당 리소스에 대한 ACL 항목이 ACL 파일에서 삭제됩니다.

ACL을 사용 중지하려면 generated-proxy-serverid.acl 파일에서 각 줄의 앞에 # 기호를 삽입하여 이를 주석으로 만듭니다.

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

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

Proxy Server는 액세스가 거부된 경우 기본 메시지를 제공하며 원하는 경우 이 기본 응답 메시지를 사용자 정의할 수 있습니다. 또한 각 액세스 제어 개체마다 서로 다른 메시지를 만들 수 있습니다.

Administration Server의 경우 사용자에게 표시되는 기본 메시지는 server_root/httpacl/admin-denymsg.html에 있는 Permission Denied입니다.

Access Denied 메시지를 변경하려면 다음을 수행합니다.
  1. Access Control Rules For 페이지에서 Response When Denied 링크를 누릅니다.
  2. 원하는 응답을 선택하고 필요한 경우 추가 정보를 입력(사용자에게 리디렉션된 응답에 대한 액세스 권한이 있는지 확인해야 함)한 다음 Update를 누릅니다.
  3. Submit를 눌러 변경 사항을 저장하거나 Revert를 눌러 페이지의 요소를 변경하기 전에 포함된 값으로 재설정합니다.

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

이 절에서는 서버 및 해당 컨텐트에 대해 일반적으로 사용되는 제한에 대해 설명합니다. 각 절차에 대한 단계에서는 필요한 작업을 세부적으로 설명합니다. 그러나 서버 인스턴스용 액세스 제어 설정에 설명된 단계를 반드시 완료해야 합니다.

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

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

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

전체 서버에 대한 액세스를 제한하려면 다음을 수행합니다.

서버 인스턴스에 대한 액세스 제어를 설정하는 방법을 사용하여 (서버 인스턴스용 액세스 제어 설정 참조) 다음과 같이 설정합니다.

  1. 서버 인스턴스에 대한 Server Manager에 액세스합니다.
  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.
  3. 드롭다운 목록에서 전체 서버를 선택하고 Select를 누른 다음 해당 Edit 버튼을 누릅니다. Access Control Rules For 페이지가 표시됩니다.
  4. 모두의 액세스를 거부할 새 규칙을 추가합니다.
  5. 특정 그룹의 액세스를 허용하는 다른 규칙을 새로 추가합니다.
  6. From Host를 사용하여 제한하려는 호스트 이름과 IP 주소를 지정합니다.
  7. Submit를 눌러 변경 사항을 저장합니다.

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

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

디렉토리에 대한 액세스를 제한하려면 다음을 수행합니다.

서버 인스턴스에 대한 액세스 제어를 설정하는 방법을 사용하여 (서버 인스턴스용 액세스 제어 설정 참조) 다음과 같이 설정합니다.

  1. 서버 인스턴스에 대한 Server Manager에 액세스합니다.
  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.
  3. 드롭다운 목록에서 원하는 리소스를 선택하고 Edit를 누릅니다.
  4. 새 규칙을 만들고 기본값을 유지하여 기타 위치로부터의 사용자 액세스를 거부합니다.
  5. 특정 그룹의 사용자에게 오직 읽기 및 실행 권한만 허용하는 새 규칙을 만듭니다.
  6. 특정 사용자에게 모든 권한을 허용하는 세 번째 새 규칙을 만듭니다.
  7. 마지막 두 규칙에 대해 Continue 선택을 취소합니다.
  8. Submit를 눌러 변경 사항을 저장합니다.

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

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

파일 유형에 대한 액세스를 제한하려면 다음을 수행합니다.

서버 인스턴스에 대한 액세스 제어를 설정하는 방법을 사용하여 (서버 인스턴스용 액세스 제어 설정 참조) 다음과 같이 설정합니다.

  1. 서버 인스턴스에 대한 Server Manager에 액세스합니다.
  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.
  3. Select A Resource 섹션에서 Regular Expression을 누르고 정규식을 지정합니다. 예: *.cgi.
  4. Edit를 누릅니다.
  5. 모든 사용자에게 읽기 액세스를 허용하는 새 규칙을 만듭니다.
  6. 오직 지정된 그룹에게 쓰기 및 삭제 액세스를 허용하는 다른 규칙을 만듭니다.
  7. Submit를 눌러 변경 사항을 저장합니다.

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

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

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

지정된 시간 또는 일 동안 서버에 대한 쓰기 및 삭제 액세스를 제한할 수 있습니다.

하루 중 시간을 기준으로 액세스를 제한하려면 다음을 수행합니다.

서버 인스턴스에 대한 액세스 제어를 설정하는 방법을 사용하여 (서버 인스턴스용 액세스 제어 설정 참조) 다음과 같이 설정합니다.

  1. 서버 인스턴스에 대한 Server Manager에 액세스합니다.
  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.
  3. Select A Resource 섹션의 드롭다운 목록에서 전체 서버를 선택하고 Edit를 누릅니다.
  4. 모든 사용자에게 읽기 및 실행 권한을 허용하는 새 규칙을 만듭니다. 이렇게 하면 사용자가 파일이나 디렉토리를 추가, 업데이트 또는 삭제하려 할 때 이 규칙이 적용되지 않으며 서버는 일치하는 다른 규칙을 검색합니다.
  5. 모든 사용자의 쓰기 및 삭제 권한을 거부하는 다른 규칙을 만듭니다.
  6. X 링크를 눌러 사용자 정의 표현식을 만듭니다.
  7. 허용할 주중 요일과 하루 중 시간을 입력합니다. 예:

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

  8. Submit를 눌러 변경 사항을 저장합니다. 사용자 정의 표현식에 오류가 있는 경우 오류 메시지가 생성됩니다. 오류를 수정하고 다시 제출하십시오.

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

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

보안을 기준으로 액세스를 제한하려면 다음을 수행합니다.

서버 인스턴스에 대한 액세스 제어를 설정하는 방법을 사용하여 (서버 인스턴스용 액세스 제어 설정 참조) 다음과 같이 설정합니다.

  1. 서버 인스턴스에 대한 Server Manager에 액세스합니다.
  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.
  3. Select A Resource 섹션의 드롭다운 목록에서 전체 서버를 선택하고 Edit를 누릅니다.
  4. 모든 사용자에게 읽기 및 실행 권한을 허용하는 새 규칙을 만듭니다. 이렇게 하면 사용자가 파일이나 디렉토리를 추가, 업데이트 또는 삭제하려 할 때 이 규칙이 적용되지 않으며 서버는 일치하는 다른 규칙을 검색합니다.
  5. 모든 사용자의 쓰기 및 삭제 권한을 거부하는 다른 규칙을 만듭니다.
  6. X 링크를 눌러 사용자 정의 표현식을 만듭니다.
  7. ssl="on"을 입력합니다. 예:

    8. user = "anyone" and ssl="on"

  8. Submit를 눌러 변경 사항을 저장합니다. 사용자 정의 표현식에 오류가 있는 경우 오류 메시지가 생성됩니다. 오류를 수정하고 다시 제출하십시오.

리소스에 대한 액세스 보안

이 절에서는 분산 관리를 사용하도록 설정한 후 Proxy Server의 액세스 제어 보안을 위해 수행해야 하는 추가 작업에 대해 설명합니다.

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

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

Proxy Server가 서버 인스턴스에 대한 액세스를 제어하도록 구성하려면 server_root/httpacl/*.proxy-admserv.acl 파일을 편집하여 액세스 제어 권한을 부여할 사용자를 지정합니다. 예:

acl "proxy-server_instance";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny absolute (all) user != "UserA";

IP 기반 액세스 제어 사용

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

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

IP 기반 액세스 제어를 사용하도록 설정하려면 다음을 수행합니다.
  1. 아래와 같이 server_root/httpacl/gen*.proxy-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";

파일 기반 인증용 ACL 생성

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

참고

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

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

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

acl "default";
  authenticate (user) {
...
  database="myfile";
...
};

server_root/userdb/dbswitch.conf 파일은 파일 인증 데이터베이스 및 해당 구성을 정의하는 항목을 포함하고 있습니다. 예:

directory myfiledb file
myfiledb:syntax keyfile
myfiledb:keyfile /path/to/config/keyfile

파일 인증 데이터베이스에서 지원하는 매개 변수는 다음 표의 목록을 참조하십시오.

표 8-2
파일 인증 데이터베이스가 지원하는 매개 변수

매개 변수

설명

구문

(선택 사항) 값은 keyfile 또는 digest입니다. 지정하지 않는 경우 기본값은 keyfile입니다.

keyfile

(syntax=keyfile인 경우 필수) 사용자 데이터가 있는 파일 경로입니다

digestfile

(syntax=digest인 경우 필수) Digest 인증용 사용자 데이터가 있는 파일 경로

주의

파일 인증 데이터베이스 파일에서 줄의 최대 길이는 255입니다. 이 한계를 초과하는 줄이 있는 경우 서버는 시작할 수 없으며 로그 파일에 오류가 기록됩니다.

참고

파일 기반 인증 데이터베이스를 사용하여 ACL을 설정하기 전에 파일 기반 인증 디렉토리 서비스가 이미 구성되어 있는지 확인하십시오. 자세한 내용은 디렉토리 서비스 구성을 참조하십시오.

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

파일 인증 기반 디렉토리 서비스용 ACL을 생성하려면 다음을 수행합니다.
  1. 서버 인스턴스에 대한 Server Manager에 액세스합니다.
  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.
  3. 드롭다운 목록에서 ACL 파일을 선택하고 Edit를 누릅니다.
  4. Access Control Rules For 페이지에서 편집하려는 ACL 항목에 대한 Users/Groups 링크를 누릅니다. User/Group 페이지가 아래 창에 표시됩니다.
  5. Authentication Database 아래의 드롭다운 목록에서 키 파일 데이터베이스를 지정합니다.
  6. Update를 누른 다음 Submit를 눌러 변경 사항을 저장합니다.

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

version 3.0;
acl "default";
authenticate (user) {
     prompt = "Sun Java System Proxy Server 4.0";
     database = "mykeyfile";
     method = "basic";
};
deny (all) user = "anyone";
allow (all) user = "all";

Digest 인증 기반 디렉토리 서비스용 ACL 생성

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

Digest 인증 기반 디렉토리 서비스용 ACL을 생성하려면 다음을 수행합니다.
  1. 서버 인스턴스에 대한 Server Manager에 액세스합니다.
  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.
  3. 드롭다운 목록에서 ACL 파일을 선택하고 Edit를 누릅니다.
  4. Access Control Rules For 페이지에서 편집하려는 ACL에 대한 Users/Groups 링크를 누릅니다. User/Group 페이지가 아래 창에 표시됩니다.
  5. Authentication Database 아래의 드롭다운 목록에서 다이제스트 데이터베이스를 지정합니다.
  6. Update를 누른 다음 Submit를 눌러 변경 사항을 저장합니다.

Digest 인증 기반 파일 인증 데이터베이스에 대한 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";



이전      목차      색인      다음     

부품 번호: 819-3161.   저작권 2005 Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.