KR20060050768A - 액세스 인가 ａｐｉ - Google Patents

Abstract

정책을 설정 및 폐지하기 위한 설비가 제공된다. 설비는 제어 프로세스(controlling process)로부터, 피제어 프로세스(cotrolled process)에 대한 정책을 설정하고자 하는 요구를 수신하고, 제어 프로세스가 피제어 프로세스에 대한 정책을 설정할 특권을 갖는지를 판정한다. 설비는 제어 프로세스가 피제어 프로세스에 대한 정책을 설정할 특권을 갖는다고 판정하면, 설비는 피제어 프로세스에 대한 정책을 설정하고, 이것은 정책이 피제어 프로세스에 적용되어 피제어 프로세스가 하나 이상의 자원에 액세스하기 위한 인가를 갖는지를 판정하게 한다.

액세스 인가, 정책, 액세스 제어 검사, 액세스 제한

Description

액세스 인가 ＡＰＩ{ACCESS AUTHORIZATION API}

도 1은 일반적으로 설비가 실행되는 컴퓨터 시스템의 적어도 일부에 통합되는 선택된 컴포넌트들을 도시하는 블록도.

도 2는 몇몇 실시예에 따라, 설비의 선택된 컴포넌트들을 도시하는 블록도.

도 3은 몇몇 실시예에 따라, 설비가 사용하기에 적합한 예시적인 정책을 도시.

도 4는 몇몇 실시예에 따라, 설비가 거부된 액세스 요구의 심사를 수행하는 방법의 흐름도.

도 5는 몇몇 실시예에 따라, 설비가 본질적으로 위험한 동작의 심사를 수행하는 방법의 흐름도.

도 6은 몇몇 실시예에 따라, 설비가 정책의 정교한-조율을 용이하게 하기 위해 학습을 수행하는 방법의 흐름도.

도 7은 몇몇 실시예에 따라, 설비가 층층의 액세스 제어 검사를 제공하는 방법의 흐름도.

도 8은 몇몇 실시예에 따라, 설비가 어플리케이션 프로그램의 보안 리스크 레벨을 결정하는 방법의 흐름도.

도 9는 일 실시예에 따라, 설비가 예외 검출 시에 더 제한적인 정책을 부과 하는 방법의 흐름도.

도 10은 몇몇 실시예에 따라, 설비가 예외 검출 시에 정책을 부과하는 방법의 흐름도.

도 11은 대상 프로세스에 대한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도.

도 12는 대상 프로세스에 대한 폐지가능한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도.

도 13은 프로세스에 대한 스스로-부과한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도.

도 14는 프로세스에 대한 폐지가능한 스스로-부과한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도.

도 15는 클라이언트-서버 액세스 제어 검사를 수행하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도.

도 16은 몇몇 실시예에 따라, 설비가 어플리케이션 프로그램에 내장된 정책을 추출하는 프로세스를 도시.

도 17은 몇몇 실시예에 따라, 설비가 레가시 어플리케이션 프로그램에 정책을 로드하고 적용하는 방법의 흐름도.

<도면의 주요부분에 대한 부호의 설명>

202 : 인가 모듈

204 : 오퍼레이팅 시스템

206: 정책들

208 : 커널

212a, 212b, 212c : 주체

210 : 가로채기 계층

214 : 예외 검출 모듈

개시된 기술은 컴퓨터 보안에 관한 것으로서, 특히, 컴퓨터 시스템 상의 자원으로의 액세스를 제어하는 것에 관한 것이다.

컴퓨터 및 컴퓨터 네트워크에 대한 의존도가 컴퓨터 및 컴퓨터 네트워크에 대한 공격의 정교성 및 빈도수와 함께 증가함에 따라, 컴퓨터 보안의 주제는 본 기술분야에서 훨씬 더 부각되고 있다. 현재의 컴퓨터 보안 기술은 특히 컴퓨터 시스템의 손상 또는 분열, 및 그 외의 바람직하지 못한 액티비티를 설계한 악성 소프트웨어("멀웨어")(예를 들어, 바이러스, 웜 및 트로이)로부터 어플리케이션 프로그램 및 오퍼레이팅 시스템을 보호하는 데 부적합하다.

기존의 액세스 제어 보안 모델은 일반적으로 사용자의 자격에 의존하여, 컴퓨터 상의 자원으로의 액세스를 인가한다. 이 모델에서, 동일한 자격을 가지고 실행 또는 실시하는 모든 프로세스는 그 프로세스가 사용자에게 이용가능한 자원 전부로의 액세스를 필요로 하든지 필요로 하지 않든지 간에 동일한 액세스 권한을 부 여받는다. 또한, 판독, 기록 등을 수행하기 위해 자원으로의 액세스를 필요로 하는 프로세스는 자원이 액세스될 때 그 요구된 액세스를 지정한다.

예를 들어, 사용자는 사용자 계정을 이용하여 개인용 컴퓨터에 로그온 하고, 그 개인용 컴퓨터에 저장되어 있고 특정 워드 프로세싱 프로그램을 이용하여 생성된 모든 워드 프로세싱 문서에 액세스할 수 있기를 기대한다. 이 기대를 만족시키기 위해, 통상적인 액세스 제어 보안 시스템은 사용자의 문맥에서 실행되는 모든 프로그램에게 상술된 워드 프로세싱 문서 전부에 액세스하도록 허가를 수여한다. 그러나, 실제로 사용자 문맥에서 실행되는 소수의 프로그램만이 워드 프로세싱 문서들 중 임의의 것에 액세스하기를 필요로 하기 때문에, 이것은 과도한 레벨의 허가를 수여하는 것이다.

일반적으로, 멀웨어(malware)는 코드 결함을 이용함으로써 프로세스를 감염시킨다. 멀웨어는 훼손된 프로세스의 내부에서 실행되면, 그 프로세스가 실행되는 사용자 문맥의 액세스 권한을 상속하고 사용자에게 이용가능한 모든 자원으로의 액세스를 획득하는데, 이것은 원래의 프로세스가 필요로 했던 것보다 훨씬 더 클 수 있다.

따라서, 컴퓨터 상의 자원의 보안을 개선하고 강화하는 액세스 인가에 대한 통합된 접근은 상당한 유용성을 가질 것이다.

컴퓨터 시스템 상의 어플리케이션 및 오퍼레이팅 시스템 프로그램에 거스르 는 행위로부터 발생하는 역효과로부터 컴퓨터 시스템을 보호하기 위한 소프트웨어 설비("설비")가 개시된다. 몇몇 실시예에서, 설비는 논리적으로-구동된 액세스 제어 계층을 오퍼레이팅 시스템에 추가한다. 설비는 다양한 보안-민감형 자원 액세스에 대한 인가 질의를 수신하고 정책에 기초하여 자원 액세스를 허용할 것인지 거부할 것인지에 대한 결정을 리턴하는 인가 모듈을 제공할 수 있다. 정책은 예를 들어, 네트워크, 파일 시스템, 어플리케이션 프로그램 등과 같은 자원이 관리 및 보호되는 방법을 결정하는 규칙 및 관습의 집합이다.

인가 모듈은 예를 들어, 사용자 문맥에서 실행되는 어플리케이션 프로그램과 같은 사용자 모드 프로그램에 의해 발행된 자원 액세스 요구에 서비스를 제공하는 다양한 오퍼레이팅 시스템 컴포넌트에 의해 직접 질의될 수 있다. 다르게, 인가 모듈은 그러한 오퍼레이팅 시스템 컴포넌트의 상단에 위치한 "가로채기 계층(interception layer)"에 의해 질의될 수 있다. 가로채기 계층은 자원에 액세스하기 위해 사용자 모드 프로그램이 사용하는 시스템 호출 함수를 가로채고, 그 가로챈 시스템 호출 함수에 "래퍼(wrapper)"를 적용하는 코드이다. 인가 모듈은, 자원 액세스를 시도하는 어플리케이션 프로그램(예를 들어, 어플리케이션 프로세스)의 아이덴티티, 사용자의 아이덴티티, 또는 어플리케이션 프로그램의 아이덴티티와 어플리케이션 프로그램이 대신 실행되는 사용자의 아이덴티티의 조합인 주체의 아이덴티티; 그 주체에 적용하는 정책; 및 그 주체가 수행하기 위해 찾는 자원 및 액션의 아이덴티티에 기초하여 그 액세스 제어 결정(즉, 허용 또는 거부)을 한다.

몇몇 실시예에서, 설비는 어플리케이션 프로그램 프로세스와 같은 프로세스 가 정책(예를 들어, 액세스 제한)을 설정 또는 폐지하는 어플리케이션 프로그램 인터페이스(API)를 제공한다. 여기에서 사용되는 바와 같이, API는 하나 이상의 관련된 함수를 포함한다. 정책은 프로세스 레벨에서 설정될 수도 있고, 스레드 레벨에서 설정될 수 있다. API를 이용하여 액세스 제한이 설정되면, 액세스 제한은 설비에 의해 시행된다. API의 유형으로는 행위-제어기 API(behavior-controller API), 스스로-부과한 API(self-imposed API) 및 클라이언트-서버 API(client-server API)가 있다.

행위-제어기 API는 프로세스가 대상 프로세스에 대해 액세스 제한을 설정하여 대상 프로세스 내의 모든 프로세스 스레드 또는 특정의 지정된 프로세스 스레드에만 영향을 줄 수 있게 한다. 액세스 제한은 폐지가능할 수도 있고 폐지불가능할 수도 있다. 액세스 제한이 폐지가능하면, 액세스 제한은 후속적으로 설비에게 요구함으로써 예를 들어, 설비에 의해 제공된 철폐 제한 API(lift restriction API)를 호출함으로써 철폐 또는 폐지될 수 있다. 액세스 제한을 폐지하고자 하는 요구는 제어 프로세스(controlling process) 즉, 액세스 제한을 설정하는 프로세스에 의해 이루어질 수 있다. 몇몇 실시예에서, 액세스 제한을 폐지하고자 하는 요구는 그 요구를 하는 프로세스가 그렇게 하도록 인가되는 한, 피제어 프로세스(controlled process)와 같은 제어 프로세스 이외의 프로세스, 또는 제어 또는 피제어 프로세스 이외의 프로세스에 의해 이루어질 수 있다. 예를 들어, 인가를 나타내기 위해 또는 폐지하고자 하는 요구의 요구자를 인증하기 위해 폐지하고자 하는 요구와 함께 식별자가 사용될 수 있다. 액세스 제한이 폐지불가능하면, 액세스 제한은 철폐 또는 폐지될 수 없다. 또한, 액세스 제한은 대상 프로세스에 대한 임의의 기존의 정책과 함께 누적될 수도 있고, 대상 프로세스에 대한 현재의 정책에 대용될 수도 있다. 예를 들어, 행위-제어기 API를 이용하여, 부모 또는 제어 프로세스는 자식 또는 피제어 프로세스에 대한 정책을 설정할 수 있다. 그에 이어, 자식 또는 피제어 프로세스가 자원에 액세스하고자 하는 요구를 할 때, 인가 모듈은 그 요구를 허가할지 거부할지를 결정하기 위해 정책을 검사한다.

