test

Sun Java System Application Server Enterprise Edition 8.2 관리 설명서

9장 보안 구성

보안이란 데이터를 보호하는 것이며 데이터를 저장하거나 전송할 때 해당 데이터에 대한 인증 되지않은 액세스나 손상을 방지하는 방법입니다. Application Server에는 J2EE 표준을 기반으로 하는 확장 가능한 동적 보안 구조가 있습니다. 내장된 보안 기능에는 암호화 도구 인증 및 권한 부여 공개 키 인프라가 포함됩니다. Application Server는 시스템이나 사용자에 대한 잠재적인 위험 없이 응용 프로그램을 안전하게 실행할 수 있는 샌드 박스를 사용하는 Java 보안 모델에 구축되어 있습니다. 이 장은 다음 내용으로 구성되어 있습니다.

응용 프로그램 및 시스템 보안 이해

대개, 다음과 같은 두 종류의 응용 프로그램 보안이 있습니다.

응용 프로그램 보안 외에 Application Server 시스템의 모든 응용 프로그램에 영향을 미치는 시스템 보안도 있습니다.

프로그래밍 방식의 보안은 응용 프로그램 개발자가 제어하므로 이 문서에서 설명하지 않습니다. 선언적 보안의 경우 덜 제어되므로 이 문서에서 가끔 다룹니다. 이 문서는 기본적으로 시스템 관리자를 대상으로 하므로 시스템 보안에 대해 중점적으로 설명합니다.

보안 관리 도구

Application Server에서는 보안을 관리하기 위한 다음 도구를 제공합니다.

Java 2 Platform, Standard Edition(J2SE)에서는 보안을 관리하기 위한 다음 두 가지 도구를 제공합니다.

keytool, policytool 및 다른 Java 보안 도구 사용에 대한 자세한 내용은 http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security에 있는 Java 2 SDK Tools and Utilities를 참조하십시오.

Enterprise Edition의 경우 NSS(Network Security Services)를 구현하는 다른 두 개의 도구를 보안 관리에 사용할 수 있습니다. NSS에 대한 자세한 내용을 보려면 http://www.mozilla.org/projects/security/pki/nss/로 이동하십시오. 보안 관리 도구는 다음과 같습니다.

certutil, pk12util 및 다른 NSS 보안 도구 사용에 대한 자세한 내용은 http://www.mozilla.org/projects/security/pki/nss/tools에 있는 NSS Security Tools를 참조하십시오.

비밀번호 보안 관리

Application Server의 이번 릴리스에서 특정 도메인에 대한 사양을 포함하는 domain.xml 파일에는 기본적으로 Sun Java System 메시지 대기열 브로커의 비밀번호가 일반 텍스트로 포함되어 있습니다. 이 비밀번호를 포함하는 domain.xml 파일의 요소는 jms-host 요소의 admin-password 속성입니다. 설치 시, 이 비밀번호를 변경할 수 없기 때문에 보안에 큰 영향을 미치지 않습니다.

그러나 관리 콘솔을 사용하여 사용자와 자원을 추가하고 이 사용자와 자원에 비밀번호를 지정합니다. 예를 들어, 데이터베이스에 액세스하기 위한 비밀번호처럼 이 비밀번호 중 일부는 domain.xml 파일에 일반 텍스트로 기록됩니다. 이 비밀번호를 domain.xml 파일에 일반 텍스트로 기록하면 보안 위험이 있을 수 있습니다. admin-password 속성이나 데이터베이스 비밀번호와 같은 domain.xml의 비밀번호를 암호화할 수 있습니다. 보안 비밀번호 관리에 대한 지침은 다음 내용을 참조하십시오.

domain.xml 파일의 비밀번호 암호화

domain.xml 파일의 비밀번호를 암호화하려면 다음 단계를 수행합니다.

  1. domain.xml 파일이 있는 디렉토리(기본적으로 domain-dir/config)에서 다음의 asadmin 명령을 실행합니다.


    asadmin create-password-alias --user admin alias-name

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


    asadmin create-password-alias --user admin jms-password

    비밀번호 프롬프트(이 경우 admin)가 표시됩니다. 자세한 내용은 create-password-alias, list-password-aliases, delete-password-alias 명령에 대한 설명서 페이지를 참조하십시오.

  2. domain.xml의 비밀번호를 제거하고 바꿉니다. asadmin set 명령을 사용하여 이를 수행합니다. 다음은 이러한 용도로 set 명령을 사용하는 예입니다.


    asadmin set --user admin server.jms-service.jms-host.
default_JMS_host.admin-password='${ALIAS=jms-password}'
    주 –

    위의 예와 같이 별칭 비밀번호를 작은 따옴표로 묶습니다.

  3. 관련 도메인을 위해 Application Server를 다시 시작합니다.

암호화된 비밀번호를 사용하여 파일 보호

일부 파일에는 파일 시스템 권한을 사용하여 보호해야 하는 암호화된 비밀번호가 포함되어 있습니다. 이 파일에는 다음 내용이 포함되어 있습니다.

마스터 비밀번호 변경

마스터 비밀번호(MP)는 전체적으로 공유하는 비밀번호입니다. 마스터 비밀번호는 인증에 사용되지 않고 네트워크를 통해 전송되지 않습니다. 이 비밀번호는 전체적인 보안의 억제 지점입니다. 필요할 경우 수동으로 입력하도록 선택하거나 파일에 숨길 수 있습니다. 비밀번호는 시스템에서 가장 중요한 데이터입니다. 이 파일을 제거하여 MP 요구를 강제로 실행할 수 있습니다. 마스터 비밀번호를 변경하면 마스터 비밀번호가 Java JCEKS 유형 키 저장소인 마스터 비밀번호 키 저장소에 다시 저장됩니다.

마스터 비밀번호를 변경하려면 다음 단계를 수행합니다.

  1. 도메인의 Application Server를 중지합니다. asadmin change-master-password 명령을 사용하여 이전 비밀번호와 새 비밀번호에 대한 메시지를 표시한 다음 모든 하위 종속 항목을 다시 암호화합니다. 예를 들면 다음과 같습니다.


    asadmin change-master-password>
Please enter the master password>
Please enter the new master password>
Please enter the the new master password again>

  2. Application Server를 다시 시작합니다.

    주의 – 주의 –

    이 때 실행 중인 서버 인스턴스를 시작해서는 안되며, 해당 노드의 SMP 에이전트가 변경될 때까지 실행 중인 서버 인스턴스를 다시 시작해서는 안 됩니다. SMP를 변경하기 전에 서버 인스턴스를 다시 시작한 경우 서버 인스턴스가 시작되지 않습니다.

  3. 노드 에이전트 및 관련된 서버를 한 번에 하나씩 중지합니다. asadmin change-master-password 명령을 다시 실행한 다음 노드 에이전트 및 관련된 서버를 다시 시작합니다.

  4. 모든 노드 에이전트를 주소 지정할 때까지 다음 노드 에이전트를 계속합니다. 이런 방법으로 변경 사항 롤백이 수행됩니다.

