یونٹ 4 / 11

رسائی کنٹرول، شناخت اور خفیہ انتظام

فائدہ:

  • تصدیق اور اجازت کو الگ کرنے اور RBAC/ABAC کے ساتھ کم سے کم اجازت کا اطلاق کرنے کی اہلیت
  • ماڈل کو صارف کے تناظر میں چلا کر مخلوط پراکسی خطرے سے بچنے کی صلاحیت
  • خفیہ انتظامی نظام کے ساتھ API کیز کو ذخیرہ کرنے اور گھمانے کی صلاحیت

AI سسٹم پر حملوں کا ایک اہم حصہ ماڈل کو "دھوکہ دینے" سے نہیں بلکہ چوری شدہ API کلید یا زیادہ مجاز اکاؤنٹ سے شروع ہوتا ہے۔ سیکیورٹی کی یہ پرت کلاسیکی معلومات کی حفاظت سے آتی ہے، لیکن AI کے تناظر میں نئے خطرات کا اضافہ کرتی ہے: ایک ماڈل کسی اور کی طرف سے ایک سواری کو کال کرتا ہے، ایک سروس اکاؤنٹ تمام ڈیٹا تک رسائی حاصل کرتا ہے، GitHub میں ایک اہم لیکس۔ اس یونٹ میں، ہم سیکھیں گے کہ کس طرح تصدیق، اجازت (RBAC/ABAC)، کم از کم اجازت اور خفیہ انتظام کے ساتھ AI سسٹم تک رسائی کو کم کرنا ہے۔

توثیق اور اجازت کے درمیان فرق

دو شرائط اکثر الجھ جاتی ہیں:

  • توثیق: "آپ کون ہیں؟" - یہ ثابت کرنا کہ صارف/سروس واقعی وہی ہے جس کا وہ دعویٰ کرتے ہیں (پاس ورڈ، ٹوکن، سرٹیفکیٹ، MFA)۔
  • اجازت: "آپ کیا کر سکتے ہیں؟" - اس بات کا تعین کریں کہ تصدیق شدہ فریق کون سے وسائل/کارروائی تک رسائی حاصل کر سکتا ہے۔

AI سسٹمز میں اہم باریک بینی یہ ہے: جب ماڈل کسی صارف کی جانب سے کام کر رہا ہے، کیا یہ اس صارف کی اتھارٹی کے ساتھ کام کر رہا ہے یا ایک وسیع سروس اکاؤنٹ کے ساتھ؟ مؤخر الذکر خطرناک ہے - کیونکہ انجیکشن کے ذریعے دھوکہ دہی کا ماڈل سروس اکاؤنٹ تک مکمل رسائی حاصل کرتا ہے۔

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

آر بی اے سی اور اے بی اے سی

  • RBAC (رول پر مبنی رسائی کنٹرول): رسائی صارف کے کردار پر منحصر ہے۔ "معاون ماہر" کا کردار کسٹمر کے نوٹس پڑھ سکتا ہے، لیکن انہیں حذف نہیں کر سکتا۔ سادہ اور عام۔
  • ABAC (انتساب پر مبنی رسائی کنٹرول): رسائی اوصاف پر منحصر ہے: صارف کا شعبہ، ڈیٹا کا رازداری کا لیبل، دن کا وقت، وہ نیٹ ورک جہاں سے درخواست آتی ہے۔ زیادہ عمدہ لیکن زیادہ پیچیدہ۔

زیادہ تر تنظیمیں RBAC سے شروع ہوتی ہیں اور حساس ڈیٹا کے لیے ABAC تک گہری ہوتی ہیں۔ AI کے لیے انگوٹھے کا اصول: ماڈل کو ہر اس ایجنٹ کو فلٹر کرنا چاہیے جسے وہ کال کرتا ہے اور ہر اس ڈیٹا تک رسائی حاصل کرتا ہے جو درخواست کرنے والے صارف کے کردار/صفات کی بنیاد پر کرتا ہے۔

مرحلہ وار: کم سے کم اتھارٹی کا استعمال

  1. انوینٹری لیں۔ ماڈل کن ٹولز کو کال کرتا ہے، یہ کس ڈیٹا تک رسائی حاصل کرتا ہے؟ ان سب کی فہرست بنائیں۔
  2. ہر رسائی کا جواز پیش کریں۔ "کیا اس اسسٹنٹ کو واقعی ڈیلیٹ اتھارٹی کی ضرورت ہے؟" دوسری صورت میں، اسے ہٹا دیں.
  3. صرف پڑھنے کے لیے ڈیفالٹ۔ ماڈل کو بطور ڈیفالٹ پڑھنے کے قابل ہونا چاہئے؛ علیحدہ، تنگ دائرہ کار ٹوکن لکھنے/حذف کرنے کی ضرورت ہے۔
  4. صارف کے سیاق و سباق کو منتقل کریں۔ گاڑی کو صارف کے اختیار سے کال کریں، سروس اکاؤنٹ سے نہیں۔
  5. قلیل المدت سند۔ طویل المدتی کلیدوں کے بجائے قلیل المدتی، خودکار تجدید کرنے والے ٹوکن استعمال کریں۔

