KR102037160B1 - 기대치에 따른 데이터 보안 작동 - Google Patents

Abstract

암호화 서비스는 들어오는 요청을 처리할 때 암호화 키를 관리하고 보안 기대치를 평가할 수 있게 한다. 일부 상황에서, 상기 암호화 서비스는, 암호화 작동을 수행하라는 요청을 수신하면, 보안 기대치들의 세트를 평가하여 상기 암호화 작동을 수행하는데 사용 가능한 암호화 키 또는 키들이 신뢰되어야 하는지 여부를 결정한다. 상기 요청에 대한 응답은 상기 보안 기대치의 평가에 달려 있다.

Description

기대치에 따른 데이터 보안 작동{DATA SECURITY OPERATIONS WITH EXPECTATIONS}

관련 출원에 대한 상호 참조

본 출원은, 발명의 명칭이 "DATA SECURITY OPERATIONS WITH EXPECTATIONS"인 2014년 12월 17일자로 출원된 공동 계류 중인 미국 특허 출원 번호 14/574,337의 우선권을 주장하며, 이 기초 출원은 그 전체 내용이 본 명세서에 병합된다.

컴퓨팅 자원과 관련 데이터의 보안은 많은 상황에서 매우 중요하다. 예를 들어, 조직은 종종 컴퓨팅 장치의 네트워크를 사용하여 사용자들에게 강력한 서비스 세트를 제공한다. 네트워크는 종종 다수의 지리적 경계에 걸쳐 있으며 종종 다른 네트워크와 연결된다. 예를 들어 조직은 컴퓨팅 자원의 내부 네트워크와 다른 사람이 관리하는 컴퓨팅 자원을 모두 사용하여 그 작동을 지원할 수 있다. 예를 들어 조직의 컴퓨터는 다른 조직의 컴퓨터와 통신하며 다른 조직의 서비스를 사용하면서 데이터에 액세스하고 데이터를 제공할 수 있다. 많은 경우 조직은 다른 조직에서 관리하는 하드웨어를 사용하여 원격 네트워크를 구성하고 작동하여, 이에 의해 인프라 비용을 줄이고 다른 장점을 달성할 수 있다. 이러한 컴퓨팅 자원의 구성에 의해 특히 이러한 구성의 크기와 복잡성이 커짐에 따라 조직이 보유하는 자원과 데이터에 액세스하는 것이 안전하다는 것을 보장하는 것이 문제시될 수 있다.

종종, 데이터에 비-허가된 액세스(unauthorized access)를 방지하기 위하여 예를 들어 암호화를 사용할 때 보안 목적의 컴퓨터 네트워크 또는 시스템에서 다수의 소스로부터 암호화 키가 사용될 수 있다. 그러나, 신뢰할 수 없는 알려진 개체(entity)(예를 들어, 해커)로부터 암호화 키를 사용하는 것을 회피하기 위하여 신뢰되는 키를 사용하여 암호화 작동이 수행되고 있는 것을 보장하는 것이 문제시되고 있다.

본 발명에 따른 다양한 실시예가 도면을 참조하여 설명될 것이다:
도 1은 다양한 실시예가 구현될 수 있는 일 환경을 도시한 도면;
도 2는 다양한 실시예가 구현될 수 있는 일 환경을 도시한 도면;
도 3은 일 실시예에 따른 보안 정책을 도시한 도면;
도 4는 일 실시예에 따른 신뢰키 동작(TRUSTKEY action)을 사용하는 예시적인 보안 기대치를 도시한 도면;
도 5는 일 실시예에 따른 암호화 작동을 수행하기 위한 요청을 이행하기 위한 예시적인 공정도;
도 6은 일 실시예에 따른 다수의 보안 정책 및/또는 다수의 보안 기대치 간의 충돌을 해결하기 위한 예시적인 공정도;
도 7은 다양한 실시예가 구현될 수 있는 일 환경을 도시한 도면.

이하의 설명에서, 다양한 실시예가 설명될 것이다. 설명을 위해, 특정 구성 및 상세가 실시예의 완전한 이해를 제공하기 위해 제시된다. 그러나, 실시예들이 특정 상세 없이 실시될 수 있음은 또한 이 기술 분야에 통상의 지식을 가진 자에게 명백할 것이다. 또한, 잘 알려진 특징들은 설명되는 실시예를 모호하게 하지 않게 하기 위해 생략되거나 단순화될 수 있다.

본 명세서에 설명되고 제안된 기술은 예를 들어 암호화된 자원을 복호화 및 검증(validation)할 때와 같이 데이터를 검증하는 것을 수반하는 암호화 작동을 수행할 때 보안 기대치를 사용하는 것을 통해 멀티-테넌트 구성가능한 서비스(multi-tenant configurable service)에서 암호화된 자원의 보안 관리를 포함한다. 일 실시예에서, 멀티-테넌트 API 구성가능한 암호화 서비스는 암호화된 데이터의 복호화 및 디지털 서명 검증과 같은 암호화 작동을 수행하라는 클라이언트로부터의 요청(예를 들어, API 요청, 또한 API 호출이라고도 지칭됨)을 수신하도록 구성된다. "디지털 서명"이란 용어는 RSA 기반 디지털 방식(예를 들어, RSA-PSS), 디지털 서명 알고리즘(digital signature algorithm: DSA) 및 타원 곡선 디지털 서명 알고리즘, ElGamal 서명 방식, Schnorr 서명 방식, Pointcheval-Stern 서명 알고리즘, Rabin 서명 알고리즘, 페어링 기반 디지털 서명 방식(예를 들어, Boneh-Lynn-Schacham 서명 방식), 부인할 수 없는 디지털 서명 방식 및 기타 등을 사용하여 생성된 정보를 포함하는 메시지의 진정성(authenticity)을 암호적으로 검증하는 데 사용할 수 있는 임의의 정보를 포함한다. 또한, 해시 기반 메시지 인증 코드(hash-based message authentication code: HMAC), 키 암호화 해시 함수 및 기타 유형의 정보와 같은 메시지 인증 코드를 디지털 서명으로 사용할 수도 있다.

암호화 서비스는 서비스 및 이 서비스를 통해 액세스 가능한 데이터의 보안 및 무결성을 보장하기 위해 다양한 메커니즘을 사용할 수 있다. 멀티-테넌트 구성가능한 암호화 서비스 내에서 사용될 수 있는 메커니즘은 보안 정책을 사용하는 것이다. 아래에서 보다 상세히 설명되는 바와 같이, 보안 정책(간단히 정책이라고도 지칭됨)은 데이터의 액세스와 관련된 권한(privilege), 및 컴퓨터 시스템이 API 요청 이행과 같은 작동을 수행하게 하는 권한과 같은, 컴퓨터 시스템에서 권한을 한정하는 정보이다. 일부 실시예에서, 암호화 키는 데이터의 보안 통신 및/또는 저장을 보장하는 것과 같은 다양한 목적을 위해 암호화 작동을 수행하기 위해 암호화 서비스에 의해 사용될 수 있다. 예를 들어, 데이터를 암호화하고 복호화하고, 디지털 서명을 생성하고 인증하는 등의 환경에서 암호화 키(문맥으로부터 분명할 때 "키"라고도 지칭됨)를 사용할 수 있다.

일부 실시예에서, 복호 및 서명_검증(DECRYPT 및 VERIFY_SIGNATURE) API 호출을 이행하기 위해 수행되는 작동과 같은 암호화 키를 사용하는 작동은 대응하는 암호화 작동을 수행하기 위해 충족되어야 하는 보안 기대치를 더 지정할 수 있다. 보안 기대치는 요청(예를 들어, 서비스 제공자의 고객이 제출 및/또는 허가할 수 있는 API 호출) 이행의 일부로서 평가되는 조건 또는 조건들의 세트이다. 즉, 보안 기대치는 API 호출이 이행되는 방법을 나타낸다. 보안 기대치는 최소 개수의 보안 보호 비트, 화이트리스트 키들의 세트(예를 들어, 신뢰할 수 있는 암호화 키들의 세트, 이는 서비스 제공자의 다른 고객이 관리하는 암호화 키들의 서브세트를 포함할 수 있음), 블랙리스트 키들의 세트(예를 들어, 신뢰되지 않는 암호화 키들의 세트, 이는 서비스 제공자의 다른 고객이 관리하는 암호화 키들의 서브세트를 포함할 수 있음), 암호화 키가 만료일을 가지는 유효일(validity date), 암호화 키가 신뢰되어야 하는지 여부를 평가하기 위한 임의의 코드 및/또는 이들의 임의의 조합에 적어도 부분적으로 기초한 조건을 포함할 수 있다. 일부 실시예에서, 보안 기대치에 대한 조건은 요청자가 특정 상태(예를 들어, 연방 정보 처리 표준(Federal Information Processing Standards: FIPS) 모드)에 있음을 나타내는 요청 내 정보(예를 들어, 원격 입증을 통한 상태 및/또는 암호적으로 증명)에 대해 평가될 수 있다. 또한, 보안 기대치는, 보안 정책과 같이, (예를 들어, 복호화 키가 신뢰되지 않고 보안 기대치가 복호화 키의 신뢰를 요구할 때 복호화 요청에 응답하여 평문(plaintext)을 제공하지 않는 것에 의해) 요청의 이행을 허용하거나 거부할 수 있으나, 더 복잡한 효과를 구비할 수도 있다. 예를 들어 보안 기대치의 효과에 의해, 검증을 수행하는 데 사용되는 암호화 키의 신뢰성(trustedness)에 따라 디지털 서명 검증 요청이 달라질 수 있다. 다시 말해 보안 기대치는 보안 기대치의 이행에 따라 상이한 결과를 리턴하는 것에 의해 동일한 API 요청이 상이하게 이행되게 할 수 있다.

보안 기대치는 요청의 주된 목적에 부수적일 것일 수 있다. 예를 들어, 암호화 서비스는 디지털 서명을 확인(검증)하라는 요청을 수신할 수 있다. 일부 예(예를 들어, 보안 기대치가 그렇게 요구하지 않는 경우)에서, 디지털 서명을 검증하는데 사용되는 암호화 키의 신뢰와 관련하여 임의의 작동을 수행하지 않고 디지털 서명이 올바른지 여부를 검증함으로써 요청이 이행될 수 있다. 다른 예에서, 보안 기대치는 디지털 서명을 확인하는 요청이 디지털 서명이 올바른 것인지를 검증하지만 또한 디지털 서명을 검증하는 데 사용되는 암호화 키가 (예를 들어, 암호화 키가 신뢰할 수 있는 개체와 관련된 것으로 암호적으로 검증가능하기 때문에 및/또는 암호화 키가 만료되지 않은 디지털 인증서에 지정되어 있기 때문에) 신뢰할 수 있는 것으로 지정된 것인지를 검증할 것을 요구할 수 있다. 또한, 일부 실시예에서, 조건 및/또는 기대치는 논리 연산자(logical operator)와 결합되어 집계 조건(aggregate condition) 및/또는 기대치 값을 형성할 수 있고, 그 결과는 논리 연산자와 함께 집계 조건 및/또는 기대치의 구성 요소에 적어도 부분적으로 기초한다. 집계 조건은 이어서 다수의 레벨의 집계를 포함할 수 있으며, 복합한 다중 레벨의 집계 조건 및/또는 기대치를 형성할 수 있다.

일부 실시예에서, 보안 기대치는, 예를 들어, 암호화 키를 사용하여 작동을 수행하기 위한 요청의 일부로서 제공된 추가적인 정보로서 클라이언트에 의해 제공되거나 그 밖에 지정될 수 있다. 다른 실시예에서, 보안 기대치는 주체(principal)에 의해 사용되는 모든 암호화 키에 보안 기대치 세트가 적용되도록 요청을 하는 주체와 관련될 수 있다. 또 다른 실시예에서, 보안 기대치는 계정(account)과 관련되거나 요청 문맥(request context)으로부터 결정 가능할 수 있다. 이들 실시예는 서로 별개이거나 및/또는 상호 배타적이어야 할 필요는 없다는 것을 알아야 한다. 다시 말해, 일부 예에서 보안 기대치는 요청에 명시적이며 다른 예에서는 요청의 정보를 사용하여 임의의 보안 기대치가 적용되는지 여부, 및 만약 적용된다면, 어떤 보안 기대치가 적용되는지를 결정할 수 있다.

보안 기대치는 클라이언트에 의해 암호화 서비스에 제공되거나, 또는 (예를 들어, 컴퓨팅 자원의 관리를 위한 웹 서비스 API 호출을 통해) 암호화 서비스에 의해 중앙에서 관리될 수 있다. 일부 실시예에서, 보안 기대치는 암호화 서비스에 의해 액세스가능한 중앙에서 관리되는 저장소에 저장되고, 암호화 서비스에 의해 액세스가능한 정책 관리 모듈에 의해 관리된다. 정책 관리 모듈은 암호화 서비스에 의해 액세스가능한 소프트웨어, 하드웨어, 또는 하드웨어와 소프트웨어의 조합일 수 있으며, 일부 실시예에서 컴퓨팅 자원(예를 들어, CPU, 가상 머신 인스턴스) 및 데이터 저장장치를 모두 포함하는 프론트엔드 시스템의 일부일 수 있다. 컴퓨팅 자원은 기대치를 평가하고, 보안 기대치 및/또는 정책 데이터를 검색하고, 보안 기대치의 일부로서 포함될 수 있는 실행 가능 코드를 실행하기 위해 적어도 부분적으로 사용될 수 있다.

또한, 일부 실시예에서, 보안 기대치가 암호화 서비스에 의해 액세스 가능하게 정책 관리 모듈에 의해 중앙에서 관리되는 경우, 사용자(예를 들어, 고객)는 보안 손상(security compromise)에 대한 더 큰 탄력성으로부터 이익을 얻는다. 예를 들어, 특정 암호화 키가 손상된 것으로 발견된 경우, 정책 관리 모듈은 이 키를 블랙리스트에 올릴 수 있다(즉, 모든 보안 기대치 평가를 자동으로 실패시키는 키들의 세트에 손상된 암호화 키를 포함시킬 수 있다). 이와 달리, 보안 기대치가 요청의 일부로서 클라이언트에 의해 암호화 서비스에 제공되는 실시예에서, 포함된 암호화 키를 사용할 수 있는 모든 클라이언트는 손상된 암호화 키를 블랙리스트에 올리기 위해 업데이트될 필요가 있을 수 있다.