스스로-부과된 API는 프로세스가 스스로에 대한 액세스 제한을 설정하여 행위-제어기 API를 이용하여 설정되는 액세스 제한과 같이, 모든 프로세스 스레드 또는 특정의 지정된 프로세스 스레드에만 영향을 줄 수 있게 한다. 스스로-부과된 API를 이용하여 설정되는 액세스 제한은 폐지가능할 수도 있고, 폐지불가능할 수도 있다. 액세스 제한이 폐지가능하면, 액세스 제한은 후속적으로 설비에 요구를 함으로써 철폐 또는 폐지될 수 있다. 액세스 제한이 폐지불가능하면, 액세스 제한은 철폐 또는 폐지될 수 없다. 또한, 액세스 제한은 대상 프로세스에 대한 임의의 기존의 정책과 함께 누적될 수도 있고, 대상 프로세스에 대한 현재의 정책에 대용될 수도 있다. 예를 들어, 프로세스는 정책없이 또는 효력 면에서 덜 제한적인 정책을 가지고 시동할 수도 있는데, 이것은 프로세스가 더 적극적인 자원 액세스를 수행할 수 있게 한다. 그에 이어, 시동 후 예를 들어, 네트워크를 통해 듣고 네트워크 트래픽을 수신하는 것과 같은 더 위험한 액티비티를 시작하기 전에, 프로세스는 스스로-부과된 폐지불가능한 API를 이용하여 스스로에 대한 더 제한적인 정책을 설정할 수 있다. 또 다른 예에서, 프로세스는 스스로-부과된 폐지가능한 API를 이용 하여 매크로를 시작하기 전에 스스로에 대한 정책을 설정하여, 그 정책이 매크로가 실행되는 동안 적용되게 할 수 있다. 매크로가 실행을 마치면, 프로세스는 매크로의 실행 전에 설정되었던 정책을 폐지할 수 있다.

클라이언트-서버 API는 프로세스가 논-오퍼레이팅 시스템 액션에 대해 특별 자원 액세스 검사(ad hoc resource access check)를 요구할 수 있게 한다. 예를 들어, 클라이언트 프로세스는 서버 프로세스를 호출하여, 서버 프로세스에 임의의 방법을 수행하거나 특정 데이터에 액세스하는 것과 같은 임의의 액션을 수행하도록 요구할 수 있다. 클라이언트 요구를 수신하는 것에 이어서, 서버 프로세스는 예를 들어, 주체와 같은 클라이언트 프로세스를 가장(impersonating)하고, 클라이언트-서버 API를 이용하여 클라이언트 프로세스가 그 요구된 액션을 수행할 충분한 특권을 갖는지를 검사한다. 그 후, 서버 프로세스는 액세스 제어 검사의 결과에 기초하여 그 요구된 액션을 계속할지를 결정할 수 있다.

설비의 여러 실시예 및 그 장점은 도면의 도 1 내지 17을 참조함으로써 가장 잘 이해된다. 도면의 구성요소들은 축적으로 그릴 필요는 없으며, 대신에 본 발명의 주체를 명확하게 나타내는 것에 중점을 둔다. 도면 전제에 걸쳐, 유사한 번호들은 여러 도면의 유사하고 대응하는 부분에 대해 사용된다.

도 1은 일반적으로 설비가 실행되는 컴퓨터 시스템의 적어도 일부에 통합되는 선택된 컴포넌트들을 도시하는 블록도이다. 이 컴퓨터 시스템(100)은 컴퓨터 프로그램을 실행하기 위한 하나 이상의 중앙 처리 장치(CPU)(102); 사용되는 동안, 프로그램 및 데이터 구조를 비롯한 데이터를 저장하기 위한 컴퓨터 메모리(104); 프로그램 및 데이터를 영구적으로 저장하기 위한 하드 드라이브와 같은 영구 저장 장치(106); 컴퓨터-판독가능 매체에 저장된 프로그램 및 데이터를 판독하기 위한 CD-ROM과 같은 컴퓨터-판독가능 매체 드라이브(108); 및 프로그램 및/또는 데이터 구조를 비롯한 데이터를 교환하기 위해 인터넷 등을 통해 컴퓨터 시스템을 다른 컴퓨터 시스템에 접속시키기 위한 네트워크 접속부(110)를 포함할 수 있다.

설비는 컴퓨터 시스템(100) 또는 다른 장치에 의해 실행되는 프로그램 모듈과 같은 컴퓨터-판독가능 명령어의 일반적 문맥에서 설명될 수 있다. 일반적으로, 프로그램 모듈로는, 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등이 있다. 메모리(104) 및 영구 저장 장치(106)는 설비를 구현하는 명령어들을 포함할 수 있는 컴퓨터-판독가능 매체이다. 메모리(104) 및 영구 저장장치(106)는 설비를 구현하는 명령어들 외에 다양한 다른 컨텐츠를 가질 수 있음을 이해할 것이다.

컴퓨터 시스템(100)은 비디오 모니터 또는 LCD 패널과 같은 프로그램 출력을 디스플레이하기 위한 하나 이상의 디스플레이 장치, 및 키보드, 마이크로폰, 또는 마우스를 비롯한 포인팅 장치와 같은 사용자 입력을 수신하기 위한 하나 이상의 입력 장치를 포함할 수 있음을 이해할 것이다. 상술된 바와 같이 구성된 컴퓨터 시스템(100)은 일반적으로 설비의 동작을 지원하는 데 사용되지만, 설비는 다양한 유형 및 구성의 장치를 이용하여, 다양한 컴포넌트를 가지고 구현될 수 있음을 이해할 것이다.

도 2는 몇몇 실시예에 따라, 설비의 선택된 컴포넌트들을 도시하는 블록도이 다. 도 2에 도시되어 있는 바와 같이, 설비는 컴퓨터 시스템(100) 상에서 실행되기에 적합한 오퍼레이팅 시스템(204)의 필수 컴포넌트로서 구현되는 인가 모듈(202)을 포함한다. 인가 모듈(202)은 일반적으로 네트워크 직면의 어플리케이션, 네트워크 직면의 서비스 및 오퍼레이팅 시스템 컴포넌트, 비신뢰된 컨텐츠를 다루는 어플리케이션, 및 예를 들어, 일반적으로 인터넷을 통해 전달된 코드와 같은 비신뢰된 코드와 같은 위험성 높은 프로세스에 추가된 보호 계층으로서 기능한다. 인가 모듈(202)은 컴퓨터 시스템(100) 상에서 이용가능한 자원의 정책 구동된 액세스 제어를 수행하기 위한 논리를 제공한다.

설비는 또한, 인가 모듈(202)이 그 액세스 제어 결정을 하는 정책(206)을 포함한다. 정책(206)은 자원에 액세스하고자 하는 인가 요구를 허용할지 거부할지를 결정하는 규칙이다. 몇몇 실시예에서, 정책(206)은 오퍼레이팅 시스템(204), 특히, 인가 모듈(202)에 의해 시행되는 런타임[예를 들어, 이진(binary)] 규칙으로 컴파일된다. 몇몇 실시예에서, 정책(206)은 집중화된 정책 저장소의 일부분으로서 구현되며, 이것은 정책(206) 내의 규칙을 포함하여 정책(206)이 예를 들어, 사용자 및/또는 운영자에 의해 중앙집중적으로 폐지되고 중앙집중적으로 설정되게 한다.

인가 모듈(202)은 예를 들어, 주체(212a)와 같은 주체에 의해 발행된 자원 액세스 요구에 서비스를 제공하는 다양한 오퍼레이팅 시스템 커널 컴포넌트(208)에 의해 질의될 수 있다. 인가 모듈(202)은 또한, 자원에 액세스하기 위해 예를 들어, 주체(212b)와 같은 주체에 의해 발행된 시스템 호출 함수를 가로채는 가로채기 계층(210)에 의해 질의될 수도 있다. 가로채기 계층(210)은 가로챈 시스템 호출 함수에 래퍼를 적용하여, 인가 모듈(202)이 적용가능한 정책(206)에 대해 액세스 제어 검사를 수행할 수 있게 한다. 예를 들어, 래퍼를 적용하는 것은 컴퓨팅 시스템(100)에 관련된 주체의 아이덴티티 및/또는 다양한 환경적 요인을 결정하는 것, 및 인가 모듈이 액세스 제어 검사를 수행할 수 있게 하기 위해 시스템 호출을 수행하기 위한 인가 모듈(202)로의 인가 요구의 일부분으로서 이 정보를 제공하는 것을 포함할 수 있다. 또한, 인가 모듈(202)은 예를 들어, 주체(212c)와 같은 주체에 의해 직접 질의될 수 있다.

몇몇 실시예에서, 인가 모듈(202)에 의해 수행된 액세스 제어 검사는 자원 액세스 요구를 하는 주체, 및 그 주체에 적용하는 정책의 펑션(function)이다. 그러하듯이, 인가 모듈(202)은 주체의 아이덴티티(호출하는 어플리케이션 프로그램의 아이덴티티, 또는 호출하는 어플리케이션 프로그램의 아이덴티티와 어플리케이션 프로그램이 대신하여 실행되는 사용자의 아이덴티티의 조합) 및 그 주체에 적용가능한 정책 내의 규칙에 기초하여 자신의 액세스 제어 결정(즉, 허용 또는 거부)을 한다. 몇몇 실시예에서, 인가 모듈(202)은 자신의 액세스 제어 결정을 하는 데에 있어서, 주체의 아이덴티티 및 그 주체에 적용가능한 정책 내의 규칙 외에, 추가적으로 예를 들어, 요구된 액세스 유형, 환경적 요인(어플리케이션 프로그램이 기업 네트워크 내부에서 실행되거나 공중 네트워크에 접속되어 있는 컴퓨터, 컴퓨터의 패치 레벨 등)과 같은 매개변수를 고려할 수 있다.

몇몇 실시예에서, 설비는 도 2에서 파선 또는 "점선"으로 도시되어 있는 선택적인 예외 검출 모듈(214)을 포함할 수 있다. 예외 검출 모듈(214)은 일반적으 로 예외적 상태를 검출하기 위해 컴퓨터 시스템(100) 상에서 실행되는 컴퓨터 시스템(100) 및 프로그램의 행위를 모니터링하는 기능을 한다. 몇몇 실시예에서, 예외 검출 모듈(214)은 설비에 예외를 검출할 때의 제1 통지, 및 이전에 검출된 예외의 중단을 검출할 때의 후속적인 제2 통지를 제공한다. 이것은 예외가 종료될 때까지 설비가 예외의 검출 시에 정책(206)의 시행을 활성화할 수 있게 하는데, 그 후에 정책(206)은 더 이상 시행되지 않는다. 다르게는, 설비는 초기에, 예외가 검출될 때까지 덜 제한적인 정책 집합을 부과할 수 있는데, 예외가 검출되는 경우에, 예외가 종료되고 덜 제한적인 정책 집합이 다시 시행될 때까지 더 제한적인 정책 집합이 시행된다. 예외 검출 모듈(214)은 컴퓨터 시스템(100) 상에서 실행되는 단일 프로세스, 컴퓨터 시스템(100) 상에서 실행되는 프로세스 그룹, 또는 전체 컴퓨터 시스템(100)에서 예외를 검출할 수 있다.

설비의 상술된 양태는 예시적인 것일 뿐이며 도시된 컴포넌트들의 구현 및/또는 설비의 용도 또는 기능의 범주에 관하여 어떤 제한을 제시하려는 것이 아니다. 예를 들어, 몇몇 실시예에서, 인가 모듈(202)은 오퍼레이팅 시스템(204)의 일부분 또는 필수부분으로서 구현될 필요는 없지만, 예를 들어, 논-오퍼레이팅 시스템 프로그램으로서 오퍼레이팅 시스템(204)과 분리되어 또는 그 외부에 구현될 수 있다. 또한, 몇몇 실시예에서, 정책(206)은 집중화된 정책 저장소의 일부분으로서 구현될 필요는 없다. 따라서, 정책(206)은 한 곳에 있을 필요가 없고, 예를 들어, 분산 모델을 이용하여 구현될 수 있다. 또한, 정책(206)은 인가 모듈(202)의 일부분으로서 또는 그에 포함되는 것으로서 도시되어 있지만, 정책(206)은 인가 모듈 (202)에 의해 액세스될 수 있기만 하면 된다.

다음 설명에서, 다양한 설명적인 예와 함께 설비의 실시예가 설명된다. 설비의 실시예는 다양한 양태로 이러한 예에서 크게 벗어나는 환경에서 사용될 수 있음을 이해할 것이다.

