वेब निगरानी उद्देश्यबाट सुरु हुन्छ, क्याप्चर बिन्दुबाट होइन। सक्रिय ग्राहक गणना, API कलको समय मापन र सन्देश मुख्य भाग पढ्ने प्रत्येकलाई फरक प्रमाण र फरक गोपनीयता निर्णय चाहिन्छ। सुरक्षित HTTPS अगाडि पठाउने गेटवेले पृष्ठ सामग्री होइन, जडानहरू देख्छ। गलत तह चुन्दा समृद्ध देखिने तर केही पनि जवाफ नदिने डेटा प्राप्त हुन्छ।

डेटा स्रोतभन्दा पहिले प्रश्नको नाम राख्नुहोस्

डेटाले समर्थन गर्नुपर्ने सञ्चालन निर्णयबाट सुरु गर्नुहोस्। उपलब्धता प्रश्नलाई गणना र समय चाहिन्छ, अनुरोध प्रश्नलाई मार्ग र स्थिति कोड चाहिन्छ, र सामग्री प्रश्नलाई सन्देश मुख्य भाग चाहिन्छ। भित्रतर्फको प्रत्येक कदम संवेदनशीलता र इन्जिनियरिङ जटिलता थप्छ। सङ्कलन सुरु हुनुअघि सेवा मालिक र सुरक्षा मालिकबाट दर्शक, उद्देश्य र व्यवहारको स्वीकृति लिनुहोस्, किनकि सुरुङ चलाउनु त्यो निर्णय होइन।

प्रश्न एक वाक्यमा लेख्नुहोस् र सङ्कलन योजनाको छेउमा राख्नुहोस्। यही दायराको एकमात्र भरपर्दो नियन्त्रण हो।

गेटवेले के देखाउन सक्छ र के सक्दैन

राम्ररी सुरक्षित HTTPS अगाडि पठाउने गेटवेले सामान्यतया ठेगाना, पोर्ट र मात्रा देख्छ, अनुरोध पङ्क्ति वा मुख्य भाग होइन।

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

conntrack सूचीले प्रवाह र अनुवाद देखाउँछ, र छोटो क्याप्चरले पढ्न योग्य एप सामग्री बिना प्याकेट देखाउँछ। ट्राफिक बग्छ कि बग्दैन, कति, र कुन अन्त्य बिन्दुबीच — यसको जवाफ दिन यति पर्याप्त छ। यो URL सूची होइन, र सामान्य CONNECT प्रोक्सीले एपको TLS अन्त्य नगरी इन्क्रिप्ट गरिएको आदानप्रदान अगाडि पठाउँछ। कसैले त्यो स्थानबाट अनुरोध मार्गको वाचा गर्दा सोध्नुहोस् कुन घटकले डिक्रिप्ट गर्छ र कसको विश्वासमा।

एप लगहरूले धेरैजसो अनुरोध प्रश्नको जवाफ दिन्छन्

तपाईंले चलाउने एपका लागि त्यसको आफ्नै समर्थित लगिङले सामान्यतया अरूका जडान डिक्रिप्ट नगरी अनुरोध-स्तरको प्रश्नको जवाफ दिन्छ।

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

स्वास्थ्य अनुरोधले ग्राहकको स्थानबाट उपलब्धता मापन गर्छ, र पहुँच लगले सर्भरले पहिले नै राख्न चुनेका फिल्ड रेकर्ड गर्छ। कामका लागि आवश्यक फिल्ड चुन्नुहोस् र बाँकी बाहिर राख्नुहोस्, किनकि URL ले पनि संवेदनशील प्यारामिटर बोक्न सक्छ। लग पङ्क्ति त्यो सेवाको प्रमाण हो, प्रयोगकर्ताले सुरुङबाट पुगेको हरेक अन्य सेवाको होइन। सङ्कलन साँघुरो राख्दा राख्ने प्रश्न पनि सानो रहन्छ, त्यसैले आवश्यकता जन्माउने विचार-प्रयोगभन्दा छोटो विन्डो तोक्नुहोस्।

अवरोधन छुट्टै विश्वास डिजाइन हो

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

सङ्कलन विन्डोको अन्त्यमा, मालिकहरूमार्फत कन्फिगरेसन र त्यसको विश्वास सामग्री हटाउनुहोस्, र सहमत नीति अन्तर्गत राखिएको प्रमाणको निस्तारण गर्नुहोस्। बताइएको उद्देश्यका लागि पर्याप्त भरपर्दो जानकारी नै सफलताको मापदण्ड हो, सबैभन्दा ठूलो सम्भावित क्याप्चर होइन।

सम्बन्धित लेखहरू