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 ഒരു അൽഗോരിതം പിന്തുണയ്ക്കുന്നത് എൻഡ്‌പോയിന്റ് അത് സ്വീകരിക്കും എന്ന് അർത്ഥമാക്കുന്നില്ല.
സമാരംഭത്തിന് മുമ്പ് നിങ്ങൾ തിരഞ്ഞെടുത്ത വർക്ക്ഫ്ലോയിലൂടെ ഒരു പുതുക്കലും ഒരു ക്ലയന്റ് നീക്കലും നടത്തി, ഏത് ക്രെഡൻഷ്യൽ മാറി, ഏത് എൻഡ്‌പോയിന്റ് ക്രമീകരണം മാറി, സജീവ സെഷന് എന്ത് സംഭവിച്ചു എന്ന് എഴുതുക. ആ അഭ്യാസം വ്യക്തമായ ഉടമയില്ലാതെ അവസാനിക്കുന്നുവെങ്കിൽ, നൽകുന്നയാളുടെ തിരഞ്ഞെടുപ്പ് പൂർത്തിയായിട്ടില്ല.