|
| |
| Sun Java System Messaging Server 6 2004Q2 관리 설명서 | |
19장
보안 및 액세스 제어 구성Messaging Server는 메일을 인터셉트할 수 없게 하고 침입자가 사용자 또는 관리자로 가장하는 것을 금지하며 특정 사용자에게만 메시징 시스템의 특정 부분에 대한 액세스를 허용할 수 있는 다양하고 유연한 보안 기능을 지원합니다.
Messaging Server 보안 구조는 Sun Java System 서버 전체의 보안 구조 중 일부입니다. 이 구조는 최대한의 상호 운용성과 일관성을 위해 업계 표준 및 공용 프로토콜에 기반을 둡니다. 따라서 Messaging Server 보안 정책을 구현하려면 이 장의 내용뿐만 아니라 여러 다른 문서를 읽어야 합니다. 특히 Messaging Server 보안을 설정하려면 Sun ONE Server Console 5.2 Server Management Guide에 설명된 정보가 필요합니다.
이 장은 다음 내용으로 구성되어 있습니다.
서버 보안 정보서버 보안에는 광범위한 주제가 포함됩니다. 대부분의 기업에서는 허가된 사용자만 서버에 액세스하고, 비밀번호나 아이디의 손상을 방지하며, 사용자가 통신 중에 다른 사람을 나타내지 않도록 하고, 필요 시 비밀리에 통신이 이루어지도록 보장하는 것이 메시징 시스템의 중요한 요구 사항입니다.
서버 통신의 보안이 다양한 방식으로 손상될 수 있기 때문에 보안을 향상시키는 여러 방법이 존재합니다. 이 장에서는 암호화, 인증 및 액세스 제어를 설정하는 방법에 대해 중점적으로 설명합니다. 다음과 같은 Messaging Server의 보안 관련 주제가 이 장에서 다루어집니다.
- 사용자 아이디 및 비밀번호 로그인: IMAP, POP, HTTP 또는 SMTP에 로그인하려면 사용자 아이디와 비밀번호를 입력해야 하며 보낸 사람 인증을 메일 수신자에게 전송하려면 SMTP 비밀번호 로그인을 사용해야 합니다.
- 암호화 및 인증: 통신 및 인증 클라이언트를 암호화하기 위해 TLS 및 SSL 프로토콜을 사용하도록 서버를 설정합니다.
- 관리자 액세스 제어: 콘솔의 액세스 제어 기능을 사용하여 Messaging Server 및 일부 개별 작업에 대한 액세스를 위임합니다.
- TCP 클라이언트 액세스 제어: 필터링 기술을 사용하여 서버의 POP, IMAP, HTTP 및 인증된 SMTP 서비스에 연결할 수 있는 클라이언트를 제어합니다.
Messaging Server와 관련된 모든 보안 및 액세스 문제가 이 장에서 설명되지는 않습니다. 다른 곳에서 다루어지는 보안 주제는 다음과 같습니다.
- 물리적 보안: 서버 시스템의 보안을 물리적으로 유지하기 위한 준비가 없을 경우 소프트웨어 보안은 무의미할 수 있습니다.
- 메일 저장소 액세스: Messaging Server에 대한 메일 저장소 관리자를 정의할 수 있습니다. 이러한 관리자는 메일함을 확인 및 모니터하고 메일함에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 18장, "메일 저장소 관리"를 참조하십시오.
- 최종 사용자 계정 구성: 최종 사용자 계정 정보는 주로 Delegated Administrator 제품을 사용하여 유지 관리할 수 있습니다(Sun LDAP Schema 1에만 해당). 또한 콘솔 인터페이스를 사용하여 최종 사용자 계정을 관리할 수도 있습니다.
- 원하지 않는 대량 전자 메일(UBE) 필터링: 17장, "메일 필터링 및 액세스 제어"를 참조하십시오.
다양한 보안 주제를 다루는 매우 많은 문서가 존재합니다. 여기에 언급된 주제에 대한 추가 배경 정보와 다른 보안 관련 정보는 http://docs.sun.com의 설명서 웹 사이트를 참조하십시오.
HTTP 보안 정보Messaging Server는 사용자 아이디/비밀번호 인증, 클라이언트 인증서 인증 및 Identity Server를 지원합니다. 그러나 클라이언트와 서버 간의 네트워크 연결을 프로토콜이 처리하는 방법에서 몇 가지 차이점이 있습니다.
POP, IMAP 또는 SMTP 클라이언트가 Messaging Server에 로그인하면 연결이 설정되고 세션이 만들어집니다. 세션이 끝날 때까지, 즉 로그인에서 로그아웃까지 연결이 지속됩니다. 새 연결을 설정할 때 클라이언트는 서버에 대해 재인증되어야 합니다.
HTTP 클라이언트가 Messaging Server에 로그인할 때 서버는 고유한 세션 아이디를 클라이언트에게 제공합니다. 클라이언트는 이 세션 아이디를 사용하여 세션 도중에 여러 연결을 설정합니다. HTTP 클라이언트는 각 연결에 대해 재인증될 필요가 없습니다. 즉, 세션이 해제되고 새 세션을 설정하려는 경우에만 클라이언트 재인증이 필요합니다. (지정된 기간 동안 HTTP 세션이 유휴 상태일 경우 서버가 자동으로 HTTP 세션을 해제하며 클라이언트는 자동으로 로그아웃됩니다. 이 기간의 기본값은 2시간입니다.)
HTTP 세션의 보안을 향상시키기 위해 다음 기술이 사용됩니다.
향상된 연결 성능을 위한 구성 매개 변수 지정에 대한 자세한 내용은 5장, "POP, IMAP 및 HTTP 서비스 구성"을 참조하십시오.
Identity Server에 대한 자세한 내용은 6장, "단일 사인 온(SSO) 사용"을 참조하십시오.
인증 기법 구성인증 기법은 클라이언트가 자신의 아이디를 서버에 대해 입증하는 특정 방법입니다. Messaging Server는 SASL (Simple Authentication and Security Layer) 프로토콜에 정의된 인증 방법과 인증서 기반 인증을 지원합니다. SASL 기법은 이 절에 설명되어 있습니다. 인증서 기반 인증에 대한 자세한 내용은 암호화 및 인증서 기반 인증 구성을 참조하십시오.
Messaging Server는 비밀번호 기반 인증을 위한 다음 SASL 인증 방법을 지원합니다.
SSL을 사용하여 도청 문제를 줄일 수 있다는 것에 주의합니다. 자세한 내용은 암호화 및 인증서 기반 인증 구성을 참조하십시오.
- DIGEST-MD5 - RFC 2831에 정의된 챌린지/응답 인증 기법입니다. (DIGEST-MD5는 아직 Messaging Multiplexor에서 지원하지 않습니다.)
- CRAM-MD5 - APOP와 비슷하지만 다른 프로토콜에서 사용하기에도 적합한 챌린지/응답 인증 기법입니다. RFC 2195에 정의되어 있습니다.
- APOP - POP3 프로토콜에만 사용할 수 있는 챌린지/응답 인증 기법입니다. RFC 1939에 정의되어 있습니다.
- LOGIN - PLAIN과 동일하며 SMTP 인증의 예비 표준 구현과의 호환성을 위해서만 존재합니다. 기본적으로 이 기법은 SMTP에 대해서만 사용 가능하게 됩니다.
챌린지/응답 인증 기법을 사용하면 서버는 요청 문자열을 클라이언트에게 보냅니다. 클라이언트는 사용자의 비밀번호와 해당 챌린지의 해시로 응답합니다. 클라이언트의 응답이 서버의 고유한 해시와 일치할 경우 사용자가 인증됩니다. 해시는 취소할 수 없으므로 사용자의 비밀번호가 네트워크를 통해 보내질 때 공개되지 않습니다.
표 19-1은 몇 개의 SALS 및 SASL 관련 configutil 매개 변수를 보여 줍니다. configutil 매개 변수의 최신 전체 목록은 Sun Java System Messaging Server Administration Reference를 참조하십시오.
일반 텍스트 비밀번호에 대한 액세스 구성
CRAM-MD5, DIGEST-MD5 또는 APOP SASL 인증 방법을 사용하려면 사용자의 일반 텍스트 비밀번호에 대한 액세스가 필요합니다. 다음 단계를 수행해야 합니다.
Directory Server를 구성하여 비밀번호 저장
CRAM-MD5, DIGEST-MD5 또는 APOP 기법을 사용하려면 다음과 같이 Directory Server를 구성하여 비밀번호를 일반 텍스트로 저장하게 해야 합니다.
Messaging Server 구성
이제 Messaging Server를 구성하여 Directory Server가 일반 텍스트 비밀번호를 검색할 수 있다는 것을 인식하도록 할 수 있습니다. 이렇게 하면 Messaging Server는 APOP, CRAM-MD5 및 DIGEST-MD5를 안전하게 광고할 수 있습니다.
configutil -o sasl.default.ldap.has_plain_passwords -v 1
값을 0 또는 null(“”)로 설정하여 이러한 챌린지/응답 SASL 기법을 사용 불가능하게 할 수 있습니다.
MMP는 CRAM과 동등한 옵션을 가집니다.
사용자 전환
configutil을 사용하여 사용자 전환에 대한 정보를 지정할 수 있습니다. 적절한 항목을 갖고 있지 않은 기법으로 클라이언트가 인증을 시도하거나 사용자 비밀번호가 변경되는 경우를 예로 들 수 있습니다.
configutil -o sasl.default.auto_transition -v value
value의 경우 다음 중 하나를 지정할 수 있습니다.
사용자를 성공적으로 전환하려면 사용자 비밀번호 속성에 대한 쓰기 권한을 Messaging Server에 허용하는 ACI를 Directory Server에서 설정해야 합니다. 이렇게 하려면 다음 단계를 수행합니다.
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 채널 키워드를 포함하도록 채널 정의를 수정해야 합니다. 자세한 내용은 전송 계층 보안 및 Messaging Server Reference Manual을 참조하십시오.
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 모듈을 설치하려면 다음을 수행합니다.
보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL에 대한 장을 참조하십시오.
하드웨어 암호화 가속기 설치 암호화를 위해 SSL을 사용할 경우 하드웨어 암호화 가속기를 설치하여 메일을 암호화 및 해독하는 서버의 성능을 향상시킬 수 있습니다. 일반적으로 암호화 가속기는 서버 시스템에 영구적으로 설치된 하드웨어 보드와 소프트웨어 드라이버로 구성됩니다. Messaging Server는 PKCS #11 API를 따르는 가속기 모듈을 지원합니다. (이러한 모듈은 기본적으로 고유한 키를 저장하지 않으며 이를 위한 내부 데이터베이스를 사용하는 하드웨어 토큰입니다.) 가속기를 설치하려면 우선 하드웨어와 드라이버를 제조업체에서 지정한 대로 설치한 다음 하드웨어 인증서 토큰과 마찬가지로 PKCS #11 모듈을 설치하여 설치를 완료합니다.
서버 인증서 요청
콘솔에서 서버를 열고 인증서 설정 마법사를 실행하여 서버 인증서를 요청합니다. 이 마법사는 콘솔 메뉴나 Messaging Server 암호화 탭에서 액세스할 수 있습니다. 이 마법사를 사용하여 다음 작업을 수행합니다.
CA로부터 전자 메일 응답이 도착하면 이를 텍스트 파일로 저장하고 인증서 설정 마법사를 사용하여 설치합니다.
보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL에 대한 장을 참조하십시오.
인증서 데이터베이스 만들기
- 수퍼유저로 로그인하거나 수퍼유저(root)가 됩니다.
- /opt/SUNWmsgsr/config/sslPassword에서 certutil에 대한 인증서 데이터베이스 비밀번호를 지정합니다. 예를 들면 다음과 같습니다.
# echo "password" > /opt/SUNWmsgsr/config/sslpassword
여기서 password는 해당 비밀번호입니다.
- sbin 디렉토리로 이동하여 인증서 데이터베이스(cert7.db) 및 키 데이터베이스(key3.db)를 생성합니다. 예를 들면 다음과 같습니다.
# cd /opt/SUNWmsg/sbin
# ./certutil -N -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword- 자동 서명된 기본 루트 인증 기관 인증서를 생성합니다. 예를 들면 다음과 같습니다.
- 호스트에 대한 인증서를 생성합니다. 예를 들면 다음과 같습니다.
여기서 hostname.sesta.com은 서버 호스트 이름입니다.
- 인증서의 유효성을 검사합니다. 예를 들면 다음과 같습니다.
# ./certutil -V -u V -n SampleRootCA -d /var/opt/SUNWmsgsr/config
# ./certutil -V -u V -n Server-Cert -d /opt/SUNWmsgsr/config- 인증서를 나열합니다. 예를 들면 다음과 같습니다.
# ./certutil -L -d /opt/SUNWmsgsr/config
# ./certutil -L -n Server-Cert -d /opt/SUNWmsgsr/config- modutil을 사용하여 사용 가능한 보안 모듈(secmod.db)을 나열합니다. 예를 들면 다음과 같습니다.
# . ./modutil -list -dbdir /opt/SUNWmsgsr/config
- alias 파일의 소유자를 icsuser 및 icsgroup 또는 Calendar Server를 실행할 사용자 및 그룹 아이디로 변경합니다. 예를 들면 다음과 같습니다.
find /opt/SUNWmsgsr/config/cert7.db -exec chown mailsrv {} \;
find /opt/SUNWmsgsr/config/key3.db -exec chown mailsrv {} \;
find /opt/SUNWmsgsr/config/cert7.db -exec chgrp mail {} \;
find /opt/SUNWmsgsr/config/key3.db -exec chgrp mail {} \;여기서 mailsrv는 메일 서버 UID이고 mail은 메일 서버 GID입니다.
- messaging services를 다시 시작하여 SSL을 활성화합니다.
인증서 설치
설치는 요청 생성과 별개의 프로세스입니다. 인증서 요청에 대한 전자 메일 응답이 CA로부터 도착했으며 이를 텍스트 파일로 저장한 후에는 인증서 설정 마법사를 한 번 더 실행하여 다음과 같이 파일을 인증서로 설치합니다.
보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL에 대한 장을 참조하십시오.
신뢰할 수 있는 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 인증서를 요청하여 설치하려면 다음을 수행합니다.
보다 자세한 지침은 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!
내부 인증서를 설치할 때 기본값이 아닌 비밀번호를 지정할 경우 비밀번호 파일의 위 행을 편집하여 지정된 비밀번호를 반영해야 합니다. 외부 모듈을 설치할 경우 이에 대해 지정한 모듈 이름과 비밀번호를 포함하는 새 행을 파일에 추가해야 합니다.
주의
서버 시작 시에 모듈 비밀번호를 묻는 메시지가 관리자에게 표시되지 않으므로 서버에 대한 관리자 액세스 제어와 서버 호스트 시스템 및 해당 백업의 물리적 보안을 적절하게 하는 것이 특히 중요합니다.
SSL 사용 및 암호문 선택
콘솔을 사용하여 SSL을 사용 가능하게 하고 Messaging Server가 클라이언트와의 암호화된 통신에 사용할 수 있는 암호화 암호문 집합을 선택할 수 있습니다.
암호문 정보
암호문은 암호화 프로세스에서 데이터를 암호화 및 해독하는 데 사용되는 알고리즘입니다. 일부 암호문은 다른 암호문보다 강력한데 이는 이러한 암호문으로 스크램블된 메일을 권한 없는 사용자가 푸는 것이 더 어렵다는 것을 의미합니다.
암호문은 키(긴 번호)를 데이터에 적용하는 방법으로 데이터에서 작동합니다. 일반적으로 암호문이 암호화 도중에 사용하는 키가 더 길수록 적절한 암호화 키 없이 데이터를 해독하는 것이 어려워집니다.
클라이언트는 Messaging Server와의 SSL 연결을 시작할 때 암호화에 사용할 선호되는 암호문과 키 길이를 서버에 알려줍니다. 모든 암호화된 통신에서 클라이언트와 서버는 동일한 암호문을 사용해야 합니다. 일반적으로 다양한 암호문 및 키 조합이 사용되기 때문에 서버는 암호화를 유연하게 지원해야 합니다. Messaging Server는 암호문 및 키 길이 조합을 최대 6개까지 지원할 수 있습니다.
표 6.1에는 SSL 3.0과 함께 사용하는 Messaging Server에서 지원하는 암호문을 나열합니다. 이 표에 요약된 정보의 자세한 내용은 Managing Servers with iPlanet Console의 Introduction to SSL 절에서 확인할 수 있습니다.
특정 암호문을 사용하지 않을 중요한 이유가 없을 경우 모든 암호문을 지원해야 합니다. 그러나 일부 국가에서는 수출법에 따라 특정 암호화 암호문의 사용이 제한된다는 것에 주의합니다. 또한 미국 수출 제한법이 완화되기 전에 만들어진 일부 클라이언트 소프트웨어는 더 높은 강도의 암호화를 사용할 수 없습니다. 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 채널 키워드를 포함해야 합니다. 자세한 내용은 전송 계층 보안 및 Messaging Server Reference Manual을 참조하십시오.
인증서 기반 로그인 설정
비밀번호 기반 인증 외에도 Sun Java System 서버는 디지털 인증서 검사를 통한 사용자 인증을 지원합니다. 인증서 기반 인증에서 클라이언트는 서버와의 SSL 세션을 설정하고 사용자의 인증서를 서버로 제출합니다. 그런 다음 서버는 제출된 인증서가 진짜인지 여부를 평가합니다. 인증서가 검증될 경우 사용자는 인증된 것으로 간주됩니다.
인증서 기반 로그인을 사용하도록 Messaging Server를 설정하려면 다음을 수행합니다.
- 서버의 서버 인증서를 얻습니다. 자세한 내용은 인증서 얻기를 참조하십시오.
- 인증서 설정 마법사를 실행하여 서버가 인증할 사용자에게 인증서를 발급하는 신뢰할 수 있는 모든 인증 기관의 인증서를 설치합니다. 자세한 내용은 신뢰할 수 있는 CA의 인증서 설치를 참조하십시오.
서버의 데이터베이스에 최소한 하나 이상의 신뢰할 수 있는 CA가 있을 경우 서버는 각 연결 클라이언트로부터 클라이언트 인증서를 요청한다는 것에 주의합니다.
- SSL을 설정합니다. 자세한 내용은 SSL 사용 및 암호문 선택을 참조하십시오.
- (선택 사항) 제출된 인증서의 정보에 기초하여 서버가 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 프록시를 설치하는 방법에 대한 지침은 SMTP 프록시 설치를 참조하십시오.
Messaging Server에 대한 관리자 액세스 구성이 절의 내용은 주로 Sun Java System LDAP Schema 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 1이 사용될 경우)하기 위해 작성할 수 있는 다음과 같은 액세스 계층의 최상위에 위치합니다.
- 구성 관리자. Sun Java System 서버의 네트워크에 대한 “수퍼유저”입니다. 모든 자원에 대한 전체 액세스 권한을 가집니다.
- 서버 관리자. 도메인 관리자는 각 유형의 서버를 관리하기 위해 그룹을 만들 수 있습니다. 예를 들어, 관리 도메인이나 전체 네트워크에서 모든 Messaging Server를 관리하기 위해 메시징 관리자 그룹을 만들 수 있습니다. 이러한 그룹의 구성원은 다른 서버는 제외하고 해당 관리 도메인의 모든 Messaging Server에 액세스할 수 있습니다.
- 작업 관리자. 마지막으로 위 관리자는 모두 단일 Messaging Server 또는 Messaging Server 집합에 대한 제한된 액세스 권한을 가진 그룹을 만들거나 개별 사용자를 지정할 수 있습니다. 이러한 작업 관리자는 서버를 시작 또는 중지하거나 특정 서비스의 로그를 액세스하는 등의 제한된 특정 서버 작업만 수행할 수 있습니다.
콘솔은 관리자가 다음 작업을 수행할 수 있는 편리한 인터페이스를 제공합니다.
- “서버 전체에 대한 액세스 제공”(다음)에 설명된 대로 특정 Messaging Server에 대한 액세스를 그룹이나 개인에게 허가합니다.
- 특정 작업에 대한 액세스 제한에 설명된 대로 특정 Messaging Server의 특정 작업에 대한 액세스를 제한합니다.
서버 전체에 대한 액세스 제공
특정 Messaging Server 인스턴스에 대한 액세스 권한을 사용자나 그룹에 제공하려면 다음을 수행합니다.
보다 자세한 지침은 Managing Servers with iPlanet Console에서 서버 관리 위임에 대한 장을 참조하십시오.
특정 Messaging Server에 액세스할 수 있는 개인 및 그룹 목록을 설정한 후에는 다음에 설명된 것처럼 ACI를 사용하여 특정 서버 작업을 해당 목록의 특정 개인 또는 그룹에 위임할 수 있습니다.
특정 작업에 대한 액세스 제한
관리자는 일반적으로 하나 이상의 관리 작업을 수행하기 위해 서버에 연결합니다. 일반 관리 작업은 콘솔에서 Messaging Server 작업 양식에 나열됩니다.
기본적으로 특정 Messaging Server에 대한 액세스는 모든 해당 작업에 대한 액세스를 의미합니다. 그러나 작업 양식의 각 작업은 추가된 액세스 제어 명령(ACI) 집합을 가질 수 있습니다. 서버는 작업에 대한 액세스를 연결된 사용자(서버 전체에 대한 액세스 권한을 이미 갖고 있는 사용자)에게 제공하기 전에 이러한 ACI를 참조합니다. 실제로 서버는 사용자가 권한을 갖고 있는 작업만 작업 양식에 표시합니다.
Messaging Server에 액세스할 수 있는 경우 임의의 작업(즉, 액세스할 수 있는 작업)에 대한 ACI를 작성 및 편집함으로써 다른 사용자나 그룹이 가질 수 있는 작업 액세스 권한을 제한할 수 있습니다.
연결된 사용자나 그룹이 가질 수 있는 작업 액세스 권한을 제한하려면 다음을 수행합니다.
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:*
와일드카드 이름
다음 와일드카드 이름을 사용하여 서비스 이름, 호스트 이름이나 주소, 또는 아이디를 나타낼 수 있습니다.
와일드카드 패턴
다음 패턴을 서비스나 클라이언트 주소에서 사용할 수 있습니다.
- 점 문자(.)로 시작하는 문자열. 이름의 마지막 구성 요소가 지정된 패턴과 일치할 경우 호스트 이름이 일치합니다. 예를 들어, 와일드카드 패턴 .siroe.com은 도메인 siroe.com의 모든 호스트와 일치합니다.
- 점 문자(.)로 끝나는 문자열. 첫 번째 숫자 필드가 지정된 패턴과 일치할 경우 호스트 주소가 일치합니다. 예를 들어, 와일드카드 패턴 123.45.는 서브넷 123.45.0.0에 있는 모든 호스트의 주소와 일치합니다.
- n.n.n.n/m.m.m.m 형식의 문자열. 이 와일드카드 패턴은 net/mask 쌍으로 해석됩니다. net이 주소 및 mask의 비트 AND와 같은 경우 호스트 주소가 일치합니다. 예를 들어, 패턴 123.45.67.0/255.255.255.128은 123.45.67.0에서 123.45.67.127까지의 모든 주소와 일치합니다.
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 서비스(또는 와일드카드 이름)에 의해 반환되는 사용자 아이디입니다.
필터에서 클라이언트 아이디를 지정하는 것은 유용할 수 있지만 다음과 같은 사항에 주의해야 합니다.
- identd 서비스는 인증이 아닙니다. 클라이언트 시스템이 손상된 경우 이 서비스가 반환하는 클라이언트 사용자 아이디를 신뢰할 수 없습니다. 일반적으로 특정 사용자 이름을 사용하지 않으며 ALL, KNOWN 또는 UNKNOWN 와일드카드 이름만 사용합니다.
- identd는 대부분의 최신 클라이언트 시스템에서 지원되지 않으므로 현대적인 배포에서는 거의 가치가 없습니다. 이후 버전에서는 identd 지원을 제거하는 것이 고려되고 있으므로 이 기능이 필요한 경우 Sun Java System에 따로 알릴 필요가 있을 것입니다.
- 사용자 아이디 조회는 시간이 걸립니다. 따라서 모든 사용자에 대한 조회를 수행하면 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 세션에만 적용된다는 점에서 이것은 거의 가치가 없습니다. 인증되지 않은 SMTP 세션에 대한 액세스를 제어하는 방법은 17장, "메일 필터링 및 액세스 제어"를 참조하십시오.
콘솔 콘솔을 사용하여 필터를 만들려면 다음 단계를 따릅니다.필요한 경우 일련의 삭제 및 추가 작업을 수행하여 허용 또는 거부 필터의 순서를 재정렬할 수 있다는 것에 주의합니다.
필터 구문 지정과 다양한 예는 필터 문을 참조하십시오. 추가 예는 필터 예를 참조하십시오.
명령줄 다음과 같이 명령줄에서 액세스 및 거부 필터를 지정할 수도 있습니다.서비스에 대한 액세스 필터를 작성 또는 편집하려면 다음을 수행합니다.
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 담당자에게 문의하십시오.
콘솔 HTTP 서비스에 대한 프록시 인증을 위한 액세스 필터를 만들려면 다음을 수행합니다.
- 콘솔에서 액세스 필터를 만들려는 Messaging Server를 엽니다.
- 구성 탭을 누릅니다.
- 왼쪽 표시 영역에서 서비스 폴더를 열고 서비스 폴더 아래에서 HTTP를 선택합니다.
- 오른쪽 표시 영역에서 프록시 탭을 누릅니다.
이 탭의 허용 필드에는 프록시 인증에 대한 기존의 허용 필터가 표시됩니다.
- 새 필터를 만들려면 추가를 누릅니다.
허용 필터 창이 열리면 새 필터의 텍스트를 창에 입력하고 확인을 누릅니다.
- 기존 필터를 편집하려면 필터를 선택하고 편집을 누릅니다.
허용 필터 창이 열리면 창에 표시된 필터의 텍스트를 편집하고 확인을 누릅니다.
- 기존 필터를 삭제하려면 허용 필드에서 필드를 선택하고 삭제를 누릅니다.
- 프록시 탭에 대한 변경이 끝나면 저장을 누릅니다.
허용 필터 구문에 대한 자세한 내용은 필터 문을 참조하십시오.
명령줄 다음과 같이 명령줄에서 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 서버에 알립니다.
SMTP 프록시 설치
- Sun ONE Messaging Server 설치 설명서에 설명된 대로 MMP (Messaging Multiplexor)를 설치합니다.
- MMP에서 SMTP 프록시를 사용 가능하게 합니다.
다음 문자열을
msg_svr_base/lib/SmtpProxyAService@25|587
msg_svr_base/config/AService.cfg 파일의 ServiceList 옵션에 추가합니다. 이 옵션은 길이가 한 줄이며 줄 바꿈을 포함할 수 없습니다.
- 각 SMTP 중계 서버에서 SMTP 채널 옵션 파일 tcp_local_option의 PROXY_PASSWORD 옵션을 설정합니다.
SMTP 프록시는 SMTP 서버에 연결되면 실제 클라이언트 IP 주소와 다른 연결 정보를 SMTP 서버에 알려 SMTP 서버가 중계 차단 및 다른 보안 정책(POP before SMTP 인증 포함)을 제대로 적용할 수 있게 해야 합니다. 이것은 보안에 민감한 작업으로서 반드시 인증되어야 합니다. MMP SMTP 프록시 및 SMTP 서버 모두에서 구성되는 프록시 비밀번호는 다른 사람이 기능을 남용할 수 없게 합니다.
예: PROXY_PASSWORD=A_Password
- MMP에서 SMTP 서버에 연결하기 위해 사용하는 IP 주소가 INTERNAL_IP 매핑 테이블에서 "내부" 주소로 처리되지 않는지 확인합니다.
INTERNAL_IP 매핑 테이블에 대한 자세한 내용은 17장, "메일 필터링 및 액세스 제어"에서 SMTP 중계 추가를 참조하십시오.
- POP before SMTP를 지원하도록 SMTP 프록시를 구성합니다.
- msg_svr_base/config/SmtpProxyAService.cfg 구성 파일을 편집합니다.
다음 SMTP 프록시 옵션은 IMAP 및 POP 프록시에 대한 동일한 옵션과 같은 방식으로 작동합니다. Messaging Server 설치 설명서의 부록 "Messaging Multiplexor 설치” 및 Messaging Server Reference Manual의 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 mothraSmtpProxyPassword는 SMTP 중계 서버에 대한 소스 채널 변경 사항을 허가하는 데 사용되는 비밀번호입니다. 이 옵션은 필수이고 기본값은 없으며 SMTP 서버의 PROXY_PASSWORD 옵션과 일치해야 합니다.
예: default:SmtpProxyPassword A_PasswordEhloKeywords 옵션은 기본 집합 외에 클라이언트에게 전달할 프록시에 대한 EHLO 확장 키워드 목록을 제공합니다. MMP는 SMTP 중계에 의해 반환된 EHLO 목록에서 인식되지 않은 모든 EHLO 키워드를 제거합니다.
EhloKeywords는 이 목록에서 제거하지 않아야 하는 추가 EHLO 키워드를 지정합니다. 기본값은 비어 있지만 8BITMIME, PIPELINING, DSN, ENHANCEDSTATUSCODES, EXPN, HELP, XLOOP, ETRN, SIZE, STARTTLS, AUTH 키워드는 SMTP 프록시에서 지원되므로 이 옵션에 나열할 필요가 없습니다.
다음은 드물게 사용되는 “TURN” 확장을 사용하는 사이트에서 사용할 수 있는 예입니다.
예: default:EhloKeywords TURNPopBeforeSmtpKludgeChannel 옵션은 허가된 POP before SMTP 연결에 사용할 MTA 채널의 이름으로 설정됩니다. 기본값은 비어 있으며 POP before SMTP를 사용 가능하게 하려는 사용자에 대한 일반 설정은 tcp_intranet입니다. 이 옵션은 SSL 성능을 최적화하는 데 필요하지 않습니다(SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법 참조).
예: default:PopBeforeSmtpKludgeChannel tcp_intranetClientLookup 옵션은 기본적으로 no입니다. yes로 설정된 경우 클라이언트 IP 주소에 대한 DNS 역방향 조회가 무조건 수행되므로 SMTP 중계 서버에서 이 작업을 수행할 필요가 없습니다. 이 옵션은 호스트된 도메인별로 설정할 수 있습니다.
예:
default:ClientLookup yes- PopProxyAService.cfg 구성 파일에서 PreAuth 및 AuthServiceTTL 옵션을 설정합니다. 이 옵션은 SSL 성능을 최적화하는 데 필요하지 않습니다. SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법을 참조하십시오.
이러한 옵션은 POP 인증 후에 사용자가 메일을 전달할 수 있도록 허가된 시간(초)을 지정합니다. 일반 설정은 900-1800(15-30분)입니다.
예:
default:PreAuth yes
default:AuthServiceTTL 900- 목록에서 다음 항목을 시도하기 전에 MMP가 SMTP 중계의 응답을 대기하는 시간(초)을 선택적으로 지정할 수 있습니다.
기본값은 10(초)입니다. SMTP 중계에 대한 연결이 실패할 경우 MMP는 페일오버 시간 초과에 해당하는 시간(분) 동안 해당 중계를 시도하지 않습니다(따라서 페일오버 시간 초과가 10초이고 중계가 실패할 경우 MMP는 해당 중계를 10분 동안 다시 시도하지 않음).
예: default:FailoverTimeout 10
SMTP 서비스에 대한 클라이언트 액세스 구성SMTP 서비스에 대한 클라이언트 액세스 구성에 대한 자세한 내용은 17장, "메일 필터링 및 액세스 제어"를 참조하십시오.
