Планирование реализации Power BI: планирование безопасности потребителей

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется интерфейсу Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

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

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

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

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

Чтобы получить больше всего из этой статьи, полезно понять смысл терминов совместного использования и распространения в контексте Power BI.

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

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

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

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

Внимание

Роль администратора Power BI переименована. Новое имя роли — администратор Fabric.

Стратегия для потребителей только для чтения

В служба Power BI потребители могут просматривать отчет или панель мониторинга, если у них есть разрешение на оба:

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

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

• Предоставление пользователям и группам доступа к приложению Power BI.
• Добавление пользователей и групп в роль средства просмотра рабочей области Power BI.
• Предоставление пользователям и группам разрешений для каждого элемента с помощью ссылки общего доступа.
• Предоставление пользователям и группам разрешений для каждого элемента с помощью прямого доступа.

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

Совет

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

При просмотре параметров безопасности для элемента может появиться следующее:

• Наследуется от рабочей области или приложения.
• Применяется непосредственно к элементу.

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

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

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

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

Разрешения приложения Power BI

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

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

Примечание.

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

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

Совет

Дополнительные сведения об использовании приложения Power BI для широкого распространения содержимого см. в сценарии использования бизнес-аналитики предприятия. Рекомендуется, чтобы создатели контента, которые должны распространять содержимое, рассмотрите возможность создания приложения в качестве первого выбора.

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

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

Все пользователи с доступом к рабочей области могут автоматически просматривать приложение (когда приложение Power BI опубликовано для рабочей области). Из-за этого вы можете концептуально рассматривать роли рабочей области как унаследованные каждой аудиторией приложений. Некоторые пользователи с доступом к рабочей области также могут обновлять приложение Power BI в зависимости от назначенной роли рабочей области.

Совет

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

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

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

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

• Немедленные изменения семантической модели: изменения семантической модели всегда вступают в силу немедленно. Например, если вы вводите критические изменения в семантической модели в рабочей области, она может непреднамеренно привести к нестабильности отчетов (даже если они не были повторно опубликованы в приложении). Существует два способа устранения этого риска. Во-первых, выполните все действия по разработке в Power BI Desktop (отдельно от рабочей области). Во-вторых, изоляция рабочего приложения с помощью отдельных рабочих областей для разработки и тестирования. (При необходимости можно добиться более высокого уровня контроля над развертыванием содержимого рабочей области от разработки до тестирования и рабочей среды с помощью конвейеров развертывания.)
• Содержимое и разрешения публикуются вместе: при публикации приложения его разрешения публикуются одновременно с содержимым. Например, у вас могут быть изменения отчета в рабочей области, которая еще не завершена, полностью протестирована или утверждена. Таким образом, вы не можете повторно опубликовать приложение только для обновления разрешений. Чтобы устранить этот риск, назначьте разрешения приложений группам безопасности и используйте членства в группах безопасности (а не отдельных пользователей) при предоставлении разрешений приложения. Избегайте повторной публикации приложения только для применения изменений разрешений.

Аудитория приложений

Каждая рабочая область в служба Power BI может иметь только одно приложение Power BI. Однако в приложении можно создать одну или несколько аудиторий. Рассмотрим следующий сценарий.

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

Эта возможность смешивать и сопоставлять содержимое и аудитории имеет следующие преимущества.

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

На следующем снимках экрана показано приложение с двумя аудиториями: "Руководство по продажам " и "Республика продаж". Панель "Управление доступом к аудитории" предоставляет доступ к группе аудитории "Руководство по продажам" для двух групп безопасности: "Руководство по продажам" Северная Америка и "Руководство по продажам" в Европе. Отчет о валовом анализе маржи, показанный на снимке экрана для группы аудитории "Руководство по продажам", недоступен группе аудитории Sales Reps .

Примечание.

Иногда используется группа аудитории терминов. Это не прямая ссылка на использование групп безопасности. Он включает членов целевой аудитории, которые увидят коллекцию содержимого в приложении Power BI. Хотя вы можете назначить отдельных пользователей аудитории, рекомендуется назначать группы безопасности, группы Microsoft 365 или группы рассылки всякий раз, когда это практически. Дополнительные сведения см. в стратегии использования групп в статье планирования безопасности на уровне клиента.

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

