보안 계획 개요

인터넷의 정보에 액세스하는 경우, 웹 서버 및 제품 서버를 통해 백엔드의 엔터프라이즈 데이터에 연결합니다. 이 섹션에서는 몇 가지 일반 구성 및 일반 보안 실례를 살펴봅니다.

이 절에서는 각 보안 계층이 제공하는 보안 보호와 엔드 투 엔드 보안에서의 양질의 보호에 대한 일반 보안 실례에서 제공하는 보안 보호를 살펴 봅니다. 다음 그림에서는 WebSphere® Application Server에 있는 보안의 운영 환경을 구성하는 빌딩 블록을 보여줍니다.

이 절에서는 각 보안 계층이 제공하는 보안 보호와 엔드 투 엔드 보안에서의 양질의 보호에 대한 일반 보안 실례에서 제공하는 보안 보호를 살펴봅니다. 다음 그림에서는 WebSphere® Application Server에 있는 보안의 운영 환경을 구성하는 빌드 블록을 보여줍니다.

다음 정보는 이전 그림에서 설명한 WebSphere Application Server 보안, Java™ 보안 및 플랫폼 보안의 각 컴포넌트에 대해 설명합니다.
WebSphere Application Server 보안
WebSphere 보안
WebSphere Application Server 보안은 웹 자원, 엔터프라이즈 Bean 및 JMX 관리 자원에 대한 액세스에서 통합 방식으로 보안 정책 및 서비스를 강제 실행합니다. WebSphere Application Server 보안 기술 및 기능으로 구성되어 보안 엔터프라이즈 환경의 요구를 지원합니다.
Java 보안
Java EE(Java Platform, Enterprise Edition) 보안 API(Application Programming Interface)
보안 협력자가 Java EE(Java Platform, Enterprise Edition) 기반 보안 정책을 강제 실행하고 Java EE 보안 API를 지원합니다.
CSIv2(Common Secure Interoperability Protocol 버전 2)를 사용한 EJB 보안
CSIv2(Common Secure Interoperability Version 2)는 OMG(Object Management Group)에 의해 개발된 IIOP 기반, 3중 계층의 보안 프로토콜입니다. 이 프로토콜은 메시지 보호, 상호운용 인증 및 대표를 제공합니다. 세 계층에는 기본 전송 보안 계층, 보조 클라이언트 인증 계층 및 보안 속성 계층이 포함됩니다. WebSphere Application Server for z/OS®는 CSIv2, 일치 레벨 0을 지원합니다.
Java 2 보안
Java 2 보안 모델은 파일 시스템, 시스템 특성, 소켓 연결, 스레딩, 클래스 로딩 등을 포함하여 시스템 자원에 대한 세분화된 액세스 제어를 제공합니다. 보호 설정된 자원에 액세스하기 위해서는 애플리케이션 코드에 명시적으로 필수 권한이 부여되어야 합니다.
JVM(Java Virtual Machine) 5.0
JVM 보안 모델은 운영 체제 계층 위에 보안 계층을 제공합니다. 예를 들어, JVM 보안은 제한되지 않은 액세스로부터 메모리를 보호하고 스레드 내에 오류가 발생할 때 예외를 생성하며 배열 유형을 정의합니다.
플랫폼 보안
[AIX Solaris HP-UX Linux Windows][IBM i]운영 체제 보안

기본 운영 체제의 보안 인프라는 WebSphere Application Server에 특정 보안 서비스를 제공합니다. 이러한 서비스에는 WebSphere Application Server를 위한 제품 설치 시 민감한 파일을 보호하는 파일 시스템 보안 지원이 들어 있습니다. 시스템 관리자는 제품을 구성하여 운영 체제 사용자 레지스트리에서 직접 인증 정보를 획득할 수 있습니다.

[z/OS]운영 체제 보안

기본 운영 체제의 보안 인프라는 WebSphere Application Server에 특정 보안 서비스를 제공합니다. STARTED 프로파일에 설정된 하위(servant), 제어기 및 디먼 시작 태스크의 운영 체제 ID는 시스템 자원(예: 파일 또는 소켓)에 대한 액세스를 제어하는 데 사용되는 ID입니다. 선택적으로, 운영 체제 보안은 로컬 운영 체제의 사용자 레지스트리를 사용하는 인증 서비스를 제공하거나, WebSphere 관리 콘솔 및 애플리케이션 서버 아래에서 실행되는 애플리케이션에 대해 SAF 인증을 사용하는 인증 서비스를 제공합니다.

관리자는 SSL(Secure Sockets Layer) 및 TLS(Transport Layer Securit)에 대한 지식은 물론 SAF(System Authorization Facilit) 및 RACF®(Resource Access Control Facility) 또는 동일한 SAF 기본 제품도 잘 알고 있어야 합니다.