마스터 비밀번호 및 키 저장소 작업

마스터 비밀번호는 보안 키 저장소에 대한 비밀번호입니다. 새 Application Server 도메인을 만들 때 자체 서명된 인증서가 새로 생성되고 마스터 비밀번호를 사용하여 잠근 관련 키 저장소에 저장됩니다. 마스터 비밀번호가 기본값이 아닌 경우 start-domain 명령을 실행하면 마스터 비밀번호를 입력하라는 메시지가 표시됩니다. 올바른 마스터 비밀번호를 입력하면 도메인이 시작됩니다.

도메인과 연관된 노드 에이전트를 만들면 노드 에이전트는 데이터를 도메인과 동기화합니다. 그러는 동안 키 저장소도 함께 동기화됩니다. 이 노드 에이전트가 제어하는 모든 서버 인스턴스는 키 저장소를 열어야 합니다. 이 저장소는 기본적으로 도메인 만들기 프로세스에서 만들어진 저장소와 동일하므로 이와 동일한 마스터 비밀번호를 사용해야 열립니다. 그러나 마스터 비밀번호 자체는 동기화되지 않지만, 즉 마스터 비밀번호가 동기화 중 노드 에이전트에 전송되지 않지만 노드 에이전트에 로컬로 사용할 수 있어야 합니다. 이에 따라 노드 에이전트 만들기 및/또는 시작 시 마스터 비밀번호를 입력하라는 메시지가 표시되며, 이때 도메인 만들기/시작 시에 입력한 것과 동일한 비밀번호를 입력해야 합니다. 도메인의 마스터 비밀번호가 변경되면 이 도메인과 연관된 모든 노드 에이전트에 대해 동일한 단계를 수행하여 해당 마스터 비밀번호를 변경해야 합니다.

관리 비밀번호 변경

관리 비밀번호 암호화는 비밀번호 보안 관리에 설명되어 있습니다. 관리 비밀번호를 암호화할 것을 강력하게 권장합니다. 암호화하기 전에 관리 비밀번호를 변경하려면 asadmin set 명령을 사용합니다. 다음은 이러한 용도로 set 명령을 사용하는 예입니다.


asadmin set --user admin server.jms-service.jms-host.default_JMS_host.admin-password=new_pwd

다음 절차와 같이 관리 콘솔를 사용하여 관리 비밀번호를 변경할 수도 있습니다.

관리 콘솔을 사용하여 관리 비밀번호를 변경하려면 구성 노드 > 구성할 인스턴스 > 보안 노드 > 영역 노드 > 관리 영역 노드를 선택하고 필요에 맞게 영역 페이지를 편집합니다.

인증 및 권한 부여 정보

인증 및 권한 부여는 응용 프로그램 서버 보안의 핵심 개념입니다. 인증 및 권한 부여와 관련해서 다음 내용을 설명합니다.

엔티티 인증

인증은 엔티티(사용자, 응용 프로그램 또는 구성 요소)가 다른 엔티티를 확인하는 방법입니다. 엔티티는 보안 자격 증명을 사용하여 자신을 인증합니다. 사용자 이름 및 비밀번호 디지털 인증서 등이 자격 증명이 될 수 있습니다.

일반적으로 인증은 사용자 이름과 비밀번호를 사용하여 응용 프로그램에 로그인하는 것을 의미하지만 서버의 자원을 요청할 경우 EJB 공급 보안 자격 증명을 가리킬 수도 있습니다. 대개, 서버나 응용 프로그램에서는 클라이언트의 인증을 요구합니다. 그리고 클라이언트에서는 서버가 자신을 인증할 것을 요구할 수도 있습니다. 인증이 양방향일 경우 이를 상호 인증이라고 합니다.

엔티티가 보호된 자원에 액세스할 경우 Application Server는 해당 자원에 대해 구성된 인증 체계를 사용하여 액세스를 부여할지 여부를 결정합니다. 예를 들어, 사용자는 웹 브라우저에서 사용자 이름과 비밀번호를 입력할 수 있습니다. 응용 프로그램에서 해당 자격 증명을 확인하면 사용자가 인증됩니다. 세션의 나머지 부분에서 사용자는 이 인증된 보안 아이디와 연관되어 있습니다.

Application Server는 엔티티 인증에 설명된 대로 네 가지 인증 유형을 지원합니다. 응용 프로그램은 배포 설명자 내에서 사용하는 인증 유형을 지정합니다. deploytool을 사용하여 응용 프로그램에 대한 인증 메소드를 구성하는 방법에 대한 자세한 내용은 http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html에 있는 J2EE 1.4 Tutorial을 참조하십시오.

표 9–1 Application Server 인증 방법

인증 방법

통신 프로토콜

설명

사용자 자격 증명 암호화

기본 

HTTP(SSL 선택 사항) 

서버에 내장된 팝업 로그인 대화 상자를 사용합니다. 

SSL을 사용하지 않을 경우 없음 

양식 기반 

HTTP(SSL 선택 사항) 

응용 프로그램에서 고유한 사용자 정의 로그인 및 오류 페이지를 제공합니다. 

SSL을 사용하지 않을 경우 없음 

클라이언트 인증서 

HTTPS(SSL에서의 HTTP) 

서버는 공개 키 인증서를 사용하여 클라이언트를 인증합니다. 

SSL 

단일 사인 온(SSO) 검증

단일 사인 온(SSO)을 사용하면 하나의 가상 서버 인스턴스의 여러 응용 프로그램이 사용자 인증 상태를 공유할 수 있습니다. 단일 사인 온(SSO)을 사용할 경우 사용자가 하나의 응용 프로그램에 로그인하면 동일한 인증 정보를 요구하는 다른 응용 프로그램에 암시적으로 로그인됩니다.

단일 사인 온(SSO)은 그룹을 기반으로 합니다. 배포 설명자가 동일한 그룹을 정의하고 동일한 인증 방법(기본, 양식, 다이제스트, 인증서)을 사용하는 모든 웹 응용 프로그램은 단일 사인 온(SSO)을 공유합니다.

Application Server에 대해 정의된 가상 서버에는 기본적으로 단일 사인 온(SSO)이 활성화되어 있습니다.

사용자 권한 부여

사용자가 인증되면 권한 부여의 수준은 수행할 수 있는 작업을 결정합니다. 사용자의 권한 부여는 역할을 기반으로 합니다. 예를 들어, 인사 관리 응용 프로그램은 관리자에게 모든 직원의 사원 정보를 볼 수 있도록 허용하지만 직원들에게는 자신의 개인 정보만 볼 수 있도록 허용할 수 있습니다. 역할에 대한 자세한 내용은 사용자, 그룹, 역할 및 영역 이해를 참조하십시오.

JACC 공급자 지정

JACC(Java Authorization Contract for Containers)는 플러그 가능한 권한 부여 공급자의 인터페이스를 정의하는 J2EE 1.4 사양의 일부입니다. JACC를 사용하면 관리자는 타사 플러그인 모듈에서 권한 부여를 수행하도록 설정할 수 있습니다.

