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

კლიენტის პროფილი, რომელიც ამბობს OpenVPN-ს, აღწერს პროტოკოლს და არა მის უკან მდგარ იდენტობის სისტემას.

დაიწყეთ სერვერიდან და არა adduser-იდან

ჯერ დაადგინეთ პროდუქტი. Community OpenVPN არის დემონი და ნებისმიერი აუთენტიფიკაცია, რომელიც მას დაუკავშირეთ, ხოლო Access Server არის პროდუქტი საკუთარი მომხმარებლის შრით. მოითხოვეთ კონფიგურაცია, ერთეულის სახელი და პაკეტების სია, და შეამოწმეთ არის თუ არა ვებ-ინტერფეისი მომხმარებლების მართვისთვის. შემდეგ შეხედეთ როგორ ელის განლაგებული პროფილი, რომ კლიენტებმა დაამტკიცონ ვინ არიან: სერტიფიკატით, მომხმარებლის სახელით და პაროლით, ან ორივეთი. ეს პასუხი ასახელებს სისტემას, რომელიც ანგარიშს ფლობს.

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

ოთხი backend, ანგარიშის შექმნის ოთხი ადგილი

Access Server-ის ლოკალური აუთენტიფიკაცია ანგარიშებს საკუთარ მონაცემთა ბაზაში ინახავს, ამიტომ მათი შექმნის ინტერფეისი პროდუქტს ეკუთვნის და არა ჰოსტს. PAM ამოწმებას ოპერაციული სისტემის სტეკს ანდობს და ამიტომ ლოკალური Unix ანგარიში შეიძლება იყოს რეგისტრაციის ნაწილი, როცა სერვისმა სწორედ ეს სტეკი აირჩია. LDAP, RADIUS და SAML ამოწმებას გარე სერვისში გადააქვთ, სადაც ცხოვრობს უზრუნველყოფა, პაროლის პოლიტიკა და MFA. Access Server ოთხივე შემთხვევაში კვლავ შეიძლება ინახავდეს მომხმარებლისეულ სერტიფიკატებს და ნებართვებს და სწორედ ეს ხდის გაყოფას დამაბნეველს.

შეამოწმეთ ამ კონკრეტული მომხმარებლისთვის მოქმედი მეთოდი და არა გლობალური ნაგულისხმევი. Access Server 2.10 და უფრო ახალი იძლევა სხვადასხვა აუთენტიფიკაციის მეთოდის გამოყენებას ჯგუფის ან მომხმარებლის მიხედვით, ამიტომ ლოკალური ნაგულისხმევი არ ამტკიცებს, რომ თქვენს წინ ანგარიში ლოკალურად მოწმდება.

უფლება ცალკე გადაწყვეტილებაა

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

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

წვდომის გაუქმება რეგისტრაციის ნაწილია

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

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

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

დაკავშირებული სტატიები