Astuce #011 : Interdisez le partage des mots de passe des comptes applicatifs

You are currently viewing Astuce #011 : Interdisez le partage des mots de passe des comptes applicatifs

Astuce #011 : Interdisez le partage des mots de passe des comptes applicatifs

Interdire le partage des mots de passe des comptes applicatifs. Plus facile à dire qu’à faire… surtout quand une seule personne détient tous les mots de passe. Dans beaucoup d’environnements, toute action un peu sensible finit par dépendre du DBA.

Résultat : on attend le DBA pour débloquer un agent applicatif en pleine nuit; on ne peut pas avancer sur une opération simple sans lui. Tout ceci fait monter la pression opérationnelle et les mauvaises pratiques s’installent. Ce qui pose un problème d’architecture des accès.

SOLUTION COURANTE

Dans de nombreux environnements, on observe :

le partage du mot de passe du compte applicatif entre plusieurs personnes

En cas d’erreur, d’incident ou d’accès frauduleux, il devient impossible d’identifier l’auteur des actions.
Le changement de mot de passe est complexe et risqué, car il impacte immédiatement l’application.

l’attribution du rôle DBA à des utilisateurs techniques

La solution la plus courante.

  • Cela leur donne un accès total à la base de données (données, sécurité, sauvegardes).
  • Une simple erreur de manipulation peut avoir des conséquences désastreuses, et toute compromission devient catastrophique.

l’octroi de droits excessifs à des comptes utilisateurs.

Accorder des privilèges globaux sur l’ensemble des tables applicatives est une fausse solution.

  • Les utilisateurs disposent de droits bien supérieurs à leurs besoins réels.
  • L’ajout de nouvelles tables au schéma applicatif nécessite une réaffectation des droits utilisateurs

Ces pratiques entraînent une perte totale de traçabilité et un risque majeur sur toute la bases de données en cas de compromission.

RECOMMANDATION

Séparez clairement les rôles.

Le compte applicatif devient schema-only-account

  • Il ne sert qu’à porter les objets applicatifs.
  • Aucun accès direct n’est autorisé.
SQL> CREATE USER app_data NO AUTHENTICATION;

Utilisateur cree.

SQL>  GRANT CREATE SESSION, CREATE TABLE TO app_data ;

Autorisation de privileges (GRANT) acceptee.

SQL>  ALTER USER app_data QUOTA UNLIMITED ON users;

Utilisateur modifie.

Les accès utilisateurs passent par des Proxy Users.

  • Chaque intervenant se connecte avec son propre compte nominatif ;
  • Le proxy permet d’agir au nom du schéma applicatif sans connaître son mot de passe.
SQL> CREATE USER tomy IDENTIFIED BY Password_1;

Utilisateur cree.

SQL> GRANT CREATE SESSION TO tomy;

Autorisation de privileges (GRANT) acceptee.

Identifiez les différents modes d’authentification.

SQL> select USERNAME, AUTHENTICATION_TYPE from dba_users where username in ('APP_DATA','TOMY');

USERNAME                       AUTHENTICATION_TYPE
------------------------------ ------------------------------
APP_DATA                       NONE
TOMY                           PASSWORD

Octroi de connexion via le compte proxy

SQL> ALTER USER app_data GRANT CONNECT THROUGH tomy;

Utilisateur modifie.

Connexion via e compte proxy

SQL> CONN tomy[app_data]/Password_1@pad
Connecte.
SQL> col SESSION_USER format a15
SQL> col SESSION_SCHEMA format a15
SQL> col CURRENT_SCHEMA format a15
SQL> col PROXY_USER format a15
SQL> select sys_context('userenv','session_user') as session_user,
  2         sys_context('userenv','session_schema') as session_schema,
  3         sys_context('userenv','current_schema') as current_schema,
  4         sys_context('userenv','proxy_user') as proxy_user
  5  from   dual;

SESSION_USER    SESSION_SCHEMA  CURRENT_SCHEMA  PROXY_USER
--------------- --------------- --------------- ---------------
APP_DATA        APP_DATA        APP_DATA        TOMY

✨ EN BONUS

schema-level privileges

À partir d’Oracle 23ai il existe le schema-level privileges qui permet d’attribuer des droits à tous les objets d’un schéma

SQL> GRANT SELECT ANY TABLE ON SCHEMA APP_DATA TO TOMY;

Autorisation de privileges (GRANT) acceptee.

Surveillez régulièrement les comptes proxy avec la vue PROXY_USERS

SQL> set lines 100
SQL> col proxy format a20
SQL> col client format a20
SQL> col authentication format a20
SQL> col flags format a30
SQL> select * from proxy_users;

PROXY                CLIENT               AUTHENTICATION       FLAGS
-------------------- -------------------- -------------- ------------------------------
TOMY                 APP_DATA             NO             PROXY MAY ACTIVATE ALL CLIENT
                                                         ROLES

Supprimez les comptes proxy lorsque vous n’en avez plus besoin.

SQL> ALTER USER APP_DATA REVOKE CONNECT THROUGH TOMY;

Utilisateur modifie.

Laisser un commentaire