सेवा

एप्लिकेशन सुरक्षा इंजीनियरिंग

यह निर्माण का फ़ैसला है, लॉन्च से पहले का चरण नहीं।

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

फ़ैसला

यह कब सही फ़ैसला है।

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

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

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

आपको क्या मिलता है

काम में क्या शामिल है।

ऑथराइज़ेशन डिफ़ॉल्ट रूप से

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

हमला करने वाले टेस्ट

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

सेशन और टोकन का प्रबंधन

एक्सपायरी, रिफ़्रेश और रद्दीकरण ठीक से डिज़ाइन किए हुए, ताकि समाप्त सेशन हमेशा दोहराने के बजाय साफ़-साफ़ ख़त्म हो।

सीक्रेट्स का प्रबंधन

क्रेडेंशियल रिपॉज़िटरी और कॉन्फ़िग फ़ाइलों से बाहर, बिना रीडिप्लॉय बदले जा सकने वाले, और उनकी रोटेशन प्रक्रिया लिखित।

निर्भरता और सप्लाई चेन

स्वचालित निर्भरता समीक्षा, और यह नीति कि रिलीज़ कब रोकी जाए, साथ में लॉकफ़ाइल और दोहराए जा सकने वाले बिल्ड।

ट्रांसपोर्ट और हेडर

TLS कॉन्फ़िगरेशन, HSTS, CSP और बाक़ी सब ओरिजिन पर सेट और सत्यापित, उन प्रोटोकॉल-स्तर की सेटिंग्स सहित जो चुपचाप क्लाइंट तोड़ देती हैं।

स्टैक

हम इसे किससे बनाते हैं।

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

समीक्षा

डेटा और भूमिकाओं पर ख़तरे का मॉडल, डिज़ाइन तय होने से पहले।

परीक्षण

CI में ऑथराइज़ेशन टेस्ट, हर बिल्ड पर निर्भरता स्कैनिंग, और अहम रास्तों की समय-समय पर मैनुअल समीक्षा।

इंफ़्रास्ट्रक्चर

न्यूनतम-अधिकार वाले सर्विस अकाउंट, नेटवर्क सीमाएँ, और ऐसे बैकअप जिनकी रिस्टोर प्रक्रिया सचमुच आज़माई जा चुकी हो।

निगरानी

ऑथेंटिकेशन विफलताओं, ऑथराइज़ेशन इनकारों और एरर दर पर अलर्ट, क्योंकि एक कोशिश भी अपने आप में एक संकेत है।

प्रतिक्रिया

उस दिन के लिए लिखित प्रक्रिया जब कुछ ग़लत हो — और वह पहले से तय।

तुलना

लॉन्च से पहले स्कैन बनाम सुरक्षा को निर्माण का फ़ैसला मानना।

स्कैनर चलाने लायक़ हैं और असली चीज़ें पकड़ते हैं। पर वे उस क़िस्म की ख़ामी नहीं पकड़ते जो कारोबार को सचमुच महँगी पड़ती है।

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

यह कैसे चलता है

पहली बातचीत से लाइव होने तक।

इस तरह के काम के लिए अनुमानित। पायलट वैकल्पिक नहीं है — जब तक इस्तेमाल करने वाले यह न कहें कि यह टिकता है, कुछ भी स्विच नहीं किया जाता।

  1. 3-5 दिन

    ख़तरे का मॉडल

    डेटा, भूमिकाएँ, और हमलावर असल में क्या चाहेगा — डिज़ाइन तय होने से पहले।

  2. 2-3 हफ़्ते

    बुनियाद

    हर एंडपॉइंट पर सर्वर-साइड ऑथराइज़ेशन, सेशन और टोकन प्रबंधन, और रिपॉज़िटरी से बाहर सीक्रेट, साथ में लिखित रोटेशन प्रक्रिया।

  3. 1-2 हफ़्ते

    हमलावर की तरह किए गए टेस्ट

    ऐसे स्वचालित टेस्ट जो टेनेंट की सीमा लाँघते हैं, भूमिकाएँ बढ़ाते हैं और समाप्त टोकन दोबारा भेजते हैं, और CI में जुड़े हैं ताकि गिरावट पर बिल्ड फ़ेल हो जाए।

  4. लगातार

    सतत

    निर्भरता नीति, ऑथराइज़ेशन इनकारों पर अलर्ट, और ज़रूरत पड़ने से पहले तय की गई लिखित प्रतिक्रिया प्रक्रिया।

लॉन्च के बाद

क्या बदलता है।

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

जानबूझकर गुणात्मक रूप में बताया गया। हम ऐसे प्रतिशत सुधार प्रकाशित नहीं करते जिन्हें हम किसी नामित क्लाइंट से, उनकी सहमति के साथ, जोड़ न सकें।

सवाल

आम सवाल।

क्या यह पेनिट्रेशन टेस्ट है?

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

हमारे पास पहले से स्कैनर है। क्या वह काफ़ी नहीं?

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

क्या आप हमारे बने-बनाए एप्लिकेशन की समीक्षा कर सकते हैं?

हाँ। मौजूदा कोडबेस की समीक्षा आमतौर पर एक से दो हफ़्ते लेती है और तर्क सहित प्राथमिकता वाली सूची देती है, कोई कच्चा स्कैनर एक्सपोर्ट नहीं। सुधार हम लागू कर सकते हैं या आपकी टीम को सौंप सकते हैं।

क्या इससे काम धीमा पड़ता है?

शुरुआत में थोड़ा, और बाद में जोड़ने से कहीं कम। ऑथराइज़ेशन टेस्ट और निर्भरता नीति शुरू में कुछ दिन जोड़ते हैं; लॉन्च के बाद परमिशन मॉडल दोबारा बनाने में हफ़्ते और एक माइग्रेशन लगता है।

हमारी टीम छोटी है। क्या यह हमारे लिए ज़्यादा नहीं?

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

क्या आप अनुपालन प्रमाणपत्र दिलाते हैं?

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