관리 역할 및 네이밍 서비스 권한

WebSphere® Application Server는 Java™ EE(Java Platform, Enterprise Edition) 보안 역할 기반 액세스 제어를 확장하여 제품 관리 및 네이밍 서브시스템을 보호합니다.

관리 역할

관리 콘솔 또는 시스템 관리 스크립트 인터페이스(wsadmin)로부터 특정 WebSphere Application Server 관리 기능을 수행하는 데 필요한 권한의 정도를 제공하기 위해 많은 관리 역할이 정의되었습니다. 권한 정책은 관리 보안이 사용 가능할 때만 강제 실행됩니다. 다음 표는 관리 역할에 대해 설명합니다.

표 1. 관리 콘솔 및 wsadmin을 통해 사용 가능한 관리 역할.

다음 표에는 관리 콘솔 및 wsadmin을 통해 사용 가능한 관리 역할이 나열되어 있습니다.

기능 설명
모니터 모니터 역할을 사용하는 개인 또는 그룹은 최소 특권을 가집니다. 모니터는 다음 태스크를 완료할 수 있습니다.
  • WebSphere Application Server 구성 보기
  • Application Server의 현재 상태 보기
구성자 구성자 역할을 사용하는 개인 또는 그룹에는 모니터 특권과 WebSphere Application Server 구성을 변경할 수 있는 능력이 있습니다. 구성자는 일상적인 모든 구성 태스크를 수행할 수 있습니다. 예를 들어, 구성자는 다음 태스크를 완료할 수 있습니다.
  • 자원 작성
  • 애플리케이션 서버 맵핑.
  • 애플리케이션 설치 및 설치 제거.
  • 애플리케이션을 배치하십시오.
  • 애플리케이션에 대해 사용자 및 그룹에서 역할로의 맵핑 지정
  • 애플리케이션에 대해 Java 2 보안 권한 설정
  • CSIv2(Common Secure Interoperability Version 2), SAS(Secure Authentication Service) 및 SSL(Secure Sockets Layer) 구성 사용자 정의.
    중요사항: /SAS는 버전 6.0.x 및 버전 6.1 셀에서 연합한 이전 버전 서버 간에만 지원됩니다.
조작자 운영자 역할을 사용하는 개인 또는 그룹은 모니터 특권과 런타임 상태를 변경할 수 있는 능력을 가집니다. 예를 들어, 운영자는 다음 태스크를 완료할 수 있습니다.
  • 서버 중지 및 시작
  • 관리 콘솔에서 서버 상태 모니터.
관리자 관리자 역할을 사용하는 개인 또는 그룹은 운영자 및 구성자 특권과 관리자 역할에만 부여된 추가 특권을 가집니다. 예를 들어, 관리자는 다음 태스크를 완료할 수 있습니다.
  • 서버 사용자 ID 및 비밀번호 수정
  • 인증 및 권한 메커니즘 구성.
  • 관리 보안 사용 여부 설정.
    참고: WebSphere Application Server의 이전 릴리스에서는 관리 보안 사용 가능 옵션이 글로벌 보안 사용 가능 옵션으로 알려져 있습니다.
  • Java 2 보안을 사용하여 로컬 자원에 대한 애플리케이션 액세스 제한 옵션을 사용하여 Java 2 보안 강화
  • LTPA(Lightweight Third Party Authentication) 비밀번호 변경 및 키 생성.
  • 연합 저장소 구성에서 사용자 작성, 업데이트 또는 삭제.
  • 연합 저장소 구성에서 그룹 작성, 업데이트 또는 삭제.
참고:

관리자는 관리자 역할에 사용자 및 그룹을 맵핑할 수 없습니다.

WebSphere Application Server 관리 역할을 지정하지 않은 사용자에게 연합 저장소 관리 권한을 지정하는 방법에 관한 정보는 보안 제공 주제의 연합 저장소 관리 권한 지정을 위해 사용자 및 그룹을 역할에 맵핑 주제를 참조하십시오.

