Comment imposer le mot de passe pour l'accès SYSDBA ?

Problématique :

Dans une entreprise où plusieurs DBA travaillent sur la même base de données, pouvoir se connecter avec le privilège sysdba sans fournir de compte et de mot de passe peut constituer une faille de sécurité d'autant plus que la base de données ne retiendra que l'utilisateur générique SYS.

Comment éviter alors de se connecter de la sorte :  "sqlplus / as sysdba" ou "conn / as sysdba" sans fournir de mot de passe ?

Solution :

Tests effectués dans les environnements suivant :
      - Environnement virtuel VMWare Workstation

      - OS : RHEL 5

      - DB : Oracle 11gR2 

1. Paramètre SQLNET.AUTHENTICATION_SERVICES du fichier sqlnet.ora

Ce paramètre permet d'activer ou non les services d'authentification mis en place pour les bases de données.

        a- Editer le fichier $ORACLE_HOME/network/admin/sqlnet.ora

        b- Y ajouter la ligne SQLNET.AUTHENTICATION_SERVICES=NONE puis enregistrer et fermer.

Ceci permet de forcer les utilisateurs os définit dans le group dba à fournir un login et un mot de passe valide pour se connecter à la base de données.

Cependant un utilisateur aguerrit peux facilement contourner cette solution en modifiant le paramètre pour pouvoir se connecter sans mot de passe puis remettre la valeur initiale.

2. Groupes os DBA et OPER...

Cette second option consiste à supprimer l'utilisateur os oracle (ou tout autre que vous aurez utilisé) des groupes DBA et OPER

        a- [root@ladollhost01~]# gpasswd -d oracle dba

        b- [root@ladollhost01~]# gpasswd -d oracle oper

Une fois cette manipulation effectuée, l'utilisateur os oracle ne pourra plus se connecter sans fournir de mot de passe.

Cependant, la faille de cette méthode est que si l'utilisateur qui cherche à accéder à la base de données est le root, il a la possibilité d'ajouter l'utilisateur oracle aux groupes ou encore de créer de nouveaux utilisateurs et les ajouter aux groupes dba et oper afin de se connecter sans mot de passe.

3. Fichier $ORACLE_HOME/rdbms/lib/config.c

Cette option permet de modifier le groupe dba et oper qui sont les groupes classique que l'on créé pour installer Oracle. 

L'objectif ici est de tromper celui qui cherche à se connecter sans mot de passe par le biais de l'utilisateur os Oracle.

Tous les processus oracle doivent être arrêtés.

       a- Editer et modifier le fichier $ORACLE_HOME/rdbms/lib/config.c

           [root@ladollhost01~]# vi $ORACLE_HOME/rdbms/lib/config.c

             ----------

             #define SS_DBA_GRP "dba"

             #define SS_OPER_GRP "oper"

             #define SS_ASM_GRP ""

             char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};

       b- Après modification, enregistrer et fermer le fichier

           Le contenu du fichier peut ressembler à celui-dessous :

             [root@ladollhost01~]# cat $ORACLE_HOME/rdbms/lib/config.c

              ----------

             #define SS_DBA_GRP "laddba"

             #define SS_OPER_GRP "ladoper"

             #define SS_ASM_GRP ""

             char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};

         Pour les système UNIX tel que SOLARIS SPARC ce sera :

             .ascii "laddba\0"
             .ascii "ladoper\0"

        c- Faire un relink des binaires

             [root@ladollhost01~]# $ORACLE_HOME/bin/relink all

    

Une fois vous aurez redémarré votre base de données et tous les services afférents, il sera impossible à quiconque de se connecter sans fournir de login et de mot de passe.

Une fois n'étant pas coutume, l'utilisateur root expérimenter en Oracle pour réussir à contourner cette protection; il lui suffira pour cela de créer au niveau os les nouveaux groupes que vous ajouter au fichier $ORACLE_HOME/rdbms/lib/config.c puis d'ajouter l'utilisateur oracle dans ces groupes. Il peut encore tout simplement remettre les noms des anciens groupes.

L’idéal est de ne pas préciser de groupe, cela rendra les choses plus difficile à contourner l'accès sans mot de passe.

             #define SS_DBA_GRP ""

             #define SS_OPER_GRP ""

 3. Database Vault 

La solution la plus fiable pourrait être d'implémenter Database Vault, sujet que nous pourrons traiter dans nos posts futur.