Seguridad ng account
Pinoprotektahan ng seguridad ng server ang mga site. Pinoprotektahan ng seguridad ng account ang mga susi sa mga ito. Ang bawat pag-login sa Zinn Digital® ay tumatakbo sa isang identity system na nakabatay sa mga pamantayan — mga passkey at WebAuthn, TOTP two-factor, pag-sign in gamit ang magic-link, SAML SSO para sa mga enterprise at agency team — na may mga detalyadong tungkulin, mga API key para sa bawat organisasyon, at isang append-only na audit log sa likod nito.
Karamihan sa mga hosting account ay isang password sa isang database, na nakakabit sa isang control panel. Ang sa amin ay isang dedikadong identity system — Keycloak, na gumagamit ng OIDC at SAML — na nasa harap ng lahat: ang customer dashboard, ang staff admin console, ang pampublikong site na ito at knowledge base, at ang inyong mga support ticket. Mag-sign in nang isang beses at naka-sign in na kayo sa lahat ng mga ito.
Dahil binuo ito sa mga bukas na pamantayan sa halip na isang pagmamay-ari na pag-log in, ang identity layer ay maaaring palitan sa parehong paraan tulad ng bawat iba pang bahagi ng platform. Walang bahagi ng iyong access model ang nakakulong sa loob ng produkto ng isang vendor, at walang pagpapatotoo ng iyong koponan ang nakadepende sa pagpapanatili namin ng iisang supplier. Iyan ang parehong prinsipyo ng walang lock-in na inilalapat namin sa mga CDN account, DNS, at mga tagapagbigay ng pagbabayad.
Naka-localize ang pag-sign in, at ang paglipat mula sa site patungo sa login screen ay nagdadala ng iyong wika — kaya ang isang team na nasa iba't ibang bansa ay hindi napipilitang dumaan sa login na para lang sa English.
Apat na pamamaraan, pawang primera-klase, at lahat ay maaaring i-configure para sa bawat tao. Walang sinumang pinipilit sa pinakamahinang opsyon dahil lamang ito ang tanging iniaalok.
Ilagay ang iyong email, i-click ang link, at nakapasok ka na. Walang password na mapi-phish, muling magagamit, o tatagas sa isang breach dump. Ito ang default na paraan para sa mga bagong account, at para sa karamihan ng mga tao, ito lang ang tanging kakailanganin nila.
Magrehistro ng passkey — Touch ID, Face ID, Windows Hello, o hardware key tulad ng YubiKey — at mag-sign in nang walang password. Nakatali ang mga passkey sa pinagmulan, kaya hindi ito mananakaw ng isang huwad na login page. Tumatanggap ang platform ng mga ES256 at RS256 na authenticator at mas pinipili ang pag-verify ng user.
Mag-sign in gamit ang Google sa pamamagitan ng karaniwang koneksyon ng identity-provider, upang mamana ng isang account ang anumang kontrol na ipinapatupad na ng iyong Google Workspace. Kumokonekta ang iba pang provider sa parehong paraan — walang anuman dito na pasadyang integrasyon.
Pinapanatili para sa mga tao at script na nangangailangan nito, at sumusunod sa isang totoong patakaran: hindi bababa sa labindalawang character, hindi kailanman ang iyong username o email address, walang muling paggamit sa iyong huling tatlo, na-hash gamit ang Argon2. Bine-verify ang mga email address bago maging magagamit ang isang account.
Ang mga pangalawang salik ay bahagi ng sistema ng pagkakakilanlan, hindi isang add-on na binibili mo o isang plugin na ini-install mo sa iyong sariling site.
Kung ang inyong organisasyon ay gumagamit na ng identity provider — Okta, Entra ID, Google Workspace, o anupaman na sumusuporta sa SAML — ikonekta ninyo ito at ang inyong mga empleyado ay magsa-sign in sa Zinn Digital® gamit ang kanilang kasalukuyang corporate credentials. Walang pangalawang password na kailangang pamahalaan ang inyong team, at walang pangalawang offboarding checklist na malilimutan.
Pinakamahalaga iyan sa antas ng ahensya at reseller, kung saan ang pagpapalit ng mga kawani ay isang tunay na kaganapang pangseguridad. Kapag may umalis at na-disable mo sila sa iyong directory, na-disable mo na rin ang kanilang ruta papunta sa iyong hosting. Ang access ay sumusunod sa katayuan sa trabaho, sa sentralisadong paraan, sa halip na habulin ito sa napakaraming tool ng SaaS.
Gumagana ang SAML kasabay ng iba pang mga bagay sa halip na palitan ang mga ito: maaari pa ring bigyan ang mga kontratista ng isang magic-link account sa loob ng isang partikular na tungkulin, habang ang mga permanenteng kawani ay pumapasok sa pamamagitan ng SSO. Isang organisasyon, isang modelo ng pahintulot, dalawang pintuan sa harap.
Ang access ay nakasaklaw sa puno ng organisasyon — reseller papunta sa kliyente papunta sa site — at ipinapatupad sa mismong database sa pamamagitan ng row-level security, hindi lang sa aplikasyon. Ang cross-tenant access ay hindi isang patakaran na hinihiling naming igalang ng mga tao; ito ay isang query na hindi makakapagbalik ng mga row. Sinasaklaw ng apat na tungkulin ng customer ang makatotohanang paghahati ng mga tungkulin.
Ganap na kontrol sa organisasyon at sa mga sub-account nito: lumikha ng mga child na organisasyon, mag-imbita at mag-alis ng mga miyembro, magtalaga ng mga tungkulin, pamahalaan ang bawat site, magsagawa ng pagsingil at pag-invoice, pamahalaan ang mga API key, at basahin ang audit log.
Mga invoice, subscription, paraan ng pagbabayad, at ang catalog ng plano — at wala nang iba pa. Maaaring bayaran ng iyong finance person o accountant ang isang invoice nang hindi kailanman nagkakaroon ng kakayahang baguhin, suspindihin, o i-delete ang isang live na site.
Access sa mga site at API nang walang kontrol sa pagsingil: tingnan at maglaan ng mga site, i-restart ang mga serbisyo, i-purge ang mga cache, pamahalaan ang mga API key at ticket sa trabaho. Sadyang walang access sa mga paraan ng pagbabayad, pag-invoice, o mga pagbabago sa plano.
Tingnan lamang sa buong organisasyon — mga site, pagsingil, mga plano, mga ticket, katayuan ng pagsasalin, at ang audit log. Ang tamang tungkulin para sa isang auditor, isang kliyenteng nais ng visibility, o isang bagong pasok sa kanilang unang linggo.
Ang dashboard ay isang paraan ng pag-access. Ang API, ang CLI, ang Terraform provider, at ang MCP server ay iba pa — at sumusunod ang mga ito sa parehong modelo ng pag-access, dahil ang isang susi na walang saklaw ay lumalampas sa bawat tungkuling kaka-configure mo lang.
Ang isang API key ay ibinibigay sa isang organisasyon, hindi sa isang indibidwal, at nagdadala ng sarili nitong mga scope. Tratuhin ito bilang ibinabahaging credential material: pangalanan ito ayon sa layunin nito, bigyan ito ng pinakamakikitid na saklaw na gagana, at i-rotate ito kapag umalis na ang taong lumikha nito.
Ang raw key ay ipinapakita sa iyo nang isang beses lamang, sa oras ng paggawa. Ang aming itinatago ay isang SHA-256 hash at isang maikling prefix para sa paghahanap. Hindi na namin maipapakita sa iyo muli ang isang key, at ang pagkakakompromiso ng database ay hindi nagbibigay sa isang sumasalakay ng gumaganang mga kredensyal.
Ang bawat key ay nagdadala ng mga detalyadong saklaw na nakatali sa parehong katalogo ng pahintulot na ginagamit ng mga tungkulin, nagtatala kung kailan ito huling ginamit, at maaaring ganap na bawiin sa sandaling magmukha itong mali. Sinusubukan ng magkakahiwalay na sandbox key ang API nang walang totoong pagsingil o paglalaan ng serbisyo sa likod ng mga ito.
Pinapayagan ng MCP server ang anumang MCP-capable na agent na pamahalaan ang inyong hosting — at nagpapatunay ito sa pamamagitan ng OAuth 2.1, na sakop ang inyong organisasyon at ang mga pahintulot ng RBAC nito, na may mga bawat-kagamitang bawiing token, kumpirmasyon sa mga mapanirang pagkilos, mga limitasyon sa paggastos, at kumpletong pag-log ng audit. Ang pagkonekta ng isang AI assistant ay hindi nangangahulugang pagbibigay rito ng mga susi sa lahat ng bagay.
Ang bawat may pribilehiyong pagkilos ay nagtatala ng talaan na pwedeng dagdagan lamang — sino ang gumawa nito, ano ang ginawa nila, saan nila ito ginawa, ang sumusuportang ebidensya, at ang pinagmulang IP address, na may timestamp. Hindi ito isang kaginhawahan sa pag-debug; ito ang ebidensyang bakas.
Hindi — at mas gugustuhin naming huwag ninyo itong gawin. Ang pag-sign in gamit ang magic-link sa email ang default, at maaari kayong magrehistro ng passkey (Touch ID, Face ID, Windows Hello o isang hardware key) at mag-sign in nang walang anumang password na naitakda. Nananatiling available ang email at password bilang fallback, na may minimum na labindalawang character, bawal ang muling paggamit ng inyong huling tatlo, at may Argon2 hashing.
Ang TOTP na two-factor authentication ay nakapaloob sa identity layer at maaaring ipatupad sa pamamagitan ng patakaran sa buong organisasyon sa halip na ipaubaya sa bawat miyembro ang pagpili. Ang mga passkey ang mas matatag na opsyon kung sinusuportahan ang mga ito ng mga device ng inyong koponan, dahil inaalis ng mga ito ang password na maaaring targetin ng phishing ng isang umaatake.
Oo. Ang tungkulin ng Tagapamahala ng Pagsingil ay nagbibigay ng access sa mga invoice, subscription, paraan ng pagbabayad, at katalogo ng plano, at wala nang iba pa — walang kakayahang tumingin, mag-provision, mag-restart, magsuspinde, o magtanggal ng isang site. Nalalapat din ang kabaligtaran: pinamamahalaan ng tungkulin ng Developer ang mga site at access sa API nang walang anumang kontrol sa pagsingil. Ang mga tungkulin ay itinatalaga bawat organisasyon, kaya ang isang tungkulin sa isang organisasyon ay hindi nagbibigay ng access sa isang hiwalay at walang kaugnayang organisasyon — bagaman ang isang tungkulin sa isang pangunahing organisasyon ay nalalapat sa mga organisasyong nakapaloob sa ilalim nito.
Bawiin ito mula sa dashboard at hihinto agad ito sa paggana. Ang saklaw ng pinsala ay limitado sa kung ano ang unang-unang kayang gawin ng susi na iyon, kung kaya't ang mga susi ay nagtataglay ng mga partikular na saklaw at nagtatala ng timestamp ng huling paggamit — ang makikitid na saklaw at ang nakikitang tala ng paggamit ang nagpapabago sa isang leak upang maging isang kontroladong insidente sa halip na isang buong pagkakompromiso ng account. Tandaan na ang mga susi ay ibinibigay sa organisasyon sa halip na sa isang indibidwal, kaya tratuhin ang mga ito bilang mga ibinabahaging kredensyal at palitan ang mga ito kapag may mga tauhang umaalis. Hash lamang ng susi ang nakaimbak sa aming panig, kaya ang isang leak mula sa aming database ay hindi magbubunga ng gumaganang kredensyal.
Oo. Ang bawat pribilehiyong aksyon ay isinusulat sa isang append-only na audit log kasama ang aktor, ang aksyon, ang target, sumusuportang ebidensya, ang pinagmulang IP, at isang timestamp. Direktang mababasa ito ng mga tungkuling May-ari at read-only. Ang mga aksyon ng staff sa iyong account ay itinatala sa parehong trail, at ang sensitibo o mapanirang aksyon ng staff ay maaaring mangailangan muna ng step-up na pagpapatotoo o pag-apruba ng dalawang tao.
Oo — suportado ang SAML SSO para sa mga enterprise at agency account, kaya nagpapatunay ang inyong mga tauhan gamit ang mga kasalukuyang kredensyal ng korporasyon at ang pag-offboard sa inyong direktoryo ay nag-aalis din ng kanilang access dito. Maaari ninyong pagsamahin ang mga paraan: SSO para sa permanenteng kawani, mga scoped magic-link account para sa mga kontratista, lahat sa loob ng parehong modelo ng pahintulot.
Hindi — sadyang hindi inililipat ang mga password. Ini-import ang iyong account nang walang password, at sa unang pag-sign in ay gagamit ka ng magic-link o magtatakda ng bagong password alinsunod sa kasalukuyang patakaran. Ang paglilipat ng mga lumang password hash ay magdadala ng mga lumang kahinaan sa bagong sistema, kaya hindi namin ito ginagawa.
Ang Footprint-Free trial ay 14 na araw, walang kailangang card, at sumasaklaw ng hanggang limang site. Makukuha ninyo ang buong identity layer sa panahon ng trial — ang mga passkey, two-factor, mga tungkulin, mga API key, at ang audit log ay hindi nakakandado sa likod ng isang bayad na plano.
Magrehistro ng passkey, imbitahan ang iyong team sa tamang mga tungkulin, at mag-isyu ng may saklaw na API key — lahat sa isang 14 na araw na trial na walang kinakailangang mga detalye ng card.
Magsimula nang libre