यह सुरक्षा अवलोकन उन तकनीकी और संगठनात्मक उपायों का वर्णन करता है जो Melaya, Inc. ("Melaya") वर्तमान में Melaya प्लेटफ़ॉर्म की गोपनीयता, अखंडता, और उपलब्धता की रक्षा के लिए लागू करता है। इसका उद्देश्य संभावित और मौजूदा उपयोगकर्ताओं, उद्यम खरीदारों, और ऑडिटरों को आज उत्पादन में क्या है, क्या प्रगति में है, और क्या अभी तक लागू नहीं किया गया है, इसकी ईमानदार तस्वीर देना है। जहां कोई क्षमता आकांक्षात्मक या प्रगति में है, उसे अस्पष्ट भाषा के पीछे छिपाने के बजाय स्पष्ट रूप से ऐसे चिह्नित किया जाता है। सुरक्षा एक साझा जिम्मेदारी है: Melaya प्लेटफ़ॉर्म की सुरक्षा के लिए जिम्मेदार है, और ग्राहक उस पर बनाई, अपलोड की, और निष्पादित की गई चीजों की सुरक्षा के लिए जिम्मेदार हैं।

1. पारगमन और विश्राम में एन्क्रिप्शन

उपयोगकर्ता क्लाइंट और सेवाओं के बीच पारगमन में सभी डेटा Transport Layer Security (TLS) संस्करण 1.2 या उच्चतर द्वारा सुरक्षित है, जो तैनाती के किनारे पर Cloudflare पर समाप्त होता है। उत्पादन TLS प्रोफ़ाइल Mozilla Intermediate compatibility guide का पालन करती है: केवल TLS 1.2 और 1.3, केवल ECDHE cipher suites, दो-वर्ष max-age और preload निर्देश के साथ HSTS, और एक स्पष्ट connect-src अनुमति-सूची के साथ सख्त Content Security Policy। पूर्ण प्रोफ़ाइल, प्रतिबद्ध cipher सूची, और त्रैमासिक समीक्षा कैडेंस आंतरिक सुरक्षा vault में TLS Baseline runbook में प्रलेखित हैं और server/src/index.ts में helmet middleware द्वारा लागू हैं। हमारी आधारभूत संरचना के भीतर आंतरिक सेवा-से-सेवा कॉल loopback या निजी नेटवर्क लिंक पर चलती हैं।

प्राथमिक Postgres डेटाबेस और ऑब्जेक्ट स्टोरेज में विश्राम पर डेटा होस्टिंग प्रदाता द्वारा प्रदान की गई सममित एन्क्रिप्शन का उपयोग करके एन्क्रिप्ट किया गया है, जिसमें कुंजियां प्रदाता की key management service द्वारा प्रबंधित की जाती हैं। यह कच्ची डिस्क चोरी के खिलाफ रक्षा प्रदान करता है लेकिन स्वयं से एप्लिकेशन या प्रदाता समझौते के खिलाफ बचाव नहीं करता।

प्रदाता की डिस्क-स्तरीय एन्क्रिप्शन के ऊपर, संवेदनशील मानों को server/src/services/envelope.ts में कार्यान्वित एप्लिकेशन-स्तरीय envelope encryption परत द्वारा अतिरिक्त रूप से सुरक्षित किया जाता है। एक्सचेंज API क्रेडेंशियल (कुंजी, गुप्त, पासफ्रेज़) को Infisical vault प्रदाता को भेजे जाने या agents.credentials फ़ॉलबैक तालिका में लिखे जाने से पहले केवल सर्वर के परिवेश में रखी गई 256-बिट मास्टर कुंजी का उपयोग करके AES-256-GCM के साथ लपेटा जाता है। वायर प्रारूप एक स्पष्ट key identifier (v1:<kid>:<base64(iv|ciphertext|tag)>) वहन करता है ताकि सर्वर रोटेशन विंडो के दौरान कई वैध कुंजियां स्वीकार कर सके और प्रत्येक मान को लपेटने वाली सटीक कुंजी पर पढ़ने को रूट कर सके। नए राइट हमेशा सक्रिय कुंजी का उपयोग करते हैं, जो कॉन्फ़िगर की गई कुंजी सूची में पहली प्रविष्टि है। रोटेशन एक तीन-रिलीज प्रक्रिया है जो प्लेटफ़ॉर्म को कभी डाउन नहीं करती: नई कुंजी को दूसरी प्रविष्टि के रूप में जोड़ें (राइट अभी भी पुरानी कुंजी पर जाते हैं, नई कुंजी केवल-पठन है), इसे पहले स्थान पर प्रमोट करें (राइट नई कुंजी पर फ्लिप करते हैं, पुरानी कुंजी पठनीय रहती है), रिटायर kid से बाउंड किसी भी ऐतिहासिक पंक्ति को फिर से लपेटें, फिर पुरानी प्रविष्टि छोड़ें। न तो Infisical न ही Postgres होस्ट किसी भी बिंदु पर सादा-पाठ क्रेडेंशियल देखते हैं: किसी भी अकेले उप-प्रोसेसर का समझौता केवल सिफरटेक्स्ट उत्पन्न करता है, और हमलावर को किसी भी एक्सचेंज कुंजी को पुनर्प्राप्त करने के लिए अतिरिक्त रूप से एक कॉन्फ़िगर envelope कुंजी की आवश्यकता है। server/src/scripts/migrate-envelope-wrap.ts पर एक one-shot माइग्रेशन स्क्रिप्ट ने envelope परत से पहले के अवशिष्ट legacy सादा-पाठ पंक्तियों को संभाला; स्वीप उत्पादन डेटाबेस के खिलाफ पूरी हुई और इसके round-trip verifier (envelope-verify.ts, 7/7 परिदृश्य) हर CI रन और लाइव प्रोडक्शन के खिलाफ शून्य पर बाहर निकलते हैं।

