Microsoft 365 인증 프레임워크 개요

이 문서에서는 필요한 보안 컨트롤 목록과 ISV 및 개발자를 위한 지침을 포함하여 Microsoft 365 인증에 대한 자세한 정보를 제공합니다.

Microsoft 365 인증은 Microsoft 365 플랫폼과 통합된 앱, 추가 기능 및 지원 백 엔드 환경(앱이라고도 함)에 대한 독립적인 보안 및 개인 정보 보호 감사입니다. 통과하는 앱은 Microsoft 365 에코시스템 전체에서 Microsoft 365 인증으로 지정되며 규정 준수 중심 검색 필터 및 브랜딩을 통해 Microsoft 365 마켓플레이스에서 쉽게 찾을 수 있습니다. ISV는 이 설명서 집합 내의 전용 페이지에서 앱의 규정 준수 특성을 공유할 수 있습니다.

Microsoft 365 인증은 다음과 같은 유형의 애플리케이션에 사용할 수 있습니다.

• Microsoft 365 추가 기능(Word, Excel, Outlook, PowerPoint, OneNote, Project)
• Teams 앱
• SharePoint 솔루션
• 웹앱(SaaS)
• CoPilot 확장

중요

Microsoft 365 인증은 Microsoft 365 인증 프레임워크에 대한 앱의 보안 및 규정 준수에 대한 엄격한 검토이며 완료하려면 상당한 시간과 리소스가 필요합니다. 시작하기 전에 규정 준수 제어 프레임워크를 검토하여 앱이 적합한지 확인하세요. 질문이 있는 경우 으로 이메일을 보내 appcert@microsoft.com주세요.

용어

Microsoft 365 인증 프로그램에 참여함으로써 귀하는 이러한 추가 약관에 동의하고 Microsoft Corporation("Microsoft", "우리", "우리" 또는 "우리")과 함께 Microsoft 365 인증 프로그램에 참여하는 데 적용되는 모든 관련 설명서를 준수하는 데 동의합니다. 귀하는 본인, 회사 및/또는 기타 법인을 대신하여 본 Microsoft 365 인증 추가 조건을 수락할 권한이 있음을 당사에 대표하고 보증합니다. 당사는 언제든지 이러한 추가 약관을 변경, 수정 또는 종료할 수 있습니다. 변경 또는 수정 후 Microsoft 365 인증 프로그램에 계속 참여한다는 것은 새로운 추가 조건에 동의한다는 것을 의미합니다. 새 추가 약관에 동의하지 않거나 이러한 추가 약관을 종료하는 경우 Microsoft 365 인증 프로그램에 참여하지 않아야 합니다.

필수 구성 요소

Microsoft 365 인증을 획득하려면 먼저 앱이 다음을 완료해야 합니다.

게시자 확인 앱에 확인된 게시자가 있는 경우 앱을 게시하는 organization Microsoft에서 인증된 것으로 확인되었습니다. 앱 확인에는 확인된 Microsoft CPP(클라우드 파트너 프로그램) 계정을 사용하고 확인된 PartnerID를 앱 등록과 연결해야 합니다. 게시자 확인

Publisher Attestation 은 ISV(앱 개발자)가 중요한 데이터 처리와 같은 보안 관행에 대한 일련의 질문을 완료하는 셀프 서비스 프로세스입니다. 완료되면 앱은 Microsoft AppSource 마켓플레이스에서 특별 배딩 및 목록을 받게 됩니다.

컨트롤 조건 검토 인증을 받기 위해 모든 컨트롤을 준수해야 하는 것은 아닙니다. 그러나 이 개요 문서에서 설명하는 세 가지 보안 도메인 각각에 대해 임계값(공개되지 않음)이 적용되며 전달되어야 합니다. "하드 실패"라는 레이블이 지정된 중요한 컨트롤을 충족하지 못하면 평가가 실패합니다.

제출 시간 프레임

인증을 달성하기 위해 제출 프로세스에는 다음 두 단계가 있습니다.

1단계: 초기 문서 제출(14일 기간)

이 단계에서 ISV는 앱의 지원 환경에 대한 개요를 제공하는 설명서를 제출해야 합니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.

• 아키텍처 다이어그램/데이터 흐름
• 시스템 구성 요소 목록
• 소프트웨어 자산 인벤토리

분석가는 이 설명서를 검토하여 평가의 scope 정의합니다. ISV는 필요한 설명서를 완료하고 업로드하는 데 14일이 제공됩니다. 이 기한을 충족하지 못하면 프로세스가 지연되거나 제출에 실패할 수 있습니다.

2단계: 전체 증거 검토(60일 기간)

scope 정의되면 ISV는 증거 수집 단계로 진행됩니다. 이 단계에서는 다음을 수행합니다.

1. ISV는 scope 정의된 모든 적용 가능한 컨트롤에 대해 증거를 업로드해야 합니다.
2. 이 증거는 검토, 수정(필요한 경우) 및 최종 QA 프로세스를 거칩니다.
3. 필요한 경우 이 시간 동안 침투 테스트를 수행할 수도 있습니다.

ISV는 다음을 포함하는 첫 번째 증거 제출부터 시작하여 이 단계를 완료하는 데 60일이 걸립니다.

• 모든 컨트롤에 대한 증거 업로드
• 분석가 검토 및 피드백
• 제출된 증거에 필요한 모든 수정
• QA 프로세스 완료

최종 기한을 충족하지 못했습니다.

ISV가 60일 기간 내에 프로세스를 완료할 수 없는 경우 평가가 실패합니다. 그러나 분석가의 재량에 따라 다음과 같은 유효한 상황에서 최대 60일의 연장이 부여될 수 있습니다.

• 계절별 휴일
• 침투 테스트 지연
• 내부 변경 내용
• 제어 요구 사항을 충족하는 데 필요한 변경 내용을 구현하는 데 필요한 시간

60일의 시간 프레임이 모두 소진되면 더 이상 확장을 부여할 수 없습니다.

인증 scope

scope 환경은 앱/추가 기능이 통신할 수 있는 지원 백 엔드 시스템과 함께 앱 또는 추가 기능 코드를 제공하는 데 필요한 모든 시스템 및 인프라를 포함합니다. 적절한 세분화가 구현되고 연결된 환경이 scope 환경의 보안을 손상할 수 없는 한 scope 환경에 연결된 추가 환경도 scope 포함되어야 합니다.

참고: 이러한 환경은 기본 환경 오류 발생 시 서비스 연속성을 유지하는 데 중요할 수 있으므로 별도의 재해 복구 환경도 scope 환경에 포함되어야 합니다.

또한 원격 백업 환경은 중요한 Microsoft 데이터를 저장할 수 있으므로 scope 통합해야 합니다. 따라서 이러한 환경에 대해 적절한 보안 제어를 구현해야 합니다.