일부 실시예에서, 암호화 서비스는 암호화 키가 사용되기 전에 암호화 키가 신뢰되는 것임을 요구하는 요구조건을 프로그램적으로 구성하는 것을 허용할 수 있다. 이런 상황에서 신뢰란 암호화 키가 신뢰되는지 여부에 따라 컴퓨터 시스템이 작동하는 것을 의미한다. 예를 들어, 컴퓨터 시스템은 신뢰된 암호화 키가 암호화 서비스로부터 액세스 가능한 데이터를 암호화하는데 사용될 수 있는 반면, 신뢰된 암호화 키인 것으로 결정되지 않은 암호화 키는 암호화 서비스로부터 액세스 가능한 데이터를 암호화하는데 사용될 수 없도록 구성될 수 있다. 일반적으로 컴퓨터-구현 방법의 출력은 암호화 키가 신뢰되는 것으로 지정되는지 여부에 따라 달라진다.

암호화 키가 클라이언트에 의해 사용되기 전에 암호화 서비스는 암호화 키가 신뢰되는 것임을 요구하는 다양한 장점의 실시예가 존재한다. 이러한 장점은, 예를 들어 디지털 서명이 올바르지만 신뢰된 암호화 키를 사용하여 검증할 수는 없을 때 데이터가 다수의 다른 상태를 가질 수 있는 보다 복잡한 시스템과 달리, 암호화 서비스를 사용하는 컴퓨팅 환경의 데이터는 유효하지 않은 상태 또는 유효한 상태에만 존재한다는 장점을 적어도 포함한다. 유효하지 않은 상태는 암호화된 데이터 또는 디지털 서명이 (예를 들어, 악의적인 상대방(party)에 의해 또는 우연히) 변경된 것으로 검출되어 무결성이 결여된 상태, 또는 데이터가 변경되지 않은 것(즉 무결성을 갖는 것)으로 간주되지만, 신뢰되지 않거나 손상되거나 클라이언트가 상대방을 신뢰하기에는 근거가 부족한 것으로 알려진 것일 수 있는 상대방의 암호화 키를 사용하는 상태를 적어도 포함한다. 본 발명에 따른 암호화 서비스는 예를 들어 데이터가 올바르게 서명되었지만 신뢰되지 않는 디지털 서명을 검증하는데 사용 가능한 암호화 키로 인해 신뢰되지 않는 경우 중간 유효 상태를 부주의하게 사용하는 것을 회피하도록 구성될 수 있다.

일부 실시예에서, 클라이언트는, 디폴트에 의해, 제한된 암호화 키들의 세트를 신뢰한다. 예를 들어, 클라이언트는, 디폴트에 의해, 초기에는 클라이언트 내의 계정들 중 임의의 계정, 클라이언트의 특정 계정, 또는 심지어 클라이언트의 특정 암호화 키로부터 오는 데이터만을 신뢰한다. 설명된 실시예에서, 제3자로부터의 암호화 키(즉, 다른 클라이언트로부터의 암호화 키)는 신뢰되지 않으며, 클라이언트에 의해 암호화 작동을 수행하는데 사용될 수 없다. 애플리케이션 프로그래밍 인터페이스 호출은 클라이언트가 신뢰하는 암호화 키에 따라 암호화 작동을 수행하도록 암호화 서비스를 구성하는 데 사용될 수 있다.

도 1은 다양한 실시예가 구현될 수 있는 일 환경(100)을 도시한다. 환경(100)은 클라이언트(102)가 암호화 서비스(106)에 암호화 작동(104)을 완료하라는 요청을 발행하고 이 요청에 응답(108)하는 것을 도시한다. 예시를 위해, 작동(104)은 클라이언트가 디지털 서명(110)과 보안 기대치(112)를 제공하는 서명_검증(VERIFY_SIGNATURE) 작동이다. 작동을 수행하라는 요청을 이행하기 위해, 암호화 서비스는 진정성 및 진정성을 결정하는데 사용되는 키의 신뢰성을 위해 디지털 서명을 검증할 수 있다. 응답은 예를 들어 디지털 서명이 올바른 것으로 결정되었는지 여부를 지정할 수 있다. 예를 들어, 디지털 서명의 올바름(correctness)을 검증하는 데 사용된 디지털 인증서가 성공적으로 인증되었는지 여부, 디지털 서명을 검증하는 데 사용된 암호화 키가 신뢰되는지 여부, 디지털 인증서가 만료되지 않았는지 여부 및/또는 디지털 서명이 올바른지 여부를 체크하는 것에 더하여 수행되는 임의의 체크로부터 생기는 다른 정보가 수행되는지 여부와 같이 적용가능한 경우 다른 정보가 응답에 포함될 수 있다. 서명_검증(VERIFY_SIGNATURE)은 설명을 위하여 사용되지만 복호화(DECRYPT) 또는 다른 것과 같은 다른 암호화 작동이 사용될 수 있다는 것이 주목된다. 클라이언트(102)는 본 명세서에 설명된 다양한 작동을 수행하도록 (예를 들어, 실행 가능한 코드로) 구성된 컴퓨터 시스템일 수 있다. 클라이언트는 본 명세서에 설명된 바와 같이 작동하도록 구성될 수 있는 클라이언트 애플리케이션, 운영 시스템, 또는 다른 적절한 소프트웨어, 하드웨어 또는 이들의 조합에 따라 작동할 수 있다.

일 실시예에서, 디지털 서명을 검증하기 위한 요청(104)은 디지털 서명이 의도적으로 생성된 메시지를 검증하기 위한 디지털 서명을 적어도 포함하며, 일부 실시예에서, (예를 들어, 식별자에 의해) 서명을 검증하기 위한 암호화 키를 더 포함하거나 지정할 수 있다. 일부 실시예에서, 요청은 암호화 키를 포함하지 않거나 그 밖에 지정하지 않지만, 암호화 키를 선택하기 위해 암호화 서비스가 사용할 수 있는 정보를 포함할 수 있는데 - 예를 들어, 암호화 서비스에 의해 관리되는 다수의 암호화 키로부터의 암호화 키를 선택하기 위해 사용될 수 있는, 요청을 제출하는 개체의 식별자 또는 다른 정보는 암호화 서비스가 암호화 키를 선택할 수 있도록 하기 위해 포함될 수 있다. 예시적인 예로서, 컴퓨팅 자원 서비스 제공자의 고객은 관련된 디폴트 암호화 키를 사용할 수 있다.

키 식별자는 고유 식별자일 수 있지만, 반드시 고유 식별자일 필요는 없다는 것을 알아야 한다. 예를 들어, 키 식별자는 암호화 키의 패밀리를 식별할 수 있다. 예를 들어, 일부 실시예에서, 키 회전이 수행된다. 키 회전은 사용된 암호를 실제 크래킹(cracking)하는 것을 허용할 만큼 충분한 복호화된 데이터를 수집하는 것을 방지하기 위해 키를 다른 키로 대체하는 것을 수반할 수 있다. 키 식별자가 키를 고유하게 식별하지 못하는 경우, 적절한 기능을 가능하게 하기 위해 다양한 기술이 사용될 수 있다는 것을 또한 주목해야 한다. 예를 들어, 다양한 실시예에서, 키 식별자에 의해 식별되는 키의 패밀리는 유한하다. 키 식별자에 의해 식별된 키를 사용하는 복호화 작동이 요청되면, 추가 데이터(예를 들어, 암호화가 수행된 시간 스탬프)가 사용할 적절한 키를 결정할 수 있게 한다. 일부 실시예에서, 암호문(ciphertext)은 키 버전을 나타내는 정보를 포함할 수 있다. 일부 실시예에서, 모든 가능한 키는 해시될 수 있는 데이터의 상이한 복호화를 제공하는데 사용되며, 그 결과 생기는 해시는 저장된 해시와 비교되어 사용할 키를 식별할 수 있다. 유한한 수의 키가 있기 때문에 제공된 것들 중에서 적절한 복호화를 선택할 수 있다. 일부 실시예에서, 키를 이용한 복호화는 암호화 서비스가 예를 들어 인증된 암호화를 사용하는 것에 의해 키에 적어도 부분적으로 기초하여 암호문이 생성되지 않았음을 검출할 수 있게 하는 방식으로 수행된다. 다른 변형도 본 발명의 범위 내에 있는 것으로 간주된다.

암호화 서비스(106)는 클라이언트로부터 요청을 수신할 수 있고, 이 요청에 응답하여 데이터의 올바름 및 신뢰성에 기초하여 또한 요청의 일부로서 제공된 메타 데이터에 적어도 부분적으로 기초하여 요청을 처리하는 방법을 결정할 수 있다. 암호화 서비스는 일련의 작동(114)을 수행하여 디지털 서명(110)의 올바름과 신뢰성 및 그 요청을 처리하는 방법을 결정할 수 있다. 디지털 서명(문맥으로부터 명백할 때 간단히 서명이라고 지칭함)은, 디지털 메시지의 진정성을 증명하고, 메시지가 특정 알려진 발신자에 의해 생성되었고(인증), 발신자가 메시지를 송신한 것을 거부할 수 없고(부인 방지), 및 메시지가 전송 중 변경되지 않았음(무결성)을 나타내는 것을 보장하기 위해 사용할 수 있는 정보이다. 현재 사용 중인 디지털 서명은 PKCS(Public-Key Cryptography Standards) 및 DSA(Digital Signature Algorithm)의 다양한 버전을 포함한다. 일련의 작동(114)은 적어도 다음의 단계, 즉 암호화 키를 선택하는 단계(116), 주체에 적용 가능한 보안 정책들이 충족되는지 여부를 결정하는 단계(118), 암호화 키에 적용 가능한 보안 기대치들이 충족되는지 여부를 결정하는 단계(120), 및 요청에 응답을 준비하는 단계(122)를 포함할 수 있다. 암호화 서비스는 일부 상황에서 서로 공유될 수 있는 동일한 계정의 다수의 사용자로부터의 데이터를 포함하거나 데이터에 액세스할 수 있으며, 또한 역으로 서로 간에 데이터를 공유하지 않아야 하는 다수의 독립적인 고객으로부터의 데이터도 포함할 수 있다. 이러한 구성은, 예를 들어, 컴퓨팅 및/또는 저장 자원을 최적화하고, 대기 시간을 줄이며, 대역폭을 증가시키는 등을 위해 바람직할 수 있다. 일부 실시예에서, 고객은 (예를 들어, 시스템에 걸쳐 컴퓨팅 자원의 이용가능성에 기초하여) 컴퓨팅 자원에 동적으로 할당되고, 고객은 (예를 들어, 시스템에 걸쳐 컴퓨팅 자원의 이용가능성의 변화에 기초하여) 다른 컴퓨팅 자원에 다시 할당될 수 있다.

암호화 키를 선택(116)하는 단계는 요청(104)의 문맥으로부터 적어도 부분적으로 기초할 수 있다. 다양한 실시예에서, 요청(104)은 키 식별자를 지정하는 추가 파라미터를 포함하고 및/또는 키 식별자는 호출 클라이언트 또는 호출 클라이언트와 관련된 계정에 기초하여 유도될 수 있다. 추가적으로 또는 대안적으로, 암호화 키는 요청(104)에 포함될 수 있고 클라이언트에 의해 암호화 서비스에 제공될 수 있다.

주체에 적용 가능한 보안 정책들이 충족되는지 여부를 결정하는 단계(118)는 (예를 들어, 하나 이상의 적용 가능한 보안 정책을 인코딩하는 하나 이상의 전자 문서를 획득함으로써) 하나 이상의 적용 가능한 보안 정책을 식별하고 획득하는 단계, 및 적용가능한 보안 정책이 충족되는지 여부를 평가하는 단계를 포함할 수 있다. 주체에 적용 가능한 보안 정책은 정책 관리 모듈(124)로부터 획득될 수 있으며, 요청을 하는 클라이언트 및/또는 요청의 일부로서 제공된 정보에 적어도 부분적으로 기초할 수 있다. 일부 실시예에서, 주체는, 디폴트에 의해, 클라이언트(예를 들어, 클라이언트와 연관된 머신, 계정 또는 사용자)의 신원(identity)과 연관되지만, 디폴트 연관성은 요청의 일부로서 제공된 추가 정보에 기초하여 무시(overridden)될 수 있다.

일 실시예에서, 정책 관리 모듈(124)은, 보안 정책의 저장 및 검색을 관리하고 보안 정책을 주체와 연관시키는 프로그래밍 로직으로 구성되는 컴퓨터 시스템이다. 일부 실시예에서, 보안 정책은, 보안 정책에 저장된 데이터의 일부로서, 정책을 주체에 관련시키는 정보를 포함할 수 있다. 다른 실시예에서, 보안 정책으로부터 주체로의 매핑은, 예를 들어, 키-값 쌍의 키가 주체에게 고유하게 해결하는 연관 어레이의 사용을 통해, 또는 보안 정책 기록이 관련 주체 기록과 일치하는 외부 키 필드(foreign key field)를 포함하는 관계형 데이터베이스의 사용을 통해 존재할 수 있다. 일부 실시예에서, 보안 정책이 복수의 주체에 적용되는 그룹 정책이 또한 존재할 수 있다. 일반적으로, 정책 관리 모듈(124)은 요청과 관련된 정보(예를 들어, 요청 내 정보 및/또는 요청의 문맥 정보 및 요청의 외부에서 결정된 정보)를 사용하도록 구성된다. 정책 관리 모듈로부터 적용 가능한 보안 정책 또는 보안 정책들을 획득하면 암호화 서비스는 적용 가능한 보안 정책 또는 정책들이 충족되는지 여부를 평가할 수 있다.

일부 실시예에서, 적용 가능한 보안 정책은 호출 클라이언트와는 구별되는 주체와 연관될 수 있다. 예를 들어, 일부 실시예에서, 클라이언트는 다른 행위자(actor)의 적용 가능한 보안 정책이 적용 가능한 보안 정책을 식별할 때 사용되어야 하는 것을 나타내는 추가적인 정보를 요청에 제공할 수 있다. 예를 들어, 요청의 일부로서, 클라이언트는 제2 클라이언트로부터의 디지털 서명된 토큰을 포함할 수 있으며, 여기서 토큰은 제2 클라이언트가 제2 클라이언트의 보안 정책에 기초하여 요청을 발행하도록 제1 클라이언트에 허가하는 것을 지정하는 정보를 포함한다. 이러한 구성에서, 주체는 제1 (호출) 클라이언트가 아니라 제2 클라이언트가 된다. 다른 실시예에서, 주체는 호출 클라이언트와 구별될 수 있다.

