다음을 통해 공유

Python용 Azure Attestation 클라이언트 라이브러리 - 버전 1.0.0

  • 아티클

MAA(Microsoft Azure Attestation) 서비스는 플랫폼의 신뢰성과 내부에서 실행되는 이진 파일의 무결성을 원격으로 확인하기 위한 통합 솔루션입니다. 이 서비스는 Intel(tm) SGX(Software Guard Extensions) Enclave 및 VBS(가상화 기반 보안) Enclave와 같은 TEE(신뢰할 수 있는 실행 환경)의 상태를 증명할 수 있는 기능과 함께 TPM(신뢰할 수 있는 플랫폼 모듈)에서 지원하는 플랫폼의 증명을 지원합니다.

증명은 소프트웨어 이진 파일이 신뢰할 수 있는 플랫폼에서 올바르게 인스턴스화되었음을 보여주는 프로세스입니다. 그러면 원격 신뢰 당사자가 이러한 의도된 소프트웨어만 신뢰할 수 있는 하드웨어에서 실행된다고 확신할 수 있습니다. Azure Attestation은 증명을 위한 통합 고객 지향 서비스 및 프레임워크입니다.

Azure Attestation을 사용하면 Azure 기밀 컴퓨팅 및 인텔리전트 에지 보호와 같은 최첨단 보안 패러다임을 사용할 수 있습니다. 고객은 컴퓨터의 위치, 해당 컴퓨터의 VM(가상 머신) 상태 및 해당 VM에서 enclave가 실행되는 환경을 독립적으로 확인할 수 있는 기능을 요청했습니다. Azure Attestation은 이러한 고객과 많은 추가적인 고객 요청에 권한을 부여합니다.

Azure Attestation은 컴퓨팅 엔터티로부터 증거를 받고, 이를 클레임 세트로 전환하며, 구성 가능한 정책에 대해 유효성을 검사하고, 클레임 기반 애플리케이션(예: 신뢰 당사자 및 감사 기관)에 대한 암호화 증명을 생성합니다.

이 패키지는 Python 2.7, 3.6~ 3.9로 테스트되었습니다.

Azure 라이브러리에 대한 자세한 내용은 Python용 Azure SDK 릴리스 페이지를 참조하세요.

소스 코드 | 패키지(PyPI) | API 참조 설명서 | 제품 설명서

시작

필수 조건

  • Azure 구독 Azure Attestation 서비스를 포함하여 Azure 서비스를 사용하려면 구독이 필요합니다. 기존 Azure 계정이 없는 경우 평가판에 등록하거나 계정을 만들 때 Visual Studio 구독 혜택을 사용할 수 있습니다.
  • 기존 Azure Attestation 인스턴스이거나 각 Azure 지역에서 사용할 수 있는 "공유 공급자"를 사용할 수 있습니다. Azure Attestation 서비스 인스턴스를 만들어야 하는 경우 Azure Portal 또는 Azure CLI를 사용할 수 있습니다.

패키지 설치

PyPI를 사용하여 Python용 Azure Attestation 클라이언트 라이브러리를 설치합니다.

pip install azure-security-attestation

클라이언트 인증

Azure Attestation 서비스와 상호 작용하려면 증명 클라이언트 또는 증명관리 클라이언트 클래스의 인스턴스를 만들어야 합니다. 포털에서 "증명 URI"로 표시할 수 있는 증명 엔드포인트와 클라이언트 개체를 인스턴스화하기 위한 클라이언트 자격 증명(클라이언트 ID, 클라이언트 암호, 테넌트 ID) 이 필요합니다.

클라이언트 비밀 자격 증명 인증은 이 시작 섹션에서 사용되고 있지만 Azure ID 패키지로 인증하는 더 많은 방법을 찾을 수 있습니다. 아래에 표시된 DefaultAzureCredential 공급자 또는 Azure SDK와 함께 제공되는 다른 자격 증명 공급자를 사용하려면 azure-identity 패키지를 설치해야 합니다.

