Firebird 3.0 : problème avec un compte administrateur (Flamerobin)

Version imprimable

Voir 40 message(s) de cette discussion en une page

Salut Artemus24,

Citation:

Envoyé par Artemus24

As-tu bien mis la déclarative dans le fichier "databases.conf" ? A priori, je pense que oui !

J'avais oublié de te répondre mais oui effectivement c'est bien configuré.

Citation:

Envoyé par Artemus24

P.S.: tu ne m'as pas donné le résultat du script que je t'ai donné ?

Oui effectivement mais comme il s'est mis à fonctionner de nouveau je l'ai pas fait. Du coup je viens de prendre le temps de te le faire :

La version en se connectant sans le role rdb$admin :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
Database: 'C:\Test.fdb', User: ADMINISTRATEUR
SQL> show users;
Users in the database
  2 #ADMINISTRATEUR
SQL>
SQL> show database;
Database: C:\Test.fdb
        Owner: ADMINISTRATEUR
PAGE_SIZE 8192
Number of DB pages allocated = 216
Number of DB pages used = 199
Number of DB pages free = 17
Sweep interval = 20000
Forced Writes are ON
Transaction - oldest = 6
Transaction - oldest active = 181
Transaction - oldest snapshot = 181
Transaction - Next = 187
ODS = 12.0
Database not encrypted
Default Character set: NONE
SQL>
SQL> show tables;
       PLG$SRP
SQL>
SQL> select distinct PLG$USER_NAME from PLG$SRP;
 
PLG$USER_NAME
===============================
TEST
 
SQL> commit;
SQL>
SQL> connect 'C:\Program Files\Firebird\Firebird_3_0\Security3.fdb' user 'sysdba' password 'masterkey';
Database: 'C:\Program Files\Firebird\Firebird_3_0\Security3.fdb', User: SYSDBA
SQL>
SQL> show database;
Database: C:\Program Files\Firebird\Firebird_3_0\Security3.fdb
        Owner: ADMINISTRATOR
PAGE_SIZE 8192
Number of DB pages allocated = 224
Number of DB pages used = 202
Number of DB pages free = 22
Sweep interval = 20000
Forced Writes are ON
Transaction - oldest = 41
Transaction - oldest active = 3810
Transaction - oldest snapshot = 3810
Transaction - Next = 3814
ODS = 12.0
Database not encrypted
Default Character set: NONE
Linger: 60 seconds
SQL>
SQL> show tables;
       PLG$SRP                                PLG$USERS
 
SQL>
SQL> select distinct PLG$USER_NAME from PLG$USERS;
 
PLG$USER_NAME
===============================
SYSDBA
 
SQL> select distinct PLG$USER_NAME from PLG$SRP;
 
PLG$USER_NAME
===============================
SYSDBA
 
SQL>
SQL> exit;

La version en se connectant avec le role rdb$admin :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
Database: 'C:\Test.fdb', User: ADMINISTRATEUR, Role: RDB$ADMIN
SQL> show users;
Users in the database
  2 #ADMINISTRATEUR                      0  TEST
SQL>
SQL> show database;
Database: C:\Test.fdb
        Owner: ADMINISTRATEUR
PAGE_SIZE 8192
Number of DB pages allocated = 216
Number of DB pages used = 199
Number of DB pages free = 17
Sweep interval = 20000
Forced Writes are ON
Transaction - oldest = 6
Transaction - oldest active = 189
Transaction - oldest snapshot = 189
Transaction - Next = 195
ODS = 12.0
Database not encrypted
Default Character set: NONE
SQL>
SQL> show tables;
       PLG$SRP
SQL>
SQL> select distinct PLG$USER_NAME from PLG$SRP;
 
PLG$USER_NAME
===============================
TEST
 
SQL> commit;
SQL>
SQL> connect 'C:\Program Files\Firebird\Firebird_3_0\Security3.fdb' user 'sysdba' password 'masterkey';
Database: 'C:\Program Files\Firebird\Firebird_3_0\Security3.fdb', User: SYSDBA
SQL>
SQL> show database;
Database: C:\Program Files\Firebird\Firebird_3_0\Security3.fdb
        Owner: ADMINISTRATOR
