RDP ცვლის კლიენტს: რატომ ხედავს მონაცემთა ბაზა სხვა ჰოსტს

თქვენი VPN წესი ბაზას უარყოფს და ბილეთი firewall-ის ხარვეზად იხურება, მაშინ როცა იგივე მომხმარებელი გამოქვეყნებულ დესკტოპს ხსნის და ამ ბაზაში უპრობლემოდ აკეთებს მოთხოვნას. ორივე განცხადება მართალია. დესკტოპი სხვა კლიენტია, საკუთარი მისამართით იმ სეგმენტში, რომელსაც წესები უკვე ენდობა, და საკუთარი იდენტობით, როცა შემდგომ უკავშირდება. ის, რაც წინააღმდეგობრივ წესად გვეჩვენება, ჩვეულებრივ მეორე მოთხოვნაა, რომელიც განხილვაში არავის შეუტანია.

მეორე მოთხოვნას საკუთარი კლიენტის მისამართი აქვს

როცა სესიის შიგნით აპლიკაცია ბაზასთან კავშირს ხსნის, TCP ხელის ჩამორთმევა სესიის ჰოსტზე იწყება. მისი წყაროს მისამართი ამ ჰოსტის ქსელს ეკუთვნის, ამიტომ გზაზე ყოველი მარშრუტიზატორი და ბაზის firewall აფასებს დესკტოპის სეგმენტს და არა იმ გვირაბის აუზს, საიდანაც თქვენი ლეპტოპი მოვიდა. 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

კლიენტის გაწყვეტა დისტანციურ სესიას მუშა მდგომარეობაში ტოვებს და მისი ქსელური კავშირები და ქეშირებული სერტიფიკატები შეიძლება გამოსადეგი დარჩეს სანამ ეს სესია დასრულდება. გამოდით სისტემიდან ან ცალსახად დაასრულეთ სესია და დაადასტურეთ, რომ ამის შემდეგ ქვედა მრიცხველი წინ აღარ იწევს. წაშლის ტესტი, რომელიც მხოლოდ ლეპტოპის სახურავს ხურავს, არაფერს ამტკიცებს. იგივე ტესტი ერთხელ გამორთული ანგარიშით და ერთხელ მოხსნილი დესკტოპის ნებართვით ჩაატარეთ, შემდეგ ჩაწერეთ, რა დაარეგისტრირა რესურსმა თითოეულ შემთხვევაში.