तीन हप, एउटै होस्ट: वास्तविक गोपनीयता-निर्भरताहरूको गणना
हप-संख्या साझा होस्टिङ, एउटै एडमिन खाता र उही दर्ताकर्ता लुकाउँछ। निर्भरताको बहीखाता बनाउनुहोस्, हरेक पङ्क्तिको मूल्याङ्कन गर्नुहोस् र साझा मानले के जोड्छ हेर्नुहोस्।
दोस्रो हप समयमै उठ्यो र तपाईंको रेखाचित्रले अझै तीन अलग प्रदायक देखाउँछ। त्यसपछि बिलहरू आउँछन् र तीमध्ये दुईले एउटै होस्टिङ कम्पनीको नाम लिन्छन्, उही दर्ताकर्ताले तीनवटै डोमेन राख्छ, र हरेक खाता तपाईंको स्वामित्वको एउटै मेलबक्समा पुनर्स्थापित हुन्छ। टनेल कन्फिगरेसनमा केही पनि बिग्रेको छैन। डिजाइनले हपहरूमुनि रहेका निर्भरताहरू कहिल्यै गनेन, र हप-संख्याले ट्राफिकले लिने बाटो वर्णन गर्छ, त्यसमाथि कार्य गर्न सक्ने पक्षहरूको संख्या होइन।
लक्षण बिलिङमा देखिन्छ, लगमा होइन
तपाईंले यो टनेल लगमा भेट्नुहुन्न, किनकि टनेलले तपाईंले कन्फिगर गरेको ठ्याक्कै गर्छ। प्रमाण सार्वजनिक अभिलेख र खाता सेटिङमा बस्छ: whois संस्थाका नाम जो एन्डपोइन्टबीच मिल्छन्, एउटै नाम सर्भर, साझा दर्ताकर्ता ठेगाना, एउटा भुक्तानी विधि, एउटा नियन्त्रण प्यानल। यीमध्ये हरेक संकेत हो कि स्वतन्त्र रूपमा असफल हुनुपर्ने दुई तह सँगै असफल हुन सक्छन्।
यीमध्ये कुनै पनि संकेतले कुनै एक पक्षले तपाईंको ट्राफिक पढ्न सक्छ भनी प्रमाणित गर्दैन। तिनीहरूले घटाउने कुरा दुई सुरक्षा तह एउटै घटनाबाट सम्झौता हुनुअघि गलत हुनुपर्ने स्वतन्त्र निर्णयहरूको संख्या हो।
तपाईंले वास्तवमै देख्न सक्ने अभिलेखहरू तुलना गर्नुहोस् र के तुलना गर्नुभयो लेख्नुहोस्। हरेक एन्डपोइन्ट ठेगानामा संस्था खोज्नुहोस्, हरेक डोमेनका नाम सर्भर सूचीबद्ध गर्नुहोस्, र श्रृंखलाका हरेक खाताको पुनःप्राप्ति सेटिङ खोल्नुहोस्। जहाँ दुई मान मिल्छन्, मिलान स्वामित्वको बारेमा हो, सञ्चालनको बारेमा हो, वा केवल पुनर्विक्रेताको अगाडिको भागको बारेमा हो भनी नोट गर्नुहोस्। यी फरक निष्कर्ष हुन्, र तिनलाई एक मान्नु नै निर्भरता-समीक्षा अनुमानमा बदलिने बाटो हो।
तार्किक बाटो कोर्नुहोस्, त्यसपछि निर्भरता नक्सा
दुई रेखाचित्र चाहिन्छ, र धेरैजसो मानिसले पहिलो मात्र कोर्छन्। तार्किक बाटोले हरेक सुरक्षा तह कहाँ अन्त्य हुन्छ र त्यो एन्डपोइन्टले के अवलोकन गर्न सक्छ देखाउँछ। निर्भरता नक्साले यीमध्ये हरेक एन्डपोइन्ट कसले सञ्चालन र प्रशासन गर्छ देखाउँछ, जो पूर्ण रूपमा छुट्टै नामहरूको समूह हो।
| Layer to record | Evidence you can collect | What a shared value would mean |
|---|---|---|
| Endpoint operator | Published operator, contract, support contacts | The same party sees two traffic layers |
| Compute and hosting | Address ranges, hosting brands, platform status pages | One administrative action affects two machines |
| Network dependency | Endpoints and transit links near the observation point | Two paths share a segment that could be watched once |
| Management | Control panels, SSH keys, staff with access | One credential compromise crosses both layers |
| Account linkage | Registration records, payment method, recovery mail | Two services can be tied to one identity |
हरेक पङ्क्ति भर्नुको सट्टा मूल्याङ्कन गर्नुहोस्। ज्ञात भन्नाले त्यो भन्ने अभिलेख देख्नुभयो, अनुमानित भन्नाले एउटा अवलोकनले त्यसलाई नटुंग्याई समर्थन गर्छ, र अज्ञात भन्नाले केही फेला परेन। साझा होस्टिङ ब्रान्ड साझा पूर्वाधारको अनुमान हो, साझा ग्राहक डाटाबेसको भनाई होइन। केवल अपेक्षित निष्कर्षका लागि सुविधाजनक छ भनेर अनुमानलाई चुपचाप ज्ञात तथ्यमा उचाल्नु हुँदैन।
खाली पङ्क्ति आफैंमा एउटा निष्कर्ष हो। कुन तथ्य थाहा पाए निर्णय बदलिन्छ भनी बताउँछ, र त्यो परिष्कृत विरोधीले के गर्न सक्छ भन्ने अर्को अनुच्छेदभन्दा बढी उपयोगी छ।
AS नम्बरले राउटिङ प्रश्नको मात्र उत्तर दिन्छ
स्वायत्त प्रणाली राउटिङ प्रशासनको अवधारणा हो, ठेगानाहरूको समूह जो अन्य सञ्जाललाई एउटै सुसंगत राउटिङ दृश्यका रूपमा प्रस्तुत गरिन्छ। त्यसैले फरक AS नम्बरहरूले कर्पोरेट स्वामित्व, छुट्टै कर्मचारी वा स्वतन्त्र कानुनी नियन्त्रणबारे केही निर्णायक भन्दैनन्। उल्टो त्रुटि पनि उत्तिकै सामान्य छ: एउटै AS मा दुई एन्डपोइन्ट स्वतः एक पक्षले विशिष्ट प्रयोगकर्ता पहिचान गर्ने घटना होइन।
तपाईंलाई संख्याहरू चाहिएको भए, अनुमान गर्नुको सट्टा तिनलाई समाधान गर्नुहोस्। तलको ठेगाना प्लेसहोल्डर हो, र फ्ल्यागले उपकरणलाई हरेक हपलाई त्यो घोषणा गर्ने AS सँग लेबल गर्न भन्छ।
mtr --aslookup --report --report-cycles 5 203.0.113.9त्यो आउटपुटलाई राउटिङको मापनको रूपमा लिनुहोस्, स्वामित्व वा पूर्ण ट्राफिक बाटोको होइन। तपाईंले सुरु गर्ने पहुँच सञ्जाल र एन्डपोइन्टबीचको ट्रान्जिट निर्भरता छुट्टै प्रश्न हुन् जसको उत्तर एन्डपोइन्ट ठेगानाले दिन सक्दैन। जब कुनै मार्ग वा रिले छनोट तपाईं बसेको ठाउँबाट अवलोकन गर्न सकिँदैन, त्यसलाई अज्ञात भनी चिन्ह लगाउनुहोस्, कुनै विशेष सञ्जालले आज कसरी मार्ग छान्छ भन्ने सामान्य दाबी भित्र्याउनुको सट्टा। अवलोकन नगरिएको कुरा अवलोकन-असम्भवसँग एउटै होइन, तर त्यो प्रमाण पनि होइन।
जोखिमको नाम लिनुअघि अवलोकनको नाम लिनुहोस्
धेरैजसो निर्भरता-समीक्षामा तीन निष्कर्ष मिसिन्छन्, र तिनलाई छुट्याउनु कामको ठूलो भाग हो। इन्क्रिप्टेड ट्राफिकको निष्क्रिय देखिनेता एउटा निष्कर्ष हो। साझा व्यवस्थापन पहुँच अर्को हो, किनकि यसले दृश्य होइन, कार्य जनाउँछ। खाता-संलग्नता तेस्रो हो, किनकि यसले कुनै प्राविधिक पहुँच नदिई पहिचानहरू जोड्छ।
यसमा RFC 6973 को गोपनीयता मार्गदर्शनले यसका लागि व्यावहारिक स्वरूप दिन्छ: हरेक इकाईले के सिक्छ सूचीबद्ध गर्नुहोस्, त्यसपछि त्यसलाई अन्यत्र राखिएको सूचनासँग कसरी जोड्न सकिन्छ भनी सोध्नुहोस्। मार्गमा दुई बिन्दुले समान ट्राफिक ढाँचा अवलोकन गरेमा सहसम्बन्धको चिन्ता जगाउन सक्छ, तर तिनले कसैको पहिचान भयो भन्ने मापन गरिएको सम्भावना दिँदैनन्। चिन्ता लेख्नुहोस्, त्यसपछि त्यसलाई पुष्टि गर्ने अवलोकन लेख्नुहोस्।
दुई टनेल सेवा र भाडामा लिइएको प्रोक्सीको श्रृंखलामा फर्कनुहोस्। यदि प्रोक्सीको व्यवस्थापन प्रमाणपत्रले एउटा टनेल सर्भरसँग पुनःप्राप्ति खाता साझा गर्छ भने, एउटै प्रशासनिक सम्झौताले दुवै सीमा पार गर्न सक्छ। यदि एकमात्र ओभरल्याप एउटा होस्टिङ कम्पनीले दुवै मेसिन चलाउनु हो भने, समीक्षाले त्यो कम्पनीसँग कुन अधिकार छन् र कुन सूचना सुरक्षित रहन्छ भनी बताउनुपर्छ। उही तीन हप, फरक निष्कर्ष।
बहीखाता गुमनामताको प्रमाणपत्र होइन र कहिल्यै हुनेछैन। यसको मूल्य साँघुरो र बढी व्यावहारिक छ: यसले स्वतन्त्रता कहाँ स्थापित छ, कहाँ अनुमान गरिएको छ, र कुन एउटा अज्ञात पङ्क्तिले निर्णय सार्छ देखाउँछ। अर्को पटक त्यही पङ्क्ति छान्नुहोस्, र त्यसको उत्तर नआउँदासम्म रेखाचित्रको बाँकी भाग जस्ताको तस्तै राख्नुहोस्।