KR20090010871A - ＣＬＤＣ ＯＳＧｉ 환경에서 어플리케이션의 접속 권한을관리하는 방법 및 장치 - Google Patents

Abstract

본 발명은 CLDC OSGi 환경에서 어플리케이션의 접속 권한을 관리하는 방법 및 장치에 관한 것으로, 본 발명에 따른 어플리케이션의 접속 권한 관리 방법은 고유한 스레드 식별자를 갖는 스레드 내에서 어플리케이션을 실행하고, 매핑 테이블로부터 고유한 스레드 식별자를 어플리케이션 식별자와 매핑시킴으로써 어플리케이션을 식별하고, 식별된 어플리케이션이 어떠한 자원 접속 권한을 갖는지 보안 정책을 검사하며, 검사 결과에 따라 어플리케이션이 자원에 접속하는 것을 허가함으로써, 어플리케이션이 프레임워크 내의 자원에 접속하려고 할 때 어플리케이션들이 자원에 악의적으로 접근할 수 없도록 어플리케이션의 접속 권한을 관리할 수 있다.

CLDC, OSGi, 보안, 매핑 테이블, 보안 정책

Description

ＣＬＤＣ ＯＳＧｉ 환경에서 어플리케이션의 접속 권한을 관리하는 방법 및 장치{Method and apparatus for managing access privileges in a CLDC OSGi environment}

본 발명은 동적으로 어플리케이션을 설치할 수 있는 프레임워크(framework)에 관한 것으로, 더욱 상세하게는 CLDC OSGi 환경에서 자원에 대한 어플리케이션의 접속 권한을 관리하는 방법 및 장치에 관한 것이다.

오늘날, 대부분의 단말 장치들 및 임베디드(embedded) 장치들은 미리 내장되거나 다운로드를 통해 설치된 자바 어플리케이션(JAVA application)을 실행하기 위해 자바 프로그래밍 언어 플랫폼(platform)을 구비한다. 그러한 플랫폼들 중 하나가 J2ME(Java 2 Micro Edition)이다. J2ME 아키텍처(architecture)는 특히 이동 전화, 호출기, PDA(personal digital assistant), 스마트 카드(smart card), 셋톱 박스(set-top box) 등과 같이 제한된 자원을 갖는 임베디드 시스템을 목적으로 한다.

그러나, 이러한 장치들의 기능 및 성능이 서로 간에 많은 차이가 있기 때문에 J2ME 플랫폼이 카테고리 간에서 호환되도록 하기 위해, J2ME는 설정(configuration)과 프로파일(profile)이 분리된 형태로 설계되었다. 설정-프로 파일 쌍(pair)은 API(application programming interface)의 최소 셋(set) 또는 디바이스가 지원해야만 하는 API를 정의한다. 이러한 개념의 장점은 정의된 API들 중 어떠한 API를 이용해 어플리케이션을 제작하였더라도 J2ME 플랫폼 상에서 동작할 수 있다는 점이다. 일반적으로, 이러한 셋은 프로그램에 API를 추가하기를 원하는 경우와 같이 필요에 따라 추가적인 옵션 라이브러리(optional libraries)와 함께 확장될 수 있다.

J2ME와 관련된 설정들 중 대표적인 두 가지 설정에는 CLDC(connected limited device configuration) 및 CDC(connected device configuration)가 있다. 이 중, MIDP 및 CLDC로 구성된 플랫폼은 CDC에 비해 상대적으로 성능이 제한된 CPU나 메모리가 한정적인 시스템을 대상으로 하고 있으며, 표준 자바 플랫폼에서 API들과 응용 가상 머신(virtual machine) 기술을 채택하고 있다.

본 발명이 해결하고자 하는 기술적 과제는 가상 머신을 이용해 어플리케이션을 구동하는 실행 환경에서 하나의 어플리케이션만이 한번에 하나의 가상 머신 상에서 실행될 수 있다는 한계를 극복하고, 어플리케이션들이 프레임워크 내의 자원에 악의적으로 접근할 수 있는 문제점을 해결하는 어플리케이션의 접속 권한을 관리하는 방법 및 장치를 제공하는데 있다.

