Делегиран достъп

Дайте на хората точно този достъп, от който се нуждаят — и нищо повече

Привлечете разработчик, прехвърлете фактурирането на счетоводителя си, дайте на клиент изглед само за четене към собствените му сайтове или позволете на нашия екип за поддръжка да разгледа проблем. Всяко право е роля с определени разрешения, обвързана с организация, наложена на ниво база данни и записана в одитен дневник само за добавяне.

  • 94детайлни разрешения
  • 12вградени роли
  • 8отдели на персонала
  • 650 000+сайтове, хоствани по целия свят

Достъпът е членство, а не споделена парола

Споделянето на една парола е начинът, по който достъпът до акаунта се обърква. В Zinn Digital® всеки човек има своя собствена самоличност, а достъпът представлява членство — потребител, организация и роля — което можете да предоставите, промените или оттеглите поотделно.

Вие самите, винаги

Всеки сътрудник влиза в системата със собствен профил чрез Keycloak, нашия слой за самоличност. Никой не въдеше вашата парола, никой не споделя браузърна сесия, а премахването на даден потребител е еднократно действие вместо смяна на паролата и чудене кой друг я е знаел.

Организациите образуват дърво

Акаунтите са йерархични — организацията на дистрибутора съдържа клиентски организации, а клиентските организации съдържат сайтове. Членството се прилага за организацията и всичко под нея, така че можете да предоставите на клиент от агенционен тип контрол върху собствената им организация, без никога да разкривате останалите си клиенти.

Изолацията е наложена в базата данни

Изолацията на наемателите не е филтър в програмния код, който да бъде пропуснат поради грешка. Postgres Row-Level Security ограничава всяка заявка в рамките на организационното поддърво на извикващата страна, така че заявка извън вашия обхват няма какво да върне.

Липсата е невидима

Ако заявят организация или сайт извън вашия обхват, API отговаря с обикновено съобщение за липса вместо с грешка за права достъп. Грешката за права достъп би потвърдила, че записът съществува; липсата му не разкрива абсолютно нищо на външно лице.

Четири клиентски роли, тридесет и пет разрешения

Правата са детайлни ключове — модул плюс действие, като sites.restart или billing.refund — а ролите ги обединяват. Четири роли покриват нужните на реалните екипи форми и всяка от тях представлява начални данни, а не логика, скрита в кода.

Собственик

Пълен контрол: създаване на дъщерни организации, поканяване и премахване на членове, промяна на роли, управление на API ключове, създаване, рестартиране, изчистване на кеша, спиране и изтриване на сайтове, управление на фактуриране и фактури, отваряне на тикети и четене на одиторския дневник. Ролята, която запазвате за себе си.

Мениджър по фактурирането

Вижда организацията, нейните членове и каталога с планове, и управлява фактури, начини на плащане и такси. Няма достъп за създаване, промяна или изтриване на нито един сайт — точно ролята, която един външен счетоводител трябва да има.

Разработчик

Преглежда и създава сайтове, рестартира услуги, изчиства кеша, управлява API ключове и работи с билети. Съзнателно изключени: фактуриране, фактури, начини на плащане, управление на членове, спиране и изтриване на сайтове. Един изпълнител може да гради, без да може да ви фактурира или да унищожи нещо.

Само за четене

Вижда организацията, нейните членове, сайтове, фактуриране, каталога с планове, заявки, статус на преводите и одитния журнал – без да може да променя нищо от това. Подходящото право на достъп за клиент, който иска видимост, одитор или заинтересовано лице, което трябва само да преглежда.

Влизането на вашия екип не може незабелязано да бъде отслабено

