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-ը սպառում է հաճախորդի վկայագրերի չեղարկման ցանկը, որը դուք ներմուծում եք վերջնակետ, ինչպես նկարագրված է վկայագրի կյանքի ցիկլի ուղեցույցում։ Ձեր PKI-ի այլ տեղում CRL հրապարակելը այն չի մղում ծառայության մեջ։ Ներմուծումը առանձին, պլանավորված գործողություն է, և ժամկետանց ցանկը դադարեցնում է միացումները՝ փոխարենը լուռ վատանալու։ Նորացումը դրեք նույն օրացույցի վրա, ինչ վկայագրերը։
Դա նորացումը դարձնում է սեփականատեր ունեցող մոնիտորինգի կետ, ոչ թե մեկնարկին ավարտվող առաջադրանք։ Չեղարկեք մեկ փորձնական վկայագիր սկզբից մինչև վերջ, նախքան մեխանիզմը իրապես պետք կգա։
Ինչը ոչ մի տարբերակ չի վերացնում
Յուրաքանչյուր տարբերակ դեռ պահանջում է առանձին հաճախորդի վկայագիր և բանալի յուրաքանչյուր ինքնուրույն կառավարվող սարքի համար։ Ուղեցույցը, որը մեկ ինքնություն է բաժանում բոլորին, ուղեցույցի կարճուղի է, և այն նաև անհնար է դարձնում ընտրովի չեղարկումը։
ACM-ում ներմուծված սերվերի վկայագրերը չունեն կառավարվող նորացում, ուստի սեփականատերը պետք է ստանա փոխարինողը, կրկին ներմուծի այն և հետո հաստատի, որ վերջնակետն ընդունել է այն։ Սերվերի վկայագրի նորացումը չի նորացնում նոթբուքերում արդեն եղող հաճախորդի հավատարմագրերը։ Դրանք առանձին կյանքի ցիկլեր են՝ առանձին օրացույցներով։
Ստուգեք բանալիների տեսակներն ու ընդլայնումները, որոնք ծառայությունն ընդունում է, նախքան ինչ-որ բան թողարկելը։ Այն, որ CA-ն աջակցում է ալգորիթմին, չի նշանակում, որ վերջնակետը կընդունի այն։
Մեկնարկից առաջ անցկացրեք մեկ նորացում և մեկ հաճախորդի հեռացում ձեր ընտրած աշխատահոսքով, և գրեք, թե որ հավատարմագիրն է փոխվել, որ վերջնակետի կարգավորումն է փոխվել և ինչ եղավ ակտիվ սեսիայի հետ։ Եթե այդ վարժությունը ավարտվի առանց հստակ սեփականատիրոջ, թողարկողի ընտրությունը ավարտված չէ։