Segurança para desenvolvedores de aplicativos que trabalham com PL / SQL no Oracle

Como você lida com a falta de privilégios no nível do esquema no Oracle? A arquitetura de segurança da Oracle funciona bem para aplicativos que precisam apenas de privilégios no nível de objeto e para DBAs que precisam de poucas restrições. No entanto, parece haver um grande buraco na arquitetura para programadores que desenvolvem um aplicativo front-end e PL / SQL em vários esquemas. Aqui estão algumas das minhas opções com suas desvantagens:

1. Faça com que cada programador desenvolva seu próprio esquema. O DBA concederá privilégios no nível do objeto aos programadores que precisam deles. Qualquer desenvolvimento de pacote deve ser feito por um DBA. A principal desvantagem é que os programadores usarão o banco de dados como um bit bucket em detrimento do desempenho do banco de dados. Quero que os programadores desenvolvam no banco de dados, mas esse método desencorajaria bastante.

2. Dê a cada programador o nome de usuário / senha para a dúzia de esquemas em que eles precisam desenvolver. Conceda a esses esquemas de aplicativos permissão para criar procedimentos, tabelas etc. Algumas das desvantagens dessa abordagem são que os programadores precisam manter vários logins e são raramente logam como eles mesmos. O desenvolvimento de esquemas cruzados também é difícil.

3. Conceda aos programadores privilégios de autenticação de proxy em cada esquema para o qual eles precisam desenvolver. Isso os mantém conectados como eles mesmos, sem ter que conceder a eles outros privilégios além do proxy. As desvantagens incluem os programadores que precisam manter conexões separadas para cada esquema para o qual solicitam proxy, o desenvolvimento entre esquemas é mais complicado, pois as conexões precisam ser constantemente alteradas e os pacotes que usam links de bancos de dados públicos com autenticação passada não serão compilados dentro das conexões de proxy.

4. Dê a cada programador privilégios de DBA. - A desvantagem aqui é segurança. Nenhum programador de esquema pode ser mantido fora de qualquer esquema e qualquer programador pode representar qualquer outro programador (DBA).

Parece haver uma opção ausente para conceder a cada programador SELECT / INSERT / CREATE / etc. privilégios no esquema no qual eles precisam desenvolver. Eles se conectam como eles mesmos para fazer seu trabalho usando uma conexão. Novos objetos no esquema aos quais eles têm acesso estão imediatamente disponíveis.

Estou esquecendo de algo? Como você lida com programadores de aplicativos que desenvolvem PL / SQL?

Na época em que eu trabalhava em uma loja da Oracle, tínhamos um servidor 'dev' (desenvolvimento) específico, com restrições de segurança diferentes das do servidor 'prod' (produção). Os desenvolvedores poderiam fazer o que precisassem, e então entregaríamos os scripts necessários ao DBA para aplicar ao servidor de produção.

No caso de nossos sistemas críticos (SCT Banner, para rastreamento de turmas e alunos e Oracle Financials), também havia servidores 'test' e 'seed'. O teste foi para testes de aceitação do usuário antes que as coisas migrassem de dev para prod; 'seed' foi a instalação padrão do software; portanto, se encontrarmos um erro, poderemos verificar se foi algo que introduzimos ou viemos do SCT ou do software da Oracle.

Use funções para associar coleções de objetos e conceda acesso às funções

A instrução GRANT permite que o DBA:

Privilégios de objeto para um objeto específico para usuários, funções e PUBLIC. A Tabela 18-2 lista os privilégios do objeto e as operações que eles autorizam.

Como privilégios de objeto podem ser concedidos a uma função, é relativamente fácil conceder a uma função acesso a todas as tabelas em um esquema:

sql> spool privs.sql
sql> selecione 'conceder seleção em scott.' || nome_tabela || ' para role_select; ' de dba_tables em que owner = 'SCOTT';
sql> @ privs.sql
sql> conceda role_select a john, sam, peter;

Isso, combinado com o GRANT CREATE TABLEemitido pelo usuário do esquema apropriado para a função, significa que os desenvolvedores podem selecionar e criar tabelas. Não é perfeito, pois uma tabela criada exige que o script seja executado novamente, mas WITH GRANT OPTIONsugere que cada desenvolvedor possa conceder acesso à tabela que criou para a função apropriada.

Isso sugere que você pode criar gatilhos no nível DDL que possam executar o processo de concessão apropriado, embora, obviamente, sejam necessárias quantidades significativas de teste; deve ser possível fazer com que a instrução create table conceda automaticamente permissões apropriadas às funções apropriadas.

Editar -

Segundo GRANT , o CREATE TABLEprivilégio:

Crie uma tabela no esquema do donatário.

Assim, dando a eles a criação de tabela, alteração de tabela etc. do usuário correto, eles devem poder acessar o esquema desse usuário como se fossem o usuário apropriado.