본문 바로가기
IT for researcher/Security

Architecting Dependable Access Control Systems for Multi-Domain Computing Environments

오세암 2010. 7. 23. 14:04


Springer 2009

초록


현대 컴퓨팅 시스템들은 서비스 지향 아키텍쳐기반으로 만들어지고 다중 분산 컴포넌트들로 구성된다. 이것들은 종종 독립되고 자율적인 관리 도메인을 포함하고 동적인 협업을 수반한다. 리소스들과 서비스들은 웹서비스로써 드러난다. 웹서비스는 이질적 컴퓨팅 환경에서 상호운용성을 얻는 중립적인 선택이다.

접근 제어 시스템은 서비스들이 승인받지 못한 접근으로 부터 보호받는다는 것을 보장한다. 멀티 도메인 컴퓨팅 환경에서 그러한 시스템을 구성하는 것은 고려되야만 하는 많은 첼리지가 놓여있다. 그러한 시스템은 모듈화, 확장가능해야만 하고 재사용가능한 컴포넌트를 가지고 있어야만 한다. 권한 부여는 독립되고 자율적인 관리 도메인을 포함할 필요가 있다. 많은 사용자, 리소스 기지로 확장할 필요가 있다. 그리고 분산 컴포넌트 사이에 세밀형 상호작용을 처리하기 충분히 효율적이어야만 한다.

이 논문에서, 다중 도메인 컴퓨팅 환경을 위한 믿을 수 있는 접근 제어 시스템을 구성하기 위한 요구 분석을 보여준다. 특히, SOA기반을 만들어진 환경을 다루고 접근 기술 기반으로써 웹서비스를 사용하낟. 우리는 그러한 환경에 대한 접근 제어를 구성할 때 중요한 관련 표준들과 기술들을 참조한다. 



1 서론

단일한 형태 --> 다중 호스트들 간에 분산 컴포넌트 형태로 변경됨 --> SOA

파트너와 같은 다양한 관리 도메인으로 부터 접근 되는 경우가 많이 생김 --> 다중도메인 컴퓨팅 환경으로 변화됨

웹서비스는 서로다른 도메인의 리소스나 서비스로 부터 애플리케이션을 구성하는데 좋은 분산 컴퓨팅 추상화 기술이다.

자율적인 관리에서 컴퓨팅 환경들의 웹서비스 기반 통합은 많은 보안 챌린지를 가진다. 
단일 조직에서 리소스나 서비스를 보호하는 매커니즘으로는 부족하다. 다양한 조직들은 출동하는 보안 요구사항들을 가지고 있지만 서로 서비스와 리소스를 공개하여 상호작용할 필요가 있다. --> 그래서 멀티 도메인 환경을 위한 보안 매커니즘을 구성하는 것은 복잡하고 에러나기 쉬운 태스크이다. (각각 참여하는 도메인의 기능적, 비기능적 요구사항에 대한 깊이 있는 이해가 필요하다.)

특히 접근제어는 다중 참여자들상에 효율적이고 안전한 협업을 가능케하기 위해 잘 이해되어야한다. 리소스나 서비스를 자신들의 관리 영역안에서 보호할 필요가 있고 다중 도메인 수준에서 추가적인 매커니즘을 적용할 필요가 있다. - 호환되지 않는 정책 언어, 접근 제어 모델, 상호작용할 수 없는 보안 매커니즘 --> 이것들을 잘 통합하기 위해서 안전하고 믿을만하고 관리가능한 접근제어를 제공하기 위한 기존 접근법들을 이해할 필요가 있다.

이 논문에서는 다중도메인 컴퓨팅 환경에 대한 믿을만한 접근 제어 시스템을 구성하기 위한 첼리지를 조사하는것에 목표를 두고 있다. 특히, 접근제어 매커니즘!, 추가적으로 적절한 정책 언어와 접근 제어 모델 사용을 다룬다. 웹서비스를 사용하는 서비스 지향 아키텍쳐에서 권한부여를 제공하는 기존 해결책들에 대해서 초점을 맞춘다.
XACML또는 SAML과 같은 접근제어와 관련된 표준과 접근제어 기반구조를 보호하기위한 보안 표준에 대해 다룬다.


2 Background

2.1 다중도메인 컴퓨팅 환경들

다중 도메인 컴퓨팅 환경은 리소스 공유와 다양한 회사간 문제해결 방법을 제공하기 위해 발전함.
에드혹 형태 -p2p - 이전부터 신뢰 관계가 형성될 필요가 없다.
통합 형태 - 단일형태와 유사하다. 미리 성립된  신뢰 관계를 가지고 동작한다.
VO- virtual orgranization
VO를 형성하는 다중 도메인 컴퓨팅 환경 - PDP, PEP, PAP
공유된 리소스와 협업 참가자들간의 제한된 신뢰라는 분산 속성때문에 공유가 제어될 필요가 있다. - 어떻게 리소스를 제공할지, 누가 리소스 접근이 허가될지, 접근하기 위한 조건은 무엇인지.

