"ഓഡിറ്റ്" എന്ന് കേൾക്കുമ്പോൾ ആളുകൾ സാധാരണയായി കണക്കുകാരെയും (accountants), സ്പ്രെഡ്ഷീറ്റുകളെയും, ടാക്സ് സീസണും ആണ് സങ്കൽപ്പിക്കുന്നത്. എന്നാൽ സോഫ്റ്റ്വെയർ രംഗത്ത്, ഓഡിറ്റിംഗ് എന്നത് തികച്ചും വ്യത്യസ്തമായ ഒരു മേഖലയാണ്. ഇത് കണക്കുകൾ ഒത്തുനോക്കുന്നതിനേക്കാൾ ഉപരിയായി, നിങ്ങളുടെ കോഡ്, ഡാറ്റ, കൺട്രോളുകൾ എന്നിവയെക്കുറിച്ച് കഠിനമായ ചോദ്യങ്ങൾ ചോദിക്കുന്നതിനെക്കുറിച്ചാണ്. ഒരു സിസ്റ്റംസ് ഓഡിറ്റ് (systems audit) നിങ്ങളുടെ വിവരങ്ങൾ സുരക്ഷിതമാണോ എന്നും, ഡാറ്റ കൃത്യമാണോ എന്നും, നിങ്ങളുടെ വിഭവങ്ങൾ (resources) നിങ്ങൾ വിചാരിക്കുന്ന രീതിയിൽ തന്നെ പ്രവർത്തിക്കുന്നുണ്ടോ എന്നും വിലയിരുത്തുന്നു.
ഒരു ഫങ്ഷണൽ സിസ്റ്റം (functional system) എന്നാൽ അത് വിശ്വസനീയമായ ഒരു സിസ്റ്റം (trustworthy system) ആണെന്ന് അർത്ഥമില്ല. ഒരു അക്കാദമിക് റെക്കോർഡ്സ് പ്ലാറ്റ്ഫോം വിദ്യാർത്ഥികളെ ശരിയായി എൻറോൾ ചെയ്യുകയും കൃത്യമായ ട്രാൻസ്ക്രിപ്റ്റുകൾ നൽകുകയും ചെയ്തേക്കാം, എന്നാൽ അതേസമയം പാസ്വേഡുകൾ പ്ലെയിൻ ടെക്സ്റ്റ് ആയി സുരക്ഷിതമല്ലാത്ത രീതിയിൽ സംഭരിക്കുകയും ചെയ്തേക്കാം. ഒരു ലോജിസ്റ്റിക്സ് ഡാഷ്ബോർഡ് കൃത്യമായ ഡെലിവറി സമയം കാണിച്ചേക്കാം, എന്നാൽ അതിന്റെ ഡാറ്റാബേസ് ക്രെഡൻഷ്യലുകൾ (database credentials) എല്ലാവർക്കും വായിക്കാവുന്ന രീതിയിൽ സോഴ്സ് കോഡിൽ വെളിപ്പെടുത്തുകയും ചെയ്തേക്കാം. ഈ വിടവ് നികത്താനാണ് സിസ്റ്റംസ് ഓഡിറ്റിംഗ് നിലകൊള്ളുന്നത്.
ഒരു സിസ്റ്റംസ് ഓഡിറ്റിൽ യഥാർത്ഥത്തിൽ എന്തൊക്കെ ഉൾപ്പെടുന്നു
അതിന്റെ കാതലായ അർത്ഥത്തിൽ, ഒരു സിസ്റ്റംസ് ഓഡിറ്റ് മൂന്ന് കാര്യങ്ങളാണ് പരിശോധിക്കുന്നത്: കോൺഫിഡൻഷ്യാലിറ്റി (confidentiality), ഇന്റഗ്രിറ്റി (integrity), കാര്യക്ഷമത (efficiency). കോൺഫിഡൻഷ്യാലിറ്റി എന്നാൽ നിങ്ങളുടെ വിദ്യാർത്ഥികളുടെ റെക്കോർഡുകൾ, ഇടപാടുകളുടെ ലോഗുകൾ (transaction logs), അല്ലെങ്കിൽ രോഗികളുടെ ഫയലുകൾ എന്നിവ അർഹരായ ആളുകൾക്ക് മാത്രമേ ലഭ്യമാകൂ എന്നാണ് അർത്ഥമാക്കുന്നത്. ഇന്റഗ്രിറ്റി എന്നാൽ ഡാറ്റ സ്വയം നശിച്ചുപോകാതിരിക്കുകയോ, അതിന്റെ ഉറവിടത്തിൽ നിന്ന് വ്യതിചലിക്കുകയോ, കാലക്രമേണ തെറ്റായ വിവരങ്ങളായി മാറിക്കൊണ്ടിരിക്കാതിരിക്കുകയോ ചെയ്യുക എന്നതാണ്. കാര്യക്ഷമത എന്നാൽ നിങ്ങളുടെ സെർവറുകളും സേവനങ്ങളും പ്രക്രിയകളും വെറുതെ വിഭവങ്ങൾ ഉപയോഗിച്ചു തീർക്കുകയല്ല, മറിച്ച് മൂല്യങ്ങൾ നൽകുന്നുണ്ടെന്നും ഉറപ്പാക്കുന്നു.
ഈ മൂന്ന് ഗുണങ്ങളും തെളിയിക്കപ്പെടേണ്ടവയാണ്. നിങ്ങളുടെ ഡാറ്റാബേസ് ഇതുവരെ തകരാറിലായിട്ടില്ല എന്നതുകൊണ്ട് മാത്രം അതിനെ വിശ്വസിക്കുന്നത് ശരിയായ പരിശോധനയല്ല. ഒരു യഥാർത്ഥ ഓഡിറ്റ്, ഒരു റെഗുലേറ്ററോ, ഉപഭോക്താവോ, അല്ലെങ്കിൽ നിങ്ങളുടെ ഭാവിയിലെ നിങ്ങളോ "സിസ്റ്റം സുരക്ഷിതമാണെന്ന് നിങ്ങൾക്ക് എങ്ങനെ അറിയാം?" എന്ന് ചോദിക്കുമ്പോൾ കാണിക്കാൻ കഴിയുന്ന തെളിവുകൾ നൽകുന്നു.
പ്രധാനപ്പെട്ട സിസ്റ്റംസ് ഓഡിറ്റ് തരങ്ങൾ
എല്ലാ ഓഡിറ്റുകളും ഒരേ കാര്യങ്ങളല്ല പരിശോധിക്കുന്നത്. നിങ്ങൾ നേരിടുന്ന അപകടസാധ്യതകൾ (risks) അനുസരിച്ച്, താഴെ പറയുന്നവയിൽ ഒന്നോ അതിലധികമോ നിങ്ങൾക്ക് ആവശ്യമായി വന്നേക്കാം:
Application Audit. സോഫ്റ്റ്വെയർ ലോജിക് ശരിയാണോ എന്ന് ഇത് പരിശോധിക്കുന്നു. കണക്കുകൂട്ടലുകൾ കൃത്യമാണോ? എഡ്ജ് കേസുകൾ (edge cases) സ്റ്റേറ്റ് മെഷീനുകൾ കൈകാര്യം ചെയ്യുന്നുണ്ടോ? സെൻസിറ്റീവ് ഡാറ്റ കൈകാര്യം ചെയ്യുന്ന ഓരോ ഫങ്ക്ഷനിലും ഓതറൈസേഷൻ (authorization) നടപ്പിലാക്കിയിട്ടുണ്ടോ? ഒരു ഗ്രേഡിംഗ് മോഡ്യൂൾ ദശാംശ സംഖ്യകൾ (decimals) തെറ്റായി റൗണ്ട് ചെയ്യുന്നതോ, അല്ലെങ്കിൽ ഒരു ഡ്രോപ്പ്ഡൗൺ വാല്യൂ മാറ്റുന്നതിലൂടെ സ്കോളർഷിപ്പ് യോഗ്യത പരിശോധനയെ മറികടക്കാൻ കഴിയുന്നതോ ആയ സാഹചര്യങ്ങൾ ആപ്ലിക്കേഷൻ തലത്തിലുള്ള പരാജയങ്ങൾക്ക് ഉദാഹരണങ്ങളാണ്.
Security Audit. ഇത് ആക്സസ് കൺട്രോളുകൾ (access controls), എൻക്രിപ്ഷൻ (encryption), സുരക്ഷാ വീഴ്ചകൾ (vulnerabilities) എന്നിവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു. ഏത് റെക്കോർഡുകൾ ആർക്ക് വായിക്കാം, ഡാറ്റ കൈമാറ്റം ചെയ്യുമ്പോഴും സൂക്ഷിച്ചുവെക്കുമ്പോഴും എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ടോ, സെഷൻ മാനേജ്മെന്റിന് കൃത്രിമങ്ങൾ തടയാൻ കഴിയുമോ എന്നിവ ഇത് പരിശോധിക്കുന്നു. കൂടാതെ, നിങ്ങളുടെ ഡിപെൻഡൻസികൾ (dependencies) അറിയപ്പെടുന്ന സുരക്ഷാ വീഴ്ചകൾക്ക് കാരണമാകുന്നുണ്ടോ എന്നും ഇത് പരിശോധിക്കുന്നു.
Database Audit. ഡാറ്റാ ഇന്റഗ്രിറ്റി ഇവിടെയാണ് നിലനിൽക്കുന്നത്. റഫറൻഷ്യൽ കൺസ്ട്രയിന്റുകൾ (referential constraints) നടപ്പിലാക്കിയിട്ടുണ്ടോ? ബാക്കപ്പുകൾ യഥാർത്ഥത്തിൽ റീസ്റ്റോർ ചെയ്യാൻ കഴിയുന്നതാണോ, അതോ നിങ്ങൾ അവ ഷെഡ്യൂൾ ചെയ്യുക മാത്രമാണോ ചെയ്യുന്നത്? റീറ്റെൻഷൻ പോളിസികൾ (retention policies) നിയമപരമായ ആവശ്യകതകളുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ? ഒരു ഡാറ്റാബേസ് ഓഡിറ്റ് റിക്കവറി പ്ലാനുകളും പരിശോധിക്കുന്നു, കാരണം ഒരിക്കലും പരീക്ഷിച്ചു നോക്കാത്ത ഒരു ബാക്കപ്പ് വെറുമൊരു സിദ്ധാന്തം മാത്രമാണ്.
Network Audit. ഇത് സെർവറുകൾ, ഫയർവാളുകൾ (firewalls), റൂട്ടിംഗ്, ലഭ്യത (availability) എന്നിവ പരിശോധിക്കുന്നു. ആവശ്യമായ പോർട്ടുകൾ മാത്രമേ തുറന്നിട്ടുള്ളൂ എന്നും, ഫയർവാൾ നിയമങ്ങൾ രേഖപ്പെടുത്തിയിട്ടുണ്ടെന്നും, ട്രാഫിക് വർദ്ധനവിനെയോ denial-of-service സംഭവങ്ങളെയോ നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന് നേരിടാൻ കഴിയുമെന്നും ഇത് സ്ഥിരീകരിക്കുന്നു. കൂടാതെ, ആപ്ലിക്കേഷൻ ലെയർ മാത്രമല്ല, ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളും പാച്ച് (patched) ചെയ്തിട്ടുണ്ടോ എന്നും ഇത് പരിശോധിക്കുന്നു.
Compliance Audit. ഇത് സിസ്റ്റത്തെ ബാഹ്യ നിയമങ്ങളുമായി താരതമ്യം ചെയ്യുന്നു. വിദ്യാർത്ഥി പ്ലാറ്റ്ഫോമുകൾക്ക് FERPA പാലിക്കേണ്ടി വന്നേക്കാം. ഹെൽത്ത് കെയർ സിസ്റ്റങ്ങൾ HIPAA പാലിച്ചിരിക്കണം. പേയ്മെന്റ് പ്രോസസ്സിംഗിന് PCI-DSS അനുസരിച്ചുള്ള ക്രമീകരണങ്ങൾ ആവശ്യമാണ്. കംപ്ലയൻസ് എന്നത് സുരക്ഷിതമായിരിക്കുക എന്നത് മാത്രമല്ല; ആ സുരക്ഷ ഒരു ബാഹ്യ അധികാരിക്ക് തെളിയിച്ചു കാണിക്കാൻ കഴിയുന്നതിനെക്കുറിച്ചുകൂടിയാണ്.
Operational Audit. കോഡ് എന്നത് കഥയുടെ പകുതി മാത്രമാണ്. ഈ ഓഡിറ്റ് മെയിന്റനൻസ് പ്രക്രിയകൾ, സപ്പോർട്ട് വർക്ക്ഫ്ലോകൾ, ചേഞ്ച് മാനേജ്മെന്റ് (change management), ഡോക്യുമെന്റേഷൻ എന്നിവ പരിശോധിക്കുന്നു. ഒരു മികച്ച ആപ്ലിക്കേഷന്റെ ഡിപ്ലോയ്മെന്റ് പൈപ്പ്ലൈൻ (deployment pipeline) മനസ്സിലാക്കുന്ന ഏക വ്യക്തി സ്ഥാപനം വിട്ടുപോയാൽ, ആ ആപ്ലിക്കേഷൻ ഒരു ബാധ്യതയായി മാറും.
ഒരു യഥാർത്ഥ ഉദാഹരണം: EduManage v1.0 ഓഡിറ്റ് ചെയ്യുന്നു
അടുത്തിടെ ഞാൻ ഒരു അക്കാദമിക് മാനേജ്മെന്റ് പ്ലാറ്റ്ഫോമായ EduManage v1.0-ൽ ഒരു ഇന്റേണൽ സെക്യൂരിറ്റി, ആപ്ലിക്കേഷൻ ഓഡിറ്റ് നടത്തി. എൻറോൾമെന്റ്, റെക്കോർഡുകൾ, ഗ്രേഡിംഗ് എന്നിവയാണ് ഈ സിസ്റ്റം കൈകാര്യം ചെയ്തിരുന്നത്. യഥാർത്ഥ വിദ്യാർത്ഥി ഡാറ്റ ഉപയോഗിക്കുന്നതിന് മുമ്പ്, ഇത് വിശ്വസിക്കാമോ എന്ന് ഞങ്ങൾക്ക് അറിയണമായിരുന്നു. ഞാൻ ലളിതമായ ആറ് ഘട്ടങ്ങളുള്ള ഒരു പ്രക്രിയയാണ് പിന്തുടർന്നത്, മിക്ക ഇന്റേണൽ ഓഡിറ്റുകൾക്കും ഇതേ ഘടന ഞാൻ ശുപാർശ ചെയ്യുന്നു.
വ്യാപ്തി ആസൂത്രണം ചെയ്യുക. അതിരുകളില്ലാത്ത ഓഡിറ്റുകൾ അവസാനിക്കാത്ത കഠിനമായ ജോലികളായി മാറുന്നു. ഏതെല്ലാം മോഡ്യൂളുകളാണ് പരിഗണനയിലുള്ളതെന്ന് ഞങ്ങൾ കൃത്യമായി നിർണ്ണയിച്ചു: authentication, record management, core enrollment workflows എന്നിവ. Third-party integrations-ഉം physical infrastructure-ഉം ഇതിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല. ഞങ്ങൾ ഇതിനായി രണ്ടാഴ്ച അനുവദിക്കുകയും സംശയങ്ങൾക്ക് മറുപടി നൽകാൻ കഴിയുന്ന പ്രധാന വ്യക്തികളെ കണ്ടെത്തുകയും ചെയ്തു. ഈ വ്യക്തത scope creep ഒഴിവാക്കാനും എല്ലാവരെയും ഒരേ ലക്ഷ്യത്തിൽ നിലനിർത്താനും സഹായിക്കുന്നു.
വിവരങ്ങളും രേഖകളും ശേഖരിക്കുക. ഞാൻ architecture diagrams, API documentation, database schemas, മുൻപത്തെ incident reports എന്നിവ ശേഖരിച്ചു. Deployment practices-നെ കുറിച്ചും tech stack തിരഞ്ഞെടുപ്പുകളെ കുറിച്ചും ഞാൻ lead developer-നോട് സംസാരിച്ചു. നിങ്ങൾക്ക് മനസ്സിലാകാത്ത ഒരു കാര്യവും പരിശോധിക്കാൻ കഴിയില്ല, കൂടാതെ ഈ ഘട്ടത്തിൽ എടുക്കുന്ന തെറ്റായ അനുമാനങ്ങൾ തുടർന്നുള്ള എല്ലാ കണ്ടെത്തലുകളെയും ബാധിക്കും.
പരിശോധനകൾ നടത്തുക. ഞങ്ങൾ മൂന്ന് രീതികളിലൂടെയാണ് സിസ്റ്റത്തെ സമീപിച്ചത്. ഒരു code review-ലൂടെ anti-patterns, injection flaws, insecure dependencies എന്നിവ ഞങ്ങൾ കണ്ടെത്തി. Enrollment caps, prerequisite checks തുടങ്ങിയ business rules, വെറും frontend code-ന് പിന്നിൽ മറച്ചുവെക്കുകയല്ല, മറിച്ച് അസാധുവായ അവസ്ഥകളെ (invalid states) യഥാർത്ഥത്തിൽ തടയുന്നുണ്ടെന്ന് functional tests വഴി ഞങ്ങൾ ഉറപ്പുവരുത്തി. ഒരു ബാഹ്യ ആക്രമണകാരിയെപ്പോലെ (external attacker) പെനട്രേഷൻ ടെസ്റ്റുകൾ (Penetration tests) ഞങ്ങൾ നടത്തി; ഇതിലൂടെ exposed endpoints പരിശോധിക്കുകയും, എന്തൊക്കെയാണ് ചോരുന്നത് അല്ലെങ്കിൽ തകരാറിലാകുന്നത് എന്ന് അറിയാൻ requests മാറ്റിമറിക്കുകയും ചെയ്തു.
റിസ്കുകളും കണ്ടെത്തലുകളും വിശകലനം ചെയ്യുക. കണ്ടെത്തിയ എല്ലാ സുരക്ഷാ വീഴ്ചകളും (vulnerabilities) ഒരുപോലെ പ്രധാനപ്പെട്ടതല്ല. ഓരോ കണ്ടെത്തലിനെയും അതിന്റെ സാധ്യത (likelihood) അനുസരിച്ച് ഞങ്ങൾ തരംതിരിച്ചു...