Обзор платформы сертификации Microsoft 365
В этой статье содержатся подробные сведения о сертификации Microsoft 365, включая список необходимых элементов управления безопасностью и рекомендации для поставщиков программного обеспечения и разработчиков.
Сертификация Microsoft 365 — это независимый аудит безопасности и конфиденциальности приложений, надстроек и вспомогательной серверной среды (в совокупности называемых приложениями), интегрирующийся с платформой Microsoft 365. Приложения, которые проходят проверку, будут назначены microsoft 365 Certified в экосистеме Microsoft 365. Их можно легко найти в Microsoft 365 Marketplace с помощью фильтров поиска и фирменной символики, ориентированных на соответствие требованиям. Поставщики программного обеспечения смогут предоставлять доступ к атрибутам соответствия приложений на выделенных страницах в этом наборе документации.
Сертификация Microsoft 365 доступна для следующих типов приложений:
- Надстройки Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
- Приложения Teams
- Решения SharePoint
- Веб-приложения (SaaS)
- Расширения CoPilot
Важно!
Сертификация Microsoft 365 — это тщательная проверка безопасности и соответствия приложений платформе сертификации Microsoft 365. Для ее завершения требуется значительное время и ресурсы. Прежде чем начать, ознакомьтесь с платформами управления соответствием, чтобы убедиться, что ваше приложение подходит. Если у вас есть вопросы, отправьте сообщение по электронной почте appcert@microsoft.com.
Условия
Участвуя в программе сертификации Microsoft 365, вы соглашаетесь с этими дополнительными условиями и соблюдать любую сопроводимую документацию, которая относится к вашему участию в программе сертификации Microsoft 365 с корпорацией Майкрософт ("Microsoft", "мы", "нас" или "наш"). Вы заявляете и гарантируете нам, что у вас есть полномочия принимать эти дополнительные условия сертификации Microsoft 365 от имени себя, компании и (или) другой организации, если это применимо. Мы можем изменить, изменить или прекратить действие этих дополнительных условий в любое время. Ваше дальнейшее участие в программе сертификации Microsoft 365 после любого изменения или поправки означает, что вы соглашаетесь с новыми дополнительными условиями. Если вы не согласны с новыми дополнительными условиями или если мы прекратим действие этих дополнительных условий, вы должны прекратить участие в программе сертификации Microsoft 365.
Предварительные условия
Прежде чем получить сертификацию Microsoft 365, приложение должно выполнить следующие действия:
Проверка издателя Если у приложения есть проверенный издатель, организация, которая публикует приложение, была проверена корпорацией Майкрософт на подлинность. Проверка приложения включает использование учетной записи Microsoft Cloud Partner Program (CPP), которая была проверена, и связывание проверенного PartnerID с регистрацией приложения. Проверка издателя
Аттестация издателя — это процесс самообслуживания, в котором разработчики приложений (ISV) задают ряд вопросов о своих методах безопасности, таких как обработка конфиденциальных данных. После завершения работы приложение получит специальные сведения о недоставке и листинге в Microsoft AppSource Marketplace.
Проверка условий элемента управления Не всегда требуется соблюдение всех элементов управления, которые должны быть награждены сертификацией. Однако для каждого из трех доменов безопасности, обсуждаемых в этом обзорном документе, установлены пороговые значения (которые не будут раскрыты). Они должны быть пройдены. Если не выполнить критически важные элементы управления, помеченные как "жесткий сбой", оценка завершится ошибкой.
Интервал времени отправки
Существует два этапа процесса отправки для получения сертификации:
Этап 1. Первоначальная отправка документов (14-дневный период)
На этом этапе поставщик программного обеспечения должен отправить документацию, которая содержит общие сведения о вспомогательной среде приложения. Сюда входят, помимо прочего:
- Схема архитектуры/поток данных
- Списки системных компонентов
- Инвентаризация активов программного обеспечения
Аналитик изучит эту документацию, чтобы определить область оценки. IsV предоставляется 14 дней для заполнения и отправки необходимой документации. Несоблюдение этого крайнего срока может задержать процесс или привести к сбою отправки.
Этап 2. Полный обзор доказательств (60-дневный период)
После определения область ISV перейдет к этапу сбора доказательств. На этом этапе:
- IsV должен передавать доказательства для всех применимых элементов управления, определенных из область.
- Это свидетельство будет проходить проверку, исправления (при необходимости) и окончательный процесс контроля качества.
- При необходимости в течение этого времени также можно провести тестирование на проникновение.
У поставщика программного обеспечения есть 60 дней для завершения этого этапа, начиная с первой отправки доказательств, которая включает в себя:
- Отправка свидетельства для всех элементов управления
- Обзор аналитика и отзывы
- Все необходимые изменения для представленных доказательств
- Завершение процесса контроля качества
Несоблюдение крайнего срока
Если независимого поставщика программного обеспечения не удается завершить процесс в течение 60-дневного периода времени, оценка завершится ошибкой. Тем не менее, по усмотрению аналитика, продление до дополнительных 60 дней может быть предоставлено при действительных обстоятельствах, таких как:
- Сезонные праздники
- Задержки тестирования на проникновение
- Внутренние изменения
- Время, необходимое для реализации необходимых изменений в соответствии с требованиями к управлению
После исчерпания обоих 60-дневных временных рамок продление не может быть предоставлено.
Сертификация область
Среда в область включает в себя все системы и инфраструктуру, необходимые для доставки кода приложения или надстройки, а также любые вспомогательные серверные системы, с которыми может взаимодействовать приложение или надстройка. Все дополнительные среды, подключенные к среде в область, также должны быть включены в область, если не будет реализована адекватная сегментация и подключенные среды не могут поставить под угрозу безопасность среды в область.
Обратите внимание: все отдельные среды аварийного восстановления также должны быть включены в среду в область, так как эти среды могут иметь решающее значение для поддержания непрерывности служб в случае сбоев основной среды.
Кроме того, среды удаленного резервного копирования также должны быть включены в область, так как в них могут храниться конфиденциальные данные Майкрософт. Поэтому для этих сред должны быть реализованы надлежащие средства управления безопасностью.
Термин область системные компоненты включает все устройства и системы, активно используемые в определенной область среде. К этим компонентам относятся, помимо прочего, следующие:
- Веб-приложения
- Серверы (физические или виртуальные, локальные или облачные)
- Параметры
- Подсистемы балансировки нагрузки
- Виртуальная инфраструктура
- Порталы веб-управления поставщиков облачных служб
- Облачные ресурсы (Виртуальные машины, службы приложений, учетные записи хранения, базы данных и т. д.)
Важно!
Общедоступные компоненты системы особенно уязвимы для атак со стороны внешних субъектов угроз и, следовательно, подвергаются более высокому риску. Как правило, эти системы следует изолировать от внутренних системных компонентов с помощью реализации средств управления безопасностью сети (NSC), таких как демилитаризованная зона (DMZ). Цель dmz — выступать в качестве буферной зоны, ограничивая доверие, распространяющееся на внешние системы, и повышая безопасность для защиты внутренних систем и данных. Хотя dmz все еще может быть идеальным в некоторых случаях, современные облачные архитектуры часто полагаются на альтернативные меры безопасности, адаптированные для конкретных сценариев развертывания.
Инфраструктура как услуга (IaaS), Платформа как услуга (PaaS) и Программное обеспечение как услуга (SaaS)
Если IaaS и (или) PaaS используется для поддержки рассматриваемой среды область, поставщик облачной платформы будет отвечать за некоторые средства управления безопасностью, оцениваемые в процессе сертификации. Аналитикам потребуется обеспечить независимую внешнюю проверку рекомендаций по обеспечению безопасности поставщиком облачной платформы с помощью внешних отчетов о соответствии требованиям, таких как PCI DSS, аттестация соответствия (AOC), отчеты ISO 27001 или SOC 2 типа II.
Дополнительные сведения о том, какие элементы управления безопасностью, вероятно, применимы к типу развертывания, а также о том, обрабатывает ли среда или передает данные Microsoft 365, см. в приложении C. Типы развертывания:
- IsV Hosted: приложение, размещенное независимыми поставщиками программного обеспечения
- IaaS Hosted: инфраструктура, предоставляемая сторонними облачными платформами.
- PaaS/Бессерверное размещение: приложения со средой платформенной или бессерверной архитектуры.
- Гибридное размещение. Сочетание локальных и облачных компонентов.
- Общие размещенные: общие облачные среды, используемые несколькими клиентами.
В случаях, когда используется IaaS или PaaS, необходимо убедиться, что развертывание соответствует ожидаемым элементам управления безопасностью для соответствующей архитектуры.
Выборка
Чтобы обеспечить тщательную оценку, выборка компонентов системы в область должна учитывать такие факторы, как операционные системы, основная функция устройства, тип устройства (например, серверы, маршрутизаторы, элементы управления безопасностью сети) и географическое расположение. Примеры выбираются в начале процесса сертификации на основе этих соображений. В приведенной ниже таблице описывается размер выборки на основе совокупности область компонентов:
| Размер населения | Пример |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
Это обеспечивает репрезентативную оценку соответствия среды различным конфигурациям и моделям развертывания.
Примечание.
При обнаружении несоответствий между устройствами во время оценки размер выборки можно скорректировать, чтобы обеспечить адекватное представление среды.
Обзор процесса сертификации
Чтобы начать процесс сертификации Microsoft 365, выполните следующие действия.
Аттестация издателя Перейдите в Центр партнеров и заполните форму аттестации издателя. Примечание. Если отправка старше трех месяцев, ее необходимо повторно отправить для проверки и проверки.
Запустите сертификацию. В Центре партнеров выберите параметр "Начать сертификацию", чтобы начать первоначальную отправку документа. Этот шаг помогает аналитикам сертификации определить область оценки на основе архитектуры вашего приложения и того, как оно управляет данными Майкрософт.
Сертификация проводится в два main этапа:
Первоначальная отправка документов. На этом этапе вы предоставляете ключевые сведения, которые помогут аналитикам понять структуру приложения, поток данных и среду в область. Аналитики будут определять применимые средства управления безопасностью и описывать системные компоненты, требующие подтверждения. Для упрощения этой проверки необходимо предоставить точную документацию, которая составляет примерно 5 % от общего процесса.
Полная проверка доказательств. На этом этапе вы предоставляете подробные доказательства, демонстрирующие соответствие элементам управления безопасностью для среды в область. Аналитики будут тесно сотрудничать с вами на этом этапе, чтобы проверить, уточнить и проверить ваши отправки. Этот этап занимает оставшуюся часть процесса.
Оценка
После утверждения первоначальной отправки документов на портале появится список необходимых элементов управления безопасностью. У вас есть 60 дней , чтобы предоставить доказательства для каждого элемента управления, подтверждающие, что он установлен и работает. Аналитики проверят ваши доказательства и либо утвердят их, либо запросят дополнительные сведения или исправления.
Сертификация
После того как ваша отправка будет проверена и проверена аналитиком, вы получите уведомление о решении о сертификации. Приложениям, которые успешно соответствуют критериям сертификации, будет присвоен значок, который будет отображаться в списке AppSource и связанных Документация Майкрософт страницах. На этих страницах также содержатся подробные отчеты об атрибутах безопасности и соответствия требованиям приложения.
Проверка и повторная сертификация
Сертифицированные приложения Microsoft 365 должны проходить ежегодную повторную сертификацию, чтобы обеспечить постоянное соответствие стандартам Майкрософт. Процесс повторной сертификации включает в себя переоценку элементов управления в область, чтобы убедиться, что они соответствуют текущей среде. Вы можете начать процесс повторной сертификации за 90 дней до истечения срока действия сертификации, чтобы избежать сбоев. Сертификаты будут оставаться действительными в течение этого периода.
Если повторная сертификация не завершена до истечения срока действия, сертификация будет отозвана. В результате:
Эмблема сертификации и фирменная символика приложения будут удалены.
Независимым поставщикам программного обеспечения больше не будет разрешено выходить на рынок приложения в качестве сертифицированного microsoft 365.
Если в приложении произошли значительные изменения за пределами запланированного периода повторной сертификации, поставщики программного обеспечения должны сообщить программе соответствия приложений Майкрософт, чтобы убедиться, что приложение остается соответствующим требованиям.
Первоначальная отправка документа
Ваша первоначальная отправка должна содержать следующие сведения:
| Обзор документации | Сведения о документации |
|---|---|
| Описание приложения или надстройки | Описание назначения и функциональности приложения или надстройки. Это должно дать аналитику сертификации хорошее представление о том, как работает приложение или надстройка и что они предназначены для использования. |
| Отчет о тестировании на проникновение | Отчет о тестировании на проникновение, завершенный за последние 12 месяцев. Этот отчет должен содержать среду, поддерживающую развертывание приложения или добавления, а также любую дополнительную среду, поддерживающую работу приложения или надстройки. Примечание. Если isV в настоящее время не выполняет ежегодное тестирование на проникновение, корпорация Майкрософт покроет расходы на тестирование пера в процессе сертификации. |
| Схемы архитектуры | Схема логической архитектуры, представляющая общий обзор вспомогательной инфраструктуры приложения. Сюда должны входить все среды размещения и вспомогательная инфраструктура, поддерживающая приложение. На этой схеме должны быть показаны все различные вспомогательные системные компоненты в среде, чтобы помочь аналитикам сертификации понять системы в область и определить выборку. Укажите также, какой тип среды размещения используется; IsV Hosted, IaaS, PaaS или Hybrid. Заметка: Где используется SaaS, укажите различные службы SaaS, которые используются для предоставления вспомогательных служб в среде. |
| Общедоступная занимаемая площадь | Подробные сведения обо всех общедоступных IP-адресах и URL-адресах, используемых вспомогательной инфраструктурой. Это должно включать полный диапазон IP-адресов, выделенный для среды, если не была реализована достаточная сегментация для разделения используемого диапазона (потребуется адекватное свидетельство сегментации). |
| С помощью схем потока данных | Схемы потоков, подробно описанные ниже. |
| ✓ Данные Microsoft 365 передаются в приложение или надстройку и из нее (включая EUII и OII). | |
| ✓ Потоки данных Microsoft 365 в вспомогательной инфраструктуре (если применимо). | |
| ✓ Диаграммы, на которых показано, где и какие данные хранятся, как данные передаются внешним третьим лицам (включая сведения о сторонних сторонах), а также как данные защищаются при передаче через открытые или общедоступные сети и неактивные. | |
| Сведения о конечной точке API | Полный список всех конечных точек API, используемых приложением. Чтобы понять область среды, укажите расположения конечных точек API в среде. |
| Разрешения API Майкрософт | Предоставьте документацию со сведениями обо всех используемых API Майкрософт, а также о том, какие разрешения запрашиваются для работы приложения или надстройки, а также обоснование запрошенных разрешений. |
| Типы хранилищ данных | Хранение данных и обработка документов, описывающих: |
| ✓ В какой степени данные Microsoft 365 euII и OII получаются и хранятся | |
| ✓ Срок хранения данных. | |
| ✓ Почему собираются данные Microsoft 365. | |
| ✓ Где хранятся данные Microsoft 365 (также должны быть включены в схемы потока данных, предоставленные выше). | |
| Подтверждение соответствия требованиям | Вспомогательная документация по внешним платформам безопасности, включенным в отправку аттестации издателя или которые должны учитываться при проверке элементов управления безопасностью сертификации Microsoft 365. В настоящее время поддерживаются следующие четыре: |
| ✓ Аттестация соответствия требованиям PCI DSS (AOC). | |
| ✓ Отчеты SOC 2 типа I/II. | |
| ✓ ISMS / IEC - 1S0/IEC 27001 Заявление о применимости (SoA) и сертификация. | |
| ✓ Пакет авторизации FedRAMP FedRAMP и отчет об оценке готовности FedRAMP. | |
| Веб-зависимости | Документация содержит список всех зависимостей, используемых приложением с текущими запущенными версиями. |
| Инвентаризация программного обеспечения | Актуальный перечень программного обеспечения, включающий все программное обеспечение, используемое в среде область, а также версии. |
| Инвентаризация оборудования | Актуальные данные инвентаризации оборудования, используемого вспомогательной инфраструктурой. Это будет использоваться для упрощения выборки при выполнении этапа оценки. Если ваша среда включает PaaS, укажите сведения об используемых облачных службах или ресурсах. |
Действия по сбору и оценке доказательств
Аналитикам сертификации потребуется проверить доказательства по всем компонентам системы в заданном наборе примеров. Типы доказательств, необходимых для поддержки процесса оценки, включают в себя любые или все следующие:
Сбор доказательств
- Начальная документация, выделенная в руководстве по отправке первоначальной документации
- Документы политики
- Обработка документов
- Параметры конфигурации системы
- Изменение билетов
- Изменения записей элементов управления
- Системные отчеты
- Минуты собрания
- Контракты и соглашения
Для сбора доказательств, необходимых для завершения процесса оценки, будут использоваться различные методы. Эта коллекция доказательств может быть представлена в следующих формах:
- Документы
- Снимки экрана
- Интервью
- Скринс-шеринг
Используемые методы сбора доказательств будут определены в процессе оценки. Конкретные примеры типов доказательств, необходимых для отправки, см. в руководстве по примерам доказательств.
Действия по оценке
Аналитики сертификации проверят представленные доказательства, чтобы убедиться, что все элементы управления, необходимые для сертификации Microsoft 365, выполнены. Чтобы ускорить процесс, убедитесь, что вся документация, указанная в разделе Первоначальная отправка документации , завершена и предоставлена заранее.
Во время проверки аналитики будут оценивать доказательства из первоначальной отправки и аттестации издателя. Они определят область расследования, сторону выборки и необходимы ли дополнительные доказательства. Аналитики будут использовать всю собранную информацию, чтобы оценить соответствие спецификации сертификации Microsoft 365 и решить, соответствует ли ваше приложение определенным элементам управления.
Критерии сертификации приложений
Приложение и его поддерживающая инфраструктура, а также сопроводительная документация будут оцениваться в следующих трех доменах безопасности:
- Безопасность приложений
- Операционная безопасность и безопасное развертывание
- Безопасность и конфиденциальность обработки данных
Каждый из этих доменов безопасности включает в себя определенные ключевые элементы управления, охватывающие одно или несколько требований, которые будут оцениваться в рамках процесса оценки. Чтобы гарантировать, что сертификация Microsoft 365 является инклюзивной для разработчиков всех размеров, каждый из доменов безопасности оценивается с помощью системы оценки для определения общей оценки по каждому из доменов. Оценки для каждого из элементов управления сертификацией Microsoft 365 распределяются между 1 (низким) и 3 (высоким) в зависимости от предполагаемого риска того, что этот элемент управления не будет реализован. Каждый из доменов безопасности будет иметь минимальную процентную отметку, которую можно считать проходной. Некоторые факторы приводят к автоматическим сбоям, в том числе
Использование разрешений API, которые не соответствуют принципу минимальных привилегий (PoLP)
Отсутствие отчетов о тестировании на проникновение при необходимости.
Отсутствие защиты от вредоносных программ.
Сбой реализации многофакторной проверки подлинности (MFA) для административного доступа.
Отсутствуют или недостаточно процессов исправления.
Отсутствие соответствующего GDPR уведомления о конфиденциальности.
Безопасность приложений
Домен безопасности приложения оценивает следующие области:
- Проверка разрешений GraphAPI
- Тестирование на проникновение
Проверка разрешений GraphAPI
Это гарантирует, что приложение или надстройка не запрашивают чрезмерные или слишком разрешительные разрешения. Аналитики сертификации вручную просматривают разрешения, запрошенные приложением, и перекрестно проверка их в отправке аттестации издателя.
Цель заключается в том, чтобы убедиться, что запрошенные разрешения соответствуют принципу минимальных привилегий. Если аналитики обнаруживают, что приложение запрашивает разрешения, превышающие необходимые, они будут взаимодействовать с isV для проверки бизнес-обоснования этих разрешений. Все несоответствия, обнаруженные между запрошенными разрешениями и отправкой аттестации издателя, должны быть устранены и устранены во время этой проверки.
Тестирование на проникновение
Тестирование на проникновение имеет решающее значение для выявления и устранения рисков, связанных с приложением или надстройкой и их вспомогательной средой. Это гарантирует, что приложение предоставляет клиентам достаточные гарантии безопасности.
Тестирование на проникновение является обязательным для любого приложения, которое подключается к внешним службам, не размещенным и не управляемым корпорацией Майкрософт. Если приложение развертывается как автономное решение, использующее только службы Майкрософт, такие как GraphAPI, тестирование на проникновение может не потребоваться. Однако приложения, размещенные в Azure, должны пройти тестирование на проникновение, чтобы обеспечить безопасность среды в область.
область тестирования на проникновение
Тестирование инфраструктуры. Как для внутренней, так и для внешней инфраструктуры тестирование на проникновение должно выполняться в динамической рабочей среде , поддерживающей приложение или надстройку. К ним относятся:
Среда, в которой размещается код приложения или надстройки (обычно ссылается в файле манифеста).
Любые дополнительные среды, которые взаимодействуют или поддерживают работу приложения или надстройки (например, если приложение или надстройка обмениваются данными с другими веб-приложениями за пределами Microsoft 365).
При определении область для тестирования на проникновение важно включить все подключенные системы или среды, которые могут повлиять на безопасность среды в область.
Рекомендации
Тестирование на проникновение веб-приложений. Тестирование на проникновение веб-приложений рекомендуется выполнять непосредственно в рабочей среде. Однако тестирование веб-приложений может выполняться в тестовой среде (UAT) при условии, что отчет о тестировании на проникновение подтверждает, что та же база кода используется в рабочей среде во время тестирования.
Проверка сегментации. Если методы сегментации используются для изоляции область сред от других, отчет о тестировании на проникновение должен проверить эффективность этих методов сегментации. Это гарантирует, что в процессе сегментации не будут обнаружены уязвимости.
Требования к тестированию на проникновение
Отчеты о тестировании на проникновение будут проверены, чтобы убедиться, что нет уязвимостей, которые соответствуют следующим критериям автоматического сбоя , описанным в элементах управления ниже.
| Тип условия | Элементы управления тестом на проникновение |
|---|---|
| Общие критерии | Веб-приложения (прошедшие проверку подлинности и не прошедшие проверку подлинности) и внутреннее (если применимо) и внешнее тестирование на проникновение инфраструктуры должны выполняться ежегодно (каждые 12 месяцев) и проводится независимой компанией. |
| Исправление выявленных критических уязвимостей и уязвимостей с высоким риском должно быть завершено в течение одного месяца после завершения тестирования на проникновение или раньше в зависимости от задокументированного процесса исправления поставщика программного обеспечения. | |
| Полный внешний объем (IP-адреса, URL-адреса, конечные точки API и т. д.) Должны быть включены в область тестирования на проникновение и должны быть четко задокументированы в отчете о тестировании на проникновение. | |
| Если среда не соответствует PaaS, все внутренние сети должны быть включены в область тестирования на проникновение и должны быть четко задокументированы в отчете о тестировании на проникновение. | |
| Тестирование на проникновение веб-приложений должно включать все классы уязвимостей; например, самый актуальный OWASP Top 10 или SANS Top 25 CWE. Рекомендация заключается в том, что это подробно описано в отчете о тестировании на проникновение, в противном случае это будет трудно продемонстрировать. | |
| Критические уязвимости и уязвимости с высоким риском или уязвимости, которые считаются автоматическим сбоем , должны быть повторно протестированы компанией по тестированию на проникновение и четко выделены как зафиксированные в отчете о тестировании на проникновение. | |
| Условия автоматического сбоя: | Наличие неподдерживаемой операционной системы или неподдерживаемой библиотеки JavaScript. |
| Наличие учетных записей администратора по умолчанию, перечисляемых или угадываемых учетных записей. | |
| Наличие рисков внедрения кода SQL. | |
| Наличие междоменных сценариев. | |
| Наличие уязвимостей обхода каталога (путь к файлу). | |
| Наличие уязвимостей HTTP, например разделение ответа заголовка, контрабанда запросов и десинхронные атаки. | |
| Наличие раскрытия исходного кода (включая LFI). | |
| Любая критическая или высокая оценка, определенная в рекомендациях по управлению исправлениями CVSS. | |
| Любая значительная техническая уязвимость, которую можно легко использовать для компрометации большого количества EUII или OUI. |
Важно!
Отчеты должны иметь достаточно уверенности в том, что все подробное описание в разделе требований к тестированию на проникновение выше может быть продемонстрировано.
Требования и правила бесплатного тестирования на проникновение
Для поставщиков программного обеспечения, которые в настоящее время не выполняют тестирование на проникновение, корпорация Майкрософт предлагает бесплатную службу тестирования на проникновение в рамках процесса сертификации Microsoft 365. Эта служба покрывает до 12 дней ручного тестирования, при этом дополнительные затраты на все необходимые дни, кроме этого, несет ответственность независимого поставщика программного обеспечения.
Ключевые требования
Требования перед тестированием. Перед планированием теста на проникновение isv должно представить доказательства и получить утверждение для 50 % область элементов управления.
Тестовый отчет. Этот отчет вместе с сертификатом Microsoft 365 можно использовать для демонстрации клиентам безопасности вашей среды.
Исправление уязвимостей. Поставщики программного обеспечения отвечают за устранение всех уязвимостей, выявленных во время тестирования, до получения сертификата. Однако чистый отчет не требуется, только подтверждение того, что уязвимости были надлежащим образом устранены.
Дополнительные рекомендации
После проведения теста на проникновение isv несет ответственность за покрытие любых сборов, связанных с переносом или отменой.
| Изменение шкалы времени оплаты | Пропорция к оплате |
|---|---|
| Запрос на перенос получил более чем за 30 дней до запланированной даты начала. | 0% к оплате |
| Запрос на перенос был получен за 8–30 дней до запланированной даты начала. | 25% к оплате |
| Запрос на перенос, полученный в течение 2–7 дней до запланированной даты начала с датой повторного бронирования фирмы. | 50% к оплате |
| Запрос на изменение расписания получен менее чем за 2 дня до даты начала. | 100 % к оплате |
| Шкала времени оплаты отмены | Пропорция к оплате |
|---|---|
| Запрос на отмену получен более чем за 30 дней до запланированной даты начала. | 25% к оплате |
| Запрос на отмену получен за 8–30 дней до запланированной даты начала. | 50% к оплате |
| Запрос на отмену получен в течение 7 дней до запланированной даты начала. | 90% к оплате |
Операционная безопасность
Этот домен измеряет согласование вспомогательных процессов инфраструктуры и развертывания приложения с рекомендациями по обеспечению безопасности.
Элементы управления
| Семейство элементов управления | Controls |
|---|---|
| Обучение по повышению осведомленности | Предоставьте доказательства того, что организация проводит учебные курсы по вопросам безопасности для пользователей информационной системы (включая руководителей, руководителей и подрядчиков) в рамках первоначального обучения новых пользователей или при необходимости изменений в информационной системе. |
| Предоставьте свидетельство о частоте обучения осведомленности, определяемой организацией. | |
| Предоставьте доказательства документации и мониторинг отдельных действий по повышению осведомленности информационной системы о безопасности при сохранении отдельных учебных записей в течение определенной организацией частоты. | |
| Защита от вредоносных программ — антивирусная программа | Предоставьте подтверждение того, что ваше решение для защиты от вредоносных программ активно и включено во всех примерах системных компонентов и настроено в соответствии со следующими критериями: |
| Если антивирусная программа, это сканирование при доступе включено и что сигнатуры актуальны в течение 1 дня и автоматически блокирует вредоносные программы или оповещения и карантины при обнаружении вредоносных программ. | |
| Или, если EDR/NGAV (обнаружение конечных точек и ответ/антивирусная программа следующего поколения) выполняется периодическое сканирование, создаются журналы аудита и они постоянно обновляются и имеют возможности для самостоятельного обучения. | |
| Если EDR/NGAV, он блокирует известные вредоносные программы и определяет и блокирует новые варианты вредоносных программ на основе макрокоманды, а также с полными возможностями безопасного списка. | |
| Защита от вредоносных программ — элементы управления приложениями | Предоставьте наглядное подтверждение того, что утвержденный список программного обеспечения или приложений с бизнес-обоснованием существует и является актуальным. |
| Каждое приложение проходит процесс утверждения и выхода из системы перед развертыванием | |
| Эта технология управления приложениями активна, включена и настроена во всех примерах системных компонентов, как описано в документе. | |
| Управление исправлениями — установка исправлений и ранжирование рисков | Предоставьте документацию по политике, которая определяет, как выявляются новые уязвимости системы безопасности и присваиваются оценка риска. |
| Предоставьте доказательства того, как выявляются новые уязвимости системы безопасности. | |
| Предоставьте доказательства того, что всем уязвимостям присваивается рейтинг риска после выявления. | |
| Предоставьте доказательства того, что все выборочные системные компоненты устанавливаются в соответствии с определенными организациями временными интервалами исправления, а неподдерживаемые операционные системы и программные компоненты не используются. Если применимо, это должно быть база кода, если используется бессерверная технология или PaaS, или инфраструктура и база кода, если используется IaaS. | |
| Рекомендации по исправлению сроков на месте, например "критический - в течение 14 дней, высокий - в течение 30 дней, средний - в течение 60 дней". | |
| Проверка уязвимостей | Предоставьте ежеквартальные отчеты об уязвимостях инфраструктуры и веб-приложений. Сканирование должно выполняться по всем общедоступным (IP-адресам и URL-адресам) и внутренним диапазонам IP-адресов. |
| Предоставьте демонстрируемые доказательства того, что исправления уязвимостей, обнаруженных во время проверки уязвимостей, исправляются в соответствии с вашими документированными сроками исправления. | |
| Элементы управления безопасностью сети (NSC) | Укажите подтверждение того, что элементы управления безопасностью сети (NSC) устанавливаются на границе среды в область и устанавливаются между сетью периметра и внутренними сетями. |
| И, если гибридная, локальная среда, IaaS также предоставляет доказательства того, что весь общедоступный доступ прекращается в сети периметра. | |
| Убедитесь, что все элементы управления безопасностью сети (NSC) настроены для удаления трафика, явно не определенного в базе правил, и что проверки правил элементов управления безопасностью сети (NSC) выполняются по крайней мере каждые 6 месяцев. | |
| Элемент управления изменениями | Предоставьте доказательства того, что любые изменения, внесенные в рабочие среды, реализуются с помощью задокументированных запросов на изменение, которые содержат сведения о последствиях изменения, подробных процедурах резервного копирования, тестировании, проверке и утверждении уполномоченным персоналом. |
| Предоставьте доказательства того, что существуют отдельные среды, чтобы: среды разработки и тестирования и промежуточной среды принудительно отделяли обязанности от рабочей среды, разделение обязанностей применялось с помощью средств управления доступом, конфиденциальные рабочие данные не использовались в средах разработки или тестирования или промежуточной среды. | |
| Безопасная разработка и развертывание программного обеспечения | Предоставьте политики и процедуры, которые поддерживают безопасную разработку программного обеспечения и включают отраслевые стандарты и (или) рекомендации по безопасному кодированию. Например, Open Web Application Security Project (OWASP) Top 10 или SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE). |
| Предоставьте подтверждение того, что репозитории кода защищены, чтобы: все изменения кода проходили проверку и утверждение вторым рецензентом перед слиянием с main ветвью, были установлены соответствующие элементы управления доступом, весь доступ применялся с помощью многофакторной проверки подлинности (MFA). | |
| Предоставьте доказательства того, что все выпуски, сделанные в рабочей среде, проверяются и утверждаются до их развертывания. | |
| Управление учетными записями | Предоставьте подтверждение того, что учетные данные по умолчанию отключены, удалены или изменены в примерах системных компонентов. |
| Предоставьте доказательства того, что выполняется процесс защиты (усиления защиты) учетных записей служб и что этот процесс был выполнен. | |
| Предоставьте доказательства того, что: для всех пользователей выдаются уникальные учетные записи пользователей, в среде соблюдаются принципы минимальных привилегий пользователей, применяется политика надежных паролей или парольной фразы или другие подходящие способы устранения рисков, выполняется процесс, который выполняется по крайней мере каждые три месяца для отключения или удаления учетных записей, не используемых в течение трех месяцев. | |
| Убедитесь, что MFA настроена для всех подключений удаленного доступа и всех неконсолевых административных интерфейсов, включая доступ к любым репозиториям кода и интерфейсам управления облаком. | |
| Журнал событий безопасности, просмотр и оповещение | Предоставьте подтверждение того, что данные журнала событий безопасности сразу же доступны не менее 30 дней, при этом журналы событий безопасности хранятся в течение 90 дней. |
| Предоставьте доказательства того, что журналы периодически проверяются, а все потенциальные события или аномалии безопасности, выявленные в процессе проверки, изучаются и устраняются. | |
| Предоставьте доказательства того, что правила генерации оповещений настроены таким образом, чтобы оповещения активировались для исследования следующих событий безопасности, где это применимо: создание или изменение привилегированной учетной записи, действия или операции с привилегированным или высоким риском, события вредоносных программ, изменение журнала событий, события IDPS /WAF. (если настроено) | |
| Управление информационными рисками | Предоставьте доказательства того, что утвержденная официальная политика или процесс управления рисками информационной безопасности задокументированы и установлены. |
| Предоставьте доказательства того, что официальная оценка рисков информационной безопасности в масштабах всей компании проводится не реже одного раза в год. | |
| ИЛИ для целевого анализа рисков: целевой анализ рисков документируется и выполняется как минимум каждые 12 месяцев для каждого случая, когда отсутствует традиционный контроль или лучший отраслевой подход, когда конструктор или технологическое ограничение создает риск внедрения уязвимости в среде или ставит пользователей и данные под угрозу. при подозрении или подтверждении компромисса. | |
| Убедитесь, что оценка рисков информационной безопасности включает в себя системный компонент или затронутый ресурс, угрозы и уязвимости или эквивалентные матрицы влияния и вероятности или эквивалентные, создание регистра рисков или плана обработки рисков. | |
| Предоставьте доказательства того, что у вас есть процессы управления рисками, которые оценивают и управляют рисками, связанными с поставщиками и бизнес-партнерами, и вы можете выявлять и оценивать изменения и риски, которые могут повлиять на систему внутреннего контроля. | |
| Реагирование на инциденты безопасности | Укажите утвержденный план или процедуру реагирования на инциденты безопасности (IRP). |
| Предоставьте доказательства того, как ваша организация реагирует на инциденты, показывая, как она поддерживается, и что она включает в себя подробные сведения о группе реагирования на инциденты, включая контактные данные, внутренний план коммуникации во время инцидента и внешнюю связь с соответствующими сторонами, такими как ключевые заинтересованные лица, платежные бренды и приобретатели, регулирующие органы (например, 72 часа для GDPR), надзорные органы, директора, клиенты, а также шаги для таких действий, как классификация инцидентов, сдерживание, устранение рисков, восстановление и возвращение к обычным бизнес-операциям в зависимости от типа инцидента | |
| Предоставьте доказательства того, что все члены группы реагирования на инциденты прошли ежегодное обучение, позволяющее им реагировать на инциденты. | |
| Предоставьте доказательства того, что стратегия реагирования на инциденты и вспомогательная документация проверяются и обновляются на основе уроков, извлеченных из упражнения в верхней таблице, уроков, извлеченных из реагирования на инцидент, организационных изменений. | |
| План непрерывности бизнес-процессов и план аварийного восстановления | Предоставьте доказательства наличия и поддержки документации, которая описывает план непрерывности бизнес-процессов. |
| Предоставление доказательств в плане непрерывности бизнес-процессов с подробными сведениями о соответствующем персонале и его ролях и обязанностях, включая: бизнес-функции со связанными требованиями и целями на случай непредвиденных обстоятельств, процедуры резервного копирования систем и данных, конфигурации и планирования и хранения, приоритеты и целевые показатели восстановления, план на непредвиденные случаи, в которых подробно описаны действия, шаги и процедуры, которые необходимо выполнить для возврата критически важных информационных систем, бизнес-функций и служб для работы в случае возникновения непредвиденные и незапланированные прерывания, установленный процесс, охватывающий полное восстановление системы и возвращение в исходное состояние. | |
| Предоставьте доказательства того, что документация существует, поддерживается и описывает план аварийного восстановления и включает в себя как минимум: персонал и его роли, обязанности и процесс эскалации, инвентаризацию информационных систем, используемых для поддержки критически важных бизнес-функций и служб, процедуры резервного копирования систем и данных и конфигурацию, план восстановления с подробным описанием действий и процедур, которые необходимо выполнить для восстановления критически важных информационных систем и данных в эксплуатацию. | |
| Предоставьте доказательства того, что план непрерывности бизнес-процессов и план аварийного восстановления пересматриваются по крайней мере каждые 12 месяцев, чтобы убедиться, что он остается действительным и эффективным в неблагоприятных ситуациях. | |
| Предоставьте доказательства того, что план непрерывности бизнес-процессов обновляется на основе ежегодного обзора плана, все соответствующие сотрудники проходят обучение по своим ролям и обязанностям, назначенным в планах на случай непредвиденных обстоятельств, план тестируется с помощью непрерывности бизнес-процессов или аварийного восстановления, результаты тестирования документируются, включая уроки, извлеченные из этого упражнения или организационных изменений. |
Безопасность и конфиденциальность обработки данных
Для обеспечения безопасности данных все данные, передаваемые между пользователем приложения, промежуточными службами и системами независимого поставщика программного обеспечения, должны шифроваться с помощью подключения TLS (transport Layer Security). Как минимум, требуется ПРОТОКОЛ TLS 1.2. Настоятельно рекомендуется использовать TLS 1.3 или более поздней версии. Дополнительные сведения см. в приложении A.
Для приложений, которые получают или хранят данные Microsoft 365, необходимо реализовать схему шифрования хранилища данных. Это должно соответствовать спецификациям, описанным в приложении B.
Элементы управления
| Семейство элементов управления | Controls |
|---|---|
| Передаваемые данные | Предоставьте подтверждение того, что конфигурация TLS имеет значение TLS 1.2 или выше в соответствии с требованиями к конфигурации профиля TLS , а также что инвентаризация доверенных ключей и сертификатов хранится и обслуживается. |
| Предоставьте свидетельство о том, что сжатие TLS отключено для всех общедоступных служб, обрабатывающих веб-запросы, чтобы предотвратить утечку данных коэффициента сжатия сделано easy (CRIME), а протокол HSTS TLS включен и настроен на 180 дней на всех сайтах. | |
| Неактивные данные | Убедитесь, что неактивные данные шифруются в соответствии с требованиями профиля шифрования, используя такие алгоритмы шифрования, как расширенное шифрование Standard (AES), RSA и Twofish с размером ключа шифрования 256 бит или выше. |
| Хранение данных, резервное копирование и удаление | Предоставьте подтверждение того, что утвержденный срок хранения данных официально установлен и задокументирован. |
| Предоставьте свидетельство того, что данные хранятся только в течение определенного периода хранения, как описано в предыдущем элементе управления. | |
| Предоставьте доказательства того, что существуют процессы для безопасного удаления данных по истечении срока хранения. | |
| Предоставьте свидетельство того, что автоматизированная система резервного копирования создана и настроена для выполнения резервного копирования в запланированное время. | |
| Предоставление сведений о резервном копировании проверяется в соответствии с процедурой планирования резервного копирования и периодически восстанавливается для подтверждения надежности и целостности данных. | |
| Предоставьте доказательства реализации соответствующих средств управления доступом и механизмов защиты (т. е. неизменяемых резервных копий) для обеспечения защиты резервных копий или моментальных снимков системы от несанкционированного доступа и обеспечения конфиденциальности, целостности и доступности данных резервных копий. | |
| Управление доступом к данным | Предоставьте подтверждение того, что список пользователей с доступом к данным и (или) ключам шифрования сохраняется. Включая бизнес-обоснование для каждого человека и подтверждение, что этот список пользователей был официально утвержден на основе привилегий доступа, необходимых для их работы, и пользователи настроены с привилегиями, указанными в утверждении. |
| Предоставьте доказательства того, что список всех третьих лиц, которым предоставляется общий доступ к данным, поддерживается, а соглашения об обмене данными заключены со всеми третьими лицами, потребляющими данные. | |
| Конфиденциальность | Имеется ли в вашей организации система управления конфиденциальной информацией (PIM), созданная, внедренная и поддерживаемая, которая отвечает за лидерство с помощью политики или другой формы документации или компьютеризированной системы для обеспечения конфиденциальности и целостности системы. Определяет роли, обязанности и полномочия каждого лица, поддерживающего систему, включая обработчиков персональных данных и контроллеров. |
| Предоставьте сведения о процессах, чтобы убедиться, что происходит минимизация личных данных, деидентификация и удаление личных данных выполняется в конце периода обработки, меры контроля за передачей личных данных, включая конфиденциальность, запись о передаче личных данных из одной страны или региона в другую существует с выраженным согласием на это. | |
| GDPR | Предоставьте доказательства того, что субъекты данных могут создавать SAR, что поставщик программного обеспечения может идентифицировать все расположения данных субъектов данных при ответе на запрос SAR, что существует период хранения резервных копий, позволяющий клиентам, запрашивающим удаление данных через SAR, при удалении последовательных резервных копий в течение определенного периода (жизненный цикл удаления старых резервных копий или перезаписи). |
| Предоставьте уведомление о конфиденциальности, которое должно содержать все необходимые элементы следующим образом: сведения об организации (имя, адрес и другие персональные данные), тип обрабатываемых персональных данных, срок хранения персональных данных, законность обработки персональных данных, права субъектов данных; в том числе: права субъекта данных, право на получение информации, право на доступ со стороны субъекта данных, право на стирание, право на ограничение обработки, право на переносимость данных, право на возражение, права в отношении автоматизированного принятия решений, включая профилирование. | |
| HIPAA | Предоставьте доказательства того, что: существует политика для обработки HIPAA и HIPAA в организации для сотрудников, подрядчиков, поставщиков и т. д. Убедитесь, что наша организация обеспечивает конфиденциальность, целостность и доступность ePH. |
| Убедитесь, что вы: обеспечиваете защиту от разумно ожидаемого использования или раскрытия такой информации, которая не разрешена правилом конфиденциальности, и обеспечьте соблюдение правила безопасности сотрудниками. Предоставьте план резервного копирования данных и аварийного восстановления в 164,308 (a)(7)(ii)(A) и 164,308 (a)(7)(ii)(B). |
Необязательная проверка внешней платформы соответствия требованиям
Если ваша организация уже соответствует внешним платформам безопасности, таким как ISO 27001, PCI DSS, FedRAMP или SOC 2 типа 2, вы можете использовать эти сертификаты для удовлетворения некоторых элементов управления сертификацией Microsoft 365. Аналитики будут стремиться согласовать существующие внешние платформы безопасности с требованиями сертификации Microsoft 365.
Однако если в вспомогательной документации не показано, что элементы управления сертификацией Microsoft 365 были явно оценены как часть аудита или оценки внешней платформы, необходимо предоставить дополнительные доказательства для проверки наличия этих элементов управления.
Требования к документации
Документация должна четко продемонстрировать, что среда область для сертификации Microsoft 365 включена в область вечных платформ безопасности. Проверка этих платформ будет выполняться путем принятия доказательств действительных сертификатов, выданных авторитетными, аккредитованными сторонними аудиторами.
Эти сторонние аудиторы должны быть членами международных органов по аккредитации, например:
Стандарты сертификации и соответствия для ISO 27001
Оценщики безопасности качества (QSA) для PCI DSS
Дополнительные сведения см. в конкретных рекомендациях и стандартах для внешних платформ, относящихся к вашей сертификации.
В приведенной ниже таблице описаны необходимые платформы и документация, принятые аналитиками сертификации в рамках процесса проверки.
| Standard | Требования |
|---|---|
| ISO 27001 | Потребуется общедоступная версия заявления о применимости (SOA) и копия выданного сертификата ISO 27001. SOA суммирует вашу позицию по каждому из 114 элементов управления информационной безопасностью и будет использоваться для определения исключения элементов управления, которые не удовлетворительно подробно описаны в сертификате ISO 27001. Если это не удается определить, изучив общедоступную версию SOA, аналитику может потребоваться доступ к полной soA, если iso 27001 будет использоваться для проверки некоторых элементов управления безопасностью сертификации Microsoft 365. Помимо проверки область деятельности по оценке ISO 27001, аналитики также подтвердят действительность аудиторской компании, как описано выше. |
| PCI DSS | Необходимо предоставить допустимый документ по аттестации соответствия требованиям уровня 1 (AOC), четко определяющий компоненты область приложения и системы. AOC для самостоятельной оценки не будет приниматься в качестве доказательства рекомендаций по обеспечению безопасности собраний. AOC будет использоваться для определения того, какие из элементов управления спецификации сертификации Microsoft 365 были оценены и подтверждены в рамках оценки PCI DSS. |
| SOC 2; | Отчет SOC 2 (тип II) должен быть актуальным (выданным в течение последних 15 месяцев и объявленным периодом времени, начатым в течение последних 27 месяцев), чтобы его можно было использовать в качестве доказательства соответствия любому из средств оценки в рамках этой платформы сертификации Microsoft 365. |
| FedRAMP | Федеральная программа управления рисками и авторизацией (FedRAMP) — это федеральная государственная программа США, созданная в 2011 году. Он обеспечивает стандартизированный подход к оценке безопасности, авторизации и непрерывному мониторингу облачных продуктов и служб. |
| Платформа | Дополнительные сведения |
|---|---|
| ISO 27001 | Приложение В. Сбор доказательств — дельты для ISO 27001. |
| PCI DSS | Приложение D. Сбор доказательств — разностные значения для PCI DSS. |
| SOC 2; | Приложение Е. Сбор доказательств — разностные значения для SOC 2. |
Примечание.
Хотя внешние стандарты безопасности или платформы можно представить в качестве подтверждающих доказательств для соответствия определенным элементам управления сертификацией Microsoft 365, для получения сертификации Microsoft 365 требуется отдельная оценка. Получение сертификации Microsoft 365 не означает, что приложение полностью прошло аудит для этих внешних платформ. Спецификация сертификации Microsoft 365 ориентирована на определенное подмножество элементов управления, производных от этих платформ, чтобы обеспечить корпорации Майкрософт более высокий уровень уверенности в безопасности вашего приложения.
Требования к использованию внешних платформ соответствия требованиям
✓ Среда в область И любые вспомогательные бизнес-процессы должны быть включены в область любых поддерживаемых внешних платформ соответствия требованиям безопасности и должны быть четко указаны в предоставленной документации.
✓ Поддерживаемые внешние платформы соответствия требованиям безопасности должны быть актуальными, то есть в течение последних 12 месяцев (или в течение 15 месяцев, если в настоящее время проводится переоценка и могут быть предоставлены доказательства).
✓ Поддерживаемые внешние платформы соответствия требованиям безопасности должны выполняться независимой аккредитованной компанией.