Azure Rights Management 테넌트 키는 Microsoft Purview Information Protection 기본 암호화 서비스에 대한 organization 루트 키입니다. 다른 키는 사용자 키, 컴퓨터 키 또는 문서 암호화 키를 포함하여 이 루트 키에서 파생될 수 있습니다. Azure Rights Management 서비스에서 organization 이러한 키를 사용할 때마다 Azure Rights Management 서비스에 대한 테넌트의 루트 키에 암호화적으로 연결됩니다.
테넌트 루트 키 외에도 organization 특정 문서에 대한 온-프레미스 보안이 필요할 수 있습니다. 온-프레미스 키 암호화는 일반적으로 소량의 콘텐츠에만 필요하므로 테넌트 루트 키와 함께 구성됩니다.
다음 섹션을 사용하여 Azure Rights Management 테넌트 키에 대한 옵션과 이를 관리하는 방법을 이해합니다.
회사 합병 후와 같이 테넌트 간에 마이그레이션하는 경우 자세한 내용은 합병 및 스핀오프에 대한 블로그 게시물을 읽어보는 것이 좋습니다.
서비스의 키 형식
Azure Rights Management 서비스의 루트 키는 다음 중 하나일 수 있습니다.
- Microsoft에서 생성
- BYOK(Bring Your Own Key)를 사용하여 고객이 생성
추가 온-프레미스 보호가 필요한 매우 중요한 콘텐츠가 있는 경우 DKE(이중 키 암호화)를 사용하는 것이 좋습니다.
Microsoft에서 생성된 테넌트 루트 키
Microsoft에서 자동으로 생성되는 기본 루트 키는 테넌트 키 수명 주기의 대부분의 측면을 관리하기 위해 Azure Rights Management 서비스에만 사용되는 기본 키입니다.
특별한 하드웨어, 소프트웨어 또는 Azure 구독 없이 Azure Rights Management 서비스를 빠르게 사용하려는 경우 기본 Microsoft 키를 계속 사용합니다. 예를 들어 키 관리에 대한 규정 요구 사항이 없는 테스트 환경 또는 조직이 있습니다.
기본 키의 경우 구성 단계가 필요하지 않습니다.
참고
Microsoft에서 생성된 기본 루트 키는 관리 오버헤드가 가장 낮은 가장 간단한 옵션입니다.
대부분의 경우 Microsoft Purview Information Protection 대한 암호화 설정을 구성할 수 있고 Microsoft에서 키 관리 프로세스를 처리하므로 테넌트 키가 있다는 것을 알지 못할 수도 있습니다.
BYOK(Bring Your Own Key) 옵션
BYOK는 Azure Key Vault 또는 고객 organization 온-프레미스에서 고객이 만든 키를 사용합니다. 그런 다음, 이러한 키는 추가 관리를 위해 Azure Key Vault 전송됩니다.
모든 수명 주기 작업에 대한 제어를 포함하여 키 생성에 대한 규정 준수 규정이 organization 있는 경우 BYOK를 사용합니다. 예를 들어 하드웨어 보안 모듈로 키를 보호해야 하는 경우입니다.
자세한 내용은 BYOK 구성을 참조하세요.
이중 키 암호화(DKE)
DKE는 함께 작동하는 두 개의 루트 키, 즉 Azure에서 Microsoft에서 만들고 보유한 키와 고객이 온-프레미스에서 만들고 보유하는 루트 키를 사용하여 콘텐츠에 대한 추가 보안을 제공합니다.
DKE는 두 키를 모두 암호화된 콘텐츠에 액세스해야 하므로 Microsoft 및 기타 타사에서 암호화된 데이터에 자체 액세스하지 못하도록 합니다.
DKE는 클라우드 또는 온-프레미스에 배포하여 스토리지 위치에 대한 완전한 유연성을 제공할 수 있습니다.
자세한 내용은 이중 키 암호화를 참조하세요.
테넌트 키에 대한 작업
Azure Rights Management 서비스 키 유형에 따라 Azure Rights Management 테넌트 키에 대한 다양한 수준의 제어 및 책임이 있습니다.
키 관리 작업에 대한 용어:
- Microsoft에서 생성한 테넌트 키를 사용하는 경우 키는 Microsoft 관리형입니다.
- BYOK를 사용하여 생성한 Azure Key Vault 키를 사용하는 경우 키는 고객 관리형입니다.
다음 표를 사용하여 Azure Rights Management 테넌트 키가 Microsoft 관리형 또는 고객 관리형인지에 따라 수행할 수 있는 관리 작업을 식별합니다.
| 수명 주기 작업 | Microsoft 관리형(기본값) | BYOK(고객 관리) |
|---|---|---|
| 테넌트 키 해지 | ✕ (자동) | ✓ |
| 테넌트 키 다시 키 다시 입력 | ✓ | ✓ |
| 테넌트 키 백업 및 복구 | ✕ | ✓ |
| 테넌트 키 내보내기 | ✓ | ✕ |
| 위반에 대응 | ✓ | ✓ |
이러한 각 작업에 대한 자세한 내용은 테넌트 키 유형에 대한 관련 탭을 사용합니다.
그러나 Active Directory Rights Management Services에서 신뢰할 수 있는 게시 도메인(TPD)을 가져와서 Azure Rights Management 테넌트 키를 만들려는 경우 이 가져오기 작업은 AD RMS에서 Azure Information Protection 마이그레이션의 일부입니다. 디자인의 일부로 AD RMS TPD는 하나의 테넌트로만 가져올 수 있습니다.
테넌트 키 해지
Azure Rights Management 서비스를 포함하는 유일한 구독 또는 마지막 구독을 취소하면 서비스는 Azure Rights Management 테넌트 키 사용을 중지하고 아무 작업도 필요하지 않습니다.
테넌트 키 다시 키 다시 입력
키 다시 키는 키를 롤링하는 것으로도 알려져 있습니다. 이 작업을 수행하면 Azure Rights Management 서비스에서 기존 테넌트 키 사용을 중지하여 항목을 암호화하고 다른 키를 사용하기 시작합니다. 정책 및 권한 관리 템플릿은 즉시 사임하지만 Azure Rights Management 서비스를 사용하는 기존 클라이언트 및 서비스에 대해 이 변경은 점진적입니다. 따라서 몇 시간 동안 일부 새 콘텐츠는 이전 Azure Rights Management 테넌트 키로 계속 암호화됩니다.
키를 다시 입력하려면 Azure Rights Management 테넌트 키 개체를 구성하고 사용할 대체 키를 지정해야 합니다. 그런 다음 이전에 사용한 키가 Azure Rights Management 서비스에 대해 보관된 것으로 자동으로 표시됩니다. 이 구성은 이 키를 사용하여 암호화된 콘텐츠에 계속 액세스할 수 있도록 합니다.
Azure Rights Management 서비스에 대해 키를 다시 입력해야 하는 경우의 예:
암호화 모드 1 키를 사용하여 AD RMS(Active Directory Rights Management Services)에서 마이그레이션했습니다. 마이그레이션이 완료되면 암호화 모드 2를 사용하는 키를 사용하여 으로 변경하려고 합니다.
회사에서 두 개 이상의 회사로 나뉘어 있습니다. Azure Rights Management 테넌트 키를 다시 입력하면 새 회사에서 직원이 암호화하는 새 콘텐츠에 액세스할 수 없습니다. 이전 Azure Rights Management 테넌트 키의 복사본이 있는 경우 이전 콘텐츠에 액세스할 수 있습니다.
한 키 관리 토폴로지에서 다른 키 관리 토폴로지로 이동하려고 합니다.
Azure Rights Management 테넌트 키의 master 복사본이 손상되었습니다.
키를 다시 입력하려면 다른 Microsoft 관리형 키를 선택하여 Azure Rights Management 테넌트 키가 될 수 있지만 새 Microsoft 관리형 키를 만들 수는 없습니다. 새 키를 만들려면 키 토폴로지를 BYOK(고객 관리형)로 변경해야 합니다.
AD RMS(Active Directory Rights Management Services)에서 마이그레이션하고 Azure Rights Management 서비스에 대한 Microsoft 관리형 키 토폴로지를 선택한 경우 둘 이상의 Microsoft 관리형 키가 있습니다. 이 시나리오에서는 테넌트용 Microsoft 관리형 키가 두 개 이상 있습니다. 한 가지 키 이상은 AD RMS에서 가져온 키 또는 키입니다. Azure Rights Management 테넌트용으로 자동으로 만들어진 기본 키도 있습니다.
Azure Rights Management 서비스의 활성 테넌트 키로 사용할 다른 키를 선택하려면 AIPService 모듈의 Set-AipServiceKeyProperties cmdlet을 사용합니다. 사용할 키를 식별하는 데 도움이 되도록 Get-AipServiceKeys cmdlet을 사용합니다. 다음 명령을 실행하여 Azure Rights Management 테넌트용으로 자동으로 만들어진 기본 키를 식별할 수 있습니다.
(Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1
키 토폴로지를 BYOK(고객 관리형)로 변경하려면 Azure Rights Management 서비스 루트 키에 대한 사용자 고유의 키 가져오기를 참조하세요.
테넌트 키 백업 및 복구
Microsoft는 Azure Rights Management 테넌트 키를 백업할 책임이 있으며 사용자의 조치가 필요하지 않습니다.
테넌트 키 내보내기
다음 세 단계의 지침에 따라 Azure Rights Management 서비스 구성 및 해당 테넌트 키를 내보낼 수 있습니다.
1단계: 내보내기 시작
- Microsoft 지원 문의하여 Azure Rights Management 키 내보내기를 요청하는 Microsoft Purview Information Protection 지원 사례를 엽니다. 테넌트의 전역 관리자임을 증명하고 이 프로세스를 확인하는 데 며칠이 걸린다는 것을 이해해야 합니다. Standard 지원 요금이 적용됩니다. 테넌트 키를 내보내는 것은 무료 지원 서비스가 아닙니다.
2단계: 확인 대기
- Microsoft는 Azure Rights Management 테넌트 키 릴리스 요청이 합법적인지 확인합니다. 이 프로세스는 최대 3주가 걸릴 수 있습니다.
3단계: CSS에서 주요 지침 받기
Microsoft 고객 지원 서비스는 암호로 보호된 파일에서 암호화된 Azure Rights Management 서비스 구성 및 테넌트 키를 보냅니다. 이 파일의 확장명은 .tpd 입니다. 이를 위해 Microsoft 지원 엔지니어가 먼저 (내보내기를 시작한 사람)에게 도구를 이메일로 보냅니다. 다음과 같이 명령 프롬프트에서 도구를 실행해야 합니다.
AadrmTpd.exe -createkey이렇게 하면 RSA 키 쌍이 생성되고 공용 및 프라이빗 반쪽이 현재 폴더의 파일로 저장됩니다. 예: PublicKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt 및 PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt.
지원 엔지니어의 이메일에 응답하여 PublicKey로 시작하는 이름을 가진 파일을 첨부합니다. Microsoft 지원 다음으로 TPD 파일을 RSA 키로 암호화된 .xml 파일로 보냅니다. 원래 AadrmTpd 도구를 실행한 것과 동일한 폴더에 이 파일을 복사하고 PrivateKey로 시작하는 파일과 Microsoft 지원 파일을 사용하여 도구를 다시 실행합니다. 예시:
AadrmTpd.exe -key PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt -target TPD-77172C7B-8E21-48B7-9854-7A4CEAC474D0.xml이 명령의 출력은 두 개의 파일이어야 합니다. 하나는 암호로 보호되는 TPD에 대한 일반 텍스트 암호를 포함하고 다른 하나는 암호로 보호된 TPD 자체입니다. 파일에는 다음과 같은 새 GUID가 있습니다.
Password-5E4C2018-8C8C-4548-8705-E3218AA1544E.txt
ExportedTPD-5E4C2018-8C8C-4548-8705-E3218AA1544E.xml
이러한 파일을 백업하고 안전하게 저장하여 이 테넌트 키로 암호화된 콘텐츠의 암호를 계속 해독할 수 있도록 합니다. 또한 AD RMS로 마이그레이션하는 경우 이 TPD 파일( ExportedTDP로 시작하는 파일)을 AD RMS 서버로 가져올 수 있습니다.
4단계: 진행 중: 테넌트 키 보호
테넌트 키를 받은 후에는 누군가가 테넌트 키에 액세스하면 해당 키를 사용하여 암호화된 모든 항목의 암호를 해독할 수 있으므로 잘 보호된 상태로 유지합니다.
테넌트 키를 내보내는 이유가 더 이상 Azure Rights Management 서비스를 사용하지 않기 때문인 경우 이제 테넌트에서 Azure Rights Management 서비스를 비활성화합니다. 테넌트 키를 받은 후에는 이 작업을 수행하지 마세요. 이 예방 조치는 테넌트 키가 없어야 하는 누군가가 테넌트 키에 액세스하는 경우 결과를 최소화하는 데 도움이 되므로 이 작업을 수행하지 마세요. 자세한 내용은 Azure Rights Management 서비스 서비스 해제 및 비활성화를 참조하세요.
위반에 대응
보안 시스템이 아무리 강력하더라도 위반 대응 프로세스 없이는 완전하지 않습니다. Azure Rights Management 테넌트 키가 손상되거나 도난당할 수 있습니다. 잘 보호되는 경우에도 취약성은 현재 세대 키 기술 또는 현재 키 길이 및 알고리즘에서 찾을 수 있습니다.
Microsoft에는 제품 및 서비스의 보안 인시던트에 대응하는 전담 팀이 있습니다. 인시던트에 대한 신뢰할 수 있는 보고가 있는 즉시 이 팀은 scope, 근본 원인 및 완화를 조사하기 위해 참여합니다. 이 인시던트가 자산에 영향을 미치는 경우 Microsoft는 전자 메일로 테넌트에 대해 전역 관리자에게 알립니다.
위반이 있는 경우 귀하 또는 Microsoft가 취할 수 있는 최선의 조치는 위반의 scope 따라 달라집니다. Microsoft는 이 프로세스를 통해 귀하와 협력합니다. 다음 표에서는 정확한 응답이 조사 중에 표시되는 모든 정보에 따라 달라지지만 몇 가지 일반적인 상황과 응답 가능성이 있음을 보여 줍니다.
| 인시던트 설명 | 응답 가능성이 높습니다. |
|---|---|
| Azure Rights Management 테넌트 키가 유출되었습니다. | 테넌트 키 키를 다시 입력합니다. 이 문서의 테넌트 키 키 다시 만들기 섹션을 참조하세요. |
| 권한이 없는 개인 또는 맬웨어는 Azure Rights Management 테넌트 키를 사용할 수 있는 권한을 얻었지만 키 자체는 누출되지 않았습니다. | 테넌트 키를 다시 키 지정해도 도움이 되지 않으며 근본 원인 분석이 필요합니다. 프로세스 또는 소프트웨어 버그가 권한이 없는 개인에게 액세스 권한을 부여한 경우 해당 상황을 해결해야 합니다. |
| RSA 알고리즘에서 발견된 취약성 또는 키 길이 또는 무차별 암호 대입 공격(brute-force attack)은 계산이 가능합니다. | Microsoft는 복원력이 있는 새 알고리즘과 긴 키 길이를 지원하도록 Azure Rights Management 서비스를 업데이트하고 모든 고객에게 Azure Rights Management 테넌트 키를 다시 입력하도록 지시해야 합니다. |