암호화 키에 적용 가능한 보안 기대치가 충족되는지 여부를 결정하는 단계(120)는 하나 이상의 적용 가능한 보안 정책을 식별 및 획득하는 단계, 및 적용 가능한 보안 기대치 또는 기대치들이 충족되는지 여부를 평가하는 단계를 포함할 수 있다. 다양한 실시예에서, 암호화 키에 적용 가능한 보안 기대치는 암호화 서비스, 정책 관리 모듈, 및/또는 별개의 하드웨어 부품, 예를 들어, 하드웨어 또는 다른 보안 모듈(hardware or other security module: HSM), 또는 신뢰된 플랫폼 모듈(trusted platform module: TPM)과 같은 암호화 자료(예를 들어, 하드웨어 토큰)를 하드웨어 기반으로 보호하는 다른 장치, 또는 본 명세서에서 설명된 기술을 구현하도록 구성된 하나 이상의 서비스를 구현하도록 구성된 다른 장치에 의해 식별, 획득, 및 평가될 수 있다.

일부 실시예에서, 요청에 응답을 준비(122)하는 단계는 적용 가능한 보안 기대치(또는 기대치들)가 충족되는지 여부에 적어도 부분적으로 기초하여 생성된다. 보안 기대치(또는 기대치들)가 충족되는 경우, 암호화 서비스는 보안 기대치에 따라 요청을 이행할 수 있다. 보안 기대치를 평가하는 단계는 암호화 작동을 이행하는데 사용될 암호화 키가 신뢰되어야 하고 평가가 다양한 작동 모드를 가질 수 있는지 여부를 결정하는 단계를 포함할 수 있다. 작동 모드는 암호화 키의 신뢰성이 평가되는 방법을 결정한다. 일부 실시예에서, 작동 모드는 요청에서 지정되거나, 또는 암호화 서비스에 의해 설정될 수 있다.

도 2는 다양한 실시예가 실행될 수 있는 일 환경(200)의 예시적인 예를 도시한다. 일 실시예에서, 클라이언트(202)(요청자라고도 지칭됨)는 정책 시행 모듈(210) 및 기대치 평가 엔진(212)을 포함하는 프론트엔드(206)로 구성된 컴퓨터 시스템인 암호화 서비스(204)에 요청을 할 수 있다. 프론트엔드(206)는 정책 구성(220)에 액세스, 이를 생성, 삭제 및 업데이트하도록 구성된 정책 관리 모듈(216) 및 인증 호스트(208)에 액세스하도록 구성된 컴퓨터 시스템이다. 암호화 서비스는 또한 하나 이상의 하드웨어 보안 모듈(HSM)을 포함하는 백엔드(214) 시스템을 더 포함하고 - 명료화를 위해, 단일 HSM(218)이 도시되어 있다. 예시적인 암호화 서비스는 전체 내용이 본 명세서에 병합된 발명의 명칭이 "데이터 보안 서비스(Data Security Service)"인 2013년 2월 12일에 출원된 미국 특허 출원 번호 13/764,963에 기술되어 있다.

일 실시예에서, 서비스 프론트엔드 호스트(206)는 하나 이상의 클라이언트로부터 요청을 수신하고, 이 요청을 어떻게 처리할지를 결정하기 위해 인증 호스트(208)와 통신한다. 인증 호스트(208)는 컴퓨터 시스템, 컴퓨터 시스템 공정, 프로그램 애플리케이션, 서비스 모듈, 또는 이들의 조합 및/또는 다른 컴퓨팅 시스템 개체일 수 있다. 인증 호스트(208)는, 예를 들어, 프론트엔드(206)에 제출된 요청들을 처리할지 여부 및/또는 처리하는 방법을 결정하기 위해 암호화 서비스에 의해 이용될 수 있다. 인증 호스트는, 예를 들어, 암호화 서비스에 제출된 요청들의 디지털 서명을 검증하거나 그 밖에 요청의 이행이 허가될지 여부를 결정할 수 있다. 또한, 설명의 목적을 위해 본 명세서 전반에 걸쳐 고객/제공자 관계가 논의되지만, 본 명세서에 설명된 기술은, 예를 들어, 고객이 암호화 서비스의 내부 고객(202)(예를 들어, 서비스 제공자의 다른 서비스의 고객(202))인 경우, 다른 문맥에 적응할 수 있다.

정책 관리 모듈(216)은 적용 가능한 경우 정책에 관한 정보 및 정책 그 자체를 제공하도록 작동 가능한 암호화 서비스의 서비스 또는 서브시스템의 예시적인 예이다. 정책 관리 모듈은 정책 구성(220)을 생성, 수정, 삭제, 복사 또는 전파하도록 작동 가능할 수 있다. 예시적인 정책 구성(이는, 예를 들어, 정책 문서이고 문맥으로부터 명백한 경우 정책이라고 지칭될 수 있음)은 도 3에서 아래에서 보다 상세히 설명된다. 도 2를 다시 참조하면, 정책 시행 모듈(210)과 같은 프론트엔드(206)의 부품은 정책 관리 모듈(216) 및 확장하여 정책 구성(220)과 상호 작용하기 위해 애플리케이션 프로그래밍 인터페이스(application programming interface: API)를 사용할 수 있다. 일부 실시예에서, 클라이언트 요청은 정책 관리 모듈에 직접 전달될 수 있으나, 다른 실시예에서, 프론트엔드 또는 내부 구성 요소(예를 들어, 인증 호스트)는 클라이언트 요청을 구문 분석하고, 정책 관리 모듈이 허용할 수 있는 형식으로 요청을 생성하고 나서, 이 요청을 정책 관리 모듈에 전달할 수 있다. 도 2에서, 정책 관리 모듈은 프론트엔드 및 백엔드 모두와 분리된 서비스로서 구현되는 것으로 도시된다. 그러나, 정책 관리 모듈은 다른 실시예에서 백엔드(214)의 일부로서 구현될 수 있다(즉, 정책 구성에 대한 액세스는 중개 서비스가 아니라 백엔드(214)로 향한다). 이러한 실시예에서, 백엔드(214)로 향하는 요청들은 여전히 정책 관리 모듈에 의해 수행된다.

정책 구성(220)은 충분한 권한을 갖는, 사용자, 보안 관리자, 시스템 관리자 또는 다른 주체에 의해 생성, 변경, 복사, 삭제 또는 상속될 수 있다. 일부 실시예에서, 주체가 정책을 생성, 수정, 복사, 삭제 또는 상속할 수 있는 충분한 권한을 갖는지 여부는 주체가 생성, 수정, 복사, 삭제 또는 상속하려고 하는 정책에 기초할 수 있다. 예를 들어, 보안 관리자는 자원에 게스트 사용자 액세스를 거부하는 정책을 생성할 수 있는 충분한 권한을 가질 수 있는 반면, 게스트 사용자는 자원에 보안 관리자 액세스를 거부하는 정책을 생성할 수 있는 충분한 권한을 가질 수 없다. 정책 구성은 임의의 표준 환경, 분산 환경, 가상 환경 또는 클러스터 환경에서 데이터 서버, 데이터베이스, 데이터 저장 장치 및 데이터 저장 매체의 임의의 조합 및 수를 포함하여 다양한 컴퓨터 기반 하드웨어 및/또는 소프트웨어 구성 요소를 사용하여 저장될 수 있다.

일 실시예에서, 서비스 프론트엔드 호스트(206)가 고객 네트워크(202)로부터 요청을 수신하면, 서비스 프론트엔드 호스트(206)는 인증 요청을 인증 호스트(208)에 제출하고, 인증 호스트는, 일 실시예에서, 서비스 프론트엔드 호스트(206)에 대한 요청이 진실한(authentic) 것인지 여부(예를 들어, 이 요청의 디지털 서명이 성공적으로 검증되었는지 여부)를 지정하는 인증 응답 및 이 요청에 적용 가능한 정책들의 세트를 지정하는 정보를 제공한다. 정책 세트를 수신하면, 서비스 프론트엔드 호스트(206)는 정책 시행 모듈을 이용하여 요청을 이행할지 또는 거부할지와 같은 요청을 처리하는 방법을 결정할 수 있다. 또한, 요청이 적어도 부분적으로 충족되어야 한다고 결정하면, 기대치 평가 엔진(212)은 요청이 충족되어야 하는 방법을 결정하는데 사용될 수 있다. 기대치 평가 엔진은 클라이언트에 의해 및/또는 암호화 서비스에 의해 (예를 들어, 적용 가능한 정책 구성에 의해) 제공될 수 있는 보안 기대치에 따라 요청을 평가하는 데 사용될 수 있다.

기대치 평가 엔진은 프론트엔드의 구성 요소로서 도시되어 있지만 기대치 평가 엔진은 대안적으로 백엔드(214)의 일부로서 포함되거나, HSM(216)의 일부로 포함되거나, 또는 암호화 자료를 하드웨어 기반으로 보호하는 다른 적절한 장치의 일부로서 포함될 수 있다. 일단 정책 관리 모듈(216)로부터 정책이 수신되면, 서비스 프론트엔드 호스트(206)는 이러한 정책을 정책 시행 모듈에 제공하여 요청을 처리하는 방법(예를 들어, 정책이 요청의 이행을 허용하는지 여부 및/또는 이행이 진행되어야 하는 방법)을 평가하도록 할 수 있다. 정책 시행 모듈(216)은 디폴트 정책의 시행(예를 들어, 명시적으로 한정된 정책이 없는 경우 이행이 진행되어야 하는 방법을 결정) 및 다수의 정책들 간의 충돌이 요청을 처리하는데 영향을 미치는 방법을 결정(예를 들어 다수의 정책이 적용가능한 경우 이행이 진행되어야 하는 방법을 결정)하는 것과 같은 정책의 허가와 관련된 다양한 태스크(task)를 수행할 수 있다. 일부 실시예에서, 정책 관리 모듈은 정책들의 세트 및 요청 문맥을 수신할 수 있고, 이에 응답하여 요청이 어떻게 이행되어야 할지 (예를 들어, 요청을 허용할지 또는 거부할지)에 대한 결정을 제공할 수 있다.

백엔드(214)는 암호화 키를 저장하고 이에 액세스하도록 작동 가능하고, 적어도 하드웨어 보안 모듈(HSM) 또는 암호화 자료(예를 들어, 하드웨어 토큰)를 하드웨어 기반으로 보호하는 다른 장치를 포함할 수 있다. 백엔드는 멀티-테넌트 시스템에서 복수의 클라이언트로부터의 암호화 키를 저장하고 이에 액세스할 수 있으며, 하나의 클라이언트의 암호화 키는, 디폴트에 의해, 시스템 내의 다른 클라이언트에는 액세스될 수 없다.

도 3은 일 실시예에 따른 정책 문서(예시적인 정책 구성)의 예시적인 예를 도시한다. 일 실시예에서, 정책 문서(300)는 정책 문서에 의해 인코딩된 정책과 관련된 다양한 정보를 인코딩한다. 정책은 XACML(eXtensinble Access Control Markup Language), EPAL(Enterprise Privacy Authorization Language), 아마존 웹 서비스 액세스 정책 언어(Amazon Web Services Access Policy Language), 마이크로소프트(Microsoft) SecPol과 같은 선언적 액세스 제어 정책 언어로 인코딩되거나 또는 요청이 이행가능하기 위해 충족되어야 하는 하나 이상의 조건을 인코딩하는데 적합한 임의의 방식으로 인코딩될 수 있다. 도 3에 도시된 바와 같이, 정책 문서(300)는 정책 문서(300)에 대한 문자열을 포함할 수 있는 이름(302)을 포함한다. 이름(302)은, 예를 들어, 사람이 읽을 수 있는 용어를 사용할 때 편리한 식별자를 제공하는데 사용될 수 있다. 예를 들어, 이름(302)은 예를 들어 "나의데이터저장정책(MyDataStoragePolicy)"의 효과에 대한 문자열일 수 있다. 또한 도 3에 도시된 바와 같이, 정책 문서(300)는 버전(304)을 포함할 수 있다. 버전(304)은 다양한 요청이 수신되어 정책을 업데이트하기 위해 이행될 때 정책 문서(300)가 시간에 따라 어떻게 변하는지를 추적하는 데 사용될 수 있다. 정책 문서(300)에 대한 각각의 업데이트는 버전(304)이 새로운 값으로 업데이트되게 할 수 있다. 또한, 정책 문서(300)는 현재 버전을 갖는 정책 문서(300)를 생성하는 것을 초래한 요청을 제출한 사용자에 대한 식별자일 수 있는 발행자(306)를 지정할 수 있다. 도 3에 도시된 바와 같이, 전술한 바와 같이, 정책 문서(300)는 하나 이상의 명령문(statement)(308)을 포함할 수 있다. 정책 문서 내의 명령문은 논리적 OR을 사용하여 처리될 수 있다.

전술한 바와 같이, 명령문은 하나 이상의 자원에 액세스하는 것에 대한 허가 또는 하나 이상의 조건의 일반적으로 공식적인 설명일 수 있다. 따라서, 도 3은 전술한 바와 같이 정책 문서에 인코딩될 수 있는 명령문(308)의 예시적인 예를 도시한다. 도 3에 도시된 바와 같이, 명령문(308)은 하나 이상의 주체(310)를 식별하는 정보를 포함할 수 있다. 주체는 명령문(308)이 적용되는 개체(예를 들어, 사용자, 사용자 그룹, 사용자의 등급, 컴퓨터 시스템, 또는 시스템 또는 시스템 내 자원에 액세스하는 것에 허가가 부여될 수 있는 임의의 개체)일 수 있다.

일 예로서, 컴퓨팅 자원 서비스 제공자의 고객은 계정을 가질 수 있다. 계정은 고객의 사용자에 각각 대응하는 다수의 하위 계정과 연관될 수 있다. 각 사용자는 명령문에서 주체로 포함될 수 있는 대응하는 식별자를 가질 수 있다. 주체는 다른 방법으로도 식별될 수 있다. 예를 들어, 주체들의 세트들이 세트에 대한 식별자로 식별될 수 있다. 예시적인 예로서, 조직 내의 부서는 대응하는 식별자를 가질 수 있다. 명령문은 부서에 대한 식별자를 명령문에 나열함으로써 부서와 관련된 사용자에게 적용될 수 있다. 주체들의 세트들에 대한 식별자는 세트들이 예를 들어 직원이 조직 및/또는 조직 내 부서에 고용되거나 떠날 때와 같이 동적으로 변경되는 경우 유용할 수 있다.