pip install azure-identity

자격 증명 만들기/가져오기

아래 Azure CLI 코드 조각을 사용하여 클라이언트 비밀 자격 증명을 만들거나 가져옵니다.

  • 서비스 주체를 만들고 Azure 리소스에 대한 액세스를 구성합니다.

    az ad sp create-for-rbac -n <your-application-name> --skip-assignment

    출력:

    {
    "appId": "generated-app-ID",
    "displayName": "dummy-app-name",
    "name": "http://dummy-app-name",
    "password": "random-password",
    "tenant": "tenant-ID"
}

  • 서비스 주체 objectId를 기록해 둡

    az ad sp show --id <appId> --query objectId

    출력:

    "<your-service-principal-object-id>"

  • 위의 반환된 자격 증명을 사용하여 AZURE_CLIENT_ID (appId), AZURE_CLIENT_SECRET (암호) 및 AZURE_TENANT_ID (테넌트) 환경 변수를 설정합니다. 다음 예제에서는 Powershell에서 이 작업을 수행하는 방법을 보여줍니다.

    $Env:AZURE_CLIENT_ID="generated-app-ID"
$Env:AZURE_CLIENT_SECRET="random-password"
$Env:AZURE_TENANT_ID="tenant-ID"

Azure ID API 및 사용 방법에 대한 자세한 내용은 Azure ID 클라이언트 라이브러리를 참조하세요.

주요 개념

이 미리 보기 SDK에는 다음과 같은 네 가지 주요 기능 제품군이 제공됩니다.

Microsoft Azure Attestation 서비스는 "격리됨" 및 "AAD"의 두 가지 별도 모드로 실행됩니다. 서비스가 "격리" 모드로 실행되는 경우 고객은 인증 자격 증명 이외의 추가 정보를 제공하여 증명 인스턴스의 상태를 수정할 권한이 있는지 확인해야 합니다.

마지막으로, Azure Attestation 서비스를 사용할 수 있는 각 지역은 Azure 기준(공유 인스턴스에 적용된 정책이 없음)에 대한 확인만 필요한 SGX Enclave를 증명하는 데 사용할 수 있는 "공유" 인스턴스를 지원합니다. 공유 인스턴스에서는 TPM 증명을 사용할 수 없습니다. 공유 인스턴스에는 AAD 인증이 필요하지만 RBAC 정책이 없습니다. 유효한 AAD 전달자 토큰을 가진 고객은 공유 인스턴스를 사용하여 증명할 수 있습니다.

증명

SGX 또는 TPM 증명은 신뢰할 수 있는 실행 환경에서 수집된 증명의 유효성을 검사하여 해당 환경에 대한 Azure 기준과 해당 환경에 적용된 고객 정의 정책을 모두 충족하는지 확인하는 프로세스입니다.

증명 서비스 토큰 서명 인증서 검색 및 유효성 검사

Azure Attestation 서비스의 핵심 운영 보장 중 하나는 서비스가 "TCB에서 작동"한다는 것입니다. 즉, Microsoft 운영자가 서비스 작업을 변조하거나 클라이언트에서 보낸 손상된 데이터를 변조할 수 있는 방법은 없습니다. 이를 보장하기 위해 증명 서비스의 핵심은 Intel(tm) SGX Enclave에서 실행됩니다.

고객이 Enclave 내에서 작업이 실제로 수행되었는지 확인할 수 있도록 증명 서비스의 대부분의 응답은 증명 서비스의 Enclave 내에 있는 키로 서명된 JSON 웹 토큰으로 인코딩됩니다.

이 토큰은 지정된 인스턴스에 대해 MAA 서비스에서 발급한 서명 인증서로 서명됩니다.

MAA 서비스 인스턴스가 SGX Enclave에서 서비스가 실행되는 지역에서 실행 중인 경우 서버에서 발급한 인증서는 oe_verify_attestation_certificate API를 사용하여 확인할 수 있습니다.