사용자의 ID 및 확인은 로컬 운영 체제를 사용자 레지스트리, RACF 또는 동등한 SAF 기본 제품으로 사용하여 관리할 수 있습니다. 또는, LDAP, 사용자 정의 또는 연합 사용자 레지스트리를 사용할 수도 있습니다.

SAF 인증을 사용하도록 WebSphere를 구성할 수 있습니다. SAF 인증은 RACF 또는 동등한 SAF 기본 제품을 사용하여 사용자 및 그룹 자원을 관리하고 보호합니다. 또한 WebSphere 인증 또는 JACC 외부 권한 제공자를 사용하도록 WebSphere를 구성할 수 있습니다.

로컬 운영 체제를 사용자 레지스트리로 사용하거나 SAF 인증을 사용할 때, 보안 감사는 RACF 또는 동등한 SAF 기반 제품의 상속 기능입니다.

네트워크 보안
네트워크 보안 계층은 전송 레벨 인증, 메시지 무결성 및 기밀성을 제공합니다. SSL(Secure Sockets Layer)을 사용하도록 개별 애플리케이션 서버 간에 통신을 구성할 수 있습니다. 추가적으로 IP 보안 및 VPN(Virtual Private Network)는 추가된 메시지 보호를 위해 사용될 수 있습니다.
WebSphere Application Server, Network Deployment 설치
중요사항: 모든 컴퓨터 노드에는 노드 에이전트 인스턴스가 있습니다.

각 제품 애플리케이션 서버는 웹 컨테이너, EJB(Enterprise Java Beans) 컨테이너 및 관리 서브시스템으로 구성됩니다.

WebSphere Application Server 배치 관리자는 WebSphere Application Server 관리 코드 및 관리 콘솔만을 포함합니다.

관리 콘솔은 관리 기능을 수행하기 위한 인터페이스를 제공하는 특수 Java EE 웹 애플리케이션입니다. WebSphere Application Server 구성 데이터는 XML 디스크립터 파일에 저장되는데, 이 파일을 운영 체제 보안으로 보호 설정해야 합니다. 비밀번호와 기타 민감한 구성 데이터는 관리 콘솔을 사용하여 수정될 수 있습니다. 하지만 이들 비밀번호와 민감한 데이터를 보호해야 합니다. 자세한 정보는 파일의 비밀번호 인코딩의 내용을 참조하십시오.

관리 콘솔 웹 애플리케이션에는 관리 보안이 사용 가능한 경우 SSL 연결을 통해서만 JSP(JavaServer Pages) 파일 및 관리 콘솔 서블릿에 액세스해야 하는 설정 데이터 제한조건이 있습니다.

[AIX Solaris HP-UX Linux Windows][IBM i]WebSphere Application Server 버전 6.0.x 및 이전 버전에서는 기본 자체 서명된 인증과 함께 DummyServerKeyFile.jksDummyServerTrustFile.jks를 사용하도록 관리자 콘솔 HTTPS 포트가 구성되어 있습니다. WebSphere Application Server 설치 직후에 더미 인증 및 키를 바꾸어야 합니다. 해당 키는 모든 설치에서 공통되므로 안전하지 않습니다. WebSphere Application Server 버전 6.1은 통합 인증 및 키 관리를 제공하며, 이를 통해 호스트 이름 확인이 가능한 임베디드 서버 호스트 이름을 사용하여 자체 서명된 인증 및 고유한 개인 키가 생성됩니다. 또한 WebSphere Application Server 버전 6.1은 외부 CA(Certificate Authority)와 통합하여 CA 발행 인증을 사용할 수 있습니다. WebSphere Application Server 버전 6.1 설치 프로세스는 설치 중에 관리 보안을 사용 가능하게 하는 옵션을 제공합니다. 따라서 WebSphere Application Server 프로세스는 설치 직후 보호됩니다. WebSphere Application Server 버전 7.0은 구축된 신뢰에 영향을 미치지 않고 개인용 인증을 새로 고치기 위해 체인된 인증(루트 인증으로 서명된 개인용 인증)을 작성하여 임베디드 인증 관리 기능을 확장합니다. 또한 기본 키 저장소 비밀번호를 변경하는 기능을 비롯하여 프로파일 작성 중에(프로파일을 가져오거나 기본적으로 작성된 식별 이름(DN)을 변경할 수 있음) 인증에 맞게 조정할 수 있는 기능이 있습니다.

[AIX Solaris HP-UX Linux Windows][IBM i]다음 그림은 일반적인 여러 개의 티어 비즈니스 컴퓨팅 환경을 표시합니다. 노드 에이전트 인스턴스는 모든 컴퓨터 노드에 있습니다. 각 제품 애플리케이션 서버는 웹 컨테이너, EJB(Enterprise Java Beans) 컨테이너 및 관리 서브시스템으로 구성됩니다. WebSphere Application Server 배치 관리자에는 WebSphere Application Server 관리 코드 및 관리 콘솔만이 있습니다.

