RDP क्लाइंट बदल देता है: डेटाबेस दूसरा होस्ट क्यों देखता है

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

दूसरे अनुरोध का अपना क्लाइंट पता है

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

मूल को लैपटॉप से नहीं, सत्र के भीतर से पढ़ें, फिर उसी जगह से आगे का रास्ता जाँचें। दोनों उत्तरों को इस पर सहमत होना चाहिए कि कौन सा होस्ट अनुरोध कर रहा है।

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

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

पहचान भी पते के साथ बदलती है

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

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

पहुँच नोट लिखने से पहले टोकन और प्रत्यायोजन पथ देखें। दोनों सत्र के भीतर से दिखाई देते हैं, और यही एकमात्र जगह है जहाँ उत्तर अनुमान नहीं है।

whoami /groups
klist
query session

अगर एप्लिकेशन सेवा खाता इस्तेमाल करता है, तो आगे उसी के अधिकार मायने रखते हैं। उस क्रेडेंशियल को बदलना पहुँच समीक्षा का हिस्सा है, बाद के परिचालन विचार का नहीं।

सीधा रास्ता अब भी क्यों और ठीक से अवरुद्ध है

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

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

इसे स्प्रेडशीट से नहीं, परीक्षण सत्र के भीतर से गिनें। कुछ आदेश ही अधिकांश सतह ढक देते हैं।

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

सीमा को जानबूझकर चुनें

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

एक रिपोर्ट के लिए, प्रकाशित एप्लिकेशन या सीमित खाता सामान्य डेस्कटॉप से छोटी अनुमति है। जिस रखरखाव को सचमुच कई औज़ार चाहिए, उसमें डेस्कटॉप सही हो सकता है, पर तब स्वीकृति एक एप्लिकेशन नहीं, पूरे होस्ट का वर्णन करती है। संसाधन के मालिक से पूछें कि वे इनमें से किस पर सहमत हैं।

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

दोनों स्वीकृतियाँ और हटाने का रास्ता जाँचें

रिकॉर्ड में दो स्वीकृतियाँ होनी चाहिए: डेस्कटॉप तक पहुँचकर उसे खोलने का अधिकार, और उसके भीतर से संसाधनों के उपयोग का अधिकार। दोनों के लिए एक मालिक का नाम दें और दूसरी को संसाधन की समीक्षा करने वाले हर व्यक्ति के लिए दृश्य रखें। लेखा परीक्षक उसी दूसरी प्रविष्टि के बारे में पूछेगा, क्योंकि वह प्रवेश नहीं, पहुँच बताती है। बदलाव स्वीकृत होने से पहले दोनों लिखें, पहली घटना के बाद नहीं।

फिर हटाना जाँचें, क्योंकि डिस्कनेक्ट किया गया सत्र अपने कारण से अधिक जी सकता है। सत्र तालिका यह देखने की सबसे तेज़ जगह है कि अब भी क्या चल रहा है।

query session
query user
qwinsta /server:rdsh01.corp.internal

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