FortiGate VPN MFA: ლოკალური ტოკენი, RADIUS თუ SAML?

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

ყოველი FortiGate VPN MFA დიზაინი პირველ რიგში ერთ კითხვას პასუხობს: ვინ ამოწმებს მეორე ფაქტორს? თავად გეითვეის შეუძლია ამის გაკეთება ლოკალური ტოკენით ან ელფოსტით გაგზავნილი კოდით, RADIUS backend-ს შეუძლია ამის იძულება და გამოწვევის დაბრუნება, ან SAML იდენტობის პროვაიდერს შეუძლია მთელი ცერემონია ბრაუზერში აიღოს. თითოეული მათგანი სხვადასხვა შესვლის თანმიმდევრობას, სხვადასხვა მარცხის ნიშანს და სხვადასხვა აღდგენის პროცედურას წარმოქმნის, და მათ შორის ბრძანებების ბლოკის კოპირება ქმნის კონფიგურაციას, რომელიც დამაჯერებლად გამოიყურება და არავის ამოწმებს. ეს არის სტატია მექანიზმზე: რას აკეთებს თითოეული დიზაინი შესვლის დროს და სად იშლება.

შესვლის ცერემონია წყვეტს, ვის ეკუთვნის ფაქტორი

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

ეს განსხვავება წყვეტს, რა მტკიცებულებების შეგროვება შეგიძლიათ. როცა გეითვეი ამოწმებს, მისივე გამმართველის გამოსავალი გეუბნებათ, რა მოხდა. როცა იდენტობის პროვაიდერი ამოწმებს, გეითვეიმ იცის მხოლოდ ის, რომ დებულება მოვიდა, და პასუხი კითხვაზე „ნამდვილად იყო MFA საჭირო“ პროვაიდერის ჟურნალებშია, არა firewall-ის. არასწორი ჟურნალის კითხვა ყველაზე გავრცელებული გზაა იმ გაშვების არასწორად დიაგნოსტიკისთვის, რომელიც ზუსტად ისე მუშაობს, როგორც დაპროექტდა. თავად სერვისიც ზღუდავს ცერემონიას: FortiOS 7.6.3 აუქმებს SSL VPN გვირაბის რეჟიმს IPsec-ის სასარგებლოდ, ხოლო ვებ რეჟიმი გრძელდება როგორც Agentless VPN მხარდაჭერილ მოდელებზე, ამიტომ ერთ სერვისზე დამტკიცებული ცერემონია ავტომატურად არ არის ხელმისაწვდომი მეორეზე.

ლოკალური შემოწმება: ტოკენები და ელფოსტის კოდები

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

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

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

RADIUS: გეითვეი კითხულობს, backend წყვეტს

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

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

შეამოწმეთ backend დამოუკიდებლად, სანამ გვირაბს დაადანაშაულებთ. თუ authserver-ის ტესტი წარმატებულია და VPN შესვლა არა, განსხვავება გამოწვევის დამუშავებაშია და არა სერტიფიკატში, და გეითვეის ავთენტიფიკაციის დემონის გამმართველი არის ის ადგილი, სადაც ეს ჩანს:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: ბრაუზერი ტოვებს გეითვეის

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

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

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

აღდგენა მექანიზმის ნაწილია

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

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

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