| Sun ONE Web Server 6.1 관리자 설명서 |
6 장
인증서 및 키 사용이 장에서는 인증서 및 키 인증을 사용하여 Sun ONE Web Server 6.1의 보안을 강화하는 방법에 대하여 설명합니다. 또한 다양한 보안 기능을 사용하여 데이터를 보호하고 침입자 액세스를 거부하며 원하는 사용자의 액세스만 허용하는 방법에 대하여 설명합니다. Sun ONE Web Server 6.1에는 모든 Sun ONE 서버의 보안 아키텍처가 포함되어 있으며, 이 아키텍처는 최대의 상호 운영성과 일관성을 위하여 업계 표준 및 공용 프로토콜을 기반으로 구축되었습니다.
이 장을 읽기 전에 공용 키 암호화에 대한 기본 개념을 알고 있어야 합니다. 이 개념에는 암호화 및 복호화, 공용 및 개인 키, 전자 인증서, 암호화 프로토콜 등이 포함됩니다. 자세한 내용은 SSL 개요를 참조하십시오.
웹 서버를 보안하는 과정은 다음 부분에서 자세히 설명합니다.
인증서 기반 인증인증은 신분을 확인하는 과정입니다. 네트워크 상호작용이라는 맥락에서 인증은 한 쪽이 다른 쪽의 신분을 명확히 확인하는 것입니다. 인증서는 인증을 지원하는 방법 중 한 가지입니다.
인증용 인증서 사용
인증서는 개인, 회사 또는 기타 단체의 이름을 명시하는 디지털 데이터로 구성되며 인증서에 포함된 공용 키가 해당 단체의 소유인지 검사합니다. 클라이언트와 서버는 모두 인증서를 가질 수 있습니다.
인증서는 인증 기관(또는 CA)이 발행하고 전자적으로 서명합니다. CA는 인터넷에서 인증서를 판매하는 회사일 수도 있으며 회사의 인트라넷 또는 익스트라넷용으로 인증서를 발행하는 부서일 수도 있습니다. 다른 사람의 신분을 확인하는데 충분히 신뢰할 수 있는 CA를 선택합니다.
인증서에 의하여 확인되는 공용 키와 단체의 이름에 더하여 인증서에는 또한 만기일, 인증서를 발행한 CA의 이름 및 발행 CA의 "전자 서명"이 포함됩니다. 인증서의 내용과 형식에 대한 자세한 내용은 SSL 개요를 참조하십시오.
서버 인증
서버 인증이란 클라이언트가 서버의 신분을 확인하는 것을 말합니다. 즉, 특정 네트워크 주소에서 서버에 대한 책임이 있는 단체의 신분을 확인하는 것입니다.
클라이언트 인증
클라이언트 인증이란 서버가 클라이언트의 신분을 확인하는 것으로, 즉, 클라이언트 소프트웨어를 사용하는 사람의 신분을 확인하는 것입니다. 개인이 여러 개의 신분증을 가질 수 있는 것처럼 클라이언트에는 여러 개의 인증서가 있을 수 있습니다.
가상 서버 인증서
각 가상 서버마다 다른 인증서 데이터베이스를 부여할 수 있습니다. 각 가상 서버 데이터베이스에는 여러 개의 인증서가 있을 수 있습니다. 가상 서버에는 또한 각 인스턴스마다 서로 다른 인증서가 있을 수 있습니다.
신뢰 데이터베이스 생성서버 인증서를 요청하기 전에 반드시 신뢰할 수 있는 데이터베이스를 만들어야 합니다. Sun ONE Web Server에서는 Administration Server와 각 서버 인스턴스에 자체의 신뢰 데이터베이스를 부여할 수 있습니다. 신뢰 데이터베이스는 오직 로컬 컴퓨터에 만들어야 합니다.
신뢰 데이터베이스를 만들 때 키쌍 파일용으로 사용할 암호를 지정합니다. 또한 암호화된 통신을 사용하여 서버를 시작할 때에도 이 암호가 필요합니다. 암호를 변경하는 경우 고려해야 할 지침은 "암호 또는 PIN 변경"를 참조하십시오.
신뢰 데이터베이스에서 공용 및 개인 키를 만들고 저장할 수 있습니다. 이는 키쌍 파일이라고 합니다. 키쌍 파일은 SSL 암호화에 사용됩니다. 키쌍 파일은 서버 인증서를 요청하고 설치할 때 사용합니다. 인증서가 설치되면 신뢰 데이터베이스에 저장됩니다. 키쌍 파일은 다음 디렉토리에 암호화되어 저장됩니다.
Administration Server에는 오직 하나의 신뢰 데이터베이스만 있습니다. 각 서버 인스턴스에는 자체의 신뢰 데이터베이스를 부여할 수 있습니다. 가상 서버는 해당 서버 인스턴스용으로 만들어진 신뢰 데이터베이스를 사용합니다.
신뢰 데이터베이스 생성
신뢰 데이터베이스를 만들려면 다음과 같이 합니다.
password.conf 사용
기본적으로 시작하기 전에 관리자에게 키 데이터베이스 암호를 입력하라는 프롬프트가 웹 서버에 표시됩니다. 무인 작업으로 웹 서버를 재시작하려는 경우에는 암호를 password.conf 파일에 저장해 놓아야 합니다. 시스템이 적절히 보호되어 이 파일과 암호 데이터베이스가 조작되지 않을 경우에만 이 기능을 사용하십시오.
보통 UNIX SSL을 사용하는 서버의 경우 시작하기 전에 암호가 필요하므로 etc/rc.local 또는 etc/inittab 파일을 사용할 수 없습니다. 암호를 일반 텍스트 파일에 저장하여 SSL을 사용하는 서버를 자동으로 시작할 수는 있으나, 이는 권장하지 않습니다. 서버의 password.conf 파일은 루트 또는 서버를 설치한 사용자의 소유여야 하며, 오직 소유자만 이 파일을 읽고 쓸 수 있어야 합니다.
UNIX의 경우 SSL을 사용하는 서버의 암호를 password.conf 파일에 남겨두면 보안상의 위험이 커집니다. 파일에 액세스할 수 있는 사용자는 모두 SSL을 사용하는 서버의 암호를 알 수 있습니다. SSL을 사용하는 서버의 암호를 password.conf 파일에 보관하기 전에 보안의 위험에 대하여 고려해야 합니다.
Windows에서 NTSF 파일 시스템을 사용하는 경우, password.conf 파일을 사용하지 않는 경우라도 이 파일이 들어 있는 디렉토리에 대한 액세스를 제한하여 보호해야 합니다. 디렉토리에는 관리 서버 사용자 및 웹 서버 사용자용 읽기/쓰기 권한이 있어야 합니다. 디렉토리를 보호하면 다른 사람이 잘못된 password.conf 파일을 만들 수 없도록 방지합니다. FAT 파일 시스템의 경우 액세스를 제한하는 경우에도 디렉토리를 보호할 수 없습니다.
SSL 사용 서버 자동 시작
보안의 위험을 걱정하지 않는 경우 다음과 같이 SSL을 사용하는 서버를 자동으로 시작할 수 있습니다.
password.conf 파일을 만든 후라도 웹 서버를 시작할 때에는 항상 암호를 입력하라는 프롬프트가 표시됩니다.
VeriSign 인증서 요청 및 설치VeriSign은 Sun ONE Web Server에서 자주 사용되는 인증 기관입니다. VeriSign의 VICE 프로토콜을 사용하면 인증서 요청 프로세스를 간단히 할 수 있습니다. VeriSign에는 인증서를 사용자의 서버로 직접 회신할 수 있다는 장점이 있습니다.
서버용 인증서 신뢰 데이터베이스를 만든 후 인증서를 요청하고 이를 인증기관(CA)에 제출할 수 있습니다. 회사에 내부 CA가 있는 경우에는 해당 CA로 인증서를 요청합니다. 상용 CA로부터 인증서를 구매할 계획인 경우에는 CA를 선택하고 필요한 정보의 형식이 있는지 문의합니다. Request a Certificate 페이지에 사용 가능한 인증 기관 목록과 해당 사이트로의 링크가 있습니다. CA에 필요한 것에 대한 더 자세한 내용은 Request a Certificate에 있는 Server Administrator 또는 Server Manager Security 페이지에 있는 인증 기관 목록을 참조하십시오.
Administration Server에는 오직 하나의 서버 인증서만 부여할 수 있습니다. 각 서버 인스턴스에는 자체의 서버 인증서를 부여할 수 있습니다. 각 가상 서버에 대하여 서버 인스턴스 인증서를 선택할 수 있습니다.
VeriSign 인증서 요청
VeriSign 인증서를 요청하려면 다음과 같이 합니다.
VeriSign 인증서 설치
VeriSign 인증서를 요청하고 이에 대한 승인을 받으면 3일 이내에 Install VeriSign Certificate 페이지의 드롭 다운 목록에 인증서가 표시됩니다. VeriSign 인증서를 설치하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Install VeriSign Certificate 링크를 누릅니다.
- 외부 암호화 모듈을 사용하지 않는 경우, 암호화 모듈용 드롭 다운 목록에서 internal(software)를 선택합니다.
- 키 쌍 파일 암호 또는 PIN을 입력합니다.
- 드롭 다운 목록에서 Transaction ID to Retrieve를 선택합니다.
보통 마지막 항목을 선택합니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
기타 서버 인증서 요청 및 설치VeriSign 외에도 다른 인증 기관에 인증서를 요청하여 설치할 수 있습니다. Request a Certificate의 Server Administrator와 Server Manager Security 페이지에 사용 가능한 CA 목록이 있습니다. 회사나 조직에서 자체의 내부 인증서를 제공할 수도 있습니다. 여기에서는 다른 종류의 서버 인증서를 요청하고 설치하는 방법에 대하여 설명합니다.
필수 CA 정보
요청 프로세스를 시작하기 전에 CA가 요구하는 정보가 무엇인지 알아야 합니다. 상용 CA 또는 내부 CA 중 어느 곳에 서버 인증서를 요청할 것인가에 상관 없이 다음 정보를 제공해야 합니다.
- Email Address는 업무용 전자우편 주소입니다. 이 주소는 CA와의 의견교환을 위하여 사용됩니다.
- Organization에는 회사, 교육 기관, 협력관계 등의 공식적, 법적 이름을 지정합니다. 대부분의 CA는 정보에 대하여 법적 서류(사업자 등록 등)로 확인할 것을 요구합니다.
- Organizational Unit에는 회사 내의 조직에 대한 설명을 입력하는 선택 필드입니다. 또한 비공식적인 회사 이름을(주식회사, 법인 등을 제외하고) 알리는 데 사용할 수 있습니다.
- Locality는 선택 필드로 조직의 소재 시/도 또는 국가를 입력합니다.
- State or Province는 보통 필수 항목이 아니지만 CA에 따라 요구하는 경우도 있습니다. 대부분의 CA는 약자를 허용하지 않으나, 해당 CA에 확인하는 것이 좋습니다.
- Country는 필수 필드로 국가 이름의 두 자리 약자를 지정합니다. (ISO 형식) 미국의 국가 코드는 US입니다.
이 모든 정보는 DN(Distinguished Name)이라고 하는 일련의 속성-값 쌍으로 조합되어 인증서의 개체를 고유하게 구분합니다.
상용 CA에서 인증서를 구매하는 경우에는 반드시 CA에 연락하여 인증서를 발행하기 위하여 필요한 추가 정보가 있는지 확인해야 합니다. 대부분의 CA는 신분에 대한 증명을 요구합니다. 예를 들어, 회사 이름에 대한 확인, 회사가 서버를 관리하도록 지정한 사용자 등을 확인하며 사용자가 제공하는 정보를 사용할 법적 권한이 있는지 확인할 것입니다.
일부 상용 CA는 완벽한 신분을 제공하는 조직이나 개인에게 더 자세하고 정확한 인증서를 제공합니다. 예를 들어, 사용자가 www.sun.com 컴퓨터에 대한 관리의 권한이 사용자에게 있는지 확인하지 않았으나, 3년간 경영해온 회사로 유의할 고객 소송이 없었다는 사실을 표시하는 인증서를 구매할 수 있습니다.
기타 서버 인증서 요청
인증서를 요청하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Request a Certificate 링크를 누릅니다.
- 신규 인증서인지 또는 인증서 갱신인지 선택합니다.
인증서는 대부분 6개월이나 1년 등, 일정 시간이 경과하면 무효화됩니다. CA에 따라 자동으로 갱신을 송신하는 경우도 있습니다.
- 인증서용 요청을 제출하는 방법을 지정하려면 다음과 같이 합니다.
- CA에 전자우편 메시지로 요청서를 송신해야 하는 경우에는 CA Email을 선택하고 CA의 전자우편 주소를 입력합니다. CA의 목록을 보려면 List of available certificate authorities를 누릅니다.
- Netscape Certificate Server를 사용하는 내부 CA에 인증서를 요청하려면 CA URL을 누르고 Certificate Server용 URL을 입력합니다. 이 URL은 인증서 요청을 처리하는 인증서 서버의 프로그램을 가리키는 URL이어야 합니다. URL 예: https://CA.mozilla.com:444/cms.
- 드롭 다운 목록에서 인증서를 요청할 때 사용할 키쌍 파일용 암호화 모듈을 선택합니다.
- 키쌍 파일용 암호를 입력합니다.
내부 모듈이 아닌 다른 암호화 모듈을 선택하지 않은 한, 이 암호는 신뢰 데이터를 만들 때 지정한 암호입니다. 서버는 암호를 사용하여 개인 키를 구하고 CA로 전송되는 메시지를 암호화합니다. 그런 후, 서버는 공용 키와 암호화된 메시지를 모두 CA로 전송합니다. CA는 공용 키를 사용하여 메시지를 해독합니다.
- ID 정보를 입력합니다.
이 정보의 형식은 CA에 따라 다릅니다. 이 필드에 대한 일반적인 설명은 Request a Certificate에 있는 Server Administrator 또는 Server Manager Security 페이지에 있는 인증 기관 목록을 참조하십시오. 참고로 이 정보의 대부분은 인증서 갱신의 경우에는 필요하지 않습니다.
- 입력한 사항이 정확한지 다시 한 번 확인합니다.
정보가 정확할 수록 인증서가 더욱 빨리 승인될 수 있습니다. 요청이 서버 인증을 위한 것인 경우에는 요청을 제출하기 전에 양식 정보를 확인하라는 프롬프트가 표시될 것입니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
서버가 정보를 포함하는 인증서 요청을 생성합니다. 요청에는 개인 키를 사용하여 만든 전자 서명이 포함됩니다. CA는 전자 서명을 사용하여 요청이 서버 컴퓨터에서 CA로 라우팅되는 동안 조작되지 않았는지 검사합니다. 드물지만 요청이 조작된 경우에는 보통 CA가 전화를 통하여 사용자에게 문의합니다.
요청을 전자우편으로 보내는 경우 서버가 요청이 포함된 전자우편 메시지를 작성하고 메시지를 CA로 전송합니다. 이 후, 보통 인증서는 전자우편을 통하여 회신됩니다. 대신 인증 서버의 URL을 지정하는 경우에는 서버가 URL을 사용하여 요청을 Certificate Server에 제출합니다. CA에 따라 회신은 전자우편을 통하거나 다른 방법을 통하여 수신됩니다.
CA가 인증서 발행에 동의하는 경우 해당 사실을 통지합니다. 대부분의 경우 CA는 전자우편을 통하여 인증서를 전송합니다. 회사에서 인증 서버를 사용하는 경우 인증서 서버의 폼을 사용하여 인증서를 검색할 수 있습니다.
참고
상용 CA로 인증서를 요청하는 모든 사람에게 인증서가 발행되는 것은 아닙니다. 많은 CA가 인증서를 발행하기 전에 신분 증명을 요구합니다. 또한 승인에는 하루에서 두 달까지 걸릴 수 있습니다. 사용자는 CA에 필요한 정보를 모두 신속히 제공할 책임이 있습니다.
인증서를 받은 후, 이를 설치할 수 있습니다. 그 동안에는 SSL 없이 서버를 계속 사용할 수 있습니다.
기타 서버 인증서 설치
CA에서 인증서를 수신하면 인증서는 공용 키로 암호화되므로 오직 귀사만 이를 해독할 수 있습니다. 오직 정확한 신뢰 데이터베이스용 암호를 입력해야만 인증서를 해독하고 설치할 수 있습니다.
인증서에는 세 가지 유형이 있습니다.
인증서 체인이란 연속적인 인증 기관이 서명한 일련의 계층적 인증서를 말합니다. CA 인증서는 인증기관(CA)을 확인하고 해당 기관이 발행한 인증서에 서명하는 데 사용됩니다. 이 CA 인증서는 다시 상위 CA의 CA 인증서에 의하여 서명되는 과정을 되풀이하여 루트 CA의 서명까지 이어집니다.
참고
CA가 자동으로 인증서를 보내지 않는 경우에는 요청해야 합니다. 많은 CA가 귀사의 인증서가 있는 전자우편에 자체의 인증서를 포함하며, 서버는 이 두 인증서를 동시에 설치합니다.
CA에서 인증서를 수신하면 인증서는 공용 키로 암호화되므로 오직 귀사만 이를 해독할 수 있습니다. 인증서를 설치하면 서버는 지정한 키 쌍 파일 암호를 사용하여 이를 해독합니다. 전자우편을 서버에 액세스할 수 있는 다른 위치에 저장하거나 전자우편의 텍스트를 복사한 후 Install Certificate 폼의 해당 위치에 붙여 넣을 수 있도록 합니다.
인증서 설치
인증서를 설치하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Install Certificate 링크를 누릅니다.
- 설치하는 인증서의 유형을 선택합니다.
- 드롭 다운 목록에서 Cryptographic Module을 선택합니다.
- 키쌍 파일 암호를 입력합니다.
- 인증서가 이 서버 인스턴스용으로만 사용될 경우에는 인증서 이름 필드를 입력하지 않습니다. 그렇지 않은 경우에는 다음과 같이 합니다.
- Multiple certificates will be used for virtual servers
서버 인스턴스에 고유한 인증서 이름을 입력합니다.
- Cryptographic modules other than internal are used
단일 암호화 모듈에 있는 모든 서버 인스턴스에 대하여 고유한 인증서 이름을 입력합니다.
이름을 입력하면 Manage Certificates 목록에 표시되므로 설명적인 이름을 입력하십시오. 예를 들어 "United States Portal Service CA"는 CA의 이름이며 "VeriSign Class 2 Primary CA"는 CA와 인증서 유형을 모두 나타냅니다. 인증서 이름을 입력하지 않으면 기본 값이 적용됩니다.
- 다음 중 한 가지를 선택합니다.
- OK를 누릅니다.
- 다음 중 한 가지를 선택합니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
인증서는 서버의 인증서 데이터베이스에 저장됩니다. 파일 이름은 <별칭>-cert8.db입니다. 예:
업그레이드시 인증서 이전iPlanet Web Server 4.1이나 6.0에서 이전하는 경우 신뢰 및 인증서 데이터베이스를 포함하여 사용 중인 파일이 자동으로 업데이트됩니다.
키쌍 파일 및 인증서는 서버의 보안 기능을 사용하는 경우에만 이전됩니다. 또한 Administration Server 페이지와 Server Management 페이지에 있는 Security 탭을 사용하여 키와 인증서를 이전할 수 있습니다.
이전 버전의 경우 인증서와 키쌍 파일은 여러 서버 인스턴스가 사용할 수 있는 별칭에 의하여 참조되었습니다. Administration Server가 모든 별칭과 해당 구성 인증서를 관리했습니다. Sun ONE Web Server 6.1의 경우 Administration Server와 각 서버 인스턴스에는 자체의 인증서 및 키쌍 파일이 있으며, 이는 별칭이 아닌 신뢰 인증서라고 합니다.
Administration Server의 경우에는 그 자체에서, 서버 인스턴스의 경우에는 Server Manager에서 서버 인증서와 모든 포함된 인증 기관을 포함하여 신뢰 데이터베이스와 해당 구성 인증서를 관리합니다. 이제 인증서와 키쌍 데이터베이스 파일은 이를 사용하는 서버 인스턴스의 이름을 따라 이름이 지정됩니다. 이전 버전에서 여러 서버 인스턴스가 동일한 별칭을 공유한 경우, 이전된 인증서와 키쌍 파일의 이름은 새로운 서버 인스턴스용으로 변경됩니다.
서버 인스턴스와 연결된 신뢰 데이터베이스 전체가 이전됩니다. 이전 데이터베이스에 있는 모든 인증기관 목록이 Sun ONE Web Server 6.1 데이터베이스로 이전됩니다. CA가 중복되는 경우 유효 기간 동안 이전 CA를 사용합니다. 중복되는 CA를 삭제하면 안 됩니다.
내장 루트 인증서 모듈 사용.
동적으로 로드할 수 있는 루트 인증서 모듈이 Sun ONE Web Server 6.1에 포함되어 있으며, 여기에는 VeriSign을 비롯하여 많은 CA용 루트 인증서가 있습니다. 루트 인증서 모듈을 사용하면 이전보다 훨씬 쉽게 루트 인증서를 신규 버전으로 업그레이드할 수 있습니다. 이전에는 오래된 루트 인증서를 한 번에 하나씩 삭제하고 새 인증서를 한 번에 하나씩 설치해야 했습니다. 이제 잘 알려진 CA 인증서를 설치하는 경우, 간단히 Sun ONE Web Server의 신규 버전이나 Service Pack이 발표될 때 루프 인증서 모듈 파일을 신규 버전으로 업데이트하면 됩니다.
루트 인증서는 PKCS#11 암호화 모듈로 구현되므로 여기에 포함된 루트 인증서는 삭제할 수 없으며, 해당 인증서를 관리하는 경우 삭제 옵션은 사용할 수 없게 됩니다. 서버 인스턴스에서 루트 인증서를 제거하려면 서버의 alias 파일에서 다음을 삭제하여 루트 인증서 모듈을 사용하지 않도록 설정해야 합니다.
이 후, 루트 인증서 모듈을 복구하려면 bin/https/lib (UNIX 및 HP) 또는 bin\https\bin(Windows)에서 확장 기능을 별칭 하위 디렉토리로 복사하면 됩니다.
루트 인증서의 신뢰 정보를 수정할 수 있습니다. 신뢰 정보는 루트 인증서 모듈 그 자체가 아니라 편집하는 서버 인스턴스용 인증서 데이터베이스에 기록되어 있습니다.
인증서 관리서버에 설치된 다양한 인증서의 신뢰 설정을 확인, 삭제 또는 편집할 수 있습니다. 여기에는 귀사 자체의 인증서와 CA의 인증서가 포함됩니다.
인증서 목록을 관리하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Manage Certificates 링크를 누릅니다.
- 관리하려는 Certificate Name을 누릅니다.
해당 유형의 인증서에 대한 관리 옵션이 있는 Edit Server Certificate 페이지가 표시됩니다. 오직 CA 인증서의 경우에만 클라이언트 신뢰를 설정 또는 해제할 수 있습니다. 외부 암호화 모듈에 따라 인증서를 삭제할 수 없는 경우도 있습니다.
Edit Server Certificate
- Edit Server Certificate 창에서 다음 옵션을 선택할 수 있습니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
인증서 정보에는 소유자와 발행자가 표시됩니다.
신뢰 설정을 이용하여 클라이언트 신뢰를 설정하거나 서버 신뢰를 해제할 수 있습니다. LDAP 서버 인증서의 경우 서버가 반드시 신뢰되어야 합니다.
CRL 및 KRL 설치/관리인증서 철회 목록(CRL)과 변조된 키 목록(CKL)은 클라이언트나 서버 사용자가 더 이상 신뢰하면 안 되는 인증서를 표시합니다. 예를 들어 인증서의 유효기간이 끝나기 전에 사용자가 사무실을 이전하거나 퇴사하는 등 인증서의 데이터가 변경되면 인증서는 취소되며 CRL에 해당 데이터가 표시됩니다. 키가 조작 또는 변형되는 경우 해당 키와 데이터가 CKL에 표시됩니다. CRL과 CKL은 모두 CA에 의하여 만들어지고 주기적으로 업데이트됩니다.
CRL 또는 CKL 설치
CA에서 CRL 또는 CKL을 받으려면 다음과 같이 합니다.
- CRL이나 CKL을 다운로드할 CA의 URL을 확인합니다.
- 브라우저에 URL을 입력하여 사이트로 이동합니다.
- CA의 설명에 따라 CRL 또는 CKL을 로컬 디렉토리로 다운로드합니다.
- Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Install CRL/CKL 링크를 누릅니다.
- 다음 중 한 가지를 선택합니다.
- 해당 파일의 전체 경로 이름을 입력합니다.
- OK를 누릅니다.
- Add를 누릅니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
CRL 및 CKL 관리
CRL과 CKL을 관리하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Manage CRL/CKLs 링크를 누릅니다.
Manage Certificate Revocation List/Compromised Key List 페이지가 나타나며 설치된 서버의 CRL과 CKL 목록이 유효 기간과 함께 표시됩니다.
- Server CRL 또는 Server CKL 목록에서 Certificate Name을 선택합니다.
- 옵션:
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
보안 기본 설정인증서를 만든 후, 서버의 보안 작업을 시작할 수 있습니다. Sun ONE Web Server에는 다양한 보안 요소가 제공됩니다.
암호화는 정보를 변환하여 의도된 수신자 외에 아무도 알아볼 수 없도록 하는 프로세스입니다. 해독화는 암호화된 정보를 변환하여 다시 알아볼 수 있도록 하는 프로세스입니다. Sun ONE Web Server 6.1은 SSL 및 TLS 암호화 프로토콜을 지원합니다.
암호는 암호화 알고리즘(수학적 함수)으로 암호화 또는 해독화에 사용됩니다. SSL 및 TLS 프로토콜에는 다양한 암호 제품군이 포함됩니다. 보안의 안전성과 강도는 암호마다 다릅니다. 일반적으로 암호가 사용하는 비트의 수가 많을 수록 데이터를 해독하는 것이 어렵습니다.
양방향 암호화 프로세스에서 양쪽에는 반드시 동일한 암호가 있어야 합니다. 다양한 암호를 사용할 수 있으므로 서버를 가장 공통적으로 사용되는 암호용으로 설정해야 합니다.
보안 연결에서 클라이언트와 서버는 양쪽이 통신에 사용할 수 있는 가장 강력한 암호화를 사용하도록 동의합니다. 암호는 SSL2, SSL3 및 TLS 프로토콜 중 선택할 수 있습니다.
참고
SSL 버전 2.0 이후 보안과 성능이 향상되었으므로 SSL3를 사용할 수 있는 클라이언트가 아닌 경우에는 SSL2를 사용하면 안 됩니다. 클라이언트 인증서가 SSL 2 암호와 작동되도록 보장되지 않습니다.
암호화 프로세스 그 자체로는 서버의 비밀 정보를 보안하는 데 충분하지 않습니다. 실제의 암호화 결과를 얻거나 이전에 암호화된 정보를 해독하려면 암호화 암호와 함께 키가 사용되어야 합니다. 암호화 프로세스에는 이 결과를 위하여 공용 키와 개인 키의 두 가지 키가 사용됩니다. 공용 키로 암호화된 정보는 오직 연결된 개인 키로만 해독할 수 있습니다. 공용 키는 인증서의 일부로 만들어지며 오직 연결된 개인 키만 보호됩니다.
다양한 암호 제품군에 대한 설명과 키 및 인증서에 대한 자세한 내용은 SSL 개요를 참조하십시오.
서버가 사용할 수 있는 암호를 지정하려면 목록에서 해당 목록을 선택합니다. 특정 암호를 사용하면 안 되는 충분한 이유가 있지 않는 한, 모두 선택해야 합니다. 그러나 최적 암호화에 미치지 않는 암호를 사용하지는 않을 것입니다.
주의
"No Encryption, only MD5 message authentication"을 선택하면 안 됩니다. 클라이언트 측에 사용 가능한 다른 암호가 없는 경우 서버는 설정을 기본값으로 되돌리며 암호화가 수행되지 않습니다.
SSL 및 TLS 프로토콜
Sun ONE Web Server 6.1은 암호화 통신용으로 SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 프로토콜을 지원합니다. SSL과 TLS는 응용 프로그램 종속적인 고수준 프로토콜로 응용 프로그램에 투명하게 배치될 수 있습니다.
SSL과 TLS 프로토콜은 서버와 클라이언트가 서로를 인증하고, 인증서를 전송하며 세션 키를 설정하는 등의 작업에 사용되는 다양한 암호를 지원합니다. 클라이언트와 서버는 지원하는 프로토콜, 암호화 정도에 대한 회사 정책, 암호화된 소프트웨어의 수출에 대한 정부 규제 등, 다양한 요인에 따라 지원하는 암호 제품군이 달라집니다. 다른 기능 중 SSL과 TLS 핸드셰이크 프로토콜에 따라 서버와 클라이언트가 통신에 사용할 암호 제품군을 선택하는 방식이 결정됩니다.
LDAP와의 통신에 SSL 사용
Administration Server는 SSL을 사용하여 LDAP와 통신하도록 해야 합니다. Administration Server에서 SSL을 사용하도록 설정하려면 다음과 같이 합니다.
청취 소켓용 보안 사용 설정
다음과 같이 서버의 청취 소켓을 보안할 수 있습니다.
보안 기능 사용
청취 소켓용으로 다른 보안 설정을 구성하기 전에 반드시 보안을 사용하도록 설정해야 합니다. 보안은 새 청취 소켓을 만들거나 기존 청취 소켓을 편집할 때 사용 설정할 수 있습니다.
청취 소켓을 만들 때 보안 기능 사용 설정
새 청취 소켓을 만들 때 보안 기능을 사용하도록 설정하려면 다음과 같이 합니다.
청취 소켓을 편집할 때 보안 기능 사용 설정
또한 Administration Server나 Server Manager에서 청취 소켓을 편집할 때 보안을 사용하도록 설정할 수 있습니다. 청취 소켓을 편집할 때 보안 기능을 사용하도록 설정하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Security 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Preference 탭이 표시되지 않았으면 선택하여 표시합니다.
- Edit Listen Sockets 링크를 선택합니다.
Edit Listen Sockets 페이지가 표시됩니다.
- 청취 소켓을 편집하려면 편집하려는 청취 소켓의 Listen Socket ID를 누릅니다.
Edit Listen Socket 페이지가 표시됩니다.
- 해당 청취 소켓의 보안을 사용하려면 Security 드롭 다운 목록에서 Enabled를 선택합니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
청취 소켓용 서버 인증서 선택
Administration Server나 Server Manager에서 청취 소켓을 구성하여 요청 및 설치한 서버 인증서를 사용할 수 있습니다.
청취 소켓이 사용할 서버 인증서를 선택하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Edit Listen Sockets 링크를 선택합니다.
Edit Listen Sockets 페이지가 표시됩니다.
- 청취 소켓을 편집하려면 편집하려는 청취 소켓의 Listen Socket ID를 누릅니다.
Edit Listen Socket 페이지가 표시됩니다.
- 해당 청취 소켓의 보안을 사용하려면 Security 드롭 다운 목록에서 Enabled를 선택합니다.
.
- Server Certificate 드롭 다운 목록에서 해당 소켓용 서버 인증서를 선택합니다.
이 목록에는 설치된 모든 내부 및 외부 인증서가 표시됩니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
암호 선택
웹 서버의 안전을 보호하려면 SSL을 사용하도록 설정해야 합니다. SSL 2.0, SSL 3.0 및 TLS 암호화 프로토콜을 선택할 수 있으며 다양한 암호 제품군을 선택할 수 있습니다. SSL과 TLS는 Administration Server용 청취 소켓에서 사용하도록 설정할 수 있습니다. Server Manager용 청취 소켓에서 SSL 및 TLS를 사용하면 해당 청취 소켓에 연결된 모든 가상 서버용 보안 기본 설정이 설정됩니다.
보안되지 않은 가상 서버를 원하는 경우, 해당 서버는 모두 보안을 사용하지 않도록 설정된 동일한 청취 소켓에 구성되어야 합니다.
기본 설정의 경우 가장 많이 사용되는 암호를 허용합니다. 특정 암호를 사용하면 안 되는 충분한 이유가 있지 않는 한, 모두 허용해야 합니다. 특정 암호에 대한 자세한 내용은 SSL 개요를 참조하십시오.
tlsrollback 매개 변수의 기본 및 권장 설정은 true입니다. 이렇게 구성하면 서버가 중간개입자(man-in-the-middle) 버전 롤백 공격 시도를 감지할 수 있습니다. TLS 표준을 잘못 구현한 일부 클라이언트와의 상호 운용성을 위하여 이 설정을 false로 해야 하는 경우도 있습니다.
tlsrollback을 false로 설정하면 연결이 버전 롤백 공격에 취약해진다는 점에 유의하십시오. 버전 롤백 공격은 제3자가 클라이언트와 서버로 하여금 SSLv2 등의 덜 안전한 이전 프로토콜을 사용하도록 하는 메커니즘입니다. SSLv2에는 알려진 결함이 있으므로 버전 롤백 공격을 감지하지 못하는 경우 제3자가 암호화된 연결을 가로채어 해독할 수 있습니다.
SSL 및 TLS를 사용하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Edit Listen Sockets 링크를 누릅니다.
Edit Listen Sockets 페이지가 표시됩니다. 보안 청취 소켓에 대하여 Edit Listen Socket 페이지에 사용 가능한 암호 설정이 표시됩니다.
참고
청취 소켓에서 Security가 사용되지 않는 경우에는 SSL 및 TLS 정보가 표시되지 않습니다. 암호를 사용하려면 선택한 청취 소켓에서 보안이 사용되도록 설정해야 합니다. 더 자세한 내용은 "청취 소켓용 보안 사용 설정"를 참조하십시오.
- 필요한 암호화 설정에 해당하는 선택란을 선택합니다.
- OK를 누릅니다.
서버에서 SSL을 사용 설정하면 URL은 http가 아닌 https를 사용합니다. SSL을 사용하는 서버의 문서를 가리키는 URL의 형식은 다음과 같습니다.
예: https://admin. admin.sun.com:443.
기본 보안 http 포트 번호(443)을 사용하는 경우 URL에 포트 번호를 입력하지 않아도 됩니다.
전역적 보안 구성
SSL을 사용하는 서버를 설치하면 magnus.conf파일(서버의 기본 구성 파일)에 전역 보안 매개 변수용 지시문 항목이 만들어집니다. 가상 서버 보안 설정이 작동하려면 Security가 반드시 "on"으로 설정되어야 합니다. 가상 서버용 SSL 등록 정보는 각 서버별로 server.xml 파일의 SSLPARAMS 요소에 있습니다.
SSL 구성 파일 지시문의 값을 설정하려면 다음과 같이 합니다.
SSL Configuration File Directives의 설명은 다음과 같습니다.
SSLSessionTimeout
SSLSessionTimeout은 SSL2 세션 캐시를 제어합니다.
구문
SSLSessionTimeout 초
초는 캐시된 SSL 세션의 유효 시간을 초 단위로 입력합니다. 기본값은 100입니다. SSLSessionTimeout 지시문이 지정되면 초 단위 값은 자동으로 5에서 100초로 제한됩니다.
SSLCacheEntries
캐시할 수 있는 SSL 세션의 수를 지정합니다.
SSL3SessionTimeout
SSL3SessionTimeout 지시문은 SSL3 및 TLS 세션 캐싱을 제어합니다.
구문
SSL3SessionTimeout 초
초는 캐시된 SSL3 세션의 유효 시간을 초 단위로 입력합니다. 기본값은 86400(24시간)입니다. SSL3SessionTimeout 지지문이 지정되면 초 단위 값은 자동으로 5에서 86400초로 제한됩니다.
외부 암호화 모듈 사용Sun ONE Web Server 6.1은 스마트 카드나 토큰 링 등의 외부 암호화 모듈을 사용하는 다음의 방법을 지원합니다.
FIPS-140 암호화 표준을 사용하기 전에 PKCS#11 모듈을 추가해야 합니다.
PKCS#11 모듈 설치
Sun ONE Web Server는 PKCS(Public Key Cryptography Standard)#11을 지원합니다. 이는 SSL과 PKCS#11 모듈 사이의 통신용으로 사용되는 인터페이스를 정의합니다. PKCS#11 모듈은 SSL 하드웨어 가속기에 대한 표준 기반 연결용으로 사용됩니다. 외부 하드웨어 가속시용으로 가져온 인증서와 키는 secmod.db에 저장되며, 이 파일은 PKCS#11이 설치될 때 생성됩니다.
modutil을 사용하여 PKCS#11 모듈 설치
modutil 도구를 사용하여 PKCS#11 모듈을 .jar 파일 또는 개체 파일 형태로 설치할 수 있습니다.
modutil을 사용하여 PKCS#11 모듈을 설치하려면 다음과 같이 합니다.
- Administration Server를 포함하여 모든 서버가 종료되어야 합니다.
- 데이터베이스가 있는 server_root/alias 디렉토리로 이동합니다.
- server_root/bin/https/admin/bin을 PATH에 추가합니다.
- server_root/bin/https/admin/bin에서 modutil을 찾습니다.
- 환경을 설정합니다. 예:
- 다음 명령을 입력합니다. modutil.
옵션 목록이 표시됩니다.
- 필요한 조치를 수행합니다.
예를 들어 PCKS#11 모듈을 UNIX에 추가하려면 다음과 같이 입력합니다.
modutil -add (the name of PCKS#11 file) -libfile (your libfile for PCKS#11) -nocertdb -dbdir . (사용하는 db 디렉토리)
pk12util 사용
pk12util을 사용하면 내부 데이터베이스에서 인증서와 키를 내보내고 이를 내부 또는 외부 PKCS#11 모듈로 가져올 수 있습니다. 언제라도 인증서와 키를 내부 데이터베이스로 내보낼 수 있으나, 외부 토큰의 경우 대부분 인증서와 키를 내보낼 수 없습니다. 기본적으로 pk12util은 cert8.db와 kyes3.db라는 이름의 인증서 및 키 데이터베이스를 사용합니다.
pk12util을 사용하여 내보내기
내부 데이터베이스에서 인증서와 키를 내보내려면 다음과 같이 합니다.
- 데이터베이스가 있는 server_root/alias 디렉토리로 이동합니다.
- server_root/bin/https/admin/bin을 PATH에 추가합니다.
- server_root/bin/https/admin/bin에서 pk12util을 찾습니다.
- 환경을 설정합니다. 예:
- 다음 명령을 입력합니다. pk12util.
옵션 목록이 표시됩니다.
- 필요한 조치를 수행합니다.
예를 들어 UNIX의 경우 다음과 같이 입력합니다.
pk12util -o certpk12 -n Server-Cert [-d /server/alias] [-P https-test-host]
- 데이터베이스 암호를 입력합니다.
- pkcs12 암호를 입력합니다.
pk12util을 사용하여 가져오기
내부 또는 외부 PKCS#11 모듈로 인증서와 키를 가져오려면 다음과 같이 합니다.
- 데이터베이스가 있는 server_root/alias 디렉토리로 이동합니다.
- server_root/bin/https/admin/bin을 PATH에 추가합니다.
- server_root/bin/https/admin/bin에서 pk12util을 찾습니다.
- 환경을 설정합니다. 예:
- 다음 명령을 입력합니다. pk12util.
옵션 목록이 표시됩니다.
- 필요한 조치를 수행합니다.
예를 들어 UNIX의 경우 다음과 같이 입력합니다.
pk12util -i pk12_sunspot [-d certdir][-h ?Cipher?[-P https-jones.redplanet.com-jones-]
-P는 반드시 -h 뒤에 있어야 하며 마지막 인수여야 합니다.
대문자와 인용 부호 사이의 공백을 포함하여 토큰 이름을 정확히 입력합니다.
- 데이터베이스 암호를 입력합니다.
- pkcs12 암호를 입력합니다. 외부 인증서를 사용하여 서버 시작
서버용 인증서를 외부 PKCS#11모듈(하드웨어 가속기 등)에 설치한 경우, server.xml을 편집하거나 아래에 설명한 것과 같이 인증서 이름을 지정하지 않으면 서버가 인증서를 사용하여 시작할 수 없습니다.
서버는 항상 "Server-Cert"라는 이름의 인증서를 사용하여 시작하려고 시도합니다. 그러나 외부 PKCS#11 모듈에 있는 인증서에는 해당 ID에 모듈의 토큰 이름 중 하나가 포함됩니다. 예를 들어 외부 스마트카드 판독기에 설치된 서버 인증서가 "smartcard0"인 경우, 이름은 "smartcard0:Server-Cert"가 됩니다.
외부 모듈에 설치된 인증서를 사용하여 서버를 시작하려면 서버가 실행되는 청취 소켓용 인증서 이름을 지정해야 합니다.
청취 소켓용 인증서 이름 선택
청취 소켓용 인증서 이름을 선택하려면 다음과 같이 합니다.
참고
청취 소켓에서 Security가 사용되지 않는 경우에는 인증서 정보가 표시되지 않습니다. 청취 소켓용 인증서 이름을 선택하려면 반드시 우선 청취 소켓에서 보안을 사용하도록 설정해야 합니다. 더 자세한 내용은 "청취 소켓용 보안 사용 설정"를 참조하십시오.
- Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Preference 탭이 선택되지 않았으면 선택합니다.
- Edit Listen Sockets 링크를 누릅니다.
Edit Listen Sockets 페이지가 표시됩니다.
- 인증서와 연결하려는 청취 소켓에 해당하는 Listen Socket ID 링크를 누릅니다.
Edit Listen Socket 페이지가 표시됩니다.
- Server Certificate 드롭 다운 목록에서 해당 소켓용 서버 인증서를 선택합니다.
이 목록에는 설치된 모든 내부 및 외부 인증서가 표시됩니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
또한 server.xml 파일을 직접 편집하여 서버가 해당 인증서를 사용하여 시작하도록 할 수 있습니다. SSLPARAMS의 servercertnickname을 다음으로 변경합니다.
$TOKENNAME 용으로 사용할 값을 찾으려면 서버의 Security 탭으로 이동하여 Manage Certificate 링크를 선택합니다. Server-Cert가 저장된 외부 모듈로 로그인하면 해당 인증서가 $TOKENNAME:$NICKNAME 폼의 목록에 표시됩니다.
FIPS-140 표준
PKCS#11 API를 사용하면 암호화 작업을 수행하는 소프트웨어 또는 하드웨어 모듈과 통신할 수 있습니다. PKCS#11이 서버에 설치되면 Sun ONE Web Server가 FIPS(Federal Information Processing Standards)-140 표준을 따르도록 구성할 수 있습니다. 이 라이브러리는 오직 SSL 버전 3.0에만 포함되어 있습니다.
FIPS-140을 사용하려면 다음과 같이 합니다.
- FIPS-140의 설명을 따라 플러그인을 설치합니다.
- Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Edit Listen Sockets 링크를 누릅니다.
Edit Listen Sockets 페이지가 표시됩니다. 보안 청취 소켓에 대하여 Edit Listen Socket 페이지에 사용 가능한 보안 설정이 표시됩니다.
참고
FIPS-140을 사용하려면 선택한 청취 소켓에서 보안이 사용되도록 설정해야 합니다. 더 자세한 내용은 "청취 소켓용 보안 사용 설정"을 참조하십시오.
- Enable이 선택되어 있지 않으면 SSL Version 3 드롭 다운 목록에서 선택합니다.
- 적절한 FIPS-140 암호 제품군을 선택합니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
클라이언트 보안 요구 사항 설정서버 보안 단계를 모두 수행 한 후, 클라이언트에 대한 추가 보안 요구 사항을 설정할 수 있습니다.
클라이언트 인증 필수화
Administration Server용 청취 소켓을 사용하도록 설정하고 각 서버 인스턴스가 클라이언트 인증을 요청하도록 할 수 있습니다. 클라이언트 인증을 사용하면 서버가 쿼리에 대한 응답을 보내기 전에 클라이언트에 인증서를 요구합니다.
Sun ONE Web Server는 클라이언트 인증서에 있는 CA와 클라이언트 인증서 서명용으로 신뢰된 CA를 비교하여 클라이언트 인증서를 인증합니다. 클라이언트 인증서 서명용 CA의 목록은 Administrator Server의 Security에 있는 Manage Certificates 페이지에서 확인할 수 있습니다. CA의 유형은 네 가지입니다.
웹 서버가 신뢰된 CA의 인증서를 보유하지 않은 클라이언트를 거부하도록 구성할 수 있습니다. CA를 승인 또는 거부하려면 반드시 CA용 클라이언트 신뢰를 설정해야 합니다. 더 자세한 내용은 "인증서 관리"를 참조하십시오.
Sun ONE Web Server는 인증서의 유효 기간이 만료된 경우 오류를 기록하고 인증서를 거부하며 클라이언트에게 메시지를 반송합니다. 또한 Administration Servers Manage Certificates 페이지에서 만기된 인증서를 확인할 수 있습니다.
서버가 인증서 클라이언트에서 정보를 수집하여 이를 LDAP 디렉토리에 있는 사용자 항목과 비교하도록 구성할 수 있습니다. 이렇게 하면 클라이언트의 인증서가 유효하며 LDAP 디렉토리에 항목이 보관되도록 합니다. 또한 클라이언트 인증서가 LDAP 디렉토리의 항목 중 하나와 일치되도록 합니다. 이에 대한 방법은 "클라이언트 인증서를 LDAP로 매핑"을 참조하십시오.
클라이언트 인증서를 액세스 제어와 조합할 수 있으므로 신뢰된 CA의 요구 사항 이외에 인증서에 연결된 사용자는 반드시 액세스 제어 규칙(ACL)과 일치되어야 합니다. 더 자세한 내용은 "액세스 제어 파일 사용" 페이지 184를 참조하십시오.
또한 클라이언트 인증서의 정보를 처리할 수 있습니다. 자세한 내용은 Sun ONE Web Server 6.1 NSAPI Programmer's Guide를 참조하십시오.
클라이언트 인증 요구
클라이언트 인증을 요구하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스하고 Preferences 탭을 선택합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Edit Listen Sockets 링크를 누릅니다.
Edit Listen Sockets 페이지가 표시됩니다.
- 클라이언트 인증을 요구할 청취 소켓에 해당하는 Listen Socket ID 링크를 누릅니다.
Edit Listen Socket 페이지가 표시됩니다.
- 해당 청취 소켓용 클라이언트 인증을 요구하려면 Client Authentication 드롭 다운 목록에서 Required를 선택합니다.
- OK를 누릅니다.
클라이언트 인증서를 LDAP로 매핑
이 부분에서는 Sun ONE Web Server가 클라이언트 인증서를 LDAP 디렉토리의 항목과 매핑하는 데 사용하는 프로세스에 대하여 설명합니다.
서버에 클라이언트의 요청이 수신되면 이를 처리하기 전에 클라이언트의 인증서를 요구합니다. 클라이언트에 따라 서버에 요청과 함께 클라이언트를 전송하는 경우도 있습니다.
참고
또한, 클라이언트 인증서를 LDAP로 매핑하려면 필요한 ACL을 설정해야 합니다. 자세한 내용은 제 9장, "서버 액세스 제어"를 참조하십시오.
서버는 CA를 Administration Server에 있는 신뢰 CA의 목록과 비교하려고 합니다. 일치 항목이 없으면 Sun ONE Web Server가 연결을 종료합니다. 일치 항목이 있으면 서버가 요청 처리를 계속합니다.
신뢰 CA에서 인증서를 확인한 후, 서버는 다음과 같이 인증서를 LDAP 항목과 매핑합니다.
서버는 certmap.conf라는 인증서 매핑 파일을 사용하여 LDAP 검색 방법을 결정합니다. 서버는 매핑 파일에 따라 클라이언트 인증서에서 가져올 값(최종 사용자의 이름, 전자우편 주소 등)을 결정합니다. 서버는 이들 값을 사용하여 LDAP 디렉토리에서 사용자 항목을 검색하지만, 우선 서버가 LDAP 디렉토리에서 검색을 시작할 위치를 결정해야 합니다. 서버는 또한 인증서 매핑 파일에서 시작 위치를 알 수 있습니다.
서버가 검색을 시작할 위치와 검색할 항목을 결정하면(제1단계) LDAP 디렉토리에서 검색을 수행합니다(제2단계). 일치 항목이 없거나 일치 항목이 여러 개인 경우 매핑이 인증서 확인으로 설정되지 않고 검색은 실패합니다. 예상되는 검색 결과의 전체 목록은 아래의 표 6-1을 참조하십시오. 참고로 ACL에서 예상되는 작동을 지정할 수 있습니다. 예를 들어, Sun ONE Web Server가 오직 인증서 일치에 실패하는 경우에만 승인하도록 지정할 수 있습니다. ACL 기본 설정에 대한 자세한 내용은 "액세스 제어 파일 사용" 페이지 184을 참조하십시오.
표 6-1) LDAP 검색 결과
LDAP 검색 결과
인증서 검증 ON
인증서 검증 OFF
검색된 항목 없음
인증 실패
인증 실패
정확히 한 개 항목 일치
인증 실패
인증 성공
여러 항목 일치
인증 실패
인증 실패
서버가 LDAP 디렉토리에서 일치 항목과 인증서를 찾으면 해당 정보를 사용하여 트랜잭션을 처리할 수 있습니다. 예를 들어 서버에 따라 인증서-LDAP 매핑을 사용하여 서버에 대한 액세스를 결정합니다.
certmap.conf 파일 사용
인증서 매핑에 따라 서버가 LDAP 디렉토리에서 사용자 항목을 찾는 방법이 결정됩니다. certmap.conf를 사용하여 이름으로 명시된 인증서를 LDAP 항목과 일치시키는 방법을 구성할 수 있습니다. 이 파이를 편집하고 항목을 추가하여 LDAP 디렉토리의 조직을 검색하고 사용자에게 부여할 인증서 목록을 표시할 수 있습니다. 사용자는 사용자ID, 전자우편 또는 subjectDN에서 사용되는 다른 값을 기준으로 인증될 수 있습니다. 특히, 매핑 파일에는 다음의 정보가 정의됩니다.
인증서 매핑 파일은 다음에 있습니다.
파일에는 하나 이상의 이름 매핑이 있으며, 각각의 매핑은 서로 다른 CA에 적용됩니다. 매핑의 구문은 다음과 같습니다.
첫 번째 줄은 항목의 이름과 CA 인증서에 있는 고유 이름을 구성하는 속성을 지정합니다. name은 임의로 원하는 이름을 정의할 수 있습니다. 그러나 issuerDN은 반드시 클라이언트 인증서를 발행한 CA의 발행자 DN과 정확히 일치해야 합니다. 예를 들어 아래의 issuerDN 줄의 차이는 단지 속성을 구분하는 공백이지만 서버는 이 두 항목을 서로 다른 것으로 처리합니다.
이름 매핑의 두 번째 및 이후 줄은 등록 정보를 값과 매핑합니다. certmap.conf 파일에는 여섯 개의 등록 정보가 있습니다. (인증서 API를 사용하여 등록 정보를 사용자 정의할 수 있습니다.)
- DNComps는 쉼표로 분리된 속성 목록으로, LDAP 디렉토리에서 사용자 정보(즉, 클라이언트 인증서의 소유자)와 일치하는 항목 검색을 시작할 위치를 결정하는데 사용합니다. 서버는 클라이언트 인증서에서 이들 속성 값을 수집하고 값을 사용하여 LDAP DN을 구성합니다. 그런 후 LDAP 디렉토리에서 서버가 검색을 시작할 위치를 결정합니다. 예를 들어, DNComps가 DN의 o와 c 속성을 사용하도록 설정하면 서버는 LDAP 디렉토리에서 속성이 o=<org>, c=<country>인 항목부터 검색을 시작합니다. 여기에서 <org>와 <country>는 인증서의 DN에 있는 값으로 대체됩니다.
예를 들어 FilterComps가 전자우편과 사용자ID 속성을 사용하도록 설정하는 경우(FilterComps=e, uid), 서버는 디렉토리에서 전자우편과 사용자ID 값이 클라이언트 인증서에서 수집한 사용자 정보와 일치하는 항목을 검색합니다. 전자우편 주소와 사용자ID는 보통 디렉토리에서 고유한 항목이므로 좋은 필터입니다. LDAP 데이터베이스에서 오직 하나의 항목만 검색하려면 필터가 구체적이어야 합니다.
x509v3 인증서 속성 목록은 다음 표를 참조하십시오.
표 6-2) x509v3 인증서용 속성
속성
설명
c
국가
o
단체
cn
공통 이름
l
장 소
st
주
ou
조직 단위
uid
UNIX/Linux 사용자ID
전자우편 주소
필터용 속성 이름은 LDAP 디렉토리가 아닌 인증서의 속성 이름이어야 합니다. 예를 들어 일부 인증서에는 사용자의 전자우편 주소용 속성으로 e가 있는 반면 LDAP에서 이 속성의 이름은 mail입니다.
- 서버는 verifycert의 설정에 따라 클라이언트의 인증서를 LDAP 디렉토리에서 검색된 인증서와 비교할 것인지 결정합니다. 값은 ON이거나 OFF입니다. 이 등록 정보는 LDAP 디렉토리에 인증서가 있는 경우에만 사용해야 합니다. 기 기능은 최종 사용자의 인증서가 유효하며 취소되지 않았는지 확인하는 데 유용합니다.
- CmapLdapAttr은 LDAP 디렉토리에 있는 속성 이름으로 사용자에게 속한 모든 인증서의 대상 DN을 포함합니다. 이 등록 정보의 기본값은 certSubjectDN입니다. 이 등록 정보는 표준 LDAP 속성이 아니므로 이 등록 정보를 사용하려면 반드시 LDAP 스키마를 확장해야 합니다. 자세한 내용은 SSL 개요를 참조하십시오.
이 등록 정보에 대한 자세한 내용은 "매핑 예제"에서 설명한 예제를 참조하십시오.
사용자 정의 등록 정보 생성
클라이언트 인증서 API를 사용하여 자체의 등록 정보를 만들 수 있습니다. 클라이언트 인증서 API 프로그래밍과 사용 방법은 NSAPI Programmer's Guide를 참조하십시오.
사용자 정의 매핑이 있는 경우 매핑은 다음과 같이 참조합니다.
<name>:library <path_to_shared_library>
<name>:InitFn <name_of_init_function>예:
매핑 예제
certmap.conf 파일에는 최소한 한 개 이상의 항목이 있어야 합니다. certmap.conf 파일을 사용하는 다양한 방법은 다음 예제에 보이는 것과 같습니다.
예제 1
이 예제의 certmap.conf 파일에는 오직 한 개의 "기본" 매핑만 있습니다.
이 예제를 사용하면 서버는 ou=<orgunit>, o=<org>, c=<country> 항목을 포함하는 LDAP 분기점에서 검색을 시작하며, 여기에서 <>의 텍스트는 클라이언트 인증서에 있는 대상 DN의 값으로 대체됩니다.
그 후, 서버는 인증서에 있는 전자우편 주소와 사용자ID 값을 사용하여 LDAP 디렉토리에 일치하는 항목이 있는지 검색합니다. 항목이 검색되면 서버는 클라이언트가 전송한 인증서와 디렉토리에 있는 인증서를 비교하여 인증서를 검증합니다.
예제 2
다음 예제 파일에는 기본값과 US 우편 서비스용의 두 가지 매핑이 있습니다.
서버에 미국 우편 서비스가 아닌 다른 인증서가 수신되면 기본 매핑을 사용합니다. 이 경우 LDAP 트리의 상단에서 시작하여 클라이언트의 전자우편 및 사용자ID와 일치하는 항목을 검색합니다. 미국 우편 서비스의 인증서인 경우 서버는 조직 단위를 포함하는 LDAP 분기에서 검색을 시작하며 일치하는 전자우편 주소를 검색합니다. 또한 인증서가 USPS의 것이면 서버가 인증서를 검증하지만 기타 인증서는 검증되지 않습니다.
주의
인증서의 발행자 DN(즉, CA 정보)은 반드시 매핑의 첫 번째 줄 목록에 있는 발행자 DN과 동일해야 합니다. 앞의 예제에서 o=United States Postal Service,c=US인 발행자 DN의 인증서는 o와 c 속성 사이에 공백이 없으므로 일치되지 않습니다.
예제 3
다음 예제에서는 CmapLdapAttr 등록 정보를 사용하여 LDAP 데이터베이스에서 certSubjectDN이라고 하는 속성을 검색합니다. 이 속성의 값은 클라이언트 인증서에서 가져온 대상 DN 전체와 정확히 일치합니다.
클라이언트 인증서 대상이 다음인 경우,
서버는 우선 다음 정보를 포함한 항목을 검색합니다.
일치하는 항목이 하나 이상인 경우에는 서버가 항목을 검증합니다. 검색된 항목이 없는 경우 서버는 DNComps와 FilterComps를 사용하여 일치하는 항목을 검색합니다. 이 예제에서 서버는 o=LeavesOfGrass Inc, c=US 아래의 모든 항목에서 uid=Walt Whitman을 검색합니다.
고급 보안 설정Stronger Ciphers 옵션에서는 액세스용으로 168, 128 또는 56비트 비밀 키를 선택하거나 제한을 설정하지 않을 수 있습니다. 제한에 맞지 않는 경우 서비스될 파일을 지정할 수 있습니다. 파일을 지정하지 않으면 Sun ONE Web Server는 "Forbidden" 상태를 반환합니다.
선택한 액세스용 키 크기가 Security Preferences의 현재 암호 설정과 맞지 않는 경우 Sun ONE Web Server에 더 큰 비밀 키로 암호를 사용해야 한다는 경고 대화 상자가 표시됩니다.
현재 키 크기 제한은 Service fn=key-toosmall이 아닌 obj.conf의 NSAPI PathCheck 지시문을 기준으로 구현됩니다. 지시문:
여기에서 <nbits>는 비밀 키에 필요한 최소 비트 수이며 <filename>은 제한을 만족하지 않는 경우 서비스될 파일의 이름(URL 아님)입니다.
SSL을 사용하지 않거나 secret-keysize 매개 변수가 지정되지 않은 경우 PathCheck은 REQ_NOACTION을 반환합니다. 현재 세션의 비밀 키 크기가 지정된 secret-keysize보다 작은 경우, bong-file이 지정되지 않으면 이 함수는 REQ_ABORTED를 PROTOCOL_FORBIDDEN 상태와 함께 반환합니다. 그렇지 않은 경우 REQ_PROCEED를 반환하며 "path" 변수가 bong-file <filename>으로 설정됩니다. 또한 키 크기 제한을 만족하지 않은 경우 현재 세션용 SSL 세션 캐시가 무효화되어 다음 번 클라이언트가 서버로 연결하면 전체 SSL 핸드셰이크가 발생합니다.
참고
Stronger Ciphers 폼을 사용하면 PathCheck fn=ssl-check을 추가할 때 개체에서 검색되는 Service fn=key-toosmall 지시문이 제거됩니다.
고급 암호를 설정하려면 다음과 같이 합니다.
- Server Manager에 액세스하고 드롭 다운 목록에서 서버 인스턴스를 선택합니다.
- Virtual Server Class 탭을 누릅니다.
- 드롭 다운 목록에서 클래스 폼을 선택하고 Manage를 누릅니다.
Class Manager 페이지가 표시됩니다.
- Content Mgmt 탭을 선택합니다.
- Stronger Ciphers를 선택합니다.
- 다음 편집 옵션 중 한 가지를 선택합니다.
- 비밀 키 크기 제한을 선택합니다.
- 액세스를 거부할 메시지의 파일 위치를 입력합니다.
- OK를 누릅니다.
- Apply를 누릅니다.
- hard start/restart 또는 dynamically apply를 선택합니다.
자세한 내용은 SSL 개요를 참조하십시오.
추가 보안 고려 사항누군가 암호를 해독하려는 시도 외에도 다른 보안 위험이 있습니다. 네트워크는 서버와 서버의 정보에 액세스하려는 다양한 방법을 사용하는 외부 및 내부 해커의 위험에 직면해 있습니다.
따라서 서버의 암호화를 사용하는 것 이외에 추가의 보안 조치를 취해야 합니다. 예를 들어 서버 컴퓨터를 안전한 곳에 위치시키거나 신뢰되지 않은 개인이 서버에 프로그램을 올리지 못하도록 해야 합니다.
다음에서는 서버를 더욱 안전하게 만드는데 가장 중요한 사항들에 대하여 설명할 것입니다.
실제 액세스 제한
이 간단한 보안 수단이 종종 잊혀지고 있습니다. 서버 컴퓨터를 잠금 장치가 있는 곳에 위치시켜 권한 있는 사람만 들어갈 수 있도록 합니다. 이렇게 하면 서버 컴퓨터 자체를 해킹할 수 없도록 방지합니다.
또한 있는 경우 컴퓨터의 관리(루트) 암호를 보호하십시오.
관리 액세스 제한
원격 구성을 사용하는 경우 오직 몇몇의 사용자와 컴퓨터에만 관리를 허용하도록 액세스 제어를 설정해야 합니다. Administrator Server가 LDAP 사용자에게 LDAP 서버나 로컬 디렉토리 정보에 대한 액세스를 부여하도록 하는 경우, SSL을 사용하는 Administration Server가 마스터 서버의 역할을 하고 사용자가 기타 Administration Server에 액세스할 수 있도록 두 대의 Administration Server를 유지 및 클러스터 관리 사용을 고려하십시오.
클러스터에 대한 자세한 내용은 "클러스터 설명" 페이지 153를 참조하십시오.
또한 Administration Server용 암호화를 사용해야 합니다. 관리용 SSL 연결을 사용하지 않는 경우에는 보안되지 않은 네트워크를 통하여 원격 서버 관리를 수행할 때 조심해야 합니다. 누구라도 관리 암호를 가로채어 서버를 재구성할 수 있습니다.
강력한 암호 선택
서버에는 관리 암호, 개인 키 암호, 데이터베이스 암호 등 여러 가지 암호를 사용합니다. 관리 암호는 누구라도 컴퓨터에 있는 모든 서버를 구성할 수 있으므로 가장 중요한 암호입니다. 개인 키 암호는 다음으로 중요한 암호입니다. 개인 키와 개인 키 암호가 있으면 사용자의 것으로 보이는 가짜 서버를 만들거나 서버로 오고 가는 통신을 가로채고 변경할 수 있습니다.
좋은 암호는 자신은 기억할 수 있지만 다른 사람은 추측할 수 없는 암호입니다. 예를 들어 Mci12!mo를 "My Child is 12 months old!"라고 기억할 수 있을 것입니다. 자녀의 이름이나 생일은 나쁜 암호입니다.
해독하기 어려운 암호
강력한 암호를 만드는 데 도움이 되는 간단한 지침이 몇 가지 있습니다.
하나의 암호에 다음의 규칙을 모두 적용해야 하는 것은 아니지만 더 많은 규칙을 적용할 수록 암호가 더욱 알아내기 어려워질 것입니다.
암호 또는 PIN 변경
주기적으로 신뢰 데이터베이스/키쌍 파일 암호 또는 PIN을 변경하는 것이 좋습니다. Administration Server에서 SSL을 사용하는 경우 서버를 시작할 때 이 암호가 필요합니다. 주기적으로 암호를 변경하면 서버 보호를 한 단계 높일 수 있습니다.
이 암호는 오직 로컬 컴퓨터에서 변경해야 합니다. 암호를 변경하는 경우 고려해야 할 지침은 "해독하기 어려운 암호"를 참조하십시오.
비밀번호 변경
Administration Server 또는 서버 인스턴스용 신뢰 데이터베이스/키쌍 파일 암호를 변경하려면 다음과 같이 합니다.
- Administration Server 또는 Server Manager에 액세스합니다.
Server Manager의 경우 반드시 드롭 다운 목록에서 서버 인스턴스를 먼저 선택해야 합니다.
- Change Password 링크를 선택합니다.
- 드롭 다운 목록에서 암호를 변경하려는 보안 토큰을 선택합니다.
기본으로 이는 내부 키 데이터베이스용 "내부" 암호입니다. PKCS#11 모듈이 설치된 경우 모든 토큰 목록이 표시됩니다. Change Password 링크를 누릅니다.
- 현재 암호를 입력합니다.
- 새 암호를 입력합니다.
- 새 암호를 다시 입력합니다.
- OK를 누릅니다.
- Server Manager의 경우 Apply를 누른 다음 Restart를 눌러 변경 사항이 적용되도록 합니다.
키쌍 파일이 보호되는지 확인하십시오. Administration Server는 키 쌍 파일을 server_root/alias 디렉토리에 저장합니다. 오직 컴퓨터에 설치된 Sun ONE 서버만이 해당 파일과 디렉토리를 읽을 수 있도록 하는 경우를 생각할 수 있습니다.
또한 파일이 백업 테이프에 저장되어 있는지 또는 기타 다른 사람이 가로챌 가능성이 있는지 확인하는 것이 중요합니다. 이 경우 백업을 서버와 마찬가지로 완벽하게 보호해야 합니다.
서버에서 기타 응용 프로그램 제한
서버와 동일한 컴퓨터에서 실행되는 모든 응용 프로그램을 신중하게 고려해야 합니다. 서버에서 실행되는 다른 프로그램의 취약점을 활용하여 서버의 보안을 우회하는 것이 가능합니다. 필요하지 않은 모든 프로그램과 서비스를 종료합니다. 예를 들어 UNIX sendmail 데몬은 안전하게 구성하는 것이 어려우며 서버 컴퓨터에서 해로운 프로그램을 실행하도록 프로그램될 수 있습니다.
UNIX 및 Linux
inittab 및 rc 스크립트에서 시작하는 프로세스를 신중하게 선택합니다. 서버 컴퓨터에서 telnet 또는 rlogin을 실행하면 안 됩니다. 또한 서버 컴퓨터에 rdist가 있으면 안 됩니다. (이는 파일을 배포할 수 있으나 또한 서버 컴퓨터의 파일을 업데이트하도록 사용될 수 있습니다.)
Windows
다른 컴퓨터와 공유할 드라이브 및 디렉토리를 신중히 고려합니다. 또한 계정이나 Guest 권한을 부여할 사용자를 고려합니다.
마찬가지로 서버에 들어갈 프로그램과 다른 사람이 서버에 설치할 프로그램을 신중히 고려해야 합니다. 다른 사람의 프로그램에는 보안 취약점이 있을 수 있습니다. 또한 특히 보안을 손상시키도록 디자인된 악의적 프로그램을 업로드할 수도 있습니다. 서버에서 프로그램을 허용하기 전에 신중하게 프로그램을 평가해야 합니다.
클라이언트가 SSL 파일을 캐시하지 못하도록 방지
HTML에 있는 파일의 <HEAD> 부분에 다음 줄을 추가하여 클라이언트가 미리 암호화된 파일을 캐시할 수 없도록 방지할 수 있습니다.
포트 제한
컴퓨터에서 사용되지 않는 포트는 모두 비활성화합니다. 라우터 또는 방화벽 구성을 사용하여 절대적으로 최소 포트 세트 이외의 것으로 향하는 입중계 연결을 방지합니다. 이렇게 하면 실제로 이미 제한된 영역에 위치한 서버의 컴퓨터를 사용할 때에만 컴퓨터에서 셀을 사용할 수 있게 됩니다.
서버의 한계 파악
서버는 서버와 클라이언트 사이에 안전한 연결을 제공합니다. 클라이언트가 일단 정보를 보유하면 정보의 보안을 제어할 수 없으며 서버 컴퓨터 자체와 해당 디렉토리 및 파일에 대한 액세스는 제어할 수 없습니다.
이러한 제한을 알고 있으면 피해야 할 상황을 이해하는 데 도움이 됩니다. 예를 들어 SSL 연결을 통하여 신용 카드 번호를 구할 수 있으나 이 번호가 서버 컴퓨터의 보안 파일에 저장되어 있을까요? SSL 연결이 종료된 후 이 번호는 어떻게 될까요? 클라이언트가 SSL을 통하여 송신하는 모든 정보를 보안할 책임이 있습니다.
서버 보호를 위한 추가 변경 적용
보호된 서버와 보호되지 않은 서버를 모두 사용하려면 보호되지 않은 서버를 보호된 서버와 다른 컴퓨터에서 운용해야 합니다. 자원의 한계로 인하여 보호되지 않은 서버를 보호된 서버와 동일한 컴퓨터에서 실행해야 하는 경우에는 다음과 같이 합니다.
chroot를 사용하면 서버를 특정 디렉토리로 제한하는 제2의 루트 디렉토리를 만들 수 있습니다. 이 기능은 보호되지 않은 서버에 대한 안전 장치로 사용할 수 있다. 예를 들어 루트 디렉토리가 /dl/ms로 만들 수 있습니다. 그런 후, 웹 서버가 루트 디렉토리에 액세스하면 실제로 dl/ms로 액세스하게 됩니다. 예를 들어 /dev에 액세스하려고 시도하면 /dl/ms/dev에 액세스하게 됩니다. 이렇게 하면 실제 루트 디렉토리의 모든 파일에 대한 액세스를 허용하지 않고 UNIX/Linux 시스템에서 웹 서버를 실행할 수 있습니다.
그러나 chroot를 사용하는 경우, 아래의 그림에 보이는 것과 같이 대체 루트 디렉토리에 Sun ONE Web Server가 요구하는 전체 디렉토리 구조를 만들어야 합니다.
가상 서버 클래스용 chroot 지정
다음과 같이 가상 서버 클래스용 chroot 디렉토리를 지정할 수 있습니다.
- Server Manager에 액세스하고 드롭 다운 목록에서 서버 인스턴스를 선택합니다.
- Virtual Server Class 탭을 선택합니다.
- Edit Classes 링크를 누릅니다.
- chroot를 지정하려는 클래스용 Option이 Edit로 설정되었는지 확인합니다.
- 해당 클래스의 Advanced 버튼을 누릅니다.
Virtual Servers CGI Settings 페이지가 표시됩니다.
- Chroot 필드에 전체 경로를 입력합니다.
- OK를 누릅니다.
- Apply를 누릅니다.
- Load Configuration Files를 선택하여 동적으로 적용합니다.
가상 서버용 chroot 지정
다음과 같이 가상 서버용 chroot 디렉토리를 지정할 수 있습니다.
또한 Class Manager Virtual Servers 탭과 CGI Settings 링크를 사용하여 가상 서버용 chroot 디렉토리를 지정할 수 있습니다.
가상 서버용으로 chroot 디렉토리를 설정하는 방법에 대한 자세한 내용은 Sun ONE Web Server 6.1 Programmer's Guide를 참조하십시오.