scope 시스템 구성 요소라는 용어에는 정의된 scope 환경 내에서 적극적으로 사용되는 모든 디바이스 및 시스템이 포함됩니다. 이러한 구성 요소에는 다음이 포함되지만 이에 국한되지는 않습니다.

• 웹 애플리케이션
• 서버(물리적 또는 가상, 온-프레미스 또는 클라우드에 있음)
• 스위치
• 부하 분산 장치
• 가상 인프라
• 클라우드 공급자 웹 관리 포털
• 클라우드 리소스(Virtual Machines, App Services, Storage 계정, 데이터베이스 등)

중요

공용 시스템 구성 요소는 특히 외부 위협 행위자의 공격에 취약하므로 위험이 높습니다. 일반적으로 이러한 시스템은 DMZ(비무장지대)와 같은 NSC(네트워크 보안 제어) 구현을 통해 내부 시스템 구성 요소로부터 격리되어야 합니다. DMZ의 목적은 버퍼 영역 역할을 하여 외부 시스템으로 확장된 신뢰를 제한하고 내부 시스템 및 데이터를 보호하기 위해 보안을 강화하는 것입니다. DMZ는 여전히 이상적일 수 있지만, 최신 클라우드 아키텍처는 종종 특정 배포 시나리오에 맞게 조정된 대체 보안 조치를 사용합니다.

IaaS(Infrastructure as a Service), PaaS(Platform as a Service) 및 SaaS(Software as a Service)

검토 중인 scope 환경을 지원하기 위해 IaaS 및/또는 PaaS를 사용하는 경우 클라우드 플랫폼 공급자는 인증 프로세스 전반에 걸쳐 평가된 일부 보안 제어를 담당합니다. 분석가는 PCI DSS, AOC(규정 준수 증명), ISO 27001 또는 SOC 2 Type II 보고서와 같은 외부 규정 준수 보고서를 통해 클라우드 플랫폼 공급자의 보안 모범 사례에 대한 독립적인 외부 확인을 제공해야 합니다.

배포 유형에 적용할 수 있는 보안 컨트롤 및 환경이 Microsoft 365 데이터를 처리하거나 전송하는지에 대한 자세한 내용은 부록 C를 참조하세요. 배포 유형은 다음과 같습니다.

• ISV 호스팅: 독립 소프트웨어 공급업체에서 호스트하는 애플리케이션
• IaaS 호스트: 타사 클라우드 플랫폼에서 제공하는 인프라입니다.
• PaaS/서버리스 호스트됨: 플랫폼 기반 또는 서버리스 아키텍처를 평균하는 애플리케이션입니다.
• 하이브리드 호스팅: 온-프레미스 및 클라우드 호스팅 구성 요소의 혼합입니다.
• 공유 호스팅: 여러 테넌트가 활용하는 공유 클라우드 환경입니다.

IaaS 또는 PaaS를 사용하는 경우 배포가 관련 아키텍처에 대한 예상 보안 컨트롤과 일치하는지 확인해야 합니다.

견본 추출

철저한 평가를 위해 scope 내 시스템 구성 요소의 샘플링은 운영 체제, 기본 디바이스 기능, 디바이스 유형(예: 서버, 라우터, 네트워크 보안 제어) 및 지리적 위치와 같은 요소를 고려해야 합니다. 샘플은 이러한 고려 사항에 따라 인증 프로세스 시작 시 선택됩니다. 아래 표에서는 scope 구성 요소의 모집단을 기반으로 샘플링 크기를 안내합니다.

모집단 크기	샘플
<=5	1
>5 & <10=	2
>10 & <=30	3
>30	4

이렇게 하면 다양한 구성 및 배포 모델에서 환경의 규정 준수에 대한 대표적인 평가가 보장됩니다.

참고

평가 중에 디바이스 간에 불일치가 확인되면 샘플 크기를 조정하여 환경을 적절하게 표시할 수 있습니다.

인증 프로세스 개요

Microsoft 365 인증 프로세스를 시작하려면 다음을 수행합니다.

1. 게시자 증명 파트너 센터로 이동하여 게시자 증명 양식을 작성합니다. 참고: 제출이 3개월보다 오래된 경우 검토 및 유효성 검사를 위해 다시 제출해야 합니다.

2. 파트너 센터에서 인증을 시작하려면 "인증 시작" 옵션을 선택하여 초기 문서 제출을 시작합니다. 이 단계는 인증 분석가가 앱의 아키텍처 및 Microsoft 데이터를 관리하는 방법에 따라 평가의 scope 식별하는 데 도움이 됩니다.

인증은 다음 두 기본 단계로 수행됩니다.

1. 초기 문서 제출 이 단계에서는 분석가가 앱의 디자인, 데이터 흐름 및 scope 환경을 이해하는 데 도움이 되는 주요 세부 정보를 제공합니다. 분석가는 적용 가능한 보안 제어를 결정하고 증거가 필요한 시스템 구성 요소를 간략하게 설명합니다. 전체 프로세스의 약 5%를 나타내는 이 검토를 용이하게 하려면 정확한 설명서를 제공해야 합니다.

2. 전체 증거 검토 이 단계에서는 scope 환경에 대한 보안 제어 준수를 보여주는 자세한 증거를 제출합니다. 분석가는 이 단계에서 귀하와 긴밀히 협력하여 제출을 검토, 명확히 하고 확인합니다. 이 단계는 프로세스의 나머지 부분을 수행합니다.

평가

초기 문서 제출이 승인되면 필요한 보안 컨트롤 목록이 포털에 표시됩니다. 각 컨트롤에 대한 증거를 제공하는 데 60일이 있으며, 현재 위치 및 작동 중인지 확인합니다. 분석가는 증거를 검토하고 승인하거나 추가 세부 정보 또는 수정 사항을 요청합니다.

증명

분석가가 제출을 검토하고 유효성을 검사하면 인증 결정에 대한 알림을 받게 됩니다. 인증 기준을 성공적으로 충족하는 앱에는 해당 AppSource 목록 및 관련 Microsoft Docs 페이지에 표시되는 배지가 수여됩니다. 이러한 페이지에서는 앱의 보안 및 규정 준수 특성에 대한 자세한 보고도 제공합니다.

검토 및 재인증

Microsoft 365 인증 앱은 Microsoft 표준을 지속적으로 준수하기 위해 연간 재인증을 받아야 합니다. 재인증 프로세스에는 scope 내 컨트롤을 다시 평가하여 현재 환경과 일치하는지 확인하는 작업이 포함됩니다. 중단을 방지하기 위해 인증이 만료되기 최대 90일 전에 재인증 프로세스를 시작할 수 있습니다. 인증은 이 기간 동안 유효합니다.

만료 날짜 이전에 재인증이 완료되지 않으면 인증이 해지됩니다. 결과적으로 다음이 수행됩니다.