[z/OS]다음 그림은 일반적인 여러 개의 티어 비즈니스 컴퓨팅 환경을 표시합니다. 노드 에이전트 인스턴스는 모든 컴퓨터 노드에 있습니다. 각 제품 애플리케이션 서버는 웹 컨테이너, EJB(Enterprise Java Beans) 컨테이너 및 관리 서브시스템으로 구성됩니다. WebSphere Application Server 배치 관리자에는 WebSphere Application Server 관리 코드 및 관리 콘솔만이 있습니다.

관리 보안

[AIX Solaris HP-UX Linux Windows][IBM i]WebSphere Application Server는 HTTP 및 HTTPS 프로토콜은 물론 CSIv2 및 SAS(Secure Authentication Services) 보안 프로토콜을 통해 서로 상호작용합니다.
중요사항: SAS는 버전 6.1 셀에 연합된 이전 버전 서버와 버전 6.0.x 서버 사이에서만 지원됩니다.
[z/OS]WebSphere Application Server는 HTTP 및 HTTPS 프로토콜은 물론 CSIv2 및 z/SAS(z/OS Secure Authentication Services) 보안 프로토콜을 통해 서로 상호작용합니다.
중요사항: z/SAS는 버전 6.1 셀에 연합된 이전 버전 서버와 버전 6.0.x 서버 사이에서만 지원됩니다.

WebSphere Application Server 관리 보안을 사용할 때 SSL(Secure Sockets Layer)을 사용하도록 해당 프로토콜을 구성할 수 있습니다. 모든 서버에서 WebSphere Application Server 관리 서브시스템은 SOAP, JMX(Java Management Extensions) 커넥터 및 RMI/IIOP(Remote Method Invocation over the Internet Inter-ORB Protocol) JMX 커넥터를 사용하여 관리 명령 및 구성 데이터를 전달합니다. 관리 보안이 사용 불가능하면, SOAP JMX 커넥터는 HTTP 프로토콜을 사용하며 RMI/IIOP 커넥터는 TCP/IP 프로토콜을 사용합니다. 관리 보안이 사용 가능하면, SOAP JMX 커넥터는 항상 HTTPS 프로토콜을 사용합니다. 관리 보안이 사용 가능하면, RMI/IIOP JMX 커넥터는 SSL을 사용하거나 TCP/IP를 사용하도록 구성될 수 있습니다. 관리 보안을 사용 가능하게 하고 SSL을 사용 가능하게 하여 민감한 구성 데이터를 보호하는 것이 좋습니다.

[z/OS]관리 보안이 사용 불가능한 경우라도 애플리케이션에 대해 HTTPS를 사용 가능하게 할 수 있습니다. SSL 포트를 환경 구성의 가상 호스트에 추가하는 것 외에 서버 웹 컨테이너의 HTTP 포트 목록에 추가하여 특정 서버용으로 SSL 포트를 구성할 수 있습니다. HTTPS 및 올바른 포트를 사용하여 웹 애플리케이션에 연결할 수 있습니다. 내부 WebSphere Application Server for z/OS 통신에서는 관리 보안을 사용하는 경우에만 SSL을 사용합니다.

관리 보안이 사용 가능하면 서버 레벨에서 관리 보안 사용 가능 옵션을 지워 각 애플리케이션 서버에서 애플리케이션 보안을 사용 불가능하게 할 수 있습니다. 자세한 정보는 특정 애플리케이션 서버 보안의 내용을 참조하십시오. 애플리케이션 서버 보안을 사용 불가능하게 하면 보안 구성으로만 제어되는 해당 애플리케이션 서버에서 관리 서브시스템에 영향을 미치지 않습니다. 애플리케이션 서버에서 관리 서브시스템 및 애플리케이션 코드 둘 다 서버 보안 프로토콜 구성별 선택사항을 공유합니다.

Java EE 자원용 보안

Java EE 자원용 보안은 웹 컨테이너 및 EJB 컨테이너에서 제공됩니다. 각 컨테이너는 선언 보안과 프로그램 방식 보안인 두 가지 유형의 보안을 제공합니다.

선언 보안에서 애플리케이션 보안 구조는 네트워크 메시지 무결성, 기밀성, 인증 요구사항, 보안 역할 및 액세스 제어를 포함합니다. 액세스 제어는 애플리케이션과는 독립된 형식으로 표현됩니다. 특히 배치 디스크립터는 Java EE 플랫폼에서 선언 보안용의 1차 도구입니다. WebSphere Application Server는 배치 디스크립터로부터 파생된 정보와 XML 디스크립터 파일 세트의 배치자 및 관리자에 의해 지정된 정보를 포함한 Java EE 보안 정책을 유지보수합니다. 런타임 시, 컨테이너는 XML 디스크립터 파일에서 정의된 보안 정책을 사용하여 데이터 제한조건 및 액세스 제어를 강제 실행합니다.

