सिस्टम डिज़ाइन इंटरव्यू: आप Web Threat Model के साथ ब्राउज़र सिस्टम की समीक्षा कैसे करेंगे?

प्रॉम्प्ट और दायरा

एक ऐसे आर्किटेक्चर की समीक्षा करें जहां एक ब्राउज़र एक मल्टी-टेनेंट वेब एप्लिकेशन को एक्सेस करता है। आप सीमाओं और डेटा प्रवाहों को कैसे रेखांकित करेंगे, परिसंपत्तियों और खतरे के स्रोतों की पहचान कैसे करेंगे, लक्षित, कार्यान्वयन और बाहरी खतरों में अंतर कैसे करेंगे, और प्रतिक्रियाओं को सत्यापन योग्य सुरक्षा निश्चरों में कैसे बदलेंगे?

W3C Security Interest Group ने 26 मई 2026 को Threat Model for the Web Group Note Draft प्रकाशित किया। यह जानकारीपूर्ण और गैर-मानक (non-normative) है, जिसका उद्देश्य नए Web विनिर्देशों (specifications) की सुरक्षा समीक्षाओं का समर्थन करना है। इसके सरलीकृत दृष्टिकोण में एक ब्राउज़र, DNS, एक Web Server, उपयोगकर्ता और नेटवर्क ऑपरेटर शामिल हैं। साक्षात्कार विधि और साक्ष्य श्रृंखला (evidence chain) का परीक्षण करता है, न कि ड्राफ्ट को याद रखने का।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

साक्षात्कारकर्ता भेद्यता (vulnerability) सूची से पहले एक सिस्टम और डेटा-प्रवाह चित्र देखना चाहता है; स्पष्ट परिसंपत्तियां, हितधारक और खतरे के स्रोत; खतरों, कमजोरियों, प्रभावों और प्रतिक्रियाओं के बीच अंतर; और जांचने योग्य निश्चरों के रूप में व्यक्त सुरक्षा लक्ष्य। बताएं कि मॉडल कैसे विकसित होता है और डिज़ाइन व समीक्षा दस्तावेजों को कैसे सामग्री प्रदान करता है। एक मजबूत उत्तर अमूर्तता सीमाओं (abstraction boundaries), हमलावर की ऐसी मान्यताओं जिन्हें मॉडल नहीं किया गया है, और दायरे से बाहर की निर्भरताओं को कैसे सौंपा जाता है, यह स्पष्ट करता है।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

क्या हम ब्राउज़र प्लेटफ़ॉर्म, किसी एक वेब एप्लिकेशन, या उनके बीच एक नए Web API की समीक्षा कर रहे हैं?
क्या क्रेडेंशियल, उपयोगकर्ता डेटा, कोड, सत्र (sessions), नेटवर्क मेटाडेटा और उपलब्धता सभी दायरे में हैं?
क्या प्रवाह में तीसरे पक्ष की स्क्रिप्ट, CDNs, DNS, पहचान प्रदाता और क्रॉस-साइट अनुरोध शामिल हैं?
क्या यह एक आर्किटेक्चर समीक्षा है, रिलीज-पूर्व सुरक्षा समीक्षा है, या परिचालन परिवर्तन समीक्षा है?
कौन सी निर्भरताएं और बाहरी खतरे स्पष्ट रूप से दायरे से बाहर हैं, और फॉलो-अप का स्वामित्व किसके पास है?

30-सेकंड का उत्तर ढांचा

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

चरण-दर-चरण विस्तृत विश्लेषण

1. पहले सिस्टम की सीमा बनाएं

एक न्यूनतम उपयोग योग्य परिदृश्य से शुरुआत करें: ब्राउज़र प्रक्रिया और स्टोरेज, DNS सेवा, Web Server, उपयोगकर्ता, साइट व्यवस्थापक और नेटवर्क ऑपरेटर। प्रत्येक घटक को एक संक्षिप्त अद्वितीय आईडी और उसकी जिम्मेदारी तथा ट्रस्ट बाउंड्री का वर्णन करने वाला एक गद्य शब्दकोश दें। यदि किसी नए API की समीक्षा कर रहे हैं, तो एक अलग आरेख बनाने के बजाय इसके इनपुट, आउटपुट, अनुमतियाँ और निर्भरताएँ इसी चित्र में रखें।

