Share via

Общие сведения о примерах примеров подтверждения сертификации Microsoft 365

  • Статья

Этот пример руководства по подтверждению помогает независимым поставщикам программного обеспечения получить правильные доказательства, необходимые для прохождения сертификации Microsoft 365. Этот документ включает в себя намерение каждого элемента управления и всех его частей, а также возможные способы сбора доказательств для элементов управления с образцами документов, политик и снимков экрана. Кроме того, в этом руководстве показано, как структурировать представленные доказательства.

Все примеры, представленные в этом документе, не представляют собой единственное свидетельство, которое можно использовать для подтверждения того, что элементы управления выполняются. Это рекомендации по типу доказательств, которые могут помочь аналитикам сертификации решить, был ли контроль выполнен isv.

Обратите внимание: фактические интерфейсы, снимки экрана и документация, используемые для удовлетворения требований к сертификации, зависят от использования продукта, настройки системы и внутренних процессов. Обратите внимание, что если требуется документация по политике или процедуре, поставщик программного обеспечения должен отправлять полные версии фактических документов, а не снимки экрана, как показано в некоторых примерах.

Все снимки экрана, которые должны быть отправлены, должны быть полноэкранными с любым URL-адресом пользователя, выполнившего вход (убедитесь, что на снимке экрана отображается имя вошедшего пользователя) с меткой времени и даты. Для систем под управлением Linux добавьте эти сведения в свидетельство элемента управления или в нее с помощью командной строки для его создания.

Все доказательства при представлении должны быть менее 3 месяцев, чтобы гарантировать, что к моменту завершения сертификации доказательства по-прежнему актуальны и не устарели. Если это не выполняется, вам может быть предложено собрать новые доказательства.

Обратите также внимание: для целей этой сертификации или любого примера, используемого в рамках этого процесса, нельзя использовать API бета-версии.

Рекомендуется следовать этим рекомендациям, чтобы избежать задержки оценки из-за недостаточного объема доказательств.

Примечание.

Если вы начали сертификацию Microsoft 365 до 12 декабря 2023 г., обратитесь к руководству по устаревшим образцам доказательств.

Структура сертификации Microsoft 365

Сертификация была структурирована вокруг трех доменов безопасности:

Тест на проникновение требуется для сертификации и будет проверен в домене безопасности приложения. Дополнительные сведения см. в разделах 3 и 4 структуры отправки доказательств.

Домены безопасности разбиваются на группы управления, чтобы помочь независимым поставщикам программного обеспечения понять структуру задач и разделить коллекцию доказательств на небольшие управляемые части. Эти группы управления были согласованы с общими корпоративными структурами ресурсов, чтобы помочь определить внутренние группы для поддержки, в то же время позволяя командам работать параллельно для ускорения процесса сбора доказательств.

Элемент управления: описание действия оценки. Эти элемент управления и связанные номера (No.) взяты непосредственно из контрольного списка сертификации Microsoft 365.

Намерение: намерение о том, почему элемент управления безопасностью включен в программу, и конкретный риск, который он направлен на снижение. Надежда заключается в том, что эта информация предоставит поставщики программного обеспечения с обоснованием, стоящим за контролем, чтобы лучше понять типы доказательств, которые должны быть собраны, и что ISV должны обратить внимание и иметь осведомленность и понимание при создании своих доказательств.

Примеры рекомендаций по подтверждению. Приведены для помощи в выполнении задач по сбору доказательств в сертификации Microsoft 365. Это позволяет поставщику программного обеспечения четко видеть примеры типов доказательств, которые могут быть использованы специалистом по сертификации, который будет использовать его для уверенного определения того, что контроль имеется и поддерживается. Это ни в коем случае не является исчерпывающим по своей природе.

Пример доказательства. В этом разделе приведены примеры снимков экрана и изображений потенциальных доказательств, полученных для каждого из элементов управления в рамках сертификации Microsoft 365, в частности для доменов операционной безопасности, безопасности данных и конфиденциальности. Обратите внимание, что любая информация с красными стрелками и полями в примерах поможет вам понять требования, необходимые для выполнения любого элемента управления.

