« L’utilisateur est tenu de changer son mot de passe tous les 30 jours »
« L’accès à cette fonctionnalité sera restreint aux administrateurs du domaine »
« L’application devra être compliant au SSO de l’entreprise »
Les cahiers des charges et chartes de sécurité informatique sont remplis de ces phrases décourageantes, leur seule lecture suffit généralement à comprendre pourquoi, au sein des entreprises, la sécurité informatique reste la partie la plus « incomprise » des systèmes d’information.
Du coté collaborateurs, la sécurité informatique est vécue le plus souvent comme un passage obligé leur permettant d’accéder à leur poste de travail et à leurs applications, mais en aucun cas une démarche visant à protéger les données de l’entreprise. Prenons par exemple le mot de passe, grand axe de la sécurité, et source de plusieurs angoisses : En 2004, une enquête réalisée à Londres pour le salon InfoSecurity révélait que plus de 70 % des personnes interrogées étaient prêtes à céder leur mot de passe Windows contre une barre de chocolat :
Coté applicatif, le constat est le même, la sécurité est vécue par les chefs de projets comme un frein venant ralentir l’innovation et impacter les délais de développement. Les concepteurs des applications sont confrontés à la réalité des délais : « Je fais comment pour m’intégrer au SSO d’entreprise ? Pourquoi me Plugger sur le serveur LDAP de l’entreprise, combien cela va t-il me couter en jours hommes ? »
Toutes ces interrogations et ces aprioris ne sont de la faute de personne, c’est au cloisonnement de la DSI qu’il faut s’en prendre. Pendant ces 15 dernières années, alors qu’études et production ont peu à peu sombré dans une incompréhension mutuelle aboutissant le plus souvent à un divorce, la sécurité a elle aussi vécu une forme de mise à l’écart.
La réponse à ce cloisonnement ne peut être apportée que par l’organisation. En l’occurrence la structure recherchée doit fournir dans le domaine de la sécurité des solutions pour des acteurs aussi différents que des responsables RH ou des chefs de projets agiles. Ces acteurs veulent travailler ou développer leurs projets dans le respect des biens de l’entreprise, mais pour ce faire, ils attendent légitimement des personnes les ayant sensibilisé à la valeur de ces biens, des solutions pratiques et assistées. C’est ce que propose de faire le Centre de compétences intégré (CCI).
Le Centre de compétences intégré est un pattern décrit en long, en large et en travers et plus encore dans l’ouvrage « Une politique pour le Système d’information » qui en donne la définition suivante :
« Un Centre de Compétence Intégré (CCI) est entité basée autour d’une problématique de moyens qui couvre à la fois le BUILD (phases de définition, conception et développement) et le RUN (la production). Un CCI est dépositaire d’une fondation (ou socle technique). Par exemple un environnement CICS/Cobol/DB2, un environnement JAVA/J2EE/Oracle, un environnement SAP, un environnement d’échanges, l’infrastructure des utilisateurs (poste de travail et réseaux)…qu’il conçoit et fournit aux projets aussi bien qu’il l’administre en support des exploitants. »
Appliquée à la gestion des identités, cette définition devient :
Le CCI sécurité est une entité transverse dédiée au service des autres centres et des projets. Il leur permet, par une approche pilotée par les risques, de placer le curseur de la sécurité sur un niveau standard opérationnel. Il fournit à cet effet des solutions de sécurité pratiques, assistées et/ou clés en main.
Le CCI sécurité est donc, un fournisseur de solutions pour les projets utilisant les services de sécurité gravitant autour de l’identité, ainsi qu’un accélérateur de projets. Il fournit aux clients de la DSI des services de gestion des identités sous la forme de solutions packagées et garanties par SLA.
Par essence même, le CCI sécurité se compose d’un large éventail de profils. On y retrouve, pour la partie BUILD, des managers de la DSI, des chefs de projets représentatifs de l’utilisation de la sécurité en tant que service (exemple : Helpdesk) et des experts techniques capables de fournir des solutions packagées et instanciant les patterns de rationalisation. Pour la partie RUN, le CCI inclut des responsables d’infrastructure et des exploitants dont la fonction première est d’assurer par un socle technique de production adapté, la SLA garantie par le CCI sur les services de sécurité.
La SLA, habituellement, se définit souvent comme un contrat de service de la seule production, c’est à dire du RUN, mais pour un CCI, le SLA doit autant porter sur le RUN que sur le BUILD. Au niveau de ce dernier, la réactivité de maintenance est un élément clé (par ex : Dans le cas de l’ajout d’un attribut dans la fiche identité, et ce, sans impacter les applications existantes) et ne pourra être atteinte qu’en appliquant l’état de l’art des méthodologies de développement, en particulier la capacité de non régression par les tests automatisés.
L’organisation en CCI fournit d’ailleurs de meilleures garanties SLA que les structures classiques. Ainsi, lorsque un service d’authentification souffre de lenteurs, la production ne peut se cacher derrière un bref « on a installé le tout en suivant la doc de l’Etude, pour nous ca fonctionne » pendant que les Etudes renvoient sur chacun des chefs de projets concernés la responsabilité. Dans ce nouveau mode organisationnel, une seule structure est responsable de toute la chaine : le CCI.
Sources :
- Ouvrage « : Gestion des identités : Une politique pour le système d’information, OCTO Technology »
- computerworld.com
Saâd
Consultant Sécurité
