Réduire les accès des développeurs aux serveurs de base de données Oracle peut s’avérer parfois utile. Ainsi, si Database Vault est LA solution dans ce domaine, utiliser un trigger AFTER LOGON peut aider à former un premier rempart aux IP différentes de celles des serveurs d’applications ou à certain clients comme SQL*Developer ou SQL*Plus. Voici un exemple qui empêchera les utilisateurs de se connecter avec SQL*Developer :

create or replace trigger prevent_sqldeveloper
 after logon on database
declare
  v_program varchar2(48);
  v_sid     number;
  v_serial# number;
begin
  select sid, serial#, program into v_sid, v_serial#, v_program
    from v$session where sid=sys_context('userenv', 'sid');
  if (v_program like 'SQL Developer%') then
    raise_application_error(-20001,
      'You''re not allowed to connect from SQL*Developer');
  end if;
end prevent_sqldeveloper;
/

Attention :

• Il faut bien tester ce trigger sur un environnement de développement avant de le déployer
• le trigger ne fonctionne pas si l’utilisateur a le privilège « ADMINISTER DATABASE TRIGGER » ou un role auquel « ADMINISTER DATABASE TRIGGER » a été affecté. Pour qu’il fonctionne pour les administrateurs DBA, il faut enlever le privilège du role DBA ou des utilisateurs finaux.
• Les triggers « after logon » impactent le temps de connexion et la CPU nécessaire pour se connecter. Il faut également évaluer bien le nombre de connexions avant de mettre en oeuvre une telle méthode

Une fois la méthode en place, vos développeurs auront l’agréable surprise de découvrir le nouvel écran ci-dessous en essayant de se connecter depuis leur poste client. Il ne vous reste plus qu’à adapter cette méthode à votre contexte :