Sun Java 로고     이전      목차      색인      다음     

Sun 로고
Sun Java(TM) System Directory Server 5 2004Q2 관리 설명서 

11장
인증 및 암호화 관리

Directory Server는 네트워크를 통한 안전하고 신뢰할 수 있는 통신을 제공하기 위한 몇 가지 기법을 제공합니다. LDAPS는 SSL(Secure Sockets Layer)에 추가로 실행되는 표준 LDAP 프로토콜로, 데이터를 암호화하고 인증서를 사용하여(선택 사항) 인증합니다.

Directory Server는 Start TLS(Start Transport Layer Security) 확장 작업을 지원하므로 기존에 암호화되지 않은 LDAP 연결에서 TLS를 사용할 수 있습니다.

Directory Server에서는 SASL(Simple Authentication and Security Layer)을 통한 GSSAPI(Generic Security Services API)도 지원하므로 Solaris 운영 체제에서 Kerveros 버전 5 보안 프로토콜을 사용할 수 있습니다. 이 경우 아이디 매핑 기법이 커버로스 사용자를 디렉토리 아이디와 연결합니다.

추가 보안 정보에 대해서는 다음 위치의 NSS 웹 사이트를 참조하십시오.

http://www.mozilla.org/projects/security/pki/nss/

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

Directory Server의 SSL 소개

SSL(Secure Sockets Layer)은 Directory Server와 클라이언트 간에 암호화된 통신과 인증(선택 사항)을 제공합니다. LDAP와 DSML-over-HTTP 프로토콜 모두에 대해 SSL을 활성화하여 모든 서버 연결에 보안을 제공할 수 있습니다. 또한 복제 및 연결 접미어 기법을 구성하여 서버 간의 보안 통신에 SSL을 사용할 수도 있습니다.

SSL을 단순 인증(바인드 DN과 비밀번호)과 함께 사용하면 서버 간에 전송되는 모든 데이터가 암호화되므로 기밀성과 데이터 무결성이 보장됩니다. 선택 사항으로, 클라이언트는 인증서를 사용하여 Directory Server 또는 SASL(Simple Authentication and Security Layer)을 통한 타사 보안 기법에 인증할 수 있습니다. 인증서 기반 인증에서는 클라이언트나 서버를 사칭하지 못하도록 공개 키 암호화를 사용합니다.

Directory Server는 별도의 포트에서 SSL 통신과 비SSL 통신을 동시에 지원합니다. 보안상의 이유로 모든 통신을 보안 포트로 제한할 수도 있습니다. 클라이언트 인증은 구성이 가능하며, 필수 또는 선택 사항으로 구성되어 실행할 보안 수준을 결정할 수 있습니다.

SSL을 사용하면 일반 LDAP 연결에 보안을 제공하는 Start TLS 확장 작업도 지원됩니다. 클라이언트는 비SSL 포트에 바인드한 후에 TLS(Transport Layer Security) 프로토콜을 사용하여 SSL 연결을 시작할 수 있습니다. Start TLS 작업은 클라이언트의 유연성을 높이며 포트 할당을 용이하게 합니다.

SSL에서 제공하는 암호화 기법은 속성 암호화에도 사용됩니다. SSL을 사용할 경우 접미어에 속성 암호화를 구성하여 디렉토리에 저장된 데이터를 보호할 수 있습니다. 자세한 내용은 속성 값 암호화를 참조하십시오.

클라이언트의 SSL 및 인증서 사용에 따라 디렉토리 내용에 대한 액세스 제어를 구성하여 보안을 강화할 수 있습니다. 특정 인증 방법이 필요한 액세스 제어 명령(ACI)을 정의할 수 있으며, 이 경우 보안 채널을 통해서만 데이터가 전송됩니다. 자세한 내용은 바인드 규칙을 참조하십시오.

Administration Server에서 SSL을 구성하는 방법, SSL, 인터넷 보안 및 인증서에 대한 자세한 내용은 Administration Server Administration Guide의 9장, "Using SSL and TLS with Sun Java System Servers"를 참조하십시오.

SSL 활성화 단계 요약

각각의 단계에 대해서는 이 장의 후속 절에서 설명합니다.

  1. 인증서를 얻어 Directory Server에 설치하고 Directory Server에서 인증 기관의 인증서를 트러스트하도록 구성합니다. 이 절차에는 다음과 같은 작업이 포함됩니다.
    1. 필요한 경우 인증서 데이터 베이스 작성
    2. 서버에서 인증서 요청을 생성하여 서버 인증서를 제공할 인증 기관으로 전송
    3. 서버에 새 인증서 설치
    4. 인증 기관과 인증 기관이 발급한 모든 인증서 트러스트
  2. LDAP 및 DSML 작업을 위한 보안 포트를 포함하여 디렉토리에서 SSL을 활성화하고 구성합니다. Directory Server 콘솔에서 SSL을 사용하여 서버에 액세스하도록 구성할 수도 있습니다.
  3. 선택 사항으로, 다음 클라이언트 인증 기법 중에서 하나 이상을 서버에 구성합니다.
    1. 인증서 기반의 기본 인증 기법
    2. SASL을 통한 DIGEST_MD5 인증 기법
    3. 커버로스 V5 보안 기법의 사용을 허용하는 SASL을 통한 GSSAPI 인증
  4. 선택 사항으로 사용할 인증 기법을 포함하여 클라이언트에서 Directory Server와의 통신에 SSL을 사용하도록 구성합니다.

명령줄을 통해 인증서를 관리하려면 certutil 도구를 사용하여 위의 단계 중 일부를 수행할 수도 있습니다. 이 도구는 SUNWtlsu 패키지에 포함되어 있습니다.

서버 인증서 얻기 및 설치

이 절에서는 인증서 데이터베이스를 작성하고, Directory Server에서 사용할 인증서를 얻어서 설치하며, Directory Server에서 인증 기관(CA)의 인증서를 트러스트하도록 구성하는 절차에 대해 설명합니다.

인증서 데이터베이스 작성

서버에 처음 SSL을 구성할 때 보안 장치 비밀번호를 설정해야 합니다. 외부 하드웨어 보안 장치를 사용하지 않는 경우 아래 파일에 저장된 인증서 및 키 데이터베이스가 내부 보안 장치가 됩니다.

ServerRoot/alias/slapd-serverID-cert8.db
ServerRoot/alias/slapd-serverID-key3.db

serverID에 대문자가 포함되어 있으면 아래의 명령줄 절차를 사용하여 인증서 데이터베이스를 작성해야 합니다.

콘솔 사용

콘솔에서 인증서 관리자 대화 상자를 처음 실행하면 인증서 데이터베이스 파일이 자동으로 작성됩니다.

  1. Directory Server 콘솔의 최상위 태스크 탭에서 인증서 관리 버튼을 누릅니다. 또는 태스크 탭을 표시하고 콘솔 > 보안 메뉴에서 인증서 관리 항목을 선택합니다.
  2. 서버에서 인증서 및 키 데이터베이스를 자동으로 작성하며, 보안 장치 비밀번호를 설정하라는 메시지가 표시됩니다. 이 비밀번호는 서버에 저장된 인증서의 개인 키를 보호합니다. 비밀번호를 두 번 입력하여 확인한 다음 확인을 누릅니다.

명령줄 사용

명령줄에서 인증서 데이터베이스 파일을 작성하는 경우 서버가 이 파일을 찾을 수 있도록 아래 절차에 제공된 경로 및 파일 이름 접두어를 사용해야 합니다.

  1. 서버 호스트 시스템에서 아래 명령을 실행하여 인증서 데이터베이스를 작성합니다.

    2. certutil -N -d ServerRoot/alias -P slapd-LCserverID

    여기서 LCserverID는 모두 소문자로 지정된 서버 이름입니다.

    인증서 키를 보호할 비밀번호를 입력하라는 메시지가 표시됩니다.

인증서 요청 생성

