Proposition : tables pivot dans le moteur de requêtes

[dbarzin]

Le moteur de requête produit aujourd'hui deux types de sortie : des listes (OUTPUT list) et des graphes (OUTPUT graph). Pour l'exploitation de la cartographie, il manque une troisième forme très demandée : le tableau croisé (pivot), c'est-à-dire une vue agrégée d'une dimension en lignes contre une autre en colonnes.

Beaucoup de questions récurrentes — surtout côté sécurité — sont par nature des tableaux croisés que ni la liste ni le graphe ne rendent lisibles :

• la matrice réseau « qui parle à qui » entre zones ?
• le profil de topologie physique (quels types d'équipements sont reliés entre eux) ?
• combien de flux applicatifs par nature et par état de chiffrement ?
• quelles informations sensibles circulent chiffrées ou en clair ?

Proposition

Ajouter une clause PIVOT et une sortie OUTPUT pivot, en réutilisant les clauses existantes (FROM, WHERE, WITH, LIMIT).

Syntaxe

FROM <modèle>
[WHERE <conditions>]
PIVOT ROWS <champ> [COLUMNS <champ>] MEASURE <agrégat>
OUTPUT pivot

• ROWS : dimension en ordonnée.
• COLUMNS : dimension en abscisse. Optionnelle — sans elle, le pivot dégénère en simple liste agrégée (une dimension, une mesure).
• MEASURE : agrégat de cellule. count(*) pour commencer, extensible à sum(<champ>), avg(<champ>), min, max, count distinct.

Type d'axes déduit automatiquement (aucune option à saisir)

Le moteur déduit la forme du tableau, l'utilisateur n'a rien à préciser :

• Carré (matrice d'adjacence : lignes = colonnes = union des extrémités) lorsque ROWS et COLUMNS sont la paire source_X / dest_X du même X. Rectangulaire dans tous les autres cas (domaines différents, ex. nature × crypted).
• Symétrique (repliement A–B / B–A) lorsque le modèle est bidirectionnel (liens physiques) ; asymétrique lorsqu'il est directionnel (flux applicatifs et logiques), afin de préserver le sens des flux et de faire apparaître l'unidirectionnel.

Dimensions d'extrémité unifiées

Pour les modèles de flux et de liens, les extrémités sont aujourd'hui éclatées sur plusieurs clés étrangères (une source peut être une application, un service, un module, une base… selon le modèle). La proposition s'appuie sur des dimensions d'extrémité unifiées, résolvant l'unique extrémité renseignée :

• source_name / dest_name — le nom de l'entité d'extrémité,
• source_type / dest_type — son type (application, physical-server, workstation…),
• source_zone / dest_zone — pour les flux logiques, le rattachement du range IP à une zone/sous-réseau.

Exemples de requêtes

Chiffrement des flux applicatifs par nature — le pivot sécurité de base, fait ressortir les natures de flux qui circulent en clair (rectangulaire) :

FROM application-flows
PIVOT ROWS nature COLUMNS crypted MEASURE count(*)
OUTPUT pivot

Inventaire mono-dimension — répartition des liens physiques par type de médium (liste agrégée) :

FROM physical-links
PIVOT ROWS type MEASURE count(*)
OUTPUT pivot

Services réseau exposés — ports de destination ventilés par protocole (rectangulaire) :

FROM logical-flows
PIVOT ROWS protocol COLUMNS dest_port MEASURE count(*)
OUTPUT pivot

Matrice de flux inter-zones — la vue réseau « qui parle à qui » au niveau zone ; carrée et asymétrique (flux directionnels), lit les deux sens et la diagonale (trafic intra-zone) :

FROM logical-flows
PIVOT ROWS source_zone COLUMNS dest_zone MEASURE count(*)
OUTPUT pivot

Matrice applicative complète — les échanges nominaux entre applications, tous types d'extrémités confondus ; carrée et asymétrique :

FROM application-flows
PIVOT ROWS source_name COLUMNS dest_name MEASURE count(*)
OUTPUT pivot

Information sensible × chiffrement — quels types d'information circulent chiffrés ou non (rectangulaire) :

FROM application-flows
WITH informations
PIVOT ROWS informations.name COLUMNS crypted MEASURE count(*)
OUTPUT pivot

Topologie physique par type d'extrémité — profil de connectivité ; carrée et symétrique (liens bidirectionnels), met en évidence les liaisons anormales (poste ↔ poste, équipement ↔ stockage) :

FROM physical-links
PIVOT ROWS source_type COLUMNS dest_type MEASURE count(*)
OUTPUT pivot

Drill-down ciblé — tous les équipements raccordés à un switch donné, après un filtre de périmètre :

FROM physical-links
WHERE physicalSwitchSrc.name = 'SW-CORE-01' OR physicalSwitchDest.name = 'SW-CORE-01'
PIVOT ROWS source_name COLUMNS dest_name MEASURE count(*)
OUTPUT pivot

Bénéfices

• Cartographie : matrices de flux et d'adjacence directement exploitables, complémentaires de la vue graphe.
• Reporting : détection immédiate des flux non chiffrés, des informations sensibles en clair, des liaisons de topologie anormales.
• Réutilisation : compatible avec WHERE / WITH / LIMIT ; les résultats restent exportables (CSV) comme les listes ; intégrable aux requêtes sauvegardées (SavedQuery).

[oliboub]

Bonjour Didier,

C'est très intéressant.
Je ne suis pas sûr de visualiser, mais si l'idée est de faire du tableau croisé j'aurais une approche différente à proposer. A voir si ça fait sens.
C'est aussi pour aider les cartographes et les analystes.

Dans le temps, j'ai connu un outil de gestion de parc un peut différent des autres , et au lieu de proposer des reports figés ou pré établi, ils avaient utilisé un outil client de data warehouse.

Dans ton cas, les requêtes peuvent être exécutées par api, ce qui est génial. La plupart des gens ont leurs habitudes en tableau croisés ou data analyses: Excel, libre Office, python, r...
La question serait de pouvoir travailler avec n'importe quel outils directement sur le résultat d'une ou plusieurs requêtes.
Maintenant il faut être sûr que on puisse utiliser touts les données de cette manière.

Comme les règles de cartographes limitent le résultat aux droits, c'est déjà prêt.

Et aussi, un admin peut préparer les requêtes et les partager. Ensuite le cartographes fait les reports ou analyses de son choix, avec l'outil de son choix, même sans connaître Mercator. Si c'est une personne qui n'a besoin que d'accès aux outils (gestionnaire de risque, analyse d'évolution de buildings....)
J'espère être clair et que c'est en phase avec ta proposition.

Donc Mercator prépare les requêtes, comme un provider de source odbc ou api
L'outil externe consomme en fonction des droits et de son besoin.

[Luktos10]

Bonjour Didier,

De mon côté, je trouve la proposition pertinente et selon votre implémentation ça répondrai au besoin.
Serait-il possible d'avoir un rendu visuel (si c'est déjà dans la dev) ?

Bonne journée

[dbarzin]

Le rendu sera identique à ce qui existe déjà pour les listes.

[dbarzin]

Pour faire suite à la proposition d' @oliboub , on vient d'ajouter un bouton permettan de générer un lien de téléchargement signé.

Le lien exécute la requête à chaque accès, ne nécessite pas d'authentification et est valable 90 jours.
Cela permet de facilement importer les données dans une feuille de calcul et qu'elles se mettent à jour automatiquement.

[oliboub]

Merci Didier, c'est une fonctionnalité supplémentaire. Pas tout à fait ma demande, mais une possibilité de plus..

[oliboub]

Bonjour Didier,

### Doc
Peux-tu me dire à quoi sert le bouton format?

### Proposition optionnelle:
Quand on exporte, il faudrait peu-être un popup pour dire que le lien n'est valable que jusqu'à telle date. Car le format date de l'url n'est pas très exploitable..
Ça permettrait d'avoir l'information si on envoie le lien par mail à quelqu'un.

### Audit:

• Peut-on avoir la visibilité de tous les liens exportés , par qui et leur date de fin?
• Peut-on ajouter dans les logs ces informations:
  . qui a créé et quand
  . qui consomme, quand?
• Est-ce envisageable d'avoir un rôle pour pouvoir créer des liens ?

[dbarzin]

Doc

Peux-tu me dire à quoi sert le bouton format?

A remettre en forme la requête.

Proposition optionnelle:

Quand on exporte, il faudrait peu-être un popup pour dire que le lien n'est valable que jusqu'à telle date. Car le format date de l'url n'est pas très exploitable..

Oui, on regarde cela.

Ça permettrait d'avoir l'information si on envoie le lien par mail à quelqu'un.

Le lien est valable 90 jours par défaut.

Audit:

Peut-on avoir la visibilité de tous les liens exportés , par qui et leur date de fin?

On peut ajouter cela dans les logs.

Peut-on ajouter dans les logs ces informations:
. qui a créé et quand

Oui, dans les logs.

. qui consomme, quand?

La consommation est annonyme mais ont peut mettre l'IP dans les logs.

Est-ce envisageable d'avoir un rôle pour pouvoir créer des liens ?

Oui, cela semble légitime.

[oliboub]

Merci,

Je viens d'essayer format. j'ai compris.

• Petite proposition, (mais vraiment à réfléchir si utile)
  Changer l'ordre des boutons ,pour avoir à gauche la partie liée à la requete et à droite le copier url ( qui devrait apparaitre uniquemetn si on a les futurs droits)

• Je ne sais pas si ce serait utiile de générer un mot de passe et del 'ajouter pour télécharger le csv?
  Comme dans les partages de fichiers uniques sur internet..

[GlorfindelIldarion]

Bonjour,
cette fonctionnalité me semble très utile. C'est en effet important de pouvoir croiser des données sans les sortir de l'outil pour pouvoir auditer le SI.
A titre personnel, je me sers beaucoup des tableaux croisés précisément dans ce but.