기본적으로 Application Server는 JACC 사양과 함께 컴파일되는 단순한 파일 기반의 권한 부여 엔진을 제공합니다. 다른 타사 JACC 공급자를 지정할 수도 있습니다.

JACC 공급자는 JAAS(Java Authentication and Authorization Service) API를 사용합니다. JAAS를 사용하면 서비스에서 사용자에 따라 액세스 제어를 인증하고 강제할 수 있습니다. JAAS는 표준 PAM(Pluggable Authentication Module) 프레임워크의 기술 버전을 구현합니다.

인증 및 권한 부여 결정 사항 감사

Application Server는 감사 모듈을 통해 모든 인증 및 권한 부여 결정 사항의 감사 추적을 제공할 수 있습니다. Application Server는 기본 감사 모듈뿐만 아니라 감사 모듈을 사용자 정의할 수 있는 기능도 제공합니다. 사용자 정의 감사 모듈 개발에 대한 자세한 내용은 Application Server Developer's Guide의 Configuring an Audit Module 절을 참조하십시오.

메시지 보안 구성

메시지 보안을 사용하면 서버는 메시지 계층에서 웹 서비스 호출 및 응답의 종단간 인증을 수행할 수 있습니다. Application Server는 SOAP 계층에서 메시지 보안 공급자를 사용하여 메시지 보안을 구현합니다. 메시지 보안 공급자는 요청 및 응답 메시지에 필요한 인증 유형과 같은 정보를 제공합니다. 지원되는 인증 유형은 다음과 같습니다.

두 개의 메시지 보안 공급자가 이 릴리스에 포함되어 있습니다. SOAP 계층의 인증을 위해 메시지 보안 공급자를 구성할 수 있습니다. 구성할 수 있는 공급자에는 ClientProvider와 ServerProvider가 포함됩니다.

메시지 계층 보안 지원이 플러그 가능한 인증 모듈 양식으로 클라이언트 컨테이너와 Application Server에 통합됩니다. 기본적으로 메시지 계층 보안은 Application Server에서 비활성화됩니다.

전체 Application Server나 특정 응용 프로그램 또는 메소드에 대해 메시지 수준 보안을 구성할 수 있습니다. Application Server 수준에서 메시지 보안을 구성하는 방법은 10 장, 메시지 보안 구성에 설명되어 있습니다. 응용 프로그램 수준에서 메시지 보안을 구성하는 방법은 Developer's Guide의 Securing Applications 장에 설명되어 있습니다.

사용자, 그룹, 역할 및 영역 이해

Application Server는 다음 엔티티에 대해 인증 및 권한 부여 정책을 실행합니다.

주 –

사용자와 그룹은 전체 Application Server에 대해 지정되는 반면, 각 응용 프로그램에서는 고유한 역할을 정의합니다. 응용 프로그램을 패키지화 및 배포할 경우 다음 그림에서 설명한 대로 응용 프로그램은 사용자/그룹 및 역할 간의 매핑을 지정합니다.

그림 9–1 역할 매핑

표는 사용자가 그룹에 할당되는 방법, 사용자와 그룹이 역할에 할당되는 방법 및 응용 프로그램이 그룹과 역할을 사용하는 방법을 보여줍니다.

사용자

사용자는 Application Server에 정의된 개인 또는 응용 프로그램 아이디입니다. 사용자를 그룹과 연관시킬 수 있습니다. Application Server 인증 서비스는 여러 영역의 사용자를 관리할 수 있습니다.

그룹

J2EE 그룹(또는 단순한 그룹)은 직위나 고객 프로필 같은 공통된 특성에 따라 분류된 사용자 범주입니다. 예를 들어, 전자 상거래 응용 프로그램의 사용자는 customer 그룹에 속할 수 있지만, 대량 소비자는 preferred 그룹에 속할 수 있습니다. 사용자를 그룹으로 범주화하면 많은 수의 사용자 액세스를 더 쉽게 제어할 수 있습니다.

역할

역할은 응용 프로그램, 각 응용 프로그램에서 사용자가 액세스할 수 있는 부분 및 사용자가 할 수 있는 작업을 정의합니다. 즉, 역할은 사용자의 인증 수준을 결정합니다.

예를 들어, 인사 프로그램에서 모든 직원이 전화 번호와 전자 메일 주소에 액세스할 수 있지만 급여 정보는 관리자만 액세스할 수 있습니다. 응용 프로그램은 다음과 같이 최소한 두 가지 역할을 정의할 수 있습니다. employee 및 manager. manager 역할의 사용자만 급여 정보를 볼 수 있습니다.

역할은 응용 프로그램의 기능을 정의하는 반면, 그룹은 연관된 사용자 집합이라는 점에서 역할과 사용자 그룹은 다릅니다. 예를 들어, 인사 응용 프로그램에는 full-time, part-time 및 on-leave 같은 그룹이 있을 수 있지만, 이 모든 그룹의 사용자는 여전히 employee 역할이 됩니다.

역할은 응용 프로그램 배포 설명자에 정의됩니다. 반대로, 그룹은 전체 서버와 영역에 대해 정의됩니다. 응용 프로그램 개발자나 배포자는 배포 설명자의 각 응용 프로그램에 대한 하나 이상의 그룹에 역할을 매핑합니다.

영역

보안 정책 도메인 또는 보안 도메인이라고도 하는 영역은 서버가 공통 보안 정책을 정의 및 실행하는 범위입니다. 실제적인 면에서, 영역은 서버가 사용자 및 그룹 정보를 저장하는 저장소입니다.

Application Server는 다음의 세 가지 영역으로 미리 구성됩니다. file(초기 기본 영역), certificate 및 admin-realm. ldap, solaris 또는 사용자 정의 영역을 설정할 수도 있습니다. 응용 프로그램은 배포 설명자에서 사용할 영역을 지정할 수 있습니다. 영역을 지정하지 않을 경우 Application Server는 기본 영역을 사용합니다.

file 영역의 경우 서버는 사용자 자격 증명을 keyfile이라고 하는 파일에 로컬로 저장합니다. 관리 콘솔을 사용하여 file 영역의 사용자를 관리할 수 있습니다. .

certificate 영역의 경우 서버는 인증서 데이터베이스에 사용자 인증서를 저장합니다. certificate 영역을 사용할 경우 서버는 HTTPS 프로토콜과 함께 인증서를 사용하여 웹 클라이언트를 인증합니다. 인증서에 대한 자세한 내용은 인증서 및 SSL 소개를 참조하십시오.

admin-realm은 FileRealm이기도 하며 admin-keyfile이라는 파일에 관리자 자격 증명을 로컬로 저장합니다. file 영역에서 사용자를 관리하는 것과 같은 방법으로 관리 콘솔을 사용하여 이 영역의 사용자를 관리합니다.

