Início / dba / Perguntas / 197928
Accepted
BradC
Asked: 2018-02-15 09:36:45 +0800 CST

O encadeamento de permissões entre bancos de dados funciona para objetos pertencentes a sa/dbo?

  • 772

Eu tenho dois bancos de dados, ambos de propriedade do sa. Todos os objetos em ambos os bancos de dados estão no esquema dbo.

Eu tenho um usuário bobem dbSafeque precisa selecionar em uma exibição que une tabelas de dbSafee dbRestricted. Não quero conceder bobpermissão direta a essas tabelas em dbRestricted, pois elas contêm colunas que não quero bobver.

Eu concedi bob SELECTpermissão na exibição e SET DB_CHAINING ONnos dois bancos de dados, mas ainda estou recebendo um erro:

O servidor principal "bob" não pode acessar o banco de dados "dbRestricted" no contexto de segurança atual.

Estou entendendo mal o que o encadeamento entre bancos de dados faz ?

Se o objeto de origem no banco de dados de origem e os objetos de destino nos bancos de dados de destino forem de propriedade da mesma conta de logon, o SQL Server não verificará as permissões nos objetos de destino.

O encadeamento de banco de dados pode funcionar neste cenário, com o proprietário sae o esquema do banco de dados dbo? Ou tem que ser uma conta de login explícita/esquema não padrão?

A resposta aceita para essa pergunta sugere a criação de uma visualização dbRestrictede a atribuição de permissão direta a bob, isso funcionaria neste caso? E se adicionar uma visualização a esse banco de dados não for uma opção para mim (devido a restrições de desenvolvedor/fornecedor)? Não é para isso que serve o encadeamento entre bancos de dados?

sql-server sql-server-2012

2 respostas

  1. Best Answer

    Você precisa criar um usuário para bob em dbRestricted. Você não precisa conceder acesso bob à tabela em dbRestricted.

    Este exemplo verificável minimamente completo mostra isso em ação:

    USE master;
CREATE DATABASE db_a;
ALTER DATABASE db_a SET DB_CHAINING ON;
CREATE DATABASE db_b;
ALTER DATABASE db_b SET DB_CHAINING ON;
CREATE LOGIN db_a_login WITH PASSWORD = 'aasdfasdfasdf78723%';
GO

USE db_a;
CREATE TABLE dbo.t
(
    someval varchar(10) NOT NULL
);
INSERT INTO dbo.t (someval) VALUES ('db_a');

CREATE USER db_a_login FOR LOGIN db_a_login;

USE db_b;
CREATE TABLE dbo.t
(
    someval varchar(10) NOT NULL
);
INSERT INTO dbo.t (someval) VALUES ('db_b');
CREATE USER db_a_login FOR LOGIN db_a_login;


USE db_a;
GO
CREATE VIEW dbo.both_t
AS
SELECT *
FROM db_a.dbo.t
UNION ALL
SELECT *
FROM db_b.dbo.t;
GO
GRANT SELECT ON dbo.both_t TO db_a_login;
GRANT SELECT ON dbo.t TO db_a_login;
GO

EXECUTE AS LOGIN = 'db_a_login';
SELECT *
FROM dbo.both_t;
REVERT

    ╔═════════╗
║ algum ║
╠═════════╣
║ db_a ║
║ db_b ║
╚═════════╝

    Se removermos o encadeamento de propriedade entre bancos de dados, veremos que isso falha:

    ALTER DATABASE db_a SET DB_CHAINING OFF;
ALTER DATABASE db_b SET DB_CHAINING OFF;

EXECUTE AS LOGIN = 'db_a_login';
SELECT *
FROM dbo.both_t;
REVERT

    Msg 229, Level 14, State 5, Line 50
    A permissão SELECT foi negada no objeto 't', banco de dados 'db_b', esquema 'dbo'.

    Use isso para limpar depois:

    USE master;
IF EXISTS (SELECT 1 FROM sys.databases d WHERE d.name = 'db_a') 
DROP DATABASE db_a;
IF EXISTS (SELECT 1 FROM sys.databases d WHERE d.name = 'db_b') 
DROP DATABASE db_b;
IF EXISTS (SELECT 1 FROM sys.server_principals sp WHERE sp.name = 'db_a_login') 
DROP LOGIN db_a_login;
GO
    • 4

  2. Se, em vez de uma exibição, seu usuário bobpuder selecionar uma função com valor de tabela (TVF) de várias instruções ou executar um procedimento armazenado, isso poderá ser feito com mais segurança (ou seja, sem habilitar o encadeamento de propriedade entre bancos de dados em qualquer banco de dados, e sem criar um usuário para bobem dbRestricted).

    O principal problema com o Cross-DB Ownership Chaining é que você só pode restringi-lo não criando um usuário equivalente dbRestricted(ou seja, emulando a situação que o levou a postar esta pergunta). Mas qualquer usuário em ambos os bancos de dados agora poderá ter objetos neste banco de dados de acesso a objetos em dbRestricted. Assumindo que a maioria (se não todos) os objetos estão no dboSchema, ou um Schema de propriedade de dbo, então isso é praticamente tudo. E, mesmo que essa View seja o único objeto a ser acessado dbRestrictedhoje, você não pode impedir que outras pessoas adicionem objetos a esse banco de dados no futuro que acessem objetos em dbRestricted.

    Em vez de criar duas possíveis falhas de segurança em seu sistema, você pode usar a assinatura de módulo para atingir esse objetivo com a maior segurança possível. Eu tenho um código de exemplo mostrando como na resposta a seguir, também aqui no DBA.SE:

    Acessar a exibição com base na tabela em outro banco de dados sem conta nesse outro banco de dados

    • 2

relate perguntas