Azure Rights Management 서비스의 작동 방식: 기술 세부 정보

Azure Rights Management 서비스의 작동 방식을 자세히 이해하려면 다음 정보를 사용합니다. 데이터를 보호하기 위해 암호화 설정을 구성하거나 적용하기 위해 이 수준의 정보를 알 필요가 없습니다.

Azure Rights Management 서비스에 대해 이해해야 하는 중요한 개념은 이 서비스가 암호화 프로세스의 일부로 데이터를 보거나 저장하지 않는다는 것입니다. 암호화하는 정보는 Azure에 명시적으로 저장하거나 Azure에 저장하는 다른 클라우드 서비스를 사용하지 않는 한 Azure에 전송되거나 저장되지 않습니다. Azure Rights Management 서비스는 권한 있는 사용자 및 서비스 이외의 다른 사용자가 항목의 데이터를 읽을 수 없도록 만듭니다.

• 데이터는 애플리케이션 수준에서 암호화되며 해당 항목에 대한 권한 있는 사용을 정의하는 정책을 포함합니다.

• 합법적인 사용자가 암호화된 항목을 사용하거나 권한 있는 서비스에서 처리하는 경우 항목의 데이터는 암호가 해독되고 정책에 정의된 권한이 적용됩니다.

높은 수준에서 다음 그림에서 이 프로세스의 작동 방식을 확인할 수 있습니다. 비밀 수식이 포함된 문서가 암호화된 다음 권한 있는 사용자 또는 서비스에서 성공적으로 열립니다. 문서는 콘텐츠 키(이 그림의 녹색 키)로 암호화됩니다. 콘텐츠 키는 각 문서에 대해 고유하며 Azure Rights Management 테넌트 루트 키(이 그림의 빨간색 키)로 암호화되는 파일 헤더에 배치됩니다. 테넌트 키는 Microsoft에서 생성 및 관리하거나 사용자 고유의 테넌트 키를 생성하고 관리할 수 있습니다.

Azure Rights Management 서비스가 암호화 및 암호 해독, 권한 부여 및 제한을 적용하는 경우 암호화된 프로세스 전체에서 비밀 수식은 Azure로 전송되지 않습니다.

무슨 일이 일어나고 있는지에 대한 자세한 설명은 이 문서의 서비스 작동 방식 연습: 첫 번째 사용, 콘텐츠 암호화, 콘텐츠 사용 섹션을 참조하세요.

서비스에서 사용하는 알고리즘 및 키 길이에 대한 자세한 내용은 다음 섹션을 참조하세요.

암호화 컨트롤: 알고리즘 및 키 길이

이 기술의 작동 방식을 자세히 알 필요가 없더라도 사용하는 암호화 컨트롤에 대한 질문을 받을 수 있습니다. 예를 들어 암호화가 업계 표준인지 확인합니다.

각주 1

256비트 는 다음 시나리오에서 Microsoft Purview Information Protection 클라이언트에서 사용됩니다.

• 일반 암호화(.pfile).

• 문서가 PDF 암호화를 위해 ISO 표준으로 암호화되었거나 결과로 암호화된 문서에 .ppdf 파일 이름 확장명을 가진 경우 PDF 문서의 기본 암호화입니다.

• 텍스트 또는 이미지 파일(예: .ptxt 또는 .pjpg)에 대한 기본 암호화입니다.

각주 2

2048비트 는 Azure Rights Management 서비스가 활성화될 때의 키 길이입니다. 1024비트 는 다음과 같은 선택적 시나리오에서 지원됩니다.

• AD RMS 클러스터가 암호화 모드 1에서 실행되는 경우 온-프레미스에서 마이그레이션하는 동안

• 마이그레이션 전에 온-프레미스에서 만든 보관된 키의 경우 이전에 AD RMS에서 암호화한 콘텐츠를 마이그레이션 후 Azure Rights Management 서비스에서 계속 열 수 있습니다.

암호화 키를 저장하고 보호하는 방법

Azure Rights Management 서비스에서 보호하는 각 문서 또는 전자 메일에 대해 서비스는 단일 AES 키("콘텐츠 키")를 만들고 해당 키가 문서에 포함되며 문서의 버전을 통해 유지됩니다.

