Discussion :

[devEric69]

Bonjour,

Je voudrais sécuriser une base de données Firebird 3, à minima. L'application est mono-utilisateur en mode embarqué. Basiquement, je souaiterais créer un utilisateur - mettons login="user_admin" - dans la base, lui attribuer tous les droits \ rôle de RDB$ADMIN, et faire en sorte que cette base ne soit pas \ plus ouvrable en dehors de cet utilisateur nommé "user_admin". Dit autrement, je souhaiterais créer un simple couple login+password, qui soit le seul à pouvoir ensuite se connecter, faire du CRUD, et également faire de la DDL à l'exécution i.e. faire évoluer la base de version en version, ou en conception depuis le gestionnaire FlameRobin ou redExpert.

Pragmatiquement, je pensais faire tout ce que je viens de dire dans cette base, à la lettre, avec le compte SYSDBA. Puis au final, révoquer SYSDBA de ladite base par "user_admin".

Est-ce que cela tient la route, ou est-ce que je passe à côté de quelque chose ?

Cordialement.

[SergioMaster]

Bonjour,

hum, question intéressante.
Sous FB 2.5 le moteur embarqué se fichait comme d'un guigne du couple utilisateur/mot de passe je ne sais ce qu'il en est pour FB3.
Etant donné :
- que la partie sécurité peut être incluse dans une bdd FB3
- que le moteur d'une base embarquée est le même que sur un serveur
la donne a, peut-être, changée.

Peut-être des informations dans ce papier d'Helen Borrie
en tout cas j'en tire quelques citations

embedded connection does not authenticate, so a user name and password are not required. ...
Although no authentication is required, we still might need to log in explicitly as SYSDBA or another user with non-public privileges. In that case, we need to supply the user name. The password is not required, since authentication still does not apply. The user name will be associated with privileges and mappings in the specified database.

Je vais suivre ça.

[devEric69]

J'ai butiné sur le web, lu des documentations concernant l’attribution des privilèges en rôles (merci @SergioMaster), et relu des papiers et échanges du groupe de mails Firebird: la seule sécurité réelle possible actuellement, en Firebird embarqué a.k.a embedded, est de coder \ crypter dans l'application (Lazarus me concernant) avec un XOR par licence d'application utilisateur, dans OnSetTest (sauvegarde cryptée dans le *.fdb), et son décryptage inverse dans l'événement OnGetText. C'est le seul moyen de sécuriser à minima, de protéger les données d'un utilisateur (au jour d'aujourd'hui). Un autre intervenant sur developpez.net (au moins) est d'ailleurs déjà arrivé à cette conclusion avant moi.

ps 1: sur le site de Firebird, il est proposé de monter la base dans TrueCrypt ou dans quelque chose d'équivalent. C'est surprenant comme piste de sécurité, et illusoire. Clairement, une fois la partition TrueCrypt décryptée et montée, son accès est en clair - c'est le cas de le dire - comme n'importe quel fichier et donc l'export de ses données possible.
ps 2: les développeurs de Firebird embedded ne veulent pas créer un algorithme de gestion de mot de passe pour la version embedded, et "releaser" de tels binaires, car c'est une base Open Source: il suffit en effet de recompiler soi-même un serveur dit embedded en supprimant toute la précédente couche de vérification dudit mot de passe, pour que le tour soit joué, c'est à dire pour "craquer" \ hacker une base appartenant à quelqu'un d'autre.
A titre d'exemple inverse, c'est parce qu'un gestionnaire de bases tel que Microsoft Access est écrit avec du code propriétaire, que sa base peut être protégée algorithmiquement par un mot de passe. Là, seule l'utilisation sagace d'un éditeur hexadécimal pour "{z}jump"-per les vérifications, peut être utile à un supposé hackeur \ pirate.