O DBA é o guardião dos dados, e há dois aspectos em ser um guardião. A primeira é a integridade. Inclui tarefas como verificar a consistência do banco de dados, criar backups e, caso apareça algum problema, ter um plano de recuperação de banco de dados abrangente e bem projetado.
O segundo aspecto é a segurança. Ele sugere garantir que apenas usuários autorizados tenham acesso aos dados e apenas aos dados de que precisam.
Você pode encontrar vários recursos dedicados à segurança na Web. No entanto, acho que algumas coisas importantes carecem de atenção adequada. Neste artigo, gostaria de me concentrar nessas opções e demonstrar por que é importante conhecê-las e tratá-las corretamente.
Uma missão para comprometer um SQL Server
Vamos fazer um Role-Playing Game no qual você é um Agente Secreto, e sua missão, caso aceite, é roubar Dados Muito Importantes do TargetDB banco de dados hospedado por um SQL Server. Você precisa obter esses dados e excluí-los.
É possível obter um Login para você, mas cada login no servidor tem permissões NEGADAS explícitas no banco de dados e nos dados de destino. A única informação que nosso agente pode lhe fornecer é aquela gerada para verificação pelo protocolo de segurança durante a criação do seu login.
Informações do banco de dados do servidor de destino.
Permissões do servidor:
Permissões do banco de dados:
Como todo agente decente, vamos fazer a lição de casa e verificar com o que você está lidando.
Você não pode simplesmente fazer login e se conectar ao TargetDB , já que todas as permissões são negadas para seu login e seu usuário mapeado explicitamente. Você precisa entrar de outro banco de dados.
Uma porta trancada
Ações entre bancos de dados não são coisas fáceis de fazer. Considere-o como uma porta fechada com duas fechaduras. Não vamos nos concentrar nos detalhes técnicos aqui, mas você pode consultar o artigo Estendendo a representação do banco de dados usando EXECUTE AS MSDN (recomendo fortemente fazê-lo).
O primeiro bloqueio é Confiar no autenticador , e o segundo é Confiar no banco de dados .
Vamos começar com o primeiro bloqueio. Confiar no autenticador significa que, para acesso a outro banco de dados B, o proprietário do banco de dados A deve receber (explícita ou implicitamente) o AUTENTICAR permissão no banco de dados B.
Espere um minuto! O autenticador no nível do banco de dados é o proprietário do próprio banco de dados (não o confunda com o db_owner função de banco de dados!).
Verifique os proprietários do banco de dados:
Apesar de seguirem boas práticas usando uma conta por servidor, que não é SA , desta forma eles gentilmente abriram o primeiro cadeado para você.
Vamos nos concentrar no segundo bloqueio.
De alguma forma, você precisa ter um banco de dados criado no servidor com o TRUSTWORTHY propriedade LIGADA . A prática recomendada aqui é definir a propriedade de banco de dados TRUSTWORTHY como OFF .
Este é o momento em que devemos dizer:e se você já tiver esse banco de dados?
É o banco de dados MSDB.
O segundo bloqueio está feito. Você nem precisou quebrar nenhuma das fechaduras.
A importância da função db_owner
Agora, você tem que lidar com um desafio. De alguma forma, você precisa entrar no banco de dados MSDB com o db_owner função de banco de dados porque tem permissão implícita de representação.
Como o MSDB geralmente não é o foco dos administradores de banco de dados, essa missão não é mais impossível. Vamos ver o que você pode fazer só porque tem um usuário com o db_owner função de banco de dados no banco de dados MSDB:
Tente se conectar ao TargetDB :
Este é um erro esperado. Lembre-se do protocolo de segurança aplicado no login fornecido. Vamos iniciá-lo.
Tente se conectar ao TargetDB e para selecionar os dados de destino:
Funciona! Vamos modificá-lo e depois verificar a ação.
Isso é tudo.
Missão cumprida.
Como você viu, concentrei-me em uma combinação específica de configuração de banco de dados de segurança. Esses eram os proprietários do banco de dados e os TRUSTWORTHY opção de banco de dados prestando atenção especial ao MSDB. O cenário apresentado foi apenas um em que dados sensíveis podem ser comprometidos da mesma forma. Vamos rever outro cenário possível agora.
Proprietário do banco de dados + TRUSTWORTHY
Vamos verificar os detalhes do plano de fundo começando com o conhecido problema:propriedade do banco de dados. Quais detalhes de login o proprietário do(s) seu(s) banco(s) de dados deve usar? Muitas pessoas dizem que SA é uma escolha adequada.
Fiz uma rápida pesquisa no Google e encontrei respostas como as seguintes:
“Eu não me lembro de isso ser uma preocupação para mim. Além de parecer irritante nos relatórios ou não conseguir remover o usuário se ele possuir um banco de dados, mas não acho que isso afete as operações do servidor. Você pode simplesmente escolher sa para consistência.”
Ou
“Eu não acho que possuir um banco de dados por SA ou qualquer outro usuário deva ser motivo de preocupação. O que importa é quem está realizando “o quê” em seu banco de dados. Portanto, é uma boa ideia criar usuários com privilégios válidos. Para simplificar, você pode especificar o proprietário como SA.”
A situação atual é que usar a conta SA como proprietário do banco de dados é a PIOR prática . Pessoalmente, acho que isso deve ser destacado em todos os blogs e em todas as documentações relacionadas a esse tópico.
Se criarmos usuários apenas com privilégios válidos, isso seria suficiente, mas infelizmente não é assim que as coisas costumam funcionar. Você precisa estar preparado para os “possíveis piores cenários”. Basta pensar, o que poderíamos fazer em nossos exemplos anteriores se o proprietário do banco de dados padrão fosse SA !
Vamos continuar com a segunda opção, a TRUSTWORTHY opção de banco de dados. A situação é um pouco melhor, mas ainda tem um problema comum. Como é comumente considerado, a prática recomendada aqui é Definir a propriedade de banco de dados 'Confiável' como Desativada . Acabamos de ver por que essa opção é ruim .
Mas isso não é tudo. Se você tentar encontrar alguns scripts para verificar essa propriedade, provavelmente encontrará um script semelhante a este:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'O sp_Blitz O script que verifica a integridade do SQL Server também verifica as configurações padrão dos bancos de dados (incluindo TRUSTWORTHY como um valor padrão de 0) e relata todos os bancos de dados que possuem configurações não padrão. No entanto, o script ignora os bancos de dados do sistema.
Além disso, há um artigo MS KB, que se concentra neste tópico. Consulte as diretrizes para usar as configurações de banco de dados TRUSTWORTHY no SQL Server:
Há um exemplo de código no artigo, que lista os bancos de dados que têm o bit TRUSTWORTHY ATIVADO e cujos proprietários de banco de dados pertencem à função de servidor sysadmin:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
O que é comum nesses scripts? Cada script exclui o MSDB, mas como observa o artigo MS KB, você acabou de vê-lo em nossa “missão”:
Observação Observação:por padrão, a configuração TRUSTWORTHY é definida como ON para o banco de dados MSDB. Alterar essa configuração de seu valor padrão pode resultar em comportamento inesperado por componentes do SQL Server que usam o banco de dados MSDB.
Gostaria de enfatizar que o foco principal desta seção não é a opção de banco de dados TRUSTWORTHY nem a propriedade do proprietário do banco de dados em si, mas a combinação dessas duas opções. Concentrei-me principalmente no MSDB porque a configuração TRUSTWORTHY está definida como ON para o banco de dados MSDB por padrão.
Conclusão
É tudo por agora. Percorremos e verificamos os cenários práticos relacionados à segurança do SQL Server. Também analisamos opções importantes do banco de dados, como o proprietário do banco de dados e a configuração do banco de dados TRUSTWORTHY.
Eu só queria destacar essas opções, pois elas são críticas, especialmente quando falamos sobre elas em combinação.
