खात्याची सुरक्षा
सर्व्हर सुरक्षिततेमुळे साईट्स सुरक्षित राहतात. खाते सुरक्षिततेमुळे त्यांच्यावरील नियंत्रणाच्या चाव्या सुरक्षित राहतात. Zinn Digital® वरील प्रत्येक लॉगिन मानकांवर आधारित एकाच ओळख प्रणालीवर चालते — पासकिज आणि WebAuthn, TOTP टू-फॅक्टर, मॅजिक-लिंक साईन-इन, एंटरप्राइज आणि एजन्सी टीम्ससाठी SAML SSO — या सर्वांच्या मागे सविस्तर भूमिका (ग्रॅन्युलर रोल्स), प्रति-संघटना API की आणि केवळ जोडला जाणारा (अपेन्ड-ओन्ली) ऑडिट लॉग असतो.
बहुतेक होस्टिंग खाती हे कंट्रोल पनेलला जोडलेले डेटाबेसमधील पासवर्ड असतात. आमची सिस्टीम एक समर्पित ओळख प्रणाली आहे — Keycloak, जी OIDC आणि SAML वर काम करते — जी प्रत्येक गोष्टीच्या समोर असते: ग्राहक डॅशबोर्ड, कर्मचारी प्रशासन कन्सोल, ही सार्वजनिक साइट आणि ज्ञान आधार, आणि तुमच्या सपोर्ट तिकीट. एकदा साइन इन करा आणि तुम्ही त्या सर्वांमध्ये साइन इन आहात.
हे एक मालकीच्या (प्रोपायटरी) लॉगिनऐवजी खुल्या मानकांवर आधारित असल्यामुळे, प्लॅटफॉर्मचा इतर प्रत्येक घटक ज्याप्रमाणे बदलता येतो, त्याचप्रमाणे याची आयडेंटिटी लेयर देखील बदलता येते. तुमच्या ॲक्सेस मॉडेलचा कोणताही भाग कोणत्याही विक्रेत्याच्या उत्पादनात अडकलेला नाही, आणि तुमच्या टीमची कोणतीही प्रमाणीकरण (ऑथेंटिकेशन) प्रक्रिया एकाच पुरवठादारावर अवलंबून नाही. सीडीएन खाती, डीएनएस आणि पेमेंट प्रदात्यांना आपण जे नो-लॉक-इन तत्व लागू करतो, तेच हे आहे.
साइन-इन स्थानीयकृत केलेले आहे, आणि साइटवरून लॉगिन स्क्रीनवर जाताना तुमची भाषा सोबत जाते — त्यामुळे वेगवेगळ्या देशांमध्ये पसरलेल्या टीमवर केवळ इंग्रजी असलेल्या लॉगिनची सक्ती होत नाही.
चार पद्धती, सर्व प्रथम श्रेणीच्या, सर्व प्रत्येक व्यक्तीनुसार कॉन्फिगर करण्यायोग्य. सर्वात कमजोर पर्याय एकमेव उपलब्ध असल्यामुळे कोणावरही तो लादला जात नाही.
तुमचा ईमेल प्रविष्ट करा, लिंकवर क्लिक करा, आणि तुम्ही आत आहात. फिश करण्यासाठी, पुन्हा वापरण्यासाठी किंवा लीक झालेल्या डेटाबेसमध्ये गळती करण्यासाठी कोणताही पासवर्ड नाही. नवीन खात्यांसाठी हा डीफॉल्ट मार्ग आहे, आणि बहुतेकांसाठी त्यांना कधीही गरज पडणारा हा एकमेव मार्ग आहे.
पासकी नोंदणी करा — टच आयडी, फेस आयडी, विंडोज हलो, किंवा युबीकी (YubiKey) सारखी हार्डवेअर की — आणि पासवर्डशिवाय साइन इन करा. पासकइज ओरिजिनशी जोडलेल्या असतात, त्यामुळे हुबेहूब दिसणाऱ्या बनावट लॉगिन पेजला त्यांची चोरी करता येत नाही. प्लॅटफॉर्म ES256 आणि RS256 ऑथेंटिकेटर्स स्वीकारतो आणि युजर व्हेरिफिकेशनला प्राधान्य देतो.
Google Workspace द्वारे तुमचे खाते आधीपासूनच लागू करत असलेली कोणतीही नियंत्रणे वारसाहक्काने मिळवू शकेल, यासाठी मानक ओळख-प्रदाता (identity-provider) कनेक्शनद्वारे Google सह साइन इन करा. पुढील प्रदाता त्याचप्रमाणे जोडले जातात — त्याबद्दल काहीही कस्टमाइज्ड इंटिग्रेशन नाही.
लोक आणि स्क्रिप्ट्सच्या गरजेनुसार सुरक्षित ठेवले गेले आहे, आणि एका खऱ्या धोरणाचे पालन केले जाते: किमान बारा वर्ण, कधीही तुमचे युजरनेम किंवा ईमेल पत्ता नाही, तुमच्या मागील तीनचा पुनर्वापर नाही, Argon2 सह हॅश केलेले. खाते वापरण्यायोग्य होण्यापूर्वी ईमेल पत्त्यांची पडताळणी केली जाते.
दुसरे घटक हे ओळख प्रणालीचा भाग आहेत, तुम्ही विकत घेतलेले अतिरिक्त साधन किंवा तुम्ही तुमच्या स्वतःच्या साइटवर इन्स्टॉल केलेले प्लगइन नाही.
तुमची संस्था आधीपासूनच ओळख प्रदाता चालवत असेल — Okta, Entra ID, Google Workspace, किंवा SAML ला सपोर्ट करणारे इतर काहीही — तर तुम्ही ते कनेक्ट करू शकता आणि तुमचे लोक त्यांच्या विद्यमान कॉर्पोरेट क्रेडेन्शियल्ससह Zinn Digital® मध्ये साइन इन करू शकतात. तुमच्या टीमला व्यवस्थापित करण्यासाठी दुसरा पासवर्ड नाही आणि विसरण्यासाठी कोणतीही दुसरी ऑफबोर्डिंग चेकलिस्ट नाही.
एजन्सी आणि रिसेलर स्तरावर याला सर्वाधिक महत्त्व असते, जिथे कर्मचाऱ्यांची ये-जा ही सुरक्षेच्या दृष्टीने एक महत्त्वाची घटना असते. जेव्हा एखादी व्यक्ती संस्था सोडते आणि तुम्ही तुमच्या डिरेक्टरीत तिचे खाते निष्क्रीय करता, तेव्हा तुम्ही तिच्या होस्टिंगच्या प्रवेशाचा मार्गही बंद करत असता. डझनभर SaaS साधनांमागे धावण्याऐवजी, प्रवेशाधिकार केंद्रीयरीत्या रोजगाराच्या अधीन राहतात.
SAML हे इतर कोणत्याही गोष्टीची जागा घेत नाही, तर त्याच्यासोबतच काम करते: कंत्राटदारांना अजूनही विशिष्ट मर्यादित भूमिकेमध्ये मॅजिक-लिंक खाते दिले जाऊ शकते, तर कायमस्वरूपी कर्मचारी SSO द्वारे प्रवेश करू शकतात. एक संस्था, एक परवानग्यांचे मॉडेल, दोन प्रवेशद्वारे.
प्रवेश संस्थेच्या झाडावर मर्यादित आहे — पुनर्विक्रेत्यापासून ग्राहकापर्यंत आणि साइटपर्यंत — आणि केवळ ॲप्लिकेशनमध्येच नाही, तर डेटाबेसमध्येच पंक्ती-स्तरीय सुरक्षिततेद्वारे लागू केला जातो. क्रॉस-टेनंट प्रवेश ही लोकांना आदर करण्यास सांगण्याची धोरण नाही; ती अशी क्वेरी आहे जी पंक्ती परत करू शकत नाही. चार ग्राहक भूमिका कर्तव्यांचे वास्तववादी विभाजन साध्य करतात.
संस्थेवर आणि तिच्या सब-अकाउंट्सवर पूर्ण नियंत्रण: चाइल्ड संस्था तयार करा, सदस्यांना आमंत्रित करा आणि काढा, भूमिका नियुक्त करा, प्रत्येक साइट व्यवस्थापित करा, बिलिंग आणि इनव्हॉइसिंग चालवा, API की व्यवस्थापित करा आणि ऑडिट लॉग वाचा.
इन्व्हॉइस, सबस्क्रिप्शन, पेमेंट पद्धती आणि प्लॅन कॅटलॉग — आणि दुसरं काहीही नाही. तुमची वित्त विभागातील व्यक्ती किंवा अकाउंटंट लाईक साईटला स्पर्श न करता, ती सस्पेंड न करता किंवा डिलीट न करता आरामात इन्व्हॉइसची भरपाई करू शकतात.
बिलिंग नियंत्रणाशिवाय साइट्स आणि API प्रवेश: साइट्स पहा आणि प्रोव्हिजन करा, सेवा रीस्टार्ट करा, कॅशे पर्ज करा, API की व्यवस्थापित करा आणि तिकिटांवर काम करा. देय पद्धती, चलन किंवा प्लॅन बदल यामध्ये जाणीवपूर्वक प्रवेश नाही.
संपूर्ण संस्थेसाठी केवळ-पाहण्याची परवानगी — साइट्स, बिलिंग, प्लॅन्स, तिकीट्स, भाषांतर स्थिती आणि ऑडिट लॉग. ऑडिटरसाठी, पाहणी करू इच्छिणाऱ्या क्लायंटसाठी, किंवा पहिल्या आठवड्यात असलेल्या नवीन कर्मचाऱ्यासाठी योग्य भूमिका.
डॅशबोर्ड हा आत जाण्याचा एक मार्ग आहे. एपीआय, सीएलआय, टेराफॉर्म प्रोव्हायडर आणि एमसीपी सर्वहर हे इतर मार्ग आहेत — आणि ते त्याच ॲक्सेस मॉडेल अंतर्गत ठेवले जातात, कारण एक अनस्कोप केलेली की तुम्ही नुकत्याच कॉन्फिगर केलेल्या प्रत्येक भूमिकेचे उल्लंघन (बायपास) करते.
एका संस्थेला API की जारी केली जाते, वैयक्तिक व्यक्तीला नाही, आणि तिचे स्वतःचे स्कोप असतात. ती सामायिक क्रेडेन्शियल सामग्री म्हणून हाताळा: तिच्या उद्देशानुसार तिला नाव द्या, काम करतील असे सर्वात मर्यादित स्कोप द्या आणि ती तयार करणारी व्यक्ती बदलली की ती रोटेट करा.
कच्ची की (key) तुम्हाला केवळ तयार करताना एकदाच दाखवली जाते. आम्ही फक्त SHA-256 हॅश आणि शोधण्यासाठी एक लहान प्रिफिक्स सुरक्षित ठेवतो. आम्ही तुम्हाला ती की पुन्हा दाखवू शकत नाही, आणि डेटाबेसमध्ये छेडछाड झाल्यास आक्रमणकर्त्याच्या हाती कार्यरत क्रेडेन्शियल्स लागणार नाहीत.
प्रत्येक की (key) मध्ये विशिष्ट स्कोप्स असतात जे भूमिका वापरत असलेल्या त्याच परवानग्या कॅटलॉगशी जोडलेले असतात, ती शेवटी कधी वापरली गेली हे नोंदवते आणि संशयास्पद वाटल्यास ती त्वरित रद्द केली जाऊ शकते. स्वतंत्र सँडबॉक्स की (sandbox keys) कोणत्याही वास्तविक बिलिंग किंवा प्रोव्हिजनिंगशिवाय API चा वापर करतात.
MCP सर्व्हर कोणत्याही MCP-सक्षम एजंटला तुमचे होस्टिंग व्यवस्थापित करू देतो — आणि तो OAuth 2.1 द्वारे प्रमाणीकृत होतो, तुमच्या संस्थेसाठी आणि त्याच्या RBAC परवानग्यांसाठी मर्यादित असतो, प्रति-उपकरण रद्द करता येणारे टोकन्स, विनाशात्मक कृतींवर पुष्टीकरण, खर्च मर्यादा आणि संपूर्ण ऑडिट लॉगिंगसह येतो. AI सहाय्यक जोडणे म्हणजे प्रत्येक गोष्टीची चावी त्याला सुपूर्द करणे नाही.
प्रत्येक विशेषाधिकार प्राप्त कृती केवळ-जोड-केली-जाणारी (अपेन्ड-ऑन्ली) नोंद लिहिते — ती कोणी केली, त्यांनी काय केले, ती कशावर केली, त्याचे समर्थन करणारा पुरावा आणि स्त्रोत IP पत्ता, टाइमस्टॅम्पसह. ही डिबॅगिंगची सोय नाही; हा पुराव्याचा मार्ग आहे.
नाही — आणि आमची इच्छा आहे की तुम्ही तसे करू नका. जादूई-लिंक ईमेल साइन-इन हा डीफॉल्ट पर्याय आहे, आणि तुम्ही पासकी (Touch ID, Face ID, Windows Hello किंवा हार्डवेअर की) नोंदणी करू शकता आणि कधीही पासवर्ड सेट न करता साइन इन करू शकता. बॅकअप पर्याय म्हणून ईमेल आणि पासवर्ड उपलब्ध राहतो, ज्यासाठी किमान बारा वर्णांची अट, तुमच्या शेवटच्या तीन पासवर्डचा पुनर्वापर न करणे आणि Argon2 हॅशिंग लागू केले जाते.
TOTP टू-फॅक्टर ओळख स्तरामध्ये समाविष्ट केले आहे आणि ते प्रत्येक सदस्यावर सोडण्याऐवजी धोरणाद्वारे संपूर्ण संस्थेमध्ये लागू केले जाऊ शकते. पासकी हा अधिक मजबूत पर्याय आहे जिथे तुमच्या टीमची उपकरणे त्यांना समर्थन देतात, कारण ते पासवर्ड काढून टाकतात ज्यासाठी आक्रमणकर्ता फिशिंग करत असेल.
होय. बिलिंग मॅनेजर (Billing Manager) ही भूमिका बीजक, वर्गणी, देयक पद्धती आणि प्लॅन कॅटलॉगमध्ये प्रवेश देते, आणि इतर कशातही नाही - साइट पाहण्याची, प्रवाहित करण्याची, रीस्टार्ट करण्याची, निलंबित करण्याची किंवा हटवण्याची कोणतीही क्षमता यात नसते. याउलट, डेव्हलपर (Developer) भूमिका कोणत्याही बिलिंग नियंत्रणाशिवाय साइट आणि API प्रवेश व्यवस्थापित करते. भूमिका प्रति संस्था नियुक्त केल्या जातात, त्यामुळे एका संस्थेमधील भूमिकेमुळे दुसऱ्या, स्वतंत्र संस्थेत प्रवेश मिळत नाही - जरी मूळ (पैरेंट) संस्थेमधील भूमिका तिच्या अंतर्गत असलेल्या संस्थांना लागू होत असली.
डॅशबोर्डवरून ती रद्द करा आणि ती तात्काळ काम करणे थांबवते. नुकसानाची मर्यादा ती की सुरुवातीला काय करू शकत होती यावर अवलंबून असते, म्हणूनच की ला ग्रॅन्युलर स्कोप्स असतात आणि शेवटच्या वापराचा टाइमस्टॅम्प रेकॉर्ड केला जातो — मर्यादित स्कोप्स आणि दृश्यमान वापराचा मार्ग यामुळे लीक झालेल्या डेटाचे रूपांतर संपूर्ण खात्याच्या तडजोडीऐवजी एका नियंत्रित घटनेत होते. कृपया लक्षात घ्या की की व्यक्तीऐवजी संस्थेला जारी केल्या जातात, म्हणून त्यांना सामायिक क्रेडेन्शियल्स म्हणून हाताळा आणि लोक बदलल्यावर ती बदलून घ्या. आमच्या बाजूला केवळ की चा हॅश साठवला जातो, त्यामुळे आमच्या डेटाबेसवरील लीकमुळे कोणतेही कार्यशील क्रेडेन्शियल तयार होत नाही.
होय. प्रत्येक विशेष अधिकाराची कृती, कृती करणारी व्यक्ती, कृती, लक्ष्य, सहाय्यक पुरावा, स्त्रोत आयपी (IP) आणि टाइमस्टॅम्पसह केवळ जोडता येणाऱ्या (append-only) ऑडिट लॉगमध्ये नोंदवली जाते. मालक (Owner) आणि फक्त-वाचनीय (read-only) भूमिका असलेल्या व्यक्ती ते थेट वाचू शकतात. तुमच्या खात्यावरील कर्मचाऱ्यांच्या कृती याच ट्रॅकवर नोंदवल्या जातात आणि संवेदनशील किंवा नुकसानकारक कर्मचाऱ्यांच्या कृतींसाठी आधी स्टेप-अप प्रमाणीकरण किंवा दोन-व्यक्तींच्या मंजुरीची आवश्यकता असू शकते.
होय — एन्टरप्राइज आणि एजन्सी खात्यांसाठी SAML SSO समर्थित आहे, त्यामुळे तुमचे कर्मचारी विद्यमान कॉर्पोरेट क्रेडेन्शियल्ससह प्रमाणीकरण करतात आणि तुमच्या निर्देशिकेतील ऑफबोर्डिंग येथे देखील त्यांचा प्रवेश काढून टाकते. तुम्ही पद्धती एकत्र करू शकता: कायमस्वरूपी कर्मचाऱ्यांसाठी SSO, कंत्राटदारांसाठी मर्यादित मॅजिक-लिंक खाती, हे सर्व एकाच परवानगी मॉडेलमध्ये.
नाही — पासवर्ड जाणीवपूर्वक हस्तांतरित केले जात नाहीत. तुमचे खाते पासवर्डशिवाय आयात केले जाते, आणि पहिल्या साईन-इनवर तुम्ही एकतर मॅजिक-लिंक वापरता किंवा सध्याच्या धोरणांतर्गत नवीन पासवर्ड सेट करता. जुने पासवर्ड हॅश पोर्ट केल्याने जुन्या त्रुटी नवीन यंत्रणेत येऊ शकतात, म्हणून आम्ही ते करत नाही.
Footprint-Free ची चाचणी १४ दिवसांची, कार्डशिवाय आणि पाच साइट्सपर्यंत आहे. चाचणी दरम्यान तुम्हाला संपूर्ण ओळख स्तर मिळतो — पासकी, द्वि-घटक, भूमिका, API की आणि ऑudit लॉग सशुल्क प्लॅनच्या मागे लॉक केलेले नाहीत.
एक पासकी नोंदवा, तुमच्या टीमला योग्य भूमिकांमध्ये आमंत्रित करा आणि एक स्कोप्ड API की जारी करा—हे सर्व कार्ड-फ्री १४-दिवसांच्या चाचणीवर, यासाठी कोणत्याही कार्ड तपशीलांची आवश्यकता नाही.
विनाशुल्क सुरू करा