AWS Client VPN: რომელმა CA-მ უნდა გასცეს კლიენტის სერტიფიკატები?
არსებული CA, თვითმართული გამცემი და AWS Private CA სამუშაოს სხვადასხვაგვარად ყოფენ. გადაწყვიტეთ, ვინ ამტკიცებს, აახლებს და აუქმებს კლიენტის სერტიფიკატებს გაშვებამდე.
AWS Client VPN-ზე სერტიფიკატის საკითხს პროდუქტის კითხვად სვამენ, თუმცა სინამდვილეში ეს ოპერაციული კითხვაა. სამი ჩვეულებრივი კონფიგურაციიდან ნებისმიერი შეინარჩუნებს მუშა გვირაბს: არსებული ორგანიზაციული CA, გამოყოფილი თვითმართული გამცემი ან AWS Private CA. ისინი განსხვავდებიან იმით, თუ ვინ ამტკიცებს მოწყობილობას, ვისთან არის ხელმოწერის გასაღები და ვინ პასუხობს, როცა ლეპტოპი არასასიამოვნო საათში იკარგება. აირჩიეთ ის ვარიანტი, რომლის მფლობელსაც შეძლებთ დაასახელოთ.
AWS არ მოითხოვს Private CA-ს სერტიფიკატებით აუთენტიფიკაციისთვის. სერვერის სერტიფიკატის ACM-ში განთავსება განლაგების ნაბიჯია და არა რეგისტრაციის პროცესი.
სამი პირობა, რომლებიც ამას წყვეტს
სამი პირობა მკაფიოდ ჰყოფს ვარიანტებს: არსებობს თუ არა უკვე დამტკიცებული მოწყობილობის რეგისტრაციის პროცესი, შეგიძლიათ თუ არა ხელმოწერის გასაღების მართვა სარეზერვო ასლებით და დასახელებული მფლობელით, და როგორ აღწევს გაუქმება საბოლოო წერტილამდე. თითოეული კითხვა „დიახ“-ს ან „არა“-ს ახლოს არის, და პირველი „არა“ ჩვეულებრივ წყვეტს არქიტექტურას.
გაიარეთ ისინი რიგითობით. უშუალოდ ხარჯების შედარებაზე გადასვლა იწვევს იმას, რომ გუნდები რჩებიან მართული CA-ით და არავინ იცის, ვინ გასცემს შემდეგ ლეპტოპის სერტიფიკატს.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
პირველი პირობა: რეგისტრაცია უკვე არსებობს?
თუ თქვენი ორგანიზაცია უკვე მართავს CA-ს დამტკიცებული მოწყობილობის რეგისტრაციის გზით, Client VPN-ის კლიენტის სერტიფიკატების იქიდან გაცემა უმოკლესი გზაა. დამტკიცებები, პროცესი და აქტივების ჩანაწერები უკვე იქ არის. ამ იერარქიის ქვეშ გამოყოფილი დაქვემდებარებული გამცემი ჩვეულებრივ უკეთესია ზოგადი დანიშნულების გამცემ CA-ზე, რადგან VPN-ს აძლევს საკუთარ ნდობის საზღვარს და საკუთარ გაუქმების სიას. შეინახეთ ეს სია იერარქიის დანარჩენისგან ცალკე, რომ VPN-ის ინციდენტმა მთელ PKI-ში ცვლილება არ აიძულოს.
თუ ასეთი პროცესი არ არსებობს, ნამდვილი კითხვაა, გსურთ თუ არა მისი შექმნა. CA-ს დაწყება იოლია და ცუდად ფლობა ძვირი.
მეორე პირობა: შეგიძლიათ ხელმოწერის გასაღების მართვა?
თვითმართული გამცემი მუშაობს დოკუმენტირებული იმპორტის მოდელით, და EasyRSA ან პატარა შიდა ხელსაწყო მასალას შექმნის. ბრძანების გაშვება რთული ნაწილი არ არის. რთული ნაწილია ხელმოწერის გასაღების ოფლაინ სარეზერვო ასლები, აღდგენის გზა, რომელიც ვინმემ ნამდვილად გამოსცადა, მფლობელი, რომელიც შვებულებაში არ არის, და წესი, რომ გასაღები არასოდეს მოხვდეს კლიენტის პაკეტში ან კონფიგურაციის ექსპორტში. ჩაწერეთ ეს პროცედურად პირველი სერტიფიკატის გაცემამდე და არა პირველი ინციდენტის შემდეგ.
AWS Private CA ამ შენახვას მართულ სერვისში გადაიტანს. ის არ გადააქვს რეგისტრაციის პოლიტიკა, დამტკიცების ნაბიჯი ან სერტიფიკატის მოწყობილობამდე მიტანა.
მესამე პირობა: როგორ მოდის გაუქმება?
Client VPN იყენებს კლიენტის სერტიფიკატების გაუქმების სიას, რომელსაც თქვენ იმპორტს უკეთებთ საბოლოო წერტილში, როგორც აღწერილია სერტიფიკატის სასიცოცხლო ციკლის სახელმძღვანელოში. CRL-ის სხვაგან გამოქვეყნება თქვენს PKI-ში მას სერვისში არ უშვებს. იმპორტი ცალკე, დაგეგმილი ოპერაციაა, და ვადაგასული სია წყვეტს კავშირებს და არა ჩუმად უარესდება. განახლება იმავე კალენდარზე დადეთ, როგორც თავად სერტიფიკატები.
ეს განახლებას მფლობელის მქონე მონიტორინგის ერთეულად აქცევს და არა გაშვებისას დასრულებულ ამოცანად. გააუქმეთ ერთი სატესტო სერტიფიკატი თავიდან ბოლომდე, სანამ მექანიზმი ნამდვილად დაგჭირდებათ.
რასაც არც ერთი ვარიანტი არ აუქმებს
ყოველ ვარიანტს კვლავ სჭირდება ცალკე კლიენტის სერტიფიკატი და გასაღები ყოველი დამოუკიდებლად მართული მოწყობილობისთვის. სახელმძღვანელო, რომელიც ერთ იდენტობას ურიგებს ყველას, სახელმძღვანელოს მოკლე გზაა და არჩევით გაუქმებასაც შეუძლებელს ხდის.
ACM-ში იმპორტირებულ სერვერის სერტიფიკატებს მართული განახლება არ აქვთ, ამიტომ მფლობელმა უნდა მოიპოვოს შემცვლელი, ხელახლა იმპორტი გააკეთოს და შემდეგ დაადასტუროს, რომ საბოლოო წერტილმა ის მიიღო. სერვერის სერტიფიკატის განახლება არ აახლებს ლეპტოპებზე უკვე არსებულ კლიენტის სამართავებს. ეს ცალკე სასიცოცხლო ციკლებია ცალკე კალენდრებით.
შეამოწმეთ გასაღების ტიპები და გაფართოებები, რომლებსაც სერვისი იღებს, სანამ რამეს გასცემთ. ის, რომ CA ალგორითმს მხარს უჭერს, არ ნიშნავს, რომ საბოლოო წერტილი მიიღებს მას.
გაშვებამდე გაატარეთ ერთი განახლება და ერთი კლიენტის წაშლა თქვენ მიერ არჩეული სამუშაო ნაკადით, და ჩაწერეთ, რომელი სამართავი შეიცვალა, რომელი საბოლოო წერტილის პარამეტრი შეიცვალა და რა მოხდა აქტიურ სესიასთან. თუ ეს ვარჯიში მკაფიო მფლობელის გარეშე დასრულდა, გამცემის არჩევა არ დასრულებულა.