Что можно сделать с помощью политик Microsoft Purview DevOps?
В этой статье описывается, как управлять доступом к источникам данных в пространстве данных с помощью портала управления Microsoft Purview. В нем рассматриваются основные понятия политик DevOps. Это значит, что в нем содержатся общие сведения о политиках DevOps, которые следует знать, прежде чем следовать другим статьям, чтобы получить инструкции по настройке.
Примечание.
Эта возможность отличается от внутреннего управления доступом на портале управления Microsoft Purview.
Доступ к системным метаданным имеет решающее значение для ИТ-специалистов и сотрудников DevOps, чтобы обеспечить работоспособность критически важных систем баз данных, выполнение ожиданий и безопасность. Вы можете предоставить и отозвать этот доступ эффективно и в большом масштабе с помощью политик Microsoft Purview DevOps.
Любой пользователь, которому принадлежит роль "Автор политики" на корневом уровне коллекции в Microsoft Purview, может создавать, обновлять и удалять политики DevOps. После сохранения политик DevOps они публикуются автоматически.
Политики доступа и политики DevOps
Политики доступа Microsoft Purview позволяют клиентам управлять доступом к системам данных во всем своем пространстве данных из центрального расположения в облаке. Эти политики можно рассматривать как разрешения на доступ, которые можно создать с помощью Microsoft Purview Studio, избегая необходимости в коде. Они определяют, должен ли список Microsoft Entra субъектов, таких как пользователи и группы, разрешать или запрещать определенный тип доступа к источнику данных или ресурсу в нем. Microsoft Purview сообщает эти политики источникам данных, где они применяются в собственном коде.
Политики DevOps — это особый тип политик доступа Microsoft Purview. Они предоставляют доступ к метаданным системы базы данных, а не к данным пользователя. Они упрощают подготовку доступа для ИТ-операций и персонала по аудиту безопасности. Политики DevOps предоставляют доступ только. Они не запрещают доступ.
Элементы политики DevOps
Политику DevOps определяют три элемента:
Тема
Это список Microsoft Entra пользователей, групп или субъектов-служб, которым предоставлен доступ.
Ресурс данных
Это область, где применяется политика. Путь к ресурсу данных представляет собой состав источника данных группы > ресурсов подписки>.
Политики Microsoft Purview DevOps в настоящее время поддерживают источники данных типа SQL. Их можно настроить для отдельных источников данных, а также для целых групп ресурсов и подписок. Политики DevOps можно создавать только после регистрации ресурса данных в Microsoft Purview с включенным параметром Принудительное применение политики данных .
Роль
Роль сопоставляется с набором действий, разрешенных политикой для ресурса данных. Политики DevOps поддерживают роли Монитор производительности SQL и аудитора безопасности SQL. Обе эти роли предоставляют доступ к метаданным системы SQL, в частности к динамическим административным представлениям (DMV) и динамическим функциям управления (DMF). Но набор динамических административных представлений и dmfs, предоставляемых этими ролями, отличается. Далее в этой статье приведены некоторые популярные примеры.
В статье Создание, перечисление, обновление и удаление политик Microsoft Purview DevOps подробно описано определение роли для каждого типа источника данных. То есть он предоставляет сопоставление ролей в Microsoft Purview с действиями, которые разрешены в этом типе источника данных. Например, определение роли для SQL Монитор производительности и аудитора безопасности SQL включает действия Connect на уровне сервера и базы данных на стороне источника данных.
По сути, политика DevOps назначает субъекту разрешения, связанные с ролью, и применяется в область пути к ресурсу данных.
Иерархическое применение политик
Политика DevOps для ресурса данных применяется к самому ресурсу данных и ко всем дочерним ресурсам, которые он содержит. Например, политика DevOps в подписке Azure применяется ко всем группам ресурсов, ко всем источникам данных с поддержкой политики в каждой группе ресурсов и ко всем базам данных в каждом источнике данных.
Пример сценария для демонстрации концепции и преимуществ
Боб и Алиса участвуют в процессе DevOps в своей компании. Они должны войти в десятки экземпляров SQL Server локально и Azure SQL логических серверов, чтобы отслеживать их производительность, чтобы критически важные процессы DevOps не прерывались. Их руководитель, Mateo, помещает все эти источники данных SQL в группу ресурсов 1. Затем он создает Microsoft Entra группу и включает Алису и Боба. Затем он использует политики Microsoft Purview DevOps (политика 1 на следующей схеме), чтобы предоставить этому Microsoft Entra доступ к группе ресурсов 1, в которой размещаются логические серверы.
Ниже приведены преимущества:
- Mateo не обязательно создавать локальные имена входа на каждом сервере.
- Политики из Microsoft Purview повышают безопасность, ограничивая локальный привилегированный доступ. Они поддерживают принцип наименьших привилегий. В этом сценарии Матео предоставляет только минимальный доступ, необходимый Бобу и Алисе для выполнения задачи мониторинга работоспособности и производительности системы.
- При добавлении новых серверов в группу ресурсов Mateo не нужно обновлять политику в Microsoft Purview, чтобы она применялась на новых серверах.
- Если Алиса или Боб покидают организацию и задание не выполняется, Матео просто обновляет Microsoft Entra группу. Ему не нужно вносить какие-либо изменения в серверы или политики, созданные им в Microsoft Purview.
- В любой момент времени Матео или аудитор компании может просматривать все разрешения, предоставленные непосредственно в Microsoft Purview Studio.
| Принцип | Преимущества |
|---|---|
| Упрощать | Определения ролей SQL Монитор производительности и sql Security Auditor фиксируют разрешения, которые типичные ИТ-специалисты и DevOps должны выполнять свою работу. |
| Для каждого типа источника данных требуется меньше знаний о разрешениях. | |
| Сокращение усилий | Графический интерфейс позволяет быстро перемещаться по иерархии объектов данных. |
| Microsoft Purview поддерживает политики для всех групп ресурсов и подписок Azure. | |
| Повышение уровня безопасности | Доступ предоставляется централизованно и может быть легко проверен и отозван. |
| Для настройки доступа непосредственно к источнику данных в привилегированных учетных записях меньше. | |
| Политики DevOps поддерживают принцип минимальных привилегий с помощью областей ресурсов данных и определений ролей. | |
API политик DevOps
Многие сложные клиенты предпочитают взаимодействовать с Microsoft Purview с помощью скриптов, а не через пользовательский интерфейс. Политики Microsoft Purview DevOps теперь поддерживают REST API, который предоставляет полные возможности создания, чтения, обновления и удаления (CRUD). Эта возможность включает в себя список, политики для SQL Монитор производительности и политики для аудитора безопасности SQL. Дополнительные сведения см. в спецификации API.
Сопоставление популярных динамических административных представлений и dmfs
Динамические метаданные SQL содержат список из более чем 700 динамических административных представлений и dmfs. В следующей таблице показаны некоторые из наиболее популярных из них. Таблица сопоставляет динамические административные представления и dmfs с их определениями ролей в политиках DevOps Microsoft Purview. В нем также содержатся ссылки на справочные материалы.
| Роль DevOps | Категория | Пример динамического административного административного представления или dmf |
|---|---|---|
| SQL Монитор производительности | Запрос параметров системы для понимания системы | sys.configurations |
| sys.dm_os_sys_info | ||
| Определение узких мест производительности | sys.dm_os_wait_stats | |
| Анализ текущих выполняемых запросов | sys.dm_exec_query_stats | |
| Анализ блокирующих проблем | sys.dm_tran_locks | |
| sys.dm_exec_requests | ||
| sys.dm_os_waiting_tasks | ||
| Анализ использования памяти | sys.dm_os_memory_clerks | |
| Анализ использования файлов и производительности | sys.master_files | |
| sys.dm_io_virtual_file_stats | ||
| Анализ использования и фрагментации индекса | sys.indexes | |
| sys.dm_db_index_usage_stats | ||
| sys.dm_db_index_physical_stats | ||
| Управление активными пользовательскими подключениями и внутренними задачами | sys.dm_exec_sessions | |
| Получение статистики выполнения процедуры | sys.dm_exec_procedure_stats | |
| Использование хранилище запросов | sys.query_store_plan | |
| sys.query_store_query | ||
| sys.query_store_query_text | ||
| Получение журнала ошибок (пока не поддерживается) | sys.sp_readerrorlog | |
| Аудитор безопасности SQL | Получение сведений об аудите | sys.dm_server_audit_status |
| Sql Монитор производительности и SQL Security Auditor | sys.dm_audit_actions | |
| sys.dm_audit_class_type_map | ||
Дополнительные сведения о том, что сотрудники ИТ-службы поддержки могут делать, предоставляя им доступ через роли Microsoft Purview, см. в следующих ресурсах:
- SQL Монитор производительности. Используйте Microsoft Purview для предоставления масштабного доступа к данным о производительности в Azure SQL и SQL Server
- Аудитор безопасности SQL: динамические административные представления и функции, связанные с безопасностью
Дальнейшие действия
Чтобы приступить к работе с политиками DevOps, ознакомьтесь со следующими ресурсами:
- Воспользуйтесь политиками DevOps для базы данных Azure SQL. Краткое руководство.
- Просмотрите другие видео, блоги и статьи.