C’è un paragone calzante: pensate a centinaia, migliaia di chiavi alfabetiche statiche sparse su porte diverse. Ognuna di queste chiavi permette ad altre macchine e servizi di entrare, parlare, leggere e scrivere dati, ma — proprio come le chiavi fisiche — se cadono, vengono dimenticate, usate male, rappresentano un rischio enorme.
Questo problema, che per anni è stato tollerato come “inevitabile” in ambito IT, è quello che Hush Security vuole risolvere. In realtà, la sua proposta è quella di liberare le aziende dal peso, dal rischio e dalla fragilità delle chiavi statiche (API key, token, credenziali per servizi) — sostituendole con un sistema più dinamico, policy-based, “on demand”.
Fondata nel 2024 da una squadra che già aveva esperienza (gli stessi che avevano creato Meta Networks, poi acquisita da Proofpoint), Hush emerge oggi dal silenzio (stealth mode) con un round seed da 11 milioni di dollari, guidato da Battery Ventures e YL Ventures.
L’idea non è astratta: viene da una frustrazione concreta, di chi ha vissuto in prima persona le difficoltà legate alla gestione delle credenziali macchina a macchina. Oggi, in un’azienda moderna, non bastano poche chiavi: ogni microservizio, pipeline automatizzata, modello di intelligenza artificiale, agente digitale richiede credenziali di accesso. Sono tante, sparse, difficili da tenere sotto controllo.
Quando si parla di credenziali statiche si intende:
- Chiavi o token che non cambiano, se non manualmente;
- L’assenza di contesto: non c’è modo – o lo sforzo è enorme – per sapere quando, da dove, da quale macchina o processo la chiave è usata;
- La fragilità intrinseca: se la chiave finisce in un log, su GitHub, in configurazioni errate, chiunque la può usare, se riesce a procurarsela;
- La rotazione manuale: creare nuove chiavi, aggiornare ogni pezzo di software che ne ha bisogno, testare che non si rompano i flussi, coordinare team diversi… spesso un incubo operativo.
Col crescere della complessità (microservizi, deploy continui, infrastrutture ibride, AI e agenti) cresce anche il numero di chiavi. Tenere traccia, capire a cosa servono, cosa succede se una viene compromessa, diventa quasi ingestibile.
Hush propone non solo di mitigare il problema, ma di cambiarne radicalmente l’approccio. Ecco come:
- Accesso “just-in-time” / “on demand”: le macchine ottengono il permesso di accesso solo quando serve, non permanentemente. Se non serve, non c’è accesso.
- Politiche (policy) che regolano chi può parlare con chi: non più “dato un token valido, puoi entrare ovunque”, ma “questa specifica macchina, in questo contesto, può accedere a questo servizio, in queste condizioni”. Le policy vengono generate (anche automaticamente) da Hush, sulla base di runtime visibility: si guarda come le macchine già interagiscono, e da lì si costruisce una mappa.
- Trasparenza e scoperta continua: Hush mappa continuamente interazioni reali tra workload, servizi, agenti AI, ambienti di runtime. Scopre quali workload esistono, come comunicano, dove sono i rischi.
- Standard aperti: Hush si appoggia allo standard SPIFFE (Secure Production Identity Framework for Everyone), che aiuta a definire identità macchina più dinamiche e standardizzate.
Così, invece di costruire ancora un sistema che ruota manualmente chiavi, si inaugura una architettura in cui l’accesso è dinamico, controllato da policy, tracciabile, e – importante – dove la gestione delle credenziali statiche diventa superflua.
Se funziona come promette, Hush potrebbe portare benefici reali:
- Sicurezza migliorata: meno rischi legati a chiavi scoperte, persi, riutilizzati in modo improprio. Qualsiasi esposizione involontaria ha meno possibilità di diventare un attacco riuscito.
- Riduzione dei costi operativi: non dover ruotare ogni chiave manualmente, non dover cercare dove è usata, aggiornare codice o infrastrutture è laborioso. Se il sistema si occupa di tracciare, mappare, generare policy, identificare anomalie, si risparmia molto tempo.
- Maggiore visibilità e controllo: l’azienda sa concretamente chi accede a cosa, da dove, qual è il “raggio d’azione” (blast radius) di ogni servizio, ogni macchina. Questo aiuta anche nella compliance, negli audit, nella gestione dei rischi.
- Un modello scalabile per il futuro: con l’avvento dell’AI, degli agenti autonomi, dei servizi in cloud, la moltiplicazione delle identità macchina è inevitabile. Un approccio legacy troppe volte non è adeguato allo scenario in cui tutto parla con tutto, in modo automatizzato. Hush dice: preparati a quel mondo oggi.
Naturalmente, nessuna soluzione è magica, e trovare un nuovo equilibrio tra implementazione, affidabilità e adozione comporta difficoltà:
- Integrazione con infrastrutture pregresse: anche se Hush dice che non serve “una trasformazione pluriennale”, in molti casi le architetture esistenti sono complesse, con servizi legacy che non supportano facilmente modelli nuovi, o che sono fortemente intrecciati con credenziali statiche.
- Resistenza al cambiamento: team di sviluppo, operazioni, sicurezza devono fidarsi di un sistema diverso, meno evidente sotto il cofano, più policy-driven. Serve formazione, verifiche, cultura.
- Prestazioni, latenza, affidabilità operativa: ogni volta che si introduce un livello intermedio (routing degli accessi tramite la piattaforma Hush, policy in tempo reale), c’è il rischio che qualche richiesta venga rallentata, o che ci siano casi limite dove il sistema blocca qualcosa che non dovrebbe. Fino a che punto il compromesso è accettabile?
- Costi e modello di business: il prodotto è nuovo, ci sono costi per adottarlo, per integrarlo, per mantenerlo. I benefici devono superare i costi – non solo in termini monetari, ma di rischi residui, manutenzione, supporto.
- Sicurezza del sistema stesso: se l’intera gestione passa per Hush, allora la sicurezza, la disponibilità, la resilienza di Hush diventano critiche. Ogni vulnerabilità lì mette a rischio molti clienti.