test

Sun Java System Messaging Server 6 2005Q4 관리 설명서

19장 보안 및 액세스 제어 구성

Messaging Server는 메일을 가로챌 수 없게 하고 침입자가 사용자 또는 관리자로 가장하는 것을 금지하며 특정 사용자에게만 메시징 시스템의 특정 부분에 대한 액세스를 허용할 수 있는 다양하고 유연한 보안 기능을 지원합니다.

Messaging Server 보안 구조는 Sun Java System 서버 전체의 보안 구조 중 일부입니다. 이 구조는 최대한의 상호 운용성과 일관성을 위해 업계 표준 및 공용 프로토콜에 기반을 둡니다. 따라서 Messaging Server 보안 정책을 구현하려면 이 장의 내용뿐만 아니라 여러 다른 문서를 읽어야 합니다. 특히 Messaging Server 보안을 설정하려면 Sun ONE Server Console 5.2 Server Management Guide에 설명된 정보가 필요합니다.

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

서버 보안 정보

서버 보안에는 광범위한 주제가 포함됩니다. 대부분의 기업에서는 허가된 사용자만 서버에 액세스하고, 비밀번호나 아이디의 손상을 방지하며, 사용자가 통신 중에 다른 사람을 나타내지 않도록 하고, 필요 시 비밀리에 통신이 이루어지도록 보장하는 것이 메시징 시스템의 중요한 요구 사항입니다.

서버 통신의 보안이 다양한 방식으로 손상될 수 있기 때문에 보안을 향상시키는 여러 방법이 존재합니다. 이 장에서는 암호화, 인증 및 액세스 제어를 설정하는 방법에 대해 중점적으로 설명합니다. 다음과 같은 Messaging Server의 보안 관련 주제가 이 장에서 다루어집니다.

Messaging Server와 관련된 모든 보안 및 액세스 문제가 이 장에서 설명되지는 않습니다. 다른 곳에서 다루어지는 보안 주제는 다음과 같습니다.

다양한 보안 주제를 다루는 매우 많은 문서가 존재합니다. 여기서 언급된 주제에 대한 추가 배경 정보와 다른 보안 관련 정보는 http://docs.sun.com의 설명서 웹 사이트를 참조하십시오.

HTTP 보안 정보

Messaging Server는 사용자 아이디/비밀번호 인증, 클라이언트 인증서 인증 및 Access Manager를 지원합니다. 그러나 클라이언트와 서버 간의 네트워크 연결을 프로토콜이 처리하는 방법에서 몇 가지 차이점이 있습니다.

POP, IMAP 또는 SMTP 클라이언트가 Messaging Server에 로그인하면 연결이 설정되고 세션이 만들어집니다. 세션이 끝날 때까지, 즉 로그인에서 로그아웃까지 연결이 지속됩니다. 새 연결을 설정할 때 클라이언트는 서버에 대해 재인증되어야 합니다.

HTTP 클라이언트가 Messaging Server에 로그인할 때 서버는 고유한 세션 아이디를 클라이언트에게 제공합니다. 클라이언트는 이 세션 아이디를 사용하여 세션 도중에 여러 연결을 설정합니다. HTTP 클라이언트는 각 연결에 대해 재인증될 필요가 없습니다. 즉, 세션이 해제되고 새 세션을 설정하려는 경우에만 클라이언트 재인증이 필요합니다. (지정된 기간 동안 HTTP 세션이 유휴 상태일 경우 서버가 자동으로 HTTP 세션을 해제하며 클라이언트는 자동으로 로그아웃됩니다. 이 기간의 기본값은 2시간입니다.)

HTTP 세션의 보안을 향상시키기 위해 다음 기술이 사용됩니다.

향상된 연결 성능을 위한 구성 매개 변수 지정에 대한 자세한 내용은 5 장, POP, IMAP 및 HTTP 서비스 구성 을 참조하십시오.

Access Manager에 대한 자세한 내용은 6 장, 단일 사인 온(SSO) 사용을 참조하십시오.

인증 기법 구성

인증 기법은 클라이언트가 자신의 아이디를 서버에 대해 입증하는 특정 방법입니다. Messaging Server는 비밀번호 기반 인증을 위한 다음 SASL(Simple Authentication and Security Layer) 인증 방법을 지원합니다. SASL 기법은 이 절에 설명되어 있습니다. 인증서 기반 인증에 대한 자세한 내용은 암호화 및 인증서 기반 인증 구성 을 참조하십시오.

Messaging Server는 비밀번호 기반 인증을 위한 다음 SASL 인증 방법을 지원합니다.

주 –

이 기능은 더 이상 사용되지 않으며 이후 릴리스에서 제거될 것입니다.

챌린지/응답 인증 기법을 사용하면 서버는 요청 문자열을 클라이언트에게 보냅니다. 클라이언트는 사용자의 비밀번호와 해당 챌린지의 해시로 응답합니다. 클라이언트의 응답이 서버의 고유한 해시와 일치할 경우 사용자가 인증됩니다. 해시는 취소할 수 없으므로 사용자의 비밀번호가 네트워크를 통해 보내질 때 공개되지 않습니다.

주 –

POP, IMAP 및 SMTP 서비스는 모든 SASL 기법을 지원합니다. HTTP 서비스는 일반 텍스트 비밀번호 기법만 지원합니다.

표 19–1은 몇 개의 SASL 및 SASL 관련 configutil 매개 변수를 보여 줍니다. configutil 매개 변수의 최신 전체 목록은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 configutil Parameters를 참조하십시오.

표 19–1 일부 SASL 및 SASL 관련 configutil 매개 변수

매개 변수 

설명 

sasl.default.ldap.has_plain _passwords

디렉토리에 일반 텍스트 비밀번호가 저장되는지 나타내며 APOP, CRAM-MD5 및 DIGEST-MD5를 사용 가능하게 하는 부울입니다. 

기본값: False 

sasl.default.transition_criteria

더 이상 지원 또는 사용되지 않습니다. sasl.default.auto_transition을 참조하십시오.

sasl.default.auto_transition

부울입니다. 이 매개 변수가 설정되고 사용자가 일반 텍스트 비밀번호를 제공할 경우 비밀번호 저장 형식이 Directory Server에 대한 기본 비밀번호 저장 방법으로 전환됩니다. 일반 텍스트 비밀번호를 APOP, CRAM-MD5 또는 DIGEST-MD5로 마이그레이션하는 데 사용할 수 있습니다. 

기본값: False 

service.imap.allowanonymouslogin

IMAP에 사용하기 위해 SASL ANONYMOUS 기법을 사용 가능하게 합니다. 

기본값: False 

service.{imap|pop|http} .plaintextmincipher

이 매개 변수가 > 0이면 보안 계층(SSL 또는 TLS)이 활성화되지 않은 경우 일반 텍스트 비밀번호를 사용할 수 없게 됩니다. 사용자는 로그인하려면 네트워크상에서 비밀번호가 공개되는 것을 방지하는 SSL 또는 TLS를 클라이언트에서 사용 가능하게 해야 합니다. MMP는 동일한 옵션 "RestrictPlainPasswords"를 가집니다. 

주의: Messaging Server의 5.2 릴리스는 SSL 또는 TLS에 의해 협상된 암호문 강도에 대해 실제로 값을 검사합니다. 이 옵션을 단순화하고 일반적인 사용을 더 잘 반영하기 위해 이 기능이 제거되었습니다. 

기본값: 0 

sasl.default.mech_list

사용 가능하게 할 SASL 기법의 공백으로 구분된 목록입니다. 비어 있지 않을 경우 이 옵션은 sasl.default.ldap.has_plain_passwords 및 service.imap.allowanonymouslogin 옵션을 모두 무시합니다. 이 옵션은 모든 프로토콜(imap, pop, smtp)에 적용됩니다.

기본값: False 

sasl.default.ldap.searchfilter

도메인의 inetDomainSearchFilter에 지정되지 않은 경우 사용자를 조회하는 데 사용되는 기본 검색 필터입니다. 구문은 inetDomainSearchFilter(스키마 설명서 참조)와 동일합니다.

기본값: (&(uid=%U)(objectclass=inetmailuser))

sasl.default.ldap.searchfordomain

기본적으로 인증 시스템은 도메인 조회 규칙에 따라(즉, 필요에 따라) LDAP에서 도메인을 조회한 다음 사용자를 조회합니다. 그러나 이 옵션이 기본값 "1"이 아니라 "0"으로 설정된 경우 도메인 조회는 수행되지 않으며 sasl.default.ldap.searchfilter를 사용한 사용자 검색이 local.ugldapbasedn에 지정된 LDAP 트리에서 직접 수행됩니다. 이것은 레거시 단일 도메인 스키마와의 호환성을 위해 제공되지만 심지어 소규모 회사에서도 여러 도메인에 대한 지원이 필요한 합병이나 사명 변경이 발생할 수 있으므로 새 배포에는 사용하지 않는 것이 좋습니다.

일반 텍스트 비밀번호에 대한 액세스 구성

CRAM-MD5, DIGEST-MD5 또는 APOP SASL 인증 방법을 사용하려면 사용자의 일반 텍스트 비밀번호에 대한 액세스가 필요합니다. 다음 단계를 수행해야 합니다.

  1. 비밀번호를 일반 텍스트로 저장하도록 Directory Server를 구성합니다.

  2. Directory Server가 일반 텍스트 비밀번호를 사용한다는 것을 인식하도록 Messaging Server를 구성합니다.

ProcedureDirectory Server를 구성하여 일반 텍스트 비밀번호를 저장하는 방법

CRAM-MD5, DIGEST-MD5 또는 APOP 기법을 사용하려면 다음과 같이 Directory Server를 구성하여 비밀번호를 일반 텍스트로 저장하게 해야 합니다.

단계

  1. 콘솔에서 구성할 Directory Server를 엽니다.

  2. 구성 탭을 누릅니다.

  3. 왼쪽 표시 영역에서 데이터를 엽니다.

  4. 오른쪽 표시 영역에서 비밀번호를 누릅니다.

  5. 비밀번호 암호화 드롭다운 목록에서 "일반 텍스트"를 선택합니다.

    주 –

    이 변경 사항은 앞으로 만들 사용자에만 영향을 줍니다. 이 변경 이후에 기존 사용자는 자신의 비밀번호를 전환하거나 재설정해야 합니다.

Messaging Server에 일반 텍스트 비밀번호 구성

