test

Sun Java System Web Proxy Server 4.0.8 관리 설명서

8장 서버 액세스 제어

이 장에서는 Administration Server 및 Proxy Server에서 제공하는 데이터에 대한 액세스를 제어하는 방법에 대해 설명합니다. 서버에서 제공하는 모든 데이터 또는 특정 URL에 대한 액세스를 제한할 수 있습니다. 예를 들어 특정 사용자만 특정 URL에 액세스하거나 이러한 사용자를 제외한 모든 사용자가 파일을 볼 수 있도록 지정할 수 있습니다. 모든 클라이언트에 대해 HTTP URL에는 액세스할 수 있지만 FTP에 대해서는 제한된 액세스만 허용할 수 있습니다. 또한 Proxy Server가 여러 내부 웹 서버에 서비스를 제공하고 이러한 서버 중 하나에 저장된 기밀 연구 프로젝트에 특정 사용자만 액세스할 수 있게 하려는 경우와 같이 호스트 이름 또는 도메인 이름을 기준으로 URL을 제한할 수 있습니다.

Administration Server에서 액세스 제어를 사용하기 전에 분산 관리 기능을 활성화하고 LDAP 데이터베이스에 관리 그룹을 구성해야 합니다. 이 장의 정보는 이러한 작업이 이미 수행되었다는 가정하에 제공됩니다.

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

액세스 제어란

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

액세스는 다음 항목을 기준으로 허용 또는 거부됩니다.

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

사용자 그룹용 액세스 제어

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

Administration Server는 오직 Basic 인증만 사용합니다. 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 인증의 경우 사용자가 서버에 액세스하기 위해 사용자 이름과 비밀번호를 제공해야 합니다. Basic 인증은 기본 설정입니다. 사용자 및 그룹 목록을 만들어 Sun Java System Directory Server 같은 LDAP 데이터베이스 또는 파일에 저장해야 합니다. Proxy Server와는 다른 서버 루트에 설치된 디렉토리 서버 또는 원격 컴퓨터에 설치된 디렉토리 서버를 사용해야 합니다.

사용자가 사용자 그룹 인증이 있는 자원에 액세스하려는 경우 사용자 이름과 비밀번호를 입력하라는 메시지가 표시됩니다. 서버에서 암호화 기능이 사용되는지의 여부에 따라 이 정보는 암호화 또는 암호화되지 않은 형태로 서버에 입력됩니다(SSL 사용).

주 –

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

인증에 성공하면 사용자에게 요청된 자원이 표시됩니다. 사용자 이름 또는 비밀번호가 잘못된 경우 액세스를 거부하는 메시지가 표시됩니다.

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

SSL 인증

서버가 보안 인증서가 있는 사용자의 아이디를 확인하는 방법은 두 가지입니다.

클라이언트 인증을 위해 인증서 정보를 사용하도록 서버를 구성한 경우 서버는 다음 작업을 수행합니다.

특정 자원에 대한 액세스를 제어하기 위해 클라이언트 인증을 요구하는 경우는 서버에 대한 모든 연결에 대해 클라이언트 인증을 요구하는 경우와 다릅니다. 모든 연결에 대해 서버가 클라이언트 인증을 요구하도록 구성된 경우 클라이언트는 신뢰할 수 있는 인증 기관에서 발행한 유효한 인증서만 제시하면 됩니다. 서버가 SSL 방법을 사용하여 사용자 및 그룹을 인증하도록 구성된 경우 다음 작업을 수행해야 합니다.

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

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

Digest 인증

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

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

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

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

여기서는 샘플 dbswitch.conf 파일입니다.


directory default ldap://<host_name>:<port>
default:binddn cn=Directory Manager
default:encoded bindpw ***********
default:digestauth on

또는


directory default ldap://<host_name>:<port>/
default:binddn cn=Directory Manager
default:encoded bindpw ***********
default:digestauthstate on

서버는 Digest 인증에 보이는 것과 같이 지정된 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 인증 플러그인은 다음 공유 라이브러리와 ldif 파일로 구성됩니다.

ProcedureUNIX에 Digest 인증 플러그인을 설치하는 방법

시작하기 전에

  1. 플러그인을 설치하려면 다음 명령을 입력합니다.

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

Windows에 Digest 인증 플러그인 설치

Directory Server가 다이제스트 플러그인과 함께 제대로 시작되려면 여러 개의 .dll 파일을 프로시 서버 설치 위치에서 Directory Server용 Sun Java System Directory Server 서버 컴퓨터로 복사해야 합니다.

ProcedureWindows에 Digest 인증 플러그인을 설치하는 방법

  1. server-root \bin\proxy\bin에 있는 Proxy Server의 공유 라이브러리에 액세스합니다.

  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 알고리즘을 위해 다이제스트 비밀번호가 저장된 속성을 암호화해야 합니다.