ldap 영역의 경우 서버는 Sun Java System Directory Server 같은 LDAP(Lightweight Directory Access Protocol) 서버에서 사용자 자격 증명을 가져옵니다. LDAP는 공용 인터넷을 사용하는지 기업 인트라넷을 사용하는지 여부와 상관없이 조직, 개인 및 네트워크의 파일이나 장치 같은 다른 자원을 찾을 수 있게 해주는 프로토콜입니다. ldap 영역에서 사용자 및 그룹 관리에 대한 자세한 내용은 LDAP 서버 설명서를 참조하십시오.

solaris 영역의 경우 서버는 Solaris 운영 체제에서 사용자 자격 증명을 가져옵니다. 이 영역은 Solaris 9 OS 이상에서 지원됩니다. solaris 영역에서 사용자 및 그룹 관리에 대한 자세한 내용은 Solaris 설명서를 참조하십시오.

사용자 정의 영역은 관계형 데이터베이스나 타사 구성 요소 같은 사용자 자격 증명의 다른 저장소입니다. 자세한 내용은 관리 콘솔 온라인 도움말을 참조하십시오.

인증서 및 SSL 소개

이 절에서는 다음 항목에 대해 설명합니다.

디지털 인증서 정보

디지털 인증서(또는 인증서)는 인터넷의 사용자와 자원을 고유하게 식별하는 전자 파일입니다. 인증서는 두 엔티티 간에 안전하고 비밀을 유지하는 통신도 가능하게 해줍니다.

인증서의 종류는 여러 가지가 있는데 개인이 사용하는 개인 인증서와 SSL(Secure Sockets Layer) 기술을 통해 서버와 클라이언트 간에 안전한 세션을 설정하기 위해 사용하는 서버 인증서 등이 있습니다. SSL에 대한 자세한 내용은 SSL(Secure Sockets Layer) 정보를 참조하십시오.

인증서는 디지털 키 쌍(매우 긴 번호)을 사용하여 대상 수신자만 읽을 수 있도록 정보를 암호화 또는 인코딩하는 공개 키 암호화를 기반으로 합니다. 수신자는 정보의 비밀번호를 해독(디코드)하여 읽습니다.

키 쌍에는 공개 키와 개인 키가 포함됩니다. 소유자는 공개 키를 배포하여 모든 사용자가 사용할 수 있게 합니다. 그러나 소유자는 개인 키는 배포하지 않고 항상 비밀로 합니다. 키가 수학적으로 관련되어 있기 때문에 하나의 키로 암호화된 데이터는 키 쌍의 다른 키로만 해독할 수 있습니다.

인증서는 여권과 같습니다. 인증서는 소유자를 식별하고 기타 중요한 정보를 제공합니다. 인증 기관(CA)이라고 하는 신뢰할 수 있는 제 3자가 인증서를 발행합니다. CA는 여권 담당 부서와 유사합니다. CA는 인증서가 위조되거나 조작될 수 없도록 소유자의 아이디를 검증하고 인증서에 서명합니다. CA가 인증서에 서명하면 소유자는 신원 증명으로 인증서를 제공하고 암호화된 기밀 통신을 설정할 수 있습니다.

가장 중요한 점은 인증서가 소유자의 공개 키를 소유자의 아이디에 바인드한다는 점입니다. 여권이 소유자에 대한 개인 정보와 사진을 함께 제공하는 것과 같이 인증서는 소유자에 대한 정보에 공개 키를 바인드합니다.

공개 키 외에 인증서에는 대개 다음과 같은 정보가 포함되어 있습니다.

디지털 인증서는 X.509 형식의 기술 사양으로 관리됩니다. certificate 영역에서 사용자의 아이디를 확인하기 위해 인증 서비스는 X.509 인증서의 공통 이름 필드를 principal 이름으로 사용하여 X.509 인증서를 확인합니다.

인증서 체인 정보

웹 브라우저에는 브라우저가 자동으로 신뢰하는 루트 CA 인증서 집합이 사전 구성되어 있습니다. 모든 인증서에는 자신의 유효성을 검증하기 위한 인증서 체인이 함께 제공되어야 합니다. 인증서 체인은 최종적으로 루트 CA 인증서에서 종료되는 연속적인 CA 인증서로 발행된 일련의 인증서입니다.

처음 생성된 인증서는 자체 서명된 인증서입니다. 자체 서명된 인증서는 발급자(서명자)가 주제(공개 키를 인증서에서 인증하는 엔티티)와 동일한 인증서입니다. 소유자가 인증서 서명 요청(CSR)을 인증 기관에 전송한 다음 응답을 가져오면 자체 서명된 인증서는 인증서 체인으로 대체됩니다. 체인 맨 아래에는 주제의 공개 키를 인증하는 인증 기관에서 발행한 인증서(응답)가 있습니다. 체인의 다음 인증서는 CA의 공개 키를 인증하는 인증서입니다. 대개는 자체 서명된 인증서, 즉 해당 공개 키를 인증하는 인증 기관의 인증서이고 체인의 마지막 인증서입니다.

다른 경우는 인증서 체인을 반환할 수 있습니다. 이 경우 인증서 체인의 맨 아래 인증서는 동일하지만(키 항목의 공개 키를 인증하는 CA에서 서명한 인증서), 체인의 두 번째 인증서는 CSR을 전송한 CA의 공개 키를 인증하는 다른 CA에서 서명한 인증서입니다. 체인의 다음 인증서는 두 번째 CA의 키를 인증하는 인증서입니다. 자체 서명된 루트 인증서에 도달할 때까지 이러한 방식으로 계속됩니다. 체인의 각 인증서(첫째 인증서 제외)는 체인의 이전 인증서의 서명자 공개 키를 인증합니다.

SSL(Secure Sockets Layer) 정보

SSL(Secure Sockets Layer)은 인터넷 통신 및 트랜잭션을 보안하기 위한 가장 일반적인 표준입니다. 웹 응용 프로그램은 서버와 클라이언트간 안전한 기밀 통신을 보장하기 위해 디지털 인증서를 사용하는 HTTPS(SSL 상의 HTTP)를 사용합니다. SSL 연결에서 클라이언트와 서버는 모두 데이터를 전송하기 전에 암호화한 다음 요청 시 해독합니다.

웹 브라우저(클라이언트)에서 보안 사이트에 연결할 경우 SSL 핸드셰이크가 발생합니다.

핸드셰이크 후, 클라이언트는 웹 사이트의 아이디를 검증했고 클라이언트와 웹 서버만 세션 키의 사본을 갖고 있습니다. 이 때부터 클라이언트와 서버는 세션 키를 사용하여 서로 간의 모든 통신을 암호화합니다. 따라서 이 통신은 보안이 안전합니다.

SSL 표준의 최신 버전을 TLS(Transport Layer Security)이라고 합니다. Application Server는 SSL(Secure Sockets Layer) 3.0 및 TLS(Transport Layer Security) 1.0 암호화 프로토콜을 지원합니다.

