DeployBot کو بلڈ پائپ لائن سے آرٹیفیکٹس (artifacts) شائع کرنے کے لیے ایک طویل مدتی ٹوکن (long-lived token) موصول ہوتا ہے۔ ایک جاب (job) اس ٹوکن کو CI لاگز میں پرنٹ کرتی ہے، ایک حملہ آور لاگ آؤٹ پٹ حاصل کرتا ہے، اور وہی ٹوکن ایک نئے IP ایڈریس سے کامیابی کے ساتھ ایک اندرونی پیکیج شائع کر دیتا ہے۔ حملہ آور کو کسی ملازم کے پاس ورڈ، فشنگ پیج، یا صارف کے سیشن کی ضرورت نہیں پڑی۔ حملہ آور کو صرف ایک ایسے کریڈینشل (credential) کی ضرورت تھی جو کسی خودکار پرنسپل (automated principal) کی نمائندگی کرتا ہو۔
غیر انسانی شناخت (non-human identity) سے مراد وہ پرنسپل (فریقِ عمل) ہے جو کسی خودکار ورک لوڈ، سروس، پائپ لائن، ڈیوائس، یا ایجنٹ کے پیچھے کارفرما ہوتا ہے۔ اس ماحول میں، DeployBot کے پاس اختیار اس لیے ہے کیونکہ ڈاؤن اسٹریم سروسز اس کے ٹوکن کو قبول کرتی ہیں، نہ کہ اس لیے کہ کوئی انسان ہر درخواست پر MFA (کثیر سطحی تصدیق) مکمل کرتا ہے۔ لہٰذا، دفاع کرنے والوں کے لیے سوال آپریشنل نوعیت کا ہے: ہم محدود دائرہ کار والا اختیار کیسے جاری کریں، پروڈکشن کو متاثر کیے بغیر اسے کیسے تبدیل (rotate) کریں، اور غلط استعمال کو کیسے پہچانیں جب کریڈینشل اپنے مطلوبہ رن ٹائم (runtime) سے باہر نکل جائے؟
سب سے سادہ ناکامی کا ایک ان پٹ اور ایک نتیجہ ہوتا ہے۔ DeployBot آرٹیفیکٹ رجسٹری کو ایک کاپی شدہ ‘بیئرر ٹوکن’ (bearer token) پیش کرتا ہے، اور رجسٹری آرٹیفیکٹ کو شائع کر دیتی ہے کیونکہ ٹوکن درست رہتا ہے اور مطلوبہ اجازت کا حامل ہوتا ہے۔ ٹوکن صرف قبضے (possession) کو ثابت کرتا ہے، نہ کہ اس جائز مقام یا عمل کو جس نے اسے حاصل کیا تھا، الا یہ کہ شناخت کا مجموعی ڈیزائن ان جانچ پڑتالوں (checks) کو شامل کرے۔
حد بندی کا اصول (Boundary rule) غیر انسانی کریڈینشل کو کسی پرنسپل کی شناخت کرنی چاہیے، اس کے اختیار کو محدود کرنا چاہیے، اور جاری ہونے کے بعد نگرانی کے قابل (observable) رہنا چاہیے۔
ٹوکن کا لیک ہونا اہم ہے کیونکہ DeployBot، prod-gke-1 میں شناخت کا صرف ایک راستہ ہے۔ Kubernetes کلسٹر Orders API، Billing API، اور Inventory API چلاتا ہے۔ ان سروسز کے ساتھ ساتھ، SupportAgent منظور شدہ سپورٹ ٹولز کو کال کرتا ہے، ETLBot ڈیٹا درآمد کرتا ہے، اور DeployBot آرٹیفیکٹس تیار اور شائع کرتا ہے۔ ہر پرنسپل ایک اجازت کا فیصلہ (authorization decision)، کریڈینشل کا لائف سائیکل، اور ایسے شواہد تخلیق کرتا ہے جنہیں دفاع کرنے والوں کو محفوظ رکھنا چاہیے۔
حملے کی وسعت (attack surface) صرف کلسٹر تک محدود نہیں ہے۔ درخواستیں کلسٹر کی حد، ورک لوڈز کے درمیان سروس میش کی حد، آرٹیفیکٹ رجسٹری، سیکریٹس اسٹور، شناخت فراہم کرنے والے (identity provider) اور اجازت دینے والے سرور (authorization server)، اور بیرونی SaaS فراہم کنندہ کے APIs کو عبور کرتی ہیں۔ ایک حد سے کاپی کیا گیا کریڈینشل دوسری حد پر قبول کیا جا سکتا ہے جب پالیسیاں اس کریڈینشل کو اس کے جاری کنندہ، وصول کنندہ (audience)، ورک لوڈ، ماخذ، یا مجاز عمل پر غور کیے بغیر کافی ثبوت مان لیں۔ نیچے دیا گیا ماحول بعد کے کنٹرولز (controls) کو ایک مستقل ہدف فراہم کرتا ہے۔
آئیے اس بات کا سراغ لگائیں کہ کریڈینشلز اور ٹوکنز ان حدود کو کہاں عبور کرتے ہیں:
یہ خاکہ ظاہر کرتا ہے کہ اختیار (authority) ٹوکنز کے ساتھ کئی سسٹمز میں منتقل ہوتا ہے، جبکہ ہر سسٹم درخواست کے سفر (request trail) کا صرف ایک حصہ ریکارڈ کرتا ہے۔
چونکہ انوینٹری میں اختیار کے ہر راستے کا نام موجود ہے، اس لیے ہم کسی حفاظتی اقدام (control) کا انتخاب کرنے سے پہلے ناکامی کے منظرنامے کا ماڈل بنا سکتے ہیں۔ ریپوزٹری یا CI لاگ سے لیک ہونے والی API کی (key) حملہ آور کو اس وقت تک اصل صارف (principal) کا روپ دھارنے کی اجازت دیتی ہے جب تک کہ اسے منسوخ نہ کر دیا جائے۔ چوری شدہ OAuth کلائنٹ سیکرٹ نئے رسائی ٹوکنز (access tokens) بنا سکتا ہے۔ دوبارہ استعمال کیا جانے والا (replayed) رسائی ٹوکن غیر متوقع نیٹ ورک یا رن ٹائم سے بھی کام کر سکتا ہے۔ یہ چوری کے مختلف راستے ہیں، لیکن ہر ایک ایک ہی حد کو عبور کرتا ہے: ایک بیرونی عنصر (actor) ایسے اسناد (credentials) پیش کرتا ہے جو کسی کنٹرول شدہ ورک لوڈ کے لیے مختص تھے۔
بہت وسیع دائرہ کار (scope) چوری کے بعد کے اثرات کو تبدیل کر دیتا ہے۔ اگر SupportAgent ایک ہی وسیع اجازت کے تحت بلنگ کے ریکارڈ پڑھ سکتا ہے اور ریفنڈ ٹول کو استعمال کر سکتا ہے، تو پرامپٹ پر مبنی ٹول کی درخواست یا ایجنٹ کے کسی سمجھوتہ شدہ (compromised) حصے کی وجہ سے درخواست دہندہ کے مطلوبہ اختیار سے باہر کوئی کارروائی ہو سکتی ہے۔ یہ confused deputy (مبہم اختیار کا حامل نمائندہ) کا مسئلہ ہے: ایک ایسی سروس جس کے پاس جائز اختیار ہو، وہ کسی غیر بھروسہ مند یا ناکافی اختیار والے کالر کے لیے کوئی کارروائی انجام دیتی ہے۔ اس کا حل محض مضبوط تصدیقِ شناخت (authentication) نہیں ہے۔ ٹول کال کے لیے ایک واضح پالیسی کی ضرورت ہوتی ہے جو درخواست دہندہ (principal)، ہدف کے وسائل (target resource)، اور مجاز آپریشن کو آپس میں منسلک کرے۔
روٹیشن (تبدیلی/تجدید) ایک ایسی ناکامی کا باعث بن سکتی ہے جس کا فوری پتہ نہیں چلتا۔ ہو سکتا ہے کہ سیکرٹس اسٹور میں متبادل اسناد موجود ہوں لیکن ETLBot پرانے کیشڈ (cached) سیکرٹ کا استعمال جاری رکھے، یا کوئی ڈاؤن اسٹریم SaaS فراہم کنندہ منصوبہ بند وقت سے زیادہ عرصے تک دونوں ورژنز کو قبول کرتا رہے۔ روٹیشن تب ہی مکمل سمجھی جاتی ہے جب پرانی اسناد درخواستوں کی اجازت نہ دے سکیں اور ورک لوڈ یہ ثابت کر دے کہ وہ متبادل اسناد استعمال کر سکتا ہے۔
بعد کا مرحلہ ہر خطرے کو روک تھام اور ثبوت کے ساتھ جوڑتا ہے:
نیچے دیا گیا موازنہ ہر قسم کی اسناد کی ناکامی کے ساتھ اس کی حد (boundary)، روک تھام کے اقدام، اور ثبوت کے ماخذ کو منسلک رکھتا ہے۔