Делегирането на достъп е безопасно само ако акаунтите, на които делегирате, са трудни за компрометиране. Удостоверяването се извършва през Keycloak за всеки потребител в акаунта и на всяка повърхност.

  • Ключове за достъп и WebAuthn за устойчиво на фишинг влизане, плюс двуфакторно удостоверяване с TOTP, наложено за всички с политика — а не незадължителна настройка, която член на екипа може да пропусне.
  • Влизане с магически линк по подразбиране, с имейл и парола като алтернатива, както и социален вход през Google, Microsoft, GitHub и други.
  • SAML единно входно за корпоративни клиенти и агенции, така че новите служители и напускащите се управляват от вашия доставчик на самоличност, а не ръчно.
  • Една сесия в клиентското табло, публичния сайт, базата знания и заявките за поддръжка – влезте веднъж и излезте отвсякъде с едно щракване.
  • Политики на сесиите, поетапно удостоверяване за чувствителни действия и незадължителни списъци с разрешени IP адреси за организациите, които искат достъпът да е обвързан с познати мрежи.
  • Всеки имейл за регистрация се валидира, преди акаунтът да бъде създаден, така че недоставимите, еднократните и функционалните адреси се отсяват предварително, вместо по-късно да се превърнат в изоставени членове.

Когато нашият екип се нуждае от достъп, той е ограничен по обхват и се регистрира в системните логове

Поддержката понякога изисква преглед на вашия акаунт. Този достъп се управлява от същия модел на права като всичко останало — служителите просто се намират в организация на персонала, разпределени по отдели с ограничени правомощия.

Отдели, а не общи администратори

Екипът е разпределен в групите „Поддръжка“, „Фактуриране и финанси“, „Злоупотреби и надеждност и безопасност“, „Продажби“, „Въвеждане в експлоатация“, „Инженерство и операции“, „Маркетинг“ и „Мениджмънт“. Всяка роля предоставя конкретни модули и действия, така че агентите да виждат само онази част от административната конзола, която е необходима за тяхната работа, а не останалата.

Истинският таван на даден специалист по поддръжката

Ролята на съпорт агента предоставя точно това: преглед на клиенти, преглед и отговор на тикети, преглед на сайтове, рестартиране на сайт и изчистване на кеша му. Тя не включва конфигурация на фактуриране, възстановяване на суми, редактиране на планове и управление на флотилия. Корекционните действия, които един агент може да извършва, се ограничават от ролята, а не от добрите намерения.

Влизането като клиент е строго ограничено

Правото customer.impersonate не е част от ролята Мениджър — то се притежава само от Супер администратор. Когато се изпълнява сесия от ваше име, таблото за управление носи постоянен банер за влизане от чужо име, така че никога да няма двусмислие кой действа.

Всичко привилегировано е записано

Всяко привилегировано и административно действие се добавя към одитния журнал с възможност само за добавяне, който записва извършителя, действието, целта, поддържащите метаданни, IP адреса и времевия печат — с времеви партиции в производствената среда. Собствениците и членовете с права само за четене могат сами да четат журнала на своята организация.

Контролни точки за одобрение при деструктивни действия

Чувствителните и разрушителни действия на персонала могат да изискват допълнително удостоверяване или одобрение от двама души преди тяхното изпълнение, а новите отдели и роли представляват конфигурация, а не промяна в кода.

Машините също получават делегиран достъп

Сkриптовете, CI пайплайните, CLI инструментите, Terraform провайдърът и AI агентите се автентифицират чрез същия модел на права като потребителите — без споделени човешки идентификационни данни и без дългосрочни секрети, поставени в кеш или компилация.

API ключовете са за всяка организация и с определен обхват

Ключовете принадлежат на организация и носят грануларни обхвати, обвързани със същите RBAC разрешения — само за четене, фактуриране и подготовка. Предоставяйте на даден пиплайн тесния обхват, от който се нуждае, вместо целия акаунт на даден член.

Тестовите ключове са отделни от производствените

Ключовете за тестовия режим и работния режим са различни, така че интеграция в процес на разработване няма достъп до производствени данни случайно или чрез копирана променлива на средата.

Съхранява се само хешът

