सुरक्षा अवलोकन

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

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

उपयोगकर्ता क्लाइंट और सेवाओं के बीच पारगमन में सभी डेटा, Transport Layer Security (TLS) संस्करण 1.2 या उससे उच्चतर द्वारा संरक्षित है, जो तैनाती के किनारे पर Cloudflare पर समाप्त होता है। उत्पादन TLS प्रोफ़ाइल Mozilla Intermediate संगतता मार्गदर्शिका का पालन करती है: केवल TLS 1.2 और 1.3, केवल ECDHE साइफर सूट, केवल फॉरवर्ड-सीक्रेट AEAD साइफर, दो-वर्ष की max-age और preload निर्देश के साथ HSTS, तथा एक स्पष्ट connect-src अनुमति-सूची के साथ एक सख्त Content Security Policy। Content Security Policy दोनों स्तरों पर लागू होती है: API सर्वर अपने सुरक्षा-हेडर मिडलवेयर के माध्यम से default-src 'none' सेट करता है, और सार्वजनिक वेब एप्लिकेशन एक ऐसी नीति के साथ आती है जो हमारे स्वयं के बैकएंड के साथ-साथ भुगतान और साइन-इन प्रदाताओं को अनुमति देती है, प्लगइन सामग्री और बेस-टैग या फॉर्म-एक्शन हाईजैकिंग को अवरुद्ध करती है, और स्क्रिप्ट निष्पादन को प्रतिबंधित करती है, ताकि कोई इंजेक्टेड स्क्रिप्ट किसी हमलावर मूल पर डेटा एक्सफिल्ट्रेट न कर सके। पूर्ण TLS प्रोफ़ाइल, प्रतिबद्ध साइफर सूची, और त्रैमासिक समीक्षा कार्यक्रम, आंतरिक सुरक्षा वॉल्ट में TLS Baseline रनबुक में प्रलेखित हैं। हमारे बुनियादी ढांचे के भीतर आंतरिक सेवा-से-सेवा कॉल लूपबैक या निजी नेटवर्क लिंक पर संचालित होती हैं।

रेस्ट पर एन्क्रिप्शन वर्तमान में एप्लिकेशन लेयर पर field-level envelope encryption के माध्यम से लागू है। स्टोरेज लेयर पर full-volume disk encryption अभी तक सक्षम नहीं है: प्रोडक्शन block devices फिलहाल disk स्तर पर अनएन्क्रिप्टेड हैं। LUKS का उपयोग करके volume-level encryption को उपचार के रूप में चुना गया है और यह सुरक्षा रोडमैप पर एक प्रतिबद्ध आइटम है; जब तक इसे क्रियान्वित नहीं किया जाता, Melaya disk-layer या provider-managed volume encryption को सक्रिय नियंत्रण के रूप में प्रस्तुत नहीं करता।

संवेदनशील मानों को हमारी envelope-encryption सेवा में लागू एप्लिकेशन-स्तरीय envelope encryption लेयर द्वारा सुरक्षित किया जाता है। Exchange API क्रेडेंशियल (key, secret, passphrase), प्रति-उपयोगकर्ता connector क्रेडेंशियल और OAuth टोकन, तथा MFA सीक्रेट और recovery कोड को Infisical vault provider को भेजे जाने या agents.credentials fallback तालिका में लिखे जाने से पहले सर्वर प्रक्रिया में केवल रखी गई 256-bit master key का उपयोग करके AES-256-GCM के साथ wrap किया जाता है। wire format एक स्पष्ट key पहचानकर्ता (v1:<kid>:<base64(iv|ciphertext|tag)>) वहन करता है ताकि सर्वर rotation विंडो के दौरान कई valid keys स्वीकार कर सके और प्रत्येक मान को wrap करने वाली सटीक key पर reads रूट कर सके। नई writes हमेशा सक्रिय key का उपयोग करती हैं, जो configured key सूची में पहली प्रविष्टि है। Rotation एक तीन-release प्रक्रिया है जो प्लेटफ़ॉर्म को कभी बंद नहीं करती: नई key को दूसरी प्रविष्टि के रूप में जोड़ें (writes अभी भी पुरानी key पर जाती हैं, नई key read-only है), इसे पहले स्थान पर प्रमोट करें (writes नई key पर flip होती हैं, पुरानी key readable रहती है), retired key पहचानकर्ता से बंधी किसी भी historical पंक्ति को re-wrap करें, फिर पुरानी प्रविष्टि हटा दें। Infisical और Postgres होस्ट में से कोई भी किसी भी बिंदु पर plaintext क्रेडेंशियल नहीं देखता: किसी भी एकल subprocessor का अकेले compromise केवल ciphertext देता है, और attacker को किसी भी exchange key को recover करने के लिए अतिरिक्त रूप से एक configured envelope key की आवश्यकता होती है। एक one-shot migration script ने envelope लेयर के अस्तित्व में आने से पहले की शेष legacy plaintext पंक्तियों को संभाला; sweep प्रोडक्शन डेटाबेस के विरुद्ध पूरी हुई और इसका round-trip verifier (envelope-verify.ts, 7/7 परिदृश्य) हर CI रन पर और live प्रोडक्शन के विरुद्ध zero पर exit करता है।

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

