खाता सुरक्षा

आपका खाता, पहचान स्तर पर पूरी तरह सुरक्षित

सर्वर सुरक्षा साइटों की रक्षा करती है। खाता सुरक्षा उनकी कुंजियों की रक्षा करती है। प्रत्येक Zinn Digital® लॉगिन एक मानक-आधारित पहचान प्रणाली पर चलता है — पासकी और WebAuthn, TOTP द्वि-कारक प्रमाणीकरण, मैजिक-लिंक साइन-इन, उद्यम और एजेंसी टीमों के लिए SAML SSO — इसके पीछे विस्तृत भूमिकाएँ, प्रति-संगठन API कुंजियाँ और एक केवल-जोड़ने-योग्य ऑडिट लॉग शामिल हैं।

मुफ़्त शुरू करें होस्टिंग सुरक्षा

7,00,000+दुनिया भर में होस्ट की गई साइटें
पासकीWebAuthn साइन-इन, अंतर्निहित
SAML SSOएंटरप्राइज और एजेंसी खातों के लिए
ऑडिट-लॉग किया गयाप्रत्येक विशेषाधिकार प्राप्त क्रिया

एक पहचान, हर सतह

अधिकांश होस्टिंग खाते डेटाबेस में एक पासवर्ड होते हैं, जो कंट्रोल पैनल से जुड़े होते हैं। हमारा एक समर्पित पहचान तंत्र है — Keycloak, जो OIDC और SAML का उपयोग करता है — जो हर चीज़ के सामने रहता है: ग्राहक डैशबोर्ड, स्टाफ़ एडमिन कंसोल, यह सार्वजनिक साइट और ज्ञानकोष, और आपके समर्थन टिकट। एक बार साइन इन करें और आप इन सभी में साइन इन हो जाएंगे।

स्वामित्व वाले लॉगिन के बजाय खुले मानकों पर निर्मित होने के कारण, आइडेंटिटी लेयर को प्लेटफ़ॉर्म के हर दूसरे घटक की तरह ही बदला जा सकता है। आपके एक्सेस मॉडल का कोई भी हिस्सा किसी वेंडर के उत्पाद में फंसा नहीं है, और आपकी टीम का प्रमाणीकरण हमारे किसी एक सप्लायर को बनाए रखने पर निर्भर नहीं करता है। यह वही नो-लॉक-इन सिद्धांत है जिसे हम CDN खातों, DNS और भुगतान प्रदाताओं पर लागू करते हैं।

साइन-इन स्थानीयकृत है, और साइट से लॉगिन स्क्रीन पर जाने के दौरान आपकी भाषा भी साथ रहती है — ताकि विभिन्न देशों में फैली टीम को केवल अंग्रेज़ी लॉगिन का उपयोग करने के लिए बाध्य न होना पड़े।

उस तरीके से साइन इन करें जो आपकी टीम के लिए सबसे उपयुक्त हो

चार तरीके, सभी प्रथम श्रेणी के, सभी प्रत्येक व्यक्ति के अनुसार कॉन्फ़िगर करने योग्य। किसी को भी केवल इसलिए सबसे कमजोर विकल्प चुनने के लिए बाध्य नहीं किया जाता क्योंकि वही एकमात्र उपलब्ध विकल्प है।

मैजिक-लिंक ईमेल (डिफ़ॉल्ट)

अपना ईमेल दर्ज करें, लिंक पर क्लिक करें, और आप लॉग इन हो गए हैं। फ़िशिंग, दोबारा इस्तेमाल या डेटा ब्रीच में लीक होने के लिए कोई पासवर्ड नहीं है। यह नए खातों के लिए डिफ़ॉल्ट मार्ग है, और अधिकांश लोगों के लिए यह एकमात्र ऐसा तरीका है जिसकी उन्हें कभी आवश्यकता होगी।

पासकी / WebAuthn

