DBF x Segurança

por **EANDRIOLI** » 09 Fev 2015 14:53

Amigos...

Meus sistemas usam DBF para guardar as informações.

Todos sabem que esses arquivos ficam disponíveis "abertamente" para qualquer um que tiver acesso ao DBU/DBASE.EXE; podem fazer qualquer alteração sem autorização.

Queria mudar para outra forma em que se use uma senha para abri-los, como os arquivos em SQL etc.

Mas queria fazer isso sem mudar muita coisa em meus PRGs.

Alguém tem uma luz?

Saudações,

ERASMO ANDRIOLI

por **Toledo** » 09 Fev 2015 17:39

Erasmo, acho que a melhor solução seria o LetoDB:

LetoDb e Harbour, como usar

RDD LETO Sem Mistério

Abraços,

por **rochinha** » 09 Fev 2015 21:45

Amiguinho,

Você poderia usar o comando, USE arquivo SHARED ENCRIPTED, só que não.

Dê uma olhada na postagem DBF: criptografia total e permanente.

Pelo que coloquei a modificação seria pequenissima e direta. Eu só criptografo os campos que quero, um exemplo é o campo nome numa tabela de clientes e descriptografo no momento de ser visualizado no browser do sistema.

O único passo que seu sistema terá de fazer é o de criptografar na primeira vez a tabela:

function DBFEncripta( cDBF, lEncriptar, cCriptFrase )
   do case
      case cDBF = "CLIENTES"
           dbSelectArea( cDBF )
           OrdSetFocus( 0 )
           dbGoTop()
           do while .not. eof()
              _oque_ := clientes->NOME
              dbRLock()
              if lEncriptar // Quero encriptar
                 if !( cCriptFrase $ _oque_ ) // Se a frase de criptografia ainda na existir, inclui...
                    clientes->NOME := cCriptFrase + Codifica( alltrim( _oque_ ) )
                 endif
              else // Quero descriptar
                 if cCriptFrase $ _oque_
                    clientes->NOME := Decodifica( StrTran( _oque_, cCriptFrase, "" ) )
                 endif
              endif
              dbRUnLock()
              dbCommit()
              dbSkip()
           enddo
           OrdSetFocus( 2 )
           dbGoTop()
   endcase
   return nil

por **carlos_dornelas** » 11 Fev 2015 11:52

Utilizo de forma muito simples e eficaz com a DBFINFO no xharbour, mas acredito que também faça parte do harbour. Veja:

#include "dbinfo.ch"

passw:= "sua password que pode ser tambem criptografada"

aq1:={}
aadd(aq1,{'rsv2' ,'c',30,0})
aadd(aq1,{'rsv3' ,'n',30,0})
dbcreate('impostos',aq1)
use impostos
impostos->(DbInfo(DBI_PASSWORD, passw))

Faz o teste. Na tua aplicação ficará tudo transparente, dbedit(), etc. Abra por outro aplicativo e tudo estará criptografado.

[]s

Antonio Carlos - Curitiba

por **Toledo** » 11 Fev 2015 12:45

carlos_dornelas escreveu:mas acredito que também faça parte do harbour

Faz parte sim, veja um exemplo com mais detalhes:

viewtopic.php?f=4&t=11483#p65453

Obs.: a senha pode ter até 8 caracteres e arquivos de índices e os arquivos DBT não são criptografados.

Abraços,

por **EANDRIOLI** » 11 Fev 2015 15:29

Boa tarde!

Não entendi... ele vai deixar os arquivos .DBF criptografados? de quem forma isso ocorrerá se ele é criado normalmente pelo sistema?

ERASMO

por **Kapiaba** » 12 Fev 2015 12:05

Erasmo, desta forma, todo o conteudo do banco de dados fica invisivel para o fox.exe ou dbase.exe, somente o seu programa visualiza, mas eu não achei legal...

#Include "FiveWin.ch"  // retire para testar
#Include "dbinfo.ch"
 
