Expert SAP BusinessObjects depuis plus de 20 ans, Benoit Guillot en tant que référent BO chez Seenovate intervient régulièrement sur des sujets de migration, de gouvernance et de sécurité des plateformes SAP BI. C’est justement ce dernier point qui fait l’objet de cet article.
Préambule
Depuis que j’ai commencé à déployer les solutions BusinessObjects dans les années 2000, la question de la gestion des accès aux données et de leur mise à disposition m’a toujours fortement intéressé.
Pourquoi ?
Tous simplement, car cela correspond à un besoin de toutes les entreprises déployant ces solutions et qu’à chaque fois (ou presque) ce n’est pas une question purement technique ou de formation à la CMC (comment faire). Il s’agit d’un réel travail de consultant où il faut comprendre l’organisation de l’entreprise, la distribution des rôles, les adhérences avec d’autres composants du SI et d’accompagner le client dans la préparation de la fameuse « matrice de sécurité » !
Le constat
Aujourd’hui, il est très (trop ?) fréquent que j’entende :
« La sécurité, on y touche le moins possible car la dernière fois, on a tout cassé et il a fallu restaurer la plateforme. »
« Je dois intégrer les univers d’un nouvel éditeur, mais je ne comprends pas ce qui a été fait par mes prédécesseurs et je trouve ça trop risqué : aidez-moi ».
« Ma direction et le RSSI me demandent de présenter comment est sécurisé l’accès aux données de la plateforme BO : c’est un véritable casse-tête ! »
L’explication
Depuis l’arrivée de la CMC (à partir de BO XI) en remplacement du « Supervisor », la conception d’une matrice de sécurité explicite est devenue incontournable.
Mais à chaque évolution de leur plateforme (XI R1/R2/R3 → BI 4.x → 4.3+ -> 2025), nos clients n’ont pas toujours pris le temps d’implémenter les nouveautés et d’en tirer parti.
Résultats ?
- Un empilement historique de droits incohérents : présence +/- massive de droits « Avancés », droits contradictoires (Autorisé / Refusé) hérités de couches différentes, comportements imprévisibles selon l’utilisateur, dossiers publics profonds avec des droits différents à chaque niveau…
- Des utilisateurs ou des objets avec des droits directs, sans passer par des groupes ou en rompant les héritages (souvent issus de la XI et non revus depuis)
- Des groupes « fourre-tout » et un nommage non maîtrisé : mélange de notions métiers, techniques et applicatifs.
- Utilisation exclusive des niveaux d’accès par défaut, qui mélangent différentes couches de sécurité et donnent souvent trop de droits et compliquent les évolutions
- Sécurité applicative et sécurité du contenu entremêlées : on donne les droits à Webi via les droits sur des dossiers par exemple !
- L’utilisation de droits granulaires pour des refus explicites, bloquant toute évolution au risque de créer des « trous » de sécurité
Les causes sont multiples, les impacts aussi, mais ce que j’en retiens : les problèmes de sécurité dans SAP BI ne viennent pas d’une mauvaise version ou d’une mauvaise utilisation, mais d’une accumulation d’historiques, évolutions de l’outil et d’intervenants sans méthode documentée.
Chaque migration faite sans refonte de la matrice augmente la dette de sécurité, jusqu’au point où la plateforme devient imprévisible ou incontrôlable.
Besoins de visibilité et cas d’usage
La plupart du temps, le diagnostic est posé lorsqu’il s’agit de :
- Préparer une migration, conscient des points évoqués précédemment
- Intégrer un nouveau périmètre applicatif, avec des adhérences sur l’existant (pas un nouveau silo)
- Fusionner plusieurs environnements de production
- Opérer un changement fonctionnel : mono-société –> multi-sociétés
- Répondre à la question : “Qui a accès à quoi, et pourquoi ?” (audit, conformité RGPD,…)
Chez Seenovate, nos consultants sont en mesure d’adresser chacune de ces problématiques en s’adaptant à votre contexte et vos attentes.
Nous fixons ensemble les objectifs d’un audit établissant un état des lieux, un ensemble de préconisations et un plan d’actions associé. Dans certains cas, la mise en œuvre d’actions « flash » produit rapidement les résultats attendus pour sécuriser à la fois votre environnement et rassurer vos équipes.
Les enjeux de la maîtrise de la sécurité de vos environnements
Chez Seenovate, nous considérons que la sécurité sur une plateforme SAP BI n’est pas un simple paramétrage, mais un socle d’architecture et un outil de gouvernance. Avec une matrice de sécurité mal conçue, on se trouve confronté à :
- des droits implicites incontrôlés (effet cumulatif)
- des écarts entre environnements (DEV/REC/PROD)
- des risques RGPD (et l’accès illégitime à certaines données)
- des coûts de maintenance plus élevés
- des blocages lors des upgrades/migrations (4.x → 4.3 / 2025)
L’établissement d’une matrice vise donc à rendre le modèle de droits lisible, compréhensible, évolutif et transférable.
Grâce à cela, nous serons en mesure de (re) donner confiance dans la plateforme et sa pérennisation, et surtout réussir les projets de migration en y apportant une valeur ajoutée dans la durée.
Notre méthodologie pour bâtir une matrice simple, robuste et évolutive
Les principes fondamentaux
Chez Seenovate, nous sommes convaincus de la nécessité de dissocier les différentes couches d’objets à sécuriser, en utilisant des niveaux d’accès dédiés à chaque usage, appliqués à des groupes également spécifiques.
Il faut absolument être certain, lorsqu’on modifie ou qu’on affecte des droits, qu’il n’y aura pas d’effet de bord non maîtrisé.
De plus, la lisibilité doit être « totale » : règle de nommage précise des niveaux d’accès, des groupes, pour une lecture directe des droits de chaque utilisateur en consultant la page « Membre de… ».
Cette matrice et les modalités d’application doivent permettre à tout (nouvel) administrateur d’agir sereinement et en conformité avec ce qui est déjà en place, pour appliquer, recetter ou auditer les droits sur votre environnement : tout doit être documenté (principes généraux et mise en œuvre), et mis à jour à chaque changement !
Une approche par couche de la plateforme
Nous avons choisi de créer des unités de sécurité regroupant :
- un groupe
- un ou plusieurs niveaux d’accès
Spécifique à chaque couche à sécuriser. Ces couches représentent :
- les applications
- les connexions
- les univers (+ groupes spécifiques pour les restrictions/profils)
- les dossiers publics
Prenons l’exemple de plusieurs univers du domaine « Finance », sécurisés de façon identique (sans restriction au niveau de l’univers).
Dossier d’univers : Finance
Groupes d’utilisateurs : UNX-Finance-VàD (visualiser à la demande), UNX-Finance-Créa (créer ou modifier les requêtes dans Webi), UNX-Finance-Adm (Administrateurs/Designers d’univers).
Niveaux d’accès : UNX-VàD, UNX-Crea, UNX-ADM
Dans la CMC, vous avez compris que l’application est assez simple :
Le groupe UNX-Finance-VàD a le droit UNX-VàD sur le dossier d’univers Finance et ainsi de suite !
On utilise l’héritage de groupes pour permettre de n’ajouter aux sous-groupes QUE les droits supplémentaires par rapport au groupe parent.
Attention, il faut bien comprendre qu’un groupe ENFANT qui hérite de ses groupes PARENTS a + de droits, bien qu’en position « inférieure » d’un point de vue hiérarchique.
Il en est de même pour l’héritage de dossiers, avec une règle fondamentale : interdiction de rompre un héritage !
Il ne reste plus qu’à étendre et appliquer ce principe sur les autres couches du système, en respectant une règle de nommage universelle pour les groupes :
[type d’objet à sécuriser]-[objet à sécuriser]-[niveau d’accès]
Tout ceci doit rester aussi simple que possible à documenter dans la matrice (fichier Ms Excel généralement)
Comment la mettre en œuvre ?
D’une manière générale, il est indispensable de maîtriser les attentes et de planifier les interventions en fonction des calendriers métiers et périodes d’activités utilisateurs. Les évolutions d’univers ou des droits devront également être mises en pause pendant l’intervention.
La mise en œuvre d’une matrice de sécurité SAP BI dépend directement de votre environnement et du contexte projet. J’en ai identifié principalement trois :
- Environnement DEV + PROD (cas courant)
La matrice est conçue et déployée en environnement DEV qui doit être initialement une image fidèle de votre production (structure dossiers, groupes, et quelques documents dans l’arborescence pour la recette.).
Cela nous permet d’isoler parfaitement les cas de tests / scénarios métiers, de les recetter avant déploiement en PROD, sans pression ni risque de régression ou effet de bord non maîtrisé.
- Environnement de PROD uniquement (pas de migration prévue)
J’ai déjà rencontré ce cas régulièrement et cela nécessite une rigueur encore plus forte.
Et surtout, la mise en place doit être progressive : création et application de la nouvelle matrice en parallèle de l’existant, puis bascule des utilisateurs et objets (univers, documents) par périmètre. L’analyse préalable des adhérences et le lotissement sont primordiaux dans la réussite de cette transformation, où il faut absolument réduire le risque d’effets de bord en production.
- Migration vers un nouveau serveur
C’est le cas idéal pour repartir d’un modèle « propre » : construire une matrice cible « neuve » (arborescence, niveaux d’accès…), migrer le contenu SANS la sécurité existante, et déplacer le contenu dans cette arborescence pour hériter des nouveaux droits.
La maîtrise du timing est importante pour ne pas figer les évolutions trop longtemps ( « classique » dans un projet de migration).
Bien sûr, le risque zéro n’existe pas, mais la balance bénéfice/risque penche toujours du premier côté pour chacun des scénarios !
Avec quels outils ?
La mise en œuvre opérationnelle s’appuie principalement sur la Central Management Console (CMC), qui reste l’outil standard pour créer les groupes, définir les niveaux d’accès et appliquer les droits sur les dossiers, univers et connexions.
Cependant, dans des environnements complexes ou en refonte, nous proposons également l’intégration d’outils tiers comme Wiiisdom 360 Suite, qui apportent une valeur ajoutée significative : analyse globale de la sécurité, détection des incohérences, documentation automatique et accélération des audits. Ils facilitent également les phases de migration ou de nettoyage en offrant une vision transverse des droits souvent difficile à obtenir via la CMC seule.
Conclusion
Au fil des versions, la sécurité SAP BI s’est à la fois complexifiée et améliorée, rendant indispensable une approche structurée et maîtrisée, de la conception à l’implémentation sur vos environnements.
Sans matrice claire et standardisation de la méthode (ou intervenants au « coup par coup » sans vision globale), les environnements accumulent des incohérences, deviennent difficiles à maintenir et exposent des risques fonctionnels et réglementaires.
À l’inverse, une matrice bien conçue vous apporte lisibilité, maîtrise des accès et capacité à la faire évoluer sereinement, notamment lors des migrations. C’est pour nous également un gain de temps considérable au moment de la recette !
L’enjeu n’est donc pas seulement technique, mais bien organisationnel et stratégique : Il faut reprendre le contrôle du modèle de droits pour en faire un véritable levier de gouvernance.
C’est précisément là que Seenovate se distingue grâce à sa forte expérience terrain sur SAP BI, une méthodologie éprouvée et une approche pragmatique orientée usages métiers depuis de nombreuses versions.
Seenovate est donc en mesure d’accompagner efficacement tous types d’organisations, que ce soit en optimisation de vos serveurs existants ou en refonte complète (dans le cadre d’un migration ou non).
Ah, au fait : vous alliez me dire que j’ai oublié de parler plus spécifiquement de la BI 2025 ?
Non, car SAP confirme (cette semaine encore dans une “Live Session“) que RIEN n’a changé dans cette nouvelle version au profit de toutes les nouvelles fonctionnalités de Webi que j’ai présentées précédemment.
