छोटे प्लेटफ़ॉर्म के लिए थ्रेट मॉडलिंग

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

पूर्णता से अधिक क्रम मायने रखता है

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

क्रम संभावना × स्वयं पर पड़ने वाली लागत के अनुसार तय किया जाना चाहिए, न कि परिदृश्य कितना डरावना लगता है इसके अनुसार। एक राष्ट्र-राज्य प्रतिद्वंद्वी किसी भी सूची का सबसे भयावह बिंदु होता है और लगभग हर छोटे प्लेटफ़ॉर्म के लिए सबसे कम संभावित भी — जबकि किसी पूर्व ठेकेदार से क्रेडेंशियल लीक होना नीरस, अत्यंत सामान्य, और आमतौर पर विनाशकारी होता है।

सात प्रतिद्वंद्वी, संभावना के अनुसार क्रमबद्ध

प्रतिद्वंद्वी, संभावना के अनुसार, और उन्हें क्या कम करता है

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

होस्टिंग का निर्णय किन्हें प्रभावित करता है

सात में से दो, और आंशिक रूप से एक तीसरा। यही अनुपात इस अभ्यास का सबसे उपयोगी परिणाम है, और यही कारण है कि प्रदाता चुनने से पहले इसे करने से किसी भी तुलना-तालिका से ज़्यादा पैसा बचता है।

एक घंटे वाला संस्करण

1. यह सूचीबद्ध करें कि वास्तव में आपके पास क्या है (10 मिनट)। सिस्टम नहीं — डेटा। उपयोगकर्ता के ईमेल पते, भुगतान रिकॉर्ड, निजी संदेश, अपलोड की गई फ़ाइलें, अन्य सेवाओं के क्रेडेंशियल। यह लिख लें कि किसे खोना सबसे बुरा होगा और किसका लीक होना सबसे बुरा होगा; ये शायद ही कभी एक ही चीज़ होते हैं।
2. यह सूचीबद्ध करें कि हर एक को कौन चाहेगा (10 मिनट)। स्पष्ट रहें। “हैकर्स” कोई प्रतिद्वंद्वी नहीं है; “खातों को आगे बेचने के लिए क्रेडेंशियल डंप ख़रीदने वाला कोई व्यक्ति” है, और इसका मतलब अलग बचाव-उपाय है।
3. संभावना × लागत के अनुसार क्रम तय करें (10 मिनट)। यह नज़रअंदाज़ करें कि हर बिंदु कितना नाटकीय लगता है। नीरस बिंदु ही हावी रहते हैं।
4. शीर्ष तीन के लिए, पहला घंटा लिखें (20 मिनट)। हर एक के पहले साठ मिनट में क्या किया जाएगा। यदि इसका उत्तर न मिल सके, तो यही निष्कर्ष है — और यह स्वयं क्रम-सूची से भी अधिक मूल्यवान है।
5. यह चिह्नित करें कि इंफ़्रास्ट्रक्चर के चुनाव किन्हें प्रभावित करते हैं (10 मिनट)। आमतौर पर शीर्ष पाँच में से दो। अब यह पता चल जाता है कि आपका होस्टिंग निर्णय वास्तव में क्या ख़रीद रहा है।

जब भी कोई संरचनात्मक बदलाव हो — नया डेटा प्रकार, नया इंटीग्रेशन, किसी का संगठन छोड़ना — तब इसे दोबारा किया जाना चाहिए, न कि किसी तय समय-सारणी पर। कैलेंडर-आधारित समीक्षाएँ छूट जाती हैं; घटना-आधारित समीक्षाएँ पूरी होती हैं, क्योंकि सामने एक ठोस वजह होती है।

तीन गलतियाँ जो पूरी कवायद को बेकार कर देती हैं

ऐसे प्रतिद्वंद्वी का मॉडल बनाना जो दिलचस्प लगे। किसी राष्ट्र-राज्य की क्षमता के बारे में सोचना किसी सार्वजनिक रिपॉज़िटरी में लीक हुए API टोकन के बारे में सोचने से कहीं ज़्यादा रोमांचक लगता है। इनमें से एक चीज़ लगभग हर उस व्यक्ति के साथ हो चुकी है जिसे आप जानते हैं। ईमानदारी से क्रम तय करने पर उबाऊ बिंदु ही जीतते हैं, और यही पूरी बात है।

नियंत्रण को परिणाम समझ लेना। “हम एन्क्रिप्शन इस्तेमाल करते हैं” तब तक कोई शमन-उपाय नहीं है जब तक यह न बताया जा सके कि यह क्या रोकता है और क्या नहीं। किसी चल रहे सर्वर पर पूर्ण-डिस्क एन्क्रिप्शन डिस्क के इमारत से बाहर जाने की स्थिति से बचाता है; यह लाइव मशीन पर शेल रखने वाले घुसपैठिए के ख़िलाफ़ कुछ नहीं करता, क्योंकि वॉल्यूम पहले से ही अनलॉक्ड होता है।

निर्णय की जगह एक दस्तावेज़ बना देना। यदि अभ्यास के बाद कुछ भी नहीं बदला — कोई अनुमति रद्द नहीं हुई, कोई बैकअप जाँचा नहीं गया, प्रदाता से कोई सवाल नहीं पूछा गया — तो यह थ्रेट मॉडल नहीं था, बस एक दोपहर थी। परिणाम तीन ऐसे कार्य होने चाहिए जिनमें से हर एक के आगे एक नाम लिखा हो।

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

प्लेटफ़ॉर्म चलाने वाले इंजीनियरों द्वारा लिखा गया, और 1 महीना पहले दोबारा पढ़ा गया। यदि यहां कुछ गलत है या पुराना हो चुका है, तो पैनल से बताएं — इनमें से लगभग आधी बातें वहीं से आई हैं।