Information Protection에 대한 보안 모범 사례

중요

2020년 3월 이전에 릴리스된 Microsoft Rights Management Service SDK 버전은 더 이상 사용되지 않습니다. 2020년 3월 릴리스를 사용하려면 이전 버전을 사용하는 애플리케이션을 업데이트해야 합니다. 자세한 내용은 사용 중단 알림을 참조하세요.

Microsoft Rights Management Service SDK에 대한 추가 개선 사항은 계획되지 않았습니다. 분류, 레이블 지정 및 보호 서비스에 Microsoft Information Protection SDK를 채택하는 것이 좋습니다.

Information Protection SDK(소프트웨어 개발 키트)는 모든 종류의 보호된 정보를 게시 및 사용하기 위한 강력한 시스템을 제공합니다. 시스템이 최대한의 보호 기능을 제공하도록 하려면 정보 보호 지원 애플리케이션을 모범 사례에 따라 빌드해야 합니다. 애플리케이션은 이 에코시스템의 보안을 유지할 공동 책임이 있습니다. 보안 위험을 식별하고 애플리케이션 개발 중 발생하는 위험을 완화하는 방법을 제공하면 덜 안전한 소프트웨어를 구현할 가능성을 최소화할 수 있습니다.

이 정보는 SDK를 사용하여 애플리케이션에 대한 디지털 인증서를 얻으려면 서명해야 하는 법적 계약서를 보완합니다.

다루지 않는 주제

다음 주제는 개발 환경 및 보안 애플리케이션을 만들기 위한 중요한 고려 사항이지만 이 문서에서는 다루지 않습니다.

• 소프트웨어 개발 프로세스 관리 - 구성 관리, 원본 코드 보호, 디버그된 코드에 대한 액세스 최소화 및 버그의 우선 순위 할당. 고객에 따라서는 더 안전한 소프트웨어 개발 프로세스를 갖추는 일이 매우 중요한 경우도 있습니다. 일부 고객은 개발 프로세스를 공식적으로 정해 놓기도 합니다.
• 일반적인 코딩 오류 - 버퍼 오버런을 방지하는 정보. Michael Howard와 David LeBlanc이 작성한 Writing Secure Code(Microsoft Press, 2002)의 최신 버전에서 이러한 일반 위협과 완화 방법을 검토하는 것이 좋습니다.
• 소셜 엔지니어링 - 개발자나 제조업체 조직 내의 다른 사람이 코드를 악용하지 못하도록 하는 절차 및 구조상의 보호 조치에 대한 정보를 포함합니다.
• 물리적 보안 - 코드베이스 및 서명 인증서에 대한 액세스를 잠그는 방법에 대한 정보를 포함합니다.
• 시험판 소프트웨어의 개발 또는 배포 - 베타 소프트웨어를 배포하는 방법에 대한 정보를 포함합니다.
• 네트워크 관리 - 실제 네트워크의 침입 검색 시스템에 대한 정보를 포함합니다.

위협 모델 및 완화 방법

디지털 정보 소유자는 자기 자산의 암호가 해독되는 환경을 평가할 수 있어야 합니다. 최소 보안 표준에서는 정보 소유자에게 애플리케이션의 보안 수준을 파악 및 평가하기 위한 틀을 제공할 수 있습니다.

정부 및 보건과 같은 일부 산업 분야에는 제품에 적용될 수 있는 인증 및 승인 프로세스와 표준이 마련되어 있을 수 습니다. 이러한 최소 보안 권장 사항을 충족한다고 고객의 고유한 승인 요구 사항이 없어지지는 않습니다. 그러나 이 보안 표준은 현재와 향후의 고객 요구 사항에 대비할 수 있도록 돕기 위한 것이며 개발 주기 초기 단계의 투자는 애플리케이션에 유익합니다. 이러한 지침은 권장 사항이지 공식 Microsoft 인증 프로그램은 아닙니다.

Rights Management 서비스 시스템의 몇 가지 취약성 범주는 다음과 같습니다.

• 유출 - 정보가 인증되지 않은 위치에 표시됩니다.
• 손상 - 소프트웨어 또는 데이터가 무단으로 수정됩니다.
• 거부 - 컴퓨팅 리소스를 사용할 수 없습니다.