Структура отправки доказательств

Отправка доказательств для всех применимых элементов управления будет осуществляться через Центр партнеров, за исключением оценок в поддержку регистрации соответствия требованиям Майкрософт и сертификации центра контактов. Как правило, вам потребуется выполнить процедуру вручную. Пропустите этот раздел и ознакомьтесь со следующим разделом, посвященным прохождению сертификации, если вы выполняете запись соответствия требованиям & центре контактов.

Чтобы аналитики сертификации могли легко определить предоставленные доказательства и успешно проверить их, следуйте следующим рекомендациям:

  1. В каждом из разделов убедитесь, что доказательства четко помечены перед отправкой. Если на элемент управления имеется несколько доказательств, пожалуйста, поместите доказательства в одно слово или pdf-файл, включая комментарий к тому, что показывает доказательства. Если свидетельство состоит из нескольких документов Word/PDF, т. е. вспомогательной документации, отправьте их как отдельные файлы. Не помещайте их в ZIP-файл для отправки в Центр партнеров, так как мы не принимаем ZIP-файлы из-за риска вредоносных программ.

  2. Вся информация о внешней платформе должна быть предоставлена в полном объеме без исправлений (мы разресим только частичное имя лиц, которые будут отредактированы в этих отчетах, так как это подпадает под личные сведения (PII)) — все части отчетов должны быть включены, например, заявление о применимости ISO 27001 (SOA) и сертификат, полный отчет SOC 2 типа 2 и /или полная аттестация соответствия требованиям PCI-DSS (AOC). Все документы охватываются соглашением Центра партнеров Майкрософт в соответствии с условием 7.

Раздел 7(a) включает следующие сведения о неуявном коде:

Изображение документа NDA

  1. По запросу через Центр партнеров необходимо отправить полный отчет о нередактированном тестировании на проникновение. Обратите внимание, что если это не указано, аналитики по сертификации не смогут завершить аудит для вашей сертификации Microsoft 365.

  2. Внутренняя и внешняя инфраструктура и тест на проникновение веб-приложений. Отчет о тестировании на проникновение требуется для всех сред размещения.

    • Для инфраструктуры как услуги (IaaS) или независимого поставщика программного обеспечения (локальный частный центр обработки данных) требуется внутренняя и внешняя инфраструктура и веб-приложение.

    • Для платформы как услуги PaaS/Бессерверный тест пера должен выполняться из веб-приложения и базовой вспомогательной инфраструктуры.

Примечание. Бесплатное тестирование на проникновение. Бесплатный тест пера Майкрософт ограничен только двенадцатью днями. Если при область тест пера для приложения требуется более 12 дней тестирования, то вам будет предложено заплатить за дополнительные дни. Кроме того, если требуется тестирование пера в нерабочее время, это также повлечет за собой дополнительные расходы. Предоставляемая служба тестирования пера также ограничена одним тестом пера (включая один повторный тест) в год, например, если вы выполнили тест на проникновение 1 сентября 2022 года, вы не сможете получить еще один тест до 31 августа 2023 года.

Это применимо ко всем попыткам отправки. Это означает, что это относится к текущему циклу отправки, а также если вы решите закрыть текущую отправку и перезапустить процесс позже в том же году, вы не будете иметь право на дополнительный тест пера, так как он уже был выполнен.

  1. Все поставщики программного обеспечения должны завершить первоначальную отправку документов в течение 14 дней (включая любые обратные и переадресации с аналитиком) после того, как они получат электронное письмо о начале билета от команды администраторов Майкрософт. 14-дневный период времени предназначен для полного завершения, проверки и перемещения представления на стадию полных доказательств. Поставщики программного обеспечения должны регулярно проверять, требуются ли их аналитики какие-либо поправки или запрашивают какую-либо дополнительную информацию или документы. В течение 14-дневного периода поставщики программного обеспечения могут отправлять требуемую информацию столько раз, сколько необходимо, однако имейте в виду, что если отправка не работает активно, она будет считаться устаревшей и закрытой в Центре партнеров, и сертификацию необходимо будет перезапустить. При определенных обстоятельствах isV может быть предоставлено до 30 дней для завершения. Если независимого поставщика программного обеспечения не удается завершить первоначальную отправку документа в течение заданного периода времени, его отправка будет закрыта.