PEM 형식으로 PKCS #10 인증서 요청을 생성하려면 아래 절차 중 하나를 사용합니다. PEM은 RFC 1421부터 1424 (http://www.ietf.org/rfc/rfc1421.txt)까지에 지정된 Privacy Enhanced Mail 형식으로, base64 인코딩된 인증서 요청을 US-ASCII 문자로 나타내는 데 사용됩니다. 요청 내용은 아래 예와 같이 표시됩니다.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBrjCCARcCAQAwbjELMAkGA1UBhMCVXMxEzARBgNVBAgTCkNBElGT1JOSUExLD
AqBgVBAoTI25ldHNjYXBlIGNvb11bmljYXRpb25zIGNvcnBvcmF0aWuMRwwGgYDV
QQDExNtZWxsb24umV0c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAUAA4GNADCBiQK
BgCwAbskGh6SKYOgHy+UCSLnm3ok3X3u83Us7u0EfgSLR0f+K41eNqqWRftGR83e
mqPLDOf0ZLTLjVGJaHJn4l1gG+JDf/n/zMyahxtV7+T8GOFFigFfuxJaxMjr2j7I
vELlxQ4IfZgwqCm4qQecv3G+N9YdbjveMVXW0v4XwIDAQABAAwDQYJKoZIhvcNAQ
EEBQADgYEAZyZAm8UmP9PQYwNy4Pmypk79t2nvzKbwKVb97G+MT/gw1pLRsuBoKi
nMfLgKp1Q38K5Py2VGW1E47/rhm3yVQrIiwV+Z8Lcc=
-----END NEW CERTIFICATE REQUEST-----

콘솔 사용

  1. Directory Server 콘솔의 최상위 태스크 탭에서 인증서 관리 버튼을 누릅니다. 또는 태스크 탭을 표시하고 콘솔 > 보안 메뉴에서 인증서 관리 항목을 선택합니다.

    2. 인증서 관리 대화 상자가 표시됩니다.

  2. 서버 인증서 탭을 선택하고 요청 버튼을 누릅니다.

    3. 인증서 요청 마법사가 표시됩니다.

  3. 서버에서 CA와 직접 통신할 수 있도록 지원하는 플러그 인을 설치한 경우 지금 선택할 수 있습니다. 그렇지 않으면 생성된 요청을 전자 메일이나 웹 사이트를 통해 전송하여 수동으로 인증서를 요청해야 합니다. 다음을 눌러 계속합니다.
  4. 빈 텍스트 필드에 다음과 같은 요청자 정보를 입력합니다.

    5. 서버 이름. DNS 조회 시 사용되는 Directory Server의 전체 호스트 이름을 입력합니다(예: east.example.com).

    조직. 회사나 기관의 공식 이름을 입력합니다. 대부분의 CA는 사업자 등록증 사본과 같은 공식 문서를 사용하여 이 정보를 확인하도록 요청합니다.

    조직 구성 단위. (선택 사항) 회사 부서 또는 사업부를 잘 나타내는 이름을 입력합니다.

    구/군/시. (선택 사항) 회사가 있는 구/군/시 이름을 입력합니다.

    시/도. 약어를 사용하지 말고 회사가 있는 시/도의 전체 이름을 입력합니다.

    국가/지역. 두 자로 된 ISO 형식의 국가 이름 약어를 선택합니다. 미국의 국가 코드는 US입니다. Directory Server Administration Reference의 5장, “Directory Internationalization Reference”에는 ISO 국가 코드 목록이 포함되어 있습니다.

    다음을 눌러 계속합니다.

  5. 보안 장치 비밀번호를 입력하고 다음을 누릅니다. 이 비밀번호는 인증서 데이터베이스 작성에서 설정한 비밀번호입니다.
  6. 클립보드로 복사 또는 파일에 저장을 선택하여 인증 기관에 보내야 하는 인증서 요청 정보를 저장합니다.
  7. 완료를 눌러 인증서 요청 마법사를 닫습니다.

명령줄 사용

  1. 아래 명령을 실행하여 서버 인증서 요청을 작성합니다.

    2. certutil -R \
    -s "cn=serverName,ou=division,o=company,l=city,st=state,c=country" \
    -a -d ServerRoot/alias -P slapd-serverID-

    -s 옵션은 요청된 서버 인증서의 DN을 지정합니다. 대체로 인증 기관은 서버를 정확하게 식별하기 위해 이 예에 사용된 속성을 모두 필요로 합니다. 각 속성에 대한 자세한 내용은 위의 단계 4를 참조하십시오.

  2. certutil 도구로부터 서버의 키 데이터베이스 비밀번호를 입력하라는 메시지가 표시됩니다. 이 비밀번호는 인증서 데이터베이스 작성에서 설정한 비밀번호입니다. 그런 후에 이 도구는 PEM 인코딩된 텍스트 형식으로 PKCS #10 인증서 요청을 생성합니다.

서버 인증서 설치

인증 기관의 절차에 따라 이전 절에서 생성한 인증서 요청을 인증 기관으로 전송합니다. 예를 들어, 전자 메일로 인증서 요청을 보내야 하는 경우도 있고 CA 웹 사이트에서 요청을 입력할 수 있는 경우도 있습니다.

요청을 보낸 후에는 CA에서 이 요청에 대한 응답으로 인증서를 보내줄 때까지 기다려야 합니다. 요청에 대한 응답 시간은 경우에 따라 달라집니다. 예를 들어, 회사 내부의 CA인 경우 하루나 이틀이면 요청에 대한 응답을 받을 수 있습니다. 회사 외부의 CA를 선택하면 요청에 대한 응답을 받을 때까지 몇 주가 걸릴 수도 있습니다.

CA로부터 받은 응답 정보는 반드시 텍스트 파일에 저장해야 합니다. 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-----

인증서 데이터도 안전한 장소에 백업해 두어야 합니다. 시스템에 저장된 인증서 데이터가 손실될 경우 백업 파일을 사용하여 인증서를 다시 설치할 수 있습니다.

서버 인증서가 있으면 즉시 서버의 인증서 데이터베이스에 설치할 수 있습니다.

콘솔 사용

  1. Directory Server 콘솔의 최상위 "태스크" 탭에서 "인증서 관리" 버튼을 누릅니다. 또는 "태스크" 탭을 표시하고 "콘솔 > 보안" 메뉴에서 "인증서 관리" 항목을 선택합니다.

    2. "인증서 관리" 창이 표시됩니다.

  2. "서버 인증서" 탭을 선택하고 "설치"를 누릅니다.

    3. "인증서 설치 마법사"가 표시됩니다.

  3. 다음 인증서 위치 옵션 중에서 하나를 선택합니다.
  1. 표시된 인증서 정보가 올바른지 확인하고 다음을 누릅니다.
  2. 인증서 이름을 지정하고 다음을 누릅니다. 이 이름이 인증서 테이블에 표시됩니다.
  3. 개인 키를 보호하는 비밀번호를 입력하여 인증서를 확인합니다. 이 비밀번호는 인증서 데이터베이스 작성의 단계 2에서 입력한 비밀번호와 같아야 합니다. 작업이 끝나면 완료를 누릅니다.

    4. 서버 인증서 탭의 목록에 새 인증서가 표시됩니다. 이제 서버에서 SSL을 사용할 수 있습니다.

명령줄 사용

  1. 아래 명령을 실행하여 인증서 데이터베이스에 새 서버 인증서를 설치합니다.

    2. certutil -A -n "certificateName" -t "u,," -a -i certFile \
             -d ServerRoot/alias -P slapd-serverID-

    여기서 certificateName은 인증서를 식별하기 위한 이름이고, certFile은 PEM 형식으로 PKCS #11 인증서에 포함된 텍스트 파일입니다. -t "u,," 옵션은 이 인증서가 SSL 통신용 서버 인증서임을 나타냅니다.

  2. 선택 사항으로, 아래의 certutil 명령을 실행하여 설치된 인증서를 확인할 수도 있습니다.

    3. certutil -L -d ServerRoot/alias -P slapd-serverID-

    u,, 트러스트 속성을 사용하면 서버 인증서가 열거됩니다.

인증 기관 트러스트

Directory Server에서 인증 기관을 트러스트하도록 구성하려면 인증서를 얻어 서버의 인증서 데이터베이스에 설치해야 합니다. 이 프로세스는 사용하는 인증 기관에 따라 달라집니다. 인증서를 자동으로 다운로드할 수 있는 웹 사이트를 제공하는 민간 CA도 있고, 요청 시 전자 메일로 인증서를 보내주는 CA도 있습니다.

콘솔 사용

