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