상기 기술적 과제를 달성하기 위해, 어플리케이션의 접속 권한 관리 방법은 고유한 스레드 식별자를 갖는 스레드 내에서 상기 어플리케이션을 실행하는 단계; 매핑 테이블로부터 상기 고유한 스레드 식별자를 어플리케이션 식별자와 매핑시킴으로써 상기 어플리케이션을 식별하는 단계; 상기 식별된 어플리케이션이 어떠한 자원 접속 권한을 갖는지 보안 정책을 검사하는 단계; 및 상기 검사 결과에 따라 상기 어플리케이션이 상기 자원에 접속하는 것을 허가하는 단계를 포함한다.

또한, 본 발명의 실시예들은 상기 기재된 어플리케이션의 접속 권한 관리 방법을 실행시키기 위한 컴퓨터 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공한다.

상기 기술적 과제를 달성하기 위해, 어플리케이션의 접속 권한 관리 장치는 상기 어플리케이션을 실행하기 위해 고유한 스레드 식별자를 갖는 스레드를 생성하는 스레드 생성부; 매핑 테이블로부터 상기 고유한 스레드 식별자를 어플리케이션 식별자와 매핑시킴으로써 상기 어플리케이션을 식별하는 식별부; 및 상기 식별된 어플리케이션이 어떠한 자원 접속 권한을 갖는지 보안 정책을 검사하고, 상기 검사 결과에 따라 상기 어플리케이션이 상기 자원에 접속하는 것을 허가하는 검사부를 포함한다.

본 발명의 다양한 실시예들에 따르면, 어플리케이션이 프레임워크 내의 자원에 접속하려고 할 때, 매핑 테이블을 이용하여 어플리케이션을 식별하고, 식별된 어플리케이션의 보안 정책을 검사함으로써, 어플리케이션들이 자원에 악의적으로 접근할 수 없도록 어플리케이션의 접속 권한을 관리할 수 있다. 또한, 프레임워크를 CLDC OSGi 환경으로 구현할 경우, 다수의 어플리케이션들이 하나의 가상 머신 상에서 실행될 수 있어 메모리 소모가 현저하게 감소한다.

이하에서는 도면을 참조하여 본 발명의 다양한 실시예들을 상세히 설명한다. 실시예들을 설명함에 있어서, 프레임워크(framework)란 가상 머신(virtual machine)을 이용해 어플리케이션(application)을 구동하는 실행 환경을 의미하는 용어로서 사용될 것이다.

도 1a는 CLDC MIDP 플랫폼의 구조를 도시한 도면으로서, 하드웨어(hardware)(110), 가상 머신(120), CLDC(130), MIDP(140) 및 어플리케이션들(150)을 포함한다.

가상 머신(120)은 하드웨어(110) 상에서 플랫폼에 독립적으로 어플리케이션 을 실행시킬 수 있는 소프트웨어(software)를 의미하며, CLDC-MIDP 환경에서 이러한 가상 머신(120)은 KVM(K virtual machine)이 이용될 수 있다. KVM은 CLDC(J2ME의 Core APIs를 포함한다.)(130)와 MIDP(140)가 구동될 수 있도록 하는 플랫폼 독립적인 가상 머신의 일종이다.

도 1a에서는 앞서 설명한 설정-프로파일 쌍으로서 CLDC-MIDP을 예시하고 있다. CLDC(connected limited device configuration)(130)는 가상 머신 및 자바 언어 명세에서 명시된 것과 비교하여 축소된 라이브러리 셋을 정의한다. CLDC(130)는 제한된 자원을 가진 임베디드 장치들(예를 들어, 중-저 성능 이동 전화)을 위해 만들어졌다. 한편, MIDP(mobile information device profile)(140)는 어플리케이션 모델, 유저 인터페이스(예를 들어, 텍스트 박스 및 폼) 및 네트워킹을 포함하는 어플리케이션 프로그래밍을 위한 간단한 모델을 정의한다. 이상과 같은 환경이 준비되면 플랫폼의 최상단에 어플리케이션들(150)이 적재되어 실행된다.

