التعليمات البرمجية الشفافة أمنياً، المستوى 2

تم تقديم المستوى 2 للشفافية‬ في .NET Framework الإصدار 4. يعتمد هذا النموذج على ثلاثة مبادئ و هي التعليمات البرمجية الشفافة، التعليمات البرمجية الحرجة من ناحية السلامة الأمنية، و التعليمات البرمجية الحرجة أمنياً.

• يمكن للتعليمات البرمجية الشفافة، بما في ذلك تلك قيد التشغيل في وضع الثقة الكاملة، طلب استدعاء تعليمات برمجية شفافة أو تعليمات برمجية تطبق السلامة الأمنية فقط. يمكنها فقط تنفيذ الإجراءات المسموح بها من قبل مجموعة أذونات الثقة جزئية للمجال (في حالة وجود واحدة). لا يمكن للتعليمات البرمجية القيام بما يلي:

  • إجراء Assert أو رفع الامتيازات.

  • أن تحتوي على تعليمات برمجية غير آمنة أو لا يمكن التحقق منها.

  • طلب استدعاء تعليمات برمجية حرجة.

  • طلب استدعاء تعليمات برمجية أصلية أو تعليمات برمجية تحمل السمة SuppressUnmanagedCodeSecurityAttribute.

  • طلب استدعاء عضو محمي بواسطة LinkDemand.

  • الوراثة من الأنواع الهامة.

  بالإضافة إلى ذلك، لا يمكن للأساليب الشفافة تجاوز الأساليب الظاهرية الحرجة أو تطبيق أساليب الواجهة الهامة الحرجة.

• يوثق في التعليمات البرمجية الحرجة من ناحية السلامة ثقة كاملة ولكن يمكن طلب استدعائها بواسطة تعليمات برمجية شفافة. تقوم بالكشف عن منطقة سطحية محدودة من التعليمات البرمجية الموثوق بها ثقة كاملة; تحدث عمليات التحقق من الصحة و الأمان في التعليمات البرمجية حرجة من ناحية السلامة.

• يمكن للتعليمات البرمجية الحرجة أمنياً طلب استدعاء أي تعليمات برمجية ويكون موثوقاً بها ثقة كاملة، إلا أنه لا يمكن استدعاؤها بواسطة تعليمات برمجية شفافة.

يشمل هذا الموضوع على الأقسام التالية.

• أمثلة للاستخدام و السلوكيات

• أنماط التجاوز

• قواعد الوراثة

• معلومات وقواعد إضافية

أمثلة للاستخدام و السلوكيات

لتحديد قواعد .NET Framework 4 (شفافية من المستوى 2)، قم باستخدام التعليق التوضيحي التالي للتجميع:

[assembly: SecurityRules(SecurityRuleSet.Level2)]

لإستخدام قواعد .NET Framework 2.0 (شفافية من المستوى 1)، استخدم التعليق التوضيحي التالي:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

إذا لم تقم بالتعليق التوضيحي لتجميع ما، يتم استخدام قواعد .NET Framework 4 بشكل افتراضي. ومع ذلك، أفضل ممارسة يوصى بها هي استخدام السمة SecurityRulesAttribute بدلاً من الاعتماد على الوضع الافتراضي.

التعليق التوضيحي على مستوى التجميع

يتم تطبيق القواعد التالية لاستخدام السمات في مستوى التجميع:

• لا سمات: إذا لم تقم بتحديد أية سمات، تقوم بيئة وقت التشغيل بتفسير كل التعليمات البرمجية على أنها حرجة أمنياً، فيما عدا إن كان مبدأ الأمان الحرج قد يخالف قاعدة وراثة (على سبيل المثال، عند تجاوز أو تطبيق أسلوب شفاف ظاهري أو أسلوب واجهة). في هذه الحالات تعد الأساليب حرجة من ناحية السلامة. يؤدي عدم تحديد سمة لجعل بيئة وقت تشغيل اللغة العامة تحدد قواعد الشفافية لك.

• SecurityTransparent: كل التعليمات البرمجية شفافة; لن يقوم التجميع بأكمله بفعل أي شئ يحتاج امتيازات أو يكون غير آمن.

• SecurityCritical: كافة التعليمات البرمجية التي يتم تقديمها بواسطة أنواع في هذا التجميع تعد حرجة; و كافة التعليمات البرمجية الأخرى تكون شفافة. يشبه هذا السيناريو عدم تحديد أية سمات; ومع ذلك، لا تقوم بيئة وقت تشغيل اللغة العامة تلقائياً بتحديد قواعد الشفافية. على سبيل المثال، إذا قمت بتجاوز أسلوب ظاهري أو مُجرّد أو قمت بتطبيق أسلوب واجهة، فسيكون هذا الأسلوب شفافاً بشكل افتراضي. يجب عليك بشكل صريح عمل تعليق توضيحي للأسلوب على أنه SecurityCritical أو SecuritySafeCritical; وإلا سيتم طرح TypeLoadException، عند وقت التحميل. تطبق هذه القاعدة أيضاً عندما يكون كلاً من الفئة الأساسية والفئة المشتقة في نفس التجميع.

