VPC-ის დისტანციური წვდომის მიღება უარის ტესტებს მოითხოვს

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

გამოიყენეთ ცალკეული ანგარიშები ტესტებისთვის და მონიშნეთ ისინი ისე, რომ არავინ აურიოს სატესტო იდენტობა რეალურ გამონაკლისს.

ჩაწერეთ საზღვარი მოსალოდნელ შედეგებად

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

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

მარშრუტი ავტორიზაცია არ არის

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

ამიტომაც მიმართულია უარის ტესტები სერვერის მხარეს: ამ შედეგებს კლიენტის რედაქტირებით ვერ შეცვლით.

რომელ წყაროს ხედავს კონტროლი სინამდვილეში?

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

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

გააუქმეთ იდენტობა და ხელახლა შეამოწმეთ

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

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

შეინახეთ ცხრილი განლაგებასთან და ხელახლა გაუშვით, როცა კარიბჭე შეიცვლება. ტესტები იაფია; მათ უკან არსებული ვარაუდები არა.