Sicurezza dell'account
La sicurezza del server protegge i siti. La sicurezza dell'account protegge le relative chiavi di accesso. Ogni accesso a Zinn Digital® si basa su un unico sistema di gestione delle identità conforme agli standard — passkey e WebAuthn, autenticazione a due fattori TOTP, accesso tramite magic link, SAML SSO per team aziendali e di agenzia — con ruoli granulari, chiavi API per organizzazione e un registro di controllo di solo accodamento.
La maggior parte degli account di hosting è una password in un database, collegata a un pannello di controllo. Il nostro è un sistema di identità dedicato — Keycloak, che supporta OIDC e SAML — che si trova a monte di tutto: la dashboard clienti, la console di amministrazione del personale, questo sito pubblico e la knowledge base, e i vostri ticket di assistenza. Effettuate l'accesso una sola volta e risulterete autenticati su tutti i servizi.
Poiché è basato su standard aperti anziché su un accesso proprietario, il livello di identità è sostituibile allo stesso modo di qualsiasi altro componente della piattaforma. Nessuna parte del Suo modello di accesso è vincolata all'interno del prodotto di un fornitore e l'autenticazione del Suo team non dipende dal mantenimento di un unico fornitore da parte nostra. Questo è lo stesso principio di assenza di vincoli (no-lock-in) che applichiamo agli account CDN, al DNS e ai fornitori di servizi di pagamento.
L'accesso è localizzato e il passaggio dal sito alla schermata di accesso mantiene la Sua lingua, evitando che un team distribuito in più paesi sia costretto a un accesso esclusivamente in inglese.
Quattro metodi, tutti di altissimo livello, tutti configurabili per persona. Nessuno è costretto a scegliere l'opzione più debole solo perché è l'unica disponibile.
Inserisca la Sua email, faccia clic sul link e l'accesso è effettuato. Nessuna password da sottrarre tramite phishing, riutilizzare o diffondere in seguito a una violazione dei dati. Questo è il percorso predefinito per i nuovi account e, per la maggior parte delle persone, è l'unico di cui avranno mai bisogno.
Registri una passkey — Touch ID, Face ID, Windows Hello o una chiave hardware come YubiKey — e acceda senza alcuna password. Le passkey sono vincolate all'origine, pertanto una pagina di accesso contraffatta non può sottrarle. La piattaforma accetta autenticatori ES256 e RS256 e predilige la verifica dell'utente.
Acceda con Google tramite una connessione standard del provider di identità, in modo che un account erediti tutti i controlli già applicati dal Suo Google Workspace. Ulteriori provider si collegano allo stesso modo: non si tratta in alcun modo di un'integrazione su misura.
Conservato per le persone e gli script che ne hanno bisogno e vincolato a una vera e propria politica: minimo dodici caratteri, mai il vostro nome utente o indirizzo e-mail, nessun riutilizzo degli ultimi tre, con hash tramite Argon2. Gli indirizzi e-mail vengono verificati prima che un account diventi utilizzabile.
I secondi fattori fanno parte del sistema di identità, non sono un componente aggiuntivo da acquistare o un plugin da installare sul proprio sito.
Se la vostra organizzazione utilizza già un provider di identità — Okta, Entra ID, Google Workspace o qualsiasi altro sistema che supporti SAML — è sufficiente collegarlo e i vostri collaboratori accederanno a Zinn Digital® con le loro credenziali aziendali esistenti. Non c'è una seconda password che il vostro team debba gestire, né una seconda checklist di offboarding da dimenticare.
Questo è fondamentale soprattutto a livello di agenzie e rivenditori, dove il turnover del personale rappresenta un vero e proprio evento di sicurezza. Quando un collaboratore lascia l'azienda e viene disattivato nella directory, ne viene disattivato anche l'accesso al vostro hosting. L'accesso segue l'impiego in modo centralizzato, invece di dover essere revocato manualmente attraverso decine di strumenti SaaS.
SAML si affianca a tutto il resto invece di sostituirlo: gli appaltatori possono comunque ricevere un account con magic-link all'interno di un ruolo delimitato, mentre il personale permanente accede tramite SSO. Un'unica organizzazione, un unico modello di autorizzazioni, due porte d'accesso.
L'accesso è limitato all'albero dell'organizzazione — dal rivenditore al cliente fino al sito — ed è applicato direttamente nel database tramite la sicurezza a livello di riga, non solo nell'applicazione. L'accesso multi-tenant non è una politica che chiediamo di rispettare; è una query che non può restituire righe. Quattro ruoli cliente coprono la suddivisione realistica delle mansioni.
Controllo completo dell'organizzazione e dei relativi account secondari: create organizzazioni secondarie, invitate e rimuovete membri, assegnate ruoli, gestite ogni sito, gestite la fatturazione, gestite le chiavi API e consultate il registro di controllo.
Fatture, abbonamenti, metodi di pagamento e catalogo dei piani, e nient'altro. Il vostro responsabile finanziario o contabile può saldare una fattura senza avere mai la possibilità di modificare, sospendere o eliminare un sito online.
Accesso ai siti e alle API senza controllo della fatturazione: visualizzate e predisponete siti, riavviate servizi, svuotate le cache, gestite le chiavi API e i ticket di lavoro. Deliberatamente nessun accesso ai metodi di pagamento, alla fatturazione o alle modifiche del piano.
Sola visualizzazione nell'intera organizzazione — siti, fatturazione, piani, ticket, stato della traduzione e registro di controllo. Il ruolo ideale per un revisore, un cliente che desidera visibilità o un nuovo dipendente durante la sua prima settimana.
La dashboard è una modalità di accesso. L'API, la CLI, il provider Terraform e il server MCP ne rappresentano altre — e sono soggetti allo stesso modello di accesso, poiché una chiave senza ambito specifico aggira ogni ruolo appena configurato.
Una chiave API viene rilasciata a un'organizzazione, non a una singola persona, e dispone di propri ambiti. La tratti come materiale di credenziali condiviso: la nomini in base al suo scopo, le assegni gli ambiti più ristretti necessari al funzionamento e la sostituisca quando la persona che l'ha creata lascia l'incarico.
La chiave non elaborata viene mostrata una sola volta, al momento della creazione. Ciò che conserviamo è un hash SHA-256 e un breve prefisso per la ricerca. Non possiamo mostrarLe nuovamente una chiave e una compromissione del database non fornisce a un utente malintenzionato credenziali funzionanti.
Ogni chiave include ambiti granulari collegati allo stesso catalogo di autorizzazioni utilizzato dai ruoli, registra l'ultimo utilizzo e può essere revocata all'istante non appena sembra sospetta. Chiavi di sandbox separate testano l'API senza alcuna fatturazione o provisioning effettivo.
Il server MCP consente a qualsiasi agente compatibile con MCP di gestire il Suo hosting — e si autentica tramite OAuth 2.1, con ambito limitato alla Sua organizzazione e alle relative autorizzazioni RBAC, con token revocabili per singolo strumento, conferma per le azioni distruttive, limiti di spesa e registrazione di controllo completa. Connettere un assistente AI non significa affidargli le chiavi di tutto.
Ogni azione privilegiata registra un record di solo inserimento: chi l'ha eseguita, cosa ha fatto, su cosa l'ha fatta, le prove a supporto e l'indirizzo IP di origine, con un timestamp. Non si tratta di una comodità di debug; è la traccia probatoria.
No — e preferiremmo che non lo faceste. L'accesso tramite link magico via e-mail è l'opzione predefinita ed è possibile registrare una passkey (Touch ID, Face ID, Windows Hello o una chiave hardware) ed effettuare l'accesso senza aver mai impostato una password. E-mail e password rimangono disponibili come soluzione di fallback, con un minimo di dodici caratteri, il divieto di riutilizzare le ultime tre e l'hashing Argon2.
L'autenticazione a due fattori TOTP è integrata nel livello di identità e può essere imposta tramite criteri a livello aziendale, anziché essere lasciata alla scelta di ciascun membro. Le passkey rappresentano l'opzione più sicura laddove i dispositivi del Suo team le supportino, poiché eliminano la password a cui mirerebbe un utente malintenzionato tramite phishing.
Sì. Il ruolo Billing Manager garantisce l'accesso a fatture, abbonamenti, metodi di pagamento e al catalogo dei piani, e a nient'altro: nessuna possibilità di visualizzare, effettuare il provisioning, riavviare, sospendere o eliminare un sito. Vale anche il contrario: il ruolo Developer gestisce i siti e l'accesso alle API senza alcun controllo sulla fatturazione. I ruoli vengono assegnati per organizzazione, pertanto un ruolo in un'organizzazione non concede alcun accesso in un'organizzazione separata e non correlata, sebbene un ruolo in un'organizzazione principale si applichi alle organizzazioni subordinate al suo interno.
Revocatela dalla dashboard e smetterà immediatamente di funzionare. La finestra di danno è limitata a ciò che tale chiave poteva fare originariamente, motivo per cui le chiavi presentano ambiti granulari e registrano un timestamp dell'ultimo utilizzo: ambiti ristretti e una traccia di utilizzo visibile sono ciò che trasforma una fuga di dati in un incidente circoscritto anziché in una compromissione completa dell'account. Si noti che le chiavi vengono rilasciate all'organizzazione anziché a un singolo individuo, pertanto è opportuno trattarle come credenziali condivise e ruotarle quando il personale cambia. Da parte nostra viene memorizzato solo un hash della chiave, quindi un'eventuale fuga dal nostro database non produce una credenziale funzionante.
Sì. Ogni azione privilegiata viene registrata in un registro di controllo di solo accodamento con l'autore, l'azione, la destinazione, le prove a supporto, l'IP di origine e un timestamp. I ruoli di proprietario e di sola lettura possono leggerlo direttamente. Le azioni del personale sul Suo account vengono registrate nella stessa traccia e le azioni sensibili o distruttive del personale possono richiedere prima un'autenticazione rafforzata o l'approvazione di due persone.
Sì: SAML SSO è supportato per gli account aziendali e di agenzia, quindi il personale si autentica con le credenziali aziendali esistenti e l'offboarding nella directory rimuove l'accesso anche qui. È possibile combinare diversi approcci: SSO per il personale a tempo indeterminato, account magic-link dedicati per i collaboratori, il tutto all'interno dello stesso modello di autorizzazioni.
No — le password non vengono migrate intenzionalmente. Il Suo account viene importato senza password e, al primo accesso, potrà utilizzare un magic link oppure impostare una nuova password in base alla politica attuale. Il trasferimento dei vecchi hash delle password porterebbe vecchie vulnerabilità in un nuovo sistema, pertanto non lo facciamo.
La prova di Footprint-Free dura 14 giorni, senza carta di credito, e copre fino a cinque siti. Durante la prova riceverà il livello di identità completo: passkey, autenticazione a due fattori, ruoli, chiavi API e registro di controllo non sono vincolati a un piano a pagamento.
Registri una passkey, inviti il Suo team assegnando i ruoli appropriati ed emetta una chiave API con ambito limitato: tutto con una prova di 14 giorni senza dover inserire i dati della carta.
Inizia gratis