보안 시스템 소개

JEUS 보안 시스템에서 로그인은 Subject를 실행 Thread(Java Thread)에 결합시키는 것을 의미한다. 이 개념은 인증과는 다르다. 일반적으로 Subject가 실행 Thread와 결합되기 전에 인증이 일어난다. 만약 성공적으로 인증되면 로그인은 정상적으로 진행되어 Subject와 Thread가 결합하게 되지만, 인증에 실패하면 로그인은 더 이상 진행되지 않는다.

Subject가 성공적으로 로그인한 후에 로그인된 Subject를 대상으로 권한 체크가 이루어진다. 따라서, 로그인은 인증과 권한 체크, 양쪽 모두에 걸쳐있다고 할 수 있다. 로그인의 반대 개념은 로그아웃으로 현재 Subject를 실행 Thread로부터 분리하는 과정이다.

로그인 이면에는 다음과 같은 Stack 기반 오퍼레이션이 있다. 여러 개의 서로 다른 Subject로 로그인했을 경우 최근에 로그인한 Subject부터 Stack의 최상단에 쌓인다. 그 후 권한 체크에는 Stack의 최상단에 놓인 Subject(가장 최근에 로그인한 Subject)를 사용한다. 이 Subject가 로그아웃하고 나면, Stack으로부터 제거되고 바로 직전에 로그인한 Subject가 Export되어 활성화된다.

다음은 이 메커니즘에 대한 설명이다.

JEUS 보안 시스템에서 Java Thread마다 하나의 로그인 Stack을 가질 수 있다. 이전의 보안 아키텍처와 유사하게 로그인 메커니즘은 jeus.security.impl.login.CommonLoginService에 의해 구현된다.

인증은 호출자의 신원을 파악하는 작업으로 이는 이후 권한을 체크할 때 사용된다.

JEUS 보안 시스템에서 신원은 java.security.Principal 인터페이스로 정의한 Principal을 의미한다. Subject는 이러한 Principal들을 속성값으로 저장하고 있다. Subject는 jeus.security.base.Subject 클래스를 의미하며, 로그인할 때 실행 Thread와 결합하는 주체이기도 하다. Subject는 항상 Principals과 Credentials을 보안 속성으로 포함하고 있다.

JEUS Subject는 UML로 다음과 같이 표기할 수 있다.

Subject는 유일한 ID인 메인 Principal을 가지고 있다. 또한 메인 Principal 외의 여러 개의 부가적인 Principal을 가질 수 있는데, 이러한 부가적인 Principal들은 다른 Subject와 공유할 수 있다(따라서, 부가적인 Principal을 그룹 Principal이라고도 한다).

Subject는 또한 public 또는 private credentials을 가질 수 있다. Credential은 보통 Subject의 신원을 확인하거나, 특정 정보를 전달하려는 목적으로 사용되는 증빙 자료이다. 대표적인 private credential은 패스워드가 있고, public credential은 디지털 인증서가 있다.

Subject는 소위 CredentialFactory를 사용하여 Credential들을 생성한다. Subject의 refresh()라는 메소드가 실제 CredentialFactory로부터 Credential을 얻어 와서, 이를 public 또는 private credential set에 추가한다.

JEUS 보안 시스템에서 권한 체크는 이미 성공적으로 인증된 Subject가 특정 액션을 실행시킬 권한이 있는지 여부를 확인하는 것이다.

권한 체크는 보통 시스템 레벨에서 일어난다. 특정 Subject(보통 administrators)가 JEUS 서버를 기동 또는 종료시킬 권한을 가지고 있는지 여부를 체크하는 것이다. 또한 권한 체크는 애플리케이션 레벨에서도 일어난다. 원격지 호출자가 특정 애플리케이션 컴포넌트(특정 EJB 메소드의 실행, 특정 Servlet 호출)에 접근할 수 있는지 여부를 JEUS 엔진에서 확인하는 것은 여기에 해당한다.

Jakarta EE에서와 마찬가지로 JEUS 보안 시스템에서 권한 부여는 Role-Based 메커니즘이다. 즉, Jakarta EE 애플리케이션 Assembler 또는 개발자가 Role에 따라 보안 설정(security restriction)을 하면 시스템 관리자가 애플리케이션을 deploy하면서 실제 시스템의 Principal을 논리적인 Role에 매핑한다.

