Делегований доступ

Надавайте людям саме той доступ, який їм потрібен, — і нічого зайвого

Залучіть розробника, передайте виставлення рахунків своєму бухгалтеру, надайте клієнту доступ лише для читання до його власних сайтів або дозвольте нашій команді підтримки переглянути проблему. Кожне надання доступу — це роль із визначеними дозволами, обмежена межами організації, яка забезпечується на рівні бази даних і записується в журнал аудиту лише для додавання.

Кілька осіб, прив'язаних до одного облікового запису, кожен із власними розмежованими дозволами.
  • 94Деталізовані дозволи
  • 12Вбудовані ролі
  • 8Відділи персоналу
  • 700 000+сайтів на хостингу по всьому світу

Доступ — це членство, а не спільний пароль

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

Завжди ваша власна ідентичність

Кожен співавтор входить під власним обліковим записом через Keycloak, наш рівень ідентифікації. Ніхто не вводить ваш пароль, ніхто не ділиться сеансом браузера, а видалення когось — це одна дія, а не зміна пароля й панічні спроби з'ясувати, хто ще його знав.

Організації утворюють деревоподібну структуру

Облікові записи мають ієрархічну структуру: організація реселера містить організації клієнтів, а організації клієнтів містять сайти. Членство застосовується до організації та всього, що підпорядковано їй, тому ви можете передати клієнту агентства контроль над його власною організацією, не розкриваючи водночас інших ваших клієнтів.

Ізоляція забезпечується в базі даних

Ізоляція орендарів — це не фільтр у коді програми, який може пропустити помилка. Row-Level Security у Postgres обмежує кожен запит піддеревом організації абонента, тому запит за межами вашої області видимості нічого не поверне.

Відсутність невидима

Якщо ви запитаєте організацію або сайт за межами вашої області доступу, API відповість звичайною помилкою «не знайдено» замість помилки дозволу. Помилка дозволу підтвердила б факт існування запису; натомість відповідь «не знайдено» взагалі нічого не повідомляє сторонній особі.

Чотири ролі клієнтів, тридцять п'ять дозволів

Дозволи є деталізованими ключами — модуль плюс дія, наприклад sites.restart або billing.refund — а ролі об'єднують їх. Чотири ролі покривають потреби реальних команд, і кожна з них — це початкові дані, які ми вносимо, а не зашита в коді логіка.

Власник

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

Менеджер виставлення рахунків

Бачить організацію, її учасників і каталог планів, а також керує рахунками, способами оплати та нарахуваннями. Жодного доступу до створення, зміни чи видалення бодай одного сайту — саме такий формат, який повинен мати зовнішній бухгалтер.

Розробник

Переглядає та створює сайти, перезапускає служби, очищає кеш, керує ключами API та обробляє запити. Навмисно виключено: виставлення рахунків, рахунки-фактури, методи оплати, керування учасниками, призупинення сайтів та видалення сайтів. Підрядник може вести розробку без можливості виставити вам рахунок або будь-що знищити.

Лише для читання

Бачить організацію, її учасників, її сайти, її білінг, каталог тарифних планів, тікети, стан перекладу та журнал аудиту — і не може нічого змінити. Відповідний дозвіл для клієнта, якому потрібна прозорість, аудитора або зацікавленої особи, якій потрібен лише перегляд.

Вхід, який ваша команда не зможе непомітно послабити

Делегування доступу є безпечним лише тоді, коли облікові записи, яким ви його делегуєте, важко зламати. Автентифікація виконується через Keycloak для кожної особи в обліковому записі на кожній платформі.

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

Коли нашій команді потрібен доступ, він чітко обмежений і реєструється

Робота служби підтримки іноді вимагає перегляду вашого облікового запису. Цей доступ регулюється тією самою моделлю дозволів, що й усе інше — співробітники просто перебувають в організації персоналу, організованій у відділи з вузькими правами доступу.

Відділи, а не загальний адміністратор

Співробітники згруповані за напрямками: Служба підтримки, Білінг і фінанси, Зловживання та безпека, Продажі, Онбординг, Інженерія та експлуатація, Маркетинг і Керівництво. Кожна роль надає доступ до певних модулів і дій, тому спеціаліст бачить лише ту частину панелі адміністратора, яка необхідна для його роботи, і не бачить решти.

Справжня межа можливостей агента підтримки

Роль агента підтримки надає саме такі можливості: перегляд клієнтів, перегляд тікетів і відповідь на них, перегляд сайтів, перезапуск сайту та очищення його кешу. Вона не передбачає налаштування виставлення рахунків, повернення коштів, редагування планів та керування парком серверів. Виправлення, які може здійснювати агент, обмежені роллю, а не добрими намірами.

Вхід як клієнт суворо обмежений

