VPN വഴി Cassandra: ക്ലയന്റുകൾക്കും നോഡുകൾക്കും വേർതിരിച്ച പ്രവേശനം

ഒരു Cassandra വിന്യാസത്തിന് ഒരു സാർവത്രിക ഡാറ്റാബേസ് നെറ്റ്‌വർക്കില്ല. ആപ്ലിക്കേഷനുകൾ ക്ലയന്റ് സേവനവുമായി സംസാരിക്കുന്നു, ക്ലസ്റ്റർ അംഗങ്ങൾ പരസ്പരം സംസാരിക്കുന്നു, ഓപ്പറേറ്റർമാർ ഭരണപരമായ ഇന്റർഫേസുകൾ ഉപയോഗിക്കുന്നു, ഈ മൂന്ന് വിഭാഗങ്ങൾ പരസ്പരം അവരുടെ എത്തിച്ചേരൽ പാരമ്പര്യമായി സ്വീകരിക്കരുത്. VPN പോലുള്ള സ്വകാര്യ പാത നല്ല തുടക്കമാണ്, പക്ഷേ അത് ഡാറ്റാബേസിന്റെ ഉപയോക്തൃ ഐഡന്റിറ്റിയല്ല, അതിന്റെ എൻക്രിപ്ഷൻ നയവുമല്ല. കണക്റ്റിവിറ്റി തീരുമാനവും അധികാര തീരുമാനവും രണ്ട് വേർതിരിച്ച അവലോകനങ്ങളായി കാണുക.

മൂന്ന് വിഭാഗങ്ങളിൽ ഓരോന്നിനും സ്വന്തം ഉത്തരം ലഭിക്കുന്നു, താഴെയുള്ള വിഭാഗങ്ങൾ അവയെ വെളിപ്പെടുത്തലിന്റെ ക്രമത്തിൽ ചർച്ച ചെയ്യുന്നു.

മൂന്ന് വിഭാഗങ്ങൾ, മൂന്ന് തീരുമാനങ്ങൾ

ഏതെങ്കിലും നിയമം തൊടുന്നതിന് മുൻപ് ഓരോ ഗ്രൂപ്പിനും യഥാർത്ഥത്തിൽ എന്ത് വേണം എന്ന് തിരിച്ചറിയുക. ക്ലയന്റുകൾക്ക് ക്ലയന്റ് ശ്രോതാവും അവർക്ക് നൽകാവുന്ന ഓരോ നോഡിലും എത്താൻ ആവശ്യമായ വിവരവും വേണം, പിയർ നോഡുകൾക്ക് ഇന്റർനോഡ് പോർട്ടിൽ പരസ്പരം വേണം, ഓപ്പറേറ്റർമാർക്ക് റൺബുക്ക് യഥാർത്ഥത്തിൽ ആവശ്യപ്പെടുന്നതിനുള്ള മാനേജ്മെന്റ് ഇന്റർഫേസ് വേണം. മൂന്ന് പട്ടികകൾ, മൂന്ന് വിഭാഗങ്ങൾ, മൂന്ന് വിശ്വാസ നിലവാരങ്ങൾ.

സാധാരണ തെറ്റ് ഒരു പരന്ന സ്വകാര്യ സെഗ്മെന്റ് നിർമ്മിച്ച് VPN അതിർത്തി ബാക്കി ചെയ്യുമെന്ന് കരുതുന്നതാണ്. അതിനുള്ളിൽ, ക്ലയന്റ് പോർട്ടിൽ എത്തുന്ന ആപ്ലിക്കേഷൻ സാധാരണയായി ഇന്റർനോഡ് പോർട്ടിലും എത്തുന്നു, ഓപ്പറേറ്ററുടെ ഭരണ ഉപകരണങ്ങൾ പലപ്പോഴും ആപ്ലിക്കേഷനുമായി ഒരേ ജമ്പ് ഹോസ്റ്റിൽ ഇരിക്കുന്നു. ഇവയെ ഒരുമിച്ച് പരന്നതാക്കുന്നത് അർത്ഥമാക്കുന്നത്, വിട്ടുവീഴ്ച ചെയ്ത ആപ്ലിക്കേഷൻ ഐഡന്റിറ്റിക്ക് ഇതിനകം അതിന്റെ സ്വന്തം ക്വറികളേക്കാൾ വലിയ എത്തിച്ചേരൽ ഉണ്ട് എന്നാണ്. ഡിസൈൻ ഡോക്യുമെന്റിൽ മൂന്ന് വിഭാഗങ്ങളെ മൂന്ന് വരികളായി വരയ്ക്കുക, ഓരോന്നിനും അത് അനുവദിക്കുന്ന നിയമം ചേർക്കുക, ആരെങ്കിലും അവ നിർമ്മിക്കുന്നതിന് മുൻപ് വിടവുകൾ ദൃശ്യമാകും.

