Partilhar via

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

  • Artigo

Aplica-se a:SQL ServerAzure SQL Managed Instance

Os bancos de dados contidos têm algumas ameaças exclusivas que devem ser compreendidas e atenuadas pelos administradores do Mecanismo de Banco de Dados do SQL Server. A maioria das ameaças está relacionada ao USUÁRIO COM SENHA processo de autenticação, que move o limite de autenticação do nível do Mecanismo de Banco de Dados para o nível do banco de dados.

Os utilizadores numa base de dados contida que têm a permissão ALTER ANY USER, como membros das funções fixas db_owner e db_accessadmin de base de dados, podem conceder acesso à base de dados sem o conhecimento ou a permissão do administrador do SQL Server. Conceder aos usuários acesso a um banco de dados contido aumenta a área de superfície de ataque potencial contra toda a instância do SQL Server. Os administradores devem entender esta delegação de controlo de acesso e ter muito cuidado ao conceder aos utilizadores no banco de dados contido a permissão ALTERAR QUALQUER UTILIZADOR. Todos os proprietários de bancos de dados têm a permissão ALTERAR QUALQUER USUÁRIO. Os administradores do SQL Server devem auditar periodicamente os usuários em um banco de dados contido.

Acessando outros bancos de dados usando a conta de convidado

Proprietários de bancos de dados e usuários de banco de dados com a permissão ALTER ANY USER podem criar usuários de banco de dados contidos. Depois de se conectar a um banco de dados contido em uma instância do SQL Server, um usuário de banco de dados contido pode acessar outros bancos de dados no Mecanismo de Banco de Dados, se os outros bancos de dados tiverem 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 criando usuários de banco de dados contidos idênticos em cada banco de dados. Use a opção SID ao criar o segundo usuário com 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 entre bases de dados, deve-se definir a opção CONFIÁVEL na base de dados chamadora. Por exemplo, se o utilizador (Carlo) definido acima estiver no DB1, para executar SELECT * FROM db2.dbo.Table1;, a configuração TRUSTWORTHY deverá estar ativada para a base de dados DB1. Execute o código a seguir para definir a configuração TRUSTWORTHY.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Criando um usuário que duplica um login

Se for criado um utilizador de base de dados contido com senha, usando o mesmo nome de um logon do SQL Server, e se o logon do SQL Server se conectar especificando a base de dados contida como o catálogo inicial, o logon do SQL Server não conseguirá estabelecer a ligação. A conexão será avaliada como o utilizador do banco de dados contido com o principal de palavra-passe no banco de dados contido, em vez de um utilizador baseado no login do SQL Server. Isso pode causar uma negação de serviço intencional ou acidental para o logon do SQL Server.

  • Como prática recomendada, os membros do sysadmin função de servidor fixa devem considerar sempre se conectar sem usar a opção de catálogo inicial. Isso conecta o login ao banco de dados mestre e evita quaisquer tentativas de um proprietário do banco de dados de usar indevidamente a tentativa de login. Em seguida, o administrador pode mudar para o banco de dados incluído usando a instrução USE<database>. Você também pode definir o banco de dados padrão do logon para o banco de dados contido, que conclui o logon para o mestre e, em seguida, transfere o logon para o banco de dados contido.

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

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

  • Quando bancos de dados contidos estão presentes, os usuários de bancos de dados que não são bancos de dados contidos devem se conectar ao Mecanismo de Banco de Dados sem usar um catálogo inicial ou especificando o nome do banco de dados de um banco de dados não contido como o catálogo inicial. Isso evita a conexão com o banco de dados contido que está sob controle menos direto dos administradores do Mecanismo de Banco de Dados.

Aumentando o acesso alterando o status de contenção de um banco de dados

Os logins que têm a permissão ALTER ANY DATABASE, como os membros da função de servidor fixa dbcreator, e usuários num banco de dados não contido que têm a permissão CONTROL DATABASE, como os 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 PARCIAL ou COMPLETA, o acesso do utilizador poderá ser concedido criando utilizadores de banco de dados contidos com senhas. Isso pode fornecer acesso sem o conhecimento ou consentimento dos administradores do SQL Server. Para evitar que bancos de dados sejam contidos, defina a opção Mecanismo de Banco de Dadosautenticação de banco de dados contido como 0. Para impedir conexões de usuários de banco de dados contidos com senhas em bancos de dados contidos selecionados, use gatilhos de login para cancelar tentativas de login de usuários de banco de dados contidos com senhas.

Anexando um banco de dados contido

Ao anexar um banco de dados contido, um administrador pode conceder aos usuários indesejados acesso à instância do Mecanismo de Banco de Dados. Um administrador preocupado com esse risco pode colocar o banco de dados on-line no modo RESTRICTED_USER, o que impede a autenticação para usuários de banco de dados contidos com senhas. Somente entidades autorizadas por meio de logins poderão acessar o Mecanismo de Banco de Dados.

Os usuários são criados usando os 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. Ao anexar um banco de dados contido que permitia senhas fracas a um sistema com uma política de senha mais rígida, um administrador poderia permitir senhas que não atendessem à política de senha atual no Mecanismo de Banco de Dados anexado. Os administradores podem evitar reter as senhas fracas exigindo que todas as senhas sejam redefinidas para o banco de dados anexado.

Políticas de palavra-passe

As senhas em um banco de dados podem ser exigidas como senhas fortes, mas não podem ser protegidas por políticas de senha robustas. Use a Autenticação do Windows sempre que possível para aproveitar as políticas de senha mais abrangentes disponíveis no Windows.

Autenticação Kerberos

Os usuários de banco de dados contidos com senhas não podem usar a Autenticação Kerberos. Sempre que possível, use a Autenticação do Windows para aproveitar os recursos do Windows, como Kerberos.

Ataque de dicionário offline

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

Escapando de um banco de dados contido

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

Negação de serviço através de AUTO_CLOSE

Não configure bancos de dados contidos para fechar automaticamente. Se fechado, abrir o banco de dados para autenticar um usuário consome recursos adicionais e pode contribuir para um ataque de negação de serviço.

Ver também

Bases de Dados Contidas
migrar para um banco de dados parcialmente contido