VPN-დან VLAN-ზე წვდომა: ჯერ მატრიცა ააგეთ, შემდეგ წესები
როლები ერთ მხარეს, სერვისები მეორე მხარეს. ხუთი შემოწმება ბუნდოვან VPN-დან VLAN-ზე წვდომის დიზაინს აქცევს ცხრილად, რომლის დანერგვაც firewall-ის მფლობელს შეუძლია.
დაიწყეთ მატრიცით და არა firewall-ის სინტაქსით. ცხრილი, სადაც როლები ერთ მხარესაა და სერვისები მეორეზე, შეიძლება გადახედოს აპლიკაციის მფლობელმა, განიხილოს უსაფრთხოების მფლობელმა და დანერგოს მან, ვისაც gateway უჭირავს. ეს გადახედვა იმ წესების გამართვაზე იაფია, რომლებზეც არავინ შეთანხმებულა.
ერთი საათი წერა შემდგომში ერთი კვირის წესების არქეოლოგიას დაზოგავს. დიზაინი საუბრობს იმაზე, ვინ რომელ სერვისს აღწევს, და სწორედ ეს ნაწილი უძლებს გადანომრვას.
ნაბიჯი 1: დაასახელეთ როლები ქსელებამდე
დაიწყეთ ადამიანებით და არა კომუტატორით. ჩამოწერეთ ყოველი ჯგუფი, რომელიც დისტანციურად უკავშირდება, და ერთი წინადადება, რომელიც აღწერს, რას აკეთებს ეს ჯგუფი, მაგალითად საწყობის თანამშრომლები, რომლებიც მარაგის დონეს კითხულობენ, ან კონტრაქტორი, რომელიც ერთ ინტეგრაციას ემსახურება. თუ ორი ჯგუფი ერთსა და იმავე წვდომას მიიღებდა, ამ მიზნისთვის ისინი ერთი როლია.
აქ გაჩერდით, თუ როლი მხოლოდ ორგანიზაციული სქემის გამო არსებობს. როლი, რომელსაც საკუთარი სერვისის საჭიროება არ აქვს, იდენტური უჯრების რიგად იქცევა, და იდენტური რიგები ვიღაცას ცდუნებას უჩენს მოგვიანებით მოხერხებულობისთვის მთელი ქვექსელი მისცეს. დაყავით იმის მიხედვით, რას აკეთებენ ადამიანები და არა იმის მიხედვით, ვინ აწერს ხელს მათ ხარჯებს. ექვსი როლი ჩვეულებრივ ძალიან ბევრია პატარა ოფისისთვის, სამი კი ხშირად სწორია.
ნაბიჯი 2: ყოველი უჯრა აქციეთ სერვისის განაცხადად
უჯრა, სადაც წერია „აპლიკაციები“, შესამოწმებელი არ არის. უჯრა, სადაც წერია „HTTPS ERP ჰოსტთან 443 პორტზე, პერსონალის პულიდან“, შესამოწმებელია. შეცვალეთ ყოველი ქსელის სახელი დანიშნულებით, პროტოკოლით და პორტით, შემდეგ დაამატეთ ის დამოკიდებულება, რომლის გარეშეც სერვისი არ მუშაობს, მაგალითად შიდა ამომხსნელი ან იდენტობის მომწოდებელი.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
მიმართულების სვეტი ყველაზე ძვირ შეცდომებს იჭერს. პერსონალისთვის აპლიკაციის გახსნის ნებართვა არ ნიშნავს აპლიკაციის სერვერებისთვის ნებართვას, გახსნან კავშირები უკან პერსონალის ლეპტოპებთან, და მდგომარეობიანი წესი, რომელიც პირველ მიმართულებას უშვებს, ხშირად ისე იკითხება, თითქოს მეორესაც უშვებს.
ნაბიჯი 3: გადაწყვიტეთ, სად ხდება იდენტობა პოლიტიკად
ვიღაცამ უნდა ავთენტიფიცირებული სესია აქციოს როლად, რომლის აღსრულებაც gateway-ს შეუძლია. მხარდაჭერილ ვარიანტებში შედის ავთენტიფიკაციის backend-ის მიერ მოწოდებული ჯგუფური პოლიტიკა, სანდო სესიის ატრიბუტები ან ცალკე მისამართების პულები თითოეული როლისთვის. სამივე მუშაობს; კლიენტის მიერ გაგზავნილი იარლიყი არ მუშაობს. აირჩიეთ ის მექანიზმი, რომელსაც თქვენი gateway ადასტურებს დოკუმენტაციით და არა ის, რომელსაც ფორუმის პოსტი აღწერს.
მისამართის მინიჭება, რომელიც მხოლოდ ისე გამოიყურება, თითქოს VLAN-ს ეკუთვნის, იგივე არა-პასუხია სხვა კოსტიუმში. Netgate-ის გზამკვლევი OpenVPN-ის firewall წესებზე ამ გამიჯვნას ნათელს ხდის: გვირაბის აწევის ნებართვა განსხვავებული გადაწყვეტილებაა, ვიდრე მასში ტრაფიკის გატარების ნებართვა.
ჩაწერეთ, რომელი მექანიზმი აირჩიეთ და სად არის კონფიგურირებული. როცა როლი იცვლება, ეს ჩანაწერი განსხვავებაა ერთ რედაქტირებასა და სამ ინტერფეისში ძებნას შორის. ის აუდიტორსაც ეუბნება, სად უნდა შეხედოს პირველად.
ნაბიჯი 4: დააკვირდით წყაროს მისამართს, რომელსაც დანიშნულება ხედავს
გადაგზავნის პოლიტიკა უნდა შეესაბამებოდეს რეალურ წყაროს საზღვარზე. თუ gateway VPN კლიენტებს საკუთარ მისამართზე თარგმნის, ქვედა დონის ყოველი firewall ერთ წყაროს ხედავს და კარგავს როლის მიხედვით გადაწყვეტილების მიღების უნარს. თუ ის ინახავს კლიენტის მისამართს, დაბრუნების გზა უნდა არსებობდეს ამ პულისთვის.
საბოლოო წესების დაწერამდე შეამოწმეთ ორივე მიმართულება, შემდეგ ჩაწერეთ დაკვირვებული წყარო ყოველი უჯრის გვერდით. გაუშვით იგივე შემოწმება ორი სხვადასხვა როლიდან და შეადარეთ შედეგი. თუ ორივე gateway-ის მისამართს აჩვენებს, როლების გამიჯვნა უკვე დაკარგულია. მატრიცა, რომელიც ინახავს მისამართებს ვარაუდობს, მაშინ როცა gateway წყაროს თარგმნას აკეთებს, პირველ ქვედა ACL-ზე ვარდება.
ნაბიჯი 5: გამოშვებამდე შეამოწმეთ ყოველი უჯრა
ყოველი დაშვებული უჯრა აქციეთ ერთ წარმომადგენლობით ოპერაციად, ხოლო ყოველი აკრძალული უჯრა უარყოფით შემთხვევად. გაუშვით ორივე რეალურ როლში მყოფი კლიენტიდან და არა gateway-ის კონსოლიდან, რადგან კონსოლი გვერდს უვლის იმ გზას, რომელსაც ამოწმებთ.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'დაკავშირებადი უარყოფითი შემთხვევა აღმოჩენაა და არა შემთხვევითობა, და მისი ადგილი მატრიცაში წარუმატებელ უჯრადაა, სანამ წესი არ გასწორდება. შეინახეთ სატესტო ბრძანებები ცხრილის გვერდით, რომ შემდეგმა მიმომხილველმა ხელახლა გაუშვას ისინი და არ აღადგინოს მსჯელობა.
დასრულებული ცხრილი დიდხანს ცოცხლობს, ვიდრე ის gateway, რომლისთვისაც დაიწერა. წესები იცვლება firmware-სა და მომწოდებელთან ერთად, ხოლო სტრიქონი, რომელიც ამბობს, რომ კონტრაქტორი ერთ პროექტის სერვისს აღწევს, ჭეშმარიტი რჩება მანამ, სანამ ეს სამუშაო არ შეიცვლება.