초록
점점더 웹 서비스를 기반으로 하는 소프트웨어 시스템이 개발되오고 있다. 웹서비스 개발 기술은 그래서 매우 중요한다. 안전한 정보 접근을 보장하기 위하여, 접근 제어는 웹서비스를 개발할때 고려되어야만 한다. 이 논문은 웹서비스를 위한 안전한 정보 접근을 보장하기 위한 확장된 XACML 모델을 제안한다. 이느 정보 흐름 제어 기술에 기반한다. 이 모델에 의해 제공되는 주요 특징은 (1) 요청자들의 정보와 웹서비스들의 정보는 보호받는다. (2) 웹서비스 접근 제어는 기존 모델에서의 "허용" 또는 "거부"보다 좀더 정확하다. (3) 모델은 요청자가 웹서비스를 호출하도록 허락 받았을 때 웹서비스를 실행하는 동안 안전하지 못한 정보 접근을 거부할 것이다.
1. 서론
소프트웨어 시스템들이 점점더 네트워크위에서 동작하기 때문에 인터넷은 실제적으로 소프트웨어를 변화시키고 있다. 소프트웨어 개발의 노력을 줄이기 위하여, 웹서비스는 애플리케이션이 호출하도록 제공해 오고 있다. (여기서 웹서비스는 재사용된 소프트웨어 컴포넌트로 간주 될수 있다.) 웹서비스 개발에서, 웹서비스가 실행되는 동안 안전한 정보 접근을 보장하는 것은 중요하다. 많은 연구들이 웹서비스 접근 제어에 관하여 제안해 오고 있다. 일반적으로, 이러한 연구들은 웹서비스를 접근하는 요청자를 허용 또는 거부하는데 집중한다. 일부 연구는 웹서비스들 사이에 협상/대화(negotiation/conversation)의 문제를 해결하기 위해 좀더 발을 내딛는다. 협상에 대한 필요는 호출된 웹서비스가 다른 웹서비스들을 호출하기 때문이다. 우리의 연구에서, 우리는 요청자 또는 웹서비스들이 실행되고 있을 때 정보의 안전한 접근을 보장하기 위해 한걸음 더 나아간다.(정보 누수 방지) 안전한 정보 접근은 정보 흐름 제어를 통해 성취될 수 있다. 기본 제어 매커니즘은 승인받지 못한 롤들이 애플리케이션 실행안에서 정보를 접근하는 것을 허락하지 않는것이다. 롤들은 사용자에 의해 행동되기 때문에, 승인받지 못한 롤들이 정보를 접근하는것을 허락하지 않는 것은 승인받지 못한 사용자가 민감한 정보를 접근하는 것을 막는다. 이는 정보 흐름 제어의 목적을 성취한다. (예. 정보 누수 방지하기)
우리는 웹서비스 접근 제어를 위해 OASIS에서 제안된 XACML 모델을 확인했다. 요청자의 속성을 검사하여 요청자가 웹서비스를 호출할 수 있을지를 판단한다. 우리는 또한 XACML 구현물들을 확인했다. 더불어, 우리는 협상 문제를 해결하기 위한 모델들을 확인했다. 처리되고 있는 이슈들에 추가로, 우리의 연구는 웹서비스 접근제어에서 풀어야만 하는 다음 세가지 문제를 식별했다.
(a) 기존 모델들은 웹서비스들만을 보호한다. 우리 견해로는, 요청자들의 정보와 웹서비스들의 정보 모두 보호되어야만 한다.
(b) 기존 모델들은 "허용" 또는 "거부" 결정만 한다. 다시말해 요청자의 속성이 웹서비스 요구를 만족한다면 요청자들은 웹서비스를 호출하도록 허락받을 것이다. 그렇지 않으면 요청은 거절된다. 우리는 "허락" 또는 "거절"만으로는 웹서비스 접근제어에서 부정확하다라고 생각한다. 예를 들어 웹서비스가 어떤 상황에서는 민감한 정보(은행에서 고객의 계정과 비밀번호) 를 관리하고 또 다른 상황에서는 민감하지 않은 정보(은행에 의해 제공괴는 광고)를 관리한다고 가정하자. "허용" 또는 거절" 정책에서, 요청자들은 요청자가 웹서비스에 의해 관리되는 민감한 정보에 접근하도록 승인된 경우에만 웹서비스를 호출할 수 있도록 허락받는다. 실제의 경우에, 민감하지 않은 정보를 접근하기위하여 웹서비스를 요청할 수도 있다. 이러한 경우에, 요청자에 의해 웹서비스가 호출되는 것은 거절되지 말아야한다. 그럼에도 불구하고, 요청자가 민감한 정보를 접근하도록 승인받지 못한다면 "허용" 또는 "거부" 정책은 요청자를 거부할 것이다. 우리 견해로는, 요청자가 기본 요구사항을 만족한다면 웹서비스를 호출하는 것은 허락되어야만 한다고 생각한다. 웹서비스가 실행되고 있을때, 요청자가 요청자에 대한 인증받지 못한 정보를 접근하는것을 요청한다면, 웹서비스는 요청을 거부하고 서비스를 정지한다. 이러한 접근 제어 정책은 "허용" 또는 "거부" 정책보다 좀더 정확하다.
(c) 기존 모델들의 제어에서 요청자가 웹서비스를 호출하도록 허락받으면 웹서비스는 요청자가 요구한 모든 것을 해야만 한다. 만약 안전하지 않은 접근이 일어나면, 웹서비스는 접근을 거부할 수 없다. 우리 견해로는, 웹서비스에서 정보 접근은 웹서비스가 요청자에 의해 호출되는 것이 허락되었더라도 모니터되어야만 한다고 생각한다.
위에 기술된것에 의하면, 우리는 웹서비스를 위하 접근 제어가 좀 더 정확해야만 한다고 생각한다. 과거 몇년간 우리는 정보 누수를 막기 위한 정보 흐름 제어 모델을 개발했다. 이는 웹서비스의 접근 제어에서 또한 사용될 수 있다. 여기에서 정보 누수는 낮은 보안 수준 사용자에게 높은 수준의 정보를 드러내가 되는 것을 의미한다. 예를 들어, 환자의 케이스 히스토리는 병원의 의사만이 읽을 수 있다면, 정보 누수는 환자가 다른 환자의 케이스 히스토리를 얻었을 때 일어난다. 프로그램을 실행하는 것에서, 정보 흐름은 정보가 변수에 할당 되었을 때 일어난다. 정보 흐름을 제어하는 것은 높은 수준의정보가 낮은 보안 수준의 사용자에 의해 접근될 수 있는 변수에 할당되는 것을 막는것이다. 애플리케이션의 변수는 일반적으로 애플리케이션의 정보를 운반하고 사용자는 변수를 출력하면 변수의 내용을 얻을수 있기 때문에, 정보 흐름을 제어하는 것은 낮은 보안 수준 사용자가 높은 보안 수준 정보를 얻는 것을 막는다.
우리 연구에서, 우리는 정보 흐름 제어 개념을 포함하여 XACML를 확장했다. 확장된 모델은 EXACML 으로 명명한다. 현재, 이 모델은 객체 지향 웹서비스에 적당하다. EXACML은 요청자와 웹서비스에 의해 관리되는 정보를 보호한다. 더욱이 EXACML에서 접근제어는 "허용" 또는 "거부" 정책을 따르지 않는다. 대신, EXACML은 웹서비스에 기본 요구사항을 설정한다. 기본 요구사항은 요청자가 웹서비스를 호출할 수 있는지 여부를 결정한다. 웹서비스가 다른 웹서비스를 호출 하기 때문에, 기본 요구사항은 요청자가 그 웹서비스들을 호출 할 수 있는지 또한 결정한다. 다시말해, 기본 요구사항은 위에서 말한 협상을 제어한다. 요청자가 웹서비스의 기본 요구사항을 만족하면 요청자는 서비스를 호출할 수 있다. 웹 서비스 실행중에, EXACML은 요청자가 승인되지 않은 민감한 정보를 접근하는 것을 막는다. 그래서 EXACML은 위에서 언급한 세가지 문제를 해결한다. 더욱이, 정보 흐름 제어의 개념이 포함되었기 때문에, EXACML은 일기 쓰기를 제어하는 것과 간접적 정보누수를 막는것과 같은 정보 흐름 제어 모델의 특징을 상속한다.
2. 관련 연구
웹서비스에 대한 접근 제어는 민감한 정보가 누수되는것을 막는다.
그 동안 제안되어 왔던 웹서비스의 접근제어를 조사한다.
Bertino (2006)는 웹서비스 접근 제어에 대한 두가지 레벨 매커니즘을 사용한다.1단계(서비스 레벨)은 고객과 웹서비스에 할당된 롤을 검사한다. 승인받은 요청자는 웹서비스를 부를 수 있는 후보자이다. 우리는 승인받은 요청자는 웹서비스를 호출하기 위하여 2단계를 만족해야 하므로 후보자(candidate)라는 용어를 사용한다. 2 단계(속성 레벨)은 서비스의 속성으로써 파라미터를 사용하고 속성에 퍼미션을 할당한다. 요청자는 속성 접근하기 위한 퍼미션을 가지고 있을 때에만 웹서비스를 호출할 수 있다. 이 모델 제어는 하나의 레벨 제어를 사용하는 것보다 좀 더 정확하다. 하지만, 여전히 문제점을 해결할 수는 없다.
몇몇 연구들은 요청자와 웹서비스간 협상에 초점을 맞춘다. - 우리의 목적과 일치하지 않기 때문에 살짝 조사한다. 우리는 우리 모델의 기본 요구사항이 또한 협상의 한 종류이기 때문에 그것들에 대해 논한다.
3. 모델
웹서비스 XACML, EXACML 에 대해 기술한다.
3.1 웹서비스
서비스 요청자, 서비스 제공자, 서비스 중개자.(UDD)
서비스 제공자가 서비스 중개자에가 서비스를 등록한다.
서비스 요청자는 서비스 중개자로부터 서비스를 검색한다.
만족되는 서비스가 있다면 서비스 제공자의 웹서비스를 호출한다.
3.2 XACML
3.3 EXACML
XACML에 정보 흐름 제어 함수를 할당했다. EXACML에서 요청자는 웹서비스를 호출하기 전에 기본 요구사항을 만족해야만 한다. 요청자가 기본 요구사항을 만족하는지 검사하는 것은 요청자와 웹서비스들 간 협상과 일치한다. 그래서, 기본 요구사항은 섹션 1에서 말한 협상 해결책의 하나이다. 우리는 우리 연구는 단지 협상 문제를 해결하는 대신 섹션 1에서 언급한 세가지 문제를 해결하는데 목표를 두고 있기 때문에 우리의 협상 접근법을 다른 것과 비교하지 않는다.
요청자가 기본 요구사항을 만족하고 웹서비스를 호출할 때 웹서비스는 실행되고 있다. 실행동안 EXACML은 정보 흐름의 원인이 될 수 있는 명령이 안전한지 검사한다. 만약 안전하지 않은 정보 흐름이 식별된다면, 웹서비스는 정보 누수를 막기위하여 정지될 것이다. 우리는 RBAC 에 기반한 EXACML 모델을 공식적으로 정의한다.
EXACML = (USR, RLE, URA, VAR, ACLS, DSOURCES, BR)
(a) USR: 사용자들의 집합, 사용자들은 애플리케이션이 수행될 때 롤들로 동작한다.
(b) RLE: 롤들의 집합. EXACML은 객체(object)를 롤로써 간주한다. 실세계의 객체들이 소프트웨어 객체로 자주 맵핑되기 때문에 이는 자연스럽다.
(c) URA: 사용자-롤 할당 집합이다. USR --> 2(RLE)
(d) VAR: 요청자와 웹서비스에 나타나는 변수의 집합. 변수는 객체의 속성, 메소드에서 사용하는 사적인 변수 또는 메소드 리턴 값이다.
(e) ACL은 접근제어 목록들의 집합. EXACML은 ACL을 변수에 붙인다. ACL은 EXACML에서 퍼미션이다. ACL이 변수에 붙게되니까, 제어 범주는 변수만큼 상세하게 된다. 우리는 다양한 변수들이 각기 다른 보안 수준에서 정보를 운반하기 때문에 세밀형 제어가 필요하다. 일반적으로 롤은 ACL을 정의하기 위해 사용되어야만 한다 (예, 퍼미션). 그럼에도 불구하고 ACL을 정의하기 위해 롤을 사용하는 것은 부정확한 제어 결과를 초래한다. 의사는 자신에게 할당되어 있는 환자의 케이스 히스토리를 살펴보고 변경할 수 있다. 더불어, 자신에게 할당되지 않은 환자에 대한 케이스 히스토리를 볼 수는 있지만 변경할 수 없다. 이러한 가정아래, 만약 환자가 어떤 의사에게 할당된다면 의사의 객체 메소드 "browse_case_history" 와 "change_case_history"는 환자 객체의 속성 "case_history"를 접근할 수 있다. 반면에, 의사에게 할당되지 않은 환자라면, "browse_case_history" 메소드만 "case_history" 속성을 접근할 수 있을 것이다. 우리는 객체들을 롤로써 간주한다고 가정해보자. 그러면, 객체가 변수의 접근이 허락될 때 객체의 모든 메소드는 그 변수를 접근할 수 있다. 이는 모든 의사 객체의 메소드 "brose_case_history"와 "chang_case_history"에게 모든 환자 객체의 속성 "case_history"에 접근하는 것을 허락할 것이다. (롤이 의사뿐만 아니라 좀 더 세분화된 동적 롤을 만들면 안될까?) 이는 위에서 언급한 예제를 제어하는데 문제가 된다. ACL을 정의하기 위하여 롤을 사용하는 것은 부정확한 제어를 초래한다. EXACML은 ACL을 정의하기 위하여 롤 (예, 객체) 대신 객체 메소드를 사용한다. MD를 객체 메소드의 집합이라고 하자, 변수 var에 붙은 ACLvar은 다음과 같이 정의된다.
ACLvar = {RACLvar; WACLvar}
RACLvar은 var 변수를 읽는 것이 허락된다.
WACLvar은 var 변수를 쓰는것을 허락된다.
(f) DSOURCES는 데이터 소스들의 집합. EXACML에서 각 변수는 접근 제어를 쓰는데 이용하기 위한 DSOURCE와 연관되어 있다. DSOURCE는 변수의 데이터를 쓰는 객체 메소드를 기록한다. 예를 들어, 변수 "var"은 "var1" 과 "var2"로 부터 파생되고, "var1"과 "var2"는 각각 객체 메소드 "md1" 과 "md2"에 의해 쓰여진다고 가정하자. 그러면 "var"의 DSOURCE는 집합 {md1, md2} 이다.
(g) BR은 기본 요구사항이다. 다음 텍스트에서 우리는 BR에 대해 기술할 것이다.
정의 1에는 중요한 컴포넌트가 빠져있다. (롤-퍼미션 할당과 세션)
롤-퍼미션 할당은 ACL은 변수가 롤의 메소드에 의해 읽혀지거나 쓰여질 수 있다는 것을 의미하기 때문에 포함시키지 않는다. 다시 말해, 롤-퍼미션 할당은 ACL안에 포함된다. 우리는 웹서비스가 호출되면 자동적으로 세션이 생성되고 서비스가 끝나면 세션이 끝난다고 추정한다. 그래서 우리는 세션을 정의할 필요가 없다.
요청자가 웹서비스를 호출할 수 있는지 검사하기 위하여, 요청자와 웹서비스는 우선 기본 요구사항을 만족해야만한다. (BR 컴포넌트로 구성된 기본 요구사항)
우리 원래 설계에서, 우리는 기본 요구사항을 정의하기 위하여 ACL을 사용한다. 우리는 ACL은 접근이 프로그램안에서 안전한지 검사하거나 프로그램으로 부터 다른것이 호출되는 것이 안전한지 검사하는 것에만 적절하다는 것을 식별했다. 그럼에도 불구하고, 이것들은 프로그램들이 추가되거나 제거되는 환경아래에서 프로그램에서 다른 프로그램을 호출하는 것이 안전한지를 검사하는데 사용될 수 없다. 이론적 설명은 ACL을 정의하기 위해서 모든 프로그램의 변수를 아는것이 필수적이다. 웹서비스 기반 환경에서, 애플리케이션과 웹서비스 모두 언제든지 추가된고 제거된다. 그래서, 우리는 기본 요구사항을 정의하기 위하여 ACL대신 다른 매커니즘을 사용했다. 우리는 이를 신뢰 관리 매커니즘이라 부른다. 이 매커니즘을 정의하기 위하여 다음과 같은 서브 컴포넌트가 BR 컴포넌트에 포함되어야만 한다.
(a) 보안 레벨 숫자: 요청자가 웹서비스를 호출 할 때 요청자의 모든 인수와 웹서비스의 리턴 값은 보안 레벨 숫자와 연관되어야만한다. 이 숫자는 요청자와 웹서비스 모두 인수와 리턴 값의 보안 레벨을 알지 못하기 때문에 프로그래머에 의해 설정된다. 프로그래머는 우선 인수와 리턴 값의 보안 레벨을 결정한다. 그들은 그후 인수와 리턴 값에 적절한 보안 레벨 숫자를 지정한다. EXACML은 4비트 숫자를 사용한다. 다시말해 보안 레벨은 0~15이다. 숫자가 클 수록 좀 더 민감한 정보임을 의미한다.
(b) 신용 레벨 숫자: 모든 애플리케이션과 웹서비스는 신용 레벨 숫자와 연관되어 있다. 보안 레벨 숫자처럼, EXACML은 4비트 숫자를 사용한다.
(c) 호출 그래프: 웹서비스는 다른 웹서비스를 호출한다. 신뢰 관리 매커니즘은 웹서비스들 사이에서 호출 관계를 나타내기 위하여호출 그래프가 필요하다. 관계는 요청자가 웹서비스를 호출할 때 요청자에 의해 호출될 수 있는 웹서비스의 구성을 식별하는데 이용한다.
새로운 서비스가 생성되면 UDDI에 등록된다 . 새로 추가된 웹서비스에서 호출될 기존 웹서비스들도 등록된다. 새로 추가된 웹서비스의 리턴 값의 보안 레벨 숫자 또한 등록된다. 등록된 호출 관계로 UDDI는 호출 그래프를 생성한다. UDDI는 새로운 서비스에 초기 신용 레벨 숫자를 부여한다. (15를 부여한다.) 그들이 정보 누수를 시도하면 웹서비스 또는 애플리케이션 실행을 정지할 것이므로 최대 신용 숫자를 부여했다.
애플리케이션 APPLI 가 웹서비스 WEBSER를 호출을 시도할 때 APPLI 프로그래머는 WEBSER에 보내질 모든 인수에 보안 레벨 숫자를 할당한다. EXACML은 그후 UDDI에게 APPLI의 이름과 WEBSER의 이름을 보낸다. 이름을 받으면 UDDI는 호출 그래프를 검사하여 호출될 수 있는 모든 웹서비스를 찾아낸다. 그런 후 UDDI는 EXACML에 다음 정보를 리턴한다.
(a) APPLI의 신용 레벨 숫자들 (b) 호출 될 수 있는 웹서비스들과 그들의 신용 레벨 숫자 (c) 호출된 웹서비스의 리턴 값의 보안 레벨 숫자
WEB: 호출될 수 있는 웹서비스들의 집합
WEBclni: WEB에서 i번쨰 웹서비스의 신용 레벨 숫자
WEBslni: WEB에서 i번째 웹 서비스 리턴값의 보안 레벨 숫자
APPcln: APPLI의 신용 레벨 숫자
ARG: APPLI에 의해 보내진 인수들의 집합
ARGslni: ARG에서 i번째 인수의 보안 레벨 숫자
첫 번째 기본 요구사항
Min(WEBclni) >= Max(ARGslni)
결국 웹서비스의 신용 레벨 숫자가 인수들에 대한 보안 레벨 숫자보다 커야한다.
호출당하는 입장에서 호출하는 쪽의 신용도가 당연히 자신의 보안레벨보다 높아야할 듯.
두 번째 기본 요구사항
APPcln >= Max(WEBslni)
첫 번쨰 경우와는 반대로 리턴하는 데이터를 받는 입장에서 보안레벨보다 높은 신용레벨을 데이터를 받아들여야 할듯.
위에서 말한것 처럼, 인수들의 보안 레벨은 프로그래머에 의해 지정된다. 더불어, 호출 그래프는 프로그래머들에 의해 등록된 호출 관계에 의해 만들어진다. 그래서, 보안 레벨 숫자와 호출 그래프는 애플리케이션 실행중에 변화될 수 없다. 웹서비스와 애플리케이션의 신용 레벨 숫자는 프로그래머에 의해 제어되지 않는다. 대신, 그들은 자동적으로 애플리케이션과 웹서비스의 동적인 해동에 의해 승격되거나 강등된다.
신용 레벨 숫자 승격 규칙: 만약에 애플리케이션이 웹서비스로부터 리턴된 정보를 누출 시키지 않는다면, 신용 레벨 숫자는 증가할 것이다. 비슷하게 웹서비스가 애플리케이션에서 보내온 인수로부터 받은 정보를 누출하지 않으면 증가한다. +1 시킴
신용 레벨 숫자 강등 규칙: 누출 시키면 강등: << 쉬프트 시켜버림 (흠 누출 여부를 어떻게 판단 할 수 있을까?) 헐 바로 다음에 나온다.
섹션 1에서 언급한것 처럼, 호출을 허락하는 것이 정보 누출이 일어나지 않는다는 것을 보장하지는 않는다. 그래서, 우리는 호출된 웹서비스가 실행되는 동안 정보 흐름을 일으키는 모든 명령들이 안전하다는 것을 보장해야만 한다. EXACML은 웹서비스에서 정보 흐름이 일어날 때 다음 두가지 EXACML 안전 규칙들이 실현되어야만한다.
(a) d_var은 1부터 n사이의 i 변수 집합의 변수들중 하나로 할당된다. (vari)
(b) 이 할당은 객체 메소드 md1에 나타난다.
(c) d_var의 원래 ACL은 {RACLd_var, WACLd_var} 이다.
(d) i번째 변수의 ACL은 {RACLd_vari WACLd_vari}
(e) vari의 DSOURCE는 DSOURCEvari 이다.
d_var 이 VAR 이라고 생각하고 뒤에 나온 내용으로 대신 정리
첫번째 규칙
변수 VAR의 값이 변수들의 집합으로부터 유래될 때, 높은 보안 레벨 변수에 값들이 낮은 보안 레벨 변수로 흘러가는 것을 막기 위하여 들VAR의 보안 레벨은 최소한 변수 집합안의 모든 변수들과 같아야한다.
두번째 규칙
VAR은 변수 집합에 모든 변수의 데이터 소스들을 신뢰해야만 한다. 신뢰할 수 없는 데이터 소스로 부터 일어나는 정보의 망가짐을 막는다.