• 앱의 인증 배지 및 브랜딩이 제거됩니다.

• ISV는 더 이상 Microsoft 365 Certified로 앱을 마케팅할 수 없습니다.

예약된 재인증 기간 이외에 앱이 크게 변경 된 경우 ISV는 Microsoft 앱 준수 프로그램에 알려 앱이 규정을 준수하는지 확인해야 합니다.

초기 문서 제출

초기 제출에는 다음 정보가 포함되어야 합니다.

설명서 개요	설명서 세부 정보
앱/추가 기능 설명	앱/추가 기능의 용도 및 기능에 대한 설명입니다. 이렇게 하면 인증 분석가가 앱/추가 기능의 기능과 용도를 잘 이해할 수 있어야 합니다.
침투 테스트 보고서	침투 테스트 보고서는 지난 12개월 이내에 완료되었습니다. 이 보고서에는 앱/추가 기능의 작업을 지원하는 추가 환경과 함께 앱/추가 배포를 지원하는 환경이 포함되어야 합니다. 참고: ISV가 현재 연간 침투 테스트를 수행하지 않는 경우 Microsoft는 인증 프로세스를 통해 펜 테스트 비용을 처리합니다.
아키텍처 다이어그램	앱의 지원 인프라에 대한 개략적인 개요를 나타내는 논리 아키텍처 다이어그램입니다. 여기에는 모든 호스팅 환경과 앱을 지원하는 지원 인프라가 포함되어야 합니다. 이 다이어그램은 인증 분석가가 scope 시스템을 이해하고 샘플링을 결정하는 데 도움이 되도록 환경 내의 다양한 지원 시스템 구성 요소를 보여 주어야 합니다. 사용되는 호스팅 환경 유형도 지정하세요. ISV Hosted, IaaS, PaaS 또는 Hybrid. 메모: SaaS가 사용되는 경우 환경 내에서 지원 서비스를 제공하는 데 사용되는 다양한 SaaS 서비스를 지정하세요.
공용 공간	지원 인프라에서 사용하는 모든 공용 IP 주소 및 URL을 자세히 설명합니다. 사용 중인 범위를 분할하기 위해 적절한 세분화가 구현되지 않은 한 환경에 할당된 전체 라우팅 가능한 IP 범위를 포함해야 합니다(적절한 분할 증거가 필요함).
데이터 흐름 다이어그램	다음을 자세히 설명하는 흐름 다이어그램:
	✓ Microsoft 365 데이터는 앱/추가 기능( EUII 및 OII 포함)을 오가는 흐름입니다.
	✓ 지원 인프라 내에서 Microsoft 365 데이터 흐름(해당하는 경우).
	✓ 데이터가 저장되는 위치와 내용, 외부 제3자에게 데이터가 전달되는 방식(제3자에 대한 세부 정보 포함) 및 공개/공용 네트워크 및 미사용 전송 시 데이터가 보호되는 방식을 강조하는 다이어그램
API 엔드포인트 세부 정보	앱에서 사용하는 모든 API 엔드포인트의 전체 목록입니다. 환경 scope 이해하는 데 도움이 되도록 환경 내에서 API 엔드포인트 위치를 제공합니다.
Microsoft API 권한	요청된 권한에 대한 근거와 함께 앱/추가 기능이 작동하도록 요청되는 권한과 함께 사용되는 모든 Microsoft API를 자세히 설명하는 설명서를 제공합니다.
데이터 스토리지 유형	다음을 설명하는 데이터 스토리지 및 처리 문서:
	✓ Microsoft 365 Data EUII 및 OII 가 수신되어 저장되는 범위까지
	✓ 데이터 보존 기간입니다.
	✓ Microsoft 365 데이터가 캡처되는 이유
	✓ Microsoft 365 데이터가 저장되는 위치(위에서 제공된 데이터 흐름 다이어그램에도 포함되어야 함).
규정 준수 확인	게시자 증명 제출에 포함되거나 Microsoft 365 인증 보안 제어를 검토할 때 고려할 외부 보안 프레임워크에 대한 지원 설명서입니다. 현재 다음 네 가지가 지원됩니다.
	✓ PCI DSS 준수 증명(AOC).
	✓ SOC 2 유형 I / 유형 II 보고서.
	✓ ISMS / IEC - 1S0/IEC 27001 SoA(적용 가능성 설명) 및 인증.
	✓ FedRAMP FedRAMP 권한 부여 패키지 및 FedRAMP 준비 평가 보고서.
웹 종속성	현재 실행 중인 버전이 있는 앱에서 사용하는 모든 종속성을 나열하는 설명서입니다.
소프트웨어 인벤토리	버전과 함께 scope 환경 내에서 사용되는 모든 소프트웨어를 포함하는 최신 소프트웨어 인벤토리입니다.
하드웨어 인벤토리	지원 인프라에서 사용하는 최신 하드웨어 인벤토리입니다. 평가 단계를 수행할 때 샘플링에 도움이 되는 데 사용됩니다. 사용자 환경에 PaaS가 포함된 경우 사용된 클라우드 서비스/리소스에 대한 세부 정보를 제공합니다.

증거 수집 및 평가 활동

인증 분석가는 정의된 샘플 집합 내의 모든 시스템 구성 요소에서 증거를 검토해야 합니다. 평가 프로세스를 지원하는 데 필요한 증거 유형에는 다음 중 어느 것 또는 전부가 포함됩니다.

증거 수집

• 초기 설명서 제출 가이드 내에서 강조 표시된 초기 설명서
• 정책 문서
• 문서 처리
• 시스템 구성 설정
• 티켓 변경
• 컨트롤 레코드 변경
• 시스템 보고서
• 모임 시간(분)
• 계약/계약

평가 프로세스를 완료하는 데 필요한 증거를 수집하는 데 다양한 방법이 사용됩니다. 이 증거 수집은 다음과 같은 형식일 수 있습니다.

• 문서
• 스크린샷
• 인터뷰
• 화면 공유

사용된 증거 수집 기술은 평가 프로세스 중에 결정됩니다. 제출에 필요한 증거 유형에 대한 구체적인 예는 샘플 증거 가이드를 참조하세요.

평가 활동

인증 분석가는 제출된 증거를 검토하여 Microsoft 365 인증에 필요한 모든 컨트롤이 충족되는지 확인합니다. 프로세스를 신속하게 처리하려면 초기 설명서 제출에 지정된 모든 설명서 가 완료되고 미리 제공되었는지 확인합니다.

검토하는 동안 분석가는 초기 제출 및 게시자 증명의 증거를 평가합니다. 그들은 조사, 샘플링 측의 scope 및 추가 증거가 필요한지 여부를 결정합니다. 분석가는 수집된 모든 정보를 사용하여 Microsoft 365 인증 사양 준수를 평가하고 앱이 정의된 컨트롤을 충족하는지 여부를 결정합니다.