CA 인증서가 있으면 인증서 설치 마법사를 사용하여 Directory Server에서 인증 기관을 트러스트하도록 구성할 수 있습니다.

  1. Directory Server 콘솔의 최상위 태스크 탭에서 인증서 관리 버튼을 누릅니다. 또는 태스크 탭을 표시하고 콘솔 > 보안 메뉴에서 인증서 관리 항목을 선택합니다.

    2. 인증서 관리 창이 표시됩니다.

  2. CA 인증서 탭을 선택하고 설치를 누릅니다.

    3. 인증서 설치 마법사가 표시됩니다.

  3. CA 인증서를 파일에 저장한 경우 제공된 필드에 파일 경로를 입력합니다. 전자 메일을 통해 CA 인증서를 받은 경우 헤더를 포함한 인증서 전체를 복사하여 제공된 텍스트 필드에 붙여넣습니다. 다음을 누릅니다.
  4. 표시된 인증서 정보가 인증 기관에 맞는지 확인하고 다음을 누릅니다.
  5. 인증서 이름을 지정하고 다음을 누릅니다.
  6. 이 CA를 트러스트하는 목적을 선택합니다. 다음 중 하나 또는 둘 모두를 선택할 수 있습니다.

    7. 클라이언트의 연결 허용(클라이언트 인증). LDAP 클라이언트가 이 CA에서 발급한 인증서를 제공하여 인증서 기반의 클라이언트 인증을 수행하는 경우 이 확인란을 선택합니다.

    다른 서버에 연결(서버 인증). 서버가 이 CA에서 발급한 인증서가 있는 다른 서버에 대해 SSL을 통한 복제 공급자 또는 연결 멀티플렉서 역할을 할 경우 이 확인란을 선택합니다.

  7. 완료를 눌러 마법사를 닫습니다.

명령줄 사용

  1. 아래 명령을 실행하여 트러스트할 수 있는 CA 인증서를 설치할 수도 있습니다.

    2. certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile \
             -d ServerRoot/alias -P slapd-serverID-

    여기서 CAcertificateName은 트러스트할 수 있는 CA를 식별하기 위해 사용자가 지정한 이름이고 certFile은 PEM 인코딩된 텍스트 형식의 PKCS #11 CA 인증서가 포함된 텍스트 파일이며, trust는 다음 코드 중 하나입니다.

    • T - 이 CA는 클라이언트 인증서를 발급하도록 트러스트되었습니다. LDAP 클라이언트가 이 CA에서 발급한 인증서를 제공하여 인증서 기반의 클라이언트 인증을 수행하는 경우 이 코드를 사용합니다.
    • C - 이 CA는 서버 인증서를 발급하도록 트러스트되었습니다. 서버가 이 CA에서 발급한 인증서가 있는 다른 서버에 대해 SSL을 통한 복제 공급자 또는 연결 멀티플렉서 역할을 할 경우 이 코드를 사용합니다.
    • CT - 이 CA는 클라이언트 인증서와 서버 인증서를 모두 발급하도록 트러스트되었습니다. 위의 두 경우가 모두 적용되면 이 코드를 사용합니다.
  2. 선택 사항으로, 아래의 certutil 명령을 실행하여 설치된 인증서를 확인할 수도 있습니다.

    3. certutil -L -d ServerRoot/alias -P slapd-serverID

    u,, 트러스트 속성을 사용하면 서버 인증서가 열거되고 CT,, 속성을 사용하면 트러스트할 수 있는 CA 인증서가 열거됩니다.

SSL 활성화

서버 인증서 설치와 CA 인증서 트러스트가 완료되면 SSL을 활성화할 수 있습니다. 대체로 SSL을 사용하여 서버를 실행하는 것이 좋습니다. 일시적으로 SSL을 비활성화한 경우 기밀성, 인증 또는 데이터 무결성이 필요한 작업을 처리하기 전에 SSL을 다시 활성화해야 합니다.

SSL을 활성화하려면 먼저 서버 인증서 얻기 및 설치에 설명된 것처럼 인증서 데이터베이스를 작성하고 서버 인증서를 얻어서 설치한 후에 CA 인증서를 트러스트해야 합니다.

그런 다음, 아래 절차에 따라 디렉토리 서버에서 SSL 통신을 활성화하고 암호화 기법을 사용합니다.

  1. Directory Server 콘솔의 최상위 구성 탭에서 이 서버 이름이 포함된 루트 노드를 선택한 다음 오른쪽 창에서 암호화 탭을 선택합니다.

    2. 현재의 서버 암호화 설정이 탭에 표시됩니다.

  2. 이 서버에 SSL 사용 확인란을 선택하여 암호화를 사용하도록 지정합니다.
  3. 사용할 암호 패밀리 확인란을 선택합니다.
  4. 드롭다운 메뉴에서 사용할 인증서를 선택합니다.
  5. 암호 설정을 눌러 암호 기본 설정 대화 상자에서 사용할 암호를 선택합니다. 특정 암호에 대한 자세한 내용은 암호화 암호 선택을 참조하십시오.
  6. 클라이언트 인증에 대한 기본 설정을 설정합니다.

    7. 클라이언트 인증 허용 안 함. 이 옵션을 사용하면 서버는 클라이언트의 인증서를 무시하고 해당 인증서에 기반한 인증을 거부합니다.

    클라이언트 인증 허용. 이 옵션이 기본 설정입니다. 이 옵션을 사용하면 클라이언트 요청에 대한 인증이 수행됩니다. 인증서 기반의 인증에 대한 자세한 내용은 클라이언트 인증 구성을 참조하십시오.

    주

    복제 시 인증서 기반의 인증을 사용하는 경우 소비자 서버에서 클라이언트 인증을 허용하거나 필요로 하도록 구성해야 합니다.

    클라이언트 인증 필요. 이 옵션을 사용하면 클라이언트가 서버의 인증 요청에 응답하지 않을 경우 클라이언트 연결이 거부됩니다.

    주

    서버 콘솔이 SSL을 통해 Directory Server에 연결하는 경우 "클라이언트 인증 필요"를 선택하면 클라이언트 인증에 사용할 인증서가 서버 콘솔에 없기 때문에 통신이 비활성화됩니다. 명령줄에서 이 속성을 수정하려면 클라이언트 인증 허용을 참조하십시오.

  7. 선택 사항으로, 콘솔이 SSL을 통해 Directory Server와 통신하도록 설정하려면 "서버 콘솔에 SSL 사용"을 선택합니다.
  8. 작업이 끝나면 저장을 누릅니다.
  9. 선택 사항으로, 서버에서 LDAP 및 DSML-over-HTTP 프로토콜 모두의 SSL 통신에 사용할 보안 포트를 설정합니다. 자세한 내용은 Directory Server의 포트 번호 변경을 참조하십시오.

    10. 보안 포트에 대한 모든 연결은 SSL을 사용해야 합니다. SSL을 활성화하면 보안 포트 구성 여부에 관계 없이 클라이언트에서 Start TLS 작업을 사용하여 비보안 포트를 통한 SSL 암호화를 수행할 수 있습니다.

  10. Directory Server를 다시 시작합니다.

    11. 자세한 내용은 SSL을 활성화하여 서버 시작을 참조하십시오.

암호화 암호 선택

암호는 데이터를 암호화하고 암호를 해독하는 데 사용하는 알고리즘입니다. 일반적으로 암호는 암호화 중에 사용하는 비트 수가 많을수록 더 강력하거나 안전합니다. SSL 암호는 사용된 메시지 인증 유형으로도 식별할 수 있습니다. 메시지 인증은 데이터 무결성을 보장하는 체크섬을 계산하는 별개의 알고리즘입니다. 암호 알고리즘 및 각 장점에 대한 자세한 내용은 Administration Server Administration Guide의 Appendix B, "Ciphers Used With SSL"을 참조하십시오.

클라이언트가 서버와의 SSL 연결을 시작하려면 클라이언트 및 서버가 정보 암호화에 사용할 암호에 동의해야 합니다. 양방향 암호화 프로세스의 경우 클라이언트와 서버 모두 지원되는 가장 강력한 암호를 동일하게 사용해야 합니다.

Directory Server는 다음과 같은 SSL 3.0 및 TLS용 암호를 제공합니다.

표 11-1 Directory Server에서 제공하는 암호 

암호 이름

설명

None

암호화 없음. MD5 메시지 인증만 사용(rsa_null_md5)

RC4(128비트)

128비트 암호화 및 MD5 메시지 인증을 사용하는 RC4 암호(rsa_rc4_128_md5)

RC4(Export)

40비트 암호화 및 MD5 메시지 인증을 사용하는 RC4 암호(rsa_rc4_40_md5)

RC2(Export)

40비트 암호화 및 MD5 메시지 인증을 사용하는 RC2 암호(rsa_rc2_40_md5)

DES 또는 Export DES

56비트 암호화 및 SHA 메시지 인증을 사용하는 DES(rsa_des_sha)

DES(FIPS)

