고객 키 설정
고객 키를 사용하면 조직의 암호화 키를 제어한 다음 Microsoft 365를 사용하여 Microsoft의 데이터 센터에서 미사용 데이터를 암호화하도록 구성합니다. 즉, 고객 키를 사용하면 키를 사용하여 사용자에게 속한 암호화 계층을 추가할 수 있습니다.
고객 키를 사용하기 전에 Azure를 설정합니다. 이 문서에서는 필요한 Azure 리소스를 만들고 구성하기 위해 수행해야 하는 단계를 설명한 다음, 고객 키를 설정하는 단계를 제공합니다. Azure를 설정한 후 조직의 다양한 Microsoft 365 워크로드에서 데이터를 암호화하기 위해 할당할 정책 및 키를 결정합니다. 고객 키 또는 일반 개요에 대한 자세한 내용은 고객 키 개요를 참조하세요.
중요
이 문서의 모범 사례를 따르는 것이 좋습니다. 이는 TIP 및 IMPORTANT로 호출됩니다. 고객 키를 사용하면 범위가 전체 조직만큼 클 수 있는 루트 암호화 키를 제어할 수 있습니다. 즉, 이러한 키를 사용하여 수행한 실수는 광범위한 영향을 미칠 수 있으며 서비스 중단 또는 취소할 수 없는 데이터 손실이 발생할 수 있습니다.
팁
E5 고객이 아닌 경우 90일 Microsoft Purview 솔루션 평가판을 사용하여 조직이 데이터 보안 및 규정 준수 요구 사항을 관리하는 데 도움이 되는 추가 Purview 기능을 살펴보세요. Microsoft Purview 규정 준수 포털 평가판 허브에서 지금 시작하세요. 등록 및 평가판 조건에 대한 세부 정보를 알아봅니다.
Microsoft Purview 고객 키에 대한 Windows 365 지원은 공개 미리 보기 상태이며 변경될 수 있습니다.
고객 키를 설정하기 전에
시작하기 전에 조직에 적절한 Azure 구독 및 Microsoft 365, Office 365 및 Windows 365 라이선스가 있는지 확인합니다. 유료 Azure 구독을 사용해야 합니다. 레거시 지원에서 무료, 평가판, 스폰서쉽, MSDN 구독 및 구독을 통해 얻은 구독은 자격이 없습니다.
중요
Microsoft 365 고객 키를 제공하는 유효한 Microsoft 365 및 Office 365 라이선스:
- Office 365 E5
- Microsoft 365 E5
- Microsoft 365 E5 Compliance
- Microsoft 365 E5 Information Protection & 거버넌스 SKU
- FLW용 Microsoft 365 보안 및 규정 준수
기존 Office 365 고급 규정 준수 라이선스는 여전히 지원됩니다.
이 문서의 개념 및 절차를 이해하려면 Azure Key Vault 설명서를 검토하세요. 또한 Azure에서 사용되는 용어(예: Microsoft Entra 테넌트)에 익숙해집니다.
설명서 이외의 지원이 더 필요한 경우 Microsoft 지원에 문의하세요. 설명서를 포함하여 고객 키에 대한 피드백을 제공하려면 Microsoft 365 커뮤니티에 아이디어, 제안 및 관점을 보냅니다.
고객 키를 설정하는 단계 개요
고객 키를 설정하려면 나열된 순서대로 이러한 작업을 완료합니다. 이 문서의 나머지 부분에는 각 작업에 대한 자세한 지침이 제공되거나 프로세스의 각 단계에 대한 자세한 정보로 연결됩니다.
Azure에서:
Azure PowerShell에 원격으로 연결하여 다음 필수 조건을 완료합니다. 최상의 결과를 위해 Azure PowerShell 버전 4.4.0 이상을 사용합니다.
이전 작업을 완료한 후 테넌트 사용:
고객 키용 Azure Key Vault에서 작업 완료
Azure Key Vault에서 이러한 작업을 완료합니다. 고객 키와 함께 사용하는 모든 DEP(데이터 암호화 정책) 유형에 대해 이러한 단계를 완료해야 합니다.
두 개의 새 Azure 구독 만들기
고객 키에는 두 개의 Azure 구독이 필요합니다. 모범 사례로 고객 키와 함께 사용할 새 Azure 구독을 만드는 것이 좋습니다. Azure Key Vault 키는 동일한 Microsoft Entra 테넌트에서 애플리케이션에 대해서만 권한을 부여할 수 있습니다. DEP가 할당된 조직에서 사용하는 것과 동일한 Microsoft Entra 테넌트에서 새 구독을 만들어야 합니다. 예를 들어 조직에서 전역 관리자 권한이 있는 회사 또는 학교 계정을 사용합니다. 자세한 단계는 조직으로 Azure 등록을 참조하세요.
중요
고객 키에는 각 DEP(데이터 암호화 정책)에 대해 두 개의 키가 필요합니다. 이를 위해서는 두 개의 Azure 구독을 만들어야 합니다. 모범 사례로, 조직의 개별 구성원이 각 구독에서 하나의 키를 구성하는 것이 좋습니다. 이러한 Azure 구독만 사용하여 Microsoft 365에 대한 암호화 키를 관리해야 합니다. 이렇게 하면 운영자 중 한 명이 실수로, 의도적으로 또는 악의적으로 삭제하거나, 책임 있는 키를 잘못 관리하는 경우 조직을 보호할 수 있습니다.
조직에 대해 만들 수 있는 Azure 구독 수에는 실질적인 제한이 없습니다. 이러한 모범 사례를 따르면 사용자 오류의 영향을 최소화하는 동시에 고객 키에서 사용하는 리소스를 관리할 수 있습니다.
필요한 서비스 주체 등록
고객 키를 사용하려면 테넌트에서 필요한 서비스 주체가 등록되어 있어야 합니다. 다음 섹션에서는 서비스 주체가 테넌트에서 이미 등록되어 있는지 확인하기 위한 지침이 제공됩니다. 등록되지 않은 경우 표시된 대로 'New-AzADServicePrincipal' cmdlet을 실행합니다.
고객 키 온보딩 애플리케이션에 대한 서비스 주체 등록
고객 키 온보딩 애플리케이션이 전역 관리자 권한으로 테넌트에서 이미 등록되어 있는지 확인하려면 다음 명령을 실행합니다.
Get-AzADServicePrincipal -ServicePrincipalName 19f7f505-34aa-44a4-9dcc-6a768854d2ea
애플리케이션이 테넌트에서 등록되지 않은 경우 다음 명령을 실행합니다.
New-AzADServicePrincipal -ApplicationId 19f7f505-34aa-44a4-9dcc-6a768854d2ea
M365DataAtRestEncryption 애플리케이션에 대한 서비스 주체 등록
M365DataAtRestEncryption 애플리케이션이 전역 관리자 권한으로 테넌트에 이미 등록되어 있는지 확인하려면 다음 명령을 실행합니다.
Get-AzADServicePrincipal -ServicePrincipalName c066d759-24ae-40e7-a56f-027002b5d3e4
애플리케이션이 테넌트에서 등록되지 않은 경우 다음 명령을 실행합니다.
New-AzADServicePrincipal -ApplicationId c066d759-24ae-40e7-a56f-027002b5d3e4
Office 365 Exchange Online 애플리케이션의 서비스 주체 등록
Office 365 Exchange Online 애플리케이션이 전역 관리자 권한으로 테넌트에서 이미 등록되어 있는지 확인하려면 다음 명령을 실행합니다.
Get-AzADServicePrincipal -ServicePrincipalName 00000002-0000-0ff1-ce00-000000000000
애플리케이션이 테넌트에서 등록되지 않은 경우 다음 명령을 실행합니다.
New-AzADServicePrincipal -ApplicationId 00000002-0000-0ff1-ce00-000000000000
각 구독에서 프리미엄 Azure Key Vault 만들기
키 자격 증명 모음을 만드는 단계는 Azure Key Vault 시작에 설명되어 있습니다. 다음 단계에서는 Azure PowerShell을 설치 및 시작하고, Azure 구독에 연결하고, 리소스 그룹을 만들고, 해당 리소스 그룹에 키 자격 증명 모음을 만드는 방법을 안내합니다.
키 자격 증명 모음을 만들 때 SKU(표준 또는 프리미엄)를 선택해야 합니다. 표준 SKU를 사용하면 Azure Key Vault 키를 소프트웨어(HSM(하드웨어 보안 모듈) 키 보호가 없는 소프트웨어로 보호할 수 있으며 프리미엄 SKU를 사용하면 Key Vault 키를 보호하기 위해 HSM을 사용할 수 있습니다. 고객 키는 SKU를 사용하는 키 자격 증명 모음을 허용하지만 프리미엄 SKU만 사용하는 것이 좋습니다. 두 유형의 키가 있는 작업 비용은 동일하므로 비용의 유일한 차이점은 각 HSM 보호 키에 대한 월별 비용입니다. 자세한 내용은 Key Vault 가격 책정 을 참조하세요.
고객 키는 최근 FIPS 140-2 수준 3 규격 솔루션인 관리형 HSM에 저장된 RSA 키에 대한 지원을 추가했습니다. Azure Key Vault 관리형 HSM은 FIPS 140-2 수준 3 유효성이 검사된 HSM을 사용하여 클라우드 애플리케이션에 대한 암호화 키를 보호할 수 있는 완전 관리형 고가용성 단일 테넌트 표준 규격 클라우드 서비스입니다. 관리형 HSM에 대한 자세한 내용은 개요를 검토하세요.
중요
프로덕션 데이터에 프리미엄 SKU 키 자격 증명 모음 및 HSM 보호 키를 사용합니다. 테스트 및 유효성 검사를 위해 표준 SKU 키 자격 증명 모음 및 키만 사용합니다.
고객 키를 사용하는 각 Microsoft 365 서비스에 대해 만든 두 Azure 구독 각각에 키 자격 증명 모음 또는 관리형 HSM을 만듭니다.
예를 들어 고객 키가 Exchange, SharePoint 및 다중 워크로드 시나리오에 DEP를 사용할 수 있도록 하려면 총 6개의 키 자격 증명 모음 또는 관리형 HSM 쌍을만듭니다. 자격 증명 모음을 연결하는 DEP의 의도된 사용을 반영하는 명명 규칙을 사용합니다. 다음 표에서는 각 AKV(Azure Key Vault) 또는 관리형 HSM을 각 워크로드에 매핑하는 방법을 보여 줍니다.
| Key Vault 이름 | 여러 Microsoft 365 워크로드에 대한 권한(M365DataAtRestEncryption) | Exchange에 대한 권한 | SharePoint 및 OneDrive에 대한 권한 |
|---|---|---|---|
| ContosoM365AKV01 | 예 | 아니요 | 아니요 |
| ContosoM365AKV02 | 예 | 아니요 | 아니요 |
| ContosoEXOAKV01 | 아니오 | 예 | 아니요 |
| ContosoEXOAKV02 | 아니오 | 예 | 아니요 |
| ContosoSPOAKV01 | 아니요 | 아니요 | 예 |
| ContosoSPOAKV02 | 아니요 | 아니요 | 예 |
키 자격 증명 모음을 만들려면 Azure 리소스 그룹을 만들어야 합니다. 키 자격 증명 모음에는 스토리지 용량(작지만)이 필요하고 Key Vault 로깅이 필요한 경우 저장된 데이터도 생성됩니다. Microsoft는 모든 관련 고객 키 리소스를 관리하는 관리자 집합과 일치하는 관리와 함께 별도의 관리자를 사용하여 각 리소스 그룹을 관리하는 것이 좋습니다.
Exchange의 경우 사서함에 정책을 할당할 때 데이터 암호화 정책의 범위가 선택됩니다. 사서함에는 하나의 정책만 할당할 수 있으며 최대 50개의 정책을 만들 수 있습니다. SharePoint 정책의 범위에는 지리적 위치 또는 지리적 위치에 있는 조직 내의 모든 데이터가 포함 됩니다. 다중 워크로드 정책의 범위에는 모든 사용자에 대해 지원되는 워크로드의 모든 데이터가 포함됩니다.
중요
여러 Microsoft 365 워크로드, Exchange 및 SharePoint & OneDrive에 고객 키를 사용하려는 경우 각 워크로드에 대해 2개의 Azure Key Vault를 만들어야 합니다. 총 6개의 자격 증명 모음을 만들어야 합니다.
각 키 자격 증명 모음에 권한 할당
Azure RBAC( Azure 역할 기반 액세스 제어 )를 사용하여 각 키 자격 증명 모음에 필요한 권한을 정의합니다. Azure Key Vault 구성 작업은 Azure Portal을 사용하여 수행됩니다. 이 섹션에서는 RBAC를 사용하여 적절한 권한을 적용하는 방법을 자세히 설명합니다.
RBAC 메서드를 사용하여 권한 할당
Azure Key Vault에 , unwrapkey및 get 권한을 할당wrapKey하려면 해당 Microsoft 365 앱에 "Key Vault Crypto Service Encryption User" 역할을 할당해야 합니다.
Azure RBAC를 사용하여 Azure Key Vault에 액세스할 수 있는 권한 부여 | Microsoft Learn.
관리되는 HSM에 대해 , 및 권한을 할당wrapKey하려면 해당 Microsoft 365 앱에 "관리형 HSM 암호화 서비스 암호화 사용자" 역할을 할당해야 합니다.getunwrapkey
관리형 HSM 역할 관리 | 참조 Microsoft Learn.
Azure Key Vault에 역할을 추가할 때 각 Microsoft 365 앱에 대해 다음 이름을 검색합니다.
Exchange의 경우:
Office 365 Exchange OnlineSharePoint 및 OneDrive의 경우:
Office 365 SharePoint Online다중 워크로드 정책(Exchange, Teams, Microsoft Purview Information Protection)의 경우:
M365DataAtRestEncryption
해당 Microsoft 365 앱이 표시되지 않으면 테넌트에서 앱을 등록했는지 확인합니다.
역할 및 권한 할당에 대한 자세한 내용은 역할 기반 액세스 제어를 사용하여 Azure 구독 리소스에 대한 액세스 관리를 참조하세요.
사용자 역할 할당
조직에 대한 키 자격 증명 모음의 일상적인 관리를 수행하는 키 자격 증명 모음 관리자 또는 관리형 HSM 관리자 입니다. 이러한 작업에는 백업, 만들기, 가져오기, 가져오기, 나열 및 복원이 포함됩니다 .
중요
키 자격 증명 모음 관리자에게 할당된 권한 집합에는 키를 삭제할 수 있는 권한이 포함되지 않습니다. 이는 의도적이고 중요한 관행입니다. 이렇게 하면 데이터가 영구적으로 삭제되므로 암호화 키를 삭제하는 것은 일반적으로 수행되지 않습니다. 기본적으로 키 자격 증명 모음 관리자에게 암호화 키를 삭제할 수 있는 권한을 부여하지 않는 것이 좋습니다. 대신 키 자격 증명 모음 기여자를 위해 이 권한을 예약하고 결과를 명확하게 이해한 후에만 단기간에 관리자에게 할당합니다.
RBAC를 사용하여 조직의 사용자에게 이러한 권한을 할당하려면 Azure Portal을 사용하여 Azure 역할 할당 및 Key Vault 관리자 역할 할당을 참조하세요.
Azure Key Vault 자체에 대한 권한을 변경할 수 있는 기여자입니다. 직원이 팀을 떠나거나 팀에 합류할 때 이러한 권한을 변경합니다. 키 자격 증명 모음 관리자가 키를 삭제하거나 복원할 수 있는 권한이 합법적으로 필요한 드문 상황에서는 사용 권한도 변경해야 합니다. 이 키 자격 증명 모음 기여자 집합에는 키 자격 증명 모음에 대한 기여자 역할이 부여되어야 합니다. RBAC를 사용하여 이 역할을 할당할 수 있습니다. 구독을 만드는 관리자는 이 액세스 권한을 암시적으로 가지며 다른 관리자를 기여자 역할에 할당할 수 있습니다.
키를 만들거나 가져와서 각 키 자격 증명 모음에 키 추가
Azure Key Vault 또는 관리형 HSM에 키를 추가하는 방법에는 두 가지가 있습니다. 리소스에서 직접 키를 만들거나 키를 가져올 수 있습니다. Key Vault에서 직접 키를 만드는 것은 덜 복잡하지만 키를 가져오면 키가 생성되는 방식을 완전히 제어할 수 있습니다. RSA 키를 사용합니다. 고객 키는 최대 4096개의 RSA 키 길이를 지원합니다. Azure Key Vault는 타원형 곡선 키로 래핑 및 래핑 해제를 지원하지 않습니다.
관리형 HSM은 HSM 보호 키만 지원합니다. 관리되는 HSM에 대한 키를 만들 때 다른 형식이 아닌 RSA-HSM 키를 만들어야 합니다.
각 자격 증명 모음 또는 관리형 HSM에 키를 추가하는 지침은 Add-AzKeyVaultKey를 참조하세요.
온-프레미스에서 키를 만들고 키 자격 증명 모음으로 가져오는 자세한 단계는 Azure Key Vault에 대한 HSM 보호 키를 생성하고 전송하는 방법을 참조하세요. Azure 지침을 사용하여 각 키 자격 증명 모음에 키를 만듭니다.
키의 만료 날짜 확인
키에 대한 만료 날짜가 설정되지 않았는지 확인하려면 Get-AzKeyVaultKey cmdlet을 실행합니다.
Azure Key Vault의 경우:
Get-AzKeyVaultKey -VaultName <vault name>
관리형 HSM의 경우:
Get-AzKeyVaultKey -HsmName <HSM name>
고객 키는 만료된 키를 사용할 수 없습니다. 만료된 키로 시도한 작업이 실패하고 서비스 중단이 발생할 수 있습니다. 고객 키와 함께 사용되는 키에는 만료 날짜가 없는 것이 좋습니다.
일단 설정된 만료 날짜는 제거할 수 없지만 다른 날짜로 변경할 수 있습니다. 만료 날짜가 있는 키를 사용해야 하는 경우 만료 값을 12/31/9999로 변경하고 레거시 온보딩 프로세스를 사용합니다. 만료 날짜가 12/31/9999 이외의 날짜로 설정된 키는 Microsoft 365 유효성 검사에 실패합니다. 고객 키 온보딩 서비스는 만료 날짜가 없는 키만 허용합니다.
12/31/9999 이외의 값으로 설정된 만료 날짜를 변경하려면 Update-AzKeyVaultKey cmdlet을 실행합니다.
Azure Key Vault의 경우:
Update-AzKeyVaultKey -VaultName <vault name> -Name <key name> -Expires (Get-Date -Date "12/31/9999")
관리형 HSM의 경우:
Update-AzKeyVaultKey -HsmName <HSM name> -Name <key name> -Expires (Get-Date -Date "12/31/9999")
주의
고객 키와 함께 사용하는 암호화 키에 만료 날짜를 설정하지 마세요.
키 자격 증명 모음에서 일시 삭제가 사용하도록 설정되어 있는지 확인합니다.
키를 빠르게 복구할 수 있는 경우 실수로 또는 악의적으로 삭제된 키로 인해 확장된 서비스 중단이 발생할 가능성이 줄어듭니다. 이 구성을 일시 삭제라고 합니다. 일시 삭제를 사용하도록 설정하면 삭제 후 90일 이내에 키 또는 자격 증명 모음을 백업에서 복원하지 않고도 복구할 수 있습니다. 이 구성은 새 Azure Key Vault를 만들 때 자동으로 사용하도록 설정됩니다. 관리되는 HSM 리소스에 대해 일시 삭제를 해제할 수 없습니다. 이 설정을 사용하도록 설정하지 않은 기존 자격 증명 모음을 사용하는 경우 사용하도록 설정할 수 있습니다.
키 자격 증명 모음에서 일시 삭제를 사용하도록 설정하려면 다음 단계를 완료합니다.
Azure PowerShell을 사용하여 Azure 구독에 로그인합니다. 자세한 내용은 Azure PowerShell을 사용하여 로그인을 참조하세요.
Get-AzKeyVault cmdlet을 실행합니다. 이 예제에서 자격 증명 모음 이름은 일시 삭제를 사용하도록 설정하는 키 자격 증명 모음의 이름입니다.
$v = Get-AzKeyVault -VaultName <vault name> $r = Get-AzResource -ResourceId $v.ResourceId $r.Properties | Add-Member -MemberType NoteProperty -Name enableSoftDelete -Value 'True' Set-AzResource -ResourceId $r.ResourceId -Properties $r.PropertiesGet-AzKeyVault cmdlet을 실행하여 키 자격 증명 모음에 대해 일시 삭제가 구성되었는지 확인합니다. 키 자격 증명 모음에 대해 일시 삭제가 올바르게 구성된 경우 일시 삭제 사용 속성은True 값을 반환합니다.
Get-AzKeyVault -VaultName <vault name> | fl
계속하기 전에 '일시 삭제를 사용하도록 설정했나요?' 가 'True'로 설정되고 '일시 삭제 보존 기간(일)'이 '90'으로 설정됩니다.
Azure Key Vault 백업
키를 만들거나 변경한 직후 백업을 수행하고 온라인 및 오프라인에서 백업 복사본을 저장합니다. Azure Key Vault 또는 관리형 HSM 키의 백업을 만들려면 Backup-AzKeyVaultKey cmdlet을 실행합니다.
각 Azure Key Vault 키에 대한 URI 가져오기
키 자격 증명 모음을 설정하고 키를 추가한 후 다음 명령을 실행하여 각 키 자격 증명 모음의 키에 대한 URI를 가져옵니다. 나중에 각 DEP를 만들고 할당할 때 이러한 URI를 사용하므로 이 정보를 안전한 장소에 저장합니다. 각 키 자격 증명 모음에 대해 이 명령을 한 번 실행합니다.
Azure PowerShell에서:
(Get-AzKeyVaultKey -VaultName <vault name>).Id
관리형 HSM의 경우:
(Get-AzKeyVaultKey -HsmName <HSM name>).Id
고객 키 온보딩 서비스를 사용하여 온보딩
Microsoft 365 고객 키 온보딩 서비스는 사용자 고유의 테넌트 내에서 고객 키를 사용하도록 설정할 수 있는 서비스입니다. 이 기능은 필요한 고객 키 리소스의 유효성을 자동으로 검사합니다. 원하는 경우 테넌트 내에서 고객 키 사용을 계속하기 전에 리소스의 유효성을 별도로 검사할 수 있습니다.
중요
이 서비스는 다음 시나리오에서 아직 사용할 수 없습니다.
- 정부 테넌트 - 아래의 "정부 테넌트용 고객 키에 온보딩"을 참조하세요.
- SharePoint 및 OneDrive - 아래의 "SharePoint 및 OneDrive용 고객 키에 온보딩"을 참조하세요.
- 관리형 HSM을 사용하는 테넌트 - 아래의 "레거시 방법을 사용하여 고객 키에 온보딩"을 참조하세요.
온보딩에 사용되는 계정에는 최소 권한을 충족하는 다음 역할이 있어야 합니다 .
'M365CustomerKeyOnboarding' PowerShell 모듈 설치
Azure PowerShell을 사용하여 Azure 구독에 로그인합니다. 자세한 내용은 Azure PowerShell을 사용하여 로그인을 참조하세요.
PowerShell 갤러리에서 사용할 수 있는 최신 버전의 M365CustomerKeyOnboarding 모듈을 설치합니다. 페이지 아래쪽에 있는 "버전 기록" 탭을 보고 최신 버전을 다운로드하고 있는지 확인합니다. 관리자 권한으로 PowerShell 세션을 시작합니다. Azure PowerShell에서 명령을 복사하여 붙여넣고 실행하여 패키지를 설치합니다. 메시지가 표시되면 "모두에 예" 옵션을 선택합니다. 설치하는 데 몇 분 정도 걸립니다.
3가지 온보딩 모드 사용
온보딩 프로세스에서 각기 다른 용도로 사용되는 3가지 온보딩 모드가 있습니다. 이러한 3가지 모드는 "유효성 검사", "준비", "사용"입니다. 온보딩 요청 만들기에서 cmdlet을 실행하는 경우 "-OnboardingMode" 매개 변수를 사용하여 모드를 나타냅니다.
유효성 검사
"유효성 검사" 모드를 사용하여 고객 키에 사용되는 리소스의 구성이 올바른지 확인합니다. 이 모드의 리소스에 대해 아무 작업도 수행되지 않습니다.
중요
리소스의 구성을 변경하는 경우 원하는 만큼 이 모드를 실행할 수 있습니다.
준비
"준비" 모드 는 Cmdlet에 표시된 2개의 Azure 구독을 등록하여 MandatoryRetentionPeriod를 사용하여 고객 키 리소스에 대한 작업을 수행합니다. 루트 암호화 키의 일시적 또는 영구적 손실은 서비스 작업에 지장을 주거나 심지어 치명적일 수 있으며 데이터 손실을 초래할 수 있습니다. 이러한 이유로 고객 키와 함께 사용되는 리소스에는 강력한 보호가 필요합니다. 필수 보존 기간은 Azure 구독의 즉각적이고 취소할 수 없는 취소를 방지합니다. cmdlet을 실행한 후 구독은 변경 사항을 반영하는 데 최대 1시간이 걸릴 수 있습니다. MandatoryRetentionPeriod 등록의 상태를 확인하려면 준비 모드에서 cmdlet을 실행한 후 "유효성 검사" 모드로 이동합니다.
중요
Azure 구독에 대해 MandatoryRetentionPeriod를 등록하는 것은 필수입니다. cmdlet에서 다시 실행하라는 메시지가 표시되지 않는 한 이 모드를 한 번만 실행하면 됩니다.
사용
고객 키에 온보딩할 준비가 되면 이 모드를 사용합니다. "사용"은 -Scenario 매개 변수로 표시된 워크로드에 대해서만 고객 키에 대한 테넌트만 사용하도록 설정합니다. Exchange 및 M365DataAtRestEncryption 둘 다에 대해 고객 키를 사용하도록 설정하려면 각 워크로드에 대해 총 2회 온보딩 cmdlet을 실행합니다. "사용" 모드에서 cmdlet을 실행하기 전에 리소스가 "ValidationResult" 아래에 "전달됨"으로 표시되어 올바르게 구성되었는지 확인합니다.
중요
리소스가 "유효성 검사" 모드에서 검사를 충족하는 경우에만 사용하도록 설정하면 테넌트가 고객 키에 성공적으로 온보딩됩니다.
온보딩 요청 만들기
이 자동화 프로세스의 첫 번째 단계는 새 요청을 만드는 것입니다. PowerShell을 사용하면 cmdlet 결과를 변수로 압축할 수 있습니다. 새 요청을 변수로 압축합니다. "$" 기호 뒤에 변수 이름을 사용하여 변수를 만들 수 있습니다.
예제에서 $request 온보딩 요청에 할당할 수 있는 변수입니다.
$request = New-CustomerKeyOnboardingRequest -Organization <tenantID> -Scenario <Scenario> -Subscription1 <subscriptionID1> -VaultName1 <AKVVaultName1> -KeyName1 <KeyName1> -Subscription2 <subscriptionID2> -VaultName2 <AKVVaultName2> -KeyName2 <KeyName2> -OnboardingMode <OnboardingMode>
| 매개 변수 | 설명 | 예제 |
|---|---|---|
| -조직 | 테넌트 ID를 xxxxxxxx-xxxx-xxxx-xxxx-xxxx 형식으로 입력합니다. | abcd1234-abcd-efgh-hijk-abcdef123456 |
| -시나리오 | 온보딩할 워크로드를 입력합니다. 입력 옵션은 'MDEP' – 여러 워크로드에 대한 고객 키입니다. 'EXO' – Exchange용 고객 키 |
MDEP 또는 EXO |
| -Subscription1 | 필수 보존 기간에 등록한 첫 번째 구독의 Azure 구독 ID를 입력합니다. | p12ld534-1234-5678-9876-g3def67j9k12 |
| -VaultName1 | 고객 키에 대해 구성한 첫 번째 Azure Key Vault의 자격 증명 모음 이름을 입력합니다. | EXOVault1 |
| -KeyName1 | 고객 키에 대해 구성한 첫 번째 Azure Key Vault 내에 첫 번째 Azure Key Vault 키의 이름을 입력합니다. | EXOKey1 |
| -Subscription2 | 필수 보존 기간에 등록한 두 번째 구독의 Azure 구독 ID를 입력합니다. | 21k9j76f-ed3g-6789-8765-43215dl21pbd |
| -VaultName2 | 고객 키에 대해 구성한 두 번째 Azure Key Vault의 자격 증명 모음 이름을 입력합니다. | EXOVault2 |
| -KeyName2 | 고객 키에 대해 구성한 두 번째 Azure Key Vault 내에 두 번째 Azure Key Vault 키의 이름을 입력합니다. | EXOKey2 |
| -온보딩 모드 | "준비" - 필수 구성은 구독에 MandatoryRetentionPeriod를 적용하여 리소스에서 수행됩니다. 적용하는 데 최대 1시간 이 걸릴 수 있습니다. "유효성 검사" – Azure Key Vault 및 Azure 구독 리소스의 유효성 검사만 고객 키에 온보딩하지 않습니다. 이 모드는 모든 리소스를 확인하지만 나중에 공식적으로 온보딩하도록 선택하는 경우에 유용합니다. "사용" – 유효성 검사가 성공하면 Azure Key Vault 및 구독 리소스의 유효성을 검사하고 테넌트 내에서 고객 키를 사용하도록 설정합니다. |
준비 또는 사용 또는 유효성 검사 |
테넌트 관리자 자격 증명으로 로그인
권한 있는 계정으로 로그인하라는 메시지가 표시되는 브라우저 창이 열립니다. 적절한 자격 증명을 사용하여 로그인합니다.
유효성 검사 및 사용 세부 정보 보기
성공적으로 로그인한 후 PowerShell 창으로 다시 이동합니다. 온보딩 cmdlet을 압축한 변수를 실행하여 온보딩 요청의 출력을 가져옵니다.
$request
ID, CreatedDate, ValidationResult 및 EnablementResult를 사용하여 출력을 받습니다.
| 출력 | 설명 |
|---|---|
| ID | 생성된 온보딩 요청과 연결된 ID입니다. |
| CreatedDate | 요청이 만들어진 날짜입니다. |
| ValidationResult | 성공/실패 유효성 검사 표시기입니다. |
| EnablementResult | 성공/실패를 나타내는 표시기입니다. |
고객 키를 사용할 준비가 된 테넌트는 다음과 같이 'ValidationResult' 및 'EnablementResult' 아래에 "성공"이 있습니다.
테넌트가 고객 키에 성공적으로 온보딩된 경우 다음 단계로 진행합니다.
실패한 유효성 검사 세부 정보 문제 해결
테넌트 유효성 검사에 실패하는 경우 다음 단계는 잘못 구성된 리소스의 근본 원인을 조사하기 위한 가이드입니다. 유효성 검사가 실패하는 잘못 구성된 리소스를 확인하려면 온보딩 결과를 변수에 저장하고 유효성 검사 결과로 이동합니다.
- 모든 요청을 나열하여 조사하려는 요청의 요청 ID를 찾습니다.
Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID>
- 특정 온보딩 요청을 '$request' 변수에 저장
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
- 다음 명령을 실행합니다.
$request.FailedValidations
각 규칙의 예상 값은 "ExpectedValue" 열에 표시되며 실제 값은 "ActualValue" 열에 표시됩니다. "범위" 열에는 구독 ID의 처음 5자가 표시되므로 문제가 있는 구독 및 기본 키 자격 증명 모음을 확인할 수 있습니다. "세부 정보" 섹션에서는 오류의 근본 원인과 이를 처리하는 방법에 대한 설명을 제공합니다.
| RuleName | 설명 | 해결 방법 |
|---|---|---|
| MandatoryRetentionPeriodState | MandatoryRetentionPeriod의 상태를 반환합니다. | "준비" 모드가 실행되었는지 확인합니다. 문제가 지속되면 잘못된 필수 보존 기간 상태로 이동합니다. |
| SubscriptionInRequestOrganization | Azure 구독은 조직 내에 있습니다. | 제공된 구독이 표시된 테넌트 내에서 만들어졌음을 확인합니다. |
| VaultExistsinSubscription | Azure Key Vault는 Azure 구독 내에 있습니다. | 표시된 구독 내에서 Azure Key Vault가 만들어졌음을 확인합니다. |
| SubscriptionUniquePerScenario | 구독은 고객 키에 대해 고유합니다. | 두 개의 고유한 구독 ID를 사용하고 있는지 확인합니다. |
| SubscriptionsCountPerScenario | 시나리오당 두 개의 구독이 있습니다. | 요청에서 두 개의 구독을 사용하고 있는지 확인합니다. |
| RecoveryLevel | AKV 키 복구 수준은 Recoveryable+ProtectedSubscription입니다. | 잘못된 필수 보존 기간 상태 |
| KeyOperationsSupported | 키 자격 증명 모음에는 적절한 워크로드에 필요한 권한이 있습니다. | AKV 키에 적절한 권한 할당 |
| KeyNeverExpires | AKV 키에 만료 날짜가 없습니다. | 키 만료 확인 |
| KeyAccessPermissions | AKV 키에 필요한 액세스 권한이 있습니다. | AKV 키에 적절한 권한 할당 |
| OrganizationHasRequiredServicePlan | 조직에 고객 키를 사용하는 올바른 서비스 계획이 있습니다. | 테넌트에게 필요한 라이선스가 있는지 확인 |
잘못된 필수 보존 기간 상태
'준비' 모드에서 온보딩 cmdlet을 실행한 후 1시간 후에 MandatoryRetentionPeriodState가 '복구 가능' 또는 '복구 가능+제거 가능'으로 설정되어 있고 Azure Key Vault에서 일시 삭제를 사용하도록 설정한 경우 다음 단계를 수행합니다.
- 다음 명령을 실행하여 두 Azure 구독이 '등록됨' 상태를 반환했는지 확인합니다.
Set-AzContext -SubscriptionId <Subscription ID>
Get-AzProviderFeature -FeatureName mandatoryRetentionPeriodEnabled -ProviderNamespace Microsoft.Resources
두 구독에서 'Microsoft.Resources' 및 'Microsoft.KeyVault' 리소스 공급자 를 모두 다시 등록합니다.
- Azure Portal, Azure CLI 및 Azure PowerShell의 세 가지 방법을 사용하여 다시 등록을 수행할 수 있습니다.
- Azure PowerShell:
Register-AzResourceProvider -ProviderNamespace Microsoft.Resources Register-AzResourceProvider -ProviderNamespace Microsoft.Keyvault - Azure CLI:
az provider register --namespace Microsoft.Resources az provider register --namespace Microsoft.Keyvault - Azure Portal:
- Azure PowerShell:
- Azure Portal, Azure CLI 및 Azure PowerShell의 세 가지 방법을 사용하여 다시 등록을 수행할 수 있습니다.
키의 복구 수준을 확인하려면 Azure PowerShell에서 다음과 같이 Get-AzKeyVaultKey cmdlet을 실행합니다.
(Get-AzKeyVaultKey -VaultName <vault name> -Name <key name>).Attributes
통과된 유효성 검사
전달된 유효성 검사를 확인하려면 다음 명령을 실행합니다.
- 특정 온보딩 요청을 '$request' 변수에 저장
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
- 다음 명령을 실행합니다.
$request.PassedValidations
레거시 방법을 사용하여 고객 키에 온보딩
고객 키 온보딩 서비스에서 지원되지 않는 시나리오가 테넌트에게 적용되는 경우에만 이 방법을 사용합니다. 레거시 방법을 사용하여 고객 키에 온보딩하려는 경우 Azure Key Vault 및 구독을 설정하는 모든 단계를 완료한 후 고객 키 지원을 요청하는 Microsoft 지원에 문의하세요.
정부 테넌트용 고객 키에 온보딩
GCC-H 또는 DoD에 테넌트가 있고 고객 키를 사용하도록 설정하려는 경우 Azure Key Vault 및 구독을 설정하는 모든 단계를 완료한 후 정부 테넌트용 고객 키 지원을 요청하는 Microsoft 지원에 문의하세요.
SharePoint 및 OneDrive용 고객 키에 온보딩
SharePoint 및 OneDrive용 고객 키에 온보딩하기 위한 두 가지 필수 구성 요소가 있습니다.
테넌트는 이미 Exchange용 고객 키 또는 여러 워크로드의 고객 키에 온보딩되었습니다.
두 구독 모두 필수 보존 기간을 사용하도록 등록됩니다.
테넌트가 두 필수 구성 요소를 모두 충족하는 경우 SharePoint 및 OneDrive에서 사용할 DEP 만들기로 이동합니다.
다음 단계
이 문서의 단계를 완료하면 DEP를 만들고 할당할 준비가 된 것입니다. 자세한 내용은 고객 키 관리를 참조하세요.