Discussion :

[ADN75018]

Bonjour à tous

Nouveau venu dans le monde d'InterBase, je me pose des questions concernant la sécurité d'accès aux données de ce gestionnaire. En effet, j'ai cru comprendre que n'importe qui "récupérant" un fichier GDB pouvait accèder aux données (et à la structure de la BDD) à partir du moment où il dispose des droits d'admnistration sur une machine exécutant un serveur IB. Existe t'il des solutions ? Comment protéger ses données ?
Merci de vos infos/avis sur cette question.

[Barbibulle]

D'où sort tu cette information ??
et quel est la manipulation qui permettrait de le faire ?
Moi quand j'essaye de me connecter sur la base il me réclame un mot de passe et ce même si je suis sur le serveur et que j'ai les droits administrateurs windows...

[ADN75018]

Je m'explique....
Admettons que je t'envoie un fichier GDB où j'ai défini des utilisateurs avec des mots de passe, des privilèges, etc... Malgré cela, sachant que tu es administrateur Interbase sur ta machine, en recopiant le GDB en local et en te connectant en local avec ton SYSDBA, tu devrais pouvoir ouvrir ma base de données... sans connaître aucun des user/password que j'ai défini...
Ma question était donc de savoir si ceci est évitable ? En d'autres termes, comment gérer la sécurité ?

Merci d'avance !

[Barbibulle]

Oui je crois que tu as raison mais c'est à essayer....

Mais bon celà limite quand meme il faut connaitre le mot de passe du SYSDBA (tu peux le changer) mais il me semble qu'il est stocké dans la base ISC4.GDB.

Mais si tu créé une base comme ca :

Code :

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

CREATE DATABASE "mabase.gdb" USER "ADMINDB" PASSWORD "database";

qu'est ce que ca fait ? Il me semble que ADMINDB devient le propriétaire de la base mais je ne sais pas si SYSDBA a quand meme des droits dessus.

C'est un sujet interessant... A creuser

[ADN75018]

Tu n'as pas à connaitre MON password de SYSDBA, puisque tu vas te connecter avec le tien... et que tu le connais, à priori !
Concernant les droits du SYSDBA, voilà ce que j'ai trouvé : "The SYSDBA user always assumes total control over a database. SYSDBA is the superuser, there is no way to deny access from the SYSDBA user. The GRANT and REVOKE statements have no effect on the SYSDBA user."
Alors.... comment peut-on éviter de se faire "pirater" sa BDD? IB7 apporte t'il des améliorations à ce sujet ??

Merci d'avance

[Epictète]

Il n'y à aucun probleme de sécurité avec interbase, et d'ailleurs interbase est utilisé par l'armée américaine et différentes bourses et salles de marché et banques dans le monde.

Je t'invite à commencer par lire la doc sur ce sujet, que tu trouvera ici :

http://sgbd.developpez.com/cours/#interbase

[Barbibulle]

Ce que je vois dans la documentation ftp://212.73.230.16/borland/doc/inte...ide_FR_pdf.zip dans les pages 85 concerne la sécurité en effet et précise que SYSDBA a tous les droits et qu'il est préférable de changer son mot de passe dès l'installation terminée.

Mais il est marqué également que si l'on supprime le SYSDBA on ne peux plus ajouter et modifier la liste des utilisateur et qu'il faut réinstaller InterBase pour restaurer la base de données de sécurité isc4.gdb.

Ce qui appuit les dires d' ADN75018, une personne copiant une base de donnée pourra facilement accéder à sa structure en la copiant sur son poste en y installant Interbase (du coup le mot de passe de SYSDBA est masterkey).

Donc je dirais que une des solutions serait de proteger le fichier de la base (le .gdb).
Mais ce n'est pas toujours possible : exemple une personne ayant développé un logiciel qu'il commercialise. Il suffirait que la personne l'ayant acheté installe Interbase pour avoir accés aux sources (structures des tables, procédures stoquées) et n'a plus qu'à le plagier pour pouvoir le vendre à son tour (oui je sais il faut développé également la partie cliente mais bon l'analyse des données est une partie tres importante d'un développement qui mériterait de pouvoir être protégé...)

