AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.
Docs Menu

Azure Key Vault로 고객 키 관리(Secretless)

참고

다음 배포에서는 이 기능 사용할 수 없습니다.

  • 무료 클러스터

  • Flex 클러스터

자세한 학습 제한 사항을 참조하세요.

Atlas는 미사용 데이터 암호화(EAR)와 함께 Azure Key Vault (AKV)를 사용할 때 비밀 없는 인증을 지원합니다. 이 모델을 사용하면 Atlas에 오래 지속되는 정적 자격 증명(테넌트 ID, 클라이언트 ID, 클라이언트 암호)을 제공할 필요가 없습니다. 대신 사용자의 Azure 테넌트에서 Atlas managed Azure Service Principal을 인증하면 Atlas는 2.0 Azure Active 디렉토리 (Azure AD)가 발급하는 단기 사용 OAuth 액세스 토큰을 사용하여 AKV 에 인증합니다.

참고

The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see Shared Responsibility Model.

이 접근 방식은 다음과 같습니다.

  • Atlas 에서 클라이언트 시크릿을 생성, 저장 및 순환할 필요가 없습니다.

  • Azure RBAC 또는 Key Vault 액세스 정책을 사용하여 Azure 내에서 액세스 제어를 완전히 중앙 집중화합니다.

  • 클러스터 및 애플리케이션에 대한 기존 EAR 동작을 보존합니다. 인증 메커니즘 만 변경됨

Secretless EAR은 Azure AD와 Azure Key Vault 보안 경계로 사용합니다. Atlas 재사용 가능한 고객 관리형 시크릿을 저장 하지 않고 대신 런타임에 Azure발급한 토큰을 사용합니다. 액세스는 최소 권한 권한을 사용하여 적용되며 Azure 권한을 제거 하여 즉시 취소할 수 있습니다.

Atlas 더 간단하고 안전한 인증 모델을 위해 Atlas에서 관리하는 서비스 주체에 대한 직접 역할 할당을 사용합니다.

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

  • M10 이상의 클러스터.

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

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

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

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

    • 테넌트에 엔터프라이즈 서비스 주체를 등록합니다. 이 사전 요건에는 엔터프라이즈 애플리케이션을 추가 또는 관리할 수 있는 Microsoft Entra ID 역할이 필요합니다. 다음 내장 역할에 이 권한이 부여됩니다.

      • 애플리케이션 개발자(최소 권한)

      • 애플리케이션 관리자

      • 클라우드 애플리케이션 관리자

      • 하브리드 아이덴티티 관리자

      • 전 세계 관리자

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

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

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

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

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

  • get

  • encrypt

  • decrypt

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

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

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

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

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

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

테넌트에 Atlas 소유 Azure 애플리케이션에 대한 Azure 서비스 주체를 만들고 Cloud Provider Access API(클라우드 공급자 액세스 API)를 사용하여 Atlas에 등록합니다. Atlas는 EAR을 활성화할 때 사용하는 roleId를 반환합니다.

Atlas 다음 Azure 애플리케이션 ID를 사용합니다.

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

다음 명령을 실행하여 서비스 주체가 존재할 리소스 의 테넌트 ID 조회 .

az account show --query tenantId -o tsv
2

Atlas 애플리케이션 에 대한 서비스 주체가 이미 존재하는 경우 다음 명령을 실행 찾습니다.

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

존재하지 않는 경우 다음 명령을 실행 생성합니다.

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

If this command returns a permission-denied error, confirm that your Microsoft Entra ID account has one of the roles listed in the Prerequisites.

출력에서 Atlas 에 필요한 서비스 주체 객체 ID 인 id 필드 복사합니다.

3

클라우드 공급자 액세스 API를 사용합니다.

엔드포인트:

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

요청 본문 예시:

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

Atlas provisions and manages the Service Principal and returns an id value, which is the roleId required when you configure EAR.

Atlas에서 관리하는 서비스 주체에게 EAR에 사용되는 키 볼트 키에 대한 암호화 작업을 수행할 수 있는 권한을 부여합니다.

Azure RBAC 또는 Key Vault 액세스 정책을 사용하여 액세스 부여할 수 있습니다.

Azure RBAC를 사용하여 액세스 부여하려면 다음을 수행합니다.

1

다음 명령을 실행합니다:

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"
2

다음 명령을 실행합니다:

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

After you register and authorize the Service Principal in Azure, update your EAR configuration with the roleId that the Cloud Provider Access API returned.

1
  1. 아직 표시되지 않은 경우 탐색 표시줄의 Organizations 메뉴에서 프로젝트가 포함된 조직을 선택합니다.

  2. 아직 표시되지 않은 경우 내비게이션 바의 Projects 메뉴에서 프로젝트를 선택합니다.

  3. 사이드바에서 Security 제목 아래의 Database & Network Access를 클릭합니다.

  4. 사이드바에서 Advanced를 클릭합니다.

    고급 페이지가 표시됩니다.

2
3
4

Atlas는 AKV에 대해 두 가지 인증 방법을 지원합니다.

5

구독 ID

Key Vault의 Subscription ID 을 입력합니다.

리소스 그룹 이름

키 볼트가 포함된 Azure Resource Group 의 Resource Group 이름을 입력합니다.

Key Vault 이름

키 볼트의 이름을 입력합니다. 키 볼트에 필요한 액세스 정책이 있는지 확인합니다. 자세한 학습 은 필수 액세스를 참조하세요.

참고

AKV에 대한 비공개 엔드포인트 연결을 활성화 하고 설정하다 한 후에는 AKV 구성을 수정할 수 없습니다.

6

키 식별자

Key Vault에서 생성한 키의 전체 URL을 입력합니다.

중요한: 키 식별자는 전체 Azure 일반 형식으로제공되어야 합니다.

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

/{object-version}을(를) 추가할 수 있습니다. 그러나 최신 버전으로 자동 해결 활성화 하려면 버전을 생략하는 것이 좋습니다.

7

학습 보려면 프로젝트에 대한 비공개 엔드포인트 연결 활성화 및 설정을참조하세요.

8

Atlas 관리 API를 사용하여 Azure Private Link를 통해 AKV와 통신하고 Atlas 와 Key Vault 간의 모든 트래픽이 Azure의 비공개 네트워크 인터페이스를 통해 이루어지도록 하기 위해 Atlas를 구성했는 경우, Atlas는 Require Private Networking 상태를 Active(으)로 설정합니다. Atlas가 AKV 에 대한 비공개 엔드포인트 연결을 사용하도록 하려면, 상태인 경우 Inactive 필요에 따라 다음 단계를 완료할 수 있습니다.프로젝트에 대한 비공개 엔드포인트 연결 활성화 및 설정

9

Atlas는 암호화 프로세스 중에 Atlas 콘솔에 배너를 표시합니다.

이 업데이트 이후 Atlas는 정적 자격 증명 대신 단기 Azure AD 토큰을 사용하여 AKV 에 인증합니다.

프로젝트 에서 이미 정적 자격 증명 (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"

할당된 역할 get, encrypt, decrypt 등의 키 권한을 부여하는지 확인합니다.

다음 명령을 실행합니다:

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

서비스 주체가 나열되고 필요한 키 권한이 포함되어 있는지 확인합니다.