प्लेटफ़ॉर्म एप्लिकेशन परत पर टेनेंट्स के बीच तार्किक अलगाव लागू करता है। प्रत्येक प्रमाणित अनुरोध एक मान्य JSON Web Token से प्राप्त उपयोगकर्ता पहचानकर्ता वहन करता है, और प्रत्येक डेटाबेस क्वेरी, ऑब्जेक्ट स्टोर एक्सेस, और पुनर्प्राप्ति इंडेक्स लुकअप उस पहचानकर्ता द्वारा पैरामीटराइज़्ड SQL और tRPC संदर्भ प्लंबिंग के माध्यम से स्कोप किया जाता है। Agentic Framework के लिए निर्मित पुनर्प्राप्ति इंडेक्स प्रति-पाइपलाइन संग्रहीत होते हैं और केवल उन क्वेरीज़ को लौटाए जाते हैं जो उस पाइपलाइन से उत्पन्न होती हैं जो उनकी मालिक है। इंजन स्थिति, रणनीति कॉन्फ़िगरेशन, और ऑर्डर इतिहास भी उपयोगकर्ता द्वारा विभाजित हैं। Postgres रो-लेवल सुरक्षा एप्लिकेशन-लेयर स्कोपिंग के पीछे एक रक्षा-गहन परत के रूप में लागू की गई है: FORCE ROW LEVEL SECURITY उत्पादन में agents.* और cex.* स्कीमा में 117 रो-लेवल-सुरक्षा नीतियों के अंतर्गत 44 तालिकाओं में सक्रिय है, और एप्लिकेशन एक समर्पित कम-विशेषाधिकार भूमिका के अंतर्गत जुड़ता है जो NOBYPASSRLS चलाता है और इसलिए यदि कोई क्वेरी गलती से अपना WHERE user_id खंड भूल जाए तो भी टेनेंट्स के पार नहीं देख सकता। प्रति-अनुरोध रो-लेवल-सुरक्षा संदर्भ किसी भी क्वेरी निष्पादित होने से पहले टेनेंट पहचानकर्ता और भूमिका को सत्र पैरामीटर के रूप में सेट करता है, और कनेक्शन पूल रिलीज़ पर DISCARD ALL जारी करता है ताकि संदर्भ टेनेंट्स के बीच स्थानांतरित न हो सके। हमारे वेरीफायर rls-verify.ts में सत्रह क्रॉस-टेनेंट परिदृश्य प्रत्येक CI रन पर लाइव डेटाबेस के विरुद्ध शून्य एग्ज़िट करते हैं, जिनमें SELECT, INSERT, UPDATE, DELETE, स्वामित्व-पुनर्असाइनमेंट, एडमिन बाईपास, नो-कॉन्टेक्स्ट ज़ीरो-रो, और कॉन्टेक्स्ट-लीक रिग्रेशन मामले शामिल हैं।

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

Melaya द्वारा स्वयं उपयोग किए जाने वाले एप्लिकेशन secrets, signing keys, डेटाबेस क्रेडेंशियल, और third-party API keys एक operator-controlled secrets फ़ाइल में संग्रहीत हैं जो process start पर लोड होती है, और हमारे vault provider में। इन्हें कभी भी source control में commit नहीं किया जाता और प्रोडक्शन मान developers के बीच साझा नहीं किए जाते। envelope encryption key एक dedicated encryption key है जो केवल operator के secrets store में रखी जाती है, Postgres डेटाबेस क्रेडेंशियल से अलग और Infisical vault token से अलग, इसलिए तीनों में से किसी एक का compromise plaintext exchange क्रेडेंशियल नहीं देता। ग्राहकों को दृढ़ता से प्रोत्साहित किया जाता है कि वे प्रत्येक exchange API key को केवल trading अनुमतियों तक सीमित करें, जारी करने वाले venue पर withdrawals अक्षम करें, और जहां venue इसका समर्थन करता हो वहां IP allowlisting लागू करें।

