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

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

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

온-프레미스 권한 관리 인프라에서 컴퓨터를 검색하지 못하게 하려면 Active Directory에서 SCP(서비스 연결 지점)를 제거합니다. 이는 레지스트리에서 마이그레이션 스크립트를 실행하는 등의 방법으로 구성한 리디렉션 때문에 마이그레이션한 기존 클라이언트에 대한 선택 사항입니다. 그러나 SCP를 제거하면 마이그레이션이 완료될 때 새 클라이언트 및 잠재적으로 RMS 관련 서비스 및 도구가 SCP를 찾지 못합니다. 이때 모든 컴퓨터 연결은 Azure Rights Management Service로 이동해야 합니다.

SCP를 제거하려면 도메인 엔터프라이즈 관리자로 로그인하고 다음 절차를 사용합니다.

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

  2. SCP 탭을 클릭합니다.

  3. SCP 변경 확인란을 선택합니다.

  4. 현재 SCP 제거를 클릭하고 확인을 클릭합니다.

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

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

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

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

중요

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

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

중요

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
    

    출력에서 LicenseFalse를 표시해야 하고, SecurityGroupOjbectId에 대해 표시되는 GUID가 없습니다.

마지막으로, Office 2010을 사용 중이며, Windows 작업 스케줄러 라이브러리에서 AD RMS Rights Policy Template Management(자동) 작업을 활성화한 경우 Azure Information Protection 클라이언트에서는 이 작업이 사용되지 않으므로 비활성화하세요.

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

중요

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 배포 로드맵을 검토하여 수행해야 할 수 있는 다른 배포 작업을 식별합니다.