그러나, CLDC-MIDP 플랫폼은 강력하고 여유있는 자원이 없고, 지원되는 API문헌 및 응용 가상 머신 기술에 있어서 표준 자바 플랫폼과 동떨어져 있다는 문제점이 발견되었다. 또한, 이전까지의 자바 프레임워크에서는 오직 하나의 자바 어플리케이션만이 한번에 하나의 가상 머신 상에서 실행될 수 있었다. 따라서, 다수의 어플리케이션들을 실행하기 위해서는 다수의 가상 머신들을 하드웨어 상에서 구동해야 하는 비효율이 발생하였다.

이상에서 언급된 MIDP-CLDC 조합의 단점에 대해 제안된 해결 방법 중 하나가 MIDP-CLDC로 구성된 플랫폼보다 더 고성능의 어플리케이션 프레임워크를 포함하는 OSGi(open service gateway initiative)이다. 이하에서 도 1b를 참조하여 설명한다.

도 1b는 CLDC OSGi 프레임워크의 구조를 도시한 도면으로서, 예시된 프레임워크는 도 1a와 유사한 구조를 가지나 MIDP 대신 OSGi(160) 기술을 채택하고 있다. OSGi는 운영체제(operating system)나 서비스 플랫폼에 독립적으로 운영되는 일종의 미들웨어 프레임워크로서, 자바를 이용하여 동적으로 어플리케이션의 설치 및 삭제가 가능한 시스템 환경을 말한다. 기술적으로 OSGi는 일반적이고, 서비스 중심적인 프레임워크를 기술하고 있는 실행 환경이며, 잠재적으로 다른 공급자들로부터의 서비스 구현이 추가된 다수의 값을 전달할 수 있는 서비스 인터페이스의 핵심 셋이다.

다시 말해, OSGi는 확장된 배치 및 다른 공급자들로부터 다운로드 가능한 번들(bundle)이라고 알려진 서비스 어플리케이션을 지원하는 범용-목적의 안전하고 관리된 자바 프레임워크를 제공한다. OSGi는 자바 클래스(class) 파일을 포함하는 jar 파일 형태의 물리적 묶음인 번들(bundle)을 설치함으로써 서비스를 제공하는데, 번들은 서비스의 배포 및 관리의 기본 단위를 형성한다. 따라서, OSGi 호환(compliant) 장치들은 OSGi 번들을 다운로드하고, 설치하며, OSGi 번들이 장치 내에서 더 이상 필요 없을 때 OSGi 번들을 제거할 수 있다. 번들은 OSGi의 제어 하에서 다른 번들과 공유하는 서비스들을 등록할 수 있는데, OSGi는 서비스 레지스트리(service registry)를 가지고 있어 서비스에 대한 등록, 조회, 실행 및 삭제를 수행한다.

OSGi(160)는 CLDC 및 FP(foundation profile)의 최상위에서 실행될 수 있다. 더 나아가, OSGi에서 다수의 번들이 동시에 하나의 가상 머신 상에서 실행될 수 있다. 다시 말해, OSGi에서는 자바 어플리케이션들의 숫자만큼 여러 번 가상 머신을 적재하거나 실행할 필요가 없다. 가상 머신이 일단 적재되면, 다수의 번들이 동시에 가상 머신 상에서 실행될 수 있으므로, 메모리 소모가 현저하게 감소한다.

OSGi의 견고함 덕분에 JSR(JAVA specification request) 232는 이동 장치를 위한 기초적인 어플리케이션 프레임워크로서 OSGi를 사용할 것을 제안하였다.