콘텐츠 키는 문서의 정책의 일부로 organization RSA 키("Azure Rights Management 테넌트 키")로 암호화되며, 문서의 작성자도 정책에 서명합니다. 이 테넌트 키는 organization 대한 Azure Rights Management 서비스로 보호되는 모든 문서 및 전자 메일에 공통되며, 이 키는 organization 고객 관리형 테넌트 키("BRING Your Own Key" 또는 BYOK)를 사용하는 경우에만 서비스에 대한 관리자가 변경할 수 있습니다.

이 테넌트 키는 Microsoft의 온라인 서비스, 고도로 제어된 환경 및 긴밀한 모니터링에서 보호됩니다. BYOK(고객 관리 테넌트 키)를 사용하는 경우 어떤 상황에서도 키를 추출, 내보내기 또는 공유할 수 없도록 각 Azure 지역에서 HSM(고급 하드웨어 보안 모듈) 배열을 사용하여 이 보안을 강화합니다. 테넌트 키 및 BYOK에 대한 자세한 내용은 Azure Information Protection 테넌트 키 계획 및 구현을 참조하세요.

Windows 디바이스로 전송되는 라이선스 및 인증서는 클라이언트의 디바이스 프라이빗 키로 암호화됩니다. 이 프라이빗 키는 디바이스의 사용자가 Azure Rights Management 서비스를 처음 사용할 때 만들어집니다. 이 프라이빗 키는 클라이언트에서 DPAPI를 사용하여 암호화되며, 사용자의 암호에서 파생된 키를 사용하여 이러한 비밀을 보호합니다. 모바일 디바이스에서 키는 한 번만 사용되므로 클라이언트에 저장되지 않으므로 이러한 키를 디바이스에서 암호화할 필요가 없습니다.

서비스 작동 방식 연습: 첫 번째 사용, 콘텐츠 암호화, 콘텐츠 사용

Azure Rights Management 서비스의 작동 방식을 자세히 이해하려면 Azure Rights Management 서비스가 활성화되고 사용자가 Windows 컴퓨터에서 Rights Management 서비스를 처음 사용하는 경우( 사용자 환경 초기화 또는 부트스트랩이라고도 함) 콘텐츠(문서 또는 전자 메일)를 암호화 하는 일반적인 흐름을 살펴보겠습니다. 그런 다음 다른 사람이 암호화한 콘텐츠를 사용 (열기 및 사용)합니다.

사용자 환경이 초기화되면 해당 사용자는 문서를 암호화하거나 해당 컴퓨터에서 암호화된 문서를 사용할 수 있습니다.

사용자 환경 초기화

사용자가 Windows 컴퓨터에서 콘텐츠를 암호화하거나 암호화된 콘텐츠를 사용하려면 먼저 디바이스에서 사용자 환경을 준비해야 합니다. 이는 일회성 프로세스이며 사용자가 암호화된 콘텐츠를 암호화하거나 사용하려고 할 때 사용자의 개입 없이 자동으로 발생합니다.

1단계에서 발생하는 작업: 컴퓨터에서 실행되는 Azure Rights Management 서비스의 클라이언트는 먼저 서비스에 연결하고 서비스는 해당 Microsoft Entra 계정을 사용하여 사용자를 인증합니다.

사용자의 계정이 Microsoft Entra ID 페더레이션되면 이 인증은 자동으로 수행되며 사용자에게 자격 증명을 묻는 메시지가 표시되지 않습니다.

2단계: 사용자가 인증되면 연결이 자동으로 organization 테넌트로 리디렉션됩니다. 이 테넌트는 사용자가 암호화된 콘텐츠를 사용하고 오프라인으로 콘텐츠를 암호화하기 위해 Azure Rights Management 서비스에 인증할 수 있는 인증서를 발급합니다.

이러한 인증서 중 하나는 RAC로 약어되는 권한 계정 인증서입니다. 이 인증서는 사용자가 Microsoft Entra ID 인증하며 31일 동안 유효합니다. 사용자 계정이 아직 Microsoft Entra ID 있고 계정이 사용하도록 설정되어 있으면 클라이언트에서 인증서를 자동으로 갱신합니다. 이 인증서는 관리자가 구성할 수 없습니다.