일반적으로, 주체들의 세트들이 주체의 특성에 적어도 부분적으로 기초하여 한정될 수 있다. 주체의 식별자는 개방형일 수도 있다. 예를 들어, 명령문(308)이 누구에게나 적용가능하다는 것, 즉 컴퓨팅 자원 서비스 제공자의 계정을 대신하여 요청을 제출할 수 있는 모든 사용자 또는 일반적으로 모든 사용자에게 적용 가능하다는 것을 나타내는 정보가 포함될 수 있다. 일부 실시예에서, 명령문은 적어도 주체(310), 자원(312), 동작(316) 및 효과(318)를 식별해야 한다. 보안 정책에 설명된 주체는 예를 들어 사용자, 그룹, 도메인, 서비스, 컴퓨터, 개인, 공정, 스레드, 환경 또는 암호화 서비스에 의해 인증될 수 있는 다른 유형의 개체일 수 있다. 주체의 일부 예는 행위자 세트(예를 들어, 다수의 사용자 또는 '관리자'와 같은 사용자 그룹), 서로 다른 유형의 행위자를 갖는 세트(예를 들어, 사용자 및 도메인을 포함하는 세트) 또는 이들의 임의의 조합을 포함할 수 있다. 주체는 주체 또는 주체들의 특성에 기초하여 경험적으로 기술될 수 있고, 예를 들어, 정책의 주체는 안전한 전송 계층 보안(transport layer security: TLS) 연결을 통해 암호화 서비스에 연결된 개체를 포함할 수 있다.

설명된 자원은 정책이 적용될 수 있는 컴퓨터 기반 자원일 수 있다. 정책에 설명된 자원은 컴퓨팅 자원(예를 들어, 프로세서, 컴퓨팅 클러스터), 컴퓨터 저장장치(예를 들어, 컴퓨터 파일, 컴퓨터 디스크 드라이브 또는 파티션, 물리적 하드 드라이브, 자기 테이프 데이터 저장장치), 암호화 자원(예를 들어, 암호화 키), 컴퓨터 작동(예를 들어, API 또는 API 세트) 및 시스템 자원(예를 들어, 동기화 기본 요소)을 포함하지만 이에 국한되지 않는 다양한 유형의 컴퓨팅 자원을 포함한다. 주체와 유사하게 정책에 지정된 자원은 단일 자원(예를 들어, 파일), 자원 세트(예를 들어, 임의의 파일 목록), 자원 유형 조합(예를 들어, 컴퓨터 파일 및 프로세서) 또는 이들의 임의의 조합에 적용될 수 있다. 정책의 동작은 행위자가 정책에 지정된 자원 또는 자원들에 수행하는 것이 허용된 동작 또는 동작들의 세트를 지정한다. 동작은, 예를 들어, 단일 API 호출(예를 들어, 논리적 컨테이너에 저장된 리스트 전체 데이터가 제공되는 '리스트데이터(ListData)' API)과 같은 단일의 특정 동작일 수 있으며, 액세스 레벨(예를 들어, - "리스트데이터"를 포함할 수 있는 - 모든 판독 작동이 포함되는 "판독" 액세스)을 나타낼 수 있고, 또는 이들의 일부 조합을 포함할 수 있다.

도 3에 도시된 바와 같이, 명령문(308)은 하나 이상의 자원(312)을 식별한다. 자원은 전술한 바와 같은 컴퓨팅 자원일 수 있다. 자원은 예를 들어 컴퓨팅 자원 서비스 제공자가 제공하는 서비스의 대상일 수 있다. 예를 들어, 자원은 가상 컴퓨터 시스템일 수 있고, 데이터 객체들을 함께 연관시키는데 사용되는 논리적인 데이터 컨테이너일 수 있고, 블록 레벨 데이터 저장 장치의 볼륨 식별자, 데이터베이스, 데이터베이스에 저장된 항목, 데이터 객체(예를 들어, 파일), 및 일반적으로 서비스로 제공될 수 있는 임의의 유형의 자원일 수 있다. 일부 실시예에서, 자원은 고객 또는 다른 개체(예를 들어, 사용자, 역할, 그룹 등)를 대신하여 암호화 서비스에 의해 관리되는 암호화 키 및/또는 하나 이상의 데이터 저장 서비스에 대한 디폴트 키로서 사용되는 암호화 키와 같은 암호화 키이다. 주체와 같이, 자원은 자원의 특성에 적어도 부분적으로 기초하여 한정될 수 있는 자원들의 세트들의 식별자를 사용하여 기술될 수 있다. 예를 들어, 일부 실시예에서, 가상 컴퓨터 시스템은 가상 컴퓨터 시스템에 의해 이행되는 역할을 기술할 수 있는 사용자 생성된 태그와 연관될 수 있다. 예를 들어, 가상 컴퓨터 시스템 그룹은 "웹 서버" 태그와 연관될 수 있다. 따라서 자원은 이러한 태그로 식별될 수 있다. 다른 예로서, 자원은 논리적 데이터 컨테이너에 대응할 수 있고, 이에 의해 명령문(308)이 논리적 데이터 컨테이너 내에 저장된, 즉 논리적 데이터 컨테이너와 관련된 임의의 데이터 객체에 적용가능하다. 자원(예를 들어, 데이터 객체)은 자원을 암호화하는 데 사용되는 키에 의해 한정될 수도 있다. 전술한 것에 더하여, 정책이 적용되는 객체(예를 들어, 주체 및 자원)는 SAML(Security Assertion Markup Language)을 사용하여 전달될 수 있는 속성 및/또는 디렉토리를 사용하여 결정되는 속성에 적어도 부분적으로 기초할 수 있다.

도 3에 도시된 바와 같이, 명령문(308)은 하나 이상의 조건을 더 포함할 수 있다. 일 실시예에서, 조건은 정책 문서의 명령문이 특정 문맥에서 적용되는지, 즉 명령문이 제출된 문맥에서 제출된 요청에 적용되는지 여부를 결정짓는다. 조건은, 부울리안 연산자(같음, 보다 작음 등)를 사용하여, 정책이 평가되고 있는 요청에서 제공되거나 제공되지 않을 수 있는, 명령문(주체, 자원 등)의 다른 값 및 허가 문맥(authorization context)의 다른 값에 대한 조건을 평가할 수 있다. 조건 값은 날짜, 시간, 요청자의 인터넷 프로토콜(Internet Protocol: IP) 주소, 요청 소스의 식별자, 사용자 이름, 사용자 식별자 및/또는 요청자의 사용자 에이전트 및/또는 다른 값을 포함할 수 있다. 값은 조건이 적용되는 서비스에 고유한 것일 수도 있다. AND 및 OR과 같은 논리적 연결자를 사용하여 조건을 논리적으로 연결하여 평가할 수 있다.

명령문은 또한 하나 이상의 동작(316)을 인코딩할 수 있다. 일 실시예에서, 동작은 서비스 제공자에 의해 수행가능한 작동이다. 일 실시예에서, 동작은 서비스 제공자에 의해 지원되는 API 호출(즉, 서비스 제공자가 이행할 수 있는 서비스 제공자에게 이루어질 수 있는 API 호출)에 대응한다. 지정된 동작은 API 호출(아마도 다수의 상이한 유형의 API 호출)의 이행의 일부로 수행되는 작동일 수도 있고, 일부 API 호출에서는 다른 작동도 수행될 수 있다. 예를 들어, API 호출의 이행은 다수의 작동의 수행을 포함할 수 있으며 정책에서 하나 이상의 작동이 동작으로 지정될 수 있다.

도 3에 도시된 바와 같이, 명령문(308)은 하나 이상의 효과(318)를 더 포함할 수 있다. 일 실시예에서, 효과는 정책의 행위자가 정책에 지정된 작동을 동일한 정책에 지정된 자원에 대해 수행하려고 시도하는 요청의 예상 결과를 결정한다. 이 효과는 작동이 자원에 액세스하는 작동을 단순히 "허용" 또는 "거부"할 수 있다. 예를 들어, 정책 문서(300)에 의해 인코딩된 정책이 복호 요청에 적용될 때, 명령문(308) 내 조건이 충족되는 것에 의해 요청의 이행이 효과(318)에 따라 허용되거나 또는 거부될 수 있다. 충돌 해결 규칙은 예를 들어 2개의 서로 다른 명령문이 동시에 이행가능한 각 명령문을 가지고 있고 2개의 명령문 사이에 효과가 다른 경우 적용될 수 있다. 예를 들어 정책에 의해 명시적으로 허용되지 않는 한, 디폴트가 거부될 수 있으며, 명시적 거부가 명시적 허용보다 우선 적용되거나, 그 반대로 적용되도록 시스템을 구성할 수 있다. 충돌 해결을 수반하는 예시적인 방법은 도 6과 관련하여 아래에서 논의된다. 명시적인 효과(예를 들어, 명시적인 허용 또는 명시적인 거부)는 정책에서 인코딩된 효과이다.

도 4는 신뢰키 동작을 사용하여 암호화 키를 사용하기 위한 액세스를 부여하는 예시적인 보안 정책을 나타낸다. 명료화를 위해, 정책 문서(400)는 주체, 자원, 동작 및 효과만을 갖는 것으로 도시지만, 정책 문서는 도 3에서 상기 논의된 바와 같은 추가 정보를 포함할 수 있다. 신뢰키 동작(406)은 정책 문서에서 지정된 효과(408)에 기초하여 암호화 작동을 수행할 때 정책 문서에서 식별된 주체(402)가 자원(404)을 사용하기 위해 액세스하는 것을 허가하거나 또는 거부한다. 일부 실시예에서, 정책 문서(400)에서 지정된 자원(404)은 암호화된 키 및 암호화 키와 관련하여 사용 가능한 다른 자원, 예를 들어, 암호화된 파일 또는 암호화된 미디어 저장매체를 포함할 수 있다. 일부 실시예에서, 신뢰키 동작은 신뢰키 API 호출에 대응할 수 있는 반면, 다른 실시예에서는 신뢰키 동작은 다른 API 호출(즉, 추가 동작을 갖는 다른 API 호출)의 일부임을 유의해야 한다.

일부 실시예에서, 클라이언트는 암호화 서비스에 신뢰키 동작을 통해 신뢰되는 암호화 키들의 세트에 대한 추가 암호화 키를 포함할 수 있다. 신뢰키 동작은 적어도 데이터 암호화 및 복호화와 같은 암호화 작동, 디지털 서명의 생성 및 검증을 포함하는 다양한 작동을 수행하기 위해 클라이언트가 신뢰하고자 하는 암호화 키 또는 암호화 키들의 세트를 적어도 설명한다. 신뢰되는 암호화 키만이 암호화 작동을 수행하는 데 사용될 수 있다. 일부 실시예에서, 신뢰키 작동은 또한 신뢰키 작동이 암호화 키를 신뢰된 것으로 식별하기 위해 충족되어야 하는 조건을 더 포함할 수 있다. 일부 실시예에서, 신뢰키 작동(또는 암호화 작동의 결과를 신뢰할지 여부를 결정하는 것과 관련하여 사용되는 다른 작동)을 이행하는데 사용되는 조건은 암호화 키에 고유한 특성의 사용을 포함할 수 있다. 암호화 키에 고유한 속성은 키 자체로부터 결정할 수 있는 키 크기 및 다른 정보를 포함할 수 있다.

도 5는 전술한 실시예에서 요청을 처리하기 위한 공정(500)의 예시적인 예를 설명한다. 공정(500)은 전술한 바와 같이 프론트엔드를 구현하는 웹 서버와 같은 암호화 서비스 또는 그 구성 요소와 같은 임의의 적절한 시스템에 의해 또는 애플리케이션 서버 및/또는 보안 모듈과 함께 웹 서버에 의해 수행될 수 있다. 예시의 목적으로, 공정은 도 2에 설명된 것과 같은 암호화 서비스와 관련하여 설명되지만, 암호화 서비스를 구현하기 위한 컴퓨팅 자원의 다른 구성도 본 발명의 범위 내에 있는 것으로 고려된다. 암호화 서비스는 암호화 작동을 수행하라는 요청을 수신할 수 있다(502). 일부 예에서, 이 요청은 웹 서비스 요청이지만, 다른 API 호출은 본 발명의 범위 내에 있는 것으로 고려된다. 또한, 일부 실시예에서, 공정(500) 또는 그 작동의 서브세트는, 암호화 키들을 하드웨어적으로 보호하는 HSM 또는 다른 장치와 같은 하드웨어 장치에 의해 수행될 수 있고, 일부 실시예에서 암호화 키는 암호화 키들로부터 평문 형태로 보낼 수 없다(unexportable). 프로그래밍적으로 (예를 들어, 장치의 인터페이스를 통해) 장치가 정보를 제공하도록 하는 합법적인 방법이 없다면, 정보는 프로그래밍적으로 보낼 수 없다라고 말할 수 있다. 예를 들어, 하드웨어가 평문 형태의 정보에 액세스하여 평문 형태로 정보를 드러내도록 하는 요청 메커니즘(예를 들어, 애플리케이션 프로그래밍 인터페이스(API) 호출)이 없도록 정보가 유지될 수 있다. 예를 들어, 정보를 저장하는 장치(예를 들어, 암호화 모듈)는 그 메모리의 일부 또는 전부의 사본을 제공할 능력이 없어서 사본이 평문 형태로 정보를 포함하도록 구성될 수 있다. 그러나, 평문 형태로 정보를 얻는 합법적인 방법이 없는 정보는 설명의 목적으로 본 명세서 전반에 걸쳐 사용되지만, 일부 정보는 다양한 보안 프로토콜을 사용할 것을 요구하는 제한된 수의 허가된 사용을 통해 정보를 얻을 수 있고, 평문 형태의 정보에 허가 없이 액세스하는 것을 방지할 수 있도록 일부 정보를 유지할 수 있다는 것에 유의해야 한다. 일반적으로 프로그래밍적으로 보낼 수 없는 정보는 평문 형태의 정보를 얻는 것이 가능하다면 평문 형태로 정보를 얻기 위해 특별한 조치가 취해져야 하는 정보(예를 들어, 하나 이상의 암호화 키)이다.

