Поделиться через

Защита по умолчанию с помощью Microsoft Purview и защита от чрезмерного совместного доступа — этап 4

  • Статья

Это руководство состоит из четырех этапов:

Защита по умолчанию с помощью Microsoft Purview и защита от чрезмерного совместного доступа — Схема

Этап 4. Стратегические действия— эксплуатация, расширение и ретроактивные действия

На этом заключительном этапе мы рассмотрим реализацию операционных процедур и выход за рамки Microsoft 365.

Операционный обзор поведения маркировки пользователей

Метка файлов является неотъемлемой частью этой схемы. Администраторы должны проверять рискованное поведение и конфигурации, которые не соответствуют стандартам.

Ниже приведены основные операционные сценарии, которые необходимо просмотреть:

  • Сайты без меток или Teams — используйте API Graph для идентификации сайтов и связи с владельцами сайтов или применения корректирующих мер.
  • Несоответствие между меткой сайта и меткой библиотеки по умолчанию. Используйте API Graph для выявления несоответствия и обращения к владельцам сайтов или применения корректирующих мер.
  • Использование защиты от потери данных (DLP) в SIT и неограниченных метках — перехват исключений с помощью защиты от потери данных, если содержимое помечается без защиты и предпринимается попытка совместного использования.
  • Ищите рискованных пользователей с помощью аудита управления внутренними рисками . Просмотрите рискованных пользователей и поведение, точно настраивайте политики IRM и реализуйте более строгую адаптивную защиту.

Итерации с новыми сценариями маркировки

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

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

Безопасная совместная работа с доверенными партнерами или мультитенантными организациями

В ситуациях, когда в вашей организации есть несколько клиентов или она открыто работает с доверенным партнером, рассмотрите возможность использования меток с шифрованием, поддерживающим несколько доменов, таких как @contoso.com + @adventureworks.com”.

Они будут помечены как конфиденциальные, так и строго конфиденциальные.

Проекты в палатках

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

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

Full-Time сотрудники, поставщики, оффшорные или региональные команды

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

  • сотрудники Full-Time (FTE)
  • Поставщиков
  • Офшорный
  • Регион или страна

В этом руководстве мы упростим маркировку до "Все сотрудники", но понимаем, что в некоторых случаях может потребоваться защита меток по-разному между FTE и поставщиками или партнерами, а иногда и для определенных регионов.

Как и в предыдущем сценарии, рекомендуется ограничить количество меток, видимых пользователям, не более чем 5 метками группы, каждая из которых по возможности не превышает 5 меток (5x5). В контексте маркировки по регионам или странам вы можете нацелить публикацию на соответствующих пользователей и использовать контейнеры для маркировки файлов, чтобы упростить использование по умолчанию наиболее подходящей метки.

Присвоение меток локальным общим папкам и серверу SharePoint

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

Примечание.

Остальные локальные сценарии см. в статье Сведения о сканере Защита информации Microsoft Purview.

Использование собственного ключа (BYOK) и шифрования двойного ключа (DKE)

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

Дополнительные сведения о BYOK см. здесь: Шифрование служб и управление ключами — Microsoft Purview

Дополнительные сведения о DKE см. здесь: Шифрование с двойным ключом (DKE)

Настройка цепочки отчетности и управления жизненным циклом

Расширение возможностей совместной работы с SharePoint включает в себя обязанности владельцев сайтов. Важно реализовать цепочку подотчетности и управления жизненным циклом со следующими рекомендациями:

  • Более 2 владельцев сайтов на всех сайтах . Используйте политики владения сайтом, чтобы идентифицировать сайты без по крайней мере двух владельцев и связаться с текущими владельцами или участниками для разрешения.
  • Неактивный сайт — политики неактивных сайтов для удаления неиспользуемых сайтов.
  • Аттестация сайта — требуется, чтобы владельцы сайтов регулярно тестировать сайты.
  • Просмотр содержимого, к которым предоставлен общий доступ всем пользователям, кроме внешних пользователей. Используйте отчеты SharePoint Advanced Management, чтобы определить содержимое, к которым предоставлен доступ всем пользователям, кроме гостей, и связаться с владельцами сайтов.
  • Проверки доступа к сайту . Используйте расширенное управление SharePoint, проверьте управление данными сайта и инициируйте проверку доступа к сайту, особенно для сайтов с большим объемом общего доступа или доступа.

Расширение защиты для Azure SQL и хранилища, отличного от Microsoft 365

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

  • База данных SQL Azure
  • Хранилище BLOB-объектов Azure
  • Azure Data Lake Storage 2-го поколения
  • Контейнеры Amazon S3

Microsoft Purview — это сочетание того, что ранее называлось Azure Purview и Microsoft Purview. Этот интерфейс теперь доступен на новом портале Microsoft Purview с июля 2024 г. Она позволяет администраторам безопасности данных настраивать метки, автоматические метки и политики защиты как в Microsoft 365, так и в microsoft 365.

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

Аналогичным образом для базы данных Azure SQL политики защиты ограничивают доступ к столбцу, если найдено конфиденциальное содержимое и столбец помечен. Доступны детализированные конфигурации, позволяющие настроить, кто может сохранять доступ к каждому ресурсу данных.

Этап 4. Сводка

См. также