एक पासकी पंजीकृत करें — Touch ID, Face ID, Windows Hello, या YubiKey जैसी कोई हार्डवेयर कुंजी — और बिना किसी पासवर्ड के साइन इन करें। पासकी मूल डोमेन से बंधी होती हैं, इसलिए कोई मिलती-जुलती फ़र्ज़ी लॉगिन साइट इसे चुरा नहीं सकती। यह प्लेटफ़ॉर्म ES256 और RS256 प्रमाणीकर्ताओं को स्वीकार करता है और उपयोगकर्ता सत्यापन को प्राथमिकता देता है।

सोशल लॉगिन

एक मानक पहचान-प्रदाता कनेक्शन के माध्यम से Google से साइन इन करें, ताकि खाता उन सभी नियंत्रणों को प्राप्त कर सके जिन्हें आपका Google Workspace पहले से लागू करता है। अन्य प्रदाता भी उसी तरह जुड़ते हैं — इसमें कुछ भी कस्टम एकीकरण नहीं है।

ईमेल और पासवर्ड (फ़ॉलबैक)

उन लोगों और लिपियों के लिए रखा गया है जिन्हें इसकी आवश्यकता है, और एक वास्तविक नीति के तहत बाध्य है: न्यूनतम बारह वर्ण, कभी भी आपका उपयोगकर्ता नाम या ईमेल पता नहीं, आपके पिछले तीन का पुन: उपयोग नहीं, Argon2 के साथ हैश किया गया। खाता उपयोग योग्य बनने से पहले ईमेल पते सत्यापित किए जाते हैं।

टू-फैक्टर और ब्रूट-फोर्स सुरक्षा

दूसरे कारक पहचान प्रणाली का एक हिस्सा हैं, यह कोई ऐसा ऐड-ऑन नहीं है जिसे आप खरीदते हैं या कोई प्लगइन जिसे आप अपनी साइट पर इंस्टॉल करते हैं।

किसी भी मानक प्रमाणीकरण ऐप के माध्यम से TOTP दो-चरणीय प्रमाणीकरण — तीस सेकंड की अवधि में छह अंक, वही योजना जो Google Authenticator, 1Password और Authy उपयोग करते हैं। इसे प्रत्येक व्यक्ति की सद्भावना पर छोड़ने के बजाय नीति के माध्यम से पूरे संगठन में अनिवार्य किया जा सकता है।
पासकी पासवर्ड के ऊपर एक अतिरिक्त परत बनने के बजाय उसे पूरी तरह से प्रतिस्थापित कर सकती हैं, जिससे वे क्रेडेंशियल ही समाप्त हो जाते हैं जिन्हें कोई फ़िशर सबसे पहले चुराने की कोशिश करता है।
रेल्म स्तर पर ब्रूट-फोर्स सुरक्षा चालू है: बार-बार असफल प्रयासों के कारण प्रतीक्षा अवधि बढ़ती जाती है, जो पंद्रह मिनट तक हो सकती है, जिससे क्रेडेंशियल-स्टफिंग का प्रयास किसी शब्दसूची को खंगालने के बजाय रुक जाता है। लॉकआउट को जानबूझकर अस्थायी रखा गया है — कोई भी हमलावर किसी वास्तविक ग्राहक को उसके अपने खाते से स्थायी रूप से बाहर नहीं कर सकता है।
साइनअप ईमेल पतों को पंजीकरण के समय ZeroBounce-संचालित एडॉप्टर के माध्यम से सत्यापित किया जाता है: न पहुँचने योग्य और अमान्य पतों को अस्वीकार कर दिया जाता है, और डिस्पोजेबल, भूमिका-आधारित तथा दुरुपयोग के रूप में चिह्नित पतों को फ़्लैग किया जाता है। फ़र्जी या ईमेल प्राप्त न कर सकने वाले पतों को खाता नहीं मिलता है, जो ट्रायल के दुरुपयोग-विरोधी और धोखाधड़ी की जाँच में भी सहायता करता है।
सत्रों को कड़े नियंत्रण में रखा जाता है — एक्सेस टोकन अल्पकालिक होते हैं, निष्क्रिय सत्र समाप्त हो जाते हैं, और प्रत्येक सत्र का एक निश्चित अधिकतम जीवनकाल होता है, ताकि साझा कंप्यूटर पर भूला हुआ ब्राउज़र कल के लिए कोई खुला दरवाजा न बन जाए।