이러한 항목에서는 주로 유출 문제를 다룹니다. API 시스템의 무결성은 점차 지정된 엔터티만 액세스할 수 있도록 하여 정보를 보호할 수 있는 기능에 의존합니다. 이러한 항목에서는 손상 문제도 다룹니다. 거부 문제는 다루지 않습니다.

Microsoft는 최소 표준을 충족하는 데 관련된 테스트 결과를 테스트하거나 검토하지 않습니다. 파트너는 최소 표준 준수를 보장하는 일을 담당합니다. Microsoft에서는 일반적인 위협을 완화하는 데 도움이 되는 두 가지 추가 수준의 권장 사항을 제공합니다. 일반적으로 이러한 제안 사항은 부가적인 사항입니다. 예를 들어 기본 권장 사항을 충족하면 달리 지정되지 않은 경우 해당하는 최소 표준을 충족한 것으로 간주됩니다.

표준 수준	설명
최소 표준	보호된 정보를 처리하는 애플리케이션이 최소 표준을 충족해야만 Microsoft에서 받는 프로덕션 인증서로 애플리케이션이 서명될 수 있습니다. 파트너는 일반적으로 소프트웨어의 최종 릴리스 시점에 프로덕션 계층 구조 인증서를 사용합니다. 파트너의 고유한 내부 테스트는 애플리케이션인 이 최소 표준을 충족하는지 여부를 확인하는 데 사용됩니다. 최소 표준을 충족한다고 Microsoft에서 보안을 보장하는 것은 아니며 이처럼 해석해서도 안 됩니다. Microsoft는 최소 표준을 충족하는 데 관련된 테스트 결과를 테스트하거나 검토하지 않습니다. 파트너는 최소한의 준수를 보장하는 일을 담당합니다.
권장 표준	권장 지침에서는 애플리케이션 보안을 개선하는 방향을 설명할 뿐 아니라 더 많은 보안 기준을 구현함에 따라 SDK가 어떻게 개선될 수 있는지를 보여줍니다. 공급업체에서는 더 높은 수준의 보안 지침에 따라 빌드하여 애플리케이션을 차별화할 수 있습니다.
기본 표준	이 표준은 현재 정의된 가장 높은 수준의 보안 범주입니다. 매우 안전하다고 마케팅하는 애플리케이션을 개발하는 공급업체는 이 표준을 목표로 해야 합니다. 이 표준을 준수하는 애플리케이션은 공격에 취약할 가능성이 가장 낮습니다.

악성 소프트웨어

Microsoft에서는 애플리케이션이 악성 소프트웨어 콘텐츠를 보호하기 위해 준수해야 하는 최소 필수 표준을 정의했습니다.

주소 테이블을 사용하여 악성 소프트웨어 가져오기

정보 보호 SDK에서는 런타임 시 코드를 수정하거나 IAT(가져오기 주소 테이블)를 수정할 수 없습니다. 가져오기 주소 테이블은 프로세스 공간에서 로드되는 모든 DLL에 대해 생성됩니다. 이 테이블에서는 애플리케이션이 가져오는 모든 함수의 주소를 지정합니다. 한 가지 일반적인 공격 방법은 애플리케이션 내에서 IAT 항목을 수정하는 것입니다. 예를 들어 악성 소프트웨어를 가리키도록 수정할 수 있습니다. SDK에서는 이러한 유형의 공격을 감지하면 애플리케이션을 중지합니다.

최소 표준

