सुरक्षा

ऑथेंटिकेशन

अकाउंट Supabase Auth द्वारा ईमेल और पासवर्ड, Google OAuth, या GitHub OAuth से मैनेज किए जाते हैं। लॉगिन के बाद, आपका ब्राउज़र एक सेशन टोकन (एक JWT) रखता है जिसे प्लेटफ़ॉर्म मिडलवेयर अपने आप रिफ़्रेश करता है, इसलिए एक चालू सेशन काम के बीच में चुपचाप एक्सपायर नहीं होता।

API उस सेशन टोकन को दो रूपों में स्वीकार करता है: सेशन कुकी के रूप में जो डैशबोर्ड वैसे भी भेजता है, या एक Authorization Bearer हेडर के रूप में। बिना ब्राउज़र लॉगिन के प्रोग्रामेटिक एक्सेस इसके बजाय API key इस्तेमाल करता है, जो नीचे बताई गई है। एंडपॉइंट बिना किसी वैध क्रेडेंशियल के अनुरोधों को अस्वीकार करते हैं; केवल स्पष्ट रूप से पब्लिक रूट, जैसे हेल्थ चेक और कॉन्टैक्ट फ़ॉर्म, बिना ऑथेंटिकेशन के काम करते हैं।

भूमिकाएं और अनुमतियां

हर अकाउंट की ठीक एक भूमिका होती है: CLIENT, OPERATOR, या ADMIN। क्लाइंट रोबोट के मालिक होते हैं और सेशन के लिए भुगतान करते हैं, ऑपरेटर रोबोट चलाते हैं और सेशन से कमाते हैं, और एडमिन प्लेटफ़ॉर्म चलाते हैं। आप ऑनबोर्डिंग के दौरान क्लाइंट और ऑपरेटर के बीच चुनते हैं; एडमिन भूमिका प्लेटफ़ॉर्म एडमिनिस्ट्रेटर द्वारा दी जाती है और खुद नहीं चुनी जा सकती।

भूमिका जांच हर अनुरोध पर सर्वर-साइड होती है, UI में नहीं। API के नीचे, डेटाबेस एक्सेस को row-level security नीतियों से और सीमित किया जाता है, इसलिए किसी एंडपॉइंट में मौजूद कोई बग भी दूसरे अकाउंट की पंक्तियों तक मुफ़्त एक्सेस में नहीं बदलता।

API key

API key स्क्रिप्ट और सर्वर को बिना ब्राउज़र लॉगिन के एक्सेस देती हैं। आप इन्हें /dashboard/settings में बनाते और हटाते हैं; key में ayr_live_ प्रीफ़िक्स होता है और इन्हें एक Authorization Bearer हेडर के रूप में भेजा जाता है। एक key उस अकाउंट की भूमिका और अनुमतियों के साथ काम करती है जिसने इसे बनाया, इसलिए एक लीक हुई key ठीक उतनी ही बुरी है जितना एक लीक हुआ पासवर्ड।

• key को सर्वर-साइड रखें। इन्हें क्लाइंट-साइड JavaScript, मोबाइल ऐप, या पब्लिक रिपॉज़िटरी में नहीं होना चाहिए।
• हर इंटीग्रेशन के लिए एक key इस्तेमाल करें। जब कुछ लीक हो, आप एक कंज़्यूमर हटाना चाहते हैं, सबको नहीं।
• बिना डाउनटाइम के रोटेट करें: पहले बदली हुई key बनाएं, उसे डिप्लॉय करें, फिर /dashboard/settings में पुरानी key हटाएं।
• किसी भी शक पर तुरंत हटा दें। एक नई key बनाना कुछ सेकंड लेता है; एक वैध key वाला हमलावर वह सब कुछ कर सकता है जो आपका अकाउंट कर सकता है।

लाइव कंट्रोल के दौरान सुरक्षा

लाइव कंट्रोल एक session lease से बंधा होता है। एक रोबोट कमांड तभी स्वीकार करता है जब वह ठीक एक ACTIVE सेशन में हो, और केवल उस सेशन को पकड़े ऑपरेटर से; रोबोट खुद बाकी सबके लिए IN_SESSION दिखता है। एक ऑपरेटर एक समय पर अधिकतम एक ACTIVE या PAUSED सेशन रख सकता है, जो एक व्यक्ति को नाममात्र के लिए एक साथ दो आर्म नियंत्रित करने से रोकता है।

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

ऑडिट ट्रेल

हर सेशन एक इवेंट लॉग रखता है: शुरुआत और अंत, रुकना और फिर से शुरू होना, एक्टिविटी चेक, इनएक्टिविटी वॉर्निंग, ऑपरेटर बदलाव, विस्तार के अनुरोध, और एरर, हर एक के साथ एक टाइमस्टैम्प। जब किसी विवाद की समीक्षा होती है, यह इवेंट लॉग मुख्य सबूत होता है, जो एक और वजह है कि प्लेटफ़ॉर्म इसे किसी की याददाश्त पर निर्भर रहने के बजाय अपने आप लिखता है।

सेशन से परे, महत्वपूर्ण प्लेटफ़ॉर्म कार्रवाइयां कार्रवाई करने वाले यूज़र id, कार्रवाई, प्रभावित रिसोर्स, और मेटाडेटा के साथ एक ऑडिट लॉग में दर्ज होती हैं। प्रोफ़ाइल बदलाव, भुगतान-संबंधी लेन-देन, और एडमिन कार्रवाइयां सब एंट्री छोड़ती हैं। ऑडिट रिकॉर्ड प्लेटफ़ॉर्म द्वारा लिखे जाते हैं और किसी भी यूज़र-सामने वाले इंटरफ़ेस से एडिट नहीं किए जा सकते।

एन्क्रिप्शन और डेटा सुरक्षा

प्लेटफ़ॉर्म से आने-जाने वाला सारा ट्रैफ़िक TLS से एन्क्रिप्टेड होता है, जिसमें वीडियो स्ट्रीम और कंट्रोल सिग्नल शामिल हैं। डेटा लेयर पर, row-level security नीतियां प्रति अकाउंट डेटाबेस एक्सेस सीमित करती हैं। भुगतान डेटा सबसे साफ़ सीमा है: कार्ड और बैंक विवरण केवल Stripe संभालता है और कभी AY-Robots सर्वर को नहीं छूते।

किसी कमज़ोरी की रिपोर्ट करना

अगर आपको कोई सुरक्षा समस्या मिले, तो इसे /security पेज या Bug Report श्रेणी का इस्तेमाल करते हुए /contact फ़ॉर्म से ज़िम्मेदारी से रिपोर्ट करें। बताएं कि आपने क्या पाया, कहां, और इसे कैसे दोबारा दिखाया जाए; समस्या दिखाने के लिए ज़रूरी न्यूनतम से ज़्यादा दूसरे यूज़र के डेटा तक न पहुंचें, और हमें इसे ठीक करने का उचित मौका मिलने से पहले विवरण प्रकाशित न करें। हम हर रिपोर्ट पढ़ते हैं।

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