이제 Messaging Server를 구성하여 Directory Server가 일반 텍스트 비밀번호를 검색할 수 있다는 것을 인식하도록 할 수 있습니다. 이렇게 하면 Messaging Server는 APOP, CRAM-MD5 및 DIGEST-MD5를 안전하게 광고할 수 있습니다.

configutil -o sasl.default.ldap.has_plain_passwords -v 1

값을 0으로 설정하여 이러한 챌린지/응답 SASL 기법을 사용 불가능하게 할 수 있습니다.

주 –

기존 사용자는 비밀번호를 재설정하거나 마이그레이션할 때까지 APOP, CRAM-MD5 또는 DIGEST-MD5를 사용할 수 없습니다(사용자 전환 참조).

MMP는 CRAM과 동등한 옵션을 가집니다.

사용자 전환

configutil을 사용하여 사용자 전환에 대한 정보를 지정할 수 있습니다. 적절한 항목을 갖고 있지 않은 기법으로 클라이언트가 인증을 시도하거나 사용자 비밀번호가 변경되는 경우를 예로 들 수 있습니다.

configutil -o sasl.default.auto_transition -v value

value의 경우 다음 중 하나를 지정할 수 있습니다.

사용자를 성공적으로 전환하려면 사용자 비밀번호 속성에 대한 쓰기 권한을 Messaging Server에 허용하는 ACI를 Directory Server에서 설정해야 합니다. 이렇게 하려면 다음 단계를 수행합니다.

Procedure사용자 전환

단계

  1. 콘솔에서 구성할 Directory Server를 엽니다.

  2. 디렉토리 탭을 누릅니다.

  3. 사용자/그룹 트리의 기본 접미어를 선택합니다.

  4. 객체 메뉴에서 액세스 권한을 선택합니다.

  5. "Messaging Server 최종 사용자 관리자 쓰기 액세스 권한"에 대한 ACI를 선택(두 번 누름)합니다.

  6. ACI 속성을 누릅니다.

  7. userpassword 속성을 기존 속성 목록에 추가합니다.

  8. 확인을 누릅니다.

    sasl.default.mech_list를 사용하여 SASL 기법의 목록을 사용 가능하게 할 수 있습니다. 비어 있지 않을 경우 이 옵션은 sasl.default.ldap.has_plain_passwords 및 service.imap.allowanonymouslogin 옵션을 모두 무시합니다. 이 옵션은 모든 프로토콜(imap, pop, smtp)에 적용됩니다.

사용자 비밀번호 로그인

Messaging Server에 로그인하여 메일을 주고 받으려는 사용자에게 비밀번호 제출을 요구하는 것은 무단 액세스를 방지하는 첫 번째 방법입니다. Messaging Server는 IMAP, POP, HTTP 및 SMTP 서비스에 대한 비밀번호 기반 로그인을 지원합니다.

IMAP, POP 및 HTTP 비밀번호 로그인

기본적으로 내부 사용자는 Messaging Server에서 메일을 검색하기 위해 비밀번호를 제출해야 합니다. 관리자는 POP, IMAP 및 HTTP 서비스에 대한 비밀번호 로그인을 별개로 사용 가능 또는 불가능하게 합니다. POP, IMAP 및 HTTP 서비스의 비밀번호 로그인에 대한 자세한 내용은 비밀번호 기반 로그인을 참조하십시오.

사용자 비밀번호는 사용자의 클라이언트 소프트웨어에서 서버로 일반 텍스트 또는 암호화된 형식으로 전송할 수 있습니다. 클라이언트와 서버가 둘 다 SSL을 사용 가능하게 구성되고 SSL 사용 및 암호문 선택에 설명된 것처럼 필요한 강도의 암호화를 지원할 경우 암호화가 수행됩니다.

사용자 아이디와 비밀번호는 설치 시의 LDAP 사용자 디렉토리에 저장됩니다. 최소 길이와 같은 비밀번호 보안 조건은 디렉토리 정책 요구 사항에 의해 결정되며 Messaging Server 관리의 일부가 아닙니다.

인증서 기반 로그인은 비밀번호 기반 로그인의 대안입니다. 이 장에서 SSL의 나머지 내용을 다루면서 인증서 기반 로그인이 설명됩니다. 인증서 기반 로그인 설정을 참조하십시오.

챌린지/응답 SASL 기법은 일반 텍스트 비밀번호 로그인의 또 다른 대안입니다.

SMTP 비밀번호 로그인

기본적으로 사용자는 메일을 보내기 위해 Messaging Server의 SMTP 서비스에 연결할 때 비밀번호를 제출할 필요가 없습니다. 그러나 관리자는 인증된 SMTP를 사용할 수 있도록 SMTP에 대한 비밀번호 로그인을 사용 가능하게 할 수 있습니다.

인증된 SMTP는 클라이언트를 서버에 대해 인증할 수 있는 SMTP 프로토콜의 확장입니다. 이 인증에는 메일이 수반됩니다. 인증된 SMTP는 주로 이동 중이거나 홈 ISP를 사용하는 로컬 사용자가 열린 중계(다른 사용자가 남용할 수 있는)를 만들지 않고 메일을 전달하도록 허용하기 위해 사용됩니다. 클라이언트는 서버에 대해 인증되도록 "AUTH" 명령을 사용합니다.

SMTP 비밀번호 로그인과 이에 따라 인증된 SMTP를 사용 가능하게 하는 방법은 SMTP 인증, SASL 및 TLS를 참조하십시오.

SSL 암호화를 함께 사용하거나 사용하지 않으면서 인증된 SMTP를 사용할 수 있습니다.

암호화 및 인증서 기반 인증 구성

이 절에는 다음과 같은 하위 절이 포함됩니다.

Messaging Server는 클라이언트 및 서버의 암호화된 통신과 인증서 기반 인증을 위해 TLS(Transport Layer Security) 프로토콜(또는 SSL(Secure Sockets Layer) 프로토콜로 알려져 있음)을 사용합니다. Messaging Server는 SSL 버전 3.0 및 3.1을 지원합니다. TLS는 SSL과 완전히 호환되며 필요한 모든 SSL 기능을 포함합니다.

SSL에 대한 배경 정보는 Introduction to SSL(Managing Servers with iPlanet Console의 부록으로 제공됨)을 참조하십시오. SSL은 Introduction to Public-Key Cryptography(Managing Servers with iPlanet Console의 부록으로 제공됨)에 설명되어 있는 공개 키 암호화의 개념에 기초합니다.

Messaging Server와 클라이언트 간의 메일이나 Messaging Server와 다른 서버 간의 메일 전송이 암호화될 경우 통신에서 도청이 발생할 가능성이 거의 없습니다. 또한 연결하는 클라이언트가 인증될 경우 침입자가 클라이언트를 가장(스푸핑)할 가능성이 거의 없습니다.

SSL은 IMAP4, HTTP, POP3 및 SMTP의 응용 프로그램 계층 아래에 있는 프로토콜 계층의 기능을 수행합니다. SMTP 및 SMTP/SSL은 같은 포트를 사용하고 HTTP 및 HTTP/SSL에는 다른 포트가 필요하며 IMAP 및 IMAP/SSL과 POP 및 POP/SSL은 같은 포트나 다른 포트를 사용할 수 있습니다. 그림 19–1에 나온 것처럼 SSL은 보내는 메일과 받는 메일 모두에 대해 특정 메일 통신 단계에서 작동합니다.

그림 19–1 Messaging Server와의 암호화된 통신

이 그림은 암호화된 받는 메일 및 보내는 메일을 보여 줍니다.

SSL은 홉 간의 암호화를 제공하지만 메일은 각 중간 서버에서 암호화되지 않습니다.

주 –

보내는 메일에 대한 암호화를 사용하려면 maytls, musttls 등의 tls 채널 키워드를 포함하도록 채널 정의를 수정해야 합니다. 자세한 내용은 전송 계층 보안을 참조하십시오.

SSL 연결을 설정하는 과정에서 발생하는 추가 오버헤드가 서버의 성능에 부담을 줄 수 있다는 것에 주의합니다. 따라서 메시징 설치를 디자인하고 성능을 분석할 경우 서버 용량과 보안 요구 사항 간에 적절히 균형을 맞추는 것이 필요합니다.

주 –

모든 Sun Java System 서버가 SSL을 지원하며 콘솔을 통해 SSL을 사용 가능하게 하고 구성하기 위한 인터페이스가 대부분의 서버에서 거의 동일하기 때문에 이 절에 설명된 여러 작업은 Managing Servers with iPlanet Console의 SSL 장에 더 자세하게 설명되어 있습니다. 이 장에서는 이러한 작업에 대한 요약 정보만 제공합니다.

관리 콘솔을 통해 인증서 얻기

SSL을 암호화에 사용하는지 아니면 인증에 사용하는지 여부에 상관 없이 Messaging Server에 대한 서버 인증서를 얻어야 합니다. 인증서는 해당 서버를 클라이언트와 다른 서버에 대해 식별합니다. 관리 콘솔을 통해 인증서를 얻으려면 이 절의 단계를 수행합니다. 명령줄 모드에서 자체 서명된 인증서를 만들려면 자체 서명된 인증서 만들기를 참조하십시오.

내부 및 외부 모듈 관리

서버 인증서는 데이터를 암호화 및 해독하는 데 사용되는 숫자인 키 쌍의 소유권과 유효성을 설정합니다. 서버 인증서와 키 쌍은 서버의 신원을 나타내며 서버 내부이거나 외부의 이동식 하드웨어 카드(스마트 카드)가 될 수 있는 인증서 데이터베이스에 저장됩니다.

Sun Java System 서버는 PKCS(Public-Key Cryptography System) #11 API를 따르는 모듈을 사용하여 키 및 인증서 데이터베이스에 액세스합니다. 특정 하드웨어 장치의 PKCS #11 모듈은 일반적으로 해당 제공자로부터 얻을 수 있으며 Messaging Server에 설치한 후에만 Messaging Server에서 해당 장치를 사용할 수 있습니다. 미리 설치된 "Netscape Internal PKCS # 11 Module"은 서버 내부의 인증서 데이터베이스를 사용하는 단일 내부 소프트웨어 토큰을 지원합니다.

