Access-Control Language for Multidomain Environments

2004년 논문. 

Access-Control Language for Multidomain Environments.pdf

XML Role-Based Access Control (X-RBAC)

그림1은 NIST RBAC 모델의 간단 버전이다.

사용자, 롤, 퍼미션, 세션

시스템 관리자는 롤에 사용자와 퍼미션을 할당에 제약과 세션에 롤의 사용자 활성화를 적용할 수 있다. 우리는 파라미터화된 롤들, 컨텍스트와 내용-기반 제약, XML 기반 정책 컴포넌트을 가지고 NIST 모델을 확장한다.

Roles with Attributes

확장된 RBAC 모델에서 롤들은 그들이 사용될 수 있을 때를 지정하는 연관된 시간적 제약을 가지는 개념이 있다. 애플리케이션 의미에 따라, 모든 롤들이 모든 사용자에게 항상 이용될 수 있는 것이 아니다. 우리의 모델은 다양한 상태를 롤들과 연관시키는 개념이 있다.

그림 2는 세가지 잠재적 롤 상태를 보여준다.

• Disabled: 롤이 세션 안에서 활성화 될 수 없다는 것을 의미한다.
• Enabled: 요청 시간에 롤에 대해 승인된 사용자가 롤을 활성화 할 수 있다는 의미한다.
• Active: 적어도 한명의 사용자가 롤을 활성화 하고 있다는 것을 의미한다.

만약에 시스템은 role-disabling 이벤트를 발생하면 enabled 또는 active 상태가 disabled 상태로 변함. 예를 들어, 롤이 특정 시간동안 enabled로 머물어 있은 후에, 시스템은 이것을 비활성하기 위한 disabling event를 발생시키고 활성하는것을 막는다.

이 모델은 어떻게 롤이 상태를 변화시키는지 정의하는 전제조건들을 포착하도록 허락한다. 각 전제조건은 롤 파라미터 집합의 요소들에 정의된 논리적 조건들로 구성된다. 예를 들어, 롤 enabling 전제조건은 현재 시간이 롤을 위해 정의된 특정 시간인지를 검사하는 것이 수반된다. 비슷하게 롤 activation 전제조건은 사용자의 네트워크 도메인이 미리 명시한 도메인 이름과 매치되는지 검사하는 것을 수반한다. 또한 사용자와 퍼미션을 롤에 할당하는것을 제어하기 위한 전제조건의 명시를 허락한다. 예를 들어, 사용자 할당 전제조건은 사용자의 credential 값인 미리 지정한 기준을 만족한다면 주어진 롤에 할당하도록 명시한다.

롤-할당 파라미터들은 다음의 속성들 값을 포함한다.

• 시스템 관리자는 롤을 사용하기위한 권한을 포함하여 사용자에게 할당한다.  (미리 명시된 조직-지정 값들)
• 사용자는 인증서를 가지고 있어야만한다. (모르는 사용자를 나타내는 일반적인 값들)

전제조건의 세 가지 유형을 위한 속성 집합은 공통된 요소를 가지고 있을수 있다: 같은 파라미터들이 롤-enabling, 할당, 활성화에 영향을 줄 수 있다. 

롤 전제조건

Xen: 롤 enabling

Xas: 롤 할당

Xac: 롤 활성화
병원에서 DoctorinTraining 롤에 대해, 

{time instance (t), time duration(d), system load(l), user(u) role (x), certification (c)}

• Xen = {t, l}
  1. 아침 9시에 저녁 9시까지 근무일
  2. 시스템 로드는 낮음. 현재 활동중인 의사와 간호사의 수로 추정한다.
• Xas = {c,t}
  1. 의사 스미스의 인증서 c는 유효하다. ValidCertificate(c)
  2. 매주 월, 화, 수 아침 9시에 저녁 9시까지
• Xac = {t, u, r, d}
  1. 의사 존은 슈퍼바이저이다. active(u, r)로 검사한다. u = "의사 존"과 r = SupervisorDoctor"이면 만족!
  2. 액티브 기간은 2시간 이하.

Capturing Context and Content Information

Context - 뻔한것.

Content: XML 문서 소스를 위해 4가지 레벨 - conceptual, XML 스키마, XML instance, XML 엘리먼트.

이제서야 멀티 도메인 얘기가 나오네;

웹서비스와 그리드기반 시스템에서 멀티도메인 환경이 나타남.

도메인들간 접근에서 위반이 일어나지 않게 하는것이 결국 보안의 목표다.

안전한 상호 작용 (secure interoperation)은 두가지 원칙을 강화해야만 한다.

• 자치권: 개별 시스템안에서 허용되는 접근은 안전한 상호작용하에 허락되어야만 한다.
• 보안: 개별 시스템안에서 허용되지 않는 접근은 안전한 상호작용하에 허락되지 말아야한다.