다중도메인 컴퓨팅 환경에는 여러 타입이 있다. 
--> 설립 목적, 영역, 크리, 기간, 구조, 커뮤니티, 사회공학들에 따라 달라진다. 
--> 결국 권한 부여 시스템에 영향을 미침

2.2 다중도메인 컴퓨팅 환경에서 접근 제어


단일 도메인인 경우 논리적 장벽을 설정하거나 모든 접근 요청을 분석하여 접근 제어를 수행 할 수 있다.
다중 도메인인 경우 좀더 융통성이 필요하다. 분산 서비스 그룹에 간단한 논리적 장벽을 생성하는 것은 바람직하지 못하다.

접근 제어는 접근제어 정책, 접근제어 모델, 접근 제어 매커니즘을 포함한다. (다양한 추상화 레벨)
정책 - 어떻게 접근이 관리되는지, 누가 그 리소스를 접근하는지를 기술한다.
매커니즘 - 정책을 강화하고, 그러한 정책들이 접근 요청을 어떻게 평가하는지 정의한다.
모델 - 하이레벨 정책과 로우레벨매커니즘간 차이를 연결한다. - 어떻게 접근 제어 룰들이 프로젝트 리소스들에게 적용되는지 정의한다. - 대부분 주체, 대상, 상호작용으로 정의된다.

다양한 접근 정책들이 제안됨. DAC, MAC, RBAC

접근 제어 정책은 Positive authorization과 Negative authorization을 포함한다.

분산환경에서 리소스와 서비스 - 그들 자신이 권한 부여를 처리하지 않고 별도의 서비스에 떠넘긴다. 
Woo and Lam에 의채 처음 다루어짐.

일반적으로, 표면화되는 정책 기반 권한 부여 매커니즘은 네가지 주요 컴포넌트을 필요로 한다.

1. Policy Enforcement Point (PEP): 보호할 리소스 주변에 장벽을 만들고 해당 리소스에 대한 모든 접근을 중재한다. 
2. Policy Decision Point (PDP):  PEP에서 발생시킨 접근 요청 결정 쿼리를 평가한다.
3. Policy Administration Point (PAP): 관리자가 권한부여 시스템에 정책들을 삽입할 수 있는 기능을 제공한다.
4. Policy Information Point (PIP): 접근 요청을 평가하는 동안 사용되는 정보를 제공한다.


보안 정책은 보안 전문가, 서비스 주인 또는 관리자에의해 독립적으로 쓰여질 수 있고 비즈니스 서비스처럼 같은 시간, 같은 패키지에 코딩될 필요가 없다.


PEP와 PEP 사이에 상호 작용은 세가지 제안된 권한부여 결정 쿼리 시퀀스  중 하나를 기반으로 하고 있다.
agent, pull, push

에이전트 모델은 프락시 기반 접근법이다. - 프락시가 서비스 앞단에 놓이고 서비스들의 모든 접근 요청을 중재한다.
PUSH 모델은 권한부여시스템의 결정 컴포넌트에게 접근 요청을 보낼 책임을 지닌 서비스에게 접근 요청이 직접 만들어진다.
PULL 모델은 클라이언트가 결정 컴포넌트와 통신하고 특정 서비스에 접근하기 위하여 credential을 얻는다. 그러한 컴포넌트는 접근에 대해 결정하고 클라이언트를 서비스와 통신할 수 있도록 허락한다.

agent model은 분산된 접근법이다. 정책들은 서비스가 강화되는 모든 도메인의 주위에 위치한 분산된 메이전트에서 표현되고 관리되고 강화된다. 단일 관리 도메인은 다중의 서브도메인들을 가지고 그들 서비스의 접근을 제어하기 위한 다중의 에이전트를 요구한다. 푸쉬나 풀 모델에서, 정책들은 중앙집중적으로 관리될 수 있다 그리고 서로다른 도메인에 위치한 서비스들 그룹에 적용될 수 있다. 특별한 서버들에서 권한부여 정보를 중앙집중화하는 방법을 제공할 때  두가지 솔루션은 SOA에 적합하다. 

권한 부여 결정 쿼리의 푸쉬와 풀 모델은 두가지 권한 부여 매커니즘을 비교하여 표현될 수 있다. 첫째, 푸시 모델을 사용하는 Capability-issueing 매커니즘이다. 

Capability-Issuing Security Architecture.

capability service - CA

