test

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

5장 인증서 및 키 사용

이 장에서는 인증서와 키 인증을 사용하여 Sun Java System Web Proxy Server의 보안을 강화하는 방법에 대해 설명합니다. Proxy Server에는 모든 Sun Java System 서버의 보안 아키텍처가 포함되어 있으며, 최대의 상호 운영성과 일관성을 위해 업계 표준 및 공용 프로토콜을 기반으로 구축되었습니다.

이 장에서는 암호화 및 복호화, 공용 및 개인 키, 디지털 인증서 및 암호화 프로토콜과 같은 공용 키 암호화에 대한 기본 개념을 이해하는 것으로 가정합니다.

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

Administration Server 액세스 보안

서버의 관리, 추가, 제거 및 마이그레이션에 사용되는 웹 기반 사용자 인터페이스인 Administration Server에는 보안이 필요합니다.

기본 Administration Server 페이지는 HTTP 모드에서 시작됩니다. 사용 가능한 Proxy Server 인스턴스가 Manage Servers의 제목 아래에 목록으로 표시됩니다. Proxy Server 인스턴스를 관리하려면 목록에서 이름을 누릅니다. Proxy Server 인스턴스의 이름을 누르면 해당 인스턴스의 Server Manager 페이지가 표시됩니다.

Server Manager 페이지에서 왼쪽 상단에 있는 Manage Servers 링크를 눌러 Administration Server 페이지로 돌아갈 수 있습니다.

인증서 기반 인증, 트러스트 데이터베이스 만들기, SSL 구성, 인증서 요청 및 설치, 보안 기본 설정 지정과 같은 보안 기능은 Administration Server와 개별 Proxy Server 인스턴스 모두에 적용됩니다. Administration Server의 보안 관련 구성의 경우 Preferences 탭과 Administration Server 페이지의 Security 탭을 사용합니다. Proxy Server 인스턴스와 관련된 보안 구성의 경우 Preferences 탭과 해당 프록시 인스턴스의 Server Manager 페이지에 나타나는 Security 탭을 사용합니다.

Administration Server를 보안 모드에서 시작하려면 기본 HTTP가 아닌 HTTPS를 사용하여 액세스해야 합니다.

보안 기능은 다음 절에서 자세히 설명합니다.

인증서 기반 인증

인증은 아이디를 확인하는 과정입니다. 네트워크 상호작용이라는 맥락에서 인증은 한 쪽이 다른 쪽의 아이디를 명확히 확인하는 것입니다. 인증서는 인증을 지원하는 방법 중 한 가지입니다.

인증서는 개인, 회사 또는 기타 엔티티의 이름을 지정하며 인증서에 포함된 공용 키가 해당 엔티티에 속한다는 것을 인증하는 디지털 데이터로 구성됩니다.

클라이언트와 서버 모두 인증서를 가질 수 있습니다. 서버 인증이란 클라이언트가 서버의 아이디를 확인하는 것을 말합니다. 즉, 특정 네트워크의 주소에서 서버에 대한 책임이 있는 조직의 아이디를 확인하는 것입니다. 클라이언트 인증이란 서버가 클라이언트의 아이디를 확인하거나 클라이언트 소프트웨어를 사용하는 사람의 아이디를 확인하는 것입니다. 개인이 여러 개의 신분증을 가질 수 있는 것처럼 클라이언트에는 여러 개의 인증서가 있을 수 있습니다.

인증서는 인증 기관(또는 CA)이 발행하고 전자적으로 서명합니다. CA는 인증서를 판매하는 회사이거나 회사의 인트라넷 또는 익스트라넷용으로 인증서를 발행하는 부서일 수 있습니다. 다른 사람의 아이디를 확인하는 데 충분히 신뢰할 수 있는 CA를 선택합니다.

인증서에는 다음 정보가 포함됩니다.

주 –

서버 인증서는 반드시 암호화 기능을 사용하기 전에 설치되어야 합니다.

트러스트 데이터베이스 생성

서버 인증서를 요청하기 전에 트러스트 데이터베이스를 만들어야 합니다. Proxy Server에서는 Administration Server 및 각 서버 인스턴스에 자체 트러스트 데이터베이스가 있을 수 있습니다. 트러스트 데이터베이스는 로컬 컴퓨터에만 만들 수 있습니다.

트러스트 데이터베이스를 만들 때 키 쌍 파일용으로 사용할 비밀번호를 지정합니다. 또한 암호화된 통신을 사용하여 서버를 시작할 때에도 이 비밀번호가 필요합니다. 비밀번호를 선택하는 경우 고려해야 할 지침은 고급 비밀번호 선택을 참조하십시오.

트러스트 데이터베이스에서 공용 및 개인 키를 만들고 저장할 수 있습니다. 이는 키 쌍 파일이라고 합니다. 키 쌍 파일은 SSL 암호화에 사용됩니다. 키 쌍 파일은 서버 인증서를 요청하고 설치할 때 사용합니다. 인증서가 설치되면 트러스트 데이터베이스에 저장됩니다.

키 쌍 파일은 다음 디렉토리에 암호화되어 저장됩니다.

server-root/alias/proxy-serverid-key3.db

Administration Server에는 하나의 트러스트 데이터베이스만 있을 수 있습니다. 각 서버 인스턴스에는 자체의 트러스트 데이터베이스를 부여할 수 있습니다.

Procedure트러스트 데이터베이스를 만드는 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Create Database 링크를 누릅니다.

  3. 트러스트 데이터베이스의 비밀번호를 입력합니다.

  4. 비밀번호를 다시 입력하고 OK를 누릅니다.

password.conf 사용

기본적으로 시작하기 전에 관리자에게 키 데이터베이스 비밀번호를 입력하라는 프롬프트가 Proxy Server에 표시됩니다. 무인 작업으로 Proxy Server를 다시 시작하려면 비밀번호를 password.conf 파일에 저장해야 합니다. 시스템이 적절히 보호되어 이 파일과 키 데이터베이스가 조작되지 않을 경우에만 이 기능을 사용하십시오.

일반적으로 UNIX SSL 사용 서버의 경우 시작하기 전에 비밀번호가 필요하므로 /etc/ rc.local 또는 /etc/inittab 파일을 사용할 수 없습니다. 비밀번호를 일반 텍스트 파일에 저장하여 SSL 사용 서버를 자동으로 시작할 수는 있지만 안전하지 않습니다. 서버의 password.conf 파일은 루트 또는 서버를 설치한 사용자의 소유여야 하며 소유자만 파일을 읽고 쓸 수 있어야 합니다.

UNIX의 경우 SSL 사용 서버의 비밀번호를 password.conf 파일에 남겨두면 보안상의 위험이 커집니다. 파일에 액세스할 수 있는 사용자는 모두 SSL 사용 서버의 비밀번호를 알 수 있습니다. SSL 사용 서버의 비밀번호를 password.conf 파일에 보관하기 전에 보안 위험에 대해 고려해야 합니다.

Windows의 경우 NTFS 파일 시스템이 있으면 파일을 사용하지 않더라도 액세스를 제한하여 password.conf 파일이 포함된 디렉토리를 보호해야 합니다. 디렉토리에는 Administration Server 사용자와 Proxy Server 사용자에 대해 읽기 및 쓰기 권한이 있어야 합니다. 디렉토리를 보호하면 다른 사람이 잘못된 password.conf 파일을 만들 수 없도록 방지합니다. FAT 파일 시스템의 경우 액세스를 제한하는 경우에도 디렉토리나 파일을 보호할 수 없습니다.

SSL 사용 서버 자동 시작

ProcedureSSL 사용 서버 자동 시작 방법

  1. SSL이 활성화되어 있는지 확인합니다.

  2. Proxy Server 인스턴스의 config 하위 디렉토리에 새 password.conf 파일을 만듭니다.

    • Proxy Server와 함께 제공되는 내부 PKCS #11 소프트웨어 암호화 모듈을 사용하는 경우 다음 정보를 입력합니다.internal: your-password

      • 하드웨어 암호화 또는 하드웨어 가속기용의 다른 PKCS #11 모듈을 사용하는 경우에는 해당 PKCS #11 모듈의 이름과 비밀번호를 지정합니다. 예를 들면 다음과 같습니다.nFast:your-password

        password.conf 파일을 만든 후에도 Proxy Server를 시작할 때 항상 비밀번호를 입력하라는 프롬프트가 표시됩니다.

Sun Crypto Accelerator 키 저장소 사용

Sun Crypto Accelerator 4000 카드는 시스템 CPU가 낼 수 있는 속도보다 훨씬 빠른 속도로 확장 가능하고 최적화된 SSL 작업을 제공합니다.

ProcedureSun Crypto Accelerator를 사용하도록 Proxy Server를 구성하려면

  1. Sun Crypto Accelerator 4000 보드를 설치합니다.

  2. Sun Crypto Accelerator 4000 보드를 초기화합니다.

  3. Proxy Server 4.0.8을 설치합니다(루트로 설치하는 것이 좋음).

  4. 프록시 인스턴스에 트러스트 데이터베이스를 만듭니다.

    트러스트 데이터베이스를 만드는 방법에 대한 자세한 내용은 트러스트 데이터베이스 생성를 참조하십시오.

  5. Sun Crypto Accelerator 4000 보드를 활성화합니다.

ProcedureProxy Server에서 Sun Crypto Accelerator 4000 보드를 활성화하려면

  1. secadm 명령을 사용하여 사용자와 영역을 설정합니다.

  2. "server-root/bin/proxy " 디렉토리를 "server-root/bin/https" 디렉토리에 복사합니다.

    이 단계에서는 ipsslcfg 스크립트를 사용하여 modutil 명령을 찾아야 합니다.

  3. /opt/SUNWconn/bin/iplsslcfg 스크립트를 편집하여 modutil 경로를 지정합니다.

  4. /opt/SUNWconn/bin/iplsslcfg를 실행합니다.

  5. 옵션 1. Configure Sun ONE Web Server for SSL을 선택합니다.

    주 –

    옵션 1은 SSL에 대한 Web Server의 구성을 나타냅니다. Proxy Server 구성에 대해서도 같은 옵션 1을 선택합니다.

  6. Proxy Server 4.0.8 설치 디렉토리를 지정하고 y 를 선택하여 계속 진행합니다.

    모듈 Sun Crypto Accelerator가 데이터베이스에 추가됩니다.

  7. 관리 서버를 다시 시작합니다.

  8. 다시 시작한 후 Security->Request Certificate->Cryptographic Module을 선택합니다.

    그러면 목록에 SUNW acceleration only, Internal 및 keystore_name 등이 표시됩니다. 각 키 저장소는 목록에 자체 항목이 있습니다.

  9. 해당 키 저장소를 선택합니다.

    서버 인증서를 만드는 동안에는 SUNW acceleration only 옵션을 선택하지 마십시오.

