TYO Reach पर सुरक्षा
सुरक्षा Reach के काम की नींव है — आप अपने ट्रैफ़िक को हमारे इंफ्रास्ट्रक्चर के माध्यम से रूट कर रहे हैं, इसलिए आपको यह जानने का पूरा अधिकार है कि इसे कैसे संभाला जाता है।
आपका ट्रैफ़िक Reach के माध्यम से कैसे चलता है
डेटा पथ को समझना आपको यह मूल्यांकन करने में मदद करता है कि हम क्या देख सकते हैं और क्या नहीं — और डिज़ाइन ऐसा क्यों है।
जब Reach सक्रिय होता है, तो क्लाइंट ऐप एक छोटा लोकल प्रॉक्सी (HTTP CONNECT और SOCKS5 सपोर्ट के साथ) चलाता है, जिससे आपका ब्राउज़र कनेक्ट होता है। HTTPS के लिए, जब आपका ब्राउज़र कनेक्शन खोलता है, तो लोकल प्रॉक्सी "200 Connection Established" लौटाता है और फिर कच्चे, अभी भी एन्क्रिप्टेड बाइट्स को आपके चुने हुए क्षेत्र में मैनेज्ड क्लाउड इन्फ्रास्ट्रक्चर पर चल रहे TYO Reach के गेटवे तक एक प्रमाणित टनल के ज़रिए आगे भेज देता है; गेटवे उन्हीं बाइट्स को डेस्टिनेशन सर्वर तक अग्रेषित करता है। आपके ब्राउज़र का मूल TLS सत्र इस टनल के ज़रिए डेस्टिनेशन साइट तक एंड-टू-एंड चलता है — Reach एक एंडपॉइंट नहीं, बल्कि सिर्फ़ एक पाइप है। यह कभी भी प्लेनटेक्स्ट नहीं देखता, कभी भी विकल्प प्रमाणपत्र नहीं बनाता या प्रस्तुत नहीं करता, और आपके डिवाइस पर कोई रूट CA इंस्टॉल नहीं करता। डेस्टिनेशन को गेटवे का IP पता दिखाई देता है, न कि आपका।
जिसे प्रमाणित किया जाता है वह आपका ट्रैफ़िक नहीं, बल्कि खुद टनल है: गेटवे के साथ टनल खोलते समय क्लाइंट एक X-Reach-Key हेडर भेजता है, ताकि गेटवे यह पहचान सके कि यह किस खाते का है और आपके डेटा भत्ते को लागू कर सके। नीति प्रवर्तन (कौन से डोमेन किस गेटवे के माध्यम से बाहर निकलते हैं) और मीटरिंग कनेक्शन मेटाडेटा — वह डेस्टिनेशन होस्ट जिससे कनेक्ट करने के लिए आपका ब्राउज़र प्रॉक्सी से अनुरोध करता है, और बाइट काउंट — के आधार पर लागू होते हैं, डिक्रिप्ट की गई सामग्री कभी पढ़कर नहीं।
हम क्या लॉग करते हैं — और हम जानबूझकर क्या नहीं करते हैं
Reach मापता है कि आप कितना डेटा उपयोग करते हैं। डिफ़ॉल्ट रूप से यह रिकॉर्ड नहीं करता कि आप इसके साथ क्या करते हैं — एक वैकल्पिक कनेक्शन लॉग, जो तब तक बंद रहता है जब तक आप या आपका संगठन इसे सक्षम नहीं करते, एकमात्र अपवाद है।
डिफ़ॉल्ट रूप से हम क्या लॉग करते हैं
हम बिलिंग अवधि के प्रति आपके खाते के माध्यम से स्थानांतरित डेटा (बाइट्स) की कुल मात्रा रिकॉर्ड करते हैं। आपके मासिक डेटा भत्ते को लागू करने के लिए केवल यही जानकारी आवश्यक है, और जब तक आप वैकल्पिक कनेक्शन लॉग चालू नहीं करते, तब तक हम केवल यही लॉग करते हैं।
हम क्या लॉग नहीं करते हैं
हम URL पथ, क्वेरी स्ट्रिंग, खोज शब्द, या पेज सामग्री कभी लॉग नहीं करते हैं। जब तक आप (या आपका संगठन) वैकल्पिक कनेक्शन लॉग चालू नहीं करते, तब तक हम आपके द्वारा देखी गई डोमेन का कोई इतिहास रिकॉर्ड नहीं करते हैं, और तब भी केवल होस्ट नाम और कनेक्शन समय संग्रहीत किया जाता है, कभी पथ या सामग्री नहीं। हम ब्राउज़िंग प्रोफ़ाइल नहीं बनाते हैं या विज्ञापनदाताओं या एनालिटिक्स प्रदाताओं के साथ ट्रैफ़िक डेटा साझा नहीं करते हैं।
वैकल्पिक कनेक्शन लॉग और रिटेंशन
बाइट-काउंट मीटरिंग डेटा आपकी वर्तमान बिलिंग अवधि के लिए रखा जाता है और विवाद समाधान के लिए एक छोटा टेल होता है। वैकल्पिक कनेक्शन (एक्सेस) लॉग डिफ़ॉल्ट रूप से बंद रहता है; जब आप या आपका संगठन इसे सक्षम करते हैं, तो कनेक्शन-स्तरीय मेटाडेटा (होस्ट, समय, अवधि) को अधिकतम 30 दिनों के लिए रखा जाता है और फिर हटा दिया जाता है। सभी लॉग सिडनी क्षेत्र में Google Cloud में संग्रहीत किए जाते हैं।
TYO ID द्वारा समर्थित पहचान
TYO Reach के लिए प्रमाणीकरण id.tyo.com.au द्वारा संभाला जाता है — TYO की अपनी पहचान सेवा — न कि किसी तीसरे पक्ष के प्लेटफ़ॉर्म द्वारा जिसे हम नियंत्रित नहीं करते हैं।
ऑस्ट्रेलियन-होस्टेड पहचान
TYO ID ऑस्ट्रेलिया में Google Cloud पर चलता है। आपके खाते के क्रेडेंशियल कभी भी US या EU पहचान प्लेटफ़ॉर्म से नहीं गुजरते हैं। साइन-इन फ़्लो अल्पकालिक सत्र टोकन के साथ OAuth 2.0 का उपयोग करते हैं — दीर्घकालिक क्रेडेंशियल कभी भी क्लाइंट ऐप में संग्रहीत नहीं किए जाते हैं।
MFA और TOTP
मल्टी-फैक्टर प्रमाणीकरण TOTP (समय-आधारित वन-टाइम पासवर्ड — किसी भी RFC 6238 ऑथेंटिकेटर ऐप के साथ संगत) के माध्यम से उपलब्ध है। टीम एडमिन सभी ग्रुप सदस्यों के लिए MFA की आवश्यकता रख सकते हैं; उपयोगकर्ता ग्रुप-लागू MFA नीति से बाहर नहीं निकल सकते हैं।
Google और Microsoft साइन-इन
टीमें Google या Microsoft के साथ साइन इन कर सकती हैं। एंटरप्राइज़ Azure AD / OIDC डायरेक्टरी फेडरेशन उन संगठनों के लिए अनुरोध पर उपलब्ध है जिन्हें इसकी आवश्यकता है।
गेटवे कैसे बनाया और संचालित किया जाता है
गेटवे प्रबंधित सर्वरलेस इंफ्रास्ट्रक्चर पर चलता है — कोई स्थायी वर्चुअल मशीन नहीं, कोई SSH पहुँच नहीं, वातावरण में कोई दीर्घकालिक रहस्य नहीं।
Google Cloud Run
Reach प्रॉक्सी गेटवे Cloud Run पर चलता है — Google का प्रबंधित सर्वरलेस कंटेनर प्लेटफ़ॉर्म। Cloud Run स्वचालित रूप से स्केल करता है, Google की अंतर्निहित इंफ्रास्ट्रक्चर सुरक्षा लागू करता है, और इसका मतलब है कि हमारे लिए पैच करने या तैनाती के बीच हमलावर के बने रहने के लिए कोई स्थायी VM नहीं है।
प्रोडक्शन तक कोई SSH पहुँच नहीं
चल रहे गेटवे तक कोई SSH या शेल पहुँच नहीं है। सभी तैनाती Google Cloud के तैनाती पाइपलाइन के माध्यम से जाती है। रोलबैक तैनाती के माध्यम से किए जाते हैं, न कि कंसोल पहुँच के माध्यम से।
GCP Secret Manager
संवेदनशील क्रेडेंशियल — API कुंजियाँ, सेवा टोकन, डेटाबेस कनेक्शन स्ट्रिंग — GCP Secret Manager में संग्रहीत किए जाते हैं, न कि पर्यावरण चर फ़ाइलों या कोड में। गेटवे एक प्रमाणित आंतरिक API पर स्टार्टअप के समय रहस्य प्राप्त करता है।
स्वचालित प्लेटफ़ॉर्म पैचिंग
Cloud Run OS और रनटाइम पैचिंग को स्वचालित रूप से संभालता है। हम एप्लिकेशन लेयर बनाए रखते हैं; Google प्लेटफ़ॉर्म बनाए रखता है। कोई अनपैच्ड-VM सतह नहीं है।
सुरक्षा भेद्यता मिली?
यदि आपको TYO Reach में कोई समस्या मिली है, तो हम सार्वजनिक रूप से प्रकट होने से पहले इसके बारे में सुनना चाहते हैं।
समस्या का विवरण [email protected] पर भेजें। कृपया शामिल करें:
- भेद्यता और उसके संभावित प्रभाव का स्पष्ट विवरण।
- पुनरुत्पादन के चरण (प्रूफ ऑफ कॉन्सेप्ट हमें तेजी से ट्राइएज करने में मदद करता है)।
- स्क्रीनशॉट, लॉग, या कोई सहायक साक्ष्य।
हम एक व्यावसायिक दिन के भीतर सभी सुरक्षा रिपोर्टों को स्वीकार करने और समस्या की पुष्टि करने के तीन व्यावसायिक दिनों के भीतर समाधान समयरेखा प्रदान करने का लक्ष्य रखते हैं। कृपया किसी भी सार्वजनिक प्रकटीकरण से पहले समस्या को ठीक करने के लिए हमें उचित समय दें।
हम आपसे अनुरोध करते हैं कि आप:
- अन्य उपयोगकर्ताओं के डेटा तक न पहुँचें और न ही उसे संशोधित करें।
- प्रोडक्शन सिस्टम के खिलाफ डिनायल-ऑफ-सर्विस परीक्षण न करें।
- सद्भावना में कार्य करें।
हम वर्तमान में कोई सशुल्क बग बाउंटी प्रोग्राम नहीं चलाते हैं, लेकिन हम उनकी अनुमति से रिलीज़ नोट्स में शोधकर्ताओं को स्वीकार करेंगे।
क्या Reach मेरे पासवर्ड देख सकता है?
नहीं। यदि आप HTTPS पर किसी साइट पर लॉगिन कर रहे हैं — जिसका उपयोग लगभग सभी लॉगिन पेज करते हैं — तो आपका TLS सत्र Reach के टनल के ज़रिए आपके ब्राउज़र और डेस्टिनेशन साइट के बीच एंड-टू-एंड चलता है; Reach केवल एन्क्रिप्टेड बाइट्स को आगे भेजता है और उन्हें कभी डिक्रिप्ट नहीं करता। यह संरचनात्मक रूप से लॉगिन फ़ॉर्म की सामग्री, जिसमें आपका पासवर्ड भी शामिल है, देखने में असमर्थ है। सामान्य नियम: किसी भी नेटवर्क पर एन्क्रिप्टेड HTTP पर क्रेडेंशियल भेजने से बचें।
क्या Reach मेरी HTTPS ब्राउज़िंग सामग्री पढ़ सकता है?
HTTPS के लिए — यानी लगभग सभी आधुनिक वेब ब्राउज़िंग — नहीं। Reach HTTPS ट्रैफ़िक को न तो इंटरसेप्ट करता है और न ही डिक्रिप्ट करता है — यह केवल आपके पहले से एन्क्रिप्टेड ट्रैफ़िक को एक टनल के ज़रिए आगे भेजता है, और आपका TLS सत्र डेस्टिनेशन साइट तक एंड-टू-एंड पहुंचता है। गेटवे को डेस्टिनेशन होस्ट नाम (जैसे example.com) केवल इसलिए पता चलता है क्योंकि आपका ब्राउज़र प्रॉक्सी को बताता है कि कहां कनेक्ट करना है (स्टैंडर्ड CONNECT डेस्टिनेशन), एन्क्रिप्टेड हैंडशेक के भीतर कुछ भी विश्लेषित करके नहीं — और यह URL पथ, क्वेरी स्ट्रिंग, या पेज सामग्री कभी नहीं देखता। यह HTTPS के लिए टनल डिज़ाइन की एक संरचनात्मक गारंटी है, केवल एक लॉगिंग नीति नहीं। डिफ़ॉल्ट रूप से हम होस्ट नाम बिल्कुल भी लॉग नहीं करते हैं; वे केवल तभी रिकॉर्ड किए जाते हैं जब आप या आपका संगठन वैकल्पिक कनेक्शन लॉग सक्षम करते हैं (केवल होस्ट नाम और कनेक्शन समय, 30 दिनों के लिए रखा गया)। इंटरनेट पर अभी भी मौजूद एन्क्रिप्टेड HTTP ट्रैफ़िक के छोटे अल्पसंख्यक के लिए, यह संरचनात्मक गारंटी लागू नहीं होती — लोकल प्रॉक्सी तकनीकी रूप से अनुरोध को पढ़ने में सक्षम है, ठीक किसी भी प्लेनटेक्स्ट फ़ॉरवर्ड प्रॉक्सी की तरह, लेकिन हम इसकी सामग्री का निरीक्षण या भंडारण नहीं करते हैं।
मेरा डेटा कहाँ संग्रहीत है?
खाता डेटा, मीटरिंग रिकॉर्ड, और कोई भी लॉग सिडनी क्षेत्र में Google Cloud में संग्रहीत किए जाते हैं। हम Google के मानक इंफ्रास्ट्रक्चर संचालन के लिए आवश्यक होने के अलावा ऑस्ट्रेलिया के बाहर के अधिकार क्षेत्रों में व्यक्तिगत डेटा को प्रतिकृति नहीं करते हैं। पूर्ण विवरण के लिए हमारी गोपनीयता नीति देखें।
मैं भेद्यता की रिपोर्ट कैसे करूँ?
समस्या का विवरण, पुनरुत्पादन के चरण, और किसी भी सहायक सामग्री के साथ [email protected] पर ईमेल करें। हम एक व्यावसायिक दिन के भीतर सभी रिपोर्टों को स्वीकार करने का लक्ष्य रखते हैं। कृपया सार्वजनिक प्रकटीकरण से पहले समस्या को हल करने के लिए हमें समय दें।