정책 관리

각 증명 서비스 인스턴스에는 고객이 정의한 추가 조건을 정의하는 정책이 적용됩니다.

증명 정책에 대한 자세한 내용은 증명 정책을 참조하세요.

정책 관리 인증서 관리

증명 인스턴스가 "격리" 모드로 실행 중인 경우 인스턴스를 만든 고객은 인스턴스를 만들 때 정책 관리 인증서를 제공하게 됩니다. 모든 정책 수정 작업을 수행하려면 고객이 기존 정책 관리 인증서 중 하나를 사용하여 정책 데이터에 서명해야 합니다. 정책 관리 인증서 관리 API를 사용하면 클라이언트가 정책 관리 인증서를 "롤"할 수 있습니다.

격리 모드 및 AAD 모드

각 Microsoft Azure Attestation 서비스 인스턴스는 "AAD" 모드 또는 "격리" 모드에서 작동합니다. MAA 인스턴스가 AAD 모드에서 작동하는 경우 증명 인스턴스를 만든 고객이 Azure Active Directory 및 Azure 역할 기반 액세스 제어 정책을 통해 증명 인스턴스에 대한 액세스를 확인할 수 있음을 의미합니다.

AttestationType

Azure Attestation 서비스는 환경에 따라 다양한 유형의 증명을 지원합니다. 현재 MAA는 다음과 같은 신뢰할 수 있는 실행 환경을 지원합니다.

  • OpenEnclave - OpenEnclave oe_get_report 또는 oe_get_evidenceAPI 를 사용하여 증명 증거가 수집된 SGX Enclave에서 코드를 실행하는 Intel(tm) 프로세서입니다.
  • SgxEnclave - 인텔 SGX SDK를 사용하여 증명 증거가 수집된 SGX Enclave에서 코드를 실행하는 Intel(tm) 프로세서입니다.
  • Tpm - 프로세서의 신뢰할 수 있는 플랫폼 모듈을 사용하여 증명 증거를 제공하는 가상화 기반 보안 환경입니다.

런타임 데이터 및 Inittime 데이터

RuntimeData는 Intel SGX Quote 생성 논리 또는 API에 oe_get_report/oe_get_evidence 표시되는 데이터를 나타냅니다. 증명 API 호출자가 특성을 제공한 runtime_data 경우 Azure Attestation 서비스는 SGX Quote/OE Report/OE Evidence에 있는 필드의 report_data 처음 32바이트가 의 runtime_dataSHA256 해시와 일치하는지 확인합니다.

InitTime 데이터는 증명되는 SGX Enclave를 구성하는 데 사용되는 데이터를 나타냅니다.

InitTime 데이터는 Azure DCsv2 시리즈 가상 머신에서 지원되지 않습니다.

추가 개념

예제

클라이언트 인스턴스 만들기

uri endpoint에서 증명 클라이언트의 인스턴스를 만듭니다.

attest_client = AttestationClient(
    endpoint=base_uri,
    credential=DefaultAzureCredential())

증명 정책 가져오기

메서드는 set_policy 서비스에서 증명 정책을 검색합니다. 증명 정책은 증명 유형별로 인스턴스화되며 매개 변수는 AttestationType 검색할 형식을 정의합니다.

policy, token = attest_client.get_policy(AttestationType.SGX_ENCLAVE)
print('Instance SGX policy: ', policy)
print('Token: ', token)

지정된 증명 유형에 대한 증명 정책 설정

증명 서비스 인스턴스가 격리 모드에서 실행되는 경우 set_policy API는 호출자가 증명 인스턴스에 대한 정책을 수정할 권한이 있는지 확인하는 데 사용할 수 있는 서명 인증서(및 프라이빗 키)를 제공해야 합니다. 서비스 인스턴스가 AAD 모드에서 실행 중인 경우 서명 인증서 및 키는 선택 사항입니다.

