Início / dba / Perguntas / 110721
Accepted
AaronLS
Asked: 2015-08-12 11:58:42 +0800 CST

Permissões temporárias para DDL

  • 772

Eu esperava usar a representação do usuário para configurar um usuário que tivesse permissões para modificar o DDL e somente quando eu precisasse implantar as alterações do DDL eu representaria esse usuário. Dessa forma, posso usar minha conta integrada do Windows para consultar dados conforme necessário, mas não posso modificar o banco de dados, exceto quando eu represento explicitamente esse outro usuário.

De acordo com o artigo do MSDN sobre representação, você só pode executar a representação se for um administrador de sistema.

Portanto, o desafio é, se meu Login padrão, vamos chamá-lo de LoginAaron, é um administrador de sistema do banco de dados, como negar a mim mesmo as permissões de gravação DDL, para que eu não possa executar o DDL sem personificar explicitamente outro usuário com a função ddl_admin (vamos chamar o usuário UserDdlDeploy)?

Ou existe outra maneira elegante de fazer isso?

Este não é tanto um procedimento de segurança, mas sim um procedimento de segurança/precaução.

sql-server permissions

1 respostas

  1. Best Answer

    A sysadminnão pode se rebaixar temporariamente / na maioria das vezes / etc. O que você deseja fazer é criar um login de autenticação SQL que você usa na maioria das vezes e que tenha privilégios apenas para fazer as coisas limitadas que você deseja fazer. Então, quando você quiser executar operações DDL, faça login como seu login do Windows.

    Provavelmente existem maneiras de fazer isso se o seu login principal não for um sysadmin, mas acho que elas serão autodestrutivas. Você teria que fazer login como outra pessoa sempre que quisesse fazer qualquer coisa (incluindo coisas que deseja que seu login com privilégios mais baixos seja capaz de fazer, mas não previu quando configurou as permissões). Como um exemplo rápido, aqui estão dois principais de banco de dados, um dos quais pode representar o outro:

    CREATE USER blat WITHOUT LOGIN;
CREATE USER floob WITHOUT LOGIN;
GRANT IMPERSONATE ON USER::blat TO floob;

EXECUTE AS USER = 'floob';
GO
PRINT USER_NAME();
GO
EXECUTE AS USER = 'blat';
GO
PRINT USER_NAME();
GO
REVERT;
GO
PRINT USER_NAME();
GO
REVERT;

    Resultados:

    floob
blat
floob

    (Agora, a representação não é perfeita - há problemas em usar isso quando você precisa acessar recursos além dos limites do banco de dados, por exemplo.)

    Portanto, imaginando que esses são usuários reais conectados a logins reais, você pode adicionar apenas blatà ddl_adminfunção e fazer login na floobmaioria das vezes. Quando necessário, você pode simplesmente personificar blat, fazer suas coisas DDL e depois reverter. Minha sugestão é apenas ficar longe de tentar diminuir os privilégios de sua conta do Windows / sysadmin, e apenas se acostumar a fazer login de uma maneira diferente para que você possa ser um peão na maioria das vezes e só elevar quando precisar. Vou repetir, no entanto, que isso não eliminará os erros que você cometeria de qualquer maneira - apenas impedirá que você execute o DDL acidentalmente ou execute o DDL errado, o que pode acontecer quando você também personificou conscientemente.

    E, porque a ideia de elevar os próprios privilégios só quando precisa, para se proteger porque acha que só vai errar quando não estiver elevado, me parece estranha, e porque não consigo evitar (crédito xkcd , claro):

    insira a descrição da imagem aqui

    Aqui está um exemplo mais concreto, que usa um login de autenticação SQL real.

    CREATE LOGIN peon WITH PASSWORD = 'peon', CHECK_POLICY = OFF;
GO

CREATE DATABASE playground;
GO

USE playground;
GO

CREATE USER peon FROM LOGIN peon;
GO
ALTER ROLE db_datareader ADD MEMBER peon;
-- of course grant all the permissions you want here
GO

CREATE USER ddldude WITHOUT LOGIN;
GO
ALTER ROLE db_owner ADD MEMBER ddldude;
-- doesn't have to be db_owner, just a valid example
GO

GRANT IMPERSONATE ON USER::ddldude TO peon;
GO

    Agora, crie uma nova sessão, logando diretamente usando peon/ peon, e execute este código:

    USE playground;
GO
CREATE TABLE dbo.foo(id INT);
GO

    Pausas, certo? Sim claro:

    Msg 262, Nível 14, Estado 1
    Permissão CREATE TABLE negada no banco de dados 'playground'.

    Agora, você pode representar outro usuário, sem ser um sysadmin, então você deve registrar um bug contra qualquer documentação que diga isso:

    EXECUTE AS USER = N'ddldude';
GO
CREATE TABLE dbo.foo(id INT); -- works
GO
REVERT;

    Não se esqueça de limpar:

    USE master;
GO
ALTER DATABASE playground SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DROP DATABASE playground;
GO
DROP LOGIN peon;
GO
    • 4

relate perguntas