명료화를 위해, 예시적인 복호화(DECRYPT) 작동이 도 5의 내용 내에서 설명될 것이다. 그러나 설명된 공정(500)은 또한 디지털 서명 검증과 같은 암호화 작동을 수행하기 위한 다른 요청을 처리하는 데 사용될 수 있다. 요청은 네트워크를 통해 수신될 수 있으며(502), 일부 예에서는 웹 서비스 요청이다.

일 실시예에서, 요청을 처리하기 위해, 암호화 서비스는 암호화 키를 선택한다(504). 암호화 키는, 예를 들어, (502)에서 수신된 요청 내의 암호화 키의 식별자 및/또는 전술한 바와 같은 요청에 포함된 다른 정보에 적어도 부분적으로 기초하여 선택될 수 있다. 요청 외부의 정보로부터 결정될 수 있는 문맥 정보를 또한 사용하여 암호화 키를 선택할 수 있다(504).

암호화 서비스 또는 그 안의 구성 요소는 이 요청이 진실한 것인지 여부를 결정하기 위해 체크한다(506). 일부 실시예에서, (도 2에 설명된 인증 호스트와 같은) 암호화 서비스 내의 또는 암호화 서비스에 의해 액세스 가능한 인증 모듈은 이 단계를 수행할 수 있다. 진실한 요청은 요청을 수신한 상대방(즉, 암호화 서비스)이 요청이 특정 상대방(예를 들어, 클라이언트(202) 또는 클라이언트(202))에 요청의 제출을 위임한 제3자)에 의해 이루어졌음을 보장될 수 있도록 클라이언트의 신원이 인증될 수 있는 요청이다. 일부 실시예에서, 이 요청은 인증된 암호화, 디지털 서명, 메시지 인증 코드(message authentication code: MAC)를 사용하여 또는 암호화 서비스가 상대방(예를 들어, TLS 연결)을 인증할 수 있게 하는 속성을 갖는 암호화 프로토콜을 사용하여 이루어진다. 진정성 체크가 요청 그 자체에 대해 이루어지는데, 즉 복호화(DECRYPT) 요청의 경우, 진정성 체크는 적어도 요청을 발행하는 상대방의 신원을 확인하고, 일부 실시예에서는 응답에 포함된 암호문이 진실하다는 것을 검증할 수 없다는 것에 주목해야 한다. 요청이 진실하다는 것을 결정할 수 없는 경우(예를 들어, 디지털 서명이 변경되거나 부정확한 암호화 키로 디지털 서명이 생성된 경우), 암호화 서비스는 요청을 거부하고(520), 일부 실시예에서는 클라이언트에 에러를 리턴하거나 및/또는 다른 조치를 취할 수 있다(예를 들어, 하나 이상의 전자 메시지를 통해 보안 관리자에게 알린다).

일 실시예에서 요청이 진실한 것으로 결정되면, 그 요청이 임의의 적용 가능한 보안 정책을 충족시키는지 여부를 암호화 서비스 또는 그 안의 구성 요소가 결정한다(508). 일부 실시예에서, 암호화 서비스 내의 또는 암호화 서비스에 의해 액세스가능한 정책 시행 모듈은 이 단계를 수행할 수 있다. 전술한 바와 같이, 요청의 진정성을 결정하는 부분으로서, 요청에 적용 가능한 정책들의 세트(집합적으로 보안 정책이라고 지칭됨)가 획득될 수 있지만, 다른 실시예에서는 보안 정책이 다른 방식으로 얻어질 수 있다. 획득한 보안 정책은 주체가 수행하는 것이 허용된 동작 및/또는 동작을 수행하는데 사용될 수 있는 자원과 관련된 제한을 포함할 수 있다. 예를 들어, 일부 보안 정책은 권한이 낮은 주체가 "읽기" 또는 "읽기" 유형의 암호화 작동(예를 들어, 복호화(DECRYPT))만 수행하는 것이 허용되지만 "쓰기" 또는 "쓰기" 관련 암호화 작동(예를 들어, 암호화(ENCRYPT))을 사용하여 내용을 변경하거나 새로운 내용을 생성하는 것이 허용되지 않는 것으로 능력을 제한할 수 있다. 제2 예로서 일부 보안 정책은 주체가 "쓰기" 또는 "쓰기" 관련 암호화 작동을 수행하는 것을 허용할 수는 있지만 복호될 수 있는 자원들의 세트를 제한할 수 있다. 요청이 보안 정책 조건을 충족시키지 못함을 검출하면, 암호화 서비스는 요청을 거부할 수 있고(520), 일부 실시예에서는 클라이언트에게 에러를 반환하거나 및/또는 다른 조치를 취할 수 있다(예를 들어, 보안 관리자에게 알린다).

요청의 이행이 획득된 보안 정책을 충족시키는 것으로 결정된 결과, 일 실시예에서, 암호화 서비스 또는 그 안의 구성 요소는 암호화 키와 관련된 보안 기대치 및 수신된 요청의 암호화 작동을 이행하는데 사용될 선택된 암호화 키를 획득한다(510). 전술한 바와 같이, 보안 기대치들의 세트는 요청 및/또는 요청 외부의 정보(예를 들어, 요청에 적용 가능한 정책들의 세트)로부터 얻어질 수 있다. 논의된 바와 같이, 보안 기대치들의 세트는, 이행될 때 및 선택된 암호화 키가 암호화 작동을 수행하는데 사용 가능한지의 여부에 상관 없이, 암호화 작동의 결과가 신뢰되는 것을 나타내는 선택된 암호화 키에 적용 가능한 조건들의 세트를 한정할 수 있다.

복호화(DECRYPT) 예에서, 암호화 작동과 함께 사용되는 암호화 키는 요청으로부터 암호문을 복호하도록 작동 가능한 암호화 키이다. 일부 예에서, 암호화 키는 암호화 서비스의 보안 모듈에 의해서만 복호화 가능한 암호화된 형태로 데이터 저장 시스템에 저장된다. 이러한 실시예에서, 암호화된 암호화 키는 데이터 저장 시스템으로부터 획득되어 보안 모듈에 제공될 수 있다. 다른 실시예에서, 보안 모듈은 암호화 키를 저장하고 로컬 데이터 저장 장치로부터 암호화 키에 액세스할 수 있다. 일반적으로, 암호화 키가 획득되는 임의의 방법이 사용될 수 있고, 암호화 키가 얻어지는 방식은 다양한 암호화 서비스 구성에 따라 달라질 수 있다. 일부 실시예에서, 암호화 서비스는 정책 관리 모듈 또는 유사한 구성 요소를 사용하여 암호화 키와 연관된 보안 기대치를 식별하고 획득할 수 있다. 다른 실시예에서, 보안 기대치는 요청에 적어도 부분적으로 포함될 수 있다. 또한, 도 5는 공정(500)의 일부로서 암호화 키를 얻는 것을 도시하는데, 일부 실시예에서, 예를 들어 보안 기대치가 암호화 키에 대한 액세스 없이 평가될 수 있는 경우 및 이러한 평가가 암호화 키에 액세스할 필요가 없을 때, 암호화 키가 획득될 수 없을 수 있다는 것이 주목된다.

일 실시예에서, 암호화 서비스 또는 그 안의 구성 요소는 보안 기대치에 따라 요청을 평가한다(512). 이 평가는 도 2에서 전술한 기대치 평가 엔진과 같은 구성 요소에 의해 수행될 수 있다. 예를 들어 만약 적용 가능한 보안 기대치에 의해 그렇게 나타난다면, 평가는 암호화 작동을 이행하는데 사용될 암호화 키가 신뢰되어야 하는지 여부를 결정하는 것을 포함할 수 있다. 평가는 다양한 작동 모드를 가질 수 있다. 작동 모드는 암호화 키의 신뢰성이 평가되는 방법을 결정한다. 일부 실시예에서, 작동 모드는 요청에서 지정되거나, 또는 암호화 서비스에 의해 설정될 수 있다.

일부 실시예에서, 작동 모드는 비활성화된 상태, 디폴트 작동 모드 또는 신뢰키 작동 모드를 포함할 수 있다. 비활성화된 작동 상태는 이 단계에서 검증이 꺼져 있는 작동 모드를 나타낸다. 이 작동 상태는 다른 작동 모드에 비해 성능 이점을 제공하며, 컴퓨팅 시스템이 본질적으로 안전한 일부 실시예(예를 들어, 신뢰할 수 있는 컴퓨팅 환경)에서 사용될 수 있다. 디폴트 작동 모드는 암호화 작동을 이행하는데 사용된 암호화 키의 검증이 인코딩된 정책에 기초하는 작동 모드일 수 있다. 디폴트 작동 모드의 예로는 모든 요청을 평가하여 암호화 작동을 이행하는 데 사용된 암호화 키가 주체 계정으로부터 온 키이도록 하는 것을 포함할 수 있다. 신뢰키 작동 모드는 정책 검증이 호출을 하는 주체에 부착되는 작동 모드일 수 있다. 일 실시예에서, 정책 관리 모듈은 룩업(lookup)하여 암호화 키에 대한 신뢰키 동작을 허용하는 주체와 관련된 보안 정책이 존재하는지 여부를 결정하는데 사용된다. 복호화(DECRYPT) 예에서 작동은 암호문 파일/자원에 대해 신뢰키 동작을 허용하는 호출 클라이언트와 관련된 보안 정책이 있는 평문을 성공적으로 복호하고 제공한다. 디지털 서명 검증의 예에서 긍정적인 응답은 디지털 서명이 올바르고 디지털 서명의 올바름을 검증하는 데 사용된 키가 신뢰할 수 있음을 모두 나타낼 수 있다.

응답은 보안 기대치의 평가에 기초하여 생성되고 제공된다(514)(예를 들어, 네트워크를 통해 전송된다). 보안 기대치가 충족되는 경우, 작동은 완료되고 적절한 응답(예를 들어, 암호문을 복호화하는 평문 결과)이 제공될 수 있다. 일부 실시예에서, 보안 기대치를 충족시키지 못하면(예를 들어, 신뢰키 동작을 허용하는 정책이 없음) 클라이언트에 실패가 리턴될 수 있다.

도 6은 다수의 적용 가능한 보안 정책들 간의 충돌을 해결하기 위한 공정(600)의 예시적인 예를 기술한다. 공정(600)은 암호화 서비스 또는 그 구성 요소와 같은 임의의 적절한 시스템에 의해 수행될 수 있다. 예를 들어, 보안 정책들에 대하여 수행될 때, 전술한 정책 시행 모듈은 공정(600)을 수행할 수 있다. 일부 실시예에서, 암호화 서비스는 요청을 처리할 때 (예를 들어, 도 5에 설명된 공정에 따라 및 도 2와 관련하여 전술한 바와 같이) 다수의 보안 정책을 획득할 수 있다. 2 이상의 정책들이 평가되어야 하는 것을 검출하면(602), 정책들이 각각 평가되고(604), 개별 정책들/기대치들 각각의 결과가 결정된다. 개별 정책 결과의 결과는 후속 평가를 계산하고 있는 동안 과도 매체(예를 들어, RAM 또는 임시 캐시) 또는 영구 매체(예를 들어, 하드 디스크 또는 네트워크 저장장치)에 저장될 수 있다. 일부 실시예에서, 평가는 병렬 방식 또는 분산 방식으로 이루어질 수 있다.

모든 평가를 완료하면, 액세스를 거부하는 임의의 명시적인 효과가 있는지 여부를 제일 먼저 체크(606)하는 것에 의해 충돌을 해결한다. 명시적 거부는 거부(DENY)하는 효과를 갖는 보안 정책으로부터 발생할 수 있다. 명시적 거부가 검출되면 충돌 해결의 결과로 자원에 액세스하는 요청이 거부된다. 그러나, 명시적인 거부가 없고 적어도 하나의 허용하는 효과가 검출되면(608), 요청이 허용되고(622), 이는 충돌 해결의 결과가 자원에 액세스하는 것을 허용하는(622) 것을 의미한다.

보안 기대치를 평가할 때 유사한 공정이 수행될 수 있다. 예를 들어, 특정 유형의 API 호출(예를 들어, 복호화(DECRYPT) 또는 서명_검증(VERIFY_SIGNATURE))의 경우, 보안 기대치에 명시적으로 언급된 효과에 의해 무시될 수 있는 요청을 이행하는 디폴트 방법이 있을 수 있다. 예를 들어, 복호화(DECRYPT)에 대한 디폴트는, 보안 기대치가 사용되는 복호 키가 신뢰되는 것임을 요구하지 않는 한, 복호된 암호문을 제공하는 것일 수 있으며, 이러한 요구조건이 충족되지 않으면 요청이 거부될 수 있다. 또 다른 예로, 서명_검증(VERIFY_SIGNATURE)에 대한 디폴트는, 보안 기대치가 키가 신뢰되는 것으로 지정되어야 할 것을 요구하지 않는 한, 올바름을 체크하는 데 사용된 키의 신뢰성에 관계없이 디지털 서명이 올바른지 여부를 나타내는 응답을 제공하는 것일 수 있다. 이러한 보안 기대치에 따라, 신뢰되지 않는 키를 사용하여 디지털 서명을 검증하기 위한 요청은 디지털 서명을 검증할 수 없음을 나타내는 응답을 제공하거나, 또는 일부 실시예에서는 디지털 서명이 올바르지만, 신뢰할 수 없는 것을 나타내는 응답을 제공함으로써 처리될 수 있다. 요청을 이행하는 디폴트 방식은, 다양한 실시예에 따라, 계정별로, 및/또는 다른 방식으로 변할 수 있다. 예를 들어, 일부 상황에서 보안 기대치가 명시적으로 더 낮은 보안(예를 들어, 신뢰할 수 없는 키를 사용하여 디지털 서명을 검증하거나 또는 신뢰할 수 없는 키를 사용하여 복호하는 경우)을 허용하지 않는 한, 디폴트는 더 큰 보안을 보장할 수 있다.

