ഷെഡ്യൂൾ ചെയ്ത ജോലിയോ മനുഷ്യ ലോഗിനോ: ഏത് ഐഡന്റിറ്റിയാണ് API കാണേണ്ടത്?

ഷെഡ്യൂൾ ചെയ്ത ജോലിയും ലോഗിൻ പ്രോംപ്റ്റിന് മുൻപിൽ നിൽക്കുന്ന ഒരാളും ഒരേ API-യെ വ്യത്യസ്ത ക്രെഡൻഷ്യലുകളോടും വ്യത്യസ്ത ആയുസ്സുകളോടും വ്യത്യസ്ത ഉടമകളോടും വിളിക്കുന്നു. ജോലിക്ക് നെറ്റ്വർക്ക് പാത, ആപ്ലിക്കേഷൻ ഐഡന്റിറ്റി, അനുമതികളുടെ കൂട്ടം എന്നിവ വേണം; മനുഷ്യന് ലോഗിൻ, രണ്ടാം ഘടകം, സെഷൻ എന്നിവ വേണം. രണ്ടും കലർത്തിയാൽ മനുഷ്യന്റെ പാസ്വേഡ് മാറുമ്പോഴെല്ലാം തകരുന്ന ഓട്ടോമേഷനോ, cron ജോലി ജീവിച്ചിരിക്കാൻ വേണ്ടി മാത്രം ദുർബലമാക്കിയ ബഹു-ഘടക നയമോ ഉണ്ടാകും.

ഒന്നുപോലെ തോന്നുന്ന മൂന്ന് കവാടങ്ങൾ

ഉറവിട വിലാസ നിയമം അഭ്യർത്ഥന എവിടെ നിന്ന് വന്നു എന്ന് ചോദിക്കുന്നു. പ്രാമാണീകരണം ആരാണ് വിളിക്കുന്നത്, ഏത് തെളിവുകളാണ് നൽകിയത് എന്ന് ചോദിക്കുന്നു. അധികാരപ്പെടുത്തൽ ഈ പ്രിൻസിപ്പലിന് ഈ പ്രവർത്തനം ചെയ്യാമോ എന്ന് ചോദിക്കുന്നു. VPN മൂന്നിൽ ആദ്യത്തേത് മാത്രം മാറ്റുന്നു, ജോലിക്ക് മാത്രമല്ല ഹോസ്റ്റിലെ ഓരോ പ്രോസസ്സിനും അത് മാറ്റുന്നു, അതിനാൽ സംഭവ രേഖയിൽ മൂന്ന് നിരീക്ഷണങ്ങളും വേർതിരിച്ച് സൂക്ഷിക്കുക.

അതുകൊണ്ടാണ് എഗ്രെസ് നോഡ് മാറ്റുന്നത് ഉറവിട വിലാസം കാരണമുള്ള നിരസിക്കലിനെ ശരിയാക്കി അസാധുവായ ടോക്കൺ തൊടാതെ വിടാൻ കഴിയുന്നത്. അതുകൊണ്ടു തന്നെ സാധുവായ API ടോക്കൺ ഉണ്ടെങ്കിലും അങ്ങോട്ട് പാതയില്ലാത്ത ജോലിയിൽ നിന്ന് സ്വകാര്യ എൻഡ്പോയിന്റ് എത്താനാവില്ല.

ഇന്ററാക്ടീവ് പാത ഓട്ടോമേഷന് മോശം ടെംപ്ലേറ്റാണ്

മനുഷ്യന്റെ ലോഗിൻ സ്ക്രിപ്റ്റ് ചെയ്യുന്നത് പ്രലോഭനീയമാണ്, കാരണം അത് ഒരിക്കൽ പ്രവർത്തിക്കുന്നു. സ്ക്രിപ്റ്റ് പാസ്വേഡും, ഒരുപക്ഷേ ഒറ്റത്തവണ പാസ്വേഡ് വിത്തും സൂക്ഷിക്കുന്നു, പിന്നീട് മനുഷ്യനെ ആവശ്യപ്പെടാൻ രൂപകൽപ്പന ചെയ്ത ഒരു വെല്ലുവിളിയെ ആശ്രയിക്കുന്നു. OAuth-ന്റെ നിലവിലെ മികച്ച സുരക്ഷാ രീതി, RFC 9700, resource-owner-password-credentials അനുവാദം വിലക്കുന്നു, അത് രണ്ട് ഘടക, ബഹു-ഘട്ട പ്രാമാണീകരണത്തിന് എന്തുകൊണ്ട് മോശമായി യോജിക്കുന്നു എന്ന് വിശദീകരിക്കുന്നു.

