Team e accesso

Fornite a ciascun membro del vostro team esattamente l'accesso di cui ha bisogno

Quattro ruoli cliente, account secondari che riflettono l'effettiva struttura della Sua azienda, chiavi API per organizzazione, single sign-on e un registro di controllo per ogni azione privilegiata. Lo stesso modello di accesso è applicato alla dashboard, all'API, alla CLI, a Terraform e al nostro server MCP. Disponibilità: il provider Terraform è in fase di sviluppo attivo e non è ancora disponibile. Tutto il resto descritto qui è già operativo.

Inizia gratis Vedi hosting per agenzie

700.000+siti ospitati in tutto il mondo
4ruoli cliente, inizializzati e pronti
35Chiavi di autorizzazione granulari
14 giorniprova senza carta

Quattro ruoli, definiti dove il lavoro si divide effettivamente

L'accesso non è un semplice interruttore di attivazione/disattivazione. Ogni organizzazione cliente include quattro ruoli, ciascuno dei quali è un pacchetto fisso di autorizzazioni granulari module.action — in questo modo un referente finanziario non tocca mai un server e uno sviluppatore non vede mai una fattura.

Proprietario

Controllo completo dell'organizzazione e dei relativi account secondari: creazione di organizzazioni secondarie, invito e rimozione di membri, modifica dei ruoli, gestione delle chiavi API, provisioning, riavvio, sospensione ed eliminazione dei siti, gestione delle fatture e dei metodi di pagamento e lettura del registro di controllo. Due operazioni ne sono deliberatamente escluse: la chiusura di un'organizzazione e l'emissione di rimborsi sono azioni riservate al personale, non un ruolo cliente.

Gestore della fatturazione

Tutto ciò che è finanziario e nient'altro: fatture, abbonamenti, metodi di pagamento e catalogo dei piani, oltre a una visualizzazione dell'organizzazione e del relativo elenco dei membri. Nessun accesso al sito: un referente finanziario o un contabile esterno non può riavviare, sospendere o eliminare nulla.

Sviluppatore

Lavorate sui siti senza gestire gli aspetti finanziari: visualizzate e predisponete i siti, riavviate i servizi, svuotate le cache, gestite le chiavi API e aprite o rispondete ai ticket di supporto. Nessuna visualizzazione della fatturazione, nessuna gestione dei membri, nessuna sospensione e nessuna eliminazione: le azioni distruttive e commerciali restano di esclusiva competenza del proprietario.

Sola lettura

Una visualizzazione completa senza possibilità di modificare alcunché: membri, siti, fatturazione, piani, ticket, stato della traduzione e registro di controllo. Il ruolo ideale per uno stakeholder del cliente, un revisore interno o un nuovo arrivato che sta ancora prendendo confidenza.

Account secondari che corrispondono alla vostra struttura reale

La tenancy è una struttura ad albero, non un elenco lineare. Un'organizzazione di rivenditori si trova al di sopra delle organizzazioni dei suoi clienti, e i siti si trovano al di sotto di esse. Un membro del team rappresenta un'adesione — un utente, un'organizzazione, un ruolo — pertanto lo stesso elemento di base supporta un team di due persone, un'agenzia che gestisce cento account cliente e un rivenditore che gestisce account secondari con il proprio marchio.

I ruoli vengono concessi per organizzazione e anche l'applicazione è per organizzazione. Un ruolo in un'organizzazione non concede alcun accesso in un'organizzazione separata e non correlata: un collaboratore può essere uno Sviluppatore sull'account di un cliente e avere accesso di Sola lettura su un secondo, utilizzando lo stesso account di accesso. L'accesso, tuttavia, discende lungo la Sua gerarchia: un ruolo in un'organizzazione principale si applica alle organizzazioni nidificate al di sotto di essa, ed è così che i rivenditori e le agenzie gestiscono i propri clienti.

L'isolamento viene applicato nel database, non solo nel codice dell'applicazione. La sicurezza a livello di riga di Postgres limita ogni query del tenant al sottoalbero del chiamante e qualsiasi elemento esterno a tale sottoalbero restituisce un errore di elemento non trovato anziché un errore di autorizzazione; pertanto, la piattaforma non conferma nemmeno l'esistenza dell'organizzazione o del sito di un altro tenant.

Le stesse autorizzazioni su ogni superficie

I ruoli non sono una semplice comodità del pannello di controllo. Ogni modalità di accesso alla piattaforma si riconduce alle stesse chiavi di autorizzazione, pertanto non esiste alcuna backdoor che eluda le Sue regole di accesso.

Dashboard