선언 보안만으로는 애플리케이션의 보안 모델을 표현하는 데 부족할 경우, 프로그램 보안을 사용하여 액세스를 결정할 수 있습니다. 관리 보안이 사용 가능하며 애플리케이션 서버 보안이 서버 레벨에서 사용 가능하면, Java EE 애플리케이션 보안이 강제 실행됩니다. 보안 정책이 웹 자원용으로 지정되면, 웹 클라이언트가 자원을 요청할 때 웹 컨테이너는 액세스 제어를 수행합니다. 아무것도 표시되지 않는 경우 웹 컨테이너는 지정된 인증 메소드에 따라 인증 데이터의 웹 클라이언트를 확인하여, 데이터 제한조건이 충족되는지 확인하고 인증된 사용자가 필수 보안 역할을 갖는지 여부를 판별합니다. 웹 보안 협력자는 액세스 관리자 구현을 사용하여 역할 기반 액세스 제어를 강제 실행합니다. 액세스 관리자는 배치 디스크립터의 보안 정책을 기반으로 권한 결정을 내립니다. 사용자 프린시펄이 필수 보안 역할 중 하나를 수행하는 경우 인증된 사용자 프린시펄을 통해 요청된 서블릿 또는 JSP에 액세스할 수 있습니다. 서블릿 및 JSP 파일은 HttpServletRequest 메소드(isUserInRole 및 getUserPrincipal)를 사용할 수 있습니다.

[AIX Solaris HP-UX Linux Windows][IBM i]관리 보안 및 애플리케이션 보안이 사용 가능하고 애플리케이션 서버 레벨 애플리케이션 보안이 사용 불가능할 경우, EJB 컨테이너는 EJB 메소드 호출에서 액세스 제어를 강제로 실행합니다.

[z/OS]셀 레벨 보안이 사용 가능하고 서버 보안이 사용 불가능할 경우, EJB 컨테이너는 EJB 메소드 호출에서 액세스 제어를 강제로 실행합니다.

특정 EJB 메소드용으로 정의된 메소드 권한과는 관계없이 인증이 발생합니다. EJB 보안 협력자는 액세스 관리자 구현을 사용하여 역할 기반 액세스 제어를 강제 실행합니다. 액세스 관리자는 배치 디스크립터의 보안 정책을 기반으로 권한 결정을 내립니다. 필수 보안 역할 중 하나를 수행할 경우, 인증된 사용자 대상을 사용하여 요청된 EJB 메소드에 액세스할 수 있습니다. EJB 코드는 EJBContext 메소드(isCallerInRole 및 getCallerPrincipal)를 사용할 수 있습니다. 권한 없는 사용자가 인터넷 및 인트라넷을 통해 액세스하지 못하도록 가치있는 비즈니스 데이터를 보호하려면 Java EE 역할 기반 액세스 제어를 사용하십시오. 어셈블리 도구를 사용하여 웹 애플리케이션 보안엔터프라이즈 Bean 애플리케이션 보안의 내용을 참조하십시오.

역할 기반 보안

WebSphere Application Server는 JMX 시스템 관리 서브시스템, 사용자 레지스트리 및 JNDI(Java Naming and Directory Interface) 네임스페이스를 포함하여 관리 자원에 대한 보안, 역할 기반 액세스 제어를 확장합니다. WebSphere 관리 서브시스템은 다음 4가지 관리 보안 역할을 정의합니다.
모니터 역할
모니터는 구성 정보 및 상태를 볼 수 있지만 변경할 수는 없습니다.
조작자 역할
운영자 역할은 애플리케이션 서버를 시작하거나 애플리케이션을 중지하는 것과 같은 런타임 상태 변경을 트리거할 수 있지만 구성 변경은 할 수 없습니다.
구성자 역할
구성자는 구성 정보를 수정할 수 있지만 런타임 상태를 변경할 수는 없습니다.
관리자 역할
구성자겸 운영자 - 민감한 보안 구성 및 보안 정책을 추가로 수정(예: 서버 ID 및 비밀번호 설정)하고 관리 보안 및 Java 2 보안을 사용 가능 또는 사용 불가능하게 하며 사용자 및 그룹을 관리자 역할에 맵핑할 수 있습니다.
iscadmins
iscadmins 역할에는 관리 콘솔 내에서만 사용자와 그룹을 관리할 수 있는 특권이 있습니다.
WebSphere Application Server는 wsadmin 스크립트를 사용할 때에만 사용 가능한 두 가지 추가 역할을 정의합니다.
Deployer
배치자는 애플리케이션에서 구성 조치와 런타임 조작을 모두 수행할 수 있습니다.
Adminsecuritymanager
관리 보안 관리자는 사용자를 관리 역할에 맵핑할 수 있습니다. 또한 세분화된 관리 보안이 사용되는 경우 이 역할이 부여된 사용자는 권한 그룹을 관리할 수 있습니다.
감사자
감사자는 보안 감사 서브시스템에 대한 구성 설정값을 보고 수정할 수 있습니다.

