TAXII : paginer sans perdre les ajouts du flux

Un client TAXII peut répondre « synchronisation réussie » tout en oubliant des objets. Le défaut apparaît souvent quand il utilise modified d’un objet STIX comme valeur de added_after, ou lorsqu’il avance son checkpoint avant d’avoir enregistré la dernière page.

Pour vérifier votre intégration, séparez deux problèmes : parcourir toutes les pages d’une requête et savoir d’où reprendre après une panne. Un curseur de pagination résout le premier. Un checkpoint durable et un stockage capable de rejouer les mêmes données résolvent le second.

La date du renseignement n’est pas la date du transport

Dans TAXII 2.1, added_after sélectionne les objets ajoutés après une date donnée à la collection. Cette date est indépendante des horodatages internes de STIX. Le manifeste expose date_added ; les en-têtes X-TAXII-Date-Added-First et X-TAXII-Date-Added-Last décrivent les bornes de la réponse. Ces règles figurent dans la spécification TAXII 2.1.

Considérez cet exemple fictif, où A et B abrègent des identifiants :

Un import démarré après le 11 octobre doit pouvoir récupérer A malgré son contenu ancien. Si votre filtre local rejette automatiquement les objets dont modified précède le dernier passage, A disparaîtra. C’est le cas à inclure en priorité dans un test de synchronisation.

Stockez les horodatages avec leur précision originale. Convertir une date en secondes entières pour simplifier la base peut déplacer une frontière de reprise. Conservez aussi une représentation lisible, mais ne l’utilisez pas comme clé technique.

Lire toutes les pages, puis confirmer le passage

Lorsque more vaut true, une réponse TAXII 2.1 peut fournir next. Le client transmet ce jeton dans la requête suivante avec les options d’origine. Sans jeton, la spécification prévoit un repli : utiliser X-TAXII-Date-Added-Last comme added_after, en gardant les autres filtres. Le document de tests d’interopérabilité OASIS décrit ces deux parcours.

Traitez next comme une valeur opaque. Ne le décodez pas pour construire un numéro de page et ne le réutilisez pas pour une autre collection. Le triplet racine API, collection, filtres doit rester associé au passage courant.

Une recette opérationnelle peut suivre ces étapes :

1. Charger le dernier checkpoint confirmé et les filtres de la tâche.
2. Demander la première page et vérifier son statut ainsi que sa structure.
3. Enregistrer les objets et les éventuels rejets de validation de façon durable.
4. Continuer selon more et les informations de continuation reçues.
5. Confirmer le nouveau checkpoint lorsque tout le passage a été traité.

Cette liste décrit un contrat de traitement, pas une implémentation transactionnelle imposée. Un stockage par page convient si le rejeu est sans effet supplémentaire. L’enjeu est de pouvoir expliquer ce qui se passe entre une écriture réussie et une panne du processus.

Tester les frontières qui font perdre des objets

Construisez une collection de test dont plusieurs objets partagent exactement le même instant d’ajout. Imposez une petite taille de page pour couper ce groupe. Vérifiez que la suite des réponses restitue tous les identifiants attendus.

Ce test est indispensable avec une continuation temporelle : une condition strictement « après T » ne récupère pas, par elle-même, les autres éléments datés de T. Si le serveur ne permet pas de parcourir cette frontière correctement, refaire aveuglément la même requête ne règle rien. Documentez l’écart et faites préciser le comportement par le fournisseur avant de déclarer l’import complet.

Testez aussi une page vide après une réponse annonçant encore des éléments. Une collection peut évoluer pendant la lecture. Le client doit enregistrer ce résultat et terminer ou signaler l’anomalie selon le contrat observé, sans entrer dans une boucle infinie. Ajoutez une protection contre un jeton répété sans progression.

Une fenêtre de recouvrement entre deux passages peut aider à rejouer des éléments de frontière. Elle augmente aussi le nombre de doublons à absorber. Elle ne répare ni une rétention expirée, ni une pagination défectueuse qui rend certains éléments inaccessibles.

Choisir explicitement les versions à conserver

Le filtre TAXII match[version] peut demander first, last ou all ; last est le comportement par défaut, selon la section sur les filtres de versions. Pour les objets STIX versionnés, une valeur précise correspond à leur horodatage modified. Le même identifiant peut donc désigner plusieurs états du renseignement.

Décidez si votre besoin est une vue actuelle ou un historique. Pour une vue actuelle, vous pouvez conserver le dernier état tout en archivant la provenance de chaque import. Pour un historique, demandez les versions pertinentes et vérifiez que le serveur les conserve effectivement. Aucun choix de paramètre ne recrée une version que le fournisseur a supprimée.

Une déduplication uniquement sur l’identifiant peut jeter une révision utile. Pour les objets STIX qui portent modified, testez une clé incluant ce champ. Pour les types sans ce champ, définissez une règle adaptée au type au lieu d’ajouter une date inventée.

Simuler la panne avant d’ouvrir le flux en production

Interrompez volontairement le client après l’enregistrement d’une page mais avant la confirmation du checkpoint. Au redémarrage, il doit relire ce qui est nécessaire sans créer une nouvelle alerte pour chaque objet déjà connu.

Refaites l’exercice avec un objet invalide. Deux décisions sont défendables : arrêter la fenêtre pour correction, ou isoler durablement l’objet rejeté et poursuivre selon une politique explicite. L’ignorer silencieusement rend le compteur « importés » trompeur. Le journal doit distinguer reçus, enregistrés, déjà présents et rejetés.

Le guide d’intégration continue TAXII vers un SIEM détaille l’environnement du connecteur. Les différences entre Indicator et Observed Data permettent ensuite de vérifier ce que deviennent les objets une fois transportés.

Avant de multiplier vos collections, rejouez ces cas sur une seule : ajout tardif, dates identiques, nouvelle version, panne intermédiaire et rejet de validation. Conservez le résultat attendu avec le connecteur. Vous disposerez alors d’un contrôle concret lors de chaque évolution du pipeline STIX/TAXII, au lieu de vous fier au seul nombre de réponses HTTP réussies.