앱 인증 기준

앱과 인프라를 지원하고 지원 설명서는 다음 세 가지 보안 도메인에서 평가됩니다.

1. 애플리케이션 보안
2. 운영 보안/보안 배포
3. 데이터 처리 보안 및 개인 정보

이러한 각 보안 도메인에는 평가 프로세스의 일부로 평가될 하나 이상의 요구 사항을 포함하는 특정 키 컨트롤이 포함됩니다. Microsoft 365 인증이 모든 규모의 개발자에게 포함되도록 하기 위해 각 보안 도메인은 점수 매기기 시스템을 사용하여 평가되어 각 도메인의 전체 점수를 결정합니다. 각 Microsoft 365 인증 컨트롤에 대한 점수는 해당 컨트롤이 구현되지 않을 경우의 인식된 위험에 따라 1(낮음)에서 3(높음) 사이에 할당됩니다. 각 보안 도메인에는 통과로 간주되는 최소 백분율 표시가 있습니다. 특정 요인으로 인해 자동 오류가 발생합니다(포함).

• 최소 권한 원칙(PoLP)을 준수하지 않는 API 권한 사용

• 필요한 경우 침투 테스트 보고서가 부족합니다.

• 맬웨어 방지 방어가 없는 경우

• 관리 액세스에 대한 MFA(다단계 인증)를 구현하지 못했습니다.

• 패치 프로세스가 없거나 부족합니다.

• 규정 준수 GDPR 개인 정보 보호 알림이 부족합니다.

애플리케이션 보안

애플리케이션 보안 도메인은 다음 영역을 평가합니다.

• GraphAPI 권한 유효성 검사
• 침투 테스트

GraphAPI 권한 유효성 검사

이렇게 하면 앱 또는 추가 기능이 과도하게 또는 지나치게 허용된 권한을 요청하지 않습니다. 인증 분석가는 앱에서 요청한 권한을 수동으로 검토하고 게시자 증명 제출에 대해 교차 검사.

목표는 요청된 권한이 최소 권한 원칙을 준수하는지 확인하는 것입니다. 분석가가 앱이 필요한 권한을 초과하는 권한을 요청하는 경우 ISV와 협력하여 이러한 권한에 대한 비즈니스 근거의 유효성을 검사합니다. 요청된 권한과 게시자 증명 제출 간에 식별된 모든 불일치는 이 검토 중에 해결되고 해결되어야 합니다.

침투 테스트

침투 테스트는 앱 또는 추가 기능 및 지원 환경과 관련된 위험을 식별하고 완화하는 데 중요합니다. 이렇게 하면 앱이 고객에게 적절한 보안 보증을 제공합니다.

침투 테스트는 Microsoft에서 호스팅하거나 관리하지 않는 외부 서비스에 연결하는 모든 앱에 필수 입니다. 앱이 GraphAPI와 같은 Microsoft 서비스만 사용하는 독립 실행형 솔루션으로 배포되는 경우 침투 테스트가 필요하지 않을 수 있습니다. 그러나 Azure에서 호스트되는 앱은 scope 환경의 보안을 보장하기 위해 침투 테스트를 거쳐야 합니다.

침투 테스트 scope

인프라 테스트: 내부 및 외부 인프라의 경우 앱 또는 추가 기능을 지원하는 라이브 프로덕션 환경에서 침투 테스트를 수행해야 합니다. 여기에는 다음이 포함됩니다.

앱 또는 추가 기능의 코드가 호스트되는 환경(일반적으로 매니페스트 파일에서 참조됨)

앱/추가 기능과 상호 작용하거나 앱/추가 기능의 작업을 지원하는 추가 환경(예: 앱/추가 기능이 Microsoft 365 외부의 다른 웹 애플리케이션과 통신하는 경우).

침투 테스트를 위한 scope 정의할 때는 scope 환경의 보안에 영향을 미칠 수 있는 연결된 모든 시스템 또는 환경을 포함하는 것이 중요합니다.

권장 사항

웹 애플리케이션 침투 테스트: 라이브 프로덕션 환경에 대해 웹앱 침투 테스트를 직접 수행하는 것이 좋습니다. 그러나 테스트/UAT(사용자 승인 테스트) 환경에서 웹앱 테스트를 수행할 수 있습니다. 침투 테스트 보고서에서 테스트 시 프로덕션에서 동일한 코드베이스가 사용되고 있음을 확인하면 됩니다.

세분화 유효성 검사: 세분화 기술을 사용하여 scope 내 환경을 다른 환경과 격리하는 경우 침투 테스트 보고서는 이러한 세분화 기술의 유효성을 검사해야 합니다. 이렇게 하면 세분화 프로세스를 통해 취약성이 발생하지 않습니다.

침투 테스트 요구 사항

침투 테스트 보고서를 검토하여 아래 컨트롤에 설명된 다음 자동 실패 조건을 충족하는 취약성이 없는지 확인합니다.

조건 유형	침투 테스트 컨트롤
일반 조건	웹 애플리케이션(인증 및 인증되지 않음) 및 내부(해당하는 경우) 및 외부 인프라 침투 테스트는 매년(12개월마다) 수행해야 하며 평판이 좋은 독립 회사에서 수행해야 합니다 .
	확인된 위험 및 고위험 취약성의 수정은 침투 테스트가 끝난 후 1개월 이내에 또는 ISV의 문서화된 패치 프로세스에 따라 더 빨리 완료 해야 합니다 .
	전체 외부 공간(IP 주소, URL, API 엔드포인트 등) 침투 테스트 scope 포함되어야 하며 침투 테스트 보고서에 명확하게 문서화되어야 합니다.
	환경이 PaaS에 부합하지 않는 한 전체 내부 네트워크는 침투 테스트 scope 포함되어야 하며 침투 테스트 보고서 내에 명확하게 문서화되어야 합니다.
	웹 애플리케이션 침투 테스트에는 모든 취약성 클래스가 포함되어 야 합니다 . 예를 들어 최신 OWASP 상위 10개 또는 SANS 상위 25개 CWE가 있습니다. 침투 테스트 보고서 내에 자세히 설명되어 있는 것이 좋습니다. 그렇지 않으면 설명하기가 어렵습니다.
	자동 실패로 간주되는 위험 및 고위험 취약성 또는 취약성은 침투 테스트 회사에서 다시 테스트하고 침투 테스트 보고서 내에서 수정된 것으로 명확하게 강조 표시 되어야 합니다 .