Совет

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

Параметры разрешения приложения

При создании (или повторной публикации) приложения каждая аудитория имеет область "Управление доступом к аудитории". В этой области доступны следующие разрешения.

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

Возможность добавления разрешений повторного доступа к семантической модели или сборки при публикации приложения удобна. Однако рекомендуется управлять разрешениями приложений и разрешениями семантической модели отдельно. Вот почему.

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

Совет

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

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

После публикации приложения Power BI пользователь обычно должен установить его, чтобы он смог открыть его. Пользователь может установить приложение на странице "Приложения" в служба Power BI или с помощью ссылки, полученной от другого пользователя. Они смогут найти (и установить) приложение, если они включены по крайней мере в одну аудиторию приложения.

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

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

Совет

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

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

• Определите стратегию использования приложений: определите параметры использования приложений. Убедитесь, что она соответствует вашей общей стратегии для потребителей только для чтения.
• Решите, кто может публиковать приложения в всей организации: решите, какие создатели отчетов могут публиковать в всей организации. Задайте для приложения публикации значение всего клиента организации , чтобы оно соответствовало этому решению.
• Решите, кто может отправлять приложения конечным пользователям: решите, какие создатели отчетов Power BI могут предварительно установить приложения. Задайте для конечных пользователей параметры клиента push-приложений, чтобы выровнять это решение.
• Создание и публикация рекомендаций для создателей контента: предоставление документации и обучения создателям контента. Включите требования и предпочтения для эффективного использования приложений.
• Определите, как обрабатывать запросы доступа к приложению: убедитесь, что процесс выполняется для назначения контактов и обработки запросов на доступ к приложениям своевременно.

Роль средства просмотра рабочей области

Как описано в статьях планирования рабочей области, основная цель рабочей области — совместная работа. Сотрудники рабочей области, такие как создатели семантической модели, создатели отчетов и тестировщики, должны быть назначены одной из трех ролей: участник, член или Администратор. Эти роли описаны в статье планирования безопасности создателя контента.

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

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

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

Ниже приведены некоторые рекомендации по поддержке средств просмотра рабочих областей.

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

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

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

Разрешения для каждого элемента

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

Разрешения для каждого элемента являются хорошим выбором, когда:

• Вы хотите предоставить доступ только для чтения к одному элементу (отчету или панели мониторинга).
• Вы не хотите, чтобы потребитель просматривал все содержимое, опубликованное в рабочей области.
• Вы не хотите, чтобы потребитель просматривал все содержимое, опубликованное в аудитории приложения.

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

Совет

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

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

Внимание

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

При совместном использовании отдельного элемента у вас есть несколько параметров разрешений.

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

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

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

Существует три конкретных типа общего доступа: ссылки для общего доступа, прямой общий доступ и общие представления.

Ссылки на разрешения для каждого элемента

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

• Люди в организации: При включении в параметрах клиента Power BI этот тип ссылки для общего доступа является простым способом предоставления доступа только для чтения всем пользователям в организации. Однако ссылка на общий доступ не будет работать для внешних пользователей. Этот вариант лучше всего подходит, когда любой пользователь может просматривать содержимое, и ссылка может быть свободно предоставлена всей организации. Если ссылки разрешены для предоставления общего доступа всем пользователям в параметре клиента организации, этот тип общего доступа по умолчанию не отключен.
• Люди с существующим доступом: Этот параметр не создает новую ссылку для общего доступа. Скорее, он позволяет получить URL-адрес, чтобы отправить его пользователю, у которого уже есть доступ.
• Конкретные пользователи: этот параметр создает ссылку на общий доступ для определенных пользователей или групп. Рекомендуется использовать этот вариант чаще всего, так как он предоставляет конкретный доступ. Если вы обычно работаете с внешними пользователями, вы можете использовать эту ссылку для гостевых пользователей, которые уже существуют в идентификаторе Microsoft Entra (ранее известном как Azure Active Directory). Дополнительные сведения о запланированном процессе приглашения для создания гостевых пользователей см. в статье о планировании безопасности на уровне клиента.

Внимание