PAGE_SIZE 8192
Number of DB pages allocated = 224
Number of DB pages used = 202
Number of DB pages free = 22
Sweep interval = 20000
Forced Writes are ON
Transaction - oldest = 41
Transaction - oldest active = 3816
Transaction - oldest snapshot = 3816
Transaction - Next = 3820
ODS = 12.0
Database not encrypted
Default Character set: NONE
Linger: 60 seconds
SQL>
SQL> show tables;
       PLG$SRP                                PLG$USERS
 
SQL>
SQL> select distinct PLG$USER_NAME from PLG$USERS;
 
PLG$USER_NAME
===============================
SYSDBA
 
SQL> select distinct PLG$USER_NAME from PLG$SRP;
 
PLG$USER_NAME
===============================
SYSDBA
 
SQL>
SQL> exit;

Citation:

Envoyé par Artemus24

isql -charset win1252 -echo -input 7.Test.sql -quiet -nodbtriggers -password 'sysdba' -role 'rdb$admin' -user 'masterkey' first

Je vois que tu te sers d'un certain nombre de paramètres mais je ne procède pas de la même manière. Pourrais-tu avoir la gentillesse de le tester en 2 fois comme moi ?

Code:

1
2
3
4
5
6
7
8
9
D'abord j'ouvre une invite de commande dos et je me place dans le dossier qui contient isql et je le lance :
C:\Program Files\Firebird\Firebird_3_0>isql -nodbtriggers
 
Ensuite dans la même fenêtre je lance la connexion depuis isql directement :
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect 'C:\Test.fdb' user Administrateur password 'monpassword';
Database: 'C:\Test.fdb', User: ADMINISTRATEUR
SQL>alter trigger autorisation inactive;
SQL>

Voci le résultat avec / sans le paramètre "-nodbtriggers" :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
C:\Program Files\Firebird\Firebird_3_0>isql
 
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect 'C:\Test.fdb' user Administrateur password 'monpassword';
Statement failed, SQLSTATE = 42000
exception 1
-INTERDIT
-Accès interdit à la base de données !
-At trigger 'AUTORISATION' line: 6, col: 25
 
SQL> quit;
 
C:\Program Files\Firebird\Firebird_3_0>isql -nodbtriggers
 
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect 'C:\Test.fdb' user Administrateur password 'monpassword';
Database: 'C:\Test.fdb', User: ADMINISTRATEUR
SQL>alter trigger autorisation inactive;
SQL>

PS : j'ai oublié de préciser que j'ai aussi fait le test du "-nodbtriggers" avec une connexion en utilisant sysdba / masterkey et que j'y arrive de la même manière.
PS2 : J'utilise la commande "alter trigger autorisation inactive;" pour tester que ça fonctionne mais il est évident que je l'ai remis en fonction en faisant un "alter trigger autorisation active;" à chaque fois que c'était nécessaire.

Merci pour l'aide et les différents tests.
Bonne soirée et à plus tard,

12/07/2016, 23h59
Artemus24
Salut DelphiCode.

Citation:

Envoyé par DelphiCode

Oui effectivement mais comme il s'est mis à fonctionner de nouveau je l'ai pas fait. Du coup je viens de prendre le temps de te le faire :

Je te remercie d'avoir pris le temps de faire le test.
Dans le fichier "security3.fdb" tu as seulement le compte "sysdba". Et dans ta base de données, tu as les comptes "administrateur" et "test".
Je voulais être certain de tes comptes et c'est le cas. Donc je ne comprends pas comment as-tu pu obtenir le compte "sysdba" dans la base puisqu'il n'y est pas.

J'ai refais le test précédent.
Mon erreur est que j'ai inversé le nom du user avec le mot de passe dans la ligne isql.
J'ai corrigé mon exemple ainsi que les commentaires à ce sujet.

J'ai, en effet, pu désactivé le déclencheur et cela pose un grave problème de sécurité.
Je suis passé par le compte "sysdba" comme il est indiqué dans le message ci-dessous :
Code:

