O que posso fazer com as políticas de DevOps do Microsoft Purview?

Observação

O Catálogo de Dados do Microsoft Purview (clássico), o Insights de Integridade de Dados (clássico) e o Fluxo de Trabalho do Purview (clássico) não estão mais aceitando novos clientes e esses serviços, anteriormente Purview do Azure, agora estão no modo de suporte ao cliente.

Este artigo descreve como gerenciar o acesso às fontes de dados em seu acervo de dados usando o portal de governança do Microsoft Purview. Ele se concentra nos conceitos básicos das políticas de DevOps. Ou seja, ele fornece informações básicas sobre as políticas de DevOps que você deve saber antes de seguir outros artigos para obter as etapas de configuração.

Observação

Essa funcionalidade é diferente do controle de acesso interno no portal de governança do Microsoft Purview.

O acesso aos metadados do sistema é crucial para a equipe de TI e DevOps para garantir que os sistemas de banco de dados críticos estejam íntegros, estejam funcionando de acordo com as expectativas e sejam seguros. Você pode conceder e revogar esse acesso de forma eficiente e em escala por meio das políticas de DevOps do Microsoft Purview.

Qualquer usuário que detenha a função Autor de Política no nível da coleção raiz no Microsoft Purview pode criar, atualizar e excluir políticas de DevOps. Depois que as políticas de DevOps são salvas, elas são publicadas automaticamente.

Políticas de acesso versus políticas de DevOps

As políticas de acesso do Microsoft Purview permitem que os clientes gerenciem o acesso aos sistemas de dados em todo o seu acervo de dados, tudo a partir de um local central na nuvem. Você pode pensar nessas políticas como concessões de acesso que podem ser criadas por meio do Microsoft Purview Studio, evitando a necessidade de código. Eles determinam se uma lista de entidades de segurança do Microsoft Entra, como usuários e grupos, deve ter um tipo específico de acesso a uma fonte de dados ou a um ativo dentro dela deve ter permissão ou negação. O Microsoft Purview comunica essas políticas às fontes de dados, onde elas são impostas nativamente.

As políticas de DevOps são um tipo especial de políticas de acesso do Microsoft Purview. Eles concedem acesso aos metadados do sistema de banco de dados em vez de dados do usuário. Eles simplificam o provisionamento de acesso para operações de TI e pessoal de auditoria de segurança. As políticas de DevOps só concedem acesso. Eles não negam o acesso.

Elementos de uma política de DevOps

Três elementos definem uma política de DevOps:

  • Assunto

    Esta é uma lista de usuários, grupos ou entidades de serviço do Microsoft Entra que recebem acesso.

  • Recurso de dados

    Esse é o escopo em que a política é imposta. O caminho do recurso de dados é a composição da fonte de dados do grupo > de recursos da assinatura>.

    No momento, as políticas de DevOps do Microsoft Purview dão suporte a fontes de dados do tipo SQL. Você pode configurá-los em fontes de dados individuais e em grupos de recursos inteiros e assinaturas. Você só poderá criar políticas de DevOps depois de registrar o recurso de dados no Microsoft Purview com a opção Imposição de política de dados ativada.

  • Função

    Uma função é mapeada para um conjunto de ações que a política permite no recurso de dados. As políticas de DevOps dão suporte às funções de Monitor de Monitor de Desempenho do SQL e Auditor de Segurança do SQL. Ambas as funções fornecem acesso aos metadados do sistema SQL e, mais especificamente, às DMVs (exibições de gerenciamento dinâmico) e às DMFs (funções de gerenciamento dinâmico). Mas o conjunto de DMVs e DMFs que essas funções concedem é diferente. Forneceremos alguns exemplos populares mais adiante neste artigo.

    O artigo Criar, listar, atualizar e excluir políticas de DevOps do Microsoft Purview detalha a definição de função para cada tipo de fonte de dados. Ou seja, ele fornece um mapeamento de funções no Microsoft Purview para as ações que são permitidas nesse tipo de fonte de dados. Por exemplo, a definição de função para o SQL Monitor de Desempenho e o SQL Security Auditor inclui ações de conexão no nível do servidor e do banco de dados no lado da fonte de dados.

Em essência, a política de DevOps atribui as permissões relacionadas da função ao assunto e é imposta no escopo do caminho do recurso de dados.

Imposição hierárquica de políticas

Uma política de DevOps em um recurso de dados é imposta ao próprio recurso de dados e a todos os recursos filho que ele contém. Por exemplo, uma política de DevOps em uma assinatura do Azure se aplica a todos os grupos de recursos, a todas as fontes de dados habilitadas para política em cada grupo de recursos e a todos os bancos de dados em cada fonte de dados.

Cenário de exemplo para demonstrar o conceito e os benefícios

