Accesso delegato
Coinvolgete uno sviluppatore, affidate la fatturazione al vostro commercialista, concedete a un cliente l'accesso in sola lettura ai propri siti o consentite al nostro team di assistenza di esaminare un problema. Ogni concessione è un ruolo con autorizzazioni definite, limitato a un'organizzazione, applicato nel database e registrato in un registro di audit di sola aggiunta.
Condividere un unico account di accesso è la causa dei problemi di accesso all'account. Su Zinn Digital® ogni persona ha la propria identità e l'accesso è un'adesione — un utente, un'organizzazione e un ruolo — che può concedere, modificare o revocare in modo indipendente.
Ciascun collaboratore accede con la propria identità tramite Keycloak, il nostro livello di gestione delle identità. Nessuno digita la Sua password, nessuno condivide una sessione del browser e la rimozione di un utente richiede una sola azione, anziché la reimpostazione della password e l'affannosa ricerca di chi altro ne fosse a conoscenza.
Gli account sono gerarchici: un'organizzazione rivenditore comprende le organizzazioni dei clienti e le organizzazioni dei clienti comprendono i siti. L'iscrizione si applica a un'organizzazione e a tutto ciò che si trova al di sotto di essa, consentendovi di concedere a un cliente dell'agenzia 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 ignorare. La Row-Level Security di Postgres limita ogni query al sottoalbero dell'organizzazione del chiamante, pertanto una richiesta al di fuori del Vostro ambito non ha nulla da restituire.
Se richiede un'organizzazione o un sito al di fuori del Suo ambito, l'API risponde con un semplice "non trovato" invece di un errore di autorizzazione. Un errore di autorizzazione confermerebbe l'esistenza del record; "non trovato" non rivela assolutamente nulla a un utente esterno.
Le autorizzazioni sono chiavi granulari — modulo più azione, come sites.restart o billing.refund — e i ruoli le raggruppano. Quattro ruoli coprono le strutture necessarie ai team reali e ciascuno di essi è costituito da dati che inseriamo noi, non da logica nascosta nel codice.
Controllo completo: create organizzazioni secondarie, invitate e rimuovete membri, modificate i ruoli, gestite le chiavi API, create, riavviate, eliminate definitivamente, sospendete ed eliminate siti, gestite fatturazione e fatture, aprite ticket e consultate il registro di controllo. Il ruolo che riservate a voi stessi.
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 alcun sito: esattamente il profilo ideale per un contabile esterno.
Visualizza e crea siti, riavvia servizi, svuota la cache, gestisce le chiavi API e gestisce i ticket. Deliberatamente esclusi: fatturazione, fatture, metodi di pagamento, gestione dei membri, sospensione dei siti ed eliminazione dei siti. Un collaboratore può sviluppare senza poterLe fatturare nulla né distruggere alcunché.
Visualizza l'organizzazione, i suoi membri, i suoi siti, la sua fatturazione, il catalogo dei piani, i ticket, lo stato della traduzione e il registro di controllo — e non può modificare nulla di tutto ciò. L'autorizzazione ideale per un cliente che desidera visibilità, un revisore o uno stakeholder che ha solo bisogno di consultare.
Delegare l'accesso è sicuro solo se gli account a cui si delega sono difficili da compromettere. L'autenticazione viene eseguita tramite Keycloak per ogni persona dell'account, su ogni interfaccia.
L'attività di supporto richiede talvolta di verificare all'interno del Suo account. Tale accesso è regolato dallo stesso modello di autorizzazioni applicato a tutto il resto: il personale fa semplicemente parte di un'organizzazione interna, strutturata in reparti con autorizzazioni limitate.
Il personale è suddiviso in Assistenza, Fatturazione e finanza, Abusi e affidabilità e sicurezza, Vendite, Onboarding, Ingegneria e operazioni, Marketing e Gestione. Ciascun ruolo concede moduli e azioni specifici, in modo tale che un operatore veda unicamente la parte della console di amministrazione richiesta dalle proprie mansioni e non il resto.
Il ruolo di Agente di supporto concede esattamente quanto segue: visualizzare i clienti, visualizzare e rispondere ai ticket, visualizzare i siti, riavviare un sito e svuotarne la cache. Non include alcuna configurazione di fatturazione, rimborsi, modifica dei piani o gestione del parco siti. Le azioni correttive che un agente può eseguire sono delimitate dal ruolo, non dalle buone intenzioni.
L'autorizzazione customer.impersonate non fa parte del ruolo Manager — appartiene esclusivamente a Super Admin. Quando una sessione viene eseguita per Suo conto, la dashboard mostra un banner persistente di rappresentanza, in modo che non vi sia mai ambiguità su chi stia agendo.
Ogni azione con privilegi e amministrativa viene aggiunta a un registro di controllo di solo accodamento che registra l'autore, l'azione, l'obiettivo, i metadati di supporto, l'indirizzo IP e la marcatura oraria — partizionato temporalmente in produzione. I proprietari e i membri con accesso di sola lettura possono consultare autonomamente il registro della propria organizzazione.
Le azioni del personale sensibili e distruttive 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 agenti AI si autenticano tutti tramite lo stesso modello di autorizzazione delle persone: nessuna credenziale umana condivisa, nessun segreto a lungo termine incollato in una build.
Le chiavi appartengono a un'organizzazione e presentano ambiti granulari legati agli stessi permessi RBAC: sola lettura, fatturazione, provisioning. Conceda a una pipeline l'ambito limitato di cui ha bisogno anziché l'intero account di un membro.
Le chiavi della modalità di test e della modalità live sono distinte, pertanto un'integrazione in fase di sviluppo non può accedere ai dati di produzione per errore o tramite una variabile di ambiente copiata.
Memorizziamo un hash SHA-256 del segreto e un prefisso di ricerca, mai la chiave non elaborata. La chiave viene visualizzata una sola volta al momento della creazione. Ciascuna chiave tiene traccia dell'ultimo utilizzo e può essere revocata singolarmente senza interferire con null'altro.
Il nostro server MCP consente a qualsiasi agente con supporto MCP di gestire il vostro hosting in linguaggio naturale, autenticato con OAuth 2.1 e limitato alla vostra organizzazione e al vostro ruolo RBAC, con token revocabili per ciascun tool, conferma per le azioni distruttive, limiti di spesa e registrazione di controllo completa.
L'accesso all'account e l'accesso al server sono problemi distinti. Le credenziali a livello di sito vengono gestite nel pannello di controllo, rilasciate con privilegi minimi e isolate in modo che la shell di un collaboratore sia limitata a un unico sito.
Un operatore individuale mantiene una singola organizzazione e una sola iscrizione come proprietario, e aggiunge un ruolo Sviluppatore quando un collaboratore esterno interviene per un progetto. Al termine del progetto, l'iscrizione viene rimossa e il suo accesso smette immediatamente di funzionare: non rimangono credenziali condivise da ruotare.
Un'agenzia utilizza la struttura ad albero dell'organizzazione. Ogni cliente riceve la propria organizzazione secondaria, che contiene i siti di quel cliente, e le persone stesse del cliente ottengono l'iscrizione a tale livello: di sola lettura per uno stakeholder che desidera visibilità, di proprietario per un cliente che desidera l'autogestione. Il Vostro personale detiene adesioni a livelli superiori dell'albero e visualizza l'intero portfolio; un cliente vede solo la propria filiale, e la Row-Level Security è ciò che rende tutto questo realtà anziché una promessa.
Un rivenditore funziona allo stesso modo, a un livello superiore: un'organizzazione rivenditore contiene organizzazioni clienti, ciascuna con i propri membri, la propria vista di fatturazione e i propri siti. La stessa primitiva alimenta account secondari, team di agenzie e gerarchie di rivenditori; non esiste un meccanismo separato e meno potente per nessuno di essi.
Tutto è disponibile nella prova di 14 giorni senza carta di credito. Registratevi senza dettagli di pagamento, invitate un collega, verificate a cosa può e non può accedere ciascun ruolo e consultate il vostro registro di audit.
Attualmente, un'iscrizione concede il proprio ruolo all'interno di un'organizzazione e a tutti gli elementi sottostanti nella struttura ad albero, pertanto il modo per separare i gruppi di siti consiste nel separare le organizzazioni: inserisca tali siti nella loro organizzazione secondaria e conceda l'iscrizione in quella sede. È un modello lineare per agenzie e rivenditori, in cui ogni cliente desidera già un proprio limite definito. La definizione dell'ambito delle risorse per singola iscrizione, associando una singola iscrizione a siti specifici all'interno di una sola organizzazione, è un perfezionamento pianificato e non una funzionalità attualmente disponibile.
Il ruolo Developer non include l'eliminazione o la sospensione del sito; tali chiavi appartengono al ruolo Owner. Consente di visualizzare e creare siti, riavviare servizi, cancellare la cache, gestire le chiavi API e lavorare sui ticket. Nemmeno i permessi di distribuzione e di push-to-live fanno parte delle concessioni per Developer, pertanto il passaggio alla produzione rimane di competenza del proprietario dell'account. Abbini questo elemento allo staging, in modo che il lavoro di compilazione avvenga fin dall'inizio al di fuori del sito live.
Dipende interamente dal ruolo del personale, e ogni ruolo costituisce un insieme ristretto di chiavi di autorizzazione. Un addetto all'assistenza, ad esempio, può visualizzare il Suo account e i Suoi siti, visualizzare e rispondere ai Suoi ticket, riavviare un sito e svuotarne la cache, ma non può toccare la configurazione di fatturazione, i rimborsi, i piani o la flotta. L'accesso come cliente è un'autorizzazione separata riservata esclusivamente al Super Admin, e quando si verifica, la dashboard mostra un banner persistente di impersonificazione. Ogni azione con privilegi viene registrata nel registro di controllo con autore, azione, destinazione, IP e timestamp, e può verificare Lei stesso il registro della Sua organizzazione.
Rimuova l'iscrizione e il loro accesso a tale organizzazione terminerà: manterranno la propria identità, ma non avranno alcun ruolo e quindi nessuna autorizzazione nel Suo account. Le chiavi API vengono revocate singolarmente, consentendo di interrompere una chiave di pipeline senza interferire con il resto. Se utilizza il single sign-on SAML, il deprovisioning nel Suo provider di identità 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 precisare il motivo. Le chiavi API appartengono all'organizzazione, non a un singolo membro, e presentano ambiti granulari propri legati allo stesso catalogo di autorizzazioni. Pertanto, invece di consegnare una chiave a una persona, si crea una chiave per l'attività che svolge con l'ambito più ristretto richiesto da tale attività, revocandola al termine dell'attività stessa. Viene memorizzato solo l'hash del segreto e ciascuna chiave registra l'ultimo utilizzo, rendendo facile individuare e ritirare le chiavi inutilizzate.
Sì. Il nostro server MCP autentica gli agenti con OAuth 2.1 e ne limita l'ambito alla Sua organizzazione e al Suo ruolo RBAC, con token revocabili per strumento, in modo da concedere una funzionalità specifica anziché un accesso totale. Le azioni distruttive richiedono una conferma, si applicano limiti di spesa e ogni azione viene registrata nello stesso registro di controllo delle attività umane.
La funzionalità Row-Level Security di Postgres limita le query al sottoalbero dell'organizzazione del chiamante all'interno del database stesso, utilizzando il filtro a livello di applicazione come difesa approfondita anziché come unica linea. Le richieste di record al di fuori dell'ambito restituiscono "non trovato" invece di un errore di autorizzazione, in modo da non rivelare alcuna informazione sull'esistenza dei dati. Sul lato server, l'isolamento per sito tramite CageFS confina la shell e i file di ciascun tenant al proprio sito.
Sì. La prova di 14 giorni non richiede carta di credito — nessun dato di pagamento, nessun impegno — e include l'hosting Footprint-Free per un massimo di cinque siti. È sufficiente per invitare un collega, assegnare un ruolo e verificare che i limiti funzionino come desiderate prima di sottoscrivere un piano.
Iniziate con la prova di 14 giorni senza carta di credito, invitate un utente e osservate il modello di autorizzazioni svolgere il proprio lavoro: ruoli a cui potete assegnare un nome, ambiti che potete revocare e un registro di controllo che indica con esattezza chi ha fatto cosa.
Inizia gratis