KR101621128B1 - 보안 관점의 분산 시스템 간의 데이터 전송 제어 - Google Patents

Abstract

데이터 클라우드에서 동작하는 장치를 위한 방법은, 서비스 클라우드에 신뢰 정보를 요청하는 단계; 상기 서비스 클라우드로부터 상기 신뢰 정보를 수신하는 단계; 상기 신뢰 정보에 기반하여 상기 서비스 클라우드의 신뢰 평가를 수행하는 단계; 및 상기 신뢰 평가의 결과에 따라 상기 서비스 클라우드로 데이터를 송신하는 것을 제어하는 단계를 포함한다.

Description

보안 관점의 분산 시스템 간의 데이터 전송 제어{DATA TRANSIT CONTROL BETWEEN DISTRIBUTED SYSTEMS IN TERMS OF SECURITY}

예시적인 실시예에 따른 장치, 방법, 시스템 및 컴퓨터 프로그램 제품은 클라우드 컴퓨팅에 관한 것으로서, 더욱 상세하게는 안전한 클라우드간 데이터 전송(inter-cloud data transfer)을 가능하게 하는 것과 관련된다.

최근, 개인 및 기업체가 인터넷과 같은 네트워크를 통해 데이터를 저장하고 전송하기 위한 유용한 방법으로서 클라우드 컴퓨팅 기술이 발전해 왔다. 클라우드 환경에서, 데이터의 보호(protection) 및 보안(security)은 데이터 소유자들에게 극히 중요한 것이다. 그러나, 클라우드 시스템에 저장된 데이터를 보호하는 것은 어려울 수 있는데, 이는 통상적으로 클라우드 시스템의 데이터 스토리지 설비(data storage facility)들이 데이터 소유자로부터 멀리 떨어진 원격지에 위치하기 때문이다.

데이터 소유자가 하나의 클라우드 시스템으로부터 다른 클라우드 시스템으로 데이터를 전송하기를 바라는 경우 클라우드 환경에서 데이터를 보호하는 일의 어려움은 훨씬 더 커진다. 예를 들어, 데이터 소유자인 어떤 조직은 사설(private) 클라우드 시스템, 가상(virtual) 사설 클라우드 시스템 및 공용(public) 클라우드 시스템을 동시에 사용할 수 있다. 그 조직의 비즈니스 프로세스는 이와 같이 상이한 타입의 클라우드 간의 데이터 전송을 수반할지도 모른다. 나아가, 데이터 소유자는 데이터 소유자의 데이터를 저장하는 클라우드 시스템(데이터 클라우드)과 분리된 클라우드 시스템(서비스 클라우드)에 위치한 서비스의 이용을 원할 수 있다. 이러한 경우, 서비스 클라우드에 의해 제공되는 서비스를 사용하기 위해 데이터 소유자는 데이터 클라우드에 저장된 데이터를 서비스 클라우드에 일시적으로 제공하기를 바랄 수 있다. 그러나, 이러한 데이터 전송은 데이터에 대한 데이터 소유자의 제어 및 가시성(visibility)을 감소시킨다.

관련 기술의 클라우드 보안 솔루션은 클라우드 환경의 다양한 서브-컴포넌트에 집중한다. 그러나, 이러한 관련 기술의 클라우드 보안 솔루션은 단지 통신의 일 종단(end)(예컨대, 데이터 클라우드)을 안전하게 하려고 할 뿐이고, 이는 다른 통신 엔티티(예컨대, 서비스 클라우드)가 공격(attack)에 취약할 수 있다는 점을 고려하면 보안을 보장하기에 충분하지 않다. 데이터가 전송될 타겟 클라우드 시스템의 보안 및 신뢰도를 감정(evaluate)하는 프로세스는 관련 기술의 클라우드 보안 솔루션에는 존재하지 않는다.

따라서, 클라우드간 데이터 전송과 연관된 타겟 클라우드 시스템의 보안 및 신뢰도를 감정할 수 있고 이로써 더욱 안전한 클라우드간 데이터 전송을 가능하게 하는 기법에 대한 필요성이 있다.

하나 이상의 실시예는 위 난점 및 위에서 기술되지 않은 다른 난점을 극복할 수 있다. 그러나, 하나 이상의 실시예가 위에서 기술된 난점을 극복하지 않아도 되고, 위에서 기술된 문제들 중 어느 것도 극복하지 않을 수 있다고 이해된다.

예시적인 실시예는 타겟 클라우드 시스템에서 타겟 서비스의 신뢰 감정(trust evaluation)을 수행함으로써 안전한 클라우드간 데이터 전송을 가능하게 하는 방법 및 장치와 관련된다.

예시적인 실시예는 또한, 알 필요가 있는 것만 최소한으로 알려주는 방식으로(on a minimal, need to know basis) 데이터 클라우드 시스템으로부터 타겟 클라우드 시스템으로 데이터를 제공함으로써 안전한 클라우드간 데이터 전송을 가능하게 하는 방법 및 장치와 관련된다.

따라서, 전송 제어 프레임워크(transit control framework)의 일부로서, 데이터가 하나의 클라우드로부터 다른 클라우드로 전송되기 전에 타겟 클라우드 시스템의 신뢰 감정 및 데이터 필터링을 수행하기 위한 메커니즘이 제안된다.

예시적인 실시예에 따르면, 데이터 클라우드(data cloud)에서 동작하는 장치를 위한 방법으로서, 서비스 클라우드(service cloud)에 신뢰 정보(trust information)를 요청하는 단계; 상기 서비스 클라우드로부터 상기 신뢰 정보를 수신하는 단계; 상기 신뢰 정보에 기반하여 상기 서비스 클라우드의 신뢰 평가(trust assessment)를 수행하는 단계; 및 상기 신뢰 평가의 결과에 따라 상기 서비스 클라우드로 데이터를 송신하는 것을 제어하는 단계를 포함하는 방법이 제공된다.

상기 방법은, 상기 신뢰 평가의 결과가 상기 데이터를 사용하여 타겟 서비스(target service)를 제공하는 상기 서비스 클라우드는 신뢰할 수 있는 것임을 나타내는 경우 상기 서비스 클라우드로 상기 데이터를 송신하는 단계를 더 포함할 수 있다.

상기 데이터 클라우드는 데이터 신뢰 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)를 포함할 수 있고, 상기 신뢰 정보를 요청하는 단계는 상기 데이터 신뢰 API가 상기 서비스 클라우드의 서비스 신뢰 API에 상기 신뢰 정보를 요청하는 단계를 포함할 수 있다.

상기 방법은, 상기 데이터 신뢰 API가 상기 서비스 신뢰 API에 상기 타겟 서비스를 서술하는 서비스 서술 정보(service description information)를 요청하는 단계를 더 포함할 수 있다.

상기 방법은, 상기 데이터 신뢰 API에 의해, 상기 서비스 신뢰 API로부터 상기 서비스 서술 정보를 수신하는 단계를 더 포함할 수 있다.

상기 서비스 신뢰 API는 상기 서비스 클라우드에서 동작하는 서비스 서술 데이터베이스로부터 상기 서비스 서술 정보를 검색할 수 있다.

상기 방법은, 상기 데이터 신뢰 API가, 상기 서비스 클라우드의 상기 신뢰 평가를 수행하는 데에 사용될 보안 파라미터를 식별하기 위해 상기 데이터 클라우드에서 동작하는 타겟 시스템 보안 상태정보 검색(Target System Security Posture Retrieval: TSSPR) 호스트 에이전트(Host Agent: HA)에 요청을 송신하는 단계를 더 포함할 수 있고, 상기 요청은 상기 서비스 서술 정보에 기반한다.

상기 보안 파라미터는 상기 서비스 클라우드에 의해 구현되는 안티바이러스(antivirus) 시스템에 관련된 정보, 상기 서비스 클라우드에 의해 구현되는 로그 파일(log file)에 관련된 정보 및 상기 서비스 클라우드에 의해 구현되는 플랫폼(platform) 및 운영 시스템(Operating System: OS) 중 적어도 하나에 관련된 정보 중에서 선택된 적어도 하나의 타입의 정보를 포함할 수 있다.

상기 플랫폼에 관련된 정보는 하드웨어 설정 정보(hardware configuration information), 서버 정보(server information), 네트워킹 정보(networking information) 및 스토리지 정보(storage information)에 관련된 정보 중 적어도 하나를 포함할 수 있다.

상기 신뢰 정보를 요청하는 단계는, 상기 서비스 신뢰 API에 상기 보안 파라미터를 송신하는 단계를 포함할 수 있고, 상기 보안 파라미터는, 상기 보안 파라미터에 관련된 정보를 모으기 위해 보안 데이터 컴파일러(security data compiler)를 구동할 것을 상기 서비스 클라우드에서 동작하는 TSSPR 원격 에이전트(Remote Agent: RA)에 요청하기 위해 상기 서비스 신뢰 API에 의해 사용된다.

상기 신뢰 정보를 수신하는 단계는, 상기 데이터 신뢰 API가 상기 서비스 신뢰 API로부터 상기 보안 파라미터에 관련된 정보를 수신하는 단계를 포함할 수 있고, 상기 신뢰 평가를 수행하는 단계는, 상기 보안 파라미터에 연관된 정보에 기반하여 신뢰 확인기(trust verifier)를 구동함으로써 상기 신뢰 평가를 시작할 것을 상기 데이터 신뢰 API가 상기 TSSPR HA에 요청하는 단계를 포함할 수 있다.

상기 방법은, 상기 서비스 클라우드는 신뢰할 수 있는 것임을 상기 신뢰 확인기가 나타내는 경우 필터 규칙(filter rule)을 생성할 것을 상기 데이터 클라우드에 있는 뷰 필터 서버(view filter server)에게 상기 데이터 신뢰 API가 지시하는 단계를 더 포함할 수 있다.

상기 뷰 필터 서버는 상기 데이터를 필터링하기 위해 상기 필터 규칙을 동적으로 생성할 수 있다.

상기 뷰 필터 서버는 정책에 관련된 정보에 기반하여 상기 필터 규칙을 생성할 수 있다.

상기 방법은, 상기 뷰 필터 서버가 정책 데이터베이스로부터 상기 정책에 관련된 정보를 획득하는 단계를 더 포함할 수 있다.

상기 뷰 필터 서버는 상기 데이터와 연관된 메타데이터에 기반하여 상기 필터 규칙을 생성할 수 있다.

상기 방법은, 상기 필터 규칙을 사용하여 상기 데이터를 필터링하는 단계; 및 상기 필터링된 데이터를 상기 서비스 클라우드에 직접 송신하는 단계를 더 포함할 수 있고, 상기 필터링된 데이터는 상기 서비스 클라우드의 상기 타겟 서비스와 함께 사용된다.

상기 방법은, 상기 필터 규칙을 사용하여 상기 데이터를 필터링하는 단계; 및 상기 서비스 클라우드로 하여금 URL을 통해 상기 필터링된 데이터를 액세스할 수 있도록 하기 위해 상기 서비스 클라우드에 상기 URL을 제공하는 단계를 더 포함할 수 있고, 상기 필터링된 데이터는 상기 서비스 클라우드의 상기 타겟 서비스와 함께 사용된다.

상기 뷰 필터 서버는 기본(atomic) 필터 규칙 및 카테고리화된(categorized) 필터 규칙의 조합인 복수의 필터 규칙을 생성할 수 있다.

상기 기본 필터 규칙은, 상기 데이터에 대하여 지정된 타입의 정보를 각각 추가, 대체 또는 제거하는 ADD, REPLACE 또는 REMOVE 규칙을 포함할 수 있다.

상기 카테고리화된 필터 규칙은 정책에 기반하여 생성될 수 있다.

상기 데이터 신뢰 API는 복수의 계층을 포함할 수 있고, 상기 방법은, 상기 복수의 계층에 대응하는 복수의 보안 파라미터를 식별할 것을 상기 데이터 신뢰 API가 상기 TSSPR HA에 요청하는 단계를 더 포함할 수 있다.

상기 복수의 계층은, 서비스로서의 인프라스트럭처(Infrastructure as a Service: Iaas) 계층; 서비스로서의 플랫폼 (Platform as a Service: PaaS) 계층; 및 서비스로서의 소프트웨어 (Software as a Service: SaaS) 계층을 포함할 수 있다.

상기 신뢰 정보를 상기 서비스 클라우드에 요청하는 단계, 상기 신뢰 정보를 상기 서비스 클라우드로부터 수신하는 단계 및 상기 신뢰 정보에 기반하여 상기 서비스 클라우드의 상기 신뢰 평가를 수행하는 단계는 제3자 신뢰 조정기(third party trust orchestrator)를 통해 수행될 수 있다.

사용자는 상기 데이터 클라우드와 제1 서비스 레벨 합의(Service Level Agreement: SLA)를 가질 수 있고 상기 서비스 클라우드와 제2 SLA를 가질 수 있다.

다른 예시적인 실시예에 따르면, 사용자에 의해 요청된 타겟 서비스를 제공하는 서비스 클라우드에서 동작하는 장치에 의해 수행되는 방법은 데이터 클라우드에 저장된 상기 사용자의 데이터를 수신하기 위해 사용되고, 상기 방법은, 신뢰 정보에 대한 요청을 상기 데이터 클라우드로부터 수신하는 단계; 상기 신뢰 정보를 상기 데이터 클라우드에 송신하는 단계; 및 상기 신뢰 정보에 기반하여 상기 데이터 클라우드에 의해 수행되는 신뢰 평가의 결과에 따라 상기 데이터 클라우드로부터 상기 데이터를 수신하는 단계를 포함한다.

