Предотвращение недопустимого распространения секретной информации для австралийского правительства

В этой статье приводятся рекомендации для австралийских государственных организаций по настройке, чтобы снизить риск неуместного раскрытия конфиденциальной информации через службы Microsoft 365. Его цель — помочь организациям улучшить состояние информационной безопасности. Рекомендации, приведенные в этой статье, соответствуют требованиям, изложенным в разделе Защита политики безопасности (PSPF) и Руководстве по информационной безопасности (ISM).

Для настройки политик, обсуждаемых в этой статье, требуется знание Защита от потери данных Microsoft Purview (DLP). Вводные рекомендации по защите от потери данных в Microsoft Purview см. в статье Сведения о защите от потери данных.

Ограничение распространения секретной информации по электронной почте

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

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

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

Ограничение распространения секретной информации по электронной почте неавторизованным организациям

Требование 77 PSPF 2024 гласит, что соглашение должно быть заключено до того, как секретная информация будет передана внешнему пользователю или организации:

Чтобы выполнить это требование PSPF, правительственные организации должны рассмотреть следующие аспекты:

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

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

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

1. Выберите условие для общего доступа к содержимому из Microsoft 365пользователям за пределами моей организации.
2. Выберите второе условие содержимого, содержащееметку конфиденциальности и выбранные соответствующие метки (например, метку PROTECTED и связанные вложенные метки).
3. Выберите вторую группу условий, связанную с помощью операнда AND .
   1. Для второй группы задано значение NOT.
   2. Вторая группа содержит условие домена получателя вместе со списком доменов, которые утверждены для получения выбранных классификаций безопасности.
4. Выберите действие, которое блокирует или перенаправляет электронную почту получателям, которые не из одного из настроенных доменов получателей.

Пример правила защиты от потери данных: блокировка защищенной электронной почты для неутвержденных организаций

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

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

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

Разрешение распространения секретной информации по электронной почте авторизованным гостям

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

Авторизованное гостевое разрешение достигается с помощью:

• Создание групп, обслуживаемых вручную (например, защищенных гостей), в которых содержатся гости из утвержденных внешних организаций, у которых была проверена проверка состояния разрешения; или

• Создание динамических групп, настроенных для включения гостевых учетных записей из указанных доменов. Этого можно добиться за счет использования динамических запросов, оценивая имена участников-пользователей (UPN). Например:

  (user.userPrincipalName -match "#EXT#") and (user.userPrincipalName -match "microsoft.com")

Дополнительные сведения о динамическом членстве в группах см. в разделе Правила динамического членства для групп в Microsoft Entra идентификаторе.

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

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

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

1. Выберите условие для общего доступа к содержимому из Microsoft 365пользователям за пределами моей организации.
2. Выберите второе условие содержимого, содержащееметку конфиденциальности и выбранные соответствующие метки (например, метку PROTECTED и связанные вложенные метки).
3. Выберите вторую группу условий, связанную с помощью операнда AND .
   1. Для второй группы задано значение NOT.
   2. Он содержит условие получателя является членом, защищенных гостей.
4. Выберите действие, которое блокирует или перенаправляет сообщения электронной почты получателям, которые не входят в выбранную группу.

Пример правила защиты от потери данных: блокировка защищенной электронной почты для неутвержденных гостей

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

Предотвращение распространения секретной информации по электронной почте среди несанкционированных пользователей

Требование 75 PSPF 2024 касается уровней зазора, необходимых для доступа к конфиденциальной информации:

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

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

Настройка политики защиты от потери данных для удовлетворения следующих требований:

• Условия содержимого передаются из Microsoft 365людям в моей организации.
• Условие Содержимого содержит любые из этих меток конфиденциальности с выбранными соответствующими метками (например, все защищенные метки).
• Группа условий, связанная с помощью операнда AND . Вторая группа с параметром NOT с условием содержать получателя является членом защищенныхпользователей.
• Правила требуют действия, которые блокируют или перенаправляют сообщения электронной почты получателям, которые не входят в настроенную группу.

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

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

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

Добавление учета защитной маркировки

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

Предотвращение отправки неавторизованных пользователей по электронной почте секретной информации

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

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

• Условие Содержимого содержит любые из этих меток конфиденциальности с выбранными соответствующими метками (например, все защищенные метки).
• Группа условий, связанная с помощью операнда AND . Вторая группа с параметром NOT с условием содержать получателя является членом защищенныхпользователей.
  • Содержать условие отправителя является членом защищенныхпользователей.
