[firebase-br] Voltando ao assunto de segurança

OttoFuch ottofuch em terra.com.br
Sex Ago 15 10:32:01 -03 2008


Continuo mantendo a minha opinião de que a segurança tem que ser garantida 
pelo sistema operacional do servidor, que não pode ser Windows NT 
workstation, Windows 2000 professional, Windows XP ou Windos Vista, e sim, 
ou da linha Windows Server (NT, 2000, 2003 ou 2008), NetWare ou Linux 
blindado.

Porque a linha server do Windows tem recursos para isto, sobretudo depois da 
inclusão do Active Directory. Minha formação, nesta área foi da linha 
NetWare (3.12 até 6.5 - o último) que leva a segurança e flexibilidade ao 
máximo. Mas mesmo assim deve haver ganchos no servidor de banco de dados que 
permite esta segurança cobrir também áreas internas do gerenciador do banco 
de dados, protegendo bancos de dados inidividuais, e dentro dele, tabelas 
individuais, ou até colunas.

Em
http://www.oracle.com/technology/tech/windows/wp/Oracle_with_Active_Directory_TWP.pdf
encontrei um artigo, de 2004, em inglês, "Usando Oracle com Microsoft Active 
Directory"

O MySQL não tem nada disto. Será necessário na maioria dos casos?

100+

Otto

----- Original Message ----- 
From: "Rodrigo" <dominio em engeplus.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, August 15, 2008 8:58 AM
Subject: Re: [firebase-br] Voltando ao assunto de segurança


Bom dia a todos,

Sobre segurança do banco acho algo importante. Até a tempos atraz postei
sobre esse topico, pois tinha o costume de
alterar a Senha Masterkey do password do banco, e só entrava com essa senha.

Estava bem facero com isso. Evitava que varias pessoas mal intecionadas
usassem algum gerenciador de banco de dados, para
alterar valores do banco. Tinha um que até tentou boicotar meu sistema
excluindo registros e falando pro seu chefe que o sistema
era falho. entao tive a ideia de mudar a senha do banco e nunca mais tive
problemas.

Até que certo dia alguns clientes tinham outros sistemas rodando com senhas
diferentes. Ai começaram as dores de cabeça.

Enfim troquei novamente a senha para senha padrao Masterkey.

Nao sei se é muito dificil de fazer, mas em vez de colocar a senha no
servidor firebird, colocar diretamente no banco, onde
varios bancos podem ter senhas diferentes?

Acho que seria uma ótima solução.

At.
Rodrigo


----- Original Message ----- 
From: "Magno System" <magno em speet.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Thursday, August 14, 2008 10:49 PM
Subject: Re: [firebase-br]Voltando ao assunto de segurança


Olha João Paulo, só para você ter idéia no meu ponto de venda, a venda à
vista, venda a prazo, controle de estoque, cancelamento de venda, cálculo de
desconto, cálculo de multa, fechamento de caixa é todo feito através de SP.
E o banco é aberto.

Se alguém quiser usar o meu banco de repente para casar alguma rotina com um
programa já existente no cliente, ótimo eu dou todo apoio. Eu não vejo como
pirataria e sim como uma grande possibilidade de termos um cliente em comum.

Para finalizar vou pegar um exemplo: O Jason Wharton disponibilizou o código
do IBO. O IBO é considerado por uma grande massa de desenvolvedores como o
melhor componente para INTERBASE e FIREBIRD. Eu não conheço nenhum
programador que tenha pego o código do IBO e comercializado fazendo
adaptações, porque mesmo sendo um código aberto, quem detém a lógica e o
conhecimento das estruturas do componente é o Jason Wharton. Agora imaginem
um banco onde o funcionamento das SP's e TRIGGER, etc dependem de um código
de uma linguagem de programação ao qual ninguém além de você, se você assim
o desejar, terá acesso.

Neste ponto, acho que o FOREST entendeu o espírito da coisa...


----- Original Message ----- 
From: "Joao Paulo Franqueto" <joao.franqueto em gmail.com>
To: <lista em firebase.com.br>
Sent: Thursday, August 14, 2008 7:28 PM
Subject: Re: [firebase-br]Voltando ao assunto de segurança


