다음을 통해 공유

Azure Monitor 고객 관리형 키

  • 아티클

Azure Monitor의 데이터는 Microsoft 관리형 키를 사용하여 암호화됩니다. 사용자 고유의 암호화 키를 사용하여 작업 영역에서 데이터 및 저장된 쿼리를 보호할 수 있습니다. Azure Monitor에서 고객 관리형 키를 사용하면 로그에 대한 액세스 제어를 보다 유연하게 관리할 수 있습니다. 구성되면 연결된 작업 영역에 수집된 새 데이터가 Azure Key Vault 또는 Azure Key Vault 관리형 “HSM”에 저장된 키로 암호화됩니다.

구성 전에 제한 사항 및 제약 조건을 검토하세요.

고객 관리형 키 개요

미사용 암호화는 조직의 일반적인 개인 정보 보호 및 보안 요구 사항입니다. Azure에서 미사용 암호화를 완전히 관리하도록 하거나 암호화 및 암호화 키를 긴밀하게 관리하는 다양한 옵션을 사용할 수 있습니다.

Azure Monitor를 사용하면 모든 데이터 및 저장된 쿼리가 MMK(Microsoft 관리형 키)를 사용하여 미사용 상태로 암호화됩니다. Azure Monitor의 암호화 사용은 Azure Storage 암호화가 작동하는 방식과 동일합니다.

키 수명 주기를 관리하고 데이터에 대한 액세스 권한을 취소할 수 있도록 Azure Key Vault에서 고유한 키를 사용하여 데이터를 암호화할 수 있습니다.

고객 관리형 키는 전용 클러스터에서 사용할 수 있으며 더 높은 수준의 보호 및 제어를 제공합니다. 데이터는 스토리지에서 두 번 암호화됩니다.즉, Microsoft 관리형 키 또는 고객 관리형 키를 사용하는 서비스 수준에서 한 번 암호화되고, 두 개의 서로 다른 암호화 알고리즘과 두 개의 서로 다른 키를 사용하여 인프라 수준에서 한 번 암호화됩니다. 이중 암호화는 암호화 알고리즘 또는 키 중 하나가 손상될 수 있는 상황으로부터 보호합니다. 전용 클러스터에서는 Lockbox를 사용하여 데이터를 보호할 수도 있습니다.

지난 14일 동안 수집되었거나 최근에 쿼리에 사용된 데이터는 쿼리 효율성을 위해 핫 캐시(SSD 지원)에 보관됩니다. SSD 데이터는 고객 관리형 키를 구성하는지 여부에 관계없이 Microsoft 키로 암호화되지만 SSD 액세스에 대한 제어는 키 해지를 따릅니다.

Important

전용 클러스터는 하루에 100GB 이상의 약정 계층 가격 책정 모델을 사용합니다.

Azure Monitor에서 고객 관리형 키가 작동하는 방식

Azure Monitor는 관리 ID를 사용하여 Azure Key Vault에 대한 액세스 권한을 부여합니다. 클러스터 수준에서 Log Analytics 클러스터의 ID가 지원됩니다. 여러 작업 영역에서 고객 관리형 키를 허용하기 위해 Log Analytics 클러스터 리소스에서 Key Vault와 Log Analytics 작업 영역 간의 중간 ID 연결 역할을 수행합니다. 클러스터의 스토리지는 클러스터와 연결된 관리 ID를 사용하여 Microsoft Entra ID를 통해 Azure Key Vault에 인증합니다.

클러스터는 두 가지 관리 ID 유형(시스템 할당 및 사용자 할당)을 지원하지만 시나리오에 따라 클러스터에서 단일 ID를 정의할 수 있습니다.

  • 시스템 할당 관리 ID는 더 간단하며 클러스터로 설정된 SystemAssigned경우 identity type 자동으로 생성됩니다. 이 ID는 나중에 데이터 암호화 및 암호 해독을 위해 Key Vault에 스토리지 액세스 권한을 부여하는 데 사용됩니다.
  • 사용자가 할당한 관리 ID를 사용하면 클러스터를 만들 때 identity type UserAssigned고객 관리형 키를 구성하고 클러스터를 만들기 전에 Key Vault에서 권한을 부여할 수 있습니다.