Рекомендуется ограничить ссылки allowable для предоставления доступа всем пользователям в параметре клиента организации участникам группы. Вы можете создать имя группы, например Power BI Share для всей организации, а затем добавить небольшое количество пользователей, которые понимают последствия общего доступа на уровне организации. Если вы обеспокоены существующими ссылками на уровне организации, вы можете использовать API администрирования, чтобы найти все элементы, которыми предоставлен общий доступ ко всей организации.

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

Совет

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

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

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

Разрешения прямого доступа для каждого элемента

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

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

Совет

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

Опубликованные представления

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

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

Контрольный список . При создании стратегии использования разрешений для каждого элемента ключевые решения и действия включают:

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

Другие методы запросов потребителей

Наиболее распространенными способами взаимодействия потребителей с Power BI являются приложения, рабочие области и разрешения для каждого элемента (ранее описанные в этой статье).

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

• Анализ в Excel. Потребители, которые предпочитают использовать Excel, могут запрашивать семантику Power BI с помощью анализа в Excel. Эта возможность является отличной альтернативой экспорту данных в Excel, так как данные не дублируются. При динамическом подключении к семантической модели пользователи могут создавать сводные таблицы, диаграммы и срезы. Затем они могут опубликовать книгу в рабочей области в служба Power BI, что позволяет потребителям открывать ее и взаимодействовать с ней.
• Конечная точка XMLA: потребители могут запрашивать семантику модели, подключаясь к конечной точке XMLA. Приложение, совместимое с XMLA, может подключаться, запрашивать и использовать семантические модели, хранящиеся в рабочей области Premium. Эта возможность полезна, если потребители хотят использовать семантику Power BI в качестве источника данных для средства визуализации данных за пределами экосистемы Майкрософт.
• Редактор Datamart: потребители могут запрашивать datamart Power BI с помощью редактора datamart. Это веб-редактор визуальных запросов для создания запросов без кода. Существует также веб-редактор SQL, когда потребители предпочитают писать запросы SQL. Оба редактора запрашивают управляемую База данных SQL Azure, которая лежит в основе объекта datamart Power BI (а не встроенной семантической модели).
• Конечная точка SQL: потребители могут запрашивать datamart Power BI с помощью конечной точки SQL. Они могут использовать такие средства, как Azure Data Studio или SQL Server Management Studio (SSMS) для выполнения запросов SQL. Конечная точка SQL направляет запросы к управляемому База данных SQL Azure, который лежит в основе datamart Power BI (а не встроенной семантической модели).

Дополнительные сведения о разрешении сборки см. в статье о планировании безопасности создателя содержимого.

Контрольный список . При планировании использования потребителей методов запроса ключевые решения и действия включают:

• Создание рекомендаций для пользователей по использованию анализа в Excel: предоставление документации и обучения потребителям лучшего способа повторного использования существующих семантических моделей с помощью Excel.
• Создание рекомендаций для пользователей по использованию конечной точки XMLA. Предоставление документации и обучения для потребителей лучше всего использовать существующие семантические модели с конечной точкой XMLA.
• Создание рекомендаций для пользователей по запросам datamart: предоставление документации и обучения для потребителей доступных методов запроса данных Power BI.

Запрос рабочего процесса доступа для потребителей

При совместном использовании содержимого один пользователь перенаправит ссылку (URL-адрес) другому пользователю. Когда получатель пытается просмотреть содержимое и обнаруживает, что у него нет доступа, он может выбрать кнопку "Запрос доступа ". Это действие инициирует рабочий процесс доступа к запросу. Затем пользователю будет предложено предоставить сообщение, чтобы объяснить, почему они хотят получить доступ.

Рабочий процесс доступа к запросу существует для:

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

Запросы на доступ к приложению

Существует два способа узнать о ожидающих запросах доступа, отправленных для приложения.

• Электронная почта: контакты для приложения получают уведомление по электронной почте. По умолчанию этот контакт является издателем приложения. Чтобы обеспечить более высокую поддержку критически важных приложений, рекомендуется настроить контакт для группы, которая может быстро реагировать на запросы доступа.
• Меню управления разрешениями: администраторы рабочей области и члены могут просматривать, утверждать или отклонять запросы на доступ. Страница "Управление разрешениями" доступна на странице "Приложения" и может быть открыта для каждого приложения. Эта возможность также доступна для рабочих областей участник, когда включено разрешение участник обновления приложения для этого параметра рабочей области.

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

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

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