एंटरप्राइज़ और एजेंसी टीमों के लिए SAML SSO

यदि आपका संगठन पहले से ही किसी आइडेंटिटी प्रोवाइडर का उपयोग करता है — Okta, Entra ID, Google Workspace, या ऐसा कुछ भी जो SAML का समर्थन करता है — तो आप इसे कनेक्ट करते हैं और आपके कर्मचारी अपने मौजूदा कॉर्पोरेट क्रेडेंशियल्स के साथ Zinn Digital® में साइन इन करते हैं। आपकी टीम के लिए प्रबंधित करने हेतु कोई दूसरा पासवर्ड नहीं है, और भूलने के लिए कोई दूसरी ऑफ़बोर्डिंग चेकलिस्ट नहीं है।

यह एजेंसी और रीसेलर के स्तर पर सबसे अधिक मायने रखता है, जहाँ कर्मचारियों का आना-जाना सुरक्षा से जुड़ी एक वास्तविक घटना होती है। जब कोई व्यक्ति संस्थान छोड़ता है और आप उसे अपनी डायरेक्टरी में निष्क्रिय कर देते हैं, तो आप अपनी होस्टिंग में भी उसके प्रवेश मार्ग को निष्क्रिय कर देते हैं। दर्जनों SaaS टूल्स में खोजने के बजाय, एक्सेस केंद्रीय रूप से रोज़गार की स्थिति का अनुसरण करता है।

SAML हर चीज़ को बदलने के बजाय उसके साथ मिलकर काम करता है: ठेकेदारों को अभी भी एक सीमित भूमिका के भीतर मैजिक-लिंक खाता दिया जा सकता है, जबकि स्थायी कर्मचारी SSO के माध्यम से आते हैं। एक संगठन, एक अनुमति मॉडल, दो मुख्य द्वार।

ऐसी भूमिकाएं जो केवल वही प्रदान करती हैं जिसकी कार्य के लिए आवश्यकता है

एक्सेस संगठन ट्री तक सीमित है — पुनर्विक्रेता से क्लाइंट और फिर साइट तक — और इसे केवल एप्लिकेशन में ही नहीं, बल्कि डेटाबेस में रो-लेवल सुरक्षा के माध्यम से लागू किया जाता है। क्रॉस-टैनेंट एक्सेस कोई ऐसी नीति नहीं है जिसका हम लोगों से सम्मान करने का अनुरोध करते हैं; यह एक ऐसी क्वेरी है जो पंक्तियाँ वापस नहीं कर सकती। ग्राहकों की चार भूमिकाएँ कर्तव्यों के यथार्थवादी विभाजन को कवर करती हैं।

स्वामी

संगठन और उसके उप-खातों पर पूर्ण नियंत्रण: चाइल्ड संगठन बनाएं, सदस्यों को आमंत्रित करें और हटाएं, भूमिकाएं सौंपें, प्रत्येक साइट का प्रबंधन करें, बिलिंग और इनवॉइसिंग संचालित करें, API कुंजियों का प्रबंधन करें, और ऑडिट लॉग पढ़ें।

बिलिंग प्रबंधक

चालान, सदस्यताएँ, भुगतान विधियाँ और प्लान कैटलॉग — और कुछ भी नहीं। आपका वित्त विशेषज्ञ या मुनीम किसी लाइव साइट में बदलाव करने, उसे निलंबित करने या हटाने की क्षमता रखे बिना भी चालान का निपटान कर सकता है।

डेवलपर

बिलिंग नियंत्रण के बिना साइटों और API तक पहुंच: साइटें देखें और प्रावधान करें, सेवाओं को पुनः आरंभ करें, कैश साफ़ करें, API कुंजियां और कार्य टिकट प्रबंधित करें। जानबूझकर भुगतान विधियों, चालान या योजना परिवर्तनों तक कोई पहुंच नहीं है।

केवल पढ़ने के लिए

पूरे संगठन में केवल देखने की अनुमति — साइटें, बिलिंग, योजनाएं, टिकट, अनुवाद की स्थिति और ऑडिट लॉग। एक ऑडिटर, दृश्यता चाहने वाले ग्राहक, या अपने पहले सप्ताह में शामिल होने वाले नए कर्मचारी के लिए उपयुक्त भूमिका।

