마이그레이션 5단계 - 마이그레이션 후 작업

  • 아티클

AD RMS에서 Azure Information Protection으로 마이그레이션하는 5단계에 다음 정보를 사용합니다. 이러한 절차는 AD RMS에서 Azure Information Protection으로 마이그레이션하는 10~12단계를 다룹니다.

10단계: AD RMS 프로비전 해제

컴퓨터가 온-프레미스 Rights Management 인프라를 검색하지 못하도록 Active Directory에서 SCP(서비스 커넥트ion Point)를 제거합니다. 이는 레지스트리에서 구성한 리디렉션(예: 마이그레이션 스크립트 실행)으로 인해 마이그레이션한 기존 클라이언트에 대해 선택 사항입니다. 그러나 SCP를 제거하면 마이그레이션이 완료되면 새 클라이언트 및 잠재적으로 RMS 관련 서비스 및 도구에서 SCP를 찾을 수 없습니다. 이 시점에서 모든 컴퓨터 연결은 Azure Rights Management 서비스로 이동해야 합니다.

SCP를 제거하려면 기본 엔터프라이즈 관리자로 로그인했는지 확인한 다음 다음 절차를 사용합니다.

  1. Active Directory Rights Management Services 콘솔에서 AD RMS 클러스터를 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.

  2. SCP 탭을 클릭합니다.

  3. SCP 검사 변경 상자를 선택합니다.

  4. 현재 SCP 제거를 선택한 다음 확인을 클릭합니다.

이제 AD RMS 서버에서 활동을 모니터링합니다. 예를 들어 System Health 보고서, ServiceRequest 테이블 또는 보호된 콘텐츠에 대한 사용자 액세스 감사의 요청을 검사.

RMS 클라이언트가 더 이상 이러한 서버와 통신하지 않고 클라이언트가 Azure Information Protection을 성공적으로 사용하고 있음을 확인한 경우 이러한 서버에서 AD RMS 서버 역할을 제거할 수 있습니다. 전용 서버를 사용하는 경우 일정 기간 동안 서버를 먼저 종료하는 주의 단계를 선호할 수 있습니다. 이렇게 하면 클라이언트가 Azure Information Protection을 사용하지 않는 이유를 조사하는 동안 서비스 연속성을 위해 이러한 서버를 다시 시작해야 할 수 있는 보고된 문제가 없는지 확인할 수 있습니다.

AD RMS 서버를 프로비전 해제한 후에는 템플릿 및 레이블을 검토할 수 있습니다. 예를 들어 템플릿을 레이블로 변환하거나, 사용자가 선택할 수 있도록 통합하거나, 다시 구성합니다. 이때 기본 템플릿을 게시할 수도 있습니다.

민감도 레이블 및 통합 레이블 지정 클라이언트의 경우 Microsoft Purview 규정 준수 포털 사용합니다. 자세한 내용은 Microsoft 365 설명서를 참조하세요.

Important

이 마이그레이션이 끝나면 AD RMS 클러스터를 Azure Information Protection 및 HYOK(사용자 고유 키) 옵션과 함께 사용할 수 없습니다.

Office 2010을 실행하는 컴퓨터에 대한 추가 구성

Important

Office 2010 확장 지원은 2020년 10월 13일에 종료되었습니다. 자세한 내용은 AIP 및 레거시 Windows 및 Office 버전을 참조하세요.

마이그레이션된 클라이언트에서 Office 2010을 실행하는 경우 AD RMS 서버가 프로비전 해제된 후 보호된 콘텐츠를 여는 데 지연이 발생할 수 있습니다. 또는 보호된 콘텐츠를 여는 데 필요한 자격 증명이 없다는 메시지가 표시될 수 있습니다. 이러한 문제를 해결하려면 AD RMS URL FQDN을 컴퓨터의 로컬 IP 주소(127.0.0.1)로 리디렉션하는 이러한 컴퓨터에 대한 네트워크 리디렉션을 만듭니다. 각 컴퓨터에서 로컬 호스트 파일을 구성하거나 DNS를 사용하여 이 작업을 수행할 수 있습니다.

  • 로컬 호스트 파일을 통한 리디렉션: 다음 줄을 로컬 호스트 파일에 추가하고 접두사 없이 AD RMS 클러스터의 값 또는 웹 페이지로 <AD RMS URL FQDN>을 대체합니다.

    127.0.0.1 <AD RMS URL FQDN>

  • DNS를 통한 리디렉션: IP 주소가 127.0.0.1인 AD RMS URL FQDN에 대한 새 호스트(A) 레코드를 만듭니다.

11단계: 클라이언트 마이그레이션 작업 완료

모바일 디바이스 클라이언트 및 Mac 컴퓨터의 경우: AD RMS 모바일 디바이스 확장을 배포할 때 만든 DNS SRV 레코드를 제거합니다.

이러한 DNS 변경 내용이 전파되면 이러한 클라이언트는 Azure Rights Management 서비스를 자동으로 검색하고 사용하기 시작합니다. 그러나 Office Mac을 실행하는 Mac 컴퓨터는 AD RMS의 정보를 캐시합니다. 이러한 컴퓨터의 경우 이 프로세스는 최대 30일이 걸릴 수 있습니다.

Mac 컴퓨터에서 검색 프로세스를 즉시 실행하도록 강제하려면 키체인 "adal"을 검색하고 모든 ADAL 항목을 삭제합니다. 그런 다음, 이러한 컴퓨터에서 다음 명령을 실행합니다.


rm -r ~/Library/Cache/MSRightsManagement