VeriSign 인증서 요청 및 설치

VeriSign은 Proxy Server의 기본 인증 기관입니다. 이 회사의 기술은 인증서 요청 프로세스를 간소화합니다. VeriSign에는 인증서를 사용자의 서버로 직접 회신할 수 있다는 장점이 있습니다.

서버용 인증서 트러스트 데이터베이스를 만든 후 인증서를 요청하고 인증 기관(CA)에 제출할 수 있습니다. 회사에 내부 CA가 있는 경우에는 해당 부서로 인증서를 요청합니다. 상용 CA로부터 인증서를 구매할 계획인 경우에는 CA를 선택하고 필요한 정보 형식이 있는지 문의합니다.

Administration Server에는 오직 하나의 서버 인증서만 부여할 수 있습니다. 각 서버 인스턴스에는 자체의 서버 인증서를 부여할 수 있습니다.

ProcedureVeriSign 인증서 요청 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Request VeriSign Certificate 링크를 누릅니다.

  3. 표시되는 페이지에 나열된 단계를 검토하고 OK를 누릅니다.

    VeriSign Enrollment Wizard가 과정을 안내합니다.

ProcedureVeriSign 인증서 설치 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Install VeriSign Certificate 링크를 누릅니다.

  3. 외부 암호화 모듈을 사용하지 않는 한 Cryptographic Module 드롭다운 목록에서 Internal을 선택합니다.

  4. 키 쌍 파일 비밀번호 또는 PIN을 입력합니다.

  5. 드롭다운 목록에서 검색할 Transaction ID를 선택하고 OK를 누릅니다.

기타 서버 인증서 요청 및 설치

VeriSign 외에도 다른 인증 기관에 인증서를 요청하여 설치할 수 있습니다. 회사나 조직에서 자체의 내부 인증서를 제공할 수도 있습니다. 이 절에서는 여러 유형의 서버 인증서를 요청하고 설치하는 방법에 대해 설명합니다.

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

필수 CA 정보

요청 프로세스를 시작하기 전에 CA가 요구하는 정보가 무엇인지 알아야 합니다. 요청되는 정보의 형식은 CA에 따라 다르지만 일반적으로 아래 나열된 정보를 제공해야 합니다. 이 정보의 대부분은 인증서를 갱신할 때는 필요하지 않습니다.

모든 정보는 고유 이름(DN)이라고 하는 일련의 속성 값 쌍으로 조합되어 인증서의 개체를 고유하게 구분합니다.

상용 CA에서 인증서를 구매하는 경우에는 반드시 CA에 연락하여 인증서를 발행하기 위하여 필요한 추가 정보가 있는지 확인해야 합니다. 대부분의 CA는 아이디에 대한 증명을 요구합니다. 예를 들어, 회사 이름 및 회사가 서버를 관리하도록 지정한 사용자를 확인하고 사용자가 제공하는 정보를 사용할 법적 권한이 있는지 확인할 수 있습니다.

일부 상용 CA는 완벽한 아이디를 제공하는 조직이나 개인에게 더 자세하고 정확한 인증서를 제공합니다. 예를 들어, 사용자에게 www.example.com 컴퓨터에 대한 관리의 권한이 있으며 3년간 경영해온 회사로 유의할 고객 소송이 없었다는 사실을 표시하는 인증서를 구매할 수 있습니다.

기타 서버 인증서 요청

Procedure기타 서버 인증서 요청 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Request a Certificate 링크를 누릅니다.

  3. 신규 인증서인지 또는 인증서 갱신인지 지정합니다.

    인증서는 대부분 6개월이나 1년 등, 일정 시간이 경과하면 무효화됩니다. CA에 따라 자동으로 갱신을 송신하는 경우도 있습니다.

  4. 인증서 요청을 제출할 방법을 지정합니다.

    • 전자 메일을 사용하여 요청을 제출하려면 CA Email Address를 선택하고 해당 요청에 적절한 전자 메일 주소를 입력합니다.

      • CA의 웹 사이트를 사용하여 요청을 제출하려면 CA URL을 선택하고 해당 요청에 적절한 URL을 입력합니다.

  5. Cryptographic Module 드롭다운 목록에서 인증서 요청 시 키 쌍 파일에 사용될 암호화 모듈을 선택합니다.

  6. 키 쌍 파일용 비밀번호를 입력합니다.

    Internal이 아닌 암호화 모듈을 선택하지 않는 한 이 비밀번호는 트러스트 데이터베이스를 만들 때 지정됩니다. 서버는 비밀번호를 사용하여 개인 키를 구하고 CA로 전송되는 메시지를 암호화합니다. 그런 다음 서버는 공용 키와 암호화된 메시지를 모두 CA로 전송합니다. CA는 공용 키를 사용하여 메시지를 해독합니다.

  7. 이름 및 전화 번호와 같은 아이디 정보를 입력합니다.

    이 정보의 형식은 CA에 따라 다릅니다. 이 정보의 대부분은 인증서를 갱신할 때는 필요하지 않습니다.

  8. 입력한 사항이 정확한지 다시 한 번 확인한 다음 OK를 누릅니다.

    정보가 정확할 수록 인증서가 더욱 빨리 승인될 수 있습니다. 인증 서버에 대한 요청인 경우 요청을 제출하기 전에 양식 정보를 확인하라는 프롬프트가 표시됩니다.

    서버가 정보를 포함하는 인증서 요청을 생성합니다. 요청에는 개인 키를 사용하여 만든 전자 서명이 포함됩니다. CA는 전자 서명을 사용하여 요청이 서버 컴퓨터에서 CA로 라우팅되는 동안 조작되지 않았는지 검사합니다. 드물지만 요청이 조작된 경우에는 보통 CA가 전화를 통하여 사용자에게 문의합니다.

    요청을 전자 메일로 보내는 경우 서버는 요청이 포함된 전자 메일 메시지를 CA로 전송합니다. 이후 대개 인증서는 전자 메일로 전달됩니다. 인증 서버에 대한 URL을 지정한 경우 서버가 URL을 사용하여 요청을 인증 서버에 제출합니다. CA에 따라 전자 메일 또는 다른 방법을 통해 회신을 받을 수 있습니다.

    CA가 인증서 발행에 동의하는 경우 해당 사실을 통지합니다. 대부분의 경우 CA는 전자 메일을 사용하여 인증서를 전송합니다. 조직에서 인증 서버를 사용하는 경우 인증서 서버의 형식을 사용하여 인증서를 검색할 수 있습니다.

    주 –

    상용 CA로 인증서를 요청하는 모든 사람에게 인증서가 발행되는 것은 아닙니다. 많은 CA가 인증서를 발행하기 전에 아이디 증명을 요구합니다. 또한 승인에는 하루에서 몇 주까지 걸릴 수 있습니다. CA에 필요한 모든 정보를 신속하게 제공할 책임이 있습니다.

    인증서를 받으면 설치합니다. 그 동안에는 SSL 없이 Proxy Server를 계속 사용할 수 있습니다.

기타 서버 인증서 설치

CA의 인증서는 공용 키로 암호화되므로 오직 해당 사용자만 해독할 수 있습니다. 정확한 트러스트 데이터베이스용 비밀번호를 입력해야만 인증서를 해독하고 설치할 수 있습니다.

인증서에는 세 가지 유형이 있습니다.

인증서 체인이란 연속적인 인증 기관이 서명한 일련의 계층적 인증서를 말합니다. CA 인증서는 인증 기관을 확인하고 해당 기관이 발행한 인증서에 서명하는 데 사용됩니다. 이 CA 인증서는 다시 상위 CA의 CA 인증서에 의하여 서명되는 과정을 되풀이하여 루트 CA의 서명까지 이어집니다.

주 –

CA가 자동으로 인증서를 보내지 않는 경우에는 요청해야 합니다. 많은 CA가 귀사의 인증서가 있는 전자 메일에 자체의 인증서를 포함하며 서버는 이 두 인증서를 동시에 설치합니다.

CA의 인증서는 공용 키로 암호화되므로 오직 해당 사용자만 해독할 수 있습니다. 인증서를 설치하면 Proxy Server는 지정한 키 쌍 파일 비밀번호를 사용하여 이를 해독합니다. 다음 절차에 설명된 대로 전자 메일을 서버에 액세스할 수 있는 다른 위치에 저장하거나 전자 메일의 텍스트를 복사한 후 Install Certificate 형식에 붙여넣을 수 있도록 합니다.

Procedure기타 서버 인증서 설치 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Install Certificate 링크를 누릅니다.

  3. Certificate For 옆에서 설치할 인증서 유형을 선택합니다.

    • This Server

      • Server Certificate Chain

      • Certification Authority

        특정 설정에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

  4. 드롭다운 목록에서 암호화 모듈을 선택합니다.

  5. 키 쌍 파일 비밀번호를 입력합니다.

  6. 단계 3에서 Server Certificate Chain 또는Certification Authority를 선택한 경우에만 인증서 이름을 입력합니다.

  7. 다음 중 하나를 수행하여 인증서 정보를 입력합니다.

    • Message Is In This File을 선택한 다음 CA 인증서가 포함된 파일의 전체 경로 이름을 입력합니다.

      • Message Text(헤더 포함)를 선택한 다음 CA 인증서의 컨텐트를 복사하여 붙여넣습니다. Begin Certificate 및 End Certificate 헤더를 시작 및 끝 하이픈과 함께 포함해야 합니다.

  8. OK를 누릅니다.

  9. 새 인증서를 추가하는지 기존 인증서를 갱신하는지 여부를 지정합니다.

    • Add Certificate. 새 인증서를 설치하는 경우

      • Replace Certificate. 인증서 갱신을 설치하는 경우

        인증서는 서버의 인증서 데이터베이스에 저장됩니다. 예:

        server-root/alias/ proxy-serverid-cert8.db

이전 버전의 인증서 마이그레이션

Sun ONE Web Proxy Server 3.6(iPlanet Web Proxy Server라고도 함)에서 Sun Java System Web Proxy Server 4로 마이그레이션하는 경우 트러스트 및 인증서 데이터베이스를 포함한 파일이 자동으로 업데이트됩니다.

Proxy Server 4 Administration Server가 이전 3.x 데이터베이스 파일에 대한 읽기 권한이 있는지 확인해야 합니다. 파일은 alias-cert.db 및 alias-key.db이며 3.x-server-root/alias 디렉토리에 있습니다.