API कुंजियाँ, टोकन और AI कनेक्शन

डैशबोर्ड प्रवेश का एक माध्यम है। API, CLI, Terraform प्रदाता और MCP सर्वर अन्य माध्यम हैं — और वे समान एक्सेस मॉडल का पालन करते हैं, क्योंकि एक अनस्कोप्ड कुंजी आपके द्वारा अभी कॉन्फ़िगर की गई प्रत्येक भूमिका को बायपास कर देती है।

कुंजियाँ संगठन की हैं

एक API कुंजी किसी संस्था को जारी की जाती है, किसी व्यक्तिगत व्यक्ति को नहीं, और इसके अपने स्कोप होते हैं। इसे साझा क्रेडेंशियल सामग्री के रूप में मानें: इसके उद्देश्य के अनुसार इसका नाम रखें, इसे काम करने योग्य न्यूनतम स्कोप प्रदान करें, और इसे बनाने वाले व्यक्ति के पद छोड़ने या जाने पर इसे रोटेट करें।

केवल एक हैश ही संग्रहीत किया जाता है

रॉ कुंजी आपको केवल एक बार, निर्माण के समय दिखाई जाती है। हम केवल एक SHA-256 हैश और लुकअप के लिए एक छोटा उपसर्ग ही रखते हैं। हम आपको दोबारा कुंजी नहीं दिखा सकते हैं, और डेटाबेस में सेंध लगने पर भी हमलावर के हाथ काम करने वाले क्रेडेंशियल नहीं लगते हैं।

सीमित कार्यक्षेत्र वाला, निरसनीय, अवलोकनीय

प्रत्येक कुंजी में भूमिकाओं द्वारा उपयोग की जाने वाली समान अनुमति सूची से जुड़े सूक्ष्म दायरे होते हैं, यह रिकॉर्ड करती है कि इसका अंतिम उपयोग कब किया गया था, और संदिग्ध लगते ही इसे तुरंत निरस्त किया जा सकता है। अलग sandbox कुंजियाँ बिना किसी वास्तविक बिलिंग या प्रावधान के API का परीक्षण करती हैं।

एआई उपकरण समान नियमों के तहत कनेक्ट होते हैं

MCP सर्वर किसी भी MCP-सक्षम एजेंट को आपके होस्टिंग को प्रबंधित करने की अनुमति देता है — और यह OAuth 2.1 के माध्यम से प्रमाणित होता है, जो आपके संगठन और उसकी RBAC अनुमतियों तक सीमित है, जिसमें प्रति-उपकरण प्रतिसंहरणीय टोकन, विनाशकारी क्रियाओं पर पुष्टि, खर्च सीमाएं और पूर्ण ऑडिट लॉगिंग शामिल हैं। AI सहायक को कनेक्ट करने का मतलब यह नहीं है कि उसे हर चीज़ की चाबियां सौंप दी जाएं।

ऑडिट लॉग और उस तक पहुंच

प्रत्येक विशेषाधिकार प्राप्त क्रिया एक केवल-जोड़ने-योग्य (अपेंड-ओनली) रिकॉर्ड दर्ज करती है — यह किसने किया, उन्होंने क्या किया, किस पर किया, सहायक साक्ष्य और स्रोत आईपी पता, टाइमस्टैम्प के साथ। यह केवल डिबगिंग की सुविधा नहीं है; यह साक्ष्य का निशान है।

