Implicações de segurança e desempenho de "Exibir estado do servidor"

Esta pergunta indica que a permissão "Exibir estado do servidor" é necessária para várias DMVs (visualizações de gerenciamento dinâmico), mas não consigo encontrar nada sobre quem você faz e não deseja conceder a permissão.

Agora, é claro, eu entendo "menos permissões" e por que você não gostaria de conceder a ninguém, mas não consigo encontrar nenhuma orientação sobre como avaliar se DEVE ser concedida ou não.

Então, minha pergunta: quais são as implicações de segurança e desempenho da concessão de permissão ao usuário "View Server State". O que eles podem fazer que talvez não devam fazer ...

Atualização : uma implicação é que o usuário poderá usar as DMVs para examinar as consultas. Se as consultas ou parâmetros de consulta puderem conter informações confidenciais que, de outra forma, o usuário não conseguiria ver, permitir VIEW SERVER STATE permitiria que o fizessem (por exemplo, dob = ou ssn =).

Não há problemas significativos de desempenho que eu possa pensar ao conceder essa permissão. Do ponto de vista da segurança, você corre o risco de permitir que um usuário veja o que você mais detalha sobre seus pontos fracos; portanto, por exemplo, um usuário mal-intencionado pode visualizar suas estatísticas de espera mais comuns, o que pode ajudá-lo a direcionar um ataque de negação de serviço ao seu servidor .

Isso é possível? Definitivamente. Isso é provável? Sou obrigado a dizer não, mas lembre-se de que estima-se que 90% dos ataques contra empresas sejam de invasores internos.

Como administrador, você visualizaria essas informações como estando em seu domínio (desempenho / uso de índice / etc), mas existem razões potencialmente convincentes para que uma organização de desenvolvimento queira essas informações para um grande sistema legado suportado - identificando tabelas de zumbis que são tocadas apenas por processos de manutenção, por exemplo.

No final, sempre acaba sendo uma questão de "sorte e generosidade", uma vez que a solicitação de justificação de alguma solicitação específica acaba sendo uma escolha suave e não uma fórmula precisa. O uso de padrões de boas práticas sem olhar para o contexto é, em si, um antipadrão bastante desagradável e a realidade é que muitos abordam suas posições com o "falar com a mão" como ponto de partida.

Em relação às implicações de desempenho, não conheço nenhuma para esta ou qualquer outra permissão.

A respeito de:

O que eles podem fazer que talvez não devam fazer

Simplificando, eles podem ver coisas que talvez não devessem estar vendo. E não pense nisso apenas em termos de SQL Server. Essa permissão específica também governa as DMVs, como sys.dm_os_sys_info e várias outras que fornecem informações sobre a máquina host (hardware, serviços, etc.). Você nem sempre sabe quais informações podem ser usadas contra você. E, mesmo se você concorda com alguém que vê tudo o que é permitido por essa permissão agora, às vezes as DMVs são adicionadas nos Service Packs / Atualizações Cumulativas e, portanto, talvez seja exibida uma nova informação que você não conhece.

Não consigo encontrar nenhuma orientação sobre como avaliar se deve ser concedido ou não.

Como você já mencionou dar às pessoas as permissões mínimas necessárias, o que realmente se resume é: alguém precisa dessa permissão para uso ad hoc ? Ou seja, alguém precisa da flexibilidade de apresentar suas próprias consultas? Criar um ou mais procedimentos armazenados e / ou TVFs com várias instruções funcionaria? Nesse caso, você não precisa conceder permissões a nenhum usuário (que é livre para qualquer coisa permitida por essa permissão); em vez disso, você concede as permissões ao código (que faz apenas o que está codificado para fazer). A assinatura do módulo é como você consegue isso. O conceito geral é:

1. Crie o (s) procedimento (s) armazenado (s) e / ou TVF (s) de múltiplas instruções para executar as ações desejadas.
2. Conceda EXECUTEesses módulos a qualquer usuário e / ou função necessária para executar essas ações
3. Crie um certificado
4. Assine o (s) módulo (s) usando esse certificado (usando ADD SIGNATURE)
5. Copie o certificado no [master]banco de dados (ou seja, crie um certificado [master]usando a chave pública do certificado usado para assinar o (s) módulo (s).
6. Crie um logon do certificado copiado para [master]
7. Conceda as permissões no nível da instância necessárias para esse logon baseado em certificado (que pode incluir a adição a funções no nível da instância).

Para alguns exemplos, consulte:

• Como manter a propriedade do banco de dados restaurando entre domínios?

• Use com segurança e facilidade as permissões de alto nível sem concedê-las a ninguém: no nível do servidor

É um problema de segurança. Você nunca pode dar errado se seguir o Princípio dos Menos Privilegiados . Em outras palavras, se um principal de autenticação não precisar de uma permissão específica, não a conceda. Você fornece informações sobre o tipo de fechadura na sua porta a outras pessoas que não precisam saber isso sobre sua casa? Eu espero que não. Eles provavelmente não fariam nada, mas ainda não é prudente.

Se basearmos os princípios de dados fora da sorte e da generosidade, teríamos problemas maiores com bastante frequência. A segurança é um aspecto em que você só deve conceder quando pode defender por que concedeu. Você está simplesmente dando a alguém mais informações do que elas precisam saber . Não faça isso. O estado do servidor ainda é sensível.