고객 관리형 키를 새 클러스터 또는 작업 영역에 연결되어 있고 이미 데이터를 수집하고 있는 기존 클러스터에 구성할 수 있습니다. 연결된 작업 영역에 수집된 새 데이터는 키로 암호화되고 구성 전에 수집된 이전 데이터는 Microsoft 키로 암호화되어 있습니다. 고객 관리형 키 구성은 쿼리에 영향을 주지 않고 이전 데이터와 새 데이터에서 원활하게 실행됩니다. 언제든지 클러스터에서 작업 영역의 연결을 해제할 수 있습니다. 연결 해제 후 수집되는 새 데이터는 Microsoft 키로 암호화되고 쿼리는 이전 데이터와 새 데이터 간에 원활하게 수행됩니다.

Important

고객 관리형 키 기능은 지역에 따라 다를 수 있습니다. Azure Key Vault, 클러스터 및 연결된 작업 영역은 동일한 지역에 있어야 하지만 서로 다른 구독에 있을 수 있습니다.

고객 관리형 키 개요 스크린샷.

  1. Key Vault
  2. Key Vault에 대한 권한이 있는 관리 ID를 사용하는 Log Analytics 클러스터 리소스 - 이 ID는 기본 전용 클러스터 스토리지로 전파됩니다.
  3. 전용 클러스터
  4. 전용 클러스터에 연결된 작업 영역

암호화 키 작업

스토리지 데이터 암호화에는 세 가지 유형의 키가 있습니다.

  • “KEK” - 키 암호화 키(고객 관리형 키)
  • “AEK” - 계정 암호화 키
  • “DEK” - 데이터 암호화 키

다음 규칙이 적용됩니다.

  • 클러스터 스토리지의 모든 스토리지 계정에는 “AEK”라고 하는 고유한 암호화 키가 있습니다.
  • “AEK”는 디스크에 기록되는 각 데이터 블록을 암호화하는 데 사용되는 키인 “DEK”를 파생하는 데 사용됩니다.
  • Key Vault에서 키를 구성하고 클러스터의 키 세부 정보를 업데이트하면 클러스터 스토리지는 암호화 및 암호 해독을 위해 ‘래핑’ 및 ‘래핑 해제’ “AEK”에 대한 요청을 수행합니다.
  • “KEK”는 Key Vault를 유지하며, 관리형 “HSM”을 사용하는 경우 하드웨어를 그대로 유지합니다.
  • Azure Storage는 인증을 위해 ‘클러스터’ 리소스와 연결된 관리 ID를 사용합니다. Microsoft Entra ID를 통해 Azure Key Vault에 액세스합니다.

고객 관리형 키 프로비저닝 단계

  1. Azure Key Vault 만들기 및 키 저장
  2. 클러스터 만들기
  3. Key Vault에 권한 부여
  4. 키 식별자 세부 정보를 사용하여 클러스터 업데이트
  5. 작업 영역 연결

고객 관리형 키 구성은 현재 Azure Portal에서 지원되지 않으며 PowerShell, CLI 또는 REST 요청을 통해 프로비저닝을 수행할 수 있습니다.

암호화 키(“KEK”) 저장

Azure Key Management 제품의 포트폴리오에는 사용할 수 있는 자격 증명 모음 및 관리형 HSM이 나열됩니다.

클러스터가 계획되는 지역에서 기존 Azure Key Vault를 사용하거나 새로 만듭니다. Key Vault에서 로그 암호화에 사용할 키를 생성하거나 가져옵니다. Azure Monitor에서 키와 데이터에 대한 액세스를 보호하기 위해 Azure Key Vault를 복구 가능으로 구성해야 합니다. 이 구성은 Key Vault의 속성에서 확인할 수 있습니다. 일시 삭제 및 제거 보호를 모두 사용하도록 설정되어 있어야 합니다.

일시 삭제 및 제거 방지 설정의 스크린샷.

이러한 설정은 CLI 및 PowerShell을 통해 키 자격 증명 모음에서 업데이트할 수 있습니다.

  • 일시 삭제
  • 제거 보호는 일시 삭제 후에도 비밀, 자격 증명 모음을 강제로 삭제하지 않도록 방지합니다.

클러스터 만들기

클러스터는 Key Vault를 통한 데이터 암호화에 관리 ID를 사용합니다. 데이터 암호화 및 암호 해독 작업을 위해 Key Vault에 대한 액세스를 허용하도록 클러스터를 만들 때 또는 UserAssigned 클러스터를 만들 때 속성을 SystemAssigned 구성 identity type 합니다.