Дозвіл customer.impersonate не входить до ролі Manager — він доступний лише Super Admin. Коли сеанс виконується від вашого імені, на інформаційній панелі відображається постійний банер уособлення, щоб ніколи не виникало сумнівів щодо того, хто саме діє.

Усе конфіденційне зафіксовано в письмовому вигляді

Кожна привілейована та адміністративна дія додається до журналу аудиту, доступного лише для додавання, який фіксує ініціатора, дію, цільовий об'єкт, супутні метадані, IP-адресу та часову мітку — з розділенням за часом у робочому середовищі. Власники та учасники з доступом лише для читання можуть самостійно переглядати журнал своєї організації.

Етапи затвердження для деструктивних дій

Чутливі та деструктивні дії персоналу можуть вимагати посиленої автентифікації або схвалення двома особами перед виконанням, а нові відділи та ролі створюються за допомогою конфігурації, а не внесенням змін до коду.

Машини також отримують делегований доступ

Скрипти, конвеєри CI, інтерфейс CLI, провайдер Terraform та ШІ-агенти проходять автентифікацію за тією ж моделлю дозволів, що й люди, — жодних спільних облікових даних користувачів і жодних довгострокових секретів, вставлених у збірку.

Ключі API діють для кожної організації та мають обмежену область дії

Ключі належать організації та мають деталізовані області доступу, прив'язані до тих самих дозволів RBAC: лише читання, виставлення рахунків, підготовка ресурсів. Надавайте конвеєру лише ту вузьку область доступу, яка йому потрібна, а не весь обліковий запис учасника.

Ключі пісочниці відокремлені від робочого середовища

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

Зберігається лише хеш

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

Інструменти ШІ підключаються відповідно до ваших дозволів

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

Доступ до самих сайтів

Доступ до облікового запису та доступ до сервера — це різні проблеми. Облікові дані на рівні сайту керуються на панелі приладів, видаються за принципом найменших привілеїв та ізолюються так, щоб оболонка одного співавтора була оболонкою лише одного сайту.

  • SSH з ізольованою оболонкою (jailed shell), а також SFTP і FTP — ізоляція CageFS означає, що кожен користувач бачить лише власні файли.
  • wp-cli з термінала панелі та через SSH — для операцій, які розробники дійсно хочуть автоматизувати за допомогою скриптів.
  • Повноцінний редактор VS Code у браузері через code-server, з git, для редагування файлів сайту безпосередньо на панелі керування.
  • Вбудовані phpMyAdmin та Adminer для баз даних, а також вбудований файловий менеджер, доступ до яких здійснюється за допомогою єдиного входу безпосередньо з панелі керування, замість використання другого набору облікових даних.
  • Ключі доступу та облікові дані створюються, переглядаються у списку, змінюються за розкладом і відкликаються на панелі керування, видаються з мінімальними привілеями, а їхнє використання фіксується в журналі аудиту.
  • Тестове середовище з клонуванням і публікацією на робочий сайт тримає ризиковані завдання подалі від продакшену, тому перша зміна нового співавтора ніколи не потрапляє безпосередньо на робочий сайт.

Як структурувати доступ відповідно до вашого фактичного робочого процесу

Один оператор утримує одну організацію та одне членство власника, а також додає роль розробника, коли підрядник приєднується до проєкту. Коли проєкт завершується, членство видаляється, а їхній вхід у систему негайно припиняє діяти — спільних облікових даних, які потрібно змінювати, не залишається.

Агенція використовує дерево організацій. Кожен клієнт отримує власну дочірню організацію, що містить сайти цього клієнта, а співробітники клієнта отримують у ній членство: лише для читання для зацікавленої сторони, якій потрібна видимість, або власника для клієнта, який бажає обслуговувати себе самостійно. Ваш персонал має членство на вищих рівнях дерева й бачить усе портфоліо; клієнт бачить лише власну гілку, і саме безпека на рівні рядків (Row-Level Security) перетворює це на реальність, а не просто обіцянку.

Реселер працює так само, на один рівень вище: організація реселера містить клієнтські організації, кожна з яких має власних учасників, перегляд рахунків і сайти. Той самий базовий елемент забезпечує роботу субакаунтів, команд агентств та ієрархій реселерів — для жодного з них немає окремого, слабшого механізму.

Усе доступно у 14-денній пробній версії без прив’язки картки. Зареєструйтеся без платіжних даних, запросіть колегу, перевірте, до чого кожен користувач із певною роллю має або не має доступу, і перегляньте власний журнал аудиту.

Часті запитання

Чи можу я надати комусь доступ лише до одного сайту?