SSL을 사용하려면 Application Server에 외부 인터페이스에 대한 인증서나 보안 연결을 승인하는 IP 주소가 있어야 합니다. 디지털 인증서가 설치되지 않으면 대부분 웹 서버의 HTTPS 서비스가 실행되지 않습니다. keytool 유틸리티를 사용하여 인증서 생성에 설명된 절차를 사용하여 웹 서버가 SSL에 대해 사용할 수 있는 디지털 인증서를 설정합니다.

암호화 정보

암호화는 암호화나 해독에 사용되는 암호화 알고리즘입니다. SSL 및 TLS 프로토콜은 서버와 클라이언트가 서로 간에 인증하고 인증서를 전송하며 세션 키를 설정하기 위해 사용한 다양한 암호화를 지원합니다.

일부 비밀번호는 다른 비밀번호보다 더 강력하고 더 안전합니다. 클라이언트와 서버는 서로 다른 암호화 제품군을 지원할 수 있습니다. SSL3 및 TLS 프로토콜에서 암호화를 선택합니다. 세션 연결 중에 클라이언트와 서버는 서로가 통신을 위해 설정한 더 강력한 암호화 사용을 승인하므로 대개 모든 암호화를 충분히 사용할 수 있습니다.

이름 기반의 가상 호스트 사용

보안 응용 프로그램에 대해 이름 기반의 가상 호스트를 사용하는 것은 문제가 될 수 있습니다. 이는 SSL 프로토콜 자체의 설계 한계입니다. 클라이언트 브라우저가 서버 인증서를 승인하는 SSL 핸드셰이크는 HTTP 요청에 액세스하기 전에 발생해야 합니다. 따라서 가상 호스트 이름을 포함하는 요청 정보를 인증 전에 확인할 수 없습니다. 그러므로 단일 IP 주소에 복수 인증서를 지정할 수 없습니다.

단일 IP 주소의 모든 가상 호스트를 동일한 인증서에 대해 인증해야 할 경우 복수 가상 호스트를 추가해도 서버의 정상 SSL 작업을 방해하지 않습니다. 그러나 대부분의 브라우저는 (공식적인 CA 서명된 인증서에 우선적으로 적용할 수 있는 경우) 서버의 도메인 이름을 인증서에 나열된 도메인 이름과 비교합니다. 도메인 이름이 일치하지 않을 경우 이 브라우저에서 경고를 표시합니다. 일반적으로 주소 기반 가상 호스트만 작업 환경에서 SSL과 같이 사용됩니다.

방화벽 정보

방화벽은 둘 이상의 네트워크간 데이터 흐름을 제어하고 네트워크간 링크를 관리합니다. 방화벽은 하드웨어 및 소프트웨어 요소 둘 다로 구성될 수 있습니다. 이 절에서는 일반 방화벽 구조와 방화벽 구성을 설명합니다. 여기에서는 주로 Application Server에 관련된 사항을 다룹니다. 특정 방화벽 기술에 대한 자세한 내용은 방화벽 공급업체의 설명서를 참조하십시오.

일반적으로 클라이언트가 필요한 TCP/IP 포트에 액세스할 수 있도록 방화벽을 구성합니다. 예를 들어 HTTP Listener가 포트 8080에서 작동할 경우 포트 8080에서만 HTTP 요청을 허용하도록 방화벽을 구성합니다. 마찬가지로, 포트 8181에 대한 HTTP 요청을 설정한 경우 포트 8181에서 HTTP 요청을 허용하도록 방화벽을 구성해야 합니다.

인터넷에서 EJB 모듈로 직접 RMI-IIOP(Remote Method Invocations over Internet Inter-ORB Protocol) 액세스가 필요한 경우 RMI-IIOP Listener 포트도 엽니다. 그러나 보안 위험이 생기기 때문에 열지 않는 것이 좋습니다.

이중 방화벽 구조의 경우 HTTP 및 HTTPS 트랜잭션을 허용하도록 외부 방화벽을 구성해야 합니다. 방화벽 뒤에서 Application Server와 통신하려면 HTTP 서버 플러그인을 허용하도록 내부 방화벽을 구성해야 합니다.

관리 콘솔을 사용하여 보안 관리

관리 콘솔은 보안의 다음 측면을 관리하기 위한 수단을 제공합니다.

서버 보안 설정

보안 설정 페이지에서 기본 영역, 익명 역할, principal 사용자 이름 및 비밀번호 지정을 포함한 전체 서버에 대한 등록 정보를 설정합니다.

영역 및 파일 영역 사용자

영역에 대한 개념은 사용자, 그룹, 역할 및 영역 이해에 설명되어 있습니다.

JACC 공급자

JACC 공급자에 대한 내용은 JACC 공급자 지정에 설명되어 있습니다. 관리 콘솔을 사용하여 다음 작업을 수행할 수 있습니다.

감사 모듈

감사 모듈에 대한 내용은 인증 및 권한 부여 결정 사항 감사에 설명되어 있습니다. 감사는 오류나 보안 위반 같은 중요한 이벤트를 나중에 검토하기 위해 기록하는 방법입니다. 모든 인증 이벤트는 Application Server 로그에 기록됩니다. 전체 액세스 로그는 Application Server 액세스 이벤트의 순차적인 추적을 제공합니다.

관리 콘솔을 사용하여 다음 작업을 수행할 수 있습니다.

메시지 보안

메시지 보안에 대한 개념은 메시지 보안 구성에 설명되어 있습니다. 관리 콘솔을 사용하여 다음 작업을 수행할 수 있습니다.

이 작업에 대한 자세한 내용은 관리 콘솔 온라인 도움말을 참조하십시오.

HTTP 및 IIOP Listener 보안

HTTP 서비스의 가상 서버마다 하나 이상의 HTTP Listener를 통해 네트워크 연결을 제공합니다.

Application Server는 CORBA(Common Object Request Broker Architecture) 객체를 지원합니다. 이 객체는 IIOP(Internet Inter-Orb Protocol)를 사용하여 네트워크에서 통신합니다. IIOP Listener는 EJB의 원격 클라이언트와 다른 CORBA 기반 클라이언트에서 들어오는 연결을 받아들입니다. IIOP Listener에 대한 자세한 내용은 IIOP Listener를 참조하십시오.

관리 콘솔을 사용하여 다음 작업을 수행합니다.

관리 서비스 보안

관리 서비스는 서버 인스턴스가 일반 인스턴스 또는 도메인 관리 서버(DAS)인지, 아니면 이 둘의 조합인지 지정합니다. 관리 서비스를 사용하여 원격 서버 인스턴스에 맞게 JSR-160 호환 원격 JMK 커넥터를 구성함으로써 호스트 시스템에서 서버 인스턴스를 관리합니다. 이 커넥터는 도메인 관리 서버와 노드 에이전트 간의 통신을 처리합니다.

관리 콘솔을 사용하여 다음 작업을 수행합니다.

보안 맵

관리 콘솔을 사용하여 다음 보안 매핑 작업을 수행합니다.

인증서 및 SSL 작업

