Sicurezza dell'account
La sicurezza del server protegge i siti. La sicurezza dell'account protegge le relative chiavi. Ogni accesso a Zinn Digital® si basa su un sistema di identità basato su standard — passkey e WebAuthn, autenticazione a due fattori TOTP, accesso tramite magic-link, SAML SSO per team aziendali e di agenzia — supportato da ruoli granulari, chiavi API per organizzazione e un registro di audit di sola aggiunta.
La maggior parte degli account di hosting è costituita da una password in un database, collegata a un pannello di controllo. Il nostro è un sistema di identità dedicato — Keycloak, basato su OIDC e SAML — che si trova davanti a tutto: la dashboard del cliente, la console di amministrazione dello staff, questo sito pubblico con la relativa base di conoscenza e i vostri ticket di supporto. Accedete una volta sola e sarete connessi a tutti loro.
Poiché è costruito su standard aperti anziché su un sistema di login proprietario, lo strato di identità è sostituibile esattamente come ogni altro componente della piattaforma. Nessuna parte del vostro modello di accesso è vincolata al prodotto di un fornitore e nessuna autenticazione del vostro team dipende dal fatto che noi ci affidiamo a un determinato fornitore. È lo stesso principio di assenza di vincoli che applichiamo agli account CDN, al DNS e ai provider di pagamento.
L'accesso è localizzato e il passaggio dal sito alla schermata di login mantiene la lingua impostata, evitando così che un team dislocato in vari Paesi sia costretto a usare un login esclusivamente in inglese.
Quattro metodi, tutti di prima classe, tutti configurabili per persona. Nessuno è costretto a scegliere l'opzione più debole solo perché è l'unica disponibile.
Inserisci la tua email, clicca sul link e sei dentro. Nessuna password da sottrarre con il phishing, da riutilizzare o da far filtrare in una violazione di dati. Questa è la modalità predefinita per i nuovi account e per la maggior parte delle persone è l'unica di cui avranno mai bisogno.
Registra una passkey (Touch ID, Face ID, Windows Hello o una chiave hardware come YubiKey) e accedi senza alcuna password. Le passkey sono vincolate all'origine, quindi una pagina di login contraffatta non può sottrarle. La piattaforma accetta autenticatori ES256 e RS256 e privilegia la verifica dell'utente.
Accedi con Google tramite una connessione standard con un provider di identità, in modo che l'account erediti tutti i controlli già imposti da Google Workspace. Altri provider si collegano allo stesso modo: non si tratta di un'integrazione su misura.
Conservato per le persone e gli script che ne hanno bisogno, e soggetto a una vera norma: minimo dodici caratteri, mai il tuo nome utente o indirizzo email, nessun riutilizzo degli ultimi tre, crittografato con Argon2. Gli indirizzi email vengono verificati prima che un account diventi utilizzabile.
I secondi fattori fanno parte del sistema di identità, non sono un componente aggiuntivo che acquisti o un plugin che installi sul tuo sito.
Se la tua organizzazione utilizza già un provider di identità — Okta, Entra ID, Google Workspace o qualsiasi altro sistema basato su SAML — puoi collegarlo e il tuo team potrà accedere a Zinn Digital® con le proprie credenziali aziendali esistenti. Non c'è una seconda password da gestire per il team e nessuna seconda checklist di offboarding da dimenticare.
Ciò è particolarmente importante per le agenzie e i rivenditori, dove il turn-over del personale rappresenta un vero e proprio problema di sicurezza. Quando qualcuno se ne va e lo disabiliti nella tua directory, hai disabilitato anche il suo accesso all'hosting. L'accesso segue il rapporto di lavoro, in modo centralizzato, anziché dover essere gestito su una dozzina di strumenti SaaS diversi.
SAML si affianca a tutto il resto anziché sostituirlo: agli appaltatori può comunque essere assegnato un account con magic-link all'interno di un ruolo delimitato, mentre il personale assunto a tempo indeterminato accede tramite SSO. Un'organizzazione, un modello di autorizzazione, due ingressi.
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 tra tenant non è una norma che chiediamo di rispettare; è una query che non può restituire righe. Quattro ruoli cliente coprono la divisione realistica delle mansioni.
Controllo completo dell'organizzazione e dei relativi sub-account: crea organizzazioni subordinate, invita e rimuovi membri, assegna ruoli, gestisci ogni sito, gestisci fatturazione e fatture, gestisci le chiavi API e leggi il log di audit.
Fatture, abbonamenti, metodi di pagamento e catalogo dei piani, e nient'altro. Il vostro responsabile finanziario o commercialista può saldare una fattura senza avere mai la possibilità di toccare, sospendere o eliminare un sito attivo.
Siti e accesso API senza controllo di fatturazione: visualizza e crea siti, riavvia i servizi, pulisci la cache, gestisci le chiavi API e i ticket di supporto. Deliberatamente senza accesso a metodi di pagamento, fatturazione o modifiche del piano.
Sola visualizzazione in tutta l'organizzazione: siti, fatturazione, piani, ticket, stato delle traduzioni e registro di controllo. Il ruolo ideale per un revisore, un cliente che desidera visibilità o un nuovo assunto nella sua prima settimana.
La dashboard è una delle vie d'accesso. L'API, la CLI, il provider Terraform e il server MCP sono le altre, e sono soggette allo stesso modello di accesso, perché una chiave non delimitata aggrega ogni ruolo appena configurato.
Una chiave API viene rilasciata a un'organizzazione, non a una persona fisica, e possiede i propri ambiti. Trattala come credenziale condivisa: dalle un nome in base al suo scopo, assegna i permessi più ristretti possibili e ruotala quando la persona che l'ha creata cambia ruolo o lascia l'azienda.
La chiave grezza ti 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 mostrarti di nuovo una chiave e la compromissione di un database non fornisce a un malintenzionato credenziali funzionanti.
Ogni chiave possiede ambiti granulari legati allo stesso catalogo di permessi utilizzato dai ruoli, registra quando è stata usata l'ultima volta e può essere revocata immediatamente non appena qualcosa sembra anomalo. Chiavi sandbox separate consentono di testare l'API senza alcuna fatturazione o provisioning reali associati.
Il server MCP consente a qualsiasi agente compatibile con MCP di gestire il tuo hosting e si autentica tramite OAuth 2.1, limitato alla tua organizzazione e ai suoi permessi RBAC, con token revocabili per singolo strumento, conferma per le azioni distruttive, limiti di spesa e audit logging completo. Connettere un assistente IA non significa consegnargli le chiavi di tutto.
Ogni azione privilegiata scrive un record di sola scrittura: chi l'ha eseguita, cosa è stato fatto, su cosa è stata fatta, le prove a supporto e l'indirizzo IP di origine, con un timestamp. Non è una comodità di debug; è la traccia probatoria.
No — e preferiremmo che non lo facessi. L'accesso tramite e-mail con magic link è l'opzione predefinita e puoi registrare una passkey (Touch ID, Face ID, Windows Hello o una chiave hardware) ed effettuare l'accesso senza aver mai impostato alcuna password. L'accesso con e-mail e password rimane disponibile come soluzione di riserva, con un requisito minimo di dodici caratteri, il divieto di riutilizzare gli ultimi tre e la cifratura Argon2.
L'autenticazione a due fattori TOTP è integrata nel livello di identità e può essere imposta tramite policy in un'intera organizzazione anziché essere lasciata alla scelta dei singoli membri. Le passkeys rappresentano l'opzione più sicura laddove i dispositivi del vostro team le supportino, poiché eliminano la password che un malintenzionato cercherebbe di ottenere tramite phishing.
Sì. Il ruolo di Responsabile della fatturazione consente l'accesso a fatture, abbonamenti, metodi di pagamento e al catalogo dei piani, e nient'altro: nessuna possibilità di visualizzare, attivare, riavviare, sospendere o eliminare un sito. Vale anche il contrario: il ruolo di Sviluppatore gestisce i siti e l'accesso alle API senza alcun controllo sulla fatturazione. I ruoli vengono assegnati per organizzazione, quindi un ruolo in un'organizzazione non concede alcun accesso in un'altra organizzazione separata e non correlata, sebbene un ruolo in un'organizzazione madre si applici a quelle annidate al di sotto di essa.
Revocandola dalla dashboard smette di funzionare immediatamente. La finestra di danno è limitata da ciò che quella chiave poteva fare in origine, 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 totale dell'account. Nota che le chiavi vengono emesse per l'organizzazione anziché per un singolo individuo, quindi trattale come credenziali condivise e ruotale quando le persone cambiano ruolo. Da parte nostra viene memorizzato solo un hash della chiave, quindi una fuga di dati dal nostro database non produce una credenziale funzionante.
Sì. Ogni azione privilegiata viene registrata in un registro di audit di sola scrittura con l'attore, l'azione, il bersaglio, le prove di supporto, l'IP di origine e un timestamp. I ruoli di proprietario e di sola lettura possono leggerlo direttamente. Le azioni dello staff sul tuo account vengono registrate nello stesso percorso e le azioni dello staff sensibili o distruttive possono richiedere prima un'autenticazione rafforzata o l'approvazione di due persone.
Sì — Il Single Sign-On (SSO) SAML è supportato per gli account aziendali e per le agenzie, quindi il tuo personale può autenticarsi con le credenziali aziendali esistenti e la disattivazione nella tua directory rimuoverà l'accesso anche qui. Puoi combinare diversi approcci: SSO per il personale fisso e account con magic link circoscritti per i collaboratori esterni, il tutto all'interno dello stesso modello di permessi.
No — le password deliberatamente non vengono migrate. Il tuo account viene importato senza, e al primo accesso puoi usare un magic-link o impostare una nuova password in base ai criteri attuali. Trasferire i vecchi hash delle password porterebbe vecchie vulnerabilità in un nuovo sistema, quindi non lo facciamo.
La prova di Footprint-Free dura 14 giorni, non richiede carta di credito e copre fino a cinque siti. Durante la prova ricevi il livello di identità completo: passkeys, autenticazione a due fattori, ruoli, chiavi API e registro di audit non sono limitati a un piano a pagamento.
Registra una passkey, invita il tuo team nei ruoli giusti e genera una chiave API con scoped permissions, il tutto con una prova di 14 giorni senza carta di credito richiesta.
Inizia gratis