다음을 통해 공유

Microsoft 365 인증 프레임워크 개요

  • 아티클

이 문서에서는 Microsoft 365 인증 보안 제어 목록과 Microsoft 365 인증을 받는 ISV 및 개발자에 대한 지원을 포함하여 자세한 정보를 제공합니다.

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

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

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

중요

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를 앱 등록과 연결해야 합니다. 게시자 확인

게시자 증명 은 ISV가 앱의 보안 및 데이터 처리 관행에 대한 일련의 질문에 답변하는 셀프 서비스 프로세스입니다. 앱은 Microsoft 파트너 센터에서 게시자로 테스트하고 완료 시 Microsoft AppSource 마켓플레이스에서 배딩 및 전용 필터를 받을 수 있습니다.

컨트롤 조건 검토 인증을 받기 위해 모든 컨트롤을 준수할 필요는 없습니다. 그러나 이 개요 문서에서 설명하는 세 가지 보안 도메인 각각에 대해 임계값(공개되지 않음)이 적용되며 전달되어야 합니다. 일부 컨트롤은 '하드 실패'로 분류됩니다. 즉, 이러한 보안 컨트롤이 없으면 평가에 실패합니다.

중요

제출 시간 프레임: ISV가 제출 상태 자주 검사 수 있고 적시에 의견 및 추가 증거 요청에 응답할 수 있는 경우 평균적으로 평가 프로세스에는 30일이 소요됩니다. 인증 프로세스를 시작하면 평가를 완료하는 데 최대 60일이 허용됩니다. 모든 제출이 60일 기간 내에 완료되지 않은 경우 제출이 실패하고 프로세스가 다시 시작되어야 합니다. 이러한 결과는 공개되지 않습니다.

인증 scope

scope 환경은 앱/추가 기능 코드 배달을 지원하고 앱/추가 기능이 통신할 수 있는 모든 백 엔드 시스템을 지원합니다. 적절한 세분화가 마련되어 있고 연결된 환경이 scope 환경의 보안에 영향을 줄 수 없는 한 scope 환경에 연결된 추가 환경도 scope 포함됩니다.

기본 환경에 어떤 일이 발생해도 서비스를 이행하려면 이러한 환경이 필요하기 때문에 별도의 재해 복구 환경도 scope 환경에 포함되어야 합니다. 이러한 환경에서 Microsoft 데이터를 저장할 수 있으므로 적절한 보안 제어가 있어야 하므로 원격 백업 환경도 포함되어야 합니다.

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

  • 웹 애플리케이션
  • 서버(온-프레미스 또는 클라우드에 있을 수 있는 물리적 또는 가상)
  • 방화벽과 같은 NSC(네트워크 보안 제어)
  • 스위치
  • 부하 분산 장치
  • 가상 인프라
  • 클라우드 공급자 웹 관리 포털
  • 클라우드 리소스(Virtual Machines, App Service, 스토리지 계정, EC2 인스턴스 등)

중요

공용 시스템 구성 요소는 외부 위협 행위자의 공격에 취약하므로 훨씬 더 큰 위험이 있습니다. 일반적으로 이러한 시스템은 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 보고서와 같은 외부 규정 준수 보고서를 통해 클라우드 플랫폼 공급자의 보안 모범 사례에 대한 독립적인 외부 확인을 제공해야 합니다.

부록 C 는 다음 유형의 배포 및 앱이 Microsoft 365 데이터를 유출하는지 여부에 따라 적용할 수 있는 보안 컨트롤에 대해 자세히 설명합니다.

  • ISV 호스팅
  • IaaS 호스트
  • PaaS/서버리스 호스트
  • 하이브리드 호스팅
  • 공유 호스트됨

IaaS 또는 PaaS를 배포하는 경우 이러한 배포 유형에 대한 환경의 맞춤을 확인하는 증거를 제공해야 합니다.

견본 추출

