AWS Client VPN-ის წესები რესურსს ეკუთვნის, არა ქვექსელს

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

ქვექსელის განლაგება მარშრუტიზაციაა, არა ავტორიზაცია

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

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

Client VPN-ის ასოციაციის ჯგუფი სწორედ ის სახელურია

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

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

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

რას ვერ გაარჩევს ერთი ასოციაციის ჯგუფი

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

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

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

ნუ დააკოპირებთ ამ წესს ყველა VPN დიზაინში

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

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

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

გადახედეთ ეფექტურ საზღვარს

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

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

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