인증서 사용을 위해 서버를 설정하는 작업에는 인증서와 해당 키를 위한 데이터베이스를 만들고 PKCS #11 모듈을 설치하는 것이 포함됩니다. 외부 하드웨어 토큰을 사용하지 않을 경우 서버에서 내부 데이터베이스를 만들고 Messaging Server의 일부인 내부 기본 모듈을 사용합니다. 외부 토큰을 사용할 경우 하드웨어 스마트 카드 판독기를 연결하고 해당 PKCS #11 모듈을 설치합니다.

내부 및 외부 PKCS #11 모듈을 모두 콘솔을 통해 관리할 수 있습니다. PKCS #11 모듈을 설치하려면 다음을 수행합니다.

  1. 하드웨어 카드 판독기를 Messaging Server 호스트 시스템에 연결하고 드라이버를 설치합니다.

  2. 콘솔에서 PKCS #11 관리 인터페이스를 사용하여 설치된 드라이버를 위한 PKCS #11 모듈을 설치합니다.

보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

하드웨어 암호화 가속기 설치. 암호화를 위해 SSL을 사용할 경우 하드웨어 암호화 가속기를 설치하여 메일을 암호화 및 해독하는 서버의 성능을 향상시킬 수 있습니다. 일반적으로 암호화 가속기는 서버 시스템에 영구적으로 설치된 하드웨어 보드와 소프트웨어 드라이버로 구성됩니다. Messaging Server는 PKCS #11 API를 따르는 가속기 모듈을 지원합니다. (이러한 모듈은 기본적으로 고유한 키를 저장하지 않으며 이를 위한 내부 데이터베이스를 사용하는 하드웨어 토큰입니다.) 가속기를 설치하려면 우선 하드웨어와 드라이버를 제조업체에서 지정한 대로 설치한 다음 하드웨어 인증서 토큰과 마찬가지로 PKCS #11 모듈을 설치하여 설치를 완료합니다.

Procedure서버 인증서 요청

콘솔에서 서버를 열고 인증서 설정 마법사를 실행하여 서버 인증서를 요청합니다. 이 마법사는 콘솔 메뉴나 Messaging Server 암호화 탭에서 액세스할 수 있습니다. 이 마법사를 사용하여 다음 작업을 수행합니다.

단계

  1. 인증서 요청을 생성합니다.

  2. 인증서를 발급한 인증 기관(CA)에 전자 메일로 요청을 보냅니다.

    CA로부터 전자 메일 응답이 도착하면 이를 텍스트 파일로 저장하고 인증서 설정 마법사를 사용하여 설치합니다.

    보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

Procedure인증서 설치

설치는 요청 생성과 별개의 프로세스입니다. 인증서 요청에 대한 전자 메일 응답이 CA로부터 도착했으며 이를 텍스트 파일로 저장한 후에는 인증서 설정 마법사를 한 번 더 실행하여 다음과 같이 파일을 인증서로 설치합니다.

단계

  1. 이미 얻은 인증서를 설치하고 있다는 것을 지정합니다.

  2. 인증서의 텍스트를 필드에 붙여넣습니다(그렇게 하라는 메일이 나타났을 때).

  3. 인증서 별명을 server-cert에서 Server-Cert로 변경합니다.

    인증서 별명을 변경하지 않으려면 configutil 매개 변수 encryption.rsa.nssslpersonalityssl을 설정하여 시스템에서 원하는 인증서 별명을 변경할 수 있습니다.

    보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 )

    주 –

    이것은 또한 다음에 설명하는 CA 인증서를 설치할 때 따르는 프로세스입니다. 서버는 CA 인증서를 사용하여 클라이언트가 제공한 인증서를 신뢰할지 여부를 결정합니다.

신뢰할 수 있는 CA의 인증서 설치

또한 인증서 설정 마법사를 사용하여 인증 기관의 인증서를 설치할 수 있습니다. CA 인증서는 CA 자체의 신원을 검증합니다. 서버는 클라이언트 및 다른 서버를 인증하는 과정에서 이러한 CA 인증서를 사용합니다.

예를 들어, 비밀번호 기반 인증 외에 인증서 기반 클라이언트 인증이 가능하도록 설정한 경우(157페이지의 "인증 기반 로그인 설정" 참조) 클라이언트가 제공할 수 있는 인증서를 발급하는 신뢰할 수 있는 모든 CA의 CA 인증서를 설치해야 합니다. 이러한 CA는 조직 내부에 대한 것이거나 민간 또는 정부 기관이나 다른 회사 등 외부에 대한 것일 수 있습니다. (인증을 위한 CA 인증서 사용에 대한 자세한 내용은 Managing Servers with iPlanet Console에서 Introduction to Public-Key Cryptography를 참조하십시오.)

Messaging Server를 설치하면 여러 상용 CA에 대한 CA 인증서가 기본적으로 포함되어 있습니다. 다른 상용 CA를 추가해야 하거나 회사에서 내부 용도의 고유한 CA를 개발(Sun Java System Certificate Server 사용)하는 중이면 추가 CA 인증서를 얻어 설치해야 합니다.

주 –

Messaging Server에서 자동으로 제공되는 CA 인증서는 처음에 클라이언트 인증서에 대해 신뢰할 수 있는 것으로 표시되지 않습니다. 따라서 이러한 CA에 의해 발급된 클라이언트 인증서를 신뢰하려면 트러스트 설정을 편집해야 합니다. 자세한 지침은 153페이지의 "인증 및 신뢰할 수 있는 CA 관리"를 참조하십시오.

새 CA 인증서를 요청하여 설치하려면 다음을 수행합니다.

Procedure새 CA 인증서 요청 및 설치 방법

단계

  1. 인증 기관에 문의하여(대부분의 웹 또는 전자 메일을 통해) 해당 CA 인증서를 다운로드합니다.

  2. 받은 인증서의 텍스트를 텍스트 파일로 저장합니다.

  3. 앞의 절에 설명된 대로 인증서 설정 마법사를 사용하여 인증서를 설치합니다.

    보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

인증서 및 신뢰할 수 있는 CA 관리

서버는 신뢰할 수 있는 CA의 여러 인증서를 클라이언트 인증에 사용할 수 있습니다.

콘솔에서 서버를 열고 콘솔 메뉴에서 인증서 관리 명령을 선택하여 Messaging Server에 설치된 모든 인증서를 확인하거나, 해당 트러스트 설정을 편집하거나, 인증서 자체를 삭제할 수 있습니다. 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

비밀번호 파일 만들기

모든 Sun Java System 서버에서 인증서 설정 마법사를 사용하여 인증서를 요청하면 마법사는 내부 모듈의 데이터베이스나 스마트 카드의 외부 데이터베이스에 저장되는 키 쌍을 만듭니다. 그런 다음 이 마법사는 개인 키를 암호화하는 데 사용되는 비밀번호를 묻는 메시지를 표시합니다. 나중에 이와 동일한 비밀번호를 통해서만 키를 해독할 수 있습니다. 이 마법사는 비밀번호를 보유하거나 임의의 위치에 저장하지 않습니다.

SSL이 사용 가능하게 되는 대부분의 Sun Java System 서버에서는 키 쌍을 해독하는 데 필요한 비밀번호를 제공하라는 메시지가 시작 시에 관리자에게 표시됩니다. 그러나 Messaging Server에서는 비밀번호를 여러 번 입력(최소한 세 개의 서버 프로세스에 필요함)하는 불편함을 없애고 무인 서버의 다시 시작을 용이하게 만들기 위해 비밀번호를 비밀번호 파일에서 읽습니다.

비밀번호 파일의 이름은 sslpassword.conf이며 msg_svr_base/config/ 디렉토리에 위치합니다. 이 파일의 항목은 다음 형식을 갖는 개별 행입니다.

moduleName:password

여기에서 moduleName은 사용할 내부 또는 외부 PKCS #11 모듈의 이름이며 password는 모듈의 키 쌍을 해독하는 비밀번호입니다. 비밀번호는 일반(암호화되지 않은) 텍스트로 저장됩니다.

Messaging Server는 내부 모듈 및 기본 비밀번호를 위한 다음과 같은 단일 항목을 가지는 기본 버전의 비밀번호 파일을 제공합니다.

Internal (Software) Token:netscape!

내부 인증서를 설치할 때 기본값이 아닌 비밀번호를 지정할 경우 비밀번호 파일의 위 행을 편집하여 지정된 비밀번호를 반영해야 합니다. 외부 모듈을 설치할 경우 이에 대해 지정한 모듈 이름과 비밀번호를 포함하는 새 행을 파일에 추가해야 합니다.

주의 – 주의 –

서버 시작 시에 모듈 비밀번호를 묻는 메시지가 관리자에게 표시되지 않으므로 서버에 대한 관리자 액세스 제어와 서버 호스트 시스템 및 해당 백업의 물리적 보안을 적절하게 하는 것이 특히 중요합니다.

자체 서명된 인증서 만들기

명령줄모드에서자체서명된인증서를만들려면이절의지침을따릅니다인증서 마법사를 사용하여 인증서를 만들려면 관리 콘솔을 통해 인증서 얻기 를 참조하십시오.

Procedure자체 서명된 인증서 만들기

단계

  1. 수퍼유저로 로그인하거나 수퍼유저(root)가 됩니다.

  2. /opt/SUNWmsgsr/config/sslpassword에서 certutil에 대한 인증서 데이터베이스 비밀번호를 지정합니다. 예를 들면 다음과 같습니다.


    # echo "password" > /opt/SUNWmsgsr/config/sslpassword

    여기서 password는 해당 비밀번호입니다.

  3. sbin 디렉토리로 이동하여 인증서 데이터베이스(cert8.db) 및 키 데이터베이스(key3.db)를 생성합니다. 예를 들면 다음과 같습니다.


    # cd /opt/SUNWmsgsr/sbin
# ./certutil -N -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword

  4. 자동 서명된 기본 루트 인증 기관 인증서를 생성합니다. 예:


    # ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
-s "CN=My Sample Root CA, O=sesta.com" -m 25000
-o /opt/SUNWmsgsr/config/SampleRootCA.crt
-d /opt/SUNWmsgsr/config
-f /opt/SUNWmsgsr/config/sslpassword   -z /etc/passwd

  5. 호스트에 대한 인증서를 생성합니다. 예를 들면 다음과 같습니다.


    ../certutil -S -n Server-Cert -c SampleRootCA -t "u,u,u"
-s "CN=hostname.sesta.com, o=sesta.com" -m 25001
-o /opt/SUNWmsgsr/config/SampleSSLServer.crt
-d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword
-z /etc/passwd

    여기서 hostname.sesta.com은 서버 호스트 이름입니다.

  6. 인증서의 유효성을 검사합니다. 예를 들면 다음과 같습니다.


    # ./certutil -V -u V -n  SampleRootCA -d /opt/SUNWmsgsr/config