다른 예시적인 실시예에 따르면, 데이터 신뢰 애플리케이션 프로그래밍 인터페이스 서버는 프로세서(processor); 스토리지(storage); 및 입출력 유닛(input/output unit)을 포함하고, 상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은, 상기 입출력 유닛을 통해, 사용자에 의해 요청된 타겟 서비스를 제공하는 서비스 클라우드에 신뢰 정보를 요청하는 것; 상기 입출력 유닛을 통해, 상기 서비스 클라우드로부터 상기 신뢰 정보를 수신하는 것; 상기 신뢰 정보에 기반하여 상기 서비스 클라우드의 신뢰 평가를 수행하는 것; 및 상기 입출력 유닛을 통해, 상기 신뢰 평가의 결과에 따라 상기 서비스 클라우드로 데이터를 송신하는 것을 제어하는 것을 포함한다.

다른 예시적인 실시예에 따르면, 서비스 신뢰 애플리케이션 프로그래밍 인터페이스 서버는, 프로세서; 스토리지; 및 입출력 유닛을 포함하고, 상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은, 상기 입출력 유닛을 통해, 데이터 클라우드로부터 신뢰 정보에 대한 요청을 수신하는 것; 상기 신뢰 정보를 상기 데이터 클라우드에 송신하는 것; 및 상기 신뢰 정보에 기반하여 상기 데이터 클라우드에 의해 수행되는 신뢰 평가의 결과에 따라 상기 데이터 클라우드로부터 데이터를 수신하는 것을 포함하되, 상기 수신된 데이터는 서비스 클라우드에 저장된 타겟 서비스와 함께 사용된다.

다른 예시적인 실시예에 따르면, 뷰 필터 서버는, 프로세서; 스토리지; 및 입출력 유닛을 포함하고, 상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은, 상기 입출력 유닛을 통해, 서비스 클라우드가 신뢰할 수 있는 것인지 여부를 나타내는 표시를 수신하는 것; 및 상기 표시가 상기 서비스 클라우드는 신뢰할 수 있는 것임을 나타내는 경우, 데이터 클라우드에 저장된 사용자의 데이터를 필터링하기 위한 필터 규칙을 생성하는 것; 상기 필터 규칙을 사용하여 상기 데이터를 필터링하는 것; 및 상기 입출력 유닛을 통해, 상기 필터링된 데이터를 송신하는 것을 포함한다.

다른 예시적인 실시예에 따르면, 신뢰 확인기는, 프로세서; 스토리지; 및 입출력 유닛을 포함하고, 상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은, 상기 입출력 유닛을 통해, 서비스 클라우드의 보안 파라미터에 관련된 정보를 수신하는 것; 상기 정보에 기반하여 상기 서비스 클라우드가 신뢰할 수 있는 것인지 여부에 관한 신뢰 평가를 수행하는 것; 및 데이터 클라우드에 저장된 데이터를 필터링하기 위한 필터 규칙을 생성할 것인지 여부를 판정하기 위해 뷰 필터 서버에 의해 사용될, 상기 신뢰 평가의 결과의 표시를 상기 뷰 필터 서버에 송신하는 것을 포함한다.

다른 예시적인 실시예에 따르면, 보안 데이터 컴파일러는, 프로세서; 스토리지; 및 입출력 유닛을 포함하고, 상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은, 상기 입출력 유닛을 통해, 상기 보안 데이터 컴파일러가 서비스 클라우드의 보안 파라미터에 연관된 정보를 수집할 것을 요청하는 요청을 타겟 시스템 보안 상태정보 검색(Target System Security Posture Retrieval: TSSPR) 원격 에이전트(Remote Agent: RA)로부터 수신하는 것; 상기 요청된 정보를 수집하는 것; 및 상기 입출력 유닛을 통해, 상기 TSSPR RA로 하여금 상기 요청된 정보를 데이터 클라우드에 송신할 수 있도록 하기 위해 상기 요청된 정보를 상기 TSSPR RA에 송신하는 것을 포함한다.

다른 예시적인 실시예에 따르면, 타겟 시스템 보안 상태정보 검색 호스트 에이전트는, 프로세서; 스토리지; 및 입출력 유닛을 포함하고, 상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은, 상기 입출력 유닛을 통해, 서비스 클라우드의 신뢰 평가를 수행하는 데 사용될 보안 파라미터의 식별을 요청하는 요청을 데이터 신뢰 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API) 서버로부터 수신하는 것; 상기 보안 파라미터를 식별하는 것; 및 상기 입출력 유닛을 통해, 상기 식별된 보안 파라미터를 상기 데이터 신뢰 API 서버에 송신하는 것을 포함한다.

다른 예시적인 실시예에 따르면, 타겟 시스템 보안 상태정보 검색 원격 에이전트는, 프로세서; 스토리지; 및 입출력 유닛을 포함하고, 상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은, 상기 입출력 유닛을 통해, 보안 파라미터에 연관된 정보를 수집하기 위해 보안 데이터 컴파일러의 구동을 요청하는 요청을 서비스 신뢰 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API) 서버로부터 수신하는 것; 상기 보안 데이터 컴파일러를 구동하는 것; 상기 입출력 유닛을 통해, 상기 보안 데이터 컴파일러에 의해 수집된 정보를 수신하는 것; 및 상기 입출력 유닛을 통해, 상기 보안 데이터 컴파일러에 의해 수집된 상기 정보를 상기 서비스 신뢰 API 서버에 송신하는 것을 포함한다.

도 1은 예시적인 실시예에 따른 클라우드 컴퓨팅 시스템을 도시한다.
도 2는 도 1에 도시된 클라우드 컴퓨팅 시스템의 상세도를 도시한다.
도 3은 예시적인 실시예에 따른 클라우드간 데이터 전송의 방법 및 알고리즘을 도시한다.
도 4는 예시적인 실시예에 따라 신뢰 평가 프로세스를 수행하는 방법 및 알고리즘을 도시한다.
도 5는 예시적인 실시예에 따라 뷰 필터 규칙을 생성하는 방법 및 알고리즘을 도시한다.
도 6은 다른 예시적인 실시예에 따른 클라우드 컴퓨팅 시스템을 도시한다.
도 7은 예시적인 실시예를 단순화된 도해 형태로 보여준다.
도 8은 구체적인 구현의 예시적인 실시예를 단순화된 도해 형태로 보여준다.

첨부된 도면을 참조하여 아래에서 더욱 상세하게 실시예들이 기술된다. 이하의 상세한 설명은 독자가 본 명세서에서 기술된 방법, 장치 및/또는 시스템을 포괄적으로 이해하는 것을 돕기 위해 제공된다. 따라서, 본 명세서에서 기술된 시스템, 장치 및/또는 방법의 다양한 변경, 수정 및 등가물이 당업계에서 통상의 지식을 가진 자에게 시사될 것이다. 또한, 공지의 기능 및 구성의 설명은 명확성 및 간결성을 더하기 위해 생략될 수 있다.

상세한 설명에서 사용되는 용어는 단지 실시예를 기술하기 위한 것이고, 결코 제한적이어서는 안 된다. 명확하게 달리 사용되지 않는 한, 단수 형태의 표현은 복수 형태의 의미를 포함한다. 본 설명에서, “포함” 또는 “구비”와 같은 표현은 특성, 숫자, 단계, 동작, 요소, 그 일부 또는 조합을 가리키기 위한 것이고, 하나 또는 그 이상의 다른 특성, 숫자, 단계, 동작, 요소, 그 일부 또는 조합의 임의의 존재 또는 가능성을 배제시키도록 해석되어서는 안 된다.

예시적인 실시예는 타겟 서비스의 신뢰 감정을 수행하고 이어서 알 필요가 있는 것만 최소한으로 알려주는 방식으로 요구되는 데이터를 타겟 서비스에 제공하는 것에 의해 안전한 클라우드간 데이터 전송을 가능하게 한다. 이를 달성하기 위해, 예시적인 실시예는 소정의 보안 정보가 타겟 서비스 플랫폼에서 수집되고 추가적인 프로세싱이 사용자 데이터를 호스팅하는 데이터 클라우드에서 수행되는 기법을 제공한다. 따라서, 두 클라우드 시스템 모두 안전한 클라우드간 데이터 전송을 보장하는 데 능동적으로 관련된다.

도 1은 예시적인 실시예에 따른 클라우드 컴퓨팅 시스템을 도시한다. 도 1에 나타낸 바와 같이, 클라우드 컴퓨팅 시스템(10)은 클라우드 고객(20), 데이터 클라우드 시스템(100)(이하에서 “데이터 클라우드(100)”이라고도 지칭됨) 및 서비스 클라우드 시스템(200)(이하에서 “서비스 클라우드(200)”이라고도 지칭됨)을 포함한다. 클라우드 고객(20)은 연결(30)을 통해 데이터 클라우드(100)에 연결된다. 클라우드 고객(20)은 연결(40)을 통해 서비스 클라우드(200)에 연결된다. 데이터 클라우드(100)는 연결(50)을 통해 서비스 클라우드(200)에 연결된다.

예시적인 실시예에서, 클라우드 고객(20)은 개인 사용자 또는 기업 엔티티(Enterprise entity)와 같은 법인 중 하나이다. 예를 들어, 클라우드 고객(20)은 데이터 클라우드(100)에 자신의 데이터를 저장하는 개인 데이터 소유자일 수 있다. 대안적으로, 클라우드 고객(20)은 예컨대 데이터 클라우드(100)에 의료 기록을 유지하는 건강 보험 회사와 같은 법인일 수 있다. 클라우드 고객(20)은 예컨대 월드 와이드 웹(World Wide Web: WWW) 인터페이스를 통하는 등 다양한 방식으로 데이터 클라우드(100) 및 서비스 클라우드(200)를 액세스할 수 있다.

클라우드 고객(20)이 개인 인터넷 사용자인 경우, 클라우드 고객(20)은 데스크톱 컴퓨터, 랩톱 컴퓨터, 모바일 폰 등과 같은 그 사용자의 개인용 전자 장치 상에서 제공되는 사용자 인터페이스(예컨대, WWW 인터페이스)를 통해 데이터 클라우드(100)에 저장된 데이터 및 서비스 클라우드(200)에 의해 제공되는 서비스를 액세스할 수 있다.

클라우드 고객(20)이 기업 엔티티와 같은 법인인 경우, 클라우드 고객(20)은 클라이언트 컴퓨터로부터 액세스 가능한 클라우드 제공자 인터페이스를 통해 또는 클라우드 중개자 인터페이스를 통해 데이터 클라우드(100)에 저장된 데이터 및 서비스 클라우드(200)에 의해 제공되는 서비스를 액세스할 수 있다. 기업 엔티티의 요구 사항에 따라, 액세스는 여러 다른 방법으로 제공될 수도 있다.

예시적인 실시예에서, 데이터 클라우드(100), 서비스 클라우드(200) 또는 제3자 엔티티(third-party entity)는 클라우드간 데이터 전송을 요구하는 클라우드 고객(20)의 신원(identity)을 확인하기 위해 클라우드 고객(20)의 장치 상에서 확인 절차를 수행할 수 있다. 그러한 확인은 예컨대 암호를 입력하는 등의 여러 상이한 기법을 사용하여 수행될 수 있다.

예시적인 실시예에 따르면, 클라우드 고객(20) 및 데이터 클라우드(100)(데이터 클라우드(100)의 대표자(representative)를 통해)는 클라우드 고객(20)이 데이터 클라우드(100)에 의해 제공되는 데이터 스토리지 서비스(data storage service)들을 사용하기 위한 액세스를 승인 받는 합의에 들어간다. 그 합의는 예컨대 서비스 레벨 합의(Service Level Agreement: SLA)일 수 있다. 그 SLA는 여러 가지 상이한 타입의 조항을 가질 수 있다. 예를 들어, 그러한 SLA는 수수료의 대가로 클라우드 고객(20)이 데이터 클라우드(100)의 대표자에 의해 소유 내지 동작되는 스토리지 설비에 데이터를 저장하는 것을 인가할 수 있다.

클라우드 고객(20)은 연결(30)을 통해 데이터 클라우드(100)를 액세스한다. 예시적인 실시예에서, 연결(30)은 유선 및/또는 무선 연결 장치를 사용하여 인터넷 상에서 수립된다. 클라우드 고객(20)은 연결(30)을 통해 데이터 클라우드(100)의 스토리지 설비로 및/또는 데이터 클라우드(100)의 스토리지 설비로부터 데이터를 송신 및/또는 수신할 수 있다.

예시적인 실시예에 따르면, 클라우드 고객(20) 및 서비스 클라우드(200)(서비스 클라우드(200)의 대표자를 통해)는 클라우드 고객(20)이 서비스 클라우드(200)에 의해 제공되는 서비스를 사용하기 위한 액세스를 승인 받는 합의에 들어간다. 예를 들어, 클라우드 고객(20) 및 서비스 클라우드(200)의 대표자는 서비스 레벨 합의(SLA)에 들어갈 수 있다. 그 SLA는 여러 가지 상이한 타입의 조항을 가질 수 있다. 예를 들어, 그러한 SLA는 수수료의 대가로 클라우드 고객(20)이 서비스 클라우드(200)에 의해 제공되는 다양한 서비스를 사용하는 것을 인가할 수 있다.

클라우드 고객(20)은 연결(40)을 통해 서비스 클라우드(200)를 액세스한다. 예시적인 실시예에서, 연결(40)은 유선 및/또는 무선 연결 장치를 사용하여 인터넷 상에서 수립된다. 클라우드 고객(20)은 연결(40)을 통해 서비스 클라우드에 의해 수행되는 서비스를 요청할 수 있고, 나아가 연결(40)을 통해 서비스의 결과를 수신할 수 있다.

