Least Privilege का सिद्धांत, समझाया गया

Least privilege एक बार जब आप इसे जोर से कहते हैं तो स्पष्ट लगता है: किसी खाते, प्रक्रिया या उपयोगकर्ता को केवल अपना काम करने के लिए आवश्यक पहुंच दें, कुछ भी नहीं। वह अंतर जो इसे कहने और वास्तव में अपने सिस्टम को उस तरह चलाने के बीच है, वह है जहां अधिकांश breaches एक मामूली घटना से पूरे domain compromise में बदल जाते हैं।

इसका वास्तविक अर्थ क्या है

Least privilege का सिद्धांत (PoLP) कहता है कि सिस्टम में हर विषय — एक उपयोगकर्ता, एक service account, एक application, एक container — अपना कार्य पूरा करने के लिए आवश्यक न्यूनतम permissions के साथ संचालित होना चाहिए। ऐसी permissions नहीं जो सुविधाजनक हों। ऐसी permissions नहीं जो किसी ने तीन साल पहले दीं और revoke करना भूल गएं। न्यूनतम।

यह हर layer पर लागू होता है: file system permissions, database roles, API scopes, cloud IAM policies, firewall rules, sudo access। एक web server process जो static files पढ़ता है उसे /etc में write access की जरूरत नहीं है। एक reporting script जो केवल SELECT queries चलाता है उसे DROP TABLE rights वाली database role की जरूरत नहीं है। एक marketing intern को domain admin की जरूरत नहीं है क्योंकि सही group निकालना आसान नहीं था।

यह क्यों मायने रखता है, जितना यह लगता है उससे अधिक

जब कोई attacker किसी खाते या प्रक्रिया को compromise करता है, तो वे जो कुछ भी वह खाता कर सकता है उसे inherit करते हैं। अगर phished employee का laptop केवल उनकी team के लिए relevant file shares तक पहुंच रखता है, तो उस phish का blast radius contained रहता है। अगर उसी खाते को domain admin rights हैं क्योंकि IT ने troubleshooting के लिए एक बार ऐसा सेटअप किया और कभी rollback नहीं किया, तो attacker के पास अब पूरे network है।

यह अधिकांश post-breach forensic reports के पीछे का logic है: initial access कम मूल्य का था, लेकिन over-permissioned accounts के माध्यम से lateral movement ने इसे पूरे environment में ransomware में बदल दिया। Excess privilege initial compromise का कारण नहीं बनता, लेकिन यह लगभग हमेशा वही है जो compromise को महंगा बनाता है।

यह practice में कहां दिखता है

Cloud IAM. AWS, Azure, और GCP सभी permissive behavior के साथ default होते हैं अगर आप सावधान नहीं हैं — एक IAM policy जिसमें "Action": "*" और "Resource": "*" हो वह validation pass करेगा और ठीक काम करेगा, ठीक तब तक जब तक कि एक leaked access key एक attacker को पूरे account control नहीं दे देता। Policies को wildcard तक पहुंचने की जगह specific actions और resource ARNs तक scope करें।

Service accounts. ये अक्सर सबसे बुरे अपराधी होते हैं क्योंकि कोई उन्हें उसी तरह review नहीं करता जैसे human accounts को करते हैं। एक CI/CD pipeline जो एक S3 bucket में deploy करता है उसे credentials नहीं रखने चाहिए जो account के हर bucket को read कर सकें।

Database roles. Read-only reporting roles को application roles से अलग करें जिन्हें INSERT/UPDATE की जरूरत है, और उन्हें DBA role से अलग करें जो schema को alter कर सकता है। PostgreSQL और MySQL दोनों granular GRANT statements को support करते हैं — उन्हें हर app connection को equivalent-of-root देने की जगह use करें।

Sudo और local admin. Just-in-time elevation (access request करें, सीमित window के लिए पाएं, इसे automatically lose करें) standing admin rights से हमेशा बेहतर होता है। sudo जैसे tools time-limited rules के साथ, या enterprise environments में PAM solutions, विशेष रूप से इसके लिए exist करते हैं।

The tension with