이 인증서의 복사본은 사용자가 다른 디바이스로 이동하는 경우 동일한 키를 사용하여 인증서를 만들 수 있도록 Azure에 저장됩니다.

콘텐츠 암호화

사용자가 문서를 암호화하면 Azure Rights Management 서비스의 클라이언트는 암호화되지 않은 문서에 대해 다음 작업을 수행합니다.

1단계에서 발생하는 작업: 클라이언트는 임의 키(콘텐츠 키)를 만들고 AES 대칭 암호화 알고리즘과 함께 이 키를 사용하여 문서를 암호화합니다.

2단계에서 발생하는 작업: 클라이언트는 사용자 또는 그룹에 대한 사용 권한 및 만료 날짜와 같은 기타 제한을 포함하는 문서에 대한 정책을 포함하는 인증서를 만듭니다. 이러한 설정은 이전에 관리자가 구성했거나 콘텐츠가 암호화될 때 지정한 민감도 레이블 암호화 설정("사용자 정의 권한" 또는 "임시 정책"이라고도 함)으로 정의할 수 있습니다.

선택한 사용자 및 그룹을 식별하는 데 사용되는 주요 Microsoft Entra 특성은 사용자 또는 그룹의 모든 이메일 주소를 저장하는 Microsoft Entra ProxyAddresses 특성입니다. 그러나 사용자 계정에 AD ProxyAddresses 특성에 값이 없는 경우 사용자의 UserPrincipalName 값이 대신 사용됩니다.

그런 다음 클라이언트는 사용자 환경이 초기화될 때 가져온 organization 키를 사용하고 이 키를 사용하여 정책 및 대칭 콘텐츠 키를 암호화합니다. 또한 클라이언트는 사용자 환경을 초기화할 때 얻은 사용자 인증서를 사용하여 정책에 서명합니다.

3단계에서 발생하는 작업: 마지막으로 클라이언트는 이전에 암호화된 문서 본문이 있는 파일에 정책을 포함하며, 이는 함께 암호화된 문서로 구성됩니다.

이 문서는 모든 위치에 저장하거나 메서드를 사용하여 공유할 수 있으며 정책은 항상 암호화된 문서와 함께 유지됩니다.

콘텐츠 사용량

사용자가 암호화된 문서를 사용하려는 경우 클라이언트는 Azure Rights Management 서비스에 대한 액세스를 요청하여 시작합니다.

1단계에서 발생하는 작업: 인증된 사용자는 문서 정책 및 사용자의 인증서를 Azure Rights Management 서비스로 보냅니다. 서비스는 정책의 암호를 해독하고 평가하고 사용자가 문서에 대해 가지고 있는 권한 목록(있는 경우)을 작성합니다. 사용자를 식별하기 위해 Microsoft Entra ProxyAddresses 특성은 사용자의 계정 및 사용자가 멤버인 그룹에 사용됩니다. 성능상의 이유로 그룹 멤버 자격은 캐시됩니다. 사용자 계정에 Microsoft Entra ProxyAddresses 특성에 대한 값이 없는 경우 Microsoft Entra UserPrincipalName의 값이 대신 사용됩니다.

2단계: 서비스는 암호 해독된 정책에서 AES 콘텐츠 키를 추출합니다. 그런 다음, 이 키는 요청으로 가져온 사용자의 공용 RSA 키로 암호화됩니다.

그런 다음, 다시 암호화된 콘텐츠 키가 사용자 권한 목록과 함께 암호화된 사용 라이선스에 포함되고 클라이언트에 반환됩니다.

3단계에서 발생하는 작업: 마지막으로 클라이언트는 암호화된 사용 라이선스를 사용하고 자체 사용자 프라이빗 키로 암호를 해독합니다. 이렇게 하면 클라이언트가 필요에 따라 문서의 본문을 해독하고 화면에 렌더링할 수 있습니다.

또한 클라이언트는 권한 목록의 암호를 해독하고 애플리케이션에 전달하여 애플리케이션의 사용자 인터페이스에서 해당 권한을 적용합니다.

