test

Sun Java System Messaging Server 6.3 관리 설명서

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

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

Messaging Server 보안 구조는 Sun Java System 서버 전체의 보안 구조 중 일부입니다. 이 구조는 최대한의 상호 운용성과 일관성을 위해 업계 표준 및 공개 프로토콜에 기반을 둡니다.

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

23.1 서버 보안 정보

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

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

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

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

23.2 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) 사용을 참조하십시오.

23.3 인증 기법 구성

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

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

주 –

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

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

주 –

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

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

표 23–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 트리에서 직접 수행됩니다. 이것은 레거시 단일 도메인 스키마와의 호환성을 위해 제공되지만 심지어 소규모 회사에서도 여러 도메인에 대한 지원이 필요한 합병이나 사명 변경이 발생할 수 있으므로 새 배포에는 사용하지 않는 것이 좋습니다.

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

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

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

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

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

CRAM-MD5, DIGEST-MD5 또는 APOP 기법을 사용하려면 Directory Server를 구성하여 비밀번호를 일반 텍스트로 저장하게 해야 합니다. Directory Server 6 이전 버전을 사용하는 경우 다음 지침이 적용됩니다. 6 이상 버전의 경우 최신 Directory Server 설명서(Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide)를 :

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

  2. 구성 탭을 누릅니다.

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

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

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

    주 –

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

23.3.1.1 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과 동등한 옵션을 가집니다.

23.3.2 사용자 전환

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

configutil -o sasl.default.auto_transition -v value

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

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

Procedure사용자 전환

. Directory Server 6 이전 버전을 사용하는 경우 다음 지침이 적용됩니다. 6 이상 버전의 경우 최신 Directory Server 설명서(Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide)를

  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)에 적용됩니다.

23.4 사용자 비밀번호 로그인

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

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

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

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

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

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

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

23.4.2 SMTP 비밀번호 로그인

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

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

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

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

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

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

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

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

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

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

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

이 그림은 암호화된 받는 메시지 및 보내는 메시지를 보여 줍니다.

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

주 –

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

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

23.5.1 인증서 얻기

SSL을 암호화에 사용하는지 아니면 인증에 사용하는지 여부에 상관 없이 Messaging Server에 대한 서버 인증서를 얻어야 합니다. 인증서는 해당 서버를 클라이언트와 다른 서버에 대해 식별합니다. 이 절의 뒷 부분에서 설명하는 대로 msgcert 명령을 사용하여 인증서를 얻는 방법이 가장 효과적입니다. 이전 certutil 명령을 계속 사용할 수는 있지만 훨씬 더 복잡하고 국제화되지 않았습니다. certutil에 대한 자세한 내용은 23.5 암호화 및 인증서 기반 인증 구성 및 http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html을 참조하십시오.

이 절은 다음과 같은 하위 절로 구성되어 있습니다.

23.5.1.1 내부 및 외부 모듈 관리

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

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 모듈을 설치합니다.

주 –

다음 절에서는 콘솔 또는 Directory Server 콘솔에 대해 설명합니다. 이 명칭은 Directory Server 6 이전 버전에 사용되는 용어입니다. 6 이상 버전에서는 그래픽 사용자 인터페이스를 Directory Server Control Center라고 합니다. 자세한 내용은 최신 Directory Server 설명서(Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide)를 참조하십시오.

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

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

  2. msg-svr-base/sbin에 있는 modutil을 사용하여 설치된 드라이버용 PKCS #11 모듈을 설치합니다.

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

23.5.1.2 비밀번호 파일 만들기

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

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

moduleName:password

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

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

Internal (Software) Token:netscape!

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

주의 – 주의 –

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

23.5.1.3 인증서 얻기 및 관리

SSL을 암호화에 사용하는지 아니면 인증에 사용하는지 여부에 상관 없이 Messaging Server에 대한 서버 인증서를 얻어야 합니다. 인증서는 해당 서버를 클라이언트와 다른 서버에 대해 식별합니다. 인증서 얻기 및 관리를 위한 기본 기법은 msgcert를 사용하는 것입니다. Administration Server를 설치한 경우에는 관리 콘솔을 사용할 수도 있습니다.

