Auditoria no Azure Synapse Analytics

A auditoria do Azure Synapse Analytics acompanha eventos da base de dados e escreve-os para o Armazenamento do Azure, um espaço de trabalho do Azure Monitor Log Analytics ou o Hubs de Eventos do Azure.

A auditoria ajuda-o a:

• Manter um registo de auditoria dos eventos selecionados.
• Compreender a atividade da base de dados e investigar discrepâncias ou anomalias.
• Crie relatórios sobre a atividade utilizando consultas, livros e ferramentas de monitorização a jusante.
• Apoiar os requisitos de conformidade regulamentar e organizacional. A auditoria não garante a conformidade por si só.

Overview

Você pode usar a auditoria do Banco de dados SQL para:

• Manter um registo de auditoria de eventos selecionados. Você pode definir categorias de ações de banco de dados a serem auditadas.
• Relatório sobre a atividade do banco de dados. Você pode usar relatórios pré-configurados e um painel para começar rapidamente com relatórios de atividades e eventos.
• Analise relatórios. Você pode encontrar eventos suspeitos, atividades incomuns e tendências.

Abordagem recomendada de auditoria para cargas de trabalho OLTP de grande porte

Para ambientes com muitas bases de dados a executar cargas de trabalho OLTP pesadas, usar auditoria ao nível do servidor com definições predefinidas pode levar a volumes de auditoria muito grandes em todo o servidor lógico. Como todos os eventos de todas as bases de dados são escritos na mesma pasta de auditoria, consultar registos de auditoria para uma única base de dados torna-se lento e operacionalmente dispendioso. Para melhorar o desempenho e reduzir o ruído:

• Mude para auditoria ao nível da base de dados. Cada base de dados escreve na sua própria pasta de registo de auditoria, reduzindo o volume total analisado e tornando a recuperação mais rápida.
• Revise a configuração da auditoria. Determine se é necessário capturar todos os eventos completados em lote ou se uma configuração personalizada filtrada pode cumprir os seus requisitos de segurança e conformidade.

Proteger informações sensíveis nos registos de auditoria

O texto da instrução auditada pode conter valores sensíveis quando as aplicações concatenam esses valores em SQL dinâmico. Utilize parâmetros para os valores dos dados, evite incorporar segredos ou dados pessoais no texto da consulta e restrinja o acesso ao registo de auditoria a utilizadores autorizados.

As permissões no destino de auditoria controlam o acesso a partir do exterior do motor SQL. Aplique o privilégio mínimo ao Armazenamento do Azure, Log Analytics e Event Hubs, e monitorize o acesso a esses recursos.

Limitations

• Não é possível habilitar a auditoria em um pool SQL dedicado pausado. Retome o pool antes de ativar a política.
• Identidades geridas atribuídas pelos utilizadores não são suportadas para auditoria no Azure Synapse Analytics.
• Uma identidade gerida atribuída pelo sistema é suportada para um destino Armazenamento do Azure quando a conta de armazenamento está atrás de uma rede virtual ou firewall. Identidades geridas não são suportadas para o Azure Synapse, a menos que a conta de armazenamento esteja atrás de uma rede virtual ou firewall.
• Os pools SQL do Synapse suportam apenas os grupos de ações de auditoria por defeito.
• Não há suporte para auditoria em bancos de dados com nomes que contenham o ? caractere. Esta limitação aplica-se tanto à auditoria ao nível do servidor como ao nível da base de dados, pois as bases de dados com ? nos seus nomes já não são suportadas no Azure.
• Os registos de auditoria armazenam até 4.000 caracteres nos campos statement e data_sensitivity_information. Caracteres adicionais são truncados.

Remarks

