AWS Client VPN പ്രാമാണീകരണം: IAM അനുമതികൾ ലോഗിൻ രീതിയല്ല
കൺസോൾ അനുമതികൾ ഒരു ടണൽ പ്രാമാണീകരിക്കുന്നില്ല. സർട്ടിഫിക്കറ്റ്, AD, SAML രീതികൾ താരതമ്യം ചെയ്യുക, തുടർന്ന് SSM പോർട്ട് ഫോർവേഡിംഗ് ഒരു സ്വകാര്യ ഡാറ്റാബേസിന് എപ്പോൾ അനുയോജ്യമാണെന്ന് നോക്കുക.
ഒരു ഉപയോക്താവിന് AWS Client VPN എൻഡ്പോയിന്റ് സൃഷ്ടിക്കാനോ വിവരിക്കാനോ അനുമതി നൽകുന്നത് അയാളെ അതിലേക്ക് ബന്ധിപ്പാൻ അനുവദിക്കുന്നില്ല. ഇവ രണ്ട് വ്യത്യസ്ത തരം ഐഡന്റിറ്റികളാണ്: IAM AWS API കോളുകൾ നിയന്ത്രിക്കുന്നു, എൻഡ്പോയിന്റ് അതിൽ കോൺഫിഗർ ചെയ്ത ക്ലയന്റ് പ്രാമാണീകരണ രീതികൾ മാത്രം സ്വീകരിക്കുന്നു. അതിനാൽ ഉപയോക്താവിന് വിശാലമായ കൺസോൾ അവകാശങ്ങൾ ഉണ്ടായിരിക്കാം, എന്നിട്ടും VPN ക്ലയന്റ് അവതരിപ്പിക്കാൻ ഒന്നും ഇല്ലാതിരിക്കാം. എൻഡ്പോയിന്റ് ഏത് രീതിയെ വിശ്വസിക്കുന്നുവെന്ന് തീരുമാനിക്കുക, തുടർന്ന് നൽകുന്ന ആക്സസിന് പൂർണ്ണ ടണൽ ശരിയായ രൂപമാണോ എന്ന് തീരുമാനിക്കുക.
API ഐഡന്റിറ്റി ടണൽ ഐഡന്റിറ്റിയല്ല
«IAM റോൾ അറ്റാച്ച് ചെയ്തിട്ടുണ്ട്, പിന്നെന്തുകൊണ്ട് VPN ഇപ്പോഴും പരാജയപ്പെടുന്നു» എന്ന് ആരെങ്കിലും ചോദിച്ചാൽ, ഉത്തരം സാധാരണയായി കണക്ഷൻ പ്രവാഹത്തിലെ ഒരു ഘട്ടവും ആ റോൾ വായിക്കുന്നില്ല എന്നതാണ്. ക്ലയന്റ് ഒരു സർട്ടിഫിക്കറ്റ്, AD ഉപയോക്തൃനാമവും പാസ്വേഡും, അല്ലെങ്കിൽ SAML അവകാശവാദം അവതരിപ്പിക്കുന്നു. എൻഡ്പോയിന്റ് അവയിലൊന്ന് സാധൂകരിച്ച് പിന്നീട് ഒരു വിലാസം അനുവദിക്കുന്നു.
IAM ഇപ്പോഴും പ്രധാനമാണ്, പക്ഷേ പിന്നീട്, മറ്റൊരിടത്ത്: എൻഡ്പോയിന്റ് സൃഷ്ടിക്കൽ, സബ്നെറ്റുകൾ ബന്ധിപ്പിക്കൽ, റൂട്ടുകൾ പ്രസിദ്ധീകരിക്കൽ, അധികാര നിയമങ്ങൾ എഴുതൽ എന്നിവ API പ്രവർത്തനങ്ങളാണ്. ആ അനുമതികൾ അവ ആവശ്യമുള്ള ഓപ്പറേറ്റർമാർക്ക് മാത്രമായി പരിമിതപ്പെടുത്തുക, ഓരോ ഉപയോക്താവിനും എൻഡ്പോയിന്റിന്റെ ആക്സസ് നിയമങ്ങൾ വീണ്ടും എഴുതാനുള്ള കഴിവ് നൽകുന്നതിന് പകരം.
എൻഡ്പോയിന്റ് പിന്തുണയ്ക്കുന്ന രീതികളിൽ നിന്ന് തിരഞ്ഞെടുക്കുക
AWS Client VPN സർട്ടിഫിക്കറ്റ് അടിസ്ഥാനമാക്കിയ പരസ്പര പ്രാമാണീകരണം, Active Directory പ്രാമാണീകരണം, SAML അടിസ്ഥാനമാക്കിയ ഫെഡറേറ്റഡ് പ്രാമാണീകരണം എന്നിവ സ്വീകരിക്കുന്നു. നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന ക്ലയന്റ് രീതി ഏതായാലും സെർവർ സർട്ടിഫിക്കറ്റ് ആവശ്യമാണ്, രീതികൾ സംയോജിപ്പിക്കുന്ന കോൺഫിഗറേഷന് രണ്ടും വിജയിക്കണം, ഒന്നല്ല.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
സർട്ടിഫിക്കറ്റുകൾ സ്ഥാപിക്കാൻ ഏറ്റവും വിലകുറഞ്ഞതും വലിയ തോതിൽ തെറ്റാകാൻ ഏറ്റവും എളുപ്പവുമാണ്, കാരണം ഓരോ ഉപയോക്താവിനും ഒരു ക്രെഡൻഷ്യൽ ആവശ്യമാണ്, ഓരോ പുറത്തുപോക്കിനും റദ്ദാക്കൽ ആവശ്യമാണ്. ഡയറക്ടറി പ്രാമാണീകരണം ആ ജീവിതചക്രം നിലവിലുള്ള ഒരു സിസ്റ്റത്തിലേക്ക് മാറ്റുന്നു. ഫെഡറേഷൻ അത് ഒരു ഐഡന്റിറ്റി പ്രൊവൈഡറിലേക്ക് മാറ്റുകയും ക്ലയന്റിൽ ഒരു ബ്രൗസർ ഘട്ടം ചേർക്കുകയും ചെയ്യുന്നു.
ക്ലയന്റ് ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് എൻഡ്പോയിന്റിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ വായിക്കുക. ഉപയോക്താവ് അടിസ്ഥാനമാക്കിയ രീതിക്കൊപ്പം പരസ്പര പ്രാമാണീകരണം സജീവമാണെങ്കിൽ, സാധുവായ സർട്ടിഫിക്കറ്റുള്ള പക്ഷേ ഡയറക്ടറി അക്കൗണ്ടില്ലാത്ത ക്ലയന്റ് ഇപ്പോഴും പരാജയപ്പെടും, പിശക് സാധാരണയായി ഒരു പൊതു ഹാൻഡ്ഷേക്ക് പ്രശ്നം പോലെ തോന്നും.
ഫെഡറേഷൻ ആക്സസ് കീകൾ കൈമാറ്റം ചെയ്യലല്ല
SAML സജ്ജീകരണം IAM ആക്സസ് കീകളോ ഏറ്റെടുത്ത റോളിന്റെ ടോക്കണോ ടണലിലേക്ക് നൽകുന്നില്ല. ഐഡന്റിറ്റി പ്രൊവൈഡർ വ്യക്തിയെ പ്രാമാണീകരിച്ച് ഒരു അവകാശവാദം തിരികെ നൽകുന്നു, എൻഡ്പോയിന്റ് നിങ്ങൾ കോൺഫിഗർ ചെയ്ത വിശ്വാസത്തിന് കീഴിൽ അത് സ്വീകരിക്കുന്നു. ഫലമായുണ്ടാകുന്ന സെഷൻ VPN സെഷനാണ്, AWS API സെഷനല്ല.
ആ വ്യത്യാസമാണ് ആർക്ക് എന്ത് രോഗനിർണ്ണയം ചെയ്യാമെന്ന് തീരുമാനിക്കുന്നത്. IdP പ്രശ്നങ്ങൾ ഒരു ടണലും ഉണ്ടാകുന്നതിന് മുമ്പ് ബ്രൗസർ അല്ലെങ്കിൽ ക്ലയന്റ് പിശകായി പ്രത്യക്ഷപ്പെടുന്നു, അതേസമയം ടണൽ പ്രശ്നങ്ങൾ വിജയകരമായ അവകാശവാദത്തിന് ശേഷം പ്രത്യക്ഷപ്പെടുന്നു. ഏതെങ്കിലും കൺസോൾ തുറക്കുന്നതിന് മുമ്പ് ഇവയിൽ ഏതാണ് നിങ്ങൾ നോക്കുന്നതെന്ന് ചോദിക്കുക.
ലോഗിൻ ചെയ്തതിന് ശേഷവും റൂട്ടുകളും അധികാരവും തീരുമാനിക്കുന്നു
പ്രാമാണീകരണം ഒരു സെഷന് വിലാസം നൽകുന്നു; അത് സെഷന് ഒരു ലക്ഷ്യസ്ഥാനം നൽകുന്നില്ല. എൻഡ്പോയിന്റ് റൂട്ടുകൾ ഏത് സബ്നെറ്റുകളിലേക്ക് അയക്കണമെന്ന് ക്ലയന്റിനോട് പറയുന്നു, അധികാര നിയമങ്ങൾ ഏത് ഉപയോക്താക്കൾക്ക് ആ സബ്നെറ്റുകളിൽ ഏതിലേക്ക് എത്താമെന്ന് തീരുമാനിക്കുന്നു, സുരക്ഷാ ഗ്രൂപ്പുകളും ലക്ഷ്യത്തിന്റെ സ്വന്തം അനുമതികളും ബാക്കിയുള്ളത് തീരുമാനിക്കുന്നു.
അതുകൊണ്ടാണ് വിജയകരമായി പ്രാമാണീകരിച്ച ഉപയോക്താവിനും ഡാറ്റാബേസിലേക്ക് എത്താൻ പരാജയപ്പെടാം. സബ്നെറ്റിന്റെ റൂട്ട് ടേബിൾ ബന്ധം, ഉപയോക്താവിന്റെ ഗ്രൂപ്പിന്റെ അധികാര നിയമം, ലക്ഷ്യത്തിലെ സുരക്ഷാ ഗ്രൂപ്പ് എന്നിവ ഈ ക്രമത്തിൽ പരിശോധിക്കുക, കാരണം ഓരോന്നും വ്യത്യസ്ത തരം കാലഹരണം സൃഷ്ടിക്കുന്നു.
ഒരു സ്വകാര്യ ഡാറ്റാബേസിന്, പോർട്ട് ഫോർവേഡിംഗുമായി താരതമ്യം ചെയ്യുക
യഥാർത്ഥ ജോലി ഒരു സ്വകാര്യ ഡാറ്റാബേസിലേക്കുള്ള ഒരു അംഗീകൃത കണക്ഷനാണെങ്കിൽ, പൂർണ്ണ നെറ്റ്വർക്ക് ടണൽ ആവശ്യകതയല്ല, തിരഞ്ഞെടുപ്പാണ്. AWS Systems Manager Session Manager IAM വഴി ഒരു മാനേജ്ഡ് നോഡിലേക്ക് പോർട്ട് ഫോർവേഡിംഗ് സെഷൻ തുറക്കാം, ആ നോഡ് സ്വകാര്യ നെറ്റ്വർക്കിലെ ഡാറ്റാബേസിൽ എത്തുന്നു. ഉപയോക്താവിന് ഒരിക്കലും VPC വിലാസം ലഭിക്കുന്നില്ല. മാനേജ്ഡ് നോഡ് ഡാറ്റാബേസ് പോർട്ടിൽ എത്താൻ കഴിയുന്ന ഏക ഹോസ്റ്റായി മാറുന്നു, സുരക്ഷാ അവലോകനം സാധാരണയായി ആവശ്യപ്പെട്ടത് അതാണ്. തുടർന്ന് ഉപയോക്താക്കൾക്ക് VPN പ്രൊഫൈലിന് പകരം ഒരു പ്രാദേശിക ക്ലയന്റും സെഷൻ കമാന്റും വേണം.
വ്യാപാരം വ്യാപ്തിയും മുൻവ്യവസ്ഥകളും തമ്മിലാണ്. പോർട്ട് ഫോർവേഡിംഗിന് മാനേജ്ഡ് നോഡിൽ SSM ഏജന്റ്, ആ നോഡിൽ നിന്ന് ഡാറ്റാബേസിലേക്ക് നെറ്റ്വർക്ക് എത്തിച്ചേരൽ, ഉപയോക്താവിന്റെ മെഷീനിൽ Session Manager പ്ലഗിൻ, ആ നിർദ്ദിഷ്ട സെഷൻ ആരംഭിക്കാനുള്ള അനുമതി എന്നിവ വേണം. ഇത് ഓരോ സബ്നെറ്റിലേക്കുമുള്ള വഴിയല്ല, ടണൽ പോലെ അനിയന്ത്രിത പ്രോട്ടോക്കോളുകൾ വഹിക്കുകയുമില്ല.
ഏത് സാഹചര്യത്തിലും ഡാറ്റാബേസിന്റെ സ്വന്തം ഐഡന്റിറ്റി അതിന്റെ സ്ഥാനത്ത് നിലനിർത്തുക. IAM അധികാരപ്പെടുത്തിയതിനാൽ TLS പരിശോധനയും ഡാറ്റാബേസ് പ്രാമാണീകരണവും അപ്രത്യക്ഷമാകുന്നില്ല, അംഗീകൃത സെഷൻ ഉപയോക്താവിന് ഏത് പട്ടികകൾ വായിക്കാമെന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
വ്യാപ്തിയും ജീവിതചക്രവും അനുസരിച്ച് തിരഞ്ഞെടുക്കുക: ധാരാളം ഉപയോക്താക്കൾക്ക് ധാരാളം ലക്ഷ്യങ്ങൾ വേണ്ടിവരികയും സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ ഡയറക്ടറി ജീവിതചക്രം നടത്താനാകുകയും ചെയ്യുമ്പോൾ ടണൽ; കുറച്ച് ആളുകൾക്ക് ഒരു സേവനം വേണ്ടിവരികയും നെറ്റ്വർക്ക് വിലാസങ്ങൾ വിതരണം ചെയ്യാൻ ഇഷ്ടപ്പെടാതിരിക്കുകയും ചെയ്യുമ്പോൾ ഫോർവേഡിംഗ് സെഷൻ. ഏത് സാഹചര്യത്തിലും, പ്രാമാണീകരണ രീതി, അധികാര നിയമം, ഡാറ്റാബേസ് ലോഗിൻ എന്നിവ മൂന്ന് വേറിട്ട വസ്തുതകളായി രേഖപ്പെടുത്തുക, കാരണം അവ വെവ്വേറെ പരാജയപ്പെടുന്നു.