Субъект-служба в хранилище данных Fabric

2025-06-09

применимо к: хранилище✅ в Microsoft Fabric

Служебная учетная запись Azure (SPN) — это удостоверение безопасности, используемое приложениями или средствами автоматизации для доступа к конкретным ресурсам Azure. В отличие от удостоверений пользователей, служебные принципы являются неинтерактивными удостоверениями, связанными с приложениями, которым могут быть назначены конкретные разрешения, что делает их идеальными для автоматизированных процессов или фоновых служб. Используя служебные принципы, вы можете безопасно подключиться к источникам данных, свести к минимуму риски человеческих ошибок и уязвимостей, основанных на удостоверении. Дополнительные сведения о служебных принципах см. в разделе Объекты приложения и служебных принципов в Microsoft Entra ID.

Необходимые условия

Создание учетной записи службы, назначение ролей и создание секрета с помощью Azure.
Убедитесь, что администратор клиента может включить субъекты-службы могут использовать API Fabric на портале администрирования Fabric.
Убедитесь, что пользователь с ролью Администратор рабочей области может предоставить доступ имени службы (SPN) через Управление доступом в рабочей области.

Создание и доступ к хранилищам через REST API с помощью служебного имени участника.

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

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

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

Хранилища, созданные SPN с помощью REST API, будут отображаться в виде списка рабочих пространств на портале Fabric, при этом имя SPN будет имя владельца. На следующем изображении представлено изображение рабочего пространства на портале Fabric. "Тестовое приложение публичного API Fabric" — это SPN, который создал Contoso Marketing Warehouse.

Подключение к клиентским приложениям с использованием SPN

Вы можете подключиться к хранилищам Fabric, используя принципы служб, с помощью инструментов, таких как SQL Server Management Studio (SSMS) 19 или более поздних версий.

Аутентификация: Служебный принципал Microsoft Entra
имя пользователя: идентификатор клиента SPN (создан с помощью Azure в разделе предварительных требований)
пароль: секрет (созданный с помощью Azure в разделе предварительных требований)

Разрешения плоскости управления

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

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

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

Например:

GRANT SELECT ON <table name> TO <service principal name>;

После предоставления разрешений SPN могут подключаться к средствам клиентского приложения, таким как SSMS, тем самым обеспечивая безопасный доступ для разработчиков для запуска COPY INTO (с включенной функцией брандмауэра и без неё), а также программно выполнять любой запрос T-SQL по расписанию с помощью конвейеров Azure Data Factory .

Монитор

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

динамических административных представлений (DMVs): столбец login_name в sys.dm_exec_sessions.
Query Insights: столбец login_name в представлении queryinsights.exec_requests_history.
действие запроса: столбец submitter в активности запроса Fabric.
Приложение метрик емкости: Использование вычислений для операций с хранилищем, выполняемых SPN, отображается как идентификатор клиента в столбце Пользователь в таблице детализации фоновых операций.

Дополнительные сведения см. в разделе Monitor Fabric Data Warehouse.

API поглощения

Владение хранилищами может быть изменено с SPN на пользователя и с пользователя на SPN.

Переход от SPN или от пользователя к пользователю: см. изменение владельца склада Fabric.
Переход от SPN или пользователя к другому SPN. Используйте вызов POST в REST API.
```
POST <PowerBI Global Service FQDN>/v1.0/myorg/groups/{workspaceid}/datawarehouses/{warehouseid}/takeover
```

Ограничения

Ограничения субъектов-служб с помощью хранилища данных Microsoft Fabric:

В настоящее время учетные данные субъекта-службы или Entra ID не поддерживаются для файлов ошибок COPY INTO.
Субъекты-службы не поддерживаются для API-интерфейсов GIT. Поддержка SPN существует только для API-интерфейсов конвейера развертывания .
Субъекты-службы в настоящее время не могут выполнять операции DCL в хранилище. Сюда входят команды GRANT, REVOKE, и DENY, независимо от существования целевого субъекта.
Субъекты-службы не могут активировать операции, которые приводят к автоматическому созданию удостоверений пользователей в хранилище данных. Это включает в себя сценарии, в которых система обычно пытается создать пользователя в рамках операции. Примеры операций, которые могут вызвать неявное создание пользователя, включают:
- ALTER USER ... WITH DEFAULT_SCHEMA
- ALTER ROLE ... ADD MEMBER

элементы — создание хранилища — REST API (хранилище)
Поддержка основного сервиса в Data Factory