이 절의 나머지 부분에서는 msgcert 사용 방법에 대해 설명합니다.

23.5.1.4 msgcert 정보

msgcert를 사용하면 인증서 요청 생성, 인증서 데이터베이스에 인증서 추가, 데이터베이스에 있는 인증서 나열 등과 같은 작업을 수행할 수 있습니다. 자세한 내용을 보려면 명령줄에 다음을 입력하십시오.

msg-svr-base/sbin/msgcert --help

그러면 아래와 같이 표시됩니다.


# ./msgcert --help

Usage: msgcert SUBCMD [GLOBAL_OPTS] [SUBCMD_OPTS] [SUBCMD_OPERANDS]
Manages the Messaging Servers Certificate Database
The accepted values for SUBCMD are:

add-cert              Adds a certificate to the certificate database
add-selfsign-cert     Creates and adds a selfsign certificate to the 
                      certificate database
export-cert           Exports a certificate and its keys from the database
generate-certDB       Creates Messaging Server Databases cert8.db key3.db 
                      secmod.db and sslPassword
import-cert           Adds a new certificate and its keys to the cert database
import-selfsign-cert  Adds a new selfsign certificate and its keys to the 
                      cert database
list-certs            Lists all certificates in the Certificate database
remove-cert           Removes a certificate from the database
renew-cert            Renews a certificate
renew-selfsign-cert   Renews a selfsign certificate
request-cert          Generates a certificate request
show-cert             Displays a certificate

The accepted value for GLOBAL_OPTS is:-?, --help
                Displays SUBCMD help

NOTE: You must stop all the TLS or SSL-enabled servers before making any 
changes to the Certificate Database.

위에 표시된 각 하위 명령은 특정 인증서 관리 기능을 수행합니다. 다음을 입력하면 이러한 하위 명령과 해당 기능에 대한 자세한 내용을 볼 수 있습니다.

msgcert SUBCMD –help

이 절의 나머지 부분에서는 일부 공통된 인증서 관리 절차에 대해 설명합니다.

23.5.1.5 인증서 관리

이 절에서는 Messaging Server에서 SSL 인증서를 관리하는 방법에 대해 설명합니다. Messaging Server에서 SSL을 실행하려면 외부 인증 기관(CA)을 포함하는 PKI(Public Key Infrastructure) 솔루션이나 자체 서명된 인증서를 사용해야 합니다. PKI 솔루션의 경우 공개 키와 개인 키를 모두 포함하는 CA 서명된 서버 인증서가 필요합니다. 이 인증서는 하나의 Messaging Server에만 한정됩니다. 또한 공개 키가 포함된 신뢰할 수 있는 CA 인증서가 필요합니다. 신뢰할 수 있는 CA 인증서가 있으면 해당 CA의 모든 서버 인증서가 신뢰됩니다. 이 인증서를 CA 루트 키 또는 루트 인증서라고도 합니다.

인증서 데이터베이스 비밀번호 구성

인증서를 관리할 때 인증서 비밀번호를 입력하거나 비밀번호 파일을 지정할 필요는 없습니다. 비밀번호를 -W 인수로 간단히 전달할 수 있습니다. 예: 


echo "password22" > /tmp/certdbpwd
echo "password22" > /tmp/certdbpwd
# ./msgcert list-certs -W /tmp/certdbpwd

Procedure기본 자체 서명된 인증서를 사용하여 Messaging Server 인증서 데이터베이스 만들기

  1. Messaging Server 인증서 데이터베이스를 만들려면 다음 명령을 실행합니다.


    msgcert generate-certDB

    이 명령은 CERT_PW_FILE에서 인증서 데이터베이스 비밀번호를 읽습니다(기본값: 비밀번호 요청).

  2. 다음 명령을 사용하여 이 인증서를 볼 수 있습니다. 


    msgcert show-cert Server-Cert

Procedure자체 서명된 인증서 관리

