Seguridad sa account
Ang seguridad ng server ay nagpoprotekta sa mga site. Ang seguridad ng account ang nagpoprotekta sa mga susi ng mga ito. Ang bawat pag-login sa Zinn Digital® ay tumatakbo sa isang sistema ng pagkakakilanlan na nakabatay sa mga pamantayan — mga passkey at WebAuthn, TOTP two-factor, pag-sign-in sa pamamagitan ng magic-link, SAML SSO para sa mga koponan ng enterprise at agency — kasama ang mga granular na papel, mga API key sa bawat organisasyon, at isang append-only na audit log sa likod nito.
Karamihan sa mga hosting account ay password lamang sa loob ng database, na nakakabit sa isang control panel. Ang sa amin ay isang dedikadong sistema ng pagkakakilanlan — ang Keycloak, na gumagamit ng OIDC at SAML — na nakalagay sa unahan ng lahat: ang customer dashboard, ang staff admin console, ang pampublikong site at knowledge base na ito, at ang iyong mga support ticket. Mag-sign in nang isang beses at naka-sign in ka na sa lahat ng ito.
Dahil ito ay binuo sa mga bukas na pamantayan sa halip na isang pagmamay-ari na login, ang layer ng pagkakakilanlan ay maaaring palitan sa parehong paraan ng bawat iba pang bahagi ng platform. Walang bahagi ng iyong access model ang nakakulong sa loob ng produkto ng isang vendor, at wala sa authentication ng iyong koponan ang nakasalalay sa pagpapanatili namin sa isang supplier. Iyan din ang prinsipyong walang lock-in na inilalapat namin sa mga account sa CDN, DNS, at mga tagapagbigay ng pagbabayad.
Ang pag-sign-in ay naka-localize, at ang paglipat mula sa site patungo sa login screen ay nagdadala ng iyong wika—kaya ang isang team na nakakalat sa iba't ibang bansa ay hindi napipilitang dumaan sa isang login na Ingles lamang.
Apat na pamamaraan, lahat ay de-kalibre, lahat ay nakakapag-configure bawat tao. Walang sinuman ang napipilitang gumamit sa pinakamahihirang na opsyon dahil ito lang ang iniaalok.
Ilagay ang iyong email, i-click ang link, at pasok ka na. Walang password na maaaring i-phish, uliting gamitin, o tumagas sa isang data breach dump. Ito ang default na ruta para sa mga bagong account, at para sa karamihan ng mga tao, ito na ang tanging kailangan nila kailanman.
Magrehistro ng passkey — Touch ID, Face ID, Windows Hello, o hardware key tulad ng YubiKey — at mag-sign in nang walang anumang password. Nakatali ang mga passkey sa pinagmulan, kaya hindi ito mananakaw ng kamukhang pahina sa pag-sign in. Tumatanggap ang platform ng mga ES256 at RS256 authenticator at mas pinipili ang pag-verify sa user.
Mag-sign in gamit ang Google sa pamamagitan ng karaniwang koneksyon ng identity-provider, kaya mamanahin ng isang account ang anumang mga kontrol na ipinapatupad na ng iyong Google Workspace. Nakakonekta ang iba pang mga provider sa parehong paraan—walang anuman dito na isang pinasadyang integrasyon.
Pinapanatili para sa mga tao at script na nangangailangan nito, at sumusunod sa isang tunay na patakaran: hindi bababa sa labindalawang karakter, huwag kailanman gamitin ang iyong username o email address, walang paggamit muli sa iyong huling tatlo, at naka-hash gamit ang Argon2. Ang mga email address ay bina-verify bago maging magagamit ang isang account.
Ang ikalawang salik ay bahagi ng sistema ng pagkakakilanlan, hindi isang karagdagang binibili mo o plugin na in-install mo sa sarili mong site.
Kung ang iyong organisasyon ay nagpapatakbo na ng isang identity provider — Okta, Entra ID, Google Workspace, o anumang iba pa na sumusuporta sa SAML — maaari mo itong ikonekta at ang iyong mga tao ay mag-sign in sa Zinn Digital® gamit ang kanilang kasalukuyang corporate credentials. Walang pangalawang password para pamahalaan ang iyong koponan, at walang pangalawang offboarding checklist na makakalimutan.
Pinakamahalaga ito sa antas ng ahensya at reseller, kung saan ang pagpapalit ng tauhan ay isang tunay na isyu sa seguridad. Kapag may umalis at in-disable mo sila sa iyong direktoryo, na-disable mo na rin ang kanilang ruta papunta sa iyong hosting. Ang access ay sumusunod sa empleyo, nang sentralisado, sa halip na habulin ito sa labindalawang tool sa SaaS.
Ang SAML ay kasama ng iba pang mga sistema sa halip na palitan ito: ang mga kontratista ay maaari pa ring bigyan ng magic-link account sa loob ng may saklaw na tungkulin, habang ang mga permanenteng kawani naman ay pumapasok sa pamamagitan ng SSO. Isang organisasyon, isang modelo ng pahintulot, dalawang pintuan sa harapan.
Ang access ay nakasaklaw sa puno ng organisasyon — mula sa reseller hanggang sa kliyente hanggang sa site — at ipinapatupad mismo sa 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 maaaring magbalik ng mga row. Apat na tungkulin ng customer ang sumasaklaw sa makatotohanang dibisyon ng mga tungkulin.
Buong kontrol sa organisasyon at sa mga sub-account nito: gumawa ng mga child organization, mag-imbita at mag-alis ng mga miyembro, magtalaga ng mga tungkulin, mamahala sa bawat site, magpatakbo ng billing at invoicing, mamahala ng mga API key, at basahin ang audit log.
Mga invoice, subscription, paraan ng pagbabayad at ang katalogo ng plan — at wala nang iba. Ang iyong taong namamahala sa pananalapi o accountant ay maaaring magbayad ng invoice nang hindi kailanman nagkakaroon ng kakayahang gumalaw, mag-suspend, o mag-delete ng live na site.
Mga site at access sa API nang walang kontrol sa pagsingil: tingnan at i-provision ang mga site, i-restart ang mga serbisyo, i-purge ang mga cache, pamahalaan ang mga API key, at magtrabaho sa mga tiket. Sadyang walang access sa mga paraan ng pagbabayad, pag-invoice, o mga pagbabago sa plan.
Pang-view lang sa buong organisasyon — mga site, billing, plan, ticket, status ng pagsasalin, at ang audit log. Ang tamang papel para sa isang auditor, isang kliyenteng gustong makakita ng mga update, o isang bagong empleyado sa kanilang unang linggo.
Ang dashboard ay isang daan papasok. Ang API, CLI, ang Terraform provider at ang MCP server ay iba pa — at sumusunod ang mga ito sa parehong modelo ng access, dahil ang key na walang saklaw ay pag-bypass sa bawat role na kakakonpigura mo lang.
Ang isang API key ay ibinibigay sa isang organisasyon, hindi sa isang indibidwal na tao, at mayroon itong sariling mga saklaw (scopes). Ituring itong nakabahaging materyal ng kredensyal: pangalanan ito para sa layunin nito, bigyan ito ng pinakamakitid na mga saklaw na gagana, at palitan ito kapag umalis na ang taong lumikha nito.
Ipinapakita sa iyo ang hilaw na key nang isang minsan lamang, sa paggawa. Ang itinatago namin ay isang SHA-256 hash at isang maikling prefix para sa paghanap. Hindi na namin maipapakita sa iyo muli ang isang key, at ang paglabag sa database ay hindi nagbibigay sa isang attacker ng mga gumaganang kredensyal.
Ang bawat susi ay nagdadala ng mga detalyadong saklaw na nakaugnay sa parehong katalogo ng pahintulot na ginagamit ng mga tungkulin, nagtatala kung kailan ito huling ginamit, at maaaring bawiin nang tuluyan sa sandaling magmukhang mali ito. Ang mga hiwalay na sandbox key ay sumusubok sa API nang walang tunay na pagsingil o pagbibigay sa likod ng mga ito.
Binibigyang-daan ng MCP server ang anumang agent na may kakayahang MCP na pamahalaan ang iyong hosting — at nagpapatotoo ito sa pamamagitan ng OAuth 2.1, na naka-scope sa iyong organisasyon at sa mga pahintulot nitong RBAC, na may mga token na maaaring bawiin sa bawat tool, kumpirmasyon sa mga mapanirang aksyon, mga limitasyon sa gastusin, at buong audit logging. Ang pagkonekta ng AI assistant ay nangangahulugang hindi mo ibinibigay sa kanya ang mga susi sa lahat ng bagay.
Ang bawat privileged action ay sumusulat ng append-only record — kung sino ang gumawa, kung ano ang ginawa nila, kung ano ang ginawaan nito, ang sumusuportang ebidensya, at ang source IP address, kasama ang isang timestamp. Hindi ito isang kaginhawahan sa pag-debug; ito ang ebidensya trail.
Hindi — at mas nanaisin naming huwag mo itong gawin. Ang pag-sign in sa pamamagitan ng magic-link email ang default, at maaari kang magrehistro ng passkey (Touch ID, Face ID, Windows Hello, o hardware key) at mag-sign in nang hindi kailanman nagtatakda ng password. Nananatiling available ang email at password bilang opsyon sa pagsaklolo, na may minimum na labindalawang character, bawal ang paggamit ulit sa huli mong tatlo, at may Argon2 hashing.
Ang TOTP two-factor ay binuo sa identity layer at maaaring ipatupad sa pamamagitan ng patakaran sa buong organisasyon sa halip na iwanan sa bawat miyembro ang pag-opt in. Ang mga passkey ang mas malakas na opsyon kung sinusuportahan ito ng mga device ng iyong koponan, dahil inaalis nito ang password na posibleng i-phishing ng isang attacker.
Oo. Ang papel na Billing Manager ay nagbibigay ng access sa mga invoice, subscription, paraan ng pagbabayad, at katalogo ng plan, at wala nang iba pa — walang kakayahang tumingin, mag-provision, mag-restart, mag-suspend, o mag-delete ng site. Ganundin ang kabaligtaran: ang papel na Developer ay namamahala ng mga site at access sa API nang walang anumang kontrol sa pagsingil. Ang mga papel ay itinalaga sa bawat organisasyon, kaya ang isang papel sa isang organisasyon ay hindi nagbibigay ng access sa isa pa at hiwalay na organisasyon — bagama't ang isang papel sa isang magulang na organisasyon ay nalalapat sa mga organisasyong nakapaloob sa ilalim nito.
Bawiin ito mula sa dashboard at titigil ito sa paggana kaagad. Limitado ang saklaw ng pinsala sa kung ano ang kaya sanang gawin ng key na iyon noong una pa man, kaya naman mayroon itong mga detalyadong saklaw at nagtatala ng timestamp kung kailan ito huling ginamit — ang mga makikitid na saklaw at nakikitang bakas ng paggamit ang nagiging dahilan upang maging isang nakakubkob na insidente ang pagtagas sa halip na isang ganap na kompromiso sa account. Tandaan na ang mga key ay ibinibigay sa organisasyon sa halip na sa isang indibidwal, kaya ituring ang mga ito bilang mga ibinahaging kredensyal at palitan ang mga ito kapag umalis ang mga tao. Tanging ang hash lamang ng key ang nakaimbak sa aming panig, kaya ang pagtagas mula sa aming database ay hindi magbubunga ng gumaganang kredensyal.
Oo. Ang bawat pribilehiyong aksyon ay nakasulat sa isang append-only audit log kasama ang aktor, ang aksyon, ang target, sumusuportang ebidensya, ang pinagmulang IP, at isang timestamp. Ang mga may-ari at read-only na mga tungkulin ay direktang makakabasa nito. Ang mga aksyon ng staff sa iyong account ay nakatala sa parehong trail, at ang sensitibo o mapanirang mga aksyon ng staff ay maaaring mangailangan muna ng step-up authentication o pag-apruba ng dalawang tao.
Oo — sinusuportahan ang SAML SSO para sa mga enterprise at agency account, kaya nag-a-authenticate ang iyong mga tao gamit ang mga umiiral nang corporate credential at ang pag-offboard sa iyong direktoryo ay nag-aalis din ng kanilang access dito. Maaari mong pagsamahin ang mga diskarteng ito: SSO para sa mga permanenteng kawani, mga scoped magic-link account para sa mga contractor, na nasa loob lahat ng parehong modelo ng pahintulot.
Hindi — sadya naming hindi inililipat ang mga password. Ang iyong account ay ina-import nang walang password, at sa unang pag-sign in ay gagamit ka ng magic-link o magtatakda ng bagong password sa ilalim ng kasalukuyang patakaran. Ang paglipat ng mga lumang password hash ay magdadala ng mga lumang kahinaan sa isang bagong sistema, kaya hindi namin ito ginagawa.
Ang pagsubok sa Footprint-Free ay 14 na araw, walang kailangang credit card, at sumasaklaw sa hanggang limang site. Makukuha mo ang buong identity layer sa panahon ng pagsubok—ang mga passkey, two-factor, mga role, API key, at audit log ay hindi naka-lock sa likod ng bayaring plano.
Magrehistro ng passkey, imbitahan ang iyong team sa mga tamang tungkulin, at mag-isyu ng may saklaw na API key — lahat sa isang card-free na 14-araw na pagsubok na hindi nangangailangan ng mga detalye ng card.
Magsimula nang libre