Lancer et exploiter

En bref

Cette page est le mode d’emploi minimal du moteur de monitoring : le lancer en local, livrer une nouvelle version, revenir en arrière et débloquer un scan qui traîne. À retenir : la livraison est manuelle, depuis un poste de développeur, sans déploiement automatique. En cas d’incident, enclenche d’abord l’arrêt d’urgence avant toute restauration de données. Rien ne surveille les files des échecs : consulte-les dans Cloudflare.

Fonctionnement

En local. Un développeur installe le projet, prépare la base locale et lance le programme sur sa machine ; les tests utilisent une base simulée en mémoire. Les clés des fournisseurs sont facultatives : un scanner sans clé utilisable est sauté. Les tâches planifiées ne se déclenchent pas en local. Pour piloter le monitoring depuis le backend, il faut renseigner son adresse et son jeton d’accès dans la configuration du backend. Commandes : section « Pour les développeurs » plus bas.

Déploiement. Manuel, depuis un poste de développeur, en une seule commande qui enchaîne trois choses : rafraîchir les plages d’adresses de CloudFront (avec repli sur une liste versionnée), mettre à jour la base de données, puis publier le programme. Aucune intégration continue (CI) ne déploie le monitoring.

Tâches planifiées. Toutes en UTC. Une étape en échec est journalisée et n’arrête pas les autres. Horaires, files et arrêt d’urgence : planification. Le planning côté backend est un autre fichier.

Règles et pièges

• Une publication écrase les variables saisies à la main dans le tableau de bord Cloudflare : toute variable non secrète doit être dans le fichier de configuration. Les secrets se posent par commande ; rotation dans Secrets et clés.
• Les jeux de données de détection (technologies reconnues, fins de vie des logiciels) sont compilés dans le programme : fusionner la mise à jour hebdomadaire ne déploie rien avant la prochaine publication.
• Les deux files d’attente (fuites de données, instantanés), leurs files des échecs et la base du monitoring doivent exister dans le compte Cloudflare.
• Files des échecs. Rien dans le code ne les lit : consulte-les dans Cloudflare. Réessais et délais : files et reprises.
• Retour arrière du code : annuler la dernière publication ou republier un commit antérieur.
• Retour arrière des données : la base permet de revenir à la minute près sur 30 jours. Les trois dernières migrations de données ont des scripts d’annulation manuels. Enclenche d’abord l’arrêt d’urgence (depuis l’admin du backend, ou par un appel direct), laisse les files se vider, exécute le script, puis republie l’ancien code. N’applique jamais un script seul.
• Coffre de clés : gère les clés dans l’admin du backend, page des clés d’API du monitoring. Changer la clé de chiffrement du coffre rend toutes les clés stockées illisibles : il faut les ressaisir.
• Scan bloqué (un scan de courtier reste « en cours ») : le monitoring clôt seul cibles et scans à leur délai limite (voir files et reprises). Si rien ne bouge, vérifie l’arrêt d’urgence, l’adresse et le jeton d’accès du monitoring, et l’accumulation de tâches dans la file des instantanés.
• Monitoring hors service : les appels du backend échouent et la page de santé aussi. Vérifie cette page, les logs Cloudflare, puis l’arrêt d’urgence. L’alerte Slack « garde aveugle » est un autre cas : usage Cloudflare illisible, voir planification.

Pour les développeurs : commandes

npm ci            # Node 24 or newer (.nvmrc)
npm run db:migrate:local
npm run dev        # wrangler dev, port 8787
npm run typecheck && npm test
npm run deploy:full

• Secrets locaux : fichier .dev.vars (ignoré par git) avec SCANNER_TOKEN, ou MONITORING_API_TOKEN qui a priorité. Côté backend : MONITORING_API_URL et MONITORING_API_TOKEN.
• deploy:full enchaîne le rafraîchissement CloudFront, db:migrate:remote puis wrangler deploy. Secrets : wrangler secret put <NAME>.
• Retour arrière : npx wrangler rollback. Données : wrangler d1 time-travel restore, scripts monitoring/scripts/rollback-0061.sql à 0063. Arrêt d’urgence : POST /api/v1/admin/emergency-stop. Clé du coffre : KEY_VAULT_KEY.
• Files : intelx-jobs et snapshot-jobs, avec leurs -dlq ; base D1 inqase-monitoring. Page de santé : GET /up.

Où dans le code

• monitoring/package.json et monitoring/wrangler.toml
• monitoring/src/transport/cron/scheduled.ts et monitoring/src/transport/queue/router.ts
• monitoring/scripts/

Questions ouvertes

• Qui peut déployer, depuis quelle machine, et un déploiement CI est-il prévu ? Rien ne le documente.
• Le retour arrière du code et la restauration de la base à une date passée sont-ils la procédure testée ? Les deux sont non testés.
• Qui surveille les files des échecs, et avec quelle procédure ?