# ./certutil -V -u V -n  Server-Cert -d /opt/SUNWmsgsr/config

  7. 인증서를 나열합니다. 예를 들면 다음과 같습니다.


    # ./certutil -L -d /opt/SUNWmsgsr/config
# ./certutil -L -n Server-Cert -d /opt/SUNWmsgsr/config

  8. modutil을 사용하여 사용 가능한 보안 모듈(secmod.db)을 나열합니다. 예를 들면 다음과 같습니다.


    # ./modutil -list -dbdir /opt/SUNWmsgsr/config

  9. 예에 나온 것처럼 인증서 데이터베이스 파일의 소유자를 메일 서버 사용자 및 그룹으로 변경합니다.


    chown mailsrv:mail /opt/SUNWmsgsr/config/cert8.db
chown mailsrv:mail /opt/SUNWmsgsr/config/key3.db

  10. 메시징 서비스를 다시 시작하여 SSL을 활성화합니다.

    주 –

    이전에는 인증서와 키 파일이 항상 Messaging Server 구성 디렉토리에 있었습니다. 이제는 이러한 파일의 위치를 local.ssldbpath(인증서 및 키 파일의 위치 지정) 및 local.ssldbprefix(인증서 및 키 파일의 접두어 지정)를 사용하여 지정하는 일이 )

SSL 사용 및 암호문 선택

콘솔을 사용하여 SSL을 사용 가능하게 하고 Messaging Server가 클라이언트와의 암호화된 통신에 사용할 수 있는 암호화 암호문 집합을 선택할 수 있습니다.

암호문 정보

암호문은 암호화 프로세스에서 데이터를 암호화 및 해독하는 데 사용되는 알고리즘입니다. 일부 암호문은 다른 암호문보다 강력한데 이는 이러한 암호문으로 스크램블된 메일을 권한 없는 사용자가 해독하는 것이 더 어렵다는 것을 의미합니다.

암호문은 키(긴 번호)를 데이터에 적용하는 방법으로 데이터에서 작동합니다. 일반적으로 암호문이 암호화 도중에 사용하는 키가 더 길수록 적절한 암호화 키 없이 데이터를 해독하는 것이 어려워집니다.

클라이언트는 Messaging Server와의 SSL 연결을 시작할 때 암호화에 사용할 선호되는 암호문과 키 길이를 서버에 알려줍니다. 모든 암호화된 통신에서 클라이언트와 서버는 동일한 암호문을 사용해야 합니다. 일반적으로 다양한 암호문 및 키 조합이 사용되기 때문에 서버는 암호화를 유연하게 지원해야 합니다. Messaging Server는 암호문 및 키 길이 조합을 최대 6개까지 지원할 수 있습니다.

표 19–2에는 SSL 3.0과 함께 사용하는 Messaging Server에서 지원하는 암호문을 나열합니다. 이 표에 요약된 정보의 자세한 내용은 Managing Servers with iPlanet Console의 Introduction to SSL 절에서 확인할 수 있습니다.

표 19–2 Messaging Server의 SSL 암호문

암호문 

설명 

128비트 암호화 및 MD5 메일 인증을 사용하는 RC4 

가장 빠른 암호화 암호문(RSA에 의한)이며 강도가 매우 높은 암호문 및 암호화 키의 조합입니다. 

168비트 암호화 및 SHA 메일 인증을 사용하는 Triple DES 

더 느린 암호화 암호문(미국 정보 표준)이지만 강도가 가장 높은 암호문 및 암호화 키의 조합입니다. 

56비트 암호화 및 SHA 메일 인증을 사용하는 DES 

더 느린 암호화 암호문(미국 정보 표준)이며 강도가 보통인 암호문 및 암호화 키의 조합입니다. 

40비트 암호화 및 MD5 메일 인증을 사용하는 RC4 

가장 빠른 암호화 암호문(RSA에 의한)이며 강도가 낮은 암호문 및 암호화 키의 조합입니다. 

40비트 암호화 및 MD5 메일 인증을 사용하는 RC2 

더 느린 암호화 암호문(RSA에 의한)이며 강도가 낮은 암호문 및 암호화 키의 조합입니다. 

암호화 없음, MD5 메일 인증만 사용 

암호화가 없으며 메일 다이제스트만 인증에 사용됩니다. 

특정 암호문을 사용하지 않을 중요한 이유가 없을 경우 모든 암호문을 지원해야 합니다. 그러나 일부 국가에서는 수출법에 따라 특정 암호화 암호문의 사용이 제한된다는 것에 주의합니다. 또한 미국 수출 제한법이 완화되기 전에 만들어진 일부 클라이언트 소프트웨어는 더 높은 강도의 암호화를 사용할 수 없습니다. 40비트 암호문이 우발적인 도청을 방지할 수 있지만 보안되지는 않으므로 적극적인 공격을 차단하지 않는다는 것에 주의합니다.

SSL을 사용 가능하게 하고 암호화 암호문을 선택하려면 다음 명령줄 단계를 따릅니다.

SSL을 사용 또는 사용하지 않으려면 다음을 수행합니다.

configutil -o nsserversecurity -v [ on | off ]

RSA 암호문을 사용 또는 사용하지 않으려면 다음을 수행합니다.

configutil -o encryption.rsa.nssslactivation -v [ on | off ]

토큰을 지정하려면 다음을 수행합니다.

configutil -o encryption.rsa.nsssltoken -v tokenname

인증서를 지정하려면 다음을 수행합니다.

configutil -o encryption.rsa.nssslpersonalityssl -v certname

RSA 암호문을 사용 가능하게 할 경우 또한 토큰과 인증서를 지정해야 한다는 것에 주의합니다.

암호문 기본 설정을 선택하려면 다음을 수행합니다.

configutil -o encryption.nsssl3ciphers -v cipherlist

여기에서 cipherlist는 쉼표로 구분된 암호문 목록입니다.

주 –

보내는 메일에 대해 SSL 암호화를 사용하려면 채널 정의를 수정하여 maytls, musttls 등의 tls 채널 키워드를 포함해야 합니다. 자세한 내용은 전송 계층 보안을 참조하십시오.

인증서 기반 로그인 설정

비밀번호 기반 인증 외에도 Sun Java System 서버는 디지털 인증서 검사를 통한 사용자 인증을 지원합니다. 인증서 기반 인증에서 클라이언트는 서버와의 SSL 세션을 설정하고 사용자의 인증서를 서버로 제출합니다. 그런 다음 서버는 제출된 인증서가 진짜인지 여부를 평가합니다. 인증서가 검증될 경우 사용자는 인증된 것으로 간주됩니다.

인증서 기반 로그인을 사용하도록 Messaging Server를 설정하려면 다음을 수행합니다.

Procedure인증서 기반 로그인 설정

단계

  1. 서버의 서버 인증서를 얻습니다. 자세한 내용은 관리 콘솔을 통해 인증서 얻기 를 참조하십시오.

  2. 인증서 설정 마법사를 실행하여 서버가 인증할 사용자에게 인증서를 발급하는 신뢰할 수 있는 모든 인증 기관의 인증서를 설치합니다. 자세한 내용은 신뢰할 수 있는 CA의 인증서 설치을 참조하십시오.

    서버의 데이터베이스에 최소한 하나 이상의 신뢰할 수 있는 CA가 있을 경우 서버는 각 연결 클라이언트로부터 클라이언트 인증서를 요청한다는 것에 주의합니다.

  3. SSL을 설정합니다. 자세한 내용은 SSL 사용 및 암호문 선택을 참조하십시오.

  4. (선택 사항) 제출된 인증서의 정보에 기초하여 서버가 LDAP 사용자 디렉토리를 적절하게 검색하도록 서버의 certmap.conf 파일을 편집합니다.

    사용자의 인증서에 있는 전자 메일 주소가 사용자의 디렉토리 항목에 있는 전자 메일 주소와 일치하며 검색을 최적화하거나 사용자 항목의 인증서에 대해 제출된 인증서를 검증할 필요가 없을 경우에는 certmap.conf 파일을 편집할 필요가 없습니다.

    certmap.conf의 형식과 변경할 수 있는 사항에 대한 자세한 내용은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

    이러한 단계를 수행하고 나면 사용자가 IMAP 또는 HTTP에 로그인할 수 있도록 클라이언트가 SSL 세션을 설정할 때 Messaging Server는 클라이언트로부터 사용자의 인증서를 요청합니다. 클라이언트에 의해 제출된 인증서가 서버에서 신뢰할 수 있는 것으로 설정한 CA가 발급했으며 인증서의 아이디가 사용자 디렉토리의 항목과 일치할 경우 사용자가 인증되며 액세스가 허가됩니다(해당 사용자를 제어하는 액세스 제어 규칙에 따라).

    인증서 기반 로그인을 사용 가능하게 하기 위해 비밀번호 기반 로그인을 허용하지 않을 필요는 없습니다. 비밀번호 기반 로그인이 허용되는 기본 상태에서 이 절에 설명된 작업을 수행할 경우 비밀번호 기반 및 인증서 기반 로그인이 모두 지원됩니다. 이 경우 클라이언트가 SSL 세션을 설정하고 인증서를 제공할 경우 인증서 기반 로그인이 사용됩니다. 클라이언트가 SSL을 사용하지 않거나 인증서를 제공하지 않을 경우 서버는 비밀번호를 요청합니다.

SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법

SMTP 프록시는 SMTP 프로토콜에 추가 대기 시간을 야기하므로 대부분의 사이트는 SMTP 프록시를 사용해서는 안 됩니다. 그러나 SMTP 연결을 보호하기 위해 SSL에 많이 의존하는 대규모 사이트는 SSL 및 프록시 외에는 일체 수행하지 않는 서버에서 모든 프로토콜에 대해 모든 SSL 작업을 수행하여 SSL 가속기 하드웨어에 대한 투자를 극대화하길 원할 수 있습니다. SMTP 프록시를 사용하면 메일 대기열을 별개의 MTA 시스템에 두면서 SSL을 프런트엔드 프록시 서버에서 처리할 수 있습니다. 이러한 방법으로 각 작업에 대해 최적화된 하드웨어를 별도로 구성 및 구입할 수 있습니다.

SMTP 프록시를 설치하는 방법에 대한 지침은 POP before SMTP 사용를 참조하십시오.