56비트 암호화 및 SHA 메시지 인증을 사용하는 FIPS DES. 이 암호는 암호화 모듈 구현을 위한 미국 정부 표준인 FIPS 140-1(rsa_fips_des_sha)을 준수합니다.

Triple-DES

168비트 암호화 및 SHA 메시지 인증을 사용하는 Triple DES(rsa_3des_sha)

Triple-DES(FIPS)

168비트 암호화 및 SHA 메시지 인증을 사용하는 FIPS Triple DES. 이 암호는 암호화 모듈 구현을 위한 미국 정부 표준인 FIPS 140-1(rsa_fips_3des_sha)을 준수합니다.

Fortezza

80비트 암호화 및 SHA 메시지 인증을 사용하는 Fortezza 암호

RC4(Export)

128비트 암호화 및 SHA 메시지 인증을 사용하는 Fortezza RC4 암호

없음(Fortezza)

암호화 없음, Fortezza SHA 메시지 인증만 사용

서버 콘솔에서 계속 SSL을 사용하려면 최소한 다음 암호 중 하나를 선택해야 합니다.

서버에서 사용할 암호를 선택하려면 아래 절차에 따라 수행합니다.

  1. Directory Server 콘솔의 최상위 구성 탭에서 이 서버 이름이 포함된 루트 노드를 선택한 다음 오른쪽 창에서 암호화 탭을 선택합니다.

    2. 현재의 서버 암호화 설정이 탭에 표시됩니다. SSL 활성화에 설명된 것처럼 서버에서 SSL을 활성화해야 합니다.

  2. 암호 설정을 누릅니다.

    3. 암호 기본 설정 대화 상자가 표시됩니다.

  3. 암호 기본 설정 대화 상자에서 이름 옆에 있는 확인란을 선택하거나 선택 취소하여 서버에서 사용할 암호를 지정합니다.

    4. 보안상 특정 암호를 사용하지 않는 경우가 아니면 None, MD5를 제외한 모든 암호를 선택해야 합니다.

    주의   

    암호화 없음, MD5 메시지 인증만 사용 암호 옵션은 선택하지 마십시오. 서버는 클라이언트에서 다른 암호를 사용할 수 없을 때 이 옵션을 사용합니다. 이 경우 암호화가 사용되지 않으므로 연결이 안전하지 않습니다.

  4. 암호 기본 설정 대화 상자에서 확인을 누른 다음 암호화 탭에서 저장을 누릅니다.

클라이언트 인증 허용

Directory Server에 클라이언트 인증이 필요하고 서버 콘솔이 SSL을 사용하여 연결하도록 구성한 경우에는 더 이상 서버 콘솔을 사용하여 Sun Java System 서버를 관리할 수 없습니다. 이 경우 해당 명령줄 유틸리티를 사용해야 합니다.

서버 콘솔을 사용할 수 있도록 디렉토리 구성을 변경하려면 다음 단계에 따라 클라이언트 인증을 필수가 아닌 선택 사항으로 설정해야 합니다.

  1. 아래 명령을 실행하여 cn=encryption,cn=config 항목을 수정합니다.

    2. ldapmodify -h host -p port -D "cn=Directory Manager" -w password
    dn: cn=encryption,cn=config
    changetype: modify
    replace: nsSSLClientAuth
    nsSSLClientAuth: allowed
    ^D

  2. 명령줄에서 서버 시작 및 중지에 설명된 것처럼 Directory Server를 다시 시작합니다.

    3. 이제 서버 콘솔을 시작할 수 있습니다.

클라이언트 인증 구성

클라이언트 인증은 서버에서 클라이언트 아이디를 확인하는 기법입니다. 클라이언트가 제공한 인증서를 사용하거나 DIGEST-MD5 같은 SASL 기반의 기법을 통해 클라이언트 인증을 간단하게(DN과 비밀번호를 제공하여) 수행할 수 있습니다. Solaris 운영 체제의 경우 Directory Server에서 SASL을 통한 GSSAPI 기법을 지원하므로 커버로스 V5를 통해 클라이언트 인증을 허용할 수 있습니다.

인증서 기반의 인증 시에는 SSL 프로토콜을 통해 얻은 클라이언트 인증서를 사용하여 식별할 사용자 항목을 찾습니다. 이 기법은 낮은 계층이 이미 설정되어 있는 인증 기법에 의존하기 때문에 EXTERNAL이라고도 합니다.(차후 릴리스에서는 외부 인증을 IP 보안 프로토콜(ipsec)과 함께 사용할 수 있습니다.)

인증서 기반의 인증에 대해서는 Administration Server Administration Guide의 9장, "Using Client Authentication"에서 자세히 설명합니다.

다음 절에서는 Directory Server에 두 개의 SASL 기법을 구성하는 방법에 대해 설명합니다. LDAP 클라이언트에서 보안을 사용하도록 구성을 참조하십시오.

DIGEST-MD5를 통한 SASL 인증

DIGEST-MD5 기법은 클라이언트에서 보낸 해시 값을 사용자 비밀번호의 해시와 비교하여 클라이언트를 인증합니다. 하지만 이 기법은 사용자 비밀번호를 읽어야 하기 때문에 DIGEST-MD5를 통해 인증을 받으려는 사용자는 디렉토리에 {CLEAR} 비밀번호가 있어야 합니다. 디렉토리에 {CLEAR} 비밀번호를 저장하는 경우 6장, "액세스 제어 관리"에서 설명하는 것처럼, 비밀번호에 대한 액세스가 ACI를 통해 적절하게 제한되도록 해야 합니다. 속성 값 암호화에서 설명하는 것처럼 해당 접미어에 속성 암호화를 구성하여 {CLEAR} 비밀번호에 대한 보호를 더 강화할 수 있습니다.

DIGEST-MD5 기법 구성

아래 절차에서는 Directory Server에서 DIGEST-MD5를 사용하도록 구성하는 방법에 대해 설명합니다.

  1. 콘솔이나 ldapsearch 명령을 사용하여 DIGEST-MD5가 루트 항목의 supportedSASLMechanisms 속성 값인지 확인합니다. 예를 들어 아래 명령은 현재 활성화되어 있는 SASL 기법을 보여줍니다.

    2. ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
    -s base -b "" "(objectclass=*)" supportedSASLMechanisms

    dn:
    supportedSASLMechanisms: EXTERNAL
    supportedSASLMechanisms: DIGEST-MD5
    supportedSASLMechanisms: GSSAPI
    ^D

  2. DIGEST-MD5가 활성화되어 있지 않으면 아래의 ldapmodify 명령을 사용하여 활성화합니다.

    3. ldapmodify -h host -p port -D "cn=Directory Manager" -w password
    dn: cn=SASL, cn=security, cn=config
    changetype: modify
    add: dsSaslPluginsEnable
    dsSaslPluginsEnable: DIGEST-MD5
    -
    replace: dsSaslPluginsPath
    dsSaslPluginsPath: ServerRoot/lib/sasl
    ^D

  3. DIGEST-MD5 아이디 매핑에 설명된 것처럼 DIGEST-MD5에 기본 아이디 매핑을 사용하거나 새로운 아이디 매핑을 작성합니다.
  4. DIGEST-MD5를 사용하여 SSL을 통해 서버에 액세스하는 모든 사용자의 비밀번호가 {CLEAR}에 저장되어 있는지 확인합니다. 비밀번호 저장 체계를 구성하는 방법은 7장, "사용자 계정 및 비밀번호 관리"를 참조하십시오.

    5. 주의

    		 

  5. SASL 구성 항목이나 DIGEST-MD5 아이디 매핑 항목 중 하나를 수정한 경우 디렉토리 서버를 다시 시작합니다.

DIGEST-MD5 아이디 매핑

SASL 기법의 아이디 매핑은 SASL 아이디의 자격 증명을 디렉토리에 있는 사용자 항목과 일치시킵니다. 이 기법에 대한 자세한 내용은 아이디 매핑을 참조하십시오. 매핑 중에 SASL 아이디에 해당하는 DN을 찾을 수 없으면 인증은 실패합니다.

SASL 아이디는 각 기법의 고유 형식으로 사용자를 나타내는 사용자 문자열입니다. DIGEST-MD5의 경우 클라이언트가 dn: 접두어와 LDAP DN이 포함된 사용자나 클라이언트에서 지정한 텍스트가 u: 접두어 뒤에 오는 사용자를 작성하는 것이 좋습니다. 클라이언트가 보낸 사용자는 매핑 중에 ${Principal} 자리 표시자에서 사용할 수 있습니다.