Съхраняваме SHA-256 хеш на секрета и префикс за търсене — никога суровия ключ. Виждате ключ само веднъж при създаването му. Всеки ключ следи кога е бил използван за последно и може да бъде отменен самостоятелно, без да се нарушава нищо друго.

AI инструментите се свързват с вашите разрешения

Нашият MCP сървър позволява на всеки съвместим с MCP агент да управлява хостинга ви на естествен език, автентифициран с OAuth 2.1 и ограничен до вашата организация и RBAC роля, с отменяеми токени за всеки инструмент, потвърждение при деструктивни действия, лимити на разходите и пълен одит лог.

Достъп до самите сайтове

Достъпът до акаунта и достъпът до сървъра са различни проблеми. Учестникът на ниво сайт се управлява в таблото за управление, издава се с минимални привилегии и е изолиран, така че конзолата на един сътрудник да бъде конзола само за един сайт.

  • SSH с jailed shell, както и SFTP и FTP — изолацията чрез CageFS гарантира, че всеки потребител вижда само собствените си файлове.
  • wp-cli през терминала на контролния панел и през SSH, за операциите, които разработчиците наистина искат да скриптират.
  • Пълен редактор VS Code в браузъра чрез code-server — разширения, вграден терминал и git, редактиране на файловете на сайта директно в таблото за управление.
  • Вградени phpMyAdmin и Adminer за бази данни, както и вграден файлов мениджър, и двете с еднократно влизане (single-sign-on) от таблото за управление, вместо да са защитени с втори набор от идентификационни данни.
  • Достъп ключовете и удостоверенията се създават, изброяват, ротират и анулират в таблото за управление, издават се с минимални привилегии, а използването им се одитира.
  • Стейaging-ът с клониране и push-to-live предпазва производствената среда от рискови промени, така че първата промяна на нов сътрудник никога да не отива директно в жив сайт.

Как да структурирате достъпа спрямо начина, по който реално работите

Самостоятелен оператор поддържа една организация и едно собственическо членство, и добавя роля на разработчик, когато външен изпълнител се включи в проект. Когато проектът приключи, членството се премахва и входът му спира да работи незабавно – не остават споделени идентификационни данни за смяна.

Агенцията използва организационното дърво. Всеки клиент получава собствена дъщерна организация, съдържаща сайтовете на този клиент, като собствените хора на клиента получават членство там – само за четене за заинтересовано лице, което иска видимост, или собственик за клиент, който иска самообслужване. Вашият персонал има членство по-нагоре в дървото и вижда портфолиото; клиентът вижда само собствения си клон и именно защитата на ниво редове прави това факт, а не просто обещание.

Преселърът работи по същия начин, едно ниво по-нагоре: преселърската организация съдържа клиентски организации, всяка със собствени членове, изглед за фактуриране и сайтове. Същият базов принцип захранва подсметките, агенционните екипи и преселърските йерархии — няма отделен, по-слаб механизъм за нито един от тях.

Всичко е налично в рамките на 14-дневния пробен период без нужда от карта. Регистрирайте се без данни за плащане, поканете колега, вижте какво може и какво не може да достъпва всяка роля, и прегледайте собствения си одит журнал.

Често задавани въпроси

Мога ли да дам достъп на някого само до един сайт?

Към днешна дата членството дава права в рамките на цялата организация и всичко под нея в йерархията, така че начинът да разделите комплексите от сайтове е чрез разделяне на организациите — поставете тези сайтове в тяхна собствена дъщерна организация и задайте членството там. Това е изчистен модел за агенции и дистрибутори, при които всеки клиент вече изисква собствени граници. Ограничаването на ресурсите за отделно членство (обвързването на едно единствено членство с конкретни сайтове в рамките на една организация) е планирано подобрение, което все още не е налично.

Може ли поканен от мен разработчик да изтрие сайт или да го публикува на живо?