그러나, CLDC 상에서 구현된 OSGi에는 어플리케이션의 보안에 관한 심각한 결점이 존재한다. 이러한 결함은 기본적으로 CLDC가 전체 OSGi 보안 설계가 의존하고 있는 완전한 자바 2 보안에 관해 아무런 근본적인 지원을 제공하지 않는다는 사실에 기인한다. 또한, 기술 문서 내에서는 CLDC-OSGi 환경에서 실행되는 어플리케이션 내의 코드에 접속하는 권한을 관리하는 메커니즘 또는 방법 중 어느 것에 관하여도 아무런 언급을 하고 있지 않다.

따라서, 이하에서 기술될 본 발명의 다양한 실시예들은 CLDC OSGi 환경에서 실행되는 어플리케이션들이 OSGi의 다른 서비스들 또는 어플리케이션들에 악의적으로 접근하는 것을 막는 방법을 제공함으로써 이러한 약점을 극복하려 한다.

도 2는 CLDC OSGi 환경에서 어플리케이션의 자원 접속 권한을 관리할 수 있는 시스템 구조를 설명하기 위한 도면으로서, 도 1b와 유사한 구성을 가진다. 도 2에서는 OSGi(260) 내에 어플리케이션들(251, 252, 253)의 접속 요청을 관리하는 추가적인 구성(265)을 포함한다.

예를 들어, 어플리케이션(251)이 다른 어플리케이션들(252, 253) 또는 OSGi(260) 내의 특정 서비스에 접속하여 이들 자원을 이용하려 할 때 적절한 인증이나 보안 수단이 없다면, 프레임워크는 외부로부터의 악의적인 자원 요청에 무방비 상태로 노출될 수 밖에 없다. 따라서, 본 발명의 다양한 실시예들은 이러한 자원 요청을 관리하고 허가된 요청에 대해서만 접속을 허용하는 접속 권한 관리 수단(265)을 제안한다.

이하의 실시예들에서 프레임워크는 CLDC OSGi 환경을 가정하여 기술되었으나, 본 발명의 실시예들이 속하는 기술 분야에서 통상의 지식을 가진 자는 이하의 실시예들을 구현함에 있어서 이러한 CLDC OSGi 환경 이외에도 이에 상응하는 다양한 실행 환경이 적용될 수 있음을 용이하게 도출할 수 있을 것이다.

도 3a은 본 발명의 일 실시예에 따른 CLDC OSGi 프레임워크의 보안 아키텍처를 예시한 블럭도로서, 프레임워크(300) 및 어플리케이션들(프레임워크(300)에 설치된 번들을 의미한다.)(410, 420, 430)을 포함한다.

프레임워크(300)는 어플리케이션들(410, 420, 430)의 자원 요청에 대한 권한을 관리하는 권한 관리부(310)를 포함하며, 권한 관리부(310)는 다시 스레드 생성부(315) 및 보안 정책(317)을 포함한다.

스레드 생성부(315)는 새롭게 설치된 어플리케이션들(410, 420, 430)을 실행하기 위해 생성되는 스레드들(T1, T2, T3)을 관리한다. 각각의 어플리케이션들(410, 420, 430)은 생성된 스레드들(T1, T2, T3) 상에서 실행된다. 스레드들(T1, T2, T3)은 어플리케이션별로 생성되며, 프레임워크(300)의 특성에 맞 도록 설계된 커스텀 스레드(custom thread)일 수 있다.

이러한 어플리케이션들이 프레임워크(300)의 특정 자원(다른 어플리케이션이나 서비스를 의미한다.)에 접속하려고 한다면, 접속 권한을 가져야 한다. 예를 들어, 도 3a에서 어플리케이션 B1(410)은 접속 권한 셋(415)을 가지므로 해당 자원에 접속하는 것이 허용될 수 있다. 반면에, 어플리케이션 B2(420)나 어플리케이션 B3(430)은 아직 접속 권한 셋을 가지지 못하였으므로 자원에 접속하는 것이 거부될 것이다.