2. टेनेंट और पाइपलाइन पृथक्करण

प्लेटफ़ॉर्म एप्लिकेशन परत पर टेनेंटों के बीच तार्किक पृथक्करण लागू करता है। प्रत्येक प्रमाणित अनुरोध एक validated JSON Web Token से प्राप्त उपयोगकर्ता पहचानकर्ता वहन करता है, और प्रत्येक डेटाबेस क्वेरी, ऑब्जेक्ट स्टोर एक्सेस, और पुनर्प्राप्ति सूचकांक लुकअप parameterized SQL और tRPC context plumbing के माध्यम से उस पहचानकर्ता द्वारा स्कोप किया जाता है। एजेंटिक Framework के लिए बनाए गए पुनर्प्राप्ति सूचकांक प्रति-पाइपलाइन संग्रहीत किए जाते हैं और केवल उन क्वेरी को वापस किए जाते हैं जो उस पाइपलाइन से उत्पन्न होती हैं जो उनका स्वामित्व रखती है। इंजन स्थिति, रणनीति कॉन्फ़िगरेशन, और आदेश इतिहास समान रूप से उपयोगकर्ता द्वारा विभाजित हैं। Postgres row-level security एप्लिकेशन-परत स्कोपिंग के पीछे एक defense-in-depth परत के रूप में लागू की जाती है: FORCE ROW LEVEL SECURITY agents.mfa_challenge, agents.credentials, और agents.users पर उत्पादन में सक्रिय है, और एप्लिकेशन एक कम-विशेषाधिकार भूमिका (melaya_app, rolbypassrls=false) के तहत जुड़ता है जो टेनेंटों के पार नहीं देख सकता, भले ही कोई क्वेरी गलती से अपना WHERE user_id क्लॉज़ भूल जाए। server/src/scripts/rls-verify.ts में सत्रह क्रॉस-टेनेंट परिदृश्य SELECT, INSERT, UPDATE, DELETE, ownership-reassignment, admin bypass, no-context zero-row, और GUC-leak regression मामलों सहित हर CI रन पर लाइव डेटाबेस के खिलाफ शून्य पर बाहर निकलते हैं।

3. कुंजी और गोपनीयता प्रबंधन

Melaya द्वारा स्वयं उपयोग किए जाने वाले एप्लिकेशन गोपनीयता, signing keys, डेटाबेस क्रेडेंशियल, और तृतीय-पक्ष API कुंजियां प्रक्रिया प्रारंभ पर लोड किए गए परिवेश चर और हमारे vault प्रदाता में संग्रहीत हैं। उन्हें कभी भी स्रोत नियंत्रण में commit नहीं किया जाता और उत्पादन मान डेवलपर्स के बीच साझा नहीं किए जाते। MEL_ENVELOPE_KEY Postgres डेटाबेस क्रेडेंशियल से अलग और Infisical टोकन से अलग रखा जाता है, इसलिए तीनों में से किसी एक का समझौता सादा-पाठ एक्सचेंज क्रेडेंशियल नहीं देता। ग्राहकों को दृढ़ता से प्रोत्साहित किया जाता है कि प्रत्येक एक्सचेंज API कुंजी को केवल-ट्रेडिंग अनुमतियों तक सीमित करें, जारी करने वाले वेन्यू पर निकासी अक्षम करें, और जहां वेन्यू इसका समर्थन करता हो वहां IP allowlisting लागू करें।

सेशन टोकन एक multi-key rotation window के तहत हस्ताक्षरित किए जाते हैं। सर्वर JWT_SECRETS परिवेश चर के माध्यम से signing keys की एक अल्पविराम-अलग सूची स्वीकार करता है, जिसमें प्रत्येक एक छोटे key identifier के साथ टैग किया जाता है। नए टोकन पहली (सक्रिय) कुंजी के तहत हस्ताक्षरित किए जाते हैं और O(1) सत्यापन के लिए JWT header में वह पहचानकर्ता वहन करते हैं। विंडो में किसी रिटायर की गई कुंजी के तहत जारी टोकन अपने सात-दिन TTL समाप्त होने तक सत्यापन जारी रखते हैं, जिस बिंदु पर रिटायर की गई कुंजी हटाई जा सकती है। एक्सपायर्ड टोकन तुरंत अस्वीकार किए जाते हैं, भले ही कोई non-active कुंजी अन्यथा उन्हें स्वीकार करती। रोटेशन प्रक्रिया server/src/services/jwtKeys.ts में प्रलेखित है; सत्यापन round trips server/src/scripts/jwt-keys-verify.ts में दावा किए जाते हैं।

4. प्रमाणीकरण और एक्सेस नियंत्रण