구성자 역할을 가진 사용자는 새 애플리케이션 및 애플리케이션 서버를 설치하는 것을 포함하여 대부분의 관리 작업을 수행할 수 있습니다. WebSphere Application Server ID 및 비밀번호, LTPA(Lightweight Third-Party Authentication) 비밀번호 및 키를 수정하고 사용자에게 관리 보안 역할을 지정하는 것을 포함하여 관리 보안이 사용 가능할 때 구성자가 수행할 권한이 충분하지 않은 특정 구성 태스크가 있습니다. 서버 ID는 관리자 역할로 맵핑되므로 이러한 민감한 구성 태스크에는 관리 역할이 필요합니다.

관리 서브시스템 무결성을 보호하려면 WebSphere Application Server 관리 보안을 사용 가능하게 하십시오. 보호할 민감한 정보를 사용할 수 없는 경우, 애플리케이션 서버 보안을 선택적으로 사용 불가능하게 할 수 있습니다. 관리 보안의 보호는 관리 역할에 대한 액세스 권한 부여사용자 및 그룹을 역할로 지정의 내용을 참조하십시오.

Java 2 보안 권한

WebSphere Application Server는 Java 2 보안 모델을 사용하여 애플리케이션 코드를 실행하는 보안 환경을 작성합니다. Java 2 보안은 세분화된 정책 기반 액세스 제어를 제공하여 시스템 자원(예: 파일, 시스템 특성, 개방 소켓 연결, 로딩 라이브러리 등)을 보호합니다. Java EE 버전 1.4 스펙은 웹 및 EJB 컴포넌트가 소유하는 것으로 기대하는 Java 2 보안 권한의 일반 세트를 정의합니다.

표 1. 웹 컴포넌트에 대한 Java EE 보안 권한 세트. 웹 컴포넌트에 대한 Java EE 보안 권한 세트는 다음 표에 나와 있습니다.
보안 권한 대상 조치
java.lang.RuntimePermission loadLibrary  
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * 연결
java.io.FilePermission * 읽기, 쓰기
java.util.PropertyPermission * read
표 2. EJB 컴포넌트에 대한 Java EE 보안 권한 세트. EJB 컴포넌트에 대한 Java EE 보안 권한 세트는 다음 표에 나와 있습니다.
보안 권한 대상 조치
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * 연결
java.util.PropertyPermission * read
WebSphere Application Server Java 2 보안 기본 정책은 Java EE 버전 1.4 스펙에 근거합니다. 스펙에서는 너무 광범위한 파일 시스템에서 임의의 파일에 대한 읽기 및 쓰기 파일 액세스 권한을 웹 컴포넌트에 부여합니다. WebSphere Application Server 기본 정책은 웹 모듈이 설치된 서브트리와 서브디렉토리에 대한 읽기 및 쓰기 권한을 웹 컴포넌트에 부여합니다. 모든 JVM(Java Virtual Machine) 및 WebSphere Application Server 프로세스에 대한 기본 Java 2 보안 정책은 다음과 같은 정책 파일에 포함됩니다.
[IBM i]/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
[IBM i]JVM(Java Virtual Machine)의 기본 정책으로 사용됩니다.
[AIX Solaris HP-UX Linux Windows][z/OS]${java.home}/jre/lib/security/java.policy
[AIX Solaris HP-UX Linux Windows][z/OS]이 파일은 JVM(Java Virtual Machine)의 기본 정책으로 사용됩니다.
[AIX Solaris HP-UX Linux Windows][IBM i]${USER_INSTALL_ROOT}/properties/server.policy
[AIX Solaris HP-UX Linux Windows][IBM i]이 파일은 모든 제품 서버 프로세스의 기본 정책으로 사용됩니다.
[z/OS]$WAS_HOME/properties/server.policy
[z/OS]이 파일은 모든 제품 서버 프로세스의 기본 정책으로 사용됩니다.

정책 관리를 단순화시키기 위해, WebSphere Application Server 정책은 코드 기본(위치)보다는 자원 유형에 근거합니다. 다음 파일은 WebSphere Application Server 서브시스템의 기본 정책 파일입니다. WebSphere Application Server 런타임을 확장한 정책 파일을 SPI(Service Provider Programming Interfaces)라고 하며 다수의 Java EE 애플리케이션에서 공유됩니다.

