Práticas recomendadas de verificação do Microsoft Purview

As soluções de governança do Microsoft Purview dão suporte à verificação automatizada de fontes de dados locais, multicloud e software como serviço (SaaS).

A execução de uma verificação invoca o processo para ingerir metadados das fontes de dados registradas. Os metadados curados no final do processo de verificação e curadoria incluem metadados técnicos. Esses metadados podem incluir nomes de ativos de dados, como nomes de tabela ou nomes de arquivo, tamanho do arquivo, colunas e linhagem de dados. Os detalhes do esquema também são capturados para fontes de dados estruturadas. Um sistema de gerenciamento de banco de dados relacional é um exemplo desse tipo de origem.

O processo de curadoria aplica rótulos de classificação automatizados nos atributos de esquema com base no conjunto de regras de verificação configurado. Os rótulos de confidencialidade serão aplicados se sua conta do Microsoft Purview estiver conectada ao portal de conformidade do Microsoft Purview.

Importante

Se você tiver alguma Política do Azure impedindo atualizações em contas de armazenamento, isso causará erros para o processo de verificação do Microsoft Purview. Siga o guia de marca de exceção do Microsoft Purview para criar uma exceção para contas do Microsoft Purview.

Por que você precisa de práticas recomendadas para gerenciar fontes de dados?

As práticas recomendadas permitem:

• Otimizar o custo.
• Crie excelência operacional.
• Aprimorar a conformidade de segurança.
• Obtenha eficiência de desempenho.

Registrar uma origem e estabelecer uma conexão

As seguintes considerações e recomendações de design ajudam você a registrar uma origem e estabelecer uma conexão.

Considerações de design

• Use coleções para criar a hierarquia que se alinha à estratégia da organização, como geograficamente, função de negócios ou fonte de dados. A hierarquia define as fontes de dados a serem registradas e examinadas.
• Por design, você não pode registrar fontes de dados várias vezes na mesma conta do Microsoft Purview. Essa arquitetura ajuda a evitar o risco de atribuir controle de acesso diferente à mesma fonte de dados.

Recomendações de design

• Se os metadados da mesma fonte de dados forem consumidos por várias equipes, você poderá registrar e gerenciar a fonte de dados em uma coleção pai. Em seguida, você pode criar verificações correspondentes em cada subcolleção. Dessa forma, ativos relevantes aparecem em cada coleção filho. Fontes sem pais são agrupadas em uma caixa pontilhada na exibição do mapa. Nenhuma seta as liga aos pais.

  

• Use a opção Azure Multiple se precisar registrar várias fontes, como assinaturas do Azure ou grupos de recursos, na nuvem. Para obter mais informações, confira a seguinte documentação:

  • Examinar várias fontes no Microsoft Purview
  • Verificar a preparação da fonte de dados em escala
  • Configurar o acesso a fontes de dados para o MSI do Microsoft Purview em escala

• Depois que uma fonte de dados for registrada, você poderá examinar a mesma fonte várias vezes, caso a mesma fonte esteja sendo usada de forma diferente por várias equipes ou unidades de negócios.

Para obter mais informações sobre como definir uma hierarquia para registrar fontes de dados, confira Melhores práticas na arquitetura de coleções.

Verificação

As seguintes considerações e recomendações de design são organizadas com base nas principais etapas envolvidas no processo de verificação.

Considerações de design

• Depois que a fonte de dados for registrada, configure uma verificação para gerenciar a verificação e a curadoria de metadados automatizados e seguros.
• A configuração de verificação inclui configurar o nome da verificação, o escopo da verificação, o runtime de integração, a frequência de gatilho de verificação, o conjunto de regras de verificação e o conjunto de recursos exclusivamente para cada fonte de dados por frequência de verificação.
• Antes de criar credenciais, considere seus tipos de fonte de dados e requisitos de rede. Essas informações ajudam você a decidir qual método de autenticação e runtime de integração você precisa para seu cenário.

Recomendações de design

Depois de registrar sua origem na coleção relevante, planeje e siga a ordem mostrada aqui quando configurar a verificação. Essa ordem de processo ajuda você a evitar custos inesperados e retrabalho.

1. Identifique seus requisitos de classificação das regras de classificação internas do sistema. Ou você pode criar regras de classificação personalizadas específicas, conforme necessário. Baseie-os em requisitos específicos da indústria, das empresas ou regionais, que não estão disponíveis fora da caixa:

   • Confira as melhores práticas de classificação.
   • Confira como criar uma regra de classificação e classificação personalizadas.

