Surveiller les certificats sans gérer les clés privées

Sentinel n’accepte aucune connexion entrante. Il s’inscrit à l’aide d’un jeton valable pour toute l’organisation. Ce jeton est réutilisable, afin qu’un parc d’agents puisse s’inscrire automatiquement à partir d’une même image. Chaque instance de Sentinel génère ensuite sa propre paire de clés Ed25519 en local et n’en transmet jamais la partie privée. Après l’inscription, elle utilise Ed25519 et la RFC 9421 pour signer les requêtes de récupération des tâches, les rapports et les rotations de clés ; le jeton d’inscription ne sert plus à l’authentifier. Vous pouvez renouveler à tout moment le jeton de l’organisation : le précédent est immédiatement invalidé, sans perturber les instances de Sentinel déjà inscrites.

Lors de la création d’une organisation, Nocert lance une analyse publique unique du domaine situé après le signe @ dans l’adresse e-mail professionnelle que vous confirmez au moyen du code à usage unique. Le domaine saisi sur le site marketing est transmis à l’inscription et préremplit ce champ d’adresse e-mail professionnelle ; il n’est pas choisi séparément comme cible d’analyse. Un premier parcours des jeux de données publics de noms d’hôte fournit les cibles initiales. L’analyse ne contacte ensuite que les hôtes rattachés au domaine de l’adresse e-mail confirmée, depuis l’Internet public et sur des ports TLS, comme pourrait le faire tout observateur. Les hôtes ainsi observés sont réanalysés par la suite, et les noms d’hôte SAN appartenant au même domaine sont suivis. Pour étendre ce périmètre, une preuve de contrôle est nécessaire : toute nouvelle interrogation des jeux de données de sous-domaines, toute analyse de noms d’hôte importés depuis un connecteur DNS et tout ajout manuel de point de terminaison attendent que vous publiiez un jeton de vérification sous la forme d’un enregistrement TXT nocert-verify dans une zone que vous contrôlez. Seule une personne qui contrôle cette zone peut effectuer cette opération. La connexion au compte et la réinitialisation du mot de passe utilisent des codes à usage unique envoyés par e-mail et valables 20 minutes. L’authentification multifacteur TOTP est facultative.

Nocert analyse les données DER du certificat dans des sous-processus nsjail éphémères. Chaque processus dispose de ses propres espaces de noms réseau, utilisateur, montage et PID. La création de sockets est bloquée, /proc n’est pas monté, et des limites sont imposées au processeur, à la mémoire, au nombre de processus et aux fichiers produits. Dans un déploiement Custom auto-hébergé, l’application et l’analyseur de certificats s’exécutent sur l’infrastructure que vous contrôlez.

Nocert détermine l’organisation à partir de la session authentifiée. Il utilise des index Elasticsearch distincts pour chaque organisation et restreint les requêtes PostgreSQL à cette même organisation.

Vous pouvez désactiver indépendamment les analyses réseau, du système de fichiers, par écoute locale et Kubernetes. Le service Linux empaqueté s’exécute sous un compte dédié non privilégié, sans aucune capacité Linux, avec une unité systemd renforcée. Les analyses du système de fichiers sont limitées par les droits du compte de service de Sentinel. Vous fournissez les identifiants et les autorisations RBAC en lecture seule utilisés pour l’analyse Kubernetes.