მხოლოდ CSR ჯერ არ არის რეგისტრაცია: რა უნდა შეამოწმოს VPN CA-მ
ხელმოწერის მოთხოვნა მხოლოდ გასაღების ფლობას ამტკიცებს და მეტს არაფერს. შეადარეთ რეგისტრაციის მოდელები იმის მიხედვით, თუ რას აკავშირებენ, სანამ CA VPN-ზე წვდომას მისცემს.
სერტიფიკატის ხელმოწერის მოთხოვნა შეიცავს საჯარო გასაღებსა და მოთხოვნილ subiekt-ს, ხელმოწერილს შესაბამისი კერძო გასაღებით. ეს ხელმოწერა ამტკიცებს, რომ მომთხოვნს გასაღები აქვს. ის არ ამტკიცებს, რომ მომთხოვნს უფლება აქვს მოთხოვნილ სახელზე, მოწყობილობაზე ან VPN როლზე, და მოთხოვნის ისე განხილვა, თითქოს ეს ამტკიცებს, სწორედ ის გზაა, რომლითაც დახმარების სამსახურის ბილეთი წვდომის მინიჭებად იქცევა.
ორი რეგისტრაციის მოდელი ღირს შედარება იმის მიხედვით, თუ რას აკავშირებენ, და არა იმის მიხედვით, რომელ პროტოკოლზე საუბრობენ.
მოთხოვნა სახელს აცხადებს და არ ამტკიცებს
წაიკითხეთ მოთხოვნა იმის მიხედვით, რაც მასში ნამდვილად არის: საჯარო გასაღები, მომთხოვნის მიერ არჩეული subiekt და თვითხელმოწერა ორივეზე. ამ სტრუქტურაში არაფერი მიუთითებს თქვენს ინვენტარზე, ანგარიშების კატალოგზე ან დამტკიცების პროცესზე. subiekt როგორიცაა cn=finance-laptop არის სტრიქონი, რომელიც ვიღაცამ აკრიფა. სანამ გაცემის პროცესი ამ სტრიქონს სანდო ჩანაწერთან არ შეამოწმებს, სერტიფიკატი ხელმოწერით მიმაგრებული მტკიცებაა. ეს განსხვავება რეგისტრაციის პროცესის არსებობის მთელი მიზეზია.
შედეგს ოპერაციული მნიშვნელობა აქვს. სერტიფიკატების ორგანოს სერტიფიკატის გასაცემად არასდროს სჭირდება კლიენტის კერძო გასაღები, და პროცესს, რომელიც მას ითხოვს, ხელმოწერა გასაღების შენახვასთან აქვს არეული. დატოვეთ გენერაცია საბოლოო წერტილში და გაგზავნეთ მხოლოდ საჯარო ნახევარი.
შეადარეთ მოდელები იმის მიხედვით, თუ რას აკავშირებენ
ხელით ხელმოწერა აკავშირებს იმას, რისი შემოწმებაც ოპერატორს ახსოვს. ავტომატიზებული რეგისტრაციის სერვისი აკავშირებს ავთენტიფიცირებულ მოთხოვნას გადაწყვეტილებასთან, რომლის აღსრულებაც სერვისს შეუძლია, და RFC 7030 აღწერს ერთ ასეთ დიზაინს, სადაც კლიენტი ავთენტიფიცირდება სერტიფიკატის დაბრუნებამდე. განსხვავება, რომელიც აუდიტს გადაურჩება, ავტომატიზაცია არ არის; ის არის, ხდება თუ არა იდენტობის შემოწმება გაცემის გზის შიგნით, თუ მის გვერდით.
ორივე მოდელმა მაინც უნდა უპასუხოს იმავე სამ კითხვას. ვინ ითხოვს, რომელ მოწყობილობაზე ან როლში და რამდენ ხანს. ბილეთების სისტემა, რომელიც პასუხებს აღრიცხავს, ნამდვილ საქმეს აკეთებს; რიგი, სადაც ვიღაც საერთო სახელს უყურებს, არ აკეთებს, რამდენად ყურადღებითაც არ უნდა დაფორმატდეს სერტიფიკატი მოგვიანებით.
აირჩიეთ მოდელი მოსალოდნელი რეგისტრაციების რაოდენობისა და მოწყობილობების ბრუნვის მიხედვით. წელიწადში რამდენიმე სერვერი გაუძლებს ხელით განხილვას წერილობითი შემოწმების სიით. ლეპტოპების ფლოტი ვერ გაუძლებს.
ჩაწერეთ სასიცოცხლო ციკლი პირველი გაცემიდან
შეინახეთ სერტიფიკატის იდენტიფიკატორი, მფლობელი, დანიშნულება, ვადა და წაშლის გზა გაცემის მომენტში და არა პირველ ინციდენტზე. დანიშნული გამოყენება გაფართოებული გასაღების გამოყენებით თავად სერტიფიკატში უნდა იყოს და ჩანაწერი მას უნდა შეესაბამებოდეს. კლიენტის ავთენტიფიკაციისთვის შექმნილი სერტიფიკატი არ უნდა იყოს სერვერისთვის განკუთვნილისგან განურჩეველი.
დაგეგმეთ განახლება და დაკარგული მოწყობილობის გაუქმება მეათე პროფილის გაცემამდე. დეპარტამენტზე გაზიარებული სერტიფიკატი მიზნობრივ წაშლას შეფერხებად აქცევს, და ამ გადაწყვეტილების ახლა გადახედვა გაცილებით იაფია, ვიდრე პარასკევის ინციდენტის დროს.
შეამოწმეთ გაცემული სერტიფიკატი, შემდეგ წვდომა
რეგისტრაციის შემდეგ შეამოწმეთ, რა გაიცა, და დაადასტურეთ, რომ ის მოსალოდნელ ორგანომდე ჯაჭვდება. ორი ბრძანება ფარავს გავრცელებულ შეცდომებს: არასწორი გამოყენების სერტიფიკატი და ჯაჭვი, რომელიც მხოლოდ იმიტომ მუშაობს, რომ კლიენტი ვალიდაციის იგნორირებაზეა კონფიგურირებული.
openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt
შემდეგ შეამოწმეთ წვდომა და არა არტეფაქტი. სერტიფიკატი იდენტობას ამყარებს და პოლიტიკა მაინც წყვეტს, რომელ სერვისებამდე შეიძლება მიაღწიოს ამ იდენტობამ. შეამოწმეთ ორივე, რადგან სწორი არტეფაქტი ზედმეტად ფართო პოლიტიკასთან მაინც ვერ გაივლის განხილვას. დაადასტურეთ, რომ კლიენტი ავთენტიფიცირდება და მხოლოდ განკუთვნილ მარშრუტებს ან რესურსებს იღებს. ჩაწერეთ რაც დააკვირდით და არა ის, რაც პროფილს უნდა გაეკეთებინა.
პროფილი, რომელიც არასწორი მიზეზით მუშაობს, მაგალითად დამთხვეული საერთო სახელი და იდენტობის შემოწმების არარსებობა, გააგრძელებს მუშაობას მას შემდეგ, რაც მოხსნილი იქნება ის კონტროლი, რომელიც გეგონათ გქონდათ.