Início / dba / Perguntas / 153258
Accepted
i-one
Asked: 2016-10-26 04:11:17 +0800 CST

Representar usuário ou login mapeado para certificado

  • 772

Suponha que haja um certificado criado no banco de dados

create certificate certName
    with subject = 'subj';
GO

E um usuário mapeado para este certificado

create user userName
    from certificate certName;
GO

Tentando representar este usuário diretamente

execute as user = 'userName';
GO

ou especificando o usuário na execute ascláusula do módulo

create procedure procName
with execute as 'userName'
as
    set nocount on;
GO

retorna erro

Msg 15517, Nível 16, Estado 1...
Não é possível executar como principal do banco de dados porque o principal "userName" não existe, esse tipo de principal não pode ser representado ou você não tem permissão.

No entanto, não consegui encontrar essa restrição mencionada na documentação ( aqui e aqui ), onde a única declaração relevante parece ser

user_name deve existir no banco de dados atual e deve ser uma conta singleton. user_name não pode ser um grupo, função, certificado, chave ou conta integrada, como NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService ou NT AUTHORITY\LocalSystem.

É possível representar o usuário (ou login) mapeado para o certificado ou não?

sql-server security

1 respostas

  1. Best Answer

    Logins e usuários criados a partir de certificados e chaves assimétricas não podem ser representados. Eles são apenas proxies para um conjunto de permissões que serão adicionadas a qualquer módulo que seja assinado com o mesmo Certificado ou Chave Assimétrica.

    Além disso, não faz muito sentido representar esses Logins e Usuários porque:

    1. essas permissões de proxy são adicionadas ao contexto de segurança atual (de um módulo em execução que foi assinado) em vez de substituir o contexto de segurança, que é o que a representação faz. É uma abordagem totalmente diferente, não apenas um mecanismo diferente para essencialmente a mesma coisa.
    2. a assinatura do módulo não se destina a consultas ad hoc. Parte do que torna a assinatura do módulo uma abordagem mais segura do que a representação é que a pessoa que concede as permissões elevadas (assinando o módulo para associá-lo a um conjunto adicional de permissões) sabe o que o código está fazendo e, uma vez que o código recebe o permissões elevadas, ele não pode ser alterado para fazer outra coisa, como algo que a pessoa que está assinando o módulo não aprovaria. Isso é tratado por assinaturas descartadas quando qualquer alteração é feita em um módulo assinado e pelo fato de que o texto do módulo (incluindo a EXECUTE AScláusula opcional da CREATEinstrução) é usado para criar a assinatura. Se o texto mudar, a assinatura não corresponderá.

    No final, o uso de Logins e/ou Usuários criados a partir de Chaves Assimétricas e Certificados substitui a necessidade de Representação.

    Ainda assim, se estiver procurando por um indicador mais oficial, a página do MSDN para CREATE USER declara:

    Usuários que não podem autenticar Esses usuários não podem fazer logon no SQL Server ou no banco de dados SQL.

    • Usuário sem login. Não é possível fazer login, mas pode receber permissões.CREATE USER CustomApp WITHOUT LOGIN;
    • Usuário com base em um certificado. Não é possível fazer login, mas pode receber permissões e assinar módulos.CREATE USER TestProcess FOR CERTIFICATE CarnationProduction50;
    • Usuário baseado em uma chave assimétrica. Não é possível fazer login, mas pode receber permissões e assinar módulos.CREATE User TestProcess FROM ASYMMETRIC KEY PacificSales09;

    No entanto, não poder fazer login/autenticar não significa "não pode representar", uma vez que os usuários sem login estão nessa lista e você pode fazer isso EXECUTE AS USER='{user_without_login}';.

    A página do MSDN para CREATE LOGIN afirma:

    Logins criados a partir de certificados ou chaves assimétricas são usados ​​apenas para assinatura de código. Eles não podem ser usados ​​para se conectar ao SQL Server.

    Enquanto a segunda frase repete o que a CREATE USERdocumentação diz, a primeira frase é um pouco mais específica: são apenas para assinatura de código.

    Por fim, a declaração de restrições que você encontrou na documentação de EXECUTE AS e da cláusula EXECUTE AS está correta, embora tenham sido redigidas de maneira confusa. Eles declaram (ênfase em negrito adicionada):

    name deve ser uma conta singleton e não pode ser um grupo, função, certificado, chave ou conta integrada, como NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService ou NT AUTHORITY\LocalSystem.

    Essa citação foi retirada da EXECUTE ASdocumentação, e a EXECUTE AS Clausedocumentação (quase a mesma redação) é citada na pergunta. Embora ambas as páginas usem os termos "certificado" e "chave", elas realmente significam "Login/Usuário baseado em certificado" e "Login/Usuário baseado em chave assimétrica", respectivamente. Estou assumindo isso com base no fato de que a lista de tipos principais fornecidos é encontrada em sys.server_principals(para logins) e sys.database_principals(para usuários), e nem os certificados nem as chaves assimétricas seriam listados em nenhuma dessas exibições de catálogo do sistema.

    • 5

relate perguntas