Siti, fatturazione, ticket, avvisi, notifiche, chiavi API e gestione del team in un'unica interfaccia. L'interfaccia mostra ciò che il ruolo del membro connesso consente, evitando di mostrare agli utenti controlli che non possono utilizzare.

API pubblica e CLI

L'API pubblicata è la stessa API del motore utilizzata dalla dashboard. Le chiavi API vengono emesse per organizzazione con ambiti granulari legati alle autorizzazioni RBAC, e le modalità sandbox e live separate consentono di testare le integrazioni senza influire sulla fatturazione o sul provisioning effettivi.

Provider Terraform

Gestite siti, domini, DNS, caselle di posta e piani come infrastructure-as-code ed eseguite terraform apply per effettuare il provisioning dell'hosting, regolato dagli stessi ambiti di tutto il resto.

Server MCP

Collegate Claude Code, Cursor, ChatGPT, Claude Desktop o qualsiasi strumento compatibile con MCP. I token sono limitati a un'organizzazione e alle relative autorizzazioni RBAC, sono revocabili per singolo strumento, con conferma per le azioni distruttive, limiti di spesa e un audit trail completo.

Gestione delle chiavi

Viene memorizzato solo un hash di ciascuna chiave API, mai la chiave non elaborata. Le chiavi presentano un nome e un prefisso visibile per consentire di distinguerle, registrano l'ultimo utilizzo e possono essere revocate singolarmente senza influire sulle altre.

Un unico accesso, basato su standard, per ogni cosa

La gestione delle identità si basa su Keycloak, pertanto l'autenticazione avviene tramite standard OIDC e SAML appropriati, anziché mediante un modulo di accesso personalizzato integrato sommariamente in un pannello di hosting.

Accesso via e-mail con magic link per impostazione predefinita, con e-mail e password come alternativa per chi lo preferisce.
Passkey e WebAuthn per un accesso a prova di phishing, oltre all'autenticazione a due fattori TOTP resa obbligatoria per tutti tramite criteri.
Accesso tramite social network con Google, Microsoft, GitHub e altri provider di identità.
Single Sign-On SAML per clienti aziendali e agenzie, in modo che l'accesso del team segua la directory esistente.
Un'unica sessione per dashboard, console di amministrazione, sito pubblico e knowledge base, e ticket di supporto: effettui l'accesso una sola volta, non cinque.
Ogni e-mail di registrazione viene convalidata prima della creazione dell'account, pertanto gli indirizzi non recapitabili e non validi non entreranno mai a far parte del Vostro team.
Poiché è basato su standard, il provider di identità stesso è sostituibile senza dover riprogettare nulla intorno ad esso: la stessa regola di assenza di vincoli (no-lock-in) che applichiamo a qualsiasi altro fornitore.

Responsabilità da presentare direttamente a un revisore

Ogni azione privilegiata scrive un record di controllo di solo accodamento: chi l'ha eseguita, cosa ha fatto, su cosa l'ha fatta, le prove a supporto e l'indirizzo IP di origine. Il log è di solo accodamento — gli eventi vengono aggiunti, non modificati sul posto — e in produzione è partizionato per data e ora in modo da rimanere veloce man mano che cresce.

La lettura di quel registro è di per sé un'autorizzazione. I proprietari e i membri con accesso di sola lettura la possiedono, consentendo sia al responsabile dell'account sia a chi esegue l'audit di visualizzare la cronologia completa senza richiedere privilegi elevati per farlo.

A completamento di ciò vi sono i controlli richiesti dai team più ampi: criteri di sessione, elenchi di IP consentiti facoltativi per ciascuna organizzazione e autenticazione aggiuntiva per le azioni sensibili, in modo che una sessione attiva da sola non sia sufficiente per compiere operazioni critiche.

Come i permessi crescono con voi

Il catalogo delle autorizzazioni è costituito da dati e non da logica hardcoded, motivo per cui può essere esteso senza dover ristrutturare la piattaforma.

Oggi 35 chiavi module.action granulari, che coprono organizzazioni, membri, chiavi API, siti, fatturazione, piani, flotta, ticket, clienti, abusi, campagne, traduzioni e audit.
Il catalogo viene popolato in modo idempotente a ogni distribuzione e la convalida fallisce esplicitamente se un ruolo fa riferimento a un'autorizzazione inesistente: un errore di battitura non può concedere nulla in modo silenzioso.
Le nuove funzionalità del prodotto aggiungono le relative chiavi di autorizzazione al catalogo prima del rilascio dell'endpoint, in modo che il controllo degli accessi non venga mai integrato a posteriori una volta che la funzionalità è attiva.
Limitare l'ambito di una singola appartenenza a siti specifici o a una regione specifica è un perfezionamento pianificato, non una funzione attivabile oggi. La prassi attuale consiste nell'inserire tali siti in un'organizzazione secondaria e assegnare alla persona un ruolo al suo interno, ottenendo la stessa separazione tramite l'albero di tenancy.
Le chiavi API vengono emesse a livello di organizzazione anziché per persona, pertanto le consideri come credenziali di servizio per le integrazioni e utilizzi le appartenenze per l'accesso umano.