자동 실패 조건:	지원되지 않는 운영 체제 또는 지원되지 않는 JavaScript 라이브러리가 있습니다.
	기본, 열거 가능 또는 추측 가능한 관리 계정의 존재
	SQL 삽입 위험이 있습니다.
	사이트 간 스크립팅이 있습니다.
	디렉터리 통과(파일 경로) 취약성이 있습니다.
	HTTP 취약성(예: 헤더 응답 분할, 밀수 요청 및 비동기 공격)이 있습니다.
	소스 코드 공개( LFI 포함)의 존재.
	CVSS 패치 관리 지침에 정의된 모든 중요 또는 높은 점수입니다.
	대량의 EUII 또는 OUI를 손상하기 위해 쉽게 악용될 수 있는 중요한 기술적 취약성입니다.

중요

보고서는 위의 침투 테스트 요구 사항 섹션에 자세히 설명된 모든 것을 입증할 수 있는 충분한 보증을 제공할 수 있어야 합니다.

무료 침투 테스트 요구 사항 및 규칙

현재 침투 테스트를 수행하지 않는 ISV의 경우 Microsoft는 Microsoft 365 인증 프로세스의 일부로 무료 침투 테스트 서비스를 제공합니다. 이 서비스는 최대 12일간의 수동 테스트를 처리하며, ISV의 책임 이외에 필요한 일의 추가 비용이 있습니다.

주요 요구 사항

사전 테스트 요구 사항: ISV는 침투 테스트를 예약하기 전에 증거를 제출하고 scope 내 컨트롤의 50%에 대한 승인을 받아야 합니다.

테스트 보고서: Microsoft 365 인증과 함께 이 보고서를 사용하여 환경이 안전하다는 것을 고객에게 입증할 수 있습니다.

취약성 수정: ISV는 인증을 받기 전에 테스트 중에 식별된 모든 취약성을 해결할 책임이 있습니다. 그러나 클린 보고서는 필요하지 않으며 취약성이 적절하게 해결되었다는 확인 증거만 필요합니다.

추가 고려 사항

침투 테스트가 준비되면 ISV는 일정 조정 또는 취소와 관련된 모든 수수료를 처리해야 합니다.

요금 일정 조정	지급액 비율
예약된 시작 날짜 30일 전에 다시 예약된 요청이 수신되었습니다.	0% 지불
예약된 시작 날짜 8~30일 전에 다시 예약된 요청이 수신되었습니다.	25% 지불
회사 재예약 날짜로 예약된 시작 날짜 2~7일 전에 받은 요청을 다시 예약합니다.	50% 지급
다시 예약 요청이 시작 날짜 2일 전에 수신되었습니다.	100% 지급

취소 수수료 기간	지급액 비율
예약된 시작 날짜 30일 전에 취소 요청이 수신되었습니다.	25% 지불
예약된 시작 날짜 8~30일 전에 취소 요청을 받았습니다.	50% 지급
예약된 시작 날짜 7일 전에 취소 요청이 수신되었습니다.	90% 지급

운영 보안

이 도메인은 보안 모범 사례를 사용하여 앱의 지원 인프라 및 배포 프로세스의 맞춤을 측정합니다.

컨트롤

컨트롤 패밀리	컨트롤
인식 교육	organization 새로운 사용자를 위한 초기 교육의 일환으로 또는 정보 시스템 변경에 필요한 경우 정보 시스템 사용자(관리자, 고위 임원 및 계약자 포함)에게 확립된 보안 인식 교육을 제공한다는 증거를 제공합니다.
	인식 학습의 organization 정의 빈도에 대한 증거를 제공합니다.
	organization 정의 빈도를 통해 개별 학습 레코드를 유지하면서 개별 정보 시스템 보안 인식 활동에 대한 설명서 및 모니터링의 증거를 제공합니다.
맬웨어 보호 - 바이러스 백신	맬웨어 방지 솔루션이 모든 샘플링된 시스템 구성 요소에서 활성화되고 다음 조건을 충족하도록 구성되었다는 증거를 제공합니다.
	바이러스 백신을 사용하는 경우 액세스 시 검사가 활성화되고 서명이 1일 이내에 최신 상태이며 맬웨어가 검색되면 자동으로 맬웨어 또는 경고 및 격리를 차단합니다.
	또는 EDR/NGAV(엔드포인트 검색 및 응답/차세대 바이러스 백신)가 수행되고 감사 로그가 생성되며 지속적으로 최신 상태로 유지되고 자체 학습 기능이 있습니다.
	EDR/NGAV이면 알려진 맬웨어를 차단하고 매크로 동작을 기반으로 하는 새로운 맬웨어 변형을 식별하고 차단하며 전체 안전 목록 기능을 갖습니다.
맬웨어 보호 - 애플리케이션 제어	비즈니스 정당성이 있는 승인된 소프트웨어/애플리케이션 목록이 존재하며 최신 상태라는 입증 가능한 증거를 제공합니다.
	각 애플리케이션이 승인 프로세스를 거치고 배포 전에 로그오프합니다.
	해당 애플리케이션 제어 기술은 문서화된 대로 샘플링된 모든 시스템 구성 요소에서 활성, 사용 및 구성됩니다.
패치 관리 - 패치 및 위험 순위	새 보안 취약성을 식별하고 위험 점수를 할당하는 방법을 제어하는 정책 설명서를 제공합니다.
	새 보안 취약성이 식별되는 방법에 대한 증거를 제공합니다.
	모든 취약성이 식별되면 위험 순위가 할당됨을 보여 주는 증거를 제공합니다.
	샘플링된 모든 시스템 구성 요소가 조직에서 정의한 패치 기간에 따라 패치되고 지원되지 않는 운영 체제 및 소프트웨어 구성 요소가 사용되지 않는다는 증거를 제공합니다. 해당하는 경우 서버리스 기술 또는 PaaS를 사용하는 경우 코드 베이스를 포함하거나 IaaS를 사용하는 경우 인프라와 코드 베이스를 모두 포함해야 합니다.
	패치 기간 지침(예: "위험 - 14일 이내, 높음 – 30일 이내, 중간 – 60일 이내" )
취약성 검사	분기별 인프라 및 웹 애플리케이션 취약성 검사 보고서를 제공합니다. 전체 공용 공간(IP 주소 및 URL) 및 내부 IP 범위에 대해 검사를 수행해야 합니다.
	취약성 검사 중에 식별된 취약성의 수정이 문서화된 패치 기간에 따라 패치된다는 입증 가능한 증거를 제공합니다.
NSC(네트워크 보안 컨트롤)	NSC(네트워크 보안 제어)가 scope 환경 경계에 설치되고 경계 네트워크와 내부 네트워크 사이에 설치되어 있다는 증거를 제공합니다.
	하이브리드, 온-프레미스, IaaS는 경계 네트워크에서 모든 공용 액세스가 종료된다는 증거도 제공합니다.
	모든 NSC(네트워크 보안 제어)가 규칙 기반 내에서 명시적으로 정의되지 않은 트래픽을 삭제하도록 구성되어 있고 NSC(네트워크 보안 제어) 규칙 검토가 적어도 6개월마다 수행되는지 확인합니다.