ProcedureDES 알고리즘을 사용하도록 Directory Server를 설정하는 방법

  1. Sun Java System Directory Server 콘솔을 시작합니다.

  2. Sun ONE Directory Server 5.1 SP1 이상 버전의 인스턴스를 엽니다.

  3. Configuration 탭을 선택합니다.

  4. 플러그인 옆의 + 기호를 누릅니다.

  5. DES 플러그인을 선택합니다.

  6. Add를 선택하여 새 속성을 추가합니다.

  7. iplanetReversiblePassword를 입력합니다.

  8. Save를 누릅니다.

  9. Digest 인증 비밀번호를 설정합니다.

    주 –

    서버는 객체 클래스 iplanetReversiblePassword에 있는 iplanetReversiblePassword 속성을 사용합니다. 사용자의 iplanetReversiblePassword 속성에서 Digest 인증 비밀번호를 사용하려면 항목에 iplanetReversiblePasswordobject 객체가 포함되어야 합니다.

    ldapmodify를 사용하거나 Directory Server 관리 인터페이스를 사용하여 이를 수행할 수 있습니다.

    ldapmodify 사용—

    digest.ldif 파일을 만들어 LDAP 명령을 저장합니다. 비밀번호 추가 프로세스는 2단계로 구성되어 있습니다.

    1. 객체 클래스를 digest.ldif에 추가합니다.

      파일이 다음과 유사하게 표시됩니다(Directory Server 사용자 및 ACL을 기준으로 추가 ldif 파일을 가질 수 있음).


      dn:uid=user1,dc=india,dc=sun,dc=com
changetype:modify
add:objectclass
objectclass:iplanetReversiblePasswordobject

dn:uid=user1,dc=india,dc=india,dc=sun,dc=com
changetype:modify
add:iplanetReversiblePassword
iplanetReversiblePassword:user1

    2. # ldapmodify -D “cn={CN_Value}” -w <password> -a <ldif_file_name>

  10. Sun Java System Directory Server 인스턴스를 다시 시작하고 사용자 속성이 Directory Server 데이터베이스에 추가되었는지 확인합니다.

기타 인증

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

호스트-IP용 액세스 제어

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

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

호스트-IP 인증의 경우 서버에서 DNS(Domain Name Service)를 구성할 필요가 없습니다. 호스트-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 파일에서 이러한 파일을 참조할 수 있습니다. 또한 하루 중 시간 또는 요일을 기준으로 서버에 대한 액세스를 제한하는 등, 파일을 편집할 때에만 사용할 수 있는 몇 가지 기능이 있습니다.

액세스 제어 파일 및 구문에 대한 자세한 내용은 18 장ACL 파일 구문을 참조하십시오. server.xml에 대한 자세한 내용은 Sun Java System Web Proxy Server 4.0.8 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에 대한 마지막 ACL(이 경우에는 presentation.html 파일)에 도달할 때까지 계속됩니다.

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

일치되는 ACL이 둘 이상인 경우 서버는 일치되는 마지막 ACL문을 사용합니다.

액세스 제어 설정

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

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

주 –

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

전역 액세스 제어 설정

Procedure모든 서버에 대해 액세스 제어를 설정하는 방법

  1. Administration Server에 액세스하고 Global Settings 탭을 누릅니다.

  2. Administer Access Control 링크를 누릅니다.

  3. 드롭다운 목록에서 관리 서버(proxy-admserv)를 선택하고 Go to load data를 누른 다음 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를 누릅니다.

    그룹 또는 사용자에 대해 List 버튼을 누르면 선택할 목록이 표시됩니다. 설정에 대한 자세한 내용은 온라인 도움말을 참조하십시오. 또한 사용자 및 그룹 지정을 참조하십시오.

  9. From Host 열에서 아무 곳이나 누릅니다.

    From Host 페이지가 아래의 창에 표시됩니다.

  10. 액세스가 허용된 호스트 이름 및 IP 주소를 지정한 후 Update를 누릅니다.

    설정에 대한 자세한 내용은 온라인 도움말을 참조하십시오. 또한 송신 호스트 지정을 참조하십시오.

  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 페이지가 아래의 창에 표시됩니다.

    1. 원하는 응답을 선택합니다.

    2. 해당하는 경우 추가 정보를 지정합니다.

    3. Update를 누릅니다.

    설정에 대한 자세한 내용은 액세스가 거부된 경우의 응답을 참조하십시오.

  17. ACL 파일에서 새 액세스 제어 규칙을 저장하려면 Submit를 누르고 변경을 적용하기 전에 포함된 값으로 페이지의 요소를 재설정하려면 Revert를 누릅니다.

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

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