Adminsecuritymanager 이 역할이 부여된 사용자만 사용자를 관리 역할에 맵핑할 수 있습니다. 또한 세분화된 관리 보안이 사용되는 경우 이 역할이 부여된 사용자만 권한 그룹을 관리할 수 있습니다. 자세한 정보는 관리 역할의 내용을 참조하십시오.
Deployer 이 역할이 부여된 사용자는 애플리케이션에서 구성 조치 및 런타임 조작을 모두 수행할 수 있습니다.
감사자 이 역할이 부여된 사용자가 보안 감사 서브시스템의 구성 설정값을 보고 수정할 수 있습니다. 예를 들어 감사자 역할이 있는 사용자는 다음 태스크를 완료할 수 있습니다.
  • 보안 감사 서브시스템 사용 가능 및 사용 불가능
  • 이벤트 팩토리 플러그인 위치에 사용할 이벤트 팩토리 구현을 선택합니다.
  • 서비스 제공자 플러그인 위치에서 사용할 서비스 제공자 또는 이미터, 또는 둘 다를 선택하여 구성하십시오. 또는 둘 모두를 서비스 제공자 플러그인 지점과 함께 사용합니다.
  • 오류 이벤트에서 애플리케이션 서버의 작동을 표시하는 감사 정책을 보안 감사 서브시스템에 설정하십시오.
  • 보안 이벤트가 감사할 항목을 정의하십시오.
감사자 역할은 모니터 역할을 포함합니다. 이를 통해 감사자는 나머지 보안 구성을 볼 수는 있으나 변경할 수는 없습니다.
표 2. 관리 콘솔을 통해 사용 가능한 추가 관리 역할.

다음 표에는 관리 콘솔을 통해 사용 가능한 추가 관리 역할이 나열되어 있습니다.

기능 설명
iscadmins 이 역할은 wsadmin 사용자가 아닌 관리 콘솔 사용자만 사용 가능합니다. 이 역할이 부여된 사용자는 연합 저장소에서 사용자 및 그룹을 관리할 수 있는 관리자 권한을 가집니다. 예를 들어 iscadmins 역할 사용자는 다음 태스크를 완료할 수 있습니다.
  • 연합 저장소 구성에서 사용자 작성, 업데이트 또는 삭제.
  • 연합 저장소 구성에서 그룹 작성, 업데이트 또는 삭제.
표 3. wsadmin을 통해 사용 가능한 추가 관리 역할.

다음 표에는 관리 콘솔을 통해 사용 가능한 추가 관리 역할이 나열되어 있습니다.

기능 설명
Deployer 이 역할은 관리 콘솔 사용자가 아닌 wsadmin 사용자만 사용 가능합니다. 이 역할이 부여된 사용자는 애플리케이션에서 구성 조치와 런타임 조작을 모두 수행할 수 있습니다.

관리 보안이 사용 가능할 경우, 관리 서브시스템 역할 기반 액세스 제어가 강제 실행됩니다. 관리 서브시스템에는 보안 서버, 관리 콘솔, wsadmin 스크립트 도구 및 모든 JMX(Java Management Extensions) MBean이 포함됩니다. 관리 보안이 사용 가능한 경우, 관리 콘솔 및 관리 스크립트 도구는 사용자에게 필요한 인증 데이터를 제공하도록 요구합니다. 또한 관리 콘솔은 페이지에 표시되는 제어 기능이 사용자가 보유한 보안 역할에 따라 조정되도록 설계됩니다. 예를 들어, 모니터 역할만 가진 사용자는 대소문자 구분 없는 구성 데이터만 볼 수 있습니다. 조작자 역할을 수행하는 사용자는 시스템 상태를 변경할 수 있습니다.

레지스트리를 변경할 경우(예를 들어, 연합 저장소에서 LDAP로) 콘솔 사용자 및 콘솔 그룹에 대해 이전에 구성된 레지스트리와 관련된 정보를 제거해야 합니다.

