La gestion des utilisateurs des bases de données Oracle est un sujet souvent mal appréhendé par les responsables de sécurité du SI des entreprises et pour cause ! Il faut dire qu’ils ne doivent pas s’attendre à beaucoup d’aide de leurs administrateurs : qui aime le controle ? qui aime déléguer ses prérogatives ou être un peu moins indispensable ? pas moi⁽¹⁾ !

Pourtant, la gestion des utilisateurs Oracle est une des fondations pour mettre en oeuvre des principes fiables de sécurité. D’ailleurs, qui sait ce qu’il y a dans vos bases de données ? salaires, bases qualifiés de clients, données financières, moyens de paiement… Bref, pourquoi chercher à savoir qui a accédé à une bases de données ? Pourquoi ne pas laisser 50 prestataires parisiens⁽²⁾ avec des informations sur les comptes génériques de vos systèmes ? Quel est le lien entre geekitude et honêteté ?

Ce n’est pas parce que vos bases de données sont intégrées aux référentiels de gestion des utilisateurs de l’entreprise que vos mécanismes d’authentification, d’autorisation ou d’audit sont surs. La sécurité de s’arrête pas non plus à la gestion des utilisateurs. Cela étant si vous ne savez pas faire le lien entre une demande d’accès et un utilisateur physique, vous êtes à la préhistoire de la sécurité de vos bases de données. Dans cet article, vous découvrirez quelques éléments pour mieux comprendre le fonctionnement et le périmètre de Enterprise User Security et pourquoi, c’est maintenant que ça commence…

Notes :
⁽¹⁾ Je ne suis pas enclin à me laisser surveiller facilement. Cela dit, je dois reconnaitre qu’une fois au moins, ça m’a été utile pour démontrer que je n’avais pas commis le « crime » dont on m’accusait… Il faut dire que pour le coup, j’étais filmé pendant mes ébats avec cette base Oracle; voici comment !
⁽²⁾ N’étant pas originaire de Paris, j’ai remarqué qu’on donne plus facilement les mots de passe aux parisiens. Il faut dire que mon niveau de morale a été particulièrement augmenté par le fait de circuler entre Vincennes et La Défense (quoique ?).

Pourquoi identifier les vrais utilisateurs des bases Oracle ?

Faire le lien entre des bases de données, les vrais utilisateurs et des contextes applicatifs permet de changer de nombreuses limites des approches classiques ; cela permet :

• de réduire le nombre de référentiels d’utilisateurs et des mots de passe de un par base de données à quelques-uns par organisation. Vous gagnez ainsi en maintenabilité et en capacité d’analyse
• de séparer les rôles de DBA et de gestionnaire des utilisateurs qui sont rattachés aux équipes de sécurité
• de faciliter la journalisation des connexions aux bases de données et, dans la mesure où les journaux d’audits seront effectifs, d’auditer les opérations réalisées sur les systèmes cibles,
• d’homogénéiser les mots de passe entre les systèmes et la politique d’expiration avec le reste des domaines de l’entreprise,
• de faire évoluer les modèles d’autorisations par environnement vers des modèles plus contrôlés et auditables ; il devient facile de fournir des accès dans la mesure où les administrateurs administrent et le passent plus de temps à provisionner des utilisateurs,
• d’accélérer l’ouverture des comptes et de les coupler aux rôles de chacun dans les organisations,
• d’assurer la fermeture des comptes et ainsi d’éviter que les prestataires ou personnels continuent à pouvoir accéder, même par principe une fois qu’ils ont quitté l’organisation,
• d’intégrer à termes les infrastructures à des mécanismes plus évolués comme les mécanismes de single sign-on (PKI/pkcs11, Kerberos….) ou les principes de séparation des rôles offert par Oracle Database Vault.

Est-ce vraiment utile ?

La réponse est probablement oui dans une vaste majorité des cas. D’abord parce que les exemples qui montrent que la menace vient d’abord de l’intérieur foisonnent ; on peut citer Robert Moffat, WikiLeaks, Steven Jinwoo Kim ou la très récente affaire d’espionnage chez Renault. Ensuite parce que, à y bien réfléchir, il y a surement quelques informations précieuses à protéger. Les listes qualifiées de clients ? Les informations financières ? Des moyens de paiement ? Des savoir-faire ? Et, pourquoi pas, des malversassions ou des pratiques abusives ?

Cet état de fait est grossi par l’ouverture des réseaux techniques certes mais surtout par le mode de travail qui s’appuie de plus en plus sur des prestations externes (insourcing ou outsourcing) lesquelles font elles-mêmes intervenir des personnes qu’elles ne controllent pas forcément. Il m’est arrivé de croiser des serveurs provisionnés avec plus de 500 utilisateurs uniquement pour leur administration et finir par en récupérer le mot de passe SYS sans faire partie ni de l’entreprise ni des prestataires directs. Alors imaginez !

D’autre part, les firewalls ne sont pas forcément aussi efficace qu’il semble. Un bête tunnel SSH inversé accessible sur le web et n’importe qui a accès à n’importe quoi, pour un peu qu’il ait sur accéder à un serveur du réseau pendant quelques minutes. Et pas besoin d’être un grand spécialiste… Mais revenons au sujet !