더 나아가 JEUS 보안 시스템에서 개개의 권한 매핑을 Permission(실제 java.security.Permission의 서브 클래스)이라 한다. 예를 들어 Principal "user1"은 "R"이라 불리는 Role에 접근할 수 있는 RolePermission을 가지고 있다고 가정한다(이를 "user1"은 Role "R"에 포함되어 있다고 한다).

그리고 Role "R"은 Resource "jndi" 리소스에 접근해 Action "lookup"을 실행할 수 있는 Resource Permission을 가지고 있다고 가정한다.

다음은 이러한 개념에 대한 설명이다.

위 그림에서 보듯이 Principal과 Role만이 실제 물리적 실체로서 모델링된다. 그림에서 리소스를 감싸고 있는 원은 점선으로 표시되어 있는데, 리소스는 실제 권한 부여 시스템에서 물리적으로 모델링되는 부분이 아닌 암시되는 부분이기 때문이다.

“RolePermission”과 “ResourcePermission”은 실제로는 각각 jeus.security.resource.RolePermission 클래스와 jeus.security.resource.ResourcePermission 클래스의 인스턴스를 나타낸다. 이 두 클래스는 java.security.Permission 추상 클래스로부터 확장된 대표적인 클래스들로 이들 외에도 다양한 Permission 클래스의 서브 클래스들이 있다.

다시 한 번 정리하면, Principal은 여러 개의 RolePermission을 가지고 있고 각 RolePermission은 특정 Role이 Principal을 포함하는 것을 허용한다. 다시 Role도 여러 개의 ResourcePermission을 가지고 있는데, 각 ResourcePermission은 해당 Role이 특정 리소스들에 대해 특정 액션들을 취할 수 있도록 허락한다. 따라서 Principal-Role-Resource를 연결해서 생각해 보면, 어떤 Principal이 특정 리소스에 대한 특정 액션을 실행할 수 있을지 여부를 판단할 수 있다.

위의 그림에서 Principal "user1"은 실선으로 RolePermission을 소유하고 있다(owns)라고 표시되어 있다. 그러나 RolePermission은 대각선으로 Role "R"을 암시하고 있다(implies)고 표시되어 있다. "암시하다"라는 말은 둘 사이의 관계가 정적이지 않다는 뜻으로 때때로 매핑될 수도 있고, 그렇지 않을 수도 있음을 말한다. 즉, 런타임에 RolePermission이 해당 Role을 암시할지 여부는 동적으로 결정된다는 의미이다.

실제로 RolePermission의 implies(Permission p) 메소드에 의해 결정되는데 implies() 메소드가 true를 리턴하면 RolePermission이 Role "R"을 암시하고, false를 리턴하면 암시하지 않는다. 따라서 전자의 경우에는 Principal "user1"이 Role "R"에 포함되지만, 후자의 경우에는 포함되지 않는다. 같은 논리가 Role "R"과 Resource "jndi" 사이에도 성립된다.

위의 정보를 바탕으로 동적인 매핑을 구현하기란 실제 어려운 일이 아니다. 단지 implies() 메소드의 구현을 변경하면, 특정 조건하에서만 Permission이 Role 또는 Resource를 암시하도록 만들 수 있다. 예를 들어 동적인 매핑을 이용해서 Principal "user1"이 업무 시간(9시부터 5시) 동안만 Role "R"에 포함되게 구현할 수 있다. 이는 새로운 RolePermission 서브 클래스(이하 TimeConstrainedRolePermisson)를 생성하고, implies() 메소드 내에서 시간 제약과 관련된 코드만 작성하면 된다.

예로 오전 1시 30분의 Role와 오전 10시 30분의 Role을 보기 바란다.

오전 10시 30분의 Role에서 보듯이 오전 1시 30분에는 Principal "user1"은 Role "R"의 권한이 없다.

TimeConstrainedRolePermission은 두 가지 값인 Name과 Actions를 가지고 있다. Name은 Target Role의 이름인 "R"이고, Actions는 유효한 시간(9시부터 5시까지)을 나타내고 있다. Name과 Actions는 대부분의 java.security.Permission 구현 클래스의 변수들로 선언된다.

기본적인 Permission-Based 매핑과는 별도로 권한 부여 시스템에서 모든 Permission은 다음 3가지 카테고리 중에 하나에 속한다.

