* Não são todos que utilizam Oracle e não são todos que utilizam a versão enterprise do Oracle. Então não são todos que tem acesso ao FGA. O PostgreSQL tem o SE PostgreSQL que é uma alternativa bem interessante.
* Hoje acredito que cada método de autenticação tem a sua aplicação em um contexto diferente;

Tanto que este assunto me preocupou que eu mudei de idéia e fiz esta palestra: http://www.slideshare.net/telles/postgresql-o-elefante-encouraado-presentation

1. A opção de conceder privilégios através de roles, que podem ser ajustadas como default ou não, resolvem o primeiro item. Um role apenas para conexão e leitura (default, sem senha) permite o usuário se conectar, fazer SELECTs e mais nada. Uma segunda role (não default, com senha desconhecida pelo usuário) permite update, insert e delete apenas através dos aplicativos.

2 e 3. Um usuário com privilégios para criar, bloquer e eliminar usuários (e não “concedendo superpoderes”) resolve os itens 2 e 3. Uma tela simples no aplicativo auxiliar esse gestor de usuários (que não irá dar comando como CRETE USER direto no banco).

4. Ninguém migra banco executando comandos “um a um”. Fazemos um script que lê o banco “origem”, gerando os comandos que serão executados no banco “destino”. Por exemplo (simplificadíssimo):

SELECT ‘ CREATE USER ‘ || USERNAME || ‘ IDENTIFIED BY VALUES ”’ || PASSWORD || ”’;’
FROM DBA_USERS;

Se existem 10 ou 10.000 usuários, o trabalho de elaborar o script é mesmo. A margem de erro também.
O mesmo se dá para privilégios, roles, etc.

5. Através do banco não controlarei acessos a telas, mas acessos a atividades. Se bloquear um DELETE em uma tabela, por exemplo, ele pode acessar a vontade a tela que permite excluir dados de tal tabela. Mas excluir mesmo, ele não vai. Quanto ao limite por faixas de valores, realmente o Oracle não permite essa funcionalidade. Mas diversos experts em AD me disserem que ele também não permite. Associar um usuário a um grupo e verificar, no aplicativo, se o mesmo pertence a este grupo (e assim limitar por faixas) não seria uma funcionalidade do AD, mas do aplicativo. Posso fazer o mesmo com o Oracle, associando o usuário a roles e testando no aplicativo.

O que mais encontro é desconhecimento das possibilidades do banco Oracle. Como segurança é cada vez mais um requisito das empresas, fico a vontade com tais capacidade do banco. Com FGA posso auditar com tranquilidade tudo o que me interessa e indicar os possíveis “culpados”.

Alguma dicas:

a) Criar usuários distintos para atuar como “dono” dos objetos de cada sistema. Esses usuários serão raramente utilizados para conexão com o banco.
b) Criar usuários para acesso de trabalho no banco. Prefiro 1×1 (um usuário no banco para cada “pessoa física”).
c) Não crie sinônimos públicos para que os usuários do item “b” acessem os dados dos usuários do item “a”. Utilize a sintaxe dono.tabela (ou como aparece nos manuais da Oracle, schema.table). Ou estude o comando ALTER SESSION SET CURRENT_SCHEMA.

Para terminar: essa é apenas minha opinião. Em vários anos atuando como DBA, não vi ainda solução melhor. Quando encontrar, adotarei de bom grado.

Sds.

Gilberto

E acho que é a melhor pois com os recursos adicionais que os SGBDs trazem, em especial o Oracle, facilita bastante.
Gilberto

Jogue a tarefa de cuidar dos usuários para o SysAdmin. Ou seja, todos os meus exércitos no Serviço de Diretórios.