Partilhar via

Auditoria para o Banco de Dados SQL do Azure e o Azure Synapse Analytics

Aplica-se a:Banco de Dados SQL do Azure do Azure Synapse Analytics

Auditoria para Base de Dados SQL do Azure e Azure Synapse Analytics regista eventos de base de dados e escreve-os num log de auditoria na sua conta de armazenamento Azure, espaço de trabalho do Log Analytics ou Hubs de Eventos.

Auditoria também:

  • Ajuda a manter a conformidade regulamentar, entender a atividade do banco de dados e obter informações sobre discrepâncias e anomalias que podem indicar preocupações comerciais ou suspeitas de violações de segurança.

  • Permite e facilita a adesão aos padrões de conformidade, embora não garanta a conformidade. Para obter mais informações, consulte a Central de Confiabilidade do Microsoft Azure onde você pode encontrar a lista mais atual de certificações de conformidade do Banco de Dados SQL.

Observação

Para obter informações sobre a auditoria da Instância Gerenciada SQL do Azure, consulte Introdução à auditoria da Instância Gerenciada SQL do Azure.

Visão geral

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.

Importante

As auditorias para a Base de Dados SQL do Azure, pools SQL do Azure Synapse Analytics e Instância Gerenciada SQL do Azure são otimizadas para a disponibilidade e o desempenho da base de dados ou instância a ser auditada. Durante períodos de atividade muito alta ou alta carga de rede, o recurso de auditoria pode permitir que as transações prossigam sem registrar todos os eventos marcados para auditoria.

Aprimoramentos de desempenho, disponibilidade e confiabilidade na auditoria de servidor para o Banco de Dados SQL do Azure (GA, julho de 2025)

  • Rearquitetei as principais partes da Auditoria SQL, resultando em maior disponibilidade e confiabilidade das auditorias de servidor. Como um benefício adicional, há um alinhamento de recursos mais estreito com o SQL Server e a Instância Gerenciada SQL do Azure. A auditoria de banco de dados permanece inalterada.
  • O design anterior de auditoria aciona uma auditoria no nível de banco de dados e executa uma sessão de auditoria para cada banco de dados no servidor. A nova arquitetura de auditoria cria uma sessão de evento estendida no nível do servidor que captura eventos de auditoria para todos os bancos de dados.
  • O novo design de auditoria otimiza a memória e a CPU e é consistente com o funcionamento da auditoria no SQL Server e na Instância Gerenciada SQL do Azure.

Alterações da rearquitetura da auditoria de servidor

  • Alteração na estrutura de pastas da conta de armazenamento
    • Uma das principais alterações envolve uma alteração na estrutura de pastas para logs de auditoria armazenados em contêineres de contas de armazenamento. Anteriormente, os logs de auditoria do servidor eram gravados em pastas separadas; um para cada banco de dados, com o nome do banco de dados servindo como o nome da pasta. Com a nova atualização, todos os logs de auditoria do servidor serão consolidados em uma única pasta rotulada master. Esse comportamento é o mesmo que a Instância Gerenciada SQL do Azure e o SQL Server.
  • Alteração da estrutura das pastas para réplicas de leitura única.
    • As réplicas de banco de dados somente leitura anteriormente tinham seus logs armazenados em uma pasta somente leitura. Esses logs agora serão gravados na pasta master. Você pode recuperar esses logs filtrando na nova coluna is_secondary_replica_true.
  • Permissões necessárias para exibir logs de auditoria:
    • VIEW DATABASE SECURITY AUDIT permissão no banco de dados do usuário