Session टोकन एक multi-key rotation विंडो के तहत sign किए जाते हैं। सर्वर signing keys का एक ordered set स्वीकार करता है, जिनमें से प्रत्येक एक short key पहचानकर्ता के साथ tagged है। नए टोकन पहली (सक्रिय) key के तहत sign किए जाते हैं और O(1) verification के लिए JWT header में वह पहचानकर्ता वहन करते हैं। विंडो में किसी भी retired key के तहत जारी किए गए टोकन अपनी सात-दिन की TTL समाप्त होने तक verify होते रहते हैं, जिसके बाद retired key हटाई जा सकती है। Expired टोकन तुरंत reject कर दिए जाते हैं, भले ही कोई non-active key अन्यथा उन्हें स्वीकार करती। Verification round trips हमारे verifier jwt-keys-verify.ts में asserted हैं।

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

उपयोगकर्ता प्रमाणीकरण ईमेल और पासवर्ड पर आधारित है, जिसमें वर्क फ़ैक्टर 12 पर bcrypt हैशिंग का उपयोग किया जाता है। लॉगिन, रजिस्टर और पासवर्ड भूलने के एंडपॉइंट पर रेट लिमिटिंग लागू है (प्रति IP प्रति 15 मिनट में 20 प्रयास, जो Redis-आधारित वितरित लिमिटर द्वारा लागू की जाती है)। सेशन टोकन JSON Web Tokens के रूप में जारी किए जाते हैं, जिनकी सात दिन की समाप्ति अवधि होती है और वे उपयोगकर्ता, रोल तथा टियर क्लेम से बंधे होते हैं। रोल-आधारित एक्सेस कंट्रोल user और admin के बीच अंतर करता है, तथा टियर-आधारित एक्सेस कंट्रोल चार-टियर कैटलॉग के अनुसार फ़ीचर को नियंत्रित करता है। महत्त्वपूर्ण प्रत्येक कार्य की जाँच सर्वर साइड पर की जाती है। क्लाइंट-साइड गेट केवल UX संकेत हैं और सुरक्षा के लिए कभी भी इन पर निर्भर नहीं किया जाता।

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

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

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

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

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

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

प्लेटफ़ॉर्म Node.js tRPC सर्वर, Rust Engine, Python वर्कर और एज से संरचित लॉग उत्सर्जित करता है। सभी होस्ट-स्तरीय और कंटेनर-स्तरीय लॉग (systemd journal, होस्ट सिस्टम लॉग, nginx एक्सेस और एरर लॉग, CI और सोर्स-फोर्ज कंटेनर stdout, और प्रत्येक Melaya एप्लिकेशन लॉग) एक Grafana Alloy कलेक्टर के माध्यम से उत्पादन होस्ट के समान क्षेत्र में Grafana Cloud Loki टेनेंट को वास्तविक समय में ऑफ-बॉक्स भेजे जाते हैं, इसलिए ऑडिट ट्रेल होस्ट समझौता या डिस्क हानि से बचा रहता है। आउटबाउंड नेटवर्क कनेक्शन नेटवर्क-लेयर एग्रेस लॉगिंग नियम द्वारा रिकॉर्ड किए जाते हैं और उसी ऑफ-बॉक्स सिंक को अग्रेषित किए जाते हैं; यह एग्रेस ट्रैफ़िक आज लॉग और अवलोकन किया जाता है, जबकि प्रवर्तित डेनाई-आधारित एग्रेस अनुमतिसूची एक लंबित रोडमैप आइटम बनी हुई है।

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

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