Procedure서버 인스턴스용 액세스 제어를 설정하는 방법

  1. 서버 인스턴스에 대한 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  2. Administer Access Control 링크를 누릅니다.

  3. 다음 방법 중 하나를 사용하여 ACL을 선택합니다.

    • Select A Resource 드롭다운 목록에서 액세스를 제한하기 위해 ACL을 사용하는 자원을 선택하거나 Regular Expression을 눌러 정규 표현식을 지정합니다. 자세한 내용은 Proxy Server 관리 설명서에서 16 장템플리트 및 자원 관리를 참조하십시오.

    • 사용하도록 설정된 모든 ACL을 나열하는 기존 ACL 목록을 선택합니다.

      사용하도록 설정하지 않은 기존 ACL은 목록에 표시되지 않습니다. 드롭다운 목록에서 ACL을 선택합니다.

    • Type In The ACL Name . 이 옵션을 사용하여 명명된 ACL을 작성할 수 있습니다. 이 옵션은 ACL 파일에 익숙한 경우에만 사용하십시오. 명명된 ACL을 자원에 적용하려는 경우에는 obj.conf를 직접 편집해야 합니다. 자세한 내용은 18 장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를 누릅니다.

    그룹 또는 사용자에 대한 List 버튼을 누르면 선택할 목록이 표시됩니다. 설정에 대한 자세한 내용은 온라인 도움말을 참조하십시오. 또한 사용자 및 그룹 지정을 참조하십시오.

  11. From Host 열에서 아무 곳이나 누릅니다.

    From Host 페이지가 아래의 창에 표시됩니다.

  12. 액세스가 허용된 호스트 이름 및 IP 주소를 지정한 후 Update를 누릅니다.

    설정에 대한 자세한 내용은 온라인 도움말을 참조하십시오. 또한 송신 호스트 지정을 참조하십시오.

  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. ACL 파일에서 새 액세스 제어 규칙을 저장하려면 Submit를 누르고 변경을 적용하기 전에 포함된 값으로 페이지의 요소를 재설정하려면 Revert를 누릅니다.

액세스 제어 옵션 선택

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

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

작업 설정

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

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

사용자 및 그룹 지정

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

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

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

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

송신 호스트 지정

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

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

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

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

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

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

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

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

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

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

액세스 권한 설정

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

다음 요소는 사용자 인터페이스의 Access Control Rules For 페이지에서 권한에 표시됩니다.

사용자 정의 표현식 작성

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

다음 사용자 정의 표현식에서는 하루 중 시간 및 요일을 기준으로 액세스를 제한할 수 있는 방법을 보여 줍니다. 이 예에서는 LDAP 디렉토리에 두 개의 그룹이 있는 것으로 가정합니다. Regular 그룹은 월요일부터 금요일까지 오전 8시부터 오후 5시 사이에 액세스할 수 있습니다. Critical 그룹은 항상 액세스할 수 있습니다.

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

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

액세스 제어 사용 안 함

Access Control Rules For 페이지에서 Access Control Is On 옵션을 선택 취소하면 ACL에서 레코드를 삭제할지 여부를 묻는 프롬프트가 표시됩니다. 확인을 누르면 해당 자원의 ACL 항목이 ACL 파일에서 삭제됩니다.

ACL을 비활성화하려면 각 줄의 시작 부분에서 # 기호를 사용하여 파일 generated-proxy- serverid.acl에서 ACL 줄을 주석으로 처리합니다.

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

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

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

Administration Server의 경우 기본적으로사용자는 server-root/httpacl/admin-denymsg.html 에서 권한이 거부됨 메시지를 수신합니다.

Procedure액세스 거부 메시지를 변경하는 방법

  1. Access Control Rules For 페이지에서 Response When Denied 링크를 누릅니다.

  2. 원하는 응답을 선택하고 해당하는 경우 추가 정보를 제공한 다음 Update를 누릅니다. 사용자가 리디렉션되는 응답에 대한 액세스 권한이 있는지 확인합니다.

  3. 변경 사항을 저장하려면 Submit를 누르고 변경하기 전에 포함된 값으로 페이지의 요소를 재설정하려면 Revert를 누릅니다.

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

이 절에서는 서버 및 해당 컨텐츠에 대한 액세스를 제한하는 데 사용되는 일반적인 제한에 대해 설명합니다. 각 절차에 대한 단계에서는 수행해야 할 특정 작업을 자세하게 설명합니다. 그러나 서버 인스턴스용 액세스 제어 설정에서 설명한 단계는 완료해야 합니다.

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

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

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