• Для правил потребуется действие, которое блокирует или перенаправляет электронную почту получателям, которые не входят в настроенную группу.

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

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

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

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

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

Каждая организация имеет конфигурацию общего доступа по умолчанию, которая настраивается с помощью конфигурации общего доступа SharePoint. Это позволяет настроить список доменов, утвержденных для получения ссылок общего доступа. Такая конфигурация соответствует требованию 77 PSPF 2024.

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

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

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

Когда пользователь игнорирует подсказку политики и пытается поделиться защищенным элементом извне, в диалоговом окне общего доступа отображается подсказка политики:

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

Предотвращение распространения классифицированных элементов безопасности через чат Teams

Сведения об использовании microsoft Purview DLP для защиты Microsoft Teams см. в разделах Защита от потери и Microsoft Teams.

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

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

Другие сценарии совместного использования

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

Что делать, если участник безопасного расположения, например команда PROTECTED, использует элемент некорректно?

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

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

• Помеченные расположения могут быть дополнительно ограничены. Использование PowerShell для настройки метки MemberShareNone позволяет владельцам сайта или группы управлять распределением информации из расположений с примененной меткой. Дополнительные сведения об ограничениях общего доступа к участникам см. в разделе Общий доступ к участникам.

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

Что делать, если пользователь перемещает защищенный элемент в другое место, где общий доступ является более разрешительным?

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

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

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

• Расположение OneDrive может иметь более разрешительную политику общего доступа, чем к помеченному расположению. Чтобы снизить риски, связанные с общим доступом пользователей из OneDrive для обхода элементов управления на основе расположения, можно настроить политики защиты от потери данных, чтобы ограничить общий доступ к элементам с определенными метками из OneDrive. Политики также могут применяться через группы, что позволяет утвержденным пользователям делиться элементами с метками из своих расположений OneDrive с гостями, ограничивая при этом неутвержденных пользователей.

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

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

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

Рекомендации по конфигурациям управления внутренними рисками, относящиеся к австралийским государственным организациям, см. в разделе Управление внутренними рисками.

Предотвращение отправки классифицированных элементов безопасности в неуправляемые расположения

Defender for Cloud Apps — это решение Майкрософт, которое обеспечивает видимость приложений на основе SaaS и управление ими. Он предлагает интеграцию с Microsoft Purview через DLP и элементы управления общим доступом к данным.

Defender for Cloud Apps политики настраиваются в консоли Microsoft 365 Defender в менюПолитикиоблачных приложений>. Администраторы могут создавать политики, предназначенные для файлов с защищенными метками и предотвращающие их общий доступ к неутвержденным доменам. Эта конфигурация соответствует требованию 77 PSPF 2024, в котором говорится, что классифицированные элементы безопасности должны предоставляться только официально утвержденным организациям:

Дополнительные сведения об интеграции между Defender for Cloud Apps и Защита информации Microsoft Purview см. в разделе интеграция Защита информации Microsoft Purview.

Запрет копирования или печати элементов, классифицированных по безопасности

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

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

Защита от потери данных конечной точки (защита от потери данных в конечной точке) позволяет применять политики защиты от потери данных к действиям пользователей в зарегистрированных конечных точках. Сведения о процедурах подключения для защиты от потери данных в конечной точке см. в статье Начало работы с DLP конечной точки.

В качестве предварительного условия для эффективного управления защитой от потери данных в EndPoint организации для государственных организаций должны ограничить веб-браузеры только теми, которые используют microsoft 365 DLP. Chromium поддерживает защиту от потери данных, и Google Chrome и Firefox можно настроить защиту от потери данных с помощью надстройки браузера. Дополнительные сведения о расширении Microsoft Purview Chrome см. в статье Начало работы с расширением Microsoft Purview Chrome.

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

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

• Отправка элемента в домен облачной службы с ограниченным доступом (например, Google Drive) (как правило, блокировать в государственных организациях)
• Копирование из элемента в буфер обмена
• Копирование элемента на съемный USB-порт (как правило , блокировать с переопределением в государственных организациях)
• Копирование в общую сетевую папку
• Print
• Копирование или перемещение с помощью не разрешенного приложения Bluetooth (как правило, блокировать в государственных организациях)
• Копирование или перемещение с помощью протокола удаленного рабочего стола (обычно блокируются в организациях для государственных организаций)