सुरक्षा

यह पृष्ठ उन सुरक्षा उपायों का वर्णन करता है जो आज वास्तव में Astrina.io पर लागू हैं। यह जानबूझकर विशिष्ट है, और यह जानबूझकर अधूरा है: जहां हमारे पास कुछ नहीं है, हम ऐसा कहते हैं बजाय इसके कि अन्यथा संकेत करें। यदि इस पृष्ठ पर कोई सुरक्षा नियंत्रण सूचीबद्ध नहीं है, तो मान लें कि हमारे पास यह नहीं है।

जहां आपका डेटा संग्रहीत है

Astrina एक ही सर्वर पर चलती है जो EU में OVH के साथ होस्ट किया गया है। सर्वर को Hestia नियंत्रण पैनल के साथ प्रबंधित किया जाता है, और डेटाबेस (MariaDB/MySQL) उसी सर्वर पर चलता है। Cloudflare इसके सामने DNS, CDN, TLS समाप्ति और WAF के लिए बैठता है।

हमारे पक्ष में डेटा संसाधित करने वाले तीसरे पक्ष की पूरी सूची Subprocessors पृष्ठ पर है। हम क्या एकत्र करते हैं और इसे कितनी देर तक रखते हैं, यह Privacy Policy और Data Retention पृष्ठ में निर्धारित है।

संक्रमण में एन्क्रिप्शन

Astrina.io के लिए और उससे सभी ट्रैफ़िक TLS के माध्यम से परोसा जाता है। Cloudflare को पूर्ण (कठोर) मोड में कॉन्फ़िगर किया गया है, जिसका अर्थ है कि Cloudflare और हमारे मूल सर्वर के बीच का कनेक्शन भी एन्क्रिप्टेड है और मूल प्रमाणपत्र को मान्य किया गया है। मूल प्रमाणपत्र Let's Encrypt द्वारा जारी किया गया है।

पासवर्ड

पासवर्ड केवल एक हैश के रूप में संग्रहीत होते हैं, जो PHP password_hash() द्वारा bcrypt (PASSWORD_DEFAULT) का उपयोग करके उत्पन्न होता है, और password_verify() के साथ जांचा जाता है।
हम कभी भी आपका पासवर्ड स्पष्ट पाठ में नहीं रखते हैं, और हम इसे कभी भी लॉग में नहीं लिखते हैं। Astrina में कोई भी आपके पासवर्ड को नहीं पढ़ सकता या आपको यह नहीं बता सकता कि यह क्या है।
ईमेल सत्यापन और पासवर्ड रीसेट टोकन को टोकन के SHA-256 हैश के रूप में संग्रहीत किया जाता है, ये एकल-उपयोग होते हैं, और समाप्त हो जाते हैं।
जहां पासवर्ड को ज्ञात उल्लंघन सूचियों के खिलाफ जांचा जाता है, हम Pwned Passwords k-anonymity विधि का उपयोग करते हैं: केवल पासवर्ड के SHA-1 हैश के पहले पांच अक्षर भेजे जाते हैं। पासवर्ड स्वयं कभी भी ब्राउज़र या हमारे सर्वर से बाहर नहीं जाता।

Astrina खातों पर कोई दो-कारक प्रमाणीकरण नहीं है। नीचे "हमारे पास अभी क्या नहीं है" देखें।

सत्र और फ़ॉर्म

सत्र कुकी का नाम astrsess है। इसे HttpOnly (JavaScript इसे नहीं पढ़ सकता), Secure (यह केवल HTTPS के माध्यम से भेजा जाता है) और SameSite=Lax पर सेट किया गया है।
राज्य-परिवर्तन फ़ॉर्म सबमिशन में एक CSRF टोकन होता है, इसलिए कोई अन्य साइट आपके ब्राउज़र को आपके खाते में कोई क्रिया करने के लिए मजबूर नहीं कर सकती।

API कुंजी