키 쌍 파일 및 인증서는 서버에 보안이 활성화된 경우에만 마이그레이션됩니다. 또한 Administration Server 및 Server Manager의 Security 탭에서 Migrate 3.x Certificates 옵션을 사용하여 키와 인증서를 자체적으로 마이그레이션할 수 있습니다. 특정 설정에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

이전 버전의 경우 인증서와 키 쌍 파일은 여러 서버 인스턴스가 사용할 수 있는 별칭에 의하여 참조되었습니다. Administration Server가 모든 별칭과 해당 구성 인증서를 관리했습니다. Sun Java System Web Proxy Server 4의 경우 Administration Server와 각 서버 인스턴스에는 자체 인증서 및 키 쌍 파일이 있으며 이는 별칭이 아닌 트러스트 데이터베이스라고 합니다.

트러스트 데이터베이스 및 해당 구성 인증서는 Administration Server 자체에 대해서는 Administration Server에서 관리되고 서버 인스턴스에 대해서는 Server Manager에서 관리됩니다. 인증서와 키 쌍 데이터베이스 파일은 이를 사용하는 서버 인스턴스의 이름을 따라 이름이 지정됩니다. 이전 버전에서 여러 서버 인스턴스가 동일한 별칭을 공유한 경우, 마이그레이션된 인증서와 키 쌍 파일의 이름은 새로운 서버 인스턴스용으로 변경됩니다.

서버 인스턴스와 연결된 트러스트 데이터베이스 전체가 마이그레이션됩니다. 이전 데이터베이스에 나열된 모든 CA가 Proxy Server 4 데이터베이스로 마이그레이션됩니다. CA가 중복되는 경우 유효 기간 동안 이전 CA를 사용합니다. 중복되는 CA를 삭제하면 안 됩니다.

Proxy Server 3.x 인증서는 지원되는 NSS(Network Security Services) 형식으로 마이그레이션됩니다. 인증서의 이름은 해당 인증서가 액세스된 Proxy Server 페이지에 따라 지정됩니다. 즉, Administration Server Security 탭 또는 Server Manager Security 탭에서 액세스되었는지에 따라 달라집니다.

Procedure인증서 마이그레이션 방법

  1. 로컬 컴퓨터에서 Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.

  2. Migrate 3.x Certificates 링크를 누릅니다.

  3. 3.6 서버가 설치된 루트 디렉토리를 지정합니다.

  4. 이 컴퓨터의 별칭을 지정합니다.

  5. 관리자의 비밀번호를 입력하고 OK를 누릅니다.

내장 루트 인증서 모듈 사용

동적으로 로드할 수 있는 루트 인증서 모듈이 Proxy Server에 포함되어 있으며, 여기에는 VeriSign을 비롯하여 많은 CA용 루트 인증서가 있습니다. 루트 인증서 모듈을 사용하면 이전보다 훨씬 쉽게 루트 인증서를 신규 버전으로 업그레이드할 수 있습니다. 이전에는 오래된 루트 인증서를 한 번에 하나씩 삭제하고 새 인증서를 한 번에 하나씩 설치해야 했습니다. 이제 잘 알려진 CA 인증서를 설치하는 경우, 간단히 Proxy Server의 신규 버전이 발표될 때 루트 인증서 모듈 파일을 신규 버전으로 업데이트하면 됩니다.

루트 인증서는 PKCS #11 암호화 모듈로 구현되기 때문에 포함된 루트 인증서는 삭제할 수 없습니다. 이러한 인증서를 관리하는 경우 삭제 옵션은 제공되지 않습니다. 서버 인스턴스에서 루트 인증서를 제거하려면 서버의 alias 디렉토리에서 다음 항목을 삭제하여 루트 인증서 모듈을 비활성화합니다.

루트 인증서 모듈을 복원하려면 server-root/bin/proxy/lib (UNIX) 또는 server-root\\ bin\\proxy\\bin(Windows)에서 확장자를 alias 하위 디렉토리로 복사할 수 있습니다.

루트 인증서의 트러스트 정보를 수정할 수 있습니다. 트러스트 정보는 루트 인증서 모듈 그 자체가 아니라 편집하는 서버 인스턴스용 인증서 데이터베이스에 기록되어 있습니다.

인증서 관리

서버에 설치된 CA 및 자체 인증서의 트러스트 설정을 보고, 삭제 또는 편집할 수 있습니다.

Procedure인증서 관리 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Manage Certificates 링크를 누릅니다.

    • 내부 암호화 모듈을 사용하는 기본 구성용 인증서를 관리하는 경우에는 설치된 모든 인증서의 목록이 해당 유형 및 유효 기간과 함께 표시됩니다. 모든 인증서는 server-root/alias 디렉토리에 저장됩니다.

      • 하드웨어 가속기 등의 외부 암호화 모듈을 사용하는 경우에는 우선 해당 모듈용 비밀번호를 입력하고 OK를 눌러야 합니다. 인증서 목록이 해당 모듈에 있는 인증서를 포함하여 업데이트됩니다.

  3. 관리할 인증서의 이름을 누릅니다.

    해당 인증서 유형에 대한 관리 옵션을 표시하는 페이지가 나타납니다. CA 인증서의 경우에만 클라이언트 트러스트를 설정 또는 해제할 수 있습니다. 외부 암호화 모듈에 따라 인증서를 삭제할 수 없는 경우도 있습니다.

  4. 원하는 작업을 지정합니다.

    다음 옵션을 사용할 수 있습니다.

    • Delete certificate 또는 Quit - 내부 인증서용

      • Set client trust, Unset server trust 또는 Quit - CA 인증서용

        인증서 정보에는 소유자와 발행자가 표시됩니다. 트러스트 설정을 이용하여 클라이언트 신뢰를 설정하거나 서버 트러스트를 해제할 수 있습니다. LDAP 서버 인증서의 경우 서버가 반드시 신뢰되어야 합니다.

CRL 및 KRL 설치/관리

인증서 해지 목록(CRL) 및 변조된 키 목록(CKL)은 클라이언트 또는 서버 사용자가 더 이상 신뢰해서는 안 되는 모든 인증서와 키를 알려줍니다. 예를 들어, 인증서의 유효 기간이 끝나기 전에 사용자가 사무실을 이전하거나 퇴사하는 등 인증서의 데이터가 변경되면 인증서는 취소되며 CRL에 해당 데이터가 표시됩니다. 키가 조작 또는 변형되는 경우 해당 키와 데이터가 CKL에 표시됩니다. CRL과 CKL은 모두 CA에 의하여 만들어지고 주기적으로 업데이트됩니다. 이 목록을 얻으려면 특정 CA에 문의하십시오.

이 절에서는 CRL 및 CKL을 설치하고 관리하는 방법에 대해 설명합니다.

ProcedureCRL 또는 CKL 설치 방법

  1. CA에서 CRL 또는 CKL을 구하여 로컬 디렉토리에 다운로드합니다.

  2. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  3. Install CRL/CKL 링크를 누릅니다.

  4. 다음 중 한 가지를 선택합니다.

    • Certificate Revocation List

      • Compromised Key List

  5. 연결된 파일의 전체 경로 이름을 입력하고 OK를 누릅니다.

    CRL 또는 CKL 정보가 나열된 Add Certificate Revocation List 또는 Add Compromised Key List 페이지가 표시됩니다. 데이터베이스에 이미 CRL 또는 CKL이 있는 경우에는 Replace Certificate Revocation List 또는 Replace Compromised Key List 페이지가 나타납니다.

  6. CRL 또는 CKL을 추가하거나 교체합니다.

ProcedureCRL 및 CKL 관리 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Manage CRL/CKL 링크를 누릅니다.

    설치된 모든 CRL과 CKL 및 만료일이 나열된 Manage Certificate Revocation List/Compromised Key List 페이지가 표시됩니다.

  3. Server CRL 또는 Server CKL 목록에서 인증서를 선택합니다.

  4. CRL 또는 CKL을 삭제하려면 Delete CRL이나 Delete CKL을 선택합니다.

  5. 관리 페이지로 돌아가려면 Quit를 누릅니다.

보안 기본 설정

인증서를 만든 후, 서버의 보안 작업을 시작할 수 있습니다. Sun Java System Web Proxy Server는 이 절에서 설명하는 여러 보안 요소를 제공합니다.

암호화는 정보를 변환하여 의도된 수신자 외에 아무도 알아볼 수 없도록 하는 프로세스입니다. 암호 해독은 암호화된 정보를 변환하여 다시 알아볼 수 있도록 하는 프로세스입니다. Proxy Server는 SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 암호화 프로토콜을 지원합니다.

암호는 암호화 또는 암호 해독에 사용되는 암호화 알고리즘(수학 함수)입니다. SSL 및 TLS 프로토콜에는 다양한 암호 제품군이 포함됩니다. 보안의 안전성과 강도는 암호마다 다릅니다. 일반적으로 암호가 사용하는 비트의 수가 많을수록 데이터를 해독하는 것이 어렵습니다.

양방향 암호화 프로세스에서 양쪽에는 반드시 동일한 암호가 있어야 합니다. 다양한 암호를 사용할 수 있으므로 서버를 가장 공통적으로 사용되는 암호용으로 활성화해야 합니다.

보안 연결에서 클라이언트와 서버는 양쪽이 통신에 사용할 수 있는 가장 강력한 암호화를 사용하도록 동의합니다. SSL 2.0, SSL 3.0 및 TLS 프로토콜에서 암호를 선택할 수 있습니다.

주 –

SSL 버전 2.0 이후 보안과 성능이 향상되었으므로 SSL 3.0을 사용할 수 있는 클라이언트가 아닌 경우에는 SSL 2.0을 사용하면 안 됩니다. 클라이언트 인증서가 SSL 2.0 암호와 작동되도록 보장되지 않습니다.

암호화 프로세스 그 자체로는 서버의 비밀 정보를 보안하는 데 충분하지 않습니다. 실제의 암호화 결과를 생성하거나 이전에 암호화된 정보를 해독하려면 키를 암호화 암호와 함께 사용해야 합니다. 이를 위해서 암호화 프로세스에는두 가지 키(공용 키와 개인 키)가 사용됩니다. 공용 키로 암호화된 정보는 오직 연결된 개인 키로만 해독할 수 있습니다. 공용 키는 인증서의 일부로 게시됩니다. 연결된 개인 키만 보호할 수 있습니다.

다양한 암호 제품군에 대한 설명과 키 및 인증서에 대한 자세한 내용은 SSL 개요를 참조하십시오.