[z/OS]WebSphere Application Server for z/OS® 보안 사용자 정의 대화 상자는 관리 서브시스템이 시작된 모든 WebSphere Application Server 시스템 태스크(예: 제어기, 하위(servant) 등)의 MVS™ ID를 WebSphere 관리자로서 승인하고 구성된 관리자 ID를 승인하도록 준비합니다. 연합 저장소, 독립형 LDAP(Lightweight Directory Access Protocol) 레지스트리 또는 독립형 사용자 정의 레지스트리가 지정된 경우, 구성된 서버 ID는 시작된 태스크 ID에 의해 실행된 작업 대신 시스템에 의해 실행된 작업에 사용됩니다.

[z/OS] com.ibm.security.SAF.authorization 설정값은 SAF EJBROLE 프로파일 또는 콘솔 설정을 콘솔 사용자가 아닌 관리 프로파일에 대한 액세스를 제어하는 데 사용할지 여부를 제어합니다. com.ibm.security.SAF.authorization 특성이 true로 설정되는 경우, SAF 권한이 선택되며 SAF EJBROLE 프로파일이 관리 역할에 대한 액세스를 제어하는 데 사용됩니다.
참고: SAF(System Authorization Facility) 인증을 사용하면 콘솔 사용자와 콘솔 그룹의 값은 무시됩니다.
[z/OS] SAF 권한이 아닌 WebSphere Application Server 권한을 사용하여 Java EE(Java Platform, Enterprise Edition) 역할에 대한 액세스를 제한하는 경우, WebSphere Application Server for z/OS는 관리 콘솔에 대해 관리 보안을 사용 가능하게 할 때 지정한 서버 ID를 관리 역할로 자동 맵핑합니다. 관리 보안이 사용 가능한 경우, WebSphere Application Servers for z/OS가 활성 사용자 레지스트리 구성에 정의된 서버 ID 하에서 실행됩니다. 관리 콘솔과 기타 도구에는 표시되지 않지만 특수한 서버 주체가 관리 역할로 맵핑됩니다.
  • 일부 런타임 조작의 경우 서버 ID 하에서 실행되는 WebSphere Application Server 런타임 코드에는 권한이 필요합니다. 서버 ID 및 비밀번호를 명시적으로 입력하거나 ID를 자동 생성할 수 있습니다. 전자의 경우 서버 ID는 레지스트리에서 유효한 사용자입니다. 후자의 경우, 서버 ID를 자동으로 생성하려면 InternalServerId 기능을 사용하십시오. 각 사용자 레지스트리의 구성 패널을 사용하여 이를 선택할 수 있습니다. internalServerId의 경우 1차 관리 사용자 이름 필드에 관리자 ID 또는 adminID를 입력하십시오. 이 adminID는 레지스트리에서 유효한 사용자이고 이 ID의 비밀번호는 필요하지 않으며 구성에 저장되지도 않습니다. 다음 절의 "내부 서버 ID" 절을 참조하십시오.
  • 관리 역할에 명시적으로 사용자 또는 그룹을 지정하지 않은 경우, internalServerId 기능을 사용하여 관리 조작을 수행하고 기타 사용자 또는 그룹을 관리 역할에 지정할 때 서버 ID 또는 adminID를 사용하여 관리 콘솔 또는 wsadmin 스크립트 도구에 로그인할 수 있습니다. 이는 서버 ID(또는 adminID)가 자동으로 adminsecuritymanager 역할에 지정되었기 때문에 가능합니다. adminsecuritymanager에 연관된 사용자/그룹만이 모든 사용자 역할에 대한 사용자/그룹을 관리할 수 있습니다. 서버 ID(또는 adminID)를 사용하여 로그인하면 관리 보안 정책을 통해 다음과 같은 조작을 수행할 수 있습니다.
    • 서버 ID와 서버 비밀번호 변경
    • WebSphere Application Server 관리 보안 사용 여부 설정
    • Java 2 보안을 사용하여 로컬 자원에 대한 애플리케이션 액세스 제한 옵션을 사용하여 Java 2 보안 강화
    • LTPA 비밀번호 또는 키 생성 변경
  • 서버 ID는 자동으로 관리자 역할에 맵핑되므로 관리 목적으로 관리 보안을 사용할 때 지정되는 특수 구성이 서버 ID 사용에는 필요하지 않습니다. 사용자 및 그룹을 WebSphere Application Server 관리 콘솔의 관리 역할에(서) 추가하거나 제거할 수 있습니다. 그러나 변경사항을 적용시키려면 서버를 다시 시작해야 합니다. 가장 좋은 방법은 특정 사용자가 아닌 그룹을 관리 역할에 맵핑시키는 것입니다. 이 방법이 보다 융통성이 있고 관리도 용이합니다. 그룹을 관리 역할에 맵핑하면 사용자를 그룹에(서) 추가하거나 제거하는 조작이 WebSphere Application Server 외부에서 발생하므로, 변경사항을 적용하기 위해 서버를 다시 시작할 필요가 없습니다.

