खरिदमा खुला स्रोत VPN किन अस्वीकार गरिन्छ
खुला स्रोतको विरोध गर्ने समीक्षक सामान्यतया एउटा आवश्यकता रक्षा गर्छ, इजाजतपत्रको रुचि होइन। कुन हो भनेर सोध्नुहोस्, त्यसपछि त्यसको उत्तर दिने कागजात तयार गर्नुहोस्।
खुला स्रोत उल्लेख गर्ने अस्वीकृति विरलै इजाजतपत्रसँग सम्बन्धित हुन्छ। समीक्षक सामान्यतया एउटा आवश्यकता रक्षा गर्छ: कसैले तैनाथ गरिएको संस्करण मर्मत गरोस्, स्थापित बिल्ड पहिचान गर्न सकियोस्, मूल्यांकनले जोडिने कुरा समेटोस्, वा जडान फिर्ता लिन सकियोस्। त्यसपछिको बहस सामान्यतया कसैले नसोधेको प्रश्नको उत्तर दिन्छ।
इजाजतपत्रको बचाउ गर्नु अघि कुन आवश्यकता लागू हुन्छ सोध्नुहोस्। उत्तरले तपाईंलाई कुन कागजात चाहिन्छ भनी निर्धारण गर्छ।
लेबल नै आवश्यकता होइन
पढ्न योग्य स्रोत कोड भनेको प्रकाशित कार्यान्वयन जाँच्न सकिन्छ भन्ने हो। यसको अर्थ कसैले यो जाँच्यो, गेटवेमा रहेको बिल्ड प्रकाशितसँग मिल्छ, वा कुनै मर्मतकर्ताले तपाईंको तैनाथीलाई सुधार तिर्न बाँकी छ भन्ने होइन। यीमध्ये प्रत्येक छुट्टै स्वामी भएको छुट्टै दाबी हो, र यीमध्ये एक चाहिने समीक्षक अरूले सन्तुष्ट हुँदैन। दाबी ठूलो स्वरले भन्नु सामान्यतया कुराकानी बदल्न पर्याप्त हुन्छ।
उल्टो गल्ती पनि उत्तिकै सामान्य छ। व्यापारिक इजाजतपत्रले सहयोगले तपाईं निर्भर गर्ने सुविधा समेट्छ, कुनै मूल्यांकनले तपाईं तैनाथ गर्ने घटक जाँच्यो, वा विक्रेताले तपाईंको मर्मत अवधिभित्र सुधार पठाउँछ भनी प्रमाणित गर्दैन। इजाजतपत्रले वितरणका सर्त वर्णन गर्छ, तर खरिद निर्णय भरोसासँग सम्बन्धित हुन्छन्। दुवै हालतमा इजाजतपत्र उत्तरको सबैभन्दा कम सूचनामूलक भाग हो।
क्लाइन्ट र सेवालाई अलग राख्नुहोस्। डेस्कटप क्लाइन्टको अडिटले साझेदारको गेटवे कन्फिगरेसन, उसको पहिचान प्रदायक वा उसका अपरेटरहरूले खाता हटाउने तरिकाबारे केही भन्दैन। तपाईंले संकलन गर्ने जुनसुकै प्रमाण साझेदारलाई भरोसा गर्न भनिएको सीमासँग मिल्नुपर्छ।
चिन्तालाई कागजात बनाउनुहोस्
स्वीकृति दिनेलाई आवश्यकता एक वाक्यमा भन्न भन्नुहोस्, त्यसपछि त्यो पूरा गर्ने कागजातको नाम भन्नुहोस्। अस्पष्ट आश्वासनले नै यी कुराकानीलाई विचारधाराको बहसमा बदल्छ।
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework यहाँ एउटा साँघुरो कारणले उपयोगी छ: यसले खरिद कुराकानीलाई अभ्यास र आपूर्तिकर्तासँगको सञ्चारको साझा शब्दावलीको वरिपरि ढाँचामा राख्छ। यसले लेबलबारे बहस गर्नुको सट्टा निर्दिष्ट प्रमाण माग्न समर्थन गर्छ, र यो कुनै विशेष VPN ले उत्तीर्ण गर्ने प्रमाणपत्र होइन।
बीचको स्तम्भले के गर्छ हेर्नुहोस्। हरेक पङ्क्तिले हुने वा नहुने कागजात माग्छ, र यसले रायलाई कसैले बनाउन वा अस्वीकार गर्न सक्ने नतिजामा बदल्छ।
क्लाइन्ट र सेवा अलग राख्नुहोस्
क्लाइन्ट अनुप्रयोगको लागि सहयोग सम्झौता तपाईंको ट्राफिक पुग्ने सर्भरबारे प्रतिबद्धता होइन। प्रमाण प्रस्तुत गर्नु अघि बाटोका कुन भाग साझेदारले चलाउँछ र कुन भाग तपाईंले उसको तर्फबाट चलाउनुहुन्छ चिन्ह लगाउनुहोस्। दुवै मिसाउँदा पूर्ण देखिने तर केही पनि जवाफ नदिने कागजातको थुप्रो बन्छ।
यदि तैनाथी तपाईंको हो भने, साझेदारले एउटा पहिचान र एउटा पहुँच नियममा मात्र भरोसा गर्नुपर्ने हुनसक्छ, जुन तपाईंको सम्पूर्ण सफ्टवेयर आपूर्ति शृंखलामा भरोसा गर्नुभन्दा धेरै सानो अनुरोध हो। यदि तैनाथी उसको हो भने, तपाईंले रुचाउनुभएको क्लाइन्ट अप्रासंगिक हुनसक्छ र गेटवे कन्फिगरेसन विषय बन्छ। दोस्रो बैठक अघि तपाईं कुन स्थितिमा हुनुहुन्छ पहिचान गर्नुले एउटा समीक्षा चक्र बचाउँछ।
त्यसपछि समीक्षाहरू साँच्चै असफल हुने परिचालन प्रश्न जाँच्नुहोस्: कसले खाता हटाउँछ, कति छिटो, र पछि के प्रमाण रहन्छ। हटाउने प्रक्रिया नभएको राम्ररी कागजात गरिएको मूल्यांकन पनि खुला निष्कर्ष नै रहन्छ।
बहसले होइन, निर्णयले टुङ्ग्याउनुहोस्
आदानप्रदान लिखित नतिजासँग टुङ्ग्याउनुहोस्: स्वीकृत संस्करण, त्यसमा जोडिएका नियन्त्रण, नाम दिइएका अपरेटर, अझै बाँकी प्रमाण र ती बुझाउनुपर्ने मिति। नटुङ्गिएको कुरा सामान्य स्वीकृति वक्तव्यमा समाहित गर्नुको सट्टा सर्तका रूपमा अभिलेख गर्नुपर्छ।
यदि नीतिले कुनै निर्दिष्ट स्वीकृत उत्पादनको नाम लिन्छ भने, कसैले अधिकार नदिएको समानान्तर व्यवस्था बनाउनुको सट्टा अपवाद मार्ग प्रयोग गर्नुहोस्। प्रभावशाली प्राविधिक तर्कले अनुमति दिँदैन, र अनौपचारिक तैनाथी पत्ता लाग्न बाँकी रहेको निष्कर्ष हो।
यदि कुनै आवश्यकता साँच्चै पूरा गर्न सकिँदैन भने, स्वीकृत विकल्पमा जानुहोस् र किन भन्नुहोस्। यो अभ्यासको उद्देश्य संस्थाले केमा भरोसा गर्न सक्छ भनी स्थापित गर्नु हो, र स्पष्ट होइन भन्ने पछि कसैले पनि रक्षा गर्न नसक्ने स्वीकृतिभन्दा राम्रो नतिजा हो।