도 3은 몇몇 실시예에 따라, 설비가 사용하기에 적합한 예시적인 정책을 도시한다. 예시적인 정책은 웹 서버 어플리케이션을 보호하는 규칙을 포함한다. 예를 들어, 자원을 요구하는 아이템(302)으로 도시된 어플리케이션 프로세스는 그것이 아이템(304)으로 도시된 WebServerX 웹 서버 프로세스인지를 판정하기 위해 검사된다. 인가 모듈(202)은 요구하는 어플리케이션 프로세스가 WebServerX 웹 서버 프로세스임을 판정하면, 인가 모듈(202)은 정책에 포함된 규칙에 기초하여 그 요구된 자원에 대한 인가를 허용하거나 거부한다.

설명된 바와 같이, 예시적인 정책은 WebServerX 프로세스에 수여된 특권 또는 액세스 권한을 포함하고, 디폴트는 특권 또는 액세스 권한이 지정되지 않는 경우, 규칙(306)으로 도시된 바와 같이 요구된 자원에 대한 인가를 거부하는 것이다. 다른 방법으로 설명하면, 요구된 자원이 정책에서 명시적으로 허가되지 않으면, 요구된 자원에 대한 인가는 거부된다. 몇몇 실시예에서, 정책은 액세스 제한을 지정하는 규칙, 예를 들어, 특정 액션을 수행하도록 하는 인가가 거부되거나 자원에 액세스하도록 하는 인가를 거부하는 것으로 지정하는 규칙, 또는 심사를 야기하는 예를 들어, 이벤트를 로그하는 규칙을 포함할 수 있다.

예시적인 정책 내의 제1 규칙은 WebServerX 프로세스가 아이템(308)으로 도 시된 "$html" 파일을 아이템(310)으로 도시된 "$WebDirectories"에 기록하게 하도록 하는 지시이다. "$html"은 예를 들어, *.html, *.gif 등의 파일 유형 집합에 대한 표시이다. "$WebDirectories"는 웹 디렉토리가 되도록 구성된 디렉토리 집합에 대한 표시이며, 보안 운영자와 같은 정책의 생성자와는 다른 웹 운영자와 같은 운영자에 의해 정의될 수 있다. 예를 들어, 인가 모듈(202)은 매개변수 "$html"에 의해 정의된 유형의 파일을 매개변수 "$WebDirectories"에 의해 정의된 디렉토리들 중 하나에 기록하기를 요구하는 WebServerX 프로세스에 대한 응답으로, 이 규칙에 기초하여 허용 결정(즉, 인가의 수여)을 리턴한다. 따라서, 정책 내의 규칙은 "$WebDirectories"와 같은 독립적으로 정의된 동적인 오브젝트 그룹, 및 "$html"과 같은 동적으로 구성가능한 환경 매개변수에 적용될 수 있다.

예시적인 정책 내의 제2 규칙은 WebServerX 프로세스가 아이템(314)으로 도시된 "user A"를 대신하여 실행되는 경우 아이템(312)으로 도시된 "$FTP Upload Directory"에 기록하게 하도록 하는 지시이다. 예를 들어, 인가 모듈(202)은 "$FTP Upload Directory"에 기록하기를 요구하는 사용자 A를 대신하여 실행되는 WebServerX 프로세스에 대한 응답으로, 이 규칙에 기초하여 허용 결정(즉, 인가의 수여)을 리턴한다.

예시적인 정책 내의 제3 규칙은 아이템(316)으로 도시된 inbound http traffic을 허용하도록 하는 지시이다. 예를 들어, 인가 모듈(202)은 예를 들어, 네트워크 접속을 통해 전송된 http 데이터 패킷과 같은 인바운드 http 데이터를 수신하기를 요구하는 WebServerX 프로세스에 대한 응답으로, 이 규칙에 기초하여 허 용 결정(즉, 인가의 수여)을 리턴한다.

예시적인 정책 내의 제4 규칙은 아이템(320)으로 도시된 변수 "$FTP"가 인에이블(enable)한 경우 아이템(318)으로 도시된 "FTP traffic"을 허용하도록 하는 지시이다. 여기에서, "$FTP"는 변수이며, 정책을 생성한 보안 운영자와는 다른 운영자에 의해 설정될 수 있다. 예를 들어, 인가 모듈(202)은 런-타임 검사를 수행하여, 변수 "$FTP"가 인에이블한지를 판정하고 인에이블한 경우, 매개변수 "FTP traffic"에 의해 정의된 데이터를 송신 또는 수신하기를 요구하는 WebServerX 프로세스에 대한 응답으로, 이 규칙에 기초하여 허용 결정(즉, 인가의 수여)을 리턴한다. 다르게, "$FTP"가 인에이블하지 않으면, 인가 모듈(202)은 아이템(306)으로 도시된 상술된 액세스 요구에 대한 응답으로 거부 결정(즉, 인가의 거부)을 리턴할 것이다.

정책은 상술된 예시적인 특권에 의해 도시된 어플리케이션 프로세스와 같은 오퍼레이팅 시스템 내외의 오브젝트에 대한 특권을 정의하는 규칙을 포함할 수 있음을 이해할 것이다. 정책 내의 규칙은 컴파일되거나 번역된 프로그래밍 언어를 이용하여 코드를 기록하는 것과 유사하게 풍부한 스키마를 이용하여 지정될 수 있다. 예를 들어, 스키마는 규칙에서 예를 들어, "Y인 경우에만 X를 허용"과 같은 조건 및 시간적 조건의 포함, 동적으로 구성가능한 환경 매개변수 및 변수에 대한 의존성, 환경적 요인에 대한 의존성 등을 지원할 수 있다. 또한, 매개변수의 사용은 현재와 미래의 오브젝트 둘 다에 적용하는 규칙의 생성을 용이하게 한다. 예를 들어, 특정 유형의 문서는 매개변수에 의해 표시될 수 있고, 그 매개변수를 이용하 여, 기존의 것인지 나중에 생성된 것인지에 상관없이 그 특정 유형의 문서 전부에 적용하는 제한을 지정하는 규칙이 생성될 수 있다. 몇몇 실시예에서, 정책은 예를 들어, 팝-업 대화상자를 통해, 결정을 위해 특정 결정을 최종 사용자에게 맡기는 것으로 지정할 수 있다.

도 4는 몇몇 실시예에 따라, 설비가 거부된 액세스 요구의 심사를 수행하는 방법(400)의 흐름도를 도시한다. 예를 들어, 사용자(예를 들어, UserABC)는 컴퓨터에 로그온하여 워드 프로세싱 어플리케이션(예를 들어, WPApp)을 시작하고 컴퓨터 상의 디렉토리(예를 들어, YZDir)에 저장된 파일(예를 들어, FileX)을 오픈하기를 요구했을 수 있다. 결과적으로, WPApp는 디렉토리 YZDir에 저장된 자원 FileX에 액세스하고자 하는 요구를 발행한다. 시작 단계에서 시작하면서, 인가 모듈(202)은 단계(402)에서 예를 들어, YZDir에 저장된 FileX에 액세스하기 위한 인가 요구와 같은 인가 질의를 수신한다.

단계(404)에서, 인가 모듈(202)은 YZDir에 저장된 FileX에 액세스하기 위한 인가를 요구하는 주체를 식별한다. 상술된 예에서, 주체는 WPApp일 수도 있고, WPApp와 UserABC의 조합일 수도 있다. 단계(406)에서, 인가 모듈(202)은 예를 들어, 정책(206)과 같은 집중화된 정책 저장소로부터 그 식별된 주체에 적용가능한 정책을 식별하고, 주체의 아이덴티티 및 적용가능한 정책에 기초하여 액세스 제어 검사를 수행한다. 단계(408)에서, 인가 모듈(202)은 단계(406)에서 수행된 액세스 제어 검사의 결과가 액세스 거부인지를 판정한다. 상술된 예를 계속하여, 인가 모듈(202)은 단계(408)에서, 식별된 적용가능한 정책을 분석하여, 정책 내의 규칙 또 는 특권이 YZDir에 저장된 FileX에 액세스하도록 주체를 인가하는지를 결정한다.

인가 모듈(202)은, 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하는 것으로 결정하면, 단계(420)에서, 주체가 요구된 액션을 수행할 것을 인가받음을 나타내는 허용 결정을 리턴하고, 종료 단계로 진행한다. 다르게, 인가 모듈은(202), 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하지 않는 것으로 결정하면, 단계(410)에서, 주체가 요구된 액션을 수행할 것을 인가받지 않는 것을 나타내는 거부 결정을 리턴한다. 단계(412)에서, 인가 모듈(202)은 주체에 에러 스트링을 리턴하여, 주체에게 그 요구된 액션을 수행하기 위한 인가의 결여를 알릴 수 있다.

단계(414)에서, 인가 모듈(202)은 심사가 인에이블한지를 결정하기 위해 검사한다. 적용가능한 정책 또는 규칙에 관련된 플래그 또는 레코드는 심사를 수행할지를 나타낼 수 있다. 심사가 인에이블하지 않는 경우, 인가 모듈(202)은 종료 단계로 진행한다. 다르게, 심사가 인에이블하면, 인가 모듈(202)은 단계(416)에서 심사 로그에 엔트리를 형성한다. 엔트리는 거부된 요구, 실패한 규칙, 주체 및/또는 요구된 자원을 식별할 수 있다.

단계(418)에서, 인가 모듈(202)은 거부된 요구의 심사에 기초하여 하나 이상의 이벤트를 트리거할 수 있다. 예를 들어, 인가 모듈(202)은 예를 들어, 이메일, 음성 메일, 텍스트 메시징 등을 통해, 보안 운영자에게, 비인가된 액션을 수행하려는 주체에 의한 시도의 지시를 제공하고, 비인가된 액션을 수행하려는 주체에 의한 시도에 후속하는 어플리케이션 프로세스를 종료하고, 비인가된 액션을 수행하려는 주체에 의한 시도에 후속하는 더 엄격한 정책 집합을 부과할 수 있다. 이벤트를 트리거하는 것에 후속하여, 인가 모듈(202)은 종료 단계로 진행한다.

본 기술분야에 통상의 지식을 가진 자는 여기에 개시된 이러한 프로세스 및 방법과 그 외의 프로세스 및 방법에 있어서, 프로세스 및 방법에서 수행되는 기능은 다른 순서로 구현될 수 있음을 이해할 것이다. 또한, 개략적인 단계들은 예시적인 것일 뿐이며, 단계들 중 몇몇은 선택적일 수도 있고, 더 적은 단계들로 결합될 수도 있고, 본 발명의 본질에서 빗나가지 않고서 추가적인 단계들로 확장될 수도 있다.

도 5는 몇몇 실시예에 따라, 설비가 본질적으로 위험한 동작의 심사를 수행하는 방법(500)의 흐름도를 도시한다. 예를 들어, 사용자(예를 들어, UserABC)는 컴퓨터에 로그온하여 웹 브라우저 프로그램(예를 들어, WebBrowser)를 시작하고 비신뢰된 웹 사이트(예를 들어, WebSiteY) 상의 웹 페이지(예를 들어, PageX)에 액세스하기를 요구했을 수 있다. 결과적으로, WebBrowser는 WebSiteY로부터 PageX를 검색하고자 하는 요구를 발행한다. 단계들(502 내지 508)은 대체로 방법(400)의 단계들(402 내지 408)과 유사하다.

단계(508)에서, 인가 모듈(202)은, 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하지 않는 것으로 결정하면, 단계(510)에서, 주체가 요구된 액션을 수행할 것을 인가받지 못하는 것을 나타내는 거부 결정을 리턴한다. 상술된 예에서, WebBrowser는 비신뢰된 사이트 WebSiteY에 액세스하기 위한 인가를 가질 수 없다. 단계(512)에서, 인가 모듈(202)은 주체에 에러 스트링을 리턴하여 주 체에게 그 요구된 액션을 수행하기 위한 인가의 결여를 알릴 수 있다. 에러 스트링의 리턴에 후속하여, 인가 모듈은 종료 단계로 진행한다.