Кроме того, все поставщики программного обеспечения должны пройти сертификацию в течение 60 дней после перемещения с начального этапа отправки документов на этап полного сбора доказательств. Сюда входят любые изменения и отзывы, предоставляемые оценчиком или аудитором на протяжении всего процесса. 60-дневный период времени предназначен для полного завершения, проверки и окончательного контроля качества ваших доказательств. Это означает, что поставщики программного обеспечения должны представлять свои доказательства по крайней мере за две недели до даты завершения, чтобы убедиться, что сертификация завершена вовремя. В течение 60-дневного периода поставщики программного обеспечения могут отправлять доказательства в Центр партнеров столько раз, сколько это необходимо. Однако имейте в виду, что окончательная отправка, как указано, составляет по крайней мере две недели до даты завершения, чтобы дать аналитикам сертификации время для проверки и контроля за отправкой. По истечении 60 дней для повторного запуска процесса потребуется поставщики программного обеспечения.

Если во время процесса сертификации возникают проблемы, аналитик по сертификации может предоставить потенциальное продление для обоснованных проблем. Аналитик может по своему усмотрению предоставить продление времени до максимума до 30 дней, если поставщики программного обеспечения активно работают над вашей отправкой. Обратите внимание, что если задано продление от 0 до 30 дней, isV должен убедиться, что доказательства доступны для проверки за две недели до даты окончания продления.

Если предоставлено продление, но доказательства более 3 месяцев, оно может потенциально не проверить, так как это доказательство может потенциально считаться устаревшим из-за длительности времени между моментом предоставления и окончательным контролем качества, что будет означать, что потребуются новые доказательства для этого контроля. По истечении срока продления не будет никаких дальнейших продлений, и ожидается, что isv представит свои доказательства (по крайней мере за две недели до окончания продления), если это не было отправлено, то отправка будет классирована как неудачная и будет закрыта. Если в течение первоначальных 60 дней или в течение периода продления (до 30 дней) не было начато никаких активных работ по отправке, то отправка будет классифицирована как отброшенная и будет закрыта.

Если представление было классифицировано как отброшенное, ISV потребуется перезапустить процесс с новой аттестацией и свежими доказательствами, так как текущие доказательства будут считаться устаревшими. Обратите внимание, что поставщики программного обеспечения могут быть отправлены только один раз в год. Если по какой-либо причине isV откажется от процесса после того, как они находятся на этапе полного сбора доказательств и их отправка помечена как отложенная, он не сможет перезапустить процесс до следующего года.

Структура отправки доказательств вручную — запись соответствия требованиям & центре контактов

Чтобы помочь аналитикам сертификации легко определить предоставленные доказательства и успешно проверить их, следуйте этим рекомендациям для структуры отправки доказательств при отправке вручную по запросу группы сертификации.

  1. Создайте один документ, который можно легко просмотреть (например, в Word или PDF) для каждой группы управления безопасностью (например, антивирусная программа, управление исправлениями и т. д.).

  2. Присвойте отдельному документу имя после группы управления безопасностью, чтобы понять, что он содержит.

  3. Добавьте к нему артефакты доказательств, ознакомьтесь со вспомогательной документацией вашей организации, которая поддерживает группу управления, и любыми дополнительными заметками для аналитика сертификации, объясняющими, что такое артефакт и как это доказательство соответствует элементу управления (это поможет вашим аналитикам сертификации, если вы назовете изображения с их контрольными номерами, например, Data Security and Privacy Control No.1).

Примечание. Помните, что там, где используется выборка, артефакты должны быть взяты с каждого устройства в наборе примеров. Убедитесь, что артефакт также отображает системное имя для проверки того, что артефакт получен от оцениваемого устройства и что данные не замаскированы или отредактированы.

  1. Вся информация о внешней платформе должна быть предоставлена в полном объеме без редакции (мы разрешим только отредактировать имена лиц из этих отчетов, так как они относятся к персональным данным). Все части отчетов должны быть включены, например, ЗАЯВЛЕНИЕ о применимости ISO 27001 (SOA) и Сертификат, полный отчет SOC 2 типа 2 и/или полная аттестация соответствия PCI-DSS (AOC) полный отчет HIPAA или FedRAMP. Все документы охватываются соглашением Центра партнеров Майкрософт в соответствии с разделом 7.

