Esta questão indica que a permissão “Exibir estado do servidor” é necessária para vários DMV “s (visualizações de gerenciamento dinâmico), mas não consigo encontrar nada sobre quem você fazem e não querem conceder a permissão para.
Agora, é claro, eu entendo “menos permissões” e por que você não iria querer apenas concedê-las 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 de conceder a um usuário a permissão “Exibir estado do servidor”. O que eles podem fazer que talvez não devam “ter permissão para fazer …
Atualizar : uma implicação é que o usuário será capaz de usar os DMVs para ver as consultas. Se as consultas ou parâmetros de consulta podem conter informações confidenciais que o usuário não seria capaz de ver de outra forma, permitir VIEW SERVER STATE permitiria que eles fizessem isso (ou seja, dob = ou ssn =).
Resposta
Não há problemas de desempenho significativos em 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ê a maioria dos detalhes sobre seus pontos fracos, por exemplo, um usuário mal-intencionado pode ver suas estatísticas de espera mais comuns são, o que pode ajudá-lo a direcionar um ataque DoS contra o seu servidor.
Isso é possível? Com certeza. 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.
Resposta
Como administrador, você veria essas informações como pertencentes ao seu domínio (desempenho / uso do índice / etc), mas há motivos potencialmente convincentes para que um A organização de negócios gostaria dessas informações para um grande sistema legado que eles suportam – identificando tabelas zumbis que só são tocadas por processos de manutenção, por exemplo.
No final, sempre acaba sendo uma questão de “sorte e generosidade” uma vez que a chamada para saber se algum pedido específico é justificado acaba sendo uma escolha suave e não uma fórmula rápida. O uso de padrões de práticas recomendadas 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.
Resposta
Com relação às implicações de desempenho, não tenho conhecimento de nenhuma para esta ou qualquer outra permissão.
Com relação a:
O que eles podem fazer que talvez não devessem ser autorizados a fazer
Simplificando, eles podem ver as coisas que talvez eles não devessem estar vendo. 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 alguns outros 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 ok com alguém vendo tudo permitido por esta permissão agora, às vezes DMVs são adicionados em Service Packs / atualizações cumulativas, e talvez uma nova informação seja exposta da qual você não está ciente.
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 importa é: alguém precisa dessa permissão para uso ad hoc ? Ou seja, alguém precisa de flexibilidade para 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 só faz o que foi codificado para fazer). Assinatura de módulo é como você faz isso. O conceito geral é:
- Crie o (s) procedimento (s) armazenado (s) e / ou TVF (s) de múltiplas instruções para realizar as ações desejadas.
- Conceda
EXECUTEnesses módulos para qualquer usuário e / ou funções que precisam para realizar essas ações - Criar um certificado
- Assine o (s) módulo (s) usando esse certificado (usando
ADD SIGNATURE) - Copie o certificado para o banco de dados
[master](ou seja, crie um certificado em[master]usando a chave pública do certificado usado para assinar o (s) módulo (s). - Crie um login do certificado copiado para
[master] - Conceda qualquer instância- nível de permissão ns são necessários para esse login baseado em certificado (que pode incluir adicioná-lo a funções de nível de instância).
Para alguns exemplos, consulte:
Resposta
É um problema de segurança. Você nunca pode errar se você segue o Princípio dos menos privilegiados . Em outras palavras, se um principal de autenticação não precisa de uma permissão específica, então não ” Você dá informações sobre o tipo de fechadura da sua porta para outras pessoas que não precisam saber disso sobre a 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 por sorte e generosidade, teremos problemas maiores com um pouco mais de frequência. 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.
sys.dm_db_missing_index_details) e eles querem saber exatamente quais são os riscos de fazer isso.