Azure Information Protection을 위한 사용자 및 그룹 준비
참고 항목
이전 명칭 MIP(Microsoft Information Protection)인 Microsoft Purview Information Protection을 찾고 계신가요?
Azure Information Protection 추가 기능은 사용 중지되고 Microsoft 365 앱 및 서비스에 기본 제공되는 레이블 로 대체됩니다. 다른 Azure Information Protection 구성 요소의 지원 상태 대해 자세히 알아봅니다.
Microsoft Purview Information Protection 클라이언트(추가 기능 제외)는 일반적으로 사용할 수 있습니다.
조직에 대한 Azure Information Protection을 배포하기 전에 조직의 테넌트에 대한 Microsoft Entra ID의 사용자 및 그룹에 대한 계정이 있는지 확인합니다.
다음과 같은 사용자 및 그룹에 대해 이러한 계정을 만드는 방법에는 여러 가지가 있습니다.
Microsoft 365 관리 센터 사용자와 Exchange Online 관리 센터에서 그룹을 만듭니다.
Azure Portal에서 사용자 및 그룹을 만듭니다.
Azure AD PowerShell 및 Exchange Online cmdlet을 사용하여 사용자 및 그룹을 만듭니다.
온-프레미스 Active Directory 사용자 및 그룹을 만들고 Microsoft Entra ID와 동기화합니다.
다른 디렉터리에 사용자 및 그룹을 만들고 Microsoft Entra ID와 동기화합니다.
한 가지 예외를 제외하고 이 목록의 처음 세 가지 메서드를 사용하여 사용자 및 그룹을 만들면 자동으로 Microsoft Entra ID로 만들어지고 Azure Information Protection은 이러한 계정을 직접 사용할 수 있습니다. 하지만 많은 엔터프라이즈 네트워크에서 온-프레미스 디렉터리를 사용하여 사용자 및 그룹을 만들고 관리합니다. Azure Information Protection은 이러한 계정을 직접 사용할 수 없습니다. Microsoft Entra ID와 동기화해야 합니다.
이전 단락에서 언급한 예외는 Exchange Online용으로 만들 수 있는 동적 메일 그룹입니다. 정적 배포 목록과 달리 이러한 그룹은 Microsoft Entra ID에 복제본(replica) 아니므로 Azure Information Protection에서 사용할 수 없습니다.
Azure Information Protection에서 사용자 및 그룹을 사용하는 방법
Azure Information protection에서 사용자 및 그룹을 사용하는 세 가지 시나리오가 있습니다.
사용자에게 레이블 할당 - 문서 및 이메일에 레이블을 적용할 수 있도록 Azure Information Protection 정책을 구성하는 경우. 관리자만 다음 사용자 및 그룹을 선택할 수 있습니다.
- 기본 Azure Information Protection 정책은 테넌트의 Microsoft Entra ID에 있는 모든 사용자에게 자동으로 할당됩니다. 그러나 범위가 지정된 정책을 사용하여 지정된 사용자 또는 그룹에 추가 레이블을 할당할 수도 있습니다.
Azure Rights Management 서비스를 사용하여 문서 및 전자 메일을 보호할 때 사용 권한 및 액세스 제어를 할당합니다. 관리자와 사용자는 다음과 같은 사용자 및 그룹을 선택할 수 있습니다.
사용 권한은 사용자가 문서 또는 이메일을 열 수 있는지 여부와 사용 방법을 결정합니다. 예를 들어 읽기만 할 수 있는지, 읽고 인쇄할 수 있는지 또는 읽고 편집할 수 있는지 여부입니다.
액세스 제어에는 만료 날짜와 액세스를 위해 인터넷 연결이 필요한지 여부가 포함됩니다.
Azure Rights Management 서비스 구성 - 특정 시나리오를 지원하려는 경우. 따라서 오직 관리자만이 이러한 그룹을 선택합니다. 예를 들어 다음과 같은 구성이 있습니다.
eDiscovery 또는 데이터 복구에 필요한 경우 지정된 서비스 또는 사용자가 암호화된 콘텐츠를 열 수 있도록 슈퍼 사용자입니다.
Azure Rights Management 서비스의 위임된 관리입니다.
단계별 배포를 지원하기 위한 온보딩 컨트롤입니다.
사용자 계정에 대한 Azure Information Protection 요구 사항
레이블을 할당하는 경우:
- Microsoft Entra ID의 모든 사용자 계정을 사용하여 사용자에게 추가 레이블을 할당하는 범위가 지정된 정책을 구성할 수 있습니다.
사용 권한 및 액세스 제어를 할당하고 Azure Rights Management 서비스 구성:
사용자에게 권한을 부여하기 위해 Microsoft Entra ID의 두 특성인 proxyAddresses 및 userPrincipalName이 사용됩니다.
Microsoft Entra proxyAddresses 특성은 계정에 대한 모든 전자 메일 주소를 저장하며 다양한 방법으로 채울 수 있습니다. 예를 들어 Exchange Online 사서함을 갖고 있는 Microsoft 365 사용자는 이 특성에 저장된 이메일 주소를 자동으로 갖습니다. Microsoft 365 사용자에 대한 대체 이메일 주소를 할당하는 경우 그 주소도 이 특성에 저장됩니다. 온-프레미스 계정에서 동기화된 전자 메일 주소로 채울 수도 있습니다.
Azure Information Protection은 이 Microsoft Entra proxyAddresses 특성의 모든 값을 사용할 수 있으며, 테넌트에 do기본가 추가되었습니다("확인된 작업기본"). do기본s 확인에 대한 자세한 내용은 다음을 수행합니다.
Microsoft Entra ID의 경우: Microsoft Entra ID에 사용자 지정 do기본 이름 추가
Office 365: Office 365에 도메인 추가
Microsoft Entra userPrincipalName 특성은 테넌트의 계정에 Microsoft Entra proxyAddresses 특성의 값이 없는 경우에만 사용됩니다. 예를 들어 Azure Portal에서 사용자를 만들거나 사서함이 없는 Microsoft 365 사용자를 만듭니다.
외부 사용자에게 사용 권한 및 액세스 제어 할당
Azure Information Protection은 테넌트 사용자에 대해 Microsoft Entra proxyAddresses 및 Microsoft Entra userPrincipalName을 사용하는 것 외에도 동일한 방식으로 이러한 특성을 사용하여 다른 테넌트에서 사용자에게 권한을 부여합니다.
기타 권한 부여 방법:
Microsoft Entra ID에 없는 전자 메일 주소의 경우 Azure Information Protection은 Microsoft 계정으로 인증될 때 권한을 부여할 수 있습니다. 그러나 Microsoft 계정이 인증에 사용되는 경우 모든 애플리케이션이 보호된 콘텐츠를 열 수 있는 것은 아닙니다. 추가 정보
Microsoft Entra ID에 계정이 없는 사용자에게 새 기능이 있는 Office 365 메시지 암호화를 사용하여 전자 메일을 보내는 경우 사용자는 먼저 소셜 ID 공급자와의 페더레이션을 사용하거나 일회성 암호를 사용하여 인증됩니다. 그런 다음, 보호된 전자 메일에 지정된 전자 메일 주소를 사용하여 사용자에게 권한을 부여합니다.
그룹 계정에 대한 Azure Information Protection 요구 사항
레이블을 할당하는 경우:
그룹 구성원에게 추가 레이블을 할당하는 범위 지정 정책을 구성하려면 Microsoft Entra ID에서 사용자의 테넌트에 대해 확인된 do기본가 포함된 전자 메일 주소가 있는 모든 유형의 그룹을 사용할 수 있습니다. 메일 주소가 있는 그룹을 메일 사용 가능 그룹이라고도 합니다.
예를 들어 메일 사용이 가능한 보안 그룹, 정적 메일 그룹 및 Microsoft 365 그룹을 사용할 수 있습니다. 이 그룹 유형에는 전자 메일 주소가 없으므로 보안 그룹(동적 또는 정적)을 사용할 수 없습니다. 또한 이 그룹이 Microsoft Entra ID에 복제본(replica) 없기 때문에 Exchange Online의 동적 메일 그룹을 사용할 수 없습니다.
사용 권한 및 액세스 제어를 할당하는 경우:
- 사용자의 테넌트에 대해 확인된 do기본 포함된 전자 메일 주소가 있는 Microsoft Entra ID의 모든 유형의 그룹을 사용할 수 있습니다. 메일 주소가 있는 그룹을 메일 사용 가능 그룹이라고도 합니다.
Azure Rights Management 서비스를 구성하는 경우:
한 가지 예외를 제외하고 테넌트에서 확인된 do기본 전자 메일 주소가 있는 Microsoft Entra ID의 모든 유형의 그룹을 사용할 수 있습니다. 이 예외는 테넌트에 대한 Microsoft Entra ID의 보안 그룹이어야 하는 그룹을 사용하도록 온보딩 컨트롤을 구성하는 경우입니다.
Azure Rights Management 서비스의 위임된 관리를 위해 테넌트에서 확인된 do기본에서 Microsoft Entra ID(이메일 주소 포함 또는 없음)의 모든 그룹을 사용할 수 있습니다.
외부 그룹에 사용 권한 및 액세스 제어 할당
Azure Information Protection은 테넌트에서 그룹에 대해 Microsoft Entra proxyAddresses를 사용하는 것 외에도 동일한 방식으로 이 특성을 사용하여 다른 테넌트에서 그룹에 권한을 부여합니다.
Azure Information Protection용 Active Directory 온-프레미스의 계정 사용
Azure Information Protection과 함께 사용하려는 온-프레미스에서 관리되는 계정이 있는 경우 Microsoft Entra ID와 동기화해야 합니다. 배포를 용이하게 하려면 Microsoft Entra 커넥트 사용하는 것이 좋습니다. 그러나 동일한 결과를 달성하는 디렉터리 동기화 메서드를 사용할 수 있습니다.
계정을 동기화하는 경우 모든 특성을 동기화할 필요가 없습니다. 동기화해야 하는 특성 목록은 Microsoft Entra 설명서의 Azure RMS 섹션 을 참조하세요.
Azure Rights Management의 특성 목록에서 사용자의 경우 동기화에 메일, proxyAddresses 및 userPrincipalName의 온-프레미스 AD 특성이 필요합니다. 메일 및 proxyAddresses에 대한 값은 Microsoft Entra proxyAddresses 특성과 동기화됩니다. 자세한 내용은 proxyAddresses 특성이 Microsoft Entra ID로 채워지는 방법을 참조 하세요.
사용자 및 그룹이 Azure Information Protection에 대해 준비되는지 확인
Azure AD PowerShell을 사용하여 사용자 및 그룹을 Azure Information Protection과 함께 사용할 수 있는지 확인할 수 있습니다. PowerShell을 사용하여 사용자 및 그룹 인증에 사용할 수 있는 값을 확인할 수도 있습니다.
참고 항목
Azure AD와 MSOnline PowerShell 모듈은 2024년 3월 30일부터 더 이상 사용되지 않습니다. 자세히 알아보려면 사용 중단 업데이트를 참조하세요. 이 날짜 이후에는 이러한 모듈에 대한 지원이 Microsoft Graph PowerShell SDK 및 보안 수정 사항에 대한 마이그레이션 지원으로 제한됩니다. 사용되지 않는 모듈은 2025년 3월 30일까지 계속 작동합니다.
Microsoft Graph PowerShell로 마이그레이션하여 Microsoft Entra ID(이전의 Azure AD)와 상호 작용하는 것이 좋습니다. 일반적인 마이그레이션 관련 질문은 마이그레이션 FAQ를 참조하세요. 참고: MSOnline 버전 1.0.x는 2024년 6월 30일 이후 중단될 수 있습니다.
예를 들어 PowerShell 세션에서 Microsoft Entra ID, MSOnline용 V1 PowerShell 모듈을 사용하여 먼저 서비스에 연결하고 전역 관리자 자격 증명을 제공합니다.
Connect-MsolService
참고: 이 명령이 작동하지 않으면 실행 Install-Module MSOnline 하여 MSOnline 모듈을 설치할 수 있습니다.
다음으로, 값이 잘리지 않도록 PowerShell 세션을 구성합니다.
$Formatenumerationlimit =-1
사용자 계정이 Azure Information Protection에 대한 준비가 되는지 확인
사용자 계정을 확인하려면 다음 명령을 실행합니다.
Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses
첫 번째 검사 Azure Information Protection과 함께 사용하려는 사용자가 표시되는지 확인하는 것입니다.
그런 다음 ProxyAddresses 열이 채워지는지 여부를 검사. 채워져 있으면 이 열의 이메일 값을 사용하여 사용자에게 Azure Information Protection에 대한 권한을 부여 할 수 있습니다.
ProxyAddresses 열이 채워지지 않으면 UserPrincipalName의 값을 사용하여 사용자에게 Azure Rights Management 서비스에 대한 권한을 부여합니다.
예시:
| 표시 이름 | UserPrincipalName | ProxyAddresses |
|---|---|---|
| 자가나스 레디 | jagannathreddy@contoso.com | {} |
| 앙쿠르 로이 | ankurroy@contoso.com | {SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com} |
이 예에서는 다음이 적용됩니다.
Jagannath Reddy에 대한 사용자 계정에는 권한이 부여됩니다 jagannathreddy@contoso.com.
Ankur Roy에 대한 사용자 계정은 사용 ankur.roy@contoso.com 및 ankur.roy@onmicrosoft.contoso.com사용 권한을 부여할 수 있지만 권한은 부여할 수 없습니다 ankurroy@contoso.com.
대부분의 경우 UserPrincipalName 값은 ProxyAddresses 필드의 값 중 하나와 일치합니다. 권장 구성이지만 전자 메일 주소와 일치하도록 UPN을 변경할 수 없는 경우 다음 단계를 수행해야 합니다.
UPN 값의 do기본 이름이 Microsoft Entra 테넌트에 대해 확인된 do기본이면 UPN 값을 Microsoft Entra ID의 다른 전자 메일 주소로 추가하여 이제 UPN 값을 사용하여 Azure Information Protection에 대한 사용자 계정에 권한을 부여할 수 있습니다.
UPN 값의 도메인 이름이 테넌트에 대해 확인되지 않은 도메인인 경우 Azure Information Protection에 사용할 수 없습니다. 그러나 그룹 전자 메일 주소에서 확인된 do기본 이름을 사용하는 경우에도 사용자는 그룹의 구성원으로 권한을 부여받을 수 있습니다.
UPN을 라우팅할 수 없는 경우(예: ankurroy@contoso.local) 사용자에 대한 대체 로그인 ID를 구성하고 이 대체 로그인을 사용하여 Office에 로그인하는 방법을 지시합니다. Office에 대한 레지스트리 키도 설정해야 합니다.
사용자에 대한 UPN이 변경되면 최소 24시간 동안 또는 UPN 변경 사항이 시스템에 제대로 반영될 때까지 비즈니스 연속성이 손실됩니다.
자세한 내용은 대체 로그인 ID 구성 및 Office 애플리케이션에서 주기적으로 SharePoint, OneDrive 및 Lync Online 자격 증명 요청을 참조하세요.
팁
Export-Csv cmdlet을 사용하여 가져오기를 위한 검색 및 대량 편집과 같은 더 쉽게 관리할 수 있도록 결과를 스프레드시트로 내보낼 수 있습니다.
예: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv
참고 항목
사용자에 대한 UPN이 변경되면 최소 24시간 동안 또는 UPN 변경 사항이 시스템에 제대로 반영될 때까지 비즈니스 연속성이 손실됩니다.
그룹 계정이 Azure Information Protection에 대해 준비되는지 확인
그룹 계정을 확인하려면 다음 명령을 사용합니다.
Get-MsolGroup | select DisplayName, ProxyAddresses
Azure Information Protection과 함께 사용하려는 그룹이 표시되는지 확인합니다. 표시된 그룹의 경우 ProxyAddresses 열의 전자 메일 주소를 사용하여 Azure Rights Management 서비스에 대한 그룹 구성원에게 권한을 부여할 수 있습니다.
그런 다음, 그룹에 Azure Information Protection에 사용할 사용자(또는 다른 그룹)가 포함되어 있는지 검사. PowerShell을 사용하여 이 작업을 수행하거나(예: Get-MsolGroupMember) 관리 포털을 사용할 수 있습니다.
보안 그룹을 사용하는 두 가지 Azure Rights Management 서비스 구성 시나리오의 경우 다음 PowerShell 명령을 사용하여 이러한 그룹을 식별하는 데 사용할 수 있는 개체 ID 및 표시 이름을 찾을 수 있습니다. 또한 Azure Portal을 사용하여 이러한 그룹을 찾은 후 개체 ID 및 표시 이름의 값을 복사할 수 있습니다.
Get-MsolGroup | where {$_.GroupType -eq "Security"}
이메일 주소 변경 시 Azure Information Protection에 대해 고려할 사항
사용자 또는 그룹의 전자 메일 주소를 변경하는 경우 이전 전자 메일 주소를 두 번째 전자 메일 주소(프록시 주소, 별칭 또는 대체 전자 메일 주소라고도 함)로 사용자 또는 그룹에 추가하는 것이 좋습니다. 이렇게 하면 이전 전자 메일 주소가 Microsoft Entra proxyAddresses 특성에 추가됩니다. 이 계정 관리는 이전 전자 메일 주소가 사용 중일 때 저장된 사용 권한 또는 기타 구성에 대한 비즈니스 연속성을 보장합니다.
이렇게 할 수 없는 경우 새 전자 메일 주소를 가진 사용자 또는 그룹은 이전에 이전 전자 메일 주소로 보호된 문서 및 전자 메일에 대한 액세스가 거부될 위험이 있습니다. 이 경우 보호 구성을 반복하여 새 전자 메일 주소를 저장해야 합니다. 예를 들어 템플릿 또는 레이블에서 사용자 또는 그룹에 사용 권한이 부여된 경우 해당 템플릿 또는 레이블을 편집하고 기존 이메일 주소에 부여한 것과 동일한 사용 권한으로 새 이메일 주소를 지정합니다.
그룹이 이메일 주소를 변경하는 일은 매우 드물게 있으며 개별 사용자가 아닌 그룹에 사용 권한을 할당하면 사용자의 이메일 주소가 변경되어도 아무 문제 없습니다. 이 시나리오에서는 사용 권한이 개별 사용자 이메일 주소가 아닌 그룹 이메일 주소에 할당됩니다. 이는 관리자가 문서 및 전자 메일을 보호하는 사용 권한을 구성할 가능성이 가장 높고 권장되는 방법입니다. 그러나 사용자가 늘 하던 식으로 개별 사용자에 대한 사용자 지정 권한을 할당할 수도 있습니다. 사용자 계정 또는 그룹이 액세스 권한을 부여하는 데 사용되었는지 항상 알 수 없으므로 항상 이전 전자 메일 주소를 두 번째 전자 메일 주소로 추가하는 것이 가장 안전합니다.
Azure Information Protection의 그룹 멤버 자격 캐싱
성능상의 이유로 Azure Information Protection은 그룹 멤버 자격을 캐시합니다. 즉, 이러한 그룹이 Azure Information Protection에서 사용되고 이 기간이 변경될 경우 Microsoft Entra ID의 그룹 멤버 자격 변경이 적용되는 데 최대 3시간이 걸릴 수 있습니다.
이 지연은 사용 권한을 부여하거나 Azure Rights Management 서비스를 구성하기 위해 그룹을 사용하거나 범위가 지정된 정책을 구성할 때 수행하는 변경 또는 테스트에 고려해야 합니다.
다음 단계
사용자 및 그룹을 Azure Information Protection과 함께 사용할 수 있고 문서 및 전자 메일 보호를 시작할 준비가 된 경우 Azure Rights Management 서비스를 활성화해야 하는지 여부를 검사. 조직의 문서 및 전자 메일을 보호하려면 먼저 이 서비스를 활성화해야 합니다.
2018년 2월부터: Azure Rights Management 또는 Azure Information Protection을 포함하는 구독을 이달 중 또는 그 이후에 가져온 경우 서비스가 자동으로 활성화됩니다.
2018년 2월 이전에 구독을 얻은 경우: 서비스를 직접 활성화해야 합니다.
활성화 상태 확인을 포함한 자세한 내용은 Azure Information Protection에서 보호 서비스 활성화를 참조하세요.