Donc voilà la question reste entière : quel est le moyen de proteger efficacement sa base en cas de copie du .gdb ?? S'il n'y a pas de moyen, pour la version 6 d'interbase, la Version 7 a t'elle palié à ce problème ?

[ADN75018]

Cher Epictète

Je te remercie de me confirmer ce que je savais déjà, à savoir que je connais peu ou pas InterBase. C'est même d'ailleurs pour cela que je consulte ce forum....
J'ai lu attentivement la documentation à laquelle tu fais référence, et notamment le chapitre 6 - Sécurité des Bases de Données. Les thèmes abordés sont certes intéressants, mais ils ne me semblent pas répondre à ma question.... il n'est en effet question que d'un fonctionnement C/S pour lequel InterBase me semble parfaitement sécurisé.
Ma question est de savoir comment empêcher quelqu'un ayant copié un fichier GDB sur son PC, de faire une connexion (Login / Local Engine) en tant que SYSDBA sur sa machine, et donc d'avoir accès à l'ensemble de la BDD. Pour moi, ce n'est pas un gros délire sans intérêt que d'essayer de comprendre comment protéger ses informations...

Merci d'avance

[Epictète]

Cher Epictète

Ma question est de savoir comment empêcher quelqu'un ayant copié un fichier GDB sur son PC, de faire une connexion (Login / Local Engine) en tant que SYSDBA sur sa machine, et donc d'avoir accès à l'ensemble de la BDD.

S'il n'est pas le sysdba, avec le nouveau password, et qu'il n'à pas les droits il ne peux pas accèder au gdb.

[Epictète]

Ce qui appuit les dires d' ADN75018, une personne copiant une base de donnée pourra facilement accéder à sa structure en la copiant sur son poste en y installant Interbase (du coup le mot de passe de SYSDBA est masterkey).

Pas du tout. si tu reprends un gdb, c'est un autre sysdba, celui qui à été défini.

[ADN75018]

Ca, je l'avais bien compris. Je doit mal m'exprimer, je vais essayer d'illustrer mon propos.
Admettons que je récupère (peu importe ici le moyen) le fichier PAYE.GDB de mon entreprise (qui est super-protégé par un DBA hyper compétent, et tout, et tout). Le soir, chez moi, je recopie ce fichier sur ma machine où je suis bien sûr administrateur IB (c'est ma machine, j'ai mon compte SYSDBA, etc...). Et bien là, je peux me connecter sur le GDB et voir combien touche mon patron, non ????
C'est cela que je voudrais éviter !

[Barbibulle]

Je crois que tu n'as pas compris le problème soulevé par ADN75018.

Le password et la liste des users n'est pas dans le .gdb mais dans le isc4.gdb du poste... Donc toi sur ton serveur tu peux bien mettre le password que tu veux pour le SYSDBA si quelqu'un copie le fichier Mabase.Gdb pour la mettre chez lui. et installe interbase (donc nouveau fichier isc4.gdb avec un mot de passe pour le SYSDBA égale à masterkey)

Voilà le travail.

[Epictète]

Le password et la liste des users n'est pas dans le .gdb mais dans le isc4.gdb du poste... Donc toi sur ton serveur tu peux bien mettre le password que tu veux pour le SYSDBA si quelqu'un copie le fichier Mabase.Gdb pour la mettre chez lui. et installe interbase (donc nouveau fichier isc4.gdb avec un mot de passe pour le SYSDBA égale à masterkey)

Voilà le travail.

Ca marchera pas parce qu'il vérifie. Il faut que cela soit cohérent.

[ADN75018]

Si je me suis permis d'évoquer ce problème c'est parce que j'ai justement fait cette manip et qu'elle a très bien marchée.... Alors, il y a certainement une configuration/propriété du fichier GDB qui permet d'éviter cela, je n'en doute pas. Ce que j'aimerais connaître, c'est ce qu'il faut faire pour l'éviter...
Merci d'avance

[Epictète]

Si tu fait cela tu peux voir les metadata mais pas les datas normalement.
pour protéger les metadata voila le tip :

start ibconsole, log in as sysdba and create a new user,
let's say 'test', password 'xxx'.

Leave ibConsole, start ibconsole again and log in as test / xxx
(the new user you created)

