보안 계획 개요
인터넷의 정보에 액세스하는 경우, 웹 서버 및 제품 서버를 통해 백엔드의 엔터프라이즈 데이터에 연결합니다. 이 섹션에서는 몇 가지 일반 구성 및 일반 보안 실례를 살펴봅니다.
이 절에서는 각 보안 계층이 제공하는 보안 보호와 엔드 투 엔드 보안에서의 양질의 보호에 대한 일반 보안 실례에서 제공하는 보안 보호를 살펴 봅니다. 다음 그림에서는 WebSphere® Application Server에 있는 보안의 운영 환경을 구성하는 빌딩 블록을 보여줍니다.
- 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 보안은 제한되지 않은 액세스로부터 메모리를 보호하고 스레드 내에 오류가 발생할 때 예외를 생성하며 배열 유형을 정의합니다.
- 플랫폼 보안
운영 체제 보안
기본 운영 체제의 보안 인프라는 WebSphere Application Server에 특정 보안 서비스를 제공합니다. 이러한 서비스에는 WebSphere Application Server를 위한 제품 설치 시 민감한 파일을 보호하는 파일 시스템 보안 지원이 들어 있습니다. 시스템 관리자는 제품을 구성하여 운영 체제 사용자 레지스트리에서 직접 인증 정보를 획득할 수 있습니다.
운영 체제 보안
기본 운영 체제의 보안 인프라는 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)는 추가된 메시지 보호를 위해 사용될 수 있습니다.
각 제품 애플리케이션 서버는 웹 컨테이너, EJB(Enterprise Java Beans) 컨테이너 및 관리 서브시스템으로 구성됩니다.
WebSphere Application Server 배치 관리자는 WebSphere Application Server 관리 코드 및 관리 콘솔만을 포함합니다.
관리 콘솔은 관리 기능을 수행하기 위한 인터페이스를 제공하는 특수 Java EE 웹 애플리케이션입니다. WebSphere Application Server 구성 데이터는 XML 디스크립터 파일에 저장되는데, 이 파일을 운영 체제 보안으로 보호 설정해야 합니다. 비밀번호와 기타 민감한 구성 데이터는 관리 콘솔을 사용하여 수정될 수 있습니다. 하지만 이들 비밀번호와 민감한 데이터를 보호해야 합니다. 자세한 정보는 파일의 비밀번호 인코딩의 내용을 참조하십시오.
관리 콘솔 웹 애플리케이션에는 관리 보안이 사용 가능한 경우 SSL 연결을 통해서만 JSP(JavaServer Pages) 파일 및 관리 콘솔 서블릿에 액세스해야 하는 설정 데이터 제한조건이 있습니다.
WebSphere Application Server
버전 6.0.x 및 이전 버전에서는 기본 자체 서명된 인증과 함께 DummyServerKeyFile.jks 및 DummyServerTrustFile.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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
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을 사용 가능하게 하여 민감한 구성 데이터를 보호하는 것이 좋습니다.
관리 보안이 사용 불가능한 경우라도 애플리케이션에 대해
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)를 사용할 수 있습니다.
관리 보안 및 애플리케이션 보안이
사용 가능하고 애플리케이션 서버 레벨 애플리케이션 보안이 사용 불가능할 경우, EJB 컨테이너는 EJB 메소드 호출에서
액세스 제어를 강제로 실행합니다.
셀 레벨 보안이 사용 가능하고 서버 보안이 사용 불가능할 경우,
EJB 컨테이너는 EJB 메소드 호출에서 액세스 제어를 강제로 실행합니다.
특정 EJB 메소드용으로 정의된 메소드 권한과는 관계없이 인증이 발생합니다. EJB 보안 협력자는 액세스 관리자 구현을 사용하여 역할 기반 액세스 제어를 강제 실행합니다. 액세스 관리자는 배치 디스크립터의 보안 정책을 기반으로 권한 결정을 내립니다. 필수 보안 역할 중 하나를 수행할 경우, 인증된 사용자 대상을 사용하여 요청된 EJB 메소드에 액세스할 수 있습니다. EJB 코드는 EJBContext 메소드(isCallerInRole 및 getCallerPrincipal)를 사용할 수 있습니다. 권한 없는 사용자가 인터넷 및 인트라넷을 통해 액세스하지 못하도록 가치있는 비즈니스 데이터를 보호하려면 Java EE 역할 기반 액세스 제어를 사용하십시오. 어셈블리 도구를 사용하여 웹 애플리케이션 보안 및 엔터프라이즈 Bean 애플리케이션 보안의 내용을 참조하십시오.
역할 기반 보안
- 모니터 역할
- 모니터는 구성 정보 및 상태를 볼 수 있지만 변경할 수는 없습니다.
- 조작자 역할
- 운영자 역할은 애플리케이션 서버를 시작하거나 애플리케이션을 중지하는 것과 같은 런타임 상태 변경을 트리거할 수 있지만 구성 변경은 할 수 없습니다.
- 구성자 역할
- 구성자는 구성 정보를 수정할 수 있지만 런타임 상태를 변경할 수는 없습니다.
- 관리자 역할
- 구성자겸 운영자 - 민감한 보안 구성 및 보안 정책을 추가로 수정(예: 서버 ID 및 비밀번호 설정)하고 관리 보안 및 Java 2 보안을 사용 가능 또는 사용 불가능하게 하며 사용자 및 그룹을 관리자 역할에 맵핑할 수 있습니다.
- iscadmins
- iscadmins 역할에는 관리 콘솔 내에서만 사용자와 그룹을 관리할 수 있는 특권이 있습니다.
- 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 보안 권한의 일반 세트를 정의합니다.
보안 권한 | 대상 | 조치 |
---|---|---|
java.lang.RuntimePermission | loadLibrary | |
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | 연결 |
java.io.FilePermission | * | 읽기, 쓰기 |
java.util.PropertyPermission | * | read |
보안 권한 | 대상 | 조치 |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | 연결 |
java.util.PropertyPermission | * | read |
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
JVM(Java Virtual Machine)의 기본 정책으로 사용됩니다.
${java.home}/jre/lib/security/java.policy
이 파일은 JVM(Java Virtual Machine)의 기본 정책으로 사용됩니다.
${USER_INSTALL_ROOT}/properties/server.policy
이 파일은 모든 제품 서버 프로세스의 기본 정책으로 사용됩니다.
$WAS_HOME/properties/server.policy
이 파일은 모든 제품 서버 프로세스의 기본 정책으로 사용됩니다.
정책 관리를 단순화시키기 위해, WebSphere Application Server 정책은 코드 기본(위치)보다는 자원 유형에 근거합니다. 다음 파일은 WebSphere Application Server 서브시스템의 기본 정책 파일입니다. WebSphere Application Server 런타임을 확장한 정책 파일을 SPI(Service Provider Programming Interfaces)라고 하며 다수의 Java EE 애플리케이션에서 공유됩니다.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
- 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]](../images/ngzos.gif)
- $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]](../images/iseries.gif)
- 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 애플리케이션의 기본 정책으로 사용됩니다.
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 보안이 강제 실행되면, 코드에 필수 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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
기타 런타임 자원
기타 WebSphere Application Server 런타임 자원은 이전에 설명한 대로 유사한 메커니즘에 의해 보호됩니다. WebSphere Application Server 관리 보안을 사용 가능하게 하고 Java 2 보안을 사용하여 로컬 자원에 대한 애플리케이션 액세스를 제한하는 것은 매우 중요합니다. Java EE 스펙은 웹 컴포넌트에 대해 여러 개의 인증 메소드(HTTP 기본 인증, 양식 기반 인증 및 HTTPS 클라이언트 증명 인증)를 정의합니다. 클라이언트 인증서 로그인을 사용할 때, 웹 자원이 중요한 기밀 데이터 제한조건을 갖는 경우 브라우저 클라이언트에 대해 더 편리합니다. 브라우저가 웹 자원에 액세스하기 위해 HTTP를 사용하는 경우, 웹 컨테이너는 HTTP 포트로 브라우저를 자동 경로 재지정합니다. CSIv2 보안 프로토콜도 클라이언트 증명 인증을 지원합니다. SSL 클라이언트 인증을 사용하여 신뢰 관계에 기반을 둔 선택된 서버 세트 간의 보안 통신을 설정할 수도 있습니다.
CSIv2 보안 프로토콜도 클라이언트 증명 인증을 지원합니다. SSL 클라이언트 인증은
신뢰 관계에 기반을 둔 선택된 서버 세트 간의 보안 통신을 설정하는 데 사용될 수 있습니다.