Procedure전체 서버에 대한 액세스를 제한하는 방법

  1. 서버 인스턴스의 Server Manager에 액세스합니다.

  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.

  3. 드롭다운 목록에서 전체 서버를 선택하고 Select를 누른 다음 해당 Edit 버튼을 누릅니다.

    Access Control Rules For 페이지가 표시됩니다.

  4. 모든 사용자의 액세스를 거부할 규칙을 추가합니다.

  5. 특정 그룹의 액세스를 허용하는 다른 규칙을 추가합니다.

  6. 시작 호스트를 사용하여 제한할 호스트 이름과 IP 주소를 지정합니다.

  7. Submit를 눌러 변경 사항을 저장합니다.

디렉토리에 대한 액세스 제한

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

Procedure디렉토리에 대한 액세스를 제한하는 방법

서버 인스턴스의 액세스 제한 설정에 대해 설명된 단계( 서버 인스턴스용 액세스 제어 설정 참조)를 사용하여 다음을 수행합니다.

  1. 서버 인스턴스의 Server Manager에 액세스합니다.

  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.

  3. 드롭다운 목록에서 원하는 자원을 선택하고 Edit를 누릅니다.

  4. 모든 위치로부터의 모든 사용자 액세스를 거부하는 기본값으로 규칙을 만듭니다.

  5. 특정 그룹의 사용자에게 오직 읽기 및 실행 권한만 허용하는 다른 규칙을 만듭니다.

  6. 특정 사용자에게 모든 권한을 허용하는 세 번째 규칙을 만듭니다.

  7. 마지막 두 개의 규칙에 대해 Continue 선택을 취소합니다.

  8. Submit를 눌러 변경 사항을 저장합니다.

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

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

Procedure파일 유형에 대한 액세스를 제한하는 방법

  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";

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

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

Procedure하루 중 시간을 기준으로 액세스를 제한하는 방법

  1. 서버 인스턴스의 Server Manager에 액세스합니다.

  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.

  3. Select A Resource 섹션의 드롭다운 목록에서 전체 서버를 선택하고 Edit를 누릅니다.

  4. 모든 사용자에게 읽기 및 실행 권한을 허용하는 규칙을 만듭니다.

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

  5. 모든 사용자의 쓰기 및 삭제 권한을 거부하는 다른 규칙을 만듭니다.

  6. X 링크를 눌러 사용자 정의 표현식을 만듭니다.

  7. 허용할 주 중 요일과 하루 중 시간을 입력합니다. 예를 들면 다음과 같습니다.


    user = "anyone" anddayofweek = "sat,sun" or(timeofday >= 1800 
andtimeofday <= 600)

  8. Submit를 눌러 변경 사항을 저장합니다.

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

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

동일한 서버 인스턴스에 대해 SSL 및 비 SSL 청취 소켓을 구성할 수 있습니다. 보안을 기준으로 액세스를 제한하면 보안 채널을 통해서만 전송되어야 하는 자원을 보호할 수 있습니다.

Procedure보안을 기준으로 액세스를 제한하는 방법

  1. 서버 인스턴스의 Server Manager에 액세스합니다.

  2. Preferences 탭에서 Administer Access Control 링크를 누릅니다.

  3. Select A Resource 섹션의 드롭다운 목록에서 전체 서버를 선택하고 Edit를 누릅니다.

  4. 모든 사용자에게 읽기 및 실행 권한을 허용하는 규칙을 만듭니다.

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

  5. 모든 사용자의 쓰기 및 삭제 권한을 거부하는 다른 규칙을 만듭니다.

  6. X 링크를 눌러 사용자 정의 표현식을 만듭니다.

  7. ssl="on"을 입력합니다. 예:


    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)만 완료합니다.

ProcedureIP 기반 액세스 제어를 사용 설정하는 방법

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

    acl "proxy-admserv"; authenticate (user,group,ip) { database = "default"; method = "basic"; };

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

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

    예:

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

파일 기반 인증용 ACL 생성

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

주 –

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

이 절에서는 파일 인증 및 Digest 인증을 기준으로 디렉토리 서비스에 대한 ACL 작성 방법에 대해 설명합니다.

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

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

server-root/userdb/dbswitch.conf 파일에는 파일 인증 데이터베이스와 구성을 정의하는 항목이 포함되어 있습니다. 예:

directory myfiledb filemyfiledb:syntax keyfilemyfiledb:keyfile 
/path/to/config/keyfile

다음 표에서는 파일 인증 데이터베이스에서 지원하는 매개 변수가 나열되어 있습니다.

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

매개 변수 

설명 

구문

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

keyfile

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

digestfile

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

주의 – 주의 –

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

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

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

Procedure파일 인증을 기반으로 디렉토리 서비스용 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.A 해시 Digest 인증을 사용하기 적합한 파일 형식을 지원하며, 영역은 저장됩니다. 일반 텍스트 비밀번호는 보관되지 않습니다.

ProcedureDigest 인증을 기반으로 디렉토리 서비스용 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";