Partilhar via

Práticas recomendadas de segurança com bancos de dados independentes

  • Artigo

Aplica-se a: SQL Server Instância Gerenciada de SQL do Azure

Bancos de dados independentes têm algumas ameaças exclusivas que devem ser entendidas e mitigadas pelos administradores do Mecanismo de Banco de Dados do SQL Server . A maioria das ameaças está relacionada ao processo de autenticação USER WITH PASSWORD que move o limite de autenticação do nível do mecanismo de banco de dados para o nível do banco de dados.

Usuários em um banco de dados independente que têm a permissão ALTER ANY USER, como membros das funções de banco de dados fixas db_owner e db_accessadmin, podem permitir acesso ao banco de dados sem conhecimento ou permissão ou o administrador do SQL Server. A concessão de acesso a um banco de dados independente a usuários aumenta a área da superfície de ataque potencial contra toda a instância do SQL Server. Os administradores devem entender essa delegação de controle de acesso e ter muito cuidado ao conceder permissão ALTER ANY USER aos usuários no banco de dados independente. Todos os proprietários de banco de dados têm a permissão ALTER ANY USER . Os administradores do SQL Server deve auditar os usuários periodicamente em um banco de dados independente.

Acessando outros bancos de dados que usam a conta Convidado

Os proprietários e os usuários de banco de dados com a permissão ALTER ANY USER podem criar usuários de banco de dados independente. Após conectar-se a um banco de dados independente em uma instância do SQL Server, um usuário de banco de dados independente poderá acessar outros bancos de dados no mecanismo de banco de dados, caso os outros bancos de dados tenham habilitado a conta convidado.

Criando um usuário duplicado em outro banco de dados

Alguns aplicativos podem exigir que um usuário tenha acesso a mais de um banco de dados. Isso pode ser feito por meio da criação de usuários de banco de dados independente idênticos em cada banco de dados. Use a opção de SID ao criar o segundo usuário com a senha. O exemplo a seguir cria dois usuários idênticos em dois bancos de dados.

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO

Para executar uma consulta de bancos de dados cruzado, você deve definir a opção TRUSTWORTHY no banco de dados de chamada. Por exemplo se o usuário (Carlo) definido acima estiver em DB1, para executar SELECT * FROM db2.dbo.Table1; , a configuração TRUSTWORTHY deve estar ativada para o banco de dados DB1. Execute o código a seguir para ativar a configuração TRUSTWORTHY .

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Criando um usuário que duplica um logon

Se um usuário de banco de dados independente com senha for criado com o mesmo nome de um logon do SQL Server e se o logon do SQL Server se conectar especificando o banco de dados independente como catálogo inicial, o logon do SQL Server não poderá se conectar. A conexão será avaliada como a entidade de segurança do usuário com senha no banco de dados independente em vez de como um usuário baseado no logon do SQL Server. Isso pode provocar uma negação intencional ou acidental do serviço para o logon do SQL Server.

  • Como uma prática recomendada, membros da função de servidor fixa sysadmin devem sempre considerar conectar-se com o uso da opção de catálogo inicial. Isso conecta o logon ao banco de dados mestre e evita qualquer tentativa de um proprietário de banco de dados usar indevidamente a tentativa de logon. Em seguida, o administrador pode mudar para o banco de dados independente usando o banco de dados<da instância USE>. Também é possível definir o banco de dados padrão do logon para o banco de dados independente, o que conclui o logon no mestree, em seguida, transfere o logon para o banco de dados independente.

  • Como uma prática recomendada, não crie usuários de banco de dados independente com senhas que tenham o mesmo nome que logons do SQL Server.

  • Se o logon duplicado existir, conecte-se ao banco de dados mestre sem especificar um catálogo inicial e execute o comando USE para mudar para o banco de dados independente.

  • Quando os bancos de dados independentes estiverem presentes, os usuários de bancos de dados dependentes devem se conectar ao mecanismo de banco de dados sem usar um catálogo inicial ou especificando o nome de um banco de dados dependente como catálogo inicial. Isso evita a conexão ao banco de dados independente que está sob controle menos direto pelos administradores do mecanismo de banco de dados.

Aumentando o acesso por meio da alteração do status de contenção de um banco de dados

Logons que têm a permissão ALTER ANY DATABASE , como membros da função de servidor fixa dbcreator , e usuários em um banco de dados dependente que têm a permissão CONTROL DATABASE , como membros da função de banco de dados fixa db_owner , podem alterar a configuração de contenção de um banco de dados. Se a configuração de contenção de um banco de dados for alterada de NONE para PARTIAL ou FULL, o acesso de usuários poderá ser concedido por meio da criação de usuários de banco de dados independente com senhas. Isso pode fornecer acesso sem o conhecimento ou consentimento dos administradores do SQL Server. Para impedir a contenção de qualquer banco de dados, defina a opção autenticação de banco de dados independente do mecanismo de banco de dados para 0. Para impedir conexões por usuários de banco de dados independente com senhas em bancos de dados independentes selecionados, use gatilhos de logon para cancelar tentativas de logon por usuários de banco de dados independente com senhas.

Anexando um banco de dados independente

Por meio da anexação de um banco de dados independente, um administrador pode dar acesso não desejado de usuários à instância do mecanismo de banco de dados. Um administrador preocupado com esse risco pode colocar o banco de dados online em modo RESTRICTED_USER , o que impede a autenticação para usuários de bancos de dados independentes com senha. Apenas entidades de segurança autorizadas por meio de logon poderão acessar o mecanismo de banco de dados.

Os usuários são criados com o uso dos requisitos de senha em vigor no momento em que são criados, e as senhas não são verificadas novamente quando um banco de dados é anexado. Com a anexação de um banco de dados independente que permite senhas fracas a um sistema com uma política de senha mais rígida, um administrador pode permitir senhas que não atendam à política de senha atual no mecanismo de bancos de dados de anexação. Os administradores podem evitar a contenção de senhas fracas com a exigência de que todas as senhas sejam redefinidas para o banco de dados anexado.

Políticas de senha

É possível exigir senhas fortes em um banco de dados, mas não é possível protegê-las com políticas de senha robusta. Use a Autenticação do Windows sempre que possível para tirar proveito das políticas de senha mais extensivas disponíveis no Windows.

Autenticação Kerberos

Usuários de bancos de dados independentes com senhas não podem usar a Autenticação Kerberos. Quando possível, use a Autenticação do Windows para tirar proveito dos recursos do Windows, como o Kerberos.

Ataque de dicionário offline

Os hashes de senha de usuários de banco de dados independente com senhas são armazenados no banco de dados independente. Qualquer usuário com acesso aos arquivos de banco de dados pode executar um ataque de dicionário contra os usuários de banco de dados independente com senhas em um sistema não auditado. Para mitigar essa ameaça, restrinja o acesso aos arquivos de banco de dados, ou apenas permita conexões ao bancos de dados contido por meio da Autenticação do Windows.

Escape de um banco de dados independente

Se um banco de dados for parcialmente independente, os administradores do SQL Server deverão auditar os recursos dos usuários e módulos periodicamente em bancos de dados independentes.

Negação de serviço por meio de AUTO_CLOSE

Não configure bancos de dados independentes como fechamento automático. Se fechado, a abertura do banco de dados para autenticar um usuário consumirá recursos adicionais e poderá contribuir para um ataque de negação de serviço.

Confira também

Bancos de dados independentes
Migrar para um banco de dados parcialmente independente