보안 정책(317)은 어플리케이션들(410, 420, 430)마다 어떠한 자원에 접속하여 자원을 이용할 수 있는지 여부를 나타내는 정책을 관리한다. 이러한 보안 정책(317)은 특정 파일(file)이나 데이터베이스(database)에 기록될 수 있다.

도 3b는 도 3a의 보안 아키텍처에서 어플리케이션에 의해 생성된 서브 태스크(sub-task)가 스레드에 매핑되는 것을 예시한 블럭도로서, 어플리케이션 B1(410)으로부터 생성된 서브 태스크 B4(440)를 도시하고 있다.

서브 태스크 B4(440)는 어플리케이션 B1(410)에 의해 생성되었으며, 다른 어플리케이션들과 마찬가지로 스레드 생성부(315)로부터 스레드 T4를 생성하여 할당받는다. 서브 태스크 B4(440)는 이렇게 할당된 스레드 T4 상에서 실행될 수 있다.

한편, 만약 서브 태스크 B4(440)가 실행되는 스레드 T4가 프레임워크(300)의 서비스들 또는 다른 어플리케이션들에 접속하려 한다면, 프레임워크(300)의 표준적인 통신 규격을 이용할 수 없는 예외적인 상황이 발생할 수 있다. 이러한 가능성을 회피하기 위해, 어플리케이션 개발자는 어플리케이션으로부터 생성된 서브 태스크 를 실행하기 위해 J2SE 표준 스레드 API를 대신하는 커스터마이징된(customized) 스레드 API를 제공받을 수 있다.

이상에서 프레임워크에 설치된 어플리케이션을 실행하기 위해 각각의 어플리케이션에 스레드를 할당하는 방법을 설명하였다. 이러한 스레드들은 프레임워크 내에 준비된 보안 정책에 따라 자원 접속에 대한 권한을 검사받는다. 이하에서는 이러한 프레임워크의 자원에 접속하려는 스레드의 권한을 검사하는 보안 아키텍처의 구동 모델을 설명한다.

도 4는 본 발명의 일 실시예에 따른 프레임워크에서 프레임워크의 자원에 접속하려는 어플리케이션의 권한을 관리하는 장치를 도시한 블럭도로서, 도 3a 및 도 3b를 통해 설명한 권한 관리부(310) 이외에 서비스 레지스트리(320)를 더 포함한다. 권한 관리부(310)는 다시 식별부(311), 매핑 테이블(312), 검사부(313), 스레드 생성부(315) 및 보안 정책(317)을 포함한다. 각각을 설명한다.

우선, 서비스 레지스트리(320)는 프레임워크(300)가 제공할 수 있는 서비스를 등록하고, 조회하고, 실행하며, 삭제할 수 있는 관리 수단으로서, 도 4에는 하나의 서비스(325)가 등록되어 있을 것을 예시하고 있다.

스레드 생성부(315)는 앞서 설명한 바와 같이 어플리케이션 B1(410)을 실행하기 위해 스레드 T1을 생성한다. 이러한 스레드 T1은 다른 스레드들과 구별되는 고유의 스레드 식별자를 갖는다. 앞서 설명한 바와 같이 어플리케이션 개발자는 어플리케이션으로부터 생성된 서브 태스크를 실행하기 위해 J2SE 표준 스레드 API를 대신하는 커스터마이징된 스레드 API를 제공받을 수 있다. 이러한 커스터마이징된 스레드 API는 생성된 커스텀 스레드가 매핑 테이블에서 커스텀 스레드를 생성하는 어플리케이션에 매핑될 수 있는 고유한 스레드 식별자를 가질 수 있음을 보장할 것이다.

또한, 제안된 보안 모델은 스레드 식별자 및 어플리케이션 식별자가 프레임워크에 의해 오직 한 번만 할당될 수 있으며, 번들이 파괴되거나 제거될 때까지 바뀌거나 변경될 수 없도록 설계될 수 있다. 이러한 방식을 통해 제안된 보안 모델의 개조성(hackability)은 관리되거나 최소화될 수 있다.

