Auditoria para Base de Dados SQL do Azure e Azure Synapse Analytics

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

A auditoria de Base de Dados SQL do Azure e Azure Synapse Analytics acompanha os eventos da base de dados e escreve-os num registo de auditoria na sua conta de armazenamento do Azure, no espaço de trabalho do Log Analytics ou nos Event Hubs.

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 mais informações, consulte o Microsoft Azure Trust Center onde pode encontrar a lista mais recente de certificações de conformidade com bases de dados SQL.

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.

Melhorias no desempenho, disponibilidade e fiabilidade na auditoria de servidores para Base de Dados SQL do Azure (julho de 2025 GA)

• Rearquitetei as principais partes da Auditoria SQL, resultando em maior disponibilidade e confiabilidade das auditorias de servidor. Como benefício adicional, há um alinhamento de funcionalidades mais próximo com o SQL Server e o Azure SQL Managed Instance. 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 memória e CPU, e é consistente com o funcionamento da auditoria no SQL Server e no Azure SQL Managed Instance.

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 registos de auditoria do servidor são consolidados numa única pasta rotulada master. Este comportamento é o mesmo do Azure SQL Managed Instance e do 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 registos estão agora escritos 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 na base de dados de utilizadores

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.

Limitações da auditoria

• Ativar auditorias num pool SQL Azure Synapse pausado não é suportado. Para habilitar a auditoria, retome o pool Synapse SQL.
• Ativar a auditoria usando a Identidade Gerida Atribuída pelo Utilizador (UAMI) não é suportado no Azure Synapse.
• Atualmente, as 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.

• Devido a limitações de desempenho, não auditamos as tempdbtabelas 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 Azure Synapse SQL pools suporta grupos de ações de auditoria só padrão.

• Quando configura a auditoria para um servidor lógico em Azure ou Base de Dados SQL do Azure com o destino do registo como 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 autenticação apenas com Microsoft Entra ID (anteriormente Azure Active Directory), a auditoria pode ser configurada para usar identidades geridas para autenticação.

• Não há suporte para auditoria em bancos de dados com nomes que contenham o ? caractere. Isto aplica-se tanto à auditoria nível do servidor como à auditoria ao nível da base de dados, pois bases de dados com nos >.

• Os registos de auditoria Base de Dados SQL do Azure 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

• 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 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 tiver uma conta v1 ou Armazenamento de Blobs de uso geral, atualize para uma conta de armazenamento v2 de uso geral. 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.
• Quando os clientes ativam a auditoria SQL e também configuram restrições de rede de saída , têm de permitir listar os nomes de domínio totalmente qualificados da sua conta de armazenamento de auditoria para garantir que os eventos de auditoria conseguem chegar com sucesso ao destino. Se o endpoint de armazenamento não estiver na lista de permissões, o tráfego de auditoria é bloqueado, resultando em perda de eventos de auditoria. Após adicionar os FQDNs da conta de armazenamento exigidos à lista de permissões, os clientes devem 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 em Append Blobs num Armazenamento de Blobs do Azure da sua subscrição 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 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 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.
• 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 utilizador para iniciar sessão na base de dados solicitada. 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 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

• O que há de novo em auditoria SQL do Azure
• Comece com a auditoria do Azure SQL Managed Instance
• Auditoria para SQL Server
• Configurar Auditoria para Base de Dados SQL do Azure e Azure Synapse Analytics