Esta questão indica que a permissão "Exibir estado do servidor" é necessária para vários DMVs (visualizações de gerenciamento dinâmico), mas não consigo encontrar nada sobre quem você deseja e não deseja conceder a permissão.
Agora é claro que entendo "menos permissões" e por que você não gostaria de concedê-lo a ninguém, mas não consigo encontrar nenhuma orientação sobre como avaliar se DEVE ser concedido ou não.
Portanto, minha pergunta: quais são as implicações de segurança e desempenho de conceder a um usuário a permissão "Exibir estado do servidor". O que eles podem fazer que talvez não devam ser autorizados a fazer...
Atualização : uma implicação é que o usuário poderá usar o DMV para consultar as consultas. Se as consultas ou parâmetros de consulta puderem conter informações confidenciais que o usuário não conseguiria ver de outra forma, permitir VIEW SERVER STATE permitiria que eles o fizessem (ou seja, dob = ou ssn =).
Não há problemas de desempenho significativos que eu possa imaginar 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, então, por exemplo, um usuário mal-intencionado pode ver suas estatísticas de espera mais comuns, o que pode ajudá-lo a direcionar um ataque DoS contra seu servidor .
Isso é possível? Definitivamente. Isso é provável? Sou compelido a dizer Não, mas lembre-se de que estima-se que 90% dos ataques contra empresas sejam de invasores internos.
Como administrador, você veria essas informações como estando em seu domínio (desempenho / uso de índice / etc), mas há motivos potencialmente convincentes para que uma organização de desenvolvimento queira essas informações para um grande sistema legado que eles suportam - identificando tabelas zumbis que são apenas tocadas por processos de manutenção, por exemplo.
No final, sempre acaba sendo uma questão de "sorte e generosidade", pois a pergunta sobre se algum pedido específico é justificado acaba sendo uma escolha suave e não uma fórmula nítida. O uso de padrões de melhores 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 "falar com a mão" como ponto de partida.
Em relação às implicações de desempenho, não tenho conhecimento de nenhuma para esta ou qualquer outra permissão.
Em relação a:
Simplificando, eles podem ver coisas que talvez não devessem ver. E não pense nisso apenas em termos de SQL Server. Essa permissão específica também rege DMVs como sys.dm_os_sys_info e algumas 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ê estiver bem com alguém vendo tudo o que é permitido por esta permissão agora, às vezes DMVs são adicionados em Service Packs / Atualizações Cumulativas, e então talvez uma nova informação seja exposta que você não conhece.
Como você já mencionou dar às pessoas as permissões mínimas necessárias, o que realmente importa é: alguém precisa dessa permissão para uso ad hoc ? Ou seja, alguém precisa da flexibilidade de fazer suas próprias perguntas? A criação de 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 está livre para qualquer coisa permitida por essa permissão) e, em vez disso, concede as permissões ao código (que faz apenas o que está codificado para fazer). Assinatura de módulo é como você consegue isso. O conceito geral é:
EXECUTEesses módulos a qualquer usuário e/ou funções que precisem executar essas açõesADD SIGNATURE)[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).[master]Para alguns exemplos, consulte:
Como manter a propriedade do banco de dados restaurando entre domínios?
Use permissões de alto nível com segurança e facilidade sem concedê-las a ninguém: nível de servidor
É um problema de segurança. Você nunca errará 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 a ele. Você dá informações sobre o tipo de fechadura em sua porta para outras pessoas que não precisam saber disso sobre sua casa? Eu espero que não. Eles provavelmente não fariam nada, mas ainda não é prudente.
Se baseássemos os princípios de dados na sorte e na generosidade, estaríamos em apuros com mais frequência. A segurança é um aspecto em que você só deve conceder quando puder defender por que concedeu. Você está simplesmente dando a alguém mais informações do que eles precisam saber . Não faça isso. O estado do servidor ainda é sensível.