[AIX Solaris HP-UX Linux Windows]
  • profile_root/config/cells/cell_name/nodes/node_name/spi.policy

    이 파일은 JMS(Java Message Service), JavaMail 및 JDBC 드라이버와 같은 resources.xml 파일에 정의된 임베디드 자원에 사용됩니다.

  • profile_root/config/cells/cell_name/nodes/node_name/library.policy

    이 파일은 WebSphere Application Server 관리 콘솔에서 정의한 공유 라이브러리에 사용됩니다.

  • profile_root/config/cells/cell_name/nodes/node_name/app.policy

    이 파일은 Java EE 애플리케이션의 기본 정책으로 사용됩니다.

[z/OS]
  • $WAS_HOME/config/cells/cell_name/nodes/node_name/spi.policy

    이 파일은 JMS(Java Message Service), JavaMail API 및 JDBC 드라이버와 같은 resources.xml 파일에 정의된 임베디드 자원에 사용됩니다.

  • $WAS_HOME/config/cells/cell_name/nodes/node_name/library.policy

    이 파일은 WebSphere Application Server 관리 콘솔에서 정의한 공유 라이브러리에 사용됩니다.

  • $WAS_HOME/config/cells/cell_name/nodes/node_name/app.policy

    이 파일은 Java EE 애플리케이션의 기본 정책으로 사용됩니다.

[IBM i]
  • profile_root/config/cells/cell_name/nodes/node_name/spi.policy

    JMS(Java Message Service), JavaMail 및 JDBC 드라이버와 같은 resources.xml 파일에 정의된 임베디드 자원에 사용됩니다.

  • profile_root/config/cells/cell_name/nodes/node_name/library.policy

    WebSphere Application Server 관리 콘솔에서 정의한 공유 라이브러리에 사용됩니다.

  • profile_root/config/cells/cell_name/nodes/node_name/app.policy

    Java EE 애플리케이션의 기본 정책으로 사용됩니다.

일반적으로, 애플리케이션은 여러 애플리케이션 서버 간에 이식 가능하도록 Java EE 스펙에서 권장하는 것보다 더 많은 권한을 요구하지 않아야 합니다. 그러나 일부 애플리케이션은 더 많은 권한을 필요로 할 수 있습니다. WebSphere Application Server는 해당 애플리케이션에 대해 추가 권한을 부여하기 위해 각 애플리케이션과 함께 was.policy 파일을 패키지로 묶을 수 있도록 지원합니다.
주의: 시스템 무결성을 손상시킬 가능성이 있으므로 신중히 고려한 후에만 애플리케이션에 추가의 사용 권한을 부여하십시오.

WebSphere Application Server로 라이브러리를 로드하면 애플리케이션은 Java 샌드박스를 그대로 유지할 수 있습니다. WebSphere Application Server는 권한 필터링 정책 파일을 사용하여 추가 권한 요구사항 때문에 애플리케이션 설치에 실패할 때 이를 사용자에게 알립니다. 예를 들어, 애플리케이션 코드로 WebSphere Application Server를 종료할 수 없도록 java.lang.RuntimePermission exitVM 권한을 애플리케이션에 제공하지 않는 것이 좋습니다.

필터링 정책은 profile_root/config/cells/cell_name/filter.policy 파일에서 filtermask로 정의됩니다. 또한 WebSphere Application Server는 런타임 필터링 정책에 근거하여 런타임 권한 필터링을 수행하여 어떠한 애플리케이션 코드에도 시스템 무결성에 해가 되는 것으로 간주되는 권한이 부여되지 않도록 합니다.

따라서WebSphere Application Server의 이전 릴리스용으로 개발된 많은 애플리케이션에는 Java 2 보안이 준비되지 않을 수 있습니다. 이러한 애플리케이션을 최신 버전의 WebSphere Application Server로 빠르게 마이그레이션시키기 위해 was.policy 파일의 java.security.AllPermission 권한을 해당 애플리케이션에 일시적으로 제공할 수 있습니다. Java 2 보안이 활성 상태인 환경에서 이 애플리케이션이 실행되는지 확인하기 위해 애플리케이션을 테스트하십시오. 예를 들어, 필수 추가 권한이 있으면 식별하여 특정 애플리케이션에 해당 권한만을 부여하십시오. 애플리케이션에 AllPermission 권한을 부여하지 않으면 시스템 무결성의 손상 위험을 줄일 수 있습니다. 애플리케이션 마이그레이션에 대한 자세한 정보는 Java 2 보안 정책 마이그레이션의 내용을 참조하십시오.

WebSphere Application Server 런타임은 Java 2 보안을 사용하여 민감한 런타임 기능을 보호합니다. AllPermission 권한이 부여된 애플리케이션에는 민감한 시스템 자원에 대한 액세스뿐만 아니라 WebSphere Application Server 런타임 자원에 대한 액세스도 있으며, 둘 다에 잠재적인 손상을 줄 수 있습니다. 애플리케이션이 안전하게 신뢰되는 경우에 WebSphere Application Server는 애플리케이션 서버 기준으로 사용 불가능한 Java 2 보안을 지원합니다. 관리 콘솔에서 기본적으로 Java 2 보안을 강제 실행하고 Java 2 보안 플래그를 지워 특정 애플리케이션 서버에서 사용 불가능하게 할 수 있습니다.