FUNCTION PASSDBF()
 
   LOCAL cSenha := "123456"
   LOCAL cArq, n
 
   cArq := {}
 
   AADD( cArq, { 'CNOME' , 'C', 40, 0 } )
 
   AADD( cArq, { 'NUMERO', 'N', 16, 0 } )
 
   DBCREATE( 'PASSDBF', cArq )
 
   USE PASSDBF
 
   PASSDBF->( DbInfo( DBI_PASSWORD, cSenha ) ) // AQUI ENCRIPTA TUDO
 
   FOR N = 1 TO 10
 
      APPEND BLANK
 
      // NEM O FOX.EXE, NEM O DBASE.EXE ABREM. - Usando xHarbour.
      REPLA CNOME  WITH "ENCRIPTANDO DADOS COM SENHA NO DBF"
      REPLA NUMERO WITH VAL( "999999999999999" )
 
   NEXT
 
   GO TOP
 
   Browse()
 
RETURN NIL

abs.

por **Kapiaba** » 12 Fev 2015 12:06

Erasmo,

Assim, nem o fox.exe ou dbase.exe abrem o banco, somente o programa principal.

   //#define DBI_ENCRYPT             140  /* Encrypt table */
   PASSDBF->( DbInfo( DBI_ENCRYPT, cSenha ) )

abs

por **Itamar M. Lins Jr.** » 12 Fev 2015 12:41

Meu pensamento é o mesmo do Maligno (não sei se ele mudou) na época era que os dados pertencem ao usuário. Por isso não vejo como questão crucial.
Mas gostei das dicas.
Com qualquer servidor SQL a pessoa mal intencionada pode bagunçar tudo, tanto faz ser DBF, SQL etc...
Se ela tem acesso ao servidor e quer prejudicar não adianta nada disso.
Por exemplo, pode dar um boot com pen drive ou cdrom e formatar o servidor.
Quem sabe usar DBU ou algo similar não é um usuário primário.

Saudações,
Itamar M. Lins Jr.

por **Jairo Maia** » 12 Fev 2015 14:19

Olá Pessoal,

Minha opinião:

Os dados São propriedade particular do Cliente, e isso de forma explicita, nenhum juiz pensa o contrário.

Por outro lado, o desenvolvedor pode sim usar criptografia nos bancos de dados, e impedir que outros utilitários o vejam, deixando isso apenas por conta do programa que o gerencia.

Banco de dados DBF uma vez criptografados, podem ser transportados da forma que desejar, porém eles estarão sempre criptografados, mesmo que se formate o computador.

Se os dados estão criptografados, e o cliente decide interromper contrato, e seu sistema não tem o recurso que se não for fornecida chave liberação ele bloqueia as funções principais, permitindo apenas consultas aos dados, o cliente pode exigir e você tem a obrigação de fornecer um utilitário para que ele possa acessar seus dados quando quiser.

A Lei Brasileira de Software é omissa nisso, mas protege os direitos autorais e reza sobre a obrigação do desenvolvedor com o cliente.

por **Kapiaba** » 12 Fev 2015 15:04

Para voltar o banco de dados ao normal, abrindo pelo fox.exe ou dbase.exe

   //#define DBI_DECRYPT             141  /* Decrypt table */
   PASSDBF->( DbInfo( DBI_DECRYPT, cSenha ) ) // AQUI DESENCRIPTA TUDO

Abs.

por **Itamar M. Lins Jr.** » 12 Fev 2015 19:05

Banco de dados DBF uma vez criptografados, podem ser transportados da forma que desejar, porém eles estarão sempre criptografados, mesmo que se formate o computador.

Contanto que a senha fique de posse da empresa. O pessoal deve poder acessar a base através de outros programas. Os dados pertencem ao cliente imagine uma planilha excel que ninguém pode acessar, apenas o excel ? hoje podemos abrir a maioria dos documentos e compartilhar a informação.
Dados criptografados não servem para nada. .XLS é um padrão de dados assim como o .DBF, se eles estão criptografados não serão úteis para programas de terceiros... Quem quer abrir DBF para alterar dados, deve entender o que está fazendo, se for apenas p/ prejudicar existem outros meios só criptografia não adianta nada se a pessoa tem acesso fisicamente ao computador.

Saudações,
Itamar M. Lins Jr.

por **Itamar M. Lins Jr.** » 12 Fev 2015 19:20

É bem simples o que estou escrevendo.
MSSQL por exemplo os dados estão de uma certa forma protegidos, mas qualquer programa feito com qualquer linguagem moderna pode acessar, contanto que o administrador informe os dados p/ acesso.

Saudações,
Itamar M. Lins Jr.

por **Jairo Maia** » 12 Fev 2015 20:00

Olá Itamar,

Itamar M. Lins Jr. escreveu:Contanto que a senha fique de posse da empresa.

