VPN-ൽ നിന്ന് VLAN-ലേക്കുള്ള പ്രവേശനം: നിയമങ്ങൾക്ക് മുമ്പ് മാട്രിക്സ് നിർമ്മിക്കുക
ഒരു വശത്ത് റോളുകൾ, മറുവശത്ത് സേവനങ്ങൾ. അഞ്ച് പരിശോധനകൾ അവ്യക്തമായ VPN-മുതൽ-VLAN വരെയുള്ള പ്രവേശന രൂപകൽപ്പനയെ ഫയർവാൾ ഉടമ നടപ്പാക്കാൻ കഴിയുന്ന ഒരു പട്ടികയാക്കി മാറ്റുന്നു.
ഫയർവാൾ സിന്താക്സിൽ നിന്നല്ല, മാട്രിക്സിൽ നിന്ന് തുടങ്ങുക. ഒരു വശത്ത് റോളുകളും മറുവശത്ത് സേവനങ്ങളും ഉള്ള പട്ടിക ഒരു ആപ്ലിക്കേഷൻ ഉടമക്ക് പരിശോധിക്കാം, സുരക്ഷാ ഉടമക്ക് ചർച്ച ചെയ്യാം, ഗേറ്റ്‌വേ കൈവശമുള്ള ആർക്കും നടപ്പാക്കാം. ആരും യോജിച്ചിട്ടില്ലാത്ത നിയമങ്ങൾ ഡീബഗ് ചെയ്യുന്നതിനേക്കാൾ വിലകുറഞ്ഞതാണ് ആ പരിശോധന.
അതെഴുതാൻ ഒരു മണിക്കൂർ ചെലവിടുന്നത് പിന്നീട് ഒരു ആഴ്ചത്തെ നിയമ-പുരാവസ്തുശാസ്ത്രം ലാഭിക്കുന്നു. ആരു ഏത് സേവനത്തിൽ എത്തുന്നു എന്നതാണ് രൂപകൽപ്പന പറയുന്നത്, പുനർനമ്പറിംഗിന് ശേഷം നിലനിൽക്കുന്നത് ആ ഭാഗമാണ്.
ഘട്ടം 1: നെറ്റ്‌വർക്കുകൾക്ക് മുമ്പ് റോളുകൾക്ക് പേരിടുക
സ്വിച്ചിൽ നിന്നല്ല, ആളുകളിൽ നിന്ന് തുടങ്ങുക. വിദൂരത്തുനിന്ന് ബന്ധിപ്പിക്കുന്ന ഓരോ ഗ്രൂപ്പും അത് എന്ത് ചെയ്യുന്നു എന്ന് വിവരിക്കുന്ന ഒരൊറ്റ വാക്യവും എഴുതുക, ഉദാഹരണത്തിന് സ്റ്റോക്ക് നില വായിക്കുന്ന വെയർഹൗസ് ജീവനക്കാരോ ഒരു ഇന്റഗ്രേഷൻ പരിപാലിക്കുന്ന കരാറുകാരനോ. രണ്ട് ഗ്രൂപ്പുകൾക്ക് ഒരേ പ്രവേശനം ലഭിക്കുമെങ്കിൽ, ഈ ആവശ്യത്തിന് അവ ഒരു റോളാണ്.
റോൾ ഒരു ഓർഗനൈസേഷൻ ചാർട്ട് കാരണം മാത്രം നിലനിൽക്കുന്നെങ്കിൽ ഇവിടെ നിർത്തുക. സ്വന്തം സേവന ആവശ്യമില്ലാത്ത റോൾ ഒരേപോലുള്ള സെല്ലുകളുടെ നിരയാകുന്നു, ഒരേപോലുള്ള നിരകൾ പിന്നീട് സൗകര്യാർത്ഥം ഒരു മുഴുവൻ സബ്നെറ്റ് നൽകാൻ ആരെയെങ്കിലും പ്രേരിപ്പിക്കുന്നു. ആളുകൾ എന്ത് ചെയ്യുന്നു എന്നതനുസരിച്ച് വിഭജിക്കുക, അവരുടെ ചെലവിൽ ആരു ഒപ്പിടുന്നു എന്നതനുസരിച്ചല്ല. ചെറിയ ഓഫീസിന് ആറ് റോളുകൾ സാധാരണയായി കൂടുതലാണ്, മൂന്ന് പലപ്പോഴും ശരിയാണ്.
ഘട്ടം 2: ഓരോ സെല്ലിനെയും സേവന പ്രസ്താവനയാക്കുക
«ആപ്ലിക്കേഷനുകൾ» എന്ന് എഴുതിയ സെൽ പരിശോധിക്കാനാവില്ല. «സ്റ്റാഫ് പൂളിൽ നിന്ന് 443-ൽ ERP ഹോസ്റ്റിലേക്ക് HTTPS» എന്ന് എഴുതിയ സെൽ പരിശോധിക്കാം. ഓരോ നെറ്റ്‌വർക്ക് പേരും ലക്ഷ്യസ്ഥാനം, പ്രോട്ടോക്കോൾ, പോർട്ട് എന്നിവ കൊണ്ട് മാറ്റിസ്ഥാപിക്കുക, തുടർന്ന് സേവനം അതില്ലാതെ പ്രവർത്തിക്കാത്ത ആശ്രിതത്വം ചേർക്കുക, ഉദാഹരണത്തിന് ആന്തരിക റിസോൾവർ അല്ലെങ്കിൽ ഐഡന്റിറ്റി പ്രൊവൈഡർ.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
ദിശാ കോളം ഏറ്റവും ചെലവേറിയ തെറ്റുകൾ പിടിക്കുന്നു. ജീവനക്കാർക്ക് ഒരു ആപ്ലിക്കേഷൻ തുറക്കാനുള്ള അനുമതി ആപ്ലിക്കേഷൻ സെർവറുകൾക്ക് ജീവനക്കാരുടെ ലാപ്‌ടോപ്പുകളിലേക്ക് തിരികെ കണക്ഷനുകൾ തുറക്കാനുള്ള അനുമതി അർത്ഥമാക്കുന്നില്ല, ഒപ്പം ആദ്യ ദിശ അനുവദിക്കുന്ന സ്റ്റേറ്റ്ഫുൾ നിയമം പലപ്പോഴും രണ്ടാമത്തേതും അനുവദിക്കുന്നതായി വായിക്കപ്പെടുന്നു.
ഘട്ടം 3: ഐഡന്റിറ്റി എവിടെ നയമാകുന്നു എന്ന് തീരുമാനിക്കുക
ആരെങ്കിലും പ്രാമാണീകരിച്ച സെഷനെ ഗേറ്റ്‌വേ നടപ്പാക്കാൻ കഴിയുന്ന ഒരു റോളാക്കി മാറ്റണം. പിന്തുണയ്ക്കുന്ന ഓപ്ഷനുകളിൽ ഓതന്റിക്കേഷൻ ബാക്കെൻഡ് നൽകുന്ന ഗ്രൂപ്പ് പോളിസി, വിശ്വസനീയ സെഷൻ ആട്രിബ്യൂട്ടുകൾ, അല്ലെങ്കിൽ ഓരോ റോളിനും വെവ്വേറെ വിലാസ പൂളുകൾ എന്നിവ ഉൾപ്പെടുന്നു. മൂന്നും പ്രവർത്തിക്കുന്നു; ക്ലയന്റ് അയക്കുന്ന ലേബൽ പ്രവർത്തിക്കുന്നില്ല. ഫോറം പോസ്റ്റ് വിവരിക്കുന്നതല്ല, നിങ്ങളുടെ ഗേറ്റ്‌വേ രേഖപ്പെടുത്തുന്ന സംവിധാനം തിരഞ്ഞെടുക്കുക.
VLAN-ന് അവകാശമുള്ളതായി മാത്രം തോന്നുന്ന ഒരു വിലാസം നൽകുന്നത് മറ്റൊരു വേഷത്തിലുള്ള അതേ മറുപടിയില്ലായ്മയാണ്. OpenVPN ഫയർവാൾ നിയമങ്ങളെക്കുറിച്ചുള്ള Netgate ഗൈഡ് ഈ വേർതിരിവ് വ്യക്തമാക്കുന്നു: ടണൽ ഉയരാൻ അനുവദിക്കുന്നത് അതിലൂടെ ട്രാഫിക് കടക്കാൻ അനുവദിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ തീരുമാനമാണ്.
ഏത് സംവിധാനം തിരഞ്ഞെടുത്തു, അത് എവിടെ കോൺഫിഗർ ചെയ്തിരിക്കുന്നു എന്ന് എഴുതിവയ്ക്കുക. ഒരു റോൾ മാറുമ്പോൾ, ആ കുറിപ്പ് ഒരു തിരുത്തും മൂന്ന് ഇന്റർഫേസുകളിലൂടെയുള്ള തിരച്ചിലും തമ്മിലുള്ള വ്യത്യാസമാണ്. ഓഡിറ്ററോട് ആദ്യം എവിടെ നോക്കണം എന്നും അത് പറയുന്നു.
ഘട്ടം 4: ലക്ഷ്യസ്ഥാനം കാണുന്ന ഉറവിട വിലാസം ശ്രദ്ധിക്കുക
അതിർത്തിയിൽ ഫോർവേഡിംഗ് നയം യഥാർത്ഥ ഉറവിടവുമായി പൊരുത്തപ്പെടണം. ഗേറ്റ്‌വേ VPN ക്ലയന്റുകളെ സ്വന്തം വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യുന്നെങ്കിൽ, താഴെയുള്ള ഓരോ ഫയർവാളും ഒരൊറ്റ ഉറവിടം കാണുന്നു, റോൾ അനുസരിച്ച് തീരുമാനമെടുക്കാനുള്ള കഴിവ് നഷ്ടപ്പെടുന്നു. അത് ക്ലയന്റിന്റെ വിലാസം സൂക്ഷിക്കുന്നെങ്കിൽ, ആ പൂളിനുള്ള തിരിച്ചുവരവ് പാത നിലനിൽക്കണം.
അന്തിമ നിയമങ്ങൾ എഴുതുന്നതിന് മുമ്പ് രണ്ട് ദിശകളും പരിശോധിക്കുക, തുടർന്ന് നിരീക്ഷിച്ച ഉറവിടം ഓരോ സെല്ലിനും അടുത്ത് രേഖപ്പെടുത്തുക. അതേ പരിശോധന രണ്ട് വ്യത്യസ്ത റോളുകളിൽ നിന്ന് പ്രവർത്തിപ്പിച്ച് ഫലം താരതമ്യം ചെയ്യുക. രണ്ടും ഗേറ്റ്‌വേ വിലാസം കാണിക്കുന്നെങ്കിൽ, റോളുകളുടെ വേർതിരിവ് ഇതിനകം നഷ്ടപ്പെട്ടിരിക്കുന്നു. ഗേറ്റ്‌വേ ഉറവിട വിവർത്തനം ചെയ്യുമ്പോൾ സൂക്ഷിച്ച വിലാസങ്ങൾ അനുമാനിക്കുന്ന മാട്രിക്സ് ആദ്യത്തെ താഴത്തെ ACL-ൽ പരാജയപ്പെടുന്നു.
ഘട്ടം 5: റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് ഓരോ സെല്ലും പരിശോധിക്കുക
അനുവദിച്ച ഓരോ സെല്ലിനെയും ഒരു പ്രതിനിധി പ്രവർത്തനമാക്കി, നിരസിച്ച ഓരോ സെല്ലിനെയും നെഗറ്റീവ് കേസാക്കി മാറ്റുക. രണ്ടും യഥാർത്ഥ റോളിലുള്ള ഒരു ക്ലയന്റിൽ നിന്ന് പ്രവർത്തിപ്പിക്കുക, ഗേറ്റ്‌വേ കൺസോളിൽ നിന്നല്ല, കാരണം കൺസോൾ നിങ്ങൾ പരിശോധിക്കുന്ന പാത ഒഴിവാക്കുന്നു.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'ബന്ധിപ്പിക്കുന്ന നെഗറ്റീവ് കേസ് ഒരു കണ്ടെത്തലാണ്, യാദൃച്ഛികതയല്ല, നിയമം തിരുത്തുന്നതുവരെ അതിന്റെ സ്ഥാനം മാട്രിക്സിൽ പരാജയപ്പെട്ട സെല്ലാണ്. പരീക്ഷണ കമാൻഡുകൾ പട്ടികയ്ക്കരികിൽ സൂക്ഷിക്കുക, അടുത്ത അവലോകകൻ യുക്തി വീണ്ടും കെട്ടിപ്പടുക്കുന്നതിന് പകരം അവ വീണ്ടും പ്രവർത്തിപ്പിക്കട്ടെ.
പൂർത്തിയായ പട്ടിക അത് എഴുതിയ ഗേറ്റ്‌വേയെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കുന്നു. നിയമങ്ങൾ ഫേംവെയറിനും വെണ്ടർക്കും ഒപ്പം മാറുന്നു, എന്നാൽ ഒരു കരാറുകാരൻ ഒരു പ്രോജക്ട് സേവനത്തിൽ എത്തുന്നു എന്ന വരി ആ ജോലി മാറുന്നതുവരെ ശരിയായി തുടരുന്നു.