네트워크 보안 서비스 도구

네트워크 보안 서비스는 개방형 표준을 기반으로 하는 인터넷 보안 응용 프로그램을 구현 및 배포하는 데 사용되는 오픈 소스 라이브러리 및 도구 집합입니다. 이러한 보안 도구는 진단을 수행하고 인증서, 키 및 암호화 모듈을 관리하며 SSL 및 TLS 기반 응용 프로그램을 디버깅하는 데 도움이 됩니다. 이러한 도구는 /usr/sfw/bin에 있습니다.

인증서 및 키 관리

이 절에 설명된 도구는 암호화와 식별에 사용되는 키와 인증서를 저장, 검색 및 보호합니다.

certutil

인증서 데이터베이스 도구인 certutil은 cert8.db 및 key3.db 데이터베이스 파일을 작성 및 수정할 수 있는 명령줄 유틸리티입니다. 키와 인증서 관리 프로세스는 일반적으로 키 데이터베이스에서 키를 만든 다음 인증서 데이터베이스에서 인증서를 생성 및 관리합니다. certutil에 대한 자세한 내용은 다음 URL을 참조하십시오.

http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html

cmsutil

cmsutil 명령줄 유틸리티는 S/MIME 툴킷을 사용하여 CMS(Cryptographic Message Syntax) 메일에 대한 암호화 및 해독과 같은 기본 작업을 수행합니다. 이 유틸리티는 메일 암호화, 해독, 서명 등의 기본 인증서 관리 작업을 수행합니다. cmsutil에 대한 자세한 내용은 다음 URL을 참조하십시오.

http://www.mozilla.org/projects/security/pki/nss/tools/cmsutil.html

modutil

보안 모듈 데이터베이스 도구인 modutil은 PKCS #11 모듈(secmod.db 파일)의 데이터베이스를 관리하기 위한 명령줄 유틸리티입니다. 이 도구를 사용하면 PKCS #11 모듈 추가 및 삭제, 암호 변경, 기본값 설정, 모듈 내용 나열, 슬롯 활성화 또는 비활성화, FIPS-140-1 확인 활성화 또는 비활성화, 암호화 작업을 위한 기본 공급자 할당 등을 수행할 수 있습니다. modutil에 대한 자세한 내용은 다음 URL을 참조하십시오.

http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html

pk12util

pk12util 명령줄 유틸리티는 PKCS #12 표준에 의해 정의된 키와 인증서를 해당 데이터베이스 및 파일 형식으로 가져오거나 내보냅니다. pk12util에 대한 자세한 내용은 다음 URL을 참조하십시오.

http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html

ssltap

SSL 디버깅 도구인 ssltap은 SSL 인식 명령줄 프록시입니다. 이 도구는 SSL 서버에 대한 요청을 프록시하고 클라이언트 및 서버 간에 교환되는 메일의 내용을 표시할 수 있습니다. 이 도구는 TCP 연결을 감시하여 전송되는 데이터를 표시합니다. 연결이 SSL인 경우에는 해석된 SSL 레코드와 핸드셰이킹이 데이터 표시에 포함됩니다. 자세한 내용은 다음 URL 을 참조하십시오.

http://www.mozilla.org/projects/security/pki/nss/tools/ssltap.html

Messaging Server에 대한 관리자 액세스 구성

이 절의 내용은 주로 Sun Java System LDAP Schema v. 1과 관련됩니다. 이 절은 다음과 같은 하위 절로 구성되어 있습니다.

이 절에서는 Messaging Server에 대한 액세스 권한을 서버 관리자가 어떻게 얻을 수 있는지 제어하는 방법에 대해 설명합니다. 주어진 Messaging Server와 특정 Messaging Server 작업에 대한 관리 액세스는 위임된 서버 관리의 컨텍스트 내에서 발생합니다.

위임된 서버 관리는 대부분의 Sun Java System 서버가 갖고 있는 기능으로서 특정 관리자가 개별 서버 또는 서버 기능에 대한 선택적 액세스를 다른 관리자에게 제공하는 기능을 말합니다. 이 장에서는 위임된 서버 작업을 간단하게 요약하여 설명합니다. 자세한 내용은 Managing Servers with iPlanet Console에서 서버 관리 위임에 대한 장을 참조하십시오.

위임된 관리 계층

네트워크에 Sun Java System 서버를 처음 설치하면 설치 프로그램은 LDAP 사용자 디렉토리에 구성 관리자 그룹이라는 그룹을 자동으로 만듭니다. 기본적으로 구성 관리자 그룹의 구성원은 네트워크의 모든 호스트와 서버에 대한 무제한적인 액세스 권한을 가집니다.

구성 관리자 그룹은 Messaging Server에 대한 위임된 관리를 구현(Sun Java System LDAP Schema v. 1이 사용될 경우)하기 위해 작성할 수 있는 다음과 같은 액세스 계층의 최상위에 위치합니다.

  1. 구성 관리자.Sun Java System 서버의 네트워크에 대한 "수퍼유저"입니다. 모든 자원에 대한 전체 액세스 권한을 가집니다.

  2. 서버 관리자. 도메인 관리자는 각 유형의 서버를 관리하기 위해 그룹을 만들 수 있습니다. 예를 들어, 관리 도메인이나 전체 네트워크에서 모든 Messaging Server를 관리하기 위해 메시징 관리자 그룹을 만들 수 있습니다. 이러한 그룹의 구성원은 다른 서버는 제외하고 해당 관리 도메인의 모든 Messaging Server에 액세스할 수 있습니다.

  3. 작업 관리자. 마지막으로 위 관리자는 모두 단일 Messaging Server 또는 Messaging Server 집합에 대한 제한된 액세스 권한을 가진 그룹을 만들거나 개별 사용자를 지정할 수 있습니다. 이러한 작업 관리자는 서버를 시작 또는 중지하거나 특정 서비스의 로그를 액세스하는 등의 제한된 특정 서버 작업만 수행할 수 있습니다.

콘솔은 관리자가 다음 작업을 수행할 수 있는 편리한 인터페이스를 제공합니다.

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

이 절에서는 특정 Messaging Server 인스턴스에 대한 액세스 권한을 사용자나 그룹에 제공하는 방법에 대해 설명합니다.

단계

  1. 액세스를 제공할 Messaging Server에 액세스할 수 있는 관리자로서 콘솔에 로그인합니다.

  2. 콘솔 창에서 해당 서버를 선택합니다.

    콘솔 메뉴에서 객체를 선택한 다음 액세스 권한 설정을 선택합니다.

  3. 서버를 액세스할 수 있는 사용자 및 그룹 목록을 추가하거나 편집합니다.

    보다 자세한 지침은 Managing Servers with iPlanet Console에서 서버 관리 위임에 대한 장을 )

    특정 Messaging Server에 액세스할 수 있는 개인 및 그룹 목록을 설정한 후에는 다음에 설명된 것처럼 ACI를 사용하여 특정 서버 작업을 해당 목록의 특정 개인 또는 그룹에 위임할 수 있습니다.

특정 작업에 대한 액세스 제한

관리자는 일반적으로 하나 이상의 관리 작업을 수행하기 위해 서버에 연결합니다. 일반 관리 작업은 콘솔에서 Messaging Server 작업 양식에 나열됩니다.

기본적으로 특정 Messaging Server에 대한 액세스는 모든 해당 작업에 대한 액세스를 의미합니다. 그러나 작업 양식의 각 작업은 추가된 액세스 제어 명령(ACI) 집합을 가질 수 있습니다. 서버는 작업에 대한 액세스를 연결된 사용자(서버 전체에 대한 액세스 권한을 이미 갖고 있는 사용자)에게 제공하기 전에 이러한 ACI를 참조합니다. 실제로 서버는 사용자가 권한을 갖고 있는 작업만 작업 양식에 표시합니다.

Messaging Server에 액세스할 수 있는 경우 임의의 작업(즉, 액세스할 수 있는 작업)에 대한 ACI를 작성 및 편집함으로써 다른 사용자나 그룹이 가질 수 있는 작업 액세스 권한을 제한할 수 있습니다.

Procedure사용자 또는 그룹의 작업 액세스 제한 방법

단계

  1. 제한된 액세스를 제공할 Messaging Server에 액세스할 수 있는 관리자로서 콘솔에 로그인합니다.

  2. 서버를 열고 작업 텍스트를 눌러 서버의 작업 양식에서 작업을 선택합니다.

  3. 편집 메뉴에서 액세스 권한 설정을 선택하고 액세스 규칙 목록을 추가 또는 편집하여 사용자나 그룹에 원하는 종류의 액세스를 제공합니다.

  4. 다른 작업에 대해 적절하게 이 과정을 반복합니다.

    보다 자세한 지침은 Managing Servers with iPlanet Console에서 서버 관리 위임에 대한 장을 )

    ACI와 ACI 작성 방법에 대한 자세한 내용은 Managing Servers with iPlanet Console에서 서버 관리 위임에 대한 장에 자세히 설명되어 있습니다.

POP, IMAP 및 HTTP 서비스에 대한 클라이언트 액세스 구성

이 절에는 다음과 같은 하위 절이 포함됩니다.

Messaging Server는 서버에 액세스할 수 있는 클라이언트를 광범위하고 세부적으로 제어할 수 있도록 IMAP, POP 및 HTTP 서비스에 대한 정교한 서비스별 액세스 제어를 지원합니다.

대기업이나 인터넷 서비스 공급자에 대한 메시징 서비스를 관리하는 중이면 이러한 기능은 시스템에서 스팸 발송자 및 DNS 스푸퍼를 차단하고 네트워크의 일반 보안을 향상시키는 데 도움을 줄 수 있습니다. 특히 원하지 않은 대량 전자 메일을 제어하는 방법은 17 장, 메일 필터링 및 액세스 제어를 참조하십시오.

주 –

IP 주소별로 액세스를 제어하는 것이 기업의 중요한 문제가 아닐 경우 이 절에 설명된 필터를 만들 필요가 없습니다. 단지 최소한의 액세스 제어만 필요한 경우에는 대부분 허용에서 이를 설정하는 방법에 대한 지침을 참조하십시오.

클라이언트 액세스 필터의 작동 방법

Messaging Server 액세스 제어 기능은 서비스되는 TCP 데몬과 동일한 포트에서 수신하는 프로그램입니다. 즉, 이 기능은 액세스 필터를 사용하여 클라이언트 신원을 확인하며 클라이언트가 필터링 프로세스를 통과할 경우 데몬에 대한 액세스 권한을 클라이언트에게 제공합니다.

