마이그레이션 2단계 - AD RMS에 대한 서버 쪽 구성
AD RMS에서 Azure Information Protection으로 마이그레이션하는 2단계에 다음 정보를 사용합니다. 이러한 절차는 AD RMS에서 Azure Information Protection으로 마이그레이션하는 4~6단계를 다룹니다.
4단계: AD RMS에서 구성 데이터 내보내기 및 Azure Information Protection으로 가져오기
이 단계는 두 부분으로 구성된 프로세스입니다.
신뢰할 수 있는 게시 작업기본s(TPD)을 .xml 파일로 내보내 AD RMS에서 구성 데이터를 내보냅니다. 이 프로세스는 모든 마이그레이션에 대해 동일합니다.
구성 데이터를 Azure Information Protection으로 가져옵니다. 현재 AD RMS 배포 구성 및 Azure RMS 테넌트 키에 대한 기본 토폴로지에 따라 이 단계에 대한 다양한 프로세스가 있습니다.
AD RMS에서 구성 데이터 내보내기
조직의 콘텐츠를 보호한 신뢰할 수 있는 모든 게시에 대해 모든 AD RMS 클러스터에서 다음 절차를 수행합니다기본. 라이선스 전용 클러스터에서 이 절차를 실행할 필요가 없습니다.
구성 데이터를 내보내려면(신뢰할 수 있는 게시 수행기본 정보)
AD RMS 관리 권한이 있는 사용자로 AD RMS 클러스터에 로그온합니다.
AD RMS 관리 콘솔(Active Directory Rights Management Services)에서 AD RMS 클러스터 이름을 확장하고 신뢰 정책을 확장한 다음 신뢰할 수 있는 게시 작업을 클릭합니다기본.
결과 창에서 신뢰할 수 있는 게시 작업을 선택한 다음기본 작업 창에서 신뢰할 수 있는 게시 수행 내보내기를 클릭합니다기본.
신뢰할 수 있는 게시 실행 내보내기기본 대화 상자에서 다음을 수행합니다.
다른 이름으로 저장을 클릭하고 경로 및 원하는 파일 이름에 저장합니다. .xml을 파일 이름 확장명(자동으로 추가되지 않음)으로 지정해야 합니다.
강력한 암호를 지정하고 확인합니다. 나중에 구성 데이터를 Azure Information Protection으로 가져올 때 필요하므로 이 암호를 기억하세요.
RMS 버전 1.0에서 신뢰할 수 있는 do기본 파일을 저장할 검사 상자를 선택하지 마세요.
트러스트된 모든 게시 도메인을 내보낸 경우 이 데이터를 Azure Information Protection으로 가져오는 절차를 시작할 준비가 된 것입니다.
신뢰할기본 수 있는 게시에는 이전에 보호된 파일의 암호를 해독하는 SLC(Server Licensor Certificate) 키가 포함되므로 현재 활성 상태인 게시뿐만 아니라 신뢰할 수 있는 게시를 모두 내보내고 나중에 Azure로 가져오는 것이 중요합니다기본.
예를 들어 AD RMS 서버를 암호화 모드 1에서 암호화 모드 2로 업그레이드한 경우 신뢰할 수 있는 게시 작업을 여러 기본. 암호화 모드 1을 사용한 보관 키가 포함된 신뢰할 수 있는 게시를 내보내고 가져오지 않으면기본 마이그레이션이 끝나면 사용자는 암호화 모드 1 키로 보호된 콘텐츠를 열 수 없습니다.
Azure Information Protection으로 구성 데이터 가져오기
이 단계의 정확한 절차는 현재 AD RMS 배포 구성 및 Azure Information Protection 테넌트 키에 대한 기본 토폴로지에 따라 달라집니다.
현재 AD RMS 배포는 서버 라이선스 인증서(SLC) 키에 대해 다음 구성 중 하나를 사용합니다.
AD RMS 데이터베이스의 암호 보호 이것은 기본 구성입니다.
nCipher HSM(하드웨어 보안 모듈)을 사용하여 HSM 보호.
nCipher 이외의 공급업체의 HSM(하드웨어 보안 모듈)을 사용하여 HSM 보호.
외부 암호화 공급자를 사용하여 보호되는 암호입니다.
참고 항목
AD RMS에서 하드웨어 보안 모듈을 사용하는 방법에 대한 자세한 내용은 하드웨어 보안 모듈에서 AD RMS 사용을 참조 하세요.
두 가지 Azure Information Protection 테넌트 키 토폴로지 옵션은 Microsoft에서 테넌트 키(Microsoft 관리형)를 관리하거나 Azure Key Vault에서 테넌트 키(고객 관리형)를 관리하는 것입니다. 고유한 Azure Information Protection 테넌트 키를 관리하는 경우 이를 "BYOK(Bring Your Own Key)"라고도 합니다. 자세한 내용은 Azure Information Protection 테넌트 키 문서 계획 및 구현을 참조하세요.
다음 표를 사용하여 마이그레이션에 사용할 절차를 식별합니다.
| 현재 AD RMS 배포 | 선택한 Azure Information Protection 테넌트 키 토폴로지 | 마이그레이션 지침 |
|---|---|---|
| AD RMS 데이터베이스의 암호 보호 | Microsoft 관리 | 이 테이블 다음에 나오는 소프트웨어 보호 키-소프트웨어 보호 키 마이그레이션 절차를 참조하세요. 가장 간단한 마이그레이션 경로이며 구성 데이터를 Azure Information Protection으로 전송하기만 하면 됩니다. |
| nCipher nShield HSM(하드웨어 보안 모듈)을 사용하여 HSM 보호 | BYOK(고객 관리) | 이 테이블 뒤의 HSM 보호 키 마이그레이션 프로시저에 대한 HSM 보호 키를 참조하세요. 이렇게 하려면 먼저 온-프레미스 HSM에서 Azure Key Vault HSM으로 키를 전송한 다음 Azure Information Protection에서 Azure Rights Management 서비스에 테넌트 키를 사용하도록 권한을 부여하고 마지막으로 구성 데이터를 Azure Information Protection으로 전송하려면 Azure Key Vault BYOK 도구 집합과 세 가지 단계 집합이 필요합니다. |
| AD RMS 데이터베이스의 암호 보호 | BYOK(고객 관리) | 이 표 뒤의 HSM 보호 키 마이그레이션 절차의 소프트웨어 보호 키를 참조하세요. 이렇게 하려면 먼저 소프트웨어 키를 추출하고 온-프레미스 HSM으로 가져온 다음, 온-프레미스 HSM에서 Azure Information Protection HSM으로 키를 전송하고, 다음으로 Key Vault 데이터를 Azure Information Protection으로 전송하고, 마지막으로 구성 데이터를 Azure Information Protection으로 전송하려면 Azure Key Vault BYOK 도구 집합과 4개의 단계 집합이 필요합니다. |
| nCipher 이외의 공급업체의 HSM(하드웨어 보안 모듈)을 사용하여 HSM 보호 | BYOK(고객 관리) | 이 HSM에서 nCipher nShield HSM(하드웨어 보안 모듈)으로 키를 전송하는 방법에 대한 지침은 HSM 공급업체에 문의하세요. 그런 후 이 테이블 다음에 나오는 HSM 보호 키-HSM 보호 키 마이그레이션 절차의 지침을 따르세요. |
| 외부 암호화 공급자를 사용하여 보호되는 암호 | BYOK(고객 관리) | nCipher nShield HSM(하드웨어 보안 모듈)으로 키를 전송하는 방법에 대한 지침은 암호화 공급자의 공급업체에 문의하세요. 그런 후 이 테이블 다음에 나오는 HSM 보호 키-HSM 보호 키 마이그레이션 절차의 지침을 따르세요. |
내보낼 수 없는 HSM 보호 키가 있는 경우 읽기 전용 모드로 AD RMS 클러스터를 구성하여 Azure Information Protection으로 마이그레이션할 수 있습니다. 이 모드에서는 이전에 보호된 콘텐츠를 계속 열 수 있지만 새로 보호된 콘텐츠는 BYOK(사용자)가 관리하거나 Microsoft에서 관리하는 새 테넌트 키를 사용합니다. 자세한 내용은 AD RMS에서 Azure RMS로의 마이그레이션을 지원하기 위해 Office에서 사용할 수 있는 업데이트를 참조 하세요.
이러한 주요 마이그레이션 절차를 시작하기 전에 신뢰할 수 있는 게시 작업을 내보낼 때 이전에 만든 .xml 파일에 액세스할 수 있는지 기본. 예를 들어 AD RMS 서버에서 인터넷에 연결된 워크스테이션으로 이동하는 USB 썸 드라이브에 저장될 수 있습니다.
참고 항목
그러나 이러한 파일을 저장합니다. 이 데이터에는 프라이빗 키가 포함되어 있으므로 보안 모범 사례를 사용하여 파일을 보호합니다.
4단계를 완료하려면 마이그레이션 경로에 대한 지침을 선택하고 선택합니다.
5단계: Azure Rights Management 서비스 활성화
PowerShell 세션을 열고 다음 명령을 실행합니다.
Azure Rights Management 서비스에 커넥트 메시지가 표시되면 전역 관리자 자격 증명을 지정합니다.
Connect-AipServiceAzure Rights Management 서비스를 활성화합니다.
Enable-AipService
Azure Information Protection 테넌트가 이미 활성화된 경우 어떻게 해야 할까요? Azure Rights Management 서비스가 조직에 대해 이미 활성화되어 있고 마이그레이션 후에 사용하려는 사용자 지정 템플릿을 만든 경우 이러한 템플릿을 내보내고 가져와야 합니다. 이 절차는 다음 단계에서 다룹니다.
6단계: 가져온 템플릿 구성
가져온 템플릿은 기본 보관 상태이므로 사용자가 Azure Rights Management 서비스에서 이러한 템플릿을 사용할 수 있도록 하려면 이 상태를 게시되도록 변경해야 합니다.
AD RMS에서 가져오는 템플릿은 Azure Portal에서 만들 수 있는 사용자 지정 템플릿처럼 보이고 동작합니다. 가져온 템플릿을 사용자가 보고 애플리케이션에서 선택할 수 있도록 게시하도록 변경하려면 Azure Information Protection에 대한 템플릿 구성 및 관리를 참조하세요.
새로 가져온 템플릿을 게시하는 것 외에도 마이그레이션을 계속하기 전에 수행해야 할 수 있는 템플릿에 대한 두 가지 중요한 변경 내용만 있습니다. 마이그레이션 프로세스 중에 사용자에게 보다 일관된 환경을 제공하려면 가져온 템플릿을 추가로 변경하지 않고 Azure Information Protection과 함께 제공되는 두 개의 기본 템플릿을 게시하거나 현재 새 템플릿을 만들지 마세요. 대신 마이그레이션 프로세스가 완료되고 AD RMS 서버를 프로비전 해제할 때까지 기다립니다.
이 단계에 대해 수행해야 할 수 있는 템플릿 변경 내용:
마이그레이션 전에 Azure Information Protection 사용자 지정 템플릿을 만든 경우 수동으로 내보내고 가져와야 합니다.
AD RMS의 템플릿에서 ANYONE 그룹을 사용한 경우 사용자 또는 그룹을 수동으로 추가해야 할 수 있습니다.
AD RMS에서 ANYONE 그룹은 온-프레미스 Active Directory 인증된 모든 사용자에게 권한을 부여했으며 이 그룹은 Azure Information Protection에서 지원되지 않습니다. 해당 닫기 항목은 Microsoft Entra 테넌트의 모든 사용자에 대해 자동으로 만들어지는 그룹입니다. AD RMS 템플릿에 ANYONE 그룹을 사용하는 경우 사용자 및 사용자에게 부여하려는 권한을 추가해야 할 수 있습니다.
마이그레이션 전에 사용자 지정 템플릿을 만든 경우 프로시저
마이그레이션 전에 Azure Rights Management 서비스를 활성화하기 전이나 후에 사용자 지정 템플릿을 만든 경우 게시됨으로 설정된 경우에도 마이그레이션 후에는 템플릿을 사용할 수 없습니다. 사용자가 사용할 수 있도록 하려면 먼저 다음을 수행해야 합니다.
Get-AipServiceTemplate을 실행하여 이러한 템플릿을 식별하고 템플릿 ID를 기록해 둡니다.
Azure RMS PowerShell cmdlet, Export-AipServiceTemplate을 사용하여 템플릿을 내보냅니다.
Azure RMS PowerShell cmdlet, Import-AipServiceTemplate을 사용하여 템플릿을 가져옵니다.
그런 다음 마이그레이션 후에 만든 다른 템플릿과 마찬가지로 이러한 템플릿을 게시하거나 보관할 수 있습니다.
AD RMS의 템플릿에서 ANYONE 그룹을 사용한 경우 절차
AD RMS의 템플릿에서 ANYONE 그룹을 사용한 경우 Azure Information Protection에서 가장 비슷한 그룹의 이름은 AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name>.onmicrosoft.com입니다. 예를 들어 이 그룹은 Contoso AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com의 경우 다음과 같을 수 있습니다. 이 그룹에는 Microsoft Entra 테넌트에서 온 모든 사용자가 포함됩니다.
Azure Portal에서 템플릿 및 레이블을 관리하는 경우 이 그룹은 Microsoft Entra ID에서 테넌트의 기본 이름으로 표시됩니다. 예를 들어 이 그룹은 Contoso의 경우 다음과 같을 수 있습니다. contoso.onmicrosoft.com. 옵션에 추가 <조직 이름> - 모든 구성원이 표시되면 이 그룹을 추가할 수 있습니다.
AD RMS 템플릿에 ANYONE 그룹이 포함되어 있는지 확실하지 않은 경우 다음 샘플 Windows PowerShell 스크립트를 사용하여 이러한 템플릿을 식별할 수 있습니다. AD RMS 템플릿이 포함된 Windows PowerShell을 사용하는 방법에 대한 자세한 내용은 Windows PowerShell을 사용하여 AD RMS 관리를 참조하세요.
Azure Portal에서 이러한 템플릿을 레이블로 변환할 때 템플릿에 외부 사용자를 쉽게 추가할 수 있습니다. 그런 다음 사용 권한 추가 창에서 세부 정보 입력을 선택하여 이러한 사용자의 이메일 주소를 수동으로 지정합니다.
이 구성에 대한 자세한 내용은 Rights Management 보호에 대한 레이블을 구성하는 방법을 참조하세요.
ANYONE 그룹을 포함하는 AD RMS 템플릿을 식별하는 샘플 Windows PowerShell 스크립트
이 섹션에는 이전 섹션에 설명된 대로 ANYONE 그룹이 정의된 AD RMS 템플릿을 식별하는 데 도움이 되는 샘플 스크립트가 포함되어 있습니다.
고지 사항: 이 샘플 스크립트는 Microsoft 표준 지원 프로그램 또는 서비스에서 지원되지 않습니다. 이 샘플 스크립트는 어떤 종류의 보증도 없이 AS IS로 제공됩니다.
import-module adrmsadmin
New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost -Force
$ListofTemplates=dir MyRmsAdmin:\RightsPolicyTemplate
foreach($Template in $ListofTemplates)
{
$templateID=$Template.id
$rights = dir MyRmsAdmin:\RightsPolicyTemplate\$Templateid\userright
$templateName=$Template.DefaultDisplayName
if ($rights.usergroupname -eq "anyone")
{
$templateName = $Template.defaultdisplayname
write-host "Template " -NoNewline
write-host -NoNewline $templateName -ForegroundColor Red
write-host " contains rights for " -NoNewline
write-host ANYONE -ForegroundColor Red
}
}
Remove-PSDrive MyRmsAdmin -force
다음 단계
3단계 - 클라이언트 쪽 구성으로 이동합니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기