도 7은 다양한 실시예들에 따른 양태들을 구현하기 위한 예시적인 환경(700)의 양태를 도시한다. 이해할 수 있는 바와 같이, 웹 기반 환경이 설명의 목적으로 사용되었지만, 다양한 실시예를 구현하기 위해 적절한 경우 상이한 환경이 사용될 수 있다. 환경은 적절한 네트워크(704)를 통해 요청, 메시지 또는 정보를 송신 및/또는 수신하도록 작동할 수 있는 임의의 적절한 장치를 포함할 수 있는 전자 클라이언트 장치(702)를 포함하며, 일부 실시예에서는 장치의 사용자에게 다시 정보를 전달할 수 있다. 이러한 클라이언트 장치의 예로는 퍼스널 컴퓨터, 휴대폰, 핸드헬드 메시징 장치, 랩톱 컴퓨터, 태블릿 컴퓨터, 셋톱 박스, 개인 정보 단말기, 임베디드 컴퓨터 시스템, 전자책 리더기 등을 포함한다. 네트워크는 인트라넷, 인터넷, 셀룰러 네트워크, 근거리 네트워크, 위성 네트워크 또는 임의의 다른 그러한 네트워크 및/또는 이들의 조합을 포함하는 임의의 적절한 네트워크를 포함할 수 있다. 이러한 시스템에 사용되는 구성 요소는 선택된 네트워크 및/또는 환경의 유형에 따라 적어도 부분적으로 달라질 수 있다. 이러한 네트워크를 통해 통신하기 위한 프로토콜 및 구성 요소는 잘 알려져 있으므로 본 명세서에서는 상세히 설명하지 않는다. 네트워크를 통한 통신은 유선 또는 무선 연결 및 이들의 조합에 의해 가능해질 수 있다. 이 예에서, 네트워크는 환경이 요청을 수신하고 이 요청에 응답하여 컨텐츠를 제공하기 위한 웹 서버(706)를 포함하기 때문에 인터넷을 포함하지만, 다른 네트워크에서는 이 기술 분야에 통상의 지식을 가진 자에게 명백한 바와 같이 유사한 목적을 제공하는 대안적인 장치가 사용될 수 있다.

예시적인 환경은 적어도 하나의 애플리케이션 서버(708) 및 데이터 저장소(710)를 포함한다. 적절한 데이터 저장소로부터 데이터를 획득하는 것과 같은 태스크를 수행하기 위해 상호 작용할 수 있는, 연결된 또는 그 밖에 구성될 수 있는, 여러 애플리케이션 서버, 계층 또는 다른 요소, 공정 또는 구성 요소가 있을 수 있음을 이해해야 한다. 본 명세서에서 사용되는 서버는 하드웨어 장치 또는 가상 컴퓨터 시스템과 같은 다양한 방법으로 구현될 수 있다. 일부 상황에서 서버는 컴퓨터 시스템에서 실행되는 프로그래밍 모듈을 나타낼 수 있다. 본 명세서에 사용된 바와 같이, 달리 언급되거나 문맥으로부터 명확하지 않는 한, "데이터 저장소"라는 용어는 임의의 표준 환경, 분산 환경, 가상 환경 또는 클러스터된 환경에서 임의의 조합 또는 수의 데이터 서버, 데이터베이스, 데이터 저장 장치 및 데이터 저장 매체를 포함할 수 있는, 데이터를 저장, 액세스 및 검색할 수 있는 임의의 장치 또는 장치의 조합을 지칭한다. 애플리케이션 서버는, 애플리케이션에 대한 데이터 액세스 및 비즈니스 로직의 일부 또는 전부를 처리하는, 클라이언트 장치에 대한 하나 이상의 애플리케이션의 측면을 실행하기 위해 필요에 따라 데이터 저장소와 통합하기 위한 임의의 적절한 하드웨어, 소프트웨어 및 펌웨어를 포함할 수 있다. 애플리케이션 서버는 데이터 저장소와 협력하여 액세스 제어 서비스를 제공할 수 있으며, 사용자에게 제공되는데 사용될 수 있는, 텍스트, 그래픽, 오디오, 비디오 및/또는 기타 컨텐츠를 포함하지만 이에 국한되지 않는 컨텐츠를 생성할 수 있으며, 이는 HTML(HyperText Markup Language), XML(Extensible Markup Language), JavaScript, CSS(Cascading Style Sheets) 또는 다른 적절한 클라이언트 측 구조화된 언어의 형태로 웹 서버에 의해 사용자에게 제공될 수 있다. 클라이언트 장치로 전송된 콘텐츠는 클라이언트 장치에 의해 처리되어 사용자에게 청각적으로, 시각적으로 인식가능하거나, 및/또는 터치, 맛 및/또는 냄새를 포함하는 다른 감각을 통해 인식가능할 수 있는 형태를 포함하지만 이에 국한되지 않는 하나 이상의 형태로 콘텐츠를 제공할 수 있다. 클라이언트 장치(702)와 애플리케이션 서버(708) 사이의 컨텐트 전달뿐만 아니라 모든 요청 및 응답의 처리는 PHP(Hypertext Preprocessor: "PHP"), 파이톤(Python), 루비(Ruby), 펄(Perl), 자바(Java), HTML, XML 또는 이 예에서 기타 적절한 서버 측 구조화된 언어 등을 사용하여 웹 서버에 의해 처리될 수 있다. 본 명세서에서 논의된 구조화된 코드는 본 명세서의 다른 곳에서 논의된 바와 같이 임의의 적절한 장치 또는 호스트 머신 상에서 실행될 수 있기 때문에, 웹 서버 및 애플리케이션 서버는 요구되지 않고 단지 예시적인 구성 요소일 뿐이라는 것을 이해해야 한다. 또한, 단일 장치에 의해 수행되는 것으로 본 명세서에서 설명된 작동은, 문맥으로부터 명백하지 않는 한, 분산 시스템 및/또는 가상 시스템을 형성할 수 있는 다수의 장치에 의해 집합적으로 수행될 수 있다.

데이터 저장소(710)는 본 발명의 특정 양태에 관련된 데이터를 저장하기 위한 여러 별도의 데이터 테이블, 데이터베이스, 데이터 문서, 동적 데이터 저장 방식 및/또는 다른 데이터 저장 메커니즘 및 매체를 포함할 수 있다. 예를 들어, 도시된 데이터 저장소는 생산 측의 콘텐츠를 제공하는데 사용될 수 있는 생산 데이터(712) 및 사용자 정보(716)를 저장하기 위한 메커니즘을 포함할 수 있다. 데이터 저장소는 또한 보고하거나, 분석하거나 또는 다른 이러한 목적을 위해 사용될 수 있는 로그 데이터(714)를 저장하기 위한 메커니즘을 포함하는 것으로 도시된다. 적절한 경우 상기 열거된 메커니즘들 중 임의의 메커니즘으로 또는 데이터 저장소(710)에 추가적인 메커니즘으로 저장될 수 있는 페이지 이미지 정보 및 액세스 권리 정보와 같이, 데이터 저장소에 저장될 필요가 있는 많은 다른 측면들이 있을 수 있음을 이해해야 한다. 데이터 저장소(710)는 애플리케이션 서버(708)로부터 명령을 수신하고 이 명령에 응답하여 데이터를 획득, 업데이트 또는 달리 처리하도록 연관된 로직을 통해 작동 가능하다. 애플리케이션 서버(708)는 수신된 명령에 응답하여 정적, 동적 또는 정적 및 동적 데이터의 조합을 제공할 수 있다. 웹 로그(블로그), 쇼핑 애플리케이션, 뉴스 서비스 및 기타 이러한 애플리케이션에 사용되는 데이터와 같은 동적 데이터는 본 명세서에 설명된 서버 측 구조화된 언어에 의해 생성되거나, 또는 애플리케이션 서버에서 작동하거나 애플리케이션 서버의 제어 하에 작동하는 콘텐츠 관리 시스템(content management system: "CMS")에 의해 제공될 수 있다. 일 예에서, 사용자는, 사용자에 의해 작동되는 장치를 통해, 특정 유형의 항목에 대한 검색 요청을 제출할 수 있다. 이 경우 데이터 저장소는 사용자 정보에 액세스하여 사용자의 신원을 검증하고 카탈로그 상세 정보에 액세스하여 이런 유형의 항목에 대한 정보를 얻을 수 있다. 이 정보는, 사용자 장치(702) 상의 브라우저를 통해 사용자가 볼 수 있는 웹 페이지 상의 결과 목록과 같이, 사용자에게 반환될 수 있다. 관심 있는 특정 항목에 대한 정보는 전용 페이지 또는 브라우저의 창으로 볼 수 있다. 그러나, 본 발명의 실시예는 반드시 웹 페이지의 문맥으로 제한되는 것은 아니지만, 요청이 반드시 콘텐츠에 대한 요청이 아닌 일반적인 요청을 처리하는 것에 보다 일반적으로 적용될 수 있다는 것을 알아야 한다.

각각의 서버는 일반적으로 이 서버의 일반적인 관리 및 작동을 위한 실행 가능한 프로그램 명령을 제공하는 운영 시스템을 포함할 것이며 일반적으로 서버의 프로세서에 의해 실행될 때, 서버가 의도된 기능을 수행하게 하는 명령들을 저장하는 컴퓨터 판독 가능한 저장 매체(예를 들어, 하드 디스크, 랜덤 액세스 메모리, 판독 전용 메모리 등)를 포함할 수 있다. 서버의 일반적인 기능과 운영 시스템을 위한 적절한 구현은 알려져 있거나 상업적으로 이용 가능하며, 특히 본 명세서의 개시 내용에 비추어 이 기술 분야에 통상의 지식을 가진 자에 의해 용이하게 구현된다.

일 실시예에서, 환경은, 통신 링크를 통해, 하나 이상의 컴퓨터 네트워크 또는 직접 연결을 사용하여, 상호 연결되는 여러 컴퓨터 시스템 및 구성 요소를 이용하는 분산 및/또는 가상 컴퓨팅 환경이다. 그러나, 이 기술 분야에 통상의 지식을 가진 자라면 이러한 시스템이 도 7에 도시된 것보다 더 적거나 또는 더 많은 구성 요소를 갖는 시스템에서도 동등하게 작동될 수 있음을 알 수 있을 것이다. 따라서, 도 7에 있는 시스템(700)의 도시는 본질적으로 예시적인 것이며 본 발명의 범위를 제한하지 않는 것으로 간주되어야 한다.

다양한 실시예는 또한 일부 경우에 다수의 애플리케이션 중 임의의 애플리케이션을 작동시키는데 사용될 수 있는, 하나 이상의 사용자 컴퓨터, 컴퓨팅 장치 또는 처리 장치를 포함할 수 있는 다양한 작동 환경에서 구현될 수 있다. 사용자 또는 클라이언트 장치는, 모바일 소프트웨어를 실행하고 다수의 네트워킹 및 메시징 프로토콜을 지원할 수 있는, 셀룰러, 무선 및 핸드헬드 장치뿐만 아니라 표준 운영 시스템을 실행하는, 데스크탑, 랩탑 또는 태블릿 컴퓨터와 같은 다수의 범용 개인용 컴퓨터 중 임의의 것을 포함할 수 있다. 또한, 이러한 시스템은 상업적으로 이용 가능한 다양한 운영 시스템 및 개발 및 데이터베이스 관리와 같은 목적을 위한 다른 알려진 애플리케이션 중 임의의 것을 실행하는 다수의 워크스테이션을 포함할 수 있다. 이들 장치는 또한 네트워크를 통해 통신할 수 있는, 더미 단말기, 씬 클라이언트, 게임 시스템 및 다른 장치와 같은 다른 전자 장치를 포함할 수 있다. 또한 이러한 장치는 네트워크를 통해 통신할 수 있는 가상 머신, 하이퍼바이저 및 기타 가상 장치와 같은 가상 장치를 포함할 수 있다.

본 발명의 다양한 실시예는 전송 제어 프로토콜/인터넷 프로토콜(Transmission Control Protocol/Internet Protocol: "TCP/IP"), 사용자 데이터그램 프로토콜(User Datagram Protocol: "UDP"), 개방형 시스템 상호 연결(Open System Interconnection: "OSI") 모델의 여러 층에서 작동하는 프로토콜, 파일 전송 프로토콜(File Transfer Protocol: "FTP"), 범용 플러그 앤 플레이(Universal Plug and Play: "UpnP"), 네트워크 파일 시스템(Network File System: "NFS"), 공통 인터넷 파일 시스템(Common Internet File System: "CIFS") 및 애플토크(AppleTalk)와 같은 상업적으로 이용가능한 여러 프로토콜 중 임의의 것을 사용하여 통신을 지원하기 위해 이 기술 분야에 통상의 지식을 가진 자라면 친숙할 수 있는 적어도 하나의 네트워크를 사용한다. 이 네트워크는, 예를 들어, 근거리 네트워크, 광역 네트워크, 가상 사설망, 인터넷, 인트라넷, 엑스트라 넷, 공중 교환 전화망, 적외선 네트워크, 무선 네트워크, 위성 네트워크, 및 이들의 임의의 조합일 수 있다.

웹 서버를 이용하는 실시예에서, 웹 서버는 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol: "HTTP") 서버, FTP 서버, 공통 게이트웨이 인터페이스(Common Gateway Interface: "CGI") 서버, 데이터 서버, 자바 서버, 아파치(Apache) 서버 및 비즈니스 애플리케이션 서버를 포함하는 다양한 서버 또는 미드-티어(mid-tier) 애플리케이션 중 임의의 것을 실행할 수 있다. 서버(들)는 또한 자바(Java)

, C, C# 또는 C++ 과 같은 임의의 프로그래밍 언어 또는 루비(Ruby), PHP, 펄(Perl), 파이톤(Python) 또는 TCL과 같은 스크립팅 언어 및 이들의 조합으로 작성된 하나 이상의 스크립트 또는 프로그램으로서 구현될 수 있는 하나 이상의 웹 애플리케이션을 실행함으로써 사용자 장치로부터의 요청에 응답하여 프로그램 또는 스크립트를 실행할 수 있다. 또한 서버(들)는 오라클(Oracle)

, 마이크로소프트(Microsoft)

, 시베이스(Sybase)

및 IBM

로부터 상업적으로 이용가능한 서버뿐만 아니라 MySQL, 포스트그레스(Postgres), SQLite, MongoDB와 같은 오픈 소스 서버, 및 구조화된 데이터 또는 구조화되지 않은 데이터를 저장, 검색 및 액세스할 수 있는 임의의 다른 서버를 포함하지만 이에 국한되지 않는 데이터베이스 서버를 더 포함할 수 있다. 데이터베이스 서버는 테이블 기반 서버, 문서 기반 서버, 구조화되지 않은 서버, 관계형 서버, 비-관계형 서버 또는 이들 및/또는 다른 데이터베이스 서버의 조합을 포함할 수 있다.

