Java 2 보안

Java™ 2 보안은 특정 보호 시스템 자원에 액세스를 허용하기 전에 권한을 검사하여 전체적인 시스템 무결성을 높여 주는 정책 기반의 자세한 수준의 액세스 제어 메커니즘을 제공합니다. Java 2 보안은 파일 I/O, 소켓, 특성과 같은 시스템 자원에 대한 액세스를 보호합니다. Java 2 Platform, Enterprise Edition(J2EE) 보안은 서블릿, JSP(JavaServer Pages), Enterprise JavaBeans(EJB) 메소드와 같은 웹 자원에 대한 액세스를 보호합니다.

Java 2 보안이 상대적으로 새로운 기능이기 때문에 기존의 많은 또는 더 신규 애플리케이션은 Java 2 보안이 적용하려는 자세한 수준의 액세스 제어 프로그래밍 모델에 대한 준비가 되어있지 않을 수도 있습니다. 관리자는 애플리케이션이 Java 2 보안에 대한 준비가 되어 있지 않을 경우 Java 2 보안 사용을 위한 가능한 결과를 이해해야 합니다. Java 2 보안은 일부 새 요구사항을 애플리케이션 개발자 및 관리자에게 제공합니다.

[IBM i]중요사항: Java 2 보안은 Java 2 보안이 사용되는 Java 가상 머신에서 실행되는 Java 프로그램으로만 제한됩니다. Java 2 보안이 사용되지 않거나 시스템 자원이 다른 프로그램이나 명령에서도 액세스되는 경우 시스템 자원을 보호하지 않습니다. 따라서 시스템 자원을 보호하려면 운영 체제 보안을 사용해야 합니다.
문제점 방지 문제점 방지: 애플리케이션 서버는 사용자 정의 Java 보안 관리자 구현을 지원하지 않습니다. gotcha

배치자 및 관리자를 위한 Java 2 보안

Java 2 보안이 지원되지만 기본적으로 사용되지는 않습니다. Java 2 보안 및 관리 보안을 서로 독립적으로 구성할 수 있습니다. 관리 보안을 사용하지 않아도 Java 2 보안이 자동으로 사용되지 않는 것은 아닙니다. 명시적으로 사용되지 않도록 해야 합니다.

애플리케이션 또는 써드파티 라이브러리가 준비되지 않은 경우, Java 2 보안을 사용하면 문제가 발생합니다. 이 문제는 시스템 로그 또는 추적 파일에서 Java 2 보안 AccessControlExceptions으로 식별 가능합니다. Java 2 보안에 대한 사용자 애플리케이션 준비 여부가 확실하지 않은 경우, Java 2 보안을 처음에서 사용되지 않도록 하여 애플리케이션이 설치되고 제대로 작동하는지 확인하십시오.

이 정책 파일로 구현된 정책은 제품이 필요한 Java 2 보안 doPrivileged API를 가지고 있지 않을 수도 있어서 더 제한적일 수 없습니다. 제한적 정책은 기본 정책입니다. 추가 권한을 부여할 수는 있지만 AccessControlExceptions 예외가 WebSphere® Application Server 내에서 생성되기 때문에 기본값을 더 제한적으로 만들 수는 없습니다. 제품은 이전에 언급한 정책 파일에 정의된 기본값보다 더 제한적인 정책을 지원하지 않습니다.

몇 개의 정책 파일이 Java 프로세스에 대한 보안 정책 정의에 사용됩니다. 이 정책 파일은 정적(코드 베이스가 정책 파일에 정의)이고 IBM® Developer Kit, Java Technology Edition에서 제공하는 기본 정책 형식입니다. 엔터프라이즈 애플리케이션 자원 및 유틸리티 라이브러리의 경우, WebSphere Application Server는 동적 정책 지원을 제공합니다. 코드 베이스는 런타임 중에 배치 정보를 기반으로 동적으로 계산되며 권한은 템플리트 정책 파일을 기반으로 부여됩니다. 자세한 정보는 Java 2 보안 정책 파일 의 내용을 참조하십시오.