[AIX Solaris HP-UX Linux Windows][IBM i]관리 보안이 사용 가능한 경우, WebSphere Application Server는 활성 사용자 레지스트리 구성에 정의된 서버 ID 하에서 실행됩니다. 관리 콘솔과 기타 도구에는 표시되지 않지만 특수한 서버 주체가 관리 역할로 맵핑됩니다. 서버 ID 하에서 실행되는 WebSphere Application Server 런타임 코드에는 런타임 조작을 실행하기 위한 권한이 필요합니다. 다른 사용자에게 관리 역할을 지정하지 않은 경우, 사용자가 서버 ID를 사용하여 관리 콘솔 또는 wsadmin 스크립트 도구에 로그인하여 관리 조작을 수행하고 다른 사용자 또는 그룹에 관리 역할을 지정할 수 있습니다. 기본적으로 서버 ID가 관리자 역할로 지정되므로 관리 보안 정책은 다음 조작을 수행하는 관리 역할을 요구합니다.

[AIX Solaris HP-UX Linux Windows][IBM i]
  • 서버 ID와 서버 비밀번호 변경
  • WebSphere Application Server 관리 보안 사용 여부 설정
  • Java 2 보안을 사용하여 로컬 자원에 대한 애플리케이션 액세스 제한 옵션을 사용하여 Java 2 보안 강화
  • LTPA 비밀번호 또는 키 생성 변경
  • 사용자와 그룹에 관리 역할 지정
WebSphere Application Server의 버전 6.1 릴리스 및 이후 릴리스에는 다음이 필요합니다.
  • 관리 조치의 감사 기능을 향상시키기 위해 관리 사용자를 서버 사용자 ID와 구분해야 합니다. 사용자 이름은 로컬 운영 체제에 정의된 관리 권한이 있는 사용자를 지정합니다.
  • 감사 기능 향상을 위해 서버 ID를 관리 사용자 ID와 구분합니다. 서버 사용자 ID는 서버간 통신을 인증하기 위해 사용됩니다.
  • 내부 서버 ID를 사용하면 서버간 인증을 위해 사용자 ID를 자동으로 생성할 수 있습니다. 서버 ID의 자동 생성은 버전 6.1 이상 노드의 셀에만 향상된 감사 기능을 지원합니다. 버전 6.1 릴리스의 WebSphere Application Server에서는 보안 WebSphere 공통 구성 모델(WCCM) 모델이 새 태그인 internalServerId를 포함하기 때문에 내부적으로 생성된 서버 ID를 저장할 수 있습니다. 혼합 셀 환경을 제외하면 보안 구성 중 서버 사용자 ID 및 비밀번호를 지정할 필요가 없습니다. 서버 비밀번호는 버전 6.1 이전의 릴리스에 있어 노출되지 않으므로 내부적으로 생성된 서버 ID는 서버 환경에 한층 높은 레벨의 보호를 추가합니다. 그러나 이전 버전의 WebSphere Application Server를 사용할 경우에 역호환성을 유지보수하려면 서버 사용자 ID를 지정해야 합니다.

    보안을 사용 가능하게 할 경우 한 명 이상의 사용자 및 그룹에게 네이밍 역할을 지정할 수 있습니다. 자세한 정보는 네이밍 역할에 사용자 지정을 참조하십시오. 그러나 사용자를 네이밍 역할에 지정하기 전에 활성 사용자 레지스트리를 구성하십시오. 사용자 및 그룹 유효성 검증은 활성 사용자 레지스트리에 따라서 다릅니다. 자세한 정보는 사용자 레지스트리 구성의 내용을 참조하십시오.

  • 관리 역할에 특수 주제를 맵핑하는 기능. 특수 주제는 특정 사용자 클래스를 일반화한 것입니다. AllAuthenticated 또는 AllAuhenticatedInTrustedRealms(교차 범주가 관련되어 있는 경우) 특별 주제는 관리 역할 액세스 검사를 통해 최소한 요청 수행 사용자 인증이 확인되었음을 의미합니다. Everyone 특수 주제는 보안이 비활성화된 것처럼 인증 여부와 무관하게 모든 사용자가 조치를 수행할 수 있음을 의미합니다.

