Wabba-Sego

Votre politique de sécurité, gouvernée par votre propre modèle

Wabba-Sego orchestre chaque changement sur vos équipements de sécurité à partir d'un référentiel unique, votre modèle, et applique vos guardrails avant toute écriture. Conformité, risque et recertification sont mesurés en continu.

  • Aucune écriture hors d'un plan approuvé
  • Paramétré, sans développement
  • Déployé sur site, hors ligne
Le modèle au centre

Décrivez vos standards une fois. Chaque fonction les applique.

Le modèle de labelling est le référentiel de toute la plateforme. Wabba-Sego en déduit ce qui peut exister, l'emplacement de chaque règle et ce qui constitue un écart.

  • Catalogue et nommage

    Seuls les labels autorisés par votre modèle peuvent être créés ; les règles de nommage s'appliquent d'elles-mêmes.

  • Conventions de règles

    Un ruleset par application et par périmètre : chaque règle est écrite au bon endroit.

  • Guardrails

    Tableaux de flux autorisés sur vos types de labels et vos tags, ports et combinaisons interdits.

Votre modèle

  • Types de labels et tags
  • Règles de nommage
  • Catalogue des labels autorisés
  • Label groups et applications
  • Analyse de conformité

    Le PCE comparé à votre modèle à chaque synchronisation ; chaque écart est accompagné de sa correction.

  • Label groups gérés

    Membres des groupes alignés sur le modèle et corrigés par un plan.

  • Demandes de flux

    Des demandes par adresse IP traduites en règles par labels, conformes à vos conventions.

Paramétré à l'écran, sans développement spécifique : le modèle s'adapte à votre organisation, et non l'inverse.

Gouvernance

Vos guardrails, appliqués à chaque changement

UNIQUE*

Des guardrails contrôlés partout où une règle est créée

Chaque règle doit respecter tous vos tableaux de flux autorisés, vos ports interdits et votre modèle : à la vérification de flux, à l'import, à la remédiation, puis de nouveau au dry-run.

  • Tableaux de flux autorisés sur un type de label (environnements) ou un tag (couches).
  • Ports et protocoles interdits, chacun avec son motif.
  • Combinaisons de labels interdites, refusées à la création et signalées dans le PCE.
Tableau de flux autorisés Tiers : WEB vers DB non autorisé
Tableau « Tiers », sur le tag TIER : WEB → DB est refusé.

Des dérogations datées et justifiées

Une règle non conforme ne s'applique qu'avec une dérogation active, choisie par un utilisateur habilité.

  • Registre : code, motif, demandeur, date d'expiration et règles associées.
  • Visible de l'approbateur au dry-run, journalisée à chaque usage.
  • À l'expiration, les règles concernées doivent être recertifiées.
Registre des dérogations, avec leurs règles
Le registre des dérogations : une règle WEB → DB ne s'applique qu'avec une dérogation active.

Approbation et traçabilité

Approbation à quatre yeux lorsque votre organisation l'exige ; chaque action et chaque appel aux équipements enregistrés.

  • Rôles : prédéfinis ou personnalisés, droits vérifiés côté serveur.
  • Journal d'audit : qui, quoi, quand, depuis quelle adresse, avec quel résultat ; non modifiable, exportable.
  • Journal des échanges : chaque appel au PCE et l'action qui l'a déclenché, sans secret.
Journal d'audit : plan soumis par a.morgan, approuvé par s.patel depuis un autre poste, appliqué
Un plan soumis, approuvé deux minutes plus tard depuis un autre poste, puis appliqué.
Conformité et risque

Une conformité mesurée en continu, un risque rendu visible

Des écarts détectés à chaque synchronisation

Labels et règles de production sont comparés à votre modèle et à vos guardrails à chaque synchronisation de l'inventaire.

  • Labels hors catalogue, règles de nommage non respectées, combinaisons interdites.
  • Règles non conformes, trop larges, en double, désactivées ou sous dérogation.
  • Chaque écart mène à sa correction : un plan, ou une mise à jour du modèle.
Règles non conformes, avec ce qu'elles enfreignent et le lien Remediate
Chaque règle non conforme, avec ce qu'elle enfreint et le lien vers sa remédiation.

Analyse de risque et rapport de conformité

Un rapport PDF par instance, à la demande, prêt pour l'audit.

  • Une note de risque sur 100, calculée à partir de onze indicateurs pondérés.
  • Les dix applications les plus exposées.
  • Des recommandations priorisées, chacune avec la page où agir.
Rapport de conformité : note de risque 50/100, niveau élevé, indicateurs pondérés
Première page du rapport sur l'instance de démonstration : 50/100, risque élevé.

UNIQUE*

Des règles inutilisées identifiées, même sans trafic

L'analyse des règles repère celles qui ne servent plus.

  • Sans hit sur 90 jours par défaut, d'après le rapport Rule Hit Count du PCE.
  • Sans workload : un côté ne désigne plus aucun workload ni aucune IP list.
  • Nettoyage par un plan, avec une confirmation pour une règle encore utilisée.
