Sécurité, gouvernance et déploiement des cubes

1. Principes généraux et segmentation des accès

La gestion des rôles et des accès constitue l’un des piliers de la sécurité dans tout environnement OLAP. Les cubes décisionnels, par leur nature multidimensionnelle, exposent des volumes de données très riches, souvent sensibles, parfois stratégiques. Sans un contrôle précis des autorisations, la frontière entre un usage analytique légitime et une divulgation d’informations confidentielles devient floue. Cette problématique dépasse le cadre technique : elle relève aussi de la conformité réglementaire (RGPD, normes ISO 27001, Sarbanes-Oxley, etc.), qui impose de documenter et de justifier toute logique d’accès.

Un cube OLAP intègre généralement des données issues de plusieurs sources : systèmes de gestion, applications financières, RH, CRM. Il est donc rare, pour ne pas dire dangereux, qu’un utilisateur ait besoin d’accéder à l’ensemble des axes analytiques. Il est généralement admis qu’un responsable régional ne puisse consulter que les chiffres de sa zone, sans pour autant avoir accès aux marges nationales ou aux salaires de ses homologues.

Ce principe de segmentation logique des accès se matérialise par la création de rôles, chacun regroupant un ensemble d’autorisations adaptées à un métier, un niveau hiérarchique ou une fonction.

Les rôles peuvent être appliqués à différents niveaux :

Une stratégie répandue consiste à aligner les rôles du cube sur les groupes métiers définis dans un annuaire d’entreprise...

1. Chiffrement et gestion des clés

Protéger un cube analytique revient, en pratique, à jongler avec trois dimensions étroitement liées :

Ces trois aspects sont interdépendants. Une configuration irréprochable du chiffrement ne servira à rien si un simple drill through permet de reconstituer des informations confidentielles. À l’inverse, un cloisonnement parfait mais sans rotation de clés laisse le système vulnérable à des fuites d’identifiants.

La première couche de sécurité repose sur le chiffrement, à la fois au repos et en transit :

Mais le chiffrement n’est qu’une partie du problème : la gestion des clés est souvent la véritable faille. Dans les environnements conformes aux bonnes pratiques, les clés sont tournées annuellement, voire semestriellement dans les secteurs réglementés. L’accès au coffre KMS est strictement séparé des rôles d’administration du cube. Ainsi, la personne qui gère les clés n’est...

1. Les fondations de la gouvernance BI

Gouverner un cube est avant tout savoir répondre sans détour à trois questions en apparence simples :

Que signifie exactement cette mesure ? Quelle est sa source ? Et qui en est responsable si elle s’avère fausse ?

Ces trois interrogations, souvent esquivées, définissent pourtant la maturité d’un dispositif BI. Lorsqu’elles restent floues, la confiance s’effrite : chacun interprète différemment un même indicateur, et les réunions se transforment en débats sémantiques.

Un glossaire métier vivant devient alors indispensable. On y trouve des définitions précises, chiffre d’affaires net (hors taxes, remises déduites), marge contributive (avec exclusions explicites), ou encore Vente (date de comptabilisation, règles de rattachement). Chaque entrée renvoie vers la mesure correspondante, la table source et le steward responsable.

Sur papier, cela semble administratif, mais en pratique, ce glossaire résout une grande partie des malentendus.

Un exemple : une équipe marketing et une équipe comptable utilisent toutes deux la mesure Ventes nettes, mais l’une intègre les avoirs tandis que l’autre les exclut. Le glossaire, lié directement au modèle, documente cette différence, et chacun sait alors à quoi s’en tenir.

Pour qu’il reste pertinent, ce glossaire doit vivre au même rythme que le modèle. Les bonnes pratiques consistent à l’intégrer dans le dépôt Git du cube, versionné au même titre que le code. Une description mise à jour à chaque modification assure la cohérence entre la sémantique métier et les formules techniques.

2. Traçabilité des calculs et gestion du changement

Ventes Net = SUM(FactVentes.MontantHT * TauxDeChange - Avoirs) 

1. Quand un cube rame

Le monitoring d’un cube OLAP ne se limite pas à surveiller la santé de son serveur. C’est une démarche qui s’appuie sur des indicateurs précis.

L’avantage principal des KPIs est qu’ils sont définis au niveau du serveur. Cela garantit une « version unique de la vérité » pour tous les utilisateurs, peu importe l’outil client qu’ils utilisent pour se connecter. Un exemple concret ? Un KPI peut mesurer la marge brute d’un produit en soustrayant le coût total du chiffre d’affaires, et la valeur de ce KPI sera toujours la même, que l’on y accède depuis Excel ou depuis un tableau de bord. C’est ce qui rend la surveillance des données si puissante et si importante pour la crédibilité d’un rapport financier.

Quelques situations des plus fréquentes :

Un cube qui semble lent n’est pas toujours mal conçu ou trop volumineux. Parfois, il est simplement « froid » (cache vide), confronté à un pic inhabituel de requêtes, ou encore traversé par une mesure coûteuse évaluée au mauvais moment.

La première étape consiste à établir une ligne de base. On collecte pendant quatre semaines :

-- P95 et moyenne journalière (4 semaines)
SELECT 
  CAST(StartTime AS date) AS JourUTC,
  COUNT(*)                  AS NbReq,
  AVG(CAST(Duration AS float))          AS LatenceMoy_ms,
  PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY CAST(Duration AS float))
     OVER (PARTITION BY CAST(StartTime AS date)) AS P95_ms
FROM dbo.OlapQueryLog
WHERE StartTime >= DATEADD(day,-28, SYSUTCDATETIME())
GROUP BY CAST(StartTime AS date)
ORDER BY JourUTC 

-- Sessions & connexions en cours
SELECT * 
FROM $SYSTEM.DISCOVER_SESSIONS;           -- qui est connecté, 
depuis quand
SELECT * 
FROM $SYSTEM.DISCOVER_CONNECTIONS;        -- connexions clients...