capability 기반 권한부여 구조는 비즈니스 서비스 클라이언트에 의해 사용될 수 있는 신뢰된 CA를 특별히 포함한다. 이 CA는 권한 부여를 결정하고 PDE처럼 보여질 수 있다. 그림 2를 보면
1) 클라이언트는 capability 요청을 일으킨다. capability 요청은 적용 가능한 접근 제어 정책들을 비교하여 CS에 의해 평가받는다.
2) CS는 capability 응답을 메세지를 리턴한다.이 응답은 대상에서 주체에의해 수행될 수 있는 액션에 대한 정보를 포함하고 있는 사인된 assertion을 포함한다. 그러한 응답은 capability에 추가적인 제약들이 있다. 유효한 기간정보를 포함한다.
3) capbaility를 요청했던 주체는 비즈니스 서비스 콜에 assertion을 포함 시킨다.
4) 이러한 assertion 정보는 서버에서 추출되고 무결성과 인증에 위해 입증된다. 그러면 enforcement 포인트가 capabiltiy이 충분하지와  리소스에 대한 접근이 허가됐는지 검사한다.

리소스 제공자의 enforcement 포인트와 capability 와 credential 서비스와 신뢰관계가 형성된다.


Policy-Issuing Security Architecture.
다른 곳에서 정리~ 패스


2.3 XACML Overview

다음을 명시하기 위한 OASIS 표준이다.
1. 일반 목적 접근 제어 정책 언어
2. 접근 제어 결정 요청/응답 프로토콜

시스템의 컴포넌트들 끼리 교환되는 속성들은 SAML을 사용하여 인코딩될 수 있다.

XACML는 독립적인 보안 아키텍쳐 컴포넌트들이 도메인들에 걸쳐 함께 잘 동작할 수 있기 위하여 신뢰 도메인들간에 상호운용성을 보장한다. 

XACML in Multi-Domain Computing Environments

XACML 표준은 분산 컴퓨팅 환경을 위한 권한 부여를 제공한다. 이 표준은 다중 도메인 컴퓨팅 환경을 위한 권한부여 시스템에 적합한 확장에 관한 연구가 진행중이다. 이는 시스템의 모듈화와 관리가 별개 도메인들에 걸쳐지는 능력, 분산된 소스로부터 정책 또는 정책 집합을 구성하는 능력을 포함하고 컴퓨팅 환경안에서 XACML 정책 관리 방법을 제공하는 다른 관점들이 고려될 수 있다.
접근제어 시스템의 컴포넌트 사이에서 교환된 정책과 메시지 XML을 가지고 인코드되기때문에 XACML 따르는 컴포넌트들 사이의 상호운용성 문제는 최소화 될 수 있다.

다중 도메인 컴퓨팅 환경에 배치되기 좋은 XACML의 특징

SOA 스타일 아키텍쳐 - 서비스로써 컴포넌트가 표출되고 사용된다. 이러한 서비스들은 느슨한 결합 방법으로 통합 될 수 있고 권한부여 시스템의 요구사항에따라 재사용될 수 있다. 다중 강화 지점은 그들의 선택의 다양한 결정 지점을 사용할 수 있다. 이러한 결정 지점들은 독립된 관리 도메인에 위치하고 마음대로 선택된 정보와 속성과 정책을 가져오기 위한 관리 지점을 사용한다. 정책들이 문법과 의미론에 관해 공통의 언어를 사용하기 때문에 그들은 컴퓨팅 환경을 구성하는 모든 도메인들에서 쉽게 사용될 수 있다.

XACML에서 정책들은 분산된 정책들과 규칙들로 구성될 수 있다.--> 통합 알고리즘이 사용된다.

규칙 통합 알고리즘, 정책 통합 알고리즘 사용
자세한 내용은 OASIS eXtensible Access Control Markup Language (XACML). http://www.oasisopen.org./committees/xacml/, 2005. Version 2.0. 에서 볼수 있음

다른 중요한 특징은 다양한 XACML 프로파일의해 지원되는 정책 관리이다.
이는 XACML 관리와 위임 정책을 기술하기 위한 정책 스키마를 확장하는 위임 프로파일을 포함한다. 

XACML v3.0 Administration and Delegation Profile. http://www.oasisopen.org/committees/xacml/, 2008. Version 1.0.


다중 도메인 컴퓨팅 환경에서 보안 필요성을 다루기 위하여 Cross-Enterprise Security and Privacy 프로파일이 있다.
Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of XACML v2.0 for Healthcare. http://www.oasis-open.org./committees/xacml/, 2008. Committee Draft.

Security architecture for virtual organizations of business web services. 논문에서 권리 위임에 대한문제를 다루고 있음.


3 Challenges

3.1 Access Control Policy Challenges