Then create your database (so TEST is the owner!) and open it
now do this sql-command:
"insert into rdb$roles values ( 'SYSDBA', 'TEST' )
... now sysdba is a role for your database and not longer a user.
so if you try to connect to your db using sysdba you will fail!
(can only be removed from TEST by "drop role ..".)

Un autre :

Security is a slippery slope, one where you have to balance return on
investment with paranoia.

Many developers will design a database system, implement it, then try to
secure it. I will begin by saying that this is the most flawed approach you
can have. When you design a system with security in mind, you approach every
step in the process differently.

So, the first question is, how do I begin ?

Well, connect to your database server as SYSDBA and create a new user
'DEVELOPER' (you can use your own name but for example purposes, developer
will be fine).

Now, connect to the isc4.gdb file with ISQL or some other interactive tool
and grant full security access to 'DEVELOPER'.

Now, disconnect from the server and reconnect as 'DEVELOPER'.
From this point on, never, ever, ever, connect as SYSDBA unless you absolutly
have to.

Next step, as DEVELOPER, create your database and create three roles

IB_DESIGNER
IB_BACKUP
IB_OPERATOR

Now, create a table we will refer to as 'IB_USERS' although the name you use
will not be that.
We also need two other tables refered to as 'IB_GROUPS' and 'IB_RIGHTS'
respectively.
Together, these three tables will be the backbone for your security system,
they are beginning of a secure database.

Now, create a series of custom exceptions
for example
'CONNECTION FROM UNAUTHORISED PC'
'CONNECTION FROM UNAUTHORISED CLIENT'
'CONNECTION OUTSIDE OF AUTHORISED HOURS'
etc
You can create as many as you can think of.

The concept being, when someone does somthing against the security rules you
setup, an exception is raised, and the current work gets rolled back,
regardless of the client being used. You can get away with a single
exception, but, when it comes down to support and debugging issues, the more
differentiation, the better.

Ok, you have some tables, some exceptions, some roles, what now?

Well, now you need to make sure that only proper users can modify the
database. This includes SYSDBA. You see, once you create a GDB, and you add
a user to the system, that user, who may or may not have any rights to any of
your system tables, that user can create thier own procedures and tables
etc., that can cause problems with your nicely laid out system.

We start this process by creating a stored procedure that for reference, we
will call PRC$SEC_PERMCHECK() and we pass it a unique number that identifies
the item and action we are now doing, more on this later.
PRC$SEC_PERMCHECK() is called by triggers placed on every table in the
database, including system tables. Each of these triggers is given a unique
number that is sent to the procedure when it is called. The stored procedure
can get the current time and current user from the global variables that IB
provides. By cross referencing the user and the unique trigger identifier in
the security tables, you can find out whether you should raise an exception
or not. So, after creating a trigger on the system tables, that calls this
procedure, if any user, including SYSDBA, attempts to create, modify or
delete, any metadata, an exception will be raised, unless that user is
specifically put into the security tables.

But, how do we prevent SYSDBA from reading all of our private
procedure/trigger language source code? We update the system tables,
replacing the source code (not the BLR code) with a blob the only containes
three spaces. The reason we use three spaces instead of a null is because of
a known bug that sometimes will cause a trigger to fire twice if the source
is deleted.

Ok, we have now set it up so that SYSDBA cannot modify the tables, but we
want to make sure they can not even connect, so we create a role called
SYSDBA by directly inserting values into the system tables.

Sysdba now can not even connect to our database. Users who can extract
metadata cannot see the source of the triggers/procedures.

Ok, but how do you prevent a authorised user from connecting to the database
using some tool other than the programs you are providing?

First you never give your users thier real login names or passwords.

Your program goes through a series of steps when loging onto the database.

It prompts the user for a username and password.
It connects to the database as the 'SEC_LOGIN' user.
The SEC_LOGIN user only has the right to run the 'PRC$SEC_LOGINIB_USERS()'
procedure.
The PRC$SEC_LOGIN() procedure is passed the ip_address of the calling
machine, the user supplied username and the user supplied password.
It then looks up the appropriate information from the IB_USERS table and
calls a UDF that adds a new user to the system with a random user name and
password. The stored procedure grants the appropriate rights to the newly
created user via directly inserting values into the system tables.
The stored procedure then returns to the calling application the real
(random) user name and password, as well as the role for the user to use.