• Eventos iniciados por SQLDBControlPlaneFirstPartyApp no registo de Atividade são uma função interna Azure do plano de controlo Base de Dados SQL do Azure. Eventos iniciados por SQLDBControlPlaneFirstPartyApp fazem parte de uma operação interna de sincronização entre o motor SQL e Azure Resource Manager. Estes eventos fazem parte normal da gestão do Base de Dados SQL do Azure e são necessários para a representação e operação corretas de recursos no Azure.
• Armazenamento Premium com BlockBlobStorage é suportado. O armazenamento padrão é suportado. No entanto, para escrever registos de auditoria numa conta de armazenamento atrás de uma rede virtual ou firewall, deve usar uma conta de armazenamento v2 de uso geral. Se usar uma conta v1 ou Armazenamento de Blobs de uso geral, atualize para uma conta de armazenamento v2 de uso geral. Para instruções específicas, consulte Escrever registos de auditoria numa conta de armazenamento atrás de uma rede virtual e firewall. Para obter mais informações, consulte Tipos de contas de armazenamento.
• Quando ativa a auditoria SQL e configura restrições de rede de saída, deve adicionar à lista de permissões os nomes de domínio totalmente qualificados da sua conta de armazenamento de auditoria para garantir que os eventos de auditoria cheguem ao destino. Se não colocar o endpoint de armazenamento na lista de permissões, o tráfego de auditoria é bloqueado, resultando em perda de eventos de auditoria. Depois de adicionar os FQDNs da conta de armazenamento exigidos à lista de autorizações, deve guardar novamente a sua configuração de auditoria para retomar o fluxo normal de eventos de auditoria.
• Namespace hierárquico para todos os tipos de conta de armazenamento padrão e conta de armazenamento premium com BlockBlobStorage é suportado.
• Os registos de auditoria são escritos para Append Blobs num Armazenamento de Blobs do Azure na sua subscrição do Azure.
• Os registos de auditoria estão em formato .xel e podem ser abertos com SQL Server Management Studio (SSMS).
• Para configurar um armazenamento de registos imutável para os eventos de auditoria ao nível do servidor ou da base de dados, siga as instruções fornecidas por Armazenamento do Azure. Ao configurar o armazenamento de blob imutável para auditoria, certifique-se de que Permitir gravações de acréscimo protegidas esteja definido como Acrescentar blobs ou Bloquear e acrescentar blobs. A opção Nenhum não é suportada. Para políticas de retenção baseadas em tempo, o intervalo de retenção da conta de armazenamento deve ser menor do que a configuração de retenção da Auditoria SQL. Configurações em que a política de armazenamento é definida, mas a retenção de Auditoria SQL é 0 não são suportadas.
• Pode escrever registos de auditoria numa conta Armazenamento do Azure atrás de uma rede virtual ou firewall.
• Para detalhes sobre o formato do registo, hierarquia da pasta de armazenamento e convenções de nomenclatura, consulte formato do registo de auditoria.
• Ao usar a autenticação Microsoft Entra, os registos de logins falhados não aparecem no registo de auditoria SQL. Para ver os registos de auditoria de logins falhados, precisa de visitar o Microsoft Entra centro de administração, que regista os detalhes destes eventos.
• Depois de configurar as suas definições de auditoria, pode ativar a nova funcionalidade de deteção de ameaças e configurar os emails para receber alertas de segurança. Ao usar a deteção de ameaças, você recebe alertas proativos sobre atividades anômalas do banco de dados que podem indicar possíveis ameaças à segurança. Para mais informações, consulte SQL Advanced Threat Protection.
• Depois que um banco de dados com auditoria habilitada for copiado para outro servidor lógico , você poderá receber um e-mail notificando que a auditoria falhou. Esta condição é um problema conhecido e a auditoria deve funcionar conforme esperado na base de dados recém-copiada.

Conteúdo relacionado

• Configurar a auditoria para Azure Synapse Analytics
• Azure Synapse Analytics audit log format
• Analisar registos e relatórios de auditoria do Azure Synapse Analytics
• Auditoria das melhores práticas para ambientes de produção
• Auditoria usando identidade gerida no Azure Synapse Analytics