Variations

위의 연습에서는 표준 시나리오를 다루지만 몇 가지 변형이 있습니다.

• Email 암호화: 전자 메일 메시지를 암호화하는 데 Exchange Online 및 Microsoft Purview 메시지 암호화 사용하는 경우 사용 인증은 소셜 ID 공급자와의 페더레이션을 사용하거나 일회성 암호를 사용하여 사용할 수도 있습니다. 그런 다음, 콘텐츠 사용이 일시적으로 캐시된 아웃바운드 이메일 복사본을 통해 웹 브라우저 세션에서 서비스 쪽에서 발생한다는 점을 제외하고 프로세스 흐름은 매우 유사합니다.

• 모바일 디바이스: 모바일 디바이스가 Azure Rights Management 서비스를 사용하여 파일을 암호화하거나 사용하는 경우 프로세스 흐름이 더 간단합니다. 모바일 디바이스는 먼저 사용자 초기화 프로세스를 거치지 않습니다. 대신 각 트랜잭션(콘텐츠 암호화 또는 사용)은 독립적이기 때문입니다. Windows 컴퓨터와 마찬가지로 모바일 디바이스는 Azure Rights Management 서비스에 연결하고 인증합니다. 콘텐츠를 암호화하기 위해 모바일 디바이스는 정책을 제출하고 Azure Rights Management 서비스는 문서를 암호화하기 위해 게시 라이선스 및 대칭 키를 보냅니다. 암호화된 콘텐츠를 사용하려면 모바일 디바이스가 Azure Rights Management 서비스에 연결하고 인증할 때 문서 정책을 Azure Rights Management 서비스에 보내고 문서를 사용하기 위한 사용 라이선스를 요청합니다. 이에 대한 응답으로 Azure Rights Management 서비스는 모바일 디바이스에 필요한 키와 제한을 보냅니다. 두 프로세스 모두 TLS를 사용하여 키 교환 및 기타 통신을 보호합니다.

• Rights Management 커넥터: Azure Rights Management 서비스를 Rights Management 커넥터와 함께 사용하는 경우 프로세스 흐름은 동일하게 유지됩니다. 유일한 차이점은 커넥터가 온-프레미스 서비스(예: Exchange Server 및 SharePoint Server)와 Azure Rights Management 서비스 간의 릴레이 역할을 한다는 것입니다. 커넥터 자체는 사용자 환경의 초기화, 암호화 또는 암호 해독과 같은 작업을 수행하지 않습니다. 일반적으로 AD RMS 서버로 이동하는 통신을 릴레이하여 각 쪽에서 사용되는 프로토콜 간의 변환을 처리합니다. 이 시나리오를 사용하면 온-프레미스 서비스에서 Azure Rights Management 서비스를 사용할 수 있습니다.

• 일반 암호화(.pfile): Azure Rights Management 서비스가 일반적으로 파일을 암호화하는 경우 클라이언트가 모든 권한을 부여하는 정책을 만든다는 점을 제외하고 콘텐츠 암호화에 대한 흐름은 기본적으로 동일합니다. 파일이 사용되면 대상 애플리케이션에 전달되기 전에 암호가 해독됩니다. 이 시나리오에서는 기본적으로 Azure Rights Management 서비스를 지원하지 않는 경우에도 모든 파일을 암호화할 수 있습니다.

• Microsoft 계정: Azure Rights Management 서비스는 Microsoft 계정으로 인증될 때 사용할 이메일 주소에 권한을 부여할 수 있습니다. 그러나 Microsoft 계정을 인증에 사용할 때 모든 애플리케이션이 암호화된 콘텐츠를 열 수 있는 것은 아닙니다. 자세한 정보.

다음 단계

Azure Rights Management 서비스에 대한 덜 기술적인 개요는 Azure Rights Management 서비스에 대해 알아보기를 참조하세요.

데이터를 보호하기 위한 암호화를 포함하는 권장 단계를 배포할 준비가 되었으면 Microsoft Purview를 사용하여 정보 보호 솔루션 배포를 참조하세요.