- لماذا تعتبر مراجعات عزل وكلاء الذكاء الاصطناعي مهمة
- أمان حدود التنفيذ
- أمان نظام الملفات والتركيب
- التحكم في العمليات والموارد
- ضوابط الشبكة والتدفق الخارجي
- مخاطر DNS والوصول إلى الحزم
- معالجة الأسرار
- السجلات ومسارات التدقيق
- التقاط القطع الأثرية ومراجعتها
- ضوابط دورة الحياة وإعادة التعيين
- ضوابط الموافقة البشرية
- افتراضات الاستجابة للحوادث
- كيف يتناسب Novita Agent Sandbox
- الخاتمة
- الأسئلة الشائعة
يجب أن تتحقق مراجعة عزل صندوق الحماية لوكلاء الذكاء الاصطناعي من حدود التنفيذ، وتعرض نظام الملفات، والتحكم في العمليات والموارد، وسياسة الشبكة وDNS، وسلوك جلب الحزم، ومعالجة الأسرار، والسجلات، والتقاط القطع الأثرية، ودلالات إعادة التعيين، ونقاط الموافقة البشرية، وافتراضات الاستجابة للحوادث قبل أن يُسمح للكود المُنشأ بالعمل على الأنظمة أو البيانات الحقيقية.
لماذا تعتبر مراجعات عزل وكلاء الذكاء الاصطناعي مهمة
غالبًا ما تبدأ مراجعات صندوق الحماية التقليدية بسؤال واحد: هل يمكن لهذا النظام تشغيل كود غير موثوق دون كشف المضيف؟ تحتاج مراجعات وكلاء الذكاء الاصطناعي إلى هذا السؤال، ولكنها تحتاج أيضًا إلى قائمة تحقق أوسع لأن الوكلاء يفعلون أكثر من مجرد تنفيذ سكريبت واحد. قد يقومون باستنساخ المستودعات، وتثبيت الحزم، وتصفح المواقع، وكتابة الملفات، واستدعاء واجهات برمجة التطبيقات، وفتح جلسات واجهة المستخدم الرسومية، وإعادة محاولة الأوامر الفاشلة، وتحويل مخرجات النموذج إلى إجراءات شيل.
يغير هذا نموذج المخاطر. يمكن لوكيل البرمجة أن يتصرف كمهندس مبتدئ لديه إمكانية الوصول إلى الطرفية. يمكن لوكيل تحليل البيانات أن يتصرف كمستخدم دفتر ملاحظات يقوم بتحميل الملفات، وجلب الحزم، وتصدير الرسوم البيانية. يمكن لوكيل المتصفح أن يتصرف كمستخدم لديه ملفات تعريف ارتباط، وتنزيلات، ولقطات شاشة، وإجراءات ملء النماذج. يمكن لوكيل التعلم المعزز أو التقييم أن يقوم بتشغيل نفس المهمة آلاف المرات، مما يجعل الثغرات الصغيرة في التدفق الخارجي أو الموارد أو التسجيل ذات أهمية على نطاق واسع.
استخدم قائمة التحقق أدناه لمراجعة الحدود قبل توصيل صندوق الحماية بالمستودعات الحساسة، أو بيانات العملاء، أو واجهات برمجة التطبيقات الداخلية، أو بيانات الاعتماد المميزة، أو أنظمة النشر الإنتاجية.
أمان حدود التنفيذ
ابدأ بالحدود التي تفصل عبء عمل الوكيل عن المضيف وعن المستأجرين الآخرين. يجب أن تكون المراجعة واضحة بما يكفي بحيث يمكن لمهندس الأمان وصف ما يحدث إذا قام الوكيل بتشغيل كود عدائي.
تحقق مما يلي:
- ما هي طبقة العزل المستخدمة: حاوية، microVM، VM كامل، وساطة استدعاء النظام مثل gVisor، وصندوق حماية Kubernetes، أو نموذج آخر؟
- هل يحصل كل صندوق حماية على حدوده النواة الخاصة، أم أنه يشارك نواة المضيف؟
- هل يتم فصل وحدة المعالجة المركزية والذاكرة ونظام الملفات وجدول العمليات ومكدس الشبكة والوصول إلى الأجهزة عن عبء العمل الأخرى؟
- هل يمكن لصندوق الحماية الوصول إلى مآخذ وقت تشغيل الحاوية، أو مساحات أسماء عمليات المضيف، أو مسارات المضيف، أو خدمات بيانات التعريف السحابية، أو الأجهزة المميزة؟
- كيف يتم وضع جلسات المتصفح وأسطح مكتب واجهة المستخدم الرسومية وتدفقات VNC ومفسري الكود داخل نفس الحدود؟
- ما هو افتراض الهروب من المضيف الموثق: الاحتواء، تقليل المخاطر، أو ضمان أقوى؟
تجنب قبول بيان عام “صندوق حماية آمن” كإجابة كاملة. اسأل عن آلية العزل الملموسة، وما هو داخل الحدود، وما هو خارجها، وما هي الافتراضات التي لا تزال بحاجة إلى ضوابط تعويضية.
أمان نظام الملفات والتركيب
تستحق أنظمة ملفات الوكلاء مراجعة منفصلة لأن الوكلاء غالبًا ما يقومون بإنشاء الملفات وتحريرها وإخراجها كجزء من العمل العادي. الجزء الخطير ليس فقط إمكانية القراءة/الكتابة؛ بل هو النقل العرضي بين المهام والوصول الضمني إلى ملفات المشروع التي لم يقصد المستخدم مشاركتها.
تحقق مما يلي:
- هل نظام الملفات الافتراضي فارغ، أو قائم على قالب، أو محمل مسبقًا بملفات المشروع؟
- ما هي المسارات التي يمكن للوكيل الكتابة فيها، وأيها للقراءة فقط؟
- هل يتم تركيب أدلة المضيف، أو تركيبات المستودع، أو مفاتيح SSH، أو ذاكرات التخزين المؤقت للحزم، أو ملفات تعريف المتصفح، أو ملفات تكوين السحابة في صندوق الحماية؟
- هل يمكن للوكيل اجتياز الروابط الرمزية أو تركيبات الربط إلى مسارات غير مقصودة؟
- هل يتم تحديد نطاق الوصول إلى الملفات لكل صندوق حماية، أو لكل مستخدم، أو لكل مشروع، أو لكل مؤسسة؟
- هل يتم حذف الملفات المرفوعة، أو الاحتفاظ بها، أو التقاط لقطة لها، أو جعلها متاحة للجلسات اللاحقة؟
- هل يمكن مراجعة الملفات المُنشأة واختلافاتها قبل أن تترك صندوق الحماية؟
بالنسبة لوكلاء البرمجة، النمط الأكثر أمانًا هو عادةً مساحة عمل مشروع ضيقة، وتصدير صريح للقطع الأثرية، وعدم وجود وصول محيطي إلى أدلة المنزل الخاصة بالمطور أو مخازن بيانات الاعتماد المشتركة.
التحكم في العمليات والموارد
يمكن للوكيل إنشاء fork bomb عن طريق الخطأ، أو تعليق عملية بناء، أو ملء قرص، أو تشغيل خادم في الخلفية، أو الاستمرار في إعادة محاولة أمر مكلف. تعمل ضوابط الموارد على تحويل هذه الإخفاقات إلى إخفاقات محدودة النطاق.
تحقق مما يلي:
- هل يتم فرض حدود على وحدة المعالجة المركزية والذاكرة والقرص وواصفات الملفات وعدد العمليات ووقت التشغيل؟
- هل يوجد حد أقصى للمدة الزمنية الفعلية للأوامر والجلسات؟
- هل يمكن للعمليات الخلفية البقاء على قيد الحياة بعد انتهاء الأمر؟
- هل يتم قتل العمليات الفرعية عند إيقاف صندوق الحماية أو إعادة تعيينه؟
- هل يمكن للوكيل فتح منافذ استماع، وإذا كان الأمر كذلك، هل يتم كشف هذه المنافذ فقط من خلال آلية معاينة صريحة؟
- هل يتم اقتطاع مخرجات stdout/stderr الكبيرة، أو بثها، أو تخزينها؟
- هل تكون حالات فشل الحصة مرئية للمتصل بدلاً من إعادة المحاولة بصمت؟
بالنسبة لسير عمل الوكيل الإنتاجي، يجب أن تكون الحدود جزءًا من عقد API، وليس مجرد مفهوم للفوترة. يجب أن يعرف فريق الأمان ما يحدث عندما يصل الوكيل إلى حد وما إذا كان الفشل يترك حالة جزئية وراءه.
ضوابط الشبكة والتدفق الخارجي
سياسة الشبكة هي المكان الذي تصبح فيه العديد من مراجعات صندوق الحماية غامضة للغاية. تحتاج بعض أعباء عمل الوكيل إلى الوصول إلى الإنترنت؛ والبعض الآخر لا ينبغي أن يكون لديه ذلك افتراضيًا. تعتمد الإجابة الصحيحة على ما إذا كان صندوق الحماية يقوم بتشغيل الاختبارات، أو تصفح الصفحات العامة، أو جلب الحزم، أو استدعاء واجهات برمجة التطبيقات الداخلية، أو معالجة البيانات الحساسة.
تحقق مما يلي:
- هل الوصول إلى الإنترنت الصادر مفعل افتراضيًا؟
- هل يمكن تعطيل الوصول إلى الشبكة لكل صندوق حماية، أو لكل قالب، أو لكل مشروع؟
- هل تتوفر قوائم السماح الصادرة للنطاقات ونطاقات عناوين IP والمنافذ والبروتوكولات؟
- هل تم حظر نقاط نهاية بيانات التعريف السحابية؟
- هل يمكن لصندوق الحماية الوصول إلى شبكات VPC الخاصة، أو الخدمات الداخلية، أو قواعد البيانات، أو أنظمة النشر؟
- هل يتم تنظيم حركة مرور المتصفح، وحركة مرور CLI، وحركة مرور مدير الحزم، واتصالات المقبس المباشرة بنفس السياسة؟
- هل يتم تسجيل الطلبات الصادرة مع الطابع الزمني والوجهة وسياق العملية أو الأمر وحالة الاستجابة؟
تعامل مع التدفق الخارجي للوكيل مثل التدفق الخارجي لنظام البناء. إذا كان بإمكان الوكيل تثبيت الحزم أو تحميل القطع الأثرية أو استدعاء webhooks أو تصفح المواقع العشوائية، يجب أن تغطي المراجعة كلاً من الكود الخبيث والسلوك الناتج عن حقن المطالبة.
مخاطر DNS والوصول إلى الحزم
يتم التغاضي عن DNS ومديري الحزم بسهولة لأنهم يشعرون وكأنهم بنية تحتية. بالنسبة للوكلاء، هم جزء من سطح التنفيذ. يمكن للسكريبت المُنشأ تشفير البيانات في استعلامات DNS، أو جلب حمة typosquatted، أو سحب سكريبت من عنوان URL لم يتم مراجعته مطلقًا.
تحقق مما يلي:
- هل تتبع حركة مرور DNS نفس سياسة التدفق الخارجي مثل HTTP وHTTPS؟
- هل يتم تسجيل استعلامات DNS أو تصفيتها أو إجبارها عبر أدوات حل خاضعة للتحكم؟
- هل يمكن لمديري الحزم الوصول إلى السجلات العامة افتراضيًا؟
- هل يتم السماح بسجلات الحزم أو بروكسيتها أو تخزينها مؤقتًا أو تثبيتها؟
- هل يتم التقاط أسماء الحزم المثبتة وإصداراتها وعناوين URL والتجزئات وتغييرات ملف القفل؟
- هل يمكن للوكيل تشغيل سكريبتات التثبيت أو خطافات ما بعد التثبيت أو خطوات بناء الحزم التعسفية؟
- هل هناك بوابة مراجعة قبل استمرار التبعيات الجديدة في قالب أو سير عمل إنتاجي؟
إذا كان الوصول إلى الحزم مطلوبًا، يفضل الإصدارات المثبتة وملفات القفل وقوائم السماح للسجلات والسجلات التي تسمح للمراجعين بإعادة بناء ما تم تنزيله وتنفيذه.
معالجة الأسرار
عادةً ما تكون الأسرار أسرع طريقة لجعل حدود صندوق الحماية غير ذات صلة. إذا رأى الوكيل رمزًا واسع النطاق، يمكنه تسريب البيانات دون الهروب من المضيف.
تحقق مما يلي:
- هل يتم حقن الأسرار فقط عندما تحتاجها المهمة صراحةً؟
- هل يتم تحديد نطاق الأسرار لصندوق الحماية، والمهمة، والمستودع، والبيئة، والعمر؟
- هل يمكن قراءة الأسرار من متغيرات البيئة، أو الملفات، أو تاريخ الشيل، أو قوائم العمليات، أو السجلات، أو لقطات الشاشة، أو تخزين المتصفح؟
- هل يتم تنقيح السجلات والقطع الأثرية قبل التخزين أو التصدير؟
- هل يتم استخدام الرموز قصيرة العمر بدلاً من بيانات الاعتماد طويلة الأجل؟
- هل يمكن للوكيل الوصول إلى مفاتيح SSH على مستوى المستخدم، أو بيانات اعتماد Git، أو بيانات اعتماد السحابة، أو ملفات تعريف ارتباط المتصفح، أو مفاتيح API من المضيف؟
- هل الوصول إلى الأسرار مرئي في سجلات التدقيق؟
قاعدة عملية: إذا كان الإنسان لن يلصق بيانات اعتماد في وظيفة بناء غير موثوقة، فلا تعطها لوكيل مستقل دون نطاق أضيق وتسجيل أقوى.
السجلات ومسارات التدقيق
تحتاج فرق الأمان إلى أكثر من مجرد نجاح أو فشل. إنهم بحاجة إلى معرفة أي كود تم تشغيله، وما هي الملفات التي تغيرت، وما هي استدعاءات الشبكة التي حدثت، وما هي المخرجات التي تم إنتاجها.
تحقق مما يلي:
- هل يتم تسجيل استدعاءات الأوامر مع الوسائط ودليل العمل ورمز الخروج ووقت البدء والمدة؟
- هل يتم تسجيل قراءات الملفات وكتابتها وحذفها ورفعها وتنزيلها وتغييرات الأذونات؟
- هل يتم تسجيل تثبيتات الحزم والجلب الخارجي؟
- هل يتم التقاط إجراءات المتصفح ولقطات الشاشة والتنزيلات وإرسالات النماذج حيثما كان ذلك مناسبًا؟
- هل يتم ربط استدعاءات API واستدعاءات الأدوات والانتقالات من النموذج إلى الأداة بنفس الجلسة؟
- هل السجلات مقاومة للتلاعب من داخل صندوق الحماية؟
- ما هي فترة الاحتفاظ، ومن يمكنه الوصول إلى السجلات؟
بالنسبة لسير العمل المنظم أو المؤسسي، يجب أن يدعم مسار التدقيق كلاً من التصحيح وإعادة البناء بعد الحادث. عادةً ما يكون نص الجلسة الطرفية الجزئي غير كافٍ.
التقاط القطع الأثرية ومراجعتها
ينتج الوكلاء مخرجات مفيدة: اختلافات، نتائج اختبارات، تقارير، لقطات شاشة، ملفات مُنشأة، عناوين URL للمعاينة، ومجموعات بيانات. يجب أن يجعل التعامل مع القطع الأثرية هذه المخرجات قابلة للمراجعة دون كشف حالة أكثر من اللازم.
تحقق مما يلي:
- ما هي القطع الأثرية التي يتم تصديرها تلقائيًا، وأيها تتطلب اختيارًا صريحًا؟
- هل يمكن للمراجعين فحص الملفات المُنشأة قبل أن يتم الالتزام بها أو تحميلها أو إرسالها إلى خدمة أخرى؟
- هل يتم فحص القطع الأثرية بحثًا عن الأسرار أو البرامج الضارة أو أنواع الملفات غير الآمنة أو الحجم غير المتوقع؟
- هل يتم تخزين تنزيلات المتصفح بشكل منفصل عن اختلافات كود المصدر ومخرجات الاختبار؟
- هل يمكن ربط القطع الأثرية بالأمر الدقيق وخطوة الوكيل وجلسة صندوق الحماية التي أنتجتها؟
- هل يتم الاحتفاظ بالقطع الأثرية بعد حذف صندوق الحماية، وهل يمكن تطهيرها؟
الهدف هو الحفاظ على الأدلة المفيدة مع تجنب قناة تسريب بيانات ثانية عبر السجلات أو لقطات الشاشة أو الأرشيفات أو الحزم المُنشأة.
ضوابط دورة الحياة وإعادة التعيين
يمكن أن تكون جلسات الوكيل قصيرة العمر أو طويلة الأمد أو متوقفة مؤقتًا أو مستأنفة أو ملتقطة كصورة أو مستنسخة من قوالب. كل وضع دورة حياة يغير الحدود.
تحقق مما يلي:
- هل يتم إنشاء كل صندوق حماية جديدًا، أو استئنافه من حالة، أو استنساخه من قالب؟
- ما هي البيانات التي تبقى على قيد الحياة بعد الإيقاف المؤقت والاستئناف واللقطة وإنشاء القالب والحذف؟
- هل يتم مسح الملفات المؤقتة وذاكرة التخزين المؤقت للحزم وتاريخ الشيل وملفات تعريف ارتباط المتصفح وقواعد البيانات المحلية عند إعادة التعيين؟
- هل يمكن لجلسة مخترقة تلويث قالب قابل لإعادة الاستخدام؟
- هل يوجد حد أقصى لعمر الجلسة؟
- هل يتم إنهاء صناديق الحماية المتوقفة حقًا، أم يمكن أن تستمر المهام الخلفية؟
- هل يمكن إعادة إنتاج نفس المهمة من بيئة نظيفة؟
تعد قابلية إعادة التعيين مهمة أيضًا لأعباء عمل التقييم والتعلم المعزز. إذا بدأت كل تجربة من حالة مختلفة قليلاً، يصبح من الصعب الثقة في نتائج الأمان وسلوك النموذج.
ضوابط الموافقة البشرية
الموافقة البشرية ليست مجرد ميزة تجربة مستخدم. إنها مستوى تحكم للإجراءات التي تعبر حدود الثقة.
تحقق مما يلي:
- ما هي الإجراءات التي يمكن تشغيلها بشكل مستقل، وأيها تتطلب موافقة؟
- هل مطالبات الموافقة محددة بما يكفي لإظهار الأمر والملفات والوجهة ونطاق بيانات الاعتماد والتأثير المتوقع؟
- هل يمكن للسياسات طلب الموافقة على تثبيت الحزم والوصول إلى الشبكة الخارجية وكتابات المستودع وأوامر النشر أو الوصول إلى الأسرار؟
- هل يتم تسجيل الموافقات مع المستخدم والطابع الزمني والإجراء والأمر الناتج؟
- هل يمكن أن تكون الموافقات محددة زمنيًا ومحددة بالمهمة بدلاً من منح إذن مستقبلي واسع؟
- هل يوجد مسار لكسر الزجاج، وهل يتم تدقيقه؟
استخدم الموافقة البشرية للإجراءات غير القابلة للإلغاء أو عالية التأثير: حذف الملفات، والكتابة إلى فروع الإنتاج، واستدعاء واجهات برمجة تطبيقات النشر، والوصول إلى بيانات العملاء، وتغيير قوالب صندوق الحماية.
افتراضات الاستجابة للحوادث
لا تكتمل أي مراجعة لصندوق الحماية دون السؤال عما يحدث عندما تفشل الحدود أو يتصرف سير العمل بشكل غير متوقع. هذا مهم بشكل خاص لأنظمة الوكلاء لأن الإجراء الخطير قد يكون ناتجًا عن مخرجات النموذج، أو حقن المطالبة، أو اختراق التبعيات، أو أخطاء برمجية عادية.
تحقق مما يلي:
- من يملك الفرز عندما يُشتبه في أن صندوق الحماية يسرب بيانات أو يشغل كودًا عدائيًا؟
- هل يمكن قتل صناديق الحماية أو عزلها أو حظرها حسب المشروع أو المؤسسة؟
- هل يمكن تعطيل التدفق الخارجي للشبكة بسرعة؟
- هل يتم الحفاظ على السجلات والقطع الأثرية للتحقيق؟
- هل يتم إبطال القوالب المتأثرة وذاكرات التخزين المؤقت للحزم واللقطات؟
- هل يتم تدوير بيانات الاعتماد تلقائيًا أو من خلال دفتر تشغيل موثق؟
- هل هناك تمييز واضح بين مشكلة احتواء صندوق الحماية ومشكلة سياسة الوكيل؟
يجب أن تنتهي المراجعة بنموذج تهديد مكتوب ودفتر تشغيل قصير. حتى لو كان القرار النهائي هو “معتمد لأعباء العمل غير الحساسة فقط”، فإن تلك الحدود مفيدة.
كيف يتناسب Novita Agent Sandbox
Novita Agent Sandbox مصمم للكود المُنشأ بواسطة الذكاء الاصطناعي، وسير عمل المتصفح، واستخدام الكمبيوتر، والتقييمات، وبيئات التعلم المعزز، والمهام طويلة الأمد. تصف صفحة المنتج صناديق حماية معزولة، وبدء تشغيل دون الثانية، وجلسات مستمرة، وعرض جلسة حية قائم على VNC، وتسعير قائم على الاستخدام، وقوالب، ودعم نظام ملفات معزول. يوضح دليل البدء السريع لـ Novita Agent Sandbox إنشاء صندوق حماية قائم على SDK، وتنفيذ الأوامر، وسرد الملفات، وإيقاف تشغيل صندوق الحماية.
يمكن لهذه القدرات دعم العديد من سير العمل في قائمة التحقق هذه، ولكن يجب أن تظل معايير التقييم وادعاءات المنتج منفصلة. عندما يراجع فريقك Novita Agent Sandbox، أو أي وقت تشغيل وكيل آخر، قم بتعيين التكوين المباشر الذي تخطط لاستخدامه مقابل الضوابط المذكورة أعلاه: الحدود، والملفات، وحدود العملية، والشبكة، وDNS، وجلب الحزم، والأسرار، والسجلات، والقطع الأثرية، ودورة الحياة، والموافقة، والاستجابة للحوادث.
بالنسبة لفرق الهندسة التي تستخدم بالفعل واجهات برمجة تطبيقات نموذج Novita AI، يمكن أن يؤدي إقران استنتاج النموذج مع تنفيذ صندوق الحماية إلى تقليل انتشار المنصة لأعباء عمل الوكيل. بالنسبة للاستخدام الإنتاجي الحساس أمنيًا، لا يزال يتعين إجراء مراجعة خاصة بعبء العمل قبل توصيل صندوق الحماية بالمستودعات الخاصة أو مجموعات البيانات الحساسة أو الخدمات الداخلية أو بيانات اعتماد النشر.
الخاتمة
لا توافق على صندوق حماية وكيل الذكاء الاصطناعي إلا بعد أن تتمكن المراجعة من الإجابة على ثلاثة أسئلة بوضوح: ما هو معزول، وما الذي لا يزال بإمكانه مغادرة الحدود، وما هي الأدلة المتبقية إذا حدث خطأ ما. إذا كانت هذه الإجابات غامضة، فاقتصر صندوق الحماية على أعباء العمل غير الحساسة حتى يتم توثيق واختبار الضوابط المفقودة.
الأسئلة الشائعة
ما الذي يجب أن يتحقق منه فريق الأمان أولاً في مراجعة صندوق حماية وكيل الذكاء الاصطناعي؟
ابدأ بحدود التنفيذ، وتعرض نظام الملفات، وإعدادات الشبكة الافتراضية. تحدد هذه الضوابط الثلاثة ما إذا كان الكود العدائي يمكنه الوصول إلى المضيف أو الملفات الحساسة أو الوجهات الخارجية قبل أن تصل حتى إلى التفاصيل الخاصة بسير العمل مثل الموافقات وتصدير القطع الأثرية.
هل صندوق الحماية القائم على الحاوية فقط كافٍ لوكلاء البرمجة المستقلين؟
يعتمد ذلك على عبء العمل والبيانات التي يمكنه الوصول إليها. قد تكون الحاوية مقبولة للمهام منخفضة الحساسية مع تركيبات ضيقة وسياسة تدفق خارجي صارمة وبيانات اعتماد قصيرة العمر وتسجيل قوي، ولكن يجب على فرق الأمان اتخاذ هذا القرار من الضوابط الموثقة بدلاً من كلمة “حاوية” وحدها.
لماذا يجب مراجعة DNS والوصول إلى الحزم بشكل منفصل عن التدفق الخارجي العام؟
لأن الوكلاء غالبًا ما يقومون بتثبيت التبعيات وحل المضيفين الخارجيين كجزء من التشغيل العادي. يمكن أن تصبح استعلامات DNS وجلبات الحزم مسارًا لتسريب البيانات ومخاطرة في سلسلة التوريد إذا لم يتم تسجيلها أو تصفيتها أو تقييدها.
مقالات موصى بها:
