Usando Access

Segurança máxima, usando o OPEN

Dois focos de segurança você deve ter em mente: um é a segurança dos dados e o outro é a segurança do aplicativo.    

A segurança do aplicativo é relativamente simples de se resolver: basta convertê-lo para a extensão ACCDE, que o oponente não terá acesso aos códigos desenvolvidos por você.

A questão da segurança dos dados é que torna-se uma dor de cabeça. 

Até a versão do Access 2003, a senha simples de acesso ao aplicativo é facilmente descoberta por programas de terceiros, que você acha facilmente aí pela pesquisa do Google.  Portanto, não servindo como proteção eficaz.

Já na versão do Access 2007/2010 , esta senha simples é considerada extremamente segura, portanto um ponto muito forte a nosso favor.   Mas, apesar de sua eficácia, existem falhas no seu emprego. Uma delas é o fato de você ter que passar a senha ao usuário para ele ter acesso ao aplicativo – Ora, se você tem que revelar a senha ao usuário , abre-se aí uma brecha na segurança.

O que se costuma fazer então, na prática, é dividir o  banco de dados em dois– um contendo apenas as tabelas, chamado de back-end e um outro contendo todos os objetos restantes, como formulários e relatórios, e que é chamado de front-end.   Ligamos então o front-end ao back-end através de programação e/ou através do que chamamos de vinculação, tornando os dois bancos como se fossem um único aplicativo.  Esta também é a maneira mais empregada para o uso em REDE.

Podemos então criar uma senha simples para o back-end (tabelas), sem contudo precisar ser revelada ao usuário, já que ele estará acessando o aplicativo apenas pelo front-end. 

Quando você estiver configurando a ligação entre os dois bancos, seja ela por programação ou por vinculação, terá que informar a senha do back-end no processo.    Quando se faz isso por programação, não há risco algum desta senha ser descoberta, desde que você transforme seu aplicativo (front-end) para a extensão ACCDE (códigos protegidos).   Porém, quando se faz a ligação por vinculação, abre-se uma brecha enorme na segurança desta senha simples do back-end (você verá como, no vídeo apresentado).  

Muitos programadores, cientes deste fato, preferem optar em fazer a conexão do back-end por programação, mas isso traz uma enorme prejuízo no quesito tempo, pois haverá um acréscimo substancial de programação.  Eu, particularmente, não uso deste artifício em projetos grandes, pois preciso muito otimizar meu tempo.  Um projeto que preferi configurar por programação, pois não tinha muitas tabelas, foi o MontaRibbons, que eu ofereço aqui no site.

Então qual é o problema na vinculação ?

O problema é que as tabelas autenticadas automaticamente pela vinculação estarão disponíveis livremente pelo seu front-end.  Se nada for feito para impedir o acesso aos vínculos criados no front-end , o oponente terá acesso livre, não só aos dados, como também irá conseguir obter a senha do seu back-end que está gravada (sem qualquer proteção) nos vínculos – um absurdo!

O que fazer então?

A situação poderá ser amenizada, criando-se uma senha simples também para o front-end.  Mas cairemos na mesma situação inicial, de que esta senha de acesso deverá ser revelada para o usuário.  Pelo menos estaremos aí reduzindo o risco a zero, caso o oponente furte o banco sem a senha do usuário.

Um outro entrave que acontece com esta senha simples no front-end é o fato de termos que criar para maioria dos aplicativos, uma programação de segurança a nível de usuário, que força a gente a abrir um formulário na inicialização, solicitando nome e senha de usuário.  Ora, então o usuário terá que autenticar duas senhas para entrar no front-end:  uma de acesso global ao programa e a outra de acesso restrito ao usuário. Isso acaba não sendo funcional! Adivinhe só qual das senhas eu costumava descartar?

Não conformado com esta situação de risco , consegui elaborar um banco auxiliar, que chamo de OPEN e que faz automaticamente essa autenticação da senha simples para o front-end. 

Matei assim dois coelhos: não revelar as senhas do back-end e front-end para o usuário e não conflitar com a abertura do formulário de senha, a nível de usuário. 

O OPEN e a extensão ACCDR

ACCDR é uma nova extensão de arquivo que permite a abertura de um banco de dados em modo de tempo de execução.  Ao fazer a alteração da extensão do arquivo de ACCDB para ACCDR, você estará criando  uma versão "bloqueada".  

O modo de tempo de execução é um modo operacional  que desativa o Painel de navegação, a Faixa de opções, o Modo de design, o Modo de layout e a Ajuda.

O OPEN foi configurado para rodar o front-end apenas na extensão ACCDR, proporcionando um nível de segurança, sem qualquer programação adicional, que necessitaria ser feita se tivesse em outra extensão.   Assista o vídeo e você entenderá perfeitamente como isso funciona

Consegui gerar um nível de segurança tão bom com o OPEN, que estou utilizando em alguns dos meus clientes, os bancos em ACCDB (facilitando meus reparos no local) convertidos em ACCDR.

Neste vídeo você verá:

Como dividir seu banco de dados em back-end e front-end.
Como configurar senha simples.
Como capturar a senha do back-end pelo front-end sem proteção.
Como se proteger de keyloggers
Como configurar o OPEN para o seu projeto.
Como gerar senha para o próprio OPEN, se não utilizar senha a nível de usuário.

O arquivo

Baixe o arquivo Open.zip abaixo, que contém dois aplicativos: O Open.accdr e o SenhaOpen.accdr

Baixe aqui

Como EXIBIR a vídeo-aula em tela cheia?

1. clique na seta executar da tela abaixo para iniciar a exibição do vídeo;

2. dê dois cliques rápidos na tela, quando o vídeo começar a ser exibido.

Artigos Relacionados

O MDW (segurança em nível de usuário) morreu

Como configurar seu Banco de Dados com a extensão ACCDR

Vídeo - Criando ribbons (parte 1) - MontaRibbons

Vídeo - Criando Ribbons (parte 2) - MontaRibbons

| Home | Vídeos-aulas | Tutoriais | Dicas | Blog | Downloads | Contato | Artigo |