Echipe și acces

Oferă fiecărei persoane din echipa ta exact accesul de care are nevoie

Patru roluri pentru clienți, sub-conturi care reflectă modul în care este structurată afacerea ta, chei API per organizație, autentificare unică și un jurnal de audit în spatele fiecărei acțiuni privilegiate. Același model de acces funcționează în panoul de control, API, CLI, Terraform și pe serverul nostru MCP. Disponibilitate: furnizorul Terraform este în curs de dezvoltare activă și nu este disponibil încă. Orice altceva descris aici este disponibil începând de astăzi.

  • 650.000+site-uri găzduite la nivel mondial
  • 4roluri de clienți, predefinite și pregătite
  • 35chei de permisiuni granulate
  • 14 zileperioadă de probă gratuită cu cardul

Patru roluri, trasate acolo unde munca chiar se divide

Accesul nu este un singur comutator pornit/oprit. Fiecare organizație client vine cu patru roluri, fiecare fiind un pachet fix de permisiuni granulare pe modul.acțiune — astfel încât un contact financiar să nu atingă niciodată un server și un dezvoltator să nu vadă niciodată o factură.

Proprietar

Control deplin asupra organizației și a subconturilor sale: crearea de organizații copil, invitarea și eliminarea membrilor, schimbarea rolurilor, gestionarea cheilor API, furnizarea, repornirea, suspendarea și ștergerea site-urilor, gestionarea facturilor și a metodelor de plată, precum și citirea jurnalului de audit. Două lucruri rămân în mod deliberat în afara acestui domeniu — închiderea unei organizații și emiterea de rambursări sunt acțiuni ale personalului, nu atribuții ale rolului de client.

Manager facturare

Tot ce ține de finanțe și nimic altceva: facturi, abonamente, metode de plată și catalogul de planuri, plus o prezentare generală a organizației și a listei de membri. Fără acces la site — un contact financiar sau un contabil extern nu poate reporni, suspenda sau șterge nimic.

Dezvoltator

Lucrează pe site-uri fără a atinge banii: vizualizează și provizionează site-uri, repornește servicii, golește cache-urile, gestionează cheile API și deschide sau răspunde la tichete de suport. Fără vizualizare a facturării, fără gestionare a membrilor, fără suspendare și fără ștergere — acțiunile distructive și comerciale rămân la latitudinea proprietarului.

Doar în citire

O vizualizare completă fără posibilitatea de a modifica ceva — membrii, site-urile, facturarea, planurile, tichetele, starea traducerilor și jurnalul de audit. Rolul potrivit pentru un client cu putere de decizie, un auditor intern sau un nou angajat care încă se familiarizează cu activitatea.

Subconturi care se potrivesc cu structura ta reală

Tenancitatea este un arbore, nu o listă plată. O organizație de revânzare se află deasupra organizațiilor sale client, iar site-urile se află sub acestea. Un membru al echipei este o apartenență — un utilizator, o organizație, un rol — așa că același element de bază alimentează o echipă formată din două persoane, o agenție care administrează o sută de conturi de clienți și un revânzător care rulează subconturi sub propria marcă.

Rolurile sunt acordate per organizație, iar aplicarea lor se face tot per organizație. Un rol într-o organizație nu acordă niciun acces într-o altă organizație separată și neafiliată — un colaborator poate fi Dezvoltator pe contul unui client și Doar în citire pe al doilea, folosind aceeași autentificare. Cu toate acestea, accesul se propagă în jos în propriile ierarhii: un rol dintr-o organizație părinte se aplică organizațiilor imbricate sub aceasta, aceasta fiind modalitatea prin care revânzătorii și agențiile își gestionează clienții.

Izolarea este impusă la nivel de bază de date, nu doar în codul aplicației. Securitatea la nivel de rând din Postgres limitează fiecare interogare a unui chiriaș la subarborele apelantului, iar orice element din afara acelui subarbore returnează un rezultat negăsit în loc de o eroare de permisiune — astfel încât platforma nici măcar nu confirmă existența organizației sau site-ului altui chiriaș.

Aceleași permisiuni pe fiecare interfață

Rolurile nu reprezintă doar o comoditate la nivel de panou de control. Fiecare modalitate de acces în platformă se traduce prin aceleași chei de permisiune, așa că nu există nicio ușă din dos care să ocolească regulile tale de acces.

Panou de control

Site-uri, facturare, tichete, notificări, înștiințări, chei API și gestionarea echipei, toate într-o singură consolă. Interfața afișează doar ceea ce permite rolul membrului autenticat, astfel încât utilizatorilor să nu li se arate controale pe care nu le pot folosi.

