Least Privilege-ன் கொள்கை, விளக்கப்பட்டது

Least privilege என்பது உச்சரிக்கும்போது தெளிவாகவே தோன்றுகிறது: ஒரு கணக்கு, செயல்முறை, அல்லது பயனருக்கு அதன் வேலையைச் செய்ய தேவையான அணுகல் மட்டுமே வழங்கு, அதற்கு அধிகமாக எதுவுமில்லை. அதை சொல்வதற்கும் உண்மையாக உங்கள் அமைப்புகளை அந்த வழியில் இயக்குவதற்கும் இடையிலான இடைவெளி தான் பெரும்பாலான மீறல்களை ஒரு சிறிய சம்பவத்திலிருந்து முழு டொமைன் சமரசமாக மாற்றுகிறது.

இது உண்மையில் என்ன அர்థம்

Least privilege-ன் கொள்கை (PoLP) சொல்கிறது ஒரு அமைப்பில் ஒவ்வொரு பொருளும் — ஒரு பயனர், ஒரு சேவை கணக்கு, ஒரு பயன்பாடு, ஒரு கொள்ளளவு — அதன் செயல்பாட்டை முடிக்க தேவையான குறைந்தபட்ச அனுமதிகளின் தொகுப்பைக் கொண்டு இயங்க வேண்டும். வசதியான அனுமதிகள் அல்ல. மூன்று வருடங்களுக்கு முன்பு யாரோ வழங்கிய மற்றும் திரும்பப் பெற மறந்துவிட்ட அனுமதிகள் அல்ல. குறைந்தபட்சமானவை.

இது ஒவ்வொரு அடுக்கிலும் பொருந்தும்: ফைல் சிஸ்டம் அனுமதிகள், தரவுத்தளம் பாத்திரங்கள், API நோக்கங்கள், கிளவுட் IAM கொள்கைகள், ஃபயர்வாலைப் பெண்டிக் விதிகள், sudo அணுகல். ஸ்ট்যাটிক் ஃபைலைப் படிக்கும் வெப் சர்வர் செயல்முறைக்கு /etc-ஐ எழுத அணுகல் தேவையில்லை. SELECT வினவல்களை மட்டுமே இயக்கும் ஒரு அறிக்கை ஸ்க்ரிப்டுக்கு DROP TABLE உரிமைகளைக் கொண்ட தரவுத்தளம் பாத்திரம் தேவையில்லை. மார்க்கெட்டிங் இன்டர்ன் டொமைன் நிர்வாகக் குறிப்பைப் பெற வேண்டியதில்லை, சரியான குழுவைக் கண்டுபிடிப்பதை விட இது எளிதாக இருந்தது என்ற காரணத்தால்.

இது ஏன் இதைப் போல் தெரிவதை விட அधिক முக்கியமாக உள்ளது

ஒரு தாக்குனர் ஒரு கணக்கு அல்லது ஒரு செயல்முறையை சமரசப்படுத்தும்போது, அந்தக் கணக்கு செய்ய முடியும் என்ற எதையும் அவர்கள் பெறுகிறார்கள். ஒரு பிishing করப்பட்ட ஊழியரின் ল்যாப்டாப் கணக்கு தங்கள் குழুவுக்கு சம்பந்தப்பட்ட ஃபைல் பகிர்தலுக்கு மட்டுமே அணுகல் இருந்தால், அந்தப் பிishing-ன் வெடிப்பு வரம்பு அடக்கப்பட்டுள்ளது. அதே கணக்கு டொமைன் நிர்வாகக் குறிப்பைக் கொண்டிருந்தால், IT தகராறுதல் செய்ய அதை ஒரு முறை அமைத்து அதை ஒருபோதும் உருவாக்கவில்லை என்றால், தாக்குனர் இப்போது நெட்வொர்க்கைக் கொண்டிருக்கிறார்.

பெரும்பாலான மீறல்-பின் ஃபோரென்சிக் அறிக்கைகளுக்குப் பின்னால் உள்ள தர্க்கம் இவ்வாறுதான்: প্রাரம்ப அணுகல் குறைந்த-மூல்य, ஆனால் over-permissioned கணக்குகளில் பக்க இயக்கம் முழு சூழ்நிலায் ransomware ஆக மாற்றியது. அதிகப்படியான சலுகை ஆரம்ப சமரசத்தை ஏற்படுத்துவதில்லை, ஆனால் இது சமரசத்தை ஆகக்கூடியவற்றாக்குவது கிட்டத்தட்ட எப்போதும் உள்ளது.

இது நடைமுறையில் எங்கே தோன்றுகிறது

கிளவுட் IAM. AWS, Azure, மற்றும் GCP ஆகியவை நீங்கள் கவனமாக இல்லாவிட்டால் அனுமதிக்கொடுக்கப்பட்ட நடத்தைக்கு இயல்பாக மாற்றுகின்றன — "Action": "*" மற்றும் "Resource": "*" கொண்ட IAM கொள்கை சரிபார்ப்பை கடந்து சரியாக வேலை செய்யும், சரியான அவधि வரை ஒரு வெளியாக்கப்பட்ட அணுகல் விசை ஒரு தாக்குனருக்கு முழு கணக்கு கட்டுப்பாட்டை வழங்கும் வரை. wildcards என்பதற்குப் பதிலாக கொள்கைகளை குறிப்பிட்ட நடவடிக்கைகள் மற்றும் வள ARNs-க்கு பரிধி செய்யவும்.

சேவை கணக்குகள். இவை பெரும்பாலான times மோசமான குற்றவாளிகளாக உள்ளன, ஏனென்றால் யாரோ மனித கணக்குகள் பর்যালோசனை செய்யும் வழியை பரிசீலிக்கவே இல்லை. ஒரு CI/CD பাইப்லைன் ஒரு S3 bucket-க்கு স্থாপனை செய்ய வேண்டும், கணக்கில் ஒவ்வொரு bucket ஐ வாசிக்க முடியும் என்ற credentials ஐ வைத்திருக்க வேண்டாம்.

தரவுத்தளம் பாத்திரங்கள். வாசனை-மட்டு அறிக்கை பாத்திரங்களை INSERT/UPDATE தேவைப்படும் பயன்பாட்டு பாத்திரங்களிலிருந்து பிரிக்கவும், மற்றும் அவற்றை schema மாற்றக்கூடிய DBA பாத்திரத்திலிருந்து பிரிக்கவும். PostgreSQL மற்றும் MySQL ஆகிய இரண்டும் granular GRANT statements ஐ ஆதரிக்கின்றன — அவற்றைப் பயன்படுத்தவும் ஒவ்வொரு பயன்பாட்டு இணைப்புக்கும் root சமமான பொருளை வழங்குவதற்குப் பதிலாக.

Sudo மற்றும் உள்ளூர் நிர்வாகம். Just-in-time elevation (அணுகல் கோரி, ஒரு সীமિত சாளரத்திற்கு அதைப் பெற்று, தானாக அதை잃க) நிற்கும் நிர்வாக உரிமைகளை ஒவ்வொரு முறையும் வெல்கிறது. Time-limited விதிகள் கொண்ட sudo அல்லது enterprise சூழ்நிலைகளில் PAM தீர்வுகள் போன்ற கருவிகள் குறிப்பாக இதற்கு உள்ளன.

பதற்றம் உடன்