Collecteur de sécurité identitaire
Conçu pour les audits répétables
ETC Collector est le moteur de preuve derrière les revues Active Directory et Microsoft Entra ID d’EtcSec. C’est un collector en Go qui supporte le mode standalone local, le mode daemon enrôlé au SaaS, l’accès API REST et l’exécution récurrente sans agent sur les contrôleurs de domaine.
La documentation publiée le décrit comme un pipeline collection → parsing → analysis → graph → response, avec support LDAP ou LDAPS, SMB pour SYSVOL et GPO, Microsoft Graph API, sondes réseau optionnelles et sortie JSON structurée.
curl -fsSL https://get.etcsec.com/install-pro.sh | sudo bash -s -- --mode server --token="<verify-in-popup>"Vérifiez votre email dans le popup, puis copiez la commande server en une ligne avec un token à durée courte.
Community Edition : licence open-source Apache 2.0, gratuite pour tout usage y compris commercial. Pro Edition : licence propriétaire, incluse avec un abonnement EtcSec.
Pourquoi le collector est plus qu’un petit binaire d’audit
Collecte en lecture seule sur AD et Entra
LDAP ou LDAPS, SMB pour SYSVOL et lectures Microsoft Graph sont combinés dans le même workflow. Aucune mutation d’annuaire n’est requise pour récolter la preuve.
- Utilisateurs, groupes, ordinateurs, GPO, trusts, ACL et ADCS
- Applications, principaux de service, stratégies CA et rôles privilégiés
- Les sondes réseau restent des contrôles opt-in explicites
Moteur de détection modulaire
La documentation architecture décrit un système de providers et de détecteurs plugables avec exécution concurrente et analyse de graphes d’attaque sur les objets collectés.
- Exécution parallèle des détecteurs
- Sortie JSON structurée
- Support des graphes d’attaque dans les workflows Pro
Exploitation locale productive
Le mode standalone server expose une GUI locale et une API REST sur le port 8443, ce qui permet d’utiliser le collector sans dépendre du SaaS.
- GUI locale avec dashboard et historique des jobs
- API REST sous /api/v1
- Génération de JWT d’automatisation via le GUI token
Un collector qui monte aussi en flotte managée
Le mode daemon poll la plateforme SaaS, exécute les commandes, remonte l’état de santé et peut se mettre à jour, tout en gardant la collecte locale au client.
- Boucle de polling toutes les 30 secondes par défaut
- Stockage chiffré des credentials après enrôlement
- Conçu pour un collector par site ou domaine
Deux modes d’exploitation, un seul moteur de collecte
Utilisez le mode standalone server lorsque tout doit rester local, ou enrôlez le daemon lorsque la plateforme SaaS doit orchestrer et suivre le collector.
Ouvrir le popup de commande
Saisissez votre email, validez le code à six chiffres, puis copiez la commande server en une ligne avec un token temporaire.
Configurer les sources
Pointez le collector vers LDAP ou LDAPS, SYSVOL et éventuellement Microsoft Graph. Le mode daemon peut aussi recevoir sa configuration depuis la plateforme.
Lancer server ou daemon
Le mode standalone démarre la GUI locale et l’API. Le mode daemon s’enrôle dans la plateforme SaaS et poll les commandes tout en gardant la collecte locale.
Le collector est conçu pour être explicable en revue
Entrées en lecture seule
Les docs publiées décrivent LDAP ou LDAPS et la lecture SMB pour AD, plus les lectures Graph pour Entra. Le collector n’écrit pas dans ces systèmes pendant l’audit normal.
- Pas d’agent installé sur les contrôleurs de domaine
- Pas de mutation GPO ni annuaire
- Les sondes réseau restent opt-in
Contrôles d’exposition local-first
Le mode standalone lance une API et une GUI locales. En daemon, la GUI locale est bindée à 127.0.0.1 par défaut tant qu’un opérateur n’ouvre pas explicitement l’accès réseau.
- GUI et API standalone sur :8443
- GUI daemon désactivée sur les interfaces réseau par défaut
- L’automatisation JWT passe par le flux GUI token
Gestion des credentials et flotte
L’enrôlement stocke les credentials chiffrés localement. Les docs décrivent aussi le staging des mises à jour binaires et le redémarrage watcher en mode daemon.
- Le token d’enrôlement n’est pas stocké en clair
- Chemin unenroll best-effort
- Flux d’update automatique avec vérification de checksum
Comment ETC Collector tourne dans les vrais environnements
Mode standalone server
Lancez `etc-collector server` pour exposer la GUI locale et l’API REST. Ce mode est utile pour la revue locale, l’air-gap et les évaluations ponctuelles pilotées par API.
Mode daemon pour les collecteurs managés
Lancez `etc-collector daemon` après enrôlement pour poll la plateforme SaaS, exécuter les audits localement, et remonter résultats et état de santé centralement.
API et automatisation
L’API locale sous `/api/v1` supporte la création de JWT et les lancements d’audit programmatiques, ce qui rend le collector exploitable depuis scripts, SIEM et pipelines CI.
Suivi central via EtcSec
Le collector reste local à l’environnement, tandis qu’EtcSec apporte la couche dashboards, scheduling et suivi historique pour les organisations qui en ont besoin.
Couverture et interfaces exposées par le collector
Providers de détection
Active Directory
Actif · 340 détections · Community et Pro / FullMicrosoft Entra ID
Actif · 158 détections · Community et Pro / FullModes opératoires
API standalone
ActifExécutez ETC Collector localement avec la GUI web embarquée et l’API REST sous `/api/v1`, sans dépendre de la couche SaaS.
Daemon SaaS
ActifEnrôlez le collector dans EtcSec pour poll les commandes, exécuter les audits localement, et remonter santé et résultats de façon centrale.
Comment la documentation présente ETC Collector comme un produit et pas seulement un binaire
La doc du collector permet d’évaluer directement la forme du produit : architecture, providers, modes de déploiement, comportement API et articulation entre Community et la plateforme EtcSec.
Standalone server versus SaaS daemon
Le mode standalone est utile lorsque tout doit rester local ou lorsque l’équipe sécurité veut automatiser directement autour de l’API locale. Le mode daemon est utile lorsqu’une équipe centrale veut piloter plusieurs collectors répartis sur plusieurs sites ou domaines sans renoncer à la collecte locale.
Surtout, les deux modes partagent le même moteur de collecte. La différence porte sur l’exploitation et l’observation du workflow, pas sur la qualité de la preuve.
| Mode | Ce qu’il fait | Cas idéal |
|---|---|---|
| Serveur standalone | Expose une interface web locale et une API REST sur le port 8443 sans dépendance SaaS | Air gap, usage purement local ou évaluations ponctuelles pilotées par API |
| Daemon SaaS | Interroge la plateforme pour récupérer les commandes, exécute localement et remonte les résultats et l’état de santé | Flottes managées, audits récurrents, exploitation multisite |
L’architecture publiée est collection, parsing, analyse, graphe, réponse
La documentation architecture décrit explicitement un système de providers et de détecteurs plugables avec exécution concurrente. C’est utile côté produit parce que cela montre qu’ETC Collector n’est pas un simple script ad hoc, mais un moteur d’audit modulaire avec abstraction provider et analyse de graphes.
Pour les opérateurs, le bénéfice pratique est la clarté. Vous pouvez expliquer exactement ce que fait le collector, quels objets il collecte et comment les findings émergent de ces objets. C’est plus défendable en change control qu’un message flou du type “faites-nous confiance, ça scanne le domaine”.
Ce que le collector collecte réellement et pourquoi cela compte
Ce mix de sources explique pourquoi le collector peut parler à la fois de configuration d’identité et des contrôles autour de l’identité. Il ne s’arrête pas aux métadonnées d’annuaire ; il remonte aussi jusqu’aux couches policy et GPO qui rendent le vol de credentials ou l’exécution distante faciles.
| Source | Exemples | Pourquoi c’est utile |
|---|---|---|
| Active Directory via LDAP | Utilisateurs, groupes, ordinateurs, trusts, domaines, ACL | Relations d’identité et de privilège cœur |
| SYSVOL via SMB | registry.pol, GptTmpl.inf, scripts | Visibilité GPO, durcissement et fuite de credentials |
| Microsoft Graph API | Utilisateurs, groupes, applications, stratégies CA et affectations de rôles | Posture cloud et sécurité du plan de contrôle |
| Sondes optionnelles | Spooler, TLS, DNS ou web enrollment | Détection relay et transports faibles |
Où l’édition Community s’arrête et où les workflows plus riches commencent
La différence produit importante n’est pas seulement un feature gate. Elle tient à la question suivante : avez-vous seulement besoin du moteur de collecte, ou aussi de la couche d’exploitation autour avec dashboards, orchestration multi-sites et suivi de remédiation ?
| Capacité | Community | Pro / EtcSec |
|---|---|---|
| Détections Active Directory | Oui | Oui |
| Détections Microsoft Entra ID | Oui | Oui |
| Mode local standalone | Oui | Oui |
| Gestion daemon côté SaaS | Fonctionne avec EtcSec | Oui |
| Analyse ADCS ESC | Etendue dans les workflows Pro | Oui |
| Analyse graphe d’attaque | Etendue dans les workflows Pro | Oui |
| Dashboards, historique, scheduling | Non | Oui |
Pourquoi la surface API et le flux daemon comptent en pratique
Le standalone server expose `/api/v1` et supporte la génération de JWT via le GUI token. Cela rend le collector exploitable depuis scripts, pipelines CI ou intégrations SIEM. Le flux daemon ajoute le reporting de santé, les commandes distantes et la gestion des mises à jour pour les équipes qui gèrent plusieurs collectors.
Le collector reste ainsi exploitable pour des revues récurrentes, des workflows scriptés et des déploiements local-first, sans perdre le contrôle sur la collecte.
Là où EtcSec apporte plus que le collector seul
Le collector est le moteur de preuve. EtcSec ajoute dashboards, trending historique, scheduling et une couche d’exploitation plus large pour les équipes qui ont besoin d’un suivi central plutôt que d’une exécution locale seule.
- Suivi historique et revue de tendance
- Orchestration multi-sites
- Scheduling d’audits récurrents
- Dashboard et workflow de remédiation
- Visibilité transversale au-delà du JSON local
- Couche centrale autour du même moteur de collecte
Explorez les pages identité liées à ce sujet
Explorez les pages détaillées sur Active Directory, Entra ID, ETC Collector et les comparatifs outillés.
Consultez la landing page dédiée au Tier 0, à Kerberos, à la délégation, à ADCS et aux priorités de remédiation.
Consultez la page Entra ID pour Conditional Access, MFA, PIM, permissions applicatives et exposition des invités.
Comparez PingCastle à ETC Collector pour des audits AD récurrents et des workflows de collecte en mode standalone.
Comparez Purple Knight à ETC Collector pour des revues AD et Entra ID avec suivi récurrent.
Examinez ETC Collector, ses modes de déploiement locaux et la façon de lancer des audits standalone ou récurrents.
Explorez le collector avant de décider jusqu’où l’industrialiser
Commencez avec le collector open-source si vous avez besoin d’une collecte locale. Ajoutez EtcSec lorsque ce même moteur doit aussi fournir dashboard, scheduling et suivi central de remédiation.