This means that every time the user logs in, they are logging in via a
different user name and password. This means that all triggers and
procedures that rely upon the USER variable, will need to resolve the real
user name from the random name that is returned.
The PRC$SEC_PERMCHECK() that is called for every insert/update/delete checks
to see if the login time has expired for the user and calls a UDF that cleans
up the isc4.gdb and removes the random name from the database (and any other
random users who have not logged out properly).

As each user gets a unique name, even if they think they are logging in with
the same login name. This gives you a unique identifier for this login and
helps with logging and replication.

Since the users inside the system are constantly changing, no other
application except for yours will know how to connect to your database.

You can move the GDB around from machine to machine and still be assured some
security.

On top of the above security measures, you do not give your tables intuitive
names, nor do you make your stored procedures, thier names or thier
parameters should always be kept secret. Any knowledge of your database
structure is a direct tool for cracking your security.

This is a beginning 10000' overview on securing your database.

I am sure I have prompted more questions than I have given answers, so feel
free to ask.

Voir aussi :
http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm

Mais pour finir c'est pas spécialement un probleme lié à interbase, tu aura des problemes similaires globalement avec tous les sgbd que tu veux utiliser en stand alone.

En client/Serveur pas de probleme, c'est vrai qu'il y à une différence entre les 2 utilisations.

Pour finir refaites le test avec la version d'éval InterBase 7, je me demande ce que borland veux dire avec metadata sécurité, si c'est pas ce sujet justement.

Voir sur InterBase 7 :
http://www.borland.com/interbase/pdf/ib7_feaben.pdf


PS : pour ceux qui se servent de la version <= 6.01 open source, ne pas oublier le patch sécurité : http://info.borland.com/devsupport/interbase/security_patches.html
Ce patch n'est pas nécessaire pour les versions Borland certifiées 6.5 et 7

[ADN75018]

Je te remercie pour ces conseils éclairés.

[Barbibulle]

Et en effet j'ai lu que une des améliorations de la version 7 concernait la protection des méta-data.... Ce qui veux bien dire qu'il y a un problème avec la version 6.01 open source...

[Epictète]

Je te signale que la question initiale ne précise pas la version d'interbase, open source ou certifiée.

Je ne te donne pas tord , mais je trouve qu'il y à une énorme différence entre :

- sujet initial : "sécurité et interbase" (probleme pas clair, version interbase pas précisé)

et le

- nouveau sujet édité :"protéger (la lecture) les métatada dans le cas d'une utilisation mono poste (et avec interbase open source 6).

C'est quand meme pas tout à fait le meme sujet, c'est plus spécialisé disons....

Donc on en revien aux regles du forum :
http://www.developpez.net/forums/viewtopic.php?t=334

C'est plus efficace de donner le max de précisions dès le départ dans la question inituale, et au minimum la version d'interbase utilisée. ...

[Barbibulle]

Je te l'accorde... ceci dit ce n'est pas mon sujet....
et j'ai fait la même erreur que toi c'est a dire de ne pas demander la version d'interbase qu'il utilise... et j'ai supposé qu'il parlait de la même version que la mienne.... (Que j'ai précisé dans mes messages puisque je parle d'interbase 6 et demande si la version 7 résoud ce problème....)

[ADN75018]

Je ne sais pas d'où il sort que j'utilise IB OpenSource??? En l'occurence le "problème" évoqué a été reproduit sur IB version 5.5 et 6.5.
De plus, je confirme que les metadata ET les données sont accessibles selon la manip évoquée....
Et pour répondre à Epictète qui dit

Code :

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

tu aura des problemes similaires globalement avec tous les sgbd que tu veux utiliser en stand alone

,je ne pense pas qu'il existe de problème similaire avec MySQL par exemple (attention : je ne compare pas..... c'est juste pour l'exemple !)
Sinon, et pour info, la manip avec le "insert into rdb$roles values ( 'SYSDBA', 'TEST' )' à l'air de bien résoudre le problème.
Donc merci pour les infos