Безпека облікового запису

Ваш обліковий запис надійно захищено на рівні ідентифікації

Безпека серверів захищає сайти. Безпека облікових записів захищає ключі до них. Кожен вхід у Zinn Digital® працює на єдиній стандартизованій системі ідентифікації — ключах доступу та WebAuthn, TOTP двофакторній автентифікації, вході за магічним посиланням, SAML SSO для корпоративних команд та агентств — із деталізованим розподілом ролей, ключами API для кожної організації та журналом аудитів, до якого можна лише додавати записи.

  • 650 000+сайти, розміщені по всьому світу
  • Ключі доступуВхід через WebAuthn, вбудований
  • SAML SSOдля корпоративних і партнерських акаунтів
  • Збережено в аудитікожна привілейована дія

Один обліковий запис для всіх платформ

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

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

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

Увійдіть у зручний для вашої команди спосіб

Чотири методи, усі першокласні, кожен налаштовується індивідуально. Нікого не примушують користуватися найслабшим варіантом лише тому, що він є єдиним доступним.

Електронний лист із магічним посиланням (за замовчуванням)

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

Паролі доступу / WebAuthn

Зареєструйте ключ доступу — Touch ID, Face ID, Windows Hello або апаратний ключ на кшталт YubiKey — і входите без жодного пароля. Ключі доступу прив'язані до джерела, тому підроблена сторінка входу не зможе його перехопити. Платформа приймає автентифікатори ES256 та RS256 і віддає перевагу верифікації користувача.

Соціальний вхід

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

Електронна пошта та пароль (резервний варіант)

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

Двофакторний захист і захист від брутфорсу

Двофакторна автентифікація є частиною системи ідентифікації, а не додатком, який ви купуєте, чи плагіном, який ви встановлюєте на власному сайті.

  • TOTP двофакторна автентифікація через будь-який стандартний додаток для автентифікації — шість цифр із періодом у тридцять секунд, за тією ж схемою, яку використовують Google Authenticator, 1Password та Authy. Її можна запровадити за допомогою політики для всієї організації, а не покладатися на добру волю кожного користувача.
  • Ключі доступу можуть повністю замінити пароль, а не доповнювати його, що усуває облікові дані, які намагається викрасти зловмисник.
  • Захист від брутфорсу активовано на рівні риму: багаторазові невдалі спроби ініціюють час очікування, що поступово збільшується до п'ятнадцяти хвилин, тож атака з підбору облікових даних зупиняється, замість того щоб перебирати словник. Блокування навмисно є тимчасовим — зловмисник не зможе остаточно заблокувати реальному клієнту доступ до його власного облікового запису.
  • Адреси електронної пошти для реєстрації перевіряються за допомогою адаптера на базі ZeroBounce: недоступні та недійсні адреси відхиляються, а одноразові, ролєві та позначені як зловмисні адреси отримують відповідні позначки. Фальшиві або недоступні електронні листи не створюють обліковий запис, що також сприяє перевірці тріал-версій на предмет зловживань і шахрайства.
  • Сеанси тримають під суворим контролем: маркери доступу діють недовго, неактивні сеанси завершуються, а кожен сеанс має жорстко обмежений максимальний час життя, тому забутий у браузері на спільному комп'ютері обліковий запис не залишиться відкритим завтра.

SAML SSO для корпоративних та агентських команд

Якщо ваша організація вже використовує постачальника ідентифікаційних даних — Okta, Entra ID, Google Workspace або будь-який інший сервіс, що підтримує SAML, — ви підключаєте його, і ваша команда входить до Zinn Digital® за допомогою наявних корпоративних облікових даних. Вашій команді не доведеться керувати другим паролем або забувати про другий контрольний список для звільнення співробітників.

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

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

Ролі, які надають лише те, що потрібно для роботи

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

Власник

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

Менеджер біллингу

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

Розробник

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

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

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

Ключі API, токени та підключення ШІ

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

Організації

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

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

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

Обмежені, відкличні, спостережувані

Кожен ключ має деталізовані області дії, прив'язані до того самого каталогу дозволів, який використовують ролі, фіксує час останнього використання та може бути повністю скасований у будь-який момент, якщо щось здасться підозрілим. Окремі тестові ключі (sandbox) взаємодіють з API без реального біллінгу чи провізіонування за ними.

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

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

Журнал аутентифікації та доступ до нього

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

  • Ролі власника та лише для читання можуть переглядати журнал аудиту безпосередньо, тому для забезпечення підзвітності у вашій організації не потрібно створювати запит до нашої служби підтримки.
  • Доступ персоналу до вашого облікового запису регулюється тим самим механізмом: наші співробітники розподілені по відділах із дозволами для кожного окремого модуля та дії, тому агенти підтримки бачать тікети та базові інструменти відновлення, а не ваші налаштування біллінгу чи ваш парк серверів.
  • Чутливі та деструктивні дії співробітників можуть вимагати додаткової автентифікації або схвалення двома особами перед їх виконанням.
  • Білий список IP-адрес доступний для кожної організації для команд, які хочуть обмежити доступ відомими мережами на додачу до всього іншого.
  • Той самий журнал аудиту, модель мінімальних привілеїв та ізоляція для кожного орендаря є основою нашого плану підготовки до сертифікації SOC 2 та ISO 27001 — докази збираються з першого дня, а не створюються заднім числом.

Поширені запитання

Чи обов'язково мені взагалі використовувати пароль?

Ні — і ми б вважали за краще, щоб ви цього не робили. Вхід за допомогою магічного посилання на електронну пошту є стандартним, і ви можете зареєструвати ключ достуpu (Touch ID, Face ID, Windows Hello або апаратний ключ) і входити без будь-коли встановленого пароля. Електронна пошта та пароль залишаються доступними як запасний варіант з мінімальною довжиною дванадцять символів, забороною повторного використання трьох останніх і хешуванням Argon2.

Чи можу я зробити двофакторну автентифікацію обов'язковою для своєї команди?

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

Хтось із моєї команди займається лише рахунками. Чи можу я заборонити їм торкатися сайтів?

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

Що станеться, якщо один із наших ключів API витече?

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

Чи можу я бачити, хто що робив у моєму обліковому записі?

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

Ми вже використовуємо Okta / Entra ID. Чи може наша команда входити за їх допомогою?

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

Я переходжу з вашої платформи V1. Чи перенесеться мій старий пароль?

Ні — паролі навмисно не мігрують. Ваш обліковий запис імпортується без нього, а під час першого входу ви використовуєте магічне посилання (magic-link) або встановлюєте новий пароль відповідно до поточної політики. Перенесення старих хешів паролів призвело б до перенесення старих вразливостей у нову систему, тому ми цього не робимо.

Як спробувати це без надання даних картки?

Пробна версія Footprint-Free триває 14 днів, не вимагає картки та охоплює до п'яти сайтів. Протягом пробного періоду ви отримуєте повний рівень ідентифікації — ключі доступу, двофакторну автентифікацію, ролі, ключі API та журнал аутентифікації не обмежені платним тарифом.

Налаштуйте свій акаунт правильно за перші п'ять хвилин

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

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