Início / dba / Perguntas / 19459
Accepted
Rachel
Asked: 2012-06-19 10:26:29 +0800 CST

Existe uma maneira de configurar um usuário para executar SPs, mas não acessar as tabelas de dados subjacentes?

  • 772

Temos duas instâncias de banco de dados em duas caixas de servidor separadas que estão vinculadas. O usuário do site precisa ser capaz de executar procedimentos armazenados no Banco de DadosA que consultam as tabelas do Banco de DadosB, no entanto, não deve ser capaz de ler diretamente das tabelas no Banco de DadosB.

Isso é possível no Sql Server 2005?

Simplesmente criar um procedimento armazenado e dar ao usuário da web permissões para executá-lo retorna um erro deAccess to the remote server is denied because no login-mapping exists.

Eu realmente não quero dar à conta de usuário do site acesso gratuito às tabelas DatabaseB.

Atualizar

A sugestão de uso de Aaron EXECUTE AS OWNERnão funciona porque Ownernão tem acesso ao DatabaseB.

Usar EXECUTE AS 'UserWithPermissions'retorna um erro de Access to the remote server is denied because the current security context is not trusted. A pesquisa on-line me leva a acreditar que isso ocorre porque o banco de dados não está marcado como TRUSTWORTHY , portanto, o banco de dados remoto rejeita a conexão. Suspeito que funcionaria bem se as duas instâncias do banco de dados estivessem no mesmo servidor.

Eu não queria definir o banco de dados da web, TRUSTWORTHYjá que parte da segurança é mais relaxada, então fui com a outra opção de Aaron: criar um usuário DatabaseBque tenha acesso apenas a algumas visualizações específicas contendo os dados que o site deve acessar, em seguida, vá para Propriedades de segurança no objeto Servidor vinculado e configure o usuário do site para fazer login como o novo usuário limitado ao acessar o servidor vinculado.

Isso permitiu que o usuário do meu site tivesse acesso limitado a dados específicos no banco de dados privado, sem dar acesso a nenhuma das tabelas subjacentes.

sql-server-2005 stored-procedures

2 respostas

  1. Best Answer

    Você não poderia executar o procedimento A com execute as ownerou execute as 'db user tied to security account associated with linked server'? Dessa forma, os direitos do chamador não precisam ser transferidos...

    Ou você pode criar um login no servidor remoto que tenha apenas a capacidade de executar as consultas desejadas e adicionar uma conta de representação ao servidor vinculado existente no Servidor A para que o login do servidor web local represente o novo login no servidor B.

    • 4

  2. Eu prefiro resolver esse tipo de problema com a assinatura do módulo:

    use [<DatabaseName>];
go

create certificate <CertificateName>
    encryption by password = 'CorrectHorseBatteryStaple1!'
    with subject = 'Signing Certificate for Module: <Object>';

add signature to object::<Schema>.<Object>
    by certificate <CertificateName>
    with password = <CertificatePassword>;
go

grant execute on <Schema>.<Object>
    to <LoginName>;

backup certificate <CertificateName>
    to file = <Location>;
go

-- create certificate in master
use [master];
go

create certificate <CertificateName>
    from file = <Location>;

    Altere o procedimento para execute as ownere <LoginName>poderá usá-lo como pretendido sem precisar de concessões para objetos subjacentes. Você ainda precisa lidar com permissões entre servidores de alguma maneira, mas isso facilita a parte entre bancos de dados.

    • 0

relate perguntas