आपकी API कुंजी केवल एक अनुरोध हेडर में स्वीकार की जाती है — X-Api-Key, या Authorization: Bearer। हम जानबूझकर URL क्वेरी स्ट्रिंग में कुंजी स्वीकार नहीं करते।
यह चयन महत्वपूर्ण है: URL में रखी गई कुंजी आमतौर पर सर्वर एक्सेस लॉग, प्रॉक्सी लॉग, ब्राउज़र इतिहास और अन्य साइटों को भेजे गए Referer हेडर में समाप्त हो जाती है। हेडर में एक कुंजी ऐसा नहीं करती।
आप कभी भी /my/api.php से अपनी कुंजी को फिर से उत्पन्न कर सकते हैं। पुन: उत्पन्न करने से पुरानी कुंजी तुरंत रद्द हो जाती है।
प्रत्येक योजना में एक दैनिक कॉल कोटा होता है। एक बार जब यह समाप्त हो जाता है, तो API HTTP 429 लौटाता है बजाय इसके कि अनुरोधों को सेवा देना जारी रखे।

क्रॉस-ओरिजिन एक्सेस (CORS)

हमारी सार्वजनिक API विधियाँ जानबूझकर किसी भी मूल के लिए खुली हैं (Access-Control-Allow-Origin: *), क्योंकि वे सार्वजनिक कैटलॉग डेटा प्रदान करती हैं। निजी एनालिटिक्स विधि, /api/v1/stats, बिल्कुल भी Allow-Origin हेडर नहीं भेजती — इसलिए किसी अन्य साइट पर एक वेब पृष्ठ एक आगंतुक के ब्राउज़र का उपयोग करके आपकी सांख्यिकी नहीं पढ़ सकता, भले ही उसके पास किसी तरह आपकी कुंजी हो।

SEO क्रॉलर हार्डनिंग

हमारा SEO क्रॉलर उन URLs को लाता है जो ग्राहक प्रदान करते हैं, जो कि आंतरिक सिस्टम (SSRF) तक पहुँचने के लिए दुरुपयोग की जाने वाली विशेषता है। इसे इसके खिलाफ मजबूत किया गया है:

केवल http और https URLs स्वीकार किए जाते हैं।
निजी, लूपबैक और लिंक-स्थानीय IP रेंज को अस्वीकार कर दिया गया है।
हल किया गया IP पता पिन किया गया है, इसलिए होस्टनाम जांच और अनुरोध के बीच कुछ अलग नहीं हो सकता।
हर रीडायरेक्ट हॉप को समान नियमों के खिलाफ फिर से मान्य किया जाता है, केवल पहले URL के खिलाफ नहीं।
प्रतिक्रिया शरीर का आकार सीमित है।

सत्र रिकॉर्डिंग डिफ़ॉल्ट रूप से मास्क की गई है

यदि आप वैकल्पिक सत्र रिकॉर्डर सक्षम करते हैं, तो मास्किंग डिफ़ॉल्ट रूप से चालू है और आगंतुक के ब्राउज़र में लागू की जाती है — इससे पहले कि कुछ भी हमें भेजा जाए:

पासवर्ड, ईमेल और टेलीफोन इनपुट फ़ील्ड कभी भी कोई मान नहीं भेजते। न तो पाठ, न ही इसका मास्क किया गया संस्करण, न ही इसकी लंबाई।
भुगतान-कार्ड फ़ील्ड को भी इसी तरह से संभाला जाता है।
किसी अन्य इनपुट में टाइप किया गया टेक्स्ट बुलेट्स में छिपा दिया जाता है।
आपके पृष्ठ का कोई भी भाग जिसे आप [data-astr-mask] विशेषता के साथ चिह्नित करते हैं, वह ब्राउज़र छोड़ने से पहले छिपा दिया जाता है।

रिकॉर्डिंग डिफ़ॉल्ट रूप से 30 दिनों के लिए रखी जाती हैं। रखरखाव अवधि को कॉन्फ़िगर किया जा सकता है।

समीक्षाओं पर साक्ष्य फ़ाइलें

कुछ समीक्षा प्रकारों के लिए साक्ष्य के रूप में संलग्न छवियाँ और वीडियो वेब रूट के बाहर संग्रहीत होते हैं, इसलिए इन्हें URL का अनुमान लगाकर प्राप्त नहीं किया जा सकता। इन्हें केवल एक गेटेड एंडपॉइंट के माध्यम से प्रदान किया जाता है, जो 403 लौटाता है जब तक कि समीक्षा को मंजूरी नहीं दी गई है, या आप समीक्षा के लेखक नहीं हैं, या आप एक व्यवस्थापक नहीं हैं।

