Реализация стратегии политики данных

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

Установление политик данных идет в связке с стратегией вашей среды.

Быстрые факты

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

Классификация соединителей

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

• Бизнес: определенное приложение Power App или Power Automate ресурс может использовать один или несколько соединителей из бизнес-группы. Если Power App или ресурс Power Automate использует бизнес-соединитель, он не может использовать какие-либо соединители, не относящиеся к бизнесу.
• Некоммерческие: определенное приложение Power App или Power Automate ресурс могут использовать один или несколько соединителей из некоммерческих групп. Если Power App или ресурс Power Automate использует не бизнес-соединитель, он не может использовать какие-либо соединители, относящиеся к бизнесу.
• Заблокировано: ни одно приложение Power или Power Automate ресурс не может использовать соединитель из заблокированной группы. Все соединители премиум-класса, принадлежащие Microsoft, и соединители сторонних производителей (стандартные и расширенные) могут быть заблокированы. Стандартные соединители и Common Data Service соединители, принадлежащие Microsoft, не могут быть заблокированы.

Подробнее: Классификация соединителей

Детальный контроль

Более детального управления можно добиться, настроив управление действиями соединителя. С помощью управления действиями вы можете выбрать, какие действия на соединителе разрешены, а какие нет. Этот параметр предназначен для блокируемых соединителей, добавленных в группу небизнесовых или бизнес-данных политики. Используя его, вы можете разрешить создателям использовать действия «чтения», но не действия «изменения» на соединителе. При обновлении коннекторов появляются новые действия. Вы можете разрешить или запретить новые действия.

Другой способ получить более детальный контроль — настроить фильтрацию конечных точек коннектора. Фильтрация конечных точек позволяет администраторам определять, к каким конкретным конечным точкам могут подключаться создатели при создании приложений, потоков или чат-ботов. Фильтрация конечных точек соединителей применяется к шести соединителям: HTTP, HTTP с Microsoft Entra ID, HTTP Webhook, SQL Server, хранилище BLOB-объектов Azure и SMTP. Правила применяются только в том случае, если создатель использует статическое значение для указания конечной точки.

Платформа Power Platform позволяет создателям создавать настраиваемые соединители и публиковать их. Вы можете управлять пользовательскими соединителями для политик данных на уровне клиента и среды.

В частности:

• Администраторы сред могут использовать центр администрирования Power Platform для классификации отдельных настраиваемых соединителей по имени для политик данных на уровне среды.
• Администраторы клиентов могут использовать центр администрирования Power Platform и PowerShell для классификации настраиваемых соединителей по конечным точкам URL-адресов хоста с помощью конструкта сопоставления с образцом для политик данных на уровне клиента.

Политики данных для Copilot Studio

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

Политики данных для потоков настольных приложений

Power Automate позволяет создавать и применять политики данных, которые классифицируют модули настольных потоков и отдельные действия модуля как бизнесовые, небизнесовые или заблокированные. Эта категоризация не позволяет создателям объединять модули и действия из разных категорий в классический поток или между облачным потоком и классическими потоками, которые он использует. Узнайте больше о политиках данных для рабочих процессов на настольных компьютерах.

Стратегии создания политик данных

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

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

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

Мы рекомендуем использовать следующую отправную точку для политик данных для рабочих сред (бизнес-единиц и проектов):

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

Мы также рекомендуем:

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

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

• Отклонение запроса.
• Добавьте соединитель в политику данных по умолчанию.
• Добавьте среды в список "Все, кроме" для глобальной политики данных по умолчанию и создайте политику для конкретного сценария использования, включая исключение.

Пример: стратегия данных Contoso

Давайте рассмотрим, как компания Contoso Corporation, которая служит примером в этом руководстве, настроила свои политики данных. Настройка политик данных тесно связана со своей стратегией среды.

Администраторы Contoso хотят поддерживать сценарии повышения производительности пользователей и команд, бизнес-приложения и управление деятельностью Центра передового опыта (CoE).

Администраторы Contoso применяют стратегию политики в области среды и данных, которая включает следующие элементы:

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

2. Администраторы Contoso создают еще одну общую среду, где пользователи могут создавать приложения для повышения производительности труда как отдельных пользователей, так и команд. Эта среда имеет связанную политику данных на уровне клиента, которая не является столь же рисковенной, как политика по умолчанию, и позволяет разработчикам использовать соединители, такие как службы Azure, в дополнение к службам Microsoft 365. Поскольку эта среда не является средой по умолчанию, администраторы активно контролируют список создателей сред для нее. Эта стратегия использует многоуровневый подход к общей среде производительности пользователей и команды и связанным параметрам данных.

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

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

5. У Contoso также есть специальная среда, предназначенная для их деятельности в центре передового опыта. В Contoso политика данных для среды специального назначения требует тщательного внимания, учитывая экспериментальный характер работы теоретических команд. В этом случае администраторы клиента делегируют управление данными для этой среды непосредственно доверенному администратору среды из команды CoE и исключают её из всех политик на уровне арендатора. Эта среда управляется только политикой данных уровня среды, которая является исключением, а не правилом в Contoso.

Как и ожидалось, любые новые среды, созданные в Contoso будут соответствовать исходной политике для всех сред.

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

Настройка политик данных

1. Создайте свою политику в центре администрирования Power Platform. Подробнее читайте в разделе Управление политиками данных.

2. Используйте DLP SDK для добавления пользовательских соединителей в политику данных.

Четкое взаимодействие политик данных организации с разработчиками

Настройте сайт или вики SharePoint, который четко сообщает:

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

Также четко донесите до производителей стратегию вашей организации по охране окружающей среды.

Следующие шаги

Ознакомьтесь с подробными статьями этой серии, чтобы еще больше повысить уровень своей безопасности:

• Обнаружьте угрозы для вашей организации
• Установить контроль за защитой данных и конфиденциальностью
• Настройте управление идентификацией и доступом
• Соответствие требованиям
• Защита среды по умолчанию

После ознакомления со статьями просмотрите контрольный список безопасности, чтобы убедиться, что Power Platform развертывания надежны, устойчивы и соответствуют передовым практикам.