• 검색 결과가 없습니다.

(1) 개요

CAS (Community Authorization Service) [4]는 그리드 가상조직에 참여하는 멤버들 간의 자원 공유를 위해서 범용적으로 제안된 모델이다. 이 모델에서는 하나의 신뢰하는 CAS 서버를 지정하여, 가상조직에 참여하는 멤버들의 인증 및 자원 접근 정책을 관리한다. 따라서, CAS 서버는 한 가상조직에 속한 CA, 사용자, 서버, 자원 등에 대한 모든 구성요소 정보를 관리하며, 자원 사용 관련 모든 정책도 포함하게 된다.

그림 3에서 처럼, 가상조직에 속한 한 사용자는 먼저 CAS 서버에게 자신이 사용할 수 있는 Credential을 요청하여 받는다. 만약 그 사용자가 정당한 사용자인 경우, 그에 해당하는 Capability (예: 인증서)를 발급하게 된다. 사용자는 이 과정에서 얻은 위임장을 사용해서 자신이 원하는 작업을 수행하게 된다.

그림 3. CAS 서버로부터 사용자 Credential 요청 [4]

사용자는 그림 3에서 얻은 위임장을 자신이 사용할 자원에 제시를 하며, 그 자원은 사용자의 위임장과 자신의 자원 관리 정책에 따라 자원 제공을 결정하게 된다. (그림 4 참조)

- 7 -

그림 4. CAS 사용자 인증 [4]

CAS 방식은 사용자-CAS서버 간의 신뢰, CAS서버-자원 간의 신뢰를 바탕으로 자원은 사용자를 신뢰하게 된다. 자원제공자가 개개의 사용자에 대한 모든 정책을 관리하는 부담을 없애고, 정책 권한을 CAS서버에 위임하여 CAS서버로부터 정당한 위임장을 받은 사용자에 대해서는 허락한다. 단점은 CAS서버가 하나 존재해야 하므로, 병목현상이나 단일 결함점(Single point of failure) 등이 있다.

(2) 보안 고려사항 가. 제한된 프록시 인증서

위임된 인증서를 발급할 때 사용자의 권한을 초과한 프록시 인증서를 발급하지 않도록 해야 한다. 그리고 프록시 인증서의 유효기간을 짧게 정의하여 이 기간이 지난 인증서는 사용할 수 없도록 한다.

나. Compromised CAS 서버

만약 CAS 서버가 신뢰할 수 없는 상태가 되면, 가상조직의 정책에 위배되는 인증서를 발급하거나 멤버가 아닌 사용자에게도 인증서를 발급하게 된다. CAS 모델인 CAS 서버에서 모든 정책관리 및 위임이 되기 때문에, CAS 서버가 신뢰를 잃게 되면 인증 모델에 심각한 문제가 발생된다. 만약 자원제공자가 CAS 서버를 신뢰할 수 없다고 판단을 할 경우, 그 서버에서 발행한 인증서를 제시하는 사용자에게 접근을 제한해야 한다.

다. 취소 방법

만약 한 사용자의 인증서가 신뢰할 수 없게 되었을 경우, 그 사용자는 CAS 서버에서

- 8 - Authority)와 SSLK5/PKINIT는 Kerberos와 GSI 간의 상호 전환을 제공한다.

나. 보안 서비스에 대한 동적 생성

- 9 - 들어, WS-Policy [16], XACML, WS-Security, SAML, WS-SecureConversation, WS-Trust 등의 다양한 보안 Web Services 기술을 이용할 수 있다

나. 호스팅 환경 (Hosting Environment)

그리드 서비스는 Web Services와 같이 J2EE나 .Net과 같은 호스팅 환경에서 지원된다.

이러한 호스팅 환경에서 여러 가지 보안 서비스를 제공함으로써 사용자가 쉽게 그리드 보안 서비스를 사용할 수 있게 된다.

다. 보안 정책 (Publishing of Security Policy)

가상조직에 참여하는 여러 개의 기관 및 사용자 사이에 신뢰관계를 구축해야 한다.

- 10 -

2. 만약 필요한 Credential이 없는 경우, Credential 변환 서비스를 연결해서 필요로 하는 형식의 Credential을 얻어 온다. 예를 들어, 가상조직의 Credential을 얻기 위해서 CAS [4] 서비스를 사용하거나, Kerberos와 PKI 간의 전환을 위해서 KCA [17]를 사용한다.

3. 클라이언트 호스팅 환경은 해당 서비스와 서로 보안 토큰을 주고 받으면서 서비스 상에서의 상호 인증 절차를 진행한다.

4. 서비스 쪽에서도 마찬가지로 요구한 클라이언트와의 보안 토큰에 대한 인증 절차를 진행한다.

5. 클라이언트의 인증 절차를 마치고 정책에 대한 적합성을 위해서 권한 인증 서비스(예: PERMIS [18]나 Akenti [19])를 실행 한다.

그림 5. OGSA 보안 모델 예제 [20]

관련 문서