Messaging Server TCP 클라이언트 액세스 제어 시스템은 필요한 경우 처리 과정의 일부로서 소켓 종점 주소에 대한 다음 분석을 수행합니다.

시스템은 필터라고 부르는 액세스 제어문에 대해 이 정보를 비교하여 액세스를 허가 또는 거부할지 여부를 결정합니다. 각 서비스에 대해 별도의 허용 필터 및 거부 필터 집합이 액세스를 제어합니다. 허용 필터는 액세스를 명시적으로 허가하며 거부 필터는 액세스를 명시적으로 금지합니다.

클라이언트가 서비스에 대한 액세스를 요청하면 액세스 제어 시스템은 다음 조건을 사용하여 각 서비스의 필터에 대해 클라이언트의 주소 또는 이름 정보를 순서대로 비교합니다.

여기에서 설명된 필터 문은 간단한 방식으로 여러 다른 종류의 액세스 제어 정책을 구현할 수 있을 정도로 충분히 유연합니다. 거의 배타적인 허용 또는 거부를 사용하여 대부분의 정책을 구현할 수 있지만 허용 필터와 거부 필터를 둘 다 임의로 조합하여 사용할 수 있습니다.

다음 절에서는 필터 문을 자세하게 설명하고 사용 예를 제공합니다. 서비스에 대한 액세스 필터 만들기 절에서는 액세스 필터를 만들기 위한 절차에 대해 설명합니다.

필터 문

필터 문은 서비스 정보와 클라이언트 정보를 모두 포함합니다. 서비스 정보는 서비스 이름, 호스트 이름 및 호스트 주소를 포함할 수 있습니다. 클라이언트 정보는 호스트 이름, 호스트 주소 및 아이디를 포함할 수 있습니다. 서버 및 클라이언트 정보는 둘 다 와일드카드 이름이나 패턴을 포함할 수 있습니다.

가장 간단한 형식의 필터는 다음과 같습니다.

service: hostSpec

여기에서 service는 서비스 이름(예: smtp, pop, imap 또는 http)이고 hostSpec은 호스트 이름, IP 주소 또는 액세스를 요청하는 클라이언트는 나타내는 와일드카드 이름 또는 패턴입니다. 필터가 처리될 때 액세스를 요구하는 클라이언트가 client와 일치할 경우 service에 지정된 서비스에 대한 액세스가 해당 필터 유형에 따라 허용되거나 거부됩니다. 다음은 몇 가지 예입니다. 

imap: roberts.newyork.siroe.com
pop: ALL
http: ALL

이러한 필터가 허용 필터일 경우 첫 번째 필터는 IMAP 서비스에 대한 액세스를 roberts.newyork.siroe.com 호스트에 허가하고 두 번째 및 세 번째 필터는 각각 POP 및 HTTP 서비스에 대한 액세스를 모든 클라이언트에게 허가합니다. 이러한 필터가 거부 필터일 경우 이러한 클라이언트는 서비스에 대한 액세스가 거부됩니다. ALL과 같은 와일드카드 이름에 대한 자세한 내용은 와일드카드 이름을 참조하십시오.

필터가 더 일반적인 형식을 가질 경우 필터의 서버 또는 클라이언트 정보는 다음과 같이 다소 복잡할 수 있습니다.

serviceSpec: clientSpec

여기에서 serviceSpec은 service 또는 service@hostSpec이 될 수 있고 clientSpec은 hostSpec 또는 user@hostSpec이 될 수 있습니다. user는 액세스를 요구하는 클라이언트 호스트와 연관된 사용자 아이디 또는 와일드카드 이름입니다. 다음 두 개의 예를 가정해 봅니다.

pop@mailServer1.siroe.com: ALL
imap: srashad@xyz.europe.siroe.com

여기에서 이러한 필터가 거부 필터일 경우 첫 번째 필터는 mailServer1.siroe.com 호스트에서 SMTP 서비스에 대한 액세스를 모든 클라이언트에 대해 거부합니다. 두 번째 필터는 xyz.europe.siroe.com 호스트에서 사용자 srashad의 IMAP 서비스에 대한 액세스를 거부합니다. 이러한 확장된 서버 및 클라이언트 지정을 사용하는 시기에 대한 자세한 내용은 서버 호스트 지정 및 클라이언트 사용자 아이디 지정을 참조하십시오.

마지막으로 가장 일반적인 형식의 필터는 다음과 같습니다.

serviceList: clientList

여기에서 serviceList는 하나 이상의 serviceSpec 항목으로 구성되며 clientList는 하나 이상의 clientSpec 항목으로 구성됩니다. serviceList 및 clientList 내의 개별 항목은 공백 및/또는 쉼표로 구분됩니다.

여기에서는 필터가 처리될 때 액세스를 요구하는 클라이언트가 clientList의 clientSpec 항목 중 하나와 일치할 경우 serviceList에 지정된 모든 서비스에 대한 액세스가 해당 필터 유형에 따라 허용되거나 거부됩니다. 다음은 이에 대한 한 예입니다.

pop, imap, http: .europe.siroe.com .newyork.siroe.com

이 필터가 허용 필터일 경우 europe.siroe.com 또는 newyork.siroe.com 도메인에 있는 모든 클라이언트는 POP, IMAP 및 HTTP 서비스에 대한 액세스가 허가됩니다. 선행 점이나 다른 패턴을 사용하여 도메인 또는 서브넷을 지정하는 방법에 대한 자세한 내용은 와일드카드 패턴을 참조하십시오.

또한 다음 구문을 사용할 수도 있습니다.

“+” 또는 “-” serviceList:*$next_rule

+(허용 필터)는 클라이언트 목록에 대해 데몬 목록 서비스가 허가된다는 것을 의미합니다.

-(거부 필터)는 클라이언트 목록에 대해 서비스가 거부된다는 것을 의미합니다.

*(와일드카드 필터)는 모든 클라이언트가 이러한 서비스를 사용하도록 허용합니다.

$는 규칙을 구분합니다.

다음 예는 모든 클라이언트에서 여러 서비스를 사용 가능하게 합니다.

+imap,pop,http:*

다음 예는 여러 규칙을 표시하지만 각 규칙은 서비스 이름을 하나만 가지도록 단순화되며 클라이언트 목록에 와일드카드를 사용합니다. 이는 LDIF 파일에서 액세스 제어를 지정하기 위해 가장 일반적으로 사용되는 방법입니다.

+imap:ALL$+pop:ALL$+http:ALL

다음 예는 사용자에 대해 모든 서비스를 거부하는 방법을 보여 줍니다.

-imap:*$-pop:*$-http:*

와일드카드 이름

다음 와일드카드 이름을 사용하여 서비스 이름, 호스트 이름이나 주소, 또는 아이디를 나타낼 수 있습니다.

표 19–3 서비스 필터의 와일드카드 이름

와일드카드 이름 

설명 

ALL, *

범용 와일드카드입니다. 모든 이름과 일치합니다. 

LOCAL

모든 로컬 호스트(이름에 점 문자가 포함되지 않은 호스트)와 일치합니다. 그러나 설치가 정규 이름만 사용할 경우 로컬 호스트 이름은 점을 포함하므로 이 와일드카드와 일치하지 않습니다. 

UNKNOWN

이름이 알려지지 않은 모든 사용자나 이름이나 주소가 알려지지 않은 모든 호스트와 일치합니다. 

다음과 같이 이 와일드카드 이름을 신중하게 사용합니다. 

일시적인 DNS 서버 문제로 인해 호스트 이름을 사용하지 못할 수 있습니다. 이러한 경우 UNKNOWN을 사용하는 모든 필터는 모든 클라이언트 호스트와 일치합니다.

통신하는 네트워크 유형을 소프트웨어에서 식별할 수 없으면 네트워크 주소를 사용할 수 없습니다. 이러한 경우 UNKNOWN을 사용하는 모든 필터는 해당 네트워크의 모든 클라이언트 호스트와 일치합니다.

KNOWN

이름이 알려진 모든 사용자나 이름 및 주소가 알려진 모든 호스트와 일치합니다.

다음과 같이 이 와일드카드 이름을 신중하게 사용합니다. 

일시적인 DNS 서버 문제로 인해 호스트 이름을 사용하지 못할 수 있습니다. 이러한 경우 KNOWN을 사용하는 모든 필터를 모든 클라이언트 호스트에서 실패합니다.

통신하는 네트워크 유형을 소프트웨어에서 식별할 수 없으면 네트워크 주소를 사용할 수 없습니다. 이러한 경우 KNOWN을 사용하는 모든 필터는 해당 네트워크의 모든 클라이언트 호스트에서 실패합니다.

DNSSPOOFER

DNS 이름이 고유한 IP 주소와 일치하는 않는 모든 호스트와 일치합니다. 

와일드카드 패턴

다음 패턴을 서비스나 클라이언트 주소에서 사용할 수 있습니다.

EXCEPT 연산자

액세스 제어 시스템은 단일 연산자를 지원합니다. EXCEPT 연산자를 사용하면 serviceList 또는 clientList에 여러 항목이 있을 경우 일치하는 이름이나 패턴에 대한 예외를 만들 수 있습니다. 예를 들어, 다음 표현식은

list1 EXCEPT list2

list1과 일치하는 항목이 또한 list2와 일치하지 않을 경우에 일치한다는 것을 의미합니다.

다음은 이에 대한 한 예입니다.

ALL: ALL EXCEPT isserver.siroe.com

이 예는 거부 필터인 경우 isserver.siroe.com 호스트 시스템에 있는 것을 제외하고 모든 클라이언트에 대해 모든 서비스의 액세스를 거부합니다.

EXCEPT 절은 중복될 수 있습니다. 다음 표현식은

list1 EXCEPT list2 EXCEPT list3

다음과 같은 것으로 평가됩니다.

list1 EXCEPT (list2 EXCEPT list3)

서버 호스트 지정

서버 호스트 이름이나 주소 정보를 serviceSpec 항목에 포함하여 요청되는 특정 서비스를 필터에서 추가로 식별할 수 있습니다. 이러한 경우 항목의 형식은 다음과 같습니다.

service@hostSpec