API public și CLI

API-ul publicat este același motor de API pe care îl folosește panoul de control. Cheile API sunt emise per organizație, cu domenii granulare legate de permisiunile RBAC, iar modurile separate de testare și producție înseamnă că puteți testa integrările fără a afecta facturarea sau provizionarea reală.

Furnizor Terraform

Gestionează site-uri, domenii, DNS, căsuțe poștale și planuri ca infrastructură-ca-cod și rulează terraform apply pentru a așeza găzduirea — guvernată de aceleași domenii de aplicare ca orice altceva.

Server MCP

Conectează Claude Code, Cursor, ChatGPT, Claude Desktop sau orice alt instrument compatibil MCP. Tokenurile sunt asociate unei organizații și permisiunilor sale RBAC, pot fi revocate pentru fiecare instrument în parte, cu confirmare pentru acțiunile distructive, limite de cheltuieli și un istoric complet de audit.

Gestionarea cheilor

Doar un hash al fiecărei chei API este stocat — niciodată cheia în clar. Cheile conțin un nume și un prefix vizibil pentru a le putea distinge, pentru a înregistra când au fost utilizate ultima oară și pentru a putea fi revocate individual, fără a le afecta pe celelalte.

O singură autentificare, bazată pe standarde, pentru tot

Identitatea rulează pe Keycloak, așa că autentificarea folosește OIDC și SAML adecvate, în loc de un formular de autentificare personalizat adăugat unui panou de găzduire.

  • Autentificare prin e-mail cu link magic în mod implicit, cu e-mail și parolă ca metodă alternativă pentru cei care o preferă.
  • Chei de acces și WebAuthn pentru autentificare rezistentă la phishing, plus autentificare cu doi factori TOTP impusă tuturor prin politică.
  • Autentificare socială prin Google, Microsoft, GitHub și alți furnizori de identitate.
  • Autentificare unică SAML pentru clienții enterprise și agenții, astfel încât accesul echipei să urmeze directorul existent.
  • O singură sesiune pentru panoul de control, consola de administrare, site-ul public, baza de cunoștințe și tichetele de suport – te autentifici o dată, nu de cinci ori.
  • Fiecare e-mail de înregistrare este validat înainte ca un cont să fie creat, astfel încât adresele nelivrabile și invalide nu ajung niciodată în echipa ta.
  • Deoarece se bazează pe standarde, furnizorul de identitate în sine poate fi înlocuit fără a fi nevoie de reconfigurarea arhitecturii din jur — aceeași regulă de evitare a blocajului pe care o aplicăm oricărui alt furnizor.

Transparență pe care o poți prezenta unui auditor

Fiecare acțiune cu drepturi privilegiate scrie o înregistrare de audit de tip append-only: cine a efectuat-o, ce a făcut, asupra cărui element, dovezile suport și adresa IP de origine. Jurnalul este de tip append-only — evenimentele sunt adăugate, nu editate pe loc — iar în producție este partiționat temporar, astfel încât să rămână rapid pe măsură ce crește.

Citirea acelui jurnal reprezintă în sine o permisiune. Proprietarii și membrii cu acces doar pentru citire o dețin, astfel încât persoana responsabilă de cont și cea care îl auditează pot vedea ambele istoricul complet fără a avea nevoie de drepturi extinse pentru acest lucru.

În jurul acestora se află controalele pe care le cer echipele mai mari: politici de sesiune, liste de permisiuni IP opționale per organizație și autentificare suplimentară pentru acțiuni sensibile, astfel încât o sesiune activă să nu fie singură suficientă pentru a face ceva grav.

Cum cresc permisiunile odată cu tine

Catalogul de permisiuni este reprezentat de date, nu de logică hardcodată — motiv pentru care poate fi extins fără a fi nevoie de o reproiectare a platformei.

  • 35 de chei modul.acțiune granulate astăzi, care acoperă organizații, membri, chei API, site-uri, facturare, planuri, flotă, tichete, clienți, abuz, campanii, traduceri și audit.
  • Catalogul este populat idempotent la fiecare implementare, iar validarea eșuează zgomotos dacă un rol face vreodată referire la o permisiune care nu există — o greșeală de scriere nu poate acorda în tăcere nimic.
  • Noile capacități ale produsului își adaugă cheile de permisiuni în catalog înainte ca endpoint-ul să fie lansat, astfel încât controlul accesului să nu fie niciodată adaptat retroactiv după ce o funcționalitate este activă.
  • Limitarea unui singur abonament la site-uri specifice sau la o anumită regiune este o îmbunătățire planificată, nu ceva ce puteți activa astăzi. Modelul actual este de a plasa acele site-uri într-o organizație copil și de a acorda persoanei un rol acolo — ceea ce vă oferă aceeași separare folosind arborele de chiriași.
  • Cheile API sunt emise la nivel de organizație și nu per persoană, așa că tratați-le ca pe credențiale de serviciu pentru integrări și folosiți apartenențele la grupuri pentru accesul uman.