테스트를 위해 인증서를 사용할 경우 자체 서명된 인증서를 사용할 수 있습니다. 배포 구성에서는 신뢰할 수 있는 인증 기관(CA) 인증서를 사용할 수 있습니다. Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

  1. 인증서 데이터베이스를 만들 때 기본 자체 서명된 인증서가 자동으로 제공됩니다. 자체 서명된 인증서를 기본값이 아닌 설정으로 사용하려면 msgcert add-selfsign-cert 명령을 사용합니다. 예:


    msgcert add-selfsign-cert --name siroe --org comms --org-unit Messaging 
--city SantaClara --state ca --country us MySelfSigned-Cert

    자체 서명된 인증서는 3개월 동안 유효합니다.

  2. 자체 서명된 인증서가 만료되면 다음 명령을 사용하여 인증서를 갱신합니다.


    msgcert renew-selfsign-cert cert_alias

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

./msgcert add-cert를 사용하여 인증 기관의 인증서를 설치합니다. CA 인증서는 CA 자체의 신원을 검증합니다. 서버는 클라이언트 및 다른 서버를 인증하는 과정에서 이러한 CA 인증서를 사용합니다.

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

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

주 –

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

다음 절차에서는 Messaging Server에서 사용할 CA 서명된 서버 및 신뢰할 수 있는 CA 인증서를 요청하고 설치하는 과정에 대해 설명합니다.

ProcedureCA 서명된 서버 인증서 요청

Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

  1. CA 서명된 서버 인증서 요청을 생성합니다. 


    msgcert request-cert [-W CERT_PW_FILE] {-S DN|--name NAME [--org ORG] [--org-unit ORG-UNIT]
   [--city CITY] [--state STATE] [--country COUNTRY] } [-F FORMAT] [-o OUTPUT_FILE]

    다음은 CA 서명된 서버 인증서 요청의 예입니다. 이 예에서는 이진 형식의 인증서를 반환합니다.


    ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -o my_ca_signed_request_cert

    ASCII 형식의 인증서를 반환하려면 명령을 다음과 같이 사용합니다.


    ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -F ascii -o my_casigned_request_cert

    인증 기관에서는 서버를 완벽하게 식별하기 위해 일반적으로 이 예에 표시된 모든 속성을 요구합니다. 각 속성에 대한 설명을 보려면 ./msgcert request-cert --help를 입력합니다. msgcert request-cert를 사용하여 인증서를 요청하는 경우 ASCII를 출력 형식으로 지정하지 않는 한 결과 인증서 요청은 이진 인증서 요청입니다. ASCII를 지정한 경우 결과 인증서 요청은 PEM 형식의 PKCS #10 인증서 요청입니다. PEM은 RFC 1421-1424에 지정되고 base64 인코딩된 인증서 요청을 ASCII 문자로 표시하는 데 사용되는 Privacy Enhanced Mail 형식입니다. 요청 내용은 다음 예와 비슷합니다.


    -----BEGIN NEW CERTIFICATE REQUEST-----
MIIBdTCB3wIBADA2MRIwEAYDVQQLEwlNZXNzYWdpbmcxDjAMBgNVBAoTBXNpcm9l
MRAwDgYDVQQDEwdhcXVhdGljMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDt
KEh5Fnj/h9GEu18Da6DkJpcNShkwxanjnKs2883ZoUV5Sp4pN7U6Vfbh0414WXZh
D26m3t81q9b9h47Klkf0pW1X3BB6LOjGOHSt2VoNBI8n3hJ6XiN2zYbrlLTgdKuo
y0YrSG/kHFnqKghikag9O/Ox+cwD+mpjl2QnsPZgswIDAQABoAAwDQYJKoZIhvcN
AQEEBQADgYEArqgWQIwNZDC2d3EZawI23Wj9o6Pyvu9J1rkb+NYgIEnNp9jugxqX
F326N0ABLdHXXNX/2ZvC5TKOgS4RidTBM89N9xJvokmvRGfc+1x80uxy474YdNlZ
s+nP8AYo9dW9mrLOammozx9HLPSVYNFp4FxekgV2n8QG7WC5rkN5bCE=
-----END NEW CERTIFICATE REQUEST-----

  2. 절차에 따라 인증서 요청을 인증 기관에 전송합니다.

    인증 기관 인증서를 얻는 프로세스는 사용하는 인증 기관에 따라 다릅니다. 일부 상업용 CA는 인증서를 자동으로 다운로드할 수 있는 웹 사이트를 제공합니다. 그 외의 CA는 요청 시 인증서를 전자 메일로 전송합니다.

    요청을 보낸 후 CA에서 인증서로 응답할 때까지 기다려야 합니다. 요청에 대한 응답 시간은 각각 다릅니다. 예를 들어, CA가 회사 내부에 있는 경우 CA가 요청에 응답하는 데 1-2일이 걸릴 수 있습니다. 선택한 CA가 회사 외부에 있는 경우 CA가 요청에 응답하는 데 몇 주일이 걸릴 수도 있습니다.

  3. 인증 기관으로부터 수신한 인증서를 저장합니다.

    인증서를 안전한 위치에 백업해 두어야 합니다. 인증서가 손실될 경우 백업 파일을 사용하여 인증서를 다시 설치할 수 있습니다. 인증서를 텍스트 파일로 저장할 수 있습니다. PEM 형식의 PKCS #11 인증서는 다음 예와 비슷합니다. 


    -----BEGIN CERTIFICATE-----
MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx
IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX
aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz
dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP
MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp
Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA
A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj
jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC
APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF
BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL
bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6
6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo=
-----END CERTIFICATE-----

ProcedureCA 서명된 서버 인증서 및 신뢰할 수 있는 CA 인증서 추가

Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

  1. 다음 명령을 사용하여 CA 서명된 서버 인증서를 추가합니다.


    msgcert add-cert cert_alias cert_file

    여기서 cert_alias는 인증서를 식별하기 위해 제공하는 이름이고, cert_file은 PEM 형식의 PKCS #11 인증서를 포함하는 텍스트 파일입니다.

    예를 들어, CA 서명된 서버 인증서를 설치하려면 다음과 비슷한 명령을 사용할 수 있습니다.


    msgcert add-cert /my_cert/server-cert-file

    이제 인증서가 설치되었지만 아직 신뢰되지는 않습니다. CA 서명된 서버 인증서를 신뢰하려면 인증 기관 인증서를 설치해야 합니다.

  2. 다음 명령을 사용하여 신뢰할 수 있는 인증 기관 인증서를 추가합니다.


    msgcert add-cert -C cert_alias cert_file

    -C 옵션은 인증서가 신뢰할 수 있는 인증 기관 인증서임을 나타냅니다.

    예를 들어, 인증 기관의 신뢰할 수 있는 인증서를 설치하려면 다음 명령을 사용할 수 있습니다.


    msgcert add-cert -C CA-cert /my_cert/ca-cert-file

  3. 선택적으로 다음 명령을 사용하여 설치한 인증서를 확인합니다.

    모든 서버 인증서를 나열하여 별칭 및 유효 날짜와 같은 정보를 표시하려면 다음 명령을 사용합니다. 


    msgcert list-certs

    Messaging Server에는 ./msgcert generate-CertDB를 통해 생성된 경우 Server-Cert라는 기본 인증서가 있습니다. 텍스트 Same as issuer는 기본 인증서가 자체 서명된 서버 인증서임을 나타냅니다. 예를 들면 다음과 같습니다. 


    # ./msgcert list-certs
Enter the certificate database password:
Alias          Valid from       Expires on       Self-   Issued by             Issued to
                                                 signed
------------   ----------------  --------------- ------  --------------------- -------------------------  --------------
SelfSignedCrt 2006/07/28 12:58  2006/10/28 12:58   y     CN=SFO,L=SC,ST=ca,C=us  Same as issuer
Server-Cert   2006/07/28 07:47  2006/10/28 07:47   y     CN=perseids             Same as issuer
2 certificates found

    신뢰할 수 있는 CA 인증서를 나열하려면 다음 명령을 사용합니다.


    msgcert list-certs -C

    인증서 만료 날짜를 포함하여 인증서 세부 정보를 보려면 다음 명령을 사용합니다.


    msgcert show-cert cert_alias

    예를 들어, 자체 서명된 인증서를 표시하려면 다음 명령을 사용합니다.


    # ./msgcert show-cert MySelfSigned-Cert