rm -r ~/Library/Caches/com.microsoft.RMS-XPCService

rm -r ~/Library/Caches/Microsoft\ Rights\ Management\ Services

rm -r ~/Library/Containers/com.microsoft.RMS-XPCService

rm -r ~/Library/Containers/com.microsoft.RMSTestApp

rm ~/Library/Group\ Containers/UBF8T346G9.Office/DRM.plist

killall cfprefsd

모든 기존 Windows 컴퓨터가 Azure Information Protection으로 마이그레이션된 경우 온보딩 컨트롤을 계속 사용하고 마이그레이션 프로세스를 위해 만든 AIPMigrated 그룹을 기본 지정할 이유가 없습니다.

먼저 온보딩 컨트롤을 제거한 다음 마이그레이션 스크립트를 배포하기 위해 만든 AIPMigrated 그룹 및 소프트웨어 배포 방법을 삭제할 수 있습니다.

온보딩 컨트롤을 제거하려면 다음을 수행합니다.

  1. PowerShell 세션에서 Azure Rights Management 서비스에 연결하고 메시지가 표시되면 전역 관리자 자격 증명을 지정합니다.

    Connect-AipService

  2. 다음 명령을 실행하고 Y를 입력하여 확인합니다.

    Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False

    이 명령은 모든 컴퓨터가 문서 및 전자 메일을 보호할 수 있도록 Azure Rights Management 보호 서비스에 대한 모든 라이선스 적용을 제거합니다.

  3. 온보딩 컨트롤이 더 이상 설정되지 않는지 확인합니다.

    Get-AipServiceOnboardingControlPolicy

    출력에서 라이선스에 False가 표시되고 SecurityGroupOjbectId에 대한 GUID가 표시되지 않습니다.

마지막으로, Office 2010을 사용하고 있고 Windows 작업 스케줄러 라이브러리에서 AD RMS 권한 정책 템플릿 관리(자동화) 작업을 사용하도록 설정한 경우 Azure Information Protection 클라이언트에서 사용되지 않으므로 이 작업을 사용하지 않도록 설정합니다.

이 작업은 일반적으로 그룹 정책을 사용하여 사용하도록 설정되며 AD RMS 배포를 지원합니다. Microsoft>Windows>Active Directory Rights Management Services Client 위치에서 이 작업을 찾을 수 있습니다.

Important

Office 2010 확장 지원은 2020년 10월 13일에 종료되었습니다. 자세한 내용은 AIP 및 레거시 Windows 및 Office 버전을 참조하세요.

12단계: Azure Information Protection 테넌트 키 다시 생성

AD RMS 배포에서 RMS 암호화 모드 1을 사용한 경우 이 모드는 1024비트 키와 SHA-1을 사용하기 때문에 마이그레이션이 완료되었을 때 이 단계가 필요합니다. 이 구성은 부적절한 수준의 보호를 제공하는 것으로 간주됩니다. Microsoft는 1024비트 RSA 키와 같은 낮은 키 길이의 사용 및 SHA-1과 같은 부적절한 보호 수준을 제공하는 프로토콜의 관련 사용을 보증하지 않습니다.

키를 다시 입력하면 RMS 암호화 모드 2를 사용하는 보호가 생성되며, 이로 인해 2048비트 키와 SHA-256이 생성됩니다.

AD RMS 배포에서 암호화 모드 2를 사용하는 경우에도 새 키가 AD RMS 키에 대한 잠재적 보안 위반으로부터 테넌트를 보호하는 데 도움이 되므로 이 단계를 수행하는 것이 좋습니다.

Azure Information Protection 테넌트 키("키 롤링"라고도 함)의 키를 다시 입력하면 현재 활성 키가 보관되고 Azure Information Protection에서 지정한 다른 키를 사용하기 시작합니다. 이 다른 키는 Azure Key Vault에서 만드는 새 키이거나 테넌트에 대해 자동으로 만들어진 기본 키일 수 있습니다.

한 키에서 다른 키로 이동하는 것은 즉시 발생하지 않지만 몇 주 동안 발생합니다. 즉시 실행되지 않으므로 원래 키에 대한 위반이 의심될 때까지 기다리지 말고 마이그레이션이 완료되는 즉시 이 단계를 수행합니다.

Azure Information Protection 테넌트 키의 키를 다시 입력하려면 다음을 수행합니다.

  • Microsoft에서 테넌트 키를 관리하는 경우: PowerShell cmdlet Set-AipServiceKeyProperties를 실행하고 테넌트에 대해 자동으로 생성된 키의 키 식별자를 지정합니다. Get-AipServiceKeys cmdlet을 실행하여 지정할 값을 식별할 수 있습니다. 테넌트에 대해 자동으로 만들어진 키에는 가장 오래된 생성 날짜가 있으므로 다음 명령을 사용하여 식별할 수 있습니다.

    (Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1

  • BYOK(사용자)가 테넌트 키를 관리하는 경우: Azure Key Vault에서 Azure Information Protection 테넌트에 대한 키 만들기 프로세스를 반복한 다음 Use-AipServiceKeyVaultKey cmdlet을 다시 실행하여 이 새 키에 대한 URI를 지정합니다.

Azure Information Protection 테넌트 키를 관리하는 방법에 대한 자세한 내용은 Azure Information Protection 테넌트 키에 대한 작업을 참조하세요.

다음 단계

마이그레이션을 완료했으므로 분류, 레이블 지정 및 보호에 대한 AIP 배포 로드맵을 검토하여 수행해야 할 수 있는 다른 배포 작업을 식별합니다.