प्रत्येक कमिट CI के भाग के रूप में npm audit --production और एक Trivy फ़ाइलसिस्टम स्कैन चलाता है। Trivy को प्रत्येक बिल्ड पर दो बार लागू किया जाता है: एक बार ignore-unfixed: true के साथ गेटेड मोड में ताकि क्रियाशील निष्कर्ष जाँच विफल करें, और एक बार ignore-unfixed: false के साथ गैर-गेटिंग मोड में ताकि अनुपालन प्रमाण के लिए संपूर्ण भेद्यता सतह को रिपॉजिटरी के Security टैब पर अपलोड किया जा सके। प्रोडक्शन होस्ट सुरक्षा चैनल सक्षम और स्वचालित रीबूट विंडो के साथ unattended-upgrades चलाता है। CI, source-forge, secrets-vault, Postgres और Redis सेवाओं के लिए तृतीय-पक्ष कंटेनर इमेज को वर्शन बंप से पहले समीक्षा-द्वार से गुज़रना पड़ता है, आंतरिक सुरक्षा वॉल्ट में Patching Cadence रनबुक में ट्रैक किया जाता है, और एक दैनिक image-digest drift detector द्वारा निगरानी की जाती है जो किसी भी मौन इमेज रोटेशन के 24 घंटों के भीतर अलर्ट देता है।

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

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

प्लेटफ़ॉर्म में परिवर्तन मर्ज से पहले पीयर समीक्षा के साथ सोर्स कंट्रोल से होकर गुज़रते हैं। TypeScript का strict मोड और स्टैटिक विश्लेषण प्रत्येक क्लाइंट और सर्वर बिल्ड पर चलते हैं। gitleaks एक pre-commit हुक के रूप में और CI में चलता है, जिसमें वैश्विक allow-list के बजाय path-scoped allow-list है, ताकि क्रेडेंशियल का आकस्मिक प्रकटीकरण मर्ज से पहले बिल्ड विफल कर दे। सभी CI एक्शन supply-chain tag-rewriting हमलों को रोकने के लिए commit SHA द्वारा पिन किए गए हैं। प्रोडक्शन डिप्लॉयमेंट एक प्रतिबंधित Jenkins SSH रैपर से होती है जिसमें authorized_keys command= प्रतिबंध है, ताकि एक समझौता किया गया CI रनर भी केवल allowlisted Melaya सेवाओं के लिए स्पष्ट resync <service> और log <service> ऑपरेशन ही लागू कर सके: कोई मनमाना शेल नहीं, कोई फ़ाइलसिस्टम ट्रैवर्सल नहीं, सेवा पुनः-आरंभ से परे कोई विशेषाधिकार वृद्धि नहीं। प्रत्येक डिप्लॉय पाइपलाइन लागू करने पर ऑडिट के लिए Grafana Cloud Loki टेनेंट में ऑफ-बॉक्स लॉग किया जाता है, साथ ही एक प्रतिबद्ध provenance रिकॉर्ड चलते हुए बाइनरी को उसके सोर्स कमिट से जोड़ता है।

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

Melaya एक लिखित Incident Response रनबुक रखता है जिसमें गंभीरता घोषणा (चार गंभीरता स्तर), भूमिका असाइनमेंट (Incident Commander, तकनीकी प्रमुख, संचार, स्क्राइब), एक रोकथाम चेकलिस्ट जिसमें स्पष्ट envelope-key, JWT-key और audit-log IP-HMAC-key रोटेशन चरण शामिल हैं, GDPR अनुच्छेद 33 की 72-घंटे अधिसूचना मैट्रिक्स, और एक post-mortem टेम्पलेट शामिल हैं। रनबुक आंतरिक सुरक्षा वॉल्ट में प्रतिबद्ध है और एक जीवित दस्तावेज़ के रूप में माना जाता है: पहला tabletop drill 2026-07-15 के लिए निर्धारित है, और रनबुक को अपनी प्रक्रियाओं में स्पष्ट रूप से "सक्रिय नहीं" के रूप में चिह्नित किया गया है जब तक वह drill निष्पादित नहीं हो जाती। on-call इंजीनियर आज वास्तविक घटनाओं पर प्रतिक्रिया देते हैं, drill गेट औपचारिक tabletop अभ्यास के बारे में है, प्रतिक्रिया पथ के अस्तित्व के बारे में नहीं।

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

