test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 관리 설명서

Application Server 보안 정보

보안 개요

보안이란 데이터를 보호하는 것이며 데이터를 저장하거나 전송할 때 해당 데이터에 대한 인증 되지않은 액세스나 손상을 방지하는 방법입니다. 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의 비밀번호를 암호화할 수 있습니다.

Proceduredomain.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를 다시 시작합니다.

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

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

Procedure마스터 비밀번호를 변경하는 방법

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

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

Procedure관리 비밀번호를 변경하는 방법

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


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

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

  1. 관리 콘솔 트리 구성 요소에서 구성 노드를 확장합니다.

  2. 구성할 인스턴스를 선택합니다.

    • 특정 인스턴스를 구성하려면 해당 인스턴스의 구성 노드를 확장합니다. 예를 들어, 기본 인스턴스 server에 대해 server-config 노드를 확장합니다.

    • 모든 인스턴스의 기본 설정을 구성하려면 default-config 노드를 확장합니다.

  3. 보안 노드를 확장합니다.

  4. 영역 노드를 확장합니다.

  5. admin-realm 노드를 선택합니다.

  6. 영역 편집 페이지에서 사용자 관리 버튼을 누릅니다.

  7. admin이라는 사용자를 선택합니다.

  8. 새로운 비밀번호를 입력하고 비밀번호를 확인합니다.

  9. 저장을 눌러 저장하거나 닫기를 눌러 저장하지 않고 닫습니다.

보안 책임 지정

다음 항목에 보안 책임이 지정됩니다.

응용 프로그램 개발자

응용 프로그램 개발자의 책임은 다음과 같습니다.

응용 프로그램 개발자는 deploytool 같은 도구를 사용하여 응용 프로그램 배포 설명자를 편집할 수 있습니다. 이 보안 작업에 대해서는 http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html에서 볼 수 있는 J2EE 1.4 Tutorial의 Security 장에 자세히 설명되어 있습니다.

응용 프로그램 배포자

응용 프로그램 배포자의 책임은 다음과 같습니다.

응용 프로그램 배포자는 deploytool 같은 도구를 사용하여 응용 프로그램 배포 설명자를 편집할 수 있습니다. 이 보안 작업에 대해서는 http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html에서 볼 수 있는 J2EE 1.4 Tutorial의 Security 장에 자세히 설명되어 있습니다.

시스템 관리자

시스템 관리자의 책임은 다음과 같습니다.

시스템 관리자는 관리 콘솔을 사용하여 서버 보안 설정을 관리하고 certutil을 사용하여 인증서를 관리합니다. 이 문서는 기본적으로 시스템 관리자를 대상으로 합니다.

인증 및 권한 부여 정보

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

엔티티 인증

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

일반적으로 인증은 사용자 이름과 비밀번호를 사용하여 응용 프로그램에 로그인하는 것을 의미하지만 서버의 자원을 요청할 경우 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)이 활성화되어 있습니다. 단일 사인 온(SSO)을 비활성화하는 방법에 대한 자세한 내용은 단일 사인 온(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를 참조하십시오.

메시지 보안 구성

메시지 보안을 사용하면 서버는 메시지 계층에서 웹 서비스 호출 및 응답의 종단간 인증을 수행할 수 있습니다. 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 영역의 사용자를 관리할 수 있습니다. 자세한 내용은 file 영역 사용자 관리를 참조하십시오.

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

admin-realm은 FileRealm이기도 하며 admin-keyfile이라는 파일에 관리자 자격 증명을 로컬로 저장합니다. file 영역에서 사용자를 관리하는 것과 같은 방법으로 관리 콘솔을 사용하여 이 영역의 사용자를 관리합니다. 자세한 내용은 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 공급자 지정에 설명되어 있습니다. 관리 콘솔을 사용하여 다음 작업을 수행할 수 있습니다.

이 작업에 대한 자세한 내용은 JACC 공급자에 대한 관리 콘솔 작업을 참조하십시오.

감사 모듈

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

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

이 작업에 대한 자세한 내용은 감사 모듈에 대한 관리 콘솔 작업을 참조하십시오.

메시지 보안

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

이 작업에 대한 자세한 내용은 10 장, 메시지 보안 구성을 참조하십시오.

HTTP 및 IIOP Listener 보안

HTTP 서비스의 가상 서버마다 하나 이상의 HTTP Listener를 통해 네트워크 연결을 제공합니다. HTTP 서비스 및 HTTP Listener에 대한 자세한 내용은 HTTP 서비스를 참조하십시오.

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

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

이 작업에 대한 자세한 내용은 Listener 및 JMX 커넥터에 대한 관리 콘솔 작업을 참조하십시오.

관리 서비스 보안

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

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

이 작업에 대한 자세한 내용은 관리 서비스의 JMX 커넥터에 대한 보안을 구성하는 방법을 참조하십시오.

보안 맵

커넥터 연결 풀에 대한 보안 맵의 개념은 보안 맵 정보에 설명되어 있습니다. 관리 콘솔을 사용하여 다음 작업을 수행할 수 있습니다.

이 작업에 대한 자세한 내용은 커넥터 연결 풀에 대한 관리 콘솔 작업을 참조하십시오.