멀티 도메인 환경은 느슨한 결합과 통합된 컴포넌트를 포함 할수 있다.

Loosely Coupled Multidomain Environments

독립적인 시스템들은 일정 기간동안 정보를 공유한다. 예를 들어, 컨설팅 회사에게 계약 기간동안 정보를 부분적으로 공유하도록 허락한다. 두 가지 접근 중개 접근법이 있다.

첫째, 상호도메인 접근들을 중개하기 위하여 미리 정의된 롤 매핑들을 사용한다. 

둘째, 미리정의된 롤들과 알려지지 않은 원칙들을 매핑하기 위하여 인증서를 사용한다. - 인터넷 환경에 적절 - 신뢰 관리 인프라에 의존한다. 신뢰 협상 페이즈를 수반할 수 있다.

Federated Multidomain Environments

지정된 마스터가 있다. 마스터가 글로벌 정책을 통해 개별 시스템의 접근들을 중재한다. 정책 통합!

a) 도메인들간 상속을 나타냄, 롤 A에 승인된 사용자는 롤 Y, Z에서도 승인됨.

b) c와 d 링크를 추가하는 것은 보안 원칙에 위배 된다. (상속 cycle 발생)

c) 글로벌 롤과 로컬 롤들간의 롤 매핑

기부 시스템들은 로컬 정책들을 제출하여 참가하는 통합된 그리드 시스템을 고려할 수 있다.

글로벌 정책은 개별 도메인들의 다양한 롤들을 맵할 수 있다. 

그림 4c - 글로벌 롤 R1 mapping  도메인 3의 C, 도메인 4의 r1, r3, 도메인 5의 X

Table 1은 헬스케어 애플리케이션 환경에 특유한 매핑이다.~

R은 통합의사 롤

병원 1 롤 C : 매주 월요일,수요일 DayDoctor

병원 2 롤 r1, r2:  

               r1: 매주 화요일, 목요일 DayDoctor

               r2: 매주 금요일 EmergencyDoctor

병원 3 롤 X : 매주 주말 SupervisorDoctor

의사를 다양한 시간과 병원에 지정할 수 있다.

 loosely와 federated 멀티 도메인 환경에서 RBAC 정책들을 표현하고 중재한다.

<!-- Policy Definition --> ::=

<XPolicy [policy_id = “(value)”]>

<PolicyName> (name)</PolicyName>

<!-- XML User Sheet -->

<!-- XML Role Sheet-->

<!-- XML Permission Sheet-->

<!-- XML User-Role Assignment-->

<!-- XML Role-Permission Assignment-->

[<!-- Local Policy Definitions-->]

[<!-- Policy Relationship Definitions-->]

</XPolicy>

<!-- Local Policy Definitions-->를 통해 다른 정책 정의들을 컴포넌트로써 포함하여 통합된 정책을 명시할 수 있다.

이를 통해 연결되고 복잡한 멀티도메인 정책들의 동적 생성을 지원한다. 구성하는 정책은 통합시스템에서 로컬 정책이거나 느슨한 결합 환경에서 도메인 정책일 수 있다.

<!— Policy Relationship Definitions—>를 통해 글로벌과 로컬 정책들간의 관계 집합을 정의 해야만 한다.

자세한 내용이 나와있는 링크를 눌렀지만 깨짐

XML user sheets는 사용자와 credential 유형을 정의한다.

<XUS>

<User u_id = “u1”>

<UserName> JSmith </UserName>

<CredType c_type_id = “C100”>

<CredExpr>

<FName>John</FName>

<LName>Smith</LName>

<age>30</age>

<level>5</level>

</CredExpr>

</CredType>

<MaxRoles> 2 </MaxRoles>

</User>

</XUS>

생략

Mediation Policies

<!-Local Policy Definitions —>를 사용하여 정책 정의안에 로컬 정책을 포함할 수 있다.

로컬 정책들은 <XLPD> </XLPD> 태그 사이에 정의

<!— Policy Definition —>

mediation policies - 한 정책의 롤들이 로컬 정책들에서 롤들과 어떻게 관련되고 있는지를 나타내는 것.

<!—Policy Relationship—>

scoping rule

만약에 정책 P가 더 높은 레벨 정책의 로컬 정책이 되면 P의 로컬 정책 정의와 관계는 더 높은 레벨 정책에게 알려지지 않는다. 이러한 범위 룰은 로컬 정책들의 구성 도메인들의 엔티티라기 보다는 글로벌 정책 정의안에서 지역적으로 지배된 정책 엔티티들만 보여질 수 있다는 의미이다. 이러한 추상화는 메타정책 구조를 간단화 한다. 그러나, 더 높은 레벨의 정책 관리는 전체적인 통합 일관성을 감독해야만 한다면, 이러한 룰을 완화할 필요가 있다.

<!-- Policy Relationship --> ::=

