Compartilhar via

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

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 USER WITH PASSWORD 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 usuários em um banco de dados contido que têm a ALTER ANY USER permissão, como membros dos papéis fixos de banco de dados db_owner e db_securityadmin, podem conceder acesso ao banco de dados sem o conhecimento ou a permissão do administrador do SQL Server. Conceder aos usuários acesso a um banco de dados independente aumenta a área potencial da superfície de ataque em relação a toda a instância do SQL Server. Os administradores devem entender essa delegação de controle de acesso e ter muito cuidado ao conceder aos usuários no banco de dados contido a permissão ALTER ANY USER. Todos os proprietários de banco de dados têm a ALTER ANY USER permissão. Os administradores do SQL Server devem auditar periodicamente os usuários em um banco de dados independente.

Acessando outros bancos de dados usando a conta de convidado

Proprietários de banco de dados e usuários de banco de dados com a ALTER ANY USER permissão podem criar usuários de banco de dados independentes. Depois de se conectar 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, se os outros bancos de dados tiverem habilitado a conta de 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 independentes 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 bancos de dados, 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 TRUSTWORTHY configuração deverá estar ativada para o banco de dados DB1. Execute o comando a seguir para ativar a configuração TRUSTWORHTY.

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, usando o mesmo nome de um logon do SQL Server e se o logon do SQL Server se conectar especificando o banco de dados contido como o catálogo inicial, o logon do SQL Server não poderá se conectar. A conexão será avaliada como o usuário contido no banco de dados com a identidade de senha no banco de dados contido, em vez de como um usuário baseado no login do SQL Server. Isso pode causar uma negação intencional ou acidental de serviço para o logon do SQL Server.

  • Como prática recomendada, os membros da função de servidor fixa sysadmin devem considerar sempre se conectar sem usar a 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 de usar indevidamente a tentativa de logon. Em seguida, o administrador pode alterar para o banco de dados contido usando a instrução de USE<banco de dados> . Você também pode definir o banco de dados padrão do logon para o banco de dados contido, o que conclui o logon para 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 independentes 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 alterar para o banco de dados independente.

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

Aumentando o acesso alterando o 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 não contido 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, então o acesso do usuário poderá ser concedido criando usuários de banco de dados dependentes com senhas. Isso pode fornecer acesso sem o conhecimento ou o consentimento dos administradores do SQL Server. Para evitar que os bancos de dados sejam confinados, defina a opção Mecanismo de Banco de Dadoscontained database authentication como 0. Para impedir conexões de usuários de banco de dados independentes com senhas em bancos de dados independentes selecionados, use gatilhos de logon para cancelar tentativas de logon por usuários de banco de dados independentes com senhas.

Anexando um banco de dados contido

Ao anexar um banco de dados independente, 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 online no RESTRICTED_USER modo, o que impede a autenticação de usuários de banco de dados independentes com senhas. Somente entidades autorizadas por meio de logons 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 independente que permitia senhas fracas a um sistema com uma política de senha mais rigorosa, um administrador poderia permitir senhas que não atendem à política de senha atual no Mecanismo de Banco de Dados de anexação. Os administradores podem evitar reter as senhas fracas exigindo que todas as senhas sejam redefinidas para o banco de dados anexado.

Políticas de senha

As senhas em um banco de dados podem ser necessárias para serem 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 extensas disponíveis no Windows.

Autenticação Kerberos

Usuários de banco de dados independentes com senhas não podem usar a Autenticação Kerberos. Quando 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 independentes com senhas são armazenados no banco de dados independente. 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 independentes 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 independentes usando a Autenticação do Windows.

Como escapar 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 independentes.

Negação de serviço por meio 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 consumirá recursos adicionais e poderá contribuir para um ataque de negação de serviço.

Consulte Também

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

  • Last updated on