Запросы доступа к рабочей области

Доступ к рабочей области предоставляется пользователями, принадлежащими к роли Администратор или роли участника.

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

Запросы на доступ к элементам

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

• Электронная почта: контакты для элемента получают уведомление по электронной почте. Чтобы обеспечить более высокую поддержку критически важных отчетов, рекомендуется настроить контакт для группы, которая может быстро реагировать на запросы на доступ.
• Меню управления разрешениями: администраторы рабочей области и члены могут получить доступ к странице "Управление разрешениями " для каждого элемента. Они могут просматривать, утверждать или отклонять ожидающие запросы доступа.

Управление запросами доступа с помощью групп

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

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

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

1. Отклоните ожидающий запрос в Power BI (так как он связан с отдельным пользователем).
2. Добавьте запрашиватель в правильную группу в соответствии с текущим процессом.
3. Уведомите запрашивающего, что у них теперь есть доступ.

Совет

Сведения о реагировании на запросы доступа от создателей см. в разделе "Запрос доступа к доступу к содержимому" для создателей контента. Она также содержит рекомендации по использованию формы для запросов на доступ.

Контрольный список. При планировании рабочего процесса доступа к запросу ключевые решения и действия включают:

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

Принудительное обеспечение безопасности данных на основе удостоверения потребителя

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

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

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

Безопасность данных можно выполнять несколькими способами.

• Семантическая модель Power BI: как создатель данных Power BI можно применить безопасность на уровне строк (RLS) и безопасность на уровне объектов (OLS). RLS включает определение ролей и правил, которые фильтруют строки модели данных, а OLS ограничивает доступ к определенным таблицам или столбцам. Эти определенные правила RLS и OLS не применяются к ссылкам, хранящимся вне семантической модели, например срезов и выбора фильтров. Методы RLS и OLS описаны далее в этом разделе.
• Службы Analysis Services: семантическая модель динамического подключения может подключаться к удаленной модели данных, размещенной службами Azure Analysis Services (AAS) или СЛУЖБАми SQL Server Analysis Services (SSAS). Удаленная модель может применять RLS или OLS на основе удостоверения потребителя.
• Источник данных: некоторые источники данных, такие как База данных SQL Azure, могут применять RLS. В этом случае модель Power BI может воспользоваться преимуществами существующей безопасности, а не переопределять ее. Такой подход может быть значительным преимуществом, если RLS, определенный в источнике, является сложным. Вы можете разрабатывать и публиковать модель DirectQuery и задавать учетные данные источника данных семантической модели в служба Power BI, чтобы включить единый вход. Когда потребитель отчета открывает отчет, Power BI передает удостоверение источнику данных. Затем источник данных применяет RLS на основе удостоверения потребителя отчета. Дополнительные сведения о База данных SQL Azure RLS см. в этой статье.

Примечание.

Исходные системы, такие как База данных SQL Azure, также могут использовать такие методы, как представления, чтобы сузить то, что пользователь может видеть. Хотя это допустимый метод, он не относится к фокусу этого раздела.

Безопасность на уровне строк

Безопасность на уровне строк (RLS) позволяет моделиировщику данных ограничить доступ к подмножествам данных. Обычно используется для обеспечения того, чтобы некоторые потребители отчетов не могли видеть определенные данные, такие как результаты продаж других регионов продаж.

Совет

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

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

Существует два шага по настройке RLS: правила и сопоставления ролей.

Правила RLS

Для семантических моделей модель данных может настроить RLS в Power BI Desktop, создав одну или несколько ролей. У роли есть уникальное имя в модели, и оно обычно включает одно или несколько правил. Правила применяют фильтры к таблицам моделей с помощью выражений анализа данных (DAX). По умолчанию модель не имеет ролей.

Внимание

Модель без ролей означает, что пользователи (имеющие разрешение на запрос модели данных) имеют доступ ко всем данным модели.

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

• Статические правила: используйте выражения DAX, ссылающиеся на константы, например [Region] = "Midwest".
• Динамические правила: используйте определенные функции DAX, возвращающие значения среды (в отличие от констант). Значения среды возвращаются из трех конкретных функций DAX: USERNAME, USERPRINCIPALNAME и CUSTOMDATA. Определение динамических правил — это простой и эффективный способ, если в таблице модели хранятся значения имени пользователя. Они позволяют применять структуру безопасности на уровне строк на основе данных.

