Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Эта статья содержит подробные сведения о сертификации Microsoft 365, включая список необходимых элементов управления безопасностью и рекомендации для независимых поставщиков программного обеспечения и разработчиков.
Сертификация Microsoft 365 — это независимый аудит безопасности и конфиденциальности приложений, надстроек, агентов и поддерживающей серверной среды (совместно именуемых приложениями), интегрируемых с платформой Microsoft 365. Приложения, которые пройдут соответствующую процедуру, будут сертифицированы Microsoft 365 в экосистеме Microsoft 365 и их можно будет легко найти на торговых площадках Microsoft 365 благодаря фильтрам поиска, ориентированным на соответствие, и фирменной символике. Независимые поставщики программного обеспечения будут иметь возможность поделиться атрибутами соответствия своего приложения на специальных страницах в этом наборе документации.
Сертификация 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) отвечают на ряд вопросов о своих методах обеспечения безопасности, таких как обработка конфиденциальных данных. После завершения приложение получит страницу документов, которой можно поделиться с клиентами с предоставленными ими ответами.
Просмотрите критерии контроля. Для получения сертификата не всегда требуется соблюдение всех требований контроля. Однако пороговые значения (которые не будут разглашаться) существуют для каждого из трех доменов безопасности, обсуждаемых в этом обзорном документе, и должны быть преодолены. Невыполнение критических элементов управления с пометкой «жесткий сбой» приведет к провалу оценки.
Структура затрат
ISV будет работать с аудиторской фирмой, чтобы оплатить сертификацию. Для получения дополнительной информации и создания учетной записи в аудиторской фирме Claranet - нажмите здесь.
| Тип аудита | Что входит в комплект | Квалификация |
|---|---|---|
| Стандартный | Полная оценка по всем применимым средствам контроля | Необходимы для новых оценок и повторных сертификаций, которые не подходят для аудита спутника. Необходимо, если повторная сертификация не соответствует критериям риска, установленным для аудита спутников |
| Аудит спутников | При соблюдении критериев сниженный контроль устанавливается на второй и третий годы оценки | Соответствует требованиям после завершения стандартной сертификации на 1-м году. Для 2-го и 3-го курсов, если не произошло существенных изменений и пройти оценку риска |
| Дополнительное время болтового крепления | Возможность создания по запросу, включает время отчетности | Добавляется только в том случае, если для отправки требуется больше времени с аудитором |
| Ставка за день пентеста | Пентест, ограниченный по каждому заданию и соответствующий требованиям сертификации, который охватывает полную согласованную область оценки | Требуется, если приложение еще не прошло надежный сторонний тест на проникновение за последние 12 месяцев |
| Клонировать | Подтверждение клонированной заявки, просмотр любых средств контроля, для которых требовались дополнительные доказательства | Приложение, которое использует ту же серверную среду, что и приложение, недавно завершившее сертификацию |
Сроки отправки
Процесс подачи заявки для получения сертификата состоит из двух этапов:
Этап 1: Первичная подача документа (14 дней)
На этом этапе независимый поставщик программного обеспечения должен предоставить документацию с обзором вспомогательной среды своего приложения. Это включает в себя, но не ограничивается:
- Архитектурная схема/поток данных
- Списки системных компонентов
- Инвентаризация программных активов
Аналитик рассмотрит эту документацию, чтобы определить области оценки. Независимому поставщику программного обеспечения дается 14 дней на заполнение и отправку необходимой документации. Несоблюдение этого срока может привести к задержке процесса или к неудачной отправке.
Этап 2: Полный обзор доказательств (60-дневный срок)
После определения области действия независимый поставщик программного обеспечения перейдет к этапу сбора доказательств. На этом этапе:
Независимый поставщик программного обеспечения должен отправить доказательства для всех применимых элементов управления, определенных в области.
Эти доказательства будут подвергнуты проверке, пересмотру (при необходимости) и окончательному процессу вопросов и ответов.
В это время также может быть проведено тестирование на проникновение.
У независимого поставщика программного обеспечения есть 60 дней, чтобы завершить этот этап, начиная с первой отправки доказательств, которая включает:
- Отправка доказательств для всех элементов управления
- Обзор и отзывы аналитиков
- Любые необходимые изменения в представленных доказательствах
- Завершение процесса вопросов и ответов
Несоблюдение установленного срока
Если независимому поставщику программного обеспечения не удастся завершить процесс в течение 60 дней, оценка завершится ошибкой. Однако, по усмотрению аналитика, продление может быть предоставлено еще на 60 дней при допустимых обстоятельствах, таких как:
- Сезонные праздники
- Задержки тестирования на проникновение
- Внутренние изменения
- Время, необходимое для внедрения необходимых изменений для соответствия требованиям контроля
Дальнейшие продления не могут быть предоставлены после исчерпания обоих 60-дневных сроков.
Области сертификации
Внутренняя области среда охватывает все системы и инфраструктуру, необходимые для доставки кода приложения, надстройки или агента, а также все вспомогательные серверные системы, с которыми может взаимодействовать приложение, надстройка или агент. Любые дополнительные среды, подключенные к области области, также должны быть включены в область области, если не реализована адекватная сегментация и подключенные среды не могут поставить под угрозу безопасность внутренней области.
Обратите внимание. Все отдельные среды аварийного восстановления также должны быть включены в области среды, так как эти среды могут иметь решающее значение для поддержания непрерывности обслуживания в случае сбоев основной среды.
Кроме того, в область областей также должны быть включены удаленные среды резервного копирования, так как в них могут храниться конфиденциальные данные Майкрософт. Поэтому для этих сред должны быть реализованы адекватные средства контроля безопасности.
Термин "системные компоненты" в области включает в себя все устройства и системы, активно используемые в определенной области области. Вот некоторые из этих компонентов:
- Веб-приложения
- Серверы (физические или виртуальные, расположенные в локальной среде или в облаке)
- Параметры
- Подсистемы балансировки нагрузки
- Виртуальная инфраструктура
- Порталы веб-управления поставщика облачных служб
- Облачные ресурсы (виртуальные машины, службы приложений, учетные записи хранения, базы данных и т. д.)
Важно!
Общедоступные компоненты системы особенно уязвимы к атакам внешних злоумышленников и, следовательно, подвержены более высокому риску. Как правило, эти системы должны быть изолированы от внутренних компонентов системы путем внедрения средств контроля сетевой безопасности (NSC), таких как демилитаризованная зона (DMZ). Цель демилитаризованной зоны — действовать в качестве буферной зоны, ограничивая доверие, распространяемое на внешние системы, и повышая безопасность для защиты внутренних систем и данных. Хотя в некоторых случаях DMZ все еще может быть идеальной, современные облачные архитектуры часто полагаются на альтернативные меры безопасности, адаптированные к конкретным сценариям развертывания.
Инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS)
Если для поддержки рассматриваем область ой среды используется IaaS и (или) PaaS, поставщик облачной платформы будет отвечать за некоторые средства контроля безопасности, оцениваемые в процессе сертификации. Аналитикам необходимо будет предоставлять независимую внешнюю проверку лучших практик безопасности поставщиком облачной платформы с помощью внешних отчетов о соответствии требованиям, таких как отчеты PCI-DSS, Attestation of Compliance (AOC), ISO 27001 или SOC 2 Type II.
Сведения о том, какие элементы управления безопасностью, скорее всего, применимы к типу развертывания, а также о том, обрабатывает ли среда или передает ли данные Microsoft 365, см. в приложении В. Типы развертывания:
- Размещенные независимыми поставщиками программного обеспечения: приложение, размещенное независимыми поставщиками программного обеспечения.
- Размещение IaaS: инфраструктура, предоставляемая сторонними облачными платформами.
- PaaS/Serverless Hosted: приложения с усредненной архитектурой на основе платформы или бессерверной архитектуры.
- Гибридное размещение: сочетание локальных и облачных компонентов.
- Общее размещение: общие облачные среды, используемые несколькими клиентами.
В случаях использования IaaS или PaaS необходимо подтвердить, что развертывание соответствует ожидаемым элементам управления безопасностью для соответствующей архитектуры.
Выборка
Чтобы обеспечить тщательную оценку, при отборе системных компонентов в областях необходимо учитывать такие факторы, как операционные системы, основные функции устройства, тип устройства (например, серверы, маршрутизаторы, элементы управления сетевой безопасностью) и географическое положение. На основе этих соображений образцы отбираются в начале процесса сертификации. В приведенной ниже таблице указан размер выборки на основе генеральной совокупности компонентов в областях:
| Численность населения | Пример |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
Это обеспечивает репрезентативную оценку соответствия среды требованиям для различных конфигураций и моделей развертывания.
Примечание.
Если в ходе оценки выявляются расхождения между устройствами, размер выборки может быть скорректирован для обеспечения адекватного представления среды.
Обзор процесса сертификации
Чтобы начать процесс сертификации Microsoft 365:
Аттестация издателя Перейдите в Центр партнеров и заполните форму "Аттестация издателя". Примечание. Если срок подачи заявки превышает три месяца, необходимо повторно отправить его для проверки и проверки.
Начать сертификацию В Центре партнеров выберите параметр "Начать сертификацию", чтобы начать отправку исходного документа. Этот шаг помогает аналитикам по сертификации определить области оценки на основе архитектуры вашего приложения и того, как оно управляет данными Майкрософт. На этом этапе вам необходимо будет создать учетную запись в Claranet Limited.
Сертификация проводится в два основных этапа:
Исходная отправка документа На этом этапе вы предоставляете ключевые сведения, чтобы помочь аналитикам понять структуру вашего приложения, поток данных и внутреннюю область действия. Аналитики определят применимые средства управления безопасностью и опишут компоненты системы, для которых требуются доказательства. Вы должны предоставить точную документацию, чтобы облегчить эту проверку, что составляет примерно 5% от общего процесса.
Полный анализ доказательств На этом этапе вы отправляете подробные доказательства, демонстрирующие соответствие средствам контроля безопасности для внутренней области среды. На этом этапе аналитики будут тесно сотрудничать с вами, чтобы просматривать, разъяснять и проверять ваши отправленные материалы. Этот этап занимает оставшуюся часть процесса.
Оценка
После утверждения первоначальной подачи документа на портале появится список необходимых средств контроля безопасности. У вас есть 60 дней , чтобы предоставить доказательства для каждого элемента управления, подтверждающие, что он введен в действие и функционирует. Аналитики рассмотрят ваши доказательства и либо одобрят их, либо запросят дополнительные детали или пересмотры.
Сертификация
После рассмотрения и утверждения вашей заявки аналитиком вы получите уведомление о решении о сертификации. Приложениям, успешно соответствующим критериям сертификации, присваивается эмблема, которая отображается в списке AppSource и на связанных страницах Документации Майкрософт. На этих страницах также предоставляются подробные отчеты об атрибутах безопасности и соответствия приложения.
Проверка и повторная сертификация
Приложения, сертифицированные для Microsoft 365, должны проходить ежегодную повторную сертификацию, чтобы обеспечить постоянное соответствие стандартам Майкрософт. Процесс повторной сертификации включает в себя повторную оценку элементов управления в области областей, чтобы убедиться, что они соответствуют текущей среде. Вы можете начать процесс повторной сертификации не позднее чем за 90 дней до истечения срока действия сертификации, чтобы избежать каких-либо сбоев. В течение этого периода сертификаты остаются действительными.
Если повторная сертификация не будет завершена до истечения срока действия, сертификация будет отозвана. В результате:
Эмблема сертификации и фирменная символика приложения будут удалены.
независимым поставщикам программного обеспечения больше не будет разрешено продавать приложение как сертифицированное для Microsoft 365.
При внесении значительных изменений в приложение за пределами запланированного периода повторной сертификации независимые поставщики программного обеспечения должны сообщить об этом в программу соответствия приложений Майкрософт, чтобы убедиться, что приложение продолжает соответствовать требованиям.
Первичная подача документа
В исходной заявке должны быть указаны следующие сведения.
| Обзор документации | Сведения о документации |
|---|---|
| Описание приложения, надстройки или агента | Описание назначения и функциональности приложения, надстройки или агента. Это должно дать аналитику по сертификации хорошее понимание того, как функционирует приложение, надстройка или агент и каково его предполагаемое применение. |
| Отчет о тестировании на проникновение | Отчет о тестировании на проникновение, составленный за последние 12 месяцев. Этот отчет должен включать среду, поддерживающую развертывание приложения, надстройки или агента, а также любую дополнительную среду, поддерживающую работу приложения, надстройки или агента. Примечание: если независимый поставщик программного обеспечения в настоящее время не проводит ежегодное тестирование на проникновение, аудиторская группа может выполнить его за дополнительную плату. |
| Схемы архитектуры | Схема логической архитектуры, представляющая общий обзор вспомогательной инфраструктуры приложения. Это должны включать все среды размещения и вспомогательную инфраструктуру, поддерживающую приложение. На этой схеме ДОЛЖНЫ быть изображены все различные вспомогательные системные компоненты в среде, чтобы помочь аналитикам сертификации понять системы в областях и помочь определить выборку. Также укажите, какой тип среды размещения используется. Размещенные независимыми поставщиками программного обеспечения, IaaS, PaaS или гибридная версия. Примечание. В тех случаях, когда используется 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 доступ к подтверждению сертификации приложения в Центре администраторов Teams и Центре администрирования Microsoft 365. (Администраторы Microsoft 365 отвечают за настройку, управление и защиту служб и ресурсов Microsoft 365 в организации.) Эта прозрачность направлена на оптимизацию комплексной проверки организаций, оценивающих новые приложения, для ускорения принятия решений. Если независимый поставщик программного обеспечения предпочитает не обнародовать эти доказательства, он может просто снять флажок во время отправки, сохраняя полный контроль над тем, как и когда раскрывается его документация о соответствии требованиям.
Деятельность по оценке
Аналитики сертификации рассмотрят представленные доказательства, чтобы убедиться в соблюдении всех средств контроля, необходимых для сертификации Microsoft 365. Чтобы ускорить процесс, убедитесь, что вся документация, указанная в первоначальной подаче документации , является полной и предоставленной заранее.
В ходе проверки аналитики оценят доказательства из первоначальной отправки и аттестации издателя. Они определят области расследования, сторону выборки и необходимость дополнительных доказательств. Аналитики используют всю собранную информацию для оценки соответствия спецификации сертификации Microsoft 365 и принятия решения о соответствии вашего приложения определенным элементам управления.
Условия сертификации приложений
Приложение и его вспомогательная инфраструктура, а также вспомогательная документация будут оцениваться в следующих трех доменах безопасности:
- Безопасность приложений
- Операционная безопасность
- Безопасность и конфиденциальность обработки данных
Каждый из этих доменов безопасности содержит определенные ключевые элементы управления, охватывающие одно или несколько требований, которые будут оцениваться в рамках процесса оценки. Чтобы гарантировать, что сертификация Microsoft 365 будет инклюзивной для разработчиков любого размера, каждый из доменов безопасности оценивается с использованием системы баллов для определения общей оценки для каждого из доменов. Баллы для каждого элемента управления сертификацией Microsoft 365 распределяются между 1 (низкий) и 3 (высокий) в зависимости от предполагаемого риска того, что этот элемент управления не будет реализован. Каждый из доменов безопасности будет иметь минимальную процентную отметку, чтобы считаться пройденным. Определенные факторы приводят к автоматическим сбоям, в том числе:
Использование разрешений API, не соответствующих принципу минимальных привилегий (PoLP)
Отсутствие отчетов о тестировании на проникновение, когда это необходимо.
Отсутствие средств защиты от вредоносных программ.
Нереализована многофакторная проверка подлинности для административного доступа.
Отсутствующие или недостаточные процессы исправления.
Отсутствие соответствующего требованиям уведомления о конфиденциальности в соответствии с GDPR .
Безопасность приложений
Домен безопасности приложений оценивает следующие области:
- Тестирование на проникновение
- Проверка разрешений API Graph
- Ответственное применение ИИ
Тестирование на проникновение
Тестирование на проникновение имеет решающее значение для выявления и снижения рисков, связанных с приложением или надстройкой и их вспомогательной средой. Это гарантирует, что приложение предоставляет адекватные гарантии безопасности для клиентов.
Тестирование на проникновение является обязательным для любого приложения, которое подключается к внешним службам, не размещенным и не управляемым корпорацией Майкрософт. Если приложение развернуто как автономное решение, использующее только службы Майкрософт, такие как GraphAPI, тестирование на проникновение может не требоваться. Однако приложения, размещенные в Azure, должны пройти тестирование на проникновение, чтобы обеспечить безопасность внутренней области среды.
Области тестирования на проникновение
Тестирование инфраструктуры: как для внутренней, так и для внешней инфраструктуры тестирование на проникновение должно проводиться в рабочей среде , которая поддерживает приложение, надстройку или агент. К ним относятся:
Среда, в которой размещено приложение, надстройка или код агента (обычно указывается в файле манифеста).
Любые дополнительные среды, которые взаимодействуют или поддерживают работу приложения, надстройки или агента (например, если приложение, надстройка или агент взаимодействуют с другими веб-приложениями за пределами Microsoft 365).
При определении областей для тестирования на проникновение крайне важно включить все подключенные системы или среды, которые могут повлиять на безопасность внутренней области среды.
Рекомендации
Тестирование на проникновение в веб-приложения: Рекомендуется проводить тестирование на проникновение в веб-приложения непосредственно в рабочей среде. Однако тестирование веб-приложений может проводиться в тестовой среде/UAT (User Acceptance Testing) при условии, что отчет о тестировании на проникновение подтверждает, что во время тестирования в рабочей среде используется та же кодовая база.
Если методы сегментации используются для изоляции сред в областях от других, отчет о тестировании на проникновение должен подтверждать эффективность этих методов сегментации. Это гарантирует отсутствие уязвимостей в процессе сегментации.
Требования к тестированию на проникновение
Отчеты о тестировании на проникновение проверяются на предмет отсутствия уязвимостей, соответствующих следующим критериям автоматического отказа , описанным в элементах управления ниже.
| Тип условия | Элементы управления тестом на проникновение |
|---|---|
| Общие критерии | Веб-приложения (аутентифицированные и неаутентифицированные), а также внутреннее (если применимо) и внешнее тестирование на проникновение в инфраструктуру ДОЛЖНЫ проводиться ежегодно (каждые 12 месяцев) и проводиться авторитетной независимой компанией. |
| Устранение выявленных критических уязвимостей и уязвимостей высокого риска ДОЛЖНО быть завершено в течение одного месяца после завершения тестирования на проникновение или раньше, в зависимости от документированного процесса исправления независимым поставщиком программного обеспечения. | |
| Полный внешний контур (IP-адреса, URL-адреса, конечные точки API и т. д.) ДОЛЖЕН быть включен в области тестирования на проникновение и должен быть четко задокументирован в отчете о тестировании на проникновение. | |
| Если среда не соответствует PaaS, полные внутренние сети ДОЛЖНЫ быть включены в области тестирования на проникновение и должны быть четко задокументированы в отчете о тестировании на проникновение. | |
| Тестирование на проникновение в веб-приложения ДОЛЖНО включать все классы уязвимостей; например, самый последний OWASP Top 10 или SANS Top 25 CWE. Рекомендуется подробно описать это в отчете о тестировании на проникновение, иначе это будет трудно продемонстрировать. | |
| Критические и высокорисковые уязвимости или уязвимости, рассматриваемые как автоматический сбой, ДОЛЖНЫ быть повторно протестированы компанией, проводящей тестирование на проникновение, и четко выделены как исправленные в отчете о тестировании на проникновение. | |
| Критерии автоматического отказа: | Наличие неподдерживаемой операционной системы или неподдерживаемой библиотеки JavaScript. |
| Наличие учетных записей администраторов по умолчанию, перечисляемых или угадываемых учетных записей. | |
| Наличие рисков внедрения SQL-кода. | |
| Наличие межсайтового скриптинга. | |
| Наличие уязвимостей, связанных с обходом каталогов (путь к файлам). | |
| Наличие уязвимостей HTTP, таких как расщепление ответа заголовка, контрабанда запросов и атаки рассинхронизации. | |
| Наличие раскрытия исходного кода (в том числе LFI). | |
| Любая критическая или высокая оценка в соответствии с руководством по управлению исправлениями CVSS. | |
| Любая значительная техническая уязвимость, которая может быть легко использована для компрометации большого количества EUII или OUI. |
Важно!
Отчеты должны быть достаточно уверены в том, что все, что подробно описано в разделе требований к тестированию на проникновение, может быть продемонстрировано.
Проверка разрешений API Graph
Это гарантирует, что приложение, надстройка или агент не будут запрашивать чрезмерные или чрезмерно разрешающие разрешения. Аналитики сертификации вручную проверяют разрешения, запрашиваемые приложением, и сверяют их с отправкой аттестации издателя.
Цель состоит в том, чтобы убедиться, что запрашиваемые разрешения соответствуют принципу минимальных привилегий. Если аналитики обнаружат, что приложение запрашивает разрешения, превышающие необходимые, они будут связываться с независимым поставщиком программного обеспечения, чтобы проверить коммерческое обоснование этих разрешений. Любые обнаруженные несоответствия между запрашиваемыми разрешениями и представленной аттестацией издателя должны быть рассмотрены и разрешены в ходе этой проверки.
Ответственное применение ИИ
Информация, предоставленная в ответ на ответственные элементы управления ИИ, будет рассмотрена вместе с файлом манифеста приложения, предоставленным независимым поставщиком программного обеспечения. Это позволяет аналитику проверить интеграцию Microsoft Copilot с приложением, проходящим сертификацию, обеспечивая четкое понимание того, как эти два приложения взаимодействуют друг с другом и какие действия предпринимаются от имени клиента. Мы признаем важность ответственного использования ИИ и там, где клиент полностью информирован. При условии, что предоставленная информация соответствует ожидаемой функциональности приложения и стандартам ответственного применения ИИ корпорации Майкрософт или NIST Trustworthy & Responsible Artificial Intelligence Resource Center, эти элементы управления будут считаться утвержденными (при условии обычных проверок вопросов и ответов).
Мы планируем продолжить сотрудничество с корпорацией Майкрософт, чтобы предоставить некоторые сведения об этой проверке на соответствующих общедоступных страницах, чтобы клиенты могли принимать полностью обоснованные решения об использовании их данных, когда речь идет о Copilot и связанном приложении.
Операционная безопасность
Этот домен измеряет согласованность вспомогательной инфраструктуры и процессов развертывания приложения с рекомендациями по безопасности.
Элементы управления
| Управление семьей | Controls |
|---|---|
| Ознакомительный курс | Предоставление доказательств того, что организация проводит организованное обучение по вопросам безопасности для пользователей информационных систем (включая менеджеров, старших руководителей и подрядчиков) в рамках первоначального обучения новых пользователей или по мере необходимости в связи с изменениями в информационных системах. |
| Предоставьте доказательства того, что в организации существует определенная периодичность обучения осведомленности. | |
| Предоставление доказательств документирования и мониторинга отдельных действий по повышению осведомленности о безопасности информационных систем с сохранением индивидуальных записей обучения с частотой, определенной организацией. | |
| Защита от вредоносных программ — антивирус | Предоставьте доказательства того, что ваше решение для защиты от вредоносных программ активно и включено во всех отобранных системных компонентах и настроено на соответствие следующим критериям: |
| Если включена антивирусная программа, включается сканирование при доступе и обновление сигнатур в течение 1 дня, а также автоматически блокируются вредоносные программы или оповещения и помещаются в карантин при обнаружении вредоносных программ. | |
| ИЛИ, если EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus), то выполняется периодическое сканирование, создаются журналы аудита, он постоянно обновляется и имеет возможности самообучения. | |
| ЕСЛИ 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). |
| Предоставьте доказательства того, что репозитории кода защищены таким образом, чтобы: все изменения кода проходили процесс рассмотрения и утверждения вторым рецензентом перед слиянием с основной ветвью, были установлены соответствующие средства контроля доступа, весь доступ обеспечивался с помощью многофакторной аутентификации (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 соответствует уровню TLS1.2 или выше в требованиях к конфигурации профиля TLS , а также что инвентаризация доверенных ключей и сертификатов хранится и поддерживается. |
| Предоставление доказательств показывает, что сжатие TLS отключено для всех общедоступных служб, обрабатывающих веб-запросы, чтобы предотвратить утечку информации о коэффициенте сжатия (CRIME), а TLS HSTS включен и настроен на 180 дней на всех сайтах. | |
| Неактивные данные | Предоставьте доказательства того, что неактивные данные шифруются в соответствии с требованиями к профилю шифрования с использованием алгоритмов шифрования, таких как Advanced Encryption 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 Type 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, если для проверки некоторых элементов управления безопасностью сертификации Microsoft 365 будет использоваться ISO 27001. В дополнение к проверке областей деятельности по оценке ISO 27001, аналитики также подтвердят достоверность аудиторской компании, как описано выше. |
| ISO 22301 | Должен быть предоставлен действительный сертификат ISO 22301, выданный аккредитованным органом по сертификации, и документ, описывающий области оценки системы управления непрерывностью бизнеса (BCMS). Документация по сертификату и области будет использоваться для проверки того, что приложение, вспомогательные службы и операционные процессы в области области были оценены в рамках формальной программы управления непрерывностью бизнеса. Аналитики, проводящие оценку, рассмотрят области сертификации, подтвердят действительность органа сертификации и определят, какие элементы управления непрерывностью бизнеса сертификации Microsoft 365 могут быть удовлетворены с помощью доказательств оценки ISO 22301. |
| ИСО 27031 | Должен быть предоставлен действительный сертификат ISO 27031 или отчет об оценке, выданный аккредитованным органом по сертификации или оценке, в котором четко указывается область приложения, инфраструктуры и вспомогательных услуг информационно-коммуникационных технологий (ИКТ). Документация будет использоваться для оценки готовности ИКТ к непрерывности бизнеса, включая планирование аварийного восстановления, возможности восстановления и процессы устойчивости. Аналитики, проводящие оценку, рассмотрят области оценки, подтвердят достоверность организации, проводящей оценку, и определят, какие элементы управления аварийным восстановлением и операционной устойчивостью сертификации Microsoft 365 могут быть удовлетворены с помощью данных оценки ISO 27031 |
| PCI DSS | Необходимо предоставить действительный документ об аттестации соответствия уровня 1 (AOC), в котором четко указаны встроенные область приложения и компоненты системы. AOC самооценки не будет принят в качестве доказательства соответствия лучшим практикам в области безопасности. AOC будет использоваться для определения того, какие из элементов управления спецификацией сертификации Microsoft 365 были оценены и подтверждены в рамках оценки PCI DSS. |
| SOC 2; | Отчет SOC 2 (тип II) должен быть актуальным (выдан в течение последних 15 месяцев, а заявленный период времени начался в течение последних 27 месяцев), чтобы его можно было использовать в качестве доказательства соответствия любому из элементов управления оценкой в рамках этой системы сертификации Microsoft 365. |
| FedRAMP | Федеральная программа управления рисками и авторизацией (FedRAMP) — это общегосударственная программа США, учрежденная в 2011 году. Он обеспечивает стандартизированный подход к оценке, авторизации и непрерывному мониторингу облачных продуктов и служб. |
| Платформа | Дополнительные сведения |
|---|---|
| ISO 27001 | Приложение C: Сбор доказательств – дельты для ISO 27001. |
| PCI-DSS | Приложение D: Сбор доказательств – дельты для PCI-DSS. |
| SOC 2; | Приложение E: Сбор доказательств – дельты для SOC 2. |
Примечание.
Хотя внешние стандарты или платформы безопасности могут быть представлены в качестве подтверждающего доказательства для соответствия определенным элементам управления сертификацией Microsoft 365, получение сертификации Microsoft 365 требует отдельной оценки. Получение сертификата Microsoft 365 не означает, что приложение полностью прошло аудит для этих внешних платформ. Спецификация сертификации Microsoft 365 фокусируется на определенном подмножестве элементов управления, производных от этих платформ, чтобы предоставить корпорации Майкрософт более высокий уровень уверенности в состоянии безопасности вашего приложения.
Требования к использованию внешних платформ соответствия требованиям
Требования к использованию внешних платформ соответствия требованиям
Встроенная среда область и все вспомогательные бизнес-процессы должны быть включены в область любой поддерживаемой внешней платформы соответствия требованиям безопасности. Они должны быть четко задокументированы в прилагаемой документации.
Внешние структуры соответствия требованиям безопасности должны быть актуальными, то есть они должны быть оценены в течение последних 12 месяцев (или 15 месяцев, если текущая повторная оценка может быть подтверждена подтверждающими доказательствами)
Внешняя оценка соответствия требованиям безопасности должна проводиться независимой аккредитованной компанией.
Критерии проверки внешней платформы
Оценка SOC 2 типа 2
- Отчет SOC 2 должен быть отчета типа 2
- Аудит SOC 2 должен включать оцениваемую среду M365
- Аудит SOC 2 должен быть завершен в течение последних 12 месяцев
- Элементы управления должны быть честно представлены и должным образом оформлены, как это требуется для отчета типа 2
- Аудит SOC 2 должен проводиться квалифицированной внешней третьей стороной
- Процедуры тестирования должны подтверждать наличие средств контроля безопасности и их надлежащую проверку аудитором.
Оценка ISO 27001
- Аудит ISO 27001 должен включать среду, указанную в этой оценке M365
- Сертификат ISO 27001 должен быть актуальным и применимым к предприятию
- Оценка ISO 27001 должна проводиться аккредитованной внешней третьей стороной (внутренние аудиты ISO 27001 не принимаются)
- Оценка ISO 27001 должна быть завершена в течение последних 12 месяцев
Оценка PCI-DSS
- В документе AOC должна быть четко определена оцениваемая среда M365
- AOC должен быть датированным
- AOC должен быть подписан QSA и организацией