Раздел 7(a) включает следующие сведения о неуявном коде:

Изображение документа NDA

  1. Полный отчет об испытаниях на проникновение должен быть отправлен аналитику по сертификации по запросу. Обратите внимание, если это не указано, аналитик по сертификации не сможет пройти сертификацию Microsoft 365.

  2. Внутренняя и внешняя инфраструктура и веб-приложение. Отчет о тестировании на проникновение требуется для всех сред размещения.

    • Для инфраструктуры как услуги (IaaS) или независимого поставщика программного обеспечения (локальный частный центр обработки данных) требуется внутренняя и внешняя инфраструктура и веб-приложение.

    • Для платформы как услуги PaaS/Бессерверный тест пера должен выполняться из веб-приложения и базовой вспомогательной инфраструктуры.

Бесплатное тестирование на проникновение. Обратите внимание, что бесплатный тест пера Майкрософт ограничен только двенадцатью днями. Если приложению требуется более 12 дней тестирования, то независимого поставщика программного обеспечения будет предложено оплатить дополнительные дни. Кроме того, если поставщик программного обеспечения требует тестирования пера в обычное рабочее время в зависимости от расположения аудитора, это также повлечет за собой дополнительные расходы. Предоставляемая служба тестирования пера ограничена одним бесплатным тестом пера (включая один повторный тест) в год для каждой попытки отправки.

  1. Все поставщики программного обеспечения должны завершить первоначальную отправку документов в течение 14 дней (включая любые обратные и переадресации с аналитиком) после того, как они получат электронное письмо о начале билета от команды администраторов Майкрософт. 14-дневный период времени предназначен для полного завершения, проверки и перемещения представления на стадию полных доказательств. Поставщики программного обеспечения должны регулярно проверять, требуются ли их аналитики какие-либо поправки или запрашивают какую-либо дополнительную информацию или документы. В течение 14-дневного периода поставщики программного обеспечения могут отправлять требуемую информацию столько раз, сколько необходимо, однако имейте в виду, что если отправка не работает активно, она будет считаться устаревшей и закрытой в Центре партнеров, и сертификацию необходимо будет перезапустить. При определенных обстоятельствах isV может быть предоставлено до 30 дней для завершения. Если независимого поставщика программного обеспечения не удается завершить первоначальную отправку документа в течение заданного периода времени, его отправка будет закрыта.

Кроме того, все поставщики программного обеспечения должны пройти сертификацию в течение 60 дней после перемещения с начального этапа отправки документов на этап полного сбора доказательств. Сюда входят любые изменения и отзывы, предоставляемые оценчиком или аудитором на протяжении всего процесса. 60-дневный период времени предназначен для полного завершения, проверки и окончательного контроля качества ваших доказательств. Это означает, что поставщики программного обеспечения должны представлять свои доказательства по крайней мере за две недели до даты завершения, чтобы убедиться, что сертификация завершена вовремя. В течение 60-дневного периода поставщики программного обеспечения могут отправлять доказательства в Центр партнеров столько раз, сколько это необходимо. Однако имейте в виду, что окончательная отправка, как указано, составляет по крайней мере две недели до даты завершения, чтобы дать аналитикам сертификации время для проверки и контроля за отправкой. По истечении 60 дней для повторного запуска процесса потребуется поставщики программного обеспечения.

Если во время процесса сертификации возникают проблемы, аналитик по сертификации может предоставить потенциальное продление для обоснованных проблем. Аналитик может по своему усмотрению предоставить продление времени до максимума до 30 дней, если поставщики программного обеспечения активно работают над вашей отправкой. Обратите внимание, что если задано продление от 0 до 30 дней, isV должен убедиться, что доказательства доступны для проверки за две недели до даты окончания продления.

