Então, acabei de começar a fazer coisas parecidas com o trabalho de DBA Oracle completo recentemente, então ainda estou aprendendo muito do básico da parte administrativa do meu trabalho. Recebi a tarefa de trazer vários bancos de dados de aplicativos para atender a um determinado conjunto de padrões profissionais (estou sendo intencionalmente vago). Um desses padrões é que os proprietários de objetos que suportam o aplicativo em geral também não devem utilizá-los regularmente. A principal exceção é o DBA, mas apenas para certas classes de objetos que manteríamos regularmente, como índices. A não ser quando estiverem realizando tarefas de instalação e manutenção, os proprietários do objeto de aplicativo devem ser desabilitados.
Isso finalmente me leva à minha pergunta: quem deve ser o proprietário desses objetos de aplicativo. Devemos ter apenas um usuário que cria os objetos e, em seguida, é amplamente desabilitado pelo resto de sua vida e os privilégios de uso necessários devem ser concedidos a esta ou aquela função? Tudo bem para o DBA possuir todos os objetos do aplicativo, ou eles devem possuir apenas os objetos que estão sendo mantidos diariamente/semanal? Obviamente, a resposta exata dependerá das necessidades da organização e do que especificamente esse padrão está pedindo, mas qual é a melhor prática aqui para a propriedade do objeto do aplicativo?
Esta pergunta pode ser muito ampla, então me avise se eu precisar editá-la para torná-la mais específica. Eu realmente não sei por onde começar com isso ou mesmo quais são as perguntas certas a serem feitas. Obrigado por qualquer ajuda que você possa fornecer.
O Princípio do Mínimo Privilégio exige duas coisas: o usuário de tempo de execução (ou os logins de usuários humanos) não devem possuir os objetos, porque você não pode impedi-los de modificá-los ou eliminá-los (no Oracle).
O mesmo Princípio também sugere que você não precisa ter permissões extensas para o usuário que deseja atualizar os objetos do aplicativo.
Ambos combinados sugerem: ter um usuário do sistema possuindo os objetos do aplicativo e outro usuário do sistema com acesso a esses objetos para login em tempo de execução. Use o DBA apenas para configurar esses usuários.
É um pouco diferente no MSSQL, mas basicamente você deseja evitar ter um usuário de tempo de execução com a função dbo.
De um modo geral, é uma má ideia ter um objeto de banco de dados em uso geral que pertence a uma conta de usuário. Se a conta do usuário for desativada ou desaparecer, podem surgir problemas.
Eu sou um cara do SQL Server, então as coisas são um pouco diferentes, mas eu gosto de ter uma conta de serviço como proprietário do banco de dados, então sabemos que a conta não desaparecerá quando um funcionário sair.
No Oracle, é comum configurar um usuário Proprietário que possui as tabelas e o código armazenado (pacotes, funções, etc). Este é um usuário dedicado para esta finalidade.
Em bancos de dados maiores que suportam vários aplicativos, pode haver vários proprietários. Eles podem ter acesso a tabelas pertencentes a outros usuários, conforme necessário.
Aplicativos e usuários terão seus próprios IDs de usuário. Eles geralmente não têm a capacidade de criar objetos de banco de dados. Eles têm permissão para acessar o código de que precisam, bem como as tabelas necessárias para cumprir sua finalidade.
Como outros notaram, o princípio do privilégio mínimo deve ser aplicado. Os usuários podem ter apenas acesso de seleção (leitura) em alguma tabela. Em alguns casos, eles podem ter acesso a um subconjunto de colunas (por meio de uma visualização ou outros mecanismos).
É incomum criar rotineiramente objetos pertencentes a um ID de usuário DBA. Os usuários DBA devem ser usados para gerenciar o banco de dados. Eles podem criar objetos pertencentes a outros usuários. Isso é necessário se os IDs de usuário do proprietário não tiverem privilégios de login concedidos.