인증서 파일 정보

Application Server를 설치하면 내부 검사에 적합한 JSSE(Java Secure Socket Extension) 또는 NSS(Network Security Services) 형식으로 디지털 인증서가 생성됩니다. 기본적으로 Application Server는 domain-dir/config 디렉토리의 인증서 데이터베이스에 인증서 정보를 저장합니다.

인증서 파일 위치 변경

개발용으로 제공된 keystore 및 truststore 파일은 domain-dir/config 디렉토리에 저장됩니다.

관리 콘솔에서 server-config 노드 > JVM 설정 > JVM 옵션 탭을 확장하여 인증서 파일의 새 위치 값을 추가하거나 수정합니다.


-Dcom.sun.appserv.nss.db=${com.sun.aas.instanceRoot}/NSS-database-directory

여기서 NSS-database-directory는 NSS 데이터베이스의 위치입니다.

JSSE(Java Secure Socket Extension) 도구 사용

keytool을 사용하여 JSSE(Java Secure Socket Extension) 디지털 인증서를 설정하고 작업합니다. Platform Edition과 Enterprise Edition 모두의 경우 클라이언트측(응용 프로그램 클라이언트 또는 독립 실행형)에서는 JSSE 형식을 사용합니다.

J2SE SDK에는 keytool이 함께 제공되므로 관리자가 공개/개인 키 쌍 및 연관된 인증서를 관리할 수 있습니다. 사용자가 통신 피어의 공개 키를 인증서 양식으로 캐시할 수도 있습니다.

keytool을 실행하려면 J2SE /bin 디렉토리가 경로에 있도록 쉘 환경을 구성하거나 도구에 대한 전체 경로를 명령줄에서 제공해야 합니다. keytool에 대한 자세한 내용은 http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html에 있는 keytool 설명서를 참조하십시오.

keytool 유틸리티 사용

다음 예는 JSSE 도구를 사용한 인증서 처리와 관련된 사용법을 보여줍니다.

keytool 유틸리티를 사용하여 인증서 생성

keytool을 사용하여 인증서를 생성하고 가져오며 내보냅니다. 기본적으로 keytool은 실행될 디렉토리에 keystore 파일을 만듭니다.

  1. 인증서가 실행될 디렉토리로 변경합니다.

    인증서는 반드시 keystore와 truststore 파일이 있는 디렉토리(기본은 domain-dir/config)에 생성하십시오. 이 파일의 위치를 변경하는 방법에 대한 자세한 내용은 인증서 파일 위치 변경을 참조하십시오.

  2. 다음의 keytool 명령을 입력하여 keystore 파일 keystore.jks에 인증서를 생성합니다.


    keytool -genkey -alias keyAlias-keyalg RSA
 -keypass changeit
 -storepass changeit
-keystore keystore.jks

    keyAlias와 같이 고유한 이름을 사용합니다. keystore 또는 개인 키 비밀번호의 기본값을 변경한 경우 위 명령의 changeit을 새 비밀번호로 대체합니다.

    이름, 조직 및 keytool이 인증서를 생성하는 데 사용할 기타 정보를 묻는 메시지가 표시됩니다.

  3. 다음의 keytool 명령을 입력하여 생성된 인증서를 server.cer(아니면 client.cer) 파일로 내보냅니다.


    keytool -export -alias keyAlias-storepass changeit
 -file server.cer
 -keystore keystore.jks

  4. 인증 기관에서 서명한 인증서가 필요한 경우에는 keytool 유틸리티를 사용하여 디지털 인증서 서명을 참조하십시오.

  5. cacerts.jks truststore 파일을 만들고 인증서를 truststore에 추가하려면 다음의 keytool 명령을 입력합니다.


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit

  6. keystore 또는 개인 키 비밀번호의 기본값을 변경한 경우 위 명령의 changeit을 새 비밀번호로 대체합니다.

    도구는 인증서에 대한 정보를 표시하고 해당 인증서에 대한 신뢰 여부를 묻습니다.

  7. yes를 입력하고 Enter 키를 누릅니다.

    그러면 keytool은 다음과 같은 메시지를 표시합니다.


    Certificate was added to keystore
[Saving cacerts.jks]

  8. Application Server를 다시 시작합니다.

keytool 유틸리티를 사용하여 디지털 인증서 서명

디지털 인증서를 만든 후 소유자는 위조를 막기 위해 인증서에 서명해야 합니다. 전자 상거래 사이트나 아이디 인증이 중요한 사이트는 잘 알려진 인증 기관(CA)에서 인증서를 구매할 수 있습니다. 인증이 중요하지 않은 경우, 예를 들어 개인적인 보안 통신만 필요한 경우에는 인증서를 얻는데 필요한 시간과 경비를 절약하고 자체 서명된 인증서를 사용합니다.

  1. CA의 웹 사이트에서 지침을 수행하여 인증서 키 쌍을 생성합니다.

  2. 생성된 인증서 키 쌍을 다운로드합니다.

    인증서는 반드시 keystore와 truststore 파일이 있는 디렉토리(기본은 domain-dir/config 디렉토리)에 저장하십시오. 인증서 파일 위치 변경을 참조하십시오.

  3. 쉘에서 인증서가 있는 디렉토리로 변경합니다.

  4. keytool을 사용하여 인증서를 로컬 keystore로 가져오고, 필요한 경우 로컬 truststore로도 가져옵니다.


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit
-storepass changeit

    keystore 또는 개인 키 비밀번호의 기본값을 변경한 경우 위 명령의 changeit을 새 비밀번호로 대체합니다.

  5. Application Server를 다시 시작합니다.

keytool 유틸리티를 사용하여 인증서를 삭제하는 방법

기존의 인증서를 삭제하려면 다음 예와 같이 keytool -delete 명령을 사용합니다.

keytool -delete
 -alias keyAlias
 -keystore keystore-name
 -storepass password

NSS(Network Security Services) 도구 사용

Enterprise Edition의 경우 서버측에서 NSS(Network Security Services) 디지털 인증서를 사용하여 개인 키와 인증서를 저장하는 데이터베이스를 관리합니다. 클라이언트측(응용 프로그램 클라이언트 또는 독립 실행형)의 경우 JSSE(Java Secure Socket Extension) 도구 사용에서 설명한 대로 JSSE 형식을 사용합니다.

NSS(Network Security Services)를 사용하여 보안을 관리하는 도구는 다음 사항을 포함합니다.

도구는 install-dir/lib/ 디렉토리에 있습니다. 다음 환경 변수는 NSS 보안 도구의 위치를 나타내는 데 사용됩니다.

예에서 인증서 공통 이름(CN)은 클라이언트나 서버의 이름입니다. CN은 SSL 핸드셰이크 중에 인증서 이름과 인증서를 만든 호스트 이름을 비교하는 데도 사용됩니다. 인증서 이름과 호스트 이름이 일치하지 않으면 SSL 핸드셰이크 중에 경고나 예외가 생성됩니다. 몇 가지 예에서 편의상 인증서 공통 이름 CN=localhost가 사용되는데 모든 사용자는 실제 호스트 이름을 사용하여 새 인증서를 만드는 대신 이 인증서를 사용할 수 있습니다.

