Esta questão começou porque tiramos cópias de backups de produção e as restauramos em ambientes inferiores (com dados embaralhados, é claro) para os desenvolvedores praticarem e/ou depurarem.
Temos IDs atribuídos DBADM, SECADM, DATAACCESSe ACCESSCTRL(principalmente o proprietário da instância). Quando restauramos para um ambiente inferior, acabamos precisando fazer logon como o proprietário da instância original e conceder as mesmas autoridades acima ( DBADM, SECADM, DATAACCESSe ACCESSCTRL) ao novo proprietário da instância de destino.
Achei que não era uma boa ideia deixar o ID original no banco de dados, então tentei revogar seus privilégios. Não muito tempo depois, minhas religações de pacotes começaram a falhar, pois aparentemente há pacotes vinculados a esse ID original. Sem saber o que eles continham e se eu poderia/deveria excluí-los ou não (mesmo pensando que eles são inofensivos para remover???) Acabei restaurando os privilégios para o proprietário da instância original e apenas deixando-o lá.
Isso sempre me incomodou. Um ID com os poderes de DBADM, SECADM, DATAACCESS, e ACCESSCTRLnão deveria estar apenas por aí. Para mim, isso é uma falha de segurança. Para mim, o ID deve ser revogado e qualquer outra limpeza que precise ser executada deve ser executada para manter o banco de dados seguro. O mesmo seria verdade se dissesse que eu deixaria a empresa ou meus colegas DBAs. Gostaríamos de revogar IDs e limpar e/ou transferir a propriedade de objetos para remover quaisquer brechas de segurança.
O problema é que não sei o que precisa ser limpo. Pesquisei um pouco na documentação do Google e da IBM e não encontrei nada que sugerisse as etapas que normalmente deveriam ser seguidas ao remover um usuário tão importante do sistema. Ou até mesmo um usuário com BINDADDautoridade?
O que todos vocês removem/revogam e em que ordem? Existe uma maneira de isso ser roteirizado/automatizado? Como você sabe quais pacotes você pode remover? Existem outras coisas que precisam ser movidas/transferidas?
Alguém mais encontra isso? Pensamentos? Experiências?
Existem vários aspectos que você pode querer considerar.
Em primeiro lugar, você pode atribuir autoridades apropriadas ao proprietário da instância de destino durante a restauração automaticamente usando a variável de registro DB2_RESTORE_GRANT_ADMIN_AUTHORITIES . Se for definido como ON antes da restauração, o usuário que estiver executando a restauração obterá essas autoridades.
Em segundo lugar, a maioria dos problemas de ligação/compilação vem do fato de que apenas o proprietário do objeto, ou seja, o ID de autorização que criou o objeto em primeiro lugar, recebe permissões para executar determinadas operações nele. Se você executar scripts DDL em produção como o proprietário da instância, esse será o ID do proprietário de todos os objetos após a restauração, independentemente da configuração DB2_RESTORE_GRANT_ADMIN_AUTHORITIES. Você poderia, é claro, usar a instrução TRANSFER OWNERSHIP para mudar isso, mas na vida real, com dezenas de milhares de objetos no banco de dados, isso pode não ser prático.
Para evitar a parte " em segundo lugar ", em muitas organizações, as pessoas usam um ID de autorização especial de "construtor", separado do proprietário da instância, para executar scripts DDL. Esse ID não receberá privilégios desnecessários, pode ser rigidamente controlado e, quando existente em todos os ambientes, deve ser capaz de executar todas as tarefas necessárias sem adicionar exposição à segurança.