Делегований доступ
Залучіть розробника, передайте білінг своєму бухгалтеру, надайте клієнту доступ лише для читання до його власних сайтів або дозвольте нашій службі підтримки поглянути на проблему. Кожне надання доступу — це роль із визначеними дозволами, обмежена межами організації, що забезпечується на рівні бази даних і записується в журнал аудитів лише для додавання.
Спільний логін — це шлях до проблем із доступом до облікового запису. У Zinn Digital® кожен користувач має власну ідентифікацію, а доступ є членством — користувач, організація та роль, — яке ви можете надавати, змінювати або скасовувати окремо.
Кожен співавтор входить у систему як він сам через Keycloak, наш шар ідентифікації. Ніхто не вводить ваш пароль, ніхто не спільно використовує сеанс браузера, а видалення когось потребує лише однієї дії замість ротації пароля та хаосу з'ясування того, хто ще його знав.
Облікові записи мають ієрархічну структуру: організація реселлера містить організації клієнтів, а організації клієнтів містять сайти. Членство поширюється на саму організацію та все, що підпорядковане їй, тож ви можете надати клієнту-агенції контроль над його власною організацією, не наражаючи на ризик інших клієнтів.
Ізоляція орендарів — це не фільтр у коді застосунку, який можна пропустити через помилку. Порядкова безпека Postgres (Row-Level Security) обмежує кожне опитування піддеревом організації ініціатора, тож запит поза вашою зоною видимості не має жодних даних для повернення.
Запит щодо організації чи сайту поза межами вашої компетенції повертає від API просту відповідь про відсутність замість помилки дозволу. Помилка дозволу підтвердила б існування запису; відповідь про відсутність нічого не каже сторонній особі.
Дозволи є детальними ключами — модуль плюс дія, як-от sites.restart або billing.refund — а ролі об'єднують їх. Чотири ролі охоплюють конфігурації, необхідні реальним командам, і кожна з них є даними, які ми заповнюємо за замовчуванням, а не логікою, зашитою в коді.
Повний контроль: створення дочірніх організацій, запрошення та видалення учасників, зміна ролей, керування ключами API, створення, перезапуск, очищення, призупинення та видалення сайтів, керування білінгом і рахунками, створення тікетів та читання журналу аудиту. Роль, яку ви залишаєте собі.
Має доступ до організації, її учасників і каталогу тарифних планів, а також керує рахунками, способами оплати та стягненнями. Жодного доступу до створення, зміни чи видалення окремих сайтів — ідеально підходить для зовнішнього бухгалтера.
Переглядає та створює сайти, перезапускає служби, очищує кеш, керує ключами API та опрацьовує звернення. Усміхнено виключено: білінг, рахунки, способи оплати, керування учасниками, блокування та видалення сайтів. Підрядник може створювати без можливості виставляти рахунки чи щось знищувати.
Має доступ до організації, її учасників, сайтів, біллінгу, каталогу тарифних планů, тикетів, статусу перекладів і журналу аудиту — але нічого з цього не може змінювати. Чудове право доступу для клієнта, якому потрібна видимість, для аудитора або зацікавленої особи, якій потрібно лише переглядати інформацію.
Делегування доступу є безпечним лише тоді, коли облікові записи, яким ви його делегуєте, надійно захищені від зламу. Автентифікація для кожної особи в обліковому записі на кожному інтерфейсі здійснюється через Keycloak.
Робота служби підтримки іноді вимагає заглянути всередину вашого облікового запису. Цей доступ регулюється такою ж моделлю дозволів, як і все інше: співробітники просто входять до організації співробітників, яка розділена на відділи з обмеженими повноваженнями.
Персонал об'єднано в такі групи: «Підтримка», «Біллінг і фінанси», «Зловживання та довіра й безпека», «Продажі», «Онбординг», «Інженерія та операції», «Маркетинг» і «Менеджмент». Кожна роль надає доступ до певних модулів і дій, тому агент бачить лише ту частину панелі адміністратора, яка необхідна для його роботи, а решту — ні.
Роль агента підтримки надає саме це: перегляд клієнтів, перегляд і відповідь на тікети, перегляд сайтів, перезапуск сайту та очищення його кешу. Вона не містить налаштувань білінгу, повернення коштів, редагування тарифних планів і керування флотом. Дії з усунення проблем, які може виконувати агент, обмежені цією роллю, а не добрими намірами.
Дозвіл customer.impersonate не входить до ролі Manager — його має лише Super Admin. Коли сеанс виконується від вашого імені, на панелі керування відображається постійний банер імітації, тож завжди чітко зрозуміло, хто діє.
Кожна привілейована та адміністративна дія записується до журналу аудиту доступного лише для додавання, де фіксуються суб'єкт, дія, ціль, доповні метадані, IP-адреса та мітка часу — у продакшн-середовищі вони розбиті за часом. Власники та учасники з правами лише на читання можуть самостійно переглядати журнал своєї організації.
Чутливі та деструктивні дії співробітників можуть вимагати підвищеної автентифікації або схвалення двома особами перед їх виконанням, а нові відділи та ролі налаштовуються через конфігурацію, а не зміни в коді.
Скрипти, конвеєри CI, CLI, провайдер Terraform та AI-агенти автентифікуються за допомогою тієї самої моделі дозволів, що й люди — без спільних людських облікових даних і без довгострокових секретів, вставлених у збірку.
Ключі належать організації та мають детальні області дії, прив'язані до тих самих дозволів RBAC: лише читання, білінг, надання ресурсів. Надайте конвеєру вузьку область дії, яка йому потрібна, замість усього облікового запису учасника.
Ключі тестового режиму та режиму реального часу відрізняються, тому інтеграція, що розробляється, не зможе випадково чи через скопійовану змінну середовища отримати доступ до даних у прод-середовищі.
Ми зберігаємо SHA-256 хеш секрету та префікс для пошуку — ніколи сам ключ. Ключ відображається лише один раз під час створення. Кожен ключ відстежує час останнього використання, і його можна відкликати окремо, не порушуючи роботу інших елементів.
Наш MCP-сервер дозволяє будь-якому агенту з підтримкою MCP керувати вашим хостингом природною мовою, з автентифікацією через OAuth 2.1 та обмеженням доступу за вашою організацією та роллю RBAC, із токенами з можливістю відкликання для кожного інструменту, підтвердженням деструктивних дій, лімітами витрат та повним веденням аудиторського журналу.
Доступ до облікового запису та доступ до сервера — це різні проблеми. Облікові дані на рівні сайту керуються в панелі керування, надаються за принципом найменших привілеїв та ізолюються так, що оболонкою (shell) одного співавтора є оболонка лише одного сайту.
Один оператор керує єдиною організацією та одним обліковим записом власника, а також додає роль розробника, коли для проєкту залучають підрядника. Коли проєкт завершується, членство видаляється, і вхід цього користувача одразу припиняє працювати — не залишається жодних спільних облікових даних, які потрібно було б оновлювати.
Агентство використовує дерево організацій. Кожен клієнт отримує власну дочірню організацію, яка містить сайти цього клієнта, а власні співробітники клієнта отримують там членство — лише для читання для зацікавленої особи, якій потрібна видимість, або власника для клієнта, який хоче самостійно керувати послугами. Ваші співробітники мають членство вище за деревом і бачать портфоліо; клієнт бачить лише власну гілку, і безпека на рівні рядків гарантує це на практиці, а не на словах.
Реселлер працює за тим самим принципом, але на один рівень вище: організація-реселлер містить клієнтські організації, кожна з яких має власних учасників, власне білдингове представлення та сайти. Той самий примітив забезпечує роботу суб-акаунтів, команд агентств та ієрархій реселерів — для жодного з них немає окремого, слабшого механізму.
Усе доступне під час 14-денного пробного періоду без використання карток. Зареєструйтеся без введення платіжних реквізитів, запросіть колегу, перевірте, до чого має чи не має доступ кожна роль, і перегляньте власний журнал аудиту.
Сьогодні членство надає свою роль у межах усієї організації та всього, що підпорядковане їй у дереві, тож способом розділення наборів сайтів є розділення організацій — розмістіть ці сайти у власній дочірній організації та надайте членство там. Це чістка модель для агентств і реселлерів, де кожен клієнт уже прагне власної межі. Визначення області ресурсів для кожного членства окремо, тобто закріплення одного членства за визначеними сайтами в межах однієї організації, є запланованим удосконаленням, а не чинною функцією.
Роль розробника не передбачає видалення чи призупинення сайту — ці повноваження належать лише власнику. Вона надає права на перегляд і створення сайтів, перезапуск служб, очищення кешу, керування ключами API та опрацювання тікетів. Права на розгортання та перенесення в ефір також не входять до складу повноважень розробника, тому просування до продакшену залишається за власником облікового запису. Поєднуйте це зі стейджингом, щоб робота зі збиранням виконувалася поза межами робочого сайту.
Це повністю залежить від ролі співробітника, і кожна роль є чітким набором ключів дозволів. Наприклад, агент підтримки може переглядати ваш обліковий запис і сайти, переглядати ваші тикети та відповідати на них, перезапускати сайт і очищати його кеш — і не може торкатися конфігурації біллінгу, повернення коштів, тарифних планів чи інфраструктури. Вхід як клієнт є окремим дозволом, яким володіє лише суперадмін, і коли це відбувається, в панелі керування відображається постійний банер імітації облікового запису. Кожна привілейована дія записується в журнал аудитів із зазначенням суб'єкта, дії, цілі, IP-адреси та мітки часу, і ви можете самостійно читати журнал вашої організації.
Видаліть членство, і їхній доступ до цієї організації припиниться — у них залишається власний обліковий запис, але немає ролі, а отже, і жодних дозволів у вашому обліковому записі. Ключі API відкликаються індивідуально, тому ключ конвеєра можна деактивувати без порушення роботи інших елементів. Якщо ви використовуєте єдиний вхід SAML, девізіонування у вашому постачальнику ідентифікаційних даних керує входом централізовано. Облікові дані рівня сайту, такі як ключі SSH, відкликаються в панелі керування, а саме видалення реєструється в системі аудит-логування.
Ні — але варто чітко пояснити чому. API-ключі належать організації, а не окремому учаснику, і вони мають власні детальні області дії, прив'язані до того самого каталогу дозволів. Тому замість того, щоб давати ключ людині, ви створюєте ключ для виконання певного завдання з найвужчою областю дії, яка потрібна для цього завдання, і відкликаєте цей ключ, коли завдання завершується. Зберігається лише хеш секрету, і кожен ключ фіксує час його останнього використання, тому невикористані ключі легко знайти та анулювати.
Так. Наш сервер MCP автентифікує агентів за допомогою OAuth 2.1 і обмежує їхні повноваження вашою організацією та вашою роллю RBAC, використовуючи відкличні маркери для кожного окремого інструменту, тож ви надаєте конкретну функцію, а не повний доступ. Деструктивні дії вимагають підтвердження, діють ліміти витрат, і кожна дія потрапляє до того самого журналу аудиту, що й діяльність людей.
Поврівнева безпека Postgres (Row-Level Security) обмежує запити піддеревом організації ініціатора безпосередньо в базі даних, при цьому фільтр на рівні додатків слугує захистом на глибину, а не єдиним рубежем. Запити щодо записів поза межами області повертають статус «не знайдено» замість помилки доступу, тож жодної інформації про те, що саме існує, не розголошується. На сервері ізоляція на рівні сайтів за допомогою CageFS обмежує оболонку та файли кожного тенанта виключно його власним сайтом.
Так. 14-денний пробний період не потребує картки — жодних платіжних реквізитів, жодних зобов'язань — і поширюється на хостинг Footprint-Free Hosting із кількістю сайтів до п'яти. Цього достатньо, щоб запросити колегу, призначити роль і переконатися, що обмеження працюють так, як вам потрібно, перш ніж брати на себе зобов'язання.
Розпочніть 14-денний пробний період без банківської картки, запросіть когось і переконайтеся, як працює модель дозволів: ролі, яким можна давати назви, області дії, які можна скасовувати, і журнал аудиту, де чітко зазначено, хто і що зробив.
Почати безплатно