이 태스크를 완료하기 위해 IKEYMAN 및 인증 관리 유틸리티를 사용하여 세 개의 인증서를 생성할 수 있습니다. 또한 인증서 W를 사용하여 인증서 A 및 B를 신뢰할 수 있습니다. 인증서 A를 사용하고 인증서 W를 신뢰하도록 WebSphere Application Server A의 HTTPS 서버를 구성하십시오.
이 태스크를 완료하기 위해 인증서 W, A 및 B라는 RACF(Resource Access Control Facility)를 사용하여 세 개의 인증서를 생성할 수 있습니다. 인증서 W를 사용하고 인증서 A 및 B를 신뢰하도록 WebSphere Application Server 플러그인을 구성하십시오. 인증서 A를 사용하고 인증서 W를 신뢰하도록 WebSphere Application Server A의 HTTPS 서버를 구성하십시오.
서버 | 키 | 신뢰 |
---|---|---|
WebSphere Application Server 플러그인 | W | A, B |
WebSphere Application Server A | W | |
WebSphere Application Server B | B | W |
WebSphere Application Server 배치 관리자는 관리의 중심점입니다. 시스템 관리 명령은 배치 관리자에서 각 애플리케이션 서버로 전송됩니다. 관리 보안이 사용 가능하면, SSL 및 상호 인증을 요구하도록 WebSphere Application Server를 구성할 수 있습니다.
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 서버와 통신해야 합니다. 배치 관리자와 노드 에이전트가 동일한 인증서를 사용하는 것이 좋습니다. 애플리케이션 서버 A 및 C는 동일한 컴퓨터 노드에 있다고 가정하십시오. 해당 노드에서 노드 에이전트는 인증서 A 및 C를 신뢰 저장소에 가지고 있어야 합니다.
WebSphere Application Server는
레지스트리 구성 또는 관리 유틸리티를 제공하지 않습니다. 그리고 레지스트리 비밀번호 정책을
지시하지 않습니다. 비밀번호 길이 및 만기 기간을 포함하여 레지스트리에서 권장하는
비밀번호 정책을 사용하는 것이 좋습니다.