관리 콘솔의 글로벌 보안 패널에서 관리 보안 사용 가능 및 Java 2 보안을 사용하여 로컬 자원에 대한 애플리케이션 액세스 제한 옵션을 지정하는 경우, 정보 및 다른 민감한 구성 데이터는 XML 구성 파일 세트에 저장됩니다. 역할 기반 액세스 제어 및 Java 2 보안 권한 액세스 제어 둘 다 구성 데이터의 무결성을 보호하는 데 사용됩니다. 예에서는 시스템 무결성이 유지보수되는 방식을 예시하는 데 구성 데이터 보호를 사용합니다.
주의: WebSphere Application Server의 이전 릴리스에 있는 글로벌 보안 사용 가능 옵션은 버전 9.0관리 보안 사용 가능 옵션과 동일합니다. 또한 이전 릴리스에 있는 Java 2 보안 사용 가능 옵션도 버전 9.0의 Java 2 보안을 사용하여 로컬 자원에 대한 애플리케이션 액세스 제한 옵션과 동일합니다.
  • Java 2 보안이 강제 실행되면, 코드에 필수 WebSphere Application Server 런타임 권한을 부여한 경우를 제외하고는 구성 데이터를 관리하는 WebSphere Application Server 런타임 클래스에 애플리케이션 코드에서 액세스할 수 없습니다.
  • Java 2 보안이 강제 실행되면, 코드에 필수 파일 읽기 및 쓰기 권한을 부여한 경우를 제외하고는 WebSphere Application Server 구성 XML 파일에 애플리케이션 코드에서 액세스할 수 없습니다.
  • JMX 관리 서브시스템은 HTTP 또는 HTTPS 및 RMI/IIOP 원격 인터페이스에서 SOAP를 제공하여 애플리케이션이 구성 파일과 데이터를 추출하고 수정하게 합니다. 관리 보안이 사용 가능하면, 애플리케이션에 올바른 인증 데이터가 제공되고 보안 ID에 필수 보안 역할이 있는 경우 WebSphere Application Server 구성을 애플리케이션에서 수정할 수 있습니다.
  • 사용자가 Java 2 보안을 사용 불가능하게 할 수 있는 경우, 사용자는 다른 민감한 데이터와 함께 WebSphere Application Server 보안 ID 및 인증 데이터를 포함하는 WebSphere Application Server 구성을 수정할 수도 있습니다. 관리자 보안 역할이 있는 사용자만이 Java 2 보안을 사용 불가능하게 할 수 있습니다.
  • WebSphere Application Server 보안 ID에는 관리자 역할이 부여되므로, 관리자 역할이 있는 사용자에게만 관리 보안을 사용 불가능하게 하고, 서버 ID 및 비밀번호를 변경하고, 사용자 및 그룹을 관리 역할로 맵핑할 수 있는 것 등이 제공됩니다.
[AIX Solaris HP-UX Linux Windows][IBM i]

기타 런타임 자원

기타 WebSphere Application Server 런타임 자원은 이전에 설명한 대로 유사한 메커니즘에 의해 보호됩니다. WebSphere Application Server 관리 보안을 사용 가능하게 하고 Java 2 보안을 사용하여 로컬 자원에 대한 애플리케이션 액세스를 제한하는 것은 매우 중요합니다. Java EE 스펙은 웹 컴포넌트에 대해 여러 개의 인증 메소드(HTTP 기본 인증, 양식 기반 인증 및 HTTPS 클라이언트 증명 인증)를 정의합니다. 클라이언트 인증서 로그인을 사용할 때, 웹 자원이 중요한 기밀 데이터 제한조건을 갖는 경우 브라우저 클라이언트에 대해 더 편리합니다. 브라우저가 웹 자원에 액세스하기 위해 HTTP를 사용하는 경우, 웹 컨테이너는 HTTP 포트로 브라우저를 자동 경로 재지정합니다. CSIv2 보안 프로토콜도 클라이언트 증명 인증을 지원합니다. SSL 클라이언트 인증을 사용하여 신뢰 관계에 기반을 둔 선택된 서버 세트 간의 보안 통신을 설정할 수도 있습니다.

[z/OS]CSIv2 보안 프로토콜도 클라이언트 증명 인증을 지원합니다. SSL 클라이언트 인증은 신뢰 관계에 기반을 둔 선택된 서버 세트 간의 보안 통신을 설정하는 데 사용될 수 있습니다.