정책 파일의 구문 오류는 애플리케이션 서버 프로세스가 실패하도록 하기 때문에 이 정책 파일을 주의해서 편집하십시오.

[IBM i]참고: IBM Developer Kit, Java Technology Edition에서 제공되는 정책 도구를 사용하여 정책 파일을 편집하십시오. 자세한 정보는 PolicyTool을 사용하여 Java 2 보안을 위해 정책 파일 편집의 내용을 참조하십시오.

애플리케이션이 Java 2 보안에 대해 준비되지 않은 경우, 애플리케이션 제공자가 was.policy 파일을 애플리케이션 파트로 제공하지 않는 경우 또는 애플리케이션 제공자가 예상 권한과 통신하지 않는 경우, 애플리케이션은 런타임에서 Java 2 보안 액세스 제어 예외가 발생할 수 있습니다. 애플리케이션이 Java 2 보안에 대해 준비되지 않은 것은 명확하지 않을 수도 있습니다. 몇 개의 런타임 디버깅 지원은 액세스 제어 예외가 있는 애플리케이션의 문제점 해결에 도움이 될 수 있습니다. 자세한 내용은 Java 2 보안 디버깅 지원을 사용하십시오. 이런 애플리케이션 처리를 위한 정보 및 전략은 Java 2 보안이 준비되지 않은 애플리케이션 처리의 내용을 참조하십시오.

Java 보안이 관리 보안 설정에서 사용되면 설치된 보안 관리자는 현재 시스템 이외의 스레드에 대해 modifyThread 및 modifyThreadGroup 권한을 검사하지 않고 있다는 점을 명심하십시오. 웹 및 Enterprise JavaBeans(EJB) 애플리케이션 코드가 스레드를 작성하거나 수정하도록 허용하면 컨테이너의 다른 컴포넌트에 좋지 않은 영향을 줄 수 있으면 엔터프라이즈 Bean 라이프사이클 및 트랜잭션 관리 기능에도 영향을 줄 수 있습니다.

애플리케이션 개발자를 위한 Java 2 보안

애플리케이션 개발자는 기본 WebSphere 정책에서 부여되는 권한 및 추가 권한이 필요한지 여부를 알기 위해 해당 애플리케이션이 호출하는 SDK API의 권한 요구사항에 대해 알아야 합니다. 자원 절에서 Java 2 SDK 참조는 각 API에서 필요한 권한에 대해 설명합니다.

애플리케이션 제공자는 애플리케이션에 이전에 언급한 기본 정책에 대한 권한이 부여되었다고 간주할 수 있습니다. 기본 WebSphere 정책으로 처리되지 않는 자원에 액세스하는 애플리케이션의 경우에는 애플리케이션에 대해 추가 Java 2 보안 권한이 부여되어야 합니다.

다른 동적 WebSphere 정책 파일 중 하나 또는 일반 java.policy 정적 정책 파일 중 하나에서 애플리케이션에 추가 권한을 부여할 수 있으며 EAR 파일에 임베드되는 was.policy 파일은 추가 권한이 필요한 정확한 애플리케이션으로 범위 지정되도록 합니다. 필요한 애플리케이션 코드 이상의 권한 범위 지정은 일반적으로 특정 자원에 액세스할 권한이 없는 코드를 허용하게 됩니다.

애플리케이션 컴포넌트가 개발 중인 경우, 둘 이상의 .ear 파일에 실제 포함될 수도 있는 라이브러리 같은 경우, 라이브러리 개발자는 애플리케이션 어셈블러에 필요한 Java 2 권한을 문서화해야 합니다. 라이브러리 유형의 컴포넌트에 대한 was.policy 파일은 없습니다. 개발자는 API(Application Programming Interface) 문서 또는 일부 다른 문서를 통해 필요한 권한과 통신해야 합니다.