시스템이 할당한 관리 ID에 대한 클러스터의 ID 설정

{
  "identity": {
    "type": "SystemAssigned"
    }
}

참고 항목

다음 사항을 고려하여 수집 또는 쿼리를 중단하지 않고 클러스터를 만든 후 ID 유형을 변경할 수 있습니다.

  • 업데이트 SystemAssigned - UserAssignedKey Vault에서 UserAssign ID를 부여한 다음 클러스터에서 업데이트 identity type
  • 업데이트 UserAssigned - 클러스터 identity type 를 SystemAssigned업데이트한 후 시스템 할당 관리 ID가 SystemAssigned생성되었으므로 다음 단계를 따라야 합니다.
    1. 클러스터를 업데이트하고 키(set keyVaultUri) keyName및 keyVersion 값 ""을 사용하여 제거합니다.
    2. 클러스터를 identity type 로 업데이트 SystemAssigned
    3. Key Vault 업데이트 및 ID에 대한 권한 부여
    4. 클러스터에서 키 업데이트

전용 클러스터 문서에 설명된 절차를 따르세요.

Key Vault 권한 부여

Key Vault에는 클러스터 및 언더레이 스토리지에 액세스 권한을 부여하는 두 가지 권한 모델(Azure RBAC(Azure 역할 기반 액세스 제어) 및 자격 증명 모음 액세스 정책(레거시))이 있습니다.

  1. 제어하는 Azure RBAC 할당(권장)

    역할 할당을 추가하려면 Microsoft.Authorization/roleAssignments/write 및 Microsoft.Authorization/roleAssignments/delete 권한이 있는 역할(예: 사용자 액세스 관리자 또는 소유자)이 있어야 합니다.

    1. Azure Portal에서 Key Vault를 열고 설정>액세스 구성>Azure 역할 기반 액세스 제어를 선택하고 적용
    2. [이동]을 클릭하여 액세스 제어(IAM) 단추를 클릭하고 Key Vault Crypto Service Encryption 사용자 역할 할당을 추가 합니다.
    3. 구성원 탭에서 관리 ID를 선택하고 ID 및 ID에 대한 구독을 멤버로 선택합니다.

    Key Vault RBAC 권한 부여 스크린샷.

  2. 자격 증명 모음 액세스 정책 할당(레거시)

    Azure Portal에서 Key Vault를 열고, 액세스 정책>자격 증명 모음 액세스 정책>+ 액세스 정책 추가를 선택하여 다음 설정으로 정책을 만듭니다.

    • 키 권한 - 가져오기, 키 래핑 및 키 래핑 해제를 선택합니다.
    • 클러스터에서 사용되는 ID 유형(시스템 또는 사용자가 할당한 관리 ID)에 따라 보안 주체를 선택합니다.
      • 시스템이 할당한 관리 ID - 클러스터 이름 또는 클러스터 보안 주체 ID 입력
      • 사용자가 할당한 관리 ID - ID 이름 입력

    Key Vault 액세스 정책 권한 부여 스크린샷.

    Azure Monitor 데이터에 대한 액세스와 키를 보호하기 위해 Key Vault가 복구 가능으로 구성되었는지 확인하려면 가져오기 권한이 필요합니다.

키 식별자 세부 정보를 사용하여 클러스터 업데이트

