Discussion :

[looping]

bonjour,

Suite à la réalisation en interne d'une gestion commerciale spécifique à notre sociéte, mon employeur me demande de sécuriser mon logiciel.
Le logiciel est connecté à une base Firebird.

Sa reflexion de départ est la suivante: si un employé emporte l'executable chez lui , il ne doit pas pouvoir s'en servir.

La première idée qui me vient est la suivante: comme nous sommes sur un domaine, je peux l'identifier au lancement du logiciel.

Avez vous d'autre piste ? Clé logiciel ? Blocage sur racine d'adresse IP ?

Je précise que les employés ne sont pas des crack en informatique, donc pas besoin de faire des protections trop complexes. Déja si la client Firebird n'est pas installé sur le poste, le logiciel plantera dès le départ.


Merci

[ShaiLeTroll]

Suite à la réalisation en interne d'une gestion commerciale spécifique à notre sociéte, mon employeur me demande de sécuriser mon logiciel.

Le logiciel est connecté à une base Firebird.

Sur un Serveur de TA Société ?
Un Serveur accessible depuis les locaux mais probablement pas depuis l'extérieur ! non ?

Sa reflexion de départ est la suivante: si un employé emporte l'executable chez lui , il ne doit pas pouvoir s'en servir.

Il faudrait qu'il soit assez doué pour prendre aussi les dépendances comme les DLL, les BPL, mettre ce qu'il faut dans des Ini, la Base de Registre ...

La première idée qui me vient est la suivante: comme nous sommes sur un domaine, je peux l'identifier au lancement du logiciel.

Sur un domaine ?
un employé chez lui peut-il avoir accès au domaine ?
Vous avez monté prévu du VPN pour du télétravail ?
Sinon je vois pas comment quelqu'un pourrait avoir accès au serveur de base de données !
Pense au LDAP de ton ActiveDirectory, tu peux utiliser le même login\pw que celui pour le LDAP
Dans le LDAP, tu peux associer à chaque personne, un user de ta DB :
- soit un user pour chaque, pénible à gérer
- soit un user pour un groupe, permet de limiter les risques de DELETE\UPDATE sur les tables sensibles

Souvent, on a juste un user général pour l'application, toutes les instances utilisant le même, où je suis c'est le choix qui a été fait, c'est beaucoup plus simple mais nul en sécurité

Et c'est une table de la DB qui contient les login\pw et le niveau d'habilitation, un grand classique

Avez vous d'autre piste ? Clé logiciel ? Blocage sur racine d'adresse IP ?

FireBird, je ne connais pas

Je peux te faire un parallèle avec ce que je connais sur MySQL
Mais MySQL on peut limité par user une plage d'IP, par exemple, root uniquement accessible en localhost ou depuis un terminal réservé à un admin

On en revient à la gestion des users ... Application avec Firebird : méthode de connexion ?

On peut renforcer la sécurité avec
- SSL : Using SSL for Secure Connections
- SSH : Connexion à MySQL à distance avec Windows et SSH

Voir ce que propose FireBird à ce sujet :
How to protect the connection over insecure networks ... - Firebird FAQ

Firebird doesn't have anything built in for that. There is a discussion of possibility to use SSL, and perhaps it will be implemented in some future version. In the meantime, you can use some generic tunneling software like SSH, SSL or ZeBeDee.

Je précise que les employés ne sont pas des crack en informatique, donc pas besoin de faire des protections trop complexes. Déja si la client Firebird n'est pas installé sur le poste, le logiciel plantera dès le départ.

C'est ce que je disais !
Même si le client était installé, faudrait un acces sur le serveur, je doute que ton SGBD soit accessible depuis l'extérieur du réseau d'entreprise sauf dans deux cas :
- Tunnel SSH pour VPN
- un adminstrateur réseau incompétent

[SergioMaster]

C'est l'exe qu'il faut sécuriser ou la BDD ? je n'ai pas compris parce que un exe seul n'ayant pas accès a à la BDD ne servira a rien !

[looping]

Bonjour,

C'est l'exe que je veux securiser.
Mais comme vous l'indiquez, un exe sans base ne sert à rien donc ca va limiter le problème.
De plus j'ai concu ma base comme vous le préconiser: la base User/Pass est séparé de la base principale.

Pour compléter, je vais donc ajouter un filtrage sur le nom de domaine et sur la plage d'adresse IP au cas ou un petit stagiaire calé en informatique viendrait copier la base.

Merci pour vos réponses

[Ph. B.]

Bonjour,

C'est l'exe que je veux securiser.

Personnellement, ce seraient les données que je m'attacherais à protéger si j'étais à votre place et/ou à celle de votre employeur, si tant est que votre exécutable soit doté d'une interface ou de fonctionnalités exceptionnelles...

Mais comme vous l'indiquez, un exe sans base ne sert à rien donc ca va limiter le problème.

Par contre une base même sans exécutable conserve sa valeur, surtout si elle touche à la gestion commerciale de votre entreprise !