Ролята на разработчик не включва изтриване или спиране на сайтове — тези права принадлежат на ролята на собственик. Тя дава възможност за преглед и създаване на сайтове, рестартиране на услуги, изчистване на кеша, управление на API ключове и работа по заявки. Правата за внедряване и експортиране на живо също не са част от правата на разработчика, така че промотирането към продукционна среда остава за собственика на акаунта. Съчетайте това със стейгинг среда, така че работата по изграждането да се извършва извън активния сайт.

Какво могат да виждат служителите на Zinn Digital® в моя акаунт?

Всичко зависи изцяло от ролята на служителя, като всяка роля представлява тесен набор от ключове за разрешения. Един агент за поддръжка например може да преглежда вашия акаунт и сайтове, да преглежда и отговаря на вашите тикети, да рестартира сайт и да изчиства кеша му — и няма достъп до конфигурацията за фактуриране, възстановяванията на суми, плановете или флотата. Влизането като клиент е отделно разрешение, притежавано само от „Супер администратор“, и когато това се случи, таблото за управление показва постоянен банер за представяне от чуждо име. Всяко действие с привилегии се записва в одитния лог с информация за извършителя, действието, целта, IP адреса и времевия печат, като можете сами да четете лога на вашата организация.

Как да отменя достъпа бързо, ако някой напусне?

Премахнете членството и техният достъп до тази организация се прекратява — те все пак запазват собствената си самоличност, но остават без роля и съответно без никакви разрешения във вашия акаунт. API ключовете се анулират поотделно, така че ключът за пайплайн може да бъде спрян, без да се засяга нищо друго. Ако използвате SAML единично влизане (SSO), премахването на профила във вашия доставчик на самоличност управлява влизането централно. Удостоверенията на ниво сайт, като SSH ключовете, се анулират в контролния панел, а самото премахване се регистрира в одитния журнал.

Споделят ли членовете на екипа моите API ключове?

Не — но си струва да бъдем прецизни защо. API ключовете принадлежат на организацията, а не на отделен член, и те носят свои собствени детайлни обхвати, обвързани със същия каталог с разрешения. Така че вместо да давате ключ на човек, вие създавате ключ за задачата, която той върши, с най-тесния обхват, който тази задача изисква, и отменяте този ключ, когато задачата приключи. Съхранява се само хеш на тайната и всеки ключ записва кога е бил използван за последно, така че неизползваните ключове да бъдат лесни за откриване и оттегляне.

Мога ли да свържа AI агент, без да му давам достъп до всичко?

Да. Нашият MCP сървър удостоверява агентите чрез OAuth 2.1 и ги ограничава до вашата организация и вашата RBAC роля, с отменими токени за всеки инструмент, така че предоставяте конкретна възможност, вместо пълен достъп. Деструктивните действия изискват потвърждение, прилагат се лимити на разходите и всяко действие попада в същия одит лог като човешката активност.

Какво спира един наемател да получи достъп до данните на друг наемател?

Ре ред-нивната сигурност (Row-Level Security) на Postgres ограничава заявките до поддървото на организацията на извикващия директно в базата данни, като филтърът на ниво приложение служи като защитен слой в дълбочина, а не като единствена линия. Заявките за записи извън обхвата връщат състояние „не е открито“ вместо грешка за права достъп, така че нищо не се разкрива за това какво съществува. От страна на сървъра, изолацията по сайтове чрез CageFS запазва обвивката и файловете на всеки наемател ограничени до собствения му сайт.

Мога ли да изпробвам това преди да платя?

Да. 14-дневният пробен период е без карта — без данни за плащане и без ангажимент — и покрива Footprint-Free Hosting с до пет сайта. Той е напълно достатъчен, за да поканите колега, да зададете роля и да се уверите, че границите функционират според нуждите ви, преди да се ангажирате.

Делегирайте с граница, която можете да посочите

Започнете 14-дневния си пробен период без нужда от карта, поканете някой и гледайте как моделът за разрешения си върши работата — роли, които можете да наименувате, обхвати, които можете да отменяте, и одит логове, които казват точно кой какво е направил.

Започни безплатно