No Db2 v11.5 no Linux, tenho vários bancos de dados com centenas de tabelas no esquema MYSCHEMA.
EXIGÊNCIA
a) Preciso atribuir permissão SELECT a todas as tabelas no esquema MYSCHEMA, exceto para uma tabela específica MYSCHEMA.NO_ACCESS à qual os usuários não devem ter acesso.
b) Se uma nova tabela for criada no esquema MYSCHEMA, preciso adicionar manualmente GRANT SELECT na nova tabela. Gostaria de evitar qualquer tipo de administração de segurança quando uma nova tabela for criada.
c) Quando temos auditoria de uma empresa de auditoria, precisa ser simples fornecer informações sobre qual acesso algum usuário tem e qual não tem. Ter centenas de concessões é difícil de mostrar que os usuários realmente têm apenas o acesso de que precisam.
SOLUÇÃO ATUAL
Atualmente, concedemos seleção em todas as tabelas, exceto na tabela MYCHEMA.NO_ACCESS, assim:
GRANT SELECT ON TABLE MYSCHEMA.TAB1 TO GROUP GROUP1
GRANT SELECT ON TABLE MYSCHEMA.TAB2 TO GROUP GROUP1
...
GRANT SELECT ON TABLE MYSCHEMA.TAB5000 TO GROUP GROUP1
(make sure there is no MYSCHEMA.NO_ACCESS on grant list)
A abordagem acima tem limitações: sempre que uma nova tabela é criada no esquema MYSCHEMA, preciso definir GRANT SELECT na nova tabela.
Além disso, na auditoria, devido às inúmeras permissões, é difícil provar que os usuários realmente têm apenas as permissões que deveriam ter.
NOVA ABORDAGEM, SE POSSÍVEL
O Db2 v11.5 tem o privilégio GRANT SELECTIN no esquema.
Existe algo parecido como:
GRANT SELECTIN ON SCHEMA MYSCHEMA TO GROUP GRUP1
DENY SELECT ON TABLE MYSCHEMA.NO_ACCESS TO GROUP GROUP1
Onde negar tem maior importância que conceder.
Ou existe alguma outra abordagem?
Você pode criar uma Permissão de Linha nesta tabela.
Você deve criar uma função segura com base na função padrão que gera uma exceção:
Usando esta função:
Se o usuário atual for um membro de
GROUP1
, então o DB2 gera uma exceção com SQLCODE = -438 e SQLSTATE = '75000' em qualquer tentativa de acessar esta tabela. A expressão é avaliada como TRUE, permitindo o acesso à tabela correspondente para não um membro deGROUP1
.Você não obtém o SQLCODE padrão = -551 em uma tentativa de acesso "errônea", mas não deve ser importante, eu acredito...
Atualização
Além disso, você pode até fazer o DB2 levantar uma exceção com SQLCODE = -551 em tal acesso.
Você precisa usar uma rotina não documentada
SYSIBMINTERNAL.SQLEML_RAISE_ERROR
para isso.Envolva-a em uma função escalar:
e use-o em uma expressão de permissão de linha como abaixo:
Você obtém uma exceção com o SQLCODE/SQLSTATE padrão então.
Note que você deve usar a função compilada
RAISE_ERROR_MY
(sem a cláusula ATOMIC). Ela é chamada internamente de qualquer formaCASE
na expressão de permissão de linha, lançando uma exceção inesperada caso contrário.Você está certo, é claro, só é possível revogar privs que são concedidos. Embora não seja uma resposta exata para sua pergunta, você pode usar uma solução alternativa como (adicionei revoke e um manipulador para quando o usuário não tem select auth):
Como db2fenc1:
Agora vejo que era um grupo, não um usuário, mas fica como exercício para o leitor;-)
Se isso não for o caso, você pode dar uma olhada no controle de acesso de linha, o usuário (no meu caso db2fenc1), pode selecionar da tabela, mas não pode ver nenhuma linha. Você pode encontrar mais informações em Visão geral do controle de acesso de linha e coluna (RCAC)
Este é apenas um exemplo bobo:
O que db2fenc1 vê