매핑 테이블(312)은 스레드 식별자와 대응하는 어플리케이션의 식별자를 하나의 쌍으로 저장한다. 이러한 매핑 테이블(312)을 통해 어떠한 스레드가 어플리케이션에 할당되어 있는지 여부를 알 수 있다. 도 4에는 스레드 T1가 어플리케이션 B1(410)에 대응함을 나타내는 매핑 테이블(312)이 예시되어 있다.

식별부(311)는 매핑 테이블(312)로부터 고유한 스레드 식별자를 어플리케이션 식별자와 매핑시킴으로써 어플리케이션을 식별한다. 예를 들어, 어플리케이션 B1(410)이 서비스(325)에 접속하려는 요청을 하였을 때, 식별부(311)는 요청을 전달하는 스레드 T1의 스레드 식별자를 이용하여 매핑 테이블(312)을 질의한다. 질의 결과, 스레드 T1에 대응하는 어플리케이션이 어플리케이션 B1(312)임을 식별할 수 있다.

검사부(313)는 식별된 어플리케이션 이 어떠한 자원 접속 권한을 갖는지 보안 정책(317)을 검사하고, 검사 결과 어플리케이션이 자원 접속 권한을 가진다면 자원 접속을 허가하고, 그렇지 않다면 자원 접속을 거부한다. 예를 들어, 어플리케 이션 B1(410)이 검사부(313)를 통해 보안 정책(317)을 질의한 결과, 서비스(325)에 대한 접속 권한을 가진다면, 어플리케이션 B1(410)에 접속 권한 셋(415)이 부여될 것이다. 그 결과, 어플리케이션 B1(410)은 서비스(325)에 접속하는 것이 허가될 것이다.

이상에서, 도 4를 참조하여 프레임워크 내의 자원에 접속하려는 어플리케이션의 접속 권한을 관리하는 장치를 설명하였다. 본 실시예에 따르면, 매핑 테이블을 이용하여 어플리케이션을 식별하고, 식별된 어플리케이션의 보안 정책을 검사함으로써, 어플리케이션들이 프레임워크 내의 자원에 악의적으로 접근할 수 없도록 어플리케이션의 접속 권한을 관리할 수 있다. 또한, 예시된 프레임워크를 CLDC OSGi 환경으로 구현할 경우, 다수의 어플리케이션들이 하나의 가상 머신 상에서 실행될 수 있어 메모리 소모가 현저하게 감소한다.

도 5는 본 발명의 일 실시예에 따른 프레임워크에서 프레임워크의 자원에 접속하려는 어플리케이션의 권한을 관리하는 방법을 도시한 흐름도로서, 다음과 같은 단계들을 포함한다.

510 단계에서 고유한 스레드 식별자를 갖는 스레드 내에서 어플리케이션을 실행한다. 예를 들어, OSGi 어플리케이션이 CLDC OSGi 환경에 설치되었을 때, OSGi 어플리케이션은 스레드 생성부에 의해 생성된 커스텀 스레드 내에서 실행된다. 이러한 커스텀 스레드는 다른 스레드와 구별되는 고유한 스레드 식별자를 갖는다.

520 단계에서 실행된 어플리케이션이 자원 접속을 요청한다. 여기서, 자원이란 프레임워크 내의 어떤 서비스나 다른 어플리케이션을 의미한다.

530 단계에서 매핑 테이블로부터 고유한 스레드 식별자를 어플리케이션 식별자와 매핑시킴으로써 어플리케이션을 식별한다.