उपयोगकर्ता प्रमाणीकरण कार्य कारक 12 पर bcrypt हैशिंग के साथ ईमेल और पासवर्ड पर आधारित है, जो login, register, और forgot password endpoints पर rate limiting के साथ संयुक्त है (प्रति IP प्रति 15 मिनट 20 प्रयास, express-rate-limit द्वारा in-process लागू)। सेशन टोकन सात-दिन की समाप्ति के साथ JSON Web Tokens के रूप में जारी किए जाते हैं और उपयोगकर्ता, भूमिका, और टियर दावों से बाउंड होते हैं। Role-based access control user को admin से अलग करता है, और tier-based access control चार-टियर कैटलॉग के अनुसार सुविधाओं को गेट करता है। परिणाम की प्रत्येक कार्रवाई सर्वर साइड पर जांची जाती है; क्लाइंट-साइड गेट केवल एक UX संकेत हैं और कभी भी सुरक्षा के लिए नहीं भरोसा किया जाता।

दो-कारक प्रमाणीकरण सभी उपयोगकर्ताओं के लिए मानक TOTP प्रोफ़ाइल (RFC 6238, SHA-1, 6 अंक, 30-सेकंड अवधि, ±1 विंडो ड्रिफ्ट) के माध्यम से उपलब्ध है और यह हर प्रमुख प्रमाणीकरण ऐप के साथ संगत है। TOTP साझा रहस्य सर्वर-साइड पर 160 बिट एंट्रॉपी के साथ उत्पन्न किए जाते हैं, धारा 1 में वर्णित एनवलप एन्क्रिप्शन परत से लपेटे जाते हैं, और उपयोगकर्ता पंक्ति में संग्रहीत किए जाते हैं। रिकवरी कोड नामांकन के समय एक बार उत्पन्न किए जाते हैं, वर्क फ़ैक्टर 12 पर bcrypt-हैश किए जाते हैं, और फिर एनवलप परत द्वारा दूसरी बार लपेटे जाते हैं ताकि अकेले डेटाबेस समझौता उन्हें पुनर्जीवित न कर सके। नामांकन एक दो-चरणीय प्रक्रिया है जिसमें उपयोगकर्ता को यह साबित करना होता है कि उन्होंने अपना प्रमाणीकरण कॉन्फ़िगर किया है, दूसरा कारक सक्रिय होने से पहले एक लाइव कोड दर्ज करके। लॉगिन प्रवाह एक पासवर्ड जांच बन जाता है, फिर एक अल्पकालिक (पांच-मिनट) चैलेंज टोकन, फिर एक कोड सत्यापन जो परमाण्विक रूप से चैलेंज पंक्ति का उपभोग करता है। एक सफल उपभोग के बाद कैप्चर किए गए चैलेंज टोकन को दोबारा नहीं चलाया जा सकता। MFA, CEX API क्रेडेंशियल जोड़ने और प्लेटफ़ॉर्म API कुंजियां उत्पन्न करने के लिए आवश्यक है, जो उत्पाद में दो सबसे अधिक प्रभावशाली फंड-इंटरैक्टिंग क्रियाएं हैं। हर MFA चैलेंज परिणाम (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) को §6 में वर्णित केवल-अनुलग्न ऑडिट लॉग में लिखा जाता है ताकि चैलेंज पैटर्न ऑडिट योग्य और छेड़छाड़-स्पष्ट हों।

उत्पादन प्रणालियों तक Melaya कर्मचारी पहुंच प्रति-इंजीनियर आधार पर दी जाती है और जब आवश्यकता न हो तब हटा दी जाती है। पुरानी NOPASSWD sudoers प्रविष्टियां और SSH authorized keys को सत्र-दर-सत्र आधार पर साफ़ किया जाता है। एक औपचारिक त्रैमासिक-सत्यापन पहुंच-समीक्षा प्रक्रिया जिसमें हस्ताक्षरित समीक्षा रिकॉर्ड हों, और डिप्लॉय उपयोगकर्ता और सेवा रनटाइम उपयोगकर्ता के बीच पूर्ण विभाजन (ताकि एक समझौता की गई सेवा प्रक्रिया डिप्लॉय पथ पर न जा सके), दोनों को सुरक्षा रोडमैप पर नियोजित नियंत्रणों के रूप में ट्रैक किया जाता है।

5. नेटवर्क और इन्फ्रास्ट्रक्चर दर सीमाएं

दर सीमाएं express-rate-limit द्वारा एप्लिकेशन परत पर Redis-समर्थित साझा स्टोर के साथ लागू की जाती हैं ताकि सीमाएं हर सर्वर इंस्टेंस में वैश्विक हों, न कि प्रति-प्रक्रिया। दो स्वतंत्र रूप से कॉन्फ़िगर की गई बकेट लागू होती हैं: प्रमाणीकरण एंडपॉइंट पर एक सख्त बकेट (20 प्रयास प्रति IP प्रति 15 मिनट विंडो) और एक सामान्य API बकेट (200 अनुरोध प्रति IP प्रति मिनट)। सीमाकर्ता विफल-बंद है: यदि Redis स्टोर अनुपलब्ध है, तो auth एंडपॉइंट अस्वीकार कर देते हैं बजाय गिरने के। सीमाकर्ता का tRPC बैच-जागरूक रैपर server/src/scripts/rate-limit-verify.ts (7/7 परिदृश्य, proc-लॉन्ड्रिंग हमले सहित) द्वारा सत्यापित किया जाता है।