DIGEST-MD5의 기본 아이디 매핑은 서버 구성의 아래 항목에서 지정합니다.

dn: cn=default,cn=DIGEST-MD5,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: ${Principal}
dsMatching-regexp: dn:(.*)
dsMappedDN: $1

이 아이디 매핑에서는 사용자 dn 필드에 기존 디렉토리 사용자의 DN이 포함되어 있다고 가정합니다.

DIGEST-MD5에 대한 사용자 정의 아이디 매핑을 정의하려면 다음을 수행합니다.

  1. 기본 매핑 항목을 편집하거나 cn=DIGEST-MD5,cn=identity mapping,cn=config에 새 매핑 항목을 작성합니다. 아이디 매핑 항목의 속성 정의에 대해서는 아이디 매핑을 참조하십시오. DIGEST-MD5 매핑 예는 아래 파일에 포함되어 있습니다.

    2. ServerRoot/slapd-serverID/ldif/identityMapping_Examples.ldif

    이 예에서는 정식 이름이 아닌 "사용자" 텍스트 필드에 원하는 아이디의 사용자 이름이 포함되어 있다고 가정합니다. 아래 명령은 이 매핑이 어떻게 정의되는지 보여줍니다.

    ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
    dn: cn=unqualified-username,cn=DIGEST-MD5,cn=identity mapping,
     cn=config
    objectclass: dsIdentityMapping
    objectclass: dsPatternMatching
    objectclass: nsContainer
    objectclass: top
    cn: unqualified-username
    dsMatching-pattern: ${Principal}
    dsMatching-regexp: u:(.*)@(.*)\.com
    dsSearchBaseDN: dc=$2
    dsSearchFilter: (uid=$1)

  2. Directory Server를 다시 시작하여 새 매핑을 적용합니다.

GSSAPI를 통한 SASL 인증(Solaris에만 해당)

SASL을 통한 GSSAPI(Generic Security Services API)를 사용하면 커버로스 V5와 같은 타사 보안 시스템을 통해 클라이언트를 인증할 수 있습니다. GSSAPI 라이브러리는 Solaris 플랫폼에서만 사용할 수 있습니다. SEAM(Sun Enterprise Authentication Mechanism) 1.0.1 서버에 커버로스 V5 구현을 설치하는 것이 좋습니다.

서버는 이 API를 사용하여 사용자 아이디를 검증합니다. 그런 후에 SASL 기법에서 GSSAPI 매핑 규칙을 적용하여 이 연결이 유지되는 동안 모든 작업의 바인드 DN으로 지정될 DN을 얻습니다.

커버로스 시스템 구성

제조업체의 지침에 따라 커버로스 소프트웨어를 구성합니다. SEAM 1.0.1 서버를 사용하는 경우 아래 단계도 수행해야 합니다.

  1. /etc/krb5에 있는 파일을 구성합니다.
  2. 사용자와 서비스를 저장할 커버로스 데이터베이스를 작성한 다음, 여기에 LDAP 서비스 사용자를 작성합니다. LDAP 서비스 사용자는 다음과 같습니다.

    3. ldap/serverFQDN@REALM

    여기서 serverFQDN은 서버의 정규화된 도메인 이름입니다.

  3. LDAP 서비스 키 등의 서비스 키를 저장할 키 탭을 작성합니다.
  4. 커버로스 데몬 프로세스를 시작합니다.

자세한 단계별 지침은 소프트웨어 설명서를 참조하십시오.

GSSAPI 기법 구성

아래 절차에서는 Solaris 플랫폼의 Directory Server에서 GSSAPI를 사용하도록 구성하는 방법에 대해 설명합니다.

  1. 콘솔이나 ldapsearch 명령을 사용하여 GSSAPI가 루트 항목의 supportedSASLMechanisms 속성 값인지 확인합니다. 예를 들어 아래 명령은 현재 활성화되어 있는 SASL 기법을 보여줍니다.

    2. ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
    -s base -b "" "(objectclass=*)" supportedSASLMechanisms

    dn:
    supportedSASLMechanisms: EXTERNAL
    supportedSASLMechanisms: DIGEST-MD5

  2. 기본적으로 GSSAPI는 사용되지 않으므로 아래의 ldapmodify 명령을 사용하여 활성화할 수 있습니다.

    3. ldapmodify -h host -p port -D "cn=Directory Manager" -w password
    dn: cn=SASL, cn=security, cn=config
    changetype: modify
    add: dsSaslPluginsEnable
    dsSaslPluginsEnable: GSSAPI
    -
    replace: dsSaslPluginsPath
    dsSaslPluginsPath: ServerRoot/lib/sasl

  3. GSSAPI 아이디 매핑에 설명된 것처럼 GSSAPI에 대한 기본 아이디 매핑과 사용자 정의 매핑을 작성합니다.
  4. 호스트 시스템에서 서버 커버로스를 구성합니다.
    1. 세션 키를 사용하여 커버로스에 LDAP 서비스 사용자 ldap/serverHostname@Realm을 작성합니다. 여기서,
    2. serverHostname은 서버 호스트 시스템의 정규화된 도메인 이름입니다. 이 값은 반드시 소문자여야 한다는 점만 제외하고 cn=config의 nsslapd-localhost 속성 값과 반드시 동일해야 합니다.
    3. Realm은 서버의 커버로스 영역입니다.
    4. LDAP 서비스에는 /etc/krbs/krb5.keytab 파일의 키 데이터베이스에 대한 읽기 액세스 권한이 있어야 합니다.
    5. DNS는 호스트 시스템에 구성해야 합니다.
  5. SASL 구성 항목이나 GSSAPI 아이디 매핑 항목 중 하나를 수정한 경우 디렉토리 서버를 다시 시작합니다.

GSSAPI 아이디 매핑

SASL 기법의 아이디 매핑은 SASL 아이디의 자격 증명을 디렉토리에 있는 사용자 항목과 일치시킵니다. 이 기법에 대한 자세한 내용은 아이디 매핑을 참조하십시오. 매핑 중에 SASL 아이디에 해당하는 DN을 찾을 수 없으면 인증은 실패합니다.

SASL 아이디는 각 기법의 고유 형식으로 사용자를 나타내는 사용자 문자열입니다. GSSAPI를 사용하는 커버로스에서 사용자는 uid[/instance][@realm] 형식의 아이디로 나타납니다. 여기서 uid에는 instance 식별자가 선택 사항으로 포함될 수 있으며 이 식별자 뒤에 선택 사항인 realm이 옵니다. realm에는 일반적으로 도메인 이름이 포함됩니다. 예를 들어, 다음은 모두 유효한 사용자입니다.

bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM

처음에는 디렉토리에 GSSAPI 매핑이 정의되어 있지 않습니다. 클라이언트에서 사용자를 정의하는 방법에 따라 기본 매핑 및 필요한 사용자 정의 매핑을 모두 정의해야 합니다.

GSSAPI에 대한 아이디 매핑을 정의하려면 다음을 수행합니다.

  1. cn=GSSAPI,cn=identity mapping, cn=config에 새 매핑 항목을 작성합니다. 아이디 매핑 항목의 속성 정의에 대해서는 아이디 매핑을 참조하십시오.

    2. GSSAPI 매핑 예는 아래 파일에 포함되어 있습니다.

    ServerRoot/slapd-serverID/ldif/identityMapping_Examples.ldif

    이 파일에 제공된 기본 GSSAPI 매핑에서는 사용자에 사용자 아이디만 포함되어 있으며, 이 아이디로 디렉토리의 고정 분기에 있는 사용자를 결정한다고 가정합니다.

    dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
    objectclass: dsIdentityMapping
    objectclass: nsContainer
    objectclass: top
    cn: default
    dsMappedDN: uid=${Principal},ou=people,dc=example,dc=com

    이 파일의 다른 예에서는 알려진 영역이 지정된 사용자에 포함할 사용자 아이디를 결정하는 방법을 보여줍니다.

    dn: cn=same_realm,cn=GSSAPI,cn=identity mapping,cn=config
    objectclass: dsIdentityMapping
    objectclass: dsPatternMatching
    objectclass: nsContainer
    objectclass: top
    cn: same_realm
    dsMatching-pattern: ${Principal}
    dsMatching-regexp: (.*)@example.com
    dsMappedDN: uid=$1,ou=people,dc=example,dc=com

  2. Directory Server를 다시 시작하여 새로운 매핑을 적용합니다.

아이디 매핑