540 단계에서 530 단계를 통해 일단 자원을 요청하는 어플리케이션이 식별되면, 어플리케이션이 어떠한 접속 권한을 갖는지 보안 정책을 검사한다. 권한 관리부(도 4의 310), 보다 상세하게는 검사부(도 4의 313)는 접속 요청과 CLDC OSGi 프레임워크 내에 존재하는 보안 정책(도 4의 317)을 비교함으로써 어플리케이션의 접속 권한을 확인한다. 이러한 허가 권한은 미리 설정될 수 있으며, 위치(location) 및 서명자(signer) 등과 같은 요소들에 의존한다. 예를 들어, 프레임워크가 A사의 어플리케이션에 모든 자원 접속 권한을 부여하기로 사전에 합의가 된 경우, 만약 서명자가 A로 되어 있는 어플리케이션이 자원 접속을 요청할 때에 그 요청은 허가될 수 있을 것이다.

550 단계에서 어플리케이션이 자원 접속 권한을 갖는지 여부를 판단한다. 검사 결과, 만약 어플리케이션이 권한을 갖는다면 560 단계로 진행하여 자원 접속을 허용할 것이다. 반면, 어플리케이션이 권한을 갖지 않는다면 570 단계로 진행하여 자원 접속을 거부할 것이다. 또한, 자원 접속을 거부할 경우, 자바 프레임워크 상의 오류 처리 방법인 예외(exception)를 발생(throw)시킬 수도 있을 것이다.

이상에서, 도 5를 참조하여 프레임워크 내의 자원에 접속하려는 어플리케이션의 접속 권한을 관리하는 방법을 설명하였다. 본 실시예에 따르면, 어플리케이션들이 프레임워크 내의 자원에 악의적으로 접근할 수 없도록 어플리케이션의 접속 권한을 관리할 수 있다. 또한, 예시된 프레임워크를 CLDC OSGi 환경으로 구현할 경 우, 다수의 어플리케이션들이 하나의 가상 머신 상에서 실행될 수 있어 메모리 소모가 현저하게 감소한다.

한편, 본 발명은 컴퓨터로 읽을 수 있는 기록 매체에 컴퓨터가 읽을 수 있는 코드로 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록 매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다.

컴퓨터가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현하는 것을 포함한다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인(functional) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술 분야의 프로그래머들에 의하여 용이하게 추론될 수 있다.

이상에서 본 발명에 대하여 그 다양한 실시예들을 중심으로 살펴보았다. 본 발명에 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

도 1a는 CLDC MIDP 플랫폼의 구조를 도시한 도면이다.

도 1b는 CLDC OSGi 프레임워크의 구조를 도시한 도면이다.

도 2는 CLDC OSGi 환경에서 어플리케이션의 자원 접속 권한을 관리할 수 있는 시스템 구조를 설명하기 위한 도면이다.

도 3a은 본 발명의 일 실시예에 따른 CLDC OSGi 프레임워크의 보안 아키텍처를 예시한 블럭도이다.

도 3b는 도 3a의 보안 아키텍처에서 어플리케이션에 의해 생성된 서브 태스크가 스레드에 매핑되는 것을 예시한 블럭도이다.

도 4는 본 발명의 일 실시예에 따른 프레임워크에서 프레임워크의 자원에 접속하려는 어플리케이션의 권한을 관리하는 장치를 도시한 블럭도이다.

도 5는 본 발명의 일 실시예에 따른 프레임워크에서 프레임워크의 자원에 접속하려는 어플리케이션의 권한을 관리하는 방법을 도시한 흐름도이다.

Claims (15)

1. 가상 머신(virtual machine)을 이용해 어플리케이션(application)을 구동하는 실행 환경에서 상기 실행 환경 내의 자원에 접속하려는 어플리케이션의 권한을 관리하는 방법에 있어서,

   고유한 스레드(thread) 식별자를 갖는 스레드 내에서 상기 어플리케이션을 실행하는 단계;

   매핑 테이블(mapping table)로부터 상기 고유한 스레드 식별자를 어플리케이션 식별자와 매핑시킴으로써 상기 어플리케이션을 식별하는 단계;

   상기 식별된 어플리케이션이 어떠한 자원 접속 권한을 갖는지 보안 정책을 검사하는 단계; 및

   상기 검사 결과에 따라 상기 어플리케이션이 상기 자원에 접속하는 것을 허가하는 단계를 포함하는 방법.