• 실행 중인 애플리케이션 프로세스에서 가져오기 주소 테이블을 수정할 수 없습니다. 애플리케이션에서는 런타임 시 호출되는 많은 함수를 주소 테이블을 사용하여 지정합니다. 런타임 도중 또는 이후에는 이러한 테이블을 수정할 수 없습니다. 따라서 무엇보다도 이 제한은 프로덕션 인증서를 사용하여 서명된 애플리케이션에서 코드 프로파일링을 수행할 수 없음을 의미합니다.
• 매니페스트에 지정된 DLL 내에서 DebugBreak 함수를 호출할 수 없습니다.
• DONT_RESOLVE_DLL_REFERENCES 플래그를 설정하여 LoadLibrary를 호출할 수 없습니다. 이 플래그는 로더에 가져온 모듈에 대한 바인딩을 건너뛰도록 지시하므로 가져오기 주소 테이블을 수정하게 됩니다.
• 런타임이나 이후에 /DELAYLOAD 링커 스위치를 변경하여 지연된 로드를 변경할 수 없습니다.
• 자체 버전의 Delayimp.lib 도우미 함수를 제공하여 지연된 로드를 변경할 수 없습니다.
• 정보 보호 SDK 환경이 존재하는 경우 인증된 모듈로 지연 로드된 모듈을 언로드할 수 없습니다.
• /DELAY:UNLOAD 링커 스위치를 사용하여 지연된 모듈을 언로드할 수 없습니다.

라이선스 권한의 잘못된 해석

애플리케이션에서 SDK 발급 라이선스에 명시된 권한을 잘못 해석하고 적용하는 경우 정보 소유자가 의도하지 않은 방식으로 정보를 제공할 수 있습니다. 발급 라이선스에서는 정보를 볼 수 있는 권한만 부여하는데 애플리케이션에서 사용자가 암호화되지 않은 정보를 새 미디어에 저장할 수 있도록 하는 경우를 예로 들 수 있습니다.

AIP(Azure Information Protection)

정보 보호 시스템은 몇 가지 그룹화 권한을 구성합니다. 자세한 내용은 Azure Information Protection 대한 사용 권한 구성을 참조하세요.

AIP를 통해 사용자는 정보를 해독하거나 해독하지 않을 수 있습니다. 정보에는 내재된 보호 기능이 없습니다. 사용자에게 암호를 해독할 수 있는 권한이 있으면 API에서 이를 허용합니다. 애플리케이션은 해당 정보를 암호화된 후에 관리 또는 보호할 책임이 있습니다. 애플리케이션은 정보의 무단 사용을 방지하는 해당 환경 및 인터페이스를 관리할 책임이 있습니다. 예를 들어, 라이선스가 보기 권한만 부여하는 경우 인쇄 및 복사 단추를 사용하지 않도록 설정합니다. 테스트 도구 모음에서는 애플리케이션이 인식되는 모든 라이선스 권한에 대해 올바르게 작동하지는 확인해야 합니다.

최소 표준

• XrML v.1.2 권한의 고객 구현은 XrML 웹 사이트(http://www.xrml.org)에서 사용할 수 있는 XrML 사양에 설명된 대로 이러한 권한의 정의와 일치해야 합니다. 애플리케이션과 관련된 모든 권한은 애플리케이션에 관심 있는 모든 엔터티에 대해 정의해야 합니다.
• 테스트 도구 모음 및 테스트 프로세스에서는 애플리케이션이 지원하는 권한에 대해 애플리케이션이 올바로 실행되는지 확인해야 합니다. 또한 지원되지 않는 권한으로 작동하지 않도록 확인해야 합니다.
• 게시 애플리케이션을 빌드하는 경우 사용되는 기본 권한을 설명하는 정보를 사용할 수 있도록 만들어야 합니다. 여기에는 게시 애플리케이션에서 지원되고 지원되지 않는 권한과 이러한 권한을 해석하는 방법이 포함됩니다. 또한 사용자 인터페이스에서는 개별 정보를 부여하거나 거부한 각 권한의 의미를 최종 사용자에게 명확히 설명해야 합니다.
• 애플리케이션에서 구현된 새 권한에 포함되어 요약된 모든 권한은 새로운 용어에 매핑되어야 합니다. 예를 들어 MANAGER라는 새 권한에는 요약된 권한으로서 PRINT, COPY 및 EDIT 권한이 포함될 수 있습니다.

권장 표준

현재는 해결 방법이 없습니다.

기본 표준

현재는 해결 방법이 없습니다.

다음 단계

AIP SDK를 사용하여 애플리케이션을 구현하는 것에 대한 모범 사례에는 다음 문서가 포함되어 있습니다.

• 위협 모델 및 완화 방법
• Security Attacks(보안 공격)