Azure Key Vault (시크릿리스 인증) 로 고객 키 관리

전제 조건

MongoDB 프로젝트 에 대해 AKV로 고객 관리 키를 활성화 하려면 다음이 필요합니다.

• M10 이상의 클러스터.

• Azure 계정 및 AKV의 암호화 키 .

  이러한 Azure 구성 요소를 구성하는 방법을 학습 Azure 설명서를 참조하세요.

  Atlas는 Atlas 프로젝트의 cluster에 대해 미사용 데이터 암호화를 활성화할 때 이 같은 리소스를 사용합니다.

• Azure 에서 다음을 수행할 수 있는 권한:

  • 테넌트에 엔터프라이즈 서비스 주체를 등록합니다. 이 전제 조건은 애플리케이션 관리자, 클라우드 애플리케이션 관리자 또는 글로벌 관리자와 같은 엔터프라이즈 애플리케이션을 추가하거나 관리 위해 Microsoft Entra ID 권한이 필요합니다.

    자세한 학습 은 빠른 시작: 엔터프라이즈 애플리케이션 추가를 참조하세요.

  • 다음 옵션 중 하나를 사용하여 Key Vault 키에 액세스합니다.

    • Azure RBAC(Key Vault 또는 키 범위)

    • 키 볼트 액세스 정책

• 미사용 데이터 암호화를 활성화 하려는 프로젝트 에 대한 Atlas 의 프로젝트 소유자 액세스 .

고려 사항

AKV for EAR에 저장된 고객 관리형 키를 사용하려면 Atlas 관리형 서비스 주체에게 특정 키 볼트 키에 대해 암호화 작업을 수행할 수 있는 권한이 있어야 합니다.

필요한 키 권한은 다음과 같습니다.

• get

• encrypt

• decrypt

권한 범위를 최대한 좁히고 다음 옵션 중 하나를 사용하여 권한을 부여해야 합니다.

• Azure RBAC(Key Vault 또는 키 범위)

• 키 볼트 액세스 정책

자세한 학습 은 빠른 시작: 엔터프라이즈 애플리케이션 추가를 참조하세요.

EAR AKV 시크릿리스 인증 설정

시크릿리스 인증 사용하여 미사용 데이터 암호화(EAR)를 구성하려면 다음을 수행해야 합니다.

1. Atlas에서 관리하는 Azure 서비스 주체를 만듭니다.

2. 서비스 주체에게 키 볼트 키에 대한 액세스 부여합니다.

3. 서비스 주체를 사용하도록 EAR을 구성합니다.

atlasAzureAppId: 9efedfcc-2eca-4b27-a613-0cad1e114cb7

az account show --query tenantId -o tsv

az ad sp list --filter "appId eq '9efedfcc-2eca-4b27-a613-0cad1e114cb7'"

az ad sp create --id 9efedfcc-2eca-4b27-a613-0cad1e114cb7

POST /api/atlas/v2/groups/{groupId}/cloudProviderAccess

{
  "providerName": "AZURE",
  "tenantId": "<azure-tenant-id>",
  "servicePrincipalId": "<service-principal-object-id>",
  "atlasAzureAppId": "9efedfcc-2eca-4b27-a613-0cad1e114cb7"
}

az role assignment create \
  --assignee-object-id "$SERVICE_PRINCIPAL_OBJECT_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Reader" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME"

az role assignment create \
  --assignee-object-id "$SERVICE_PRINCIPAL_OBJECT_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Crypto User" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME"

az keyvault set-policy \
  --subscription "$SUBSCRIPTION_ID" \
  --resource-group "$RESOURCE_GROUP" \
  --name "$KEY_VAULT_NAME" \
  --object-id "$SERVICE_PRINCIPAL_OBJECT_ID" \
  --key-permissions get encrypt decrypt wrapKey unwrapKey

https://{keyvault-name}.vault.azure.net/{object-type}/{object-name}/{object-version}

PATCH /api/atlas/v2/groups/{groupId}/encryptionAtRest

{
  "azureKeyVault": {
    "enabled": true,
    "roleId": "<atlas-managed-roleId>",
    "subscriptionID": "<subscription-id>",
    "resourceGroupName": "<resource-group>",
    "keyVaultName": "<key-vault-name>",
    "keyIdentifier": "https://<vault>.vault.azure.net/keys/<key>/<version>",
    "azureEnvironment": "AZURE"
  }
}

정적 자격 증명에서 마이그레이션

프로젝트 에서 이미 정적 자격 증명 (tenantId, clientId, secret)을 사용하는 경우 클러스터 다운타임 없이 마이그레이션 할 수 있습니다.

1. Atlas에서 관리하는 서비스 주체를 생성합니다.

2. 키 볼트 권한을 부여합니다.

3. 새 roleId로 EAR 구성을 패치합니다.

유효성 검사 에 실패하면 Atlas 정적 자격 자격 증명 계속 사용합니다.

유효성 검사 성공하면 Atlas 저장된 정적 자격 증명 제거하고 roleId 이 인증 위한 진실 소스가 됩니다.

클러스터 에서 비공개 네트워킹을 사용하는 경우 Atlas 데이터 노드에서 비동기적으로 키 볼트 액세스 검사합니다.

• PATCH 요청 수락되더라도 유효성 검사가 즉시 완료되지 않습니다.

• 데이터 노드는 구성이 적용된 후 키 볼트 액세스 을 검사합니다.

roleId으로 EAR을 패치하기 전에 모든 Key Vault 권한이 올바르게 구성되었는지 확인합니다. 액세스 잘못 구성하면 데이터 노드에서 유효성 검사 실패가 발생할 수 있으며, 이로 인해 결국 EAR 운영이 중단되고 클러스터 종료될 수 있습니다.

EAR을 패치하기 전에 서비스 주체에게 필요한 키 볼트 권한이 있는지 확인합니다.

az role assignment list \
  --assignee "$SERVICE_PRINCIPAL_OBJECT_ID" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME"

az keyvault show \
  --name "$KEY_VAULT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --query "properties.accessPolicies"