प्रति-उपतंत्र Recovery Time Objective (RTO) और Recovery Point Objective (RPO) लक्ष्य आंतरिक RTO RPO रनबुक में प्रकाशित हैं: agents.* टियर 15-मिनट RTO / 2-घंटे RPO का लक्ष्य रखता है, CEX क्रेडेंशियल स्टोरेज 5-मिनट RTO / 1-घंटे RPO का लक्ष्य रखता है, Infisical और ऑब्जेक्ट स्टोरेज 4-घंटे RTO / 1-घंटे RPO का लक्ष्य रखते हैं, और Redis बिना बैकअप के है तथा reconnect पर पुनर्निर्मित होता है। बैकअप यांत्रिकी में निरंतर WAL आर्काइविंग के साथ 14-दिन point-in-time-recovery विंडो, cross-region में संग्रहित दैनिक लॉजिकल डंप, मासिक बेस बैकअप, और बाहरी स्थान पर दैनिक write-once audit-log एंकर निर्यात शामिल हैं। सभी बैकअप आर्टिफैक्ट restic के साथ संपीड़ित, checksummed और एन्क्रिप्टेड हैं। रिस्टोर सत्यापन दो चक्रों पर चलता है: एक स्वचालित साप्ताहिक जॉब restic integrity check और एक scratch directory में spot-restore करता है, और एक throwaway वातावरण में पहला पूर्ण रिस्टोर drill 2026-07-15 के लिए निर्धारित है, जिसके बाद रिस्टोर wall-clock और integrity check का लिखित प्रमाण उसी रनबुक में प्रतिबद्ध किया जाएगा। Melaya आज एकल प्राथमिक होस्टिंग क्षेत्र से संचालित होता है, इसे स्पष्ट रूप से प्रकट किया गया है, और क्षतिपूर्ति नियंत्रण (cross-region दैनिक डंप, निरंतर WAL आर्काइविंग, cross-region स्वास्थ्य जाँच, और Cloudflare DNS failover) दस्तावेज़ीकृत और स्वीकृत जोखिम के रूप में पूर्ण-क्षेत्र-हानि के worst-case RTO को लगभग 24 घंटे तक सीमित करते हैं।

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

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

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

Melaya सार्वजनिक Subprocessors सूची में वर्णित कार्यों के लिए उप-प्रसंस्कर्ताओं और अवसंरचना-प्रदाताओं का उपयोग करता है। प्रत्येक प्रदाता की संविदात्मक भूमिका, स्थान और अंतरण-सुरक्षा उपाय का मूल्यांकन वास्तविक परिनियोजन और अनुबंध के आधार पर किया जाना चाहिए; ग्राहक द्वारा चुने गए मॉडल, संयोजक, व्यापारी या साधन-प्रदाता Melaya के विक्रेता-अनुबंधों के बजाय ग्राहक के निर्देशों और अपनी शर्तों के अंतर्गत कार्य कर सकते हैं। उद्यम ग्राहकों को उनके अनुबंध या डेटा-संसाधन परिशिष्ट के अंतर्गत लागू उप-प्रसंस्कर्ता सूचना और आपत्ति-अधिकार मिलते हैं। Melaya का मुख्य होस्टेड परिवेश वर्तमान में Singapore में संचालित है, जो EU पर्याप्तता निर्णय के अंतर्गत नहीं आता; अतः जहाँ आवश्यक हो, लागू अंतरणों के लिए विधिसम्मत अंतरण-तंत्र और पूरक सुरक्षा-उपाय आवश्यक हैं। स्थानीय निष्पादन-परिवेश ग्राहक-नियंत्रित हार्डवेयर पर Python, स्थानीय फ़ाइलों, पुनर्प्राप्ति-क्रियाओं और चुने हुए प्रमाणीकरण संबंधी विवरणों का उपयोग करता है, पर चुनी गई विधि के अनुसार संचालन-विन्यास, हस्ताक्षरित प्रेषण-सामग्री, चयनित प्रमाणीकरण संबंधी विवरणों का वितरण, सहयोग-घटनाएँ, टेलीमेट्री, क्लाउड मॉडल के अनुरोध या संयोजक-कॉल फिर भी Melaya और तृतीय पक्षों से होकर गुजर सकते हैं या उन तक पहुँच सकते हैं। प्राप्तकर्ता और निवास-स्थान संबंधी प्रकटीकरण केवल स्थानीय शब्द से नहीं, बल्कि सार्वजनिक 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 Labs LLC उन सुरक्षा शोधकर्ताओं के खिलाफ कानूनी कार्रवाई नहीं करेगा, या किसी तृतीय-पक्ष कानूनी कार्रवाई का समर्थन नहीं करेगा, जो सद्भाव में कार्य करते हैं और इस नीति का पालन करते हैं। यह प्रतिबद्धता उन दावों पर लागू होती है जो 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 90 कैलेंडर दिनों के भीतर। यदि 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 के तहत अन्यथा ला सकने वाले किसी भी दावे को माफ करता है। यह पैराग्राफ स्वयं ऊपर बाध्यकारी प्रतिबद्धता सेट का हिस्सा है और केवल व्याख्यात्मक पाठ नहीं है।