SetPolicy API는 정책 문서 및 증명 서비스로 전송되는 서명 정보를 기반으로 JSON 웹 토큰 을 만듭니다.

policy_set_response = attest_client.set_policy(AttestationType.SGX_ENCLAVE,
    attestation_policy,
    signing_key=key,
    signing_certificate=signing_certificate)
new_policy, _ = attest_client.get_policy(AttestationType.SGX_ENCLAVE)
# `new_policy` will equal `attestation_policy`.

서비스 인스턴스가 AAD 모드에서 실행되는 경우 set_policy 호출을 간소화할 수 있습니다.

policy_set_response = attest_client.set_policy(AttestationType.SGX_ENCLAVE,            
    attestation_policy)
# Now retrieve the policy which was just set.
new_policy, _ = attest_client.get_policy(AttestationType.SGX_ENCLAVE)

클라이언트는 증명 서비스의 enclave에서 정책 문서를 받기 전에 증명 정책 문서가 수정되지 않은지 확인할 수 있어야 합니다.

PolicyResult에는 서비스에서 정책 문서를 수신했는지 확인하는 데 사용할 수 있는 두 가지 속성이 있습니다.

  • policy_signer - 호출에 set_policy 서명 인증서가 포함된 경우 호출 시 제공된 인증서입니다 set_policy . 정책 서명자가 설정되지 않은 경우 null이 됩니다.
  • policy_token_hash - 서비스로 전송된 JSON 웹 토큰 의 해시입니다.

해시를 확인하기 위해 클라이언트는 증명 정책 토큰을 생성하고 해당 토큰에서 생성된 해시를 확인할 수 있습니다.

from cryptography.hazmat.primitives import hashes

expected_policy = AttestationPolicyToken(
    attestation_policy,
    signing_key=key,
    signing_certificate=signing_certificate)
hasher = hashes.Hash(hashes.SHA256())
hasher.update(expected_policy.serialize().encode('utf-8'))
expected_hash = hasher.finalize()

# `expected_hash` will exactly match `policy_set_response.policy_token_hash`

SGX Enclave 증명

attest_sgx_enclave 메서드를 사용하여 SGX enclave를 증명합니다.

고객이 암호화된 환경과 상호 작용하는 핵심 과제 중 하나는 환경에서 실행되는 코드("enclave 코드")와 안전하게 통신할 수 있도록 하는 방법입니다.

이 문제에 대한 한 가지 해결 방법은 Enclave 코드와의 보안 통신을 가능하게 하는 패턴인 "보안 키 릴리스"입니다.

"보안 키 릴리스" 패턴을 구현하기 위해 Enclave 코드는 임시 비대칭 키를 생성합니다. 그런 다음 키의 퍼블릭 부분을 일부 형식(JSON 웹 키 또는 PEM 또는 다른 serialization 형식)으로 직렬화합니다.

그런 다음 enclave 코드는 공개 키의 SHA256 값을 계산하고 SGX 견적을 생성하는 코드에 대한 입력으로 전달합니다(OpenEnclave의 경우 oe_get_evidence 또는 oe_get_report).

그런 다음 클라이언트는 SGX 견적과 직렬화된 키를 증명 서비스에 보냅니다. 증명 서비스는 견적의 유효성을 검사하고 키의 해시가 견적에 있는지 확인하고 "증명 토큰"을 발급합니다.

그런 다음 클라이언트는 해당 증명 토큰(직렬화된 키 포함)을 타사 "신뢰 당사자"로 보낼 수 있습니다. 그런 다음 신뢰 당사자는 증명 서비스가 증명 토큰을 생성했는지 확인하므로 직렬화된 키를 사용하여 "신뢰 당사자"가 보유한 일부 데이터를 암호화하여 서비스로 보낼 수 있습니다.

이 예제에서는 요청과 연결된 증명 토큰을 검색하기 위해 증명 서비스로 호출하는 일반적인 패턴 중 하나를 보여 줍니다.