다음 예는 NSS 도구를 사용한 인증서 처리와 관련된 사용법을 보여줍니다.

certutil 유틸리티 사용

certutil을 실행하기 전에 LD_LIBRARY_PATH가 이 유틸리티를 실행하는 데 필요한 라이브러리의 위치를 가리키도록 합니다. 이 위치는 asenv.conf(제품 차원의 구성 파일)의 AS_NSS_LIB 값에서 식별할 수 있습니다.

인증서 데이터베이스 도구인 certutil은 Netscape Communicator cert8.db 및 key3.db 데이터베이스 파일을 작성 및 수정할 수 있는 명령줄 유틸리티입니다. 또한 cert8.db 파일 내에 인증서를 나열, 생성, 수정 또는 삭제하거나, 비밀번호를 작성 또는 변경하거나 새로운 공개 및 개인 키 쌍을 생성하거나, 키 데이터베이스 내용을 표시하거나 key3.db 파일 내의 키 쌍을 삭제할 수도 있습니다.

키와 인증서 관리 프로세스는 대개 키 데이터베이스에 키를 만든 다음 인증서 데이터베이스에 인증서를 생성 및 관리하는 것으로 시작됩니다. 다음의 설명서에서는 certutil 유틸리티의 구문을 포함하여 NSS를 사용한 인증서 및 키 데이터베이스 관리에 대해 설명합니다. http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html

아래 목록의 각 항목은 NSS 및 JSSE 보안 도구를 사용하여 인증서를 만들거나 관리하는 예를 보여줍니다.

pk12util 유틸리티를 사용하여 인증서 가져오기 및 내보내기

pk12util은 PKCS12 형식의 인증서/키 데이터베이스 및 파일 간에 키와 인증서를 가져오고 내보내는 데 사용하는 명령줄 유틸리티입니다. PKCS12는 Personal Information Exchange Syntax Standard(개인 정보 상호 교환 구문 표준)의 PKCS(Public-Key Cryptography Standards) #12입니다. pk12util 유틸리티에 대한 자세한 내용은 http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html을 참조하십시오.

modutil을 사용하여 PKCS11 모듈 추가 및 삭제

보안 모듈 데이터베이스 도구인 modutil은 secmod.db 파일이나 하드웨어 토큰 내에서 PKCS #11(Cryptographic Token Interface Standard, 암호화 토큰 인터페이스 표준) 모듈 정보를 관리하는 명령줄 유틸리티입니다. 이 도구를 사용하여 PKCS #11 모듈을 추가 및 삭제하고, 비밀번호를 변경하며 기본값을 설정하고, 모듈 내용을 나열하고 슬롯을 활성화하거나 비활성화하며, FIPS-140-1 호환을 활성화하거나 비활성화하고 기본 공급자를 암호화 작업에 할당할 수 있습니다. 이 도구는 key3.db, cert7.db 및 secmod.db 보안 데이터베이스 파일도 만들 수 있습니다. 이 도구에 대한 자세한 내용은 http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html을 참조하십시오.

Application Server에 하드웨어 암호화 가속기 사용

하드웨어 가속기 토큰을 사용하면 암호화 성능을 향상시킬 수 있으며 보안 키 저장소 기능을 제공할 수 있습니다. 또한, 스마트 카드를 통해 최종 사용자에게 이동식 보안 키 저장소를 제공할 수도 있습니다.

Sun Java System Application Server 8.1 및 8.2 Standard Edition 또는 Enterprise Edition은 Java 2 Platform, Standard Edition(J2SE 플랫폼) 5.0에서 실행되는 경우, SSL 또는 TLS 통신에 대한 PKCS#11 토큰 사용 및 키와 PKCS#11 토큰을 관리하는 데 필요한 NSS(Network Security Services) 도구를 지원합니다. 이 절에서는 Application Server가 해당 지원을 제공하는 방법에 대해 설명하며 관련 구성에 대한 절차를 안내합니다.

J2SE 5.0 PKCS#11 공급자는 Application Server 런타임과 쉽게 통합할 수 있습니다. 이 공급자를 통해 Application Server에서 하드웨어 가속기 및 다른 PKCS#11 토큰을 사용함으로써 빠른 성능을 얻을 수 있으며 SSL 또는 TLS 통신의 고유 개인 키를 보호할 수 있습니다.

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

하드웨어 암호화 가속기 구성 정보

Sun Java System Application Server 8.1 및 8.2 Standard Edition 또는 Enterprise Edition은 Sun Crypto Accelerator 1000(SCA-1000) 및 SCA-4000 테스트를 거쳤습니다.

Application Server는 J2SE 5.0과 함께 사용하는 경우 PKCS#11 토큰과 통신할 수 있습니다. NSS PKCS#11 토큰 라이브러리(NSS 내부 PKCS#11 모듈의 경우 일반적으로 NSS 소프트 토큰으로 알려져 있음) 및 NSS 명령줄 관리 도구는 Application Server에 패키지화되어 있습니다. 자세한 내용은 NSS(Network Security Services) 도구 사용을 참조하십시오.

런타임 시 토큰 키와 인증서에 액세스할 수 있도록 NSS 도구를 사용하여 PKCS#11 토큰 및 J2SE PKCS#11 공급자에 키와 인증서를 만듭니다. PKCS#11 공급자는 원시 PKCS#11 라이브러리에 대한 래퍼 역할을 하는 암호화 서비스 공급자입니다. PKCS#11 토큰은 일반적으로 원시 PKCS#11 인터페이스를 가진 모든 하드웨어 및 소프트웨어 토큰을 나타냅니다. 하드웨어 토큰은 하드웨어 가속기 및 스마트 카드와 같은 물리적 장치에서 구현되는 PKCS#11 토큰입니다. 소프트웨어 토큰은 전적으로 소프트웨어에서 구현되는 PKCS#11 토큰입니다.

주 –

J2SE 1.4.x 플랫폼에서 Application Server를 실행하면 하나의 PKCS#11 토큰(NSS 소프트 토큰)만 지원됩니다.

Microsoft Windows 환경의 경우, NSS 라이브러리 AS_NSS의 위치와 NSS 도구 디렉토리 AS_NSS_BIN의 위치를 PATH 환경 변수에 추가합니다. 작업상 편의를 위해 이 절의 절차에서는 UNIX 명령만 사용합니다. 적절한 위치에서 UNIX 변수를 Windows 변수로 바꿔야 합니다.

하드웨어 암호화 가속기를 구성하려면 다음의 두 가지 주요 절차를 수행합니다.

PKCS#11 토큰 구성

이 절에서는 NSS 보안 도구 modutil을 사용하여 PKCS#11 토큰을 구성하는 방법에 대해 설명합니다. 다음 절차를 사용하여 PKCS#11 토큰을 구성합니다.