다르게, 인가 모듈(202)은, 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하는 것으로 결정하면, 단계(514)에서, 주체가 요구된 액션을 수행할 것을 인가받음을 나타내는 허용 결정을 리턴한다. 단계(516)에서, 인가 모듈(202)은 인가된 액션이 본질적으로 위험한 동작인지를 판정하기 위해 검사한다. 예를 들어, 설비는 본질적으로 위험한 동작의 목록을 유지할 수 있고, 인가 모듈(202)은 인가된 액션이 본질적으로 위험한 동작으로서 나열되는지를 판정하기 위해 이 목록을 검사할 수 있다.

인가된 액션이 본직절으로 위험한 동작인 것으로 밝혀지면, 단계(518)에서, 인가 모듈(202)은 심사 동작을 수행한다. 예를 들어, 인가 모듈(202)은 본질적으로 위험한 동작을 수행하기 위한 인가 요구의 지시의 본질적으로 위험한 동작 심사 로그에 인트리를 형성할 수 있다. 엔트리는 또한, 본질적으로 위험한 동작을 수행하기 위한 인가를 요구한 주체의 지시도 포함할 수 있다. 인가 모듈(202)은 추가적으로, 본질적으로 위험한 동작을 수행하기 위한 인가에 의해 트리거될 수 있는 다른 액션을 수행할 수 있다. 단계(518)에서의 심사 동작의 수행, 또는 단계(516)에서 인가된 액션이 본질적으로 위험한 동작이 아닌 것으로 판정한 것에 후속하여, 인가 모듈(202)은 종료 단계로 진행한다.

몇몇 실시예에서, 인가 모듈(202)은 본질적으로 위험한 동작을 수행하기 위한 인가 요구의 지시의 본질적으로 위험한 동작 심사 로그에 엔트리를 형성할 수 있다. 상술된 예를 계속하여, 비신뢰된 사이트 WebSiteY에 액세스하는 것은 본질적으로 위험한 동작인 것으로 지시될 수 있고, 또한, 적용가능한 정책이 WebSiteY에 액세스하기 위한 WebBrowser 인가를 수여하지 않는다고 가정하면, 인가 모듈(202)은 거부 결정을 리턴하고(단계 510), 본질적으로 위험한 동작을 수행하기 위한 인가 요구, 및 후속적인 인가 거부를 예를 들어, 본질적으로 위험한 동작 심사 로그에 기록한다. 인가 모듈(202)은 또한, 본질적으로 위험한 액티비티를 수행하기 위한 인가를 요구한 주체의 지시도 기록할 수 있다.

도 6은 몇몇 실시예에 따라, 설비가 정책의 정교한-조율을 용이하게 하기 위해 학습을 수행하는 방법(600)의 흐름도를 도시한다. 예를 들어, 사용자(예를 들어, UserABC)는 컴퓨터에 로그온하여 웹 브라우저 프로그램(예를 들어, WebBrowser)을 시작하고 웹 사이트(예를 들어, WebSiteY) 상의 웹 페이지(예를 들어, PageX)에 액세스하기를 요구했을 수 있다. 결과적으로, WebBrowser는 WebSiteY로부터 PageX를 검색하고자 하는 요구를 발행한다. 단계들(602 내지 608)은 대체로 방법(400)의 단계들(402 내지 408)과 유사하다.

단계(608)에서, 인가 모듈(202)은, 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하는 것으로 결정하면, 단계(610)에서, 주체가 요구된 액션을 수행할 것을 인가받음을 나타내는 허용 결정을 리턴하고, 종료 단계로 진행한다. 다르게, 인가 모듈(202)은, 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하지 않는 것으로 결정하면, 단계(612)에서, 정책 내의 규칙에 있어서, 요구된 액션을 수행하기 위한 인가를 거부하는 것을 학습하는 것이 가능한지를 결정하기 위해 검사한다. 상술된 예를 계속하여, WebBrowser에 적용가능한 정책은 인터넷으로의 WebBrowser 액세스 및 WebSiteY를 명확하게 거부하는 규칙을 포함할 수 있지만, 또한, 규칙을 적용하는 것 대신에 규칙을 학습하는 것을 적용하도록 하는 지시를 제공할 수 있다.

인가 모듈(202)은 요구된 액션을 수행하기 위한 인가를 거부하는 규칙에 대한 학습이 인에이블하지 않다고 판정하면, 단계(618)에서, 인가 모듈(202)은 주체가 요구된 액션을 수행하도록 인가되지 않는 것을 나타내는 거부 결정을 리턴한다. 상술된 예에서, 인터넷으로의 WebBrowser 액세스, 및 WebSiteY를 명확하게 거부하는 규칙은 학습을 적용하도록 하는 지시를 갖지 않을 수 있다. 이 예에서, 규칙이 적용되고, WebBrowser는 WebSiteY에 액세스하기 위한 인가를 거부당한다. 단계(620)에서, 인가 모듈(202)은 주체에 에러 스트링을 리턴하여, 주체에게 그 요구된 액션을 수행하기 위한 인가의 결여를 알릴 수 있다. 에러 스트링의 리턴에 후속하여, 인가 모듈은 종료 단계로 진행한다.

다르게, 단계(612)에서, 인가 모듈(202)은 요구된 액션을 수행하기 위한 인가를 거부하는 규칙에 대한 학습이 인에이블하다고 판정하면, 단계(614)에서, 인가 모듈(202)은 실패한 규칙의 표시의 학습 리포트 로그 내의 엔트리를 형성한다. 엔트리는 또한, 실패한 규칙이 된 액션을 수행하기 위한 인가를 요구한 주체의 지시도 포함할 수 있다. 단계(616)에서, 인가 모듈(202)은 요구된 액션을 수행하도록 주체가 인가되는 것을 나타내는 허용 결정을 리턴하고, 종료 단계로 진행한다. 따라서, 적용가능한 규칙을 적용하는 것 대신에, 인가 모듈(202)은 요구된 액션을 수 행하기 위한 인가를 수여하고, 이 이벤트의 지시를 기록한다. 보안 운영자 또는 다른 관심있는 사용자는 학습 리포트 로그의 컨텐츠를 분석하여, 규칙 또는 정책이 너무 제한적인지 아니면 충분히 제한적이지 못한지를 결정하고, 실제로 규칙 또는 정책을 시행 또는 구현하기 전에 그 규칙 또는 정책에 대해 정교한-조율을 행할 수 있다.

몇몇 실시예에서, 인가 모듈(202)은 요구된 액션을 수행하기 위한 인가를 제공한 규칙의 지시의 학습 리포트 로그 내에 엔트리를 형성할 수 있다. 상술된 예를 계속하여, 규칙이 인터넷, 그리고 WebSiteY로의 WebBrowser 액세스를 명확하게 인가하고, 또한, 학습을 적용하도록 하는 지시를 제공한다고 가정하면, 인가 모듈(202)은 허용 결정을 리턴하고(단계 610) 요구된 액션을 수행하기 위한 인가를 제공한 규칙의 지시를 기록한다. 이 정보는 또한, 규칙 또는 정책에 대해 정교한-조율을 하는 데 사용될 수 있다. 예를 들어, 리포트 로그 내의 엔트리로부터 자원에 액세스하기 위한 인가가 너무 쉽게 수여되었다고 결정되면, 규칙 또는 정책은 자원에 액세스하기 위한 인가가 수여되는 인스턴스를 줄이기 위해 조정 또는 변경될 수 있다.

도 7은 몇몇 실시예에 따라, 설비가 층층의 액세스 제어 검사를 제공하는 방법(700)의 흐름도를 도시한다. 이전의 예들 중 하나를 다시 참조하면, 사용자(예를 들어, UserABC)는 컴퓨터에 로그온하여, 워드 프로세싱 어플리케이션(예를 들어, WPApp)을 시작하고 컴퓨터 상의 디렉토리(예를 들어, YZDir) 내에 저장된 파일(예를 들어, FileX)을 오픈하기를 요구했을 수 있다. 결과적으로, WPApp는 디렉토 리 YZDir 내에 저장된 자원 FileX에 액세스하고자 하는 요구를 발행한다. 시작 단계에서 시작하면서, 인가 모듈(202)은 단계(702)에서, 인가 질의 예를 들어, YZDir 내에 저장된 FileX에 액세스하기 위한 인가 요구를 수신한다.

단계(704)에서, 사용자의 컴퓨터 상에서 실행되는 오퍼레이팅 시스템은 통상적인 액세스 제어 검사를 수행한다. 상술된 예를 계속하여, 오퍼레이팅 시스템은 사용자가 YZDir 내의 FileX를 오픈(예를 들어, 판독 액세스)할 특권을 갖는지를 결정하기 위해 검사할 수 있다. 단계(706)에서, 오퍼레이팅 시스템은 그 통상적인 액세스 검사 메커니즘을 이용하여, FileX로의 사용자 액세스를 거부할지를 결정한다.

오퍼레이팅 시스템의 통상적인 액세스 검사 메커니즘이 사용자가 FileX로의 액세스를 거부당해야 한다고 결정하면, 단계(708)에서, 오퍼레이팅 시스템은 거부 결정을 리턴하고 종료 단계로 진행한다. 거부 결정은 사용자가 그 요구된 액션을 수행하도록 예를 들어, FileX를 오픈하도록 인가받지 못한 것을 나타낸다. 다르게, 오퍼레이팅 시스템의 통상적인 액세스 검사 메커니즘이 사용자가 FileX로의 액세스를 거부받지 않아야 한다고 결정하면, 단계(710)에서, 인가 모듈(202)은 YZDir 내에 저장된 FileX에 액세스하기 위한 인가를 요구하는 주체를 식별한다.

단계(712)에서, 인가 모듈(202)은 예를 들어, 정책(206)과 같은 집중화된 정책 저장소로부터, 식별된 주체에 적용가능한 정책을 식별하고, 주체의 아이덴티티 및 적용가능한 정책에 기초하여 액세스 제어 검사를 수행한다. 상술된 예를 계속하여, 인가 모듈(202)은 단계(714)에서, 그 식별된 적용가능한 정책을 분석하여, 정책 내의 규칙 또는 특권이 YZDir 내에 저장된 FileX에 액세스하도록 주체를 인가할지를 결정한다.

인가 모듈(202)은, 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하는 것으로 결정하면, 단계(720)에서, 주체가 요구된 액션을 수행할 것을 인가받음을 나타내는 허용 결정을 리턴하고, 종료 단계로 진행한다. 다르게, 인가 모듈(202)은, 적용가능한 정책이 주체가 그 요구된 액션을 수행할 것을 인가하지 않는 것으로 결정하면, 단계(716)에서, 주체가 요구된 액션을 수행할 것을 인가받지 않는 것을 나타내는 거부 결정을 리턴한다. 단계(718)에서, 인가 모듈(202)은 주체에 에러 스트링을 리턴하고 종료 단계로 진행할 수 있다. 에러 스트링은 주체에 그 요구된 액션을 수행하기 위한 인가의 결여를 알릴 수 있다.

층층의 액세스 검사는 방법(700)에 의해 도시된 것과 반대의 순서로 수행될 수 있음을 이해할 것이다. 예를 들어, 인가 모듈(202)은 우선, 그 액세스 제어 검사를 수행한다. 인가 모듈(202)이 특정 자원 액세스에 대한 인가가 제공되어야 한다고 결정하면, 오퍼레이팅 시스템은 그 통상적인 액세스 제어 메커니즘을 이용하여 그 보안 검사를 수행한다.

도 8은 몇몇 실시예에 따라, 설비가 어플리케이션 프로그램의 보안 리스크 레벨을 결정하는 방법(800)의 흐름도를 도시한다. 특히, 설비는 어플리케이션 프로그램을 위해 설계된 정책의 분석에 기초하여 보안 리스크의 레벨 및/또는 어플리케이션 프로그램의 의도의 평가를 형성한다. 예를 들어, 사용자는 컴퓨터에 로그온하여 컴퓨터 상의 어플리케이션 프로그램을 로드 및/또는 실행하기를 요구했을 수 있다.