ക്ലയന്റുകൾക്ക് വേണ്ടത്, അതിൽ കൂടുതലൊന്നുമല്ല

വിന്യസിച്ച പതിപ്പിനായി ഉദ്ദേശിച്ച ആപ്ലിക്കേഷൻ സ്രോതസ്സുകൾക്ക് ക്ലയന്റ് എൻഡ്പോയിന്റുകളിൽ എത്താൻ അനുവദിക്കുക, ബന്ധമില്ലാത്ത ക്ലസ്റ്റർ, മാനേജ്മെന്റ് സേവനങ്ങൾ ആ എത്തിച്ചേരലിന് പുറത്ത് നിർത്തുക. തുടർന്ന് ഡ്രൈവർ നോഡുകൾ എങ്ങനെ കണ്ടെത്തുന്നു എന്ന് പരിശോധിക്കുക. എത്തിച്ചേരാവുന്ന പ്രാരംഭ കോൺടാക്റ്റ് പോയിന്റ്, ഡ്രൈവർ പിന്നീട് തിരഞ്ഞെടുക്കുന്ന ഓരോ നോഡ് വിലാസവും ആ ക്ലയന്റ് സന്ദർഭത്തിൽ നിന്ന് എത്തിച്ചേരാവുന്നതാണെന്ന് തെളിയിക്കുന്നില്ല, കാരണം ഡ്രൈവർ ക്ലസ്റ്ററിനോട് പിയറുകളെക്കുറിച്ച് ചോദിച്ച് പിന്നീട് ക്ലസ്റ്റർ പരസ്യപ്പെടുത്തുന്ന വിലാസങ്ങളിലേക്ക് ബന്ധിപ്പിക്കുന്നു.

അതുകൊണ്ടാണ് സ്വകാര്യ വിലാസത്തിലെ ഒരു പൊരുത്തക്കേട് പരിചിതമായ മാതൃക സൃഷ്ടിക്കുന്നത്: വിജയകരമായ ആദ്യ കണക്ഷൻ, തുടർന്ന് സമയപരിധി കഴിയൽ. പരസ്യപ്പെടുത്തിയ വിലാസങ്ങളും ക്ലയന്റ് റൂട്ടിംഗും ബോധപൂർവം ക്രമീകരിക്കുക; ഒരു പൊരുത്തക്കേട് പരിഹരിക്കാൻ മുഴുവൻ ക്ലസ്റ്ററും ഇന്റർനെറ്റിൽ പ്രസിദ്ധീകരിക്കുന്നത് റൂട്ടിംഗ് പിഴവിനെ തിരിച്ചെടുക്കാനാകാത്ത വെളിപ്പെടുത്തലുമായി കൈമാറുന്നു.

ആപ്ലിക്കേഷന്റെ ഡാറ്റാബേസ് പ്രാമാണീകരണവും റോൾ അനുമതികളും അവയുടെ സ്ഥാനത്ത് നിർത്തുക. പങ്കിട്ട പരിഭാഷപ്പെടുത്തിയ VPN വിലാസം നിരവധി ഉപയോക്താക്കളെയോ സേവനങ്ങളെയോ പ്രതിനിധീകരിക്കാം, അതിനാൽ അത് ഒരിക്കലും വേറിട്ട ഡാറ്റാബേസ് ഐഡന്റിറ്റികൾക്ക് പകരമാകുന്നില്ല.