Directory Server에는 다른 프로토콜의 자격 증명을 디렉토리의 DN으로 매핑해야 하는 여러 가지 인증 매커니즘이 있습니다. DSML-over-HTTP 프로토콜과 DIGEST-MD5 및 GSSAPI SASL 기법도 이러한 경우에 해당합니다. 각 기법에서는 아이디 매핑을 사용하여 클라이언트가 제공한 프로토콜별 자격 증명에 따라 바인드 DN을 결정합니다.

아이디 매핑 중에는 cn=identity mapping, cn=config 구성 분기의 항목이 사용됩니다. 이 분기에는 아이디 매핑을 수행해야 하는 각 프로토콜의 컨테이너가 포함되어 있습니다.

매핑 항목은 디렉토리 검색에서 사용하기 위해 프로토콜별 자격 인증 요소를 추출하는 방법을 정의합니다. 검색 결과 한 개의 사용자 항목이 반환되면 매핑이 성공한 것이며, 연결이 유지되는 동안 이 항목을 모든 작업의 바인드 DN으로 사용합니다. 검색 결과 0 또는 두 개 이상의 항목이 반환되면 매핑이 실패하고 다른 매핑이 적용됩니다.

각 분기마다 해당 프로토콜의 기본 매핑과 사용자 정의 매핑이 포함되어야 합니다. 기본 매핑에는 cn=default RDN이 있고, 사용자 정의 매핑에는 이름 지정 속성으로 cn을 사용하는 다른 RDN이 있을 수 있습니다. 사용자 정의 매핑 중 하나가 성공할 때까지 모든 사용자 정의 매핑이 비결정적 순서로 먼저 평가됩니다. 모든 사용자 정의 매핑이 실패하면 마지막으로 기본 매핑이 적용됩니다. 기본 매핑도 실패하면 클라이언트 인증은 실패합니다.

매핑 항목에는 top, Container 및 dsIdentityMapping 객체 클래스가 있어야 하며, 이 경우 항목에는 다음과 같은 속성이 포함될 수 있습니다.

또한 매핑 항목에는 dsPatternMatching 객체 클래스가 포함되어 다음과 같은 속성의 사용을 허용할 수도 있습니다.

dsSearchScope를 제외한 위의 모든 속성 값에는 ${keyword} 형식의 자리 표시자가 포함될 수 있습니다. 여기서 keyword는 프로토콜별 자격 증명에 있는 요소 이름입니다. 매핑 중에 자리 표시자는 클라이언트가 제공한 요소의 실제 값으로 대체됩니다.

모든 자리 표시자가 대체된 후에 정의된 패턴 일치가 수행됩니다. 일치하는 패턴은 정규 표현식과 비교됩니다. 정규 표현식이 패턴 문자열과 일치하지 않으면 이 매핑은 실패합니다. 일치하면 괄호 안에 있는 정규 표현식 조건에 일치하는 값을 번호가 매겨진 다른 속성 값의 자리 표시자로 사용할 수 있습니다. 예를 들어, SASL에 아래 매핑을 정의할 수 있습니다.

dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@(.*)\.(.*)
dsMappedDN: uid=$1,ou=people,dc=$2,dc=$3

클라이언트가 bjensen@example.com 사용자로 인증하면 이 매핑은 uid=bjensen,ou=people,dc=example,dc=com 바인드 DN을 정의합니다. 디렉토리에 이 DN이 있으면 매핑이 성공하여 클라이언트 인증이 이루어지고, 연결이 유지되는 동안 수행된 모든 작업은 이 바인드 DN을 사용합니다.

dsMatching-pattern은 Posix regexec(3C) 및 regcomp(3C) 함수 호출을 사용하여 dsMatching-regexp와 비교됩니다. Directory Server는 확장된 정규 표현식을 사용하며, 비교 시 대소문자를 구분하지 않습니다. 자세한 내용은 이러한 함수에 대한 설명서 페이지를 참조하십시오.

자리 표시자를 포함할 수 있는 속성 값에서 자리 표시자로 사용되지 않은 $, { 및 } 문자는 다른 자리 표시자를 사용하지 않아도 반드시 인코딩해야 합니다. 즉, $ 는  \24, { 는  \7B, } 는  \7D로 인코딩해야 합니다.

자리 표시자와 대체를 사용하면 프로토콜별 자격 증명에서 사용자 이름과 다른 값을 추출하는 매핑을 작성하고 이 값을 사용하여 매핑된 DN을 정의하거나 디렉토리에서 해당 DN을 검색할 수 있습니다. 디렉토리 클라이언트가 제공한 예상 자격 증명을 추출하는 매핑을 정의하고 특정 디렉토리 구조에 이를 매핑해야 합니다.

주의   

제대로 정의되지 않은 매핑을 작성하면 보안에 허점이 생길 수 있습니다. 예를 들어, 패턴 일치를 수행하지 않고 하드 코딩된 DN에 매핑하면 항상 매핑이 성공하기 때문에 디렉토리 사용자가 아닌 클라이언트를 인증할 수도 있습니다.

지나치게 광범위하고 허용 범위가 넓은 한 개의 매핑을 작성하는 것보다 다양한 클라이언트 자격 증명 형식을 처리하는 여러 개의 매핑을 정의하는 것이 더 안전합니다. 항상 클라이언트 자격 증명에 따라 클라이언트 연결을 특정 사용자에게 매핑해야 합니다.

LDAP 클라이언트에서 보안을 사용하도록 구성

다음 절에서는 디렉토리 서버와 보안 연결을 구성하려는 LDAP 클라이언트에서 SSL을 구성 및 사용하는 방법에 대해 설명합니다. SSL 연결에서 서버는 해당 인증서를 클라이언트로 보냅니다. 클라이언트는 먼저 인증서를 트러스트하여 서버를 인증해야 합니다. 그런 후에 클라이언트는 두 SASL 기법(DIGEST-MD5 또는 커버로스 V5를 사용하는 GSSAPI) 중 하나에 대한 정보나 자신의 인증서를 보내 클라이언트 인증 기법 중 하나를 선택적으로 시작할 수 있습니다.

다음 절에서는 SSL을 사용하는 LDAP 클라이언트의 예로 ldapsearch 도구를 사용합니다. 디렉토리 서버와 함께 제공된 ldapmodify, ldapdelete 및 ldapcompare 도구는 모두 동일한 방법으로 구성됩니다. 이러한 디렉토리 액세스 도구는 Directory SDK for C에 기반을 두고 있으며, Directory Server Resource Kit Tools Reference에서 자세히 설명합니다.

다른 LDAP 클라이언트에서 SSL 연결을 구성하려면 응용 프로그램과 함께 제공된 설명서를 참조하십시오.

주

일부 클라이언트 응용 프로그램은 SSL만 구현하고 서버에 트러스트할 수 있는 인증서가 있는지 확인하지 않으므로 SSL 프로토콜을 사용하여 데이터 암호화는 제공하지만 기밀성이나 사칭에 대한 보호는 보장할 수 없습니다.

클라이언트에 서버 인증 구성

클라이언트는 서버와 SSL 연결을 구성할 때 서버에서 제공한 인증서를 트러스트해야 합니다. 이렇게 하려면 클라이언트는 다음과 같은 작업을 수행해야 합니다.

Mozilla는 SSL을 사용하여 HTTP 프로토콜을 통해 웹 서버와 통신하는 클라이언트 응용 프로그램입니다. Mozilla를 사용하여 LDAP 클라이언트에서도 사용할 인증서를 관리할 수 있습니다. 또는 certutil 도구를 사용하여 인증서 데이터베이스를 관리할 수 있습니다.

Mozilla를 통한 클라이언트 인증서 관리

아래 절차에서는 Mozilla를 사용하여 클라이언트 시스템에서 인증서 데이터베이스를 관리하는 방법에 대해 설명합니다.

  1. Mozilla는 시작과 동시에 인증서 데이터베이스가 있는지 확인하며, 필요한 경우 새 인증서 데이터베이스를 작성합니다. 인증서 데이터베이스는 예를 들어 .mozilla/username/string.slt/cert8.db와 같이 다른 Mozilla 기본 설정과 함께 파일에 저장됩니다.

    2. 이 절차를 사용할 경우 Mozilla에서 작성된 인증서 데이터베이스를 찾아 클라이언트 응용 프로그램에 사용할 경로를 기억해 둡니다.

  2. Mozilla를 사용하여 액세스할 디렉토리 서버 인증서를 발급한 인증 기관의 웹 사이트를 탐색합니다. Mozilla에서 인증 기관의 인증서를 자동으로 검색하며, 트러스트 여부를 묻는 메시지를 표시합니다.

    3. 예를 들어, 내부용으로 배포된 Sun Java System Certificate Server를 사용하는 경우 https://hostname:444 형식의 URL을 방문합니다.

  3. 인증서를 트러스트하라는 메시지가 Mozilla에 표시되면 인증 기관의 인증서를 트러스트합니다. 서버 인증을 위해 CA 인증서를 트러스트해야 합니다.

    4. CA 웹 사이트에 따라 이 단계를 수행할 수 없는 경우도 있습니다. CA 인증서를 트러스트하라는 메시지가 Mozilla에 자동으로 표시되지 않으면 아래 절차를 수행하여 인증서를 수동으로 트러스트합니다.

