Re: [oracle_br] Re: Segurança no BD
Obrigado pelo retorno Chiappa. Realmente não informei a versão do BD pq
queria iniciar um debate sobre práticas de segurança de BD independente da
versão.
Suas dicas e do Marcus foram muito boas.
Tb criei a minha versão da connect e resource, acho isso importante.
Acho esse debate interessante, pois nunca sabemos tudo e é sempre bom ouvir
opiniões de outros profissionais.
A auditoria Tb vai acontecer inclusive auditando o dba que muita gente
esquece.
Me assusta a forma como as bases era administradas aqui, de qualquer forma
to acertando e ainda tem muito trabalho pela frente.
Só acho que pouca gente entrou na conversa, quem tiver mais idéias
compartilhem por favor.
Em 09/08/2012 14:05, J. Laurindo Chiappa jlchia...@yahoo.com.br
escreveu:
**
Bem, vc não cita a Versão do banco(isso é sempre ultra-importante), mas de
modo geral os seus movimentos iniciais foram bons, sim : remover privs ANY
e de Administração, bem como os privilégios inerentemente altos (como
UNLIMITED TABLESPACE) que algumas versões da CONNECT e da RESOURCE davam é
uma excelente idéia Eu sempre prefiro criar a minha versão da role
CONNECT e da RESOURCE , customizada, aonde de acordo com a necessidade eu
tiro ou adiciono grants
imho a continuação seria algo do gênero :
a) eliminar as ações ilimitadas - ie, remover coisas do tipo
UTL_FILE_DIR=* (que permite ler/gravar qquer arquivo, INCLUSIVE os do
sistema)
b) rever privilégios de I/O programados (exemplo, DIRECTORIES criados por
qquer um e que qquer um tem r+w)
c) rever os privilégios de acesso à dados em produção (principalmente
usuários que tem leitura de qquer objeto do dicionário de dados - isto nem
por Segurança (embora Haja SIM questões de segurança, como acessar SQLs
administrativos no cache que contenham passwords, que recuperem dados
sigilosos em prod ou coisas do tipo), mas pra evitar que neguinho solte uma
query pesquisando JOINs de tabelas do dicionários sem chave, e coisas
assim) Certamente isso vai acabar levando à implementação de algum
mecanismo de elevamento de programas, ie : ao invés de testar desenvolver
direto na produção, e sair enfiando as novas versões sem sequer envolver o
DBA, vc vai ter um ambiente Desenv, um ambiente HOMO e só depois das novas
versões totalmente testadas é que o DBA é acionado para elevar o código à
categoria de Produção, e o Implementar
d) Auditoria : é vital que não só esteja implementada a política de lesser
privileges (que vc está tentando implementar acima, okdoc) MAS que também
as pessoas vejam que as tentativas de violação Vão Ser descobertas e
preseguidas, aí é que entra a Auditoria...
e) política de senhas : isso é a Espinha Dorsal de uma política de
segurança, é Crucial que TODAS as senhas (inclusive as suas de DBA!!!)
sigam políticas de força de senha rígidas E QUE expirem em intervalos
curtos E QUE não possam ser reaproveitadas E QUE não estejam armazenadas em
lugar algum - sim, aquela agenda de papel aonde vc guarda a sua senha de
SYSDBA não é aceitável Idem para aqueles scripts em crontab que
conectam com usuário/senha Idem idem (com mais força ainda) para
aquelas rotinas automatizadas da Aplicação que rodam conectando com um
usuário e senha específicos...
f) e finalmente o mais importante porém o mais difícil de implementar : os
patches que a Oracle disponibiliza (normalmente Quadrimestralmente)
necessariamente TEM QUE SER aplicados o mais rápido possível - Abundam
exemplos de correções de bugs de segurança importantes, que deixam um
usuário em determinadas situações elevar seu próprio privilégio, e/ou
executar / acessar itens que não lhe pertencem
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga hevandro83@...
escreveu
Felizes são aqueles que participam do projeto do bd desde o início. Nesse
caso não. To a pouco tempo e herdei de outra administração. Triggers eu
to
fugindo. O cenário atual tá péssimo , já comecei os trabalhos em
homologação p depois partir p produção.
Em 08/08/2012 21:30, Marcus Pavan marcus_apf@... escreveu:
**
Hevandro, boa noite.
Sobre segurança, sua atividade inicial está correta.
O primeiro passo é o mapeamento geral dos usuários e seus acessos.
Estes
por sua vez agrupados em ROLES.
Outro detalhe importante, esquecido por muitos, é no momento da
criação do
banco de dados. Se você for usar SPATIAL instale os pacotes caso
contrário
não instale (isto vale para todos - XMLDB, JAVA, INTERMEDIA, etc.).
Evitando a famosa instalação WINDOWS MODE (NEXTNEXTFINISH).
Algumas vezes implemento TRIGGERS para um FIREWALL (muito cuidado com
isto, deixe o usuário SYS, SYSMAN, SYSTEM e DBSNMP passarem batitos),
pois
tenho ninjas na empresa que descobrem senha do SCHEMA e manda o
excel
torar em tabela dinâmica. Então... IF (v_usuario = 'X' AND v_sistema
NOT IN
('..',)) THEN RAISE_... :)
Atenciosamente,
Marcus Pavan.
Re: [oracle_br] Re: Segurança no BD
Um ponto interessante que vc citou é a senha anotada em papel. Isso leva a outra questão: onde guardar as senhas?. Só de cabeça é inviável. Hj temos uma planilha Excel protegida por 2 senhas, uma ro e outra rw. Aí entra outro problema, e a segurança do Excel, será que é boa? Dá p confiar? Já trabalhei Tb c um aplicativo password safe e achei bem interessante. Em 09/08/2012 17:12, J. Laurindo Chiappa jlchia...@yahoo.com.br escreveu: ** Okdoc, Hevandro : quando citei a versão, era para tentar ajustar mais as respostas à sua condição particular, mas sendo uma discussão geral, aí realmente os procedimentos gerais citados são suficientes - a implementação é que Vai mudar em cada versão, mas como planejamento geral tá bala Conforme mais pessoas forem respondendo , mais pontos serão levantados, imagino... De minha parte, um ponto que quero adicionar é a Segurança no servidor : não só a segurança lógica - tal como proteção ao account administrador local (se qquer um conseguir acesso á um user membro do grupo Admin local, ele se dá inclusão no grupo DBA e aí é game over, a pessoa conecta como SYSDBA localmente) e proteção aos arquivos do Oracle (por exemplo, se alguém roubar um backup full não-encriptado , ou se alguém conseguir o arquivo de password com coisa de uma ou duas horas de esforço se consegue ou acessar os dados ou obter a senha do SYSDBA, aí é game over#2) , MAS também a segurança física até o servidor, ie, como Dificultar que alguém tenha acesso diretamente ao servidor : basta um Live CD e é game over... Há pouco tempo eu precisei acessar um servidor (Windows 7 no caso) em que ninguém tinha nenhuma senha, aí usei aquele trucão básico de boot com LiveCD e alterar um dos executáveis chamados na hora da tela de logon pelo executável de troca de senhas e kaput, funfou na hora Então a idéia aqui é não esquecer das barreiras no caminho até o servidor, sejam lógicas de último caso(por exemplo, uma password para acessar a BIOS, desabilitar o boot de CD, etc), sejam lógicas tentando restringir/prevenir acesso remoto, sejam mesmo físicas (ie, uma tranca na porta da sala dos servidores), tipo isso... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga hevandro83@... escreveu Obrigado pelo retorno Chiappa. Realmente não informei a versão do BD pq queria iniciar um debate sobre práticas de segurança de BD independente da versão. Suas dicas e do Marcus foram muito boas. Tb criei a minha versão da connect e resource, acho isso importante. Acho esse debate interessante, pois nunca sabemos tudo e é sempre bom ouvir opiniões de outros profissionais. A auditoria Tb vai acontecer inclusive auditando o dba que muita gente esquece. Me assusta a forma como as bases era administradas aqui, de qualquer forma to acertando e ainda tem muito trabalho pela frente. Só acho que pouca gente entrou na conversa, quem tiver mais idéias compartilhem por favor. Em 09/08/2012 14:05, J. Laurindo Chiappa jlchiappa@... escreveu: ** Bem, vc não cita a Versão do banco(isso é sempre ultra-importante), mas de modo geral os seus movimentos iniciais foram bons, sim : remover privs ANY e de Administração, bem como os privilégios inerentemente altos (como UNLIMITED TABLESPACE) que algumas versões da CONNECT e da RESOURCE davam é uma excelente idéia Eu sempre prefiro criar a minha versão da role CONNECT e da RESOURCE , customizada, aonde de acordo com a necessidade eu tiro ou adiciono grants imho a continuação seria algo do gênero : a) eliminar as ações ilimitadas - ie, remover coisas do tipo UTL_FILE_DIR=* (que permite ler/gravar qquer arquivo, INCLUSIVE os do sistema) b) rever privilégios de I/O programados (exemplo, DIRECTORIES criados por qquer um e que qquer um tem r+w) c) rever os privilégios de acesso à dados em produção (principalmente usuários que tem leitura de qquer objeto do dicionário de dados - isto nem por Segurança (embora Haja SIM questões de segurança, como acessar SQLs administrativos no cache que contenham passwords, que recuperem dados sigilosos em prod ou coisas do tipo), mas pra evitar que neguinho solte uma query pesquisando JOINs de tabelas do dicionários sem chave, e coisas assim) Certamente isso vai acabar levando à implementação de algum mecanismo de elevamento de programas, ie : ao invés de testar desenvolver direto na produção, e sair enfiando as novas versões sem sequer envolver o DBA, vc vai ter um ambiente Desenv, um ambiente HOMO e só depois das novas versões totalmente testadas é que o DBA é acionado para elevar o código à categoria de Produção, e o Implementar d) Auditoria : é vital que não só esteja implementada a política de lesser privileges (que vc está tentando implementar acima, okdoc) MAS que também as pessoas vejam que as tentativas de violação Vão Ser descobertas e preseguidas,
Re: [oracle_br] Re: Segurança
obrigada colega.
Sou DA, mas faço tudo de DBA, aqui não temos DBA lógico, isso é pra pagar
menos...
abraços
Cris
- Original Message -
From: jlchiappa
To: oracle_br@yahoogrupos.com.br
Sent: Monday, June 04, 2007 2:12 PM
Subject: [oracle_br] Re: Segurança
OK, isso não estava claro na sua msg original. De qquer forma colega,
ainda no espírito de comentar em geral a sua política de segurança
antes de responder, eu OBSERVARIA que um DA (data Administrador) por
definição NÂO FAZ trabalho de DBA, que é quem mexe dentro do banco,
faz upgrades, alterações estruturais de banco... Um DA
cria/altera/remove ESTUTURAS DE DADOS e as testa, então imho um
usuário que tenha recebido SELECT ANY TABLE, e via procedure (para
bloquear acesso ao schema SYS) possa exercer privs de CREATE ANY,
ALTER ANY TABLE, ANALYZE ANY, DROP ANY TABLE e similares faria 99.99%
do trabalho de um DA, não vejo O MENOR SENTIDO em um usuário desses
ter priv de DBA
Mas comentando a resposta da pergunta que vc fez, o fato é mesmo o
que eu disse : SE vc não executar o plus digitando sqlplus
usuario/[EMAIL PROTECTED], e nem ter a senha dentro de scripts e quetais (e
sim SEMPRE fazendo sqlplus [EMAIL PROTECTED]), screen readers e colegas
pescoçudos não interfeririam, E como disse a senha em si sempre
trafega criptografada (se vc seguir o recomendado e a trocar
frequentemente ainda que seja capturado o pacote de rede ele estrá
criptografado, até poder ser revertido a senha já mudou em tese),
então o sqlplus é seguro, sim, a única brecha para segurança (não
só de sqlplus, mas da maioria dos programas) seria mesmo keyloggers,
que capturem a digitação do seu teclado, pra evitar isso como eu
disse só mesmo com anti-spywares, anti-rootkits e verificação de
segurança FREQUENTE na sua máquina cliente.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, ESTUDO [EMAIL PROTECTED]
escreveu
Oi amigo. Somente um usuário tem role de DBA, é é o que eu eu (DA)
uso. Só eu tenho a senha.
Obrigada
Cris
- Original Message -
From: jlchiappa
To: oracle_br@yahoogrupos.com.br
Sent: Saturday, June 02, 2007 8:35 PM
Subject: [oracle_br] Re: Segurança
Bom, primeiro usuário com role de dba , isso ABSOLUTAMENTE,
TOTALMENTE, não faz sentido ALGUM, isso é um rombo total de
segurança,
se preocupar com captura de senha quando vc tem usuário
super-privilegiado é algo semelhante a se preocupar com fechadura
na
janela quando a porta da frente tá aberta e escancarada O
ponto
BÁSICO de segurança é que um usuário só vai ter os privilégios **
mínimos ** que necessita, nunca dar DBA pra ninguém que não seja
DBA!!! Tem muito desenvolvedor/analista preguiçoso que não quer
se
preocupar em levantar quaise sejam os privs necessários e pede
grant
de DBA, mas pergunta pra mim se no meu banco eles recebem isso :)
Quanto à senha, sim : sqlplus é uma ferramenta em modo texto,
portanto TODA e QUALQUER entrada de dados é feita em modo-texto,
um
keylogger as capturaria, sim... Um netlogger não as capturaria em
plain-text, já que desde a v7 as SENHAS TODAS sempre circulam pela
rede (entre o cliente e o banco) criptografadas, mas um keylogger
sim... Mas isso faz parte do procedimento de segurança mais
genérico,
de se ter antispyware e antivírus sempre atualizados na máquina,
de
HAVER um departamento na Empresa preocupado com isso, que
rotineiramente esteja sempre re-aplicando e revendo políticas de
segurança... É por aí.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, ESTUDO estudo2003@
escreveu
então pessoal, pegando esse gatilho.. estive pensando aqui..
Temos um usuário que é o owner, e esse usuário tem a role de
dba, é
com ele que logo no plus pra poder fazer alterações e tudo mais.
Me digam, é seguro logar no plus? Pois a minha senha é
alfanumerica
de 6 caracteres. Algum progama consegue capturar essa senha?
Obrigada
Cris
- Original Message -
From: Bia Fitzgerald
To: oracle_br@yahoogrupos.com.br
Sent: Thursday, May 24, 2007 9:57 AM
Subject: Res: [oracle_br] Segurança
ahhh, sim.. Muito obrigada.
:)
- Mensagem original
De: Gustavo Venturini de Lima gventurini@
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
Assunto: Re: [oracle_br] Segurança
Na verdade a trigger não fica ligada a ninguém... Ela fica
escutando o
banco todo no geral...
Se algo satisfazer a condição da trigger, ela será ativada...
No caso, utilize uma AFTER LOGON ON DATABASE
Parecido com isso:
CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
BEGIN
.
{suas condições e ações}
.
END;
Em 23/05/07, Bia Fitzgerald dbaemapuros@ yahoo.com. br
Re: [oracle_br] Re: Segurança
Oi amigo. Somente um usuário tem role de DBA, é é o que eu eu (DA) uso. Só eu
tenho a senha.
Obrigada
Cris
- Original Message -
From: jlchiappa
To: oracle_br@yahoogrupos.com.br
Sent: Saturday, June 02, 2007 8:35 PM
Subject: [oracle_br] Re: Segurança
Bom, primeiro usuário com role de dba , isso ABSOLUTAMENTE,
TOTALMENTE, não faz sentido ALGUM, isso é um rombo total de segurança,
se preocupar com captura de senha quando vc tem usuário
super-privilegiado é algo semelhante a se preocupar com fechadura na
janela quando a porta da frente tá aberta e escancarada O ponto
BÁSICO de segurança é que um usuário só vai ter os privilégios **
mínimos ** que necessita, nunca dar DBA pra ninguém que não seja
DBA!!! Tem muito desenvolvedor/analista preguiçoso que não quer se
preocupar em levantar quaise sejam os privs necessários e pede grant
de DBA, mas pergunta pra mim se no meu banco eles recebem isso :)
Quanto à senha, sim : sqlplus é uma ferramenta em modo texto,
portanto TODA e QUALQUER entrada de dados é feita em modo-texto, um
keylogger as capturaria, sim... Um netlogger não as capturaria em
plain-text, já que desde a v7 as SENHAS TODAS sempre circulam pela
rede (entre o cliente e o banco) criptografadas, mas um keylogger
sim... Mas isso faz parte do procedimento de segurança mais genérico,
de se ter antispyware e antivírus sempre atualizados na máquina, de
HAVER um departamento na Empresa preocupado com isso, que
rotineiramente esteja sempre re-aplicando e revendo políticas de
segurança... É por aí.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, ESTUDO [EMAIL PROTECTED] escreveu
então pessoal, pegando esse gatilho.. estive pensando aqui..
Temos um usuário que é o owner, e esse usuário tem a role de dba, é
com ele que logo no plus pra poder fazer alterações e tudo mais.
Me digam, é seguro logar no plus? Pois a minha senha é alfanumerica
de 6 caracteres. Algum progama consegue capturar essa senha?
Obrigada
Cris
- Original Message -
From: Bia Fitzgerald
To: oracle_br@yahoogrupos.com.br
Sent: Thursday, May 24, 2007 9:57 AM
Subject: Res: [oracle_br] Segurança
ahhh, sim.. Muito obrigada.
:)
- Mensagem original
De: Gustavo Venturini de Lima [EMAIL PROTECTED]
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
Assunto: Re: [oracle_br] Segurança
Na verdade a trigger não fica ligada a ninguém... Ela fica escutando o
banco todo no geral...
Se algo satisfazer a condição da trigger, ela será ativada...
No caso, utilize uma AFTER LOGON ON DATABASE
Parecido com isso:
CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
BEGIN
.
{suas condições e ações}
.
END;
Em 23/05/07, Bia Fitzgerald dbaemapuros@ yahoo.com. br escreveu:
Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o tempo
inteiro.
Mas uma Trigger ficaria ligada a quem??
Obrigada.
- Mensagem original
De: Gustavo Venturini de Lima [EMAIL PROTECTED] comgventurini%
40gmail.com
Para: [EMAIL PROTECTED] os.com.br oracle_br%40yahoog
rupos.com. br
Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
Assunto: Re: [oracle_br] Segurança
Bia, para o Oracle a conexão será a mesma (independente do método
utilizado).
Porém, podes fazer uma trigger que consulte o campo program da
v$session..
Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para
desconectar
o
usuário...
Ou então colocar que se for de NOME_DA_SUA_ APP ele desconecta o
cara...
Em 23/05/07, Bia Fitzgerald dbaemapuros@ yahoo.com. br escreveu:
Olá pessoal...
Alguém sabe como impedir que um determinado usuário acesse o
BD via
aplicativos como sqlplus e TOAD e somente acesse via sistema?
Obrigada,
Bia.
_ _ _ _ __
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger .yahoo.com/
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não continham texto foram removidas]
_ _ _ _ __
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger .yahoo.com/
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não continham texto foram removidas]
__
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não
RE: [oracle_br] Re: Segurança no sistema ?
É estou vendo mesmo que é complicado de explicar. Bem! Vou te dizer o que estou tentando fazer. Tenho uma tabela chamada usuarios, que é onde vou cadastrar meus usuários, depois tenho uma outra tabela chamada permissoes, que é onde eu pretend gravar o nome da tabela o código do usuário juntamente com suas permissões insert/update/delete/select. Ex: Cod.Usuario = 001 tablename | insert | update | delete | select cliente | v| v|v | v estoque | v| v|f | v Seria + ou - isso. O que naum estou achando uma maneira é fazer com que as permissões sejam dadas partindo desse principio, onde o codigo daquele usuario tera as permissoes, entende ? Talvez vc possa me dar uma outra idéia. []'s Fernando Paiva Em Ter, 2007-05-15 às 15:04 -0300, FERNANDES Marco A SOFTTEK escreveu: Amigo, não é nada de espetacular não. Temos algumas tabelas auxiliares para controlar nome do usuário e outros dados, e usamos algumas views do sys pra ter os objetos do banco. Daí por diante é tudo código embarcado pra dar os grants... o detalhe é que temos algumas roles padrões para os usuários comuns do sistema (consulta, alteração, acesso) e algumas coisas também fazemos por módulos e menus do sistema. Ficou um pouco confuso porque foi feito aos poucos e por isso meio remendado. Os acesso mais gerais são controlados por roles, por exemplo, execução de procedures do banco. Já para os menus e módulos fazemos o controle a nível de usuário, ou seja, tem que dar direito pra cada transação da tela da aplicação. A tela básica é sim de cadastro de usuários... nesse cara temos a criação do usuário a partir de roles básicas (como acesso por exemplo). Temos uma outra tela de cadastro de transações e uma tela para associação dos dois cadastros. Estas transações podem estar ligadas aos objetos do banco (tabelas) e aos objetos da aplicação (menus, módulos). Nada muito complexo de fazer e nada muito simples de explicar... risos Abraço, Marco. From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of PUB: pythondeveloper Sent: terça-feira, 15 de maio de 2007 14:17 To: oracle_br@yahoogrupos.com.br Subject: [oracle_br] Re: Segurança no sistema ? Opa Vc pode me dar + ou - a explicação de como fizeram ae ? Tipo, com o cadastro de usuários e tals ? Obrigado --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br , FERNANDES Marco A SOFTTEK [EMAIL PROTECTED] escreveu Amigo, aqui nós temos exatamente isso... cada usuário que loga no sistema é um usuário de banco e existe uma tela de controle de segurança que faz todo o serviço sujo... existe pouca intervenção do DBA e o trabalho fica mesmo a cargo do Analista de Segurança. É um precinho meio caro ter isso... mas o controle fica ótimo. A outra possibilidade que já vi em outros locais é o uso de uma tabela de controle de usuários e permissões apenas na aplicação (menus, botões, etc). Mas isso tbém dá um bom trabalho ! Abraço, Marco. From: oracle_br@yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br ] On Behalf Of PUB: pythondeveloper Sent: terça-feira, 15 de maio de 2007 13:29 To: oracle_br@yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br Subject: [oracle_br] Segurança no sistema ? Saudações Estou precisando criar um sistema, mas estou emperrado na parte de segurança do mesmo, estou emperrado em decidir como faze-la. A pergunta é: Como fazer para criar um mecanismo dinâmico de segurança do meu sistema, onde eu possa dar permissões aos usuários de insert/update/delete/select nas tables, qual a técnica que vocês usam ? Eu pensei em usar usuários do banco, acho que seria a maneira mais adequada, mas me vi meio perdido, pois iria precisar criar em minha aplicação uma tela para controlar esse esquema. Alguma sugestão ? [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
RE: [oracle_br] Re: Segurança no sistema ?
Fernando, vc já tentou montar o SQL com os grants e dar um execute immediate ? Deve ter também um pacote DBMS onde vc passe o SQL ou outros argumentos e o mesmo execute na base os grants. No nosso caso criamos usuários a partir de roles e por isso não temos que dar os grants diretamente. Abraço, Marco. From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of PUB: Fernando Paiva Sent: terça-feira, 15 de maio de 2007 17:19 To: oracle_br@yahoogrupos.com.br Subject: RE: [oracle_br] Re: Segurança no sistema ? É estou vendo mesmo que é complicado de explicar. Bem! Vou te dizer o que estou tentando fazer. Tenho uma tabela chamada usuarios, que é onde vou cadastrar meus usuários, depois tenho uma outra tabela chamada permissoes, que é onde eu pretend gravar o nome da tabela o código do usuário juntamente com suas permissões insert/update/delete/select. Ex: Cod.Usuario = 001 tablename | insert | update | delete | select cliente | v | v | v | v estoque | v | v | f | v Seria + ou - isso. O que naum estou achando uma maneira é fazer com que as permissões sejam dadas partindo desse principio, onde o codigo daquele usuario tera as permissoes, entende ? Talvez vc possa me dar uma outra idéia. []'s Fernando Paiva Em Ter, 2007-05-15 às 15:04 -0300, FERNANDES Marco A SOFTTEK escreveu: Amigo, não é nada de espetacular não. Temos algumas tabelas auxiliares para controlar nome do usuário e outros dados, e usamos algumas views do sys pra ter os objetos do banco. Daí por diante é tudo código embarcado pra dar os grants... o detalhe é que temos algumas roles padrões para os usuários comuns do sistema (consulta, alteração, acesso) e algumas coisas também fazemos por módulos e menus do sistema. Ficou um pouco confuso porque foi feito aos poucos e por isso meio remendado. Os acesso mais gerais são controlados por roles, por exemplo, execução de procedures do banco. Já para os menus e módulos fazemos o controle a nível de usuário, ou seja, tem que dar direito pra cada transação da tela da aplicação. A tela básica é sim de cadastro de usuários... nesse cara temos a criação do usuário a partir de roles básicas (como acesso por exemplo). Temos uma outra tela de cadastro de transações e uma tela para associação dos dois cadastros. Estas transações podem estar ligadas aos objetos do banco (tabelas) e aos objetos da aplicação (menus, módulos). Nada muito complexo de fazer e nada muito simples de explicar... risos Abraço, Marco. From: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br ] On Behalf Of PUB: pythondeveloper Sent: terça-feira, 15 de maio de 2007 14:17 To: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br Subject: [oracle_br] Re: Segurança no sistema ? Opa Vc pode me dar + ou - a explicação de como fizeram ae ? Tipo, com o cadastro de usuários e tals ? Obrigado --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br , FERNANDES Marco A SOFTTEK [EMAIL PROTECTED] escreveu Amigo, aqui nós temos exatamente isso... cada usuário que loga no sistema é um usuário de banco e existe uma tela de controle de segurança que faz todo o serviço sujo... existe pouca intervenção do DBA e o trabalho fica mesmo a cargo do Analista de Segurança. É um precinho meio caro ter isso... mas o controle fica ótimo. A outra possibilidade que já vi em outros locais é o uso de uma tabela de controle de usuários e permissões apenas na aplicação (menus, botões, etc). Mas isso tbém dá um bom trabalho ! Abraço, Marco. From: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br ] On Behalf Of PUB: pythondeveloper Sent: terça-feira, 15 de maio de 2007 13:29 To: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br% 40yahoogrupos.com.br Subject: [oracle_br] Segurança no sistema ? Saudações Estou precisando criar um sistema, mas estou emperrado na parte de segurança do mesmo, estou emperrado em decidir como faze-la. A pergunta é: Como fazer para criar um mecanismo dinâmico de segurança do meu sistema, onde eu possa dar permissões aos usuários de insert/update/delete/select nas tables, qual a técnica que vocês usam ? Eu pensei em usar usuários do banco, acho que seria a maneira mais adequada, mas me vi meio perdido, pois iria precisar criar em minha aplicação uma tela para controlar esse esquema. Alguma sugestão ? [As partes desta mensagem que não continham texto foram removidas