Onglet Unused de l'analyse des règles : règles sans hit sur 90 jours, une règle sans workload
Règles inutilisées : sans hit, ou sans workload désigné.

La recertification de chaque règle de production

Chaque règle a une échéance, 12 mois par défaut, renouvelée à chaque recertification.

  • Recertification à l'unité ou en masse, avec un commentaire.
  • Les règles créées dans la console Illumio reçoivent une échéance dès leur synchronisation.
  • À l'expiration d'une dérogation, ses règles sont à recertifier.
Registre de recertification : deux règles expirées, deux bientôt à échéance
Le registre : deux règles expirées, deux à échéance sous 30 jours.
Orchestration

Des changements construits, simulés et appliqués en toute sécurité

UNIQUE*

De la demande de flux à la règle conforme

Les demandeurs continuent de formuler une source, une destination et un port, en adresse IP ou en nom de serveur.

  • Chaque adresse résolue en workload et en labels, ou en IP list.
  • Une couverture existante détectée, règles deny comprises.
  • La règle construite selon vos conventions et contrôlée par vos guardrails.
  • Jusqu'à 100 flux par fichier ; un fichier de demande prêt pour le ticket.
Règle à créer dans RS_PAYMENTS_PROD_PAR, extra-scope, avec une alerte des guardrails
La règle construite selon vos conventions, avec l'alerte des guardrails.

Un seul chemin vers l'équipement : le plan de changement

Préparer, dry-run, approuver, appliquer, tracer : la même séquence pour chaque changement, à l'unité ou en masse.

  • Plan périmé : si l'état de l'équipement ou l'impact a changé, rien n'est écrit.
  • Arrêt à la première erreur : les modifications en attente sont annulées et le rapport indique ce qui a pris effet.
  • Opérations en masse : labels, modes, IP lists, services, rulesets et règles, jusqu'à 20 000 workloads par plan.
Déroulé d'un plan : préparé, dry-run, soumis, approuvé par s.patel, appliqué
Le déroulé d'un plan, tel que la plateforme l'enregistre.

UNIQUE*

L'impact connu avant l'écriture

Pour chaque plan, Wabba-Sego relit la politique de production et calcule les flux coupés et ouverts.

  • Effet immédiat identifié ; analyse du trafic observé disponible en option.
  • Des règles proposées conservent les flux qu'un changement couperait, écrites avant le reste du plan.
  • Un impact à effet immédiat doit être reconnu avant que le plan ne se poursuive.
Flux coupés par le changement : critiques, effet immédiat pour deux d'entre eux
pay-app-01 transféré de Paris à Londres : trois flux coupés, avant toute écriture.

UNIQUE*

Une remédiation sans interruption

Une règle non conforme est corrigée en un seul plan, dans un ordre conçu pour préserver le trafic.

  • Créer et provisionner d'abord : la règle proposée qui conserve les flux.
  • Déplacer ensuite : les workloads reçoivent leurs labels corrigés.
  • Retirer en dernier : l'ancienne règle est désactivée ou supprimée.
Workloads de la règle : labels en cause entourés, nouveau label R_INT-APP pour hr-api-01
Le label en cause est corrigé : hr-api-01 reçoit R_INT-APP.

Un passage en enforcement maîtrisé

Un workload ne quitte le mode idle qu'avec un compatibility report récent et vert.

  • Rapport jaune bloquant, sauf forçage motivé par un utilisateur habilité.
  • Flux « potentially blocked » montrés au dry-run d'un passage en selective ou en full.
  • Un passage en full sans règle allow doit être reconnu.
Plan de modes : rapports rouge, absent et jaune bloquants, verts autorisés
Six workloads d'idle vers selective : trois bloqués, chacun avec son motif.
Différenciation

Six points forts sans équivalent connu*

  • UNIQUE*

    Un modèle de labelling au cœur de chaque fonction

    Nommage, catalogue et combinaisons interdites contrôlés sur tout le PCE et corrigés par des plans.

  • UNIQUE*

    Des demandes par adresse IP, des règles par labels

    Construites selon vos conventions, contrôlées par vos guardrails, appliquées par un plan.

  • UNIQUE*

    Des guardrails fondés sur votre modèle

    Tableaux de flux autorisés sur vos types de labels et vos tags, combinaisons et ports interdits, contrôlés partout où une règle est créée.

  • UNIQUE*

    L'impact connu avant l'écriture

    Pour un label ou un objet comme pour une règle : flux coupés et ouverts, calculés à partir de la politique, effet immédiat compris.

  • UNIQUE*

    Changer et remédier sans perdre de flux

    Des règles proposées préservent les flux qu'un changement couperait ; un ordre d'écriture conçu pour éviter toute interruption.

  • UNIQUE*

    Une politique maîtrisée dans la durée

    Règles inutilisées repérées même sans trafic, recertification à échéance, règles trop larges ou en double.