Me desculpe Magno, mas neste seu caso então seu código é "writeOnly" ou o
pessoal desta software house é muito fraco. Brincadeiras a parte, acredito
que no seu caso, o problema seja o pessoal da software house...

Sobre o código fonte em SP e Trigger acho que não deve ser grande ponto de
preocupação, pois em minha opinião a regra de negócio não deve ser
implementada em SPs e Triggers, pois impossibilita um teste automatizado de
qualidade, sem contar que o debug é mais difícil. Estes recursos devem ser
usados quando trazem grande ganho de performance ou quando são
processamentos simples que ajudam a manter um código fonte legível e
simples. Ainda com o FB, as SPs selecionáveis são um grande diferencial por
possibilitarem a criação de relatórios complexos com facilidade, mas como
isto não é regra de negócio, não tem com que se preocupar.

Muitos usam SPs para melhorar o desempenho do software, já que o mesmo foi
desenvolvido como client/server pois o acesso a uma SP é muito mais rápido
do que acessar várias tabelas e acabam colondo a regra de negócio nas SPs.
Mas neste caso, pode ser usado de maneira emergencial, mas a forma correta
ao meu ver, é usar desenvolvimento em camadas.

Sobre a proteção dos dados, é tão importante para o desenvolvedor quanto pro
cliente, pois ele deve estar sabendo do problemas que um acesso indevido
diretamente no banco de dados pode gerar, como um pagamento anulado
indevidamente, dados apagados, etc... estes item vão gerar preocupação e
fazer com que o cliente investa em segurança, colocando No-Break, sala
restrita, acesso controlado, rede e firewall bem configurado, etc...

Mas caso alguma outra empresa tente pegar o banco de dados para uma migração
de sistema, acho que o cliente tem o direito, pois os dados armazendos no
sistema desenvolvido são dele. Foi ele quem adicionou todos os dados
contidos lá.
Se está ocorrendo um caso destes, é ruim para quem desenvolveu aquele
software, mas o cliente deve ter seus motivos, como um sistema atual que não
lhe atende da forma que ele queria, ou um sistema que contêm vários bugs
etc...
Se o cliente estiver tomando a decisão errada, ele vai acabar voltando atrás
e neste momento você poderá cobrar tudo o que deixou de ganhar. Se ele não
voltar, é sinal que existe algo errado e você precisa melhorar...

Bom, acho que é isto...

João Paulo...


2008/8/14 Magno System <magno em speet.com.br>

> Eu tenho no meu site, demonstrativos (banco demonstrativo = banco de
> produção) com o código do banco todo aberto e olha que eu uso e abuso de
> triggers e stored procedures e honestamente não me incomodo nem um pouco,
> pois com certeza é muito mais difícil uma software house estudar o código
> do
> meu banco e fazer um programa em cima do que começar o projeto do zero.até
> porque muitas vezes uma STORED PROCEDURE é tratada no código fonte do
> programa (no meu caso DELPHI) para ela poder desempenhar seu papel.
>
> Para se ter idéia recentemente eu vendi um fonte (banco de dados + delphi)
> para uma software house e a mesma constantemente me procura fazendo com
> que
> 80% das alterações eu mesmo tenha que fazer.
>
> Quanto aos dados eu concordo. Mas aí um linux bem instalado resolve
> bloqueando o acesso físico ao banco.
>
>
>
______________________________________________
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

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.3/1611 - Release Date: 14/8/2008
06:20




______________________________________________
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

E-mail verificado pelo Terra Anti-Spam.
Para classificar esta mensagem como spam ou não spam, visite
http://mail.terra.com.br/cgi-bin/reportspam.cgi?+_d=SCYxMTkzOTg4MSNwZXJtIXRlcnJhJjEsMTIxODgwMTY4NC44NDM2MTIuMjc2OTUuZG9tb25pLmhzdC50ZXJyYS5jb20uYnIsMTA0NTM=
Verifique periodicamente a pasta Spam para garantir que apenas mensagens
indesejadas sejam classificadas como Spam.








Mais detalhes sobre a lista de discussão lista