시작 단계에서 시작하면서, 사용자의 컴퓨터 상에서 실행되는 오퍼레이팅 시스템은 단계(802)에서 어플리케이션 프로그램을 로드/실행하고자 하는 요구를 수신한다. 단계(804)에서, 오퍼레이팅 시스템은 설비가 어플리케이션 프로그램이 대응하는 정책을 갖는지를 결정하게 한다. 예를 들어, 어플리케이션 프로그램에 적용가능한 정책은 정책들(206)의 일부분으로서 유지될 수 있다. 설비는 어플리케이션 프로그램에 적용가능한 정책이 존재하지 않는다고 결정하면, 설비는 오퍼레이팅 시스템에 적용가능한 정책이 존재하지 않다는 것을 알린다. 단계(806)에서, 오퍼레이팅 시스템은 어플리케이션 프로그램을 로드/실행하고자 하는 요구를 거부하고 에러 상황을 리턴한다. 요구를 거부하는 것에 후속하여, 오퍼레이팅 시스템은 이 요구에 대해 종료 단계로 진행한다.

다르게, 단계(804)에서, 설비는 어플리케이션 프로그램에 적용가능한 정책이 존재한다고 결정하면, 단계(808)에서, 설비는 적용가능한 정책을 분석하여, 어플리케이션 프로그램을 로드/실행하는 것에 관련되거나 그로부터 기인한 잠재적인 보안 리스크의 레벨을 결정한다. 설비는 리스크 레벨의 기초를 정책 내의 규칙에 의해 수여된 인가의 레벨 또는 범위에 둘 수 있다. 예를 들어, 규칙이 어플리케이션 프로그램을 다수의 자원 또는 다수의 본질적인 위험한 자원에 인가하면, 설비는 규칙이 어플리케이션 프로그램을 몇몇의 상대적으로 안전한 자원에만 인가하는 경우보다 더 높은 리스크 레벨을 설정할 수 있다. 설비는 오퍼레이팅 시스템에게 적용가능한 정책이 존재한다는 것을 알리고, 종료 단계로 진행한다.

도 9는 일 실시예에 따라, 설비가 예외 검출 시에 더 제한적인 정책을 부과하는 방법(900)의 흐름도를 도시한다. 예를 들어, 컴퓨터 상에서 실행되는 설비는 2개의 정책 즉, 어플리케이션 프로그램에 적용가능한 PolicyA 및 PolicyB를 가질 수 있다. 또한, PolicyA는 PolicyA가 더 많은 수의 자원에 인가를 수여한다는 점에서 PolicyB보다 덜 제한적일 수 있다.

시작 단계에서 시작하면서, 설비는 단계(902)에서 덜 제한적인 PolicyA를 부과한다. 단계(904)에서, 설비는 컴퓨터 상에서 실행되는 어플리케이션 프로그램의 인스턴스에서 예외적인 상황을 검출할 수 있다. 상술된 예를 계속하여, 어플리케이션 프로그램의 인스턴스는 컴퓨터 상에서 실행될 수 있고, 설비는 그 실행되는 어플리케이션 프로그램 프로세스를 모니터링할 수 있다. 어플리케이션 프로그램 프로세스를 모니터링하는 동안, 설비는 프로세스 내의 예외적인 상황 또는 상태를 검출할 수 있다. 예를 들어, 설비는 이전에, 컴퓨터 상에서 실행된 어플리케이션 프로그램의 이전 인스턴스를 추적함으로써 일반적으로 어플리케이션 프로그램에 의해 발행된 시스템 호출을 나타내는 방향 그래프를 생성하고, 현재의 어플리케이션 프로그램 프로세스에 의해 생성된 시스템 호출과 방향 그래프의 비교로부터 예외적인 상태의 존재를 결정했을 수 있다.

단계(906)에서, 설비는 예외적인 상태의 검출에 대한 응답으로 더 제한적인 PolicyB를 부과하고, 종료 단계로 진행한다. 일 실시예에서, 설비는 예외적인 상태가 검출된 어플리케이션 프로그램 프로세스에 더 제한적인 PolicyB를 부과한다. 다르게, 설비는 어플리케이션 프로그램 예를 들어, 어플리케이션 프로그램의 모든 인스턴스 또는 프로세스에 더 제한적인 PolicyB를 부과할 수 있다. 또한, 검출된 예외, 어플리케이션 프로그램 및/또는 특정 정책에 따라, 설비는 전체 컴퓨터에 더 제한적인 정책 집합을 부과할 수 있다. 예를 들어, 더 제한적인 정책은 컴퓨터 상에서 실행되는 모든 프로세스에 적용된다.

도 10은 몇몇 실시예에 따라, 설비가 예외 검출 시에 정책을 부과하는 방법(1000)의 흐름도를 도시한다. 예를 들어, 컴퓨터 상에서 실행되는 설비는 정책 즉, 웹 어플리케이션 프로그램에 적용가능한 PolicyA를 가질 수 있다. 시작 단계에서 시작하여, 설비는 단계(1002)에서 웹 어플리케이션 프로그램에 정책을 부과하지 않는다. 따라서, PolicyA는 휴지 상태이고, 컴퓨터 상에서 실행되는 웹 어플리케이션 프로그램의 인스턴스에 적용되지 않는다. 단계(1004)에서, 설비는 컴퓨터 상에서 실행되는 웹 어플리케이션 프로그램의 인스턴스에서 예외적인 상태를 검출할 수 있다.

상술된 예를 계속하여, 웹 어플리케이션 프로그램의 인스턴스는 컴퓨터 상에서 실행될 수 있고, 설비는 실행되는 웹 어플리케이션 프로그램 프로세스를 모니터링할 수 있다. 어플리케이션 프로그램 프로세스의 모니터링 동안, 설비는 프로세스 내의 예외적인 상황 또는 상태를 검출할 수 있다. 예를 들어, 설비는 웹 어플리케이션 프로세스에 의해 생성 또는 야기된 네트워크 트래픽을 모니터링하고, 네트워크 트래픽으로부터, 웹 어플리케이션 프로세스 내에 예외적인 상태가 존재한다고 결정할 수 있다. 단계(1006)에서, 설비는 웹 어플리케이션 프로그램 예를 들어, 예외가 검출된 웹 어플리케이션 프로그램 프로세스에 휴지 상태의 정책 즉, PolicyA를 부과하고, 종료 단계로 진행한다. 다르게, 설비는 웹 어플리케이션 프로그램의 모든 인스턴스 또는 프로세스에 PolicyA를 부과할 수 있다. 따라서, 휴지 상태의 정책은 활성화되고 웹 어플리케이션 프로그램에 적용된다.

도 11은 대상 프로세스에 대한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도이다. 예를 들어, 컴퓨터 상에서 실행되는 네트워크 서버 프로세스는 서버 프로세스 대신에 네트워크 패킷을 듣고 수신하도록 구성된 리스너 프로세스(listener process)에 대한 정책을 설정하기를 원할 수 있다. 이 경우에, 서버 프로세스는 제어 프로세스로 간주될 수 있고, 리스너 프로세스는 대상 프로세스 또는 피제어 프로세스로 간주될 수 있다.

도 11에 도시되어 있는 바와 같이, 제어 프로세스(1102)는 피제어 프로세스(1108)에 대한 정책을 설정하고자 하는 요구를 컴퓨터 상에서 실행되는 오퍼레이팅 시스템(1104)에 송신한다(단계 1). 정책은 요구와 함께 송신될 수도 있고, 이전에 송신되었을 수도 있는데, 이전에 송신된 경우, 요구는 정책을 식별하는 식별자를 포함할 수 있다. 요구는 액세스 제어 API(1106)를 통해 생성된다. 액세스 제어 API(1106)는 일반적으로 정책을 설정 및 폐지하기 위해 어플리케이션 개발자에 의해 사용될 수 있는 이용가능한 여러 인터페이스를 노출 및 생성하는 기능을 한다. 일 실시예에서, 액세스 제어 API(1106)는 어플리케이션 프로그램이 정책을 설정 및 폐지하기 위해 오퍼레이팅 시스템(1104)에 액세스하는 호출 협약을 제공한다.

정책을 설정하고자 하는 요구의 수신에 응답하여, 오퍼레이팅 시스템(1104)은 제어 프로세스(1102)가 대상 프로세스에 대한 정책을 설정할 적절한 특권을 소 유하는지를 판정하기 위해 검사한다(단계 2). 예를 들어, 오퍼레이팅 시스템(1104)은 제어 프로세스(1102)가 피제어 프로세스(1108)가 실행될 특권 레벨보다 더 높은 특권 레벨로 실행되기를 요구할 수 있다. 다르게, 오퍼레이팅 시스템(1104)은 단지 프로세스가 자식 프로세스에 대한 정책을 설정하게 할 수 있다. 오퍼레이팅 시스템(1104)은 제어 프로세스(1102)가 적절한 특권을 갖는다고 판정하면, 오퍼레이팅 시스템(1104)은 피제어 프로세스(1108)에 대한 정책을 설정한다. 요구가 정책을 포함하면, 오퍼레이팅 시스템(1104)은 수신된 정책을 예를 들어, 정책들(206)에 저장하고, 정책을 적용하도록 하는 지시를 설정한다. 요구가 정책을 식별하는 식별자를 포함하면, 오퍼레이팅 시스템(1104)은 그 식별자를 사용하여, 예를 들어, 정책들(206)에서 그 정책을 식별, 예를 들어, 그 정책의 위치를 알아내고, 그 정책을 적용하도록 하는 지시를 설정한다. 그와 달리, 오퍼레이팅 시스템(1104)이 제어 프로세스(1102)가 적절한 특권을 갖지 않는다고 판정하면, 오퍼레이팅 시스템(1104)은 피제어 프로세스(1108)에 대한 정책을 설정하지 않는다. 오퍼레이팅 시스템(1104)은 피제어 프로세스(1108)에 대한 정책을 설정하고자 하는 요구의 결과를 제어 프로세스(1102)에 리턴한다(단계 3).

후속적으로, 피제어 프로세스(1108)가 오퍼레이팅 시스템(1104)에 자원에 액세스하고자 하는 요구를 생성할 때(단계 4), 오퍼레이팅 시스템(1104)은 피제어 프로세스(1108)가 자원에 액세스하기 위한 인가를 갖는지를 판정하기 위해 액세스 제어 검사를 수행한다(단계 5). 예를 들어, 오퍼레이팅 시스템(1104)은 인가 모듈(202)을 사용하여, 적용가능한 정책이 있는지를 결정하고, 그 적용가능한 정책 내 의 규칙을 적용하여 피제어 프로세스(1108)가 그 자원에 액세스하기 위한 인가를 갖는지를 판정할 수 있다.

액세스 제어 검사의 결과에 따라, 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구에 서비스를 제공한다. 예를 들어, 오퍼레이팅 시스템(1104)은 적용가능한 정책을 적용함으로써, 피제어 프로세스(1108)가 자원에 액세스하기 위한 인가를 갖는다고 판정하면, 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구를 더 처리하도록 진행한다. 그렇지 않으면, 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구를 더 처리하지 않는다. 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구의 결과를 피제어 프로세스(1108)에 리턴한다(단계 6).

제어 프로세스(1102) 및 오퍼레이팅 시스템(1104)이 상술된 예 및 후속하는 예에서 동일한 컴퓨터 상에서 실행하는 것으로서 설명되고 있지만, 본 기술분야에 숙련된 기술자들은 제어 프로세스(1102)가 오퍼레이팅 시스템(1104)과 동일한 컴퓨터 상에서 실행될 필요가 없다는 것을 이해할 것이기 때문에, 이것은 제한되는 것으로 의도되지 않는다. 예를 들어, 정책을 설정하고자 하는 요구는 통신 네트워크를 통해 송신될 수 있다. 또한, 피제어 프로세스(1108)는 피제어 프로세스(1108)에 대한 정책을 설정하고자 하는 요구 시에 존재할 수도 있고 존재하지 않을 수도 있음을 이해할 것이다.