Domande frequenti

Cosa può fare effettivamente ciascun ruolo?

Il proprietario ha il pieno controllo dell'organizzazione e dei relativi account secondari, inclusi membri, chiavi API, siti e metodi di pagamento. Il responsabile della fatturazione visualizza fatture, abbonamenti, metodi di pagamento e piani, senza alcun accesso ai siti. Lo sviluppatore gestisce siti e chiavi API e si occupa dei ticket, senza alcun controllo sulla fatturazione o sui membri. La modalità di sola lettura consente di visualizzare membri, siti, fatturazione, piani, ticket e registro di controllo senza apportare modifiche.

Posso concedere a qualcuno l'accesso a un solo sito?

Non ancora come impostazione per singolo sito: limitare una singola appartenenza a siti specifici è un miglioramento pianificato. Oggi è possibile ottenere la stessa separazione con l'albero di tenancy: inserisca tali siti in un'organizzazione secondaria e assegni un ruolo alla persona in tale sede. Poiché i ruoli vengono concessi per organizzazione, tale accesso non si estende a nessun altro elemento del Suo account.

Le chiavi API sono collegate ai singoli membri del team?

No — le chiavi API vengono emesse per organizzazione, con ambiti granulari legati alle stesse autorizzazioni RBAC e modalità sandbox e live separate. Le utilizzi come credenziali di servizio per integrazioni, CI o Terraform, e utilizzi le appartenenze per le persone. Viene memorizzato solo un hash di ciascuna chiave, ogni chiave registra quando è stata utilizzata l'ultima volta e qualsiasi chiave può essere revocata singolarmente.

Uno sviluppatore può inviare le modifiche a un sito live?

Il ruolo di Sviluppatore include la visualizzazione e il provisioning dei siti, il riavvio dei servizi, lo svuotamento delle cache, la gestione delle chiavi API e l'elaborazione dei ticket. Non include i diritti di pubblicazione su un sito live; pertanto, se desidera che qualcuno possa implementare le modifiche, tale accesso deve appartenere a un proprietario. I ruoli sono assegnati per organizzazione, quindi può ricoprirne uno diverso su un altro account.

Supportate l'SSO per la directory della nostra azienda?

Sì. La gestione delle identità si basa su Keycloak con OIDC e SAML, pertanto il Single Sign-On SAML è disponibile per i clienti enterprise e le agenzie insieme all'accesso tramite magic link, e-mail e password, provider social, passkey e autenticazione a due fattori TOTP, applicata da criteri. Una singola sessione copre il dashboard, il sito pubblico, la knowledge base e i ticket di supporto.

Come faccio a sapere chi ha modificato qualcosa?

Ogni azione con privilegi viene registrata in un registro di controllo di solo accodamento che annota l'autore, l'azione, la destinazione, le prove a supporto e l'indirizzo IP. La sua lettura costituisce un'autorizzazione a sé stante, detenuta sia dal ruolo Proprietario sia da quello di Sola lettura, consentendo al proprietario dell'account e a un revisore di esaminare la medesima cronologia.

L'aggiunta di membri del team modifica l'importo da pagare?

I piani sono tariffati in base alla capacità di hosting anziché al numero di persone. Sulla linea Footprint-Free, ad esempio, tutti i 42 livelli condividono esattamente lo stesso insieme di funzionalità e differiscono solo per il numero di siti consentiti. I prezzi sono sempre calcolati a partire dal catalogo in tempo reale, nella Sua valuta, pertanto quanto visualizzato nella pagina dei prezzi corrisponde esattamente all'importo addebitato.

Posso provare prima di impegnarmi?

Sì. La prova di Footprint-Free dura 14 giorni, non richiede i dati della carta e copre fino a 5 siti, consentendoVi di configurare la Vostra organizzazione, invitare il Vostro team e testare i ruoli su progetti reali prima di pagare qualsiasi importo. I piani a pagamento sono coperti da una garanzia di rimborso di 30 giorni.

Correlati

Configuri il Suo team in pochi minuti, senza ticket

Attivi una prova di 14 giorni senza carta di credito sulla linea Footprint-Free, inviti il Suo team e verifichi il funzionamento dei ruoli su siti reali prima di pagare qualsiasi importo.

Inizia gratis