명령줄을 통한 클라이언트 인증서 관리

명령줄을 통해 인증서를 관리하려면 certutil 도구를 사용합니다. 이 도구는 SUNWtlsu 패키지에 포함되어 있습니다.

  1. 아래 명령을 실행하여 클라이언트 호스트 시스템에 인증서 데이터베이스를 작성합니다.

    2. certutil -N -d path -P prefix

    이 도구는 인증서를 보호하는 비밀번호를 입력하라는 메시지를 사용자에게 표시한 다음 path/prefixcert8.db 및 path/prefixkey3.db 파일을 생성합니다.

    LDAP 클라이언트 응용 프로그램 사용자는 자신들만 액세스할 수 있는 위치(예: 홈 디렉토리의 보호된 하위 디렉토리)에 개별적으로 인증서 데이터베이스를 작성해야 합니다.

  2. 액세스하려는 Directory Server의 인증서를 발급한 인증 기관에 연락하여 CA 인증서를 요청합니다. 전자 메일을 보내거나 해당 웹 사이트에 액세스하여 PEM 인코딩된 텍스트 버전 형식의 PKCS #11 인증서를 얻을 수 있습니다. 이 인증서를 파일에 저장합니다.

    3. 예를 들어, 내부용으로 배포된 Sun Java System Certificate Server를 사용하는 경우 https://hostname:444 형식의 URL을 방문합니다. 최상위 검색 탭에서 CA 인증서 체인 가져오기를 선택하고 인코딩된 인증서를 복사합니다.

    또는, 동일한 CA에서 클라이언트 인증서와 서버 인증서를 얻는 경우 인증 기관 트러스트 절차를 통해 얻은 CA 인증서를 다시 사용할 수도 있습니다.

  3. SSL 연결에 사용할 서버 인증서를 발급하기 위해 CA 인증서를 트러스트할 수 있는 CA로 가져옵니다. 아래 명령을 실행합니다.

    4. certutil -A -n "certificateName" -t "C,," -a -i certFile -d path -P prefix

    여기서 certificateName은 이 인증서를 식별하기 위해 사용자가 지정한 이름이고 certFile은 PEM 인코딩된 텍스트 형식의 PKCS #11 CA 인증서가 있는 텍스트 파일이며, path와 prefix는 단계 1과 같습니다.

    LDAP 클라이언트 응용 프로그램의 모든 사용자는 CA 인증서를 자신의 인증서 데이터베이스로 가져와야 하며 모든 사용자가 certFile에 있는 동일한 인증서를 가져올 수 있습니다.

서버 인증에 대한 SSL 옵션 지정

ldapsearch 도구를 사용하여 SSL에서 서버 인증을 수행하려면 사용자는 인증서 데이터베이스 경로만 지정하면 됩니다. 서버는 보안 포트를 통해 SSL 연결을 구성할 때 자체 인증서를 보냅니다. 그런 후에 ldapsearch 도구는 사용자의 인증서 데이터베이스에서 서버 인증서를 발급한 CA의 트러스트할 수 있는 CA 인증서를 찾습니다.

아래 명령은 Mozilla에서 인증서 데이터베이스를 작성한 경우 사용자가 자신의 인증서 데이터베이스를 지정하는 방법을 보여줍니다.

ldapsearch -h host -p securePort \
           -D "uid=bjensen,dc=example,dc=com" -w bindPassword \
           -Z -P .mozilla/bjensen/string.slt/cert8.db \
           -b "dc=example,dc=com" "(givenname=Richard)"

클라이언트에 인증서 기반의 인증 구성

클라이언트 인증의 기본 기법은 인증서를 사용하여 디렉토리 서버에서 사용자를 안전하게 식별하는 것입니다. 인증서 기반의 클라이언트 인증을 수행하려면 다음과 같은 작업을 해야 합니다.

이 절차에서는 certutil 도구를 사용하여 명령줄을 통해 인증서를 관리해야 합니다. 이 도구는 SUNWtlsu 패키지에 포함되어 있습니다.

사용자 인증서 얻기 및 설치

인증서 기반의 인증을 사용하여 디렉토리에 액세스하려는 각 사용자는 클라이언트 인증서를 요청하여 설치해야 합니다. 이 절차에서는 클라이언트에 서버 인증 구성에 설명된 것처럼 사용자가 이미 인증서 데이터베이스를 구성했다고 가정합니다.

  1. 아래 명령을 실행하여 사용자 인증서 요청을 작성합니다.

    2. certutil -R \
    -s "cn=Babs Jensen,ou=Sales,o=example.com,l=city,st=state,c=country"\
    -a -d path -P prefix

    -s 옵션은 요청한 인증서의 DN을 지정합니다. 대체로 인증 기관은 인증서 소유자를 정확하게 식별하기 위해 이 예에 사용된 속성을 모두 필요로 합니다. 단계 9의 인증서 매핑 기법을 통해 인증서 DN이 사용자 디렉토리 DN에 매핑됩니다.

    path 및 prefix가 사용자의 인증서와 키 데이터베이스를 찾습니다. certutil 도구는 사용자에게 키 데이터베이스 비밀번호를 입력하라는 메시지를 표시한 다음 PEM 인코딩된 텍스트 형식으로 PKCS #10 인증서 요청을 생성합니다.

  2. 해당 절차에 따라 인코딩된 인증서 요청을 파일에 저장하여 인증 기관으로 보냅니다. 예를 들어, 전자 메일로 인증서 요청을 보내야 하는 경우도 있고 CA 웹 사이트에서 요청을 입력할 수 있는 경우도 있습니다.
  3. 요청을 보낸 후에는 CA에서 이 요청에 대한 응답으로 인증서를 보내줄 때까지 기다려야 합니다. 요청에 대한 응답 시간은 경우에 따라 달라집니다. 예를 들어, 회사 내부의 CA인 경우 하루나 이틀이면 요청에 대한 응답을 받을 수 있습니다. 회사 외부의 CA를 선택하면 요청에 대한 응답을 받을 때까지 몇 주가 걸릴 수도 있습니다.
  4. CA에서 응답을 보내면 새 인증서의 PEM 인코딩된 텍스트를 다운로드하거나 텍스트 파일에 복사합니다.
  5. 아래 명령을 실행하여 인증서 데이터베이스에 새 사용자 인증서를 설치합니다.

    6. certutil -A -n "certificateName" -t "u,," -a -i certFile -d path -P prefix

    여기서 certificateName은 이 인증서를 식별하기 위해 사용자가 지정한 이름이고 certFile은 PEM 형식의 PKCS #11 CA 인증서가 있는 텍스트 파일이며, path와 prefix는 단계 1과 같습니다.

    또는 Mozilla를 통해 인증서 데이터베이스를 관리하는 경우 CA 웹 사이트에 있는 링크를 사용하여 인증서를 직접 설치할 수도 있습니다. 이 링크를 누른 다음 Mozilla에서 제공하는 대화 상자에 따라 단계별로 수행합니다.

  6. 아래 명령을 실행하여 인증서 이진 복사본을 작성합니다.

    7. certutil -L -n "certificateName" -d path -r > userCert.bin

    여기서 certificateName은 설치할 때 인증서에 지정한 이름이고 path는 인증서 데이터베이스의 위치이며, userCert.bin은 이진 형식의 인증서가 포함될 출력 파일의 이름입니다.

  7. Directory Server에서 클라이언트 인증서를 소유한 사용자의 디렉토리 항목에 userCertificate 속성을 추가합니다.
  1. 필요한 경우 사용자 인증서를 발급한 CA 인증서를 Directory Server에 설치하여 트러스트합니다. 클라이언트 연결을 허용하려면 이 CA를 트러스트해야 합니다. 인증 기관 트러스트를 참조하십시오.
  2. Administration Server Administration Guide의 9장, “Using Client Authentication”에서 설명하는 것처럼 Directory Server에 인증서 기반 인증을 구성합니다. 이 절차에서는 서버가 LDAP 클라이언트를 통해 제공된 사용자 인증서를 해당 사용자 DN에 매핑할 수 있도록 certmap.conf 파일을 편집합니다.

    3. certmap.conf 파일의 verifyCert 매개 변수가 on으로 설정되어 있는지 확인합니다. 이렇게 하면 서버가 사용자 항목에 동일한 인증서가 있는지 확인하여 사용자를 증명합니다.