एज ट्रैफ़िक WAF, बॉट डिटेक्शन और उच्च-जोखिम पथों पर जियो-ब्लॉकिंग के साथ Cloudflare द्वारा अग्रसारित किया जाता है। Cloudflare ज़ोन के लिए एक Terraform स्कैफ़ोल्ड deploy/cloudflare/ पर ड्रिफ्ट डिटेक्शन, आपातकालीन ओवरराइड और 24-घंटे सुलह नियम को कवर करने वाले एक ऑपरेशनल रनबुक के साथ प्रतिबद्ध है। उस स्कैफ़ोल्ड के विरुद्ध वर्तमान-मैन्युअल ज़ोन का इम्पोर्ट-और-सुलह प्रगति में है और पहले बाहरी पेनेट्रेशन टेस्ट से पहले की गेटिंग कार्य है।

6. निगरानी, लॉगिंग और ऑडिट

प्लेटफ़ॉर्म Node.js tRPC सर्वर, Rust इंजन, Python वर्कर और एज से संरचित लॉग उत्सर्जित करता है। सभी होस्ट-स्तरीय और कंटेनर-स्तरीय लॉग (systemd journal, /var/log/, nginx access/error, Jenkins और Gitea कंटेनर stdout, और हर Melaya एप्लिकेशन लॉग फ़ाइल) एक Grafana Alloy कलेक्टर के माध्यम से प्रोडक्शन होस्ट के समान क्षेत्र में Grafana Cloud Loki टेनेंट को वास्तविक समय में ऑफ-बॉक्स भेजे जाते हैं, ताकि ऑडिट ट्रेल होस्ट समझौते या डिस्क हानि से बचे।

सुरक्षा-प्रासंगिक घटनाएं (प्रमाणीकरण परिणाम, MFA चैलेंज परिणाम, CEX क्रेडेंशियल जोड़ना और हटाना, प्लेटफ़ॉर्म API कुंजी जारी करना और निरस्त करना, टियर परिवर्तन और रोलबैक) अतिरिक्त रूप से server/sql/audit_log_schema.sql में परिभाषित केवल-अनुलग्न agents.audit_log तालिका में लिखी जाती हैं। स्कीमा एप्लिकेशन भूमिका से REVOKE UPDATE, DELETE का उपयोग करती है, पंक्तियों पर एक क्रिप्टोग्राफ़िक हैश चेन (prev_hash / row_hash), एक कुंजीकृत रहस्य के साथ अभिनेता IP पर HMAC-SHA256 (सादे SHA-256 नहीं, जो शब्दकोश-हमलावर है), और GDPR अनुच्छेद 17 मिटाने के लिए एक साइड-टेबल agents.audit_log_tombstone जो कभी चेन को नहीं बदलती। एक दैनिक सत्यापनकर्ता (verify-audit-chain.ts) चेन को अंत से अंत तक चलाता है, ±2 सेकंड NTP सहनशीलता के साथ टाइमस्टैम्प एकरसता का दावा करता है, और बाहरी राइट-वन्स स्टोरेज के लिए उपयुक्त एक एंकर डाइजेस्ट उत्सर्जित करता है। audit-log-verify.ts में छह छेड़छाड़ परिदृश्य लाइव प्रोड के विरुद्ध शून्य पर निकलते हैं।

7. भेद्यता प्रबंधन

हर कमिट CI के भाग के रूप में npm audit --production और एक Trivy फ़ाइलसिस्टम स्कैन चलाता है। Trivy को प्रत्येक बिल्ड पर दो बार आमंत्रित किया जाता है: एक बार ignore-unfixed: true के साथ गेटेड मोड में ताकि कार्रवाई योग्य खोज जांच विफल कर दें, और एक बार ignore-unfixed: false और गैर-गेटिंग के साथ ताकि SOC 2 साक्ष्य के लिए रिपोजिटरी के Security टैब पर पूरी भेद्यता सतह अपलोड हो। प्रोडक्शन होस्ट सुरक्षा चैनल सक्षम के साथ unattended-upgrades चलाता है। Jenkins, Gitea, Infisical, Postgres, और Redis के लिए तृतीय-पक्ष कंटेनर छवियां संस्करण बम्प से पहले समीक्षा-गेटेड हैं और आंतरिक सुरक्षा वॉल्ट में पैचिंग कैडेंस रनबुक में ट्रैक की जाती हैं।

Melaya ने अभी तक तृतीय-पक्ष बाहरी पेनेट्रेशन टेस्ट नहीं कराया है। एंगेजमेंट का दायरा (इन-स्कोप और आउट-ऑफ-स्कोप एसेट, एंगेजमेंट के नियम, विक्रेता शॉर्टलिस्ट, और पोस्ट-एंगेजमेंट उपचार कैडेंस सहित) आंतरिक Pentest Scope रनबुक में प्रतिबद्ध है ताकि §5 से Cloudflare IaC सुलह उतरते ही विक्रेता चयन आगे बढ़ सके। Melaya दस्तावेज़ीकरण में कहीं भी "वार्षिक पेनेट्रेशन टेस्ट" का दावा नहीं किया जाता।