1 2 Statement failed, SQLSTATE = 28000 Unable to perform operation. You must be either SYSDBA or owner of the database
Le déclencheur peut être désactivé uniquement par le compte "sysdba".
Je ne parle pas ici du compte créateur/propriétaire car en principe le pirate ne connait ni le nom de ce compte et encore moins le mot de passe.
A moins d'avoir une mémoire de poisson rouge et d'avoir collé un post-it sous le clavier avec le nom et de le mot du compte créteur/propriétaire.

Comment empêcher ce compte d'accéder à la base ?
En fait, le compte "sysdba" est un cas particulier qui peut se résoudre en mettant dans la déclarative des privilèges ceci :

Code:

create role sysdba

Cela provoque une erreur d'accès, autre que celle du déclencheur !

Et quand est-il des autres comptes administrateur ?
Ce n'est pas parce que le compte est déclaré dans le fichier "security3.fdb" qu'il est automatiquement administrateur.
Je ne parle pas du "sysdba" mais de tout autre compte ! Dans mon exemple, ce compte se nomme "administrator".

La question est la suivante.
Je n'ai pas accès à la base de données et je veux mettre le compte "administrator" en tant qu'administrateur.
pour ce faire, je dois taper ceci : "grant rdb$admin to administrator".

Comment puis-je faire ?
Vu que je ne peux pas accéder à la base par le compte "sysdba" et vu que j'ignore le compte créateur / propriétaire, je suis dans l'incapacité de modifier la sécurité de la base de données.
A moins d'avoir une autre astuce pour palier à ce problème, je pense qu'il est impossible de faire cette manipulation.

Récapitulation :
1) faire en sorte de fusionner la base de sécurités avec la base de données ==> voire databases.conf
2) créer la base de données avec un compte qui n'existe pas (autre que sysdba, bien sûr).
3) créer les comptes qui auront accès à la base de données
4) créer un déclencheur afin de restreindre les accès uniquement aux comptes du §3).
5) donner à chaque compte les privilèges d'accès (grant and role).
6) mettre "create role sysdba" pour empêcher l'accès du compte "sysdba".
7) utiliser la sécurité du système d'exploitation (Windows ou Linux) afin d'interdire les accès direct au fichier physique de la base de données.
8) toutes les manipulations sur cette base de données devront se faire par l'intermédiaire du serveur FireBird.

@+
13/07/2016, 12h02
DelphiCode

Bonjour à tous,

C'est bien ce que je pensais Artemus24, même avec la version 3 il n'y a pas encore de solution vraiment propre et efficace pour protéger sa base de données de la copie du fichier fdb sur un autre ordinateur avec une installation fraîche de Firebird.

Citation:

Envoyé par Artemus24

Récapitulation :
1) faire en sorte de fusionner la base de sécurités avec la base de données ==> voire databases.conf
2) créer la base de données avec un compte qui n'existe pas (autre que sysdba, bien sûr).
3) créer les comptes qui auront accès à la base de données
4) créer un déclencheur afin de restreindre les accès uniquement aux comptes du §3).
5) donner à chaque compte les privilèges d'accès (grant and role).
6) mettre "create role sysdba" pour empêcher l'accès du compte "sysdba".
7) utiliser la sécurité du système d'exploitation (Windows ou Linux) afin d'interdire les accès direct au fichier physique de la base de données.
8) toutes les manipulations sur cette base de données devront se faire par l'intermédiaire du serveur FireBird.

Dans mon cas le point 7 c'est mort !

En ce qui concerne le point 6, si nous nous référons au post #5 de makowski, dont voici un extrait :

Citation:

Envoyé par makowski

cela n'a pas de sens avec Firebird 3, puisque que tu peux maintenant créer les utilisateurs dans la base.
créer une role SYSDBA a toujours été un mauvais hack inutile et inefficace et avec Firebird 3. complétement inutile.

Il n'a pas l'air de penser que c'est une bonne idée mais faute de mieux pour le moment je m'en contenterais. J'attire ton attention Artemus24 sur le fait que si tu crées une base de données vierge "classique" (uniquement avec la gestion security3.fdb) tu ne peux pas créer le rôle sysdba (j'ai essayé mais tu obtiens un message d'erreur te disant que c'est interdit de le faire). Je suppose donc que le fait d'avoir fusionné les 2 bases de données (sécurité + travail) en une seule et qu'il n'y ait pas sysdba dedans permet donc de créer le role sysdba.

