OneAPI et flux de logs répondent à des questions différentes
L'OneAPI officielle de Zscaler reste l'interface centrale pour les données de configuration et de statut prises en charge, ainsi que pour les lectures et écritures contrôlées. Les flux de logs complètent cet état actuel avec les accès, l'activité des règles et les sessions réellement observés. C'est seulement ensemble qu'ils créent le contexte nécessaire à de nombreuses analyses historiques et opérationnelles.
Trois types de flux aux rôles clairs
NSS Web
Fournit les accès web, les actions, les catégories, les motifs de blocage, l'indice de risque de page, les signaux d'applications cloud, le volume de données et le contexte géographique.
NSS Firewall
Fournit le contexte des règles, les sessions autorisées et bloquées, la dernière utilisation, les services, les pays et les utilisateurs concernés dans le contexte pare-feu.
ZPA LSS
Fournit les sessions utilisateur et applicatives, le contexte des connecteurs, les signaux de plateforme et de localisation, ainsi que des métadonnées PRA sélectionnées.
Où cela crée une valeur produit concrète
- Helpdesk et utilisateurs finaux : User Support Center et Unified Support Center relient le statut de session, le contexte des connecteurs et les sites web bloqués à l'image utilisateur, appareil et politique existante. Les demandes issues du navigateur et du self-service parviennent ainsi au helpdesk avec un meilleur contexte de départ.
- Sécurité : les rapports montrent les accès bloqués, les évolutions temporelles, les catégories fréquentes, les répartitions de l'indice de risque de page, le Shadow IT, la géographie et d'autres signaux de risque disponibles.
- Administration et 2e niveau : la bande passante peut être classée par application, site, utilisateur et durée. L'activité des règles pare-feu appuie l'évaluation des règles inutilisées ou remarquables.
- Direction et MSP : des rapports condensés et des analyses liées au tenant créent une comparabilité, sans mélanger les contextes clients.
Réexaminer les modifications à la lumière de l'utilisation réelle
Pour les chemins de modification et de validation pris en charge, CentaurNexus peut évaluer les accès passés dans l'historique disponible. La rétrospective montre par exemple la fréquence d'une destination ou d'une catégorie, les décisions réellement prises et le nombre d'utilisateurs concernés. Un aperçu de modification s'appuie ainsi non seulement sur l'ensemble de règles actuel, mais aussi sur l'utilisation observée.
Source, ancienneté des données et couverture font partie du résultat
Une valeur sans état de la source peut facilement être mal interprétée. CentaurNexus indique donc toujours la source, le statut, l'ancienneté des données et la couverture. Les lacunes de flux et les données obsolètes restent visibles. Un flux manquant n'est pas présenté comme un zéro confirmé.
Un onboarding précoce crée plus tôt une base de comparaison
L'historique commence avec un raccordement fiable. Les accès et sessions antérieurs à ce moment ne peuvent pas être reconstitués après coup. Certaines analyses fournissent des résultats immédiats ; les schémas récurrents et l'activité des règles gagnent en pertinence à mesure que l'historique s'étoffe.
Cela vaut toujours dans les limites de la rétention réellement convenue. Les projections produit à finalité définie suivent leurs classes de données définies. Une rétention NSS/LSS supplémentaire ou différente n'est pas promise de façon générale et doit être définie explicitement pour le tenant et le périmètre d'exploitation concernés.
Intégrer NSS et LSS en parallèle des chemins de données existants
Là où le déploiement Zscaler le permet, un flux dédié alimente CentaurNexus en parallèle d'une connexion SIEM existante. CentaurNexus utilise NSS et LSS pour le contexte utilisateur, le reporting, l'évaluation des règles et la rétrospective des modifications.
La qualité du flux, c'est plus que « connecté »
Une connexion verte ne dit pas encore si un flux est complet et suffisamment à jour pour l'analyse concernée. Sont déterminants : la dernière réception, les volumes d'événements attendus et observés, le statut du parseur, le rattachement au tenant et la couverture de la période observée. CentaurNexus fait figurer ces caractéristiques avec le résultat, afin qu'une donnée incomplète ne ressemble pas à un constat complet.
Les changements de format doivent eux aussi être traités de façon visible. Si des champs manquent ou que leur signification ne correspond plus au contrat attendu, la plateforme ne doit en tirer aucun énoncé faussement précis. La partie concernée de l'analyse reçoit un statut de source traçable, tandis que les fonctions disponibles indépendamment continuent de fonctionner.
Un exemple issu du helpdesk
Un utilisateur signale qu'une application interne était accessible le matin et ne fonctionne plus ensuite. L'OneAPI peut fournir le contexte de configuration et de statut actuel. ZPA LSS complète avec les sessions réellement observées et le contexte des connecteurs disponible. NSS Web ou NSS Firewall peuvent apporter d'autres indices lorsque le déroulement touche aussi des trajets web ou pare-feu.
Le helpdesk voit ainsi plus qu'un instantané. Il peut situer le moment du problème par rapport à l'historique disponible et transmettre le cas au 2e niveau avec un constat compréhensible. L'énoncé reste lié à la couverture réellement disponible.
Un exemple issu de l'administration et de la sécurité
Pour évaluer une ancienne règle pare-feu, son nom ne suffit pas. NSS Firewall peut montrer si et quand elle a été utilisée dans l'historique disponible, quels services étaient concernés et si des sessions autorisées ou bloquées ont été observées. Ces informations appuient une décision humaine sur la prochaine étape de vérification.
Les équipes sécurité peuvent en même temps condenser dans le temps les accès web, les catégories, les décisions de blocage et les signaux de risque disponibles. Le rapport reste distinct d'une recherche dans les logs bruts : il répond à une question opérationnelle concrète et cite la source utilisée.
L'onboarding comme point de départ de la courbe de données
Pour chaque cas d'usage souhaité, il convient de déterminer au préalable quel flux est nécessaire, quels champs arrivent réellement et pendant combien de temps l'historique convenu reste disponible. Un démarrage précoce constitue cette base de comparaison plus tôt. Il n'augmente cependant pas rétroactivement le volume de données antérieur à l'onboarding et ne modifie aucune rétention définie contractuellement.
Concrètement, cela signifie : qui raccorde CentaurNexus tôt peut évaluer plus tôt, sur une période plus longue, l'utilisation récurrente, les schémas saisonniers et l'activité des règles. C'est précisément pourquoi la planification des flux fait partie du début de l'onboarding, et non de la fin d'une analyse ultérieure.
Quelles questions trouvent de meilleures réponses avec un historique croissant
Avec une base de données plus longue et cohérente, les comparaisons deviennent plus solides. Les équipes peuvent vérifier si un accès remarquable était isolé, si une application est utilisée régulièrement à certains moments, ou si une règle ne montre aucune activité observée sur plusieurs cycles d'exploitation. L'historique fournit du contexte, mais pas une décision automatique.
Pour la direction et les MSP, il en résulte des rapports de tendance traçables. Une comparaison ne doit mettre en regard que des tenants, périodes et sources dont la couverture est connue. Une qualité de flux différente ne doit pas être masquée par un indicateur apparemment uniforme.
La sobriété des données reste partie du contrat produit
Qu'un flux puisse fournir de nombreux champs ne signifie pas que chaque information brute doive être stockée durablement pour chaque fonction. CentaurNexus utilise des projections à finalité définie pour les analyses prises en charge. Classe de données, rattachement au tenant et rétention convenue déterminent le cycle de vie.
Cette séparation facilite le contrôle métier. Un client peut comprendre quelle analyse a besoin de quelle source et pendant combien de temps le contexte pertinent reste disponible. Les exigences supplémentaires sont convenues explicitement, plutôt que déduites tacitement d'une possibilité technique de flux.
- Définir l'accès OneAPI et les domaines Zscaler nécessaires.
- Connecter NSS Web, NSS Firewall et ZPA LSS en fonction des analyses souhaitées.
- Surveiller source, statut du flux, ancienneté des données, couverture et lacunes.
- N'interpréter les résultats que dans les limites de l'historique réellement disponible et convenu.
Questions fréquentes
L'OneAPI seule suffit-elle ?
Pour les données de configuration et de statut actuelles, l'OneAPI peut être la source déterminante. Pour l'utilité complète des analyses historiques décrites ici, les flux NSS et LSS adaptés sont également nécessaires.
Quels flux distingue-t-on ?
NSS Web fournit le contexte web et applications cloud, NSS Firewall l'utilisation des règles pare-feu, et ZPA LSS les signaux de session, de connecteur et certains signaux PRA sélectionnés.
Un SIEM existant doit-il être remplacé ?
Non. CentaurNexus peut être alimenté par un flux dédié en parallèle d'une connexion SIEM existante, dans la mesure où le déploiement Zscaler concret le prend en charge.
Pourquoi un onboarding précoce est-il avantageux ?
Parce qu'un historique solide ne se constitue qu'avec le raccordement des flux. Un démarrage plus précoce crée plus tôt une base de comparaison plus large, dans les limites de la rétention réellement convenue.
Qu'est-ce que NSS (Nanolog Streaming Service) chez Zscaler ?
NSS est le mécanisme de Zscaler pour diffuser des données de log détaillées, par exemple des transactions web ou des sessions pare-feu, depuis le cloud Zscaler vers un système récepteur, au lieu de n'afficher que des données condensées dans le portail d'administration. Il existe des types de flux NSS distincts pour différents types de trafic, c'est pourquoi CentaurNexus distingue NSS Web de NSS Firewall, plutôt que de traiter le flux de logs Zscaler comme une chose unique et générale.
Ai-je besoin d'une machine virtuelle dédiée pour recevoir les données NSS ?
Dans le déploiement standard de Zscaler, une appliance virtuelle exploitée par le client reçoit le flux NSS, le déchiffre et transmet le flux de logs vers sa destination, par exemple un SIEM ou, là où c'est pris en charge, CentaurNexus. Les détails exacts de déploiement dépendent de la configuration Zscaler concernée ; il vaut la peine de clarifier ce point concrètement pour votre propre tenant lors de l'onboarding.
Combien de temps CentaurNexus conserve-t-il l'historique NSS/LSS ?
La conservation suit ce qui est réellement convenu pour le tenant concerné, et non une valeur par défaut fixe applicable partout. CentaurNexus utilise des projections de données à finalité définie avec leur propre classe de données, et une rétention NSS ou LSS allant au-delà de l'accord standard n'est pas supposée automatiquement, elle doit être définie explicitement pour le déploiement concret.
Zscaler peut-il alimenter un SIEM ou un SIEM nouvelle génération ?
Oui, c'est exactement à cela que servent les flux NSS et LSS. Ils diffusent des données de log dans un format qu'un SIEM peut traiter, et comme il s'agit d'un export standard, le flux atteint généralement aussi les plateformes SIEM modernes ou nouvelle génération, la configuration exacte dépendant de ce qu'attend la plateforme réceptrice.
ZPA dispose-t-il d'un flux propre pour les données de session et de connecteur, comme NSS ?
Oui, c'est le Log Streaming Service, LSS en abrégé. Alors que NSS couvre l'activité web et pare-feu de ZIA, LSS couvre spécifiquement ZPA : sessions utilisateur et applicatives, contexte des connecteurs, ainsi que signaux de plateforme et de localisation, exactement les données que CentaurNexus utilise pour le volet Private Access du support et du reporting.
Sources et pour aller plus loin
Voir le workflow en contexte
Choisissez le rôle correspondant dans le lanceur de démo. La démo utilise des données d'exemple préparées.
Ouvrir le lanceur de démo