Messaging Server 호스트 시스템이 다른 인터넷 호스트 이름을 가진 여러 인터넷 주소에 대해 설정된 경우 이 기능을 사용할 수 있습니다. 서비스 공급자인 경우에는 이 기능을 사용하여 다른 액세스 제어 규칙을 가진 여러 도메인을 단일 서버 인스턴스에서 호스트할 수 있습니다.

클라이언트 사용자 아이디 지정

RFC 1413에 설명된 대로 identd 서비스를 지원하는 클라이언트 호스트 시스템의 경우 클라이언트의 사용자 아이디를 필터의 clientSpec 항목에 포함하여 특정 클라이언트 요청 서비스를 추가로 식별할 수 있습니다. 이러한 경우 항목의 형식은 다음과 같습니다.

user@hostSpec

여기에서 user는 클라이언트의 identd 서비스(또는 와일드카드 이름)에 의해 반환되는 사용자 아이디입니다.

필터에서 클라이언트 아이디를 지정하는 것은 유용할 수 있지만 다음과 같은 사항에 주의해야 합니다.

경우에 따라 사용자 아이디 조회 기능은 클라이언트 호스트에서 권한 없는 사용자의 공격으로부터 보호하는 데 도움이 될 수 있습니다. 예를 들어, 일부 TCP/IP 구현에서는 rsh(원격 쉘 서비스)를 사용하는 침입자가 신뢰할 수 있는 클라이언트 호스트를 가장할 수 있습니다. 클라이언트 호스트가 ident 서비스를 지원할 경우 사용자 아이디 조회를 사용하여 이러한 공격을 감지할 수 있습니다.

필터 예

이 절의 예는 액세스 제어의 다양한 방법을 보여 줍니다. 이러한 예에서는 허용 필터가 거부 필터보다 먼저 처리되고 일치하는 항목이 발견될 때 검색이 종료하며 일치하는 항목이 전혀 없을 경우 액세스가 허가된다는 것에 주의합니다.

여기에 나열된 예는 IP 주소가 아니라 호스트 및 도메인 이름을 사용합니다. 주소와 넷마스크 정보를 필터에 포함하여 이름 서비스 실패를 대비한 안정성을 향상시킬 수 있다는 것에 주의합니다.

대부분 거부

이 경우에는 액세스가 기본적으로 거부됩니다. 명시적으로 허가된 호스트만 액세스가 허용됩니다.

기본 정책(액세스 없음)은 다음과 같은 평범하고 단순한 거부 파일을 통해 구현됩니다. 

ALL: ALL

이 필터는 허용 필터에 의해 액세스가 명시적으로 허가되지 않은 모든 클라이언트에 대한 모든 서비스를 거부합니다. 그런 다음 허용 필터는 다음과 같을 수 있습니다.

ALL: LOCAL @netgroup1

ALL: .siroe.com EXCEPT externalserver.siroe.com

첫 번째 규칙은 로컬 도메인(즉, 호스트 이름에 점이 없는 모든 호스트)의 모든 호스트와 netgroup1 그룹의 구성원에 대해 액세스를 허가합니다. 두 번째 규칙은 선행 점 와일드카드 패턴을 사용하여 externalserver.siroe.com 호스트를 제외하고 siroe.com 도메인에 있는 모든 호스트의 액세스를 허가합니다.

대부분 허용

이 경우에는 액세스가 기본적으로 허가됩니다. 명시적으로 지정된 호스트만 액세스가 거부됩니다.

기본 정책(액세스 허가)은 허용 필터를 불필요하게 만듭니다. 원하지 않는 클라이언트는 다음과 같이 거부 필터에 명시적으로 나열됩니다.

ALL: externalserver.siroe1.com, .siroe.asia.com
ALL EXCEPT pop: contractor.siroe1.com, .siroe.com

첫 번째 필터는 특정 호스트와 특정 도메인에 대해 모든 서비스를 거부합니다. 두 번째 필터는 특정 호스트와 특정 도메인의 POP 액세스만 허가합니다.

스푸핑된 도메인에 대한 액세스 거부

필터에서 DNSSPOOFER 와일드카드 이름을 사용하여 호스트 이름 스푸핑을 감지할 수 있습니다. DNSSPOOFER을 지정하면 액세스 제어 시스템은 정방향 또는 역방향 DNS 조회를 수행하여 클라이언트가 제공한 호스트 이름이 실제 IP 주소와 일치하는지 확인합니다. 다음은 거부 필터의 예입니다.

ALL: DNSSPOOFER

이 필터는 IP 주소가 해당 DNS 호스트 이름과 일치하지 않는 모든 원격 호스트에 대한 모든 서비스를 거부합니다.

가상 도메인에 대한 액세스 제어

단일 서버 인스턴스가 여러 IP 주소 및 도메인 이름과 연관된 가상 도메인을 메시징 설치에서 사용할 경우 허용 및 거부 필터를 조합하여 각 가상 도메인에 대한 액세스를 제어할 수 있습니다. 예를 들어, 다음 허용 필터를

ALL@msgServer.siroe1.com: @.siroe1.com
ALL@msgServer.siroe2.com: @.siroe2.com
...

다음 거부 필터와 결합하여 사용할 수 있습니다.

ALL: ALL

각 허용 필터는 domainN 내의 호스트만 IP 주소가 msgServer.siroeN .com에 해당하는 서비스에 연결되도록 허용합니다. 다른 모든 연결은 거부됩니다.

서비스에 대한 액세스 필터 만들기

IMAP, POP 또는 HTTP 서비스에 대한 허용 및 거부 필터를 만들 수 있습니다. 또한 이러한 필터를 SMTP 서비스에 대해 만들 수 있지만 인증된 SMTP 세션에만 적용된다는 점에서 이것은 거의 가치가 없습니다. 17 장, 메일 필터링 및 액세스 제어를 참조하십시오.

Procedure필터를 만드는 방법

단계

  1. 콘솔에서 액세스 필터를 만들려는 Messaging Server를 엽니다.

  2. 구성 탭을 누릅니다.

  3. 왼쪽 표시 영역에서 서비스 폴더를 열고 서비스 폴더 아래에서 IMAP, POP 또는 HTTP를 선택합니다.

  4. 오른쪽 표시 영역에서 액세스 탭을 누릅니다.

    이 탭의 허용 및 표시 필드에는 해당 서비스에 대한 기존의 허용 및 거부 필터가 표시됩니다. 필드의 각 행은 하나의 필터를 나타냅니다. 이러한 필드 중 하나에서 다음 작업을 지정할 수 있습니다.

    1. 추가를 눌러 새 필터를 만듭니다필터 허용 또는 필터 거부 창이 열리면 새 필터의 텍스트를 창에 입력하고 확인을 누릅니다.

    2. 필터를 선택하고 편집을 눌러 필터를 수정합니다. 필터 허용 또는 필터 거부 창이 열리면 창에 표시된 필터의 텍스트를 편집하고 확인을 누릅니다.

    3. 필터를 선택하고 삭제를 눌러 필터를 제거합니다.

      필요한 경우 일련의 삭제 및 추가 작업을 수행하여 허용 또는 거부 필터의 순서를 재정렬할 수 있다는 것에 주의합니다.

      필터 문 지정과 다양한 예는 필터 문 및 필터 예를 참조하십시오.

      명령줄

      다음과 같이 명령줄에서 액세스 및 거부 필터를 지정할 수도 있습니다.

      서비스에 대한 액세스 필터를 작성 또는 편집하려면 다음을 수행합니다.


      configutil -o service.service.domainallowed -v filter

      여기에서 service는 pop, imap 또는 http이고 filter는 필터 문에 설명된 구문 규칙을 따릅니다.

      서비스에 대한 거부 필터를 작성 또는 편집하려면 다음을 수행합니다.


      configutil -o service.service.domainnotallowed -v filter

      여기에서 service는 pop, imap 또는 http이고 filter는 필터 문에 설명된 구문 규칙을 따릅니다.

HTTP 프록시 인증에 대한 액세스 필터 만들기

모든 저장소 관리자는 모든 서비스에 대해 프록시 인증을 수행할 수 있습니다. 저장소 관리자에 대한 자세한 내용은 저장소에 대한 관리자 액세스 지정을 참조하십시오. 모든 사용자는 해당 클라이언트 호스트가 프록시 인증 액세스 필터를 통해 액세스가 허가된 경우 HTTP 서비스에 한하여 프록시 인증을 수행할 수 있습니다.

프록시 인증을 사용하면 포털 사이트 등의 다른 서비스에서 사용자를 인증하고 인증서를 HTTP 로그인 서비스로 전달할 수 있습니다. 예를 들어, 포털 사이트가 여러 서비스를 제공하며 그 중 하나가 Messenger Express 웹 기반 전자 메일이라고 가정해 봅니다. 이 경우 최종 사용자는 HTTP 프록시 인증 기능을 사용하여 포털 서비스에 한 번만 인증되면 됩니다. 즉, 전자 메일을 액세스하기 위해 다시 인증될 필요가 없습니다. 포털 사이트는 클라이언트와 서비스 간의 인터페이스로 작동하는 로그인 서버를 구성해야 합니다. Messenger Express 인증을 위한 로그인 서버의 구성을 돕기 위해 Sun Java System은 Messenger Express용 인증 SDK를 제공합니다.

이 절에서는 IP 주소별로 HTTP 프록시 인증을 허용하기 위해 허용 필터를 만드는 방법에 대해 설명합니다. 로그인 서버를 설정하는 방법이나 Messenger Express 인증 SDK를 사용하는 방법은 이 절에서 설명하지 않습니다. Messenger Express에 맞게 로그인 서버를 설정하고 인증 SDK를 사용하는 방법에 대한 자세한 내용은 Sun Java System 담당자에게 문의하십시오.

ProcedureHTTP 프록시 인증에 대한 액세스 필터 만들기

단계

  1. 콘솔에서 액세스 필터를 만들려는 Messaging Server를 엽니다.

  2. 구성 탭을 누릅니다.

  3. 왼쪽 표시 영역에서 서비스 폴더를 열고 서비스 폴더 아래에서 HTTP를 선택합니다.

  4. 오른쪽 표시 영역에서 프록시 탭을 누릅니다.

    이 탭의 허용 필드에는 프록시 인증에 대한 기존의 허용 필터가 표시됩니다.

  5. 새 필터를 만들려면 추가를 누릅니다.

    허용 필터 창이 열리면새 필터의 텍스트를 창에 입력하고 확인을 누릅니다.

  6. 기존 필터를 편집하려면 필터를 선택하고 편집을 누릅니다.

    허용 필터 창이 열리면창에 표시된 필터의 텍스트를 편집하고 확인을 누릅니다.

  7. 기존 필터를 삭제하려면 허용 필드에서 필드를 선택하고 삭제를 누릅니다.

  8. 프록시 탭에 대한 변경이 끝나면 저장을 누릅니다.

    허용 필터 문에 대한 자세한 내용은 필터 문을 참조하십시오.

    명령줄

    다음과 같이 명령줄에서 HTTP 서비스에 대한 프록시 인증을 위한 액세스 필터를 지정할 수도 있습니다.


    configutil -o service.service.proxydomainallowed -v filter

    여기에서 filter는 필터 문에 설명된 구문 규칙을 따릅니다.