인증 평가를 지원하는 증거 요청은 다양한 운영 체제, 디바이스의 기본 기능, 다양한 디바이스 유형(예: 서버, NSC, 라우터 등) 및 위치를 고려하여 scope 내 시스템 구성 요소의 샘플을 기반으로 해야 합니다. 인증 프로세스가 시작될 때 적합한 샘플이 선택됩니다. 다음 표는 위에서 설명한 요인에 따라 샘플링이 결정되는 가이드로 사용해야 합니다.

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

참고

초기 샘플에 포함된 디바이스 간에 불일치가 확인되면 평가 중에 샘플 크기가 증가할 수 있습니다.

엔드 투 엔드 인증 프로세스

Microsoft 365 인증을 시작하려면 다음을 수행합니다.

  1. 파트너 센터로 이동하여 게시자 증명을 완료합니다. 제출이 3개월보다 오래된 경우 검토 및 유효성 검사를 위해 다시 제출하세요.

  2. 파트너 센터 내에서 "인증 시작"을 선택하여 초기 문서 제출을 시작합니다. 이렇게 하면 인증 분석가가 앱의 아키텍처 및 Microsoft 데이터를 처리하는 방법에 따라 평가에 scope 사항을 결정하는 데 도움이 됩니다.

팁

단계별 지침 에 대한 방법 가이드 에 따라 Microsoft 365 Certified 앱을 가져옵니다.

인증 프로세스는 아래에 설명된 대로 두 단계로 수행됩니다.

초기 문서 제출은 분석가가 앱, 데이터 흐름을 이해하고, scope 환경을 정의하고, 적용 가능한 보안 제어를 식별하고, 증거를 수집해야 하는 시스템 구성 요소를 결정하는 데 도움이 됩니다. ISV는 인증 분석가가 전체 프로세스의 약 5%인 프로세스의 이 단계를 완료할 수 있도록 요청된 정보를 제공해야 합니다.

전체 증거 검토는 ISV가 scope 환경이 보안 제어를 충족하는 방법을 보여주는 증거 아티팩트 제출 프로세스입니다. 이 감사 단계에서 ISV와 분석가 간에는 프로세스의 나머지 부분인 여러 상호 작용이 있습니다.

평가

초기 문서 제출이 수락되면 보안 컨트롤 집합이 포털에 자동으로 표시됩니다. ISV는 컨트롤이 제자리에 있고 모든 증거를 제출하는 데 60일 이 있음을 보여주는 각 컨트롤에 대한 증거를 제공해야 합니다. 분석가는 증거를 검토하고 제어를 승인하거나 새 증거 또는 추가 증거를 요청합니다.

증명

분석가가 제출의 유효성을 검사하면 ISV는 인증 결정에 대한 알림을 받습니다. 인증을 받은 앱은 AppSource 내에서 해당 애플리케이션에 배지를 받게 되며, 보안 및 규정 준수 특성에 대한 자세한 보고가 포함된 전용 Microsoft 문서 페이지를 받게 됩니다.

검토 및 재인증

Microsoft 365 인증 앱은 매년 재인증을 통과해야 합니다. 이렇게 하려면 현재 scope 환경에 대해 scope 내 컨트롤의 유효성을 다시 검사해야 합니다. 이 프로세스는 인증이 만료되기 최대 90일 전에 시작할 수 있습니다. 기존 인증은 재인증 기간 동안 만료되지 않습니다. 모든 프로그램의 재인증은 Microsoft 365 인증 1주년을 맞아 만료됩니다.

만료 날짜 이전에 인증이 갱신되지 않으면 앱 인증 상태 해지됩니다. 모든 배딩, 아이콘 및 관련 인증 브랜딩이 앱에서 제거되고 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 인증에 대한 모든 제어가 충족되었는지 확인합니다.

평가를 완료하는 데 필요한 시간을 줄이려면 초기 설명서 제출 에 자세히 설명된 설명서의 전부 또는 전부를 미리 제공해야 합니다.