도 12는 대상 프로세스에 대한 폐지가능한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도이다. 제어 프로세스(1202) 는 액세스 제어 API(1106)를 통해, 피제어 프로세스(1204)에 대한 폐지가능한 정책을 설정하고자 하는 요구를 컴퓨터 상에서 실행되는 오퍼레이팅 시스템(1104)에 송신한다(단계 1). 폐지가능한 정책을 설정하고자 하는 요구를 수신하는 것에 응답하여, 오퍼레이팅 시스템(1104)은 제어 프로세스(1202)가 대상 프로세스에 대한 폐지가능한 정책을 설정할 적절한 특권을 소유하는지를 판정하기 위해 검사한다(단계 2). 오퍼레이팅 시스템(1104)은, 제어 프로세스(1202)가 적절한 특권을 갖는다고 판정하면, 그 정책을 피제어 프로세스(1204)에 적용하도록 하는 지시를 설정한다. 이와 달리, 오퍼레이팅 시스템(1104)은 제어 프로세스(1202)가 적절한 특권을 갖지 않는다고 판정하면, 오퍼레이팅 시스템(1104)은 피제어 프로세스(1204)에 대한 정책을 설정하지 않는다.

오퍼레이팅 시스템(1104)은 피제어 프로세스(1204)에 대한 폐지가능한 정책을 설정하고자 하는 요구의 결과를 제어 프로세스(1202)에 리턴한다(단계 3). 폐지가능한 정책이 성공적으로 설정되었으면, 오퍼레이팅 시스템(1104)은 제어 프로세스(1202)에 예를 들어, "쿠키" 내의 식별자를 리턴한다. 일 실시예에서, 식별자는 폐지가능한 정책을 설정하는 프로세스를 인증하고, 폐지가능한 정책을 식별 및 폐지하는 데 사용된다. 다른 방법으로 설명하면, 식별자는 폐지가능한 정책을 폐지하기 위한 특권 또는 인가와 유사하며, 후속적으로 정책을 폐지하고자 하는 요구와 함께 오퍼레이팅 시스템(1104)에 제출된다. 다른 실시예에서, 쿠키는 또한, 이전에 효력있었던 정책을 식별하는 식별자와 같은 상태 정보를 포함할 수 있다.

후속적으로, 피제어 프로세스(1204)가 오퍼레이팅 시스템(1104)에 자원에 액 세스하고자 하는 요구를 생성할 때(단계 4), 오퍼레이팅 시스템(1104)은 피제어 프로세스(1204)가 자원에 액세스하기 위한 인가를 갖는지를 판정하기 위해 액세스 제어 검사를 수행한다(단계 5). 액세스 제어 검사의 결과에 따라, 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구에 서비스를 제공한다. 예를 들어, 오퍼레이팅 시스템(1104)은 적용가능한 정책을 적용함으로써, 피제어 프로세스(1204)가 자원에 액세스하기 위한 인가를 갖는다고 판정하면, 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구를 더 처리하도록 진행한다. 그렇지 않으면, 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구를 더 처리하지 않는다. 오퍼레이팅 시스템(1104)은 자원에 액세스하고자 하는 요구의 결과를 피제어 프로세스(1204)에 리턴한다(단계 6).

그 후, 제어 프로세스(1202)는 액세스 제어 API(1106)를 통해, 피제어 프로세스(1204)에 대해 이전에 설정된 폐지가능한 정책을 폐지하고자 하는 요구를 오퍼레이팅 시스템(1104)에 송신할 수 있다(단계 7). 다르게, 제어 프로세스(1202)는 피제어 프로세스(1204)에 식별자를 포함하는 쿠키를 송신할 수 있고(단계 8), 피제어 프로세스(1204)는 후속적으로 액세스 제어 API(1106)를 통해, 피제어 프로세스(1204)에 대해 이전에 설정된 폐지가능한 정책을 폐지하고자 하는 요구를 오퍼레이팅 시스템(1104)에 송신할 수 있다(단계 9). 두 경우 모두에서, 쿠키는 폐지가능한 정책을 폐지하고자 하는 요구와 함께 송신된다.

폐지가능한 정책을 폐지하고자 하는 요구를 수신하는 것에 응답하여, 오퍼레이팅 시스템(1104)은 쿠키 내에 포함된 식별자를 사용하여, 지시된 폐지가능한 정 책을 폐지하기 위한 인가를 갖는 프로세스로서 요구자를 인증한다. 오퍼레이팅 시스템(1104)은 또한, 식별자를 사용하여 폐지될 정책을 식별할 수 있다. 요구자{제어 프로세스(1202)(단계 7) 또는 피제어 프로세스(1204)(단계 9)}를 인증하는 것에 후속하여, 오퍼레이팅 시스템(1104)은 현재 피제어 프로세스(1202)에 적용되는 폐지가능한 정책을 폐지한다. 다른 실시예에서, 오퍼레이팅 시스템(1104)은 방금 폐지된 폐지가능한 정책의 적용 전에 피제어 프로세스(1204)에 적용되었던 정책을 적용할 수 있다. 예를 들어, 이전에 효력있었던 정책을 식별하는 식별자는 폐지가능한 정책을 폐지하고자 하는 요구와 함께 송신되었던 '쿠키' 내의 오퍼레이팅 시스템(1104)에 전달될 수 있다. 다르게, 오퍼레이팅 시스템(1104)은 폐지가능한 정책을 적용하기 전에, 예를 들어, 컴퓨터 상의 영구 저장 장치에 상태 정보를 보존했을 수 있다.

도 13은 프로세스에 대한 스스로-부과한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도이다. 예를 들어, 컴퓨터 상의 사용자는 방금 웹 브라우저 어플리케이션 프로그램을 활성화시켰을 수 있다. 초기화 프로세스의 일부분으로서, 웹 브라우저 어플리케이션 프로세스(1302)는 액세스 제어 API(1106)를 통해, 내 정책을 PolicyA로 설정하고자 하는 요구를 컴퓨터 상에서 실행되는 오퍼레이팅 시스템(1104)에 송신한다(단계 1). 응답으로, 오퍼레이팅 시스템(1104)은 프로세스(1302)에 대한 정책을 PolicyA로 설정한다(단계 2). 요구가 PolicyA를 포함하면, 오퍼레이팅 시스템(1104)은 PolicyA를 예를 들어, 정책들(206) 내에 저장하고, PolicyA를 적용하도록 하는 지시를 설정한다. 요구가 PolicyA를 식별하는 식별자를 포함하면, 오퍼레이팅 시스템(1104)은 식별자를 사용하여 예를 들어, 정책들(206) 내의 PolicyA를 식별, 예를 들어, PolicyA의 위치를 알아내고, PolicyA를 적용하도록 하는 지시를 설정한다. 오퍼레이팅 시스템(1104)은 내 정책을 PolicyA로 설정하고자 하는 요구의 결과를 프로세스(1302)에 리턴한다(단계 3).

후속적으로, 프로세스(1302)는 활성중인 PolicyA와 함께 프로세싱을 계속한다(단계 4). 프로세싱은 오퍼레이팅 시스템(1104)과의 상호작용을 포함할 수 있다. 예를 들어, 사용자는 프로세스(1302)를 사용하여 하나 이상의 웹 어플리케이션을 업로드할 수 있다. 웹 어플리케이션을 업로드했다면, 사용자는 프로세스(1302)를 통해 업로드된 웹 어플리케이션의 처리를 요구했을 수 있다. 사용자의 요구에 응답하여, 프로세스(1302)는 액세스 제어 API(1106)를 통해, 내 정책을 PolicyB로 설정하고자 하는 요구를 오퍼레이팅 시스템(1104)에 송신한다(단계 5). 예를 들어, 프로세스(1302)는 업로드되고 사용자 개시된 웹 어플리케이션의 무결성(integrity)을 신뢰하지 않고서, 정책을 더 엄격한 PolicyB로 설정하기를 요구한다. 응답으로, 오퍼레이팅 시스템(1104)은 프로세스(1302)에 대한 정책을 PolicyB로 설정한다(단계 6). 오퍼레이팅 시스템(1104)은 내 정책을 PolicyB로 설정하고자 하는 요구의 결과를 프로세스(1302)에 리턴한다(단계 7).

정책을 PolicyB로 설정하고자 하는 요구의 리턴된 결과에 따라, 프로세스(1302)는 처리를 계속한다(단계 8). 예를 들어, 정책을 PolicyB로 설정하고자 하는 요구가 성공적이었으면, 프로세스(1302)는 요구된 웹 어플리케이션의 실행을 시 작한다. 여기서, 더 엄격한 PolicyB는 웹 어플리케이션 프로세스에 적용된다. 대안적으로, 정책을 PolicyB로 설정하고자 하는 요구가 성공적이지 못하였으면, 프로세스(1302)는 웹 어플리케이션의 실행을 시작하지 않고, 사용자에게 에러 상황 예를 들어, 웹 어플리케이션을 실행하기 못하는 이유를 알릴 수 있다.

몇몇 실시예에서, PolicyB는 웹 어플리케이션 프로세스에 적용되고, PolicyA는 사실상 폐지된다. 이 경우에, PolicyA는 폐지가능한 정책이었을 수 있다. 몇몇 실시예에서, PolicyA와 PolicyB 둘 다는 웹 어플리케이션 프로세스에 적용된다. 여기서, PolicyA는 폐지불가능했을 수 있고, 따라서, PolicyB와 함께 효력있는 것으로 남아있다.

도 14는 프로세스에 대한 폐지가능한 스스로-부과한 정책을 설정하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도이다. 예를 들어, 컴퓨터 상의 사용자는 어플리케이션 프로그램을 실행하고 있을 수 있고, 매크로가 실행될 지점에 왔을 수 있다. 매크로에 의해 수행될 처리를 알고서, 어플리케이션 프로그램(1402)은 액세스 제어 API(1106)를 통해, 내 폐지가능한 정책을 PolicyA로 설정하고자 하는 요구를 컴퓨터 상에서 실행되는 오퍼레이팅 시스템(1104)에 송신한다(단계 1). 예를 들어, PolicyA는 현재 프로세스(1402)에 적용되고 있는 정책보다 더 제한적인 정책일 수 있다.

응답으로, 오퍼레이팅 시스템(1104)은 프로세스(1402)에 대한 정책을 PolicyA로 설정하고(단계 2), 내 폐지가능한 정책을 PolicyA로 설정하고자 하는 요구의 결과를 프로세스(1402)에 리턴한다(단계 3). PolicyA가 성공적으로 설정되었 으면, 오퍼레이팅 시스템(1104)은 또한, 식별자 및/또는 상태 정보 예를 들어, PolicyA 이전에 적용되었던 임의의 이전 정책에 관한 정보를 포함하는 쿠키도 프로세스(1402)에 리턴할 수 있다. 식별자는 폐지가능한 정책을 폐지하기 위한 인가를 갖는 프로세스로서 보유자를 인증하는 데 사용된다.

폐지가능한 정책을 PolicyA로 설정하고자 하는 요구의 리턴된 결과에 따라, 프로세스(1402)는 처리를 계속한다(단계 4). 예를 들어, 폐지가능한 정책을 PolicyA로 설정하고자 하는 요구가 성공적이었으면, 프로세스(1402)는 매크로를 실행하는 단계로 진행한다. 여기서, 더 제한적인 PolicyA가 매크로에 적용된다. 대안적으로, 폐지가능한 정책을 PolicyA로 설정하고자 하는 요구가 성공적이지 못하였다면, 프로세스(1402)는 매크로를 실행하는 단계로 진행할 수 없다.

후속적으로, 예를 들어, 매크로가 실행을 마쳤음을 검출한 후에, 프로세스(1402)는 액세스 제어 API(1106)를 통해, 내 정책 예를 들어, PolicyA를 폐지하고자 하는 요구를 오퍼레이팅 시스템(1104)에 송신한다(단계 5). 프로세스(1402)는 오퍼레이팅 시스템(1104)으로부터 이전에 수신된 '쿠키'를 내 정책을 폐지하고자 하는 요구와 함께 제출한다. 내 정책을 폐지하고자 하는 요구를 수신하는 것에 응답하여, 오퍼레이팅 시스템(1104)은 쿠키 내에 포함된 식별자를 이용하여, 정책을 폐지하기 위한 인가를 갖는 프로세스로서 프로세스(1402)를 인증한다. 프로세스(1402)의 인증에 후속하여, 오퍼레이팅 시스템(1104)은 PolicyA를 폐지하고, 쿠키에서 식별된 정책을 프로세스(1402)에 적용한다(단계 6). 오퍼레이팅 시스템(1104)은 내 정책을 폐지하고자 하는 요구의 결과를 프로세스(1402)에 리턴하고(단 계 7), 프로세스(1402)는 처리를 계속한다(단계 8). 다른 실시예에서, 내 정책 폐지 요구는 현재의 폐지가능한 정책을 폐지하는 것에 후속하여 적용될 정책을 식별할 수 있다.