Senha é pessoal e intransferível. Se alguém fizer alguma operação com sua senha, o responsável é você, até que você prove judicialmente que sua senha foi obtida de forma ilegal.

Itamar M. Lins Jr. escreveu:O pessoal deve poder acessar a base através de outros programas.

Não. Não deve. Essa decisão é do desenvolvedor, e se for o caso, deve fazer parte do contrato, onde o desenvolvedor se exime de responsabilidades.

Itamar M. Lins Jr. escreveu:Os dados pertencem ao cliente

Sim. Ele é proprietário dos dados.

Itamar M. Lins Jr. escreveu:imagine uma planilha excel que ninguém pode acessar, apenas o excel ? hoje podemos abrir a maioria dos documentos e compartilhar a informação.

Como disse antes, essa decisão é do cliente contratante, sem prejuízo ao desenvolvedor se ele decidir que seus dados tenham acesso livre (público).

Itamar M. Lins Jr. escreveu:Dados criptografados não servem para nada.

Não até você encontrar um cliente que peça isso, principalmente em SGBD Legado.

Itamar M. Lins Jr. escreveu:Quem quer abrir DBF para alterar dados, deve entender o que está fazendo, se for apenas p/ prejudicar existem outros meios só criptografia não adianta nada se a pessoa tem acesso fisicamente ao computador.

Com certeza. Basta ver o que os Estados Unidos Montou (e custa uma fortuna) após 2012, quando teve seus bancos de dados invadidos por um antigo espião (deles mesmo, a saber: Edward Snowden).

No entanto, quanto menos facilitar melhor em sistemas que necessitam esse tipo de segurança.

por **Itamar M. Lins Jr.** » 12 Fev 2015 20:45

Ola!

Não. Não deve. Essa decisão é do desenvolvedor, e se for o caso, deve fazer parte do contrato, onde o desenvolvedor se exime de responsabilidades.

Pois é, no mundo real não funciona dessa forma. Já participei de projetos com a Lenovo por exemplo tínhamos acesso aos dados das bases de dados deles, nenhuma era criptografada, basta o endereço ip e senha.
No caso o projeto uma base em MSSQL e Oracle e uma terceira, que eu nem sei... penso que era via dados exportados CVS.
Meu sistema eu exporto dados p/ XLS por exemplo... então não tenho esse trauma com criptografia.
Desenvolvedor não apita nada em projetos grandes. Fala mais alto quem paga mais.

Senha é pessoal e intransferível. Se alguém fizer alguma operação com sua senha, o responsável é você, até que você prove judicialmente que sua senha foi obtida de forma ilegal.

Senha do servidor do SGBD Jairo, não tem nada a ver com essa que vc está se referindo.

Como disse antes, essa decisão é do cliente contratante, sem prejuízo ao desenvolvedor se ele decidir que seus dados tenham acesso livre (público).

Não Jairo não é publico é um acesso restrito vc pode somente permitir por exemplo acesso a leitura, não pode gravar nada.
Como disse antes o desenvolvedor não apita nada!!! A base de dados é do cliente ele comprou o MSSQL por exemplo e dentro dele rodam 5 bases de aplicativos de empresas diferentes, que podem ou não compartilhar dados.
Vc vai criptografar os seus dados dentro de uma base MSSQL por exemplo ?
Vai criptografar os dados de uma planilha excel ?
É o mesmo pensamento p/ DBF. Pode até criptografar, mas a chave para descriptografar deve pertencer a quem é o dono das informações, não pertence a quem fez o programa, não pertence a Microsoft por exemplo.
A empresa compra um servidor de banco de dados por 200.000,00 por exemplo, coloca lá dentro vários tipos de informações de diversos programas e de diversas empresas, ai vem um lindinho coloca a informação dele toda criptografada os outros precisando trabalhar com a informação vai fazer como ?
Meus dados estão protegidos ele diz, ai o dono da empresa fala protegidos de quem ? eu preciso saber quantos notebooks deram defeito... ? É mais meus dados... Seus dados ? como assim ?
Podem existir dados criptografados em SGBD(MSSQL/FireBird/MySQL...) mais é muito difícil achar, em 99% é apenas uma senha e o IP do servidor... no mais voltamos tudo de novo p/ o inicio da conversa.

Saudações,
Itamar M. Lins Jr.

DBF x Segurança

DBF x Segurança

DBF x SEGURANÇA

DBF x SEGURANÇA

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

DBF x Segurança

Quem está online