Si c’est si fondamental, pourquoi tout le monde n’est-il pas encore équipé ?

Il y a sûrement plusieurs explications. Evitons les tartes à la crème du genre, les gens ont besoin de se faire pièger… Il y a des explications plus réelles :

• D’abord le manque de maturité et d’ouverture de la solution Oracle. Il faut reconnaître (pour l’avoir fait en 2005 !) que la solution d’Oracle a nécessité du temps et de nombreuses itérations pour en arriver où elle en est aujourd’hui; les optimistes qui l’ont ont payé de leur personne peuvent en témoigner ; quelques exemple :
• Pour que la solution fonctionne en JDBC Thin, il aura fallu attendre la version 11.1 du drivers à condition d’appliquer un contournement (cf How to Connect to an EUS Database Using 11g Thin JDBC Driver? [ID 793673.1])
• Pour pouvoir vous authentifier via un annuaire et être SYSDBA nécessaire pour l’arrêt/démarrage à distance, la constitution de standby ou les sauvegardes RMAN, il a fallu attendre les serveurs 11g (cf
  How To Configure Directory Authentication for Database Administrative Users (SYSDBA and SYSOPER) [ID 457083.1])
• Pour ne pas utiliser OID et s’intégrer sans trop de difficulté à Active Directory (avec des serveurs Unix/Linux), Sun Java Directory Server (aka iPlanet) et Novell eDirectory il aura fallut attendre, non seulement le rachat d’OctetString et de sa technologie de Virtual Directory mais encore l’intégration d’EUS avec cette plateforme et le développement de plug-in spécifiques en version 10.1.3.4. L’intégration à eDirectory est même arrivée plusieurs mois après cette version.
• Il n’est toujours pas possible aujourd’hui d’externaliser la gestion de ses utilisateurs vers un annuaire comme OpenLDAP ou un logiciel de RH comme PeopleSoft… ou plutôt, c’est possible à condition de bien connaître OVD, les annuaires et Java et : ce n’est pas supporté !
• Ensuite parce que les compétences sur le sujet sont plutôt rares ; à la frontière entre les problèmatiques de gestion des identités et l’administration Oracle, vous entrez dans ce qui était encore récemment un « no man’s land » ou vous ne pouviez croiser qu’un Jack ou un Yves. Le nom du prem
  ier étant Sparrow ;-), je vous laisse deviner le nom du second.
• Encore parce que ça nécessite des licences Directory Services Plus
• Enfin, je pense, parce que si vous demandez à n’importe quel DBA qui opère des environnements, il vous enverra au diable : imaginer qu’il ne puisse pas faire un « grant » pour un utilisateur ou une application, et quoi encore ? Ne plus accéder aux données ? Etre audité ?

Mais tout cela change de plus en plus vite. Le produit couvre enfin presque l’intégralité des besoins et surtout a gagné en stabilité et en facilité d’utilisation avec ODSM. Les versions 9i qui nécessitaient OID disparaissent peu à peu. Les offres complémentaires comme Audit Vault permettent de tirer partie de cette intégration tout aussi rapidement. Plusieurs sociétés utilisatrices, y compris des banques, ont désormais implémenté la solution en France. La zone auparavant déserte se peuple de ressources compétentes, à commencer par Oracle France où le nombre de ressources à littéralement explosé avec l’offre de sécurité et l’intégration de Sun… Si bien que Jack n’est plus la star qu’elle était. Vous pourrez faire appel à des ressources expertes qui pourront en quelques jours implémenter un prototype ou un pilote dans votre organisation ; au forfait : je le fais moi-même ;-). Bref 2011 sent le saut quantique. C’est le bon moment pour vous y intéresser ; d’autant que 2 ou 3 sauts successifs s’annoncent dans la foulée, mais c’est d’autres histoires pour d’autres articles…

Qu’est-ce que j’allais oublier ?

Avant de vous laisser à votre réflexion et à vos tests, il y a au moins 2 points à ajouter à cette petite introduction :

• D’abord, il est essentiel d’appréhender avec soin les impacts de la mise en place de la solutions sur les sujets techniques comme la fiabilité du système, les performances des connexions en regard des besoins de vos applications et l’administration/la supervision. Par exemple, EUS permet d’enregistrer plusieurs annuaires mais encore faut-il assurer la disponibilité de vos annuaires en amont par des mécanismes robustes.
• L’externalisation de la gestion de certains utilisateurs n’interdit pas la gestion locale ; à ce titre, certains comptes techniques et notamment SYS et SYSTEM restent présent. Mettre en place EUS seul ne suffit pas, si votre objectif est l’auditabilité des accès ; il faudra également intégrer le référentiel des identité à vos serveurs et assurer les mécanismes de délégation des droits auditables comme la commande sudo.

Le sujet est extrêmement vaste si vous vous y lancer pour adresser des besoins particuliers. Comme d’habitude, n’hésitez pas à laisser vos histoires ou vos commentaires bons ou moins bons.