도 15는 클라이언트-서버 액세스 제어 검사를 수행하기 위해 몇몇 실시예에서 설비가 사용하는 통신 흐름을 도시하는 블록도이다. 예를 들어, 이메일 클라이언트 프로세스(1502)는 이메일 서버 프로세스(1504)를 호출하여 이메일 메시지를 주소매김된 수신지에 송신할 수 있다(단계 1). 클라이언트 프로세스(1502)는 호출의 일부분으로서 자신의 식별자 예를 들어, ClientID를 서버 프로세스(1504)에 송신한다. 응답으로, 주소매김된 수신지에 이메일 메시지를 송신하려고 시도하기 전에, 서버 프로세스(1504)는 클라이언트 프로세스(1504)가 요구된 액션을 수행하기에, 예를 들어, 이 경우에는, 이메일을 주소매김된 수신지에 송신하기에 충분한 특권을 갖는지를 판정하기 위해 검사를 수행한다. 따라서, 서버 프로세스(1504)는 클라이언트 프로세스(1502)의 아이덴티티를 취함(assuming)으로써 클라이언트 프로세스(1502)를 가장한다(단계 2).

클라이언트 프로세스(1502)의 아이덴티티를 취하였으면(assuming), 서버 프로세스(1504)는 액세스 제어 API(1106)를 통해, 액세스 제어 검사를 수행하고자 하는 요구를 오퍼레이팅 시스템(1104)에 송신한다(단계 3). 요구는 클라이언트 프로세스(1502)의 아이덴티티 예를 들어, ClientID, 및 요구된 액션 예를 들어, 이메일 메시지를 주소매김된 수신지에 송신하는 것을 포함한다. 오퍼레이팅 시스템(1104)은 액세스 제어 검사를 수행하고, 서버 프로세스(1504)에게 클라이언트 프로세스 (1502)가 그 요구된 액션을 수행하기 위한 인가를 갖는지에 대한 표시를 송신한다. 몇몇 실시예에서, 오퍼레이팅 시스템(1104)은 정책들(206)에서 적용가능한 정책을 검사하여, 클라이언트 프로세스(1502)가 그 요구된 액션을 수행하기 위한 인가를 갖는지를 판정할 수 있다. 몇몇 실시예에서, 오퍼레이팅 시스템(1104)은 인가 모듈(202)을 사용하여, 클라이언트 프로세스(1502)가 그 요구된 액션을 수행하기 위한 인가를 갖는지를 판정할 수 있다. 액세스 제어 검사의 결과에 따라, 서버 프로세스(1504)는 이메일 메시지의 처리 예를 들어, 이메일 메시지를 주소매김된 수신지에 송신하는 것을 계속할 수도 있고, 이메일 메시지의 처리를 중지하고 클라이언트 프로세스(1502)에 에러 메시지를 송신할 수도 있다. 상술된 예에서, 서버 프로세스(1504)는 오퍼레이팅 시스템(1104)에 액세스 제어 검사를 수행하고자 하는 요구를 송신하였지만, 서버 프로세스(1504)는 액세스 제어 검사를 수행하기 위해 직접 인가 모듈(202)을 폐지했을 수 있다.

도 16은 몇몇 실시예에 따라, 어플리케이션 프로그램에 내장된 정책이 추출되는 프로세스를 도시한다. 이것은 정책이 어플리케이션을 포함하는 소프트웨어 패키지의 일부분으로서 전달되게 하고, 정책은 어플리케이션을 포함하는 임의의 코드가 실행을 시작하기 전에 추출 및 적용된다. 따라서, 이 접근을 이용하여, 코드가 악성 코드에 의해 이용된 결함을 포함하면, 공격 손상은 감소되고/감소되거나 저지될 수 있다.

단계(1602)에서, 정책은 어플리케이션 프로그램의 코드의 일부분으로서 내장된다. 내장된 정책은 어플리케이션 코드로 범위가 정해진다. 몇몇 실시예에서, 코드 내의 정책은 정책의 존재의 내장된 정책을 추출하는 데 적합한 오퍼레이팅 시스템 또는 다른 프로세스를 나타내는 플래그를 실행가능한 코드에 위치시킴으로써 범위가 정해진다. 단계(1604)에서, 어플리케이션 프로그램 코드는 결과로서 생긴 이미지를 보호하기 위해 서명된다. 코드 서명은 서명된 이미지가 디지털 서명의 제공자 예를 들어, 코드의 서명자로부터 온다는 보장을 제공한다. 공용 키 및 개인 키를 이용한 디지털 서명은 일반적으로, 본 기술분야에서 보통의 기술을 가진 자에게 알려져 있어서, 여기에서 더 설명하지 않을 것이다.

후속적으로 단계(1606)에서, 예를 들어, 컴퓨터 상에 어플리케이션 프로그램 이미지를 로드하고자 하는 요구가 생성된다. 단계(1608)에서, 오퍼레이팅 시스템, 또는 오퍼레이팅 시스템의 로더 컴포넌트는 어플리케이션 프로그램 이미지의 무결성을 검사한다. 오퍼레이팅 시스템은 어플리케이션 프로그램 이미지의 무결성이 수용가능하지 못하다고 판정하면(단계 1610), 단계(1618)에서, 오퍼레이팅 시스템은 어플리케이션 프로그램 이미지를 컴퓨터 상에 로드하지 않는다. 오퍼레이팅 시스템은 또한, 에러 상황을 생성하고 에러의 표시를 제공할 수 있다.

다르게, 오퍼레이팅 시스템은 어플리케이션 프로그램 이미지의 무결성이 수용가능하다고 판정하면(단계 1610), 단계(1612)에서, 오퍼레이팅 시스템은 어플리케이션 프로그램 이미지를 컴퓨터 상에 로드한다. 단계(1614)에서, 오퍼레이팅 시스템은 내장된 정책의 존재를 검사하고, 내장된 정책이 검출되면, 어플리케이션 프로그램 이미지로부터 정책을 추출한다. 몇몇 실시예에서, 오퍼레이팅 시스템은 오퍼레이팅 시스템에 의해 제공된 정책 테이블 또는 레포지토리 예를 들어, 정책들 (206) 내에 그 추출된 정책을 저장할 수 있다. 단계(1616)에서, 오퍼레이팅 시스템은 로드된 어플리케이션 프로그램 이미지에 그 추출된 정책을 적용한다.

도 17은 몇몇 실시예에 따라, 설비가 레가시 어플리케이션 프로그램에 정책을 로드하고 적용하는 방법(1700)의 흐름도이다. 예를 들어, 레가시 어플리케이션 프로그램은 컴퓨터 상에 저장될 수 있다. 레가시 어플리케이션 코드 또는 혼란(hassle)을 수정하는 것과 관련된 리스크, 및 잠재적으로 큰 수의 레가시 어플리케이션 프로그램을 삭제(uninstall), 재설치 및 재구성하는 것과 관련된 비용을 초래하지 않고서, 레가시 어플리케이션 프로그램에 정책을 적용하는 것을 기다리면서, 레가시 어플리케이션 프로그램에 대한 정책은 레가시 어플리케이션 프로그램에 독립적인 프로세스에 의해 전달될 수 있다.

시작 단계에서 시작하면서, 레가시 어플리케이션 프로그램을 호스트하는 컴퓨터 상에서 실행되는 오퍼레이팅 시스템은 단계(1702)에서, 프로세스로부터, 레가시 어플리케이션 프로그램에 대한 정책을 로드하고자 하는 요구를 수신한다. 예를 들어, 프로세스는 컴퓨터 상에서 실행되는 업데이트 프로그램의 인스턴스일 수 있다. 또한, 정책에 포함될 수 있는 규칙 외에, 정책은 레가시 어플리케이션 코드의 버전, 레가시 어플리케이션 코드 내에 통합된 패치 레벨 등과 같은 정보에 기초하여 의존적이고 적용가능한 규칙을 더 포함할 수 있다. 단계(1704)에서, 오퍼레이팅 시스템은 프로세스로부터 정책을 수신하고, 레가시 어플리케이션 프로그램에 대한 정책을 로드한다. 오퍼레이팅 시스템은 레가시 어플리케이션 프로그램에 적용가능한 정책을 전달하도록 인가된 것으로서 프로세스를 검증할 수 있다. 오퍼레이 팅 시스템은 또한, 정책을 수신 및 저장하기 전에 프로세스와 정책 둘 다의 무결성을 검증할 수 있다. 몇몇 실시예에서, 오퍼레이팅 시스템은 정책 테이블 또는 레포지토리 내의 정책을 로드하고, 그 정책을 레가시 어플리케이션 프로그램에 관련시킨다. 그 관련은 정책의 메타데이터로 표시될 수 있다.

후속적으로, 단계(1706)에서, 오퍼레이팅 시스템은 레가시 어플리케이션 프로그램을 로드하고자 하는 요구를 수신한다. 단계(1708)에서, 오퍼레이팅 시스템은 레가시 어플리케이션 프로그램에 적용가능한 정책이 있는지를 판정하기 위해 검사한다. 레가시 어플리케이션 프로그램이 적용가능한 정책을 갖지 않으면, 단계(1704)에서, 오퍼레이팅 시스템은 레가시 어플리케이션 프로그램을 로드하지 않는다. 이 경우에, 오퍼레이팅 시스템은 사실상 적용가능한 정책을 갖는 어플리케이션을 로드 및 실행하기만 하도록 구성될 수 있다. 오퍼레이팅 시스템은 레가시 어플리케이션 프로그램을 로드하는 것의 실패를 나타내는 에러를 리턴할 수 있다. 에러의 표시를 제공하는 것에 후속하여, 오퍼레이팅 시스템은 처리를 계속한다.

단계(1708)에서, 오퍼레이팅 시스템은 레가시 어플리케이션 프로그램이 적용가능한 정책을 가진다고 판정하면, 단계(1710)에서, 오퍼레이팅 시스템은 레가시 어플리케이션 프로그램을 로드한다. 단계(1712)에서, 오퍼레이팅 시스템은 그 실행동안 레가시 어플리케이션 프로그램에 정책을 적용하고, 처리를 계속한다.

상술된 것으로부터, 본 발명의 특정 실시예는 여기에서 설명을 목적으로 설명되었지만, 본 발명의 취지 및 범주를 벗어나지 않고서 다양한 변경이 이루어질 수 있음을 이해할 것이다. 따라서, 본 발명은 첨부된 청구범위에서 명확하게 기술 된 구성요소에 따라서만 제한된다.

본 발명은, 컴퓨터 시스템 상의 어플리케이션 및 오퍼레이팅 시스템 프로그램에 거스르는 행위로부터 발생하는 역효과로부터 컴퓨터 시스템을 보호하기 위한 소프트웨어 설비를 제공한다.

Claims (32)

1. 컨텐츠를 포함하는 컴퓨터-판독가능 저장 매체로서,

   상기 컨텐츠는 컴퓨터가

   제1 정책에 스스로-부과된 정책(self-imposed policy)을 설정하고자 하는 제1 요구를 제출하고,

   제1 자원에 액세스하고자 하는 적어도 하나의 요구를 제출하고,

   제2 정책에 스스로-부과된 정책을 설정하고자 하는 제2 요구를 제출하고,

   제2 자원에 액세스하고자 하는 적어도 하나의 요구를 제출하게 하여,

   상기 제1 정책은 상기 제1 자원에 액세스하기 위한 인가를 받았는지를 판정하는 데 사용되고, 상기 제2 정책은 상기 제2 자원에 액세스하기 위한 인가를 받았는지를 판정하는 데 사용되도록 하는 컴퓨터-판독가능 저장 매체.