데이터 클라우드(100) 및 서비스 클라우드(200)는 연결(50) 상에서 서로 통신한다. 예시적인 실시예에서, 연결(50)은 유선 및/또는 무선 연결 장치를 사용하여 인터넷 상에서 수립된다. 데이터 클라우드(100) 및 서비스 클라우드(200)는 연결(50) 상에서 서로 통신하고 요청되는 정보를 교환한다.

도 2는 도 1에 도시된 클라우드 컴퓨팅 시스템의 상세도를 도시한다. 도 2에 나타낸 바와 같이, 데이터 클라우드(100)는 데이터 서버(102), 타겟 시스템 보안 상태정보 검색(Target System Security Posture Retrieval: TSSPR) 호스트 에이전트(Host Agent: HA)(104), 신뢰 확인기(trust verifiers)(106), 뷰 필터 서버(view filter server)(108), 데이터 신뢰 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)(110), 정책 데이터베이스(112), 서비스 레벨 합의(SLA) 데이터베이스(114) 및 데이터 클라우드(100) 내 다양한 컴포넌트들을 연결하는 복수의 연결(120)을 포함한다.

데이터 서버(102)는 클라우드 고객(20)의 데이터를 저장하도록 구성된다. 데이터 서버(102)는 예컨대 복수의 메모리 장치로서 구현되는 등 다양한 방식으로 구현될 수 있다. 여러 상이한 타입의 정보가 데이터 서버(102)에 저장될 수 있다. 예를 들어, 클라우드 고객(20)이 건강 보험 회사인 경우, 데이터 서버(102)는 건강 보험 회사의 보험에 가입한 고객들의 의료 기록을 저장하고 유지하는 데 이용될 수 있다.

추가적으로, 예시적인 실시예에서, 데이터 서버(102)는 클라우드 고객(20)의 저장된 데이터와 관련된 데이터인 메타데이터(102a)를 저장한다. 예시적인 실시예에서, 메타데이터(102a)는 그 메타데이터에 대응하는 저장된 데이터가 준수하도록 요구되는 정책 내지 정책들의 그룹을 나타낸다. 저장된 데이터가 상이한 타입의 정책들을 준수하도록 요구될 수 있다. 소정의 타입의 데이터는 매우 민감하며, 특정 정책을 준수하도록 법률적으로 요구될 수 있다. 예를 들어, 환자의 의료 기록은 매우 민감한 정보이며, 1996년의 건강 보험 이동성 및 책임 법률(Health Insurance Portability and Accountability Act of 1996)(이하에서 “HIPAA”라고도 지칭됨) 과 같은 소정의 의료 규정을 준수할 것이 요구될 수 있다. HIPAA는, 예를 들어 환자의 의료 기록에 대한 액세스가 소정의 타입의 외부 엔티티에게 승인될 수 있는지 및 어느 정도까지 승인될 수 있는지를 포함하여, 의료 기록의 여러 가지 측면을 규제한다. 따라서, 예컨대 클라우드 고객(20)이 건강 보험 회사이고 그 건강 보험 회사의 보험에 가입한 환자의 의료 기록을 저장하는 경우, 그와 같이 저장된 데이터에 대응하는 메타데이터는 저장된 데이터가 의료 기록을 포함한다는 것을 나타내고 나아가 의료 기록은 HIPAA를 준수하여야 한다는 것을 나타낸다.

데이터 신뢰 API(110)는 서비스 클라우드(200)에 상주하는 서비스 신뢰 API(210) 및 데이터 클라우드(100) 간 통신을 위한 인터페이스로서의 역할을 한다. 예시적인 실시예에서, 데이터 신뢰 API(110)는 소프트웨어의 모듈 부분들(클라우드내 및 클라우드간 통신을 수립하기 위한 로직을 구비함)을 포함한다. 데이터 신뢰 API(110)는 또한 소프트웨어의 모듈 부분들을 실행하기 위해 프로세서와 같은 하드웨어의 여러 부분을 포함할 수 있다. 데이터 신뢰 API(110)는 데이터 클라우드(100)의 여러 컴포넌트를 직접적으로 또는 간접적으로 구동함으로써 데이터 클라우드(100) 내 여러 프로세스를 제어하도록 구성된다.

데이터 신뢰 API(110)는 타겟 서비스(202)를 서술하는 서비스 서술 정보를 획득하기 위해 서비스 클라우드(200) 내의 서비스 신뢰 API(210)와 메시지를 교환하도록 구성된다. 데이터 신뢰 API(110)는 또한 타겟 서비스(202)의 신뢰 평가(trust assessment)을 수행하기 위해 요구되는 보안 파라미터(“신뢰 정보”라고도 지칭됨)를 판정하도록 TSSPR HA(104)와 메시지를 교환하도록 구성된다. 예시적인 실시예에서, 보안 파라미터를 식별하는 이러한 프로세스가 서비스 클라우드(200) 내의 IaaS, PaaS 및 SaaS 계층을 포함하는 상이한 계층에 대하여 수행된다.

예시적인 실시예에 따르면, 데이터 신뢰 API(110)는 계층화된(layered) 신뢰 API 또는 비-계층화(non-layered) 신뢰 API 중 어느 하나로서 구현될 수 있다. 예를 들어, 데이터 신뢰 API(110)는 서비스로서의 소프트웨어(Software as a Service: Saas) 계층, 서비스로서의 플랫폼(Platform as a Service: PaaS) 계층 및 서비스로서의 인프라스트럭처(Infrastructure as a Service: IaaS) 계층에 각각 대응하는 3개의 계층을 구비한 계층화된 신뢰 API로서 구현될 수 있다. 타겟 서비스(202)의 신뢰 평가를 하기 위해 SaaS, PaaS 및 IaaS 서비스 제공자들로부터의 신뢰 감정에 요구되는 보안 파라미터를 분류하는 데에 그 계층들이 사용된다. 데이터 신뢰 API(110)는 데이터 신뢰 API(110)가 요구하는 보안 파라미터의 통합된 리스트를 서비스 신뢰 API(210)에 전송할 수 있다. 대안적으로, 데이터 신뢰 API(110)가 서비스 신뢰 API(210)에 요청하는 보안 파라미터의 리스트는 IaaS, Paas 및/또는 SaaS 서비스 프레임워크 컴포넌트의 서브세트(subset)를 포함할 수 있다.

TSSPR HA(104)는 타겟 서비스(202)의 신뢰 감정을 위한 보안 파라미터를 식별하고 신뢰 확인기(106)을 호출함으로써 신뢰 평가 프로세스를 돕는다.

TSSPR HA(104)는 어느 보안 파라미터를 타겟 서비스(202)에 요청할 것인지 판정하기 위한 여러 상이한 방법을 사용할 수 있다. 예를 들어, 특정한 법률, 규제 또는 그 밖의 기업 정책 내지 개인 정책은 대응하는 보안 파라미터와 연관될 수 있다. 이 경우, 타겟 서비스(202)에 의해 요청되는 데이터(또는 그 데이터와 연관된 메타데이터)를 분석한 후, 요청된 데이터의 제공이 특정한 법률, 규제 또는 그 밖의 기업 정책 내지 개인 정책을 준수할 필요가 있다고 TSSPR HA(104)가 판정하면, TSSPR HA(104)는 타겟 서비스(20)에 요청될 대응하는 보안 파라미터를 판정할 수 있다. 대안적으로, 데이터의 보안 레벨(예컨대, 기밀(confidential), 비밀(secret), 극비(top secret))을 달리 하는 것은 대응하는 보안 파라미터와 연관될 수 있다. 이 경우, 데이터의 보안 레벨을 판정한 후, TSSPR HA(104)는 타겟 서비스(202)에 요청될 대응하는 보안 파라미터를 판정할 수 있다. 그 밖의 많은 타입의 대응관계가 또한 가능하다. 보안 파라미터 및 다른 기준(예컨대, 정책, 보안 레벨 등) 간의 대응관계는 TSSPR HA(104) 또는 다른 데이터베이스에 저장될 수 있다.

예를 들어, 타겟 서비스(202)가 의료 기록을 데이터 서버(202)에 요청하는 경우, TSSPR HA(104)는 특정 정책(예컨대, HIPAA)에 기반하여 다음과 같은 보안 파라미터가 타겟 서비스(202)에 요청될 것이라고 판정할 수 있다: 하드웨어 설정 정보(hardware configuration information), SaaS가 호스팅되는 서버 정보, 운영 시스템 무결성(operating system integrity), 소프트웨어 버전, 안티-바이러스 소프트웨어 및 버전, 보안 패치 업데이트 정보, 네트워킹 정보(networking information), 그리고 스토리지 정보(storage information). 나아가, TSSPR HA(104)에 의해 식별되는 보안 파라미터는 데이터 신뢰 API(110)에 의해 Iaas, PaaS 및 SaaS 계층의 파라미터로 카테고리화될 수 있다. 이 경우, 데이터 신뢰 API(110)는 하드웨어 설정 정보, SaaS가 호스팅되는 서버 정보, 네트워킹 정보 및 스토리지 정보를 IaaS 계층 보안 파라미터로 분류하고, 운영 시스템 무결성 및 안티-바이러스 소프트웨어 및 버전을 PaaS 계층 보안 파라미터로 분류하며, 소프트웨어 버전 및 보안 패치 업데이트 정보를 SaaS 계층 정보로 분류한다. 보안 파라미터를 계층별로 분류한 후, 데이터 신뢰 API(110)는 소정의 요청을 서비스 신뢰 API(210)에 전송하여 보안 파라미터를 요청하고 특정 보안 데이터 컴필레이션 프로세스(security data compilation process)의 개시를 요청한다.

TSSPR HA(104)는 신뢰 확인기(106)로부터 획득되는 확인 프로세스의 결과에 기반하여 타겟 서비스(102)의 보안 상태정보(security posture)에 대한 판정을 내릴 수 있다. 이 판정(“신뢰 평가”라고도 지칭됨)은 데이터 전송이 계속될 것인지 아니면 중단될 것인지를 판정한다. 이 판정이 긍정적(positive)인 경우, 신뢰 평가 결과, 서비스 서술 및 요청된 데이터에 대한 포인터를 뷰 필터 서버(108)에 전송함으로써 데이터 신뢰 API(110)에 의해 뷰 필터 생성(view filter creation)의 절차가 개시된다.

신뢰 확인기(106)는 서비스 클라우드(200)로부터 전송되고 TSSPR HA(104)로부터 신뢰 확인기(106)에 입력되는 신뢰 정보를 이용하여 서비스 클라우드(200)의 신뢰 평가를 수행하는 것을 책임진다. 예시적인 실시예에서, 신뢰 확인기(106)는 서비스 클라우드(200)의 상이한 계층들, 예컨대 서비스로서의 플랫폼(PaaS) 계층, 서비스로서의 인프라스트럭처(IaaS) 계층 및 서비스로서의 소프트웨어(SaaS) 계층에 대해 특정한 보안 관련 정보의 확인 프로세스를 수행한다. 상이한 타입의 정보가 계층들 간에 중복될 수 있다고 여겨지기는 하나, 이러한 계층들 각각은 상이한 타입의 정보를 포함할 수 있다.

예를 들어, 신뢰 확인기(106) 중 하나는 서비스로서의 인프라스트럭처(IaaS) 계층으로 분류되는 보안 파라미터에 대하여 신뢰 확인을 수행하도록 구성될 수 있고, 예컨대 하드웨어 설정 정보, 서버 정보, 네트워킹 정보 또는 스토리지 정보와 같은 다양한 IaaS 계층 파라미터와 관련된 보안 관련 정보를 확인할 수 있다.

또한, 신뢰 확인기(106)는 서비스 클라우드(200)에 있어서 서비스로서의 플랫폼(PaaS) 계층에 특정적인 보안 정보에 대하여 확인 프로세스를 수행할 수 있다. PaaS 계층에 특정적인 보안 정보는 예컨대 서비스 클라우드(200)의 안티바이러스/침입 감지 시스템(Intrusion Detection System: IDS)/방화벽과 관련된 정보를 포함할 수 있다. 예를 들어, 하나의 신뢰 확인기(106)는 보고된 안티바이러스 정의의 '최종 업데이트된' 날짜를 체크하고 임의의 원치 않는 컨텐츠에 대한 안티바이러스 툴 보고(antivirus tool report)(예컨대, 멀웨어(malware)가 식별되었는지 여부)를 체크할 수 있다.

PaaS 계층에 특정적인 보안 정보는 예컨대 서비스 클라우드(200)의 안티바이러스/침입 감지 시스템(Intrusion Detection System: IDS)/방화벽과 관련된 정보를 포함할 수 있다. 예를 들어, 신뢰 확인기(106)는 보고된 안티바이러스 정의의 '최종 업데이트된' 날짜를 체크하고 임의의 원치 않는 컨텐츠에 대한 안티바이러스 툴 보고(예컨대, 멀웨어가 식별되었는지 여부)를 체크할 수 있다.

신뢰 확인기(106)는 또한 로그 파일 체킹(log file checking)을 수행할 수 있다. 서비스 클라우드(200)의 로그 파일은 두 가지 상이한 종류의 정보를 포함할 수 있는데, 이는 어느 사용자가 서비스 클라우드(200)의 프로세스, 파일 및 시스템에 액세스하였는지를 보여주는 액세스 로그(access logs) 및 서비스 클라우드(200)에서 실행 중인 애플리케이션 및 프로그램에 관한 정보를 포함하는 프로그램 론치 및 상태 로그(program launch and status logs)이다. 위 로그 파일은 SaaS 계층 보안 정보의 예이다. 정적 플랫폼 설정 정보 보고(static platform configuration information reporting)(예컨대, 하드웨어 컴포넌트, 인터페이스, 연결, 대역폭 및 스토리지 능력)의 경우, 로그 파일 체킹은 또한 Iaas 계층 관련 정보를 다룰 수 있다.

