Início / dba / Perguntas / 305
Accepted
Leigh Riffel
Asked: 2011-01-06 10:59:46 +0800 CST

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

  • 772

Como você lida com a falta de privilégios de nível de esquema no Oracle? A arquitetura de segurança da Oracle funciona bem para aplicativos que precisam apenas de privilégios de nível de objeto e funciona bem para DBAs que precisam de poucas restrições. No entanto, parece haver um grande buraco na arquitetura para programadores que fazem desenvolvimento com 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 faça o desenvolvimento em seu próprio esquema. O DBA concederá privilégios de nível de 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 balde de bits em detrimento do desempenho do banco de dados. Eu quero que os programadores desenvolvam no banco de dados, mas esse método desencorajaria muito isso.

  2. Dê a cada programador o nome de usuário/senha para a dúzia de esquemas que eles precisam para desenvolver. Conceda a esses esquemas de aplicativos permissão para criar procedimentos, tabelas etc. raramente logados como eles mesmos. O desenvolvimento de esquema cruzado 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 privilégios além do privilégio de proxy. As desvantagens incluem que os programadores precisam manter conexões separadas para cada esquema para o qual fazem proxy, o desenvolvimento de esquema cruzado é mais complicado, pois as conexões precisam ser constantemente alteradas e os pacotes que usam links de banco de dados públicos com autenticação aprovada não serão compilados dentro das conexões de proxy.

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

Parece estar faltando uma opção para conceder a cada programador SELECT/INSERT/CREATE/etc. privilégios no esquema em que precisam fazer o desenvolvimento. Eles fazem login como eles mesmos para fazer seu trabalho usando uma conexão. Novos objetos no esquema aos quais eles têm acesso ficam imediatamente disponíveis.

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

oracle security

2 respostas

  1. Best Answer

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

    No caso de nossos sistemas críticos (SCT Banner, para acompanhamento de aulas e alunos, e Oracle Financials), havia também servidores 'test' e 'seed'. O teste era para teste de aceitação do usuário antes que as coisas fossem migradas de dev para prod; 'seed' era a instalação de estoque do software, portanto, se encontrássemos um bug, poderíamos verificar se era algo que introduzimos ou veio da SCT ou do software da Oracle.

    • 11

  2. Use funções para associar coleções de objetos e, em seguida, conceda acesso às funções

    A instrução GRANT permite ao 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 de objeto e as operações que eles autorizam.

    Como os 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>select 'conceder seleção em scott.'||table_name||' para role_select;' de dba_tables onde owner='SCOTT';
sql>@privs.sql
sql> conceder role_select para john,sam,peter;

    Isso, combinado com a GRANT CREATE TABLEemissão do 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 de nível DDL que podem executar o processo de concessão apropriado, embora uma quantidade significativa de testes obviamente seja necessária, deve ser possível fazer com que a instrução create table conceda automaticamente as permissões apropriadas para as funções apropriadas.

    Editar --

    De acordo com GRANT , o CREATE TABLEprivilégio:

    Crie uma tabela no esquema do beneficiário.

    Assim, dando a eles criar tabela, alterar tabela, etc. do usuário correto, eles devem ser capazes de acessar o esquema desse usuário como se fossem o usuário apropriado.

    • 3

relate perguntas