네이밍 서비스 권한

CosNaming 보안은 CosNaming 기능에 대한 보안 제어의 증가된 세분성을 제공합니다. CosNaming 기능은 WebSphere Application Server와 같은 CosNaming 서버에서 사용 가능합니다. 이러한 기능은 WebSphere Application Server 네임스페이스의 컨텐츠에 영향을 줍니다. 일반적으로 클라이언트 프로그램에서 CosNaming 호출이 생성되는 방법으로는 두 가지가 있습니다. 첫 번째는 JNDI(Java Naming and Directory Interface) 호출을 통한 방법입니다. 두 번째는 CosNaming 메소드를 직접 호출하는 CORBA(Common Object Request Broker Architecture)를 사용한 방법입니다.

네 개의 보안 역할이 소개됩니다.
  • CosNamingRead
  • CosNamingWrite
  • CosNamingCreate
  • CosNamingDelete
역할에는 낮은 단계에서 높은 단계까지의 권한 레벨이 있습니다.
CosNamingRead
예를 들어, 사용자가 JNDI 검색 메소드를 사용하여 WebSphere Application Server 네임스페이스를 조회할 수 있습니다. 특정 주제인 Everyone이 이 역할에 대한 기본 정책입니다.
CosNamingWrite
사용자가 JNDI 바인드, 리바인드 또는 언바인드와 같은 쓰기 조작과 CosNamingRead 조작을 수행할 수 있습니다. 기본 정책으로서, 이 역할에는 주제가 지정되지 않습니다.
CosNamingCreate
JNDI createSubcontext 및 CosNamingWrite와 같은 조작을 통해 네임스페이스에서 오브젝트를 새로 작성할 수 있습니다. 기본 정책으로서, 이 역할에는 주제가 지정되지 않습니다.
CosNamingDelete
예를 들어, JNDI destroySubcontext 메소드와 CosNamingCreate 조작을 사용하여 네임스페이스에 있는 오브젝트를 삭제할 수 있습니다. 기본 정책으로서, 이 역할에는 주제가 지정되지 않습니다.

[z/OS]WebSphere Application Server for z/OS로 로컬 운영 체제 레지스트리를 구성하는 경우 몇 가지 추가 고려사항이 있습니다. 자세한 정보는 레지스트리 또는 저장소 선택로컬 운영 체제 레지스트리 구성 내용을 참조하십시오. 연합 저장소, 독립형 LDAP 레지스트리 또는 독립형 사용자 정의 레지스트리를 지정하는 경우, 사전 구성된 WebSphere Application Server 구성 그룹과 관리자 ID를 콘솔 그룹에서 삭제하여 로컬 운영 체제 사용자 정의를 제거하고 콘솔 사용자를 삭제해야 합니다.