8. सुरक्षित सॉफ़्टवेयर विकास

प्लेटफ़ॉर्म में परिवर्तन मर्ज से पहले पीयर समीक्षा के साथ सोर्स कंट्रोल से होकर गुजरते हैं। TypeScript का strict मोड और स्टैटिक विश्लेषण हर क्लाइंट और सर्वर बिल्ड पर चलते हैं। gitleaks एक प्री-कमिट हुक के रूप में और CI में चलता है, एक पथ-दायरे वाली अनुमति-सूची के साथ बजाय वैश्विक के, ताकि क्रेडेंशियल का आकस्मिक खुलासा मर्ज से पहले बिल्ड विफल कर दे। सभी GitHub Actions को सप्लाई-चेन टैग-रीराइटिंग हमलों को रोकने के लिए कमिट SHA द्वारा पिन किया गया है। प्रोडक्शन डिप्लॉयमेंट एक प्रतिबंधित Jenkins SSH रैपर के माध्यम से जाते हैं जिसमें authorized_keys command= प्रतिबंध है ताकि एक समझौता किया गया CI रनर भी केवल चार Melaya सेवाओं के लिए स्पष्ट resync <service> और log <service> ऑपरेशन को ही आमंत्रित कर सके: कोई मनमाना शेल नहीं, कोई फ़ाइलसिस्टम ट्रैवर्सल नहीं, सेवा पुनरारंभ से परे कोई विशेषाधिकार वृद्धि नहीं। हर डिप्लॉय पाइपलाइन आमंत्रण ऑडिट के लिए Grafana Cloud Loki टेनेंट में ऑफ-बॉक्स लॉग किया जाता है।

9. घटना प्रतिक्रिया

Melaya एक लिखित Incident Response रनबुक बनाए रखता है जिसमें गंभीरता घोषणा (SEV-0 से SEV-3), भूमिका असाइनमेंट (IC, तकनीकी प्रमुख, संचार, लिखाई), एक नियंत्रण चेकलिस्ट जिसमें स्पष्ट एनवलप-कुंजी, JWT-कुंजी और ऑडिट-लॉग IP-HMAC-कुंजी रोटेशन चरण शामिल हैं, GDPR अनुच्छेद 33 72-घंटे अधिसूचना मैट्रिक्स, और एक पोस्ट-मॉर्टम टेम्प्लेट शामिल हैं। रनबुक आंतरिक सुरक्षा वॉल्ट में प्रतिबद्ध है और एक जीवंत दस्तावेज़ के रूप में माना जाता है: पहला टेबलटॉप ड्रिल Q3 2026 के लिए निर्धारित है, और रनबुक को अपने §7 में स्पष्ट रूप से "सक्रिय नहीं" के रूप में चिह्नित किया गया है जब तक वह ड्रिल निष्पादित न हो। ऑन-कॉल इंजीनियर आज वास्तविक घटनाओं का जवाब देते हैं। ड्रिल गेट औपचारिक टेबलटॉप अभ्यास के बारे में है, प्रतिक्रिया पथ के अस्तित्व के बारे में नहीं।

10. बैकअप और आपदा पुनर्प्राप्ति

प्रति-उपप्रणाली रिकवरी टाइम ऑब्जेक्टिव (RTO) और रिकवरी पॉइंट ऑब्जेक्टिव (RPO) लक्ष्य आंतरिक RTO RPO रनबुक में प्रकाशित हैं: agents.* टियर 15-मिनट RTO / 2-घंटे RPO को लक्षित करता है, CEX क्रेडेंशियल स्टोरेज 5-मिनट RTO / 1-घंटे RPO को लक्षित करता है, Infisical और ऑब्जेक्ट स्टोरेज 1-घंटे RTO / 4-घंटे RPO को लक्षित करते हैं, Redis कोई-बैकअप नहीं और पुनः कनेक्शन पर पुनर्निर्मित है। बैकअप मैकेनिक्स निरंतर WAL आर्काइविंग, एक रात्रि लॉजिकल डंप, एक मासिक बेस बैकअप, और एक बाहरी स्थान पर दैनिक राइट-वन्स ऑडिट-लॉग एंकर एक्सपोर्ट को संयोजित करते हैं। पहला पूर्ण वार्षिक रिस्टोर ड्रिल Q3 2026 के लिए निर्धारित है और रिस्टोर वॉल-क्लॉक और अखंडता जांच का इसका लिखित सत्यापन उसी रनबुक में प्रतिबद्ध होगा।

11. व्यापार निरंतरता

एक लिखित व्यापार निरंतरता योजना आंतरिक सुरक्षा वॉल्ट में प्रतिबद्ध है जिसमें प्राथमिक-क्षेत्र आउटेज प्रतिक्रिया, Postgres-प्रदाता विफलता, Infisical वॉल्ट आउटेज (सर्वर कैश किए गए क्रेडेंशियल के माध्यम से मौजूदा सत्रों की सेवा जारी रखता है, नई CEX लिखाई उपयोगकर्ता-दृश्यमान त्रुटि के साथ अस्वीकार करती है), Stripe आउटेज (मौजूदा सदस्यताएं अप्रभावित), कार्मिक उपलब्धता मैट्रिक्स, और एक प्रति-आपूर्तिकर्ता आकस्मिक तालिका शामिल है। योजना TLS आधारभूत के समान त्रैमासिक कैडेंस पर समीक्षा की जाती है।