Pour compléter, je vais donc ajouter un filtrage sur le nom de domaine et sur la plage d'adresse IP au cas ou un petit stagiaire calé en informatique viendrait copier la base.

Ce qui est, je me permets d'insister, futile !

Attachez vous plutôt à protéger votre base sur votre serveur (fichier seulement accessible par "l'utilisateur" qui fait tourner le SGBD, "l'utilisateur" chargé des sauvegardes et l'administrateur. Et que l'accès à ces utilisateurs ne soit pas ouvert à tous les vents !
Tant que n'importe quel quidam peut accéder au fichier de base de données, il y a faille...

[SergioMaster]

Bonjour,
C'est un des points a déplorer avec Firebird : le non cryptage des données . Quoique avec un peu d'acharnement une bonne dose de patience et une bonne qualification C il est toujours possible de prendre les sources de Firebird et en faire une version "personnelle" comme cela est expliqué dans certaines discussions/papiers sur le site de Firebirdsql.org (désolé pas de lien, j'ai lu cela il y a déjà longtemps, je ne fais que régurgiter ce qu'il me reste de ces lectures).

[Edit] après avoir poster ces réflexions je me suis souvenu d'une traduction de FAQ Firebird que j'avais faite et qui n'a peut être jamais été mise dans ces dernières . heureusement je l'avais cité in extenso dans un post

Pour complètement faire le tour du sujet , j'ajouterais quelques lectures sur ZEBEEDEE en ce qui concerne le VPN et l'approche multi-tiers (datasnap) cependant nulle protection ne sera parfaite contre les "pays au comportement voyou" (je suis sur que vous savez a quels pays je cite et pense) C'est fou ce qu'un simple petit serveur ftp peut subir comme attaque (je parle d'expérience) à croire qu'ils n'ont que ça a faire ! noyons les dans des mégatonnes de données inutiles

[Gilbert Geyer]

Bonjour,

Ph. B. : Tant que n'importe quel quidam peut accéder au fichier de base de données, il y a faille...

Pour compléter la sécurisation il y a aussi la possibilité d'inclure dans le code de l'exe et plus exactement dans le FormCreate de l'unité principale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
procedure TFormMain.FormCreate(Sender: TObject);
begin
 if not FileExists('F:\Doss1\Doss2\Doss3\...\FichierVerrou.dat')
  then Application.Terminate;
end;

dans cet exemple 'F:\Doss1\Doss2\Doss3\...\FichierVerrou.dat' désigne un fichier quelconque stocké en permanence dans un sous-répertoire du labyrinthe de l'ordinateur central de l'entreprise.
Donc même si un quidam copie l'exe et la base de données utilisée par l'exe il y a peu de chances que sur son ordi perso il ait également le même chemin d'accès au fichier 'FichierVerrou.dat' ... sauf cas fort improbable que le quidam reproduise chez lui la copie intégrale du contenu de l'ordi central de l'entreprise.
(on peut être encore plus radical en remplaçant Application.Terminate par DeleteFile(Application.ExeName) ... à voir)

A+.

[Ph. B.]

Bonjour,

...dans cet exemple 'F:\Doss1\Doss2\Doss3\...\FichierVerrou.dat' désigne un fichier quelconque stocké en permanence dans un sous-répertoire du labyrinthe de l'ordinateur central de l'entreprise.
Donc même si un quidam copie l'exe et la base de données utilisée par l'exe il y a peu de chances que sur son ordi perso il ait également le même chemin d'accès au fichier 'FichierVerrou.dat' ... sauf cas fort improbable que le quidam reproduise chez lui la copie intégrale du contenu de l'ordi central de l'entreprise.
(on peut être encore plus radical en remplaçant Application.Terminate par DeleteFile(Application.ExeName) ... à voir)

Et bien moi, je prends mon éditeur hexadécimal et je remplace 'F:\Doss1\Doss2\Doss3\...\FichierVerrou.dat' par 'C:\Autoexec.bat' par exemple, et le tour est joué ! plus de verrou !

[Gilbert Geyer]

Re-bonjour,

Ph. B. : Et bien moi, je prends mon éditeur hexadécimal et je remplace 'F:\Doss1\Doss2\Doss3\...\FichierVerrou.dat' par 'C:\Autoexec.bat' par exemple, et le tour est joué ! plus de verrou !

Oui sauf qu'à coté de Ph. B. il est marqué Expert Confirmé
... alors que dans l'introduction de cette discussion il est dit :

Je précise que les employés ne sont pas des crack en informatique, donc pas besoin de faire des protections trop complexes.

A+.

[SergioMaster]

soyons fous , ajoutons un Alternate Data Stream au fichier .dat
cela ne changera pas le fond du problème

[Ph. B.]

Oui sauf qu'à coté de Ph. B. il est marqué Expert Confirmé
... alors que dans l'introduction de cette discussion il est dit :

Je précise que les employés ne sont pas des crack en informatique, donc pas besoin de faire des protections trop complexes.

C'est sous estimer les employés qui ne manqueront pas de faire appel à plus expérimentés qu'eux...