दुरुपयोग और बॉट नियंत्रण

समीक्षा प्रस्तुतियाँ प्रति IP पते पर दर-सीमित होती हैं, और समीक्षाएँ मॉडरेट की जाती हैं। मेहमानों से समीक्षाएँ केवल मॉडरेशन के बाद प्रकाशित होती हैं; साइन-इन सदस्यों से समीक्षाएँ तुरंत प्रकाशित होती हैं।
एनालिटिक्स ट्रैफ़िक को बॉट्स के लिए उपयोगकर्ता-एजेंट नियमों का उपयोग करके फ़िल्टर किया जाता है, साथ ही डेटा सेंटर और होस्टिंग IP वर्गीकरण को रिवर्स DNS के माध्यम से।

व्यवस्थापक पहुंच

व्यवस्थापक क्षेत्र एक भूमिका जांच द्वारा गेटेड है। प्रशासनिक खाते अन्य सभी की तरह ही लॉगिन तंत्र का उपयोग करते हैं, जिसका अर्थ है कि वे भी दो-कारक प्रमाणीकरण द्वारा सुरक्षित नहीं हैं।

हम जो ईमेल भेजते हैं

आउटबाउंड ईमेल (noreply@astrina.io से) हमारे अपने Exim मेल सर्वर द्वारा DKIM कॉन्फ़िगर के साथ भेजा जाता है, ताकि प्राप्तकर्ता यह सत्यापित कर सकें कि संदेश वास्तव में हमसे आया है। हम आपका पता किसी तीसरे पक्ष के मेल प्रदाता को नहीं देते।

बैकअप और सेवा को पुनर्स्थापित करना

Hestia लगभग 05:12 UTC पर फ़ाइलों और डेटाबेस का एक दैनिक बैकअप लेती है।

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

यदि सेवा को पुनर्स्थापित करने की आवश्यकता है, तो हम सबसे हालिया दैनिक बैकअप से पुनर्स्थापित करते हैं। हम पुनर्प्राप्ति समय उद्देश्य (RTO) या पुनर्प्राप्ति बिंदु उद्देश्य (RPO) की गारंटी नहीं देते हैं, और हम सार्वजनिक सेवा स्तर समझौता नहीं प्रदान करते हैं। एक SLA केवल तभी मौजूद है जब इसे एक व्यक्तिगत अनुबंध में अलग से सहमति दी गई हो।

हमारे पास अभी क्या नहीं है

हम आपको यह स्पष्ट रूप से बताना चाहेंगे बजाय इसके कि एक सुरक्षा पृष्ठ को ऐसा संकेत देने दें जो उसे नहीं देना चाहिए। Astrina के पास वर्तमान में नहीं है:

कोई दो-कारक प्रमाणीकरण (2FA) नहीं है, और Astrina पैनल के लिए कोई SSO नहीं है।
कोई तीसरे पक्ष का सुरक्षा ऑडिट और कोई पैठ परीक्षण नहीं है। कोई भी नहीं किया गया है, इसलिए प्रकाशित करने के लिए कोई परिणाम नहीं हैं।
कोई ISO 27001, SOC 2 या कोई अन्य प्रमाणन नहीं है। हम किसी मानक के खिलाफ प्रमाणित या ऑडिट नहीं हैं।
कोई ऑफ-साइट बैकअप नहीं। ऊपर बैकअप अनुभाग देखें।
कोई बग-बाउंटी कार्यक्रम नहीं है। हम रिपोर्ट स्वीकार करते हैं, लेकिन हम इसके लिए भुगतान नहीं कर सकते।
कोई औपचारिक सेवा स्तर समझौता नहीं है और न ही कोई प्रकाशित अपटाइम गारंटी है।

यदि इनमें से कोई भी आपके लिए आवश्यक है, तो वे आज अनुपस्थित हैं, और आपको तदनुसार निर्णय लेना चाहिए।