12. विक्रेता और उप-प्रोसेसर सुरक्षा

Melaya उप-प्रोसेसरों का एक सीमित सेट उपयोग करता है, जिनमें से प्रत्येक को उसकी सुरक्षा स्थिति के लिए चुना गया है। उत्पादन में वर्तमान उप-प्रोसेसर में भुगतान प्रसंस्करण के लिए Stripe, एज TLS और WAF के लिए Cloudflare, सीक्रेट स्टोरेज के लिए स्व-होस्टेड Infisical (प्रोडक्शन होस्ट पर सह-निवासी, कोई तृतीय पक्ष नहीं), हमारा Postgres होस्टिंग प्रदाता, हमारा Redis होस्टिंग प्रदाता, हमारा ऑब्जेक्ट स्टोरेज प्रदाता, ट्रांजेक्शनल ईमेल प्रदाता, और Grafana Cloud में ऑफ-बॉक्स लॉग और मेट्रिक संग्रह के लिए Grafana Labs (प्रोडक्शन होस्ट के समान क्षेत्र, SOC 2 Type II प्रमाणित) शामिल हैं। जो ग्राहक तृतीय-पक्ष भाषा मॉडल प्रदाताओं को कॉन्फ़िगर करते हैं, वे वास्तव में उन पाइपलाइनों के लिए उन प्रदाताओं को उप-प्रोसेसर के रूप में जोड़ते हैं जिनके माध्यम से वे रूट करते हैं। वे प्रदाता ग्राहक के अपने कॉन्फ़िगरेशन के अधीन हैं और Melaya के विक्रेता अनुबंधों द्वारा कवर नहीं हैं। विहित उप-प्रोसेसर सूची आंतरिक सुरक्षा वॉल्ट में उद्यम ग्राहकों को 15-दिन परिवर्तन अधिसूचना प्रतिबद्धता के साथ बनाए रखी जाती है। एक सार्वजनिक संस्करण फ्रंटएंड के लाइव होने पर melaya.org/legal/subprocessors पर प्रकाशित किया जाता है।

13. अनुपालन स्थिति

Melaya SOC 2 ट्रस्ट सेवा मानदंड और ISO/IEC 27001 को ध्यान में रखते हुए अपने नियंत्रण बना रहा है। इस दस्तावेज़ की तिथि के अनुसार Melaya के पास SOC 2 Type I, SOC 2 Type II, ISO/IEC 27001, या कोई समकक्ष तृतीय-पक्ष सुरक्षा प्रमाणन नहीं है। ये हमारे रोडमैप पर आकांक्षी मील के पत्थर हैं। आज प्रमाणन की आवश्यकता वाले किसी भी संभावित ग्राहक को एक पूर्ण रिपोर्ट के बजाय अंतराल विश्लेषण डिलीवरेबल की अपेक्षा करनी चाहिए। उद्यम ग्राहक [email protected] से संपर्क करके हमारे वर्तमान नियंत्रण मैट्रिक्स और प्रगति में उपचारों की सूची का अनुरोध कर सकते हैं।