다음 명령을 모두 한 줄로 입력합니다.

modutil -dbdir AS_NSS_DB -nocertdb -force -add moduleName -libfile
 absolute_path_of_pkcs11_library -mechanisms list_of_security_mechanisms

여기서, AS_NSS_DB는 NSS 데이터베이스 디렉토리입니다(DAS(Domain Administration Server)를 사용하는 경우 AS_DOMAIN_CONFIG와 동일함).

예를 들어, 하드웨어 가속기 토큰을 구성하려면 다음을 모두 한 줄로 입력합니다.

modutil -dbdir AS_NSS_DB -nocertdb -force -add "Sun Crypto Accelerator" -libfile
 /opt/SUNWconn/crypto/lib/libpkcs11.so -mechanisms RSA:DSA:RC4:DES

이 예에서 하드웨어 가속기는 SCA–1000 암호화 가속기입니다. 해당 PKCS#11 라이브러리는 기본적으로 /opt/SUNWconn/crypto/lib/libpkcs11.so에 있습니다.

mechanisms는 해당 토큰에 사용할 수 있는 암호화 메커니즘에 대한 전체 목록이어야 합니다. 몇 개의 암호화 메커니즘만 사용하려면 J2SE 5.0 PKCS#11 공급자 구성을 참조하십시오. 지원되는 모든 메커니즘 목록을 보려면 NSS 보안 도구 사이트(http://www.mozilla.org/projects/security/pki/nss/tools)의 modutil 설명서를 참조하십시오.

다음 예에서는 토큰 설치 시 지정한 토큰 이름이 mytoken이라고 가정합니다.

하드웨어 가속기가 제대로 구성되었는지 확인하려면 다음 명령을 입력합니다. 

modutil -list -dbdir AS_NSS_DB

표준 출력은 다음과 유사합니다.


Using database directory /var/opt/SUNWappserver/domains/domain1/config ...

Listing of PKCS#11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS#11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services                            
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services                  
        token: NSS Certificate DB

  2. Sun Crypto Accelerator
        library name: /opt/SUNWconn/crypto/lib/libpkcs11.so
         slots: 1 slot attached
        status: loaded

         slot: Sun Crypto Accelerator:mytoken
        token: mytoken
-----------------------------------------------------------

키 및 인증서 관리

이 절에서는 certutil 및 pk12util을 사용하여 키 및 인증서를 만들고 관리하는 몇 가지 일반 절차에 대해 설명합니다. certutil 및 pk12util에 대한 자세한 내용은 NSS(Network Security Services) 도구 사용 및 NSS 보안 도구 사이트(http://www.mozilla.org/projects/security/pki/nss/tools)의 설명서를 참조하십시오.

주 –

또한 java.security 등록 정보 파일(Java 런타임의 JAVA_HOME/jre/lib/security 디렉토리에 있음)에 PKCS#11 공급자를 구성하면 J2SE keytool 유틸리티를 사용하여 키와 인증서를 관리할 수 있습니다. keytool 사용에 대한 자세한 내용은 http://java.sun.com/j2se/1.5.0/docs/guide/secuirty/p11guide.html의 Java PKCS#11 Reference Guide를 참조하십시오.

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

키 및 인증서 나열

개인 키 및 인증서 작업

certutil을 사용하여 자체 서명된 인증서를 만들고 인증서를 가져오거나 내보냅니다. 개인 키를 가져오거나 내보내려면 pk12util 유틸리티를 사용합니다. 자세한 내용은 NSS(Network Security Services) 도구 사용을 참조하십시오.

주의 – 주의 –

Application Server에서 NSS 도구 certutil 및 modutil을 사용하여 NSS 비밀번호를 직접 수정하지 마십시오. NSS 비밀번호를 직접 수정하면 Application Server의 보안 데이터가 손상될 수 있습니다.

J2SE 5.0 PKCS#11 공급자 구성

Application Server는 J2SE PKCS#11 공급자를 사용하여 런타임 시 PKCS#11 토큰에 있는 키 및 인증서에 액세스합니다. 기본적으로 Application Server는 NSS 소프트 토큰에 J2SE PKCS#11 공급자를 구성합니다. 이 절에서는 J2SE PKCS#11 공급자의 기본 구성을 대체하는 방법에 대해 설명합니다.

Application Server에서 각 PKCS#11 토큰에 다음과 같은 기본 PKCS#11 구성 매개 변수가 생성됩니다.

이 구성은 Java PKCS#11 Reference Guide에 설명된 구문을 준수합니다.

주 –

이름 매개 변수는 고유해야 하며, 이외의 다른 요구 사항은 없습니다. J2SE 5.0과 같은 이전의 특정 버전은 영숫자 문자만 지원합니다.

사용자 정의 구성 파일을 만들어 기본 구성 매개 변수를 대체할 수 있습니다. 예를 들어, SCA–1000의 RSA 암호화 및 RSA 키 쌍 생성기를 명시적으로 비활성화할 수 있습니다. RSA 암호화 및 RSA 키 쌍 생성기를 비활성화하는 방법에 대한 자세한 내용은 http://www.mozilla.org/projects/security/pki/nss/tools를 참조하십시오.

사용자 정의 구성 파일을 만들려면 다음을 수행합니다.

  1. 다음 코드를 사용하여 install-dir/mypkcs11.cfg라는 구성 파일을 만들고 저장합니다.


    name=HW1000
library=/opt/SUNWconn/crypto/lib/libpkcs11.so
slotListIndex=0
disabledMechanisms = {
	CKM_RSA_PKCS
	CKM_RSA_PKCS_KEY_PAIR_GEN
}
omitInitialize=true

  2. 필요한 경우 NSS 데이터베이스를 업데이트합니다. 여기서는 RSA를 비활성화하기 위해 NSS 데이터베이스를 업데이트합니다.

    다음 명령을 실행합니다.


    modutil -undefault "Sun Crypto Accelerator" -dbdir AS_NSS_DB -mechanisms RSA

    mechanisms 목록의 알고리즘 이름은 기본 구성의 알고리즘 이름과 다릅니다. NSS의 유효한 mechanisms 목록을 보려면 NSS 보안 도구 사이트(http://www.mozilla.org/projects/security/pki/nss/tools)의 modutil 설명서를 참조하십시오.

  3. 다음과 같이 등록 정보를 해당 위치에 추가하여 서버에 이 변경 사항을 업데이트합니다.


    <property name="mytoken" value="&InstallDir;/mypkcs11.cfg"/>

    등록 정보의 위치는 다음 중 하나일 수 있습니다.

    • 공급자가 DAS 또는 서버 인스턴스용인 경우, 연관된 <security-service> 아래에 등록 정보를 추가합니다.

    • 공급자가 노드 에이전트용인 경우, domain.xml 파일에서 연관된 <node-agent> 요소 아래에 등록 정보를 추가합니다.

  4. Application Server를 다시 시작합니다.

    사용자 정의한 구성을 적용하려면 서버를 다시 시작합니다.

추가 정보