Сигурност на акаунта
Защитата на сървъра защитава сайтовете. Защитата на акаунта защитава ключовете за тях. Входът в Zinn Digital® работи чрез единна базирана на стандарти система за идентичност — passkeys и WebAuthn, TOTP двуфакторна автентификация, вход чрез magic link, SAML SSO за корпоративни и агенционни екипи — с детайлно управлявани роли, API ключове за всяка организация и регистър за одит без възможност за изтриване.
Повечето хостинг акаунти представляват парола в база данни, скачена към контролен панел. Нашият е специализирана система за самоличност — Keycloak, поддържаща OIDC и SAML — която стои пред всичко: клиентското табло за управление, административната конзола за персонала, този публичен сайт и база знание, както и вашите заявки за поддръжка. Влезте веднъж и ще вте влезли във всички тях.
Тъй като е изграден върху отворени стандарти, а не върху собственически метод за вход, слой за самоличност е заменяем по същия начин, както всеки друг компонент на платформата. Никаква част от вашия модел за достъп не е заключена в продукт на даден доставчик и автентикацията на никой от членовете на вашия екип не зависи от това дали ще запазим конкретен доставчик. Това е същият принцип на липса на обвързване с един доставчик, който прилагаме към CDN акаунтите, DNS и доставчиците на плащания.
Влизането е локализирано, а преходът от сайта към екрана за вход запазва вашия език — така че екип, разпръснат в различни държави, не е принуден да използва само английски при влизане.
Четири метода, всичките от първа класа, всичките конфигурирани за всеки потребител. Никой не е принуден да избира най-слабата опция само защото тя е единствената на разположение.
Въведете имейла си, кликнете върху връзката и сте вътре. Няма парола за фишинг, повторно използване или изтичане при пробив. Това е стандартният път за новите акаунти и за повечето хора той е единственият, който някога ще им трябва.
Регистрирайте passkey — 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 разрешения, с токени за еднократна или отменяема употреба за всеки инструмент, потвърждение при деструктивни действия, лимити на разходите и пълен одит лог. Свързването на AI асистент не означава да му дадете пълни права за всичко.
Всяко привилегировано действие записва хронологичен запис само с възможност за добавяне — кой го е направил, какво е направил, върху какво го е направил, съпътстващите доказателства и изходния IP адрес, заедно с времеви печат. Това не е удобство за отстраняване на грешки; това е следата от доказателства.
Не — и бихме предпочели да не го правите. Входът с имейл и магически линк е стандартният метод, като можете да регистрирате ключ за достъп (Touch ID, Face ID, Windows Hello или хардуерен ключ) и да влизате, без никога да задавате парола. Имейлът и паролата остават достъпни като алтернативен вариант с изискване за минимум дванадесет символа, забрана за повторно използване на последните три и хеширане с Argon2.
Двуфакторното удостоверяване с TOTP е вградено в слоя за самоличност и може да бъде наложено чрез политика в цялата организация, вместо да се оставя на избора на всеки член. Ключовете за достъп (passkeys) са по-силната опция, когато устройствата на вашия екип ги поддържат, тъй като те елиминират паролата, която нападателят би се опитал да открадне чрез фишинг.
Да. Ролята на мениджър по фактурирането дава достъп до фактури, абонаменти, платежни методи и каталога с планове, и нищо друго — без възможност за преглед, създаване, рестартиране, спиране или изтриване на сайт. Обратното също важи: ролята на програмист управлява сайтове и API достъп без какъвто и да е контрол върху фактурирането. Ролите се задават за всяка организация поотделно, така че роля в една организация не дава достъп в отделна, несвързана организация — въпреки че роля в родителска организация се прилага за организациите, вложени под нея.
Анулирайте го от таблото за управление и то спира да работи незабавно. Прозорецът на щетите е ограничен от това какво е могъл да направи този ключ на първо място, поради което ключовете носят гранулирани обхвати и записват времеви печат на последна употреба — тесните обхвати и видимата следа на използване са това, което превръща изтичането в овладян инцидент, а не в пълно компрометиране на акаунта. Имайте предвид, че ключовете се издават на организацията, а не на отделно лице, така че се отнасяйте към тях като към споделени идентификационни данни и ги сменяйте, когато хората напускат или сменят ролята си. На наша страна се съхранява само хеш на ключа, така че изтичането от нашата база данни не води до създаване на работещи идентификационни данни.
Да. Всяко привилегирано действие се записва в одитен журнал само за добавяне, съдържащ извършителя, действието, целта, придружаващите доказателства, изходния IP адрес и времеви печат. Ролите на собственика и тези само за четене могат да го четат директно. Действията на персонала във вашия акаунт се регистрират в същата хронология, а чувствителните или деструктивни действия на персонала могат да изискват предварително допълнително удостоверяване или одобрение от двама души.
Да — SAML SSO се поддържа за корпоративни и агенционни профили, така че вашите служители да се автентикират с наличните корпоративни идентификационни данни, а прекратяването на достъпа в директорията ви премахва достъпа им и тук. Можете да комбинирате подхода: SSO за постоянния персонал и профили с ограничена валидност с магически линк за контрактори — всичко това в рамките на един и същ модел на права.
Не — паролите умишлено не се мигрират. Вашият акаунт се импортира без такава и при първото влизане или използвате magic-link, или задавате нова парола съгласно актуалната политика. Пренасянето на стари хешове на пароли би пренесло стари уязвимости в новата система, затова не го правим.
Пробният период на Footprint-Free е 14 дни, без нужда от карта и покрива до пет сайта. Получавате пълния слой за идентичност по време на пробния период — ключове за достъп, двуфакторна автентификация, роли, API ключове и одитния журнал не са заключени зад платен план.
Регистрирайте ключ за достъп, поканете екипа си в правилните роли и издайте ограничен API ключ — всичко това в рамките на 14-дневен пробен период без изискване на кредитна карта.
Започни безплатно