एक पंद्रह-खंड डेटा प्रसंस्करण अनुबंध टेम्प्लेट का मसौदा तैयार किया गया है और आंतरिक सुरक्षा वॉल्ट में प्रतिबद्ध किया गया है। इसमें यूरोपीय आयोग मानक संविदात्मक खंड (नियंत्रक-से-प्रोसेसर के लिए Module 2 और प्रोसेसर-से-प्रोसेसर के लिए Module 3), UK अंतरराष्ट्रीय डेटा स्थानांतरण अनुबंध, और Swiss FADP समकक्ष शामिल हैं। GDPR अनुच्छेद 33 72-घंटे उल्लंघन-अधिसूचना प्रतिबद्धता, वापसी-या-विलोपन प्रक्रिया, और ऑडिट अधिकार (वार्षिक और NDA'd SOC 2 Type II तक सीमित जब वह उपलब्ध हो) सभी टेम्प्लेट में बाध्य हैं। भुगतान टियर पर क्लिकरैप के रूप में DPA प्रदान करने और citadel टियर पर द्विपक्षीय रूप से हस्ताक्षर योग्य संस्करण के रूप में प्रदान करने से पहले बाहरी वकील समीक्षा लंबित है।

14. ग्राहक उत्तरदायित्व

Melaya पर सुरक्षा साझा है। ग्राहक मजबूत, अद्वितीय पासवर्ड चुनने, अपने खाता क्रेडेंशियल की सुरक्षा करने, एक्सचेंज API कुंजियों को न्यूनतम आवश्यक अनुमतियों तक सीमित करने, उनके द्वारा बनाई गई पाइपलाइनों के व्यवहार की समीक्षा और सत्यापन करने, पुनर्प्राप्ति सूचकांकों पर अपलोड की गई सामग्री को नियंत्रित करने, किसी भी तृतीय-पक्ष भाषा मॉडल प्रदाताओं की शर्तों और डेटा प्रबंधन प्रथाओं की समीक्षा करने जिन्हें वे रूट करना चुनते हैं, और किसी भी संदिग्ध समझौते की तुरंत रिपोर्ट करने के लिए जिम्मेदार हैं। हम दृढ़ता से अनुशंसा करते हैं कि आप पहली बार साइन इन करते समय खाता सेटिंग में दो-कारक प्रमाणीकरण सक्षम करें। किसी भी CEX क्रेडेंशियल जोड़ने या कोई प्लेटफ़ॉर्म API कुंजी उत्पन्न करने से पहले यह आवश्यक है, और यह एकल सबसे प्रभावशाली सुरक्षा नियंत्रण है जो कोई ग्राहक अपने खाते पर लागू कर सकता है।

15. जिम्मेदार प्रकटीकरण और सुरक्षित-बंदरगाह

सुरक्षित-बंदरगाह। Melaya, Inc. उन सुरक्षा शोधकर्ताओं के खिलाफ कानूनी कार्रवाई नहीं करेगा, या किसी तृतीय-पक्ष कानूनी कार्रवाई का समर्थन नहीं करेगा, जो सद्भाव में कार्य करते हैं और इस नीति का पालन करते हैं। यह प्रतिबद्धता उन दावों पर लागू होती है जो Melaya अन्यथा U.S. Computer Fraud and Abuse Act (CFAA), U.K. Computer Misuse Act, EU सदस्य राज्य कंप्यूटर-दुरुपयोग क़ानूनों के समकक्ष प्रावधानों, और अनुबंध के उल्लंघन, कपटपूर्ण हस्तक्षेप, या संपत्ति अतिक्रमण के लिए किसी भी सिविल-कानून दावों के तहत ला सकता है। "सद्भाव" का अर्थ है कि शोधकर्ता ने नीचे दिए गए दायरे और एंगेजमेंट नियमों का पालन करने का वास्तविक प्रयास किया, अन्य उपयोगकर्ताओं के डेटा तक पहुंच, संशोधन, नष्ट या निष्कासन नहीं किया, जानबूझकर अन्य उपयोगकर्ताओं के लिए सेवाओं को खराब नहीं किया, और किसी भी सार्वजनिक प्रकटीकरण से पहले निजी तौर पर [email protected] को खोज का खुलासा किया। यह खंड Melaya पर बाध्यकारी है और प्रति-रिपोर्ट अनुमोदन की आवश्यकता नहीं है। यह ऐसे आचरण को कवर नहीं करता जो शोधकर्ता के क्षेत्राधिकार के तहत स्वतंत्र रूप से अवैध है, जैसे अन्य उपयोगकर्ताओं के खिलाफ वास्तविक वित्तीय धोखाधड़ी, या जबरदस्ती।

दायरा। परीक्षण melaya.org और *.melaya.org ज़ोन में सभी उपडोमेन, app.melaya.org पर एप्लिकेशन सतह, Builder API एंडपॉइंट, और Melaya-प्रकाशित कानूनी पृष्ठों के विरुद्ध अधिकृत है। परीक्षण अधिकृत नहीं है: (i) Melaya के माध्यम से पहुंचे किसी भी तृतीय-पक्ष एक्सचेंज पर लाइव ऑर्डर प्लेसमेंट, रद्दीकरण, या संशोधन; (ii) उपयोगकर्ता-कॉन्फ़िगर की गई पाइपलाइन के माध्यम से पहुंचे तृतीय-पक्ष भाषा मॉडल प्रदाता (OpenAI, Anthropic, Google, Cohere, स्थानीय रनटाइम); (iii) स्वयं Cloudflare, होस्टिंग प्रदाता, या वॉल्ट प्रदाता इन्फ्रास्ट्रक्चर; (iv) डेनियल-ऑफ-सर्विस हमले का कोई भी रूप (L3/L4 बाढ़, L7 बाढ़, क्रेडेंशियल मात्रा में स्टफिंग); (v) Melaya कर्मचारियों, ठेकेदारों, या ग्राहकों की सामाजिक इंजीनियरिंग; (vi) भौतिक घुसपैठ।

एंगेजमेंट के नियम। शोधकर्ताओं को एक खोज साबित होते ही परीक्षण बंद करना होगा (क्रॉस-टेनेंट एक्सेस के प्रमाण के लिए एकल गैर-विनाशकारी रीड पर्याप्त है), कभी भी अन्य उपयोगकर्ताओं के डेटा को संशोधित या निष्कासन नहीं करना है, स्थायित्व स्थापित नहीं करना है, और स्वचालित परीक्षण को 1 अनुरोध प्रति सेकंड निरंतर से नीचे रखना है। परीक्षण ट्रैफ़िक में एक अलग User-Agent: Melaya-research/<handle> हेडर होना चाहिए ताकि Melaya इसे वास्तविक ट्रैफ़िक से अलग कर सके और इसके लिए ऑन-कॉल को पेज न करे।

ट्राइज SLA। Melaya प्राप्ति के पांच (5) व्यापार दिनों के भीतर वैध रिपोर्ट की पावती देने, पावती के दस (10) व्यापार दिनों के भीतर प्रारंभिक गंभीरता मूल्यांकन प्रदान करने, और गंभीरता सीढ़ी के अनुसार खोजों का उपचार करने की प्रतिबद्धता करता है: Critical 48 घंटों के भीतर, High 7 कैलेंडर दिनों के भीतर, Medium 30 कैलेंडर दिनों के भीतर, Low अवसरवादी आधार पर। यदि Melaya SLA प्रतिबद्धता चूक जाता है, तो शोधकर्ता प्रकाशित करने के इरादे की सात (7) दिन लिखित सूचना दे सकता है और सुरक्षित-बंदरगाह सुरक्षा प्रकाशन के दौरान प्रभावी रहती है बशर्ते शोधकर्ता पूरे समय एंगेजमेंट के नियमों का पालन करे।

संपर्क। रिपोर्ट [email protected] पर भेजी जानी चाहिए। एन्क्रिप्टेड रिपोर्ट के लिए एक PGP कुंजी /.well-known/security.txt पर प्रकाशित की जाएगी। रिपोर्ट सोशल मीडिया, सार्वजनिक Melaya रिपोजिटरी पर GitHub issues, या किसी भी सपोर्ट चैट सतह के माध्यम से नहीं भेजी जानी चाहिए: वे चैनल सुरक्षा-संवेदनशील सामग्री के लिए निगरानी में नहीं हैं और उपचार से पहले आकस्मिक सार्वजनिक प्रकटीकरण का जोखिम पैदा करते हैं।

यह धारा 15 स्व-संपूर्ण है और इसकी प्रतिबद्धताएं बाध्यकारी हैं। पहले पैराग्राफ में सुरक्षित-बंदरगाह, दूसरे और तीसरे पैराग्राफ में दायरा और एंगेजमेंट के नियम, चौथे पैराग्राफ में ट्राइज SLA, और तुरंत अनुसरण करने वाले पैराग्राफ में Terms-of-Service इंटरैक्शन और केवल-भविष्य संशोधन नियम मिलकर सुरक्षा शोधकर्ताओं के संबंध में Melaya पर बाध्यकारी प्रतिबद्धताओं का पूर्ण सेट बनाते हैं। इस धारा 15 का हर पैराग्राफ, न केवल पहले चार, बाध्यकारी प्रतिबद्धता सेट का हिस्सा है। Melaya ट्राइज रूटिंग और एस्केलेशन के लिए एक आंतरिक ऑपरेशनल रनबुक बनाए रखता है, लेकिन वह रनबुक इस धारा 15 में किसी भी प्रतिबद्धता को जोड़ता, घटाता, या संशोधित नहीं करता, और एक शोधकर्ता को ऊपर सुरक्षित-बंदरगाह पर भरोसा करने के लिए कोई अन्य दस्तावेज़ पढ़ने की आवश्यकता नहीं है। इस धारा 15 में कोई भी परिवर्तन केवल भविष्यलक्षी रूप से लागू होता है: रिपोर्ट के समय प्रभावी इस धारा 15 के संस्करण के तहत सद्भाव में रिपोर्ट की गई खोज उस संस्करण के सुरक्षित-बंदरगाह द्वारा किसी भी बाद के संशोधन के बावजूद सुरक्षित रहती है।

Terms of Service के साथ इंटरैक्शन (बाध्यकारी)। यह धारा 15 Melaya की ओर से सुरक्षा अनुसंधान गतिविधि के लिए स्पष्ट प्राधिकरण है जो अन्यथा Terms of Service के Melaya की सुरक्षा, दर-सीमा, या एक्सेस-कंट्रोल सुविधाओं को दरकिनार करने, अक्षम करने, या हस्तक्षेप करने के खिलाफ निषेधों द्वारा प्रतिबंधित होती। ऊपर दिए गए दायरे और एंगेजमेंट के नियमों के भीतर कार्य करने वाला एक शोधकर्ता इसलिए उस आचरण के लिए Terms के उल्लंघन में नहीं है, और Melaya उस विशिष्ट आचरण के संबंध में Terms के तहत अन्यथा ला सकने वाले किसी भी दावे को माफ करता है। यह पैराग्राफ स्वयं ऊपर बाध्यकारी प्रतिबद्धता सेट का हिस्सा है और केवल व्याख्यात्मक पाठ नहीं है।

16. इस अवलोकन में परिवर्तन

Melaya समय-समय पर इस सुरक्षा अवलोकन को अपडेट कर सकता है, ताकि प्लेटफ़ॉर्म, हमारे नियंत्रणों, या हमारे उप-प्रोसेसर में हुए बदलावों को दर्शाया जा सके। इस दस्तावेज़ के शीर्ष पर दी गई "अंतिम अपडेट" तारीख सबसे हाल के संशोधन को दर्शाती है। जब संचालन-संबंधी लंबित कार्य (जैसे पहला रिस्टोर ड्रिल, पहला IR टेबलटॉप ड्रिल, पहला बाहरी पेनटेस्ट, या DPA टेम्पलेट की बाहरी कानूनी समीक्षा) पूरे होते हैं, तो संबंधित अनुभाग को नई स्थिति दर्शाने के लिए फिर से लिखा जाता है और यह बदलाव उत्पाद चेंजलॉग में घोषित किया जाता है।

17. संपर्क

सुरक्षा संबंधी प्रश्नों, भेद्यता रिपोर्ट, या अनुपालन दस्तावेज़ीकरण का अनुरोध करने के लिए, संपर्क करें: