Como eu poderia fazer um backend do MsAccess e do Mysql mais conscientes do usuário?

Question

Eu tenho um banco de dados front-end MsAccess distribuído que usa um backend mysql.

Ele usa as conexões ODBC DSN do sistema Windows para se conectar ao servidor. Todas as minhas tabelas vinculadas referem-se a essa conexão ODBC. A coisa é, todos eles usam o mesmo nome de usuário e senha que é codificado em cada computador.

Qual seria a melhor maneira de implementá-lo para que cada usuário recebesse seu login.

Como cada conexão de DSN é "hard-wired", não acho que reescrever o registro toda vez que o aplicativo for iniciado é uma maneira segura, já que no momento em que o aplicativo falha, as configurações de DSN permanecem.

Eu não sei se posso deixar o DSN do sistema sem um nome de usuário e senha para um prompt, no entanto nos conectamos a quatro bancos de dados diferentes para que eu não queira que o usuário insira suas informações quatro vezes, o que frustraria o usuário .

Eu estava pensando que talvez eu pudesse usar o usuário DSN do sistema como uma leitura somente para uma tabela de usuários, ou talvez de preferência um procedimento que validasse o usuário, exceto que uma vez validado não tenho certeza de como eu iria conectar cada tabela subsequentemente. Posso armazenar uma variável global na cadeia de conexão ODBC?

Qual é a melhor maneira de tornar o MsAccess mais sensível ao usuário?

(Eu olhei para as configurações de segurança do MSACCESS, no entanto, parece que a Microsoft está desistindo disso e minha tentativa de estabelecê-lo bloqueia-me completamente e não apresenta qualquer forma de validação de login. Eu acho que ele usa apenas o login de widows como segurança, mas isso não é uma solução real) E há um aviso aqui:

Introdução à segurança do Access 2010 (escritório .microsoft.com)

Access and user-level security

Access does not support user-level security for databases that are created in the new file format (.accdb and .accde files). However, if you open a database from an earlier version of Access in Access 2010 and that database has user-level security applied, those settings will still function.

IMPORTANT Permissions created by using the user-level security feature do not protect your database from users who have malicious intent, and are not intended as a security barrier. It is appropriate to use this feature to improve the usability of a database for trusted users. To help keep your data secure, allow only trusted users to access your database file or associated user-level security files by using Windows file system permissions.

If you convert a database from an earlier version of Access with user-level security to the new file format, Access strips out all security settings automatically, and the rules for securing an .accdb or .accde file apply.

Finally, remember that all users can see all database objects at all times when you open databases that have the new file format.

    

Answer 1

Pelo que entendi, você deseja fornecer uma experiência / ambiente mais personalizada para seus usuários finais dentro do aplicativo ("usuários do aplicativo"), além de melhorar a segurança acoplando o processo de autenticação do usuário com as credenciais de conexão DSN OBDC ("usuário do banco de dados").

Esse ambiente de usuário personalizado é normalmente alcançado ao fazer com que seus usuários finais se autentiquem com seu aplicativo. Isso geralmente é feito com os usuários digitando um nome de usuário e senha (que normalmente é armazenado em uma tabela my_app_db.users ) quando o aplicativo é carregado.

Antes que esta autenticação de usuário do aplicativo possa acontecer, o próprio aplicativo (ou máquina) precisa estabelecer uma conexão com o servidor de banco de dados. Este "usuário do banco de dados" normalmente é obtido com:

1. Um usuário / senha de banco de dados estático e pré-definido que está codificado no aplicativo (e / ou script do instalador / binário). O script de instalação normalmente pedirá a você, o administrador do servidor, credenciais de banco de dados com (entre outros) as permissões CREATE e GRANT (normalmente o usuário raiz) para que o instalador possa criar o usuário do banco de dados necessário. li>
2. Um usuário do banco de dados definido pelo usuário que foi pré-criado com as permissões apropriadas; o instalador solicitará que você forneça essas credenciais, que o aplicativo armazenará usando seu próprio método de criptografia reversível (ou ofuscação) para manter essas credenciais em algum lugar no cliente (um arquivo .dat, uma chave de registro, etc.) uma maneira que pode ser lida antes que a conexão do banco de dados seja estabelecida.

Quanto à segurança, a Regra de Menor Privilégio é importante aqui: esse usuário do banco de dados deve receber a menor quantidade de privilégios necessários para que o aplicativo funcione corretamente (isto é, SELECT, INSERT, UPDATE e talvez DELETE, e apenas banco de dados do aplicativo, nunca o banco de dados do sistema / mestre (s)).

Isso em combinação com não armazenar credenciais de banco de dados em texto simples nas máquinas dos usuários finais pode ser uma maneira de proteger seu aplicativo do acesso não autorizado. Lembre-se de que, se um usuário mal-intencionado obtiver acesso de administrador local a uma máquina em que seu aplicativo foi instalado, o início do jogo será praticamente extenso: eles provavelmente removeriam essa cadeia de conexão da memória descriptografada ou até mesmo de niff tráfego MySQL na interface de rede para obter as credenciais do usuário do banco de dados e, nesse ponto, depende de quão restrito você fez esse usuário (bem, e esperamos que o MySQL esteja recebendo correções regularmente) e quão sofisticado e determinado é o atacante.

Tenha em mente que muitos aplicativos de banco de dados usarão um servidor de aplicativos, essencialmente um "watch watch" no meio que intermedia a conexão de / para o banco de dados em nome do cliente. Isso geralmente é feito por motivos de desempenho / escalabilidade, mas também há um benefício de segurança em que o servidor de banco de dados pode ser isolado / restrito apenas ao servidor de aplicativos e nenhum cliente de usuário final pode acessá-lo diretamente.

Quanto às opções ODBC DSN e MySQL, não sou muito versado no que está disponível. No entanto, parece haver suporte para autenticação nativa do Windows em versões posteriores do MySQL.

Já tive sucesso usando o conector MySQL / NET com certificados de segurança em conjunto com o MySQL e um aplicativo ASP.NET, mas não sei se isso se estende ao Microsoft Access; você provavelmente teria que escrever alguma cola .NET lá.

E quando / se chegar aos detalhes, provavelmente é melhor você perguntar em estouro de pilha nesse momento.

Espero que isso ajude.