خفیہ انتظام

راز وہ اسناد ہیں جو خفیہ رہیں، جیسے API کلید، پاس ورڈ، ٹوکن، یا سرٹیفکیٹ۔ AI پروجیکٹس میں سب سے عام حادثہ اس وقت ہوتا ہے جب ماڈل فراہم کنندہ کی API کلید کوڈ میں سرایت کر جاتی ہے اور ورژن کنٹرول (Git) میں لیک ہو جاتی ہے۔

درست درخواست:

  • کوڈ میں چابیاں کبھی بھی شامل نہ کریں۔ ماحولیاتی متغیر یا خفیہ نظم و نسق کا نظام استعمال کریں (ایک ایسی خدمت جو کیز کو انکرپٹڈ اسٹور کرتی ہے اور رسائی کو کنٹرول کرتی ہے)۔
  • گردش: چابیاں باقاعدہ وقفوں پر تجدید کریں (جیسے ہر 90 دن)؛ اگر لیک ہونے کا شبہ ہے تو فوراً منسوخ کر دیں۔
  • دائرہ کار میں کمی: ہر سوئچ میں صرف مطلوبہ سروس اور مطلوبہ اجازت ہوتی ہے۔
  • آڈٹ: لاگ کس نے کلید استعمال کی، کب، اور کہاں۔

چار کاپی ایبل ٹیمپلیٹس

رسائی کا جائزہ کنٹرول پرامپٹ:

ذیل میں ٹول لسٹ میں ہر ٹول کے لیے، اندازہ کریں:- کیا اس اسسٹنٹ کے کام کو انجام دینے کے لیے اس ٹول کی ضرورت ہے؟ (ہاں/نہیں) - کیا یہ صرف پڑھنے کے لیے ہے یا لکھنے/مٹانے کے لیے؟ - کیا اس ٹول کو صارف کی اتھارٹی یا سروس اکاؤنٹ سے بلایا جاتا ہے؟ غیر ضروری یا ضرورت سے زیادہ اجازت یافتہ کو "ہٹائیں/ریڈیکٹ" کے بطور نشان زد کریں۔<tools>{{ tool_list }}</tools>

خفیہ لیک اسکیننگ پرامپٹ:

درج ذیل کوڈ کے ٹکڑوں میں ایسی کوئی بھی چیز تلاش کریں جو ہارڈ کوڈ شدہ راز ہو: API کلید، پاس ورڈ، ٹوکن، کنکشن سٹرنگ، نجی کلید۔ ہر ایک کے لیے قطار اور ٹائپ دیں۔ جواب میں قیمت کاپی کریں؛ ماسک (پہلے 4 حروف + ***)۔<code>{{ ماخذ }}</code>

کم سے کم اتھارٹی کے فیصلے کا اصول:

جب کوئی نیا ٹول/ رسائی کی درخواست آتی ہے تو پوچھیں: 1۔ کیا اس رسائی کے بغیر کام انجام دیا جا سکتا ہے؟ -> اگر ہاں: REJECT2۔ کیا صرف پڑھنے کے لیے کافی ہے؟ -> اگر ہاں: لکھنے کی اجازت دیں3۔ کیا دائرہ کار کو کسی ایک ذریعہ تک محدود کیا جا سکتا ہے؟ -> اگر ہاں: darat پہلے سے طے شدہ جواب "نہیں" ہے؛ رسائی عقل سے حاصل ہوتی ہے۔

گردش کیلنڈر کی یاد دہانی:

ہر راز کے لیے، ریکارڈ: مالک، تاریخ تخلیق، میعاد ختم ہونے، دائرہ کار۔ کسی بھی کلید کی اطلاع دیں جو 90 دن سے زیادہ ہو گئی ہو یا 30 دنوں سے بطور "ROTATION/CANCELLATION CANDIDATE" استعمال نہ ہوئی ہو۔

کمزور پرامپٹ / مضبوط اشارہ

غریب نقطہ نظر

مضبوط نقطہ نظر

ماڈل ایک سروس اکاؤنٹ کے ساتھ تمام ڈیٹا تک رسائی حاصل کرتا ہے۔

ماڈل درخواست کرنے والے صارف کے اختیار کے ساتھ رسائی حاصل کرتا ہے۔

API کلید کوڈ میں سرایت کی جاتی ہے، یہ کبھی تبدیل نہیں ہوتی

کلیدی خفیہ مینیجر میں گردش، 90 دن

اسسٹنٹ کو وسیع "کچھ بھی کریں" کا اختیار

صرف پڑھنے کے لیے پہلے سے طے شدہ، تنگ لکھیں۔

رسائی کا کبھی جائزہ نہیں لیا جاتا ہے۔

