IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Outils Firebird Discussion :

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


Sujet :

Outils Firebird

  1. #41
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Mars 2008
    Messages : 38
    Points : 15
    Points
    15
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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,

  2. #42
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 :
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  3. #43
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Mars 2008
    Messages : 38
    Points : 15
    Points
    15
    Par défaut
    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 !

  4. #44
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  5. #45
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Mars 2008
    Messages : 38
    Points : 15
    Points
    15
    Par défaut
    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,

  6. #46
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    Bonjour,

    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 )

    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
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  7. #47
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  8. #48
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    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 !
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  9. #49
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Mars 2008
    Messages : 38
    Points : 15
    Points
    15
    Par défaut
    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

  10. #50
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    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é
    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
    Si sécurité l'on veut, c'est bien par cryptage, externalisation (serveur dans pièce protégée ) etc ... que cela doit passer
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  11. #51
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    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é.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  12. #52
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    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
    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é :
    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)
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  13. #53
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Mars 2008
    Messages : 38
    Points : 15
    Points
    15
    Par défaut
    Merci beaucoup pour les éclaircissements.

  14. #54
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    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.

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  15. #55
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par SergioMaster Voir le message
    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 !

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  16. #56
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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 Voir le message
    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 Voir le message
    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
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  17. #57
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    Bonjour,

    @makowski Heureux de voir une intervention de ta part , 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

    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
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

+ Répondre à la discussion
Cette discussion est résolue.
Page 3 sur 3 PremièrePremière 123

Discussions similaires

  1. problème d'accès avec le compte administrateur local
    Par ferhat.adel dans le forum Windows Serveur
    Réponses: 5
    Dernier message: 02/02/2014, 18h55
  2. problème avec la session administrateur
    Par fofmata dans le forum Windows XP
    Réponses: 1
    Dernier message: 24/05/2007, 00h19
  3. Problème avec mon compte d'administrateur
    Par Ganak dans le forum Windows XP
    Réponses: 4
    Dernier message: 13/01/2007, 15h58
  4. Réponses: 2
    Dernier message: 21/07/2005, 13h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo