Azure RMS는 어떻게 작동합니까? 기본적인 이해

Azure RMS의 작동 방식을 이해해야 하는 중요한 점은 Azure Information Protection의 이 데이터 보호 서비스가 보호 프로세스의 일부로 데이터를 보거나 저장하지 않는다는 것입니다. 보호되는 정보는 Azure에 명시적으로 저장하거나 Azure에 저장하는 다른 클라우드 서비스를 사용하지 않는 한 Azure에 전송되거나 저장되지 않습니다. Azure RMS는 권한 있는 사용자 및 서비스 이외의 다른 사용자가 문서의 데이터를 읽을 수 없도록 만듭니다.

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

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

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

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

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

Azure RMS에서 사용하는 알고리즘 및 키 길이에 대한 기술 세부 정보는 다음 섹션을 참조하세요.

Azure RMS에서 사용하는 암호화 컨트롤: 알고리즘 및 키 길이

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

암호화 컨트롤	Azure RMS에서 사용
알고리즘: AES 키 길이: 128비트 및 256비트 [1]	콘텐츠 보호
알고리즘: RSA 키 길이: 2048비트 [2]	키 보호
SHA-256	인증서 서명

각주 1

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

• 일반 보호(.pfile).

• 문서가 PDF 암호화용 ISO 표준으로 보호되었거나 그로 인해 보호된 문서에 .ppdf 파일 이름 확장명을 가진 경우 PDF 문서에 대한 기본 보호입니다.

• 텍스트 또는 이미지 파일(예: .ptxt 또는 .pjpg)에 대한 네이티브 보호입니다.

각주 2

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

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

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

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

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

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

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

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

Azure RMS 작동 방식 연습: 첫 번째 사용, 콘텐츠 보호, 콘텐츠 사용

Azure RMS가 작동하는 방식을 자세히 이해하기 위해 Azure Rights Management 서비스가 활성화된 후 및 사용자가 자신의 Windows 컴퓨터에서 Rights Management Service를 처음 사용하고(사용자 환경 초기화 또는 부트 스트랩으로 알려진 프로세스), 콘텐츠(문서 또는 이메일)를 보호한 다음, 다른 사람이 보호한 콘텐츠를 사용(열기 및 사용)하는 경우의 일반적인 흐름을 단계별로 살펴보겠습니다.

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

참고 항목

이 사용자가 다른 Windows 컴퓨터로 이동하거나 다른 사용자가 동일한 이 Windows 컴퓨터를 사용하는 경우 초기화 프로세스가 반복됩니다.

사용자 환경 초기화

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

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

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

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

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

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

콘텐츠 보호

사용자가 문서를 보호하면 RMS 클라이언트는 보호되지 않는 문서에서 다음 작업을 수행합니다.

1단계의 상황: RMS 클라이언트에서 임의 키(콘텐츠 키)를 만들고, AES 대칭 암호화 알고리즘을 사용하여 이 키로 문서를 암호화합니다.

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

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

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

3단계의 상황: 마지막으로 RMS 클라이언트에서 이전에 암호화된 문서 본문이 있는 파일에 정책을 포함하여 보호된 문서를 구성합니다.

이 문서는 모든 방법을 사용하여 어디에나 저장하거나 공유할 수 있으며 정책은 항상 암호화된 문서와 함께 유지됩니다.

콘텐츠 사용

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

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

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

그러면 다시 암호화된 콘텐츠 키가 사용자 권한 목록을 사용하여 암호화된 사용 라이선스에 포함되고 RMS 클라이언트로 반환됩니다.

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

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

참고 항목

조직 외부에 있는 사용자가 보호한 콘텐츠를 사용하는 경우 소비 흐름은 동일합니다. 이 시나리오의 변경 사항은 사용자를 인증하는 방법입니다. 자세한 내용은 회사 외부의 다른 사용자와 보호된 문서를 공유할 때 해당 사용자가 어떻게 인증되나요?

변형

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

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

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

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

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

• Microsoft 계정: Azure Information Protection은 Microsoft 계정으로 인증될 때 사용할 전자 메일 주소에 권한을 부여할 수 있습니다. 그러나 Microsoft 계정이 인증에 사용되는 경우 모든 애플리케이션이 보호된 콘텐츠를 열 수 있는 것은 아닙니다. 추가 정보.

다음 단계

Azure Rights Management 서비스에 대해 자세히 알아보려면 애플리케이션이 Azure Rights Management 서비스를 지원하는 방법과 같은 이해 및 탐색 섹션의 다른 문서를 사용하여 기존 애플리케이션이 Azure Rights Management와 통합되어 정보 보호 솔루션을 제공하는 방법을 알아봅니다.

Azure Information Protection에 사용되는 용어를 검토하여 Azure Rights Management 서비스를 구성하고 사용할 때 나올 수 있는 용어를 파악하고, 배포를 시작하기 전에 Azure Information Protection에 대한 요구 사항도 확인합니다. Azure RMS를 직접 사용해 보려는 경우에는 다음에 나와 있는 빠른 시작 및 자습서를 참조하세요.

• 빠른 시작: 통합 레이블 지정 클라이언트 배포
• 자습서: AIP(Azure Information Protection) 통합 레이블 지정 스캐너 설치
• 자습서: AIP(Azure Information Protection) 스캐너를 사용하여 중요한 콘텐츠 찾기
• 자습서: AIP(Azure Information Protection)를 사용하여 Outlook에서 과도한 공유 방지

조직에 대한 데이터 보호 배포를 시작할 준비가 되면 분류, 레이블 지정 및 보호에 대한 AIP 배포 로드맵을 사용하여 배포 단계 및 방법 지침에 대한 링크를 확인합니다.