서버에서 사용할 수 있는 암호를 지정할 수 있습니다. 암호화 성능이 최적인 암호를 활성화하려면 특정 암호를 사용하면 안 되는 충분한 이유가 있지 않는 한,모두 선택해야 합니다.

주의 – 주의 –

Enable No Encryption, Only MD5 Authentication을 선택하지 마십시오. 클라이언트 측에 사용 가능한 다른 암호가 없는 경우 서버는 이 설정을 기본값으로 사용하며 암호화가 수행되지 않습니다.

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

SSL 및 TLS 프로토콜

프록시 서버는 암호화 통신에 SSL 및 TLS 프로토콜을 지원합니다. SSL 및 TLS는 응용 프로그램에 독립적이며 더 높은 수준의 프로토콜과 함께 투명하게 계층을 이룰 수 있습니다.

SSL과 TLS 프로토콜은 서버와 클라이언트가 서로를 인증하고, 인증서를 전송하며 세션 키를 설정하는 등의 작업에 사용되는 다양한 암호를 지원합니다. 클라이언트와 서버는 지원하는 프로토콜, 암호화 정도에 대한 회사 정책, 암호화된 소프트웨어의 수출에 대한 정부 규제 등, 다양한 요인에 따라 지원하는 암호 제품군이 달라집니다. 다른 기능 중 SSL과 TLS 핸드셰이크 프로토콜에 따라 서버와 클라이언트가 통신에 사용할 암호 제품군을 선택하는 방식을 결정됩니다.

SSL을 사용하여 LDAP와 통신

Administration Server는 SSL을 사용하여 LDAP와 통신하도록 해야 합니다.

주 –

이 경우 Proxy Server는 SSL 클라이언트 역할을 하며 SSL 서버 LDAP 인증서를 서명한 루트 CA 인증서를 가져와야 합니다. LDAP에 대한 SSL 인증서가 잘 알려진 CA에서 발행되지 않은 경우 사용된 CA 루트 키를 Proxy Server 키 저장소로 가져와야 합니다.

ProcedureAdministration Server에서 SSL 연결로 LDAP를 활성화하는 방법

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

  2. Configure Directory Service 링크를 누릅니다.

  3. 나타나는 표에서 디렉토리 서비스에 대한 링크를 누릅니다.

    Configure Directory Service 페이지가 표시됩니다. LDAP 기반 디렉토리 서비스를 아직 만들지 않은 경우 Create New Service of Type 드롭다운 목록에서 LDAP Server를 선택한 다음 New를 눌러 디렉토리 서비스를 구성합니다. LDAP 기반 디렉토리 서비스에 대해 표시되는 특정 필드에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

  4. 연결에 SSL을 사용하도록 Yes를 선택한 다음 Save Changes를 누릅니다.

Proxy Server를 통해 SSL 터널링

Proxy Server(프록시)를 정방향으로 실행할 때 클라이언트가 프록시를 통해 보안 서버에 대한 SSL 연결을 요청하면, 프록시는 보안 서버에 대한 연결을 연 다음 보안 트랜잭션에 관여하지 않고 양방향으로 데이터를 복사합니다. 이 프로세스를 SSL 터널링이라고 하며 아래 그림에서 설명합니다.

그림 5–1 SSL 연결

클라이언트에서 프록시 서버를 통해 보안 서버로 가는 SSL 연결을 보여 주는 그림

HTTPS URL에 SSL 터널링을 사용하려면 클라이언트는 SSL과 HTTPS를 모두 지원해야 합니다. HTTPS는 일반 HTTP에 SSL을 사용하여 구현됩니다. HTTPS 지원이 없는 클라이언트도 Proxy Server의 HTTPS 프록싱 기능을 사용하여 HTTPS 문서에 액세스할 수 있습니다.

SSL 터널링은 응용 프로그램 수준(HTTPS)에 영향을 미치지 않는 더 낮은 수준의 작동입니다. SSL 터널링은 프록싱이 없는 SSL만큼 안전합니다. 사이에 프록시가 있어도 보안이 손상되거나 SSL 기능이 저하되지 않습니다.

SSL을 통해 데이터 스트림이 암호화되므로 프록시가 실제 트랜잭션에 액세스할 수 없습니다. 따라서 액세스 로그가 원격 서버에서 수신된 상태 코드나 헤더 길이를 나열할 수 없습니다. 또한 이 프로세스를 통해 프록시 또는 다른 제 3자가 트랜잭션을 도청하는 것을 방지할 수 있습니다.

프록시는 데이터를 볼 수 없으므로 클라이언트와 원격 서버 사이에 사용되는 프로토콜이 SSL인지 확인할 수 없습니다. 따라서 프록시도 다른 프로토콜이 통과되는 것을 차단할 수 없습니다. IANA(Assigned Numbers AuthorityIANA)에 의해 할당된 HTTPS용 포트 443 및 SNEWS용 포트 563과 같이 잘 알려진 SSL 포트로만 SSL 연결을 제한해야 합니다. 다른 포트에서 보안 서버를 실행하는 사이트가 있는 경우 connect://.* 자원을 사용하여 명시적으로 예외를 지정하여 특정 호스트에 있는 다른 포트에 대한 연결을 허용할 수 있습니다.

SSL 터널링 기능은 실제로 프로토콜에 독립적인 일반 SOCKS의 기능과 유사하기 때문에 다른 서비스에도 이 기능을 사용할 수 있습니다. 프록시 서버는 HTTPS 및 SNEWS 프로토콜뿐만 아니라 SSL을 지원하는 모든 응용 프로그램에 대한 SSL 터널링을 처리할 수 있습니다.

SSL 터널링 구성

다음 절차에서는 SSL을 터널링하도록 Proxy Server를 구성하는 방법에 대해 설명합니다.

ProcedureSSL 터널링 구성 방법

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

  2. Enable/Disable Proxying 링크를 누릅니다.

  3. 드롭다운 목록에서 connect://.*.443 자원을 선택합니다.

    connect:// 메소드는 내부 프록시 표기법으로 프록시의 외부에는 존재하지 않습니다. connect에 대한 자세한 내용은 SSL 터널링에 대한 기술적 세부 정보를 참조하십시오.

    다른 포트에 대한 연결을 허용하려면 템플리트에 비슷한 URL 패턴을 사용합니다. 템플리트에 대한 자세한 내용은 16 장템플리트 및 자원 관리을 참조하십시오.

  4. Enable Proxying Of This Resource를 선택하고 OK를 누릅니다.

    주의 – 주의 –

    프록시가 잘못 구성되면 이 프록시를 사용하여 telnet 연결이 실제 연결하는 호스트가 아닌 프록시 호스트에서 들어오는 것처럼 나타나게 할 수 있습니다. 따라서 절대적으로 필요하지 않은 포트는 허용하지 말고 프록시에서 액세스 제어를 사용하여 클라이언트 호스트를 제한해야 합니다.

SSL 터널링에 대한 기술적 세부 정보

내부적으로 SSL 터널링은 CONNECT 메소드를 사용하고 대상 호스트 이름과 포트 번호를 매개 변수로 지정한 다음 빈 행을 추가합니다.

CONNECT energy.example.com:443 HTTP/1.0

Proxy Server의 성공적인 응답은 다음과 같으며 뒤에 빈 줄이 옵니다.

HTTP/1.0 200 Connection establishedProxy-agent: Sun-Java-System-Web-Proxy-Server/4.0

그러면 클라이언트와 원격 서버 사이에 연결이 설정됩니다. 한 쪽 연결이 닫히기 전까지 데이터를 양방향으로 전송할 수 있습니다.

내부적으로는 URL 패턴에 따라 일반적인 구성 메커니즘을 활용하려면 다음과 같이 호스트 이름 및 포트 번호를 자동으로 URL에 매핑해야 합니다.

connect://energy.example.com:443

connect://는 구성을 용이하게 하고 다른 URL 패턴과 일치하도록 Proxy Server에서 사용하는 내부 표기법입니다. Proxy Server 외부에는 connect URL이 존재하지 않습니다. Proxy Server가 네트워크에서 이런 URL을 수신하면 URL을 유효하지 않은 것으로 표시하고 해당 요청에 대한 서비스를 거부합니다.

청취 소켓용 보안 사용 설정

다음을 수행하여 서버의 청취 소켓을 보안할 수 있습니다.

주 –

역방향 프록시 모드에서만 보안을 사용할 수 있으며 순방향 프록시 모드에서는 사용할 수 없습니다.

보안 기능 사용

청취 소켓용으로 다른 보안 설정을 구성하기 전에 반드시 보안을 사용하도록 설정해야 합니다. 새 청취 소켓을 만들거나 기존 청취 소켓을 편집할 때 보안을 사용하도록 설정할 수 있습니다.

Procedure청취 소켓을 만들 때 보안을 사용하도록 설정하는 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  2. Add Listen Socket 링크를 누릅니다.

  3. 필요한 정보를 입력합니다.

    주 –

    청취 소켓을 만든 후 보안 설정을 구성하려면 Edit Listen Sockets 링크를 사용합니다.

  4. 보안을 사용하도록 설정하려면 Security 드롭다운 목록에서 Enabled를 선택한 다음 OK를 누릅니다.

    서버 인증서가 설치되지 않은 경우에는 Disabled만 선택할 수 있습니다. 특정 설정에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

Procedure청취 소켓을 편집할 때 보안을 사용하도록 설정하는 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  2. Edit Listen Sockets 링크를 누릅니다.

  3. 편집할 청취 소켓의 링크를 누릅니다.

  4. Security 드롭다운 목록에서 Enabled를 선택한 다음 OK를 누릅니다.

    서버 인증서가 설치되지 않은 경우에는 Disabled만 선택할 수 있습니다.

청취 소켓용 서버 인증서 선택

Administration Server나 Server Manager에서 청취 소켓을 구성하여 요청 및 설치한 서버 인증서를 사용할 수 있습니다.

주 –

인증서를 한 개 이상 설치해야 합니다.

Procedure청취 소켓용 서버 인증서를 선택하는 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  2. Edit Listen Sockets 링크를 누릅니다.

  3. 편집할 청취 소켓의 링크를 누릅니다.

  4. Security 드롭다운 목록에서 Enabled를 선택한 다음 OK를 누릅니다.

    서버 인증서가 설치되지 않은 경우에는 Disabled만 선택할 수 있습니다.

  5. Server Certificate Name 드롭다운 목록에서 해당 청취 소켓의 서버 인증서를 선택하고 OK를 누릅니다.

암호 선택