2. 제1항에 있어서,

   상기 제2 정책은 상기 제1 정책보다 더 제한적인 컴퓨터-판독가능 저장 매체.
3. 제1항에 있어서,

   상기 제2 정책에 스스로-부과된 정책을 설정하고자 하는 제2 요구는 상기 제1 정책을 폐지하는 컴퓨터-판독가능 저장 매체.
4. 제1항에 있어서,

   상기 제2 정책에 스스로-부과된 정책을 설정하고자 하는 제2 요구는 상기 제1 정책을 폐지하지 않는 컴퓨터-판독가능 저장 매체.
5. 제1항에 있어서,

   상기 제2 정책에 스스로-부과된 정책을 설정하고자 하는 제2 요구는 상기 제1 정책을 폐지하지 않아서,

   상기 제1 정책 및 상기 제2 정책이 상기 제2 자원에 액세스하기 위한 인가를 받았는지를 판정하는 데 사용되도록 하는 컴퓨터-판독가능 저장 매체.
6. 컴퓨팅 시스템에서 클라이언트-서버 액세스 제어 검사를 제공하기 위한 방법으로서,

   상기 컴퓨팅 시스템 상에서 실행되는 프로세스의 제어 하에서,

   제1 프로세스로부터 상기 프로세스에 의해 제공된 자원에 대한 요구를 수신하는 단계 - 상기 요구는 식별자를 포함함 - ;

   상기 제1 프로세스를 가장(impersonating)하는 단계;

   상기 제1 프로세스가 상기 자원을 요구하기 위한 인가를 갖는지를 판정하는 단계; 및

   상기 제1 프로세스가 상기 자원을 요구하기 위한 인가를 갖는지를 판정하는 단계에 후속하여, 상기 자원에 대한 요구를 처리하는 단계

   를 포함하는 방법.
7. 제6항에 있어서,

   상기 프로세스는 상기 제1 프로세스의 아이덴티티를 취함(assuming)으로써 상기 제1 프로세스를 가장하는 방법.
8. 제6항에 있어서,

   상기 프로세스는 액세스 제어 검사를 수행하고자 하는 요구를 송신함으로써 상기 제1 프로세스가 상기 자원을 요구하기 위한 인가를 갖는지를 판정하고, 상기 요구는 상기 제1 프로세스로부터 수신된 식별자, 및 상기 요구된 자원의 표시(indication)를 포함하는 방법.
9. 제8항에 있어서,

   상기 액세스 제어 검사를 수행하고자 하는 요구는 오퍼레이팅 시스템에 대해 이루어지는 방법.
10. 제6항에 있어서,

    상기 제1 프로세스가 상기 자원을 요구하기 위한 인가를 갖는지에 대한 판정은 상기 제1 프로세스에 적용가능한 정책의 검사를 포함하는 방법.
11. 자신 상에서 실행되고 있는 피제어 프로세스(controlled process)에 대한 정책을 설정하기 위한 시스템으로서,

    제어 프로세스(controlling process)로부터 상기 피제어 프로세스에 대한 정책을 설정하고자 하는 요구를 수신하는 컴포넌트;

    상기 제어 프로세스가 상기 피제어 프로세스에 대한 정책을 설정할 특권을 갖는지를 판정하는 컴포넌트; 및

    상기 제어 프로세스가 상기 피제어 프로세스에 대한 정책을 설정할 특권을 갖는다고 판정한 것에 응답하여, 상기 피제어 프로세스에 대한 정책을 설정하는 컴포넌트

    를 포함하여,

    상기 피제어 프로세스가 자원에 액세스하기 위한 인가를 갖는지를 판정하기 위해 액세스 제어 검사를 수행할 때, 상기 정책이 상기 피제어 프로세스에 적용되도록 하는 시스템.
12. 제11항에 있어서,

    상기 정책은 폐지가능한 정책이고, 상기 피제어 프로세스에 대한 정책을 설정하는 것에 후속하여, 상기 설정된 정책의 폐지를 요구하는 데 사용하기 위한 식별자를 상기 제어 프로세스에 송신하는 시스템.
13. 제12항에 있어서,

    상기 피제어 프로세스에 대한 정책을 설정하는 것에 후속하여, 상기 정책을 설정하기 전에 효력있었던 이전의 정책의 표시를 상기 제어 프로세스에 송신하는 컴포넌트를 더 포함하는 시스템.
14. 제12항에 있어서,

    상기 피제어 프로세스에 대한 정책을 폐지하고자 하는 요구를 수신하는 컴포넌트;

    상기 피제어 프로세스에 대한 정책을 폐지하고자 하는 요구를 인증하는 컴포넌트; 및

    상기 정책을 폐지하고자 하는 요구를 인증하는 것에 응답하여, 상기 피제어 프로세스에 대한 정책을 폐지하는 컴포넌트

    를 더 포함하는 시스템.
15. 제14항에 있어서,

    상기 요구를 인증하는 것은 상기 식별자가 상기 정책을 폐지하고자 하는 요구의 일부분으로서 수신되는지를 판정하기 위한 검사를 포함하는 시스템.
16. 제14항에 있어서,

    상기 정책을 폐지하고자 하는 요구는 상기 제어 프로세스로부터 수신되는 시 스템.
17. 제14항에 있어서,

    상기 정책을 폐지하고자 하는 요구는 상기 피제어 프로세스로부터 수신되는 시스템.
18. 제14항에 있어서,

    상기 정책을 폐지하고자 하는 요구는 상기 제어 프로세스 또는 상기 피제어 프로세스 이외의 프로세스로부터 수신되는 시스템.
19. 제14항에 있어서,

    상기 정책을 폐지하고자 하는 요구를 인증하는 것에 응답하여, 상기 정책이 바로 폐지되도록 설정하기 전에 효력있었던 상기 피제어 프로세스에 대한 이전 정책을 설정하는 것을 더 포함하는 시스템.
20. 제11항에 있어서,

    상기 피제어 프로세스 및 상기 제어 프로세스는 동일한 프로세스인 시스템.
21. 제11항에 있어서,

    상기 피제어 프로세스는 상기 제어 프로세스의 실행중인 스레드인 시스템.
22. 컨텐츠를 포함하는 컴퓨터-판독가능 저장 매체로서,

    상기 컨텐츠는 컴퓨터가

    어플리케이션 프로그램에 적용가능한 정책을 로드하고자 하는 요구를 수신하고 - 상기 요구는 상기 어플리케이션 프로그램의 인스턴스 외의 상기 컴퓨터 상에서 실행되는 프로세스에 의해 생성됨 -,

    상기 정책을 정책 레포지토리에 저장하고,

    상기 정책을 상기 대응하는 어플리케이션 프로그램에 관련시키도록 하여,

    상기 저장된 정책이 후속적으로, 상기 컴퓨터 상에서 실행되는 상기 어플리케이션 프로그램의 인스턴스에 적용되도록 하는 컴퓨터-판독가능 저장 매체.
23. 제22항에 있어서,

    상기 컴퓨터가

    상기 어플리케이션 프로그램을 상기 컴퓨터 상에 로드하고자 하는 요구를 수신하고,

    상기 어플리케이션 프로그램에 적용가능한 정책이 상기 정책 레포지토리에 존재하는지를 판정하고, 상기 어플리케이션 프로그램에 적용가능한 정책이 존재한다고 판정하는 것에 응답하여,

    상기 어플리케이션 프로그램을 상기 컴퓨터 상에 로드하고,

    상기 적용가능한 정책을 상기 어플리케이션 프로그램에 적용하게 하는

    컨텐츠를 더 포함하는 컴퓨터-판독가능 저장 매체.
24. 제23항에 있어서,

    상기 컴퓨터가

    상기 어플리케이션 프로그램에 적용가능한 정책이 상기 정책 레포지토리에 존재하는지를 판정하고,

    상기 어플리케이션 프로그램에 적용가능한 정책이 존재하지 않다고 판정한 것에 응답하여, 상기 어플리케이션 프로그램을 상기 컴퓨터 상에 로드하지 않게 하는

    컨텐츠를 더 포함하는 컴퓨터-판독가능 저장 매체.
25. 컴퓨팅 시스템에서 내장된 정책을 수신하기 위한 방법으로서,

    어플리케이션 프로그램 이미지를 로드하고자 하는 요구를 수신하는 단계;

    정책이 상기 어플리케이션 프로그램 이미지 내에 내장되어 있는지를 판정하는 단계;

    정책이 상기 어플리케이션 프로그램 이미지 내에 내장되어 있다고 판정한 것에 응답하여,

    상기 어플리케이션 프로그램 이미지로부터 상기 정책을 추출하는 단계;

    상기 어플리케이션 프로그램 이미지를 로드하는 단계; 및

    상기 추출된 정책을 상기 로드된 어플리케이션 프로그램 이미지에 적용하는 단계

    를 포함하는 방법.
26. 제25항에 있어서,

    상기 내장된 정책은 XML을 이용하여 선언되는 방법.
27. 제25항에 있어서,

    상기 내장된 정책은 프로그래밍 언어로 코딩되는 방법.
28. 제25항에 있어서,

    상기 내장된 정책을 추출하고, 상기 어플리케이션 프로그램 이미지를 로드하고, 상기 추출된 정책을 상기 어플리케이션 프로그램 이미지에 적용하기 전에, 상기 어플리케이션 프로그램 이미지의 무결성(integrity)을 검증하는 단계; 및

    상기 어플리케이션 프로그램 이미지의 무결성을 검증한 것에 후속하여, 상기 내장된 정책을 추출하고, 상기 어플리케이션 프로그램 이미지를 로드하고, 상기 추출된 정책을 상기 어플리케이션 프로그램 이미지에 적용하는 단계

    를 더 포함하는 방법.
29. 제25항에 있어서,

    상기 추출된 정책을 정책 레포지토리에 저장하는 단계를 더 포함하는 방법.
30. 한 프로세스로부터 다른 프로세스에 적용가능한 정책을 수신하기 위한 시스템으로서,

    레가시 어플리케이션 프로그램에 적용가능한 정책을 전달하도록 동작가능한 업데이트 프로세스 - 상기 업데이트 프로세스는 상기 레가시 어플리케이션 프로그램의 프로세스가 아님 - ; 및

    상기 레가시 어플리케이션 프로그램에 적용가능한 정책을 수신하도록 동작가능한 정책 로더 컴포넌트 - 상기 정책 로더 컴포넌트는 또한, 상기 수신된 정책을 정책 레포지토리에 저장하고 상기 정책을 상기 레가시 어플리케이션 프로그램에 관련시키도록 동작가능함 -

    를 포함하여,

    상기 저장된 정책이 상기 어플리케이션 프로그램의 인스턴스에 적용되게 하는 시스템.
31. 제30항에 있어서,

    상기 레가시 어플리케이션 프로그램의 이미지를 로드하고자 하는 요구를 수신하도록 동작가능한 어플리케이션 로더 컴포넌트를 더 포함하고, 상기 어플리케이션 로더 컴포넌트는 또한,

    상기 레가시 어플리케이션 프로그램의 이미지에 적용가능한 정책이 상기 정책 레포지토리에 존재하는지를 판정하고, 상기 어플리케이션 프로그램의 이미지에 적용가능한 정책이 존재한다고 판정한 것에 응답하여,

    상기 어플리케이션 프로그램의 이미지를 로드하고,

    상기 정책을 상기 어플리케이션 프로그램의 이미지에 적용하도록 동작가능한 시스템.
32. 제31항에 있어서,

    상기 로더 컴포넌트는 또한, 상기 어플리케이션 프로그램의 이미지에 적용가능한 정책이 존재하지 않는다고 판정한 것에 응답하여, 상기 어플리케이션 프로그램의 이미지를 로드하지 않도록 동작가능한 시스템.

Images