기본적으로 네 개의 모든 CosNaming 역할에 Server 특수 주제가 지정됩니다. Server 특수 주제는 서버 ID 하에서 실행되며 모든 CosNaming 조작에 액세스하는 WebSphere Application Server 프로세스를 제공합니다. Server 특수 주제는 관리 콘솔 또는 기타 관리 도구를 통해 표시 또는 수정할 수 없습니다.

서버 ID는 자동으로 관리자 역할에 맵핑되므로 관리 목적으로 관리 보안을 사용할 때 지정되는 특수 구성이 서버 ID 사용에는 필요하지 않습니다.

[AIX Solaris HP-UX Linux Windows][IBM i]언제든지 WebSphere Application Server 관리 콘솔에서 사용자, 그룹 또는 특수 주제 AllAuthenticated 및 Everyone을 네이밍 역할에 추가하거나 제거할 수 있습니다. 그러나 변경사항을 적용하려면 서버를 다시 시작해야 합니다.

[z/OS]서버 ID는 자동으로 관리자 역할에 맵핑되므로 관리 목적으로 관리 보안을 사용할 때 지정되는 구성이 서버 ID 사용에는 필요하지 않습니다. 언제든지 WebSphere Application Server 관리 콘솔에서 사용자, 그룹 또는 특수 주제 AllAuthenticated 및 Everyone을 네이밍 역할에 추가하거나 제거할 수 있습니다. 그러나 변경사항을 적용하려면 서버를 다시 시작해야 합니다. SAF 권한을 선택하는 경우 추가 사용자 또는 그룹에게 권한을 부여하기 위해 서버를 다시 시작하지 않아도 됩니다.

가장 좋은 방법은 특정 사용자가 아닌 그룹 또는 특수 주제 중 하나에 맵핑시키는 것입니다. 장기간 관리하기에는 이 방법이 보다 융통성이 있고 쉽습니다. 그룹을 네이밍 역할에 맵핑하면 사용자를 그룹에(서) 추가하거나 제거하는 조작이 WebSphere Application Server 외부에서 발생하므로, 변경사항을 적용하기 위해 서버를 다시 시작할 필요가 없습니다.

CosNaming 권한 정책은 관리 보안이 사용 가능할 때만 강제 실행됩니다. 관리 보안을 사용할 수 있을 때 적절한 역할을 지정하지 않고 CosNanming 조작을 수행하려고 시도하면 CosNaming 서버에서 org.omg.CORBA.NO_PERMISSION 예외가 발생합니다.

[AIX Solaris HP-UX Linux Windows][IBM i]각 CosNaming 기능은 한 역할에만 지정됩니다. 따라서 CosNamingCreate 역할에 지정된 사용자가 CosNamingRead에도 지정되지 않으면, 네임스페이스를 조회할 수 없게 됩니다. 또한 대부분의 경우에, 작성자를 세 가지 역할인 CosNamingRead, CosNamingWrite 및 CosNamingCreate에 지정해야 합니다. 위 예의 작성자에 대한 CosNamingRead 및 CosNamingWrite 역할 지정이 CosNamingCreate 역할에 포함되었습니다. 대부분의 경우, 이전 릴리스에서 이 릴리스로 이동할 때 WebSphere Application Server 관리자가 모든 사용자 또는 그룹에 대한 역할 지정을 변경할 필요는 없습니다.

기본 정책을 변경하여 네임스페이스에 대한 액세스를 엄격히 제한하는 기능이 있어도 런타임 시 예상치 못한 org.omg.CORBA.NO_PERMISSION 예외가 발생할 수 있습니다. 일반적으로 Java EE 애플리케이션이 네임스페이스에 액세스하며, 사용하는 ID는 Java EE 애플리케이션에 액세스할 때 WebSphere Application Server에 인증한 사용자 ID입니다. Java EE 애플리케이션 제공자가 예상되는 네이밍 역할과 확실하게 통신하지 않을 경우, 기본 네이밍 권한 정책을 변경할 때 주의해야 합니다.


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



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