Les risques opérationnels Bâle II liés aux accès aux applications

Prenons l'exemple d'un banque qui possède un ensemble d'applications sensibles qui sont autant de sources potentielles de risque.

• Risque de fraude lorsqu'un employé décide de détourner à son profit des sommes appartenant à la banque ou à ses clients
• Risque d'erreur humaine lorsqu'un employé non habilité accède à des applications qu'il ne maîtrise pas, ou dont il ne perçoit pas toutes les implications

L'an passé cette banque ne possédait pas de système centralisé de gestion des identités et des accès.

Toutes les opérations d'identification des utilisateurs étaient faites au niveau de chaque application, chacune nécessitant son propre administrateur pour la création des comptes utilisateurs.

Certaines applications, mais pas toutes, permettaient d'historiser les accès des utilisateurs dans des fichiers de log. Cependant cette option n'était pas toujours activée ou alors mal configurée. De plus, ces fichiers étaient très rarement consultés – pour ne pas dire jamais – car leur accès et format étaient très compliqués et multiples.

Il était donc impossible d'analyser tous les accès d'un utilisateur aux applications du système d'information ou encore de mettre en place des indicateurs de suivi de risques.

En cas d'intrusion sur les systèmes sensibles, il était alors très difficile – voire dans certain cas impossible – d'analyser les accès d'une application ou d'un utilisateur donné, d'établir un diagnostic sur les causes à l'origine des brèches de sécurité ou de proposer une amélioration des processus de gestion des utilisateurs.

Cela en contradiction avec les accords de Bâle II qui préconisent de mettre en place des points de contrôle capables d'évaluer le niveau d'exposition aux risques.

La banque a donc décidé, l'an dernier, de mettre en oeuvre un système global de gestion des identités et des accès afin de lui permettre de piloter et réduire les risques opérationnels liés aux accès aux applications.