Безпека облікового запису
Безпека серверів захищає сайти. Безпека облікових записів захищає ключі до них. Кожен вхід у Zinn Digital® працює на базі єдиної стандартизованої системи ідентифікації — ключі доступу та WebAuthn, двоетапна перевірка TOTP, вхід за магічним посиланням, SAML SSO для корпоративних та агентських команд — із детальним налаштуванням ролей, ключами API для кожної організації та журналом аудиту лише для додавання записів.
Більшість хостинг-акаунтів — це пароль у базі даних, прив'язаний до панелі керування. Наш акаунт — це виділена система ідентифікації — Keycloak із підтримкою OIDC та SAML, — яка розташована перед усім: панеллю клієнта, консоллю адміністратора для співробітників, цим публічним сайтом і базою знань, а також Вашими запитами до служби підтримки. Увійдіть один раз, і Ви отримаєте доступ до всіх цих ресурсів.
Оскільки рівень ідентифікації побудовано на відкритих стандартах, а не на власницькій системі входу, його можна замінити так само, як і будь-який інший компонент платформи. Жодна частина вашої моделі доступу не залишається заблокованою всередині продукту постачальника, і автентифікація вашої команди не залежить від того, чи користуємося ми послугами одного постачальника. Це той самий принцип відсутності прив’язки до постачальника, який ми застосовуємо до облікових записів CDN, DNS та платіжних провайдерів.
Вхід локалізовано, і перехід із сайту на екран входу зберігає вибрану вами мову — тож команда, розкидана різними країнами, не змушена проходити вхід виключно англійською.
Чотири методи, усі першокласні, усі налаштовуються індивідуально для кожної особи. Ніхто не змушений використовувати найслабший варіант лише тому, що він єдиний із запропонованих.
Введіть свою електронну адресу, натисніть на посилання — і ви всередині. Жодних паролів, які можна виманити фішингом, використати повторно чи злити під час витоку даних. Це стандартний шлях для нових облікових записів, і для більшості людей це єдине, що їм коли-небудь знадобиться.
Зареєструйте ключ доступу — Touch ID, Face ID, Windows Hello або апаратний ключ, як-от YubiKey, — і входьте зовсім без пароля. Ключі доступу прив'язані до джерела, тому схожа фішингова сторінка входу не зможе їх перехопити. Платформа підтримує автентифікатори ES256 і RS256 та надає перевагу перевірці користувача.
Увійдіть за допомогою Google через стандартне підключення до постачальника ідентифікаційних даних, щоб обліковий запис успадковував усі елементи керування, які вже застосовує ваш Google Workspace. Інші постачальники підключаються так само — тут немає ніяких індивідуальних інтеграцій.
Збережено для користувачів і скриптів, які цього потребують, та підпорядковано чітким правилам: щонайменше дванадцять символів, у жодному разі не ваше ім'я користувача чи адреса електронної пошти, без повторного використання трьох останніх, хешовано за допомогою Argon2. Адреси електронної пошти перевіряються до того, як обліковий запис стане придатним для використання.
Другі фактори є частиною системи ідентифікації, а не додатком, який ви купуєте, чи плагіном, який ви встановлюєте на власному сайті.
Якщо ваша організація вже використовує постачальника посвідчень — Okta, Entra ID, Google Workspace або будь-який інший сервіс із підтримкою SAML — ви просто підключаєте його, і ваші співробітники входять до Zinn Digital® за допомогою наявних корпоративних облікових даних. Вашій команді не потрібно керувати додатковим паролем, а вам — турбуватися про ще один контрольний список дій під час звільнення працівників.
Це найважливіше на рівні агенцій та реселерів, де зміна персоналу становить реальну загрозу безпеці. Коли співробітник звільняється і ви деактивуєте його у своєму каталозі, ви також блокуєте йому доступ до вашого хостингу. Доступ централізовано прив'язаний до статусу зайнятості, тож вам не доведеться відстежувати його в десятку інструментів SaaS.
SAML працює паралельно з усім іншим, а не замінює його: підрядникам усе ще можна надати обліковий запис із чарівним посиланням у межах окресленої ролі, тоді як постійні працівники входять через SSO. Одна організація, одна модель дозволів, двоє вхідних дверей.
Доступ обмежено структурою організації — від реселера до клієнта та сайту — і забезпечено безпосередньо в базі даних за допомогою безпеки на рівні рядків, а не лише в додатку. Міжклієнтський доступ — це не правило, якого ми просимо дотримуватися; це запит, який просто не може повернути рядки. Чотири ролі клієнтів охоплюють реалістичний розподіл обов'язків.
Повний контроль над організацією та її субрахунками: створюйте дочірні організації, запрошуйте та видаляйте учасників, призначайте ролі, керуйте кожним сайтом, здійснюйте розрахунки та виставлення рахунків, керуйте ключами API та переглядайте журнал аудиту.
Рахунки, передплати, способи оплати та каталог тарифів — і нічого зайвого. Ваш фінансист або бухгалтер може оплатити рахунок, не маючи жодної змоги змінити, призупинити або видалити активний сайт.
Доступ до сайтів та API без керування платежами: переглядайте та розгортайте сайти, перезапускайте служби, очищайте кеш, керуйте ключами API та робочими тікетами. Навмисно немає доступу до способів оплати, виставлення рахунків або зміни тарифного плану.
Лише перегляд у межах усієї організації — сайти, виставлення рахунків, плани, тікети, статус перекладу та журнал аудиту. Відповідна роль для аудитора, клієнта, який бажає мати доступ до інформації, або нового співробітника в його перший тиждень.
Панель керування — це один зі способів доступу. API, CLI, провайдер Terraform і сервер MCP — інші способи, і вони підпорядковуються тій самій моделі доступу, оскільки ключ без обмеження області дії є обходом кожної ролі, яку ви щойно налаштували.
Ключ API видається організації, а не окремій особі, і має власні області дії. Ставтеся до нього як до спільного облікового запису: назвіть його відповідно до призначення, надайте найвужчі можливі області дії та замініть його, коли особа, яка його створила, перейде на іншу посаду чи звільниться.
Необроблений ключ відображається вам лише один раз, під час створення. Ми зберігаємо лише хеш SHA-256 і короткий префікс для пошуку. Ми не зможемо показати вам ключ знову, а компрометація бази даних не передасть зловмиснику дійсні облікові дані.
Кожен ключ має деталізовані області дії, пов'язані з тим самим каталогом дозволів, який використовують ролі, фіксує час останнього використання та може бути негайно відкликаний за найменшої підозри. Окремі ключі пісочниці тестують API без реального виставлення рахунків чи надання ресурсів.
Сервер MCP дозволяє будь-якому агенту з підтримкою MCP керувати вашим хостингом — і він проходить автентифікацію через OAuth 2.1, обмежену масштабом вашої організації та її дозволами RBAC, з можливістю відкликання токенів для кожного інструмента, підтвердженням руйнівних дій, обмеженнями витрат і повним журналюванням аудиту. Підключення штучного інтелекту-помічника не означає передачу йому ключів від усього.
Кожна привілейована дія створює запис, призначений лише для додавання: хто її виконав, що саме зробив, над чим виконав дію, підтверджувальні докази та вихідну IP-адресу з позначкою часу. Це не просто зручність для налагодження; це доказова база.
Ні — і ми вважаємо за краще, щоб ви цього не робили. Вхід за магічним посиланням на електронну пошту є типовим, і ви можете зареєструвати ключ доступу (Touch ID, Face ID, Windows Hello або апаратний ключ) і входити без створення пароля. Вхід за електронною поштою та паролем залишається доступним як резервний варіант із мінімальною довжиною у дванадцять символів, забороною повторного використання трьох останніх паролів і хешуванням Argon2.
Двофакторна автентифікація TOTP вбудована в рівень ідентифікації та може бути впроваджена як обов'язкова політика для всієї організації, а не залишена на розсуд кожного учасника. Ключі доступу (passkeys) є надійнішим варіантом, якщо пристрої вашої команди підтримують їх, оскільки вони усувають пароль, який зловмисник міг би спробувати викрасти за допомогою фішингу.
Так. Роль Менеджера з виставлення рахунків надає доступ лише до рахунків-фактур, підписок, способів оплати та каталогу планів, і більше ні до чого — без можливості переглядати, розгортати, перезапускати, призупиняти або видаляти сайт. Зворотне також вірно: роль Розробника керує сайтами та доступом до API без будь-якого контролю над рахунками. Ролі призначаються для кожної організації окремо, тому роль в одній організації не надає доступу до окремої, не пов'язаної з нею організації — хоча роль у батьківській організації застосовується до вкладених у неї організацій.
Відкличте його на панелі керування, і він негайно припинить працювати. Масштаб потенційних збитків обмежений тим, які дії цей ключ міг виконувати із самого початку, саме тому ключі мають деталізовані області доступу та фіксують мітку часу останнього використання — вузькі області доступу та видимий слід використання перетворюють витік на локалізований інцидент, а не на повну скомпрометованість облікового запису. Зверніть увагу, що ключі видаються організації, а не окремій особі, тому ставтеся до них як до спільних облікових даних і змінюйте їх у разі звільнення співробітників. На нашій стороні зберігається лише хеш ключа, тому витік із нашої бази даних не призведе до створення дійсних облікових даних.
Так. Кожна привілейована дія записується в журнал аудиту, призначений лише для додавання записів, із зазначенням виконавця, дії, цілі, підтверджувальних доказів, вихідної IP-адреси та позначки часу. Ролі власника та лише для читання можуть переглядати його безпосередньо. Дії персоналу з вашим обліковим записом фіксуються в тому самому журналі, а чутливі або деструктивні дії персоналу можуть вимагати попередньої додаткової автентифікації або схвалення двома особами.
Так — SAML SSO підтримується для облікових записів підприємств та агентств, тому ваші співробітники проходять автентифікацію за допомогою наявних корпоративних облікових даних, а вилучення з вашого каталогу скасовує їхній доступ і тут. Ви можете комбінувати підходи: SSO для постійного штату, облікові записи з обмеженим доступом через magic-link для підрядників — і все це в межах єдиної моделі дозволів.
Ні — паролі свідомо не переносяться. Ваш обліковий запис імпортується без пароля, і під час першого входу ви або використовуєте magic-link, або встановлюєте новий пароль відповідно до поточної політики. Перенесення старих хешів паролів призвело б до перенесення старих уразливостей у нову систему, тому ми цього не робимо.
Пробний період Footprint-Free триває 14 днів, не потребує картки та охоплює до п'яти сайтів. Ви отримуєте повний рівень ідентифікації протягом пробного періоду — ключі доступу, двофакторна автентифікація, ролі, ключі API та журнал аудиту не заблоковані за платним тарифом.
Зареєструйте ключ доступу, запросіть свою команду на відповідні ролі та створіть ключ API з обмеженою областю дії — усе це під час 14-денного пробного періоду без необхідності вказувати дані картки.
Почати безкоштовно