Enter the certificate database password:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:83:35:37:94
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer:
            "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us"
        Validity:
            Not Before: Fri Jul 28 19:58:31 2006
            Not After : Sat Oct 28 19:58:31 2006
        Subject:
            "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    aa:9d:3d:23:b2:59:39:f3:77:c8:69:7f:b0:d1:ac:d2:
                    4e:81:c8:51:0f:27:6f:a1:21:4b:a9:27:46:d7:0f:b4:
                    c8:44:86:32:5e:4f:2f:1c:2f:a9:b8:a3:49:b5:b8:ab:
                    51:a8:a5:ba:1c:e8:90:7d:46:67:f9:a7:44:c5:1d:24:
                    e6:bd:e8:8f:07:b4:5a:68:41:b1:19:f2:ea:98:ba:25:
                    55:b8:ba:9c:af:bb:43:c3:c0:8f:14:a7:4c:2b:50:b4:
                    ac:df:b5:cd:68:de:a6:14:9d:68:77:d3:8b:7f:de:c0:
                    5d:35:d7:55:8d:b5:c3:14:2a:60:a9:bf:de:96:90:a9
                Exponent: 65537 (0x10001)
    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        15:86:f1:cc:85:c9:08:0f:ff:d3:56:d8:e2:c8:ea:3c:
        8e:45:36:be:8b:b0:7d:2f:e9:cd:e3:b4:ad:8c:70:59:
        c8:a5:14:da:9c:fa:7f:70:86:64:34:0b:21:ae:c4:28:
        d2:f5:94:5c:a6:78:0f:d9:fd:fc:c5:5e:37:49:25:a9:
        bc:12:59:cb:fb:4e:e9:d4:8a:8d:3d:41:12:ae:f1:7f:
        8d:d3:10:ac:fb:33:51:5d:0c:1b:dc:23:5f:95:d5:6d:
        c6:1d:e5:ed:13:8b:16:41:89:5b:4d:de:c0:c7:56:a2:
        48:82:38:32:5a:99:d5:21:20:c5:0d:5c:ea:0c:84:aa
    Fingerprint (MD5):
        EF:76:A3:6C:09:4E:BC:6B:87:76:A3:35:70:1F:B2:C4
    Fingerprint (SHA1):
        BB:1C:20:4B:79:3A:F1:49:F0:83:FB:CC:9C:56:10:D3:06:97:AA:07

    Certificate Trust Flags:
        SSL Flags:
            Valid CA
            Trusted CA
            User
            Trusted Client CA
        Email Flags:
            User
        Object Signing Flags:
            User

Procedure만료된 CA 서명된 서버 인증서 갱신

CA 서명된 서버 인증서(공개 및 개인 키)가 만료된 경우 다음 절차에 따라 인증서를 갱신할 수 있습니다. Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

  1. 인증 기관으로부터 업데이트된 CA 서명된 서버 인증서를 얻습니다.

  2. 업데이트된 인증서를 받은 다음 인증서를 설치합니다.


    msgcert renew-cert cert_alias cert_file

ProcedureCA 서명된 서버 인증서 내보내기 및 가져오기

경우에 따라 나중에 인증서를 다른 시스템(예: 다른 호스트)으로 가져올 수 있도록 인증서를 내보낼 수도 있습니다. Directory Server 관리 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

  1. 인증서를 내보냅니다.


    msgcert export-cert [-o OUTPUT_FILE] CERT_ALIAS

    예를 들면 다음과 같습니다.


    $ ./msgcert export-cert -o /tmp/first-certificate "First Certificate"
$./msgcert export-cert -o /tmp/first-server-certificate Server-Cert
Choose the PKCS#12 file password:
Confirm the PKCS#12 file password:
$ls /tmp
first-server-certificate
/tmp/first-certificate

  2. 인증서를 가져옵니다.


    $ msgcert import-cert  CERT_FILE

    예를 들어, 인증서를 가져오려면 다음 명령을 사용합니다. 


    $ msgcert import-cert /tmp/first-server-certificate
Enter the PKCS#12 file password:
$

23.5.2 SSL 사용 및 암호문 선택