Сопоставления ролей RLS

После публикации модели в служба Power BI необходимо настроить сопоставления ролей перед доступом пользователей к соответствующим отчетам. Сопоставление ролей включает назначение объектам безопасности Microsoft Entra ролям. Объектами безопасности могут быть учетные записи пользователей или группы безопасности.

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

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

Совет

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

Взаимодействие с пользователем RLS

Некоторые организации решили использовать RLS в качестве дополнительного уровня безопасности в дополнение к стандартным разрешениям Power BI. Рассмотрим следующий сценарий: вы предоставляете ссылку на отчет всей организации. Любой пользователь, который просматривает отчет, должен быть сопоставлен с ролью RLS, чтобы просмотреть данные в отчете. Если они не сопоставлены с ролью RLS, они не увидят никаких данных.

Наличие RLS изменяет интерфейс по умолчанию для потребителей.

• Если RLS не определена для семантической модели: создатели и потребители с по крайней мере разрешением на чтение для семантической модели могут просматривать все данные в семантической модели.
• Если RLS определена в семантической модели: создатели и потребители с разрешением только на чтение в семантической модели смогут просматривать только данные, которые они могут просматривать (на основе сопоставления ролей RLS).

Примечание.

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

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

Ниже приведены правила разрешений, определяющие, применяется ли RLS.

• Пользователь имеет разрешение на чтение семантической модели: RLS применяется для пользователя.
• У пользователя есть разрешения на чтение и сборку для семантической модели: RLS применяется для пользователя.
• Пользователь имеет разрешение на запись в семантической модели: RLS не применяется для пользователя, то есть они могут видеть все данные в семантической модели. Разрешение на запись предоставляет возможность редактирования семантической модели. Его можно предоставить одним из двух способов:
  • С ролью участника, члена или Администратор рабочей области (для рабочей области, в которой хранится семантическая модель).
  • Разрешение на запись семантической модели для каждого элемента.

Совет

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

Дополнительные сведения о RLS см. в разделе "Ограничение доступа к данным модели Power BI".

RLS для datamarts

Данные Power BI также могут применять RLS. Однако реализация отличается.

Основное различие заключается в том, что RLS для данныхmarts настраивается в служба Power BI, а не в Power BI Desktop.

Другое отличие заключается в том, что datamarts применяют RLS как к семантической модели, так и к управляемой База данных SQL Azure, связанной с datamart. Применение RLS на обоих уровнях обеспечивает согласованность и гибкость. Те же фильтры RLS применяются независимо от того, как пользователь запрашивает данные, будь то подключение к семантической модели или к управляемому База данных SQL Azure.

Дополнительные сведения см. в статье RLS для datamarts.

Безопасность на уровне объекта

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

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

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

Примечание.

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

В настоящее время нет интерфейса в Power BI Desktop для настройки OLS. Вы можете использовать табличный редактор, который является сторонним инструментом для создания, обслуживания и управления моделями. Дополнительные сведения см. в сценарии использования расширенной модели данных.

Дополнительные сведения об OLS см. в разделе "Ограничение доступа к объектам модели Power BI".

Контрольный список . При планировании RLS и OLS ключевые решения и действия включают:

• Определите стратегию использования RLS. Рассмотрим, для каких вариантов использования и целей вы планируете использовать безопасность на уровне строк.
• Определите стратегию использования OLS: рассмотрите, для каких вариантов использования и целей вы планируете использовать безопасность на уровне объектов.
• Рассмотрите требования для сертифицированного содержимого: если у вас есть процесс сертификации семантической модели, определите, следует ли включать какие-либо конкретные требования для использования RLS или OLS.
• Руководство по созданию и публикации пользователей: создание документации для пользователей, включающих требования и предпочтения для использования RLS и OLS. Узнайте, как получить сведения о сопоставлении пользователей, если он существует в централизованном расположении.
• Обновление учебных материалов: включите ключевые сведения о требованиях и предпочтениях для RLS и OLS в учебные материалы пользователей. Укажите примеры для пользователей, чтобы понять, когда он подходит для использования любого метода безопасности данных.

Связанный контент

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