ക്ലയന്റ്-മുതൽ-നോഡ്, ഇന്റർനോഡ് എന്നിവ വേർതിരിച്ച് എൻക്രിപ്റ്റ് ചെയ്യുക

Apache-ന്റെ സുരക്ഷാ ഡോക്യുമെന്റേഷൻ ക്ലയന്റ്-മുതൽ-നോഡ്, ഇന്റർനോഡ് എൻക്രിപ്ഷനുകളെ വേർതിരിച്ച കോൺഫിഗറേഷനുകളായി കാണുന്നു, ഒന്ന് സജീവമാക്കുന്നത് മറ്റൊന്നിനെ സജീവമാക്കുന്നില്ല. ആ വ്യത്യാസം VPN-നുള്ളിലും ബാധകമാണ്, കാരണം ടണൽ അതിന്റെ സ്വന്തം സെഗ്മെന്റിനെ സംരക്ഷിക്കുന്നു, ആപ്ലിക്കേഷൻ പ്രോസസ്സിൽ നിന്ന് ഡാറ്റാബേസ് പ്രോസസ്സിലേക്കോ ക്ലസ്റ്റർ അംഗങ്ങളുടെ ഓരോ ജോടിക്കിടയിലേക്കോ സ്വയമേവ വ്യാപിക്കുന്നില്ല.

ടെംപ്ലേറ്റ് സ്ഥിരമൂല്യം പാരമ്പര്യമായി സ്വീകരിക്കുന്നതിന് പകരം രണ്ടും വ്യക്തമായി ഓണാക്കുന്ന കോൺഫിഗറേഷൻ ഏകദേശം ഇങ്ങനെ കാണാം:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

ഓപ്ഷണൽ ക്ലയന്റ് എൻക്രിപ്ഷൻ അനുവദിക്കുന്ന സെർവർ കോൺഫിഗറേഷനുകളിൽ, TLS സ്വീകരിക്കുന്നത് എൻക്രിപ്റ്റ് ചെയ്യാത്ത കണക്ഷനുകൾ സ്വീകരിക്കുന്നതിനൊപ്പം നിലനിൽക്കാം, അതിനാൽ ഉദ്ദേശ്യമല്ല, ഫലപ്രദമായ നയം വായിക്കുക. ഓരോ ക്ലയന്റും യഥാർത്ഥത്തിൽ ബന്ധപ്പെടുന്ന എൻഡ്പോയിന്റുകൾക്ക് സർട്ടിഫിക്കറ്റ് പേരുകൾ, വിശ്വാസ വിതരണം, പുതുക്കൽ എന്നിവ ആസൂത്രണം ചെയ്യുക; ഹോസ്റ്റ്നെയിമിന് പകരം IP വിലാസം ഇടുന്നത് ക്ലയന്റിന്റെ ഐഡന്റിറ്റി പരിശോധന മാറ്റുന്നു, അതിന്റെ റൂട്ട് മാത്രമല്ല.

ഭരണം അതിന്റെ സ്വന്തം പാതയിൽ നിർത്തുക

ഇന്റർനോഡ് ട്രാഫിക്കിന് അനുവദിച്ച പിയർ കൂട്ടവും സ്വന്തം സംരക്ഷണ നയവും വേണം. ഭരണപരമായ പ്രവേശനത്തിന്, ഉപയോഗിക്കുന്നിടത്ത് JMX ഉൾപ്പെടെ, വേർതിരിച്ച വിഭാഗവും സ്വന്തം പ്രാമാണീകരണവും വേണം. സാധാരണ ക്വറികൾ നൽകാൻ അനുമതിയുള്ള ഒരു ആപ്ലിക്കേഷന് അതുകൊണ്ട് എല്ലാ മാനേജ്മെന്റ് കഴിവുകളും ആവശ്യമില്ല, വിപരീതം കൂടുതൽ മോശമാണ്: ആപ്ലിക്കേഷൻ സെഗ്മെന്റിന് തുറന്ന ഭരണ പാത പിഴവിൽ നിന്ന് പുനർനിർമ്മാണത്തിലേക്കുള്ള ഏറ്റവും ചെറിയ വഴിയാണ്. ആ രണ്ട് വിഭാഗങ്ങളും വേർതിരിച്ച് എഴുതുക, അവയുടെ ഉടമകളെ പേരിടുക, കാരണം സാധാരണയായി അവ വ്യത്യസ്ത ടീമുകളാണ്, അവരുടെ നിയമങ്ങൾ ആകസ്മികമായി ലയിപ്പിച്ചതാണ്.