컴포넌트 라이브러리가 다중 엔터프라이즈 애플리케이션과 공유되는 경우, 권한은 app.policy 파일의 노드에서 모든 엔터프라이즈 애플리케이션에 부여 가능합니다.
참고: app.policy 파일에 대한 업데이트는 app.policy 파일이 속한 노드의 엔터프라이즈 애플리케이션에만 적용됩니다.

권한이 컴포넌트 라이브러리에서 내부적으로만 사용되고 애플리케이션은 권한으로 보호된 자원에 대한 액세스가 부여되지 않은 경우, 코드를 privileged로 표시해야 할 수도 있습니다. 자세한 정보는 AccessControlException, 주제를 참조하십시오. 그렇지만 doPrivileged 호출을 잘못 삽입하면 보안 구멍이 생길 수도 있습니다. doPrivileged 호출 내포에 대해 이해하고 정확한 판단을 내리십시오.

Java 2 보안 정책 파일의 동적 정책 파일 절에서 was.policy 파일의 권한이 런타임에서 부여되는 방법에 대해 설명합니다.

Java 2 보안에 사용하려는 애플리케이션 개발은 새로운 기술일 수 있으며 이전의 애플리케이션 개발자에게는 필요하지 않았던 보안 인식을 보여줄 수 있습니다. Java 2 보안 모델 및 애플리케이션 개발 내포에 대한 설명은 이 절 범위를 넘어섭니다. 다음 URL을 통해 시작할 수 있습니다. http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html.

디버깅 지원

WebSphere Application Server SYSOUT 파일 및 com.ibm.websphere.java2secman.norethrow 특성은 디버깅을 위한 두 개의 기본 지원입니다.

WebSphere 시스템 로그 및 추적 파일

시스템 로그 및 추적 파일에 로깅되는 AccessControl 예외는 예외, 예외 호출 스택, 각 스택 프레임에 부여된 권한을 초래할 수 있습니다. 이 정보는 일반적으로 누락된 권한 및 권한이 필요한 코드 판별에 충분합니다.

com.ibm.websphere.java2secman.norethrow 특성

Java 2 보안이 WebSphere Application Server에서 사용되면 보안 관리자 컴포넌트는 권한 위반 발생 시 java.security.AccessControl 예외를 작성합니다. 이 예외는 처리되지 않는 경우 런타임 실패를 초래합니다. 이 예외는 SYSOUT 파일에도 로깅됩니다.

그렇지만 JVM(Java virtual machine) com.ibm.websphere.java2secman.norethrow 특성이 설정되고 값이 true인 경우 보안 관리자는 AccessControl 예외를 작성하지 않습니다. 이 정보는 로깅됩니다.

이 특성은 샌드박스 또는 디버그 환경을 위한 것으로 보안 관리자에게 AccessControl 예외를 작성하지 않도록 지시하기 때문입니다. Java 2 보안이 강제 적용되지 않습니다. 느슨한 Java 2 보안 환경으로 Java 2 보안이 작성하려는 무결성을 취약하게 하는 프로덕션 환경에서는 이 특성을 사용하지 마십시오.

이 특성은 샌드박스 또는 애플리케이션이 완벽하게 테스트되고 로그 또는 추적 파일이 AccessControl 예외에 대해 검사 가능한 테스트 환경에서 가치가 있습니다. 이 특성은 AccessControl 예외를 작성하지 않기 때문에 호출 스택을 전파하지 않고 장애를 발생시키지 않습니다. 이 특성을 사용하지 않으면 한 번에 한 개씩 AccessControl 예외를 찾아서 수정해야 합니다.

Java 2 보안이 준비되지 않은 애플리케이션 처리

Java 2 보안이 제공하는 시스템 무결성 증가가 중요한 경우, 애플리케이션 제공자에게 Java 2 보안을 지원하도록 요청하고 최소한 부여되어야 하는 기본 WebSphere Application Server 정책 이상으로 필요한 추가 권한에 대해 통신하십시오.

