Accesso delegato
Coinvolgi uno sviluppatore, affida la fatturazione al tuo commercialista, offri a un cliente una visualizzazione di sola lettura dei suoi siti o lascia che il nostro team di supporto analizzi un problema. Ciascuna concessione è un ruolo con permessi definiti, circoscritto a un'organizzazione, applicato nel database e registrato in un registro di audit di sola aggiunta.
Condividere le stesse credenziali di accesso è il modo in cui la sicurezza dell'account viene compromessa. Su Zinn Digital® ogni persona ha la propria identità e l'accesso è un'iscrizione — un utente, un'organizzazione e un ruolo — che puoi concedere, modificare o revocare autonomamente.
Ciascun collaboratore effettua l'accesso individualmente tramite Keycloak, il nostro livello di identità. Nessuno digita la tua password, nessuno condivide una sessione del browser e rimuovere qualcuno richiede un'azione sola, anziché una rotazione delle password e una corsa frenetica per scoprire chi altro la conoscesse.
Gli account sono gerarchici: un'organizzazione di rivenditori contiene organizzazioni di clienti e le organizzazioni di clienti contengono siti. Un'associazione si applica a un'organizzazione e a tutto ciò che si trova al di sotto di essa, consentendo di affidare a un'agenzia cliente il controllo della propria organizzazione senza mai esporre gli altri clienti.
La separazione dei tenant non è un filtro nel codice dell'applicazione che un bug potrebbe saltare. La sicurezza a livello di riga di Postgres delimita ogni query al sottoalbero dell'organizzazione del chiamante, quindi una richiesta al di fuori del proprio ambito non ha nulla da restituire.
Richiedi un'organizzazione o un sito fuori dal tuo ambito e l'API risponde con un semplice errore di elemento non trovato anziché con un errore di autorizzazione. Un errore di autorizzazione confermerebbe che il record esiste; l'assenza di risultati non rivela assolutamente nulla a un estraneo.
I permessi sono chiavi granulari: modulo più azione, come sites.restart o billing.refund, e i ruoli li raggruppano. Quattro ruoli coprono le configurazioni di cui i team reali hanno bisogno, e ciascuno di essi è un dato predefinito, non logica nascosta nel codice.
Controllo totale: crea organizzazioni figlio, invita e rimuovi membri, modifica i ruoli, gestisci le chiavi API, crea, riavvia, elimina la cache, sospendi ed elimina siti, gestisci fatturazione e fatture, apri ticket e leggi il registro di controllo. Il ruolo che tieni per te.
Visualizza l'organizzazione, i suoi membri e il catalogo dei piani, e gestisce fatture, metodi di pagamento e addebiti. Nessun accesso per creare, modificare o eliminare un singolo sito: esattamente il profilo ideale per un contabile esterno.
Visualizza e crea siti, riavvia i servizi, svuota la cache, gestisce le chiavi API e lavora sui ticket. Deliberatamente esclusi: fatturazione, fatture, metodi di pagamento, gestione dei membri, sospensione ed eliminazione dei siti. Un appaltatore può sviluppare senza poter ricevere addebiti o distruggere alcunché.
Vede l'organizzazione, i suoi membri, i suoi siti, la fatturazione, il catalogo dei piani, i ticket, lo stato delle traduzioni e il registro di audit, senza poter modificare nulla. Il permesso ideale per un cliente che desidera visibilità, un revisore dei conti o un interessato che ha solo bisogno di visualizzare.
La delega dell'accesso è sicura solo se gli account a cui deleghi sono difficili da compromettere. L'autenticazione passa attraverso Keycloak per ogni utente dell'account, su qualsiasi interfaccia.
Il lavoro di supporto a volte significa dare un'occhiata all'interno del tuo account. Tale accesso è regolato dallo stesso modello di autorizzazione di qualsiasi altra cosa: il personale fa semplicemente parte di un'organizzazione dello staff, suddivisa in reparti con permessi limitati.
Il personale è suddiviso in Supporto, Fatturazione e Finanza, Abusi e Affidabilità e sicurezza, Vendite, Onboarding, Ingegneria e Operazioni, Marketing e Management. Ciascun ruolo garantisce moduli e azioni specifici, in modo che un agente visualizzi solo la parte della console di amministrazione necessaria per il proprio lavoro e non il resto.
Il ruolo di Agente di supporto concede esattamente questo: visualizzare i clienti, visualizzare e rispondere ai ticket, visualizzare i siti, riavviare un sito e svuotare la relativa cache. Non include alcuna configurazione di fatturazione, alcun rimborso, alcuna modifica dei piani e alcuna gestione della flotta. La risoluzione che un agente può eseguire è limitata dal ruolo, non dalle buone intenzioni.
Il permesso customer.impersonate non fa parte del ruolo Manager, ma è riservato esclusivamente al Super Admin. Quando è attiva una sessione per tuo conto, la dashboard mostra un banner di impersonificazione persistente affinché sia sempre chiaro chi sta agendo.
Ogni azione privilegiata e amministrativa viene aggiunta a un registro di audit di sola scrittura che registra l'attore, l'azione, la destinazione, i metadati di supporto, l'indirizzo IP e la marcatura temporale, partizionati per tempo in produzione. I proprietari e i membri con sola lettura possono leggere autonomamente il registro della propria organizzazione.
Le azioni sensibili e distruttive del personale possono richiedere un'autenticazione rafforzata o l'approvazione di due persone prima di essere eseguite, e i nuovi reparti e ruoli sono questioni di configurazione anziché di modifica del codice.
Script, pipeline CI, CLI, provider Terraform e agent IA si autenticano attraverso lo stesso modello di permessi degli utenti: niente credenziali umane condivise, nessun segreto a lungo termine incollato in una build.
Le chiavi appartengono a un'organizzazione e dispongono di ambiti granulari associati alle stesse autorizzazioni RBAC: sola lettura, fatturazione, provisioning. Concedi a una pipeline l'ambito specifico di cui ha bisogno anziché l'intero account di un membro.
Le chiavi di test e di produzione sono distinte, quindi un'integrazione in fase di sviluppo non può accedere ai dati di produzione per errore o a causa di una variabile d'ambiente copiata.
Memorizziamo un hash SHA-256 del segreto e un prefisso di ricerca, mai la chiave in chiaro. Una chiave viene mostrata una sola volta al momento della creazione. Ciascuna chiave tiene traccia dell'ultimo utilizzo e può essere revocata singolarmente senza compromettere nient'altro.
Il nostro server MCP consente a qualsiasi agente abilitato a MCP di gestire il tuo hosting in linguaggio naturale, autenticato con OAuth 2.1 e limitato alla tua organizzazione e al tuo ruolo RBAC, con token revocabili per singolo strumento, conferma delle azioni distruttive, limiti di spesa e log di audit completi.
L'accesso all'account e l'accesso al server sono problemi diversi. Le credenziali a livello di sito sono gestite nella dashboard, emesse con privilegi minimi e isolate in modo che la shell di un collaboratore corrisponda alla shell di un solo sito.
Un operatore solitario gestisce una singola organizzazione e una sola iscrizione come proprietario, e aggiunge un ruolo di sviluppatore quando un collaboratore esterno interviene per un progetto. Quando il progetto termina, l'iscrizione viene rimossa e il suo accesso smette di funzionare immediatamente: non rimangono credenziali condivise da ruotare.
Un'agenzia utilizza l'albero delle organizzazioni. Ogni cliente ottiene la propria organizzazione figlia, che contiene i siti di quel cliente, e le persone del cliente ricevono lì le proprie iscrizioni: di sola lettura per un stakeholder che desidera visibilità, proprietario per un cliente che vuole gestirsi in autonomia. Il tuo staff detiene iscrizioni più in alto nell'albero e vede il portfolio; un cliente vede solo il proprio ramo, ed è la Sicurezza a Livello di Riga a rendere ciò una realtà anziché una promessa.
Un rivenditore funziona allo stesso modo, salendo di un livello: un'organizzazione di rivenditori contiene organizzazioni di clienti, Ognuna con i propri membri, la propria visualizzazione di fatturazione e i propri siti. La stessa primitiva alimenta sub-account, team di agenzie e gerarchie di rivenditori: non esiste alcun meccanismo separato o inferiore per nessuno di essi.
Tutto è disponibile nella prova gratuita di 14 giorni senza carta di credito. Registrati senza dati di pagamento, invita un collega, guarda cosa ciascun ruolo può e non può raggiungere e rileggi il tuo registro di audit.
Oggi un'associazione assegna il suo ruolo a un'organizzazione e a tutto ciò che si trova al di sotto di essa nella gerarchia, quindi il modo per separare gli insiemi di siti è separare le organizzazioni: inserisci quei siti nella loro organizzazione figlia e assegna lì l'associazione. È un modello pulito per agenzie e rivenditori, in cui ciascun cliente desidera già il proprio confine. La limitazione delle risorse per singola associazione, ovvero il blocco di una singola associazione su siti specifici all'interno di una stessa organizzazione, è un perfezionamento pianificato piuttosto che una funzione attualmente disponibile.
Il ruolo Developer non include l'eliminazione o la sospensione dei siti; queste autorizzazioni appartengono al ruolo Owner. Consente di visualizzare e creare siti, riavviare i servizi, svuotare la cache, gestire le chiavi API e lavorare sui ticket. Anche i permessi di deployment e di push-to-live non fanno parte del ruolo Developer, quindi la promozione alla produzione rimane di competenza del proprietario dell'account. Abbinalo agli ambienti di staging in modo che il lavoro di sviluppo avvenga innanzitutto lontano dal sito live.
Dipende interamente dal ruolo del personale e ciascun ruolo corrisponde a un insieme ristretto di chiavi di permesso. Un agente del supporto, ad esempio, può visualizzare il tuo account e i tuoi siti, visualizzare e rispondere ai tuoi ticket, riavviare un sito e pulirne la cache, ma non può toccare la configurazione di fatturazione, i rimborsi, i piani o la flotta. L'accesso come cliente è un permesso separato detenuto solo dal Super Admin e, quando si verifica, la dashboard mostra un banner di impersonificazione persistente. Ogni azione privilegiata viene registrata nel log di audit con l'autore, l'azione, la destinazione, l'indirizzo IP e la marca temporale, e puoi leggere tu stesso il log della tua organizzazione.
Rimuovi l'iscrizione e il loro accesso a quell'organizzazione termina: mantengono la propria identità, ma nessun ruolo e quindi nessun permesso nel tuo account. Le chiavi API vengono revocate singolarmente, quindi una chiave di pipeline può essere rimossa senza interrompere nient'altro. Se utilizzi l'accesso singolo SAML, il provisioning nel tuo identity provider gestisce l'accesso in modo centralizzato. Le credenziali a livello di sito come le chiavi SSH vengono revocate nella dashboard e la rimozione stessa viene registrata nel registro di controllo.
No — ma vale la pena essere precisi sul perché. Le chiavi API appartengono all'organizzazione, non a un singolo membro, e dispongono di ambiti granulari propri legati allo stesso catalogo di autorizzazioni. Quindi, anziché consegnare una chiave a una persona, si crea una chiave per la mansione che deve svolgere, assegnandole l'ambito più ristretto possibile necessario per quella mansione, e la si revoca quando il lavoro è completato. Viene memorizzato solo un hash del segreto e ciascuna chiave registra l'ultimo utilizzo, in modo che sia facile trovare e ritirare le chiavi inutilizzate.
Sì. Il nostro server MCP autentica gli agenti tramite OAuth 2.1 e li delimita alla tua organizzazione e al tuo ruolo RBAC, con token revocabili per singolo strumento, in modo da concedere una specifica funzionalità anziché un accesso completo. Le azioni distruttive richiedono conferma, si applicano limiti di spesa e ogni azione viene registrata nello stesso registro di audit delle attività umane.
La sicurezza a livello di riga di Postgres limita le query al sottoinsieme dell'organizzazione del chiamante direttamente nel database, utilizzando il filtro a livello applicativo come difesa in profondità anziché come unico sbarramento. Le richieste di record al di fuori dell'ambito restituiscono un errore di elemento non trovato anziché un errore di autorizzazione, in modo da non rivelare alcuna informazione sull'esistenza di tali elementi. Sul lato server, l'isolamento per singolo sito tramite CageFS circoscrive la shell e i file di ciascun tenant al proprio sito.
Sì. La prova di 14 giorni è senza carta di credito, senza dettagli di pagamento e senza impegno, e copre Footprint-Free Hosting con un massimo di cinque siti. È sufficiente per invitare un collega, assegnare un ruolo e confermare che i confini si comportino nel modo desiderato prima di impegnarsi.
Inizia la prova gratuita di 14 giorni senza carta di credito, invita qualcuno e guarda il modello di permessi fare il suo lavoro: ruoli che puoi definire, ambiti che puoi revocare e un registro di controllo che dice esattamente chi ha fatto cosa.
Inizia gratis