콘솔을 사용하여 SSL을 사용 가능하게 하고 Messaging Server가 클라이언트와의 암호화된 통신에 사용할 수 있는 암호화 암호문 집합을 선택할 수 있습니다. msgcert 유틸리티를 사용하여 SSL 인증서를 설치하고 해당 configutil을 실행하거나 해당 서비스에 대해 SSL을 활성화하는 데 필요한 구성 파일을 편집할 수도 있습니다.

23.5.2.1 암호문 정보

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

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

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

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

표 23–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을 사용 가능하게 하고 암호화 암호문을 선택하려면 다음 명령줄 단계를 따릅니다.

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

configutil -o encryption.rsa.nssslpersonalityssl -v certname

또한 SSL 서버 인증서 별명에 대한 서비스별 구성 설정이 있습니다. 새 configutil 설정은 다음과 같습니다.

local.imta.sslnicknames(SMTP 및 Submit 서버용), local.imap.sslnicknames(IMAP 서버용), local.pop.sslnicknames(POP 서버용), local.http.sslnicknames(웹 메일 서버용)

이러한 설정은 의미가 동일하며 encryption.rsa.nssslpersonalityssl 설정을 대체합니다. 특히, 이 설정은 쉼표로 분리된 NSS 인증서 별명 목록입니다. 목록에 허용되는 별명이 여러 개 있더라도 각 별명은 서로 다른 유형의 인증서(예: RSA 인증서 및 DSS 인증서)를 참조해야 하므로 설정은 거의 항상 한 개의 별명입니다. NSS 소프트웨어 토큰 또는 기본 토큰을 검색하는 경우 별명이 비정규화될 수 있습니다. 또는 지정된 보안 모듈에서 해당 별명을 검색하는 경우 security-module: nickname" 형식을 사용할 수 있습니다. 이는 기본 NSS 데이터베이스 이외의 위치나 하드웨어 토큰에 저장된 인증서에 필요합니다.

또한 제품에서 여러 NSS 소프트웨어 토큰을 사용할 수 없습니다. 특히 IMAP, POP, SMTP 및 HTTP용으로는 cert8.db, key3.db 및 secmod.db가 하나만 제공됩니다. NSS에서는 그렇지 않습니다.

주 –

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

23.5.3 인증서 기반 로그인 설정

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

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

Procedure인증서 기반 로그인 설정

  1. 서버의 서버 인증서를 얻습니다. 자세한 내용은 23.5.1 인증서 얻기를 참조하십시오.

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

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

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

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

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

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

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

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

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

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

SMTP 프록시를 설치하는 방법은 Sun Java Communications Suite 5 Deployment Planning Guide의 Using the MMP SMTP Proxy 및 23.8 POP before SMTP 사용을 참조하십시오.

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

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

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

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

23.6.1 위임된 관리 계층

네트워크에 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를 사용하여 특정 서버 작업을 해당 목록의 특정 개인 또는 그룹에 위임할 수 있습니다.

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

관리자는 일반적으로 하나 이상의 관리 작업을 수행하기 위해 서버에 연결합니다. 일반 관리 작업은 콘솔에서 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에서 서버 관리 위임에 대한 장에 자세히 설명되어 있습니다.

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

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

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

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

주 –

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

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

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

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

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

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

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

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

23.7.2 필터 구문

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

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

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과 같은 와일드카드 이름에 대한 자세한 내용은 23.7.2.1 와일드카드 이름을 참조하십시오.

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

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 서비스에 대한 액세스를 거부합니다. 이러한 확장된 서버 및 클라이언트 지정을 사용하는 시기에 대한 자세한 내용은 23.7.2.4 서버 호스트 지정 및 23.7.2.5 클라이언트 사용자 아이디 지정을 참조하십시오.

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

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 서비스에 대한 액세스가 허가됩니다. 선행 점이나 다른 패턴을 사용하여 도메인 또는 서브넷을 지정하는 방법에 대한 자세한 내용은 23.7.2.2 와일드카드 패턴을 참조하십시오.

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

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

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

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

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

$는 규칙을 구분합니다.

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

+imap,pop,http:*

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

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

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

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