이러한 두 가지 타입의 정보(액세스 로그, 그리고 프로그램 론치 및 상태 로그)는 하나의 신뢰 확인기(106)에 의해 감정될 수 있다. 액세스 로그 파일에 대하여, 감사 이력(audit trail)이 생성될 수 있도록 그 신뢰 확인기(106)는 데이터베이스로의 각 액세스가 인증(authenticated)되고 인가(authorized)되어 있는지 체크한다.

프로그램 론치 및 상태 로그 파일에 대하여, 위 신뢰 확인기(106)는 소프트웨어가 안전한 버전으로 업데이트되었는지 확인한다. 그 신뢰 확인기(106)는 이 확인을 다양한 방식으로 수행할 수 있다. 예를 들어, 그 신뢰 확인기(106)는 이용가능한 데이터베이스 및/또는 알려진 취약점과 관련된 정보를 포함하는 다른 정보 소스, 예컨대 CVE(Common Vulnerabilities and Exposures) 데이터베이스, NVD(National Vulnerabilities Database), US-CERT 경보(U.S. Computer Emergency Readiness Team alerts), OSVDB(Open Source Vulnerability Database)에 질의할 수 있을 것이다. 서비스 클라우드(200)에 의해 사용되는 것으로 보고된 소프트웨어 패키지 중 임의의 소프트웨어 패키지가 활성(active) 또는 패치되지 않은(unpatched) 취약점 내지 익스플로잇(exploit)을 가진 것으로 데이터베이스/정보 소스에 의해 식별되면, 타겟 서비스(202)는 신뢰할 수 없는 것으로 간주하여야 하고 데이터는 타겟 서비스(202)로 전송되지 않아야 한다. 위 신뢰 확인기(106)는 또한 보고된 소프트웨어 버전을 계속 추적하고 규칙적으로 취약점 데이터베이스/정보 소스를 체크하며, 이전에 보고된 소프트웨어 패키지 중 임의의 소프트웨어 패키지가 취약점을 나타내면 클라우드 소비자(20)에 알린다.

신뢰 확인기(106)는 또한 지속적인 로그 파일 모니터링을 수행할 수 있다. 이 경우, 하나의 신뢰 확인기(106)는 서비스 클라우드(200)에 데이터가 전송된 이후 미리 설정된 시구간 동안 로그 파일 변경을 지속적으로 모니터링하도록 구성될 수 있다. 이 특징은 그 신뢰 확인기(106)로 하여금 서비스 클라우드(200)의 시스템 로그 파일의 최신 뷰(view)를 지속적으로 획득할 수 있도록 한다. 이는 예컨대 로그 파일 변경을 나타내는 통지 업데이트를 데이터 클라우드(100)에 전송하는 서비스 클라우드(200)에 의해 수행될 수 있다. 로그 파일의 지속적인 모니터링 확인은 데이터 클라우드(100)로 하여금 액세스 로그에서 흔하지 않은 행동 패턴 또는 소프트웨어 로그에서 소프트웨어 변경에 신속하게 반응할 수 있도록 한다. 예시적인 실시예에 따르면, 정보는 서비스 클라우드(200)로부터 신뢰 확인기(106)로 포스팅되거나(posted) 아니면 신뢰 확인기(106)에 의해 서비스 클라우드 로그 정보 종단점(endpoint)로부터 풀링된다(pulled).

신뢰 확인기(106)는 또한 플랫폼 및 운영 시스템(OS) 신뢰 상태 보고 및 감정을 수행할 수 있다. 예시적인 실시예에서, 신뢰 확인기(106)에 의해 수행되는 플랫폼 및 운영 시스템 신뢰 상태 보고 및 감정 절차는 Trusted Computing Group™ 시스템 원격 입증(Trusted Computing Group™ system remote attestation) 방법과 유사하다. 이 경우, 하나의 신뢰 확인기(106)는 하드웨어 설정 정보, 서버 정보, 네트워킹 정보, 스토리지 정보 등과 같은 IaaS 계층에 특정적인 보안 상태 정보 모두를 확인할 수 있고, 그 밖의 보안 상태 정보로부터 얻을 수 있는 신뢰 레벨을 감정하기 위한 기초를 쌓을 수 있다(예컨대, 로그파일 정보의 신뢰도는 신뢰되고 입증된(trusted and attested) PaaS 상에서 더 높을 수 있다).

따라서, 예시적인 실시예에 따르면, 각 데이터 타입에 대하여 확인을 수행하는 별개의 모듈들(신뢰 확인기(106))이 있을 수 있도록 확인 시스템이 모듈 방식으로 구축된다. 확장 가능한 이 아키텍처는 사용자로 하여금 필요에 따라 상이한 신뢰 확인기(106)에 접속(plug)하도록 한다. 예시적인 실시예에서, 한 신뢰 확인기(106)의 결과는 2진 판정에 대한 2진 결과(합격(passed), 불합격(failed)), 아니면 1) 추가적인 보안 상태정보 데이터에 대한 필요성, 2) 누락된 확인 정보, 3) 신뢰 확인에서 주의가 필요한 다른 에러, 또는 4) 필터의 생성을 위해 필터링 프로세스에 추가적인 입력을 제공하는 것을 나타내는 더욱 상세한 리턴 값일 수 있다.

뷰 필터 서버(108)는 데이터 서버(102)에 저장된 데이터를 필터링하고 데이터 신뢰 API(110)에 필터링된 데이터를 제공하여 데이터 신뢰 API(110)로 하여금 필터링된 데이터를 타겟 서비스(202)에 전달할 수 있도록 하는 기능을 수행한다. 뷰 필터 서버(108)는 다양한 타입의 정보에 기반하여 적어도 하나의 데이터 뷰 필터(108a)(“필터 규칙”이라고도 지칭됨)을 생성하고, 데이터 서버(102)에 저장된 데이터를 필터링하는 데에 데이터 뷰 필터(108a)를 사용한다. 예시적인 실시예에서, 오직 최소한으로 필요한 양의 데이터가 데이터 클라우드(100)로부터 서비스 클라우드(200)로 전송되는 것을 보장하기 위해 뷰 필터 서버(108)는 데이터를 필터링한다.

신뢰 평가의 결과에 기반하여, 뷰 필터 서버(108)는 데이터 신뢰 API(110)로부터 명령(command)을 수신하여 필터 규칙(108a)의 생성을 시작한다. 예컨대, 타겟 서비스(202)를 서술하는 서비스 서술 정보, 신뢰 확인기(106)에 의해 판정된 신뢰 평가 결과 및 메타데이터(102b)가 나타내는 정책을 포함하는 다양한 기준에 기초하여, 뷰 필터 서버(108)는 필터 규칙(108a)을 생성한다. 뷰 필터 서버(108)는 요청된 데이터 및 대응하는 메타데이터를 데이터 서버(102)로부터 가지고 온다(fetch). 이어서, 데이터 신뢰 API(110)에 의해 제공되는 입력에 기반하여, 뷰 필터 서버(108)는 동적으로 필터 규칙(108a)을 생성한다. 예시적인 실시예에서, 뷰 필터 서버(108)는 또한 요청된 데이터의 메타데이터(102a)를 정책 데이터베이스(112)에 맵핑한 결과로서 획득되는 추가적인 규칙을 생성할 수 있다.

예시적인 실시예에서, 뷰 필터 서버(108)는 근본적인 기본(atomic) 필터를 카테고리화된 필터와 결합함으로써 필터 규칙(108a)을 생성한다. 근본적인 기본 필터의 예는, 예컨대 데이터 기록 내의 사람의 이름을 각각 제거, 추가 및 대체하는 REMOVE, ADD 및 REPLACE를 포함한다. 카테고리화된 필터의 예는 데이터와 연관된 소정의 정책에 특정적인 필터이다. 추가적인 새 필터 규칙이 뷰 필터 기능을 위한 입력을 기반으로 기본 필터와 결합하여 생성될 수 있다. 예를 들어, 이는 서비스 서술로부터의 요청된 데이터를 위한 정보일 수 있다.

예를 들어, 뷰 필터 서버(108)는 타겟 서비스(202)를 서술하는 서비스 서술 정보에 기반하여 필터 규칙을 생성할 수 있다. 예를 들어, 클라우드 고객(20)은 타겟 서비스(202)에 의해 제공되는 통계 분석(예컨대, 수술을 받은 적이 있는 환자의 수에 관한 통계)을 획득하기를 바라는 건강 보험 회사일 수 있다. 이 경우, 타겟 서비스(202)는 데이터 클라우드(100)가 모든 보험 고객의 건강 기록을 제공하는 것을 요청할 수 있다. 그러나, 서비스 서술 정보로부터, 뷰 필터 서버(108)는, 원하는 서비스를 수행하기 위해 타겟 서비스(202)는 병원을 방문한 적이 있는 보험 고객의 서브세트의 의료 기록이 필요할 뿐이라고 판정하며, 다른 모든 의료 기록은 걸러낼 수 있다. 따라서, 타겟 서비스(202)를 서술하는 서비스 서술 정보에 기반하여 뷰 필터 서버(108)는 필터 규칙의 초기 세트(예컨대, 병원을 방문한 적이 없는 보험 고객을 제거하는 필터 규칙)를 생성한다.

또한, 뷰 필터 서버(108)는 정책 데이터베이스(112)에 저장된 정책에 기반하여 필터 규칙을 생성할 수 있다. 예를 들어, 환자에 대한 건강 기록은 배우 민감한 정보이고, 그러한 데이터는 그러한 데이터 세트가 준수할 것이 요구되는 정책을 지정하는 소정의 메타데이터와 연관될 수 있다. 예를 들어, 메타데이터는 데이터가 HIPAA를 준수하여야 함을 나타낼 수 있다. 그러면 메타데이터로부터의 이 정보는 정책 데이터베이스(112)에 맵핑되고 HIPAA와 연관된 모든 기저의 하위-정책(underlying sub-policy)들이 찾아진다. 예를 들어, HIPAA 하위-정책은 건강 기록이 타측(타겟 서비스(202))에 제공되기 전에 환자의 첫째 이름(first name), 가운데 이름(middle name) 및 성(last name)이 제거되어야 함을 요구할 수 있다. 이러한 정책 기반 필터는 카테고리화된 필터이다. 관련 정책 및 연관된 규칙이 검색되면, 기본적인 필터 규칙은 요구에 따라 맞춤화되고(customized) 이로써 데이터를 필터링하기 위한 필터 규칙(108a)의 최종 세트를 형성한다.

정책 데이터베이스(112)는 데이터가 타겟 서비스(202)에 송신되기 전에 데이터 서버(102)에 저장된 데이터를 필터링하는 데 사용될 수 있는 정책을 저장하도록 구성되는 데이터베이스이다. 그 정책은 입법적 및 규제적 준수 정책 및 연관된 하위-정책, 사용자 정책 등을 포함하는 여러 상이한 유형일 수 있다. 예시적인 실시예에서, 정책 데이터베이스(112)에 저장된 정책 및 하위-정책은 타겟 서비스(202)에 의해 요청되는 데이터와 연관된 메타데이터에 매칭된다. 뷰 필터 서버(108)는 정책-메타데이터 매칭 동작의 결과에 기반하여 필터 규칙을 생성한다. 예를 들어, 저장된 데이터가 HIPAA를 준수할 것이 요구되는 의료 기록을 포함한다는 것을 메타데이터가 나타내는 경우, 정책 데이터베이스(112)는 메타데이터를 정책 데이터베이스(112)에 저장된 HIPAA의 특정 정책/하위-정책과 매칭한다.

서비스 레벨 합의(SLA) 데이터베이스(114)는, 가령 클라우드 고객(20) 및 데이터 클라우드(100) 간에 형성된 SLA와 같이, 데이터 클라우드(100) 및 다른 엔티티 간에 수립된 SLA를 저장한다. 예시적인 실시예에 따르면, SLA 데이터베이스(114)에 구현되고 저장될 수 있는 다양한 서비스 레벨 합의 표준이 있다. 예를 들어, 오픈 그리드 프레임워크(Open Grid Framework)으로부터의 웹 서비스 합의(Web Service Agreement: WS- Agreement), IBM으로부터의 웹 서비스 레벨 합의(Web Service Level Agreement: WSLA) 언어 및 프레임워크 및 월드 와이드 웹 컨소시움(World Wide Web Consortium)으로부터의 통일된 서비스 서술(Unified Service Description)은 웹 서비스와 관련된 SLA를 위해 고려할 주요 표준이다. WS-Agreement 및 WSLA은 WSDL과 조화시켜 사용할 수 있는데, 이는 서비스 서술 사양을 위해 가능한 표준들 중 하나로서 사용될 수도 있는 반면, USDL은 서비스 서술의 사양과 SLA를 결합할 수 있다. 이러한 표준들 모두 그러한 사양을 위해 XML을 사용할 수 있으나, 거기에 제한되는 것은 아니다.

데이터 클라우드(100) 내에 상주하는 다양한 컴포넌트를 연결하는 연결(120)은 인터넷 상의 연결, 로컬 영역 네트워크(Local Area Network: LAN) 연결, 이더넷, 이들의 조합 등과 같은 다양한 타입의 유선 및/또는 무선 연결일 수 있다. 연결 (120)은 도 2에 도시된 바와 같이 구현되는 것에 제한되지 않는다.