이에 대한 몇 가지 예제들은 다음에 더 살펴본다.

JEUS 보안 시스템에서 모든 Permission 매핑들은 jeus.security.base.PermissionMap 클래스를 구현한 클래스이다. PermissionMap 클래스는 다시 jeus.security.base.Policy 클래스에 포함된다.

Policy는 2가지 종류의 PermissionMap을 가지고 있다.

이들은 각각 Principal-to-Role 매핑과 Role-to-Resource 매핑을 나타낸다. 각 PermissionMap은 다시 위에서 언급한 3가지 종류(Excluded, Unchecked, Ckecked)의 Permission들을 포함하고 있다. Checked Permission의 경우 Permission과 RolePermissionMap은 Principal이나 Role을 매개로 결합되어 있고, Policy와 ResourcePermissionMap은 Context ID(권한 체크가 일어나는 범위를 나타낸다)를 통해 결합되어 있다.

다음은 Policy와 PermissionMap의 UML 다이어그램을 나타낸다.

이상에서 언급한 내용이 다음 그림에 요약되어 있다.

해당 Policy는 하나의 Principal-to-Role Map(필수 사항)과 각각의 Context ID가 "A"와 "B"인 2개의 Role-to-Resource Map을 포함하고 있다. 3가지 PermissionMap은 다음과 같은 Permission set을 가지고 있다.

박스 내의 타원은 Name과 Action을 가진 실제 Permission 인스턴스(Name: Action)를 나타내고 있다.

Context ID가 "A"이고, Principal이 "user1"인 Subject가 "JNDI"에 접근해서 "modify"라는 액션을 실행하고 싶다고 가정했을 때 과연 "user1"은 원하는 액션을 실행할 수 있을까?

권한 부여 시스템은 이 요구사항을 다음과 같은 방식으로 풀어나간다.

"user1"이 "Administrator" Role에 매핑되어 있지만, "Administrator" RolePermission이 Excluded Permission이므로 "user1"을 포함한 누구도 "Administrator" Role에 접근할 수 없게 된다. 이는 Excluded Permission이 Unchecked Permission과 Checked Permission보다 우선순위가 높기 때문이다.

위에서 설명한 대로 차근 차근 과정을 따라가 보면 다음 권한 체크 질의가 어떻게 풀릴지 알 수 있을 것이다.

보안 감사는 일반적으로 보안과 관련된 이벤트(인증 실패, 런타임 예외 발생)를 포착하여 적절히 처리함으로써 전반적인 보안 품질을 향상시키는 것이다.

JEUS 보안 시스템은 보안 이벤트를 기반으로 하는 단순하지만 유연한 보안 감사 메커니즘을 특징으로 한다. 주요한 이벤트가 발생할 때마다(인증 실패, 권한 부여 실패, 관심도가 높은 기타 이벤트) 이벤트는 미리 등록된 이벤트 핸들러에 포착된다. 커스텀 핸들러 구현 클래스는 이에 적절하게 대응한다.

예를 들어 한 번에 연속적으로 너무 많이 인증에 실패할 경우 해당 Subject의 Credential에 Lock을 걸도록 할 수 있다.

보안 시스템에서 실제 보안 기능을 구현하고 있는 클래스를 서비스라고 한다. 즉, 서비스는 특정 보안 기능(인증, 권한 부여, 네트워킹, 기타)을 제공하는 SPI를 구현한 클래스이다.

SPI는 jeus.security.spi 패키지에 포함되어 있는 추상 클래스이다. 커스텀 보안 기능을 구현하기 위해 SPI 클래스를 다양하게 확장하고 구현할 수 있다. SPI를 확장한 서브 클래스가 바로 서비스이다.

보안 시스템에서 서비스 인스턴스는 각각이 특정 보안 기능을 제공하는 독립적인 실체로 간주된다. 그러나 종종 서비스는 다른 SPI를 호출하기도 하기 때문에 서비스 간의 어느 정도 의존성은 존재한다. 서비스를 초기화하기 위해 모든 서비스는 "key-value"로 이루어진 한 쌍의 속성값을 전달받는다. 이러한 데이터는 설정 파일을 사용해서 저장해둘 수도 있다.

모든 서비스는 선택사항으로 JEUS 관리 시스템에 보고할 JMX Bean을 정의하기도 한다. JMX MBean은 보통 Service.getMBeanInfo() 메소드로부터 리턴받은 MBeanInfo를 기반으로 생성된다.

