Обзор платформы сертификации Microsoft 365
В этой статье содержатся подробные сведения, включая список элементов управления безопасностью сертификации 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)
Важно!
Сертификация 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 с регистрацией приложения. Проверка издателя
Аттестация издателя — это процесс самообслуживания, в котором поставщики программного обеспечения отвечают на ряд вопросов о рекомендациях по безопасности и обработке данных приложения. Приложения могут быть аттестованы издателем в Центре партнеров Майкрософт и получать недопустимые и выделенные фильтры в Microsoft AppSource Marketplace по завершении.
Проверка условий элемента управления Для получения сертификации не требуется соблюдать все элементы управления. Однако для каждого из трех доменов безопасности, обсуждаемых в этом обзорном документе, установлены пороговые значения (которые не будут раскрыты). Они должны быть пройдены. Некоторые элементы управления будут классироваться как "жесткий сбой", что означает, что отсутствие этих элементов управления безопасностью приведет к неудачной оценке.
Важно!
Интервал времени отправки: В среднем процесс оценки должен занять 30 дней при условии, что поставщики программного обеспечения могут часто проверка состояние отправки и своевременно отвечать на комментарии и дополнительные запросы на доказательства. После начала процесса сертификации допускается не более 60 дней для завершения оценки. Если все отправки не были завершены в течение 60-дневного периода времени, отправка будет выдана сбой, и процесс должен начаться снова. Эти результаты не будут обнародованы.
Сертификация область
Среда в область поддерживает доставку кода приложения или надстройки и поддерживает любые серверные системы, с которыми может взаимодействовать приложение или надстройка. Все дополнительные среды, подключенные к среде в область, также будут включены в область, если не будет проведена достаточная сегментация и подключенные к среде не могут повлиять на безопасность среды в область.
Все отдельные среды аварийного восстановления также должны быть включены в среду в область, так как эти среды потребуются для выполнения службы, если что-либо произойдет с основной средой. Кроме того, необходимо включить удаленные среды резервного копирования, так как в этих средах могут храниться данные Майкрософт, поэтому необходимо иметь соответствующие средства управления безопасностью.
Термин область системные компоненты ссылается на все устройства и системы, используемые в определенной среде область. Компоненты область включают, но не ограничиваются следующими:
- Веб-приложения
- Серверы (физические или виртуальные, которые могут быть локальными или облачными)
- Элементы управления безопасностью сети (NSC), такие как брандмауэры
- Параметры
- Подсистемы балансировки нагрузки
- Виртуальная инфраструктура
- Порталы веб-управления поставщиков облачных служб
- Облачные ресурсы (Виртуальные машины, Служба приложений, учетные записи хранения, экземпляры EC2 и т. д.)
Важно!
Общедоступные компоненты системы подвержены атакам со стороны внешних субъектов угроз и поэтому подвергаются гораздо большему риску. Как правило, эти системы сегментируются от других внутренних системных компонентов с помощью средства управления безопасностью сети (NSC), создавая демилитаризованную зону (DMZ). Намерение заключается в том, что dmz является менее доверенным, чем внутренняя сеть, и дополнительная безопасность поможет еще больше защитить внутренние системы и данные в случае компрометации общедоступных систем. В идеале будет использоваться dmz, однако это нецелесообразно или даже необходимо в некоторых сценариях развертывания.
Инфраструктура как услуга (IaaS), Платформа как услуга (PaaS) и Программное обеспечение как услуга (SaaS)
Если IaaS и (или) PaaS используется для поддержки рассматриваемой среды область, поставщик облачной платформы будет отвечать за некоторые средства управления безопасностью, оцениваемые в процессе сертификации. Аналитикам потребуется обеспечить независимую внешнюю проверку рекомендаций по обеспечению безопасности поставщиком облачной платформы с помощью внешних отчетов о соответствии требованиям, таких как PCI DSS, аттестация соответствия (AOC), отчеты ISO 27001 или SOC 2 типа II.
В приложении C содержатся сведения о том, какие элементы управления безопасностью, скорее всего, будут применяться в зависимости от следующих типов развертывания и в зависимости от того, эксфильтрует ли приложение данные Microsoft 365:
- Размещено в isv
- Размещено в IaaS
- PaaS/бессерверное размещение
- Гибридное размещение
- Общая размещенная
При развертывании IaaS или PaaS необходимо предоставить свидетельство, проверяющее соответствие среды этим типам развертывания.
Выборки
Запросы на подтверждение в поддержку оценки сертификации должны основываться на выборке область системных компонентов с учетом различных операционных систем, основной функции устройства, различных типов устройств (например, серверов, NSC, маршрутизаторов и т. д.) и расположения. Подходящий образец будет выбран в начале процесса сертификации. В качестве руководства следует использовать следующую таблицу, в которой выборка будет определяться на основе описанных выше факторов:
| Размер населения | Пример |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
Примечание.
Если между устройствами, включенными в исходную выборку, обнаружены несоответствия, во время оценки размер выборки может быть увеличен.
Комплексный процесс сертификации
Чтобы начать сертификацию Microsoft 365:
Перейдите в Центр партнеров и завершите аттестацию издателя. Если отправка старше трех месяцев, отправьте повторно для проверки и проверки.
В Центре партнеров выберите "Начать сертификацию", чтобы начать первоначальную отправку документа. Это поможет аналитикам сертификации определить, что область для оценки на основе архитектуры приложения и того, как оно обрабатывает данные Майкрософт.
Совет
Пошаговые инструкции по сертификации приложения Microsoft 365 см. в этом руководстве .
Процесс сертификации выполняется в два этапа, как описано ниже.
Первоначальная отправка документов помогает аналитику понять приложение, потоки данных, определить среду в область, определить, какие элементы управления безопасностью применимы, и определить системные компоненты, из которых потребуется собрать доказательства. Поставщик программного обеспечения должен предоставить запрошенную информацию, чтобы помочь аналитику сертификации завершить этот этап процесса, который составляет примерно 5 % от общего процесса.
Полная проверка доказательств — это процесс, в ходе которого isv представляет артефакты доказательства, демонстрирующие, как среда в область соответствует элементам управления безопасностью. На этом этапе аудита, который является оставшейся частью процесса, между isv и аналитиком будет несколько взаимодействий.
Оценка
После принятия первоначальной отправки документа набор элементов управления безопасностью будет автоматически отображаться на портале. Поставщики программного обеспечения должны предоставлять доказательства для каждого элемента управления, демонстрирующие наличие элемента управления и наличие 60 дней для отправки всех доказательств. Аналитик проверит доказательства и либо утвердит контроль, либо запросит новые или дополнительные доказательства.
Сертификация
После проверки отправки аналитиком поставщики программного обеспечения получают уведомление о решении о сертификации. Приложения, получиющие сертификацию, получат значок на своем приложении в AppSource и специальные страницы документации Майкрософт с подробным отчетом об их атрибутах безопасности и соответствия требованиям.
Проверка и повторная сертификация
Сертифицированные приложения Microsoft 365 должны проходить повторную сертификацию на ежегодной основе. Это потребует повторной проверки элементов управления в область по отношению к текущей среде в область. Этот процесс может начаться за 90 дней до истечения срока действия сертификации. Срок действия существующих сертификатов не истечет в течение периода повторной сертификации. Срок действия повторной сертификации для всех программ истекает в год сертификации Microsoft 365.
Если сертификация не продлевается до истечения срока действия, состояние сертификации приложений будет отозвано. Все символы, значки и связанные с ними символы сертификации будут удалены из вашего приложения, а независимым поставщикам программного обеспечения будет запрещено рекламировать ваше приложение как сертифицированное для 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).
- При необходимости нет отчета о тестировании на проникновение.
- Защита от вредоносных программ отсутствует.
- Многофакторная проверка подлинности не используется для защиты административного доступа.
- Нет процессов исправления.
- Нет подходящего уведомления о конфиденциальности GDPR .
Безопасность приложений
Домен безопасности приложений сосредоточен на трех областях:
- Проверка разрешений GraphAPI
- Внешние проверки подключения
- Тестирование на проникновение
Проверка разрешений GraphAPI
Проверка разрешений GraphAPI выполняется для проверки того, что приложение или надстройка не запрашивает слишком разрешительные разрешения. Это выполняется путем ручной проверки запрашиваемых разрешений. Аналитики сертификации будут перекрестно ссылаться на эти проверки в соответствии с отправкой аттестации издателя и оценивать уровень запрашиваемого доступа, чтобы убедиться, что соблюдаются методы "наименьших привилегий". Если аналитики по сертификации считают, что эти методы "наименьших привилегий" не выполняются, аналитики сертификации будут открыто обсудить с ISV, чтобы проверить бизнес-обоснование запрашиваемых разрешений. Все несоответствия в отправке аттестации издателя, обнаруженные в ходе этой проверки, необходимо исправить.
Проверки внешнего подключения
В рамках оценки будет выполнено легкое пошаговое руководство по функциональным возможностям приложений, чтобы определить все подключения, выполняемые за пределами Microsoft 365. Все подключения, которые не определены как microsoft или прямые подключения к вашей службе, будут помечены и обсуждены во время оценки.
Тестирование на проникновение
Адекватный анализ рисков, связанных с приложением или надстройкой и вспомогательной средой, имеет важное значение для обеспечения клиентам уверенности в безопасности приложения или надстройки. Тестирование безопасности приложений в форме тестирования на проникновение должно выполняться, если ваше приложение имеет какое-либо подключение к какой-либо службе, не опубликованной корпорацией Майкрософт. Если после развертывания приложение работает с автономным доступом только к службе Майкрософт, например GraphAPI, то тестирование на проникновение не требуется. Тестирование на проникновение по-прежнему требуется, если среда в область размещена в Azure.
область тестирования на проникновение
Для внутреннего и внешнего тестирования на проникновение инфраструктуры все действия по тестированию на проникновение должны выполняться в динамической рабочей среде, поддерживающей развертывание приложения или надстройки (например, где размещается код приложения или надстройки, который обычно является ресурсом в файле манифеста), а также в любых дополнительных средах, поддерживающих работу приложения или надстройки (например, Значение , если приложение или надстройка взаимодействует с другими веб-приложениями за пределами Microsoft 365). При определении область для тестирования на проникновение необходимо соблюдать осторожность, чтобы все системы или среды , подключенные к , которые могут повлиять на безопасность область среды, также включены в все действия по тестированию на проникновение.
Рекомендуется провести тестирование на проникновение веб-приложений в динамической рабочей среде. Однако было бы приемлемо проводить тестирование только веб-приложения с помощью среды тестирования или UAT, при условии, что в отчете о тестировании на проникновение подтверждается, что та же база кода действовала в среде тестирования или UAT во время тестирования.
Если методы используются для сегментирования сред в область из других сред, действия по тестированию на проникновение должны проверять эффективность указанных методов сегментации. Это должно быть подробно описано в отчете о тестировании на проникновение.
Примечание.
Необходимо выполнить внутреннее тестирование на проникновение, если среда размещения не классизована только как PaaS.
Требования к тестированию на проникновение
Отчеты о тестировании на проникновение будут проверены, чтобы убедиться, что нет уязвимостей, которые соответствуют следующим критериям автоматического сбоя , описанным в элементах управления ниже.
| Тип условия | Элементы управления тестом на проникновение |
|---|---|
| Общие критерии | Тестирование на проникновение веб-приложений и внутренней (если применимо) и внешней инфраструктуры должно выполняться ежегодно (каждые 12 месяцев) и проводится независимой компанией. |
| Исправление выявленных критических уязвимостей и уязвимостей с высоким риском должно быть завершено в течение одного месяца после завершения тестирования на проникновение или раньше в зависимости от задокументированного процесса исправления поставщика программного обеспечения. | |
| Полный внешний объем (IP-адреса, URL-адреса, конечные точки API и т. д.) Должны быть включены в область тестирования на проникновение и должны быть четко задокументированы в отчете о тестировании на проникновение. | |
| Если среда не соответствует PaaS, все внутренние сети должны быть включены в область тестирования на проникновение и должны быть четко задокументированы в отчете о тестировании на проникновение. | |
| Тестирование на проникновение веб-приложений должно включать все классы уязвимостей; например, самый актуальный OWASP Top 10 или SANS Top 25 CWE. Рекомендация заключается в том, что это подробно описано в отчете о тестировании на проникновение, в противном случае это будет трудно продемонстрировать. | |
| Критические уязвимости и уязвимости с высоким риском или уязвимости, которые считаются автоматическим сбоем , должны быть повторно протестированы компанией по тестированию на проникновение и четко выделены как зафиксированные в отчете о тестировании на проникновение. | |
| Условия автоматического сбоя: | Наличие неподдерживаемой операционной системы или неподдерживаемой библиотеки JavaScript. |
| Наличие учетных записей администратора по умолчанию, перечисляемых или угадываемых учетных записей. | |
| Наличие рисков внедрения кода SQL. | |
| Наличие междоменных сценариев. | |
| Наличие уязвимостей обхода каталога (путь к файлу). | |
| Наличие уязвимостей HTTP, например разделение ответа заголовка, контрабанда запросов и десинхронные атаки. | |
| Наличие раскрытия исходного кода (включая LFI). | |
| Любая критическая или высокая оценка, определенная в рекомендациях по управлению исправлениями CVSS. | |
| Любая значительная техническая уязвимость, которую можно легко использовать для компрометации большого количества EUII или OUI. |
Важно!
Отчеты должны иметь достаточно уверенности в том, что все подробное описание в разделе требований к тестированию на проникновение выше может быть продемонстрировано.
Требования и правила бесплатного тестирования на проникновение
- Для поставщиков программного обеспечения, которые в настоящее время не участвуют в тестировании на проникновение, тестирование на проникновение можно проводить бесплатно для сертификации Microsoft 365. Корпорация Майкрософт организует и покрывает расходы на тест на проникновение в течение 12 дней ручного тестирования. Затраты на тесты на проникновение рассчитываются на основе количества дней, необходимых для тестирования среды в область. За любые расходы, превышающие 12 дней тестирования, несет isv.
- Поставщики программного обеспечения должны будут представить доказательства и получить одобрение для 50% элементов контроля в область до проведения испытания на проникновение. Чтобы приступить к работе, заполните свою первоначальную отправку документа и выберите, чтобы тестирование на проникновение было включено в рамках оценки. С вами свяжутся, чтобы область и запланировать тест на проникновение после завершения 50 % элементов управления.
- Отчет, выданный после завершения теста пером, будет предоставлен isv после завершения сертификации. Этот отчет вместе с сертификацией 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-подключение, поддерживающее как минимум TLS версии 1.1. (Рекомендуется использовать ПРОТОКОЛ TLS версии 1.2+). См.приложение A.
Если приложение получает и хранит данные Microsoft 365, вам потребуется реализовать схему шифрования хранилища данных, которая соответствует спецификации, определенной в приложении Б.
Элементы управления
| Семейство элементов управления | Controls |
|---|---|
| Передаваемые данные | Предоставьте подтверждение того, что конфигурация TLS имеет значение TLS 1.2 или выше в соответствии с требованиями к конфигурации профиля TLS , а также что инвентаризация доверенных ключей и сертификатов хранится и обслуживается. |
| Предоставьте свидетельство о том, что сжатие TLS отключено для всех общедоступных служб, обрабатывающих веб-запросы, чтобы предотвратить утечку данных коэффициента сжатия сделано easy (CRIME), а протокол HSTS TLS включен и настроен на 180 дней на всех сайтах. | |
| Неактивные данные | Предоставьте доказательства того, что неактивные данные шифруются в соответствии с требованиями профиля шифрования, используя такие алгоритмы шифрования, как Расширенный стандарт шифрования (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 или SOC2, вы можете использовать эти сертификаты для удовлетворения некоторых элементов управления сертификацией Microsoft 365. Аналитики попытаются согласовать существующие внешние платформы безопасности с платформой сертификации Microsoft 365. Однако если в вспомогательной документации не удается убедиться, что элементы управления сертификацией Microsoft 365 были оценены как часть аудита и оценки внешних платформ безопасности, вам потребуется предоставить дополнительные доказательства наличия указанных элементов управления.
Документация должна надлежащим образом продемонстрировать, что среда область для сертификации Microsoft 365 была включена в область этих внешних платформ безопасности. Проверка этих платформ безопасности будет выполняться путем принятия подтверждения действительных сертификатов, проведенных авторитетными внешними сторонними компаниями. Эти авторитетные компании должны быть членами международных органов аккредитации для соответствующих программ соответствия. См. статью Стандарты сертификации и соответствия ISO для 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 — это лишь небольшое подмножество этих стандартов и платформ безопасности, что позволяет корпорации Майкрософт получить уровень уверенности в отношении вашего состояния безопасности.
Требования к использованию внешних платформ соответствия требованиям
✓ Среда в область И любые вспомогательные бизнес-процессы должны быть включены в область любых поддерживаемых внешних платформ соответствия требованиям безопасности и должны быть четко указаны в предоставленной документации.
✓ Поддерживаемые внешние платформы соответствия требованиям безопасности должны быть актуальными, то есть в течение последних 12 месяцев (или в течение 15 месяцев, если в настоящее время проводится переоценка и могут быть предоставлены доказательства).
✓ Поддерживаемые внешние платформы соответствия требованиям безопасности должны выполняться независимой аккредитованной компанией.