컨트롤 변경	프로덕션 환경에 도입된 변경 내용이 변경의 영향, 백아웃 절차의 세부 정보, 수행할 테스트, 승인된 담당자의 검토 및 승인을 포함하는 문서화된 변경 요청을 통해 구현된다는 증거를 제공합니다.
	개발 및 테스트/스테이징 환경이 프로덕션 환경으로부터 의무 분리를 적용하고, 업무 분리가 액세스 제어를 통해 적용되고, 중요한 프로덕션 데이터가 개발 또는 테스트/스테이징 환경 내에서 사용되지 않도록 별도의 환경이 존재한다는 증거를 제공합니다.
보안 소프트웨어 개발/배포	보안 소프트웨어 개발을 지원하고 보안 코딩에 대한 업계 표준 및/또는 모범 사례를 포함하는 정책 및 절차를 제공합니다. OWASP(Open Web Application Security Project) Top 10 또는 SysAdmin, AUDIT, Network and Security(SANS) Top 25 CWE(Common Weakness Enumeration)와 같은
	코드 리포지토리가 보호된다는 증거 제공: 모든 코드 변경은 기본 분기와 병합되기 전에 두 번째 검토자가 검토 및 승인 프로세스를 거치고, 적절한 액세스 제어가 적용되고, 모든 액세스는 MFA(다단계 인증)를 통해 적용됩니다.
	프로덕션 환경에 적용된 모든 릴리스가 배포 전에 검토 및 승인되었다는 증거를 제공합니다.
계정 관리	샘플링된 시스템 구성 요소에서 기본 자격 증명이 비활성화, 제거 또는 변경되었다는 증거를 제공합니다.
	서비스 계정을 보호(강화)하기 위한 프로세스가 마련되어 있으며 이 프로세스가 수행되었다는 증거를 제공합니다.
	고유한 사용자 계정이 모든 사용자에게 발급되고, 사용자 최소 권한 원칙이 환경 내에서 준수되고 있으며, 강력한 암호/암호 정책 또는 기타 적절한 완화가 이루어지고, 프로세스가 마련되어 있으며, 3개월 이내에 사용되지 않는 계정을 사용하지 않도록 설정하거나 삭제하기 위해 적어도 3개월마다 수행된다는 증거를 제공합니다.
	모든 코드 리포지토리 및 클라우드 관리 인터페이스에 대한 액세스를 포함하여 모든 원격 액세스 연결 및 모든 비 콘솔 관리 인터페이스에 대해 MFA가 구성되어 있는지 확인합니다.
보안 이벤트 로깅, 검토 및 경고	90일의 보안 이벤트 로그가 유지되는 상태에서 최소 30일 분량의 보안 이벤트 로깅 데이터를 즉시 사용할 수 있다는 증거를 제공합니다.
	로그가 주기적으로 검토되고 있으며 검토 프로세스 중에 식별된 잠재적인 보안 이벤트/변칙이 조사 및 해결된다는 증거를 제공합니다.
	권한 있는 계정 생성/수정, 권한 있는/높은 위험 활동 또는 작업, 맬웨어 이벤트, 이벤트 로그 변조, IDPS /WAF 이벤트 등 해당되는 보안 이벤트에 대한 조사를 위해 경고가 트리거되도록 경고 규칙이 구성되었다는 증거를 제공합니다. (구성된 경우)
정보 위험 관리	비준된 공식 정보 보안 위험 관리 정책/프로세스가 문서화되고 설정되었다는 증거를 제공합니다.
	공식적인 회사 차원의 정보 보안 위험 평가가 적어도 매년 수행된다는 증거를 제공합니다.
	또는 대상 위험 분석의 경우: 기존의 제어 또는 업계 모범 사례가 없는 모든 instance 대해 대상 위험 분석을 최소 12개월마다 문서화하고 수행합니다. 여기서 디자인/기술적 제한으로 인해 환경에 취약성이 도입되거나 사용자와 데이터가 위험에 노출될 위험이 있습니다. 손상의 의심 또는 확인 시
	정보 보안 위험 평가에는 영향을 받는 시스템 구성 요소 또는 리소스, 위협 및 취약성 또는 이와 동등한 영향 및 가능성 행렬 또는 이와 동등한 위험 레지스터/위험 처리 계획 생성이 포함되는지 확인합니다.
	공급업체 및 비즈니스 파트너와 관련된 위험을 평가하고 관리하는 위험 관리 프로세스가 마련되어 있으며 내부 제어 시스템에 영향을 줄 수 있는 변경 내용과 위험을 식별하고 평가할 수 있다는 증거를 제공합니다.
보안 인시던트 대응	비준된 IRP(보안 인시던트 대응 계획/절차)를 제공합니다.
	organization 인시던트에 대응하는 방법을 간략하게 설명하고, 유지 관리 방법을 보여 줍니다. 여기에는 연락처 정보, 인시던트 중 내부 통신 계획 및 주요 이해 관계자, 결제 브랜드 및 취득자, 규제 기관(예: GDPR의 경우 72시간), 감독 기관과 같은 관련 당사자에 대한 외부 통신을 포함한 인시던트 대응 팀의 세부 정보가 포함되어 있음을 보여 줍니다. 인시던트 유형에 따라 인시던트 분류, 포함, 완화, 복구 및 정상 비즈니스 운영으로 복귀와 같은 활동에 대한 단계뿐만 아니라 이사, 고객
	인시던트 대응 팀의 모든 구성원이 인시던트에 대응할 수 있는 연간 교육을 받았다는 증거를 제공합니다.
	인시던트 대응 전략 및 지원 설명서가 테이블 상위 연습에서 배운 교훈, 인시던트 대응에서 배운 교훈, 조직 변경 내용을 기반으로 검토 및 업데이트된다는 증거를 제공합니다.
비즈니스 연속성 계획 및 재해 복구 계획	비즈니스 연속성 계획을 간략하게 설명하는 설명서가 존재하고 유지 관리된다는 증거를 제공합니다.
	비즈니스 연속성 계획에서 관련 담당자와 관련 담당자의 역할 및 책임에 대해 자세히 설명합니다. 관련 비상 요구 사항 및 목표, 시스템 및 데이터 백업 절차, 구성 및 예약/보존, 복구 우선 순위 및 기간 목표, 중요한 정보 시스템, 비즈니스 기능 및 서비스를 반환하기 위해 수행해야 하는 작업, 단계 및 절차를 자세히 설명하는 대체 계획 예기치 않은 예약되지 않은 중단, 최종 전체 시스템 복원을 포함하고 원래 상태로 돌아가는 설정된 프로세스입니다.
	설명서가 존재하고 유지 관리되며 재해 복구 계획을 간략하게 설명하고 최소한 직원 및 해당 역할, 책임 및 에스컬레이션 프로세스, 중요한 비즈니스 기능 및 서비스를 지원하는 데 사용되는 정보 시스템의 인벤토리, 시스템 및 데이터 백업 절차 및 구성, 중요한 정보 시스템 및 데이터를 운영으로 복원하기 위한 조치 및 절차를 자세히 설명하는 복구 계획을 제공합니다.
	비즈니스 연속성 계획 및 재해 복구 계획이 적어도 12개월마다 검토되어 불리한 상황에서 유효하고 효과적인 상태를 유지한다는 증거를 제공합니다.
	계획의 연간 검토를 기반으로 비즈니스 연속성 계획이 업데이트되고, 비상 계획에 할당된 역할 및 책임에 대한 교육을 받는 모든 관련 담당자, 비즈니스 연속성 또는 재해 복구 연습을 통해 계획/s가 테스트되고, 연습 또는 조직 변경에서 배운 교훈을 포함하여 테스트 결과가 문서화된다는 증거를 제공합니다.