باقاعدہ رسائی کا جائزہ اور منسوخی

تین چھوٹے کیسز

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

کیس 2 — لیک ہونے والی کلید، 2 ہفتوں میں 190,000 TL بل۔ ایک ڈویلپر نے ماڈل API کلید کو مددگار اسکرپٹ میں سرایت کیا اور اسے عوامی ذخیرہ میں دھکیل دیا۔ ایک بوٹ نے چابی 40 منٹ میں ڈھونڈ لی اور اسے دو ہفتوں تک استعمال کیا۔ بل 190,000 TL تک پہنچ گیا۔ جب چابی کو خفیہ مینیجر کے پاس منتقل کیا گیا، گردش سے منسلک کیا گیا، اور ریپوزٹری سکیننگ شامل کی گئی، تو یہ واقعہ دوبارہ نہیں ہوا۔

کیس 3 - صرف پڑھنے کے لیے پہلے سے طے شدہ رکاوٹ کو روکا گیا۔ ایک DevOps اسسٹنٹ کو فوری انجیکشن کے ذریعے "ری سیٹ پروڈکشن ڈیٹا بیس" کمانڈ موصول ہوئی۔ تاہم، اسسٹنٹ کو صرف پڑھنے کے لیے ٹوکن دیا گیا تھا۔ لکھنا/مٹانا ایک الگ منظور شدہ بہاؤ میں تھا۔ کمانڈ کو اجازت کی غلطی کے ساتھ مسترد کر دیا گیا تھا اور ایونٹ کو الارم کے طور پر لاگ ان کیا گیا تھا۔ ڈیٹا کا کوئی نقصان نہیں ہوا۔

ٹپ: رسائی کی نئی درخواست کا اپنا ڈیفالٹ جواب "نہیں" بنائیں۔ رسائی وہ چیز ہے جو جواز کے ذریعے حاصل کی جاتی ہے۔ سب کو چوڑا دینا اور پھر کاٹنا تقریباً کبھی نہیں ہوتا ہے اور خطرہ جمع ہوجاتا ہے۔

عام غلطیاں

  • ایک بڑے سروس اکاؤنٹ کے ساتھ ماڈل کو چلانا اور صارف کے سیاق و سباق کو کھونا (مخلوط پراکسی)۔
  • API کلید کو کوڈ میں شامل کرنا اور اسے ورژن کنٹرول میں لیک کرنا۔
  • چابیاں بالکل نہیں گھمائیں ("کام کر رہے ہیں، ہاتھ نہ لگائیں")۔
  • اسسٹنٹ کو بطور ڈیفالٹ لکھنے/حذف کرنے کی اجازت دینا۔
  • ایک بار رسائی دینا اور اس پر کبھی غور نہیں کرنا۔
  • اجازت کے ساتھ تصدیق کو الجھانا اور یہ فرض کرنا کہ "وہ لاگ ان ہے، وہ ہر چیز تک رسائی حاصل کر سکتا ہے"۔

خلاصہ میں

  • تصدیق "آپ کون ہیں" کا سوال ہے، اجازت "آپ کیا کر سکتے ہیں" کا سوال ہے؛ AI میں، دونوں کو صارف کے تناظر میں کام کرنا چاہیے۔
  • ماڈل کو درخواست کرنے والے صارف کے اختیار کے ساتھ کام کرنا چاہئے، نہ کہ اس کی اپنی وسیع اتھارٹی (مخلوط ایجنسی کے خطرے سے بچتے ہوئے)۔
  • RBAC کے ساتھ شروع کریں، حساس ڈیٹا پر ABAC کے ساتھ گہرا کریں۔ کم سے کم اتھارٹی کو ڈیفالٹ بنائیں۔
  • کوڈ میں راز دفن نہ کریں؛ اسے خفیہ مینیجر میں محفوظ کریں، اسے تنگ کریں اور اسے باقاعدہ گردش میں رکھیں۔
  • صرف پڑھنے کے لیے طے شدہ اور تنگ تحریر انجیکشن کے اثر کو بہت حد تک محدود کرتی ہے۔

درخواست کا کام

آپ کے AI اسسٹنٹ تک رسائی حاصل کرنے والے تمام ٹولز اور ڈیٹا کی فہرست بنائیں۔ ہر ایک کے لیے تین سوالوں کے جواب دیں: (1) کیا یہ واقعی ضروری ہے؟ (2) کیا صرف پڑھنا کافی ہے؟ (3) کیا یہ صارف کے تناظر میں چلتا ہے؟ پھر تمام ہارڈ کوڈ شدہ رازوں کو تلاش کریں (اوپر اسکین پرامپٹ کے ذریعے) اور آپ کو ملنے والی ہر کلید کے لیے ایک گردشی منصوبہ لکھیں۔ کم از کم ایک غیر ضروری اجازت کو ہٹا دیں۔

چیک لسٹ

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