[oracle_br] Re: Segurança no BD
Bem, é inegável que a opção mais segura (e paranóica) é a senha não estar escrita em lugar nenhum, E não ter nenhuma "fórmula" (ser o mais aleatória possível) E mudar constantemente, Mas é claro que dependendo do número de senhas a memorizar isso pode ser impraticável, Além de entrar em ação o fator humano : por mais que vc queira implementar o esquema "cada senha é falada oralmente e essa-mensagem-vai-se-autodestruir-em-10-segundos", na prática as pessoas acabam passando pros papelzinhos Aí, a segunda opção seria vc ter uma senha não-100% randômica, baseada num texto aleatório mas publicamente disponível : por exemplo, numa antiga Empresa o nosso amado líder nos presenteava regularmente com e-mails tipo "Palava do Presidente", que nós (óbviamente), e nós, sequiosos da sabedoria Superior, salvamos os ditos emails numa pasta própria. Somando isso com o número da semana (segunda=dia 1) E com alguma regra simples (digamos, 2 letras iniciais da nª palavra da carta + SID com início e fim em minusc + símbolo que fica no teclado em cima do número do dia mais um número acima do dia de hoje), se numa dada segunda-feira a primeira palava da imorredoura prosa do Ser Superior foi Hoje (comemorando alguma efeméride, talvez) , para acessar a instância PROD a senha seria HopROd!2 , enquanto se a alteração foi (digamos) numa 4a feira, digamos que a 3a palavra sábia do texto do Bem Amado dos Deuses foi inflação (pois era uma séria e ponderada reflexão macro-econômica), para acessar a mesma PROD a senha seria inpROd#4 Taí, senhas bem fortes, com maiúsculas, minusc, caracter especial e números, mas não tão difícil de lembrar/calcular E claro, conforme o seu grau de paranóia, vc pode dificultar ainda mais, por ex : trocar vogais por números (no estilo hacker), mudar a posição dos componentes (tendo o seed randômico ora como prefixo ora como sufixo), aí vai Eu reporto guardar as senhas nalgum repositório como a terceira Opção, só aplicável se as duas anteriores não são viáveis : neste caso, respondendo à vc : => não, a criptografia do Excel é uma piada, googla por excel password crack pra vc ter uma idéia... => sim, um password manager seria interessante, mas vc : a) teria que escolher um com criptografia forte, no mínimo com 1024 bits na chave E que suporte/implemente mais de um algoritmo, para que fique ainda mais difícil a dedução de uma senha e b) necessariamente para se acessar o próprio password manager uma Senha é requerida, aí caímos na mesma questão de dificuldade de lembrar uma senha forte, então provavelmente teríamos que implementar algum tipo de fórmula, também ==> uma vantagem dos melhores password managers é que eles permitem que vc Automatize o algoritmo gerador de senhas E implemente as novas senhas automaticamente nas máquinas-destino (para o usuário "oracle" no SO) E também nos databases (com algumas restrições), é um ponto a considerar... Em resumo, a coisa é um trade-off entre facilidade de uso x segurança, quanto mais fácil mais inseguro, quanto mais seguro mais tempo e mais esforço vc demanda Balanceie aí a sua paranóia x a sua preguiça e chegue num mínimo denominador comum que te atenda... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga escreveu > > 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" > 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
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" 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 > 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" > > 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 v
[oracle_br] Re: Segurança no BD
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 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" > 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
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" 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 > 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" 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 (NEXT>NEXT>FINISH). > > > 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 > > > (
[oracle_br] Re: Segurança no BD
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 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" 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 (NEXT>NEXT>FINISH).
> > 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.
> >
> >
> > De: Hevandro Veiga
> > Para: oracle_br@yahoogrupos.com.br
> > Enviadas: Quarta-feira, 8 de Agosto de 2012 19:45
> > Assunto: [oracle_br] Segurança no BD
> >
> >
> >
> > Prezados,
> >
> > Recebi há algum tempo umas bases Oracle p administrar. Dentre outras
> > atividades já realizadas, cheguei na segurança.
> > Inicialmente estou cortando qualquer privilégio ANY , ADMIN ou GRANT OPTION
> > . Removi tb as roles connect e resource e inicialmente ia dar os grants
> > diretamente p o usuário ou criar uma segunda versão dessas roles que eu
> > possa manter, sem o risco de mudar entre uma versão ou outra, um patch e
> > etc.
> > E que utilizam como prática ? Nesse caso criaram a outra role ou dariam
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" 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 > > Para: oracle_br@yahoogrupos.com.br > > Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19 > > Assunto: Re: [oracle_br] Segurança > > > >
[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" 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 > > 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 LOGO
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 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] com
> > >
> > Para: [EMAIL PROTECTED] os.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 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 am
[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 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] com
> > >
> > Para: [EMAIL PROTECTED] os.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 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]
>
[oracle_br] Re: Segurança no sis tema ?
Concordo com o que o Chiappa falou. Se vc quiser fazer controle de acesso aos objetos do banco, faça-o diretamento com as features do Oracle. Agora deixa ver se eu entendi. Vc está implementando um sistema do que? Se for um sistema normal, com menus, etc, então o ideal seria implementar segurança a nível de menus e de objetos da tela, pois neste caso vai independer das tabelas que serão acessadas, e sim da funcionalidade de cada tela. Tipo, se vc tiver uma tela de manutenção de empregado, tb teria que ter direito de leitura(pelo menos) para ler o município do mesmo, agência, função, etc. -Mensagem Original- De: Fernando Paiva Para: oracle_br@yahoogrupos.com.br Enviada em: terça-feira, 15 de maio de 2007 17:19 Assunto: 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 ? > > > > > &g
[oracle_br] Re: Segurança no sistema ?
Fernando. deixe-me palpitar aí na conversa de vcs : primeiro de tudo, SE vc puder usar o recomendado, o fácil, o built-in,o nativo do banco, que é CADA usuário do sistema corresponder a um usuário no banco, aí vc NÂO TEM necessidade alguma de tabelas extras, o banco controla isso, é função dele, além de vc ganhar ENORME facilidade em traces de usuário, em auditorias, etc... Nesse cenário, vc não teria uma tabela chamada usuário, mas um uma VIEW chamada usuarios, que busca a info necessária dba DBA_USERS, DBA_TAB_PRIVS, trazendo nome da tabela, do usuário, e teria colunas INSERT, UPDATE, DELETE, SELECT, que estariam vazias pros privs de tabela que o usuário não tem, etc. A sua aplicação de controle de usuários consulta essa view, a mostra na tela, e o usuário tem chance de clicar nos campos que hoje estão vazios ou nos que estão preenchidos, se clicou numa coluna vazia (digamos, na coluna de UPDATE) a aplicação monta e envia pro banco um SQL dinâmico tipo GRANT UPDATE ON nomedatabela TO usuáriodestino, caso clicou num campo não-vazio quer remover o privilégio, aí a aplicação monta um REVOKE - já que nome do usuário e da tabela taria na view, problema nenhum Eu acho que REALMENTE não é necessário se criar tabela pera isso, MAS se vc quiser criar deve funcionar também. Agora, se por qquer mau motivo vc não puder ter o ideal e correto, que é cada usuário da aplicação ter o seu usuário de banco, aí o negócio complica mais... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Fernando Paiva <[EMAIL PROTECTED]> escreveu > > É 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" > > 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 pou
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 pr
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 ?
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]
[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, "FERNANDES Marco ASOFTTEK" <[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:[EMAIL PROTECTED] On Behalf Of PUB: pythondeveloper > Sent: terça-feira, 15 de maio de 2007 13:29 > To: oracle_br@yahoogrupos.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] >
[oracle_br] Re: Segurança em nível de conexão
Chiappa, talvez o assunto da mensagem não seja o ideal, desculpe-me, mas na verdade nós temos dúvidas quanto ao que deve ser usado para implementar 'segurança' no acesso ao banco no momento das conexões (dos usuários da aplicação). Estamos estudando formas de implementar isso. Estou lendo algumas coisas como 'user authentication' e 'proxy authentication', que usam User Enterprise, um diretório para armazenar as informações adicionais dos usuários da aplicação, etc. Lembrando que cada usuário final, de cada cliente, vai ser um usuário da aplicação, e a aplicação é quem vai ter alguns usuários do banco (1 por sistema). Ontem eu me dediquei bastante a isso e até agora a maior dificuldade que estou vendo é relacionado ao uso de pool de conexões. Assim ficam as dúvidas de como tratar isso, pois deverá haver algumas sessões disponíveis no banco. Gostaria de saber se aqui na lista alguém já implementou isso nos seus sistemas web, e se não foi dessa forma, como têm feito então? Temos lido bastante coisa a respeito desse tipo de implementação mas podemos estar indo pelo caminho errado. Espero ter sido mais claro. Anderson. --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > Cara, eu não manjo muito disso, mas lendo a sua msg ainda não ficou > claro exatamente o que vc quer, o que exatamente vc pretende dizer > com essa "segurança em nível de conexão" - é referente à segurança > lógica/privilégios de acesso aos dados, é isso ?? > Se é isso, sabemos que vc vai ter o VPD fazendo a > segunça "horizontal", ie, em cada tabela "separando" quais registros > cada sessão que conecta no banco pode acessar, o que vc quer é > segurança das colunas ? Ou é segurança das tabelas em si, vc quer que > para cada item na lista de usuários X do teu sistema haja uma lista > de tabelas permitidas , é isso ? Ou exatamente qual é a sua > necessidade ?? Vc cita "proxy user", ou seja, com ele um usuário > Oracle X pode se conectar temporariamente com os privs como se fosse > o usuário Oracle Y, mas vc vai (provavelmente por alguma limitação de > ambiente/tool, argh!) usar aquele esquema de UM ÚNICO usuário Oracle > onde todos do sistema conectam, então exatamente o que o proxy user > vai te comprar ??? > > Explica isso melhor... > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, "Anderson" <[EMAIL PROTECTED]> > escreveu > > > > Desculpem-me por insistir neste assunto, mas... > > > > Alguém da lista trabalha ou já trabalhou com "Proxy Authentication"? > > > > Conforme e-mail abaixo, como poderemos controlar ou aplicar > segurança > > em nível de conexão? > > > > Alguém pode nos orientar? > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, "Anderson" <[EMAIL PROTECTED]> > > escreveu > > > > > > Olá pessoal. > > > > > > Temos um projeto em andamento para acesso ao banco Oracle 10g > (EE) > > > via web. > > > > > > Nossas aplicações web compartilharão um pool de conexões > (Servidor > > de > > > Aplicação). > > > > > > Haverá vários usuários finais da aplicação e um usuário do banco > > para > > > cada aplicação. > > > > > > A segurança em nível de transações de banco será controlada por > > meio > > > de VPD. > > > > > > A nossa dúvida neste momento é referente à melhor forma de > > controlar > > > ou aplicar segurança em nível de conexão. > > > > > > Como os usuários finais serão usuários da aplicação e não do > banco, > > > como podemos implementar a segurança? > > > > > > Já pensamos em criar uma tabela no banco com os usuários de cada > > > aplicação e seguir por este caminho. > > > > > > Mas contamos com a colaboração e compatilhamento de experiências > > dos > > > colegas da lista. > > > > > > Quaisquer informações, indicações de materiais para estudo, > links, > > > etc, são bem vindos. > > > > > > > > > Infos adicionais: > > > - Nossa empresa tem pelo menos 20 softwares no mercado, > instalados > > em > > > mais de mil clientes. > > > > > > - Cada cliente tem mais de um software instalado e vários > usuários > > em > > > cada aplicação. > > > > > > - Um usuário pode estar ligado e cadastrado em mais de um cliente > > > (tipo 'consultores' q prestam serviços nos nossos clientes). > > > > > > - O VPD garantirá q os usuários somente tenham acesso às > > informações > > > das empresas que estão ligados. > > > > > > > > > Anderson. > > > > > > -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACL
[oracle_br] Re: Segurança em nível de conexão
Cara, eu não manjo muito disso, mas lendo a sua msg ainda não ficou claro exatamente o que vc quer, o que exatamente vc pretende dizer com essa "segurança em nível de conexão" - é referente à segurança lógica/privilégios de acesso aos dados, é isso ?? Se é isso, sabemos que vc vai ter o VPD fazendo a segunça "horizontal", ie, em cada tabela "separando" quais registros cada sessão que conecta no banco pode acessar, o que vc quer é segurança das colunas ? Ou é segurança das tabelas em si, vc quer que para cada item na lista de usuários X do teu sistema haja uma lista de tabelas permitidas , é isso ? Ou exatamente qual é a sua necessidade ?? Vc cita "proxy user", ou seja, com ele um usuário Oracle X pode se conectar temporariamente com os privs como se fosse o usuário Oracle Y, mas vc vai (provavelmente por alguma limitação de ambiente/tool, argh!) usar aquele esquema de UM ÚNICO usuário Oracle onde todos do sistema conectam, então exatamente o que o proxy user vai te comprar ??? Explica isso melhor... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Anderson" <[EMAIL PROTECTED]> escreveu > > Desculpem-me por insistir neste assunto, mas... > > Alguém da lista trabalha ou já trabalhou com "Proxy Authentication"? > > Conforme e-mail abaixo, como poderemos controlar ou aplicar segurança > em nível de conexão? > > Alguém pode nos orientar? > > > > --- Em oracle_br@yahoogrupos.com.br, "Anderson" <[EMAIL PROTECTED]> > escreveu > > > > Olá pessoal. > > > > Temos um projeto em andamento para acesso ao banco Oracle 10g (EE) > > via web. > > > > Nossas aplicações web compartilharão um pool de conexões (Servidor > de > > Aplicação). > > > > Haverá vários usuários finais da aplicação e um usuário do banco > para > > cada aplicação. > > > > A segurança em nível de transações de banco será controlada por > meio > > de VPD. > > > > A nossa dúvida neste momento é referente à melhor forma de > controlar > > ou aplicar segurança em nível de conexão. > > > > Como os usuários finais serão usuários da aplicação e não do banco, > > como podemos implementar a segurança? > > > > Já pensamos em criar uma tabela no banco com os usuários de cada > > aplicação e seguir por este caminho. > > > > Mas contamos com a colaboração e compatilhamento de experiências > dos > > colegas da lista. > > > > Quaisquer informações, indicações de materiais para estudo, links, > > etc, são bem vindos. > > > > > > Infos adicionais: > > - Nossa empresa tem pelo menos 20 softwares no mercado, instalados > em > > mais de mil clientes. > > > > - Cada cliente tem mais de um software instalado e vários usuários > em > > cada aplicação. > > > > - Um usuário pode estar ligado e cadastrado em mais de um cliente > > (tipo 'consultores' q prestam serviços nos nossos clientes). > > > > - O VPD garantirá q os usuários somente tenham acesso às > informações > > das empresas que estão ligados. > > > > > > Anderson. > > > -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: http://www.oraclebr.com.br/ __ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
RES: [oracle_br] Re: Segurança
Agradeço a todos pelas dicas e vou testar, qualquer dúvida perturbo novamente vocês. Grato Ricardo Lyrio _ De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: terça-feira, 28 de março de 2006 13:39 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Segurança Bom, não há uma receita de bolo exata e precisa pra isso, mas de modo geral : necessidade 1, criptografar : vc vai precisar escrever uma pequena rotina pra isso, tradicionalmente isso era feito com a package DBMS_OBFUSCATION_TOOLKIT, no 10g foi introduzida a DBMS_CRYPTO, que é uma melhoria dela. No manual 10g de Supplied Packages vc acha as sintaxes e alguns exemplos de ambas, em http://www.dbasupport.com/oracle/ora10g/10g_PLSQL01.shtml , http://www.dbasupport.com/oracle/ora10g/DBMS_OBFUSCATION_TOOLKIT.shtml e http://asktom.oracle.com (use a opção Search procurando por DBMS_CRYPTO) algumas dicas. necessidade 2, restringir acesso de acordo com usuário : primeira coisa, o nome do usuário que fez a inserção ** NÃO ** fica automaticamente guardado em lugar algum, vc VAI ter que guardar isso pra poder usar depois na hora de SELECTs - o mais comum seria vc ter uma coluna NOME_USUARIO nas tabelas, provavelmente preenchida automaticamente por um trigger. Uma vez vc já tendo a informação de quem inseriu (e portanto pode "enxergar") cada linha, pra que cada usuário só "veja" os seus registros, OU vc só dá pros usuários acesso a uma VIEW que filtra isso, tipo CREATE VIEW V_TABELA as (select * from tabela where NOME_USUARIO=user; , OU então vc usa o recurso do FGAC (Fine Grained Access Control), também conhecido como VPD (Virtual Private Database), com esse recurso automaticamente o banco vai "interceptar" cada SQL que vc indicar e adicionar uma condição de WHERE , no caso a condição de where NOME_USUARIO=user , o que dá o resultado desejado também. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Ricardo Lyrio" <[EMAIL PROTECTED]> escreveu > > Tenho a seguinte situação: > > > > Oracle 10gR2, e preciso implementar segurança em determinadas colunas de > algumas tabelas da seguinte maneira: > > > > Um usuário que cadastrou um registro na tabela A somente ele e mais ninguém > poderá ver o registro, inclusive num select com permissões de DBA eu não > posso ver o conteúdo do registro, ele precisa vir criptografado. > > > > Alguém tem alguma idéia de qual caminho seguir? > > > > Abraço a todos e desde já agradeço a ajuda > > Ricardo Lyrio > > > > [As partes desta mensagem que não continham texto foram removidas] > -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine __ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. _ Links do Yahoo! Grupos * Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ * Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> * O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do <http://br.yahoo.com/info/utos.html> Yahoo!. [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine __ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Segurança
Bom, não há uma receita de bolo exata e precisa pra isso, mas de modo geral : necessidade 1, criptografar : vc vai precisar escrever uma pequena rotina pra isso, tradicionalmente isso era feito com a package DBMS_OBFUSCATION_TOOLKIT, no 10g foi introduzida a DBMS_CRYPTO, que é uma melhoria dela. No manual 10g de Supplied Packages vc acha as sintaxes e alguns exemplos de ambas, em http://www.dbasupport.com/oracle/ora10g/10g_PLSQL01.shtml , http://www.dbasupport.com/oracle/ora10g/DBMS_OBFUSCATION_TOOLKIT.shtml e http://asktom.oracle.com (use a opção Search procurando por DBMS_CRYPTO) algumas dicas. necessidade 2, restringir acesso de acordo com usuário : primeira coisa, o nome do usuário que fez a inserção ** NÃO ** fica automaticamente guardado em lugar algum, vc VAI ter que guardar isso pra poder usar depois na hora de SELECTs - o mais comum seria vc ter uma coluna NOME_USUARIO nas tabelas, provavelmente preenchida automaticamente por um trigger. Uma vez vc já tendo a informação de quem inseriu (e portanto pode "enxergar") cada linha, pra que cada usuário só "veja" os seus registros, OU vc só dá pros usuários acesso a uma VIEW que filtra isso, tipo CREATE VIEW V_TABELA as (select * from tabela where NOME_USUARIO=user; , OU então vc usa o recurso do FGAC (Fine Grained Access Control), também conhecido como VPD (Virtual Private Database), com esse recurso automaticamente o banco vai "interceptar" cada SQL que vc indicar e adicionar uma condição de WHERE , no caso a condição de where NOME_USUARIO=user , o que dá o resultado desejado também. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Ricardo Lyrio" <[EMAIL PROTECTED]> escreveu > > Tenho a seguinte situação: > > > > Oracle 10gR2, e preciso implementar segurança em determinadas colunas de > algumas tabelas da seguinte maneira: > > > > Um usuário que cadastrou um registro na tabela A somente ele e mais ninguém > poderá ver o registro, inclusive num select com permissões de DBA eu não > posso ver o conteúdo do registro, ele precisa vir criptografado. > > > > Alguém tem alguma idéia de qual caminho seguir? > > > > Abraço a todos e desde já agradeço a ajuda > > Ricardo Lyrio > > > > [As partes desta mensagem que não continham texto foram removidas] > -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine __ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Segurança
Uma das maneiras é utilizando Virtual Private Database(VPD), que tem
como utilidade camuflar algumas linhas da uma determinada tabela
dependendo de um fator. Por exemplo:
Vamos supor que eu tenha uma tabela no SH de nome salario.
SQL> conn sh/sh
Connected.
SQL> show user
USER is "SH"
SQL> CREATE TABLE SALARIO(
2 NOME VARCHAR2(30),
3 SALARIO NUMBER(8,2));
Table created.
SQL> INSERT INTO SALARIO VALUES('JONATHAN',1);
1 row created.
SQL> INSERT INTO SALARIO VALUES('SH',12000);
1 row created.
SQL> INSERT INTO SALARIO VALUES('RICARDO',14000);
1 row created.
AGORA VOU CRIAR A FUNÇÃO QUE SERÁ USADA NAS COLUNAS QUE EU DETERMINAR.
RETORNAR AS LINHAS EM QUE A COLUNA NOME SEJA IGUAL AO USERNAME DO
USUÁRIO. ESTA CLÁUSULA WHERE SERÁ ADICIONADA A CADA INSTRUÇÃO SELECT
QUE FOR FEITA NA TABELA SALARIO.
SQL> CONN SYS/ORACLE AS SYSDBA
Connected.
SQL> CREATE OR REPLACE FUNCTION SALARIO_PF
2 (DONO VARCHAR2, NOMEOBJ VARCHAR2)
3 RETURN VARCHAR2 4IS
5 WHERE_CLAUSE VARCHAR2(2000);
6 BEGIN
7 WHERE_cLAUSE := 'NOME=SYS_CONTEXT(''USERENV'',''SESSION_USER'')';
8 RETURN WHERE_CLAUSE;
9 END;
10 /
Function created.
AGORA VOU CRIAR A POLÍTICA NOS OBJETOS E COLUNAS QUE EU QUERO. NESSE
CASO A TABELA SALARIO DO SH.
BEGIN
SYS.DBMS_RLS.ADD_POLICY (
OBJECT_SCHEMA=>'SH',
OBJECT_NAME=>'SALARIO',
POLICY_NAME=>'FILTRAR_SAL',
FUNCTION_SCHEMA=>'SYS',
POLICY_FUNCTION=>'SALARIO_PF',
SEC_RELEVANT_COLS=>'SALARIO');
END;
/
VOU CONECTAR COMO JONATHAN E SH E VEREI SOMENTE AS LINHAS QUE PERTENCEM
À ELES, APESAR DA TABELA POSSUIR 3 LINHAS.
SQL> CONN SH/SH
Connected.
SQL> SELECT * FROM SALARIO;
NOME SALARIO
-- --
SH 12000
SQL> CONN JONATHAN/JONATHAN
Connected.
SQL> SELECT * FROM SH.SALARIO;
NOME SALARIO
-- --
JONATHAN1
SQL> CONN SYSTEM/ORACLE
SQL> SELECT * FROM SH.SALARIO;
no rows selected
É mais ou menos isso aí :). Agora dá uma estudada em VPD e veja como
implementar aí no teu caso.
Abs
Jonathan Barbosa
- Original Message - From: "Ricardo Lyrio" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, March 28, 2006 8:28 AM
Subject: [oracle_br] Segurança
Tenho a seguinte situação:
Oracle 10gR2, e preciso implementar segurança em determinadas colunas de
algumas tabelas da seguinte maneira:
Um usuário que cadastrou um registro na tabela A somente ele e mais ninguém
poderá ver o registro, inclusive num select com permissões de DBA eu não
posso ver o conteúdo do registro, ele precisa vir criptografado.
Alguém tem alguma idéia de qual caminho seguir?
Abraço a todos e desde já agradeço a ajuda
Ricardo Lyrio
[As partes desta mensagem que não continham texto foram removidas]
--
Atenção! As mensagens deste grupo são de acesso público e de inteira
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--__
Este Grupo recebe o apoio da SQL Magazine -
www.devmedia.com.br/sqlmagazine
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo,
tenha o link do mesmo para evitar trafego(pedidos) desnecessário. Links
do Yahoo! Grupos
--
Atenção! As mensagens deste grupo são de acesso público e de inteira
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o
link do mesmo para evitar trafego(pedidos) desnecessário.
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
<*> Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
[oracle_br] Re: segurança no oracle
Tem mais de um até : alguns bons estão em http://www.pentest.co.uk , vá no link Whitepapers. Muito de segurança, porém, é bom-senso, por exemplo : - tanto auditar ** rigorosamente ** tudo quanto não auditar nada são alternativas inaceitáveis, vc TEM que levantar exatamente o que deve ser auditado, quando e como, e isso depende é das necessidades da Empresa, não sou eu nem é vc quem define isso - deve SEMPRE ser utilizado o conceito de privilégios mínimos, ie : um usuário deve ter APENAS e TÃO SOMENTE os privilégios que necessita, nem mais nem menos. O que se vê por aí de "administrador Oracle" que, por exemplo, quando alguém pede pra poder ler qqer tabela do banco o sujeito dá pro usuário a role de DBA não tá no gibi... Da mesma forma, os privilégios ANY significam (muito logicamente) QUALQUER, são POR DEMAIS poderosos : um GRANT SELECT ANY TABLE< por exemplo, implica que o sujeito poderá ler QUALQUER tabela, até as eventuais tabelas internas do banco, ou de outros sistemas - patches : comumente um patch não corrige APENAS bugs de performance/corrupção, mas TAMBÈM problemas de segurança : assim, um banco que ser quer seguro TEM QUE continuamente, sob tutela/recomendação do Suporte Oracle ** E ** do fornecedor do aplicativo, estar sendo atualizado cfrme os patches saem... - gerenciamento de senhas : as senhas poderosas (ie, root-user, oracle user, senhas DBA e SYSDBA no banco, etc), absolutamente TEM QUE serem trocadas em intervalos E tem que serem gerenciadas,ie : mantidas seguras - jamais escritas em lugar algum que não seja altamente seguro !, E conhecidas apenas pelas pessoas responsáveis e confiáveis. e coisinhas do tipo []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "mfrancoso" <[EMAIL PROTECTED]> escreveu > Boa tarde pessoal, > > Gostaria de saber se alguem tem algum artigo que fale sobre boa pratica > de segurança em um database ORACLE(versão 8.1.7.3 em solaris) > > desde já agradeço. > > obrigado. ORACLE_BR APOIA 2ºENPO-BR _ O 2º Encontro Nacional de Profissionais Oracle será realizado no dia 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas Palestras e Cases dirigidos exclusivamente por profissionais especialistas e renomados no mercado. Confira a programação no site do evento! http://www.enpo-br.org/ _ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
