AWS Client VPN-ის ავთენტიფიკაცია: IAM-ის ნებართვები შესვლის მეთოდი არ არის
კონსოლის ნებართვები გვირაბს არ ავთენტიფიცირებს. შეადარეთ სერტიფიკატის, AD-ისა და SAML-ის მეთოდები, შემდეგ ნახეთ, როდის შეესაბამება SSM-ის პორტის გადატანა ერთ კერძო მონაცემთა ბაზას.
მომხმარებლისთვის AWS Client VPN-ის ბოლო წერტილის შექმნის ან აღწერის ნებართვის მიცემა მას ამ პუნქტზე დაკავშირების საშუალებას არ აძლევს. ეს იდენტობის ორი განსხვავებული ტიპია: IAM მართავს AWS API-ის გამოძახებებს, ხოლო ბოლო წერტილი იღებს მხოლოდ მასზე კონფიგურირებულ კლიენტის ავთენტიფიკაციის მეთოდებს. ასე რომ, მომხმარებელს შეიძლება ჰქონდეს ფართო კონსოლის უფლებები და მაინც არაფერი ჰქონდეს იმისა, რაც VPN-ის კლიენტს შეუძლია წარმოადგინოს. გადაწყვიტეთ, რომელ მეთოდს ენდობა ბოლო წერტილი, შემდეგ გადაწყვიტეთ, სრული გვირაბია თუ არა სწორი ფორმა თქვენს მიერ მიცემული წვდომისთვის.
API-ის იდენტობა გვირაბის იდენტობა არ არის
როცა ვინმე ამბობს „IAM-ის როლი მიმაგრებულია, მაშინ რატომ კვლავ ვარდება VPN“, პასუხი ჩვეულებრივ ისაა, რომ კავშირის ნაკადის არც ერთი ნაბიჯი არ კითხულობს ამ როლს. კლიენტი წარმოადგენს სერტიფიკატს, AD-ის მომხმარებლის სახელსა და პაროლს, ან SAML-ის მტკიცებას. ბოლო წერტილი ამოწმებს ერთ-ერთ მათგანს და შემდეგ ანიჭებს მისამართს.
IAM კვლავ მნიშვნელოვანია, უბრალოდ უფრო გვიან და სხვა ადგილას: ბოლო წერტილის შექმნა, ქვექსელების დაკავშირება, მარშრუტების გამოქვეყნება და ავტორიზაციის წესების წერა API-ის მოქმედებებია. შეინახეთ ეს ნებართვები შეზღუდული იმ ოპერატორებით, რომლებსაც ისინი სჭირდებათ, ნაცვლად იმისა, რომ ყველა მომხმარებელს მისცეთ ბოლო წერტილის წვდომის წესების გადაწერის შესაძლებლობა.
აირჩიეთ ბოლო წერტილის მხარდაჭერილი მეთოდებიდან
AWS Client VPN იღებს სერტიფიკატზე დაფუძნებულ ურთიერთ ავთენტიფიკაციას, Active Directory-ის ავთენტიფიკაციას და SAML-ზე დაფუძნებულ ფედერაციულ ავთენტიფიკაციას. სერვერის სერტიფიკატი საჭიროა თქვენს მიერ არჩეული კლიენტის მეთოდის მიუხედავად, და მეთოდების კომბინირებული კონფიგურაცია მოითხოვს ორივეს წარმატებას და არა ერთისას.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
სერტიფიკატები ყველაზე იაფია დასანერგად და ყველაზე ადვილია შეცდეს მასშტაბში, რადგან ყველა მომხმარებელს სჭირდება სერთიფიკატი, ხოლო ყოველი წასვლა მოითხოვს გაუქმებას. დირექტორიის ავთენტიფიკაცია ამ სასიცოცხლო ციკლს არსებულ სისტემაში გადააქვს. ფედერაცია მას იდენტობის მომწოდებელთან გადააქვს და კლიენტს ბრაუზერის ნაბიჯს უმატებს.
წაიკითხეთ თავად ბოლო წერტილის კონფიგურაცია, სანამ კლიენტს გამართავთ. თუ ურთიერთ ავთენტიფიკაცია ჩართულია მომხმარებელზე დაფუძნებული მეთოდის გვერდით, სწორი სერტიფიკატის მქონე, მაგრამ დირექტორიის ანგარიშის გარეშე კლიენტი მაინც ვერ შეძლებს და შეცდომა ჩვეულებრივ ჩვეულებრივი ხელის ჩამორთმევის პრობლემას ჰგავს.
ფედერაცია წვდომის გასაღებების გადაცემა არ არის
SAML-ის კონფიგურაცია გვირაბში არ შეჰყავს IAM-ის წვდომის გასაღებებს ან მიღებული როლის ტოკენს. იდენტობის მომწოდებელი ავთენტიფიცირებს პიროვნებას, აბრუნებს მტკიცებას, და ბოლო წერტილი იღებს მას თქვენ მიერ კონფიგურირებული ნდობის ფარგლებში. შედეგად მიღებული სესია VPN-ის სესიაა და არა AWS API-ის სესია.
ეს განსხვავება წყვეტს, ვის შეუძლია რისი დიაგნოსტიკა. IdP-ის პრობლემები ჩნდება როგორც ბრაუზერის ან კლიენტის შეცდომა ნებისმიერი გვირაბის არსებობამდე, ხოლო გვირაბის პრობლემები ჩნდება წარმატებული მტკიცების შემდეგ. ჰკითხეთ, ამ ორიდან რომელს უყურებთ, სანამ რომელიმე კონსოლს გახსნით.
შესვლის შემდეგ მარშრუტები და ავტორიზაცია კვლავ წყვეტს
ავთენტიფიკაცია სესიას მისამართს აძლევს, მაგრამ სესიას დანიშნულებას არ აძლევს. ბოლო წერტილის მარშრუტები კლიენტს ეუბნება, რომელ ქვექსელებში გაგზავნოს, ავტორიზაციის წესები წყვეტს, რომელი მომხმარებლები მიაღწევენ ამ ქვექსელებიდან რომელს, ხოლო უსაფრთხოების ჯგუფები და სამიზნის საკუთარი ნებართვები წყვეტს დანარჩენს.
ამიტომ წარმატებით ავთენტიფიცირებული მომხმარებელი მაინც ვერ მიაღწევს მონაცემთა ბაზას. შეამოწმეთ ქვექსელის მარშრუტთა ცხრილის კავშირი, მომხმარებლის ჯგუფის ავტორიზაციის წესი და სამიზნის უსაფრთხოების ჯგუფი სწორედ ამ თანმიმდევრობით, რადგან თითოეული მათგანი სხვადასხვა სახის ვადის გასვლას იწვევს.
ერთი კერძო მონაცემთა ბაზისთვის შეადარეთ პორტის გადატანას
თუ რეალური ამოცანა ერთ კერძო მონაცემთა ბაზაზე ერთი დამტკიცებული კავშირია, სრული ქსელური გვირაბი არჩევანია და არა მოთხოვნა. AWS Systems Manager Session Manager-ს შეუძლია IAM-ის მეშვეობით გახსნას პორტის გადატანის სესია მართულ კვანძთან, და ეს კვანძი აღწევს მონაცემთა ბაზას კერძო ქსელში. მომხმარებელი არასოდეს იღებს VPC-ის მისამართს. მართული კვანძი ხდება ერთადერთი ჰოსტი, რომელსაც შეუძლია მონაცემთა ბაზის პორტამდე მიღწევა, და ეს ჩვეულებრივ არის ის, რასაც უსაფრთხოების მიმოხილვა ითხოვდა. შემდეგ მომხმარებლებს სჭირდებათ ლოკალური კლიენტი და სესიის ბრძანება VPN-ის პროფილის ნაცვლად.
გაცვლა არის მოცულობა წინაპირობების წინააღმდეგ. პორტის გადატანას სჭირდება SSM-ის აგენტი მართულ კვანძზე, ქსელური ხელმისაწვდომობა ამ კვანძიდან მონაცემთა ბაზამდე, Session Manager-ის დანამატი მომხმარებლის მანქანაზე და ნებართვა სწორედ იმ სესიის დასაწყებად. ეს არ არის შესასვლელი ყველა ქვექსელში და არ გადაიტანს თვითნებურ პროტოკოლებს ისე, როგორც გვირაბი.
ნებისმიერ შემთხვევაში შეინახეთ მონაცემთა ბაზის საკუთარი იდენტობა თავის ადგილზე. TLS-ის შემოწმება და მონაცემთა ბაზის ავთენტიფიკაცია არ ქრება იმიტომ, რომ გზა IAM-ით ავტორიზებული იყო, და დამტკიცებული სესია არაფერს ამბობს იმაზე, რომელი ცხრილების წაკითხვა შეუძლია მომხმარებელს.
აირჩიეთ მოცულობისა და სასიცოცხლო ციკლის მიხედვით: გვირაბი, როცა ბევრ მომხმარებელს ბევრი დანიშნულება სჭირდება და შეგიძლიათ მართოთ სერტიფიკატის ან დირექტორიის სასიცოცხლო ციკლი; გადატანის სესია, როცა რამდენიმე ადამიანს ერთი სერვისი სჭირდება და ამჯობინებთ ქსელური მისამართების გაუნაწილებლობას. ნებისმიერ შემთხვევაში ჩაწერეთ ავთენტიფიკაციის მეთოდი, ავტორიზაციის წესი და მონაცემთა ბაზაში შესვლა როგორც სამი ცალკე ფაქტი, რადგან ისინი ცალ-ცალკე ვარდება.