접근 제어 규칙을 정의하는 프로파일은 권한부여 시스템이 보호하는 목표로 하는 다양한 주체와 대상을 다룰 필요가 있다. 주체에 관한한 접근제어 정책들은 많은 사용자들을 커버하고 결정들은 주체 자격에 대한 이질성을 다룰 수 있어야만 한다. 접근 제어 결정들은 주체들이 동적 분산 환경에서 사전에 알려져 있지 않기 때문에 주체의 신분이 아니라 주체의 속성을 기반으로 만들어져야만 한다. 대상에 관해, 권한부여 정책들은 다양한 프로토콜로 접근가능 해야만 한다. 더욱이 접근 제어 시스템은 서로 다른 문법과 의미를 가지고 다중 정책들을 기반으로 결정을 내리는 방법을 제공 해야만한다. 그래서, 접근 제어 정책 수준에서 상호운용성을 제공하는 것은 필수적이다. 정책 충돌 해결 프로토콜은 해당되는 정책들이 분리된 관리 도메인들로 부터 올 때 과정을 결정한 지원이 존재해야만 한다.


Heterogeneity and Distribution of Subjects and Objects
권한 부여 기반구조는  이질적 주체와 대상의 분산 환경의 보안을 다룰 수 있어야만 한다.
웹 서비스 기반 환경인 경우, 단일 URI를 사용하여 호출되는 다양한 메소드들을 위한 다양한 접근 제어 규칙들을 명시할 수 있을 필요가 있다. 서비스를 교환하는 메세지의 내용을 기반한 권한 부여를 제공해야만 한다. XACML에 대한 웹서비스 프로파일은 권한부여와 프라이버시 요구를 명시하기 위하여 사용될 수 있는 정책 assertioin을 정의한다. 그러한 assertion은 WS-Policy 프레임워크를 사용하여 웹서비스 쪽에서 명시될 수 있는 정책들로 구성된다. RESTful 웹서비스 경우 SOAP 기반 웹서비스들에서 얻을 수 있는 비슷한 프로파일이 필수 적이지 않다. REST 아키텍쳐 스타일에서 부과되는 제약을 따르면 웹서비스들은 다른 URI를 가지고 접근 되고, 그것들의 접근을 제어하기가 더 쉽다.

개체들의 이질성과 분산에 대해 말하자면, 권한 부여시스템은 주체의 자격이 독립된 관리 도메인으로 부터 신분 제공자에 의해 발행될 것이다 라는 것을 고려할 필요가 있다. 거기에는 다양한 신분 제공자들이 권한부여 컴포넌트에 의해 신뢰받을 수 있는 자격을 발행할 수 있다고 보장하는 다양한 방법이 있다. 대분의 접근법은 협업하고 있는 참가자들 사이에서 신뢰형성하는 기본 블록으로 구성된 PKI에 의지한다. 이러한 권한부여 시스템과 사용자 자격사이에 신뢰의 접근법은 
1. identity-based
2. Capability-based
3. Trust-negotiation based

identity-based 접근 제어 시스템에서 
사용자는 자신의 신분 자격으로 표현되고 권한 부여 시스템은 신분 제공자에게 모든 정보를 요청하고 프로파일로써 그것을 참조한다. 
  
Capability-based
사용자는 그들의 신분으로 표현되지 않고 CS로 부터 요구되는 capability를 얻고 강화 지점에 보낸다. 
--------------------------------------------------------------------------------------------
높은 동적 다중도메인 컴퓨팅 환경인 경우에, 사용자 관리는 좀더 복잡하고 identity-based와 capbability-based 접근법은 쉬운 관리와 사용자 프로비저닝, 확장성을 제공해 주지 못한다. 그러한 환경에서는 협업 참가자들이 익숙하다는 가정 없이 신뢰가 성립될 수 있어야만 한다. 그러한 그룹들은 특정 리소스에 접근에 허가되어야만한다는 것을 강화 지점에 확신시키기 위하여 신뢰 협상을 사용한다. 이러한 과정에서 클라이언트와 리소스 제공자는 쌍방의 상호 정책들과 자격정보들 교환을 수행한다.


Context and Content-Based Access to Resources

다중 도메인 환경에서 리소스들의 접근을 제어하는 것은 복잡한 접근 정책을 정의하는 것을 수반한다. 그러한 요청의 상황에 기반한 접근 요청에 제한을 명시할 수 있어야만 한다.  접근이 허가되거나 거부되어야만 하는 임의의 복잡한 조건들을 선언할 수 있어야한다. 권한부여 정책을 명시하기 위해 유용할 수 있는 정보는 사용자의 권리상 도메인, 접근시간 또는 환경상태를 포함한다.  그림 4에서 보여준 것처럼, XACML 모델에 의해 명시된 권한 부여 결정 쿼리 시퀀스는  PIP(Policy Information Point)에서 속성을 검색하는것을 수반한다. 이러한 속성들은 주체, 리소스, 액션, 환경을 참조한다. PIP 컴포넌트들은 이러한 속성들을 저장한다. 특히 주체와 리소스들. 접근 요청동안 액션과 환경에대한 새로운 것을 계산한다.
접근 제어 규칙은 내용 기반 접근의 필요성을 처리할 수 있어야만한다. 그러한 요구는 리소스 소유자 또는 관리인에게 리소스안에 포함된 정보에 따라 제한들을 명시하도록 허락해야만 한다. 웹서비스 경우, 그러한 데이터가 정적이지 않기 때문에 클라이언트에 의해 요청된 리소스안에 포함된 데이터를 예상하는 것이 불가능하다. 그러나, 어떤 접근제어 정책 언어는 의무(obligation) 개념을 통합한다.  섹션 2.3에서 다룬것 처럼 의무는 접근을 허가 또는 거부하기 전에 실행 해야만 하는 액션이다. 웹서비스에서 리소스가 요청받으면 이 리소스에 접근은 이 리소스의 내용을 검사하는 의무를 가지고 허락된다. 개선된 접근은 리소스가 클라이언트에게 돌려주어야하는지 말아야하는지 결정하도록 수행할 수 있다. XACML 명세는 의무를 제한하고 있지 않으며 명시된 구현이 되도록 허락하기떄문에, 의무들은 내용기반 접근제어의 요구 수준을 제공하기 위해 사용될 수 있다.

Policy Heterogeneity Management

구분된 관리상 도메인이 통합된 환경을 만들면, 대부분의 전형적인 각 도메인은 자신의 소유한 보안 도메인을 가지고 있다. [39]에서 다룬 것처럼,
보안 정책들 사이에 의미상 차이점 (접근 제어 정책을 포함하여) 다음 접근법들 중 하나를 채택하여 처리할 수 있다. 첫째, 다양한 도메인들로 부터 균일한 접근 제어 규칙 표현을 제공한다. 이는 다중 도메인들에 걸쳐나타나는 각 접근 요청을 중재하는 메타 정책들을 사용하여 할 수 있다. 둘째,  전체 보안 시스템에 걸쳐 일관되게 사용되는 표준 정책 언어 사용을 강화할 것이다. 조직들이 그들의 권한부여 정책들을 표준화하는 쪽으로 감에 따라, 두 번째 접근법을 더욱 좋아한다. XACML 표준은 일반적인 목적의 접근 제어 언어와 요청/응답 권한부여 결정 프로토콜의 모델 제공을 목표로 하고 있다.

Policy Conflict Resolution

PDP는 관리상 지점이라 불리우는 지정된 저장소로 부터 가져온 모든 적용된 정책 집합, 정책들 규칙들과 비교하여 평가한다. 분산 컴퓨팅 시스템에서  각도메인은  전형적으로 자신이 소유한 PAP 컴포넌트집합을 가진다. 그러한 접근법은 분산된 리소스 집합에 적용 될 수 있는 정책들을 집중화하도록 허락한다.