또한 모든 서비스는 생성(created)과 소멸(destroyed) 상태를 가지고 있다 . 이 두 상태 간의 전이는 create()와 destroy()가 불려질 때 발생한다. 이 메소드를 호출하면 실제 추상 메소드인 doCreate()와 doDestroy() 메소드가 호출된다. 이 추상 메소드들은 서비스 서브 클래스에서 구현되는데, 서비스를 초기화하고 서비스를 정리하는 작업을 포함한다.

다음은 jeus.security.spi 패키지에 포함되어 있는 다양한 SPI 클래스와 서비스 클래스들을 클래스 다이어그램을 사용해 보여주고 있다.

런타임에 서비스 인스턴스는 SecurityInstaller 싱글톤 클래스에 의해 생성된다. 단순하게 SecurityInstaller를 구현한다면 서비스를 프로그램에서 직접 생성하는 코드만 작성하면 되겠지만, 더 유연하고 정교하게 서비스를 생성하는 방법이 있다. 서비스 클래스명과 속성값을 특정 설정 파일에 저장해 놓고 파일로부터 설정 정보를 읽어들여 서비스 인스턴스를 만들고 초기화하는 방법이다. 디폴트 SecurityInstaller 구현 클래스는 후자의 접근법을 도입하였으므로 쉽고 유연한 방법으로 서비스를 보안 시스템에 추가할 수 있다.

보안 도메인(Security Domain)은 보안 서비스 인스턴스의 집합이라 할 수 있다. 하나의 보안 시스템에 여러 개의 도메인이 동시에 있을 수 있다. 도메인 개념의 배경에는 서로 다른 애플리케이션이나 JEUS 서브 시스템이 각각 별도의 보안 서비스를 사용하도록 하는 데 있다. 도메인은 보안 서비스를 각 애플리케이션별로 분리하는 역할을 한다.

예를 들어서 JEUS 시스템만 사용하는 특별한 도메인을 설정할 수 있다. JEUS가 사용하는 도메인을 SYSTEM_DOMAIN이라고 한다. 이 도메인은 JEUS를 관리하는 데 사용하는 Subject와 Policy를 포함하고 있다. SYSTEM_DOMAIN에 서버를 부트 또는 다운할 수 있는 "administrator"라는 메인 Subject에 대한 사용자 정보를 설정할 수 있을 것이다.

또 다른 성격의 도메인으로 deploy된 특정 Jakarta EE 애플리케이션에서만 사용하는 도메인을 설정할 수 있다. 이를 APP_DOMAIN이라 한다. APP_DOMAIN도 "administrator"라는 사용자 정보를 설정할 수 있지만, JEUS의 "administrator"와는 Permission이 다르다. 또한 도메인별로 Repository 메커니즘을 다르게 설정할 수 있다. 가령 SYSTEM_DOMAIN이 사용자 정보를 XML 파일에 저장하는데 반해, APP_DOMAIN은 원격지에 있는 데이터베이스를 사용해서 Subject에 대한 사용자 정의를 읽고 쓰도록 설정할 수 있다.

다음은 도메인 개념을 보여주고 있다.

도메인을 별도로 설정할지 여부는 선택사항이다. 만약 도메인을 별도로 설정하지 않는다면 SYSTEM_DOMAIN이 사용된다.

다음과 같이 JEUS는 기본적으로 SYSTEM_DOMAIN과 SHARED_DOMAIN 2개의 도메인을 사용한다.

애플리케이션에 JEUS 시스템에서와 다른 보안 서비스를 사용하려면 별도의 도메인을 생성하고 domain.xml에 해당 내용을 적어 주어야 한다. 보안 도메인의 생성 및 설정은 보안 시스템 설정을 참고한다.

본 절에서는 보안 시스템을 사용하면서 JEUS 서버 전체에 미치는 성능의 영향력을 최소화시키는 방법을 설명한다.

보안 시스템의 전반적인 성능을 향상시키는 방법은 다음과 같다.

본 절에서는 성능을 희생하더라도 보안 시스템에서 전반적인 보안 수준을 향상시키는 방법에 대해 설명한다.

JEUS의 전반적인 보안 수준을 향상하기 위한 방법은 다음과 같다.