Proxy Server의 보안을 보호하려면 SSL을 활성화해야 합니다. SSL 2.0, SSL 3.0 및 TLS 암호화 프로토콜을 활성화하고 다양한 암호 제품군을 선택할 수 있습니다. SSL 및 TLS 프로토콜은 Administration Server용 청취 소켓에서 활성화할 수 있습니다. Server Manager용 청취 소켓에서 SSL 및 TLS를 활성화하면 특정 서버 인스턴스에 대한 해당 보안 기본 설정이 지정됩니다. 인증서를 한 개 이상 설치해야 합니다.

주 –

청취 소켓에서 SSL를 활성화하는 것은 Proxy Server가 역방향 프록싱을 수행하도록 구성된 경우에만 적용됩니다.

기본 설정의 경우 가장 많이 사용되는 암호를 허용합니다. 특정 암호 제품군을 사용하면 안 되는 충분한 이유가 있지 않는 한, 모두 선택해야 합니다.

TLS Rollback에 대한 기본 및 권장 설정은 Enabled입니다.이 설정은 “중간개입자(man-in-the-middle) 버전 롤백” 공격 시도를 감지하도록 서버를 구성합니다. TLS 사양을 잘못 구현한 일부 클라이언트와의 상호 운영성을 위해 TLS Rollback을 Disabled로 설정해야 할 수 있습니다.

TLS Rollback을 비활성화하면 연결이 버전 롤백 공격에 취약해집니다. 버전 롤백 공격은 클라이언트와 서버가 SSL 2.0과 같이 보안이 약한 이전 프로토콜을 사용하도록 제 3자가 강제로 조정할 수 있는 메커니즘입니다. SSL 2.0 프로토콜에는 알려진 결함이 있으므로 "버전 롤백" 공격을 감지하지 못하면 제 3자가 더 쉽게 암호화된 연결을 가로채어 해독할 수 있습니다.

ProcedureSSL 및 TLS 활성화 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  2. Edit Listen Sockets 링크를 누른 다음 편집할 청취 소켓의 링크를 누릅니다.

    보안 청취 소켓의 경우 사용 가능한 암호 설정이 표시됩니다.

    청취 소켓에서 보안을 활성화하지 않은 경우 SSL 및 TLS 정보가 나열되지 않습니다. 암호를 사용하려면 선택한 청취 소켓에서 보안이 사용되도록 설정해야 합니다. 자세한 내용은 청취 소켓용 보안 사용 설정을 참조하십시오.

  3. 필요한 암호화 설정에 해당하는 확인란을 선택하고 OK를 누릅니다.

  4. Netscape Navigator 6.0의 경우 TLS 및 SSL 3.0을 모두 선택합니다. TLS Rollback의 경우에는 TLS를 선택하고 SSL 3.0 및 SSL 2.0을 모두 비활성화해야 합니다.

    서버에서 SSL을 활성화하면 URL은 http가 아닌 https를 사용합니다. SSL 사용 서버의 문서를 가리키는 URL의 형식은 다음과 같습니다. https://servername .domain.dom :port, 예: https://admin.example.com:443

    기본 보안 HTTP 포트(443)를 사용하는 경우 URL에 포트 번호를 입력하지 않아도 됩니다.

전역적 보안 구성

SSL 사용 서버를 설치하면 magnus.conf 파일(서버의 기본 구성 파일)에전역 보안 매개 변수용 지시문 항목이 만들어집니다.

SSLSessionTimeout

SSLSessionTimeout 지시문은 SSL 2.0 세션 캐시를 제어합니다. 구문:

SSLSessionTimeout seconds

여기서 seconds는 캐시된 SSL 세션의 유효 시간(초)입니다. 기본값은 100입니다. SSLSessionTimeout 지시문이 지정되면 초 단위 값은 자동으로 5에서 100초로 제한됩니다.

SSLCacheEntries

캐시할 수 있는 SSL 세션의 수를 지정합니다.

SSL3SessionTimeout

SSL3SessionTimeout 지시문은 3.0 및 TLS 세션 캐시를 제어합니다. 구문:

SSL3SessionTimeout seconds

여기서 seconds는 캐시된 SSL 3.0 세션의 유효한 시간(초)입니다. 기본값은 86400(24시간)입니다. SSL3SessionTimeout 지시문이 지정되면 초 단위 값은 자동으로 5초에서 86400초 사이로 제한됩니다.

ProcedureSSL 구성 파일 지시문에 대한 값을 설정하는 방법

  1. 서버 인스턴스에 대한 Sever Manager에 액세스합니다.

  2. 구성하려는 청취 소켓에서 보안을 사용하는지 확인하십시오.

    자세한 내용은 청취 소켓용 보안 사용 설정을 참조하십시오.

  3. magnus.conf 파일을 수동으로 편집하여 다음 설정에 대한 값을 제공합니다.

    • SSLSessionTimeout

    • SSLCacheEntries

    • SSL3SessionTimeout

    magnus.conf에 대한 자세한 내용은 Sun Java System Web Proxy Server 4.0.8 Configuration File Reference를 참조하십시오.

외부 암호화 모듈 사용

Proxy Server는 다음과 같이 스마트 카드나 토큰 링 등 외부 암호화 모듈을 사용하는 방법을 지원합니다.

FIPS 140 암호화 표준을 사용하기 전에 PKCS#11 모듈을 추가해야 합니다.

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

PKCS #11 모듈 설치

Proxy Server는 SSL과 PKCS #11 모듈 사이의 통신에 사용되는 인터페이스를 정의하는 PKCS(Public Key Cryptography Standard) #11을 지원합니다. PKCS #11 모듈은 SSL 하드웨어 가속기에 대한 표준 기반 연결용으로 사용됩니다. 외부 하드웨어 가속기용으로 가져온 인증서 및 키는 secmod.db 파일에 저장되며 이 파일은 PKCS #11 모듈을 설치할 때 생성됩니다. 이 파일은 server-root/alias 디렉토리에 있습니다.

modutil 도구를 사용하여 PKCS #11 모듈 설치

modutil 도구를 사용하여 PKCS #11 모듈을 .jar 파일 또는 객체 파일의 형태로 설치할 수 있습니다.