이런 애플리케이션을 처리하는 가장 편한 방법은 Java 2 보안을 WebSphere Application Server에서 사용되지 않도록 하는 것입니다. 이 솔루션은 전체 시스템에 적용되고 시스템의 무결성이 생각보다 강력하지 않다는 점이 취약점입니다. Java 2 보안을 사용하지 않는 것은 조직 보안 정책 또는 위험성 허용에 따라 허용되지 않을 수도 있습니다.

다른 접근 방식은 Java 2 보안이 사용되도록 둔 채 충분한 추가 권한을 부여하거나 문제가 되는 애플리케이션에게 전체 권한을 부여하는 것입니다. 그렇지만 권한 부여는 사소한 문제가 아닐 수 있습니다. 애플리케이션 제공자가 어떤 식으로든 필수 권한에 대해 통신하지 않은 경우 필수 권한을 파악하는 것이 쉽지 않고 모든 권한을 부여하는 것이 유일한 선택일 수 있습니다. 이 애플리케이션을 다른 노드에서 찾아서 이를 특정 자원과는 격리시켜 위험을 줄일 수도 있습니다. java.security.AllPermission 권한을 애플리케이션 .ear 파일에 임베드된 was.policy 파일에서 부여하십시오. 예를 들어,
grant codeBase "file:${application}" {
            permission java.security.AllPermission;
        };

server.policy 파일

[AIX Solaris HP-UX Linux Windows][z/OS]server.policy 파일은 app_server_root/properties/ 디렉토리에 있습니다.

[IBM i]server.policy 파일은 profile_root/properties 디렉토리에 있습니다.

이 정책은 WebSphere Application Server 클래스의 정책을 정의합니다. 현재 동일한 설치의 모든 서버 프로세스가 동일한 server.policy 파일을 공유합니다. 그렇지만 각 서버 프로세스가 별도의 server.policy 파일을 사용하도록 이 파일을 구성할 수도 있습니다. java.security.policy Java 시스템 특성의 값으로 정책 파일을 정의하십시오. Java 시스템 특성 정의 방법에 대한 세부사항은 애플리케이션 서버 파일 관리 절의 프로세스 정의를 참조하십시오.

server.policy 파일은 저장소 및 파일 복제 서비스로 관리되는 구성 파일이 아닙니다. 이 파일에 대한 변경사항은 로컬이며 다른 머신으로 복제되지 않습니다. server.policy 파일을 사용하여 서버 자원에 대한 Java 2 보안 정책을 정의하십시오. app.policy 파일(노드당) 또는 was.policy 파일(엔터프라이즈 애플리케이션당)을 사용하여 엔터프라이즈 애플리케이션 자원에 대한 Java 2 보안 정책을 정의하십시오.
참고: app.policy에 대한 업데이트는 app.policy 파일이 속한 노드의 엔터프라이즈 애플리케이션에만 적용됩니다.

java.policy 파일

파일은 모든 클래스에 부여되는 기본 권한을 나타냅니다. 이 파일 정책은 WebSphere Application Server의 Java Virtual Machine에서 실행되는 모든 프로세스에 적용됩니다.

[AIX Solaris HP-UX Linux Windows][z/OS]java.policy 파일은 app_server_root/java/lib/security 디렉토리에 있습니다.

[IBM i]java.policy 파일은 ${java.home}/lib/security/ 디렉토리에 있으며 여기서 ${java.home}은 사용 중인 SDK(Software Development Kit)의 경로입니다. 정책 파일은 운영 체제 전체에서 사용됩니다. java.policy 파일을 편집해서는 안됩니다.

문제점 해결

오류 메시지 CWSCJ0314E

증상:

