खाता सुरक्षा
सर्वर सुरक्षा साइटों की सुरक्षा करती है। खाता सुरक्षा उनकी कुंजियों की सुरक्षा करती है। हर Zinn Digital® लॉगिन एक मानक-आधारित पहचान प्रणाली पर चलता है — पासकी और WebAuthn, TOTP टू-फैक्टर, मैजिक-लिंक साइन-इन, एंटरप्राइज़ और एजेंसी टीमों के लिए SAML SSO — जिसके पीछे दानेदार भूमिकाएँ, प्रति-संगठन API कुंजियाँ और केवल-जोड़ने योग्य (append-only) ऑडिट लॉग होते हैं।
ज़्यादातर होस्टिंग खाते कंट्रोल पैनल से जुड़े डेटाबेस में एक पासवर्ड होते हैं। हमारा एक समर्पित पहचान सिस्टम है — Keycloak, जो OIDC और SAML पर काम करता है — और यह हर चीज़ के सामने मौजूद रहता है: ग्राहक डैशबोर्ड, स्टाफ़ एडमिन कंसोल, यह सार्वजनिक साइट और नॉलेज बेस, और आपके सहायता टिकट। एक बार साइन इन करें और आप इन सभी में साइन इन हो जाते हैं।
चूँकि यह प्रोपरायटरी लॉगिन के बजाय खुले मानकों पर आधारित है, इसलिए पहचान परत (आइडेंटिटी लेयर) उसी तरह बदली जा सकती है जैसे प्लेटफ़ॉर्म का हर दूसरा घटक बदला जा सकता है। आपके एक्सेस मॉडल का कोई भी हिस्सा किसी वेंडर के उत्पाद के भीतर सीमित नहीं है, और आपकी टीम का कोई भी प्रमाणीकरण इस बात पर निर्भर नहीं करता कि हम किसी एक आपूर्तिकर्ता को बनाए रखें। यह वही नो-लॉक-इन सिद्धांत है जिसे हम CDN खातों, DNS और भुगतान प्रदाताओं पर लागू करते हैं।
साइन-इन को स्थानीयकृत किया गया है, और साइट से लॉगिन स्क्रीन पर जाने पर आपकी भाषा साथ चलती है—ताकि विभिन्न देशों में फैली टीम को केवल-अंग्रेज़ी लॉगिन से न गुजरना पड़े।
चार तरीके, सभी प्रथम श्रेणी के, सभी प्रत्येक व्यक्ति के लिए कॉन्फ़िगर करने योग्य। किसी को भी सबसे कमज़ोर विकल्प पर मजबूर नहीं किया जाता क्योंकि केवल वही एक विकल्प उपलब्ध है।
अपना ईमेल दर्ज करें, लिंक पर क्लिक करें, और आप अंदर हैं। फ़िशिंग, पुनः उपयोग या किसी डेटा उल्लंघन में लीक होने के लिए कोई पासवर्ड नहीं। यह नए खातों के लिए डिफ़ॉल्ट तरीका है, और अधिकांश लोगों के लिए यह एकमात्र तरीका है जिसकी उन्हें कभी आवश्यकता होती है।
पासकी रजिस्टर करें — टच आईडी, फेस आईडी, विंडोज हैलो, या YubiKey जैसी हार्डवेयर की — और बिना किसी पासवर्ड के साइन इन करें। पासकी ओरिजिन से जुड़ी होती हैं, इसलिए मिलती-जुलती लॉगिन पेज उन्हें चुरा नहीं सकती। प्लेटफ़ॉर्म ES256 और RS256 प्रमाणीकारकों को स्वीकार करता है और उपयोगकर्ता सत्यापन को प्राथमिकता देता है।
Google Workspace मानक आइडेंटिटी-प्रोवाइडेड कनेक्शन के ज़रिए Google से साइन इन करें, ताकि किसी खाते को वे सभी नियंत्रण मिल सकें जिन्हें आपका Google Workspace पहले से लागू करता है। अन्य प्रोवाइडर भी इसी तरह जुड़ते हैं — इसके बारे में कुछ भी कस्टमाइज़्ड इंटीग्रेशन नहीं है।
इसे उन लोगों और स्क्रिप्ट्स के लिए रखा गया है जिन्हें इसकी आवश्यकता है, और एक वास्तविक नीति का पालन किया जाता है: कम से कम बारह वर्ण, कभी भी आपका उपयोगकर्ता नाम या ईमेल पता नहीं, आपके पिछले तीन का कोई पुनः उपयोग नहीं, Argon2 के साथ हैश किया गया। खाता उपयोग योग्य बनने से पहले ईमेल पतों का सत्यापन किया जाता है।
दूसरा कारक पहचान प्रणाली का हिस्सा है, कोई अतिरिक्त चीज़ नहीं जिसे आप खरीदते हैं या अपनी साइट पर खुद प्लगइन के रूप में स्थापित करते हैं।
यदि आपका संगठन पहले से ही कोई पहचान प्रदाता — Okta, Entra ID, Google Workspace, या SAML का समर्थन करने वाला कोई अन्य प्रदाता — चलाता है, तो आप इसे कनेक्ट कर सकते हैं और आपके लोग अपनी मौजूदा कॉर्पोरेट साख के साथ Zinn Digital® में साइन इन कर सकते हैं। आपकी टीम के प्रबंधन के लिए कोई दूसरा पासवर्ड नहीं है, और भूलने के लिए कोई दूसरी ऑफ़बोर्डिंग चेकलिस्ट नहीं है।
एजेंसी और रीeller पैमाने पर यह सबसे अधिक मायने रखता है, जहाँ कर्मचारियों का आना-जाना एक वास्तविक सुरक्षा घटना है। जब कोई व्यक्ति जाता है और आप उसे अपनी डायरेक्टरी में अक्षम कर देते हैं, तो आपने होस्टिंग तक उनके रास्ते को भी अक्षम कर दिया है। पहुँच रोजगार का अनुसरण करती है, केंद्रीय रूप से, न कि दर्जनों SaaS टूल में उसका पीछा किया जाता है।
SAML किसी भी चीज़ को बदलने के बजाय बाकी सब के साथ काम करता है: ठेकेदारों को अभी भी एक सीमित भूमिका के भीतर मैजिक-लिंक अकाउंट दिया जा सकता है, जबकि स्थायी कर्मचारी SSO के माध्यम से प्रवेश करते हैं। एक संगठन, एक अनुमति मॉडल, दो प्रवेश द्वार।
एक्सेस को संगठन ट्री — रीसेलर से क्लाइंट और फिर साइट — तक सीमित किया गया है और इसे केवल एप्लिकेशन में ही नहीं, बल्कि डेटाबेस में ही पंक्ति-स्तरीय सुरक्षा (रो-लेवल सिक्योरिटी) के माध्यम से लागू किया जाता है। क्रॉस-टैनेंट एक्सेस कोई ऐसी नीति नहीं है जिसका हम लोगों से सम्मान करने की अपेक्षा करते हैं; यह एक ऐसी क्वेरी है जो पंक्तियाँ लौटा ही नहीं सकती। चार ग्राहक भूमिकाएँ कर्तव्यों के यथार्थवादी विभाजन को कवर करती हैं।
संगठन और उसके उप-खातों पर पूर्ण नियंत्रण: चाइल्ड संगठन बनाएं, सदस्यों को आमंत्रित करें और हटाएं, भूमिकाएँ असाइन करें, प्रत्येक साइट को प्रबंधित करें, बिलिंग और चालान-पुस्तिका चलाएं, API कुंजियों को प्रबंधित करें, और ऑडिट लॉग पढ़ें।
चालान, सदस्यताएँ, भुगतान के तरीके और प्लान कैटलॉग — और इसके अलावा कुछ नहीं। आपका वित्त कर्मचारी या अकाउंटेंट किसी लाइव साइट को छुए बिना, निलंबित किए बिना या हटाए बिना कोई चालान चुका सकता है।
साइटें और एपीआई एक्सेस बिना बिलिंग नियंत्रण के: साइटें देखना और प्रावधान करना, सेवाओं को पुनरारंभ करना, कैश साफ़ करना, एपीआई कुंजियाँ प्रबंधित करना और टिकटों पर काम करना। भुगतान विधियों, इनवॉइसिंग या प्लान परिवर्तनों तक जानबूझकर कोई पहुँच नहीं।
पूरे संगठन में केवल-देखने की अनुमति — साइट्स, बिलिंग, प्लान्स, टिकट, अनुवाद स्थिति और ऑडिट लॉग। किसी ऑडिटर, पारदर्शिता चाहने वाले क्लाइंट, या अपने पहले हफ़्ते में नए काम शुरू करने वाले व्यक्ति के लिए सही भूमिका।
डैशबोर्ड प्रवेश का एक तरीका है। API, CLI, Terraform प्रोवाइडर और MCP सर्वर अन्य तरीके हैं — और इन्हें समान एक्सेस मॉडल के अधीन रखा जाता है, क्योंकि एक बिना दायरे वाली कुंजी (unscoped key) आपके द्वारा अभी कॉन्फ़िगर किए गए प्रत्येक रोल को दरकिनार करती है।
एक API कुंजी किसी संगठन को जारी की जाती है, किसी व्यक्तिगत व्यक्ति को नहीं, और इसके अपने दायरे होते हैं। इसे साझा क्रेडेंशियल सामग्री के रूप में मानें: इसके उद्देश्य के अनुसार इसका नाम रखें, इसे सबसे सीमित दायरे दें जो काम करते हैं, और जब इसे बनाने वाला व्यक्ति चला जाए तो इसे घुमाएँ (रोटेट करें)।
कच्ची कुंजी (raw key) आपको केवल निर्माण के समय एक बार दिखाई जाती है। हम केवल SHA-256 हैश और लुकअप के लिए एक छोटा प्रिफिक्स सुरक्षित रखते हैं। हम आपको कुंजी दोबारा नहीं दिखा सकते, और डेटाबेस से छेड़छाड़ होने पर भी हमलावर के हाथ में काम करने वाले क्रेडेंशियल्स नहीं आते।
हर कुंजी में दानेदार स्कोप होते हैं जो उसी अनुमति कैटलॉग से जुड़े होते हैं जिनका उपयोग भूमिकाएँ करती हैं, यह रिकॉर्ड करता है कि इसका अंतिम बार उपयोग कब किया गया था, और संदिग्ध लगने पर इसे तुरंत निरस्त किया जा सकता है। अलग-अलग सैंडबॉक्स कुंजियाँ इसके पीछे किसी वास्तविक बिलिंग या प्रोविज़निंग के बिना API का परीक्षण करती हैं।
MCP सर्वर किसी भी MCP-सक्षम एजेंट को आपकी होस्टिंग प्रबंधित करने की अनुमति देता है—और यह OAuth 2.1 के माध्यम से प्रमाणित करता है, जो आपके संगठन और उसकी RBAC अनुमतियों तक सीमित है, प्रति-टूल निरस्त करने योग्य टोकन, विनाशकारी क्रियाओं पर पुष्टि, खर्च की सीमा और पूर्ण ऑडिट लॉगिंग के साथ। AI सहायक को जोड़ने का मतलब यह नहीं है कि उसे हर चीज़ की चाबी सौंप दी जाए।
हर विशेषाधिकार प्राप्त कार्रवाई एक अपेंड-ओनली रिकॉर्ड लिखती है — किसने किया, उन्होंने क्या किया, किस पर किया, इसके समर्थन में साक्ष्य, और स्रोत आईपी पता, एक टाइमस्टैम्प के साथ। यह डिबगिंग की सुविधा नहीं है; यह साक्ष्य का ट्रेल है।
नहीं — और हम चाहेंगे कि आप ऐसा न करें। मैजिक-लिंक ईमेल साइन-इन डिफ़ॉल्ट है, और आप पासकी (Touch ID, Face ID, Windows Hello या एक हार्डवेयर की) रजिस्टर कर सकते हैं और बिना कोई पासवर्ड सेट किए साइन इन कर सकते हैं। ईमेल और पासवर्ड का विकल्प एक बैकअप के रूप में उपलब्ध रहता है, जिसके लिए न्यूनतम बारह-अक्षर अनिवार्य हैं, आपके अंतिम तीन पासवर्ड का पुनः उपयोग नहीं किया जा सकता, और यह Argon2 हैशिंग से सुरक्षित है।
TOTP टू-फ़ैक्टर इसके आइडेंटिटी लेयर में पहले से मौजूद है और इसे किसी संगठन में हर सदस्य की मर्ज़ी पर छोड़ने के बजाय नीति के ज़रिए लागू किया जा सकता है। पासकीज़ ज़्यादा मज़बूत विकल्प हैं जहाँ आपकी टीम के डिवाइस उनका समर्थन करते हैं, क्योंकि वे उस पासवर्ड को हटा देते हैं जिसके लिए हमलावर फ़िशिंग करेंगे।
हाँ। बिलिंग मैनेजर की भूमिका केवल इनवॉयस, सब्सक्रिप्शन, भुगतान के तरीकों और प्लान कैटलॉग तक पहुँच देती है, और इसके अलावा कुछ नहीं — इसमें किसी साइट को देखने, प्रावधान करने, रीस्टार्ट करने, निलंबित करने या हटाने की कोई क्षमता नहीं होती है। इसका उल्टा भी लागू होता है: डेवलपर की भूमिका बिना किसी बिलिंग नियंत्रण के केवल साइटों और API एक्सेस को प्रबंधित करती है। भूमिकाएँ प्रत्येक संगठन के हिसाब से असाइन की जाती हैं, इसलिए एक संगठन में दी गई भूमिका किसी अलग, असंबंधित संगठन में कोई पहुँच नहीं देती है — हालाँकि मूल (पैरेंट) संगठन की भूमिका उसके अंतर्गत नेस्टेड संगठनों पर लागू होती है।
इसे डैशबोर्ड से निरस्त करें और यह तुरंत काम करना बंद कर देता है। नुकसान की सीमा इस बात से तय होती है कि वह कुंजी शुरुआत में क्या कर सकती थी, यही वजह है कि कुंजियों में सटीक स्कोप होते हैं और यह अंतिम-उपयोग का टाइमस्टैम्प रिकॉर्ड करती हैं — सीमित स्कोप और उपयोग का दृश्यमान इतिहास ही किसी लीक को पूरे खाते की सुरक्षा में सेंध लगने के बजाय एक नियंत्रित घटना में बदलते हैं। ध्यान दें कि कुंजियाँ किसी व्यक्ति के बजाय संगठन को जारी की जाती हैं, इसलिए इन्हें साझा क्रेडेंशियल के रूप में मानें और लोगों के जाने पर इन्हें बदल दें। हमारे पास केवल कुंजी का एक हैश संग्रहीत होता है, इसलिए हमारे डेटाबेस से लीक होने पर भी कोई काम करने योग्य क्रेडेंशियल हाथ नहीं लगता है।
हाँ। हर विशेषाधिकार प्राप्त क्रिया को अभिनेता, क्रिया, लक्ष्य, सहायक साक्ष्य, स्रोत IP और टाइमस्टैम्प के साथ केवल-अपेंड ऑडिट लॉग में लिखा जाता है। Owner और read-only भूमिकाएं इसे सीधे पढ़ सकती हैं। आपके खाते पर स्टाफ की क्रियाएं उसी ट्रेल में लॉग की जाती हैं, और संवेदनशील या विनाशकारी स्टाफ क्रियाओं के लिए पहले स्टेप-अप प्रमाणीकरण या दो-व्यक्ति अनुमोदन की आवश्यकता हो सकती है।
हाँ — एंटरप्राइज़ और एजेंसी खातों के लिए SAML SSO समर्थित है, इसलिए आपके लोग मौजूदा कॉर्पोरेट क्रेडेंशियल्स के साथ प्रमाणीकरण करते हैं और आपकी निर्देशिका में ऑफ़बोर्डिंग करने से यहाँ भी उनकी पहुँच समाप्त हो जाती है। आप दोनों तरीकों को मिला सकते हैं: स्थायी कर्मचारियों के लिए SSO, ठेकेदारों के लिए सीमित मैजिक-लिंक खाते, ये सभी एक ही अनुमति मॉडल के भीतर।
नहीं — पासवर्ड जानबूझकर माइग्रेट नहीं किए जाते हैं। आपका खाता बिना पासवर्ड के आयात किया जाता है, और पहली बार साइन-इन करने पर आप या तो मैजिक-लिंक का उपयोग करते हैं या मौजूदा नीति के तहत एक नया पासवर्ड सेट करते हैं। पुराने पासवर्ड हैश को पोर्ट करने से एक नई प्रणाली में पुरानी कमज़ोरियाँ आ जातीं, इसलिए हम ऐसा नहीं करते हैं।
Footprint-Free ट्रायल 14 दिनों का है, इसके लिए किसी कार्ड की आवश्यकता नहीं है, और यह अधिकतम पांच साइटों को कवर करता है। ट्रायल के दौरान आपको पूरा आइडेंटिटी लेयर मिलता है — पासकी, टू-फ़ैक्टर, भूमिकाएँ, API की और ऑडिट लॉग किसी पैड प्लान के पीछे सीमित नहीं किए गए हैं।
एक पासकी रजिस्टर करें, अपनी टीम को सही भूमिकाओं में आमंत्रित करें, और एक स्कोप्ड API कुंजी जारी करें — यह सब कार्ड-मुक्त 14-दिन के ट्रायल पर, जिसमें किसी कार्ड विवरण की आवश्यकता नहीं है।
निःशुल्क शुरू करें