인증서 기반의 클라이언트 인증에 대한 SSL 옵션 지정

ldapsearch 도구를 사용하여 SSL에서 인증서 기반의 클라이언트 인증을 수행하려는 경우 사용자는 자신의 인증서를 사용하는 여러 가지 명령줄 옵션을 지정해야 합니다. 보안 포트를 통해 SSL 연결을 설정하면 이 도구는 서버 인증서를 인증한 다음 사용자 인증서를 서버로 보냅니다.

아래 명령은 사용자가 Mozilla에서 작성된 자신의 인증서 데이터베이스에 액세스하는 옵션을 지정하는 방법을 보여줍니다.

ldapsearch -h host -p securePort \
           -Z -P .mozilla/bjensen/string.slt/cert8.db \
           -N "certificateName" \
           -K .mozilla/bjensen/string.slt/key3.db -W keyPassword \
           -b "dc=example,dc=com" "(givenname=Richard)"

-Z 옵션은 인증서 기반의 인증을 나타내고 certificateName은 보낼 인증서를 지정하며, -K 및 -W 옵션은 클라이언트 응용 프로그램이 인증서에 액세스하여 보낼 수 있도록 합니다. -D 및 -w 옵션을 지정하지 않으면 인증서 매핑을 통해 바인드 DN이 결정됩니다.

클라이언트에 SASL DIGEST-MD5 사용

클라이언트에 DIGEST-MD5 기법을 사용하는 경우에는 사용자 인증서를 설치할 필요가 없습니다. 하지만 암호화된 SSL 연결을 사용하려면 클라이언트에 서버 인증 구성에 설명된 것처럼 서버 인증서를 트러스트해야 합니다.

영역 지정

영역은 선택한 인증 아이디가 속하는 이름 공간을 정의합니다. DIGEST-MD5 인증에서는 특정 영역에 인증해야 합니다.

Directory Server는 시스템의 정규화된 호스트 이름을 DIGEST-MD5의 기본 영역으로 사용하며, nsslapd-localhost 구성 속성에 있는 호스트 이름의 소문자 값을 사용합니다.

영역을 지정하지 않으면 서버에서 제공하는 기본 영역이 사용됩니다.

환경 변수 지정

UNIX 환경에서 LDAP 도구가 DIGEST-MD5 라이브러리를 찾으려면 SASL_PATH 환경 변수를 설정해야 합니다. DIGEST-MD5 라이브러리는 SASL 플러그 인에 의해 동적으로 로드되는 공유 라이브러리이므로 Korn 쉘의 경우처럼 SASL_PATH 변수를 다음과 같이 설정해야 합니다.

export SASL_PATH=ServerRoot/lib/sasl

이 경로에서는 Directory Server가 LDAP 도구를 실행할 호스트에 설치되어 있다고 가정합니다.

ldapsearch 명령 예

SSL을 사용하지 않고 DIGEST-MD5 클라이언트 인증을 수행할 수 있습니다. 아래 예에서는 기본 DIGEST-MD5 아이디 매핑을 사용하여 바인드 DN을 결정합니다.

ldapsearch -h host -p nonSecurePort -D "" -w bindPassword \
           -o mech=DIGEST-MD5 [-o realm="hostFQDN"] \
           -o authid="dn:uid=bjensen,dc=example,dc=com" \
           -o authzid="dn:uid=bjensen,dc=example,dc=com" \
           -b "dc=example,dc=com" "(givenname=Richard)"

위 예에서는 -o(소문자 o) 옵션을 사용하여 SASL 옵션을 지정합니다. Realm은 선택 사항이지만 지정할 경우 서버 호스트 시스템의 정규화된 도메인 이름을 제공해야 합니다. 프록시 작업용 authzid를 사용하지 않는 경우에도 authid와 authzid는 둘 다 있어야 하며 동일한 값을 가져야 합니다.

authid 값은 아이디 매핑에 사용되는 사용자입니다. authid는 dn: 접두어가 사용되고 뒤에 디렉토리의 유효한 사용자 DN이 오거나 u: 접두어가 사용되고 뒤에 클라이언트에서 결정되는 문자열이 오는 것이 좋습니다. 이렇게 하면 DIGEST-MD5 아이디 매핑에 설명된 매핑을 사용할 수 있습니다.

일반적으로 SSL 연결을 사용하여 보안 포트를 통해 암호화를 제공하고 DIGEST-MD5를 사용하여 클라이언트 인증을 제공합니다. 아래 예에서는 SSL을 통해 동일한 작업을 수행합니다.

ldapsearch -h host -p securePort \
           -Z -P .mozilla/bjensen/string.slt/cert8.db \
           -N "certificateName" -W keyPassword \
           -o mech=DIGEST-MD5 [-o realm="hostFQDN"] \
           -o authid="dn:uid=bjensen,dc=example,dc=com" \
           -o authzid="dn:uid=bjensen,dc=example,dc=com" \
           -b "dc=example,dc=com" "(givenname=Richard)"

이 예에서 -N 및 -W 옵션은 ldapsearch 명령에 필요하며 클라이언트 인증에는 사용되지 않습니다. 대신, 서버는 authid 값의 사용자에 대해 다시 DIGEST-MD5 아이디 매핑을 수행합니다.

클라이언트에 커버로스 SASL GSSAPI 사용

클라이언트에 GSSAPI 기법을 사용하는 경우 사용자 인증서를 설치할 필요는 없지만 커버로스 V5 보안 시스템을 구성해야 합니다. 또한 암호화된 SSL 연결을 사용하려면 클라이언트에 서버 인증 구성에 설명된 것처럼 서버 인증서를 트러스트해야 합니다.

클라이언트 호스트에 커버로스 V5 구성

LDAP 클라이언트를 실행할 호스트 시스템에 커버로스 V5를 구성해야 합니다.

  1. 설치 지침에 따라 커버로스 V5를 설치합니다. Sun Enterprise Authentication Mechanism(SEAM) 1.0.1 클라이언트 소프트웨어를 설치할 것을 권장합니다.
  2. 커버로스 소프트웨어를 구성합니다. SEAM을 사용하면/etc/krb5에 있는 파일을 구성하여 kdc 서버를 설정하고, 기본 영역 및 커버로스 시스템에 필요한 기타 구성을 정의할 수 있습니다.
  3. 필요한 경우 /etc/gss/mech 파일을 수정하여 kerberos_v5를 첫 번째 값으로 표시합니다.

커버로스 인증에 대한 SASL 옵션 지정

  1. GSSAPI를 사용하는 클라이언트 응용 프로그램을 사용하기 전에 먼저 아래 명령을 실행하여 커버로스 보안 시스템을 사용자로 초기화해야 합니다.

    2. kinit userPrincipal

    userPrincipal은 사용자의 SASL 아이디입니다(예: bjensen@example.com).

  2. 아래의 ldapsearch 도구 예에서는 -o(소문자 o) 옵션을 사용하여 커버로스 사용에 대한 SASL 옵션을 지정하는 방법을 보여줍니다.

    3. ldapsearch -h host -p securePort \
               -Z -P .mozilla/bjensen/string.slt/cert8.db \
               -N "certificateName" -W keyPassword \
               -o mech=GSSAPI [-o realm="example.com" \
               -o authid="bjensen@example.com" \
               -o authzid="bjensen@example.com"] \
               -b "dc=example,dc=com" "(givenname=Richard)"

  3. 이 예에서 -N 및 -W 옵션은 ldapsearch 명령에 필요하며 클라이언트 인증에는 사용되지 않습니다. realm, authid 및 authzid는 kinit 명령으로 초기화된 커버로스 캐시에 있기 때문에 생략할 수 있습니다. 프록시 작업용 authzid를 사용하지 않는 경우에도 authid와 authzid 값은 둘 다 있어야 하며 동일한 값을 가져야 합니다. authid 값은 아이디 매핑에 사용되는 사용자입니다. 자세한 내용은 GSSAPI 아이디 매핑을 참조하십시오.


이전      목차      색인      다음     

Copyright 2004 Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.