2. XACML POLICY LANGUAGE
접근제어 정책들을 명시하기 위하여 XACML에 의해 채택된 공식은 네가지 주요 컴포넌트를 기반으로 하고 있다.
1) Attributes and functions (속성과 함수)
속성들은 주체들, 리소스들, 액션들 또는 제한을 정의하기 위해 사용되는 환경들의 특성이다. XACML은 속성 목록을 미리 정의하지 않는다. 대신 데이터 유형과 주체 또는 단체들이 시스템에 대해 유효한 속성들의 집합을 생성하기 위하여 사용할 수 있는 함수 목록을 명시한다. String, Time, Boolean, Double, AnyURI는 유효한 데이터 유형의 예들이다. 반면에 , String-Equal, Greater-Than, Date-Equal, String-Is-In, AnyURI-One-and-Only는 유효한 함수들의 예이다.
2) Rule (규칙)
규칙은 정책의 기본 요소이다. 이는 룰이 생성되는 정책에대해 고립해서 존재할 수 있는 완전하고 원자적인 권한부여 제약을 식별한다. 규칙은 규칙을 적용하는 요청 집합들을 식별하는 대상과 permit 또는 "deny"하는 영향과 언제 규칙이 요청에 적용되는지를 명시하는 추가적인 predicates를 표현하는 조건들의 집합으로 구성되어 있다.
3) Policies.
정책은 하나 이상의 규칙이다. 정책은 대상 (규칙 대상으로써 같은 컴포넌트를 사용하여 명시하는)과 룰의 집합과 룰의 통합 알고리즘을 포함한다. 통합 알고리즘은 정책이 영향이 충돌하는 규칙들을 포함할 때 어떤 정책의 결정 결과를 계산하기 위하여 채갵한 접근법을 명시하도록 허락한다. XACML의 일부로써 명시된 규칙 통합 알고리즘은 그림 1에 나타나있다.
그림1
Deny Overrides (거부 우선): 만약에 규칙이 "Deny"되는 영향(effect)을 만난다면 정책은 거부된다.
Permit-overrides: 만약에 규칙이 "Permit"되는 영향을 만난다면 정책은 허락된다.
First-one-applicable: 통합된 결과은 처음 규칙의 결과와 동일하다.
Only-one-applicable: 통합된 결과는 요청에 적용하는 유일한 규칙의 결과에 상응한다.
4) Policy set (정책 집합)
다중 룰들이 정책을 구성하기 떄문에, 다중 정책들은 정책 집합을 구성한다. 이는 권한 부여결정이 다중 단체에 의해 명시된 요구사항을 고려해야만 하는 경우 적용하기 위하여 조건들을 표현한다. 정책집합은 대상과 정책들의 집합, 정책 통합 알고리즘을 정의한다. XACML에서 제안된 정책 통합 알고리즘은 정책안에 규칙들을 통합하기 위하여 사용된 것과 같다. 그림 1
XACML 정책은 또한 의무(obligation)을 포함할 수 있다. 권한부여 결정의 강화와 함꼐 PEP에 의해 수행애야만 하는 정책 또는 정책 집합에 명시된 오퍼레이션을 나타낸다. (예를 들어, 데이터는 오후 5에서 아침 8에 접근될 수 있다, 요구자의 이름이 데이터 소유자에 이메일로 보내졌다면~). 그러나, 의무들은 이 논문 범주 밖이다. 그래서 나머지에서는 이를 고려하지 않는다.
XACML은 정책 명세서를 위한 언어들 제공할 뿐만 아니라 요청와 연관된 정책 속성 값들에 근거한 정책을 평가하기 위한 메소드를 제공한다. 접근제어 정책들을 평가하고 강화하기 위한 과정은 세가지 주요 요소로 구성된다.
PDP
PEP
context handler - 네이티브 요청을 XACML 형태로 변환해 준다. XACML로 부터 권한부여 결과를 네이티브 포멧으로 변환해 준다.
간단하게, 접근 요청은 다음과 같이 평가된다.
요청자는 PEP에 요청을 보낸다.
PEP는 순서대로 context handler와 접촉하여 네이티브 포멧을 XACML 요청 컨텍스트로 변환한다.
그러한 컨텍스트는 PDP에 보내진다.
만약 컨텍스트 요청에 대한 정보가 규칙 대상과 규칙 조건 술어 모두 만족한다면 규칙은 요청에 적용한다.
술어가 증명되지 않는다면 규칙은 "not applicable" 이고 영향은 무시된다.
똑같이, 요청에 적용할 규칙이 없다면 정책은 "not applicable"이다.
규칙 통합 알고리즘은 서로다른 영향을 가지고 적용된 규칙들사이에 충돌을 해결하기 위하여 사용된다.
정책 평가 결과는 컨텍스트 핸들러에게 되돌아온다.
네이티브 포멧으로 변환하고 PEP에게 전달한다.
PEP는 정책 평가 결과를 평가하고 최종 결정을 내린다.
3. MOTIVATING EXAMPLES: TWO CASES FOR REQUIRING POLICY INTEGRATION
3.1 Example 1: Collaborative Storage System
Lockss는 협업하는 피어들에게 저장 네트워크를 구성하도록 허락하는 P2P 저장 시스템이다. 이는 다른 참가하는 노드들에 그들의 데이터를 복제하여 그들의 컨텐트를 안전하게 보존하기 위하여 참가하는 피어들에 의해 사용된다. 그러한 복제는 컨텐트 소유자에게 임시적인 실패(예,네트워크 사용량이 너무 많은경우)뿐만 아니라 영구적인 실패(복구 불가능한 디스크 실패)에서 살아 남도록 허가하여 가용성을 향상시킨다.
Lockss는 안전하게 디지털 컨텐트를 보존하기 위하여 US에서 많은 공공 도서관에 의해 사용된다. 참가하는 도서관의 credential은 오프라인에서 증명된다. 일단 피어가 시스템에 참가하면, 접근 제어 정책은 중앙 관리자에 의해 글로벌하게 정의된다.
자 이제 Lockss와 같은 협업시스템이 어떻게 도서관-정의 접근 제어 정책들을 지원할지 설명한다. 예를들어, 도서관 A는 다중 도서관들에게 컨텐트를 복제하여 이를 보존하기 원한다고 생각하자. 이 시나리오에서, 두 도서관인 LibB와 LibC는 저장 시스템에 참가하는 피어들의 복제를 원하고 다음과 같은 정책을 가지고 있다.
도서관 B 정책: 사용자들은 피크타임동안(아침 10시에서 오후 2시) 어떤 리소스에 대한 가져오기/저장 액션을 수행하기 위하여 승인받지 않는다.(수행할 권한이 없다.) 그러나, ".gov" 또는 ".edu" 네임스페이스가 있는 email을 가진 사용자는 항상 접근할 수 있다.
도서관 C 정책: ".edu" 네임스페이스가 있는 email을 가진 어떤 사용자도 어떤 리소스에 대한 어떤 액션을 수행할 수 있다. HP와 제휴되어 있는 사용자도 동일한 규칙을 적용한다. 그러나, 오전 8시에 오후 8시사이에 들어온 요청들은 접근이 거부된다.
도서관 A가 B와 C에 의해 소유된 저장소안에 데이터를 호스트하기 원한다고 추정하자.
A의 접근제어 정책은 다음과 같다.
도서관 A 정책: ".edu" 또는 ".gov" 네임스페이스가 있는 이메일을 가진 어떤 사용자도 어떤 정보도 읽을 수 있다. 그러나, 아침 8시에서 아침 12까지는 어떤 접근도 허락되지 않는다.
도서관 B와 도서관 A는 규칙 통합 알고리즘으로써 "deny override"를 채택한다. 반면에 도서관 C는 "permit override"
이 시나리오에서 , 도서관 A는 도서관 B또는 C에 데이터를 저장할 수 있다. 그러나 XACML에 의해 정의된 것들 사이에서 어떤 정책통합 알고리즘이 정책들을 통합하는데 사용되어야만 하는지와 어떤 파트가 이를 결정할 권리를 가졌는지가 명확하지 않다.
"Permit override"는 데이터 소유자(도서관 A)가 정보를 호스팅하는 리소스 소유자(도서관 B, C)에 의해 승인되지 않은 요청에 대한 접근을 허가하기때문에 사용될 수 없다. 동시에, "Permit override"는 주체가 정보를 호스팅하는 리소스에 접근하도록 승인받기 때문에 데이터 소유자 정책을 우회하여 요청이 데이터에대한 접근이 주어지도록 되는 상황을 생성할 것이다.
반면에, "deny override"는 도서관 B(또는 C)가 도서관 A의 모든 정책을 평가하는 부가적인 임무를 추정하기 꺼려할 것이기 때문에 사용될 수 없다. 동시에, 도서관 A는 승인된 사용자의 일부가 이 데이터에 접근하는 것을 거부되는 것을 받아들일 수 없다.
결국, 두 정책을 통합하기 위하여 "deny override" 사용하는 것은 요청받은 리소스에 대한 접근을 승인받을 사용자가 없다는 시나리오를 이끌 것이다. 예를 들어, 데이터 소유자의 정책이 ".edu"네임스페이스가 있는 이메일 주소를 가진 사용자들에게만 접근이 허용된다고 가정하자. 데이터를 호스팅하는 리소스 소유자는 .com 네임스페이스가 있는 이메일 주소를 가진 주체에게만 리소스 접근을 허가한다고 하자. 이 예제에서, "deny override" 통합 알고리즘은 정보를 접근하기 바라는 모든 주체들에게 접근을 거부하게 만든다.
4. Policy similarity process
정책 통합 알고리즘을 소개하기 전에, 그들이 인증하는 요청들에대해 통합되도록 정책들의 행동을 분석할 필요가 있다. 다시말해, 우리는 하나의 정책에 의해 승인된 요청인지 다른 것에 의해 거부된 것인지 식별할 필요가 있다.
이 섹션에서, 그러한 정보를 추출하기 위한 과정을 기술한다. 우리는 이를 두 정책들의 정책 유사성으로써 나타낸다. 예를 들어, Pi와 Pj 정책사이의 정책 유사성이 "제한적" 이라고 말하는 것은 Pi에 의해 승인되지 않고 Pj에 의해 승인된 요청이 있다. 반면에 그 반대는 진실이 아니다.
정책 유사성 통합 알고리즘을 소개하는 이유는 다양한 엔티티들에 의해 설정된 정책 통합 요구를 보호하는 것하기 위하여, 우리는 우선 그들이 승인한 요구에 대하여 정책들의 행동을 비교하기 위한 메소드가 필요하다는 것이다.
XACML 정책들 사이에 정책 유사성을 계산하기 위한 과정은 그리 간단하지 않다. 특히, 세가지 요소가 고려될 필요가 있다.
규칙 대상과 조건(rule targets and conditions): 평가받기 위한 predicate를 표현
규칙 영향(rule effects): 규칙들의 의도된 결과를 명시한다. (허가또는 거부)
규칙 조합 알고리즘(rule combination algorithms): 각 정책에서 규칙 영향을 어떻게 통합할지 명시한다.
그러한 상황에서, "적용불가" 규칙들이 (예를 들어, 상황 요청에 의해 확인된 대상의 조건에 없는 규칙들) 권한 부여 결정에 참가하지 않는다것을 상기하는것이 중요하다. 이것은 예를 들어, 오전 8시부터 오후 8시까지 접근이 거부되는 규칙은 밤에 발생한 요청에 대한 어떤 조짐도 주지 않는다는 의미이다. "적용불가" 정책은 "허용" 도 "거부"도 아니다. 그러나, 정책을 위해 우리는 최소 권한 원칙을 예상할 수 있다. 다시말해, 요구는 정책 평가가 "거부" 또는 "적용불가" 이라면, 요구가 거절된다.
이 섹션의 나머지에서 우리는 두가지 XACML 정책들 사이의 유사성을 계산하기 위하여 개발한 과정을 기술한다.
이 과정은 다음과 같은 3 단계로 구성되어 있다.
1) 유사성은 그들의 대상과 조건들을 고려하여 단일한 규칙들 사이에서 계산된다.
2) 규칙들의 유사성들은 그룹되고 그들의 영향을 고려하여 단순화 된다.
3) 정책 유사성은 두 정책에의해 명시된 규칙 조합 알고리즘을 사용하여 추출된다.
4.1 Step 1: Computing similarity of rules : 규칙들의 유사성을 계산한다.
두개의 XACML 정책들이 주어지면, 첫번째 단계는 같은 정책 속성을 사용하여 정의된 규칙들 쌍 사이의 유사성을 계산하는 것이다. 이 목표는 각 속성을 대해 어느 정책이 가장 제한적(restrictive) 조건을 명시하는지 식별하는 것이다. 그러한 정보를 얻기 위하여, 우리 통합 방법은 두 규칙의 조건들을 분석하고 데이터 타입과 함수에 기반하여 두 표현에서 잡아 낼수 있는 값들의 집합들을 추출하고 비교한다.
그림 2에서 보여주는 것 처럼, 룰들간의 유사성의 5가지 유형을 구분한다.
- Converge. 만약에 값들의 집합이 그들의 조건들이 가지고 있는 것에 대하여 동일하다면 두 규칙은 "converge"
- Diverge. 만약에 값들의 집합이 그들의 조건들이 가지고 있는 것에 대하여 교차(intersect)하지 않는다면 두 규칙은 "diverge"
- Restrict and extend. 만약 조건들이 가지고 있는것에 대하여 값들의 집합이 다른 규칙에 대해 계산된 값들의 집합을 포함한다면(또는 포함된다면) 어떤 규칙이 다른 규칙을 "restrict" (or extedns)
- Shuffle. 만약 그들의 조건들이 가지고 있는 값들의 집합들이 교차하지만 서로 포함되지 않는다면 두 규칙은 "shuffle"
예제 1.
Lockss 예제에서, 도서관A와 도서관 C 정책들간 계산된 규칙 유사성은 다음과 같다. 도서관 A 이메일은 "extend"도서관 C의 이메일 조건, 반면에, 도서관 A의 시간에 대한 조건은 도서관 C에 의해 설정된 시간 조건에 "restrict"하다.
<AttributeValue DataType=“#String”>.gov</AttributeValue>
<AttributeValue DataType=“#String”>.edu</AttributeValue>
extend
<AttributeValue DataType=“#String”> .edu </AttributeValue>
<AttributeValue DataType=“#Time”>08:00</AttributeValue>
<AttributeValue DataType=“#Time”>12:00</AttributeValue>
restrict
<AttributeValue DataType=“#Time”>10:00</AttributeValue>
<AttributeValue DataType=“#Time”>14:00</AttributeValue>
다른 접근법은 정책 속성이 두 정책 중 하나에서만 명시된 규칙을을 가져온다. 이 경우에, 위에 전략은 비교할수 있는 두 개의 조건이 없기 때문에 적용될 수 없다. 그러한 경우 규칙 유사성은 두 정책 중에 어떤 것이 그 규칙을 포함하고 있는지 고려하여 계산된다. 이러한 컨텍스트에서, Pi와 Pj 정책들간 유사성을 계산할 때, Pi가 Pj에 없는 규칙 속성을 가지고 있다면, 규칙 유사성은 "restrict"이다. 반면에 Pj가 Pi에 없는 규칙 속성을 포함하고 있다면 규칙 유사성은 "extends" 이다.
이 논문에 나머지에서, 우리는 Pol_Att: Rule_Eff/sim_type 로 표기하여 규칙 유사성을 나타낼것이다.
Pol_Att: 두 규익에 명시된 속성
Rule_eff: 영향 (허가 또는 거부)
sim_type: 유사성의 값 {converge, diverge, restrict, extend, shuffle}
예제 2.
도서관 A와 도서관 B 정책
Email: permit/converge, Current-Time: deny/shuffle
도서관 A와 도서관 C 정책
Email: permit/extend, Current-Time: deny/restrict and Affiliation: permit/extend (restrict가 맞는게 아닐까;)
4.2 Step 2: Group rules’ similarity based on rule effects and applied transformation functions
규칙 영향(permit or deny)에 기반한 그룹 규칙의 유사성 과 적용된 변환 함수
정책 유사성을 계산하는 과정에서 다음 단계는 규칙들의 영향(effect)에 기반한 그룹 규칙들의 유사성과 고려되는 규칙 유사성들의 수를 줄이기 위하여 어떤 로직을 수행하는 변환함수를 적용하는 것이다. 이 단계의 목표는 두 개의 유사성 값을 얻는 것이다. 하나는 "deny" 영향의 규칙들을 위한것과 다른 하나는 영향으로써 "permit"을 정의하고 있는 규칙들을 위한것이다. 마지막 단계에서, 그러한 정보들은 결국 두개의 정책에 의해 명시된 규칙 통합 알고리즘에 기반하여 통합될 것이다.
이 단계로 부터, XACML 규칙은 더이상 사용되지 않는다. 규칙 유사성만 고려된다. 다음에, 우리는 일반적 용어 R을 가지고 규칙 유사성에서 정의된 정책 속성들을 대체한다. 규칙 유사성은 R: Rule_Eff/sim_type 으로 표기된다. 그러한 고려로, 규칙 유사성은 두개의 그룹으로 조직화 될수 있다. permit 규칙의 유사성, deny 규칙의 유사성. 각 그룹에 대하여 다음의 변환 함수가 적용된다.
정의 1
i ∈{converge, diverge, restrict, extend, shuffle}
m∈ {permit, deny}
예제 3.
예제 2에서 계산된 규칙 유사성에 변환 함수를 적용하여 다음과 같은 값을 생성한다.
도서관 A와 도서관 B 정책
R permit/converge, R: deny/shuffle
도서관 A와 도서관 C 정책
R: deny/restrict and R: permit/extend
4.3 Step 3: Applying rules combination algorithms (규칙 조합 알고리즘 적용하기)
우리는 두 정책에 의해 명시된 규칙 조합 알고리즘을 처리하는것을 고려한다.
4가지 가능성이 있다.
3.a 단계: 두 정책은 규칙 조합 알고리즘으로써 "permit override"를 명시한다. 이것은 가장 간단한 경우이다. 정책이 거부된것으로 추정되면 접근제어 결정이 "deny" 또는 "not applicable"이며, 정책 유사성은 허락 규칙의 유사성만을 고려하여 계산될 수 있다.
정의 2
규칙 조합 알고리즘으로써 "permit override"를 사용하여 정의된 두 정책 Pm, Pn이 있다. 더욱이,
i, j ∈{converge, diverge, restrict, extend, shuffle}
정책 유사성은 {R:Deny/i , R:Permit/j} = j 로 계산된다.
3.b 단계: 두 정책이 규칙 조합 알고리즘으로써 "deny override"로 명시된다. 이 시니라오는 좀더 복잡하다. 사실, 어떤 정책이 "permit"된다는 것은 "deny" 규칙이 없을 뿐만 아니라 컨텍스트 요청이 "permit"되는 최소 하나의 규칙 영향을 만족해야만 한다. 이러한 컨텍스트에서, 정책 유사성은 다음과 같이 계산된다.
정의 3
규칙 조합 알고리즘으로써 "deny override"를 사용하여 정의된 두 정책 Pm, Pn이 있다.
i, j ∈{converge, diverge,restrict, extend, shuffle}
정책 유사성은 다음과 같이 계산된다.
아... 이해가 안된다~~~~~~~~~~아 짜증....
3.c 단계: 하나의 정책은 "허용우선"으로 명시하고 반면에 다른하나의 정책은 "거부우선"로 명시한다.
이러한 시나리오에서, "허용" 규칙들을 위해 계산된 유사성은 두 규칙 조합 알고리즘에 대해 두 정책들에 의해 승인된 요구들의 집합들을 표현한다. 그러나 "거부우선" 경우에 승인된 요청 집합들은 적어도 하나의 "거부" 규칙을 만족하는 요청들로 부터 잘라내야하는 반면에, "허용우선"인 경우 잘라내기는 필요하지 않다. 그래서, 정책 유사성은 다음과 같이 계산된다.
정의 4.
만약 Pm이 "허용우선"이고 Pn이 "거부우선"라면 정책 유사성은 다음과 같이 계산된다.
Pm의 규칙 속성의 허용 effect가 Pn를 포함하면 허용우선쪽에 허용 effect가 더 속해 있으므로 정책들간 Pm extends Pn 유사성?
반면에, Pm이 "거부우선"이고 Pn이 "허용우선"라면 정책 유사성은 다음과 같이 계산된다.
예제 4:
우리 예제에서, 도서관 A와 도서관 C (둘다 deny override 사용)에 의해 명시된 정책들을 위해 계산된 정책 유사성은 "extend"이다. 왜냐하면 "deny"규칙들을 위해 계산된 유사성은 "restrict"이고 "permit" 규칙에 대해 계산된 유사성은 "extend"이기 때문이다. 이는 도서관 C에 의해 승인된 모든 요청은 도서관 A에 의해 승인될 것이다. 반면에 그 반대는 그렇지 않다.
R: deny/restrict and R: permit/extend
반면에, 도서관 A와 도서관 B에 의해 명시된 정책들사이의 유사성은 "restrict"이다. 왜냐하면 "허용"룰에 대한 유사성은 "converge"인 반면에 "거부"규칙에 대한 유사성은 "shuffle"이기 때문이다. 그래서, 도서관 A에 의해 승인된 모든 요청은 도서관 B에 의해 또한 승인된다. 추가적으로, 도서관 B에 의해 승인되고 도서관 A에 의해 거부되는 요청도 있다.
R permit/converge, R: deny/shuffle
5. POLICY INTEGRATION ALGORITHMS
이전 섹션에서 다룬것 처럼 정책 통합 과정을 완성하기 위하여, 정책 유사성은 관여된 모든 주체들의 정책 통합 요구사항을 가지고 조합되어야만 한다.
섹션 1에서 간단히 소개된 것처럼, 다른 것에서 명시된 것을 가지고 통합될 때, 서비스 시각화 모델에서 그들의 리소스들을 공유하는 주체와 그러한 리소스들을 사용하는 주체들 모두가 정책들의 행동을 명시하기 위하여 그들의 서비스를 제공할 것같다.
그래서, 다중의 독립적이고 자율적인 엔티티들을 포함하는 서비스인 경우, 모든 PoE(points of enforcement)들이 단일한 중앙집중적인 엔티티에 의해 관리에 의한 XACML 접근법은 좀 더 융통성있는 해결책으로 교체되어야만 한다. 어떤 접근법은 각 RO(리소스 소유자, 정책들이 궁극적으로 강화되는 곳)는 자신의 정책들과 자신이 소유하고 있는 PoE를 사용하여 리소스들을 사용하는 서드파티들사이에서 정책 통합을 수행하는것을 가정하는 것이다.
이와 관련해서, PoE 소유자는 PoE 소유자 정책 통합 요구사항을 명시할 수 있는데, 이는 PoE가 다른 엔티티들에 의해 명시된 정책들을 평가하도록 요청받은 경우에 사용되는 접근법을 의미한다.
PoE 소유자 정책통합 요구사항은 다음과 같다.
PoE 소유자는 다음과 같이 명시한다.
Converge override: 이는 가장 제한적인(restrictive) 경우이다. 자신의 PoE가 PoE 소유자에 의해 정의된 것과 다른 정책들을 평가하기 위해 사용되지 말아야한다. (자기것만 평가한다.)
Restrict override: 만일 PoE 소유자에 의해 명시된 정책들에 의해 거부된 요청을 승인하지만 않는다면 PoE는 서드파티 정책들을 평가 할 수 있다. (거부된 것을 승인하는 경우만 뺴고는 평가할 수 있다.)
Deny override: XACML과 같이, PoE는 서드 파티 엔티티에의해 명시된 정책들을 평가할 수 있다. 컨텍스트 요청은 두 정책이 "허용"인 경우에만 승인받는다. "restrict override"와의 차이점은 PoE 소유자는 어떤 정책도 평가하는 반면에 "restrict override"는 충돌없는 정책들만 평가를 고려한다.
Permit override: PoE는 서드파티에의해 명시된 어떤 정책도 평가할 수 있다. 상황 요청은 두 정책중 최소한 하나라도 "허용"이라면 승인받을 것이다.
PoE 소유자 처럼, (서드파티에 의해 소유되는 PoE에 의해 평가될 정책) PoE 게스트라고 불리우는 주체 또한 정책 통합 요구사항을 명시할 수 있다. Lockss 시나리오의 예처럼, DO는 DO 정책에 의해 승인된 어떠한 요청도 데이터접근이 거부되지 말아야한다고 명시하는 것에 관심이 있다 .
PoE 게스트 정책 통합 요구사항은 다음과 같은 값들중에 하나를 가진다.
Restrict override: PoE 게스트의 가장 중요한 보안 목표는 정보에 대한 승인받지 않은 접근을 막는것이다. 반면에 PoE 게스트는 PoE가 자신에게 승인된 사용자의 접근이 거부되는 것을 받아들인다. (Owner allow < Guest deny)
Extend override: 이전 경우와 다르게, 서비스 거부로부터 보호는 PoE 게스트의 주요 보안 목표이다. 다시말해, PoE는 승인되지 않은 요청을 받아들이지만, PoE 게스트에 의해 승인된 어떤 요청도 거부하지 말아야한다.
Converge override: PoE 게스트는 자신의 정책들이 PoE에 의해 완전히 강화되길 요구한다. 다시말해, PoE는 PoE 게스트에 의해 승인된 모든 요청을 승인해야만 한다.
두 정책이 통합될 때, PoE 게스트와 PoE 소유자의 정책 통합 요구사항이 만족되어야만 한다. 그러한 목표를 성취하기 위하여 두 요구사항은 이전 섹션에서 계산된 정책 유사성을 사용하여 조합된다. PoE 소유자와 게스트가 주어지면, 그림 3은 정책 통합 요구사항을 만족시키는 정책 유사성의 집합을 보여준다.
owner - converge override - 다른 정책들은 평가 안한다. 결국 유사성은 converge
owner - restrict override - 거부한 접근을 허용하지만 않으면 평가.
restrict - 자신이 승인된 접근이 거부되어도 상관없다. owner의 거부가 더 많다면 restrict, 같다면 converge
extend - 자신이 승인한 요청은 거부되지 말아야한다.
예제 5.
도서관 A의 PoE 게스트 정책 통합 요구사항- "converge override"
도서관 B의 PoE 소유자 정책 통합 요구사항 - "deny override"
정책 유사성을 계산하면 "restrict" 가 되기 때문에 정책 통합이 가능하다. 그래서, 도서관 B에 도서관 A 데이터를 복제하는 것은 도서관 A에 의해 승인된 모든 요청은 리소스와 데이터 모두 접근할 수 있다는 것을 보장한다. 반면에, 도서관 A의 정책들을 위반하고 그룹(도서관 B)에 의해 승인된 데이터만을 접근하는 요청은 없다.
만일 도서관 A가 도서관 C가 소유한 저장소 리소스에 데이터를 복제한다면 똑같이 적용하지 않는다. 사실, 만약 도서관 C가 "deny override"라고 명시한다면, 정책들은 통합될 수 없다. 왜냐하면, 유사성은 extend이고 그래서 리소스를 접근하도록 승인받지 못한 도서관 A에 의해 승인된 요청들이 있다.
6. POLICY HINTS
정책 유사성은 그들이 승인한 요청들의 집합들에 관하여 두 정책이 어떻게 관련되어 있는지 결정한다. 예를 들어, converge는 두 정책이 요청들의 같은 집합들을 인증한다는 의미이다. 정책 유사성은 요청리 다중의 독립적이고 자율적인 엔티티들에 의해 명시된 정책 집합을 비교하여 평가되어야만하는 경우 필요하다. 협업 저장 시스템은 정책 유사성을 요구하는 시스템의 예이다. 그러한 시스템에서, 일반적으로 모든 PoE의 행동을 결정하는 관리자가 있지 않고 각 PoE 소유자는 다른 엔티티들에 의해 명시된 정책들을 강화할지 그리고 어떻게 강화할지를 결정하는데 자유롭다. 이와 관련해서, 정책 통합 알고리즘은 리소스들을 고유하는 주체와 리소스만을 공유하는 PoE와 주체에 대한 보안 요구사항을 보호하기 위하여 소개 되어왔다. 예를 들어, 정책 유사성의 조합과 정책 통합 알고리즘은 DO가 어떤 RO가 데이터를 호스트해야만해서 요청들이 접근이 허가될 것이라는 결정하는데 도움을 준다.
정책 유사성과 정책 통합 알고리즘이 XACML 통합 과정에 관심이 있는 가치있는 정보를 주더라도, 이는 충분하지 않다. 우리의 협업 저장 시스템 시나리오를 다시 고려하자. 그림 3을 보면, 만일 DO 정책이 RO 정책을 확장하고 RO PoE 소유자가 "deny override"라면 DO는 승인받지 못한 요청이 DO 데이터를 접근할 수도 있는 위험없이 RO에 데이터를 복제할 수 있다. 그러나, DO에 의해 승인된 어떤 요청들은 RO 정책을 실패했기 때문에 거절될 수 있다. 그래서, DO가 RO들 선택하여 모든 승인된 요청들이 제공될 수 있을까? 그러한 질물을 답하기 위하여, 이번 섹션에서 우리는 Policy_Hint라는 개념을 소개하는데 이는 두 XACML 정책들 사이의 차이점을 특징화 한다. Policy_Hint는 다음과 같은 세가지 정책들을 포함하는 집합이다.
Restrict_Pol, Extend_Pol, Integrate_Pol
특히, 정책 Poli와 Polj를 비교할때
Polj에 의해 승인되고 Poli에 의해 거부된 모든 요청들을 승인하는 정책을 Restrict_Pol이라고 부른다.
반면에, Poli에 의해 승인되고 Polj에 의해 거부된 모든 요청들을 승인하는 정책을 Extend_Pol이라고 부른다.
마지막으로, Poli와 Polj 모두에 의해 승인받은 모든 요청을 승인하는 정책을 Integrate_Pol이라고 부른다.
Example 6. 어떻게 Policy_Hint가 사용되는지 이해하기 위하여 추가적인 RO, 도서관 D를 고려한다. 도서관 D는 다음과 같은 정책을 가지고 있다.
도서관 D 정책: ".edu" 또는 ".gov" 네임스페이스가 있는 이메일을 가진 어떤 사람도 어떤 리소스에 대한 어떤 액션도 수행할 수 있다. 그러나, 아침 8시에서 저녁 8시 사이에 들어오는 요청들은 거절된다.
XACML 도서관 D의 명세서는 다음과 같다.
도서관 D는 규칙 조합 알고리즘으로 "거부우선"을 채택한다. 이 예제에서, 도서관 A와 도서관 D사이의 차이점으로 계산된 Restrict_Pol (도서관 D(RO)에 의해 승인되고 도서관 A(DO)에 의해 승인되지 않은)은 아침 12시에서 저녁 8시사이에 들어온 요청들을 승인한다. 그러한 정보를 아는 것으로, 도서관 A는 정책들을 도서관 D 데이터 저장소에 데이터를 안전하게 복제할수 있게 해야만 하도록 어느 것을 변화시킬지 알고 있다. 다시 말해, 도서관 D는 아침 8시에서 아침 10시사이에 들어오는 요청만 승인한다면 Policy_hint는 아침 10시에서 아침 12시 사이에 발생한 요청을 승인하는 정책을 Extend_Pol로써 포함할 것이다. 그러한 정보는 도서관 A가 정보를 다운로드하고 받아들이는 모든 요청을 가지기 위해 어떤 추가적인 RO가 선택해야하는지 결정하는데 유용하다.
Policy_hint 를 계산하는 과정은 그림 4에서 명시되고 있다. 알고리즘은 섹션 4에 기술된 것과 유사한 접근법을 가진다. 두 입력 정책과 각 룰, 속성들이 있다. 만일 그러한 rj가 존재한다면 시스템은 두 논리적 표현을 증명하는 값들의 집합을 비교하여 규칙 유사성을 추출한다. 이 과정은 규칙을 추출하는 것으로 계속되고 이 규칙의 승인된 요청은 rj에 의해 승인되고 ri에 의해 승인되지 않는다. 이를 rj-ri로써 그러한 과정을 표시한다. 규칙 유사성을 기반으로, 그러한 표현은 Ristrict_Pol, Extend_Pol 또는 Integrate_Pol중에 하나로 추가된다. 만약 Pj가 ri로써 동일한 정책 속성을 가지고 정의된 규칙을 포함하고 있지 않다면, ri는 Restict_Pol로 추가되고 정책 유사성은 extend로써 설정된다. 일단 알고리즘이 pi에 모든 규칙들을 처리하면, pj에 모든 규칙을에 대한 처리를 계속한다. (pi의 규칙안에 명시되지 않은 정책 속성들). 만일 그러한 규칙들이 존재하며, 정책 유사성은 "restrict" (전에 "extend"로 설정된 경우 "shuffle" )로 설정하고 "Restrict_Pol"을 추가된 규칙들을 설정한다.
예제 7. 도서관 A와 도서관 D의 정책들 사이에 계산된 정책 힌트는 다음과 같은 정책들을 포함하고 있을 것이다.
Restrict_Pol: 오전 12에서 오전 8시사이에 들어온 요청들은 접근이 허가되어야한다.
Integrate_Pol: ".edu", ".gov" 이메일을 가진 사용자는 접근이 허락된다. 하지만, 오전 8시에서 오전 12시까지는 접근이 거부된다.
정책 통합 알고리즘같이 정책 힌트 알고리즘은 접근 제어 결정 결과를 명시하지 않는다. 사실, 그러한 결정은 특정 접근 제어 시스템이 할일이고 접근 제어 결정에 참여하는 주체들에 근거하여 변화된다.