मालिक और केवल-पठन भूमिकाएँ ऑडिट लॉग को सीधे पढ़ सकती हैं, इसलिए आपके संगठन के भीतर जवाबदेही के लिए हमारे साथ कोई समर्थन टिकट खोलने की आवश्यकता नहीं है।
आपके खाते तक कर्मचारियों की पहुंच उसी व्यवस्था द्वारा नियंत्रित होती है: हमारे कर्मी प्रति-मॉड्यूल, प्रति-कार्रवाई अनुमतियों वाले विभागों में बैठते हैं, इसलिए एक सहायता एजेंट केवल टिकट और बुनियादी समाधान देखता है, न कि आपका बिलिंग कॉन्फ़िगरेशन या आपका बेड़ा।
संवेदनशील और विनाशकारी स्टाफ कार्रवाइयों को निष्पादित करने से पहले अतिरिक्त प्रमाणीकरण या दो-व्यक्ति अनुमोदन की आवश्यकता हो सकती है।
अन्य सभी चीज़ों के अलावा, जो टीमें केवल ज्ञात नेटवर्क तक ही पहुँच सीमित करना चाहती हैं, उनके लिए संगठन स्तर पर IP अनुमति सूची (allowlisting) उपलब्ध है।
वही ऑडिट ट्रेल, न्यूनतम-विशेषाधिकार मॉडल और प्रति-किरायेदार अलगाव हमारे SOC 2 और ISO 27001 रोडमैप को गति देते हैं — साक्ष्य बाद में पुनर्निर्मित किए जाने के बजाय पहले दिन से ही तैयार किए जा रहे हैं।

अक्सर पूछे जाने वाले प्रश्न

क्या मुझे पासवर्ड का उपयोग करना ही होगा?

नहीं — और हम चाहेंगे कि आप ऐसा न करें। मैजिक-लिंक ईमेल साइन-इन डिफ़ॉल्ट है, और आप एक पासकी (Touch ID, Face ID, Windows Hello या हार्डवेयर कुंजी) पंजीकृत कर सकते हैं और बिना कोई पासवर्ड सेट किए साइन इन कर सकते हैं। ईमेल और पासवर्ड एक फ़ॉलबैक के रूप में उपलब्ध रहता है, जिसके लिए न्यूनतम बारह अक्षर, आपके पिछले तीन पासवर्ड का पुन: उपयोग न करने और Argon2 हैशिंग की आवश्यकता होती है।

क्या मैं अपनी टीम के लिए दो-चरणीय प्रमाणीकरण अनिवार्य कर सकता हूँ?

TOTP टू-फैक्टर प्रमाणीकरण पहचान परत में अंतर्निहित है और इसे प्रत्येक सदस्य की पसंद पर छोड़ने के बजाय संगठन स्तर पर नीति द्वारा लागू किया जा सकता है। जहां आपकी टीम के डिवाइस इसका समर्थन करते हैं, वहां पासकी अधिक सशक्त विकल्प हैं, क्योंकि वे उस पासवर्ड को ही हटा देते हैं जिसे कोई हमलावर फ़िशिंग के ज़रिये चुराने का प्रयास कर सकता है।

मेरी टीम का एक सदस्य केवल इनवॉइस संभालता है। क्या मैं उसे साइटों में बदलाव करने से रोक सकता हूँ?

हाँ। बिलिंग प्रबंधक (Billing Manager) भूमिका केवल इनवॉइस, सदस्यताओं, भुगतान विधियों और प्लान कैटलॉग तक पहुंच प्रदान करती है, और कुछ नहीं — साइट को देखने, प्रोविज़न करने, पुनः आरंभ करने, निलंबित करने या हटाने की कोई क्षमता नहीं। इसका विपरीत भी लागू होता है: डेवलपर (Developer) भूमिका बिना किसी बिलिंग नियंत्रण के साइटों और API एक्सेस का प्रबंधन करती है। भूमिकाएं प्रति संगठन सौंपी जाती हैं, इसलिए एक संगठन में एक भूमिका एक अलग, असंबंधित संगठन में कोई पहुंच प्रदान नहीं करती है — यद्यपि मूल (पैरेंट) संगठन में एक भूमिका उसके तहत आने वाले संगठनों पर लागू होती है।

यदि हमारी कोई API कुंजी लीक हो जाती है तो क्या होता है?

