Concevoir une plateforme multilocataire pour surveiller les menaces externes d’une organisation

Contexte

La protection contre les risques numériques — surveiller ce qui apparaît hors du périmètre d’une organisation : domaines sosies, sous-domaines oubliés, certificats faibles, usurpation de marque et identifiants indexés sur le web public — est une catégorie dominée par de grands fournisseurs aux prix opaques. Je voulais une plateforme de ce type qu’une équipe de sécurité canadienne puisse exploiter elle-même, ou qu’un fournisseur de services de sécurité gérés puisse opérer pour plusieurs clients. AEGIS DRP est cette plateforme : conçue comme le pendant externe des outils de sécurité interne que mon équipe bâtit, avec la même pile et la même discipline, et spécifiée comme un produit complet dès le premier jour plutôt que comme une collection de scripts.

Défi

Trois problèmes devaient être résolus ensemble. La détection devait reposer uniquement sur des requêtes publiques — DNS, recherche web, vérification de certificats — pour qu’analyser un domaine ne touche jamais la cible et ne ressemble jamais à une attaque. Chaque détection devait devenir un objet exploitable : une alerte avec une sévérité, un dossier avec un pipeline de statuts, une demande de retrait visant un registraire ou une plateforme réels. Et l’ensemble devait être multilocataire dès la première migration, parce qu’une plateforme de sécurité qui mélange les constats de deux organisations est pire que pas de plateforme du tout. Enfin, la composante IA devait servir l’analyste sans jamais prétendre être le détecteur.

Mon rôle

Fondateur, architecte et concepteur du produit. J’ai défini le modèle de menaces — quels signaux externes comptent et lesquels peuvent être recueillis sans toucher à la cible —, le modèle de données qui transforme ces signaux en constats, en dossiers et en demandes de retrait, et la spécification fonctionnelle par phases qui a ordonné la construction. J’ai choisi la pile et le modèle d’isolation, fixé la règle selon laquelle l’IA conseille mais ne détecte jamais, et dirigé le travail technique de la première migration jusqu’à la plateforme en service. La plateforme a été bâtie et est exploitée avec mon équipe chez SOFT M POWER CANADA.

Architecture / approche

Le modèle de données est venu en premier, posé en quatre migrations thématiques — socle multilocataire, puis surface d’attaque avec constats et dossiers, puis retrait et preuves, puis renseignement sur les menaces et marque — pour trente-cinq tables, huit énumérations, vingt et un types de constats et douze types d’indicateurs. L’isolation est appliquée dans la base de données : une seule fonction à privilèges définis résout l’organisation de l’appelant, et des politiques de sécurité au niveau des lignes l’imposent à chaque table liée à un locataire, de sorte qu’aucune page ne peut l’oublier. Les quatre moteurs d’analyse sont des fonctions serveur sans état qui renvoient leurs résultats au navigateur; l’analyste les examine et décide de ceux qui deviennent des alertes. La détection et la qualification humaine sont séparées à dessein.

Technologie

Application monopage React et TypeScript avec bibliothèque de composants et cache de requêtes; PostgreSQL avec sécurité au niveau des lignes, planification en base et appels HTTP sortants pour les exécutions quotidiennes; cinq fonctions serveur en TypeScript sur un environnement sans serveur : un générateur de typosquattage maison (sept techniques de permutation, plafond de 200 candidats, résolution DNS sur HTTPS par lots de 20), une analyse de surface d’attaque combinant enregistrements DNS, vérification TLS et exploration web avec captures d’écran, deux veilles fondées sur la recherche web pour les mentions de marque et les identifiants divulgués, et un copilote en continu relayé vers un grand modèle de langage hébergé dans le nuage par une passerelle, pour qu’aucune clé de fournisseur n’atteigne le client.

Exécution

La construction a suivi la spécification phase par phase, mon équipe travaillant sur une plateforme de développement assistée par l’IA à partir d’un cahier fonctionnel détaillé : socle et authentification, puis constats, dossiers et centre de commandement, puis rédaction des demandes de retrait et modèle de renseignement sur les menaces. Deux corrections visibles dans l’historique ont compté plus que n’importe quelle fonctionnalité. Le tableau de bord affichait au départ des chiffres de remplissage; il a été réécrit pour calculer son score de risque, sa tendance et ses répartitions uniquement à partir des données réelles du locataire. Et l’importation des actifs découverts par une analyse créait des doublons jusqu’à ce qu’un index unique sur organisation, type et valeur rende l’importation idempotente. La fonction de création des utilisateurs a aussi été durcie par un chemin de recherche verrouillé.

Contraintes

Aucune analyse active : seulement le DNS public, la recherche web publique, une consultation de certificat et l’exploration du site public, ce qui garde la plateforme du bon côté de la ligne mais limite ce qu’elle voit — pas de réseaux sociaux, de boutiques d’applications ni de sources du web clandestin aujourd’hui. Des services tiers sont utilisés pour la recherche web et la vérification des certificats, et le copilote transmet les échanges à un fournisseur de modèle infonuagique; rien de cela n’est caché à l’utilisateur. La remédiation est rédigée, pas exécutée : une demande de retrait est écrite pour le canal d’abus de la cible et suivie avec le dossier, et son envoi reste un geste humain. Les résultats des analyses planifiées ne sont pas encore conservés : c’est le prochain point de la feuille de route.

Leçons clés

1. Mettre l’isolation dans la base de données, pas dans les pages : une fonction qui résout le locataire et des politiques sur chaque table, c’est la seule conception qui survit à la croissance des fonctionnalités.
2. Séparer la détection de la qualification. Des moteurs sans état qui renvoient des candidats, et un humain qui décide de ce qui devient une alerte, donnent un produit plus net qu’une persistance automatique.
3. Un tableau de bord qui affiche des chiffres de remplissage est un passif; calculer à partir des données réelles dès la première version coûte moins cher que de retirer les faux plus tard.
4. Rendre les importations idempotentes avant de les rendre rapides : un index unique a réglé plus de problèmes de soutien que n’importe quelle fonctionnalité.
5. Dire exactement ce que fait l’IA. Un copilote qui conseille l’analyste a de la valeur; un copilote présenté comme le détecteur est une promesse que le code ne peut pas tenir.