2. Crie conjuntos de regras de verificação antes de configurar a verificação.

   

   Ao criar o conjunto de regras de verificação, verifique os seguintes pontos:

   • Verifique se o conjunto de regras de verificação padrão do sistema é suficiente para a fonte de dados que está sendo digitalizada. Caso contrário, defina o conjunto de regras de verificação personalizado.

   • O conjunto de regras de verificação personalizado pode incluir o padrão do sistema e o personalizado, portanto, desmarque essas opções não relevantes para os ativos de dados que estão sendo verificados.

   • Quando necessário, crie uma regra personalizada definida para excluir rótulos de classificação indesejados. Por exemplo, o conjunto de regras do sistema contém padrões genéricos de código governamental para o planeta, não apenas o Estados Unidos. Seus dados podem corresponder ao padrão de algum outro tipo, como "Número da Carteira de Motorista da Bélgica".

   • Limite as regras de classificação personalizadas aos rótulos mais importantes e relevantes para evitar desordem. Você não quer ter muitos rótulos marcados no ativo.

   • Se você modificar a classificação personalizada ou o conjunto de regras de verificação, uma verificação completa será disparada. Configure o conjunto de regras de classificação e verificação adequadamente para evitar retrabalhos e verificações completas dispendiosas.

     

     Observação

     Quando você verifica uma conta de armazenamento, o Microsoft Purview usa um conjunto de padrões definidos para determinar se um grupo de ativos forma um conjunto de recursos. Você pode usar regras de padrão de conjunto de recursos para personalizar ou substituir como o Microsoft Purview detecta quais ativos são agrupados como conjuntos de recursos. As regras também determinam como os ativos são exibidos no catálogo. Para obter mais informações, consulte Criar regras de padrão de conjunto de recursos. Esse recurso tem considerações de custo. Para obter informações, confira a página de preços.