• AllowPartiallyTrustedCallers (مستوى 2 فقط): ‏‫يتم عادةً تعيين‬ كافة التعليمات البرمجية افتراضيًا على أنها شفافة. ومع ذلك، فإنه يمكن أن يكون للأنواع و الأعضاء الفردية سمات أخرى.

يقارن الجدول التالي سلوك مستوى التجميع للمستوى 2 مع المستوى 1.

سمة التجميع	Level 2	Level 1
عدم وجود سمة على تجميع موثوق به جزئيًا	تكون الأنواع والأعضاء بشكل افتراضي شفافة ولكن يمكن أن تكون حرجة أمنياُ أو حرجة من ناحية السلامة الأمنية .	كافة الأنواع و الأعضاء شفافة.
لا سمة:	يؤدي عدم تحديد سمة لجعل بيئة وقت تشغيل اللغة العامة تحدد قواعد الشفافية لك. كافة الأنواع والأعضاء حرجة أمنياُ، فيما عدا إن كان ذلك يؤدي إلى مخالفة قاعدة وراثة.	في التجميع الموثوق به ثقة كاملة (في مخزن التجميع العمومي المؤقت أو تم تعريفه على أن له ثقة كاملة في AppDomain) تكون كافة الأنواع شفافة و كافة الأعضاء حرجة أمنياً.
SecurityTransparent	كافة الأنواع و الأعضاء شفافة.	كافة الأنواع و الأعضاء شفافة.
SecurityCritical(SecurityCriticalScope.Everything)	غير متوفر.	كافة الأنواع والأعضاء حرجة أمنياً.
SecurityCritical	كافة التعليمات البرمجية التي يتم تقديمها بواسطة أنواع في هذا التجميع تعد حرجة; و كافة التعليمات البرمجية الأخرى تكون شفافة. إذا قمت بتجاوز أسلوب ظاهري أو مُجرّد أو قمت بتطبيق أسلوب واجهة، يجب أن تقوم بشكل صريح بالتعليق التوضيحي للأسلوب على أنه SecurityCritical أو SecuritySafeCritical.	‏‫يتم عادةً تعيين‬ كافة التعليمات البرمجية افتراضيًا على أنها شفافة. ومع ذلك، فإنه يمكن أن يكون للأنواع و الأعضاء الفردية سمات أخرى.

التعليق التوضيحي للأنواع والأعضاء

سمات الأمان التي يتم تطبيقها لنوع ما، تُطبق أيضاً على الأعضاء التي يتم تقديمها بواسطة النوع. ومع ذلك، لا يتم تطبيقها على التجاوزات الظاهرية أوالمُجرّدة من الفئة الأساسية أو تطبيقات الواجهة. يتم تطبيق القواعد التالية لاستخدام السمات على مستوى العضو والنوع:

• SecurityCritical: يعد العضو و النوع حرجين و يمكن طلب الاستدعاء فقط بواسطة تعليمات برمجية لها الثقة الكاملة. الأساليب المُقدمة في نوع ما حرج أمنياُ تعتبر حرجة أمنية هي أيضاً.

  هام
  الأساليب الظاهرية و المجردة التي يتم تقديمها في فئات أساسية أو واجهات و يتم تجاوزها أو تطبيقها في فئة حرجة أمنية تعتبر شفافة بشكل افتراضي.يجب تعريفها لتكون إما SecuritySafeCritical أو SecurityCritical.

• SecuritySafeCritical: يعد النوع أو العضو حرج من ناحية السلامة. ومع ذلك، يمكن أن يتم استدعاء النوع أو العضو من تعليمات برمجية شفافة (موثوق بها جزئياً) وتكون قادرة على فعل أي مما تفعله التعليمات البرمجية الحرجة الأخرى. يجب أن يتم عمل تدقيق أمني للتعليمات البرمجية.

العودة إلى الأعلى

أنماط التجاوز

يعرض الجدول التالي تجاوزات الأسلوب المسموح بها في الشفافية من المستوى 2.

عضو أساسي ظاهري/عضو أساسي لواجهة	تجاوز/واجهة
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

العودة إلى الأعلى

قواعد الوراثة

في هذا المقطع، يتم تعيين الترتيب التالي للتعليمات البرمجية Transparent ، Critical ، و SafeCritical و المستندة إلى الوصول والقدرات:

Transparent < SafeCritical < Critical