* Approche que nous n'avons pas trouvée dans la documentation publique d'Illumio Core, des autres solutions de microsegmentation ni des outils qui les administrent (octobre 2026).

Bénéfices

Bénéfices par profil

  • RSSI et direction

    • Une conformité mesurée et démontrée : rapports, registres et journaux.
    • Des guardrails appliqués à chaque changement ; chaque dérogation datée et justifiée.
  • Équipes réseau et sécurité

    • Des demandes de flux traitées sans changer la façon de les formuler.
    • Moins d'incidents : impact calculé et règles proposées avant tout changement.
  • Intégrateurs et MSSP

    • Une plateforme unique pour tous vos clients, strictement cloisonnés.
    • La gouvernance de chaque client appliquée de manière homogène.
Feuille de route

Intégrations et nouveaux modules

L'intégration ServiceNow et les modules firewalls étendent Wabba-Sego à votre circuit de demandes et au reste de votre parc de sécurité.

  1. Disponible

    Module microsegmentation

    Illumio Core

    • Modèle de labelling, guardrails et dérogations.
    • Vérification de flux, plans de changement et analyse d'impact.
    • Analyse de conformité et de risque, recertification.
  2. Prévu

    Intégration ServiceNow

    Ouverture de flux et implémentations du quotidien automatisées

    • Demandes de flux du catalogue de services traduites en règles conformes.
    • Plans reliés aux demandes de changement, approuvés dans ServiceNow ou Wabba-Sego.
    • Demandes clôturées avec le rapport du plan.
  3. Prévu

    Module Firewalls

    En complément de la microsegmentation

    • Le même modèle, les mêmes guardrails, les mêmes dérogations.
    • Vérification et ouverture de flux, impact, plans de changement.
    • Recertification et remédiation des règles non conformes.
  4. Ensuite

    Au-delà

    L'ensemble du parc de sécurité

    • Autres éditeurs de microsegmentation.
    • Proxies et SASE/SSE.
    • Authentification unique (SSO) et offre SaaS.

Feuille de route indicative, non contractuelle.

Plateforme

Conçue pour les entreprises et les MSSP, déployée sur site

  • Tenants cloisonnés

    Comptes, instances et données de chaque client strictement isolés.

  • Plusieurs PCE

    Production, préproduction et filiales dans un même tenant.

  • Rôles et approbation

    Rôles prédéfinis ou personnalisés ; approbation à quatre yeux, activable.

  • Anglais ou français

    Langue de l'interface au choix de chaque utilisateur ; rapports et fichiers en anglais.

  • Sur site, hors ligne

    Paquet signé ; machine virtuelle (OVA, VHDX) ou conteneurs Linux.

  • Accès protégés

    Double authentification, droits vérifiés côté serveur, HTTPS.

  • Secrets chiffrés

    Identifiants des PCE chiffrés en AES-256-GCM, jamais affichés ni journalisés.

  • Sauvegardes

    Chaque nuit et avant chaque mise à jour ; restauration testée à chaque version.

Prérequis techniques
Illumio Core
Sur site ou en SaaS.
Clé d'API
Rôle global, sans périmètre : Global Administrator ou Owner pour écrire. Une clé en lecture seule est aussi possible, les plans s'exécutant alors à la main.
Santé du PCE
PCE sur site.
Règles sans hit
Rule Hit Count activé : PCE 23.5.10 ou plus sur site, 24.2 ou plus en SaaS ; VEN 23.2.30 ou plus.
Règles deny dans les rulesets
PCE 24.2 ou plus.
Machine
2 processeurs et 4 Go de mémoire au minimum (4 et 8 Go recommandés), 40 Go de disque ; aucun accès à Internet nécessaire.
Licence

Une licence à l'usage, en unités d'œuvre

Wabba-Sego est licencié en unités d'œuvre (WU) : chaque opération utile qui réussit (calcul d'un plan, vérification d'un flux, production d'un rapport) consomme les unités prévues par votre licence. Une opération qui échoue n'est pas décomptée.

Le barème et le volume d'unités figurent dans votre proposition commerciale.

  • Sans frais : synchronisations, consultations, exports de listes, application d'un plan, nouveaux dry-runs.
  • Solde reporté d'une licence à la suivante.
  • Transparence : consommation détaillée par tenant, module et opération, visible dans la plateforme.
  • Renouvellement simple : le relevé de consommation signé se dépose dans le portail client.

Évaluez Wabba-Sego dans votre environnement

  1. Démonstration

    Sur vos cas d'usage et avec vos conventions.

  2. POC (preuve de concept)

    Déployé sur site, hors ligne et connecté à votre environnement, sur un périmètre défini ensemble.

  3. Bilan du POC

    Des objectifs fixés au départ, des résultats mesurés à la fin.