Início / dba / Perguntas / 290112
Accepted
Aleksey Vitsko
Asked: 2021-04-21 03:21:42 +0800 CST

Há alguma coisa a considerar antes de conceder VIEW SERVER STATE e VIEW DEFINITION aos desenvolvedores?

  • 772

Gostaria de conceder abaixo as permissões ao grupo Desenvolvedores, no SQL Server de Produção:

VIEW SERVER STATE
VIEW DEFINITION (server level)

Isso é feito para torná-los capazes de consultar algumas visualizações e funções de gerenciamento dinâmico, visualizar dados de desempenho, bem como ver o código (definições) de todos os procedimentos e funções armazenados

Existem desvantagens ou razões pelas quais isso não é bom em determinados cenários?
Quaisquer possíveis efeitos colaterais indesejados da concessão das permissões acima?

Segunda pergunta - se eu conceder VIEW DEFINITIONno banco de dados mestre, isso o torna no nível do servidor e não precisa ser concedido em nenhum banco de dados do usuário? O mesmo com SHOWPLAN?

sql-server permissions

3 respostas

  1. Best Answer

    Para VIEW DEFINITION/ VIEW ANY DEFINITIONvocê provavelmente está bem, já que os desenvolvedores provavelmente já têm acesso ao código-fonte.

    Para VIEW SERVER STATE, isso controla o acesso a uma ampla variedade de funcionalidades, portanto, você precisa ser mais deliberado e cauteloso ao conceder essa permissão. A consideração principal é: Quão aberto versus restrito o acesso precisa ser? O problema é que não há granularidade para VIEW SERVER STATE: é tudo ou nada.

    Os desenvolvedores precisam de acesso total a consultas ad hoc ou simplesmente precisam da capacidade de executar algumas consultas predefinidas que você fornecerá? Se eles precisarem de acesso total à consulta ad hoc, você provavelmente precisará conceder a eles VIEW SERVER STATE. Mas, se você puder fornecer um número limitado de consultas, não precisará conceder nada a elas (fora da EXECUTEpermissão nos procedimentos armazenados que contêm as consultas que estão fornecendo). Nesse caso, você concederia aos procedimentos armazenados a VIEW SERVER STATEpermissão (e/ouALTER TRACEpermissão). Os desenvolvedores só poderiam usar essas permissões elevadas por meio dos procedimentos armazenados. E, se algum desenvolvedor tentar ser sorrateiro e atualizar um dos procedimentos armazenados para usar as permissões elevadas de outra maneira, qualquer procedimento armazenado atualizado perderá automaticamente as permissões elevadas.

    Tudo isso é possível através da assinatura do módulo . Por exemplo, veja minha resposta para Executar permissões para um procedimento de armazenamento que cria bancos de dados (também aqui no DBA.StackExchange).

    Uma vez que você tenha esse mecanismo de segurança instalado (ou seja, o certificado e o login e/ou usuário baseado em certificado, dependendo do escopo das permissões que você precisa conceder), ele pode ser aplicado a qualquer número de procedimentos armazenados, gatilhos, TVFs (exceto para inline) e UDFs. Se uma segunda permissão for necessária, se a permissão for sempre necessária junto com a permissão inicial, basta adicioná-la ao mesmo principal baseado em certificado (login e/ou usuário). Se a segunda permissão for necessária apenas em alguns casos, crie outro certificado e outro principal baseado em certificado a partir do 2º certificado, atribua a outra permissão ao 2º principal baseado em certificado e executeADD SIGNATUREnovamente, usando o 2º certificado, nos objetos que precisam da outra permissão (você pode adicionar várias assinaturas aos objetos, combinando as permissões).

    • 3

  2. VIEW DEFINITIONé uma permissão de banco de dados. Há uma permissão de servidor correspondente que VIEW ANY DEFINITIONvocê pode adicionar. Se você deseja conceder acesso a alguns logins para visualizar o estado do servidor e todos os metadados do objeto, você pode fazer assim:

    create server role developers
grant view any definition to developers
grant connect any database to developers 
grant view server state to developers

    Você pode conceder SHOWPLANpara cada banco de dados ou conceder ALTER TRACEno nível do servidor. ALTER TRACEtambém permite que o usuário crie SQL Traces que talvez você não queira permitir que os desenvolvedores façam em um servidor de produção. Tudo isso está documentado em Permissões .

    • 2

  3. Algumas notas do link de Dan Guzman:

    VER ESTADO DO SERVIDOR

    O usuário poderá usar os DMVs para examinar as consultas. Se as consultas ou parâmetros de consulta puderem conter informações confidenciais que o usuário não conseguiria ver, permitir VIEW SERVER STATE permitiria que eles o fizessem (ou seja, dob = ou ssn =)

    Do ponto de vista da segurança, você corre o risco de permitir que um usuário veja detalhes sobre seus pontos fracos. 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 DoS contra 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.

    Simplificando, eles podem ver coisas que talvez não deveriam 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 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 que você esteja bem com alguém vendo tudo o que é permitido por essa permissão agora, às vezes DMVs são adicionados em Service Packs / Atualizações Cumulativas e, portanto, talvez uma nova informação seja exposta e você não esteja ciente

    • 1

relate perguntas