일반적으로 다중으로 구분된 권한들은 단일 권한 부여 시스템에 의해 지원된다. 그러한 시스템의 결정 컴포넌트들은 다양한 정책 저장소에 있는 정책들을 가져오길 바란다. 그러한 해결책은 PRIMA 권한 부여 시스템에 의해 채택되어 왔다. (다양한 도메인의 사용자 뿐만 아니라 관리자가 리소스에 대한 권한 부여를 위임할 수 있다.

정책들이 다양한 지휘권으로 부터 옴에 따라 정책 충돌이 일어난다. 이는 생략, 에러 또는 정책을 명시하는 관리자의 요구사항의 충돌에 기인한다. 다중 정책들 또는 규칙들이 같은 접근 요청에 적용할때 일관되지 않는것이 발생될 수 있다. 

정책 불일치성은 리소스에 대한 올바른 접근을 하지 못하는 결과를 가져온다. 그래서 정책 충돌이 해결된다는 것을 보장하는 것은 중요한 이슈이다. 어떤 충돌은 정책이 배치되기전에 해결될 수있다. (예를 들어 정책들이 관리 지점에 보내지기 전에). 이러한 처리는 (정적 충돌이라 불린다.) 정책들의 정적 분석에 기반하고 modality 충돌들에 한해서만 적용한다. 그러한 분석은 적용한 정책들의 다양한 집합들을 가지고 있는 모든 {주체, 액션, 대상} 튜플들을 열거한다. 만약 한 튜플에 적용되는 두개 이상의 정책들이 있다면, 거기에는 잠재된 충돌이 있다. 그러한 정책들은 거기에 실제 충돌이 있는지를 보기위하여 후에 검사되어야만 한다.

[3]에서 나타난것처럼, XACML에서 충돌 해결은 규칙과 정책 통합 알고리즘을 사용하여 처리된다. 이는 정책 집합과 다중의 규칙들에 기반하여 권한부여 결정을 수행하기 위해 사용된다. XACML은 이러한 목적을 위해 다음과 같은 알고리즘을 정의한다.
거부 오버라이드, 허가 오버라이드, 처음 적용된, 유일하게 적용된. XACML를 따르는 결정 지점이 단일한 정책안에서 모순된 의미를 가지고 두개 이상의 정책 또는 두개 이상의 규칙을 찾으면, 접근 제어 결정을 하기 위하여 말했던 알고리즘중 하나를 사용한다.

정적 분석은 접근 제어 정책들에서 모든 충돌을 알려줄 수 없다. 일부 충돌들은 애플리케이션에 특정하고 시스템안에 모든 정책들이 배치되는 실행중에만 보여질 수 있다. 그러한 충돌의 예는 정책에 정의된 규칙들이 요구된 의무 분리의 원칙을 처리하지 못할 때이다. 그러한 원칙은 다중 도메인 컴퓨팅 환경에서 협업하는 조직들에 의해 부관된다. 제한된 해결책중 하나는 메타-정책 (다른 접근 제어 정책들안에 애플리케이션에 특정한 제약들을 포함한다.). 섹션 2.2에서 다룬 접근 제어 매커니즘을 고려해 보면, 메타 정책들은 각 도메인안에 놓여질수도 또는 모든 도메인에 적용될 수도 있다. 첫 번째 경우, 같은 클라이언트는 동시에 어떤 리소스를 접근할 수 없어야만 하는 SoD 정책을 참조한다. 


3,2 Access Control Architecture Challenges : 접근 제어 아키텍쳐 챌린지
권한부여 아키텍쳐는 다중 도메인 컴퓨팅 환경을 형성하는 조직들 사이에서 복잡한 통합 시나리오를 고려할 필요가 있다. 이는 그러한 아키텍쳐를 구성하는 컴포넌트들의 이질성을 다룰 필요가 있고 그들 사이에 상호운용성을 보장하는 방법을 제공해야만 한다.
컴포넌트들은 접근제어를 결정할때 의미있는 정보를 서로 교환할 수 있어야만 한다. 권한부여 아키텍쳐는 컴퓨팅 환경안에 리소스들과 비슷한 방법으로 안전해야만 한다. 컴포넌트간 통신은 보존되는 메세지의 기밀성과 무결성을 믿을 수 있어야만 한다. 그러한 아키텍쳐는 컴포넌트들끼리 통신을 효율성을 보존하는 동안 자신의 환경을 따라 확장할 수 있는 능력이 있어야만 한다. 새로운 접근 제어를 소개하거나 예전것을 취소하는 것은 다중의 별개의 관리상 그룹에 의해 실행될 수 있어야만 한다. 


Interoperability Between Access Control Components
분리되고 자율적인 관리 도메인들은 분산된 권한부여 시스템에서 협력할 필요가 있다. 그러한 시스템은 일관된 권한 부여 전략을 유지할 필요가 있고 각 도메인은 다중 도메인 컴퓨팅 환경의 정체 생명주기에 걸쳐 잠재된 협업자의 최소 지식을 가지고 있어야만 한다. 관리 도메인들에 걸쳐 퍼져있는 권한 부여 결정들은 모든 도메인에 컴포넌트가 잠재적으로 이질적 피어들의 그룹으로 부터 온 권한 부여 정보를 올바르게 생산하고, 받아들이고 해석할 수 있음을 요구한다. 공통 합의 프로토콜 (권한 부여 시스템의 컴포넌트들끼리 교환되는 모든 정보의 문법과 의미)은 필수이다. 이는 퍼미션 명세를 위해 사용되는 언어 수준과 시스템의 다양한 컴포넌트들사이의 통신을 위해 사용되는 프로토콜 수준에서의 상호운용성을 포함한다.
정책 명세 언어 수준에서 상호운용성을 성취하는 것은 많은 연구가 이루어 지고 있고 다양한 언어들이 접근 제어 규칙들을 명시하기 위해 존재한다. XML 기술은 이러한 언어들중에 가장 유망한 언어중 하나로써 알려지고 있다. XML은 이질적인 시스템들간 정보의 균일한 표현, 교환, 공유, 구분을 허락한다. XACML로써 접근 제어 정책 언어의 기본을 구성한다.
권한 부여 시스템의 분산된 컴포넌트들사이의 통신을 위해 사용되는 표준 프로토콜은 필수이다. 섹션 2.3에서 다룬것 처럼 접근제어 시스템의 강화, 결정, 정보, 관리 지점간 정보 흐름은 보내지고 의해 되는 다중의 메세지들을 요구한다. 권한부여 시스템의 컴포넌트들은 그들이 교환하기 바라는 정보의 구문과 의미에 동의 해야만 한다. XACML 표준에서 제안되는 요청/응답과 같은 프로토콜들은 그러한것을 성취하는 것을 목표로한다. 다양한 컴포넌트들간 교환되는 정보의 구문과 의미외에도 그들 컴포넌트들의 인터페이스들은 잘 표준화되어야만 한다. 이는 또한 SOAP기반 또는 RESTful 인터페이스로써 그들의 기능을 드러내는 컴포넌트들에 적용한다. 두 경우에서 그들의 인터페이스들은 잘 정의되어야만 하고 접근 제어 시스템의 다른 컴포넌트들은 그것들을 호출 할 수 있어야만 한다. 권한 부여 아키텍쳐의 XACML를 따르는 컴포넌트들인 경우, 컴포넌트들과 인터페이스 정의들간 상호운용성은 [10], [12]에서 다루어지고 있다.

Location of Policy Decision Points
일단 접근 요청이 리소스에게 만들어지면 강화 지점은 접근을 허가할지 말지 결정하기 위하여 결정 지점과 접촉할 필요가 있다. 강화 지점은 어느 결정 지점이 사용되어야만 하는지 알 필요가 있다. 권한부여 기반구조의 제한된 컴포넌트 갯수를 가진 분산 시스템에서, 강화지점과 결정 지점사이의 관계는 정적일 수 있다. 강화 지점이 초기화 될때, 미리정의된 결정 지점이 그 지점을 가지고 통신 채널을  얻을 수 있는지 검사한다. 권한부여 기반구조의 컴포넌트들간 정적 관계는 잘 확장 될수 없지만 설계,구현이 쉽다.
우선, 결정지점과 강화지점 모두 쉽게 상호간 인증을 받을 수 있다. 셋업하는 동안 이러한 컴포넌트들 서로 공개키를 접근할 필요가 있다. 상호 인증은 두가지 이유때문에 필요하다. 첫째, 강화 지점은 권한부여 결정 응답이 신뢰받은 결정 지점으로 부터 온 것이라는 확신이 필요하다. 이는 강화 액션들이  적용된 보안 정책들을 반영한다는 것을 보장한다. 둘째, 결정 지점들은 진짜 접근 요청 결정 쿼리에서만 결정들을 드러내야만한다. 그렇지 않으면, 시스템 안에 강화된 접근제어 정책들에 대한 정보를 누출할 수 있다.
비록 정적 바인딩이 소규모 분산 시스템에서는 충분하지만 다중의 분리된 관리 도멩인에 걸쳐 퍼져있는 대형 컴퓨팅 환경에는 적절치 못하다. 무엇보다 강화 지점은 다른 도메인들에게 권리를 위임하고 어느 결정 지점이 사용되어야만 한다는것을 정확히 명시하기 원하지 않는다. 그러한 강화지점은 특정 관리 단체에 의해 사인된 어떤 결정에서도 만족된다. 동적으로 변경되는 분산 환경에서 정적 바인딩은 실행될 수 없음. 그러한 경우 발견 매커니즘이 채택될 필요가 있다.

Management of Access Control Systems
많은 경우에 서로 다른 강화 지점으 설정은 가능한 정확하게 보안 정책을 구현하기 위하여 독립적으로 관리된다. 결과적으로, 보안 정책을 변경하고 모든 기반구조안에서 이를 배치한다는 것은 매우 비용이 많이 들고  신뢰할 수 없는 일이다. 추가적으로, 보호와 보안 제어의 통합된 관점을 얻는것이 불가능하다. 이는 어떻게 보안 정책이 강화되는지 이해하는것을 어렵게 만든다. 행정부는 보안이 ISO2007와 같은 문서로 부터 가이드라인을 따르는 방법에 제공되고  DAP와 같은 필수적인 제정법 요구사항과 긴밀히 연결되는 것을 보장하도록 강요받는다. 요구된 문서를 따르는 외부 회계감사관에게 증명하기 위한 능력은 회사와 VO에게 보안 정책을 강화를 더 잘 이해가능토록하는 보안 매커니즘을 제공하도록 강요한다.
권한부여 상황에서, 보안 시스템은 컴퓨팅 환경안에서 강화된 접근제어 정책의 통합된 관점을 제공하는 방법이 필요하다. 이는 일반적으로 중앙집중화된 정책과니롸 결정 컴포넌트들에 의해 성취된다. 정책들은 그들이 사용되는 서비스들을 독립적으로 구성할 수 있다. 이러한 정책들은 컴플라이언스 또는 다른 요구사항들을 만족하도록 정의될 필요가 있다. 더욱이, 중앙 집중적인 정책들은 그들 정책들이 분산된 리소스들의 집합에서 일관되고 적용되고 그들 정책을 감사하는데 이용될 수 있다는 것을 보장한다. [3]에서 다룬것 처럼, 정책 관리는 권한 부여 정책을 쓰기, 검토, 테스트, 이슈 승인, 통합, 분석, 변경, 취소, 가져오기, 강화를 포함한 여러 다양한 단계를 수반한다. 각 단계를 안전하게 하는 방법을 제공하는 것이 고려되어야만 한다.

Communication Performance



Autonomy of Administration Domains.
리소스들이 VO안에 서로 다른 조직에게 공유되면 일부 접근 제어는 크로스도메인 면에서 위임된다. 하나의 도메인은 다른 도메인으로 부터 온 접근제어 결정을 받아들일지 결정하고 두 접근 제어 시스템들의 컴포넌트들간 신뢰관계를 형성한다. 그러나, VO 환경에 참여하는 조직들은 접근 제어 결정에서 그들의 자율성을 보존할 수 있어야만 한다. 각 도메인은 전형적으로 자신들이 소유한 접근 제어 규칙을 소개할 것이다.
분리된 도메인의 자율성을 보존하는 첼리지에 대한 접근법은 승인 계층 (authorities hierarchy)를 사용하여 처리될 수 있다. 그러한 계층의 각 레벨은 서로다른 역역의 접근 제어 규칙을 정의하는것을 책임진다. 이러한 접근법의 한 예는 [50]에서 다루어지고 있다. 그러한 시스템에서, 다중 엔티티들은 서로 다른 레벨에서 리소스에대한 접근제오를 수행한다. 예를 들어, 사이트 정책은 사이트 권한을 정의할 수 있고 단일 리소스에 대한 정책은 개별적으로 정의될 수 있다. 추가적으로, 전체 VO를 위한 권한 부여 정책을 제어하기 위한 승인들도 있다.
승인의 각 레벨은 받아들일수 있는 접근 권한 규칙들에 자신이 소유한 제약들을 부과한다. 그러한 제약들이 충돌을 발생시키면 제안된 해결 매커니즘을 사용하여 해결할 수 이다. - 섹션 3.1에서 이미 다루었음. XACML 표준은 관리 도메인들의 자율성에 관한 요구사항을 다룰 수 있는 프로파일을 제공한다. 이 정책들은 관리상의 요구와 위임 정책을 기술하기 위한 적절한 스키마들을 확장한다. 

Access Control Delegation.
이전 섹션에서 다룬것 처럼, VO안에서 협업하는 참가자는 같은 VO의 다른 참가자에게 접근제어 결정을 위임한다. 그러한 위임은 누가 리소스를 위해 접근 제어 규칙들을 구성하도록 승인받았는지 정의하는 관리 정책에 명시된다. 중앙집중된 관리 정책은 협업하는 참가자들이 권한 부여 관리를 허가하거나 취소하는 단일 승인에 동의하지 않기 때문에 다중 도메인 컴퓨팅 환경에 충분하지 못하다. 그러한 경우들에서, 도메인들은 협업 유형 관리 정책을 사용한다. (모든 참가자들이 권한부여 규칙들을 동의할 수 있는)

또 다른 접근법은 관리 정책들의 분산된 모델이다. 이 모델에서 각 도메인들은 자신이 소유한 관리 정책을 가지고 얼마나 많이 다른 도메인에게 접근 제어 결정을 위임시킬지 정의한다. 그러한 접근이 다른 도메인들에게 위임되었을때, 도메인들은 더욱 이를 위임할수 있을수도 없을수도 있다. 리소스들에 대한 권리를 추적하기 어렵기 떄문에 권한 부여 관리 프로세세는 복잡하다. [55]에서 다룬것 처럼, 접근 제어 권리의 취소는 복잡하다.
PRIMA 권한 부여 시스템에서 제안된 위임 사용 예가 있다. 이 시스템은 승인된 리소스에대한 접근을 사용자뿐만 아니라 관리자에게 위임하도록 허락하여 다중 승인을 지원한다. 리소스 승인은 다른 사용자에게 권한을 허가하고 리소스를 위한 정책을 발행하는동일한 매커니즘을 사용할 수 있다. XACML 표준은 프로파일 사용을 통해 위임을 얻는 방법을 제공한다. 2.3에서 다루었다.

'IT for researcher/Security' Related Articles

티스토리툴바