Controle de acesso a bancos de dados é algo que perturba a vida de desenvolvedores, IT Pros e DBAs desde… Bem, desde sempre!
Sabe aquele estória de connection string com usuário e senha rolando para lá e para cá? Quem nunca, né?
Além dos problemas óbvios com isso – acesso não-autorizado a dados que muitas vezes são confidenciais, há um outro agravante: os logins no SQL Server acontecem sempre no nível do servidor. Em outras palavras, há sempre o risco de um usuário malicioso fazer o que não deve no banco de dados master
do SQL Server.
Sabia que o SQL Server 2012 introduziu uma nova funcionalidade que reduz – e muito – esse risco? Venha conhecer os novos usuários contidos (contained users).
Historicamente, o processo de criação de usuários no SQL Server sempre foi feito em duas etapas. Na primeira criamos um login para que o usuário possa se conectar ao servidor:
CREATE LOGIN nome_do_usuário WITH PASSWORD = 'senha_do_usuário'
Esse login é criado no banco de dados master
, que contém todas as informações de sistema do SQL Server (e. por isso mesmo, é extremamente sensível). A seguir, criamos um user em cada um dos bancos de dados a que esse login deve ter acesso:
USE DATABASE foo GO CREATE nome_do_usuário FOR LOGIN 'nome_do_usuário'
O problema todo é a criação do login no banco de dados master
. Se, por acaso, o lockdown da conta não for adequadamente feito, no caso de uma invasão (através de SQL Injection, por exemplo), o invasor teria acesso ao banco de dados master
e, de lá, fazer enormes estragos (como o bom e velho DROP TABLE que acompanha praticamente todo ataque de SQL Injection).
Habilitando o uso de usuários contidos
A mudança introduzida no SQL Server 2012 é a de conter (limitar) um usuário a um único banco de dados. Ou seja, agora podemos criar um user sem um login associado. Dessa forma, esse usuário não tem acesso ao master
, mas apenas ao banco de dados designado. No caso de uma invasão, os danos podem ser contidos – na pior das hipóteses – a apenas o banco de dados que está sendo acessado. Para usar usuários contidos é preciso configurar seu ambiente. Esse processo varia dependendo do quê você está usando – SQL Server (on-premises) ou SQL Azure (nuvem).
SQL Server (on-premises)
Se você usa um SQL Server on-premises, então é necessário ter a versão 2012 ou superior. Além disso, é necessário ativar o recurso de usuários contidos:
sp_configure 'contained database authentication', 1; GO RECONFIGURE; GO
SQL Azure (nuvem)
Já no SQL Azure, é preciso que seu servidor esteja em modo de compatibilidade V12. Acesse o Portal do Azure, navegue até seu servidor e selecione a opção Latest SQL Database Update (1).
Faça o update (se necessário) e o recurso de contained users estará ativado automaticamente.
Utilizando usuários contidos
Uma vez que o recurso esteja disponível, use o comando CREATE USER para criar seus usuários contidos:
USE DATABASE foo GO CREATE USER nome_do_usuário WITH PASSWORD = 'senha_do_usuário'; GO
Agora, basta alterar suas connection strings para usar esse usuário. Como o usuário existe apenas no contexto do banco de dados, não se esqueça de informar o banco correto no instante da conexão:
Server=nome_do_servidor; Database=nome_do_banco; User ID=nome_do_usuário; Password=senha_do_usuário
Para saber mais
Contained Database Users – Making Your Database Portable
contained database authentication Server Configuration Option
Um abraço,
Igor
(Post publicado originalmente em https://www.tshooter.com.br/2016/03/03/aumente-a-segurana-de-seu-sql-server-com-usurios-contidos/)
Igor Abade
Igor Abade V. Leite ([email protected]) é Microsoft MVP (Most Valuable Professional) de Visual Studio ALM desde 2006. Palestrante em diversos eventos da comunidade de desenvolvimento de software (TechEd Brasil, The Developers’ Conference, DevOps Summit Brasil, Agile Brazil, Visual Studio Summit, QCON e outros), é também autor de artigos em revistas e sites como o MSDN Brasil. Desde março de 2011 é um dos sócios da Lambda3, uma consultoria especializada em ALM, desenvolvimento de software e treinamentos. Siga-o no Twitter @igorabade.