اصول کم سے کم مراعات، وضاحت

کم سے کم مراعات واضح لگتی ہے جب آپ اسے بول کر کہتے ہیں: کسی اکاؤنٹ، عمل، یا صارف کو صرف وہی رسائی دیں جو اسے اپنا کام کرنے کے لیے چاہیے، کچھ اور نہیں۔ یہ کہنے اور اپنے سسٹم کو اس طریقے سے چلانے کے درمیان خلا ہی وہ جگہ ہے جہاں زیادہ تر خلاف ورزیاں ایک معمولی واقعے سے مکمل ڈومین سمجھوتے میں بدل جاتی ہیں۔

اس کا اصل مطلب

اصول کم سے کم مراعات (PoLP) کہتا ہے کہ سسٹم میں ہر موضوع — ایک صارف، ایک سروس اکاؤنٹ، ایک ایپلیکیشن، ایک کنٹینر — کم سے کم اجازتوں کے ساتھ کام کرے جو اس کے کام کو مکمل کرنے کے لیے درکار ہوں۔ وہ اجازتیں نہیں جو سہولت بخش ہوں۔ وہ اجازتیں نہیں جو کسی نے تین سال پہلے دی تھیں اور واپس لینا بھول گیا۔ کم سے کم۔

یہ ہر سطح پر لاگو ہوتا ہے: فائل سسٹم اجازتیں، ڈیٹابیس کے کردار، API اسکوپ، کلاؤڈ IAM پالیسیاں، فائر وال کے اصول، sudo رسائی۔ ایک ویب سرور کے عمل کو جو static فائلیں پڑھتے ہیں /etc میں لکھنے کی رسائی کی ضرورت نہیں۔ ایک رپورٹنگ اسکرپٹ جو صرف SELECT سوالات چلاتا ہے کو DROP TABLE حقوق کے ساتھ ڈیٹابیس کے کردار کی ضرورت نہیں۔ ایک مارکیٹنگ انٹرن کو ڈومین ایڈمن کی ضرورت نہیں کیونکہ یہ صحیح گروپ معلوم کرنے سے آسان تھا۔

یہ اتنا اہم کیوں ہے جتنا لگتا ہے

جب کوئی حملہ آور کسی اکاؤنٹ یا عمل سے سمجھوتہ کرتا ہے، تو وہ اس اکاؤنٹ کی جو کچھ بھی کر سکتے ہوں۔ اگر کسی phished صارف کے لیپ ٹاپ کے پاس صرف اپنی ٹیم سے متعلق فائل شیئرز تک رسائی ہے، تو اس phish کے نقصان کا دائرہ محدود ہے۔ اگر اسی اکاؤنٹ کے پاس ڈومین ایڈمن حقوق ہوں کیونکہ IT نے اسے ایک بار troubleshooting کے لیے اس طریقے سے سیٹ کیا تھا اور کبھی واپس نہیں لیا، تو حملہ آور اب نیٹ ورک کو نیل رکھتا ہے۔

یہ منطق زیادہ تر خلاف ورزی کے بعد کی forensic رپورٹوں کے پیچھے ہے: ابتدائی رسائی کم قیمت تھی، لیکن over-permissioned اکاؤنٹس کے ذریعے بغاوت کے اگلے قدم اسے پورے ماحول میں ransomware میں بدل دیا۔ اضافی مراعات ابتدائی سمجھوتے کا سبب نہیں بنتی ہیں، لیکن یہ تقریباً ہمیشہ وہی ہے جو سمجھوتے کو مہنگا بناتا ہے۔

یہ عملی طور پر کہاں دکھائی دیتا ہے

Cloud IAM۔ AWS، Azure، اور GCP سب کچھ permissive رویے کو default کرتے ہیں اگر آپ احتیاط سے کام نہ لیں — "Action": "*" اور "Resource": "*" کے ساتھ ایک IAM پالیسی validation کو pass کرے گی اور بہتری سے کام کرے گی، بالکل اس وقت تک جب تک کہ leaked access key کسی حملہ آور کو مکمل اکاؤنٹ کنٹرول نہ دے دے۔ wildcards تک پہنچنے کی بجائے پالیسیوں کو مخصوص actions اور resource ARNs تک محدود کریں۔

سروس اکاؤنٹس۔ یہ اکثر سب سے بدتر قصوروار ہوتے ہیں کیونکہ کوئی ان کا جائزہ اسی طریقے سے نہیں لیتا جیسے وہ انسانی اکاؤنٹس کا جائزہ لیتے ہیں۔ ایک CI/CD pipeline جو ایک S3 bucket میں deploy کرتا ہے کو وہ credentials نہیں رکھنے چاہیے جو اکاؤنٹ میں ہر bucket کو پڑھ سکیں۔

ڈیٹابیس کے کردار۔ read-only reporting کردار کو application کردار سے الگ کریں جن کو INSERT/UPDATE کی ضرورت ہے، اور انہیں DBA کے کردار سے الگ کریں جو schema کو بدل سکتا ہے۔ PostgreSQL اور MySQL دونوں granular GRANT statements کی سپورٹ کرتے ہیں — انہیں استعمال کریں ہر app connection کو root کے برابر دینے کی بجائے۔

Sudo اور local admin۔ Just-in-time elevation (رسائی کی درخواست کریں، ایک محدود ونڈو کے لیے اسے حاصل کریں، خودکار طور پر اسے کھو دیں) standing admin rights کے مقابلے میں ہمیشہ بہتر ہے۔ sudo جیسے tools وقت کے محدود اصول کے ساتھ، یا enterprise ماحول میں PAM حل، خاص طور پر اس کے لیے موجود ہیں۔

کے ساتھ کشیدگی