ორი შესვლის შემოწმება ორი ფაქტორი არ არის: VPN და RADIUS

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

რას ამტკიცებს სინამდვილეში მეორე backend

ლოკალურ ანგარიშში ძებნა ამტკიცებს, რომ სახელი არსებობს მონაცემთა ბაზაში და რომ პაროლი მას შეესაბამებოდა. RADIUS გაცვლა ამტკიცებს, რომ RADIUS სერვერმა მიღებული ატრიბუტებისთვის დააბრუნა Access-Accept. არც ერთი განცხადება არ ახსენებს ფაქტორის ტიპს, რადგან ორივე ცოდნას ამოწმებს. და NIST-ის ციფრული იდენტობის სახელმძღვანელო ითვლის ფაქტორის სხვადასხვა ტიპს და მათ აუთენტიფიკატორებს, და არა სერვერებს ან მინიშნებებს.

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

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

AND, OR და სარეზერვო სხვადასხვა პროდუქტია

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

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

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

OpenVPN-ის ორმაგი შემოწმება კონკრეტული შემთხვევაა

საზოგადოებრივი OpenVPN 2.6 მოითხოვს როგორც კლიენტის სერტიფიკატს, ისე კონფიგურირებულ auth-user-pass-verify სკრიპტს, როცა ორივე ჩართულია. ეს არის დოკუმენტირებული AND სერტიფიკატის შემოწმებასა და სერტიფიკატული მონაცემების სკრიპტს შორის, და ეს ნამდვილად ორი შემოწმებაა. ეს ჯერ არ არის ავტომატურად ორი ტიპის ფაქტორი, რადგან სკრიპტმა შეიძლება მხოლოდ პაროლი გადაამოწმოს.

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

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

მოწყობილობების მწარმოებლები საკუთარ მილსადენს აშენებენ, ხშირად PAM მოდული ან RADIUS plugin ვებ კონსოლის მიღმა. საზოგადოების ქცევა მითითებაა იმაზე, როგორ გამოიყურება ორმაგი შემოწმებები, და არა აღწერა იმისა, როგორ აერთიანებს მათ მოწყობილობა.

შეამოწმეთ კომბინაცია თქვენს კარიბჭეზე

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

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep აჩვენებს, საჭიროა თუ არა სერტიფიკატი და რომელი სკრიპტი ეშვება მის შემდეგ, და რიგი უფრო მნიშვნელოვანია, ვიდრე სახელები გვაფიქრებინებს. სერტიფიკატის დამპი იძლევა იდენტობას, რომელსაც კარიბჭე დაინახავს, მათ შორის CN და სერიული ნომერი, რომლებიც დაკავშირების რუკისთვის გჭირდებათ. RADIUS ტესტი უარყოფითი შემთხვევაა: არასწორმა პაროლმა უნდა მისცეს Access-Reject, ხოლო სწორმა Access-Accept. თუ უარყოფილი მონაცემები მაინც იძლევა სესიას, სკრიპტი საერთოდ არ არის აუთენტიფიკაციის გზაზე.

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

დაწერეთ მოთხოვნა უარყოფით შემთხვევებად

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

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

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