Proceduremodutil 도구를 사용하여 PKCS #11 모듈을 설치하는 방법

  1. Administration Server를 포함한 모든 서버를 중지해야 합니다.

  2. 데이터베이스가 포함된 server-root/alias 디렉토리로 이동합니다.

  3. PATH에 server-root/bin/proxy/admin/bin을 추가합니다.

  4. server-root /bin/proxy/admin/bin에서 modutil을 찾습니다.

  5. 환경을 설정합니다.

    • UNIX: setenv

      LD_LIBRARY_PATH server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • Windows의 경우 이를 PATH에 추가합니다.

      LD_LIBRARY_PATH server-root/bin/proxy/bin

      server-root/proxy-admserv/start에서 나열된 컴퓨터에 대한 PATH를 찾을 수 있습니다.

  6. 단말기 창에서 modutil을 입력합니다.

    옵션이 나열됩니다.

  7. 필요한 조치를 수행합니다.

    예를 들어, UNIX에서 PKCS #11 모듈을 추가하려면 다음을 입력합니다.

    modutil -add ( PKCS#11 파일의 이름) -libfile (PKCS #11에 대한 libfile) -nocertdb -dbdir . (db 디렉토리)

pk12util 도구를 사용하여 내보내기

pk12util을 사용하면 내부 데이터베이스에서 인증서와 키를 내보내고 이를 내부 또는 외부 PKCS #11 모듈로 가져올 수 있습니다. 언제라도 인증서와 키를 내부 데이터베이스로 내보낼 수 있으나, 외부 토큰의 경우 대부분 인증서와 키를 내보낼 수 없습니다. 기본적으로 pk12util은 cert8.db와 key3.db라는 이름의 인증서 및 키 데이터베이스를 사용합니다.

Procedure내부 데이터베이스에서 인증서 및 키를 내보내는 방법

  1. 데이터베이스가 포함된 server-root/alias 디렉토리로 이동합니다.

  2. PATH에 server-root/bin/proxy/admin/bin을 추가합니다.

  3. server-root /bin/proxy/admin/bin에서 pk12util을 찾습니다.

  4. 환경을 설정합니다.

    • UNIX:

      setenv LD_LIBRARY_PATH/ server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • Windows의 경우 이를 PATH에 추가합니다.

      LD_LIBRARY_PATH server-root/bin/proxy/bin

      아래 나열된 컴퓨터에 대한 PATH를 찾을 수 있습니다. server-root/proxy-admserv/start.

  5. 터미널 창에서 pk12util을 입력합니다.

    옵션이 나열됩니다.

  6. 필요한 조치를 수행합니다.

    예를 들어, UNIX의 경우 다음을 입력합니다.

    pk12util -o certpk12 -n Server-Cert [-d /server/alias] [-P https-test-host]

  7. 데이터베이스 비밀번호를 입력합니다.

  8. pkcs12 비밀번호를 입력합니다.

Procedure인증서 및 키를 내부 또는 외부 PKCS #11 모듈로 가져오는 방법

  1. 데이터베이스가 포함된 server-root/alias 디렉토리로 이동합니다.

  2. PATH에 server-root/bin/proxy/admin/bin을 추가합니다.

  3. server-root /bin/proxy/admin/bin에서 pk12util을 찾습니다.

  4. 환경을 설정합니다.

    예:

    • UNIX:

      setenv LD_LIBRARY_PATH/ server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

      • Windows의 경우 이를 PATH에 추가합니다.

        LD_LIBRARY_PATH server-root/bin/proxy/bin

        server-root/proxy-admserv/start에 나열된 컴퓨터에 대한 PATH를 찾을 수 있습니다.

  5. 터미널 창에서 pk12util을 입력합니다.

    옵션이 나열됩니다.

  6. 필요한 조치를 수행합니다.

    예를 들어, UNIX의 경우 다음을 입력합니다.

    pk12util -i pk12_sunspot [-d certdir][-h “nCipher”][-P https-jones.redplanet.com-jones-]

    -P는 반드시 -h 뒤에 있어야 하며 마지막 인수여야 합니다.

    대문자와 인용 부호 사이의 공백을 포함하여 토큰 이름을 정확히 입력합니다.

  7. 데이터베이스 비밀번호를 입력합니다.

  8. pkcs12 비밀번호를 입력합니다.

외부 인증서를 사용하여 서버 시작

서버용 인증서를 하드웨어 가속기와 같은 외부 PKCS #11 모듈에 설치한 경우 server.xml 파일을 편집하거나 아래에 설명된 대로 인증서 이름을 지정하지 않으면 해당 인증서를 사용하여 서버를 시작할 수 없습니다.

서버는 항상 이름이 Server-Cert인 인증서를 사용하여 시작하려고 합니다. 그러나 외부 PKCS #11 모듈의 인증서는 해당 식별자에 모듈의 토큰 이름 중 하나를 포함합니다. 예를 들어, smartcard0라는 외부 스마트 카드 판독기에 설치된 서버 인증서의 이름은 smartcard0:Server-Cert가 됩니다.

외부 모듈에 설치된 인증서를 사용하여 서버를 시작하려면 서버가 실행되는 청취 소켓용 인증서 이름을 지정해야 합니다.

Procedure청취 소켓용 인증서 이름을 선택하는 방법

청취 소켓에서 보안이 활성화되지 않는 경우에는 인증서 정보가 표시되지 않습니다. 청취 소켓용 인증서 이름을 선택하려면 먼저 청취 소켓에서 보안을 활성화해야 합니다. 자세한 내용은 청취 소켓용 보안 사용 설정을 참조하십시오.

  1. Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  2. Edit Listen Sockets 링크를 누릅니다.

  3. 인증서와 연결할 청취 소켓에 대한 링크를 누릅니다.

  4. 청취 소켓에 대한 Server Certificate Name 드롭다운 목록에서 서버 인증서를 선택하고 OK를 누릅니다.

    이 목록에는 설치된 모든 내부 및 외부 인증서가 표시됩니다.

    또한 server.xml 파일을 수동으로 편집하여 서버가 해당 서버 인증서를 사용하여 시작하도록 할 수 있습니다. SSLPARAMS의 servercertnickname 속성을 다음으로 변경합니다.

    $TOKENNAME:Server-Cert

    $TOKENNAME용으로 사용할 값을 찾으려면 서버의 Security 탭으로 이동하여 Manage Certificate 링크를 선택합니다. Server-Cert가 저장된 외부 모듈로 로그인하면 해당 인증서가 $TOKENNAME:$NICKNAME 형식의 목록에 표시됩니다.

    트러스트 데이터베이스를 만들지 않은 경우, 외부 PKCS #11 모듈에 대한 인증서를 요청하거나 설치하면 자동으로 만들어집니다. 만들어진 기본 데이터베이스에는 비밀번호가 없으며 액세스할 수 없습니다. 외부 모듈은 작동하지만 서버 인증서를 요청하거나 설치할 수는 없습니다. 기본 데이터베이스가 비밀번호 없이 만들어진 경우 Security 탭의 Create Database 페이지를 사용하여 비밀번호를 설정합니다.

FIPS 140 표준

PKCS #11 API를 사용하면 암호화 작업을 수행하는 소프트웨어 또는 하드웨어 모듈과 통신할 수 있습니다. PKCS #11을 Proxy Server에 설치한 후 서버를 FIPS 140과 호환되도록 구성할 수 있습니다. FIPS는 Federal Information Processing Standards를 나타냅니다. 이 라이브러리는 SSL 3.0에만 포함되어 있습니다.

ProcedureFIPS 140 활성화 방법

  1. FIPS 140의 설명을 따라 플러그인을 설치합니다.

  2. Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  3. Edit Listen Sockets 링크를 누릅니다.

    보안 청취 소켓에 대해 Edit Listen Socket 페이지에 사용 가능한 보안 설정이 표시됩니다.

    FIPS 140을 사용하려면 선택한 청취 소켓에서 보안이 사용되도록 설정해야 합니다. 자세한 내용은 청취 소켓용 보안 사용 설정을 참조하십시오.

  4. Enable이 선택되어 있지 않으면 SSL Version 3 드롭다운 목록에서 선택합니다.

  5. 적절한 FIPS 140 암호 제품군을 선택하고 OK를 누릅니다.

    • 168비트 암호화 및 SHA 인증이 포함된 Triple DES(FIPS) 활성화

      • 56비트 암호화 및 SHA 인증이 포함된 DES(FIPS) 활성화

클라이언트 보안 요구 사항 설정

서버 보안 단계를 모두 수행한 후, 클라이언트에 대한 추가 보안 요구 사항을 설정할 수 있습니다.

클라이언트 인증이 SSL 연결에 반드시 필요한 것은 아니지만 암호화된 정보를 올바른 대상에게 전송하는 데 도움이 될 수 있습니다. 역방향 프록시에서 클라이언트 인증을 사용하여 내용 서버가 권한이 없는 프록시나 클라이언트와 정보를 공유하지 않도록 할 수 있습니다.

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

클라이언트 인증 요구

Administration Server용 청취 소켓을 사용하도록 설정하고 각 서버 인스턴스가 클라이언트 인증을 요청하도록 할 수 있습니다. 클라이언트 인증을 활성화하면 서버가 쿼리에 대한 응답을 전송하기 전에 클라이언트에 인증서를 요구합니다.

Proxy Server는 클라이언트 인증서에 있는 CA와 클라이언트 인증서 서명용으로 신뢰된 CA를 비교하여 클라이언트 인증서를 인증합니다. 클라이언트 인증서 서명용으로 신뢰된 CA의 목록은 Security 탭을 통해 Manage Certificates 페이지에서 볼 수 있습니다.

신뢰할 수 있는 CA의 클라이언트 인증서를 보유하지 않은 클라이언트를 거부하도록 프록시 서버를 구성할 수 있습니다. 신뢰할 수 있는 CA를 수락하거나 거부하려면 CA에 대해 클라이언트 트러스트를 설정해야 합니다. 자세한 내용은 인증서 관리를 참조하십시오.

인증서의 유효 기간이 만료된 경우 프록시 서버는 오류를 기록하고 인증서를 거부하며 클라이언트에게 메시지를 반송합니다. 또한 Manage Certificates 페이지에서 만료된 인증서를 볼 수 있습니다.

서버가 인증서 클라이언트에서 정보를 수집하여 이를 LDAP 디렉토리에 있는 사용자 항목과 비교하도록 구성할 수 있습니다. 이 프로세스는 클라이언트에 유효한 인증서가 있고 LDAP 디렉토리에 항목이 있는지 확인합니다. 또한 클라이언트 인증서가 LDAP 디렉토리의 항목 중 하나와 일치되도록 합니다. 이에 대한 방법은 클라이언트 인증서를 LDAP로 매핑을 참조하십시오.

클라이언트 인증서를 액세스 제어와 조합할 수 있으므로 신뢰된 CA의 요구 사항 이외에 인증서에 연결된 사용자는 반드시 액세스 제어 규칙(ACL)과 일치되어야 합니다. 자세한 내용은 액세스 제어 파일 사용을 참조하십시오.

Procedure클라이언트 인증 요구 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 누릅니다.

  2. Edit Listen Sockets 링크를 누릅니다.

  3. 클라이언트 인증을 요구할 청취 소켓에 대한 링크를 누릅니다.

  4. Client Authentication 드롭다운 목록을 사용하여 청취 소켓에 대한 클라이언트 인증을 요구하고 OK를 누릅니다.

역방향 프록시에서의 클라이언트 인증

역방향 프록시에서는 다음 시나리오 중 하나에 따라 클라이언트 인증을 구성할 수 있습니다.

이러한 시나리오를 구성하는 방법에 대한 자세한 내용은 역방향 프록시에서의 클라이언트 인증 설정을 참조하십시오.

역방향 프록시에서의 클라이언트 인증 설정

보안 역방향 프록시에서의 클라이언트 인증은 연결의 보안을 더욱 강화할 수 있습니다. 다음 지침에서는 선택한 시나리오에 따라 클라이언트 인증을 구성하는 방법에 대해 설명합니다.

주 –

각 시나리오에서는 보안 클라이언트-프록시 연결 및 보안 프록시-내용 서버 연결을 모두 사용한다고 가정합니다.

ProcedureProxy-Authenticates-Client 시나리오 구성 방법

  1. 14 장역방향 프록시 사용의 "역방향 프록시 설정"에 있는 보안 클라이언트-프록시 및 보안 프록시-내용 서버 시나리오 구성 지침을 따릅니다.

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

  3. Edit Listen Sockets 링크를 누른 다음 나타나는 표에서 원하는 청취 소켓에 대한 링크를 누릅니다.

    청취 소켓을 구성하고 추가하려면 Add Listen Socket 링크를 사용합니다.

  4. 클라이언트 인증 요구 사항을 지정합니다.

    1. 유효한 인증서가 있는 모든 사용자에게 액세스를 허용하는 방법

      Security 섹션에서 Client Authentication 설정을 사용하여 이 청취 소켓에 대해 클라이언트 인증을 요구합니다. 서버 인증서가 설치되어 있지 않으면 이 설정이 표시되지 않습니다.

    2. 두 개의 유효한 인증서가 모두 있고 액세스 제어에 승인된 사용자로 지정된 사용자에게만 액세스를 허용하는 방법

      1. Security 섹션에서 Client Authentication 설정을 off로 유지합니다. 서버 인증서가 설치되어 있지 않으면 이 설정이 표시되지 않습니다.

      2. 이 서버 인스턴스에 대한 Server Manager Preferences 탭에서 Administer Access Control 링크를 누릅니다.

      3. ACL을 선택한 다음 Edit 버튼을 누릅니다.

        Access Control Rules For 페이지가 표시됩니다(프롬프트가 표시되면 인증 필요).

      4. 액세스 제어를 사용하도록 설정합니다(아직 선택되어 있지 않으면 Access control Is On 확인란 선택).

      5. 역방향 프록시로 인증하도록 Proxy Server를 설정합니다.

        자세한 내용은 역방향 프록시 설정을 참조하십시오.

      6. 원하는 액세스 제어 규칙에 대한 Rights 링크를 누르고 아래 창에서 액세스 권한을 지정한 다음 Update를 눌러 이 항목을 업데이트합니다.

      7. Users/Groups 링크를 누릅니다. 아래 창에서사용자 및 그룹을 지정하고 인증 방법으로 SSL을 선택한 다음 Update를 눌러 이 항목을 업데이트합니다.

      8. 위 창에서 Submit를 눌러 항목을 저장합니다.

        액세스 제어 설정에 대한 자세한 내용은 8 장서버 액세스 제어를 참조하십시오.

ProcedureContent Server-Authenticates-Proxy 시나리오를 구성하는 방법

  1. 역방향 프록시 설정의 보안 클라이언트-프록시 및 프록시-내용 서버 시나리오를 구성하는 지침을 따릅니다.

  2. 내용 서버에서 클라이언트 인증을 사용하도록 설정합니다.

    Proxy Server에 대한 비보안 클라이언트 연결 및 내용 서버에 대한 보안 연결을 수행하고 내용 서버가 프록시 서버를 인증하도록 이 시나리오를 수정할 수 있습니다. 이렇게 하려면 다음 절차에 설명된 대로 암호화의 사용 설정을 해제하고 프록시가 인증서만 초기화하도록 해야 합니다.

ProcedureProxy-Authenticates-Client and Content Server-Authenticates-Proxy 시나리오를 구성하는 방법

  1. Proxy-Authenticates-Client 시나리오 구성 방법의 프록시-인증-클라이언트 시나리오를 구성하는 방법에 대한 지침을 따릅니다.

  2. 내용 서버에서 클라이언트 인증을 사용하도록 설정합니다.

클라이언트 인증서를 LDAP로 매핑

이 절에서는 Proxy Server가 클라이언트 인증서를 LDAP 디렉토리의 항목으로 매핑하는 프로세스에 대해 설명합니다. 클라이언트 인증서를 LDAP에 매핑하기 전에 필수 ACL을 구성해야 합니다. 자세한 내용은 8 장서버 액세스 제어를 참조하십시오.

서버가 클라이언트의 요청을 수신하면 이를 처리하기 전에 클라이언트의 인증서를 요구합니다. 클라이언트에 따라 서버에 요청과 함께 클라이언트를 전송하는 경우도 있습니다.

서버는 CA를 Administration Server에 있는 신뢰할 수 있는 CA의 목록과 일치시키려 합니다. 일치 항목이 없으면 Proxy Server는 연결을 종료합니다. 일치 항목이 있으면 서버가 요청 처리를 계속합니다.

신뢰할 수 있는 CA의 인증서임을 확인한 후 서버는 다음과 같이 인증서를 LDAP 항목으로 매핑합니다.

서버는 certmap.conf라는 인증서 매핑 파일을 사용하여 LDAP 검색이 수행되는 방법을 결정합니다. 서버는 매핑 파일에 따라 클라이언트 인증서에서 가져올 값(예: 최종 사용자의 이름, 전자 메일 주소 등)을 결정합니다. 서버는 이 값을 사용하여 LDAP 디렉토리에서 사용자 항목을 검색하지만, 우선 서버가 LDAP 디렉토리에서 검색을 시작할 위치를 결정해야 합니다. 서버는 또한 인증서 매핑 파일에서 시작 위치를 알 수 있습니다.

서버가 검색을 시작할 위치와 검색할 항목을 결정하면 LDAP 디렉토리에서 검색을 수행합니다(두 번째 지점). 일치 항목이 없거나 일치 항목이 여러 개인 경우 인증서를 확인하도록 매핑이 설정되지 않고 검색은 실패합니다.

예상되는 검색 결과의 목록은 다음 표와 같습니다. ACL에서 예상 동작을 지정할 수 있습니다. 예를 들어, 인증서 일치에 실패하면 Proxy Server가 해당사용자만 허용하도록 지정할 수 있습니다. ACL 기본 설정을 지정하는 방법에 대한 자세한 내용은 액세스 제어 파일 사용을 참조하십시오.

표 5–1 LDAP 검색 결과

LDAP 검색 결과 

인증서 검증 ON 

인증서 검증 OFF 

검색된 항목 없음 

인증 실패 

인증 실패 

정확히 한 개 항목 일치 

인증 실패 

인증 성공 

여러 항목 일치 

인증 실패 

인증 실패 

서버가 LDAP 디렉토리에서 일치 항목과 인증서를 찾으면 서버는 해당 정보를 사용하여 트랜잭션을 처리할 수 있습니다. 예를 들어 서버에 따라 인증서 LDAP 매핑을 사용하여 서버에 대한 액세스를 결정합니다.

certmap.conf 파일 사용

인증서 매핑에 따라 서버가 LDAP 디렉토리에서 사용자 항목을 찾는 방법이 결정됩니다. certmap.conf 파일을 사용하여 이름으로 명시된 인증서를 LDAP 항목에 매핑하는 방법을 구성할 수 있습니다. 이 파일을 편집하고 항목을 추가하여 LDAP 디렉토리의 조직과 일치시키고 사용자에게 부여할 인증서 목록을 표시할 수 있습니다. 사용자는 사용자 아이디, 전자 메일 주소 또는 subjectDN에 사용되는 다른 모든 값을 기반으로 인증될 수 있습니다. 특히, 매핑 파일에는 다음의 정보가 정의됩니다.

인증서 매핑 파일은 다음에 있습니다.

server-root/userdb/certmap.conf

파일에는 하나 이상의 이름 매핑이 있으며, 각각의 매핑은 서로 다른 CA에 적용됩니다. 매핑의 구문은 다음과 같습니다.

certmap name issuerDNname :property [ value]

첫 번째 줄은 항목의 이름과 CA 인증서에 있는 고유 이름을 구성하는 속성을 지정합니다. name은 임의이며 원하는 값으로 정의할 수 있습니다. 그러나 issuerDN은 클라이언트 인증서를 발행한 CA의 발행자 DN과 정확하게 일치해야 합니다. 예를 들어, 아래의 발행자 DN 행의 차이는 단지 속성을 구분하는 공백이지만 서버는 이 두 항목을 서로 다른 것으로 처리합니다.

certmap sun1 ou=Sun Certificate Authority,o=Sun,c=UScertmap sun2 ou=Sun Certificate Authority, o=Sun, c=US

주 –

Sun Java System Directory Server를 사용하고 발행자 DN을 일치시키는 데 문제가 발생하는 경우에는 디렉토리 서버 오류 로그에 유용한 정보가 있는지 확인하십시오.

이름 매핑의 두 번째 및 이후 줄은 등록 정보를 값과 매핑합니다. certmap.conf 파일에는 6개의 기본 등록 정보가 있습니다. 인증서 API를 사용하여 자체 등록 정보를 직접 사용자 정의할 수도 있습니다. 기본 등록 정보는 다음과 같습니다.

표 5–2 x509v3 인증서의 속성

속성 

설명 

c

국가 

o

조직 

cn

공통 이름 

l

위치 

st

상태 

ou

조직 단위 

uid

UNIX/Linux 사용자 아이디 

email

전자 메일 주소 

이러한 등록 정보에 대한 자세한 내용은 매핑 예제에 설명된 예를 참조하십시오.

사용자 정의 등록 정보 생성

클라이언트 인증서 API는 자체 등록 정보를 만드는 데 사용할 수 있습니다. 사용자 정의 매핑이 있는 경우 매핑은 다음과 같이 참조합니다.

name:library path_to_shared_libraryname :InitFN name_of_ init_function

예:

certmap default1 o=Sun Microsystems, c=US default1:library /usr/sun/userdb/plugin.so default1:InitFn plugin_init_fn default1:DNComps ou o c default1:FilterComps l default1:verifycert on

매핑 예제

certmap.conf 파일에는 항목이 한 개 이상 있어야 합니다. 다음 예는 certmap.conf를 사용할 수 있는 다양한 방법을 보여줍니다.

예제 #1 한 개의 기본 매핑만 포함된 certmap.conf 파일

certmap default defaultdefault:DNComps ou, o, cdefault:FilterComps e, uiddefault:verifycert on

이 예제를 사용하면 서버는 ou=orgunit, o=org, c=country 항목을 포함하는 LDAP 분기점에서 검색을 시작하며, 여기서 기울임체로 표시된 텍스트는 클라이언트 인증서에 있는 대상 DN의 값으로 대체됩니다.

이후, 서버는 인증서에 있는 전자 메일 주소와 사용자 아이디 값을 사용하여 LDAP 디렉토리에 일치하는 항목이 있는지 검색합니다. 항목이 검색되면 서버는 클라이언트가 전송한 인증서와 디렉토리에 있는 인증서를 비교하여 인증서를 검증합니다.

예제 #2 두 가지 매핑이 있는 certmap.conf 파일

다음 예제 파일에는기본값 및 미국 우편 서비스에 대한 두 가지 매핑이 있습니다.

certmap default defaultdefault:DNCompsdefault:FilterComps e, uid

certmap usps ou=United States Postal Service, o=usps, c=USusps:DNComps ou,o,cusps:FilterComps eusps:verifycert on

서버에 미국 우편 서비스가 아닌 다른 인증서가 수신되면 기본 매핑을 사용합니다. 이 경우 LDAP 트리의 상단에서 시작하여 클라이언트의 전자 메일 및 사용자 아이디와 일치하는 항목을 검색합니다. 미국 우편 서비스의 인증서인 경우 서버는 조직 단위를 포함하는 LDAP 분기에서 검색을 시작하며 일치하는 전자 메일 주소를 검색합니다. 또한 서버는 인증서를 확인합니다. 다른 인증서는 확인되지 않습니다.

주의 – 주의 –

인증서의 발행자 DN(즉, CA 정보)은 반드시 매핑의 첫 번째 행 목록에 있는 발행자 DN과 동일해야 합니다. 앞의 예제에서 o=United States Postal Service,c=US인 발행자 DN의 인증서는 o와 c 속성 사이에 공백이 없으므로 일치되지 않습니다.

예제 #3 LDAP 데이터베이스 검색

다음 예제에서는 CmapLdapAttr 등록 정보를 사용하여 LDAP 데이터베이스에서 certSubjectDN이라는 속성을 검색합니다. 이 속성의 값은 클라이언트 인증서에서 가져온 전체 대상 DN과 정확하게 일치합니다. 이 예제에서는 LDAP 디렉토리에 certSubjectDN 속성이 있는 항목이 포함된 것으로 가정합니다.

certmap myco ou=My Company Inc, o=myco, c=USmyco:CmapLdapAttr certSubjectDNmyco:DNComps o, c myco:FilterComps mail, uid myco:verifycert on

클라이언트 인증서 대상이 다음인 경우,

uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

서버는 우선 다음 정보를 포함한 항목을 검색합니다.

certSubjectDN=uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

일치하는 항목이 하나 이상인 경우에는 서버가 항목을 검증합니다. 일치 항목이 없는 경우 서버는 DNComps 및 FilterComps를 사용하여 일치하는 항목을 검색합니다. 이 예제에서 서버는 o=LeavesOfGrass Inc, c=US의 모든 항목에서 uid=Walt Whitman을 검색합니다.

고급 암호 설정

Server Manager Preferences 탭의 Set Cipher Size 옵션에서는 액세스용으로 168비트, 128비트 또는 56비트 비밀 키 크기를 선택하거나 제한을 설정하지 않을 수 있습니다. 제한에 맞지 않는 경우 서비스될 파일을 지정할 수 있습니다. 파일을 지정하지 않으면 Proxy Server는 Forbidden 상태를 반환합니다.

선택한 액세스용 키 크기가 Security Preferences의 현재 비밀번호 설정과 맞지 않는 경우 Proxy Server에 더 큰 비밀 키로 암호를 활성화해야 한다는 경고가 표시됩니다.

키 크기 제한은 Service fn=key-toosmall이 아니라 obj.conf의 NSAPI PathCheck 지시문을 기준으로 구현됩니다. 지시문은 다음과 같습니다.

PathCheck fn="ssl-check" [secret-keysize=nbits ] [bong-file=filename ]

여기서 nbits는 비밀 키에 필요한 최소 비트 수이며 filename은 제한을 만족하지 않는 경우 서비스될 파일의 이름(URL 아님)입니다.

SSL이 활성화되지 않았거나 secret-keysize 매개 변수가 지정되지 않은 경우 PathCheck는 REQ_NOACTION을 반환합니다. 현재 세션의 비밀 키 크기가 지정된 secret-keysize보다 작은 경우, bong-file이 지정되지 않으면 이 함수는 REQ_ABORTED를 PROTOCOL_FORBIDDEN 상태와 함께 반환합니다. bong-file이 지정된 경우 함수는 REQ_PROCEED를 반환하고 경로 변수가 bong-file filename으로 설정됩니다. 또한 키 크기 제한을 만족하지 않은 경우 현재 세션용 SSL 세션 캐시가 무효화되어 다음 번 클라이언트가 서버로 연결하면 전체 SSL 핸드셰이크가 발생합니다.

주 –

Set Cipher Size 형식을 사용하면 PathCheck fn=ssl-check를 추가할 때 객체에서 검색되는 모든 Service fn=key-toosmall 지시문을 제거합니다.

Procedure고급 암호 설정 방법

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

  2. Set Cipher Size 링크를 누릅니다.

  3. 드롭다운 목록에서 고급 암호를 적용할 자원을 선택하고 Select를 누릅니다. 정규 표현식도 지정할 수 있습니다.

    자세한 내용은 16 장템플리트 및 자원 관리를 참조하십시오.

  4. 비밀 키 크기 제한을 선택합니다.

    • 168비트 이상

      • 128비트 이상

      • 56비트 이상

      • 제한 없음

  5. 액세스를 거부할 메시지의 파일 위치를 지정하고 OK를 누릅니다.

    암호화에 대한 자세한 내용은 SSL 개요를 참조하십시오.

기타 보안 고려 사항

누군가 암호를 해독하려는 시도 외에도 다른 보안 위험이 있습니다. 네트워크는 서버와 서버의 정보에 액세스하려는 다양한 방법을 사용하는 외부 및 내부 해커의 위험에 직면해 있습니다. 서버 암호화 활성화 외에도 추가적인 보안 조치가 필요합니다. 예를 들어, 서버 컴퓨터를 안전한 곳에 배치하거나 신뢰할 수 없는 개인이 서버에 프로그램을 업로드하지 못하도록 해야 합니다다. 이 절에서는 서버의 보안을 강화하기 위해 취할 수 있는 몇 가지 주요 사항에 대해 설명합니다.

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

실제 액세스 제한

이 간단한 보안 수단이 종종 잊혀지고 있습니다. 서버 컴퓨터를 잠금 장치가 있는 곳에 보관하고 권한이 있는 사람만 출입할 수 있도록 합니다. 이 정책을 사용하면 서버 컴퓨터 자체를 해킹할 수 없도록 방지합니다. 또한 컴퓨터의 관리(루트) 비밀번호(있는 경우)를 보호하십시오.

관리 액세스 제한

원격 구성을 사용하는 경우 오직 몇몇의 사용자와 컴퓨터에만 관리를 허용하도록 액세스 제어를 설정해야 합니다. Administration Server가 최종 사용자에게 LDAP 서버나 로컬 디렉토리 정보에 대한 액세스를 제공하도록 하는 경우 두 대의 Administration Server를 유지하고 클러스터 관리를 사용하는 것을 고려하십시오. 그러면 SSL 사용 Administration Server가 마스터 서버 역할을 하고 최종 사용자가 다른 Administration Server에 액세스할 수 있습니다. 클러스터에 대한 자세한 내용은 6 장서버 클러스터 관리을 참조하십시오.

또한 Administration Server에서 암호화를 사용하도록 설정해야 합니다. 관리용 SSL 연결을 사용하지 않는 경우에는 보안되지 않은 네트워크를 통하여 원격 서버 관리를 수행할 때 조심해야 합니다. 누구라도 관리 비밀번호를 가로채어 서버를 재구성할 수 있습니다.

고급 비밀번호 선택

서버에는관리 비밀번호, 개인 키 비밀번호, 데이터베이스 비밀번호 등 여러 개의 비밀번호를 사용합니다. 관리 비밀번호가 있으면 누구라도 컴퓨터에 있는 모든 서버를 구성할 수 있으므로 가장 중요한 비밀번호입니다. 개인 키 비밀번호는 다음으로 중요한 비밀번호입니다. 개인 키와 개인 키 비밀번호가 있으면 사용자의 것으로 보이는 가짜 서버를 만들거나 서버로 오고 가는 통신을 가로채고 변경할 수 있습니다.

좋은 비밀번호는 자신은 기억할 수 있지만 다른 사람은 추측할 수 없는 비밀번호입니다. 예를 들어, MCi12!mo를 "My Child is 12 months old!"로 기억할 수 있습니다. 자녀의 이름이나 생일은 비밀번호로 적합하지 않습니다.

해독하기 어려운 비밀번호

다음 지침을 사용하여 고급 비밀번호를 만드십시오. 하나의 비밀번호에 다음의 규칙을 모두 적용해야 하는 것은 아니지만 더 많은 규칙을 적용할수록 비밀번호를 알아내기가 더욱 어려워질 것입니다. 몇 가지 팁은 다음과 같습니다.

비밀번호 또는 PIN 변경

트러스트 데이터베이스/키 쌍 파일 비밀번호나 PIN을 주기적으로 변경합니다. Administration Server에서 SSL을 사용하는 경우 서버를 시작할 때 이 비밀번호가 필요합니다. 주기적으로 비밀번호를 변경하면 서버 보호를 한 단계 높일 수 있습니다.

이 비밀번호는 로컬 컴퓨터에서만 변경해야 합니다. 비밀번호를 변경할 때 고려해야 하는 지침 목록은 해독하기 어려운 비밀번호를 참조하십시오.

Procedure트러스트 데이터베이스/키 쌍 파일 비밀번호 변경 방법

  1. Administration Server 또는 Server Manager에 액세스하고 Security 탭을 누릅니다.

  2. Change Key Pair File Password 링크를 누릅니다.

  3. Cryptographic Module 드롭다운 목록에서 비밀번호를 변경할 보안 토큰을 선택합니다.

    기본적으로 내부 키 데이터베이스용 내부 토큰입니다. PKCS #11 모듈이 설치된 경우 모든 보안 토큰이 나열됩니다.

  4. 현재 비밀번호를 입력합니다.

  5. 새 비밀번호를 입력합니다.

  6. 새 비밀번호를 다시 입력하고 OK를 누릅니다.

    키 쌍 파일이 보호되는지 확인합니다. Administration Server는 키 쌍 파일을 server-root/alias 디렉토리에 저장합니다.

    파일이 백업 테이프에 저장되어 있는지 또는 다른 사람이 가로챌 수 있는지 확인합니다. 이 경우 백업을 서버와 마찬가지로 완벽하게 보호해야 합니다.

서버에서 기타 응용 프로그램 제한

서버와 동일한 컴퓨터에서 실행되는 모든 응용 프로그램을 신중하게 고려해야 합니다. 서버에서 실행되는 다른 프로그램의 취약점을 악용하여 서버의 보안을 우회할 수 있습니다. 필요하지 않은 모든 프로그램과 서비스를 종료합니다. 예를 들어, UNIX sendmail 데몬은 안전하게 구성하는 것이 어려우며 서버 컴퓨터에서 해로운 프로그램을 실행하도록 프로그램될 수 있습니다.

UNIX 및 Linux

inittab 및 rc 스크립트에서 시작하는 프로세스를 신중하게 선택합니다. 서버 컴퓨터에서 telnet 또는 rlogin을 실행하지 마십시오. 서버 컴퓨터에 rdist가 있으면 안 됩니다. 파일을 분산할 수는 있지만 서버 컴퓨터의 파일을 업데이트하는 데도 사용될 수 있습니다.

Windows

다른 컴퓨터와 공유할 드라이브 및 디렉토리를 신중히 고려합니다. 또한 계정이나 Guest 권한을 부여할 사용자를 고려합니다. 서버에 설치하거나 다른 사람이 설치할 수 있도록 허용할 프로그램을 신중하게 고려합니다. 다른 사람의 프로그램에는 보안 취약점이 있을 수 있습니다. 또한 특히 보안을 손상시키도록 디자인된 악의적 프로그램을 업로드할 수도 있습니다. 서버에서 프로그램을 허용하기 전에 신중하게 프로그램을 평가해야 합니다.

클라이언트가 SSL 파일을 캐시하지 못하도록 방지

HTML 파일의 <HEAD> 부분에 다음 행을 추가하여 클라이언트가 미리 암호화된 파일을 캐시할 수 없도록 방지할 수 있습니다.

<meta http-equiv="pragma" content="no-cache">

포트 제한

컴퓨터에서 사용되지 않는 포트는 모두 비활성화합니다. 라우터 또는 방화벽 구성을 사용하여 절대적인 최소 포트 이외로 들어오는 연결을 차단합니다. 이 보호 기능을 적용하면 이미 제한된 영역에 위치한 서버의 컴퓨터를 사용할 때에만 컴퓨터에서 쉘을 사용할 수 있게 됩니다.

서버의 한계 파악

서버는 서버와 클라이언트 사이에 안전한 연결을 제공합니다. 클라이언트가 일단 정보를 보유하면 정보의 보안을 제어할 수 없으며 서버 컴퓨터 자체와 해당 디렉토리 및 파일에 대한 액세스를 제어할 수 없습니다.

이러한 제한을 알고 있으면 피해야 할 상황을 이해하는 데 도움이 됩니다. 예를 들어, SSL 연결을 통해 신용 카드 번호를 구할 수 있으나 이 번호가 서버 컴퓨터의 보안 파일에 저장되어 있을까요? SSL 연결이 종료된 후 이 번호는 어떻게 될까요? 클라이언트가 SSL을 통해 전송하는 모든 정보를 보안해야 합니다.