Donc pour résumer, avec cette dernière astuce et votre aide, j'ai réussi à reproduire le même niveau de protection qu'avec Firebird 2.5.4 même s'il est loin d'être parfait.

Je tiens à tous vous remercier de m'avoir aidé et particulièrement Artemus24 pour n'avoir jamais lâché le morceau et réaliser mes tests à la demande. Ce grand topic m'aura au moins permis de mieux appréhender le côté sécurité de cette version 3.

Je me doute c'est un gros travail de développement, mais j'espère que pour la prochaine grosse mise à jour de Firebird les développeurs auront tenu compte de nos remarques et auront essayé de résoudre ce problème.

Je vais mettre ce topic en résolu même si au fond ce n'est pas vraiment résolu mais comme pour cette version nous ne pourrons pas faire mieux et que j'ai atteint le même niveau de protection qu'avant ...

Encore un grand merci à tous pour vos contributions et bonne journée !
13/07/2016, 14h51
Artemus24

Salut DelphiCode.

Citation:

Envoyé par DelphiCode

même avec la version 3 il n'y a pas encore de solution vraiment propre et efficace pour protéger sa base de données

A vrai dire, je ne suis pas un expert et j'ai beaucoup de lacune concernant la pratique de FireBird.
Mais il n'existe pas des solutions toutes faites pouvant répondre à chaque demande.

Citation:

Envoyé par DelphiCode

Dans mon cas le point 7 c'est mort !

Et pourquoi donc ? Est-ce une question de savoir-faire ?

La sécurité à mettre en place consiste à protéger le fichier physique concernant les accès directs.
Seul le serveur doit avoir l'accès ! Pour les autres comptes, aucun accès.

Citation:

Envoyé par DelphiCode

En ce qui concerne le point 6 ...

Le point 6 est la solution que j'ai trouvé pour interdire l'accès du compte "sysdba" à la base de données.
Et en particulier, l'astuce qui consiste à désactiver les déclencheurs.

Je n'ai rien trouvé dans la documentation pour renommer le compte "sysdba" ou pour le détruire définitivement, voire lui supprimer ses droits !
Le problème est qu'il faut partie intégrante de FireBird et c'est un problème de sécurité.

De ce fait, toute la sécurité que tu dois mettre en place doit être interne à la base que tu crées.
Si quelque chose vient court-circuiter cette sécurité, par exemple le fichier "security3.fdb, ou une autre astuce, cela remet en cause ce que tu as fait au préalable.

En fait, le compte "sysdba" a été mal pensé dès le départ.
Si un existant est proposé lors de l'installation de FireBird, c'est normal.
Mais que l'on ne puisse pas modifier ce compte, voire le détruire est une aberration.

Citation:

Envoyé par DelphiCode

Je suppose donc que le fait d'avoir fusionné les 2 bases de données (sécurité + travail) en une seule et qu'il n'y ait pas "sysdba" dedans permet donc de créer le role sysdba.

Je suis en mode superclassique, et j'ai pu fusionner les deux bases en une seule (sécurités + données). C'est le fait d'accéder à la base en tant que créateur/propriétaire que j'ai pu utiliser cette astuce.
Sur le fond, je suis d'accord avec makowski, cete astuce n'est pas propre.
Mais faute de mieux, on se contente de cette astuce !

Citation:

Envoyé par makowski

créer un rôle SYSDBA a toujours été un mauvais hack inutile et inefficace et avec Firebird 3. complètement inutile.

La preuve que non, puisque sans cette astuce, le compte "sysdba" est quand même autorisé à désactiver le déclencheur.

Citation:

Envoyé par DelphiCode

j'ai réussi à reproduire le même niveau de protection qu'avec Firebird 2.5.4 même s'il est loin d'être parfait.

Y-a-t-il un autre problème ?