도 2에 나타낸 바와 같이, 서비스 클라우드(200)는 타겟 서비스(202), 타겟 시스템 보안 상태정보 검색(Target System Security Posture Retrieval: TSSPR) 원격 에이전트(Remote Agent: RA)(204), 보안 데이터 컴파일러(security data compiler)(206), 서비스 서술 데이터베이스(208), 서비스 신뢰 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)(210), 서비스 레벨 합의(Service Level Agreement: SLA) 데이터베이스(2140 및 서비스 클라우드(200) 내 다양한 컴포넌트를 연결하는 복수의 연결(220)을 포함한다.

타겟 서비스(202)는 클라우드 고객(20)에 의해 사용될 것이 희망되는 서비스이다. 예시적인 실시예에서, 타겟 서비스(202)는 SaaS 계층 서비스이다. 타겟 서비스(202)는 데이터 서버(102)에 저장된, 클라우드 고객(20) 소유의 데이터에 대하여 서비스를 수행하고 그 수행 결과를 클라우드 고객(20)에게 출력한다. 타겟 서비스(202)는 매우 광범위한 갖가지 상이한 타입의 서비스일 수 있고, 하나의 서비스이거나 아니면 복수의 서비스일 수 있다. 타겟 서비스(202)는 예컨대 데이터의 통계적 분석을 생성하는 통계적 분석 서비스, 특정한 기준에 기반하여 데이터를 검색하는 데이터 검색 서비스 등일 수 있다. 예를 들어, 클라우드 고객(20)이 건강 보험 회사인 경우, 타겟 서비스(202)는 건강 보험 회사의 보험에 가입한 사람들의 의료 기록에 관련된 소정의 타입의 정보(예컨대, 수술을 받는 환자의 수, 치과의사를 방문하는 환자의 수 등)를 분석하는 통계적 분석 서비스일 수 있다.

서비스 신뢰 API(210)는 데이터 클라우드(100)에 상주하는 데이터 신뢰 API(110) 및 서비스 클라우드(200) 간의 통신을 위한 인터페이스로서의 역할을 한다. 서비스 신뢰 API(210)는 서비스 클라우드(200) 내의 다양한 컴포넌트 중에서 그 기능을 트리거링(triggering)함으로써 데이터 신뢰 API(110)로부터 전송되는 요청에 응답하고, 이어서 요청된 정보를 데이터 신뢰 API(110)로 중계한다. 서비스 신뢰 API(210)는 데이터 신뢰 API(110)로 전송될 신뢰 정보를 통합한다. 또한, 선택적으로, 서비스 신뢰 API(210)은 신뢰 정보를 다른 포맷으로 바꿀 수 있다. 예를 들어, 예시적인 실시예에서, 서비스 신뢰 API(210)는 신뢰 정보를 XML 데이터로 변환하고, 변환된 신뢰 정보를 데이터 신뢰 API(110)에 송신한다.

식별된 보안 파라미터에 기반하여, 서비스 신뢰 API(210)는 상이한 계층으로부터 보안 정보를 모으는 것에서의 임의의 문제를 해결한다. 예를 들어, 서비스 클라우드(200)는 상이한 SaaS, PaaS 및 IaaS 제공자들을 이용할 수 있는데, 이 경우 상이한 제공자들 간의 SLA는 적절히 보안 파라미터 정보에 대한 요청에 응답하는 데 이용될 수 있다. 그 문제를 해결한 이후, 서비스 신뢰 API(210)는 요청된 보안 파라미터 모두를 모으기 위해 보안 데이터 컴파일러(206)의 구동을 요청할 것을 TSSPR RA(204)에 지시한다.

예시적인 실시예에 따르면, 서비스 신뢰 API(210)는 계층화된 신뢰 API 또는 비-계층화 신뢰 API 중 어느 하나로서 구현될 수 있다. 예를 들어, 도 2에서 나타낸 바와 같이, 서비스 신뢰 API(210)는 서비스로서의 소프트웨어(Software as a Service: Saas) 계층, 서비스로서의 플랫폼(Platform as a Service: PaaS) 계층 및 서비스로서의 인프라스트럭처(Infrastructure as a Service: IaaS) 계층에 각각 대응하는 3개의 계층(210a, 201b 및 210c)을 구비한 계층화된 신뢰 API로서 구현될 수 있다. 계층들(210a, 201b 및 210c) 각각은 신뢰 감정을 위해 요구되는 보안 파라미터를 포함한다. 서비스 신뢰 API(210)는 데이터 신뢰 API(110)에 요청되는 보안 파라미터의 통합된 리스트를 수신할 수 있다. 대안적으로, 데이터 신뢰 API(110)에 요청되는 보안 파라미터의 리스트는 IaaS, Paas 및 SaaS 계층들(210a, 210b 및 210c)의 서브세트를 포함할 수 있다.

예시적인 실시예에서, 서비스 신뢰 API(210)는 SaaS 제공자에 의해 소유된다. 이 SaaS 제공자는 또한 기저의 PaaS 및 IaaS 서비스를 소유할 수 있는데, 이 경우 필요한 보안 파라미터 모두는 용이하게 측정될 수 있다. PaaS 및 IaaS 서비스들이 다른 제공자 또는 복수의 다른 제공자들에 속하면, SaaS 제공자가 기저의 PaaS 또는 IaaS 제공자들로부터 액세스할 수 있는 정보의 한계를 정의하기 위해 SaaS 제공자는 다른 제공자 또는 복수의 다른 제공자들과 서비스 레벨 합의 또는 복수의 서비스 레벨 합의들에 들어간다.

타겟 시스템 보안 상태정보 검색(Target System Security Posture Retrieval: TSSPR) 원격 에이전트(Remote Agent: RA)(204)는 서비스 클라우드(200)에서 보안 파라미터 정보를 제시하고 통합하는 것을 책임진다. 구체적으로, TSSPR RA(204)는 보안 파라미터 정보에 대한 요청을 수신하고, 수신된 보안 파라미터 정보에 기반하여, TSSPR RA(204)는 요청된 보안 정보를 컴파일링(compiling)하는 프로세스를 시작하기 위해 보안 데이터 컴파일러(206)를 구동한다.

보안 데이터 컴파일러(206) 각각은 서비스 클라우드(200)의 특정 보안 관련 정보의 검색을 책임진다. 보안 데이터 컴파일러(206)는 계층마다 보안 정보를 검색할 수 있다.

예시적인 실시예에서, 예컨대 신뢰되는 플랫폼 모듈(Trusted Platform Module: TPM), 가상 TPM(virtual TPM: vTPM), 트러스트존 가능 하드웨어(Trustzone enabled hardware) 또는 플랫폼 설정 정보를 측정하고 안전하게 저장할 수 있는 다른 보안 앵커(security anchor)들과 같은 신뢰되는 컴퓨팅 기술을 이용하여 하드웨어 레벨에서 보안 관련 정보가 보안 데이터 컴파일러(206)에 의해 수집될 수 있다.

보안 데이터 컴파일러(206)에 의한 보안 관련 정보 수집의 전형적인 프로세스는, 예컨대 해쉬 값의 계산을 이용하여 각 하드웨어 및 소프트웨어 컴포넌트를 그 시동(start up) 전에 측정함으로써 일련의 신뢰를 생성하는 것을 포함할 수 있다. 측정된 데이터는 이어서 보안 앵커의 보안화된 스토리지(secured storage)에 안전하게 저장된다. 보안화된 스토리지가 제한된 경우, 예컨대 TPM 플랫폼 설정 레지스터에서 사용되는 'extend' 동작과 같은 기술이 추가적으로 사용될 수 있다. 이 경우, 보안 스토리지 레지스터(secure storage register)의 새로운 값을 new_val = hash( old_val |hash(file))(여기서, hash는 SHA1과 같은 해쉬 함수이고, old_val은 위 스토리지 레지스터 내의 예전 값을 지칭하며, file은 실행 또는 측정될 실제 파일을 지칭하고, '|'는 값들의 연접(concatenation)임)로서 계산함으로써 측정치들이 하나의 해쉬 값으로 암호적으로 묶이고 교정된다(cryptographically bound and collated). 각 측정 값의 평문 표현(clear text representation), 대응하는 파일명 및 측정 값이 저장된 레지스터를 포함하는 측정 로그 파일(measurement log file)이 이 동작과 함께 생성된다. 측정 프로세스는 그 결과가 머신 상태에 대한 구조화되고 암호적으로 보안화된 표현이 되는데, 평문 로그(clear text log)는 보안화된 값에 의해 보안 앵커에서 보호된다. 그러면 그 정보는 신뢰 확인기(106)으로 전송될 수 있고, 이는 결국 평문 로그를 사용하여 평문 로그로부터 스토리지 레지스터의 값을 재계산하고 그 결과를 보안 앵커로부터의 암호적으로 보호되는 보고 값(reported value)과 비교할 수 있다. 그 값들이 매칭되지 않으며, 신뢰 확인기(106)는 평문 로그가 조작되었다고 판정하고 서비스 클라우드(200)가 신뢰할 수 없는 것이라고 판정한다. 신뢰 확인기(106)는 또한, 알려진 양호한 값의 데이터베이스 내에 있는 기대값으로부터 보고되는 상이한 해쉬 측정 값을 갖는 파일들에 대한 참조 측정 값들의 적절한 서비스 또는 데이터베이스의 도움으로 평문 로그를 체크할 수 있다. 그 결과, 신뢰 확인기(106)는 감정 하에 있는 타겟 서비스의 소프트웨어 및 하드웨어 설정에 관한 상세하고 신뢰되는 특정 뷰를 갖는다. 이 설명은 단지 예시적인 것이라고 이해된다.

서비스 서술 데이터베이스(208)는 타겟 서비스(202)에 의해 제공되는 서비스의 기능을 서술하는 정보를 저장한다. 예시적인 실시예에서, 타겟 서비스(202)에 의해 제공되는 서비스는 웹 기반 서비스이다. 이 경우, 타겟 서비스(202)는 웹 서비스 서술 언어(Web Services Description Language: WSDL)과 호환 가능하도록 구성된다. WSDL은 확장 가능 마크업 언어(Extensible Markup Language: XML) 포맷으로 웹 서비스를 서술하기 위한 표준 포맷이다. 웹 서비스의 WSDL 서술(WSDL 파일이라고도 지칭됨)은 타겟 서비스(202)를 무엇이라고 부르는지, 어떤 파라미터가 타겟 서비스(202)에 의해 기대되는지 및 어떤 데이터 구조를 타겟 서비스(202)가 반환하는지에 관한 머신 판독 가능(machine-readable) 서술을 제공한다.

예시적인 실시예에 따르면, WSDL은 인터넷 상에서 웹 서비스를 제공하기 위해 SOAP 및 XML 스키마(Schema)와 조합되어 사용될 수 있다. 웹 서비스에 연결된 클라이언트 프로그램은 어떤 함수가 타겟 서비스(202)로부터 이용 가능한지 판정하기 위해 WSDL을 판독할 수 있다. 임의의 특별한 데이터타입이 사용되더라도 XML 스키마의 형태로 WSDL 파일 내에 내장된다. 그러면 클라이언트는 WSDL 내에 열거된 함수 중 하나를 실제로 호출하기 위해 SOAP을 사용할 수 있다.

예시적인 실시예에 따르면, WSDL 2.0은 서비스 서술을 위해 사용될 수 있다. WSDL 2.0은 웹 서비스에 대한 서비스 서술을 명시하기 위한 W3C 권고이다. 다른 예시적인 실시예에 따르면, 통일된 서비스 서술 언어(Unified Service Description: USDL)가 서비스 서술을 위해 사용될 수 있는데, USDL은 서비스의 비즈니스, 운영상 및 기술적 파라미터를 서술하는 것에 관하여 포괄적인 언어인바 클라우드 컴퓨팅 시나리오에 유익할 수 있기 때문이다. USDL에서, 서비스 서술은 예컨대, 가격 책정, 법적 공지, 서비스 제공자, 상호작용 방법, 서비스 레벨 합의 등과 같은 정보를 포함할 수 있다. USDL은 또한 가격에 따라 서비스를 비교하게 해 줄 수 있다.

서비스 레벨 합의(SLA) 데이터베이스(214)는 서비스 클라우드(200) 및 다른 엔티티 간에 형성된 SLA, 예컨대 서비스 클라우드(200) 및 클라우드 고객(20) 간 형성된 SLA를 저장한다. SLA 데이터베이스(214)는 다른 SLA 역시 저장할 수 있다. 예를 들어, PaaS 및 IaaS 서비스가 다른 제공자에 의해 소유/운영되는 경우, SLA 데이터베이스(214)는 이러한 다른 제공자와의 SLA를 저장할 수 있다.

서비스 클라우드(100) 내에 상주하는 다양한 컴포넌트를 연결하는 연결(200)은 인터넷 상의 연결, 로컬 영역 네트워크(Local Area Network: LAN) 연결, 이더넷, 이들의 조합 등과 같은 다양한 타입의 유선 및/또는 무선 연결일 수 있다.

예시적인 실시예에 따르면, 수송 제어 프레임워크의 각 멤버 엔티티는 인증 키 재료(keying material)로서 사용되는 개인/전용(private/public) 키 쌍을 구비할 수 있다. 가령 통신 종단점의 발견, 데이터 요청 및 응답 등에서, 두 엔티티가 통신하여 데이터를 교환할 필요가 있는 경우, 그 엔티티들은 그들의 키 쌍에 기반하여 TLS 인증 핸드쉐이크를 수행할 수 있다. 통신 보안은 TLS 핸드쉐이크 동안 수립된 세션 키에 의해 제공될 수 있고, 메시지 무결성(message integrity)은 메시지 인증 코드(Message Authentication Codes: MACs)의 사용에 의해 생성될 수 있다.

예시적인 실시예에 따르면, 수송 제어 프레임워크의 두 멤버 엔티티가 종단점을 발견하도록, RFC5786 기반 유니폼 리소스 식별자(Uniform Resource Identifiers: URI)가 사용된다.

도 3은 예시적인 실시예에 따른 클라우드간 데이터 전송 방법을 도시한다. 도 3에 도시된 방법(300)에 관한 아래의 설명에서, 도 2와 관련하여 기술된 여러 엔티티들이 식별된다. 그러나, 이 설명은 단지 예시적이며 도 3에 도시된 방법(300)은 도 2와 관련하여 기술된 엔티티에 의해 수행되는 것에 제한되지 않는다고 이해된다. 대안적으로 도 3에 도시된 방법(300)은 다른 예시적인 실시예에 따라 다른 많은 타입의 엔티티에 의해 수행될 수 있다.

동작(302)에서, 클라우드 소비자(20)는 서비스 클라우드(200)로부터의 서비스를 요청한다. 예시적인 실시예에서, 클라우드 소비자(20)는 서비스 클라우드(200)에 의해 제공되는 사용자 인터페이스(예컨대, 웹사이트)를 이용하여 인터넷 연결 상에서 서비스를 요청한다. 예를 들어, 클라우드 소비자(20)가 건강 보험 회사인 경우, 건강 보험 회사는 지난 해 동안 수술을 받은 적이 있는 건강 보험 회사의 고객 각각을 식별하는 서비스를 서비스 클라우드(200)가 수행할 것을 요청하기를 바랄 수 있다. 동작(302)의 일부로서, 서비스 클라우드(200)는 다양한 인증 기술(예컨대, 암호, 토큰 등) 중 임의의 것을 이용하여 클라우드 소비자(20)의 신원을 인증한다.

동작(304)에서, 서비스 클라우드(200)는 서비스 클라우드(200)에 의해 지원되는 데이터 클라우드(100)의 리스트를 클라우드 소비자(20)에게 제공하여 클라우드 고객(20)으로 하여금 데이터 클라우드(100)의 리스트 중에서 클라우드 소비자의 데이터를 호스팅하는 데이터 클라우드(100)를 선택할 수 있도록 한다. 동작(304)의 일부로서, 서비스 클라우드(200)는 또한 클라우드 소비자(20)에 의해 처음에 요청된 서비스를 수행하기 위해 요구되는 데이터를 요청한다. 예를 들어, 서비스 클라우드(200)는 건강 보험 회사의 의료 기록을 요청한다.

동작(306)에서, 클라우드 소비자(20)는 클라우드 소비자(20)의 데이터를 호스팅하는 데이터 클라우드(100)를 선택한다.

동작(308)에서, 서비스 클라우드(200)는 서비스 클라우드(200)의 사용자 인터페이스로부터 동작(306)에서 선택된 데이터 클라우드(100)의 사용자 인터페이스로 제어를 이전하여 클라우드 소비자(20)로 하여금 선택된 데이터 클라우드(100)에 자신을 인증시킬 수 있도록 한다.

동작(310)에서, 데이터 클라우드(100)는 인증을 위한 인터페이스를 클라우드 소비자(20)에게 제공한다.

동작(312)에서, 클라우드 소비자(20)는 동작(310)에서 데이터 클라우드(100)에 의해 제공된 인터페이스를 이용하여 자신을 인증시킨다. 나아가, 동작(312)에서, 클라우드 소비자(20)는 서비스 클라우드(200)에 의해 요청된 데이터를 선택한다.

동작(314)에서, 데이터 클라우드(100)는 클라우드 고객의 기록을 서비스 클라우드(200)로 전송하는 것을 호출하기 위해 데이터 클라우드(100)의 사용자 인터페이스로부터 데이터 신뢰 API(110)로 제어를 이전하고 또한 서비스 클라우드(200)의 URI를 제공한다.

동작(316)에서, 민감한 신뢰 정보의 안전한 교환을 보장하기 위하여 데이터 신뢰 API(110) 및 서비스 신뢰 API(210)는 상호 간에 서로를 인증한다.

동작(318)에서, 데이터 신뢰 API(110)는 클라우드 고객(20)에 의해 요청된 서비스를 서술하는 서비스 서술 정보를 서비스 신뢰 API(210)에 요청한다.

동작(320)에서, 서비스 신뢰 API(210)는 동작(318)에서 요청된 서비스 서술 정보의 검색을 개시하고 이어서 검색된 서비스 서술 정보를 데이터 신뢰 API(110)에 송신한다.

동작(322)에서, 데이터 신뢰 API(110)는 서비스 클라우드(200)에 의해 제공되는 서비스의 신뢰 감정을 위해 요구되는 보안 파라미터를 식별하기 위한 프로세스를 호출한다.

동작(324)에서, 서비스 신뢰 API(210)는 동작(322)에서 요청된 보안 파라미터를 검색하기 위한 프로세스를 호출한다.

동작(326)에서, 요청된 파라미터가 검색되면, 서비스 신뢰 API(210)는 요청된 파라미터를 데이터 신뢰 API(110)에 송신한다.

동작(328)에서, 데이터 신뢰 API(110)는 신뢰 평가 프로세스를 시작하고 이어서 긍정적인 결과를 갖는 신뢰 평가에 기반하여 데이터 필터링 프로세스를 개시한다.

동작(330)에서, 데이터 신뢰 API(110)는 필터링된 데이터를 데이터 클라우드(100)의 사용자 인터페이스에 송신한다. 동작(332)에서, 데이터 클라우드(100)의 사용자 인터페이스는 필터링된 데이터를 서비스 클라우드(200)에 송신하고 서비스 클라우드(200)는 필터링된 데이터를 이용하여 원하는 서비스를 수행한다.

동작(334)에서, 서비스 클라우드(200)의 사용자 인터페이스는 서비스의 결과를 클라우드 고객(20)에 출력한다. 예를 들어, 서비스 클라우드(200)는 지난 해 동안 수술을 받은 적이 있는 환자의 통계적 분석을 출력한다.

도 4는 예시적인 실시예에 따라 신뢰 평가 프로세스를 수행하는 방법을 도시한다. 도 4에 도시된 방법(400)에 관한 아래의 설명에서, 도 2와 관련하여 기술된 여러 엔티티들이 도 4의 방법에서 동작을 수행하는 것으로 기술된다. 그러나, 이 설명은 단지 예시적이며 도 4에 도시된 방법(400)은 도 2와 관련하여 기술된 엔티티에 의해 수행되는 것에 제한되지 않는다고 이해된다. 대안적으로 도 4에 도시된 방법(400)은 다른 예시적인 실시예에 따라 다른 많은 타입의 엔티티에 의해 수행될 수 있다.

예시적인 실시예에 따르면, 도 4에 도시된 방법(400)은 도 3의 방법(300)에서 나타낸 동작(318, 320, 332, 324, 326 및 328)에 관한 더욱 상세한 설명이다. 그러나, 도 4에 도시된 방법(400)은 도 3에 도시된 방법(300)의 일부로서 구현될 것이 요구되지 않고, 대안적으로 도 3에 도시된 방법(300)과 무관하게 구현될 수 있다고 이해된다.

동작(402)에서, 데이터 신뢰 API(110)는 서비스 신뢰 API(210)에 서비스 서술 정보를 요청한다. 예를 들어, 클라우드 소비자(20)가 건강 보험 회사인 경우, 건강 보험 회사는 지난 해 동안 수술을 받은 적이 있는 건강 보험 회사의 고객 각각을 식별하는 서비스를 서비스 클라우드(200)가 수행할 것을 요청하기를 바랄 수 있다.

동작(404)에서, 서비스 신뢰 API(210)는 서비스 서술 정보를 서비스 서술 데이터베이스(208)에 요청한다.

동작(406)에서, 서비스 서술 데이터베이스(208)는 동작(404)에서 요청된 서비스 서술 정보를 검색하고 서비스 서술 정보를 서비스 신뢰 API(210)에 송신한다.

동작(408)에서, 서비스 신뢰 API(210)는 서비스 서술 정보를 데이터 신뢰 API(110)에 송신한다.

동작(410)에서, 데이터 신뢰 API(110)는 서비스 서술 정보를 TSSPR HA(104)에 송신하고, 이어서 서비스 서술 정보에 기반하여 타겟 서비스(202)의 신뢰 평가를 수행하는 데 필요한 보안 파라미터를 식별하기 위해 TSSPR HA(104)는 서비스 서술 정보를 분석한다.

동작(412)에서, TSSPR HA(104)는 동작(410)에서 식별된 보안 파라미터를 데이터 신뢰 API(110)에 송신한다. 예시적인 실시예에서, 동작(412)은 예컨대 IaaS, PaaS 및 SaaS 계층과 같은 계층마다 TSSPR HA(104)로부터 송신되는 보안 파라미터를 분류하는 TSSPR HA(104)의 동작을 포함한다.

동작(414)에서, 데이터 신뢰 API(110)는 동작(412)에서 TSSPR HA(104)로부터 전송된 보안 파라미터를 요청하는 요청을 서비스 신뢰 API(210)에 송신한다.

동작(416)에서, 서비스 신뢰 API(210)는 동작(414)에서 요청된 보안 파라미터에 관련된 정보를 검색하는 프로세스를 개시하기 위해 TSSPR 원격 에이전트(204)에 요청을 송신한다.

동작(418)에서, TSSPR 원격 에이전트(204)는 동작(414)에서 요청된 보안 파라미터에 관련된 정보를 컴파일링하도록 구성된 보안 데이터 컴파일러(206)을 구동한다. 예시적인 실시예에서, 보안 데이터 컴파일러(206) 각각은 상이한 계층(예컨대 IaaS, PaaS 및 SaaS 계층)에 대응하는 보안 파라미터 정보를 컴파일링한다.

동작(420)에서, 보안 데이터 컴파일러(206)는 컴파일링된 보안 파라미터 정보를 TSSPR 원격 에이전트(204)에 송신한다.

동작(422)에서, TSSPR 원격 에이전트(204)는 컴파일링된 보안 파라미터 정보를 통합하고 통합된 보안 파라미터 정보를 서비스 신뢰 API(210)에 송신한다.

동작(424)에서, 서비스 신뢰 API(210)는 동작(422)에서 수신된 보안 파라미터 정보를 데이터 신뢰 API(110)에 송신한다.

동작(426)에서, 데이터 신뢰 API(110)는 동작(424)에서 수신된 보안 파라미터 정보를 TSSPR HA(104)에 송신한다.

동작(428)에서, TSSPR HA(104)는 동작(426)에서 수신된 보안 파라미터 정보를 신뢰 확인기(106)에 송신하고 이어서 신뢰 확인기(106)는 보안 파라미터 정보에 기반하여 확인 프로세스를 수행한다.

동작(430)에서, 신뢰 확인기(106)는 확인 프로세스의 결과에 기반하여 확인 응답을 TSSPR HA(104)에 송신하고, 확인 응답에 기반하여 TSSPR HA(104)는 타겟 서비스(202)의 보안 상태정보에 관한 판정을 내린다. 그 판정은 타겟 서비스(202)가 믿을 수 있는 것이라고 TSSPR HA(104)가 판정하였는지 여부를 나타내고, 따라서 동작(430)에 이어지는 일련의 단계를 결정한다. 만일 그 판정이 타겟 서비스(202)가 믿을 수 있는 것임을 나타내면, 위 방법은 동작(432)으로 나아간다.

동작(432)에서, TSSPR HA(104)는 위 결정을 데이터 신뢰 API(110)에 송신하고, 이어서 동작(434)에서, 타겟 서비스(202)로 송신될 데이터를 필터링하는 뷰 필터 규칙의 생성을 개시하기 위해 데이터 신뢰 API(110)는 뷰 필터 서버(108)와 통신한다.

도 5는 예시적인 실시예에 따라 뷰 필터 규칙을 생성하는 방법을 도시한다. 도 5에 관한 이하의 설명에서, 도 2와 관련하여 기술된 여러 엔티티들이 도 5에 도시된 방법(500)에서 동작을 수행하는 것으로 기술된다. 그러나, 이 설명은 단지 예시적이며 도 5에 도시된 방법(500)은 도 2와 관련하여 기술된 엔티티에 의해 수행되는 것에 제한되지 않는다고 이해된다. 대안적으로 도 5에 도시된 방법(500)은 다른 예시적인 실시예에 따라 다른 많은 타입의 엔티티에 의해 수행될 수 있다.

예시적인 실시예에 따르면, 도 5에 도시된 방법(500)은 도 3에 도시된 동작(328)에 관한 더욱 상세한 설명이다. 그러나, 도 5에 도시된 방법(500)은 도 3에 도시된 방법(300)의 일부로서 구현될 것이 요구되지 않고, 대안적으로 도 3에 도시된 방법(300)과 무관하게 구현될 수 있다고 이해된다.

TSSPR HA(104)로부터 타겟 서비스(202)가 신뢰할 수 있는 것임을 나타내는 판정을 수신하는 것에 응답하여, 동작(502)에서, 데이터 신뢰 API(110)는 뷰 필터 생성 프로세스를 개시하기 위해 뷰 필터 서버(108)와 통신한다. 예시적인 실시예에서, 데이터 신뢰 API(110)는 신뢰 평가 출력, 서비스 서술 정보 및 요청된 데이터로의 포인터를 뷰 필터 서버(108)에 제공함으로써 뷰 필터 규칙의 생성을 개시한다.

동작(504)에서, 뷰 필터 서버(108)는 타겟 서비스(202)에 의해 요청된 데이터를 요청하는 요청을 데이터 서버(102)에 송신하고 나아가 타겟 서비스(202)에 의해 요청된 데이터에 대응하는 메타데이터를 요청한다.

동작(506)에서, 데이터 서버(102)는 동작(504)에서 요청된 데이터 및 대응하는 메타데이터를 검색하고 뷰 필터 서버(108)에 데이터 및 대응하는 메타데이터를 송신한다.

동작(508)에서, 뷰 필터 서버(108)는 이어서 정책 데이터베이스(112)가 메타데이터 내에 명시된 정책을 정책 데이터베이스(112) 내에 저장된 정책 정보에 맵핑할 것을 요청하는 요청을 정책 데이터베이스(112)에 송신한다. 예를 들어, 저장된 데이터가 HIPAA를 준수하도록 요구되는 의료 기록을 포함한다는 것을 메타데이터가 나타내는 경우, 정책 데이터베이스(112)는 메타데이터를 정책 데이터베이스(112)에 저장된 HIPAA의 특정 정책/하위-정책과 매칭한다. 이 경우, 예를 들어, HIPAA는 소정의 정보가 개시(disclosed)되지 않을 것 또는 최소한으로 개시될 것을 요구할 수 있다.

동작(510)에서, 정책 데이터베이스(512)는 메타데이터와 매칭되는 특정 정책/하위-정책을 다시 뷰 필터 서버(108)에 송신한다.

동작(512)에서, 뷰 필터 서버(108)는 서비스 서술 정보 및 정책 데이터베이스(512)로부터 송신된 특정 정책/하위-정책에 기반하여 하나 또는 복수의 데이터 뷰 필터(뷰 필터 규칙이라고도 지칭됨)를 생성한다.

동작(514)에서, 데이터 신뢰 API(110)로 하여금 타겟 서비스(202)에 필터링된 데이터를 전달할 수 있게 하기 위하여, 뷰 필터 서버(108)는 필터링된 데이터를 데이터 신뢰 API(110)에 송신한다. 데이터 신뢰 API(110)는 필터링된 데이터를 타겟 서비스(202)에 여러 가지 방법으로 전달할 수 있다. 예를 들어, 데이터 신뢰 API(110)는 필터링된 데이터를 타겟 서비스(202)에 직접적으로 송신할 수 있다. 대안적으로, 데이터 신뢰 API(110)는 안전한 스토리지 설비(특정 URL을 통해 액세스 가능함)에 필터링된 데이터를 저장할 수 있고, 특정 URL을 타겟 서비스(202)에 제공함으로써 저장된 데이터에 대한 액세스를 타겟 서비스(202)에 제공할 수 있다. 뷰 필터 서버(108)로부터의 그 필터링된 데이터는 데이터 신뢰 API(110)뿐만 아니라 데이터 클라우드(100)의 내부 또는 외부의 다른 엔티티에도 송신될 수 있다.

도 6은 다른 예시적인 실시예에 따른 클라우드 컴퓨팅 시스템을 도시한다. 도 6에 나타낸 바와 같이, 클라우드 컴퓨팅 시스템(60)이 제3자 신뢰 조정기(third-party trust orchestrator)(600)를 포함한다는 점에서 클라우드 컴퓨팅 시스템(60)은 도 2에 도시된 클라우드 컴퓨팅 시스템(10)과 상이하다.

제3자 신뢰 조정기(600)는 데이터 클라우드(100)의 신뢰 확인의 프로세스를 관리한다. 이러한 다른 예시적인 실시예에 따르면, 제3자 신뢰 조정기(600)는 데이터 클라우드(100) 및 서비스 제공자(200) 모두와 SLA를 갖는다. 제3자 신뢰 조정기(600)는 도 2에 도시된 클라우드 컴퓨팅 시스템(10)에 관하여 위에서 기술된 신뢰 평가 동작 모두 또는 서브세트를 수행할 수 있다.

도 7은 몇몇 구현예에 적합한 예시적 환경을 보여준다. 환경(700)은 장치들(705 내지 745)을 포함하고, 각각은 가령 네트워크(750)를 통해(예컨대 유선 및/또는 무선 연결에 의해) 적어도 하나의 다른 디바이스에 통신 가능하게 연결된다. 몇몇 장치는 하나 또는 그 이상의 스토리지 장치(730 및 745)에 통신 가능하게 연결된다.

도 2 및 도 6에 도시된 장치 및/또는 서비스는 예컨대 705 내지 745에 도시된 타입의 하나 이상의 장치를 이용하여 구체적으로 구현될 수 있고, 하나 이상의 그러한 컴퓨팅 장치와 인터페이스될 수 있다. 장치(705 내지 745)는 컴퓨터(705)(예컨대, 랩톱 컴퓨팅 장치), 모바일 장치(710)(예컨대, 스마트폰 또는 태블릿), 하나 이상의 프로세서가 내장 또는 결합된 텔레비전(715), 운송수단(vehicle)과 연관된 장치(720), 서버 컴퓨터(725), 컴퓨팅 장치(735 내지 740) 및 스토리지 장치(730)(예컨대, 부착된 스토리지 장치)와 스토리지 장치(745)(예컨대, 네트워크 액세스 가능한 스토리지 장치)를 포함할 수 있으나, 이에 제한되는 것은 아니다.

앞서 언급된 예시적인 실시예가 오늘날 고속 서버에 의해 제공되는 서비스 및 동작에 초점을 맞춘 것으로 보일 수 있으나, 컴퓨팅 장치에서의 지속적인 발전은 오늘날 종종 사용자 장치(예컨대, 네트워크에서와 같이, 서비스에 액세스하고/하거나 요청을 발부하기 위해 사용자에 의해 사용되는 장치)로 여겨지는 장치(705 내지 720)와 같은 타입의 컴퓨팅 장치들 간에 그러한 서비스 및 동작이 수행되는 것을 가능하게 할 것으로 예견된다. 그러한 사용자 장치는 데이터 클라우드 및 서비스 클라우드 간 통신의 필요성을 일으키는 요청들을 위하여 소스를 제공할 수 있다.

반면, 장치(725 내지 745)는 앞서 언급된 동작 및 서비스에 확실히 적합하나, 마찬가지로 데이터 클라우드 및 서비스 클라우드 간 통신의 필요성을 일으키는 요청을 위하여 소스를 제공할 수도 있을 것이다. 앞서 언급한 동작 및 서비스를 수행하는 경우, 그러한 장치는 더욱 전형적으로 서비스 제공자와 연관(예컨대, 서비스를 제공하고/하거나 데이터를 저장하며 도 3 내지 도 5에 도시된 동작과 같은 동작을 수행하기 위해 서비스 제공자에 의해 사용)될 수 있다.

예를 들어, 사용자 장치(705 또는 710)를 이용하여 컨텐츠의 액세스, 뷰 및/또는 공유를 하기 위해 사용자는 어떤 타입의 정보에 대한 요청을 개시할 수 있다. 그러한 요청은 네트워크(750)를 거쳐 API(110)를 지원하는 장치(725 또는 735 내지 740)과 같은 서버로 이동할 수 있다. 도 3 내지 도 5에서 도시된 것과 같은 전술한 통신은 735 내지 740과 같은 장치들 간에 일어날 수 있다. 반면, API가 735 내지 740과 같은 장치에 의해서만 지원될 것이 요구되는 것은 아니며, 도 7에 도시된 다른 장치는 기술적 상황에 적절하게 사용될 수 있다.

도 8은 몇몇 구현예에서 사용되기에 적합한 예시적 컴퓨팅 장치와 함께 예시적 컴퓨팅 환경을 보여준다. 컴퓨팅 환경(800) 내의 컴퓨팅 장치(805)는 하나 이상의 프로세싱 유닛, 코어 또는 프로세서(810), 메모리(815)(예컨대 RAM, ROM 및/또는 그 밖의 것), 내부 스토리지(820)(예컨대, 자기적(magnetic), 광학적(optical), 고체 상태 스토리지(solid state storage) 및/또는 유기적(organic)인 것) 및/또는 I/O 인터페이스(825)를 포함할 수 있고, 이들 중 임의의 것은 정보의 통신을 위해 통신 메커니즘 또는 버스(830) 상에 결합되거나 컴퓨팅 장치(805) 내에 내장될 수 있다.

컴퓨팅 장치(805)는 입력/사용자 인터페이스(835) 및 출력 장치/인터페이스(840)에 통신 가능하게 결합될 수 있다. 입력/사용자 인터페이스(835) 및 출력 장치/인터페이스(840) 중 어느 하나 또는 모두는 유선 또는 무선 인터페이스일 수 있고 분리 가능할 수 있다. 입력/사용자 인터페이스(835)는 입력을 제공하는 데 사용될 수 있는 물리적 또는 가상적인 임의의 장치, 컴포넌트, 센서 또는 인터페이스(예컨대, 버튼, 터치스크린 인터페이스, 키보드, 포인팅/커서 컨트롤, 마이크로폰, 카메라, 점자, 모션 센서, 광학 판독기 및/또는 그 밖의 것)를 포함할 수 있다. 출력 장치/인터페이스(840)는 디스플레이, 텔레비전, 모니터, 프린터, 스피커, 점자 또는 그 밖의 것을 포함할 수 있다. 몇몇 구현예에서, 입력/사용자 인터페이스(835) 및 출력 장치/인터페이스(840)는 컴퓨팅 장치(805)와 함께 내장되거나 컴퓨팅 장치(805)에 물리적으로 결합될 수 있다. 다른 구현예에서, 다른 컴퓨팅 장치가 컴퓨팅 장치(805)를 위한 입력/사용자 인터페이스(835) 및 출력 장치/인터페이스(840)로서 기능하거나 그러한 기능을 제공할 수 있다.

컴퓨팅 장치(805)의 예는 고도의 모바일 장치(예컨대, 스마트폰, 운송수단 및 다른 머신 내의 장치, 인간 및 동물이 휴대하는 장치 및 그 밖의 것), 모바일 장치(예컨대, 태블릿, 노트북, 랩톱, 개인용 컴퓨터, 이동식 텔레비전, 라디오 및 그 밖의 것) 및 이동성을 위해 설계되지 않은 장치(예컨대, 데스크톱 컴퓨터, 서버 또는 랙 마운트 형(rack-mounted) 장치와 같은 다른 컴퓨터, 안내소(information kiosk), 하나 이상의 프로세서가 내장되거나 결합된 텔레비전, 라디오 및 그 밖의 것)를 포함할 수 있으나, 이에 제한되지 않는다.

컴퓨팅 장치(805)는, 동일하거나 상이한 구성의 하나 이상의 컴퓨팅 장치를 포함하여 임의의 개수의 네트워킹된 컴포넌트, 장치 및 시스템과 통신하기 위한 외부 스토리지(845) 및 네트워크(850)에 (예컨대 I/O 인터페이스(825)를 통해) 통신 가능하게 연결될 수 있다. 컴퓨팅 장치(805) 또는 임의의 연결된 컴퓨팅 장치는 서버, 클라이언트, 씬 서버(thin server), 범용 머신(general machine), 특정 용도 머신 또는 다른 라벨로서 기능하거나, 그 서비스를 제공하거나, 그와 같이 지칭될 수 있다.

I/O 인터페이스(825)는 적어도 컴퓨팅 환경(800)에서 연결된 컴포넌트, 장치 및 네트워크 전부로 및/또는 그로부터 정보를 통신하기 위한 임의의 통신 또는 I/O 프로토콜 내지 표준을 사용하는 유선 및/또는 무선 인터페이스(예컨대, 이더넷(Ethernet), 802.11x, USB(Universal System Bus), 와이맥스(WiMax), 모뎀, 셀룰러 네트워크 프로토콜 및 그 밖의 것)를 포함할 수 있으나, 이에 제한되지 않는다. 네트워크(850)는 임의의 네트워크 또는 네트워크들의 조합(예컨대, 인터넷, 로컬 영역 네트워크, 광역 네트워크(wide area network), 전화 네트워크, 셀룰러 네트워크(cellular network), 위성 네트워크 및 그 밖의 것)일 수 있다.

컴퓨팅 장치(805)는 일시적(transitory) 매체 및 비일시적(non-transitory) 매체를 포함하는 컴퓨터 사용 가능 내지 컴퓨터 판독 가능 매체를 이용하고/하거나 이를 이용하여 통신할 수 있다. 일시적 매체는 전송 매체(예컨대, 금속 케이블, 광섬유), 신호, 반송파 및 그 밖의 것을 포함한다. 비일시적 매체는 자기적 매체(예컨대, 디스크 및 테이프), 광학적 매체(예컨대, CD ROM, 디지털 비디오 디스크, 블루레이 디스크), 고체 상태 매체(예컨대, RAM, ROM, 플래시 메모리, 고체 상태 스토리지) 및 다른 비휘발성 스토리지 내지 메모리를 포함한다.

컴퓨팅 장치(805)는 몇몇 예시적 컴퓨팅 환경에서 기법, 방법, 애플리케이션, 프로세스 또는 컴퓨터 실행 가능 명령어를 구현하기 위해 사용될 수 있다. 컴퓨터 실행 가능 명령어는 일시적 매체로부터 검색되고, 비일시적 매체 상에 저장되어 그로부터 검색될 수 있다. 그러한 실행 가능 명령어는 임의의 프로그래밍 스크립팅 및 머신 언어(예컨대, C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript 및 다른 것들) 중 하나 또는 그 이상으로부터 유래할 수 있다.

프로세서(들)(810)는 임의의 운영 시스템(OS)(미도시) 하에서 본래의(native) 또는 가상의(virtual) 환경에서 실행될 수 있다. 로직 유닛(860), API 유닛(865), 입력 유닛(870), 출력 유닛(875), 호스트 에이전트 유닛(880), 신뢰 확인기 유닛(885), 뷰 필터 유닛(890) 및 상이한 유닛들이 상호간에, OS와, 그리고 다른 애플리케이션(미도시)과 통신하기 위한 유닛간(inter-unit) 통신 메커니즘(895)을 포함하는 하나 또는 그 이상의 애플리케이션이 배치될 수 있다. 예를 들어, 호스트 에이전트 유닛(880), 신뢰 확인기 유닛(885) 및 뷰 필터 유닛(890)은 앞서 설명된 도면에서 나타낸 하나 이상의 프로세스를 구현할 수 있다. 설명된 유닛 및 구성요소는 설계, 기능, 구성 또는 구현에 있어서 달라질 수 있고 제공된 설명에 제한되지는 않는다.

몇몇 구현예에서, 정보 또는 실행 명령어가 API 유닛(865)에 의해 수신되는 경우, 그것은 하나 또는 그 이상의 다른 유닛(예컨대, 로직 유닛(860), 입력 유닛(870), 출력 유닛(875), 호스트 에이전트 유닛(880), 신뢰 확인기 유닛(885) 및 뷰 필터 유닛(890))에 통신될 수 있다. 그러한 실행 명령어를 수행하기 위해, 프로세서(들)(810)는 내부 스토리지(820), 메모리(815) 또는 외부 스토리지(845)에 저장된 명령어의 집합을 참조하여야 하고, 그러한 명령어의 집합은 프로세서(들)(810)로 하여금 API 유닛(865)에 의해 수신된 정보 또는 실행 명령어에 의해 의도되는 동작을 수행할 수 있도록 하는 것이다.

몇몇 경우에, 로직 유닛(860)은 유닛들 간의 정보 흐름을 제어하도록, 또한 앞에서 서술된 몇몇 구현예에서 API 유닛(865), 입력 유닛(870), 출력 유닛(875), 호스트 에이전트 유닛(880), 신뢰 확인기 유닛(885) 및 뷰 필터 유닛(890)에 의해 제공되는 서비스를 지시하도록 구성될 수 있다. 예를 들어, 하나 이상의 프로세스 또는 구현의 흐름은 로직 유닛(860)이 단독으로 또는 API 유닛(865)과 공동으로 제어할 수 있다.

앞서 서술된 다양한 유닛은 몇몇 예시적인 구현예에서 기술적 상황이 지시하는 바에 따라 동일한 컴퓨팅 장비 또는 상이한 컴퓨팅 장비 상에서 구현될 수 있다.

몇 개의 구현예가 보여지고 서술되었으나, 이 구현예는 본 명세서에서 서술되는 대상물(subject matter)을 이 분야에 친숙한 이들에게 전달하기 위해 제공된다. 본 명세서에서 서술된 대상물은 서술된 구현예에 제한되지 않고 다양한 형태로 구현될 수 있다고 이해되어야 한다. 본 명세서에서 서술된 대상물은 구체적으로 정의되거나 서술된 사항 없이 또는 서술되지 않은 그 밖의 또는 상이한 구성요소 내지 사항들과 함께 실시될 수 있다. 첨부된 청구항 및 그 균등물에서 정의되는 바와 같이 본 명세서에서 서술된 대상물로부터 벗어나지 않고 이러한 구현예에서 변경이 이루어질 수 있음이 이 분야에 친숙한 자들에 의해 인식될 것이다.

Claims (33)

1. 데이터 신뢰 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)를 포함하는 데이터 클라우드(data cloud)에서 동작하는 장치를 위한 방법으로서,
   상기 데이터 신뢰 API가 서비스 클라우드(service cloud)의 서비스 신뢰 API에 신뢰 정보(trust information)를 요청하는 단계;
   상기 서비스 클라우드로부터 상기 신뢰 정보를 수신하는 단계;
   상기 신뢰 정보에 기반하여 상기 서비스 클라우드의 신뢰 평가(trust assessment)를 수행하는 단계;
   상기 신뢰 평가의 결과에 따라 상기 서비스 클라우드로 데이터를 송신하는 것을 제어하는 단계;
   상기 신뢰 평가의 결과가 상기 데이터를 사용하여 타겟 서비스(target service)를 제공하는 상기 서비스 클라우드는 신뢰할 수 있는 것임을 나타내는 경우 상기 서비스 클라우드로 상기 데이터를 송신하는 단계;
   상기 데이터 신뢰 API가 상기 서비스 신뢰 API에 상기 타겟 서비스를 서술하는 서비스 서술 정보(service description information)를 요청하는 단계;
   상기 데이터 신뢰 API에 의해, 상기 서비스 신뢰 API로부터 상기 서비스 서술 정보를 수신하는 단계; 및
   상기 데이터 신뢰 API가, 상기 서비스 클라우드의 상기 신뢰 평가를 수행하는 데에 사용될 보안 파라미터를 식별하기 위해, 상기 서비스 서술 정보에 기반하여, 상기 데이터 클라우드에서 동작하는 타겟 시스템 보안 상태정보 검색(Target System Security Posture Retrieval: TSSPR) 호스트 에이전트(Host Agent: HA)에 요청을 송신하는 단계를 포함하며,
   상기 서비스 신뢰 API는 상기 서비스 클라우드에서 동작하는 서비스 서술 데이터베이스로부터 상기 서비스 서술 정보를 검색하는,
   방법.
   
   
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 삭제
8. 제1항에 있어서,
   상기 보안 파라미터는 상기 서비스 클라우드에 의해 구현되는 안티바이러스(antivirus) 시스템에 관련된 정보, 상기 서비스 클라우드에 의해 구현되는 로그 파일(log file)에 관련된 정보 및 상기 서비스 클라우드에 의해 구현되는 플랫폼(platform) 및 운영 시스템(Operating System: OS) 중 적어도 하나에 관련된 정보 중에서 선택된 적어도 하나의 타입의 정보를 포함하는,
   방법.
