[firebase-br] RES: RES: RES: Otimização de Transação

Eduardo Jedliczka jedyfb em gmail.com
Sex Dez 4 00:57:06 -03 2009


No firebird 2.1 não existe mais esta de "criar uma role para o SYSDBA".

ou seja, se alguém sabe a senha do SYSDBA ele pode acessar o banco,
apagar qualquer constraint / indice, apagar as triggers alterar qualquer
registro e reconstruir o banco como estava antes.

o segredo é proteger o banco...

ou criar uma política de replicação (para um banco protegido ou que não
possa ser excluído)

abraço

Eduardo

Em Qui, 2009-12-03 às 14:09 -0200, Alexandre Sousa escreveu:
> As triggers garantem os logs mesmo via acesso direto.
> 
> Agora se o admin acessar e excluir logs, concorda que ele está ciente dos 
> problemas com auditoria?
> 
> Uma boa solução e criar roles, adicionar o sysdba numa role e tirar o grant 
> para delete das tabelas de log para a role.
> 
> Criar uma outra role com um usuário auditor que tenha grant nessas tabelas e 
> restringir a senha para uma, no máximo duas pessoas. Se alguém acessar com a 
> senha do auditor e excluir algo, da pra saber quem foi e esse alguem que 
> pague o pato.
> 
> Abraços!
> 
> ----- Original Message ----- 
> From: "Luis" <luisfirevb em gmail.com>
> To: "'FireBase'" <lista em firebase.com.br>
> Sent: Thursday, December 03, 2009 1:51 PM
> Subject: [firebase-br] RES: RES: RES: Otimização de Transação
> 
> 
> O problema não é via aplicativo, mas sim acesso direto pelo DB.
> Quem pode garantir ou impedir que alguém com acesso ao DB exclua um registro
> ou apague qualquer rastro da exclusão desse registro? Sem ter uma numeração
> sequencial, acredito que seja impossível.
> 
> Mesmo que o próprio DB fosse capaz de gerar os tais logs, quem tem o acesso
> ao DB para exclusão (Admin) por exemplo, poderia igualmente excluir os logs
> e daria no mesmo.
> 
> Luis
> 
> -----Mensagem original-----
> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
> nome de Alessandro Morais
> Enviada em: quinta-feira, 3 de dezembro de 2009 13:46
> Para: FireBase
> Cc: FireBase
> Assunto: Re: [firebase-br] RES: RES: Otimização de Transação
> 
> Mas acredito que a solução seriam os logs e não permissão de
> exclusão dos registros e sim inativacao dos mesmos.
> Abraços
> 
> Enviado de meu iPhone
> 
> Em 03/12/2009, às 13:20, Luis <luisfirevb em gmail.com> escreveu:
> 
> > Quem disse que é "Auditoria de Sistema = informática"?
> > Leia melhor antes de responder colega, disse ..." Trabalho com
> > auditoria de
> > normas técnicas" isso é PBQP-H, ISSO-9001, PROBARE entre outras e
> > não tem
> > relação direta com informática, mas sim com você excluir um
> > registro de
> > controle exigido pela norma, por isso a numeração sempre deve ser se
> > quencial
> > ok?
> >
> > Antes de responder e criticar como "Berçário", entenda o que leu é
> > mais
> > profissional.
> >
> > Luis
> >
> >
> > -----Mensagem original-----
> > De: lista-bounces em firebase.com.br [mailto:lista-
> > bounces em firebase.com.br] Em
> > nome de RM
> > Enviada em: quinta-feira, 3 de dezembro de 2009 11:44
> > Para: FireBase
> > Assunto: Re: [firebase-br] RES: Otimização de Transação
> >
> > Auditoria e Controle...
> >
> > Isso só existe se no mínimo todas as alterações/modificações do
> > banco sejam
> > registradas por mecanismo de LOG (Isso sim seria auditoria do DB)...
> >
> > Menos que isso é coisa de berçário...
> >
> >
> > t++
> >
> > --------------------------------------------------
> > From: "Luis" <luisfirevb em gmail.com>
> > Sent: Thursday, December 03, 2009 9:24 AM
> > To: "'FireBase'" <lista em firebase.com.br>
> > Subject: [firebase-br] RES:  Otimização de Transação
> >
> >> Sandro bom dia.
> >>
> >> No meu caso isso não é perfumaria, muito pelo contrário. Porém mi
> >> nha
> >> necessidade é um pouco diferente. Não se trata de reaproveitamento
> >>  dos
> >> números ou preenchimento de lacunas, mas não deixar a sequência se
> >>  quebrar
> >> explico.
> >>
> >> Trabalho com auditoria de normas técnicas e a gestão das mesmas im
> >> plica em
> >> rastreabilidade. Sendo assim os controles realizados, devem
> >> obrigatoriamente
> >> seguir uma sequência sem lacunas, pois se houver lacunas pode ser
> >> assumido
> >> que houve exclusão de uma informação importante para ser ocultada,
> >>  mesmo
> >> que
> >> manualmente no banco. Assim essa numeração não pode "falhar". Exem
> >> plo: Um
> >> dos controles é reclamação de clientes, essas reclamações devem
> >> ser
> >> cadastradas e tem seu processo normalmente, com apuração, ações,
> >> aprovação
> >
> >> e
> >> verificação final de sua solução. Se houver uma falha um auditor
> >> pode
> >> entender como exclusão de informação crítica que compromete o
> >> sistema de
> >> controle e não certificar a empresa.
> >>
> >> Para evitar isso implementei justamente a forma mais viável, pegar
> >>  sempre
> >> o
> >> último código cadastrado e somar + 1, se na hora de gravar alguém
> >> fez isso
> >> miléssimos de segundos antes, então haverá um erro retornável, o
> >> sistema
> >> interceptará e realizará nova tentativa + 2 e assim até conseguir
> >> gravar.
> >>
> >> Até hoje não encontrei outra solução mais viável que essa para
> >> evitar
> >> buracos na numeração.
> >>
> >> Luis
> >>
> >> -----Mensagem original-----
> >> De: lista-bounces em firebase.com.br [mailto:lista-
> >> bounces em firebase.com.br]
> >> Em
> >> nome de Sandro Souza
> >> Enviada em: quinta-feira, 3 de dezembro de 2009 02:15
> >> Para: FireBase; Josauro S. J.
> >> Assunto: Re: [firebase-br] Otimização de Transação
> >>
> >> Bom dia/tarde Josauro.
> >>
> >> No meu caso, faço tudo dentro de uma única transação, mas como v
> >> ocê
> >> mesmo citou, o problema de dois ou mais usuários tentarem utilizar o
> >> mesmo código devido à concorrência existe realmente. A única
> >> vantagem,
> >> no meu caso, é não necessitar de uma tabela de códigos
> >> reaproveitáveis,
> >> mas no restante, não foge dos problemas que você já está passan
> >> do.
> >>
> >> Como já foi citado várias vezes em outros posts, o uso de
> >> geradores/sequences poderia realmente resolver essa questão de
> >> concorrência, mas por outro lado, fugiria a reutilização de
> >> códigos como
> >> é o nosso caso.
> >>
> >> Uma outra abordagem poderia ser a seguinte:
> >>
> >> 1 - Todas as chaves estrangeiras seriam criadas utilizando a opção
> >>  "ON
> >> UPDATE CASCADE".
> >>
> >> 2 - Utilizaríamos geradores/sequences, e dessa forma, nas inclusõe
> >> s não
> >> reutilizaríamos mais os códigos excluídos, ganhando performance e
> >> nos
> >> livrando de problemas de concorrência no que se refere ao uso do m
> >> esmo
> >> código.
> >>
> >> 3 - Criaríamos uma stored procedure que seria acionada sempre que
> >> desejássemos encontrar essas "brechas" de código em cada uma das t
> >> abelas
> >> dos nossos bancos, e encontrando-as, executaria UPDATEs nesses campos
> >> chaves para efetuar as "correções" e rearrumar os códigos para dei
> >> xar
> >> tudo sequencial e sem essas "brechas". Como as chaves estrangeiras
> >> teriam sido criadas com a opção "ON UPDATE CASCADE" (item 1), esses
> >> mesmos códigos nas tabelas filhas/detalhes seriam automaticamente
> >> alinhados/ajustados pelo próprio banco. Para caad tabela que sofreu
> >> ajustes de código, seu respectivo gerador/sequence também seria
> >> reajustado.
> >>
> >> Dessa forma, eu acredito que teriamos uma forma melhor de conseguir o
> >> que pretendemos.
> >>
> >> Sei que o fato de deixar essas "brechas" de código não tem realme
> >> nte
> >> qualquer impacto negativo no sistema, que viveria tranquilamente com
> >> isso, e que essa necessidade de manter todos os códigos em ordem
> >> sequencial e sem "brechas" é apenas questão de gosto pessoal,
> >> "perfumaria" ou simplesmente ter a sensação de que tudo está organ
> >> izado
> >> no banco, e que só haveria necessidade real disso se por acaso
> >> tivéssemos tabelas com tantos registros que poderia acontecer de e
> >> sgotar
> >> os valores disponíveis para os campos chaves.
> >>
> >> No meu caso específico, assumo que se trata apenas de gosto pessoa
> >> l mesmo.
> >>
> >> Josauro, o que você acha dessa nova abordagem?
> >>
> >> Espero ter ajudado mais que atrapalhado. :D
> >>
> >> Josauro S.J. escreveu:
> >>
> >>
> >> ______________________________________________
> >> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> >> Para saber como gerenciar/excluir seu cadastro na lista, use:
> >> http://www.firebase.com.br/fb/artigo.php?id=1107
> >> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >>
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> > http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: 
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa 
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa






Mais detalhes sobre a lista de discussão lista