डैशबोर्ड से इसे निरस्त करें और यह तुरंत काम करना बंद कर देता है। क्षति की सीमा इस बात से बंधी है कि वह कुंजी मूल रूप से क्या कर सकती थी, यही कारण है कि कुंजियों में विस्तृत स्कोप होते हैं और वे अंतिम बार उपयोग किए जाने का टाइमस्टैम्प रिकॉर्ड करती हैं — संकीर्ण स्कोप और एक दृश्यमान उपयोग का निशान ही रिसाव को पूरे खाते के खतरे में पड़ने के बजाय एक सीमित घटना में बदल देते हैं। ध्यान दें कि कुंजियाँ किसी व्यक्ति के बजाय संगठन को जारी की जाती हैं, इसलिए उन्हें साझा क्रेडेंशियल के रूप में मानें और लोगों के जाने पर उन्हें बदलें। हमारी ओर केवल कुंजी का एक हैश संग्रहीत किया जाता है, इसलिए हमारे डेटाबेस से रिसाव होने पर कोई कार्यशील क्रेडेंशियल उत्पन्न नहीं होता है।

क्या मैं देख सकता हूँ कि मेरे खाते में किसने क्या किया?

हाँ। प्रत्येक विशेषाधिकार प्राप्त कार्रवाई को कर्ता, कार्रवाई, लक्ष्य, सहायक साक्ष्य, स्रोत आईपी और एक टाइमस्टैम्प के साथ केवल-जोड़ने योग्य (append-only) ऑडिट लॉग में लिखा जाता है। स्वामी और केवल-पढ़ने योग्य भूमिकाएँ इसे सीधे पढ़ सकती हैं। आपके खाते पर कर्मचारियों की कार्रवाइयों को उसी ट्रेल में लॉग किया जाता है, और संवेदनशील या विनाशकारी कर्मचारी कार्रवाइयों के लिए पहले चरणबद्ध प्रमाणीकरण या दो-व्यक्ति अनुमोदन की आवश्यकता हो सकती है।

हम पहले से ही Okta / Entra ID का उपयोग करते हैं। क्या हमारी टीम उससे साइन इन कर सकती है?

हाँ — एंटरप्राइज़ और एजेंसी खातों के लिए SAML SSO समर्थित है, इसलिए आपके लोग मौजूदा कॉर्पोरेट क्रेडेंशियल्स के साथ प्रमाणित होते हैं और आपकी निर्देशिका में ऑफ़बोर्डिंग करने से उनकी पहुँच यहाँ से भी समाप्त हो जाती है। आप दृष्टिकोणों को मिला सकते हैं: स्थायी कर्मचारियों के लिए SSO, ठेकेदारों के लिए स्कोप्ड magic-link खाते, ये सभी समान अनुमति मॉडल के अंतर्गत हैं।

मैं आपके V1 प्लेटफ़ॉर्म से माइग्रेट कर रहा हूँ। क्या मेरा पुराना पासवर्ड भी ट्रांसफर हो जाएगा?

नहीं — पासवर्ड जानबूझकर माइग्रेट नहीं किए जाते हैं। आपका खाता बिना पासवर्ड के आयात किया जाता है, और पहले साइन-इन पर आप या तो मैजिक-लिंक का उपयोग करते हैं या वर्तमान नीति के तहत एक नया पासवर्ड सेट करते हैं। पुराने पासवर्ड हैश को पोर्ट करने से नए सिस्टम में पुरानी कमियां आ सकती हैं, इसलिए हम ऐसा नहीं करते हैं।

कार्ड का विवरण दिए बिना मैं इसे कैसे आज़मा सकता हूँ?

Footprint-Free ट्रायल 14 दिनों का है, इसके लिए कार्ड की आवश्यकता नहीं है, और यह पाँच साइटों तक को कवर करता है। ट्रायल के दौरान आपको संपूर्ण पहचान स्तर मिलता है — पासकी, टू-फ़ैक्टर, भूमिकाएँ, API कुंजियाँ और ऑडिट लॉग किसी सशुल्क योजना के पीछे प्रतिबंधित नहीं हैं।

पहले पांच मिनट में अपना खाता ठीक से सेट करें

एक पासकी पंजीकृत करें, अपनी टीम को सही भूमिकाओं में आमंत्रित करें, और एक सीमित दायरे वाली API कुंजी जारी करें — यह सब बिना किसी कार्ड विवरण की आवश्यकता वाले 14-दिवसीय निःशुल्क परीक्षण पर उपलब्ध है।

मुफ़्त शुरू करें