<XPR xpr_id = (id) [pt_expr_id = (id)]>

<InterDomainMapping [idMap_id = (id)] >

<RoleMapping>

[<Mapping Definition>]+

</RoleMapping>

</ InterDomainMapping >

</XPR>

<Mapping Definition>::=

<MappedRole>

<Role[role_id = (id)] [policy_id = (id)]>

(name)</Role>

[<Mapped(To|From) Definition>]+

</MappedRole>

<Mapped(To|From) Definition>::=

<Mapped(To|From)>

<Role [role_id=(id)] [policy_id = (id)]>

(name)</Role>

<MappingCondition [pt_expr_id = (id)>

[<!--LogicalExpression-->]

</MappingCondition>

</Mapped(To|From)>

그림 4-c에서 정의된 도메인들간 롤매핑

<XPR xpr_id =” XPRg”>

<InterDomainMapping [idMap_id = “IDMg”]>

<RoleMapping>

<MappedRole>

<Role policy_id = “Global”>

FederatedDoctor</Role>

</MappedRole>

<MappedTo>

<Role policy_id = “Policy3”>

DayDoctor</Role>

<MappingCondition pt_expr_id = “PT1” />

</MappedTo>

<MappedTo>

<Role policy_id=“Policy4”>

EmergencyDoctor</Role>

<MappingCondition pt_expr_id = “PT1 />

</MappedTo>

<MappedTo>

<Role policy_id = “Policy5”>

SupervisorDoctor</Role>

<MappingCondition pt_expr_id = “PT1” />

</MappedTo>

</RoleMapping>

</ InterDomainMapping >

</XPR>

느슨한 결합 시스템을 대한 중재 정책들을 담아내기 위하여 같은 구조를 사용한다. 이 경우, 각 로컬 정책 정의는 파트너 도메인의 도메인 정책의 부분으로 구성된다. 예를 들어, 그림 4-a의 정책 1, 2를 가지고 도메인 1, 2를 고려해보자.

정책 1 명세에서 정책 2의 몇몇 엔티티들은 알려진다. (특히, 롤 Y와 Z) 그리고 <!— Local Policy Definitions —>에 나타난다.

비슷하게 정책 1의 몇몇 엔티티 정의는 (롤 C, D)는 로컬 정책 정의로써 정책 2에서 나타날 것이다.

롤간의 매핑에 방향성을 표현하기 위하여 <MappedFrom>...</MappedFrom>, <MappedTo>...</MappedTo>를 포함하고 있음

도메인 1의 정책 관계 명세

<XPolicy policy_id = “Policy 1”>

<!--Policy Definition-->

<XPR pxr_id = “XPR1”>

< InterDomainMapping idMap_id = “IDM1”>

<RoleMapping>

<MappedRole>

<Role policy_id = “Policy1”> C

</Role>

</MappedRole>

<MappedTo>

<Role policy_id = “Policy2”> Y

</Role>

</MappedTo>

</RoleMapping>

<RoleMapping >

<MappedRole>

<Role policy_id = “Policy1”>D

</Role>

</MappedRole>

<MappedFrom>

<Role policy_id = “Policy2”> Z

</Role>

</MappedFrom>

</RoleMapping>

</ InterDomainMapping >

</XPR>

</XPolicy>

Policy-Integration Challenges

의미적 이질 및 정책 일관성과 같은 몇 가지 이슈들이 멀티 도메인 환경에서 많은 첼리지들이 있다. XML 통합 멀티도메인 환경에서 의미적 이질성과 다중의 이질적 정책들의 통합을 관리하기 위하여 온톨로지와 이질적 데이터베이스 스키마의 의미적 통합을 위한 접근법들이 유용할 수 있다. 우리의 정책 통합 방법론은 네 가지 단계를 가진다.

• Pre-integration: 의미적 차이점을 해결하는데 도움을 주는 각 도메인 정책 엔티티에 관한 의미적 정보의 표현 및 조직화를 처리힌다.
• Policy comparison: 의미적 충돌 검출(도메인 롤들간의 네이밍 충돌 또는 롤 계층들 간의 구조적 충돌을 포함), 사전 통합 단계에서 얻어진 정보를 검출할 때 이용한다. 의미적 충돌을 검출하기 위한 기술이 필요하다. (자동으로 또는 반자동으로)
• Policy conformance: 의미적, 규칙 충돌을 해결한다. 그림 4b에서 처럼 보안 위반이 발생되면 중재 정책들을 합성하기 위한 기술이 필요하다.
• Merging and restructuring: 일관성을 제거한 후에 일관성있는 통합된 정책을 얻기 위하여 필요한 로컬 정책 재적응을 처리한다.

이 과정은 반복적이다. 특히 모순을 제거하는 것은 많은 재구조와 중재 정책들의 정제를 수반한다. 우리는 3, 4번 단계에서 주로 이 반복을 수행한다.