ഫലപ്രദമായ ക്ലൗഡ് നിയമങ്ങൾ, ഹോസ്റ്റ് നിയമങ്ങൾ, ശ്രോതാവ് കോൺഫിഗറേഷൻ എന്നിവ പരസ്പരം യോജിപ്പിക്കുക. സ്വകാര്യ ശ്രോതാവ് ഇപ്പോഴും അനുദ്ദേശ്യമായ പരിഭാഷയിലൂടെയോ പ്രോക്സിയിലൂടെയോ തുറന്നിരിക്കാം, വിശാലമായ പൊതു നിയമം ഇടുങ്ങിയ VPN നിയമത്തിന് അരികിൽ നിശ്ശബ്ദമായി ഇരിക്കാം, ആരെങ്കിലും രണ്ടും ഒരുമിച്ച് പരിശോധിക്കുന്നത് വരെ.

ഓപ്പറേറ്റർമാർക്ക് യഥാർത്ഥത്തിൽ ഒരു മാനേജ്മെന്റ് പാത വേണ്ടിടത്ത്, അതിന് പേരുള്ള ഉടമയും ആപ്ലിക്കേഷനേക്കാൾ ചെറിയ ക്രെഡൻഷ്യൽ ആയുസ്സും നൽകുക. അടുത്ത വ്യക്തി ക്ലസ്റ്റർ പാരമ്പര്യമായി സ്വീകരിക്കുമ്പോൾ അത് പ്രതിനിധാനം ദൃശ്യമായി നിർത്തുന്നു.

ഡിസൈൻ എന്താണ് വാഗ്ദാനം ചെയ്യുന്നത്

മൂന്ന് വാഗ്ദാനങ്ങളും കണക്റ്റിവിറ്റി പരീക്ഷണങ്ങളാൽ മാത്രമല്ല, യഥാർത്ഥ റോളുകളാൽ സാധൂകരിക്കുക. അംഗീകരിക്കപ്പെട്ട ആപ്ലിക്കേഷൻ അതിന്റെ അനുവദിച്ച ജോലി പൂർത്തിയാക്കണം, അതിൽ കൂടുതലല്ല, ഒഴിവാക്കിയ സ്രോതസ്സ് ക്ലയന്റ് പ്രവേശനത്തിൽ പരാജയപ്പെടണം, ആപ്ലിക്കേഷൻ ഐഡന്റിറ്റി സംരക്ഷിത ഭരണ പാതകളിൽ നിരസിക്കപ്പെടണം. ക്ലയന്റ് പുനഃബന്ധനവും നോഡ് തിരഞ്ഞെടുപ്പും അതേ റോൾഔട്ട് പരീക്ഷണത്തിൽ ചേർക്കുക, കണ്ടെത്തലിലെ പിഴവുകൾ അവിടെയാണ് ഉയർന്നുവരുന്നത്.

ഡിസൈൻ ഡോക്യുമെന്റിൽ മൂന്ന് വാക്യങ്ങളോടെ അവസാനിപ്പിക്കുക: ഏത് ക്ലയന്റുകൾക്ക് ചോദിക്കാം, ഏത് നോഡുകൾക്ക് ആശയവിനിമയം ചെയ്യാം, ഏത് ഓപ്പറേറ്റർമാർക്ക് ഭരണം നടത്താം. VPN-ന് പിന്നിൽ ഇരിക്കുന്നത് ഉപയോഗപ്രദമായ ടോപ്പോളജി വിവരമാണ്, പക്ഷേ അത് ആ മൂന്ന് ചോദ്യങ്ങളിൽ ഏതിനും ഉത്തരമല്ല.