POP before SMTP 사용

SMTP 인증 또는 SMTP Auth(RFC 2554)는 SMTP 릴레이 서버 보안을 제공하는 데 선호되는 방법입니다. SMTP Auth는 인증된 사용자만 MTA를 통해 메일을 보낼 수 있도록 허용합니다. 그러나 일부 레거시 클라이언트는 POP before SMTP에 대한 지원만 제공합니다. 이러한 시스템에서는 아래 설명된 것처럼 POP before SMTP를 사용 가능하게 할 수 있습니다. 그러나 가능하면 사용자에게 POP before SMTP를 사용하는 대신 POP 클라이언트를 업그레이드하도록 권장하는 것이 좋습니다. 사이트에서 POP before SMTP가 배포되고 나면 사용자는 인터넷 보안 표준을 따르지 못하는 클라이언트에 의존하게 됩니다. 따라서 최종 사용자가 해킹의 위험에 노출될 뿐만 아니라 성공적인 최근 POP 세션의 IP 주소를 추적 및 조정하면서 발생하는 불가피한 성능 저하로 인해 사이트 속도가 느려집니다.

Messaging Server 의 POP before SMTP 구현은 SIMS 또는 Netscape Messaging Server에서와 완전히 다릅니다. POP 및 SMTP 프록시 모두를 가지도록 MMP(Messaging Multiplexor)를 구성하여 POP before SMTP를 지원합니다. SMTP 클라이언트가 SMTP 프록시에 연결하면 프록시는 최근 POP 인증의 메모리 내장 캐시를 검사합니다. 동일한 클라이언트 IP 주소의 POP 인증이 발견되면 SMTP 프록시는 메일을 로컬 및 비로컬 수신자 모두에게 보낼 수 있게 허용해야 한다는 것을 SMTP 서버에 알립니다.

ProcedureSMTP 프록시 설치

단계

  1. MMP(Messaging Multiplexor)를 설치합니다

    (Sun Java Enterprise System 2005Q4 설치 설명서 참조).

  2. MMP에서 SMTP 프록시를 사용 가능하게 합니다.

    다음 문자열을

    msg_svr_base/lib/SmtpProxyAService@25|587

    msg_svr_base/config/AService.cfg 파일의 ServiceList 옵션에 추가합니다. 이 옵션은 길이가 한 줄이며 줄 바꿈을 포함할 수 없습니다.

    주 –

    MMP가 업그레이드되면 MMP에 대한 네 개의 기존 구성 파일에 해당하는 네 개의 새 파일이 만들어집니다. 이러한 새 파일은 다음과 같습니다.

    AService-def.cfg, ImapProxyAService-def.cfg, PopProxyAService-def.cfg 및 SmtpProxyAService-def.cfg

    이러한 파일은 설치 프로그램에 의해 만들어지며 문서에 설명된 네 개의 구성 파일은 설치하는 동안에 만들어지거나 영향을 받지 않습니다. MMP는 시작되면 일반 구성 파일(현재 문서화되어 있는)을 찾습니다. 일반 구성 파일을 찾지 못한 경우 MMP는 각 *AService-def.cfg 파일을 해당 *AService.cfg 파일 이름에 복사하는 것을 시도합니다.

  3. 각 SMTP 릴레이 서버에서 SMTP 채널 옵션 파일 tcp_local_option의 PROXY_PASSWORD 옵션을 설정합니다.

    SMTP 프록시는 SMTP 서버에 연결되면 실제 클라이언트 IP 주소와 다른 연결 정보를 SMTP 서버에 알려 SMTP 서버가 중계 차단 및 다른 보안 정책(POP before SMTP 인증 포함)을 제대로 적용할 수 있게 해야 합니다. 이것은 보안에 민감한 작업으로서 반드시 인증되어야 합니다. MMP SMTP 프록시 및 SMTP 서버 모두에서 구성되는 프록시 비밀번호는 다른 사람이 기능을 남용할 수 없게 합니다.

    예: PROXY_PASSWORD=A_Password

  4. MMP에서 SMTP 서버에 연결하기 위해 사용하는 IP 주소가 INTERNAL_IP 매핑 테이블에서 "내부" 주소로 처리되지 않는지 확인합니다.

    INTERNAL_IP 매핑 테이블에 대한 자세한 내용은 17 장, 메일 필터링 및 액세스 제어의 SMTP 릴레이 추가를 참조하십시오.

  5. POP before SMTP를 지원하도록 SMTP 프록시를 구성합니다.

    1. msg_svr_base/config/SmtpProxyAService.cfg 구성 파일을 편집합니다.

      다음 SMTP 프록시 옵션은 IMAP 및 POP 프록시 옵션(7 장, 멀티플렉서 서비스 구성 및 관리 및 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 Encryption (SSL) Option 절의 이러한 옵션에 대한 설명 참조)과 똑같이 작동합니다.

      LdapURL, LogDir, LogLevel, BindDN, BindPass, Timeout, Banner, SSLEnable, SSLSecmodFile , SSLCertFile, SSLKeyFile, SSLKeyPasswdFile, SSLCipherSpecs, SSLCertNicknames, SSLCacheDir, SSLPorts, CertMapFile, CertmapDN, ConnLimits, TCPAccess

      위에 나열되지 않은 다른 MMP 옵션(BacksidePort 옵션 포함)은 현재 SMTP 프록시에 적용되지 않습니다.

      다음 다섯 개의 옵션을 추가합니다.

      SmtpRelays는 라운드 로빈 중계에 사용할 SMTP 중계 서버 호스트 이름(선택적 포트 포함)의 공백으로 구분된 목록입니다. 이러한 중계는 XPROXYEHLO 확장을 지원해야 합니다. 이 옵션은 필수이며 기본값은 없습니다.

      예: default:SmtpRelays manatee:485 gonzo mothra

      SmtpProxyPassword는 SMTP 중계 서버에 대한 소스 채널 변경 사항을 허가하는 데 사용되는 비밀번호입니다. 이 옵션은 필수이고 기본값은 없으며 SMTP 서버의 PROXY_PASSWORD 옵션과 일치해야 합니다.

      예: default:SmtpProxyPassword A_Password

      EhloKeywords 옵션은 기본 집합 외에 클라이언트에게 전달할 프록시에 대한 EHLO 확장 키워드 목록을 제공합니다. MMP는 SMTP 중계에 의해 반환된 EHLO 목록에서 인식되지 않은 모든 EHLO 키워드를 제거합니다. EhloKeywords는 이 목록에서 제거하지 않아야 하는 추가 EHLO 키워드를 지정합니다. 기본값은 비어 있지만8BITMIME, PIPELINING, DSN, ENHANCEDSTATUSCODES, EXPN, HELP, XLOOP, ETRN, SIZE, STARTTLS, AUTH 키워드는 SMTP 프록시에서 지원되므로 이 옵션에 나열할 필요가 없습니다.

      다음은 드물게 사용되는 "TURN" 확장을 사용하는 사이트에서 사용할 수 있는 예입니다.

      예: default:EhloKeywords TURN

      PopBeforeSmtpKludgeChannel 옵션은 허가된 POP before SMTP 연결에 사용할 MTA 채널의 이름으로 설정됩니다. 기본값은 비어 있으며 POP before SMTP를 사용 가능하게 하려는 사용자에 대한 일반 설정은 tcp_intranet입니다. 이 옵션은 SSL 성능을 최적화하는 데 필요하지 않습니다( SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법 참조).

      예: default:PopBeforeSmtpKludgeChannel tcp_intranet

      ClientLookup 옵션은 기본적으로 no입니다. yes로 설정된 경우 클라이언트 IP 주소에 대한 DNS 역방향 조회가 무조건 수행되므로 SMTP 중계 서버에서 이 작업을 수행할 필요가 없습니다. 이 옵션은 호스트된 도메인별로 설정할 수 있습니다.

      예: default:ClientLookup yes

    2. PopProxyAService.cfg 구성 파일에서 PreAuth 및 AuthServiceTTL 옵션을 설정합니다. 이 옵션은 SSL 성능을 최적화하는 데 필요하지 않습니다. SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법을 참조하십시오.

      이러한 옵션은 POP 인증 후에 사용자가 메일을 전달할 수 있도록 허가된 시간(초)을 지정합니다. 일반 설정은 900-1800(15-30분)입니다.

      예: 


      default:PreAuth yes
default:AuthServiceTTL 900

    3. 목록에서 다음 항목을 시도하기 전에 MMP가 SMTP 중계의 응답을 대기하는 시간(초)을 선택적으로 지정할 수 있습니다.

      기본값은 10(초)입니다. SMTP 중계에 대한 연결이 실패한 경우 MMP는 페일오버 시간 초과에 해당하는 시간(분) 동안 해당 중계를 시도하지 않습니다(따라서 페일오버 시간 초과가 10초이고 중계가 실패한 경우 MMP는 해당 중계를 10분 동안 다시 시도하지 않음).

      예: default:FailoverTimeout 10

SMTP 서비스에 대한 클라이언트 액세스 구성

SMTP 서비스에 대한 클라이언트 액세스 구성에 대한 자세한 내용은 17 장, 메일 필터링 및 액세스 제어를 참조하십시오.

SSL을 통한 사용자/그룹 디렉토리 조회

MTA, MMP 및 IMAP/POP/HTTP 서비스를 위해 SSL을 통한 사용자/그룹 디렉토리 조회를 수행할 수 있습니다. 전제 조건은 Messaging Server가 SSL 모드에서 구성되어야 한다는 것입니다. 이 기능을 활성화하려면 configutil 매개 변수를 설정해야 합니다. 즉, local.service.pab.ldapport는 636으로, local.ugldapport는 636으로, local.ugldapusessl은 1로 설정합니다.