Limitações da auditoria

  • Não é suportada a habilitação da auditoria em um pool SQL pausado do Azure Synapse no. Para habilitar a auditoria, retome o pool Synapse SQL.

  • Não há suporte para habilitar a auditoria usando a UAMI (Identidade Gerenciada Atribuída pelo Usuário) no Azure Synapse.

  • Atualmente, não há suporte para identidades gerenciadas para o Azure Synapse, a menos que a conta de armazenamento esteja atrás de uma rede virtual ou firewall.

  • Devido a restrições de desempenho, não auditamos o tempdb , e as tabelas temporárias . Embora o grupo de ações em lote concluído capture instruções em tabelas temporárias, ele pode não preencher corretamente os nomes dos objetos. No entanto, a tabela de origem é sempre auditada, garantindo que todas as inserções da tabela de origem para tabelas temporárias sejam registradas.

  • A auditoria para pools SQL do Azure Synapse dá suporte a grupos de ações de auditoria padrão apenas.

  • Quando você configura a auditoria para um servidor lógico no Azure ou no Banco de Dados SQL do Azure com o destino do log como uma conta de armazenamento, o modo de autenticação deve corresponder à configuração dessa conta de armazenamento. Se estiver usando chaves de acesso de armazenamento como o tipo de autenticação, a conta de armazenamento de destino deverá ser habilitada com acesso às chaves da conta de armazenamento. Se a conta de armazenamento estiver configurada para usar apenas a autenticação com o Microsoft Entra ID (anteriormente Azure Ative Directory), a auditoria poderá ser configurada para usar identidades gerenciadas para autenticação.

  • Não há suporte para auditoria em bancos de dados com nomes que contenham o ? caractere. Isso se aplica à auditoria no nível do servidor e no nível do banco de dados , pois os bancos de dados com ? seus nomes não são mais suportados no Azure.

  • Os registos de auditoria Azure SQL Database e Azure Synapse capturam até 4.000 caracteres nos campos statement e data_sensitivity_information. Se a saída de uma ação auditável exceder este limite, qualquer conteúdo além dos primeiros 4.000 caracteres é truncado e excluído do registo de auditoria.

Comentários

  • Armazenamento Premium com BlockBlobStorage é suportado. O armazenamento padrão é suportado. No entanto, para que a auditoria escreva numa conta de armazenamento atrás de uma rede virtual ou firewall, deve ter uma conta de armazenamento de uso geral v2 . Se tiveres uma conta de armazenamento de uso geral v1 ou Blob, atualiza para uma conta de armazenamento de uso geral v2. Para obter instruções específicas, consulte Gravar auditoria numa conta de armazenamento atrás da VNet e do firewall. Para obter mais informações, consulte Tipos de contas de armazenamento.

  • 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 gravados em Append Blobs num Armazenamento de Blobs do Azure na sua subscrição do Azure

  • Os logs de auditoria estão no formato .xel e podem ser abertos com SQL Server Management Studio (SSMS).

  • Para configurar um armazenamento de log imutável para eventos de auditoria no nível de servidor ou banco de dados, siga as instruções fornecidas pelo 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.

  • Você pode gravar logs de auditoria em uma conta de Armazenamento do Azure atrás de uma rede virtual ou firewall.

  • Para obter detalhes sobre o formato de log, hierarquia da pasta de armazenamento e convenções de nomenclatura, consulte o artigo Formato de Log de Auditoria do Banco de Dados SQL.

  • A auditoria em Usar réplicas de leitura apenas para descarregar o processamento de consultas de leitura é automaticamente habilitado. Para obter mais informações sobre a hierarquia das pastas de armazenamento, convenções de nomenclatura e formato de log, consulte o artigo formato de log de auditoria do Banco de Dados SQL.

  • Ao utilizar a autenticação do Microsoft Entra, os registos de logins falhados não aparecem no log de auditoria do SQL. Para exibir registos de auditoria de login com falha, você precisa visitar o centro de administração do Microsoft Entra, que registra os detalhes desses eventos.

  • Os logons são roteados pelo gateway para a instância específica onde o banco de dados está localizado. Com os logins do Microsoft Entra, as credenciais são verificadas antes de tentar usar esse usuário para entrar no banco de dados solicitado. Em caso de falha, o banco de dados solicitado nunca é acessado, portanto, nenhuma auditoria ocorre. Com logins SQL, as credenciais são verificadas nos dados solicitados, portanto, neste caso, eles podem ser auditados. Os logins bem-sucedidos, que obviamente chegam ao banco de dados, são auditados em ambos os casos.

  • Depois de definir as configurações de auditoria, você pode ativar o novo recurso de deteção de ameaças e configurar e-mails 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 obter 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. Esse é um problema conhecido e a auditoria deve funcionar conforme o esperado no banco de dados recém-copiado.

Conteúdo relacionado

  • Last updated on