클러스터의 모든 작업에는 Microsoft.OperationalInsights/clusters/write 작업 권한이 필요합니다. 이 권한은 */write 작업이 포함된 소유자 또는 기여자나 Microsoft.OperationalInsights/* 작업이 포함된 Log Analytics 기여자 역할을 통해 부여할 수 있습니다.

이 단계에서는 “AEK” 래핑 및 래핑 해제에 사용할 키 및 버전으로 전용 클러스터 스토리지를 업데이트합니다.

Important

  • 키 회전은 자동 또는 명시적 키 버전별로 수행될 수 있습니다. 클러스터에서 키 식별자 세부 정보를 업데이트하기 전에 적합한 방법을 확인하려면 키 회전을 참조하세요.
  • 클러스터 업데이트 시 동일한 작업에 ID 및 키 식별자 세부 정보를 둘 다 포함해서는 안 됩니다. 둘 다 업데이트해야 하는 경우 두 번의 연속 작업으로 업데이트를 수행해야 합니다.

Key Vault 권한 부여 스크린샷.

키 식별자 세부 정보를 사용하여 클러스터에서 KeyVaultProperties를 업데이트합니다.

작업은 비동기식이며 완료하는 데 시간이 걸릴 수 있습니다.

해당 없음

Important

이 단계는 클러스터 프로비저닝 후에 수행해야 합니다. 프로비저닝하기 전에 작업 영역을 연결하고 데이터를 수집하면 수집된 데이터가 삭제되어 복구할 수 없습니다.

이 작업을 수행하려면 작업 영역 및 클러스터에 대한 “쓰기” 권한이 있어야 합니다. 이 하위 범위에는 Microsoft.OperationalInsights/workspaces/write과 Microsoft.OperationalInsights/clusters/write이 포함되며.

전용 클러스터 문서에 설명된 절차를 따르세요.

키 해지

Important

  • 데이터에 대한 액세스를 취소하는 권장 방법은 키를 사용하지 않도록 설정하거나 키 자격 증명 모음에서 액세스 정책을 삭제하는 것입니다.
  • 클러스터의 identity type을 None으로 설정하면 데이터에 대한 액세스도 철회되지만, 이 접근 방식은 지원 담당자에게 문의하지 않고 되돌릴 수 없기 때문에 권장되지 않습니다.

클러스터 스토리지는 키 권한의 변경 내용을 항상 1시간 이내에 적용합니다. 이로 인해 스토리지가 사용할 수 없게 됩니다. 연결된 작업 영역에 수집된 새 데이터는 삭제되고 복구할 수 없습니다. 이러한 작업 영역에서는 데이터에 액세스할 수 없으며 쿼리가 실패합니다. 클러스터와 작업 영역을 삭제하지 않는 한 이전에 수집된 데이터는 스토리지에서 유지됩니다. 액세스할 수 없는 데이터는 데이터 보존 정책에 따라 제어되며 보존 기간에 도달하면 삭제됩니다. 지난 14일 동안 수집된 데이터와 최근 쿼리에 사용된 데이터도 쿼리 효율성을 위해 핫 캐시(SSD 지원)에 보관됩니다. SSD의 데이터는 키 해지 작업에서 삭제되고 액세스할 수 없게 됩니다. 클러스터 스토리지는 주기적으로 래핑 및 래핑 해제를 위해 Key Vault에 도달하려고 시도하며, 키를 사용하도록 설정되면 래핑 해제가 성공하고, SSD 데이터가 스토리지에서 다시 로드되고, 데이터 수집 및 쿼리가 30분 이내에 다시 시작됩니다.

키 회전

키 회전에는 두 가지 모드가 있습니다.

  • 자동 연결 - 클러스터의 속성을 업데이트 "keyVaultProperties" 하고 속성을 생략 "keyVersion" 하거나 으로 ""설정합니다. 스토리지는 자동으로 최신 키 버전을 사용합니다.
  • 명시적 키 버전 업데이트 - 속성을 업데이트 "keyVaultProperties" 하고 속성의 키 버전을 "keyVersion" 업데이트합니다. 키 회전을 사용하려면 클러스터에서 "keyVersion" 속성을 명시적으로 업데이트해야 합니다. 자세한 내용은 키 식별자 세부 정보로 클러스터 업데이트를 참조하세요. Key Vault에서 새 키 버전을 생성하지만 클러스터에서 키를 업데이트하지 않는 경우 클러스터 스토리지는 이전 키를 계속 사용합니다. 클러스터에서 새 키를 업데이트하기 전에 이전 키를 사용하지 않도록 설정하거나 삭제하면 키 해지 상태가 됩니다.

키 회전 작업 중 및 후에 모든 데이터에 액세스할 수 있습니다. 데이터는 Key Vault의 새 키 암호화 키(“KEK”) 버전으로 암호화되는 계정 암호화 키(“AEK”)로 항상 암호화됩니다.

저장된 쿼리 및 로그 검색 경고를 위한 고객 관리형 키

Log Analytics에 사용되는 쿼리 언어는 표현적이며 설명 또는 쿼리 구문에 중요한 정보를 포함할 수 있습니다. 일부 조직에서는 이러한 정보가 고객 관리형 키 정책에 따라 보호된 상태로 유지되어야 하며 암호화된 쿼리를 키로 저장해야 합니다. Azure Monitor를 사용하면 작업 영역에 연결될 때 저장된 쿼리 및 키로 암호화된 로그 검색 경고를 자체 스토리지 계정에 저장할 수 있습니다.

통합 문서에 대한 고객 관리형 키

저장된 쿼리 및 로그 검색 경고에 대한 고객 관리형 키에 대해 언급된 고려 사항을 통해 Azure Monitor를 사용하면 통합 문서 '저장' 작업에서 Azure Storage 계정에 콘텐츠 저장을 선택할 때 키로 암호화된 통합 문서 쿼리를 자신의 스토리지 계정에 저장할 수 있습니다.

통합 문서 저장 스크린샷.

참고 항목

고객 관리형 키 구성(Azure 대시보드, Azure 논리 앱, Azure Notebooks 및 Automation Runbook)에 관계없이 다음 시나리오에서는 쿼리가 Microsoft 키("MMK")로 암호화된 상태로 유지됩니다.

저장된 쿼리에 대해 스토리지 계정을 연결하면 서비스는 저장된 쿼리와 로그 검색 경고 쿼리를 스토리지 계정에 저장합니다. 스토리지 계정 및 미사용 암호화 정책을 제어하면 고객 관리형 키를 사용하여 저장된 쿼리와 로그 검색 경고를 보호할 수 있습니다. 그러나 해당 스토리지 계정과 관련된 비용은 사용자가 부담합니다.

검색어에 대해 고객 관리형 키를 설정하기 전 고려 사항

  • 작업 영역 및 스토리지 계정에 대한 “쓰기” 권한이 있어야 합니다.
  • 고객 관리형 키 암호화를 사용하여 Log Analytics 작업 영역이 있는 동일한 지역에 스토리지 계정을 만들어야 합니다. 저장된 쿼리는 Table Storage에 저장되고 스토리지 계정을 만들 때만 암호화할 수 있기 때문에 이는 중요합니다.
  • 쿼리 팩에 저장된 쿼리는 고객 관리형 키로 암호화되지 않습니다. 대신 쿼리를 저장할 때 레거시 쿼리로 저장을 선택하여 고객 관리형 키로 보호합니다.
  • 스토리지에 저장된 쿼리는 서비스 아티팩트로 간주되며 해당 형식이 변경될 수 있습니다.
  • 쿼리에 스토리지 계정을 연결하면 작업 영역에서 기존의 저장된 쿼리가 제거됩니다. 이 구성 전에 필요한 쿼리를 복사하고 저장합니다. PowerShell을 사용하여 저장된 쿼리를 볼 수 있습니다.
  • 쿼리에 대한 스토리지 계정을 연결할 때는 쿼리 '기록' 및 '대시보드에 고정'이 지원되지 않습니다.
  • 저장된 쿼리와 로그 검색 경고 쿼리 모두에 대해 단일 스토리지 계정을 작업 영역에 연결할 수 있습니다.
  • 로그 검색 경고는 Blob Storage에 저장되며, 고객 관리형 키 암호화는 스토리지 계정을 만들 때 또는 그 이후에 구성할 수 있습니다.
  • 실행된 로그 검색 경고에는 검색 결과나 경고 쿼리가 포함되지 않습니다. 경고 차원을 사용하여 발생한 경고의 컨텍스트를 가져올 수 있습니다.

저장된 쿼리를 위한 BYOS 구성

쿼리용 스토리지 계정을 연결하여 스토리지 계정에 저장된 쿼리를 유지합니다.

해당 없음

구성 후에는 새 저장된 검색 쿼리가 스토리지에 저장됩니다.

로그 검색 경고 쿼리를 위한 BYOS 구성

경고용 스토리지 계정을 연결하여 스토리지 계정에 로그 검색 경고 쿼리를 보관합니다.

해당 없음

구성 후에는 새 경고 쿼리가 스토리지에 저장됩니다.

고객 Lockbox

Lockbox는 지원 요청 중에 데이터에 액세스하는 Microsoft 엔지니어 요청을 승인하거나 거부할 수 있는 컨트롤을 제공합니다.

Lockbox는 Azure Monitor의 전용 클러스터에서 제공되며, 여기서 데이터 액세스 권한은 구독 수준에서 부여됩니다.

Microsoft Azure용 고객 Lockbox에 대해 자세히 알아보세요.

고객 관리형 키 작업

고객 관리형 키는 전용 클러스터에서 제공되며 이러한 작업은 전용 클러스터 문서를 참조하세요.

  • 리소스 그룹의 모든 클러스터 가져오기
  • 구독의 모든 클러스터 가져오기
  • 클러스터의 용량 예약 업데이트
  • 클러스터에서 billingType 업데이트
  • 클러스터에서 작업 영역 연결 끊기
  • 클러스터 삭제

제한 사항 및 제약 조건

  • 각 지역과 구독에 최대 5개의 활성 클러스터를 만들 수 있습니다.

  • 각 지역과 구독에 최대 7개의 예약된 클러스터(활성 또는 최근에 삭제됨)가 존재할 수 있습니다.

  • 최대 1,000개의 Log Analytics 작업 영역을 클러스터에 연결할 수 있습니다.

  • 특정 작업 영역에서 최대 두 개의 작업 영역 연결 작업이 30일 동안 허용됩니다.

  • 클러스터를 다른 리소스 그룹 또는 구독으로 이동하는 것은 현재 지원되지 않습니다.

  • 클러스터 업데이트 시 동일한 작업에 ID 및 키 식별자 세부 정보를 둘 다 포함해서는 안 됩니다. 둘 다 업데이트해야 하는 경우 업데이트 작업을 두 번 연속해서 수행해야 합니다.

  • 현재 중국에서는 Lockbox를 사용할 수 없습니다.

  • Lockbox는 보조 계획이 있는 테이블에는 적용되지 않습니다.

  • 이중 암호화는 2020년 10월부터 지원되는 지역에서 생성된 클러스터에 자동으로 구성됩니다. 클러스터에 GET 요청을 보내고 이중 암호화가 사용 설정된 클러스터의 isDoubleEncryptionEnabled 값이 true인지 관찰하여 클러스터가 이중 암호화로 구성되었는지 확인할 수 있습니다.

    • 클러스터를 만들 때 “region-name은 클러스터의 이중 암호화를 지원하지 않습니다” 오류가 발생하는 경우 REST 요청 본문에 "properties": {"isDoubleEncryptionEnabled": false}를 추가하여 이중 암호화 없이 클러스터를 만들 수 있습니다.
    • 클러스터를 만든 후에는 이중 암호화 설정을 변경할 수 없습니다.

  • 클러스터에 연결된 동안 연결된 작업 영역을 삭제할 수 있습니다. 일시 삭제 기간 동안 작업 영역을 복구하기로 결정하면 이전 상태로 돌아와 계속 클러스터에 연결되어 있습니다.

  • 고객 관리형 키 암호화는 구성 시간 이후 새로 수집된 데이터에 적용됩니다. 구성 이전에 수집된 데이터는 Microsoft 키로 암호화된 상태로 유지됩니다. 고객 관리형 키 구성 전후에 수집된 데이터를 원활하게 쿼리할 수 있습니다.

  • Azure Key Vault는 복구 가능으로 구성해야 합니다. 이러한 속성은 기본적으로 사용하도록 설정되지 않으므로 CLI 또는 PowerShell을 사용하여 구성해야 합니다.

    • 일시 삭제입니다.
    • 일시 삭제 후에도 비밀 자격 증명 모음을 강제 삭제로부터 보호하려면 제거 보호를 켜야 합니다.

  • Azure Key Vault, 클러스터 및 작업 영역은 동일한 지역 및 동일한 Microsoft Entra 테넌트에 있어야 하지만 구독은 서로 다를 수 있습니다.

  • 클러스터의 identity type을 None으로 설정하면 데이터에 대한 액세스도 철회되지만, 이 접근 방식은 지원 담당자에게 문의하지 않고 되돌릴 수 없기 때문에 권장되지 않습니다. 데이터에 대한 액세스를 철회하는 데 권장되는 방법은 키 해지입니다.

  • 키 자격 증명 모음 프라이빗-링크(vNet)에 있는 경우 사용자가 할당한 관리 ID와 함께 고객 관리형 키를 사용할 수 없습니다. 이 시나리오에서는 시스템이 할당한 관리 ID를 사용할 수 있습니다.

  • 보조 테이블 계획은 고객 관리형 키를 지원하지 않습니다. 보조 계획이 있는 테이블의 데이터는 자체 암호화 키를 사용하여 Log Analytics 작업 영역의 나머지 부분에 있는 데이터를 보호하더라도 Microsoft 관리형 키로 암호화됩니다.

문제 해결

  • Key Vault 가용성별 동작:

    • 정상 작업 - 스토리지에서 “AEK”를 짧은 시간 동안 캐시하고, Key Vault로 돌아가서 래핑을 주기적으로 해제합니다.

    • Key Vault 연결 오류 - 스토리지는 가용성 문제가 있는 동안 키가 캐시에 유지되도록 허용하여 일시적인 오류(시간 초과, 연결 실패, “DNS” 문제)를 처리하며 이는 일시적 오류 및 가용성 문제를 해결합니다. 쿼리 및 수집 기능은 중단 없이 계속됩니다.

  • Key Vault 액세스 속도 - 래핑 및 래핑 해제를 위해 클러스터 스토리지가 Key Vault에 액세스하는 빈도는 6~60초입니다.

  • 프로비저닝 또는 업데이트 상태인 클러스터를 업데이트할 경우 업데이트에 실패합니다.

  • 클러스터를 만들 때 충돌 오류가 발생하면 이름이 같은 클러스터가 지난 14일 이내에 삭제되어 예약된 상태로 유지되는 것일 수 있습니다. 삭제된 클러스터 이름은 삭제 후 14일이 경과하면 사용할 수 있습니다.

  • 작업 영역이 다른 클러스터에 연결된 경우 클러스터에 작업 영역을 연결하지 못합니다.

  • 클러스터를 만들고 KeyVaultProperties를 즉시 지정하는 경우 ID가 클러스터에 할당되고 Key Vault에 부여될 때까지 작업이 실패할 수 있습니다.

  • 기존 클러스터를 KeyVaultProperties로 업데이트하고 키 '가져오기' 액세스 정책이 Key Vault에 없으면 작업이 실패합니다.

  • 클러스터를 배포하지 못한 경우 Azure Key Vault, 클러스터 및 연결된 작업 영역이 동일한 지역에 있는지 확인합니다. 서로 다른 구독에 있을 수 있습니다.

  • Key Vault에서 키를 회전하고 클러스터에서 새 키 식별자 세부 정보를 업데이트하지 않으면 클러스터는 이전 키를 계속 사용하고 데이터에 액세스할 수 없게 됩니다. 데이터 수집 및 쿼리를 다시 시작하려면 클러스터에서 새 키 식별자 세부 정보를 업데이트합니다. 스토리지에서 항상 지연 키 버전을 자동으로 사용하도록 키 버전을 "''"로 업데이트할 수 있습니다.

  • 일부는 장기 작업이며 클러스터 만들기, 클러스터 키 업데이트, 클러스터 삭제 등의 작업을 완료하는 데 시간이 걸릴 수 있습니다. GET 요청을 클러스터 또는 작업 영역으로 전송하여 작업 상태를 확인하고 응답을 관찰할 수 있습니다. 예를 들어 연결되지 않은 작업 영역에는 features 아래에 clusterResourceId가 없습니다.

  • 오류 메시지

    클러스터 업데이트

    • 400 - 클러스터가 삭제 중 상태입니다. 비동기 작업이 진행 중입니다. 업데이트 작업을 수행하기 전에 클러스터에서 해당 작업을 완료해야 합니다.
    • 400 - KeyVaultProperties가 비어 있지 않지만 형식이 잘못되었습니다. 키 식별자 업데이트를 참조하세요.
    • 400 - Key Vault의 키 유효성을 검사하지 못했습니다. 권한이 없거나 키가 존재하지 않기 때문일 수 있습니다. Key Vault에서 키 및 액세스 정책을 설정했는지 확인하세요.
    • 400 - 키를 복구할 수 없습니다. Key Vault를 일시 삭제 및 제거 보호로 설정해야 합니다. Key Vault 설명서를 참조하세요.
    • 400 - 지금은 작업을 실행할 수 없습니다. 비동기 작업이 완료될 때까지 기다렸다가 다시 시도하세요.
    • 400 - 클러스터가 삭제 중 상태입니다. 비동기 작업이 완료될 때까지 기다렸다가 다시 시도하세요.

    클러스터 가져오기

    • 404--클러스터가 없습니다. 클러스터가 삭제되었을 수 있습니다. 이 이름을 사용하여 클러스터를 만들려고 할 때 충돌하는 경우, 클러스터가 삭제 프로세스에 있습니다.

다음 단계