പിന്തുണയുള്ള ബദൽ സാധാരണയായി രഹസ്യ കക്ഷി പ്രവാഹമാണ്, അതിൽ അധികാര സർവർ ആപ്ലിക്കേഷനെ പ്രാമാണീകരിച്ച് ടോക്കൺ നൽകുന്നു. RFC 6749-ന്റെ 4.4 വിഭാഗത്തിലെ client-credentials അനുവാദം അതിന് ഒരു ഉദാഹരണമാണ്. അതിന്റെ നിലനിൽപ്പ് ഓരോ API-യും അത് സ്വീകരിക്കുന്നു എന്നോ, ഉപയോക്താവ് ഡെലിഗേറ്റ് ചെയ്ത ജോലി അതുകൊണ്ട് മാറ്റിസ്ഥാപിക്കാം എന്നോ അർത്ഥമാക്കുന്നില്ല, കാരണം അവ സേവന ഉടമയോടുള്ള ചോദ്യങ്ങളാണ്. കോഡ് എഴുതുന്നതിന് മുൻപ് സേവനം ഏത് മേൽനോട്ടമില്ലാത്ത മാതൃക പിന്തുണയ്ക്കുന്നു എന്ന് ചോദിക്കുക.

VPN ഇപ്പോഴും എവിടെ യോജിക്കുന്നു

സ്വകാര്യ API ആവശ്യപ്പെടുന്ന നെറ്റ്വർക്ക് പാത VPN നൽകാം, അത് സാധുവായ പങ്കാണ്. അത് ജോലിയെ ആപ്ലിക്കേഷനോട് പ്രാമാണീകരിക്കുന്നില്ല, ജോലിക്ക് എന്ത് ചെയ്യാമെന്ന പരിധിയും നിർണ്ണയിക്കുന്നില്ല. പങ്കിട്ട എഗ്രെസ് വിലാസം ജോലിയെയല്ല, ഹോസ്റ്റിനെയാണ് തിരിച്ചറിയുന്നത്, അതിനാൽ ആ വിലാസത്തിനുള്ള അനുവദനീയ പട്ടികയിലെ ഒരു ഇനം അതിൽ പ്രവർത്തിക്കുന്ന ഓരോ പ്രോസസ്സിനെയും കടത്തിവിടുന്നു.

ജോലി പങ്കിട്ട റണ്ണറിൽ പ്രവർത്തിക്കുന്നെങ്കിൽ, ആ വ്യത്യാസം കുറവല്ല, കൂടുതൽ പ്രധാനമാണ്. അതേ ഹോസ്റ്റിലെ മറ്റൊരു വർക്ക്ഫ്ലോ പാതയും വിലാസവും പാരമ്പര്യമായി നേടുന്നു, API-ക്ക് രണ്ടിനെയും വേർതിരിക്കാനാവില്ല. പങ്കിട്ട പാസ്വേഡിന്റെ അതേ ദൗർബല്യമാണിത്, ഒരു പാളി താഴേക്ക് മാറ്റിയത്. ആപ്ലിക്കേഷന് നടപ്പാക്കാൻ കഴിയുന്നിടത്ത് നിയന്ത്രണം വയ്ക്കുക, അനുവദനീയ പട്ടിക കൂടുതൽ ചുരുക്കാനാവില്ലെങ്കിൽ റണ്ണറെ വേർതിരിക്കുക.

രണ്ട് രൂപകൽപ്പനകളും സത്യസന്ധമായി താരതമ്യം ചെയ്യുക

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

രണ്ട് ഉത്തരവും അതെ എങ്കിൽ, രൂപകൽപ്പനയ്ക്ക് കടം വാങ്ങിയ പാസ്വേഡല്ല, ഡെലിഗേഷൻ മാതൃക വേണം. ആ തീരുമാനം അടുത്ത പരിപാലകൻ കണ്ടെത്തുന്നിടത്ത് എഴുതുക.

കൈമാറ്റത്തിന് മുൻപ് എന്ത് പരിശോധിക്കണം

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

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

പ്രിൻസിപ്പൽ, പരിധി, റൊട്ടേഷന്റെ ഉടമ, പ്രവർത്തന പരിസ്ഥിതി എന്നിവ ആ ഫലത്തിന് അടുത്ത് രേഖപ്പെടുത്തുക. ആ രേഖയാണ് അടുത്ത റൊട്ടേഷനെ സംഭവമല്ലാതെ ദിനചര്യയാക്കുന്നത്. ഓഡിറ്റർ ആവശ്യപ്പെടുന്ന ഭാഗവും അതാണ്.