Bob e Alice estão envolvidos com o processo de DevOps em sua empresa. Eles precisam fazer logon em dezenas de instâncias do SQL Server locais e servidores lógicos do SQL do Azure para monitorar seu desempenho para que os processos críticos de DevOps não sejam interrompidos. Seu gerente, Mateo, coloca todas essas fontes de dados SQL no Grupo de Recursos 1. Em seguida, ele cria um grupo do Microsoft Entra e inclui Alice e Bob. Em seguida, ele usa as políticas de DevOps do Microsoft Purview (Política 1 no diagrama a seguir) para conceder a esse grupo do Microsoft Entra acesso ao Grupo de Recursos 1, que hospeda os servidores lógicos.

Diagrama que mostra um exemplo de políticas de DevOps em um grupo de recursos.

Estes são os benefícios:

  • O Mateo não precisa criar logins locais em cada servidor.
  • As políticas do Microsoft Purview melhoram a segurança limitando o acesso privilegiado local. Eles apóiam o princípio do privilégio mínimo. No cenário, Mateo concede apenas o acesso mínimo que Bob e Alice precisam para realizar a tarefa de monitorar a integridade e o desempenho do sistema.
  • Quando novos servidores são adicionados ao grupo de recursos, o Mateo não precisa atualizar a política no Microsoft Purview para que ela seja imposta nos novos servidores.
  • Se Alice ou Bob sair da organização e o trabalho for preenchido, Mateo apenas atualizará o grupo do Microsoft Entra. Ele não precisa fazer alterações nos servidores ou nas políticas que criou no Microsoft Purview.
  • A qualquer momento, Mateo ou o auditor da empresa podem ver todas as permissões que foram concedidas diretamente no Microsoft Purview Studio.
Princípio Benefício
Simplificar As definições de função SQL Monitor de Desempenho e Auditor de Segurança do SQL capturam as permissões que as personas típicas de TI e DevOps precisam para executar seu trabalho.
Há menos necessidade de experiência em permissão em cada tipo de fonte de dados.
Reduzir o esforço Uma interface gráfica permite que você percorra rapidamente a hierarquia de objetos de dados.
O Microsoft Purview dá suporte a políticas em grupos de recursos e assinaturas inteiros do Azure.
Aumentar a segurança O acesso é concedido centralmente e pode ser facilmente revisado e revogado.
Há menos necessidade de contas privilegiadas para configurar o acesso diretamente na fonte de dados.
As políticas de DevOps dão suporte ao princípio de privilégios mínimos por meio de escopos de recursos de dados e definições de função.

API de políticas de DevOps

Muitos clientes sofisticados preferem interagir com o Microsoft Purview por meio de scripts em vez da interface do usuário. As políticas de DevOps do Microsoft Purview agora dão suporte a uma API REST que oferece capacidade completa de criação, leitura, atualização e exclusão (CRUD). Esse recurso inclui listagem, políticas para o Monitor de Desempenho do SQL e políticas para o Auditor de Segurança do SQL. Para obter mais informações, consulte a especificação da API.

Captura de tela que mostra onde encontrar a API DevOps no menu API REST do Azure.

Os metadados dinâmicos do SQL incluem uma lista de mais de 700 DMVs e DMFs. A tabela a seguir ilustra alguns dos mais populares. A tabela mapeia as DMVs e DMFs para suas definições de função nas políticas de DevOps do Microsoft Purview. Ele também fornece links para conteúdo de referência.

Função de DevOps Categoria Exemplo de DMV ou DMF
Monitor de Desempenho do SQL Consulte os parâmetros do sistema para entender seu sistema sys.configurations
sys.dm_os_sys_info
Identificar gargalos de desempenho sys.dm_os_wait_stats
Analisar consultas em execução no momento sys.dm_exec_query_stats
Analisar problemas de bloqueio sys.dm_tran_locks
sys.dm_exec_requests
sys.dm_os_waiting_tasks
Analisar o uso de memória sys.dm_os_memory_clerks
Analisar o uso e o desempenho do arquivo sys.master_files
sys.dm_io_virtual_file_stats
Analisar o uso e a fragmentação do índice sys.indexes
sys.dm_db_index_usage_stats
sys.dm_db_index_physical_stats
Gerenciar conexões de usuário ativas e tarefas internas sys.dm_exec_sessions
Obter estatísticas de execução de procedimento sys.dm_exec_procedure_stats
Usar o Repositório de Consultas sys.query_store_plan
sys.query_store_query
sys.query_store_query_text
Obter Log de Erros (ainda não suportado) sys.sp_readerrorlog
SQL Security Auditor Obter detalhes de auditoria sys.dm_server_audit_status
O SQL Monitor de Desempenho e o SQL Security Auditor sys.dm_audit_actions
sys.dm_audit_class_type_map

Para obter mais informações sobre o que a equipe de suporte de TI pode fazer quando você concede acesso a ela por meio das funções do Microsoft Purview, consulte os seguintes recursos:

Próximas etapas

Para começar a usar as políticas de DevOps, consulte os seguintes recursos:

  • Last updated on