인증 분석가는 먼저 초기 문서 제출 및 게시자 증명 정보에서 제공된 증거를 검토하여 적절한 문의 줄, 샘플링 크기 및 위에서 자세히 설명한 대로 추가 증거를 얻을 필요성을 식별합니다. 인증 분석가는 수집된 모든 정보를 분석하여 이 Microsoft 365 인증 사양 내에서 컨트롤을 충족하는 방법과 경우에 대한 결론을 도출합니다.

앱 인증 기준

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

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

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

  • 최소 권한 원칙(PoLP)을 따르지 않는 API 권한입니다.
  • 필요한 경우 침투 테스트 보고서가 없습니다.
  • 맬웨어 방지 방어가 없습니다.
  • 다단계 인증은 관리 액세스를 보호하는 데 사용되지 않습니다.
  • 패치 프로세스가 없습니다.
  • 적절한 GDPR 개인 정보 보호 알림이 없습니다.

애플리케이션 보안

애플리케이션 보안 도메인은 다음 세 가지 영역에 중점을 둡니다.

  • GraphAPI 권한 유효성 검사
  • 외부 연결 검사
  • 침투 테스트

GraphAPI 권한 유효성 검사

GraphAPI 권한 유효성 검사는 앱/추가 기능이 지나치게 허용된 권한을 요청하지 않는지 유효성을 검사하기 위해 수행됩니다. 이 작업은 요청된 권한을 수동으로 확인하여 수행됩니다. 인증 분석가는 게시자 증명 제출에 대해 이러한 검사를 상호 참조하고 요청되는 액세스 수준을 평가하여 '최소 권한' 관행이 충족되는지 확인합니다. 인증 분석가가 이러한 '최소 권한' 관행이 충족되지 않는다고 생각하는 경우 인증 분석가는 ISV와 공개 토론을 통해 요청되는 권한에 대한 비즈니스 근거의 유효성을 검사합니다. 이 검토 중에 발견된 게시자 증명 제출에 대한 불일치는 수정해야 합니다.

외부 연결 검사

평가의 일환으로 Microsoft 365 외부에서 수행되는 연결을 식별하기 위해 애플리케이션 기능에 대한 간단한 연습이 수행됩니다. Microsoft 또는 서비스에 대한 직접 연결로 식별되지 않은 모든 연결은 평가 중에 플래그가 지정되고 논의됩니다.

침투 테스트

앱/추가 기능 및 지원 환경과 관련된 위험을 적절히 검토하는 것은 고객에게 앱/추가 기능의 보안에 대한 보증을 제공하는 데 필수적입니다. 애플리케이션이 Microsoft에서 게시하지 않은 서비스에 대한 연결이 있는 경우 침투 테스트 형식의 애플리케이션 보안 테스트를 수행해야 합니다. 앱을 배포한 후 GraphAPI와 같은 Microsoft 서비스에만 독립 실행형으로 액세스하는 경우 침투 테스트가 필요하지 않습니다. scope 환경이 Azure 내에서 호스트되는 경우에도 침투 테스트가 필요합니다.

침투 테스트 scope

내부 및 외부 인프라 침투 테스트의 경우 앱/추가 기능의 배포를 지원하는 라이브 프로덕션 환경에서 모든 침투 테스트 작업을 수행해야 합니다 (예: 앱/추가 기능 코드가 일반적으로 매니페스트 파일 내의 리소스가 되는 호스팅되는 위치)와 앱/추가 기능의 작업을 지원하는 추가 환경(예: 앱/추가 기능이 Microsoft 365 외부의 다른 웹 애플리케이션과 대화하는 경우) 침투 테스트에 대한 scope 정의할 때는 scope 환경의 보안에 영향을 미칠 수 있는 "연결된" 시스템 또는 환경도 모든 침투 테스트 활동에 포함되도록 주의해야 합니다.

