Più server significano più configurazioni e aggiornamenti da coordinare.
Intervenire macchina per macchina richiede tempo; aggiornare tutto insieme aumenta il rischio operativo.
Una flotta di server, una sola console. Aggiornamenti che non brickano niente.
Governa decine di agent da un unico punto: ogni server esegue un agent leggero in Go, connesso al server centrale via gRPC mTLS. Gli aggiornamenti partono su un sottoinsieme canary e proseguono sul resto della flotta solo se il canary resta sano — così un update difettoso non porta giù tutti i tuoi server.
Canary anti-brickmTLS end-to-endWatchdog
Porta stato e aggiornamenti in un'unica console.
Ogni agent comunica in modo autenticato e le nuove versioni partono prima su un gruppo canary.
Gestione più semplice, rollout con impatto contenuto.
Se il canary non torna sano, la distribuzione si ferma prima di raggiungere il resto della flotta.
Onboarding guidato
Dal nuovo server al primo heartbeat, senza ricostruire la procedura.
Dal pannello crei il server, assegni un nome riconoscibile e ottieni la credenziale dell'agent. La scheda di installazione prepara il comando da copiare e conserva le istruzioni operative nello stesso punto.
- Credenziale per agent visibile soltanto ai ruoli autorizzati.
- Comando d'installazione pronto e guida per servizio, log, firewall e configurazione.
- Stato di registrazione e ultimo contatto subito visibili nella console.
Console unica
Tutta la flotta, sotto lo stesso vetro.
Ogni server protetto esegue un agent leggero in Go che si connette al server centrale via gRPC mTLS e invia un heartbeat ogni 30 secondi. La dashboard raccoglie tutto in un colpo d'occhio: hostname, versione dell'agent, stato di connessione e stato dell'aggiornamento.
- Stato per server: attivo, offline o pending, in tempo reale.
- Versione e update_state di ciascun agent: idle, updating, updated o failed.
- CPU, RAM, disco e uptime del sistema e dell'agent nella scheda del server.
- Nessun agente cieco: chi smette di battere heartbeat si vede subito.
Linux e Windows
Un'unica console, con capacità adattate al sistema.
Linux è la piattaforma completa per reverse-proxy WAF, watcher web, antivirus e FIM. L'agent Windows copre inventario, heartbeat, eventi di autenticazione e blocco tramite Windows Firewall.
Linux · protezione completa
WAF, rate-limit, geo e reputation, SSH, Nginx/Apache, watcher personalizzati, scansioni file, FIM e firewall iptables/ipset.
Windows · host monitoring
Event Log di sicurezza, tentativi di logon, blocchi inbound/outbound con Windows Firewall, stato e connessione al server centrale.
Stesso piano di controllo
Identità dell'agent, heartbeat, eventi e gestione centrale restano coerenti; la disponibilità dei singoli moduli dipende dal sistema operativo.
Aggiornamenti canary anti-brick
Prima un assaggio, poi tutta la flotta — o niente.
Quando pubblichi una nuova versione, Sentinel non aggiorna tutto in blocco. Sceglie i candidati — agent online, connessi e con versione diversa dal target — e li divide: un canary pari a ceil(canaryPercent%) (default 20%, minimo 1). Il resto della flotta viene promosso solo se tutti i canary raggiungono la versione target ri-registrandosi con la nuova build. Altrimenti si abortisce e il resto non viene toccato.
- Split deterministico: default 20%, sempre almeno un canary.
- Timeout onesti: 15 minuti per il canary, 30 per il resto.
- Anti-brick: se il canary non passa, il resto della flotta resta sulla versione precedente.
Come funziona il canary
Quattro passaggi, un solo obiettivo: non brickare niente.
Il rollout segue sempre la stessa sequenza deterministica, ondata dopo ondata.
01
Split
Si selezionano i candidati — agent online, connessi e con versione diversa dal target — e si estrae il canary: ceil(canaryPercent%), default 20%, minimo un agent.
02
Canary
Il canary riceve l'update per primo. Ogni agent scarica, verifica e installa in locale, poi si ri-registra al server centrale con la nuova versione.
03
Verifica salute
Si attende che tutti i canary raggiungano la versione target entro il timeout di 15 minuti. Se anche uno solo non ce la fa, il rollout si abortisce.
04
Promozione o stop
Canary sano: il resto della flotta viene aggiornato (timeout 30 minuti). Canary fallito: abort, e il resto resta sulla versione precedente.
Watchdog & auto-recovery
L'agent che si rialza da solo.
Ogni update passa da controlli non negoziabili e da un watchdog che veglia sull'agent. L'updater verifica checksum SHA256 e firma Ed25519 del manifest — un manifest non firmato viene rifiutato — scarica solo via HTTPS con un tetto di 200 MiB, fa backup e replace atomico e, se il nuovo binario non parte entro 60 secondi, esegue un rollback locale automatico.
- Verifica obbligatoria: SHA256 + Ed25519, altrimenti l'update non parte.
- Watchdog ogni 30s: dopo 3 fallimenti riavvia il componente e lo segna "recuperato".
- Rollback locale all'agent: la protezione non cade mai per un update andato storto.
Comunicazione mTLS
Ogni agent si autentica, in entrambe le direzioni.
Il canale tra agent e server centrale è mutuo: il server verifica il certificato di ogni agent (RequireAndVerifyClientCert) e l'agent verifica quello del server. Niente client anonimi, niente comandi da un server che non è il tuo.
mTLS bidirezionale
Il server accetta connessioni solo da agent con certificato valido; l'agent parla solo con il server centrale che riconosce. L'autenticazione è reciproca, non a senso unico.
TLS 1.2 minimo
Il canale gRPC impone TLS 1.2 come versione minima: nessun downgrade a protocolli obsoleti tra agent e server centrale.
Riconnessione con backoff
Se il collegamento cade, l'agent ritenta con backoff progressivo, senza martellare il server e senza restare orfano dalla console.
Failover HA
Con più endpoint configurati, l'agent effettua failover in alta disponibilità: se un server centrale non risponde, passa al successivo.
Come si scala
Da un server a una flotta, senza cambiare metodo.
Il modello è lo stesso a 3 o a 30 agent: un rollout alla volta, difesa condivisa e ridondanza sul server centrale. Alcuni limiti li diciamo apertamente — lo stato del rollout è in-memory, quindi un restart del server centrale perde il monitor: al riavvio il Reconcile marca "failed" gli agent rimasti stuck e il rollout va rilanciato. E non esiste rollback a livello di flotta: il rollback è locale all'agent.
Un rollout alla voltaDifesa collettivaFailover HA
Domande frequenti
Quello che di solito ci chiedono sulla flotta.
Un aggiornamento può brickarmi i server?
È esattamente ciò che il canary evita. L'update parte su un sottoinsieme (default 20%, minimo 1 agent) e prosegue sul resto della flotta solo se tutti i canary raggiungono la versione target entro 15 minuti. Se il canary fallisce, si abortisce e il resto dei server non viene toccato.
Come vengono scelti i canary?
I candidati sono gli agent online, connessi e con versione diversa dal target. Da lì si estrae il canary con ceil(canaryPercent%), default 20% e comunque almeno uno. Gli altri restano in coda finché il canary non è verificato sano.
C'è un rollback di flotta?
No, e lo diciamo chiaramente: il rollback è locale all'agent — se un nuovo binario non parte entro 60 secondi, quel singolo agent ripristina la versione precedente da solo. A livello di flotta non c'è un rollback centralizzato: la protezione sta nell'evitare la promozione, non nel disfarla dopo.
Cosa succede se riavvio il server centrale durante un rollout?
Lo stato del rollout è in-memory, quindi il monitor si perde. All'avvio il Reconcile marca "failed" gli agent rimasti stuck e il rollout va semplicemente rilanciato. Nessun agent resta a metà in modo silenzioso.
Come faccio a fidarmi del binario che arriva?
Ogni update verifica checksum SHA256 e firma Ed25519 del manifest: un manifest non firmato viene rifiutato. Il download avviene solo via HTTPS con un limite di 200 MiB, con backup e replace atomico prima dello switch.
Vuoi vedere la flotta in azione?
Ti mostriamo Sentinel dal vivo sulla tua infrastruttura: console unica, rollout canary anti-brick e watchdog, tarati sui tuoi server.