Сьогодні членство надає свою роль усій організації та всьому, що розташовано під нею в дереві структури, тому спосіб розділити набори сайтів полягає в розділенні організацій — помістіть ці сайти у власну дочірню організацію та надайте членство там. Це зрозуміла модель для агентств і торговельних посередників, де кожен клієнт уже прагне мати власні межі. Налаштування меж ресурсів для окремого членства, тобто закріплення одного членства за вказаними сайтами в межах однієї організації, є запланованим удосконаленням, а не тим, що доступно зараз.

Чи може запрошений мною розробник видалити сайт або опублікувати його в робочому середовищі?

Роль розробника не передбачає видалення або призупинення сайту — ці права належать ролі власника. Вона надає дозвіл на перегляд і створення сайтів, перезапуск служб, очищення кешу, керування ключами API та роботу з тікетами. Дозволи на розгортання та перенесення на робоче середовище також не входять до повноважень розробника, тому перенесення в робоче середовище залишається за власником облікового запису. Поєднайте це з тестовим середовищем, щоб розробка від самого початку відбувалася поза межами робочого сайту.

Що працівники Zinn Digital® можуть бачити в моєму обліковому записі?

Це повністю залежить від ролі співробітника, а кожна роль є вузьким набором ключів дозволів. Агент служби підтримки, наприклад, може переглядати ваш обліковий запис і сайти, переглядати ваші запити та відповідати на них, перезапускати сайт і очищати його кеш — і не може змінювати налаштування виставлення рахунків, повернення коштів, плани чи інфраструктуру. Вхід від імені клієнта — це окремий дозвіл, наданий лише суперадміністратору, і коли це відбувається, на панелі керування відображається постійний банер уособлення. Кожна привілейована дія фіксується в журналі аудиту із зазначенням виконавця, дії, об'єкта, IP-адреси та мітки часу, і ви можете самостійно переглядати журнал вашої організації.

Як швидко відкликати доступ, якщо хтось іде?

Вилучіть членство, і доступ користувача до цієї організації припиниться — він збереже свій обліковий запис, але не матиме ролі і, відповідно, жодних дозволів у вашому обліковому записі. Ключі API відкликаються індивідуально, тому ключ конвеєра можна анулювати, не зачіпаючи нічого іншого. Якщо ви використовуєте єдиний вхід SAML, скасування надання доступу у вашому постачальнику ідентифікаційних даних керує входом централізовано. Облікові дані рівня сайту, як-от ключі SSH, відкликаються на інформаційній панелі, а саме вилучення фіксується в журналі аудиту.

Чи діляться учасники команди моїми ключами API?

Ні — але варто точно пояснити, чому. Ключі API належать організації, а не окремому учаснику, і вони мають власні деталізовані області дії, пов'язані з тим самим каталогом дозволів. Тому замість того, щоб передавати ключ людині, ви створюєте ключ для конкретного завдання з найвужчою областю дії, необхідною для цього завдання, і відкликаєте цей ключ після завершення завдання. Зберігається лише хеш секретного ключа, і кожен ключ фіксує час останнього використання, тому невикористані ключі легко знайти та вивести з експлуатації.

Чи можу я підключити ШІ-агента, не надаючи йому ключі від усього?

Так. Наш сервер MCP автентифікує агентів за допомогою OAuth 2.1 та обмежує їх відповідно до вашої організації та вашої ролі RBAC за допомогою відкличних токенів для кожного інструмента окремо, тому ви надаєте конкретні можливості замість повного доступу. Дії з незворотними наслідками потребують підтвердження, діють ліміти витрат, а кожна дія фіксується в тому самому журналі аудиту, що й активність людей.

Що заважає одному орендарю отримати доступ до даних іншого орендаря?

Безпека на рівні рядків (Row-Level Security) у Postgres обмежує запити піддеревом організації абонента безпосередньо в самій базі даних, а фільтр на рівні програми слугує ешелонованим захистом, а не єдиною лінією оборони. Запити на записи поза межами області повертають помилку «не знайдено» замість помилки дозволу, тому нічого не розкривається про те, що саме існує. На боці сервера ізоляція окремих сайтів за допомогою CageFS утримує командну оболонку та файли кожного орендаря виключно в межах його власного сайту.

Чи можу я спробувати це перед оплатою?

Так. 14-денний пробний період не потребує банківської картки — жодних платіжних даних, жодних зобов’язань — і поширюється на хостинг Footprint-Free з підтримкою до п’яти сайтів. Цього достатньо, щоб запросити колегу, призначити роль і переконатися, що обмеження працюють саме так, як вам потрібно, перш ніж брати на себе зобов’язання.

Делегуйте з межею, на яку ви можете вказати

Почніть 14-денний пробний період без банківської картки, запросіть користувача та спостерігайте за роботою моделі дозволів: ролі, яким можна давати назви, сфери доступу, які можна відкликати, та журнал аудиту, що чітко фіксує, хто і що робив.

Почати безкоштовно