3. Configure uma verificação das fontes de dados registradas.

   • Nome da verificação: por padrão, o Microsoft Purview usa a convenção de nomenclatura SCAN-[A-Z][a-z][a-z], o que não é útil quando você está tentando identificar uma verificação que você executou. Use uma convenção de nomenclatura significativa. Por exemplo, você pode nomear o ambiente de verificação-source-frequency-time como DEVODS-Daily-0200. Esse nome representa uma verificação diária em 0200 horas.

   • Autenticação: o Microsoft Purview oferece vários métodos de autenticação para a verificação de fontes de dados, dependendo do tipo de origem. Pode ser a nuvem do Azure ou fontes locais ou de terceiros. Siga o princípio de privilégio mínimo para o método de autenticação nesta ordem de preferência:

     • MSI do Microsoft Purview – Identidade de Serviço Gerenciado (por exemplo, para fontes de Azure Data Lake Storage Gen2)
     • Identidade gerenciada atribuída pelo usuário
     • Entidade de serviço
     • Autenticação SQL (por exemplo, para fontes locais ou SQL do Azure)
     • Chave da conta ou autenticação básica (por exemplo, para fontes do SAP S/4HANA)

     Para obter mais informações, consulte o guia de como gerenciar credenciais.

     Observação

     Se você tiver um firewall habilitado para a conta de armazenamento, use o método de autenticação de identidade gerenciada ao configurar uma verificação. Quando você configura uma nova credencial, o nome da credencial só pode conter letras, números, sublinhados e hífens.

   • Runtime de integração

     • Para obter mais informações, consulte Práticas recomendadas de arquitetura de rede.
     • Se o SHIR (runtime de integração auto-hospedado) for excluído, todas as verificações em andamento que dependem dele falharão.
     • Ao usar o SHIR, verifique se a memória é suficiente para a fonte de dados que está sendo digitalizada. Por exemplo, quando você usa o SHIR para examinar uma fonte sap, se você vir "erro de memória fora":
       • Verifique se o computador SHIR tem memória suficiente. A quantidade recomendada é de 128 GB.
       • Na configuração de verificação, defina a memória máxima disponível como algum valor apropriado, por exemplo, 100.
       • Para obter mais informações, consulte os pré-requisitos em Verificar e gerenciar o SAP ECC Microsoft Purview.

   • Verificação de escopo

     • Ao configurar o escopo para a verificação, selecione apenas os ativos relevantes em um nível granular ou no nível pai. Essa prática garante que o custo de verificação seja ideal e que o desempenho seja eficiente. Todos os ativos futuros em um determinado pai serão selecionados automaticamente se o pai estiver totalmente ou parcialmente verificado.

     • Alguns exemplos para algumas fontes de dados:

       • Para SQL do Azure Banco de Dados ou Data Lake Storage Gen2, você pode escopo da verificação para partes específicas da fonte de dados. Selecione os itens apropriados na lista, como pastas, subpastas, coleções ou esquemas.
       • Para fontes Oracle, Metastore Database e Teradata, uma lista específica de esquemas a serem exportados pode ser especificada por meio de valores separados por ponto e vírgula ou padrões de nome de esquema usando expressões SQL LIKE.
       • Para a consulta Do Google Big, uma lista específica de conjuntos de dados a serem exportados pode ser especificada por meio de valores separados por ponto e vírgula.
       • Ao criar uma verificação de uma conta inteira do AWS, você pode selecionar buckets específicos para examinar. Ao criar uma verificação de um bucket específico do AWS S3, você pode selecionar pastas específicas para examinar.
       • Para Erwin, você pode escopo de sua verificação fornecendo uma lista separada de ponto e vírgula de cadeias de caracteres do localizador de modelo Erwin.
       • Para Cassandra, uma lista específica de espaços-chave a serem exportados pode ser especificada por meio de valores separados por ponto e vírgula ou por meio de padrões de nome de espaços-chave usando expressões SQL LIKE.
       • Para o Looker, você pode escopo de sua verificação fornecendo uma lista separada de ponto e vírgula de projetos looker.
       • Para o locatário do Power BI, você só pode especificar se deve incluir ou excluir o workspace pessoal.

       

     • Em geral, use "ignorar padrões", em que eles têm suporte, com base em curingas (por exemplo, para data lakes) para excluir arquivos temporários, configurações, tabelas do sistema RDBMS ou tabelas de backup ou STG.

     • Ao examinar documentos ou dados não estruturados, evite examinar um grande número desses documentos. A verificação processa os primeiros 20 MB desses documentos e pode resultar em maior duração de verificação.

   • Conjunto de regras de verificação

     • Ao selecionar o conjunto de regras de verificação, configure o sistema relevante ou o conjunto de regras de verificação personalizado que foi criado anteriormente.
     • Você pode criar tipos de arquivos personalizados e preencher os detalhes de acordo. Atualmente, o Microsoft Purview dá suporte a apenas um caractere no Delimitador Personalizado. Se você usar delimitadores personalizados, como ~, em seus dados reais, precisará criar um novo conjunto de regras de verificação.

     

   • Tipo de verificação e agendamento

     • O processo de verificação pode ser configurado para executar verificações completas ou incrementais.
     • Execute as verificações durante horários não comerciais ou fora do pico para evitar qualquer sobrecarga de processamento na origem.
     • A recorrência inicial deve ser pelo menos 1 minuto menor do que o tempo de verificação de agendamento, caso contrário, a verificação será disparada na próxima recorrência.
     • A verificação inicial é uma verificação completa e cada verificação subsequente é incremental. As verificações subsequentes podem ser agendadas como verificações incrementais periódicas.
     • A frequência de verificações deve se alinhar com o cronograma de gerenciamento de alterações da fonte de dados ou dos requisitos de negócios. Por exemplo:
       • Se a estrutura de origem puder mudar semanalmente, a frequência de verificação deverá estar em sincronização. As alterações incluem novos ativos ou campos dentro de um ativo que são adicionados, modificados ou excluídos.
       • Se espera-se que os rótulos de classificação ou confidencialidade estejam atualizados semanalmente, talvez por razões regulatórias, a frequência de verificação deve ser semanal. Por exemplo, se os arquivos de partições forem adicionados toda semana em um data lake de origem, você poderá agendar exames mensais. Você não precisa agendar exames semanais porque não há alteração nos metadados. Essa sugestão pressupõe que não haja novos cenários de classificação.
       • Quando você agenda uma verificação para ser executada no mesmo dia em que ela é criada, a hora de início deve ser antes do tempo de verificação em pelo menos um minuto.
       • A duração máxima que a verificação pode ser executada é de sete dias, possivelmente devido a problemas de memória. Esse período exclui o processo de ingestão. Se o progresso não tiver sido atualizado após sete dias, a verificação será marcada como falha. O processo de ingestão (no catálogo) atualmente não tem essa limitação.

   • Cancelar verificações

     • Atualmente, as verificações só poderão ser canceladas ou pausadas se o status da verificação tiver feito a transição para um estado "Em andamento" de "Enfileirado" depois de disparar a verificação.
     • Não há suporte para cancelar uma verificação individual de filho.

Pontos a serem observados

• Se um campo ou coluna, tabela ou um arquivo for removido do sistema de origem após a execução da verificação, ele só será refletido (removido) no Microsoft Purview após a próxima verificação completa ou incremental agendada.
• Um ativo pode ser excluído de um catálogo do Microsoft Purview usando o ícone Excluir sob o nome do ativo. Essa ação não removerá o objeto na origem. Se você executar uma verificação completa na mesma origem, ela será reingessada no catálogo. Se você tiver agendado uma verificação semanal ou mensal em vez disso (incremental), o ativo excluído não será escolhido a menos que o objeto seja modificado na origem. Um exemplo é se uma coluna for adicionada ou removida da tabela.
• Para entender o comportamento das verificações subsequentes depois de editar manualmente um ativo de dados ou um esquema subjacente por meio do portal de governança do Microsoft Purview, consulte Detalhes do ativo do Catálogo.
• Para obter mais informações, confira o tutorial sobre como exibir, editar e excluir ativos.

Próximas etapas

Gerenciar fontes de dados