Device Control का सुरक्षा-प्रतिरूप

Device Control को उपयोगकर्ता-अधिकृत और पूर्वनिर्धारित रूप से निषिद्ध माध्यम के रूप में बनाया गया है। Android अनुप्रयोग स्वयं Accessibility या स्क्रीन-ग्रहण सक्षम नहीं कर सकता; उपयोगकर्ता को प्रचालन तंत्र में ये अनुमतियाँ देनी होती हैं। बाह्य स्रोत से स्थापित संस्करणों के लिए Android प्रतिबंधित सेटिंग का अनुमोदन अपेक्षित कर सकता है।

जोड़े गए फ़ोन ऐसे निरस्त किए जा सकने वाले उपकरण-टोकन से प्रमाणित होते हैं जिसका SHA-256 हैश सर्वर-पक्ष पर संग्रहित किया जाता है। Android का मूल टोकन वर्तमान में हार्डवेयर-समर्थित कूटबद्ध भंडारण के बजाय अनुप्रयोग के निजी SharedPreferences में रखा जाता है; iOS अनुप्रयोग अपना टोकन Keychain में रखता है। फ़ोन टोकन ब्राउज़र सत्रों और निष्पादन-परिवेश के टोकन से अलग होते हैं, केवल फ़ोन-अंतिम-बिंदुओं तक सीमित होते हैं, समयबद्ध रूप से समाप्त या निरस्त किए जा सकते हैं, और उन्हें उपयोगकर्ता के उपकरण-सुरक्षा उपायों से संरक्षित किया जाना चाहिए।

अभिगम्यता स्क्रीन-वृक्ष का पठन और अग्रभूमि-सीमित टैप, पाठ-दर्ज, स्वाइप तथा समान कार्रवाइयों को सर्वर और Android उपकरण पर उपयोगकर्ता की अनुमोदित-अनुप्रयोग अनुमत-सूची के विरुद्ध जाँचा जाता है। वैश्विक मार्ग-निर्देशन कार्रवाइयों की सीमाएँ अलग होती हैं, और पूर्ण-स्क्रीन MediaProjection फ़्रेम तकनीकी रूप से अग्रभूमि के अनुमत-सूचीबद्ध अनुप्रयोग तक काटे या सीमित नहीं किए जाते; इसलिए स्क्रीन-प्रतिबिंबन के दौरान दिखाई देने वाला कोई अननुमोदित या संवेदनशील अनुप्रयोग फ़्रेम में आ सकता है।

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

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

Mobile Agent और उपकरण-निष्पादन संबंधी नियंत्रण

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

उपकरण के प्रमाणीकरण संबंधी विवरण ब्राउज़र सत्रों, क्लाउड-सेवा पहचानों, प्रदाता के प्रमाणीकरण संबंधी विवरणों और स्थानीय निष्पादन-परिवेश के टोकन से अलग होते हैं। सर्वर निरस्त किए जा सकने वाले फ़ोन टोकन का SHA-256 हैश संग्रहित करता है। Android वर्तमान में मूल टोकन को निजी SharedPreferences में रखता है, जबकि iOS उसे Keychain में रखता है। फ़ोन टोकन सामान्य खाता-प्रशासन, किसी अन्य उपयोगकर्ता के फ़ोन-अंतिम-बिंदुओं या किसी असंबंधित निष्पादन-परिवेश को अधिकृत नहीं करता।