데이터 처리 보안 및 개인 정보

데이터 보안을 보장하려면 애플리케이션 사용자, 중간 서비스 및 ISV 시스템 간의 전송 중인 모든 데이터는 TLS(전송 계층 보안) 연결을 사용하여 암호화해야 합니다. 최소한 TLS 1.2가 필요하며 TLS 1.3 이상을 강력하게 권장합니다. 자세한 내용은 부록 A를 참조하세요.

Microsoft 365 데이터를 검색하거나 저장하는 애플리케이션의 경우 데이터 스토리지 암호화 체계를 구현해야 합니다. 부 록 B에 설명된 사양과 일치해야 합니다.

컨트롤

컨트롤 패밀리	컨트롤
전송 중인 데이터	TLS 구성이 TLS 프로필 구성 요구 사항 내에서 TLS1.2 이상이며 신뢰할 수 있는 키 및 인증서의 인벤토리를 유지하고 유지 관리한다는 증거를 제공합니다.
	증거를 제공하면 압축 비율 정보 유출을 방지하기 위해 웹 요청을 처리하는 모든 공용 서비스에 대해 TLS 압축이 사용하지 않도록 설정되어 있으며 TLS HSTS는 모든 사이트에서 180일로 사용하도록 설정되고 구성됩니다.
미사용 데이터	암호화 키 크기가 256비트 이상인 AES(Advanced Encryption Standard), RSA 및 Twofish와 같은 암호화 알고리즘을 사용하여 미사용 데이터가 암호화 프로필 요구 사항에 따라 암호화된다는 증거를 제공합니다.
데이터 보존, 백업 및 삭제	승인된 데이터 보존 기간이 공식적으로 설정되고 문서화되었다는 증거를 제공합니다.
	이전 컨트롤에서 설명한 대로 정의된 보존 기간 동안만 데이터가 보존된다는 증거를 제공합니다.
	보존 기간 후에 데이터를 안전하게 삭제하기 위한 프로세스가 마련되어 있다는 증거를 제공합니다.
	자동화된 백업 시스템이 설치되어 있고 예약된 시간에 백업을 수행하도록 구성되었다는 증거를 제공합니다.
	백업 예약 절차에 따라 증거 백업 정보를 테스트하고 주기적으로 복원하여 데이터의 안정성과 무결성을 확인합니다.
	백업/시스템 스냅샷이 무단 액세스에 대해 보호되고 백업 데이터의 기밀성, 무결성 및 가용성을 보장하기 위해 적절한 액세스 제어 및 보호 메커니즘(즉, 변경할 수 없는 백업)이 구현된다는 증거를 제공합니다.
데이터 액세스 관리	데이터 및/또는 암호화 키에 액세스할 수 있는 사용자 목록이 유지 관리된다는 증거를 제공합니다. 각 사용자에 대한 비즈니스 근거 및 확인을 포함하여 이 사용자 목록은 해당 작업 기능에 필요한 액세스 권한에 따라 공식적으로 승인되었으며 사용자는 승인에 설명된 권한으로 구성됩니다.
	데이터가 공유되는 모든 제3자 목록이 유지되고 데이터를 소비하는 모든 타사와 데이터 공유 계약이 체결되었다는 증거를 제공합니다.
개인 정보	organization 개인 정보 관리 노력이 시스템 기밀성 및 무결성을 위해 유지 관리되는 방식에 대한 정책 또는 다른 형태의 설명서/컴퓨터화된 시스템을 통해 리더십 약정을 보유하는 PIM(개인 정보 관리) 시스템을 설정, 구현 및 유지 관리하나요? PII 프로세서 및 컨트롤러를 포함하여 시스템을 유지 관리하는 각 사용자의 역할, 책임 및 권한을 결정합니다.
	PII 최소화가 이루어지고 있는지 확인하는 프로세스의 증거를 제공하고, PII 식별 해제 및 삭제는 처리 기간이 끝날 때 수행되고 있으며, 기밀성을 포함한 PII 전송에 대한 제어가 마련되어 있으며, 한 국가/지역에서 다른 지역으로 PII를 전송한 기록은 이에 대한 명시적인 동의를 가지고 존재합니다.
GDPR	데이터 주체가 SAR을 발생시킬 수 있고, ISV가 SAR 요청에 응답할 때 데이터 주체 데이터의 모든 위치를 식별할 수 있으며, SAR을 통해 데이터 제거를 요청하는 클라이언트가 해당 기간 동안 롤링 백업이 제거됨에 따라 제거할 수 있는 백업 보존 기간이 있다는 증거를 제공합니다(가장 오래된 백업 삭제/다시 작성 수명 주기).
	조직 세부 정보(이름, 주소 및 기타 개인 식별 정보), 처리되는 개인 데이터 유형, 개인 데이터의 보존 기간, 개인 데이터 처리의 적법성, 데이터 주체 권한 등 필요한 모든 요소를 포함해야 하는 개인 정보 보호 알림을 제공합니다. 포함: 데이터 주체의 권리, 정보 제공권, 데이터 주체에 의한 액세스 권한, 삭제 권리, 처리 제한, 데이터 이식성 권리, 이의 제기 권리, 프로파일링을 포함한 자동화된 의사 결정과 관련된 권리.
HIPAA	증명 정보 제공: 직원, 계약자, 공급업체 등에 대한 organization 내에서 HIPAA 및 HIPAA 처리를 위한 정책이 있습니다. organization ePH의 기밀성, 무결성 및 가용성을 보장하는지 확인합니다.
	사용자 확인: 개인 정보 보호 규칙에서 허용되지 않는 이러한 정보의 합리적으로 예상되는 사용 또는 공개에 대한 보호를 제공하고 직원의 보안 규칙을 준수해야 합니다. 164.308(a)(7)(ii)(A) 및 164.308(a)(7)(ii)(B) 미만의 데이터 백업 및 재해 복구 계획을 제공합니다.

