المكاسب:
- القدرة على فصل المصادقة والتفويض وتطبيق الحد الأدنى من التفويض مع RBAC/ABAC
- القدرة على تجنب مخاطر الوكيل المختلطة عن طريق تشغيل النموذج في سياق المستخدم
- القدرة على تخزين وتدوير مفاتيح API مع نظام الإدارة السري
لا يبدأ جزء كبير من الهجمات على نظام الذكاء الاصطناعي بـ "خداع" النموذج، بل بمفتاح API مسروق أو حساب مفوض بشكل مفرط. تأتي هذه الطبقة من الأمان من أمن المعلومات الكلاسيكي، ولكنها تضيف مخاطر جديدة في سياق الذكاء الاصطناعي: نموذج يستدعي رحلة نيابة عن شخص آخر، ويصل حساب الخدمة إلى جميع البيانات، ويتسرب مفتاح إلى GitHub. في هذه الوحدة، سنتعلم كيفية تضييق نطاق الوصول إلى نظام الذكاء الاصطناعي من خلال المصادقة والتفويض (RBAC/ABAC) والحد الأدنى من التفويض والإدارة السرية.
الفرق بين المصادقة والترخيص
كثيرا ما يتم الخلط بين المصطلحين:
- المصادقة: "من أنت؟" - إثبات أن المستخدم/الخدمة هو بالفعل من يدعي (كلمة المرور، الرمز المميز، الشهادة، MFA).
- التفويض: "ماذا يمكنك أن تفعل؟" - تحديد المورد/الإجراء الذي يمكن للطرف المصادق عليه الوصول إليه.
إن الدقة الحاسمة في أنظمة الذكاء الاصطناعي هي كما يلي: عندما يؤدي النموذج العمل نيابة عن مستخدم، هل يعمل بسلطة ذلك المستخدم أم باستخدام حساب خدمة واسع النطاق؟ وهذا الأخير خطير — لأن النموذج الذي تم خداعه عن طريق الحقن يتمتع بإمكانية الوصول الكامل إلى حساب الخدمة.
تحذير: مشكلة "النائب المرتبك": يصل المستخدم ذو السلطة المنخفضة بشكل غير مباشر إلى البيانات التي لا يمكنه الوصول إليها عن طريق الاستعانة بمصادر خارجية لنموذج ذو سلطة عالية. يجب أن يعمل النموذج دائمًا ضمن سياق سلطة المستخدم، وليس سلطته الواسعة.
RBAC وABAC
- RBAC (التحكم في الوصول المستند إلى الدور): يعتمد الوصول على دور المستخدم. يمكن لدور "متخصص الدعم" قراءة ملاحظات العملاء، لكن لا يمكنه حذفها. بسيطة وشائعة.
- ABAC (التحكم في الوصول القائم على السمات): يعتمد الوصول على السمات: قسم المستخدم، وعلامة خصوصية البيانات، والوقت من اليوم، والشبكة التي يأتي منها الطلب. أكثر دقة ولكنها أكثر تعقيدًا.
تبدأ معظم المؤسسات بـ RBAC وتتعمق في ABAC للبيانات الحساسة. القاعدة الأساسية للذكاء الاصطناعي: يجب أن يقوم النموذج بتصفية كل وكيل يستدعيه وكل البيانات التي يصل إليها بناءً على دور/سمات المستخدم الذي يقدم الطلب.
خطوة بخطوة: ممارسة الحد الأدنى من السلطة
- خذ الجرد. ما هي الأدوات التي يستدعيها النموذج، وما هي البيانات التي يصل إليها؟ قائمة لهم جميعا.
- تبرير كل وصول. "هل يحتاج هذا المساعد حقًا إلى حذف السلطة؟" وإلا، قم بإزالته.
- افتراضي للقراءة فقط. يجب أن يكون النموذج قادرًا على القراءة بشكل افتراضي؛ تتطلب كتابة/حذف رمز مميز منفصل وضيق النطاق.
- نقل سياق المستخدم. الاتصال بالمركبة بتفويض المستخدم وليس بحساب الخدمة.
- أوراق اعتماد قصيرة الأجل. استخدم الرموز المميزة قصيرة العمر والتي يتم تجديدها تلقائيًا بدلاً من المفاتيح طويلة العمر.
الإدارة السرية
السر هو بيانات الاعتماد التي يجب أن تظل سرية، مثل مفتاح API أو كلمة المرور أو الرمز المميز أو الشهادة. الحادث الأكثر شيوعًا في مشاريع الذكاء الاصطناعي هو عندما يتم تضمين مفتاح API الخاص بموفر النموذج في الكود ويتسرب إلى التحكم في الإصدار (Git).
التطبيق الصحيح:
- لا تقم أبدًا بتضمين المفاتيح في التعليمات البرمجية؛ استخدم متغير بيئة أو نظام إدارة سري (خدمة تخزن المفاتيح المشفرة وتتحكم في الوصول).
- التناوب: تجديد المفاتيح على فترات منتظمة (على سبيل المثال، كل 90 يومًا)؛ في حالة الاشتباه في وجود تسرب، قم بالإلغاء على الفور.
- تقليل النطاق: يحتوي كل محول على الخدمة المطلوبة والترخيص المطلوب فقط.
- التدقيق: سجل من استخدم المفتاح ومتى وأين.
أربعة قوالب قابلة للنسخ
موجه التحكم في مراجعة الوصول:
قم بتقييم كل أداة في قائمة الأدوات أدناه: - هل هذه الأداة مطلوبة لأداء مهمة هذا المساعد؟ (نعم/لا) - هل هي للقراءة فقط أم للكتابة/المسح؟ - هل يتم استدعاء هذه الأداة بصلاحية المستخدم أو حساب الخدمة؟ قم بوضع علامة على العناصر غير الضرورية أو المسموح بها بشكل مفرط كـ "REMOVE/REDACT".<tools>{{ tool_list }}</tools>
موجه مسح التسرب السري:
ابحث عن أي شيء يمكن أن يكون سرًا مضمنًا في مقتطف التعليمات البرمجية التالي: مفتاح واجهة برمجة التطبيقات، وكلمة المرور، والرمز المميز، وسلسلة الاتصال، والمفتاح الخاص. أعط صفًا واكتب لكل منها. انسخ القيمة في الاستجابة؛القناع (أول 4 أحرف + ***).<code>{{ source }}</code>
قاعدة القرار ذات السلطة الأقل:
عندما يصل طلب أداة/وصول جديد، اسأل:1. هل يمكن تنفيذ المهمة دون هذا الوصول؟ -> إذا كانت الإجابة بنعم: رفض2. هل القراءة فقط كافية؟ -> إذا كانت الإجابة بنعم: امنح إذن الكتابة3. هل يمكن تضييق النطاق إلى مصدر واحد؟ -> إذا كانت الإجابة بنعم: daratالإجابة الافتراضية هي "لا"؛ يتم الحصول على الوصول عن طريق السبب.
تذكير تقويم التناوب:
سجل لكل سر: المالك، تاريخ الإنشاء، انتهاء الصلاحية، النطاق. قم بالإبلاغ عن أي مفتاح تجاوز 90 يومًا أو لم يتم استخدامه لمدة 30 يومًا باعتباره "مرشحًا للتناوب/الإلغاء".
موجه ضعيف / موجه قوي
نهج الفقراء
نهج قوي
يصل النموذج إلى جميع البيانات باستخدام حساب خدمة واحد
يصل النموذج بصلاحية المستخدم الذي يقدم الطلب
مفتاح API مضمن في الكود، ولا يتغير أبدًا
التناوب في مدير السرية الرئيسية، 90 يوما
سلطة "فعل أي شيء" واسعة للمساعد
للقراءة فقط الافتراضي، والكتابة بشكل ضيق
لا تتم مراجعة الوصول أبدًا
مراجعة الوصول المنتظم والإلغاء
ثلاث حالات صغيرة
الحالة 1 - بيانات الوكيل المختلطة المسربة. كان أحد المساعدين الداخليين يعمل باستخدام حساب خدمة يمكنه الوصول إلى جميع سجلات الموظفين. تمكن مستخدم متدرب من الوصول إلى البيانات التي لا يراها عادة بقوله "تلخيص جدول الرواتب التنفيذية"؛ لأن النموذج شكك في ذلك في سياق سلطته الواسعة، وليس المستخدم. وبمجرد تعديل سياق المستخدم ليتم نقله، أصبح المتدرب قادرًا على سحب التسجيلات التي لا يمكن لأحد سواه رؤيتها.
الحالة 2 - مفتاح مسرب، فاتورة بقيمة 190.000 ليرة تركية في أسبوعين. قام أحد المطورين بتضمين مفتاح واجهة برمجة التطبيقات (API) النموذجي في برنامج نصي مساعد ودفعه إلى مستودع عام. عثر الروبوت على المفتاح خلال 40 دقيقة واستخدمه لمدة أسبوعين؛ وصلت الفاتورة إلى 190.000 ليرة تركية. عندما تم نقل المفتاح إلى المدير السري، وتم توصيله بالتدوير، وتمت إضافة فحص المستودع، لم يتكرر الحادث.
الحالة 3 - الوضع الافتراضي للقراءة فقط يمنع المقاطعة. تلقى مساعد DevOps أمر "إعادة تعيين قاعدة بيانات الإنتاج" عبر الحقن الفوري. ومع ذلك، تم منح المساعد رمزًا مميزًا للقراءة فقط؛ كانت الكتابة/المسح في تدفق معتمد منفصل. تم رفض الأمر بسبب خطأ في التفويض وتم تسجيل الحدث كإنذار؛ لم يكن هناك فقدان للبيانات.
نصيحة: اجعل "لا" إجابتك الافتراضية لطلب الوصول الجديد. الوصول هو شيء يتم اكتسابه من خلال التبرير؛ إن إعطاء الجميع على نطاق واسع ومن ثم تقليصه لا يتم على الإطلاق تقريبًا وتتراكم المخاطر.
الأخطاء الشائعة
- تشغيل النموذج بحساب خدمة كبير وفقدان سياق المستخدم (الوكيل المختلط).
- تضمين مفتاح API في الكود وتسريبه إلى التحكم في الإصدار.
- عدم تدوير المفاتيح على الإطلاق ("تعمل، لا تلمس").
- منح المساعد أذونات الكتابة/الحذف بشكل افتراضي.
- منح حق الوصول مرة واحدة وعدم إعادة النظر فيه أبدًا.
- الخلط بين المصادقة والتفويض وافتراض أنه "سجل الدخول، ويمكنه الوصول إلى كل شيء".
باختصار
- المصادقة هي سؤال "من أنت"، والتفويض هو سؤال "ماذا يمكنك أن تفعل"؛ في الذكاء الاصطناعي، يجب أن يعمل كلاهما في سياق المستخدم.
- يجب أن يعمل النموذج بسلطة المستخدم الذي يقدم الطلب، وليس بسلطته الواسعة (تجنب خطر الوكالة المختلطة).
- ابدأ بـ RBAC، وتعمق في ABAC بشأن البيانات الحساسة؛ اجعل الحد الأدنى من السلطة هو الوضع الافتراضي.
- لا تدفن الأسرار في الكود؛ قم بتخزينه في المدير السري، وقم بتضييق نطاقه ووضعه في دورة منتظمة.
- إن الكتابة الافتراضية للقراءة فقط والكتابة الضيقة تحد بشكل كبير من تأثير الحقن.
مهمة التطبيق
قم بإدراج جميع الأدوات والبيانات التي يصل إليها مساعد الذكاء الاصطناعي الخاص بك. أجب عن ثلاثة أسئلة لكل منها: (1) هل هذا ضروري حقًا؟ (2) هل القراءة فقط كافية؟ (3) هل يعمل في سياق المستخدم؟ ثم ابحث عن جميع الأسرار المشفرة (عبر موجه المسح أعلاه) واكتب خطة دوران لكل مفتاح تجده. قم بإزالة ترخيص واحد غير ضروري على الأقل.
قائمة مرجعية
- [ ] يعمل النموذج في سياق سلطة المستخدم الذي يقدم الطلب.
- [ ] تم تضييق نطاق الوصول إلى الأدوات والبيانات إلى مبدأ الامتياز الأقل.
- [ ] الكتابة/المسح منفصلة عن القراءة فقط، وموثقة وضيقة.
- [ ] لا توجد أسرار مدفونة في الكود؛ يتم الاحتفاظ بها في المدير السري.
- [ ] يوجد جدول زمني للتناوب وإجراءات إلغاء المفاتيح.
- [ ] تتم مراجعة عمليات الوصول بانتظام.