오류 메시지 CWSCJ0314E: Java 2 보안 권한의 잠재적 위반으로 보고된 Current® Java 2 보안 정책. 자세한 정보는 문제점 판별 안내서 정보를 참조하십시오. {0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5} Java 2 보안 권한의 잠재적 위반으로 보고된 현재 Java 2 보안 정책. 자세한 정보는 문제점 판별 안내서 정보를 참조하십시오. {0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5}

문제점:

Java 보안 관리자 checkPermission 메소드가 디버깅 정보의 주제(Subject) 권한에서 보안 예외를 보고했습니다. 보고된 정보는 시스템 구성에 관련하여 다를 수도 있습니다. 이 보고서는 RAS(Reliability Availability Service Ability) 추적을 디버깅 모드로 구성하거나 Java 특성을 설정하여 사용합니다.

디버그 모드에서 RAS 추적 구성 방법에 대한 정보는 추적 사용의 내용을 참조하십시오.

관리 콘솔의 JVM 설정 패널에서 다음 특성을 지정하십시오. java.security.debug. 올바른 값은 다음과 같습니다.
access
필수 권한: 코드, 스택 및 코드 베이스 위치 등의 모든 디버그 정보 인쇄
stack
필수 권한: 코드 및 스택 등의 디버그 정보 인쇄
failure
필수 권한 및 코드 등의 디버그 정보 인쇄

권장되는 응답:

보고된 예외는 안전 시스템에 치명적일 수 있습니다. 보안 추적을 켜서 보안 정책을 위반했을 수도 있는 잠재적 코드를 판별하십시오. 위반한 코드를 판별한 후 모든 적용 가능한 Java 2 보안 정책 파일과 애플리케이션 코드를 검사하여, 시도된 조작이 Java 2 보안에 대해 허용되는지 확인해야 합니다.

애플리케이션이 Java Mail로 실행 중인 경우, 이 메시지의 상태가 양호할 수 있습니다. 애플리케이션에 다음 권한을 부여하여 was.policy 파일을 업데이트할 수 있습니다.

permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

SecurityException - Access denied

증상:

Java 보안이 사용되고 jaxm.properties 파일 읽기 권한이 부여되지 않은 경우, SOAPFactory 인스턴스가 javax.xml.soap.SOAPFactory.newInstance()에 대한 호출로 작성되거나 또는 MessageFactory 인스턴스가 MessageFactory.newInstance()에 대한 호출로 작성되면 SecurityException 예외가 발생하고 다음 예외는 시스템 로그에 기록됩니다.
Permission: 

      /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties : access denied 
(java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties
read)

Code: 

     com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder  
in  {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/
ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib
/addressbinder1.jar}

Stack Trace: 

java.security.AccessControlException: access denied (java.io.FilePermission 
/opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read)
.

문제점:

Java 2 보안 정책은 Java 2 보안 권한에 대한 잠재적 위반을 보고합니다.

권장되는 응답:

SOAPFactory는 예외를 무시하고 로드할 구현을 판별하는 다음 단계로 계속합니다. 따라서 이 보안 예외에 대한 로그 항목을 무시할 수 있습니다.

이 제품은 WS-Addressing(WS-A), WS-Atomic Transaction(WS-AT), WS-Notification과 같은 다른 웹 서비스 기술 지원에 SOAPFactory를 사용하기 때문에 Java 보안이 사용되는 경우 모든 웹 서비스 애플리케이션에서 이 SecurityException을 무시할 수 있습니다.

메시지

메시지: CWSCJ0313E: Java 2 보안 관리자 디버그 메시지 플래그가 초기화되지 않음\: TrDebug: {0}, Access: {1}, Stack: {2}, Failure: {3}

문제점: 보안 관리자에 대한 유효한 디버그 메시지에 대해 구성된 값.

메시지: CWSCJ0307E: 코드 베이스 위치 판별 중에 예기치 않은 예외가 발견되었습니다. 예외: {0}

문제점: 코드 베이스 위치 판별 중에 예기치 않은 예외가 발견되었습니다.


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



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