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

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

A auditoria do Banco de Dados SQL Azure e do Azure Synapse Analytics rastreia eventos do banco de dados e os grava em um log de auditoria na sua conta de Armazenamento do Microsoft Azure, no workspace do Log Analytics ou nos Hubs de Eventos.

A auditoria também:

• Ajuda a manter conformidade com as normas, entender a atividade do banco de dados e aprofundar-se sobre discrepâncias e anomalias que podem indicar preocupações comerciais ou violações suspeitas de segurança.

• Permite e facilita a adesão aos padrões de conformidade, embora não garanta a conformidade. Para saber mais, confira a Central de Confiabilidade do Microsoft Azure, onde é possível encontrar a lista mais atual de certificações de conformidade do Banco de Dados SQL.

Visão geral

É possível usar a auditoria do Banco de Dados SQL para:

• Reter uma trilha de auditoria dos eventos selecionados. Definir categorias de ações de banco de dados a ser auditadas.
• Relate sobre a atividade do banco de dados. Você pode usar relatórios pré-configurados e um painel para começar rapidamente com a geração de relatórios de atividades e eventos.
• Analise os relatórios. Encontrar eventos suspeitos, atividades incomuns e tendências.

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

• Re-arquitetou partes principais da Auditoria SQL, resultando em maior disponibilidade e confiabilidade de auditorias de servidor. Como um benefício adicional, há um alinhamento de recursos mais próximo com o SQL Server e a Instância Gerenciada de SQL do Azure. A auditoria de banco de dados permanece inalterada.
• O design anterior da auditoria dispara uma auditoria no nível do 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 de SQL do Azure.

Alterações da nova arquitetura da auditoria de servidor

• Alteração da estrutura de pastas para a conta de armazenamento:
  • Uma das principais alterações envolve uma alteração de estrutura de pastas para logs de auditoria armazenados em contêineres de conta 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 de SQL do Azure e o SQL Server.
• Alteração da estrutura de pastas para réplicas somente leitura:
  • Anteriormente, as réplicas de banco de dados de somente leitura tinham seus logs armazenados em uma pasta de somente leitura. Esses logs agora serão gravados na master pasta. 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 é possível habilitar a auditoria nos pools de SQL do Azure Synapse em pausa. Para habilitar a auditoria, retome o pool de SQL do Synapse.

• 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 as identidades gerenciadas por parte do Azure Synapse, a menos que a conta de armazenamento esteja protegida por uma rede virtual ou por um firewall.

• Devido a restrições de desempenho, não auditamos o tempdb e as tabelas temporárias . Embora o grupo de ações concluído em lote 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 de pools do SQL do Azure Synapse dá suporte apenas a grupos de ação de auditoria padrão.

• 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 você 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 Active 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 contêm 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 têm mais suporte no Azure.

• Os logs de auditoria do 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 esse limite, qualquer conteúdo além dos primeiros 4.000 caracteres será truncado e excluído do registro de auditoria.

Comentários

• Há suporte para o armazenamento Premium com o BlockBlobStorage. Há suporte para o armazenamento Standard. Entretanto, para que a auditoria realize a gravação em uma conta de armazenamento protegida por uma rede virtual ou por um firewall, é necessário ter uma conta de armazenamento de uso geral v2. Se tiver uma conta de armazenamento de uso geral v1 ou de Armazenamento de Blobs, atualize para uma conta de armazenamento de uso geral v2. Para ver instruções específicas, consulte Gravar auditoria em uma conta de armazenamento protegida por VNet e firewall. Para obter mais informações, veja Tipos de contas de armazenamento.

• Há suporte para o namespace hierárquico para todos os tipos de conta de armazenamento Standard e Premium com o BlockBlobStorage.

• Os logs de auditoria são gravados nos Blob de acréscimo em um Armazenamento de Blobs do Azure em sua assinatura do Azure

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

• Para configurar um repositório de logs imutável para os eventos de auditoria no nível do servidor ou do banco de dados, siga as instruções fornecidas pelo Armazenamento do Azure. Ao configurar o armazenamento de blobs imutável para auditoria, verifique se Permitir gravações de acréscimo protegidas está definida como Blobs de acréscimo ou Blobs de bloqueio e acréscimo. Não há suporte para a opção None . 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 de SQL. Configurações em que a política de armazenamento é definida, mas a retenção da Auditoria de SQL é 0, não são suportadas.

• É possível realizar a gravação de logs de auditoria em uma conta de armazenamento do Azure protegida por uma rede virtual ou por um firewall.

• Para obter mais detalhes sobre o formato dos logs, a hierarquia da pasta de armazenamento e as convenções de nomenclatura, confira o artigo: Formato do log de auditoria do Banco de Dados SQL.

• A auditoria no Uso de réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura é habilitada automaticamente. Para obter mais informações sobre a hierarquia das pastas de armazenamento, as convenções de nomenclatura e o formato dos logs, confira o artigo: Formato do log de auditoria do Banco de Dados SQL.

• Ao usar a autenticação do Microsoft Entra, registros de tentativa de logon com falha não aparecem no log de auditoria do SQL. Para exibir registros de auditoria de logon com falha, você precisa visitar o centro de administração do Microsoft Entra, que registra os detalhes desses eventos.

• Os logons são encaminhados pelo gateway para a instância específica em que o banco de dados está localizado. Com os logons do Microsoft Entra, as credenciais são verificadas antes da tentativa de usar esse usuário para entrar no banco de dados solicitado. Em caso de falha, o banco de dados solicitado nunca é acessado, portanto, a auditoria não é realizada. Com logons do SQL, as credenciais são verificadas nos dados solicitados e, portanto, nesse caso, elas podem ser auditadas. Os logons bem-sucedidos, que obviamente alcançaram o banco de dados, são auditados em ambos os casos.

• Depois de definir as configurações de auditoria, você poderá ativar o novo recurso de detecção de ameaças e configurar emails para receber alertas de segurança. Ao usar a detecçã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, confira Proteção Avançada contra Ameaças ao SQL.

• Após um banco de dados com auditoria habilitada ser copiado para outro servidor lógico, você pode receber um email notificando que a auditoria apresentou falhas. Trata-se de um problema conhecido; a auditoria deve funcionar conforme o esperado no banco de dados recém-copiado.

Conteúdo relacionado

• Novidades na Auditoria de SQL do Azure

• Introdução à auditoria da Instância Gerenciada de SQL do Azure

• Auditoria do SQL Server

• Configurar a Auditoria do Banco de Dados SQL do Azure e Azure Synapse Analytics