O que posso fazer com as políticas de DevOps do Microsoft Purview?
Este artigo descreve como gerir o acesso a origens de dados no seu património de dados através do portal de governação do Microsoft Purview. Centra-se nos conceitos básicos das políticas de DevOps. Ou seja, fornece informações gerais sobre as políticas de DevOps que deve saber antes de seguir outros artigos para obter os passos de configuração.
Observação
Esta capacidade é diferente do controlo de acesso interno no portal de governação do Microsoft Purview.
O acesso aos metadados do sistema é crucial para o pessoal de TI e de DevOps para garantir que os sistemas de bases de dados críticos estão em bom estado de funcionamento, estão a cumprir as expectativas e estão seguros. Pode conceder e revogar esse acesso de forma eficiente e em escala através das políticas de DevOps do Microsoft Purview.
Qualquer utilizador que tenha a função Autor de Políticas ao nível da coleção de raiz no Microsoft Purview pode criar, atualizar e eliminar políticas de DevOps. Depois de as políticas de DevOps serem guardadas, são publicadas automaticamente.
Políticas de acesso vs. Políticas de DevOps
As políticas de acesso do Microsoft Purview permitem aos clientes gerir o acesso aos sistemas de dados em todo o seu património de dados, tudo a partir de uma localização central na cloud. Pode considerar estas políticas como concessões de acesso que podem ser criadas através do Microsoft Purview Studio, evitando a necessidade de código. Determinam se uma lista de Microsoft Entra principais, como utilizadores e grupos, deve ser permitida ou negada a um tipo específico de acesso a uma origem de dados ou a um recurso dentro da mesma. O Microsoft Purview comunica estas políticas às origens de dados, onde são impostas nativamente.
As políticas de DevOps são um tipo especial de políticas de acesso do Microsoft Purview. Concedem acesso aos metadados do sistema de bases de dados em vez dos dados do utilizador. Simplificam o aprovisionamento de acesso para operações de TI e pessoal de auditoria de segurança. As políticas de DevOps só concedem acesso. 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 Microsoft Entra utilizadores, grupos ou principais de serviço aos quais é concedido acesso.
Recurso de dados
Este é o âmbito onde a política é imposta. O caminho do recurso de dados é a composição da origem de dados do grupo > de recursos da subscrição>.
As políticas de DevOps do Microsoft Purview suportam atualmente origens de dados do tipo SQL. Pode configurá-las em origens de dados individuais e em grupos de recursos e subscrições inteiras. Só pode criar políticas de DevOps depois de registar o recurso de dados no Microsoft Purview com a opção Imposição da política de dados ativada.
Função
Uma função mapeia para um conjunto de ações que a política permite no recurso de dados. As políticas de DevOps suportam as funções de Auditor de Segurança do SQL Monitor de Desempenho e SQL. Ambas as funções fornecem acesso aos metadados do sistema SQL e, mais especificamente, às vistas de gestão dinâmica (DMVs) e às funções de gestão dinâmica (DMFs). No entanto, o conjunto de DMVs e DMFs que estas funções concedem é diferente. Fornecemos alguns exemplos populares mais adiante neste artigo.
O artigo Criar, listar, atualizar e eliminar políticas de DevOps do Microsoft Purview detalha a definição de função para cada tipo de origem de dados. Ou seja, fornece um mapeamento de funções no Microsoft Purview para as ações permitidas nesse tipo de origem de dados. Por exemplo, a definição de função do SQL Monitor de Desempenho e do Auditor de Segurança do SQL inclui ações ligar ao nível do servidor e da base de dados no lado da origem de dados.
Essencialmente, a política de DevOps atribui as permissões relacionadas da função ao assunto e é imposta no âmbito do caminho do recurso de dados.
Imposição hierárquica de políticas
Uma política de DevOps num recurso de dados é imposta no próprio recurso de dados e em todos os recursos subordinados que contém. Por exemplo, uma política de DevOps numa subscrição do Azure aplica-se a todos os grupos de recursos, a todas as origens de dados ativadas por políticas em cada grupo de recursos e a todas as bases de dados dentro de cada origem de dados.
Cenário de exemplo para demonstrar o conceito e os benefícios
Bob e Alice estão envolvidos no processo de DevOps na empresa. Precisam de iniciar sessão em dezenas de SQL Server instâncias no local e SQL do Azure servidores lógicos para monitorizar o desempenho, para que os processos críticos do DevOps não sejam interrompidos. O gestor, Mateo, coloca todas estas origens de dados SQL no Grupo de Recursos 1. Em seguida, cria um grupo Microsoft Entra e inclui Alice e Bob. Em seguida, utiliza as políticas de DevOps do Microsoft Purview (Política 1 no diagrama seguinte) para conceder a este Microsoft Entra acesso de grupo ao Grupo de Recursos 1, que aloja os servidores lógicos.
Estes são os benefícios:
- O Mateo não tem de criar inícios de sessão locais em cada servidor.
- As políticas do Microsoft Purview melhoram a segurança ao limitar o acesso privilegiado local. Suportam o princípio do menor privilégio. No cenário, Mateo concede apenas o acesso mínimo de que Bob e Alice precisam para realizar a tarefa de monitorização do estado de funcionamento e do desempenho do sistema.
- Quando são adicionados novos servidores ao grupo de recursos, o Mateo não precisa de atualizar a política no Microsoft Purview para que seja imposta nos novos servidores.
- Se a Alice ou o Guilherme deixarem a organização e o trabalho for preenchido novamente, o Mateo apenas atualiza o grupo Microsoft Entra. Não tem de fazer alterações aos servidores ou às políticas que criou no Microsoft Purview.
- A qualquer momento, o Mateo ou o auditor da empresa podem ver todas as permissões 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 de que as pessoas de TI e de DevOps típicas precisam para executar o respetivo trabalho. |
| Existe menos necessidade de conhecimentos de permissão em cada tipo de origem de dados. | |
| Reduzir o esforço | Uma interface gráfica permite-lhe percorrer rapidamente a hierarquia de objetos de dados. |
| O Microsoft Purview suporta políticas em todos os grupos de recursos e subscrições do Azure. | |
| Aumentar a segurança | O acesso é concedido centralmente e pode ser facilmente revisto e revogado. |
| Há menos necessidade de contas com privilégios para configurar o acesso diretamente na origem de dados. | |
| As políticas de DevOps suportam o princípio de menor privilégio através de âmbitos de recursos de dados e definições de funções. | |
API de políticas de DevOps
Muitos clientes sofisticados preferem interagir com o Microsoft Purview através de scripts e não através da IU. As políticas de DevOps do Microsoft Purview suportam agora uma API REST que oferece a capacidade de criação, leitura, atualização e eliminação completa (CRUD). Esta capacidade inclui listas, políticas para Monitor de Desempenho SQL e políticas para o Auditor de Segurança do SQL. Para obter mais informações, veja a especificação da API.
.
Mapeamento de DMVs e DMFs populares
Os metadados dinâmicos do SQL incluem uma lista de mais de 700 DMVs e DMFs. A tabela seguinte ilustra alguns dos mais populares. A tabela mapeia as DMVs e DMFs para as respetivas definições de função nas políticas de DevOps do Microsoft Purview. Também fornece ligações para conteúdo de referência.
| Função de DevOps | Categoria | DMV ou DMF de exemplo |
|---|---|---|
| MONITOR DE DESEMPENHO SQL | Consultar parâmetros do sistema para compreender o seu sistema | sys.configurations |
| sys.dm_os_sys_info | ||
| Identificar estrangulamentos de desempenho | sys.dm_os_wait_stats | |
| Analisar consultas atualmente em execução | sys.dm_exec_query_stats | |
| Analisar problemas de bloqueio | sys.dm_tran_locks | |
| sys.dm_exec_requests | ||
| sys.dm_os_waiting_tasks | ||
| Analisar a utilização da memória | sys.dm_os_memory_clerks | |
| Analisar a utilização e o desempenho dos ficheiros | sys.master_files | |
| sys.dm_io_virtual_file_stats | ||
| Analisar a utilização e fragmentação de índices | sys.indexes | |
| sys.dm_db_index_usage_stats | ||
| sys.dm_db_index_physical_stats | ||
| Gerir ligações de utilizador ativas e tarefas internas | sys.dm_exec_sessions | |
| Obter estatísticas de execução de procedimentos | sys.dm_exec_procedure_stats | |
| Utilizar o Repositório de Consultas | sys.query_store_plan | |
| sys.query_store_query | ||
| sys.query_store_query_text | ||
| Obter Registo de Erros (ainda não suportado) | sys.sp_readerrorlog | |
| Auditor de Segurança do SQL | Obter detalhes de auditoria | sys.dm_server_audit_status |
| Auditor de Segurança do SQL Monitor de Desempenho e SQL | sys.dm_audit_actions | |
| sys.dm_audit_class_type_map | ||
Para obter mais informações sobre o que o pessoal de suporte de TI pode fazer quando lhes concede acesso através das funções do Microsoft Purview, consulte os seguintes recursos:
- SQL Monitor de Desempenho: utilize o Microsoft Purview para fornecer acesso em escala aos dados de desempenho em SQL do Azure e SQL Server
- Auditor de Segurança do SQL: Funções e vistas de gestão dinâmica relacionadas com segurança
Próximas etapas
Para começar a utilizar as políticas de DevOps, consulte os seguintes recursos:
- Experimente as políticas de DevOps para SQL do Azure Base de Dados: Guia de início rápido.
- Veja outros vídeos, blogues e artigos.