환경은 전술한 바와 같이 다양한 데이터 저장소 및 다른 메모리 및 저장 매체를 포함할 수 있다. 이들은 하나 이상의 컴퓨터에 로컬에 있는 (및/또는 상주하는) 저장 매체 또는 네트워크 상의 임의의 또는 모든 컴퓨터로부터 원격에 있는 저장 매체 상의 다양한 위치에 상주할 수 있다. 특정 세트의 실시예에서, 정보는 이 기술 분야에 통상의 지식을 가진 자에게 친숙한 SAN(storage-area network)에 상주할 수 있다. 유사하게, 컴퓨터, 서버 또는 다른 네트워크 장치에 기인한 기능을 수행하는데 필요한 임의의 파일은 적절하게 로컬 및/또는 원격으로 저장될 수 있다. 시스템이 컴퓨터화된 장치를 포함하는 경우, 각각의 이러한 장치는 버스를 통해 전기적으로 결합될 수 있는 하드웨어 요소를 포함할 수 있으며, 상기 요소는 예를 들어 적어도 하나의 중앙 처리 장치(central processing unit: "CPU" 또는 "프로세서"), 적어도 하나의 입력 장치(예를 들어, 마우스, 키보드, 제어기, 터치 스크린 또는 키패드), 및 적어도 하나의 출력 장치(예를 들어, 디스플레이 장치, 프린터 또는 스피커)를 포함한다. 또한, 이러한 시스템은 디스크 드라이브, 광학 저장 장치 및 랜덤 액세스 메모리(random access memory: "RAM") 또는 읽기 전용 메모리(read-only memory: "ROM")와 같은 솔리드 스테이트 저장 장치뿐만 아니라 이동식 미디어 장치, 메모리 카드, 플래시 카드 등과 같은 하나 이상의 저장 장치를 더 포함할 수 있다.

이러한 장치는 또한 전술한 바와 같이 컴퓨터 판독 가능 저장 매체 판독기, 통신 장치(예를 들어, 모뎀, 네트워크 카드(무선 또는 유선), 적외선 통신 장치 등) 및 작업 메모리를 포함할 수 있다. 컴퓨터 판독 가능 저장 매체 판독기는 원격, 로컬, 고정 및/또는 이동식 저장 장치뿐만 아니라 컴퓨터가 읽을 수 있는 정보를 일시적으로 및/또는 보다 영구적으로 포함, 저장, 전송 및 검색하는 저장 매체를 나타내는 컴퓨터 판독 가능 저장 매체에 연결되거나 이를 수용하도록 구성될 수 있다. 이 시스템 및 다양한 장치는 또한 일반적으로, 예를 들어, 클라이언트 애플리케이션 또는 웹 브라우저와 같은 애플리케이션 프로그램 및 운영 시스템을 포함하는, 적어도 하나의 작업 메모리 장치 내에 위치된, 다수의 소프트웨어 애플리케이션, 모듈, 서비스 또는 다른 요소를 포함할 수 있다. 대안적인 실시예는 전술한 것으로부터 많은 변형을 가질 수 있음을 이해해야 한다. 예를 들어, 커스터마이징된 하드웨어가 사용될 수도 있고 및/또는 특정 요소가 하드웨어, 소프트웨어(애플릿과 같은 휴대용 소프트웨어를 포함함) 또는 이 둘 모두로 구현될 수도 있다. 또한, 네트워크 입력/출력 장치와 같은 다른 컴퓨팅 장치에 연결되어 사용될 수 있다.

코드 또는 코드의 일부를 저장하기 위한 저장 매체 및 컴퓨터 판독 가능 매체는, RAM, ROM, 전기적으로 소거 가능한 프로그래밍 가능한 판독 전용 메모리(Electrically Erasable Programmable Read-Only Memory: "EEPROM"), 플래시 메모리 또는 다른 메모리 기술, CD-ROM(Compact Disc Read-Only Memory), DVD(digital versatile disk) 또는 다른 광학 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 다른 자기 저장 장치, 또는 원하는 정보를 저장하는데 사용될 수 있고 시스템 장치에 의해 액세스될 수 있는 임의의 다른 매체를 포함하는, 컴퓨터 판독 가능 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장 및/또는 전송을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비-휘발성, 이동식 및 비-이동식 매체를 포함하지만 이에 국한되지 않는 저장 매체 및 통신 매체를 포함하는, 이 기술 분야에 알려지거나 사용되는 임의의 적절한 매체를 포함할 수 있다. 본 명세서에 제공된 개시 및 교시에 기초하여, 이 기술 분야에 통상의 지식을 가진 자라면 다양한 실시예를 구현하기 위한 다른 방식 및/또는 방법을 이해할 수 있을 것이다.

따라서, 명세서 및 도면은 제한적인 의미라기보다는 예시적인 것으로 간주되어야 한다. 그러나, 특허 청구 범위에 기재된 본 발명의 보다 넓은 사상 및 범위로부터 벗어나지 않으면서 다양한 변형 및 변경이 이루어질 수 있다는 것이 명백할 것이다.

다른 변형은 본 발명의 사상 내에 있다. 따라서, 개시된 기술들은 다양한 변형 및 대안적인 구성을 받을 수 있지만, 그 특정 예시된 실시예들이 도면에 도시되어 있으며, 상기에 상세하게 기술되어 있다. 그러나, 본 발명을 개시된 특정 형태 또는 형태들로 한정하려는 의도는 없으며, 반대로, 본 발명은 첨부된 청구 범위에 한정된 본 발명의 사상 및 범위 내에 있는 모든 변형, 대안적인 구조 및 등가물을 포함하려는 것이다.

개시된 실시예를 기술하는 문맥(특히 이하의 청구 범위의 문맥)에서, 요소 및 "상기" 요소 및 유사한 지시자의 사용은 본 명세서에 달리 언급되거나 문맥에서 명백하게 모순되지 않는 한, 단수 및 복수를 모두 포함하는 것으로 해석되어야 한다. "포함하는", "구비하는", "갖는" 및 "수반하는" 이라는 용어는, 다른 언급이 없는 한, 개방형 용어(즉, "포함하지만 이에 국한되지 않는"을 의미함)로 해석되어야 한다. 수식되지 않았을 때 물리적 연결을 의미하는 "연결된"이라는 용어는, 개입하는 것이 있는 경우에도 부분적으로 또는 전체적으로 내부에 포함되거나 부착되거나 서로 결합된 것으로 해석되어야 한다. 본 명세서에서 값의 범위를 언급하는 것은, 본 명세서에서 달리 지시되지 않는 한, 이 범위 내에 속하는 각각의 개별 값을 개별적으로 언급하는 약식 방법을 나타내기 위한 것이며, 각각의 개별 값은 본 명세서에서 개별적으로 인용된 것처럼 명세서에 통합된다. 문맥에서 달리 언급되거나 모순되지 않는 한, 용어 "세트"(예를 들어, "항목들의 세트") 또는 "서브세트"의 사용은 하나 이상의 요소를 포함하는 비어 있지 않은 집합인 것으로 해석되어야 한다. 또한, 문맥에서 달리 언급되거나 모순되지 않는 한, 대응하는 세트의 "서브세트"라는 용어는 반드시 대응하는 세트의 적절한 서브세트를 나타내는 것은 아니라, 서브세트 및 대응하는 세트는 동일할 수 있다.

"A, B, 및 C 중 적어도 하나" 또는 "A, B 및 C 중 적어도 하나"라는 형태의 어구와 같은 결합 언어는, 구체적으로 달리 언급되거나 문맥에서 명백히 모순되지 않는 한, 항목, 용어 등이 A 또는 B 또는 C이거나 A 및 B 및 C의 세트의 임의의 비어 있지 않은 서브세트일 수 있다는 것을 일반적으로 나타내는 것으로 사용된 것으로 문맥에서 이해된다. 예를 들어, 3개의 요소를 갖는 세트의 예시적인 예에서 "A, B, 및 C 중 적어도 하나"와 "A, B 및 C 중 적어도 하나" 라는 결합 어구는 다음 세트 중 {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C} 중 임의의 하나를 말한다. 따라서, 이러한 결합 언어는 일반적으로 특정 실시예가 A의 적어도 하나, B의 적어도 하나 및 C의 적어도 하나가 각각 존재해야 함을 요구할 것을 의미하는 것으로 의도된 것이 아니다.

본 명세서에 설명된 공정의 작동은, 본 명세서에서 달리 지시되지 않는 한 또는 명백히 문맥에서 모순되지 않는 한, 임의의 적합한 순서로 수행될 수 있다. 본 명세서에 설명된 공정(또는 그 변형 및/또는 조합)은 실행 가능한 명령으로 구성된 하나 이상의 컴퓨터 시스템의 제어 하에 수행될 수 있으며, 하나 이상의 프로세서에서, 하드웨어에 의해 또는 이들의 조합에 의해 집합적으로 실행되는 코드(예를 들어, 실행 가능한 명령, 하나 이상의 컴퓨터 프로그램 또는 하나 이상의 애플리케이션)로서 구현될 수 있다. 이 코드는 예를 들어 하나 이상의 프로세서에 의해 실행 가능한 복수의 명령을 포함하는 컴퓨터 프로그램의 형태로 컴퓨터 판독 가능 저장 매체에 저장될 수 있다. 컴퓨터 판독 가능 저장 매체는 비-일시적인 것일 수 있다.

본 명세서에 제공된 임의의 및 모든 예 또는 예시적인 언어(예를 들어, "와 같은")의 사용은 단지 본 발명의 실시예를 보다 잘 나타내도록 의도된 것이며, 달리 청구되지 않는 한, 본 발명의 범위를 제한하려는 것이 아니다. 명세서에서 어떠한 언어도 임의의 청구되지 않은 요소를 본 발명의 실시에 필수적인 것으로 나타내는 것으로 해석되어서는 안 된다.

본 발명을 실시하기 위해 본 발명자들에게 알려진 최상의 모드를 포함하는 본 발명의 실시예가 본 명세서에 설명된다. 이들 실시예의 변형은 전술한 설명을 읽음으로써 이 기술 분야에 통상의 지식을 가진 자에게 명백할 것이다. 본 발명자들은 이 기술 분야에 통상의 지식을 가진 자가 이러한 변형을 적절하게 사용할 것을 기대하며, 본 발명자들은 본 발명의 실시예들이 본 명세서에 구체적으로 설명된 것과 다르게 실시될 것으로 의도한다. 따라서, 본 발명의 범위는 적용 가능한 법률에 의해 허용되는 바에 따라 본 명세서에 첨부된 청구항에 언급된 주제의 모든 변형 및 등가물을 포함한다. 또한, 본 명세서에서 달리 지시되지 않는 한 또는 문맥에서 명백히 모순되지 않는 한, 모든 가능한 변형에서 전술한 요소의 임의의 조합이 본 발명의 범위에 포함된다.

본 명세서에 인용된 간행물, 특허 출원 및 특허 문헌을 포함하는 모든 문헌은 각각의 문헌이 전체 내용이 개별적으로 및 구체적으로 본 명세서에 기재되고 제시된 것처럼 본 명세서에 병합된다.

본 발명의 실시예는 다음의 항목으로 설명될 수 있다:

1. 컴퓨터-구현 방법으로서,

서비스 제공자의 고객과 관련된 요청자로부터 웹 서비스 요청을 수신하는 단계 - 상기 웹 서비스 요청을 이행하는데 암호화 작동의 수행을 포함함 - ;

상기 웹 서비스 요청의 정보에 적어도 부분적으로 기초하여, 상기 서비스 제공자의 복수의 고객에 대해 상기 서비스 제공자에 의해 관리되는 복수의 암호화 키로부터 암호화 키를 선택하는 단계;

상기 웹 서비스 요청에 적용 가능한 보안 기대치들의 세트를 결정하는 단계 - 상기 보안 기대치의 세트는, 이행될 때 그리고 상기 선택된 암호화 키가 상기 암호화 작동을 수행하는데 사용 가능한지 여부에 관계 없이, 상기 암호화 작동의 결과가 신뢰되는 것임을 나타내는 상기 선택된 암호화 키에 적용 가능한 조건들의 세트를 한정함 - ;

상기 선택된 암호화 키에 대한 상기 보안 기대치들의 세트를 평가하는 단계;

상기 보안 기대치들의 세트를 평가한 것에 적어도 부분적으로 기초하여 상기 웹 서비스 요청에 대한 응답을 생성하는 단계; 및

상기 생성된 응답을 제공하는 단계를 포함하는, 컴퓨터-구현 방법.

2. 제1항에 있어서, 상기 보안 기대치들의 세트는 상기 요청에서 지정되는, 컴퓨터-구현 방법.

3. 제1항 또는 제2항에 있어서,

상기 방법은,

상기 요청에 적용 가능한 정책들의 세트를 결정하는 단계 - 상기 정책들의 세트는 저장된 복수의 정책 문서로부터 온 것임 - ; 및

상기 정책들의 세트가 상기 요청의 이행을 허용하는지를 결정하는 단계를 더 포함하고;

상기 보안 기대치들의 세트를 결정하는 단계는 상기 결정된 정책들의 세트로부터 적어도 하나의 보안 기대치를 결정하는 단계를 포함하는, 컴퓨터-구현 방법.

4. 제3항에 있어서, 상기 방법은,

정책을 수정하기 위해 상기 고객에 의해 허가된 개체로부터, 상기 고객과 관련된 정책들의 세트에 대해 상기 보안 기대치들의 세트를 시행하기 위한 웹 서비스 요청을 수신하는 단계; 및

상기 보안 기대치들의 세트를 포함하도록 상기 정책들의 세트를 수정하는 것에 의해 상기 요청을 이행하는 단계를 더 포함하는, 컴퓨터-구현 방법.

5. 제3항 또는 제4항에 있어서, 상기 암호화 작동은 복호화 또는 디지털 서명 검증인, 컴퓨터-구현 방법.

6. 하나 이상의 서비스를 구현하도록 구성된 적어도 하나의 컴퓨팅 장치를 포함하는 시스템으로서, 상기 하나 이상의 서비스는,