2. परिसंपत्तियों और हितधारकों की गणना करें

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

3. खतरे के स्रोतों और उच्च-स्तरीय खतरों को रिकॉर्ड करें

प्रत्येक खतरे के लिए, उसका स्रोत, लक्षित परिसंपत्ति, हमले का मार्ग और प्रभाव बताएं। स्पूफिंग, छेड़छाड़ (tampering), प्रकटीकरण (disclosure), सेवा से इनकार (denial of service), और प्राधिकरण बाईपास सूची को व्यवस्थित कर सकते हैं, लेकिन प्रत्येक प्रविष्टि को एक ठोस प्रवाह से मैप किया जाना चाहिए। खतरों को विनिर्देश द्वारा संबोधित लक्षित खतरों, कार्यान्वयनकर्ताओं को ज्ञात लेकिन मानक बाधाओं के लिए अनुपयुक्त कार्यान्वयन खतरों, या निर्भरता और परिनियोजन से उत्पन्न बाहरी खतरों के रूप में वर्गीकृत करें।

4. प्रतिक्रियाओं को निश्चरों में बदलें

सुरक्षा निश्चर (security invariant) एक ऐसी स्थिति है जो प्रत्येक अनुमत निष्पादन के लिए लागू होनी चाहिए, जैसे "एक क्रॉस-ओरिजिन प्रतिक्रिया कभी भी किसी अनधिकृत कॉलर को क्रेडेंशियल नहीं देती है" या "एक रीडायरेक्ट स्क्रिप्ट-ओरिजिन और अनुमति सीमाओं को बाईपास नहीं कर सकता है।" प्रत्येक निश्चर को एक नियंत्रण और परीक्षण, लॉग या ऑडिट साक्ष्य से बांधें। चिह्नित करें कि क्या यह एक विनिर्देश गारंटी है, कार्यान्वयन गारंटी है, या परिनियोजन धारणा है।

text

component/flow -> asset -> threat source -> impact
             -> invariant -> control -> evidence -> owner

5. निर्भरताओं और बाहरी खतरों को संभालें

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

6. मॉडल को जीवनचक्र के साथ संरेखित रखें

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

7. साबित करें कि प्रतिक्रियाएं काम करती हैं

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

उच्च गुणवत्ता वाला नमूना उत्तर

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

सामान्य गलतियाँ

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

अनुवर्ती प्रश्न और उत्तर

पहले प्रत्येक हमलावर की गणना क्यों न करें?

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

आप तीसरे पक्ष की स्क्रिप्ट को कैसे संभालते हैं?

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

कोई बाहरी निर्भरता किसी परियोजना के लिए जोखिम कब बन जाती है?

जब इसकी सुरक्षा धारणा सीधे दायरे में शामिल किसी परिसंपत्ति या निश्चर को प्रभावित करती है, या परियोजना निर्भरता के वादे को सत्यापित नहीं कर सकती है, तो इसे फुटनोट के बजाय शमन या स्वीकार करने वाले स्वामी के साथ वर्तमान जोखिम के रूप में दर्ज करें।

यदि सुरक्षा समीक्षा मॉडल बहुत जटिल हो तो क्या होगा?

प्रमुख जोखिमों को कवर करने वाला एक न्यूनतम आरेख रखें, प्रोटोकॉल या परिनियोजन विवरण को लिंक किए गए उप-मॉडलों में विभाजित करें, और घटक व प्रवाह आईडी के साथ पता लगाने की क्षमता (traceability) बनाए रखें। किसी महत्वपूर्ण सीमा को हटाकर जटिलता को कम न करें।

आप किसी उत्पाद स्वामी (product owner) को अवशिष्ट जोखिम कैसे समझाते हैं?

प्रभावित परिसंपत्तियों, संभावित मार्गों, वर्तमान नियंत्रणों, परीक्षण साक्ष्यों और व्यावसायिक प्रभाव का वर्णन करें। लागत, समय सीमा और एक स्पष्ट स्वीकार करने वाले स्वामी के साथ विकल्प प्रदान करें; "पूरी तरह से सुरक्षित" या असमर्थित संभाव्यता दावों से बचें।