라이브 프로덕션 환경에 대해 웹 애플리케이션 침투 테스트를 수행하는 것이 좋습니다. 그러나 테스트/UAT 환경을 사용하여 웹 애플리케이션만 테스트하는 것이 허용되며, 테스트 시 테스트/UAT 환경 내에서 정확히 동일한 코드베이스가 작동 중임을 침투 테스트 보고서 내에서 확인하면 됩니다.

기술이 다른 환경에서 scope 환경을 분할하는 데 사용되는 경우 침투 테스트 활동은 해당 세분화 기술의 효과를 검증해야 합니다. 이 내용은 침투 테스트 보고서 내에서 자세히 설명해야 합니다.

참고

호스팅 환경이 PaaS로만 분류되지 않는 한 내부 침투 테스트를 수행해야 합니다.

침투 테스트 요구 사항

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

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

중요

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

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

  • 현재 침투 테스트에 참여하지 않는 ISV의 경우 Microsoft 365 인증에 대해 침투 테스트를 무료로 수행할 수 있습니다. Microsoft는 수동 테스트의 최대 12일 동안 침투 테스트 비용을 준비하고 처리합니다. 침투 테스트 비용은 scope 환경을 테스트하는 데 필요한 일 수를 기준으로 계산됩니다. 테스트 12일을 초과하는 비용은 ISV의 책임입니다.
  • ISV는 침투 테스트를 수행하기 전에 증거를 제출하고 scope 내 컨트롤의 50%에 대한 승인을 받아야 합니다. 시작하려면 초기 문서 제출을 작성하고 침투 테스트를 평가의 일부로 포함하도록 선택합니다. 컨트롤의 50%를 완료하면 scope 침투 테스트를 예약하라는 연락을 받게 됩니다.
  • 펜 테스트가 완료되면 발급된 보고서는 인증을 완료하면 ISV에 제공됩니다. 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 v1.1을 지원하는 TLS 연결을 통해 암호화를 통해 보호되어야 합니다. (TLS v1.2 이상은 권장됨). 부록 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) 미만의 데이터 백업 및 재해 복구 계획을 제공합니다.

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

필수는 아니지만 현재 ISO 27001, PCI DSS, FedRAMP 또는 SOC2를 준수하는 경우 이러한 인증을 사용하여 Microsoft 365 인증 컨트롤 중 일부를 충족하도록 선택할 수 있습니다. 분석가는 기존 외부 보안 프레임워크를 Microsoft 365 인증 프레임워크에 맞추려고 합니다. 그러나 지원 설명서에서 Microsoft 365 인증 컨트롤이 외부 보안 프레임워크 감사/평가의 일부로 평가되었다는 보증을 제공할 수 없는 경우 해당 컨트롤의 추가 증거를 제공해야 합니다.

설명서는 Microsoft 365 인증에 대한 scope 환경이 이러한 외부 보안 프레임워크의 scope 포함되어 있음을 적절하게 입증해야 합니다. 이러한 보안 프레임워크의 유효성 검사는 신뢰할 수 있는 외부 타사 회사에서 수행한 유효한 인증의 증거를 수락하여 수행됩니다. 이러한 평판 좋은 회사는 관련 규정 준수 프로그램에 대한 국제 인증 기관의 구성원이어야 합니다. PCI DSS에 대한 ISO 인증 및 적합성 표준 ISO 27001 및 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가 보안 태세를 참조하여 보증 수준을 얻을 수 있도록 하는 이러한 보안 표준/프레임워크의 작은 하위 집합에 불과합니다.

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

✓ scope 환경 및 지원되는 비즈니스 프로세스는 지원되는 외부 보안 규정 준수 프레임워크의 scope 포함되어야 하며 제공된 설명서에 명확하게 표시되어야 합니다.

✓ 지원되는 외부 보안 규정 준수 프레임워크는 최신 상태여야 합니다 . 즉, 지난 12개월 이내에(또는 현재 재평가가 수행되고 있고 증거를 제공할 수 있는 경우 15개월 이내)

✓ 지원되는 외부 보안 규정 준수 프레임워크는 독립적인 공인 회사에서 수행해야 합니다 .

자세히 알아보기