이 예제에서는 엔드포인트에 대한 기본 URI로 구성된 기존 AttestationClient 개체가 있다고 가정합니다. 또한 증명하려는 SGX Enclave 내에서 생성된 SGX 견적(quote)과 SGX 견적에서 참조되는 "런타임 데이터"(runtime_data)가 있다고 가정합니다.

response, token = attest_client.attest_sgx_enclave(quote, runtime_data=runtime_data)

이 시점에서 attestationResult의 enclave_held_data 특성은 입력 이진 runtime_data 보유합니다.

이제 토큰이 "신뢰 당사자"에 전달됩니다. 신뢰 당사자는 토큰이 증명 서비스에서 발급되었는지 확인합니다. 그런 다음 EnclaveHeldData 필드에서 비대칭 키를 추출합니다. 그러면 신뢰 당사자는 비대칭 키를 사용하여 "키" 데이터를 암호화하고 enclave로 다시 전송합니다.

encrypted_data = send_token_to_relying_party(attestationResult.Token)

이제 암호화된 데이터를 enclave에 전달하여 해당 데이터의 암호를 해독할 수 있습니다.

증명 토큰 유효성 검사를 수행하는 방법에 대한 추가 정보는 MAA 서비스 증명 샘플에서 찾을 수 있습니다.

토큰 인증서 검색

를 사용하여 get_signing_certificates 증명 서비스에서 반환된 토큰의 유효성을 검사하는 데 사용할 수 있는 인증서를 검색합니다.

signers = attest_client.get_signing_certificates()
for signer in signers:
    from cryptography.hazmat.backends import default_backend
    cert = cryptography.x509.load_pem_x509_certificate(signer.certificates[0].encode('ascii'), backend=default_backend())
    print('Cert  iss:', cert.issuer, '; subject:', cert.subject)

문제 해결

대부분의 증명 서비스 작업은 Azure Core에 정의된 예외를 발생합니다. 증명 서비스 API는 유용한 오류 코드와 함께 오류 발생 시 을 throw HttpResponseError 합니다. 이러한 오류 중 대부분은 복구할 수 있습니다.

try:
    response, _ = attest_client.attest_sgx_enclave(
        quote,
        runtime_data=AttestationData(runtime_data, is_json=False))
except HttpResponseError as ex:
    # Ignore invalid quote errors.
    if ex.error == "InvalidParameter":
        pass
}

MAA 서비스에 대한 추가 문제 해결 정보는 여기에서 찾을 수 있습니다.

다음 단계

Microsoft Azure Attestation 서비스에 대한 자세한 내용은 설명서 페이지를 참조하세요.

참여

이 프로젝트에 대한 기여와 제안을 환영합니다. 대부분의 경우 기여하려면 권한을 부여하며 실제로 기여를 사용할 권한을 당사에 부여한다고 선언하는 CLA(기여자 라이선스 계약)에 동의해야 합니다. 자세한 내용은 기여자 라이선스 계약 사이트를 참조하세요.

끌어오기 요청을 제출하면 CLA-bot은 CLA를 제공하고 PR을 적절하게 데코레이팅해야 하는지 여부를 자동으로 결정합니다(예: 레이블, 설명). 봇에서 제공하는 지침을 따르기만 하면 됩니다. 이 작업은 CLA를 사용하여 모든 리포지토리에서 한 번만 수행하면 됩니다.

이 프로젝트에는 Microsoft Open Source Code of Conduct(Microsoft 오픈 소스 준수 사항)가 적용됩니다. 자세한 내용은 사용 규정 FAQ를 참조하거나 opencode@microsoft.com에 추가 질문 또는 의견을 알려주세요.

이러한 라이브러리를 빌드, 테스트 및 기여하는 방법에 대한 자세한 내용은 CONTRIBUTING.md 참조하세요.

피드백 제공

버그가 발생하거나 제안이 있는 경우 프로젝트의 문제 섹션에 문제를 제출하세요.

Impressions