Un dernier point concernant le rôle d'administrateur pour le compte créateur/propriétaire.
Pour la base des données, cela ne sert à rien car ce compte à tous les droits.
Pour la base de sécurités, je n'ai pas compris pourquoi ce compte ne peut pas détruire les comptes qu'il a créé auparavant.
Mais j'ai détecté un problème avec "grant RDB$ADMIN to test" dans la base nouvellement créée.
A partir du moment où le compte est administrateur, celui-ci peut en effet désactiver les déclencheurs.
Si l'astuce donnée précédemment fonctionne pour le compte "sysdba", il est impossible d'anticiper pour n'importe quel autre compte administrateur.
De ce fait, je conseille vivement de ne pas utiliser "grant RDB$ADMIN to test" dans la nouvelle base pour autoriser un autre compte à administrer la base.

J'ai fait le test avec le compte "administrator" qui est présent, chez moi, dans "security3.fdb".
Ce compte a été fait administrateur dans la base nouvellement créée et j'ai pu désactivé les déclencheurs. Conclusion danger !!!

En ce qui me concerne, les problèmes de sécurités de la base nouvellement créée sont résolus.

@+
13/07/2016, 15h41
DelphiCode

Salut Artemus24,

Citation:

Envoyé par Artemus24

A vrai dire, je ne suis pas un expert et j'ai beaucoup de lacune concernant la pratique de FireBird.
Mais il n'existe pas des solutions toutes faites pouvant répondre à chaque demande.

Moi non plus, mais nous avons développé beaucoup d'aspects et sur le nombre de fois où ce topic a été lu il n'y a pas trop eu de réponse donc je suppose qu'il n'existe pas trop d'autres options que celle que nous utilisons (protection comme on la vu + role sysdba).

Citation:

Envoyé par Artemus24

Et pourquoi donc ? Est-ce une question de savoir-faire ?

Non de contrainte pro (client) -> pc accessible monoposte sans gestion avancée

Citation:

Envoyé par Artemus24

Je suis en mode superclassique, et j'ai pu fusionner les deux bases en une seule (sécurités + données). C'est le fait d'accéder à la base en tant que créateur/propriétaire que j'ai pu utiliser cette astuce.
Sur le fond, je suis d'accord avec makowski, cete astuce n'est pas propre.
Mais faute de mieux, on se contente de cette astuce !

Quand je disais "fusionné" je sous entendais la solution database.conf avec sa propre base de données sécurité. Entièrement d'accord c'est pas propre mais on se contente de ce qu'on a !

Citation:

Envoyé par Artemus24

Y-a-t-il un autre problème ?

Non mais je pensais qu'avec la version 3 nous allions avoir une gestion différente "à l'intérieur" plutôt qu'à "l'extérieur" niveau sécurité. Je dis que l'astuce du role sysdba est mieux que rien mais je sais très bien qu'il suffit (pour celui qui connaît l'astuce) de jouer un peu avec un éditeur hexadécimal et elle ne reste pas très longtemps (ce sujet a d'ailleurs été abordé sur un topic de developpez (je ne sais plus lequel de tête)). C'est pour cela que je dis cette astuce protège un peu (découragera la plupart des novices mais pas ceux qui connaissent bien Firebird ou ceux qui auront lu ces topics ;)) mais n'est pas robuste et pérenne.

Citation:

Envoyé par Artemus24

Un dernier point concernant le rôle d'administrateur pour le compte créateur/propriétaire.
Pour la base des données, cela ne sert à rien car ce compte à tous les droits.
Pour la base de sécurités, je n'ai pas compris pourquoi ce compte ne peut pas détruire les comptes qu'il a créé auparavant.
Mais j'ai détecté un problème avec "grant RDB$ADMIN to test" dans la base nouvellement créée.
A partir du moment où le compte est administrateur, celui-ci peut en effet désactiver les déclencheurs.
Si l'astuce donnée précédemment fonctionne pour le compte "sysdba", il est impossible d'anticiper pour n'importe quel autre compte administrateur.
De ce fait, je conseille vivement de ne pas utiliser "grant RDB$ADMIN to test" dans la nouvelle base pour autoriser un autre compte à administrer la base.