9. 제8항에 있어서,
   상기 플랫폼에 관련된 정보는 하드웨어 설정 정보(hardware configuration information), 서버 정보(server information), 네트워킹 정보(networking information) 및 스토리지 정보(storage information)에 관련된 정보 중 적어도 하나를 포함하는,
   방법.
10. 제1항에 있어서,
    상기 신뢰 정보를 요청하는 단계는, 상기 서비스 신뢰 API에 상기 보안 파라미터를 송신하는 단계를 포함하되,
    상기 보안 파라미터는, 상기 보안 파라미터에 관련된 정보를 모으기 위해 보안 데이터 컴파일러(security data compiler)를 구동할 것을 상기 서비스 클라우드에서 동작하는 TSSPR 원격 에이전트(Remote Agent: RA)에 요청하기 위해 상기 서비스 신뢰 API에 의해 사용되는,
    방법.
11. 제10항에 있어서,
    상기 신뢰 정보를 수신하는 단계는, 상기 데이터 신뢰 API가 상기 서비스 신뢰 API로부터 상기 보안 파라미터에 관련된 정보를 수신하는 단계를 포함하고,
    상기 신뢰 평가를 수행하는 단계는, 상기 보안 파라미터에 연관된 정보에 기반하여 신뢰 확인기(trust verifier)를 구동함으로써 상기 신뢰 평가를 시작할 것을 상기 데이터 신뢰 API가 상기 TSSPR HA에 요청하는 단계를 포함하는,
    방법.