2. 제 1 항에 있어서,

   상기 검사 결과, 상기 어플리케이션이 상기 자원에 대한 접속 권한이 없다면 예외(exception)를 발생시키는 단계를 더 포함하는 방법.
3. 제 1 항에 있어서,

   상기 매핑 테이블은 상기 실행 환경 내의 모든 어플리케이션들의 어플리케이 션 식별자들과 상기 모든 어플리케이션들이 실행되는 스레드들이 갖는 고유한 스레드 식별자들을 각각 대응시켜 저장하는 것을 특징으로 하는 방법.
4. 제 1 항에 있어서,

   상기 자원은 상기 실행 환경 내의 서비스들 또는 다른 어플리케이션들 중 적어도 하나인 것을 특징으로 하는 방법.
5. 제 1 항에 있어서,

   상기 보안 정책은 미리 설정되거나, 상기 어플리케이션의 속성에 의존하여 결정되는 것을 특징으로 하는 방법.
6. 제 1 항에 있어서,

   상기 스레드 식별자 및 상기 어플리케이션 식별자는 일단 생성이 되면 상기 어플리케이션이 삭제될 때까지 변경되지 않고 유지되는 것을 특징으로 하는 방법.
7. 제 1 항에 있어서,

   상기 실행 환경은 CLDC(Connected Limited Device Configuration) OSGi(Open Service Gateway Initiative) 환경인 것을 특징으로 하는 방법.
8. 제 1 항 내지 제 7 항 중에 어느 한 항의 방법을 실행시키기 위한 컴퓨터 프 로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
9. 가상 머신을 이용해 어플리케이션을 구동하는 실행 환경에서 상기 실행 환경 내의 자원에 접속하려는 어플리케이션의 권한을 관리하는 장치에 있어서,

   상기 어플리케이션을 실행하기 위해 고유한 스레드 식별자를 갖는 스레드를 생성하는 스레드 생성부;

   매핑 테이블로부터 상기 고유한 스레드 식별자를 어플리케이션 식별자와 매핑시킴으로써 상기 어플리케이션을 식별하는 식별부; 및

   상기 식별된 어플리케이션이 어떠한 자원 접속 권한을 갖는지 보안 정책을 검사하고, 상기 검사 결과에 따라 상기 어플리케이션이 상기 자원에 접속하는 것을 허가하는 검사부를 포함하는 장치.
10. 제 9 항에 있어서,

    상기 검사 결과, 상기 어플리케이션이 상기 자원에 대한 접속 권한이 없다면 예외를 발생시키는 예외 발생부를 더 포함하는 장치.
11. 제 9 항에 있어서,

    상기 매핑 테이블은 상기 실행 환경 내의 모든 어플리케이션들의 어플리케이션 식별자들과 상기 모든 어플리케이션들이 실행되는 스레드들이 갖는 고유한 스레드 식별자들을 각각 대응시켜 저장하는 것을 특징으로 하는 장치.
12. 제 9 항에 있어서,

    상기 자원은 상기 실행 환경 내의 서비스들 또는 다른 어플리케이션들 중 적어도 하나인 것을 특징으로 하는 장치.
13. 제 9 항에 있어서,

    상기 보안 정책은 미리 설정되거나, 상기 어플리케이션의 속성에 의존하여 결정되는 것을 특징으로 하는 장치.
14. 제 9 항에 있어서,

    상기 스레드 식별자 및 상기 어플리케이션 식별자는 일단 생성이 되면 상기 어플리케이션이 삭제될 때까지 변경되지 않고 유지되는 것을 특징으로 하는 장치.
15. 제 9 항에 있어서,

    상기 실행 환경은 CLDC OSGi 환경인 것을 특징으로 하는 장치.

Images