J'ai fait le test avec le compte "administrator" qui est présent, chez moi, dans "security3.fdb".
Ce compte a été fait administrateur dans la base nouvellement créée et j'ai pu désactivé les déclencheurs. Conclusion danger !!!

Merci beaucoup pour l'information c'est bon à savoir !

Encore une fois merci beaucoup pour toute l'aide que tu m'a apporté, je vais resté comme cela moi aussi.

Bonne après-midi et à plus,
14/07/2016, 12h00
SergioMaster

Bonjour,

Citation:

Non de contrainte pro (client) -> pc accessible monoposte sans gestion avancée

Donc, si je refais le point, en fait le sujet serait plutôt : comment protéger ma base et plus que SYSDBA il semble s'agir d'un problème de fond puisque un bidouilleur désactivant le trigger , "la messe est dite".

A mon avis, la bonne protection consisterai plutôt à crypter les données (ce que Firebird 3 offre comme solution). Bien sûr si un malveillant est sur le poste serveur, lit le fichier databases.conf et donc obtient les renseignements nécessaires et peut donc récupérer dll et clés de cryptage cela n'avance pas d'avantage. De même rien n'empêche d'utiliser un plugin d'autorisation indépendant (avec les mêmes inconvénients que pour le cryptage, les renseignements se trouvent dans databases.conf :aie:)

Avocat du diable, je dirais qu'il y a quand même un avantage à 'SYSDBA' (à partir du moment où sont mot de passe n'est pas masterkey) pour moi, qui travaille avec plusieurs société lorsque je récupère une de leurs bases je n'ai pas à me casser la tête (ouvrir un dossier, retrouver les sécurités) pour faire mes interventions qui bien sur dans ces cas là sont toujours urgentissimes
14/07/2016, 15h57
Artemus24

Salut SergioMaster.

Je pars du principe que l'ordinateur ou de surcroît l'hébergeur de mon application est protégé par le système d'exploitation.
A moins de posséder les identifiants, normalement, on ne peut pas accéder à cet espace de stockage.
C'est le premier niveau de sécurité qu'il faut mettre en place, même si le fichier physique ne garantie pas la totale sécurité.

Le deuxième point et non des moindre est de faire tous les accès au travers du serveur FireBird.
Donc aucun accès en direct sur le fichier physique.

Le troisième point concerne le chiffrement des données dans la base.
Cela ralentit un peu le traitement des données, mais est-ce vraiment nécessaire ?

Le quatrième point concerne la fréquence des changements des mots de passe, voire aussi leur complexité et nombre de caractères alphanumériques et en diversité.
Mais il arrive fréquemment que le point faible de la sécurité concerne l'humain ayant une mémoire de poisson rouge.
Comment garantir quoi que ce soit, quand la faille se trouve sur ce mot de passe ?

Il existe un cinquième point, celui de l'identification du terminal par son adresse IP.
Oui, sauf qu'aujourd'hui, les adresses IP sont, la plus part du temps, dynamique sous internet.

Je ne sais pas si c'est psychologique, mais le compte 'root' sous MySql ou le compte 'sa' sous microsoft SQL Server ont des portes dérobées au cas où l'on veut récupérer un quelconque accès si on perd la connaissance soit du compte administrateur et pire, du mot de passe.
Et pourtant, cela ne pose aucun problème de sécurité !

Et là, sous FireBird, on se focalise sur le compte sysdba comme si c'était une énorme faille de sécurité que l'on ne saurait colmater !

Seul, n'importe quel SGBD ne peut garantir la sécurité des données. Vous devez protéger la base physiquement !
On ne peut rien garantir sur la durée de vie d'une application ou des mauvaises manipulations humaines.

@+
16/07/2016, 10h45
SergioMaster

Bonjour,

@artemus
je suis tout à fait d'accord avec cette dernière analyse