12. 제11항에 있어서,
    상기 서비스 클라우드는 신뢰할 수 있는 것임을 상기 신뢰 확인기가 나타내는 경우 필터 규칙(filter rule)을 생성할 것을 상기 데이터 클라우드에 있는 뷰 필터 서버(view filter server)에게 상기 데이터 신뢰 API가 지시하는 단계를 더 포함하는,
    방법.
13. 제12항에 있어서,
    상기 뷰 필터 서버는 상기 데이터를 필터링하기 위해 상기 필터 규칙을 동적으로 생성하는,
    방법.
14. 제13항에 있어서,
    상기 뷰 필터 서버는 정책에 관련된 정보에 기반하여 상기 필터 규칙을 생성하는,
    방법.
15. 제14항에 있어서,
    상기 뷰 필터 서버가 정책 데이터베이스로부터 상기 정책에 관련된 정보를 획득하는 단계를 더 포함하는,
    방법.
16. 제13항에 있어서,
    상기 뷰 필터 서버는 상기 데이터와 연관된 메타데이터에 기반하여 상기 필터 규칙을 생성하는,
    방법.
17. 제12항에 있어서,
    상기 필터 규칙을 사용하여 상기 데이터를 필터링하는 단계; 및
    상기 필터링된 데이터를 상기 서비스 클라우드에 직접 송신하는 단계를 더 포함하되,
    상기 필터링된 데이터는 상기 서비스 클라우드의 상기 타겟 서비스와 함께 사용되는,
    방법.