웹 서버의 WebSphere Application Server 플러그인에서 시작하면, 해당 플러그인과 WebSphere Application Server HTTPS 서버 사이에서 SSL 상호 인증을 구성할 수 있습니다. 인증을 사용하면 다음 그림처럼 두 개의 선택된 WebSphere Application Server에서만 통신하도록 WebSphere Application Server 플러그인을 제한할 수 있습니다. 자체 서명된 인증을 사용하여 관리 작업 및 비용을 줄일 수 있습니다.
예를 들어, WebSphere Application Server 플러그인 W에서만 보안 소켓 연결을 승인하도록 WebSphere Application Server A 및 WebSphere Application Server B의 HTTPS 서버를 제한하려고 합니다.
예를 들어, WebSphere Application Server 플러그인 W에서만 WebSphere Application Server AWebSphere Application Server B의 HTTPS 서버를 제한하려고 합니다.
  • [AIX Solaris HP-UX Linux Windows][IBM i]이 태스크를 완료하기 위해 IKEYMAN 및 인증 관리 유틸리티를 사용하여 세 개의 인증서를 생성할 수 있습니다. 또한 인증서 W를 사용하여 인증서 AB를 신뢰할 수 있습니다. 인증서 A를 사용하고 인증서 W를 신뢰하도록 WebSphere Application Server A의 HTTPS 서버를 구성하십시오.
  • [z/OS]이 태스크를 완료하기 위해 인증서 W, AB라는 RACF(Resource Access Control Facility)를 사용하여 세 개의 인증서를 생성할 수 있습니다. 인증서 W를 사용하고 인증서 AB를 신뢰하도록 WebSphere Application Server 플러그인을 구성하십시오. 인증서 A를 사용하고 인증서 W를 신뢰하도록 WebSphere Application Server A의 HTTPS 서버를 구성하십시오.
인증서 B를 사용하고 인증서 W를 신뢰하도록 WebSphere Application Server B의 HTTPS 서버를 구성하십시오.
표 3. 예제의 신뢰 관계. 이전 그림에서 설명한 신뢰 관계가 다음 표에 표시됩니다.
서버 신뢰
WebSphere Application Server 플러그인 W A, B
WebSphere Application Server A   W
WebSphere Application Server B B W

WebSphere Application Server 배치 관리자는 관리의 중심점입니다. 시스템 관리 명령은 배치 관리자에서 각 애플리케이션 서버로 전송됩니다. 관리 보안이 사용 가능하면, SSL 및 상호 인증을 요구하도록 WebSphere Application Server를 구성할 수 있습니다.

WebSphere Application Server AWebSphere Application Server C와 유일하게 통신하고 WebSphere Application Server BWebSphere Application Server D와 유일하게 통신할 수 있도록 제한하려 할 수 있습니다. 모든 WebSphere Application ServerWebSphere Application Server 배치 관리자 E와 통신할 수 있어야 합니다. 따라서 자체 서명된 인증을 사용하는 경우, 다음 표에 표시된 대로 CSIv2 및 SOAP/HTTPS 키 및 신뢰 관계를 구성할 수 있습니다.
표 4. 예제의 CSIv2 및 SOAP/HTTPS 키와 신뢰 관계. CSIv2 및 SOAP/HTTPS 키와 신뢰 관계는 다음 표에 나와 있습니다.
Server 신뢰
WebSphere Application Server A   C, E
WebSphere Application Server B B D, E
WebSphere Application Server C C A, E
WebSphere Application Server D D B, E
WebSphere Application Server 배치 관리자 E E A, B, C, D

WebSphere Application Server가 LDAP(Lightweight Directory Access Protocol) 사용자 레지스트리를 사용하도록 구성되면, 모든 애플리케이션 서버와 자체 서명된 인증을 갖춘 LDAP 서버 간에 상호 인증과 함께 SSL을 구성하여 비밀번호가 WebSphere Application Server에서 LDAP 서버로 전달될 때 표시되지 않도록 할 수 있습니다.

이 예에서 노드 에이전트 프로세스는 설명되지 않습니다. 각 노드 에이전트는 동일한 노드에서 애플리케이션 서버와 통신하고 배치 관리자와 통신해야 합니다. 또한 노드 에이전트는 LDAP 사용자 레지스트리를 사용하도록 구성될 때 LDAP 서버와 통신해야 합니다. 배치 관리자와 노드 에이전트가 동일한 인증서를 사용하는 것이 좋습니다. 애플리케이션 서버 AC는 동일한 컴퓨터 노드에 있다고 가정하십시오. 해당 노드에서 노드 에이전트는 인증서 AC를 신뢰 저장소에 가지고 있어야 합니다.

[AIX Solaris HP-UX Linux Windows][IBM i]WebSphere Application Server는 레지스트리 구성 또는 관리 유틸리티를 제공하지 않습니다. 그리고 레지스트리 비밀번호 정책을 지시하지 않습니다. 비밀번호 길이 및 만기 기간을 포함하여 레지스트리에서 권장하는 비밀번호 정책을 사용하는 것이 좋습니다.


주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_plan
파일 이름:csec_plan.html