TLS, നെറ്റ്‌വർക്ക് പ്രവേശനം, SQL അനുമതികൾ എന്നിവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു
ഒരു കണക്ഷൻ എൻക്രിപ്റ്റ് ചെയ്യുക, ഒരു ഉറവിടം അനുവദിക്കുക, ഒരു പട്ടിക നൽകുക എന്നിവ മൂന്ന് തീരുമാനങ്ങളാണ്. TLS-ന് VPN-നെ മാറ്റിസ്ഥാപിക്കാനാകുമോ എന്ന് ചോദിക്കുന്നതിന് മുമ്പ് അവ ക്രമത്തിൽ പരിശോധിക്കുക.
ഒരു ഉപഭോക്താവിന് PostgreSQL ലോഗിൻ നൽകിയാൽ ചെലവ് ക്ലെയിം ആദ്യം മുതൽ അവസാനം വരെ എൻക്രിപ്റ്റ് ചെയ്ത് സഞ്ചരിക്കും എന്ന് ആരോ നിർദ്ദേശിക്കുന്നു. ഡാറ്റാബേസ് അഡ്മിനിസ്ട്രേറ്റർക്ക് യഥാർത്ഥ SQL സെഷൻ വേണം, മറ്റൊരാൾ പകരം ഒരു വെബ് ഫോം നിർദ്ദേശിക്കുന്നു. രണ്ട് നിർദ്ദേശങ്ങളും തെറ്റായ പ്രശ്നമാണ് പരിഹരിക്കുന്നത്, കാരണം രണ്ടും ഉപഭോക്താവ് യഥാർത്ഥത്തിൽ ചെയ്യുന്ന പ്രവർത്തനത്തിൽ നിന്ന് തുടങ്ങിയിട്ടില്ല. മൂന്ന് തീരുമാനങ്ങളും ക്രമത്തിൽ പരിശോധിക്കുക, എന്നാൽ TLS-ന് VPN-നെ മാറ്റിസ്ഥാപിക്കാനാകുമോ എന്ന ചോദ്യം സ്വയം ഉത്തരം നൽകും.
ഉപഭോക്താവിന് ആവശ്യമായ പ്രവർത്തനത്തിൽ നിന്ന് തുടങ്ങുക
ഉപഭോക്താവ് എന്ത് നേടണം എന്ന് എഴുതുക. ക്ലെയിം സമർപ്പിക്കുക, ഒരു റിപ്പോർട്ടിന്റെ ഒരു വരി വായിക്കുക, തൽക്ഷണ അന്വേഷണം പ്രവർത്തിപ്പിക്കുക എന്നിവ വ്യത്യസ്ത അപകടസാധ്യതാ പ്രൊഫൈലുകളുള്ള മൂന്ന് വ്യത്യസ്ത പ്രവർത്തനങ്ങളാണ്.
പിന്നീട് അഭ്യർത്ഥന ആരാണ് നടത്തുന്നത് എന്ന് എഴുതുക. ഉപഭോക്താവ്, പിന്തുണാ ഏജന്റ്, അഡ്മിനിസ്ട്രേറ്റർ എന്നിവർ ഒരേ പട്ടിക സ്പർശിച്ചാലും പരസ്പരം മാറ്റിസ്ഥാപിക്കാനാവില്ല. ഈ വ്യത്യാസം ഉപഭോക്താവ് അന്വേഷണ ഭാഷയുടെ എത്ര ഭാഗം കാണണം എന്ന് തീരുമാനിക്കുന്നു.
ഉത്തരങ്ങളുടെ ജോടി ഇന്റർഫേസ് തീരുമാനിക്കുന്നു. അതിന് ശേഷമുള്ളതെല്ലാം നടപ്പാക്കലാണ്, എൻക്രിപ്ഷനെക്കുറിച്ചുള്ള മിക്ക തർക്കങ്ങളും യഥാർത്ഥത്തിൽ ഏത് ഇന്റർഫേസ് തിരഞ്ഞെടുത്തു എന്നതിനെക്കുറിച്ചുള്ള തർക്കമാണ്.
മൂന്ന് നിയന്ത്രണങ്ങൾ, മൂന്ന് തീരുമാനങ്ങൾ
പ്രാമാണീകരിച്ച TLS കണക്ഷനെ സംരക്ഷിക്കുന്നു, ഏത് TLS ഐഡന്റിറ്റികൾ സ്വീകരിക്കണം എന്ന് തീരുമാനിക്കുന്നു. നെറ്റ്‌വർക്ക് പ്രവേശനം ഏത് ഉറവിടങ്ങൾക്ക് ശ്രോതാവിനെ എത്താം എന്ന് തീരുമാനിക്കുന്നു. ഡാറ്റാബേസ് അനുമതി ഒരു റോളിന് ഏത് വസ്തുക്കളും പ്രവർത്തനങ്ങളും ഉപയോഗിക്കാം എന്ന് തീരുമാനിക്കുന്നു.
മൂന്നിൽ ഒന്നും മറ്റുള്ളവയെ മാറ്റിസ്ഥാപിക്കുന്നില്ല, അത് പട്ടിക വ്യക്തമാക്കുന്നു.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
മറ്റൊരു വരി നീക്കം ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങൾ ആശ്രയിക്കുന്ന വരി വായിക്കുക. ഈ രൂപകൽപ്പനകളിൽ മിക്കതും നിയന്ത്രണം കോൺഫിഗർ ചെയ്യുന്നതിന് പകരം അനുമാനിച്ചതിനാൽ പരാജയപ്പെടുന്നു.
നേരിട്ടുള്ള SQL ഡാറ്റാബേസ് നയത്തെ ഉത്തരവാദിയായി നിലനിർത്തുന്നു
അംഗീകരിച്ച നേരിട്ടുള്ള കണക്ഷൻ ഉണ്ടെങ്കിൽ സേവന ഐഡന്റിറ്റി പരിശോധനയും ഉദ്ദേശിച്ച പ്രവേശന നയവും രണ്ടും നിലനിർത്തുക. TLS ഓൺ ചെയ്യുന്നത് എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷനുകൾ ലഭ്യമാക്കുന്നു; പ്രവേശന കോൺഫിഗറേഷൻ hostssl എൻട്രികൾ വഴി അത് ആവശ്യപ്പെടുന്നില്ലെങ്കിൽ അത് എൻക്രിപ്റ്റ് ചെയ്യാത്തവ നിരസിക്കുന്നില്ല.
ഈ വ്യത്യാസം ടെംപ്ലേറ്റിലല്ല, പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനിൽ പരിശോധിക്കേണ്ടതാണ്. TLS വാഗ്ദാനം ചെയ്യുകയും സാധാരണ ടെക്സ്റ്റ് സ്വീകരിക്കുകയും ചെയ്യുന്ന സർവർ, മിക്ക ആളുകളും വിന്യസിച്ചു എന്ന് കരുതുന്ന രൂപകൽപ്പനയല്ല. പ്രവേശന നിയമങ്ങൾ വായിച്ച് ഏത് എൻട്രികൾ യഥാർത്ഥത്തിൽ അത് ആവശ്യപ്പെടുന്നു എന്ന് നോക്കുക. ആ ഒരു പരിശോധന എൻക്രിപ്ഷൻ കഴിവുള്ള സർവറിനെ എൻക്രിപ്റ്റ് ചെയ്തതിൽ മാത്രമുള്ള സർവറിൽ നിന്ന് വേർതിരിക്കുന്നു.
ജോലിക്ക് ആവശ്യമായ അനുമതികൾ മാത്രമുള്ള റോളുകൾ ഉപയോഗിക്കുക, ഉടമസ്ഥത, പാരമ്പര്യ അംഗത്വം, വ്യാപകമായി നൽകിയ അനുമതികൾ എന്നിവ അവലോകനം ചെയ്യുക. PostgreSQL അനുമതി മാതൃക ഡാറ്റാബേസ് വസ്തുക്കൾക്കുള്ള അധികാര പരിധിയാണ്.
ഡാറ്റാബേസ് പ്രാമാണീകരണത്തിന് മുമ്പ് ഏത് ഉപകരണങ്ങൾ സേവനത്തിൽ എത്തുന്നു എന്ന് VPN പരിമിതപ്പെടുത്താം, പ്രവേശന ഗേറ്റ്‌വേയും സമാനമായ എന്തെങ്കിലും ചെയ്യാം. രണ്ടും വെളിപ്പെടുത്തിയ ഘടകം പരിപാലിക്കുക, ക്രെഡൻഷ്യലുകൾ കൈകാര്യം ചെയ്യുക, വിഭവ ഉപയോഗം പരിമിതപ്പെടുത്തുക എന്നിവയുടെ ആവശ്യകത ഒഴിവാക്കുന്നില്ല.
ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകൾ ഒരു ക്രെഡൻഷ്യലാണ്, ACL അല്ല
ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റിന് കണക്ഷൻ സമയത്ത് ഒരു വ്യവസ്ഥ ചേർക്കാം. clientcert ക്രമീകരണത്തിന് വിശ്വസ്ത സർട്ടിഫിക്കറ്റും കർശന മോഡിൽ സർട്ടിഫിക്കറ്റിന്റെ പേരും ഡാറ്റാബേസ് ഉപയോക്താവും തമ്മിലുള്ള ബന്ധവും ആവശ്യപ്പെടാം.
അത് കൂടുതൽ ശക്തമായ ക്രെഡൻഷ്യലാണ്. അത് അനുമതി പട്ടികയല്ല, സർവറിനെ അദൃശ്യമാക്കുന്നുമില്ല, കാരണം കണക്ഷൻ സ്വീകരിക്കുന്ന ഘടകം ഇപ്പോഴും നെറ്റ്‌വർക്ക് ട്രാഫിക്കും ഹാൻഡ്ഷേക്കും പ്രോസസ്സ് ചെയ്യുന്നു. സർട്ടിഫിക്കറ്റിനെ പ്രവേശന പട്ടികയായി കാണുന്നത് യഥാർത്ഥ അനുമതികളെ തൊടാതെ വിടുന്നു. അത് സർട്ടിഫിക്കറ്റ് വിതരണം വിശാലമാക്കാനും പ്രവണത കാണിക്കുന്നു, അത് അടുത്ത പ്രശ്നം സൃഷ്ടിക്കുന്നു.
അധികാരാധിക്യമുള്ള റോളിൽ ഘടിപ്പിച്ച ശക്തമായ സർട്ടിഫിക്കറ്റ് നന്നായി പ്രാമാണീകരിച്ച അഡ്മിനിസ്ട്രേറ്ററെ ഉണ്ടാക്കുന്നു. സർട്ടിഫിക്കറ്റ് ആഘോഷിക്കുന്നതിന് മുമ്പ് റോൾ പരിശോധിക്കുക.
യോജിക്കുമ്പോൾ ഇടുങ്ങിയ ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുക
ചെലവ് ക്ലെയിമിന്, ക്ലെയിം സ്വീകരിക്കുകയും ബിസിനസ് നിയമങ്ങൾ നടപ്പാക്കുകയും ആ ഉപയോക്താവിന്റെ അനുവദനീയ ഫലം തിരികെ നൽകുകയും ചെയ്യുന്ന ആപ്ലിക്കേഷൻ എൻഡ്‌പോയിന്റ് പൊതുവായ SQL അക്കൗണ്ടിനെക്കാൾ പ്രവർത്തനത്തെ നന്നായി പ്രതിനിധീകരിക്കുന്നു.
തുടർന്ന് ആപ്ലിക്കേഷൻ അതിന്റെ സ്വന്തം പരിമിതമായ ഡാറ്റാബേസ് ഐഡന്റിറ്റി ഉപയോഗിക്കുന്നു, ഉപഭോക്താവിന് ഒരിക്കലും ഒരു സവിശേഷതയായി അന്വേഷണ ഭാഷ ലഭിക്കുന്നില്ല. അത് തെറ്റാകാനുള്ള വഴികൾ കുറവുള്ള ചെറിയ ഉപരിതലമാണ്.
ഇത് ഒരു രൂപകൽപ്പനാ ഓപ്ഷനാണ്, ആപ്ലിക്കേഷൻ കോഡ് സ്വയമേവ സുരക്ഷിതമാണ് എന്ന അവകാശവാദമല്ല. ആ കോഡ് അതിന്റെ വിളിക്കുന്നവരെ പ്രാമാണീകരിക്കണം, ഓരോ പ്രവർത്തനവും അനുവദിക്കണം, അതിന്റെ ഇൻപുട്ട് സാധുതയുള്ളതാക്കണം, അതിന്റെ സ്വന്തം ഡാറ്റാബേസ് അനുമതികൾ ഇപ്പോഴും പ്രധാനമാണ്.
അംഗീകരിച്ച ജോലിക്ക് അത് ആവശ്യമുള്ള ആളുകൾക്കും ഉപകരണങ്ങൾക്കും നേരിട്ടുള്ള SQL ഇപ്പോഴും ശരിയാണ്. ആ രൂപകൽപ്പനയെ റോളുകൾ, നെറ്റ്‌വർക്ക് പരിധി, പ്രവർത്തന പരിമിതികൾ എന്നിവയാൽ നിയന്ത്രിക്കുക, മറ്റ് ക്ലയന്റുകൾ ഇടുങ്ങിയ ഇന്റർഫേസ് നിലനിർത്തട്ടെ. രണ്ട് ജനസംഖ്യകളെ ഒരു റോളിൽ കലർത്തുന്നതാണ് തർക്കങ്ങൾ തുടങ്ങുന്ന ഇടം.