आदेश पूर्वनिर्धारित रूप से निषिद्ध होते हैं और प्रमाणित उपयोगकर्ता, ग्रहण किए गए कार्य, अनुप्रयोग-संबंधी नीति, कार्रवाई के प्रकार, प्राचलों और कतार के जीवनकाल तक सीमित रहते हैं। कई फ़ोन जुड़े होने पर कतार और अनुमत-सूची वर्तमान में उपयोगकर्ता-सीमित होती हैं; वे किसी चुने हुए उपकरण को निश्चित रूप से संबोधित नहीं होतीं। किसी फ़ोन द्वारा कार्य ग्रहण करने के बाद स्वामित्व-जाँच उसके परिणाम को उस फ़ोन से आबद्ध करती है। संवेदनशील अंतिम-बिंदु अनुरोधकर्ताओं को प्रमाणित करते हैं, आकार और स्वामित्व सत्यापित करते हैं तथा समय-सीमा समाप्त हो चुके कार्य अस्वीकार करते हैं; फिर भी ग्राहकों को केवल विश्वसनीय उपकरण जोड़ने चाहिए।

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

आदेश और टेलीमेट्री के माध्यम कूटबद्ध परिवहन और प्रमाणित पहचानों का उपयोग करते हैं। जहाँ इन्हें कार्यान्वित किया गया है, वहाँ हस्ताक्षरित या अखंडता-संरक्षित प्रेषण, एकबारगी संख्याएँ, आदेश-पहचानकर्ता, समाप्ति, उपकरण से आबद्धता और पुनःप्रेषण की पहचान का उपयोग छेड़छाड़ और अंतर-उपयोगकर्ता निष्पादन का जोखिम घटाने के लिए किया जाता है। परिवहन-कूटलेखन अनुरोध निष्पादित करने के लिए आवश्यक सादा पाठ अधिकृत अंतिम-बिंदु से नहीं छिपाता।

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

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

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

Android Accessibility और MediaProjection उपयोगकर्ता द्वारा प्रदान की जाने वाली संवेदनशील क्षमताएँ हैं। मोबाइल अनुप्रयोग को पहुँच से पहले अपेक्षित प्रमुख प्रकटीकरण और स्पष्ट सहमति देनी चाहिए, उपलब्ध सबसे सीमित API का उपयोग करना चाहिए, आवश्यक होने पर दृश्यमान रहना चाहिए, अनुमति अस्वीकार होने पर सीमित रूप से कार्य करना चाहिए, और मंचीय सुरक्षा को दरकिनार करने या गतिविधि छिपाने के लिए अनुमतियों का कभी उपयोग नहीं करना चाहिए। Google Play से वितरित संस्करण, Google Play की नीति के विरुद्ध Accessibility को स्वायत्त रूप से कार्रवाइयाँ आरंभ करने, उनकी योजना बनाने और उन्हें निष्पादित करने की अनुमति नहीं दे सकता।

iOS App Store अनुप्रयोग Apple के सैंडबॉक्स, अधिकारिताओं और सार्वजनिक APIs द्वारा सीमित है तथा तृतीय-पक्ष अनुप्रयोगों पर अप्रतिबंधित नियंत्रण उपलब्ध नहीं कराता। Mac निष्पादन-परिवेश, Developer Mode, XCTest, WebDriverAgent, जोड़े गए उपकरण और विकासकर्ता-हस्ताक्षरित परीक्षण मार्गों का खतरा और विश्वास-प्रतिरूप अलग होता है; इनके लिए Mac, हस्ताक्षर-पहचान, उपकरण-युग्मन, परीक्षण-लक्ष्य और नेटवर्क-माध्यम पर नियंत्रण आवश्यक है।

कोई भी नियंत्रण प्रत्येक जोखिम समाप्त नहीं करता। स्क्रीन के प्रॉम्प्ट या सामग्री मॉडल को प्रभावित कर सकते हैं; अनुप्रयोग अपने विन्यास बदल सकते हैं; अनुमतियाँ अत्यधिक व्यापक हो सकती हैं; निर्भरताएँ संकटग्रस्त हो सकती हैं; उपकरण खो सकते हैं; और अधिकृत उपयोगकर्ता क्षमताओं का दुरुपयोग कर सकते हैं। हम विश्वसनीय रिपोर्टों की जाँच करते हैं, प्रभावित प्रमाणीकरण संबंधी विवरण या उपकरण निरस्त अथवा पृथक कर सकते हैं, और आपात-समापन, निरस्तीकरण, विवरण बदलने तथा घटना-रिपोर्टिंग की प्रक्रियाओं का तुरंत उपयोग करने के लिए प्रोत्साहित करते हैं।

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

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

17. संपर्क

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