Если предоставлено продление, но доказательства более 3 месяцев, оно может потенциально не проверить, так как это доказательство может потенциально считаться устаревшим из-за длительности времени между моментом предоставления и окончательным контролем качества, что будет означать, что потребуются новые доказательства для этого контроля. По истечении срока продления не будет никаких дальнейших продлений, и ожидается, что isv представит свои доказательства (по крайней мере за две недели до окончания продления), если это не было отправлено, то отправка будет классирована как неудачная и будет закрыта. Если в течение первоначальных 60 дней или в течение периода продления (до 30 дней) не было начато никаких активных работ по отправке, то отправка будет классифицирована как отброшенная и будет закрыта.

Если представление было классифицировано как отброшенное, ISV потребуется перезапустить процесс с новой аттестацией и свежими доказательствами, так как текущие доказательства будут считаться устаревшими. Обратите внимание, что поставщики программного обеспечения могут быть отправлены только один раз в год. Если по какой-либо причине isV откажется от процесса после того, как они находятся на этапе полного сбора доказательств и их отправка помечена как отложенная, он не сможет перезапустить процесс до следующего года.

Создание структуры папок для записи соответствия требованиям & центре контактов

Следуйте этим инструкциям, чтобы создать структуру папок, необходимую аналитику для просмотра предоставленных доказательств.

  1. Завершите первоначальную отправку документа, чтобы можно было задать область действия элементов управления. Укажите как можно больше сведений, и что архитектурная схема и схема потока данных также имеют одинаковый уровень детализации.

  2. Создайте внутреннюю или интернет-папку и добавьте в нее все документы.

    • Пометка фактической общей папки Microsoft Certification

    • Добавьте сведения о первоначальной отправке документов в папку Microsoft Certification в папке IDS.

    • В папке Certification создайте четыре папки со следующими именами:

      • Безопасность приложений (это для сведений о тесте пера)

      • Соответствие требованиям (для внешних платформ, таких как SOC 2)

      • Операционная безопасность (ОС)

      • Конфиденциальность & безопасности данных (DS&P)

    • В папках OS и DS&P создайте группы управления для каждого набора элементов управления, например вредоносных программ, исправлений и т. д., где можно добавить документы для каждого из элементов управления (если вы хотите быть конкретным, вы можете создать папку для каждого отдельного элемента управления, чтобы вам было проще отслеживать доказательства по имени элемента управления. В этом случае назовите эти папки Control X, где X обозначает номер элемента управления). Обратите внимание, что вы не сможете создать вторичную структуру папок до тех пор, пока область действия элементов управления не будет ограничена.

Пример структуры папок корневых папок:

Корневые папки структуры папок

Вложенные папки в папке Evidence:

Вложенные папки в папке Evidence

  1. После отправки документов в общую папку предоставьте разрешение на доступ к общей папке и отправьте подробные сведения аналитику по сертификации. Отправьте пароли в отдельном сообщении электронной почты.

  2. При сортировке доказательств не забудьте сделать полноэкранные снимки экрана, показывающие любого вошедшего в систему пользователя, URL-адреса, метки даты и времени. При использовании Linux это можно сделать из командной строки. При необходимости укажите любое объяснение для каждого элемента управления и помните, что для политик требуется полная копия политики, а не фрагменты или снимки экрана.

  3. Ознакомьтесь с этим документом, чтобы понять элемент управления и тип необходимых нам доказательств.

  4. Любой тест пера, который может потребоваться, не будет запланирован, и вы не получите документацию для начала процесса, пока не будет утверждено 50 % ваших элементов управления. Тест пера будет бесплатным только в течение 12 дней, однако если тест пера выполняется в течение 12 дней, вам потребуется оплатить дополнительные дни авансом перед началом теста.

  5. После того как вы получите копию элементов управления с заданной областью для сбора доказательств против элементов управления, начнется ваш тикер . Вы получите сообщение электронной почты с этим, и у вас будет 60 дней для завершения всего процесса сертификации, включая тест пера.

  6. Попробуйте отправить первую итерацию элементов управления в течение 30 дней, чтобы можно было определить все проблемы и внести изменения до истечения 60 дней.

Дополнительные сведения