18. 제12항에 있어서,
    상기 필터 규칙을 사용하여 상기 데이터를 필터링하는 단계; 및
    상기 서비스 클라우드로 하여금 URL을 통해 상기 필터링된 데이터를 액세스할 수 있도록 하기 위해 상기 서비스 클라우드에 상기 URL을 제공하는 단계를 더 포함하되,
    상기 필터링된 데이터는 상기 서비스 클라우드의 상기 타겟 서비스와 함께 사용되는,
    방법.
19. 제12항에 있어서,
    상기 뷰 필터 서버는 기본(atomic) 필터 규칙 및 카테고리화된(categorized) 필터 규칙의 조합인 복수의 필터 규칙을 생성하는,
    방법.
20. 제19항에 있어서,
    상기 기본 필터 규칙은, 상기 데이터에 대하여 지정된 타입의 정보를 각각 추가, 대체 또는 제거하는 ADD, REPLACE 또는 REMOVE 규칙을 포함하는,
    방법.
21. 제19항에 있어서,
    상기 카테고리화된 필터 규칙은 정책에 기반하여 생성되는,
    방법.
22. 제1항에 있어서,
    상기 데이터 신뢰 API는 복수의 계층을 포함하고,
    상기 방법은, 상기 복수의 계층에 대응하는 복수의 보안 파라미터를 식별할 것을 상기 데이터 신뢰 API가 상기 TSSPR HA에 요청하는 단계를 더 포함하는,
    방법.
23. 제22항에 있어서,
    상기 복수의 계층은,
    서비스로서의 인프라스트럭처(Infrastructure as a Service: Iaas) 계층;
    서비스로서의 플랫폼(Platform as a Service: PaaS) 계층; 및
    서비스로서의 소프트웨어(Software as a Service: SaaS) 계층을 포함하는,
    방법.
24. 제1항에 있어서,
    상기 신뢰 정보를 상기 서비스 클라우드에 요청하는 단계, 상기 신뢰 정보를 상기 서비스 클라우드로부터 수신하는 단계 및 상기 신뢰 정보에 기반하여 상기 서비스 클라우드의 상기 신뢰 평가를 수행하는 단계는 제3자 신뢰 조정기(third party trust orchestrator)를 통해 수행되는,
    방법.
25. 제1항에 있어서,
    사용자는 상기 데이터 클라우드와 제1 서비스 레벨 합의(Service Level Agreement: SLA)를 갖고 상기 서비스 클라우드와 제2 SLA를 갖는,
    방법.
26. 삭제
27. 데이터 신뢰 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API) 서버로서,
    프로세서(processor);
    스토리지(storage); 및
    입출력 유닛(input/output unit)을 포함하고,
    상기 스토리지는 상기 프로세서로 하여금 동작을 수행할 수 있도록 하는 명령어를 저장하되, 상기 동작은,
    상기 입출력 유닛을 통해, 사용자에 의해 요청된 타겟 서비스를 제공하는 서비스 클라우드의 서비스 신뢰 API에 신뢰 정보를 요청하는 것;
    상기 입출력 유닛을 통해, 상기 서비스 클라우드로부터 상기 신뢰 정보를 수신하는 것;
    상기 신뢰 정보에 기반하여 상기 서비스 클라우드의 신뢰 평가를 수행하는 것;
    상기 입출력 유닛을 통해, 상기 신뢰 평가의 결과에 따라 상기 서비스 클라우드로 데이터를 송신하는 것을 제어하는 것;
    상기 입출력 유닛을 통해, 상기 신뢰 평가의 결과가 상기 데이터를 사용하여 타겟 서비스(target service)를 제공하는 상기 서비스 클라우드는 신뢰할 수 있는 것임을 나타내는 경우 상기 서비스 클라우드로 상기 데이터를 송신하는 것;
    상기 입출력 유닛을 통해, 상기 서비스 신뢰 API에 상기 타겟 서비스를 서술하는 서비스 서술 정보(service description information)를 요청하는 것;
    상기 입출력 유닛을 통해, 상기 서비스 신뢰 API로부터 상기 서비스 서술 정보를 수신하는 것; 및
    상기 입출력 유닛을 통해, 상기 서비스 클라우드의 상기 신뢰 평가를 수행하는 데에 사용될 보안 파라미터를 식별하기 위해, 상기 서비스 서술 정보에 기반하여, 상기 데이터 신뢰 애플리케이션 프로그래밍 인터페이스 서버를 포함하는 데이터 클라우드에서 동작하는 타겟 시스템 보안 상태정보 검색(Target System Security Posture Retrieval: TSSPR) 호스트 에이전트(Host Agent: HA)에 요청을 송신하는 것을 제어하는 것을 포함하며,
    상기 서비스 신뢰 API는 상기 서비스 클라우드에서 동작하는 서비스 서술 데이터베이스로부터 상기 서비스 서술 정보를 검색하는,
    데이터 신뢰 애플리케이션 프로그래밍 인터페이스 서버.
    
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제

Images