클라이언트로부터 암호화 작동을 수행하라는 요청을 수신하고;

상기 암호화 작동을 수행하기 위한 암호화 키를 결정하고 - 상기 암호화 키는 상기 시스템에 의해 관리되는 암호화 키들의 세트로부터 온 것임 - ;

상기 요청에 포함된 정보에 적어도 부분적으로 기초하여, 상기 암호화 작동의 수행 결과가 상기 클라이언트에 의해 신뢰되어야 하는 조건들의 세트를 결정하고;

상기 암호화 키 및 상기 결정된 조건들의 세트에 적어도 부분적으로 기초하여, 상기 요청에 대한 응답을 생성하고; 그리고

상기 생성된 응답을 클라이언트에 제공하도록 구성된, 시스템.

7. 제6항에 있어서, 상기 하나 이상의 서비스는 상기 적어도 하나의 조건이 상기 요청에서 지정된 결과 상기 조건들의 세트 중 적어도 하나의 조건을 결정하도록 더 구성된, 시스템.

8. 제6항 또는 제7항에 있어서,

상기 클라이언트는 신원으로 인증되고;

상기 하나 이상의 서비스는 적어도 다음:

상기 신원에 적용 가능한 세트 정책들의 서브세트를 선택하고; 그리고

상기 적어도 하나의 조건이 상기 정책들의 세트의 서브세트에서 지정된 결과 상기 조건들의 세트의 적어도 하나의 조건을 결정하는 것

에 의해 상기 조건들의 세트를 결정하도록 구성된, 시스템.

9. 제8항에 있어서,

상기 시스템은 서비스 제공자에 의해 작동되고;

상기 정책들의 세트는 상기 신원과 연관된 상기 서비스 제공자의 고객에 의해 프로그래밍적으로 수정가능한, 시스템.

10. 제6항 내지 제9항 중 어느 한 항에 있어서, 상기 시스템은 상기 암호화 키들의 세트를 하드웨어 기반으로 보호하는 장치이고, 상기 암호화 키는 상기 암호화 키들의 세트로부터 상기 장치로부터 프로그래밍적으로 평문 형태로 보낼 수 없는, 시스템.

11. 제6항 내지 제10항 중 어느 한 항에 있어서,

상기 암호화 키는 서비스 제공자의 제1 고객을 대신하여 상기 시스템에 의해 관리되고;

상기 암호화 키들의 세트는 상기 서비스 제공자의 제2 고객을 대신하여 상기 시스템에 의해 관리되는 제2 암호화 키를 포함하는, 시스템.

12. 제11항에 있어서, 상기 클라이언트는 상기 서비스 제공자의 제3 고객에 의해 작동되는, 시스템.

13. 제6항 내지 제12항 중 어느 한 항에 있어서, 상기 생성된 응답은 상기 조건들의 세트의 평가 결과를 나타내는 정보를 포함하는, 시스템.

14. 제6항 내지 제13항 중 어느 한 항에 있어서, 상기 조건들의 세트는 상기 암호화 키가 신뢰되는 것으로 지정된 암호화 키들의 세트로부터 올 것을 요구하는, 시스템.

15. 실행가능한 명령을 저장한 비-일시적인 컴퓨터-판독가능한 저장 매체로서, 상기 명령은, 컴퓨터 시스템의 하나 이상의 프로세서에 의해 실행될 때, 상기 컴퓨터 시스템으로 하여금,

요청자로부터, 요청에 포함된 정보에 적어도 부분적으로 기초하여 - 상기 요청을 이행하는데 암호화 키를 수반하는 암호화 작동을 수반함 - , 상기 요청자가 상기 암호화 작동의 결과를 신뢰해야 하는지 여부를 결정하기 위해 상기 암호화 키에 적용 가능한 조건들의 세트를 결정하고 - 상기 암호화 키는 상기 암호화 키들의 세트의 대응하는 서브세트를 각각 갖는 복수의 개체에 대해 상기 컴퓨터 시스템에 의해 관리되는 암호화 키들의 세트로부터 오는 것임 - ;

상기 결정된 조건들의 세트를 평가하여 상기 요청을 이행하는 방식을 결정하고; 그리고

상기 결정된 조건들의 세트를 평가하여 상기 암호화 키가 신뢰될 수 있음을 나타낸 결과, 상기 요청에 응답하여 상기 암호화 작동을 수행하고 상기 암호화 작동의 결과를 제공하는

것을 수행하도록 구성된 서비스를 제공하게 하는, 비-일시적인 컴퓨터-판독가능한 저장 매체.

16. 제15항에 있어서, 상기 개체는 상기 컴퓨터 시스템을 작동시키는 서비스 제공자의 고객인, 비-일시적인 컴퓨터-판독가능한 저장 매체.

17. 제15항 또는 제16항에 있어서, 상기 컴퓨터 시스템으로 하여금 상기 조건들의 세트를 결정하게 하는 상기 명령은, 상기 하나 이상의 프로세서에 의해 실행될 때, 상기 시스템으로 하여금, 상기 요청을 제출한 신원과 연관된 정책으로부터 상기 조건들의 세트 중 적어도 하나의 조건을 획득하게 하는, 비-일시적인 컴퓨터-판독가능한 저장 매체.

18. 제15항 내지 제17항 중 어느 한 항에 있어서, 상기 요청은 웹 서비스 요청인, 비-일시적인 컴퓨터-판독가능한 저장 매체.

19. 제15항 내지 제18항 중 어느 한 항에 있어서, 상기 하나 이상의 조건은 상기 암호화 키의 고유 속성에 적어도 부분적으로 기초하는, 비-일시적인 컴퓨터-판독가능한 저장 매체.

20. 제15항 내지 제19항 중 어느 한 항에 있어서, 상기 결정된 조건들의 세트로부터의 적어도 하나의 조건은 상기 요청에 의해 지정되는, 비-일시적인 컴퓨터-판독가능한 저장 매체.

21. 제20항에 있어서, 상기 조건들의 세트는 부울리안 연산자와 연결된 다수의 조건을 포함하는, 비-일시적인 컴퓨터-판독가능한 저장 매체.

22. 제15항 내지 제21항 중 어느 한 항에 있어서, 상기 명령은, 상기 하나 이상의 프로세서에 의해 실행될 때, 상기 컴퓨터 시스템으로 하여금, 상기 결정된 조건들의 세트를 평가하기 위한 전제 조건으로서, 상기 요청에 적용 가능한 정책들의 세트를 평가하게 하는 명령을 더 포함하는, 비-일시적인 컴퓨터-판독가능한 저장 매체.

Claims (15)

1. 컴퓨터-구현 방법으로서,
   서비스 제공자의 고객과 관련된 요청자로부터 웹 서비스 요청을 수신하는 단계 - 상기 웹 서비스 요청의 이행은 상기 웹 서비스 요청에서 결정된 암호화된 데이터에 대한 암호화 작동의 수행을 포함함 - ;
   상기 웹 서비스 요청 내의 정보에 적어도 부분적으로 기초하여, 상기 서비스 제공자의 복수의 고객에 대해 상기 서비스 제공자에 의해 관리되는 복수의 암호화 키로부터 상기 웹 서비스 요청에 관련된 암호화 키를 선택하는 단계;
   상기 웹 서비스 요청에 적용 가능한 보안 기대치들의 세트를 결정하는 단계 - 상기 보안 기대치들의 세트는, 충족될 때 그리고 상기 선택된 암호화 키가 상기 암호화 작동을 수행하는데 사용 가능한지 여부에 관계 없이, 상기 암호화 작동의 결과가 신뢰되는 것을 나타내는 상기 선택된 암호화 키에 적용 가능한 조건들의 세트를 한정함 - ;
   상기 선택된 암호화 키에 대해 상기 보안 기대치들의 세트를 평가하는 단계;
   상기 보안 기대치들의 세트를 평가한 것과 상기 암호화된 데이터에 대한 상기 암호화 작동의 결과에 적어도 부분적으로 기초하여 상기 웹 서비스 요청에 대한 응답을 생성하는 단계; 및
   상기 웹 서비스 요청을 이행하기 위해 상기 생성된 응답을 제공하는 단계를 포함하는, 컴퓨터-구현 방법.
2. 제1항에 있어서, 상기 보안 기대치들의 세트는 상기 요청에서 지정되는, 컴퓨터-구현 방법.
3. 제1항에 있어서,
   상기 방법은,
   상기 요청에 적용 가능한 정책들의 세트를 결정하는 단계로서, 상기 정책들의 세트는 저장된 복수의 정책 문서로부터 온 것인, 상기 요청에 적용가능한 정책들의 세트를 결정하는 단계; 및
   상기 정책들의 세트가 상기 요청의 이행을 허용하는지를 결정하는 단계를 더 포함하되;
   상기 보안 기대치들의 세트를 결정하는 단계는 상기 결정된 정책들의 세트로부터 적어도 하나의 보안 기대치를 결정하는 단계를 포함하는, 컴퓨터-구현 방법.
4. 제3항에 있어서, 상기 방법은,
   정책을 수정하기 위해 상기 고객에 의해 허가된 개체로부터, 상기 고객과 관련된 정책들의 세트에 대해 상기 보안 기대치들의 세트를 시행하기 위한 웹 서비스 요청을 수신하는 단계; 및
   상기 보안 기대치들의 세트를 포함하도록 상기 정책들의 세트를 수정하는 것에 의해 상기 요청을 이행하는 단계를 더 포함하는, 컴퓨터-구현 방법.
5. 제3항에 있어서, 상기 암호화 작동은 복호화 또는 디지털 서명 검증인, 컴퓨터-구현 방법.
6. 하나 이상의 서비스를 구현하도록 구성된 적어도 하나의 컴퓨팅 장치를 포함하는 시스템으로서, 상기 하나 이상의 서비스는,
   요청에서 결정된 암호화된 데이터에 대한 암호화 작동을 수행하도록 상기 요청을 클라이언트로부터 수신하는 동작;
   상기 암호화 작동을 수행하기 위하여 상기 클라이언트와 관련된 암호화 키를 결정하는 동작 - 상기 암호화 키는 상기 시스템에 의해 관리되는 암호화 키들의 세트로부터 온 것임 - ;
   상기 요청에 포함된 정보에 적어도 부분적으로 기초하여, 상기 암호화 작동을 수행한 결과가 상기 클라이언트에 의해 신뢰되어야 하는 조건들의 세트를 결정하는 동작;
   상기 결정된 조건들의 세트 및 상기 암호화된 데이터에 대한 상기 암호화 작동의 결과에 적어도 부분적으로 기초하여, 상기 요청에 대한 응답을 생성하는 동작; 및
   상기 요청을 이행하기 위해 상기 생성된 응답을 상기 클라이언트에 제공하는 동작을 수행하도록 구성된, 시스템.
7. 제6항에 있어서, 상기 하나 이상의 서비스는 상기 적어도 하나의 조건이 상기 요청에서 지정된 결과 상기 조건들의 세트 중 적어도 하나의 조건을 결정하도록 더 구성된, 시스템.
8. 제6항에 있어서,
   상기 클라이언트는 신원(identity)으로 인증되고;
   상기 하나 이상의 서비스는, 적어도,
   상기 신원에 적용 가능한 세트 정책들의 서브세트를 선택하고; 그리고
   상기 적어도 하나의 조건이 상기 정책들의 세트의 상기 서브세트에서 지정된 결과 상기 조건들의 세트의 적어도 하나의 조건을 결정하는
   것에 의해 상기 조건들의 세트를 결정하도록 구성된, 시스템.
9. 제8항에 있어서,
   상기 시스템은 서비스 제공자에 의해 작동되고;
   상기 정책들의 세트는 상기 신원과 연관된 상기 서비스 제공자의 고객에 의해 프로그래밍적으로 수정 가능한, 시스템.
10. 제6항에 있어서, 상기 시스템은 상기 암호화 키들의 세트를 하드웨어 기반으로 보호하는 장치이고, 상기 암호화 키는 상기 암호화 키들의 세트로부터 상기 장치로부터 프로그래밍적으로 평문(plaintext) 형태로는 보낼 수 없는, 시스템.
11. 제6항에 있어서,
    상기 암호화 키는 서비스 제공자의 제1 고객을 대신하여 상기 시스템에 의해 관리되고; 그리고
    상기 암호화 키들의 세트는 상기 서비스 제공자의 제2 고객을 대신하여 상기 시스템에 의해 관리되는 제2 암호화 키를 포함하는, 시스템.
12. 제11항에 있어서, 상기 클라이언트는 상기 서비스 제공자의 제3 고객에 의해 작동되는, 시스템.
13. 제6항에 있어서, 상기 생성된 응답은 상기 조건들의 세트의 평가 결과를 나타내는 정보를 포함하는, 시스템.
14. 제6항에 있어서, 상기 조건들의 세트는 상기 암호화 키가 신뢰된 것으로 지정된 암호화 키들의 세트로부터 온 것임을 요구하는, 시스템.
15. 하나 이상의 서비스를 구현하도록 구성된 적어도 하나의 컴퓨팅 장치를 포함하는 시스템으로서, 상기 하나 이상의 서비스는,
    요청자로부터, 요청에 포함된 정보에 적어도 부분적으로 기초하여 - 상기 요청의 이행은 상기 요청에서 결정된 암호화된 데이터에 대한, 암호화 키를 수반하는 암호화 작동을 수반함 - , 상기 요청자가 상기 암호화 작동의 결과를 신뢰해야 하는지 여부를 결정하기 위해 상기 요청자와 관련된 상기 암호화 키에 적용 가능한 조건들의 세트를 결정하는 동작 - 상기 암호화 키는 암호화 키들의 세트의 대응하는 서브세트를 각각 갖는 복수의 개체에 대해 상기 시스템에 의해 관리되는 상기 암호화 키들의 세트로부터 오는 것임 - ;
    상기 결정된 조건들의 세트를 평가하여 상기 요청을 이행하는 방식을 결정하는 동작; 및
    상기 결정된 조건들의 세트를 평가하여 상기 암호화 키가 신뢰될 수 있음을 나타낸 결과, 상기 요청에 응답하여 상기 암호화된 데이터에 대한 상기 암호화 작동이 수행되도록 하고 상기 암호화된 데이터에 대한 상기 암호화 작동의 결과가 제공되도록 하는 동작
    을 수행하도록 구성된, 시스템.

Images