23.7.2.1 와일드카드 이름

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

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

와일드카드 이름 

설명 

ALL, *

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

LOCAL

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

UNKNOWN

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

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

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

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

KNOWN

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

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

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

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

DNSSPOOFER

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

23.7.2.2 와일드카드 패턴

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

23.7.2.3 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)

23.7.2.4 서버 호스트 지정

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

service@hostSpec

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

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

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

user@hostSpec

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

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

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

23.7.3 필터 예

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

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

23.7.3.1 대부분 거부

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

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

ALL: ALL

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

ALL: LOCAL @netgroup1

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

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

23.7.3.2 대부분 허용

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

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

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

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

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

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

ALL: DNSSPOOFER

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

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

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

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

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

ALL: ALL

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

23.7.3.5 웹 메일 액세스를 허용하면서 IMAP 액세스 제어

사용자의 웹 메일 액세스는 허용하고 IMAP 액세스는 금지하려면 다음과 같은 필터를 만듭니다.


+imap:access_server_host, access_server_host

이 필터는 액세스 서버 호스트의 IMAP만 허용합니다. service.imap.domainallowed를 사용하여 IMAP 서버 수준에서 필터를 설정하거나 LDAP 속성을 사용하여 도메인/사용자 수준에서 필터를 설정할 수 있습니다.

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

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

Procedure필터를 만드는 방법

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

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


    configutil -o service.service.domainallowed -v filter

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

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


    configutil -o service.service.domainnotallowed -v filter

    여기에서 service는 pop, imap 또는 http이고 filter는 23.7.2 필터 구문에 설명된 구문 규칙을 따릅니다. 다양한 예는 23.7.3 필터 예를 참조하십시오.

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

모든 저장소 관리자는 모든 서비스에 대해 프록시 인증을 수행할 수 있습니다. 저장소 관리자에 대한 자세한 내용은 20.4 저장소에 대한 관리자 액세스 지정을 참조하십시오. 모든 사용자는 해당 클라이언트 호스트가 프록시 인증 액세스 필터를 통해 액세스가 허가된 경우 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. 명령줄. 다음과 같이 명령줄에서 HTTP 서비스에 대한 프록시 인증을 위한 액세스 필터를 지정합니다.


    configutil -o service.service.proxydomainallowed -v filter

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

23.8 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 프록시 모두를 가지도록 Messaging Multiplexor(MMP)를 구성하여 POP before SMTP를 지원합니다. SMTP 클라이언트가 SMTP 프록시에 연결하면 프록시는 최근 POP 인증의 메모리 내장 캐시를 검사합니다. 동일한 클라이언트 IP 주소의 POP 인증이 발견되면 SMTP 프록시는 메시지를 로컬 및 비로컬 수신자 모두에게 보낼 수 있게 허용해야 한다는 것을 SMTP 서버에 알립니다.

ProcedureSMTP 프록시 설치 방법

SMTP 프록시 사용에 대한 자세한 내용은 Sun Java Communications Suite 5 Deployment Planning Guide의 Using the MMP SMTP Proxy를 참조하십시오.

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

    자세한 내용은 Sun Java Communications Suite 5 Installation Guide를 참조하십시오.

  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 매핑 테이블에 대한 자세한 내용은 18 장, 메일 필터링 및 액세스 제어의 18.6 SMTP 릴레이 추가를 참조하십시오.

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

    1. msg-svr-base/config/SmtpProxyAService.cfg 구성 파일을 편집합니다.

      다음 SMTP 프록시 옵션은 IMAP 및 POP 프록시 옵션(7 장, 멀티플렉서 서비스 구성 및 관리 및 Sun Java System Messaging Server 6.3 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 성능을 최적화하는 데 필요하지 않습니다( 23.5.4 SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법 참조).

      예: default:PopBeforeSmtpKludgeChannel tcp_intranet

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

      예: default:ClientLookup yes

    2. PopProxyAService.cfg 구성 파일에서 PreAuth 및 AuthServiceTTL 옵션을 설정합니다. 이 옵션은 SSL 성능을 최적화하는 데 필요하지 않습니다. 23.5.4 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

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

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

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

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