선택적 외부 규정 준수 프레임워크 검토

organization ISO 27001, PCI DSS, FedRAMP 또는 SOC 2 유형 2와 같은 외부 보안 프레임워크를 이미 준수하는 경우 이러한 인증을 활용하여 Microsoft 365 인증 컨트롤 중 일부를 충족하도록 선택할 수 있습니다. 분석가는 기존 외부 보안 프레임워크를 Microsoft 365 인증 요구 사항에 맞추는 것을 목표로 합니다.

그러나 지원 설명서에서 Microsoft 365 인증 컨트롤이 외부 프레임워크의 감사 또는 평가의 일부로 명시적으로 평가되었음을 입증하지 못하는 경우 이러한 컨트롤이 있는지 확인하기 위해 추가 증거를 제공해야 합니다.

설명서 요구 사항

설명서는 Microsoft 365 인증에 대한 scope 환경이 영원한 보안 프레임워크의 scope 포함되어 있음을 명확하게 보여 주어야 합니다. 이러한 프레임워크의 유효성 검사는 신뢰할 수 있는 공인 제3자 감사자가 발급한 유효한 인증의 증거를 수락하여 이행됩니다.

이러한 제3자 감사자는 다음과 같은 국제 인증 기관의 구성원이어야 합니다.

• ISO 27001에 대한 인증 및 적합성 표준

• PCI DSS에 대한 QSA(품질 보안 평가자)

자세한 내용은 인증과 관련된 외부 프레임워크에 대한 특정 지침 및 표준을 참조하세요.

아래 표에서는 유효성 검사 프로세스의 일부로 인증 분석가가 허용하는 필수 프레임워크 및 설명서를 간략하게 설명합니다.

표준	요구 사항
ISO 27001	SOA( 적용성 명세서)의 공개 버전과 발급된 ISO 27001 인증서의 복사본이 필요합니다. SOA는 114개의 정보 보안 컨트롤 각각에 대한 사용자의 위치를 요약하고 ISO 27001 인증서에 만족스럽게 자세히 설명되지 않은 컨트롤 제외를 식별하는 데 사용됩니다. 공용 버전의 SOA를 검토하여 확인할 수 없는 경우 ISO 27001을 사용하여 Microsoft 365 인증 보안 컨트롤의 유효성을 검사하는 경우 분석가가 전체 SOA에 액세스해야 할 수 있습니다. 분석가는 ISO 27001 평가 활동의 scope 유효성을 검사하는 것 외에도 위에서 설명한 대로 감사 회사의 유효성을 확인합니다.
PCI DSS	scope 내 애플리케이션 및 시스템 구성 요소를 명확하게 식별하는 유효한 AOC(수준 1 준수 증명) 문서를 제공해야 합니다. 자체 평가 AOC는 보안 모범 사례를 충족하는 증거로 받아들여 지지 않습니다 . AOC는 PCI DSS 평가의 일부로 평가 및 확인된 Microsoft 365 인증 사양 컨트롤을 결정하는 데 사용됩니다.
SOC 2	SOC 2(형식 II) 보고서는 이 Microsoft 365 인증 프레임워크 내의 평가 컨트롤을 준수하는 증거로 사용하려면 최신 보고서(지난 15개월 이내에 발행되고 지난 27개월 이내에 시작된 선언된 기간)여야 합니다.
FedRAMP	FedRAMP(연방 위험 및 권한 부여 관리 프로그램)는 2011년에 설립된 미국 연방 정부 차원의 프로그램입니다. 클라우드 제품 및 서비스에 대한 보안 평가, 권한 부여 및 지속적인 모니터링에 대한 표준화된 접근 방식을 제공합니다.

틀	추가 고려 사항
ISO 27001	부록 C: Evidence 컬렉션 – ISO 27001의 델타입니다.
PCI DSS	부록 D: Evidence 컬렉션 – PCI DSS에 대한 델타입니다.
SOC 2	부록 E: Evidence 컬렉션 – SOC 2의 델타입니다.

참고

외부 보안 표준 또는 프레임워크를 특정 Microsoft 365 인증 컨트롤을 충족하기 위한 지원 증거로 제출할 수 있지만 Microsoft 365 인증을 얻으려면 별도의 평가가 필요합니다. Microsoft 365 인증을 획득한다고 해서 앱이 이러한 외부 프레임워크에 대한 감사를 완전히 통과했음을 의미하지는 않습니다. Microsoft 365 인증 사양은 이러한 프레임워크에서 파생된 특정 컨트롤 하위 집합에 중점을 두어 Microsoft에 앱의 보안 상태와 관련하여 더 높은 수준의 보증을 제공합니다.

외부 규정 준수 프레임워크를 사용하기 위한 요구 사항

외부 규정 준수 프레임워크를 사용하기 위한 요구 사항

scope 환경 및 지원되는 모든 비즈니스 프로세스는 지원되는 외부 보안 규정 준수 프레임워크의 scope 포함되어야 합니다. 이러한 내용은 제공된 설명서에 명확하게 문서화되어야 합니다.

외부 보안 규정 준수 프레임워크는 최신 상태여야 합니다. 즉, 지난 12개월 이내에 평가해야 합니다(또는 지원 증거를 사용하여 진행 중인 재평가를 확인할 수 있는 경우 15개월).

외부 보안 규정 준수 평가는 독립적인 공인 회사에서 수행해야 합니다.

외부 프레임워크 유효성 검사 조건

SOC 2 유형 2 평가

• SOC 2 보고서는 형식 2 보고서여야 합니다.
• SOC 2 감사에는 평가 중인 M365 환경이 포함되어야 합니다.
• SOC 2 감사는 지난 12개월 이내에 완료되어야 합니다.
• 컨트롤은 형식 2 보고서에 필요한 대로 적절하게 표시되고 올바르게 설계되어야 합니다.
• SOC 2 감사는 자격을 갖춘 외부 제3자가 수행해야 합니다.
• 테스트 절차는 보안 제어가 제자리에 있고 감사자가 제대로 유효성을 검사하고 있는지 확인해야 합니다.

ISO 27001 평가

• ISO 27001 감사에는 이 M365 평가에 지정된 환경이 포함되어야 합니다.
• ISO 27001 인증서는 최신 상태여야 하며 엔터티에 적용할 수 있어야 합니다.
• ISO 27001 평가는 공인된 외부 타사에 의해 수행되어야 합니다(내부 ISO 27001 감사는 허용되지 않음).
• ISO 27001 평가는 지난 12개월 이내에 완료해야 합니다.

PCI DSS 평가

• AOC 문서는 평가되는 M365 환경을 명확하게 정의해야 합니다.
• AOC는 날짜여야 합니다.
• AOC는 QSA 및 엔터티에서 로그오프해야 합니다.

자세히 알아보기

• 게시자 증명이란?
• Microsoft 365 인증을 받는 방법