VPN-ის უკან მდებარე SaaS-ის ადმინისტრირების არე: რომელ მისამართს ვენდოთ?

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

რას იღებს ორიგინალი რეალურად გვირაბის შემდეგ

როცა ბრაუზერი საჯარო საიტს აღწევს VPN-ით, რომელიც ინტერნეტ-ტრაფიკსაც გადააქვს, კარიბჭე კავშირს გასვლამდე თარგმნის. SaaS ხედავს კარიბჭის საჯარო გამავალ მისამართს, ჩვეულებრივ ერთ მისამართს ან მცირე დიაპაზონს, და არასდროს ხედავს ლეპტოპის გვირაბის მისამართს. ამიტომ ხდება 10.90.0.42-ის დაშვებულთა სიაში შეტანა წარუმატებელი, და ამიტომ ხდება მთელი RFC 1918-ის შეტანა კიდევ უფრო ხმამაღლა წარუმატებელი: მეორე უშვებს ყველა კერძო ქსელს, რომელსაც თქვენამდე მიღწევა შეუძლია. ერთადერთი მისამართი, რომელზეც პირობის დადება ღირს, არის ის, რომელსაც თქვენი ორგანიზაცია რეალურად ფლობს გასასვლელში.

curl -s https://ifconfig.me
dig +short admin.example.com

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

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

ენდეთ მხოლოდ იმ პროქსის, რომელიც მისამართს გადაწერს

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

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

მიამაგრეთ პირობა ყოველ დაცულ ოპერაციას

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

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

იმავე საზღვარმა უნდა დაფაროს JSON API, ექსპორტები, ხელმოწერილი ჩამოტვირთვის URL-ები და WebSocket-ის ხელის ჩამორთმევა, რადგან არცერთს არ სჭირდება HTML გვერდის წინასწარ მოთხოვნა. VPN-ის მუშაობის დროს შექმნილი ჩამოტვირთვის ბმული შემდეგაც ძალაში რჩება, თუ ჩამოტვირთვის ბოლო წერტილი ხელახლა არ შეამოწმებს. გრძელვადიან სესიებსაც სჭირდება გადაფასების წესი, თორემ ერთი ავთენტიფიცირებული მოთხოვნა მუდმივ გამონაკლისად იქცევა. ნაგულისხმევი უარი ერთადერთი პარამეტრია, რომელიც პერსონალის ცვლას გადაურჩება.

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

შეამოწმეთ ის გვერდის ავლები, რომლებიც ახლახან დახურეთ

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

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

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

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