Encore heureux qu'il y ait une porte dérobée connue. Pas parce que les poissons rouges n'ont pas de mémoire, (ce qui n'est pas totalement prouvé selon les expériences de certains, je ne suis pas sur du nom de l'émission que j'ai regardée à ce sujet) mais plutôt parce que la bêtise humaine fait parfois jeter des documents importants (dossier sécurité).

Tu m'apprends qu'il en est de même pour MySQL ou SQL Serveur donc je dirais que Firebird se fait taper dessus sans raison valable si ce n'est qu'il est un vrai open source ! (NB le SYSDBA existe aussi avec Interbase et étrangement je n'ai pas lues de critiques à ce sujet)

@DelphiCode tu nous indique la contrainte : monoposte sans gestion avancée . Déjà, d'entrée de jeu, la sécurité est vraiment faible :
- accès facile à la BDD
- une petite installation fb embedded et un arrêt service = plus de sécurité par mdp
alors que SYSDBA existe ou pas est vraiment un truc secondaire !
20/07/2016, 14h41
DelphiCode

Bonjour à tous,

Désolé pour le retard !

Citation:

Envoyé par SergioMaster

Déjà, d'entrée de jeu, la sécurité est vraiment faible

Je sais mais bon on en ferait un roman ...

Citation:

Envoyé par SergioMaster

une petite installation fb embedded et un arrêt service = plus de sécurité par mdp

Je ne connais pas du tout le mode embedded, pourrais-tu m'en dire un peu plus sur ce à quoi tu penses ?

Merci par avance,
A plus
20/07/2016, 17h37
SergioMaster

Bonjour,

j'aurais du écrire pas de sécurité, je m’aperçoit que le plus était ambiguë !
Le mode embedded c'est en fait quand il n'y a pas de service Firebird actif et du coup c'est un accès mono-utilisateur, sans sécurité :calim2:
C'est une des méthodes utilisée pour créer le fichier sécurité justement avec FB3 !

Ce que je voulais dire, c'est qu'il n'est pas la peine de crier sur le SYSDBA et ses problèmes de sécurité un simple arrêt du service et on peut accèder à la base :aie:
Si sécurité l'on veut, c'est bien par cryptage, externalisation (serveur dans pièce protégée ) etc ... que cela doit passer
20/07/2016, 17h45
Artemus24

Salut SergioMaster.

Je n'ai pas compris comment tu fais pour accéder à ta base de données quand le service FireBird est désactivé.

@+
21/07/2016, 08h18
SergioMaster

Bonjour Artémus,

tu m'excuseras si je ne divulgue pas vraiment la marche à suivre sur un forum public.
Je te renvoie sur les pages de Firebird http://firebirdsql.org/manual/fbmetasecur-embedded.html et sur les pages d'installation de Firebird embedded http://firebirdsql.org/manual/ufb-cs...bedded-windows

comme je l'indiquais

Citation:

C'est une des méthodes utilisée pour créer le fichier sécurité justement avec FB3 !

je parlais des méthodes avec GSEC (je n'ai devant les yeux que le FB3 Migration Guide) qui semble utiliser cette dll, et de la méthode proposée (toujours dans ce guide, mais que je suis sur d'avoir lu dans une des docs officelles) je cite en abbrégé :

Citation:

Vous devez vous connecter a une base via ISQL ....
Comment se connecter alors qu'il n'y a pas d'utilisateur de défini ? Simple ! en se connectant via une connexion embarquée (embedded)
21/07/2016, 20h00
DelphiCode

Merci beaucoup pour les éclaircissements.
28/07/2016, 12h49
SQLpro

Citation:

Envoyé par Artemus24

Je ne sais pas si c'est psychologique, mais le compte 'root' sous MySql ou le compte 'sa' sous microsoft SQL Server ont des portes dérobées au cas où l'on veut récupérer un quelconque accès si on perd la connaissance soit du compte administrateur et pire, du mot de passe.

Dans SQL Server le compte sa est un compte interne au serveur et non pas comme root un compte système externe. On peut donc au choix, le désactiver dans SQL Server ou le supprimer (ce que je fais sur les serveurs en exploitations chez mes clients). Bien entendu il faut donc créer un autre compte de niveau DBA préalablement.

Citation:

Seul, n'importe quel SGBD ne peut garantir la sécurité des données. Vous devez protéger la base physiquement !

Pour protéger la base physiquement SQL Server bloque les fichiers en ouverture exclusive ce qui fait qu'il n'est pas possible de les copier tant qu'ils sont utilisés par le serveur (et le serveur exploite toutes les bases dès son démarrage).

En sus il est possible de chiffrer le stockage des fichiers de données et du journal de SQL Sever via TDE avec une clef de chiffrement interne, stockée dans la base, et générée par un certificat externe.
Il faut donc pouvoir disposer du certificat (qui est un fichier sauvegardabale) mais aussi de la phrase de passe de la clef de chiffrement TDE qui elle ne peut être sauvegardée.....
Ceci assure une sécurité maximale, là ou la plupart des SGBDR permettent de chiffrer, mais permettent aussi de "voler" les clefs en proposant la sauvegarde des clefs sous forme de fichier externe, ce qui est une aberration, car si on vole les fichiers de la base, il n'y a pas de raison de ne pas voler aussi les fichiers de sauvegardes des clef !!!!!

A +
28/07/2016, 12h51
SQLpro

Citation:

Envoyé par SergioMaster

Tu m'apprends qu'il en est de même pour MySQL ou SQL Serveur

Non, non, totalement faux... Lire mon post précédent !

Citation:

donc je dirais que Firebird se fait taper dessus sans raison valable si ce n'est qu'il est un vrai open source ! (NB le SYSDBA existe aussi avec Interbase et étrangement je n'ai pas lues de critiques à ce sujet)

Normal car sa sécurité est une passoire ! En même temps si c'est de l'OPEN alors que les données soient aussi de l'OPENDATA !!!

A +
29/07/2016, 14h07
makowski

Citation:

Envoyé par SQLpro

Dans SQL Server le compte sa est un compte interne au serveur et non pas comme root un compte système externe. On peut donc au choix, le désactiver dans SQL Server ou le supprimer (ce que je fais sur les serveurs en exploitations chez mes clients). Bien entendu il faut donc créer un autre compte de niveau DBA préalablement.

chose tout à fait faisable aussi avec Firebird, la version 3 permet de stocker les utilisateurs dans la base elle même, et n'oblige pas à avoir un compte nommé SYSDBA.

Citation:

Envoyé par SQLpro

Pour protéger la base physiquement SQL Server bloque les fichiers en ouverture exclusive ce qui fait qu'il n'est pas possible de les copier tant qu'ils sont utilisés par le serveur (et le serveur exploite toutes les bases dès son démarrage).

la bonne blague
il suffit donc d’arrêter le service, et donc lever le verrou.

Citation:

Envoyé par SQLpro

En sus il est possible de chiffrer le stockage des fichiers de données et du journal de SQL Sever via TDE avec une clef de chiffrement interne, stockée dans la base, et générée par un certificat externe.

pour Firebird 3.0 aujourd'hui le plugin de base permet : "With Firebird 3 comes the ability to encrypt data stored in database. Not all of the database file is encrypted: just data, index and blob pages."
mais le plugin est prêt pour accepter toutes sortes de chiffrement, libre à chacun de le développer ou le faire développer par quelqu'un d'autre.

http://www.firebirdsql.org/file/docu...ncryption.html
30/07/2016, 09h19
SergioMaster

Bonjour,

@makowski Heureux de voir une intervention de ta part :D , j'espère, si tu as lu le fil de la discussion, n'avoir pas dit trop de bêtises !
@SQLpro Je me disais bien aussi que SQL Server ne pouvait pas se permettre ce genre de choses (je ne parle pas de mySQL que, je le sais tu ne portes pas spécialement dans ton cœur)

Lire un duel d'expert au sujet de cette faille (ou présumée telle) des SYSDBA ou sa me plairait énormément, je pense que chacun resterait sur ses positions toutefois :roll:

Citation:

chose tout à fait faisable aussi avec Firebird, la version 3 permet de stocker les utilisateurs dans la base elle même, et n'oblige pas à avoir un compte nommé SYSDBA.

on est d'accord, toutefois, la discussion le prouve, SYSDBA reste un compte avec lequel il faut compter (jeu de mots nul je le reconnais) mais qu'une astuce comme le Trigger proposé par Artemus24

Voir 40 message(s) de cette discussion en une page