• القواعد الخاصة بالأنواع: بالانتقال من اليسار إلى اليمين، يصبح الوصول أكثر تقييداً. يجب أن يكون للأنواع المشتقة على الأقل نفس التقييد كما النوع الأساسي.

• القواعد الخاصة بالأساليب: لا يمكن للأساليب المشتقة تغيير إمكانية الوصول من الأسلوب الأساسي. للحصول على السلوك الافتراضي، تعد كافة الطرق المشتقة التي لم يتم عمل تعليق توضيحي لها Transparent. تؤدي مشتقات الأنواع الحرجة إلى طرح استثناء إذا لم يتم عمل تعليق توضيحي بشكل صريح على أنها SecurityCritical.

يعرض الجدول التالي أنماط وراثة النوع المسموح بها.

الفئة الأساسية	يمكن أن تكون الفئة المشتقة
Transparent	Transparent
Transparent	SafeCritical
Transparent	Critical
SafeCritical	SafeCritical
SafeCritical	Critical
Critical	Critical

يعرض الجدول التالي أنماط وراثة النوع الغير مسموح بها.

الفئة الأساسية	لا يمكن أن تكون الفئة المشتقة
SafeCritical	Transparent
Critical	Transparent
Critical	SafeCritical

يعرض الجدول التالي أنماط وراثة الأسلوب المسموح بها.

أسلوب أساسي	يمكن أن يكون الأسلوب المشتق
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

يعرض الجدول التالي أنماط وراثة الأسلوب الغير مسموح بها.

أسلوب أساسي	لا يمكن أن يكون الأسلوب المشتق
Transparent	Critical
SafeCritical	Critical
Critical	Transparent
Critical	SafeCritical

ملاحظة
يتم تطبيق قواعد الوراثة تلك إلى الأنواع والأعضاء من المستوى 2.يمكن أن ترث الأنواع في تجميعات المستوى 1 من الأنواع والأعضاء الحرجة أمنياُ من المستوى 2.ولذلك، يجب أن يكون لدى الأنواع و الأعضاء من المستوى 2 مُطالبات وراثة منفصلة عن الوارثين من المستوى 1.

العودة إلى الأعلى

معلومات وقواعد إضافية

دعم LinkDemand

يستبدل نموذج الشفافية للمستوى 2 LinkDemand بالسمة SecurityCriticalAttribute. في التعليمات البرمجية القديمة (المستوى 1) يتم تلقائياً التعامل مع LinkDemand معاملة Demand.

انعكاس

استدعاء أسلوب حرج أو قراءة حقل حرج يقوم بتنشيط طلب للثقة الكاملة (كما لو قمت باستدعاء أسلوب أو حقل خاص). و لذلك، يمكن للتعليمات البرمجية التي لها الثقة الكاملة استدعاء أسلوب حرج، بينما لا يمكن للتعليمات البرمجية التي لها الثقة الجزئية فعل ذلك.

تمت إضافة الخصائص التالية لمساحة الاسم System.Reflection لتحديد ما إذا كان يعد النوع أو الأسلوب أو الحقل SecurityCritical ، SecuritySafeCritical، أو SecurityTransparent: IsSecurityCritical ، IsSecuritySafeCritical و IsSecurityTransparent استخدم هذه الخصائص لتحديد الشفافية باستخدام الانعكاس بدلاً من التحقق من وجود السمة. قواعد الشفافية معقدة، و التحقق من السمة قد لا يكون كافيًا.

ملاحظة
على SafeCriticalالأسلوب بإرجاع trueلكل منهما IsSecurityCriticalو IsSecuritySafeCritical، لأن SafeCriticalهو حقا حرج (وليس له نفس القدرات كرمز حرج، ولكن يمكن استدعاؤه من تعليمات برمجية واضحة).

ترث الأساليب الحيوية الشفافية من الوحدات التي يتم إرفاقهم بها; فإنها لا ترث الشفافية من النوع (إذا كانت متصلة بنوع ما).

تخطي التحقق في الثقة الكاملة

يمكنك تخطي التحقق للتجميعات الشفافة الموثوق بها ثقة كاملة بواسطة تعيين الخاصية SkipVerificationInFullTrust على true في السمة SecurityRulesAttribute:

[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]

يتم تعيين الخاصية SkipVerificationInFullTrust بشكل إفتراضي على false، لذا يجب تعيين الخاصية على true لتخطي التحقق. يجب أن يتم ذلك بغرض تحسين الأداء فقط. يجب عليك التأكد من أنه يمكن التحقق من التعليمات البرمجية الشفافة في التجميع باستخدام الخيار transparent في الأداة PEVerify.

العودة إلى الأعلى

راجع أيضًا:

المبادئ

التعليمات البرمجية الشفافة أمنياً، المستوى 1

تغييرات الأمان في .NET Framework 4