Întrebări frecvente

Ce poate face efectiv fiecare rol?

Proprietarul are control complet asupra organizației și a subconturilor sale, inclusiv membri, chei API, site-uri și metode de plată. Managerul de facturare vede facturile, abonamentele, metodele de plată și planurile, fără acces la site-uri. Dezvoltatorul gestionează site-urile și cheile API și se ocupă de tichete, fără control asupra facturării sau a membrilor. Utilizatorul cu acces doar pentru citire poate vizualiza membrii, site-urile, facturarea, planurile, tichetele și Jurnalul de audit fără a modifica nimic.

Pot să-i ofer cuiva acces la un singur site?

Nu este încă o setare disponibilă la nivelul fiecărui site — limitarea unui singur abonament la anumite siteuri este o îmbunătățire planificată. În prezent, puteți obține aceeași separare cu ajutorul arborelui de multi-tenancy: plasați acele siteuri într-o organizație copil și atribuiți persoanei un rol acolo. Deoarece rolurile sunt acordate per organizație, acest acces nu se extinde la nicio altă componentă din contul dumneavoastră.

Sunt cheile API legate de membrii individuali ai echipei?

Nu — cheile API sunt emise per organizație, cu domenii granulare legate de aceleași permisiuni RBAC și moduri sandbox și live separate. Utilizați-le ca acreditări de serviciu pentru integrări, CI sau Terraform și folosiți calitățile de membru pentru persoane. Doar un hash al fiecărei chei este stocat, fiecare cheie înregistrează când a fost utilizată ultima dată și orice cheie poate fi revocată individual.

Un dezvoltator poate trimite modificări pe un site live?

Rolul de Dezvoltator acoperă vizualizarea și furnizarea site-urilor, repornirea serviciilor, golirea memoriei cache, gestionarea cheilor API și gestionarea tichetelor. Nu conferă drepturi de publicare pe un site activ, așa că, dacă doriți ca cineva să poată promova modificări, acest acces trebuie să revină unui proprietar. Rolurile sunt per organizație, așa că puteți deține unul diferit pe un alt cont.

Susțineți SSO pentru directorul companiei noastre?

Da. Identitatea funcționează pe Keycloak cu OIDC și SAML, astfel încât autentificarea unică SAML este disponibilă pentru clienții din segmentele enterprise și agenții, alături de autentificarea prin link magic, e-mail și parolă, furnizori de social media, chei de acces și autentificare cu doi factori TOTP, care este impusă prin policy. O singură sesiune acoperă panoul de control, site-ul public, baza de cunoștințe și tichetele de suport.

Cum pot afla cine a făcut o modificare?

Fiecare acțiune cu privilegii este înregistrată într-un jurnal de audit imutabil care conține actorul, acțiunea, ținta, dovezile suport și adresa IP. Citirea acestuia reprezintă o permisiune în sine, deținută atât de rolul de Proprietar, cât și de cel de Doar citire, astfel încât un proprietar de cont și un auditor pot examina același istoric.

Adăugarea membrilor în echipă modifică ceea ce plătesc?

Planurile sunt taxate în funcție de capacitatea de găzduire și nu de numărul de persoane. Pe linia Footprint-Free, de exemplu, toate cele 42 de niveluri împart exact același set de drepturi și difera doar prin numărul de site-uri pe care le permit. Prețurile sunt afișate întotdeauna din catalogul live, în moneda dvs., astfel încât ceea ce vedeți pe pagina de prețuri este ceea ce vi se va percepe efectiv.

Pot încerca acest lucru înainte de a mă abona?

Da. Perioada de probă Footprint-Free durează 14 zile, nu necesită datele cardului și acoperă până la 5 site-uri, astfel încât să vă puteți configura organizația, să vă invitați echipa și să testați rolurile pe sarcini reale înainte de a plăti ceva. Există o garanție de rambursare a banilor de 30 de zile pentru planurile cu plată.

Configurați-vă echipa în câteva minute, nu în tichete

Începeți o perioadă de probă de 14 zile fără card pe linia Footprint-Free, invitați-vă echipa și vedeți rolurile în acțiune pe site-uri reale înainte de a plăti ceva.

Începe gratuit