17 يونيو 2025·7 دقيقة
ثيو دي رادت، OpenBSD، وعقلية الآمن افتراضيًا
كيف شكل ثيو دي رادت وOpenBSD فكرية "الآمن افتراضيًا" عبر التدقيق، التصميم المحافظ، والتخفيفات العملية التي تُستخدم في الأنظمة الحديثة.
كيف شكل ثيو دي رادت وOpenBSD فكرية "الآمن افتراضيًا" عبر التدقيق، التصميم المحافظ، والتخفيفات العملية التي تُستخدم في الأنظمة الحديثة.
"الآمن افتراضيًا" يعني أن النظام يبدأ في حالته الأكثر أمانًا المعقولة دون أن تضطر للبحث في القوائم، أو قراءة قائمة طويلة من التعليمات، أو أن تكون بالفعل على دراية بما يمكن أن يسوء. يجب أن يقلل التثبيت الأولي من الخدمات المكشوفة، ويحدّ من الأذونات، ويختار الخيارات الأكثر أمانًا تلقائيًا. لا يزال بإمكانك فتح الأمور—لكن تفعل ذلك عن قصد وبعيون مفتوحة.
الإعداد الافتراضي هو المسار الذي سيتخذه معظم الناس. هذا يجعله إجراءً أمنيًا: فهو يشكل نتائج العالم الحقيقي أكثر من أي دليل تقوية اختياري. إذا كانت الإعدادات الافتراضية تُفعّل خدمات شبكة إضافية بصمت، أو وصول ملفات متساهل، أو ميزات محفوفة بالمخاطر، فسترث العديد من النشريات ذلك الخطر لفترة طويلة.
OpenBSD يُستشهد به كثيرًا في مناقشات الأمن لأنه اعتنى بهذه الفكرة كهدف هندسي أساسي لعقود: شحن إعدادات محافظة، تقليل سطح الهجوم، وجعل السلوكيات الخطرة اختيارًا يُطلب تمكينه. هذا التركيز أثر في طريقة تفكير كثير من المهندسين حول أنظمة التشغيل، وخدمات الشبكة، وتصميم التطبيقات.
سننظر في الممارسات التي دعمت عقلية "الآمن افتراضيًا"، بما في ذلك:
دور ثيو دي رادت مهم تاريخيًا، لكن الهدف هنا ليس عبادة للأبطال. الخلاصة الأكثر فائدة هي كيف يمكن لمشروع أن يحوّل الأمن من فكرة لاحقة إلى مجموعة من القرارات القابلة للتكرار—قرارات تظهر في الإعدادات الافتراضية، وعادات مراجعة الكود، والاستعداد لقول "لا" للراحة عندما تخلق مخاطرة غير ضرورية.
ثيو دي رادت مطور كندي عُرف بتركيزه طويل الأمد على هندسة أنظمة دقيقة في عائلة BSD. قبل OpenBSD، كان شخصية مركزية في جهود تشغيل BSD على الحاسوب الشخصي وكان من مؤسسي NetBSD في أوائل التسعينات. ذلك الخلفية مهمة: BSDs لم تكن "تطبيقات" فحسب، بل أنظمة تشغيل قُصد بها أن تكون قواعد موثوقة.
بدأ OpenBSD في 1995 بعد أن غادر دي رادت مشروع NetBSD. لم يؤسس المشروع الجديد لملاحقة الجديد أو لبناء "BSD بكل شيء". بُني لأجل نظام تكون فيه الصحة الأمنية والصوابية أولويات صريحة، حتى لو تطلب ذلك قول "لا" للراحة.
من البداية، وضع OpenBSD جهدًا في أمور كثير من المشاريع تعتبرها غير جذابة:
تتنافس أنظمة التشغيل والتوزيعات على الاتساع: مزيد من برامج التشغيل، مزيد من الخدمات المدمجة، مزيد من خيارات التهيئة، وتسليم ميزات أسرع. هذه أهداف مشروعة وتفيد المستخدمين.
قصة أصل OpenBSD تعكس رهانًا مختلفًا: أن نظامًا أساسيًا أصغر وأسهل للفهم—مصحوبًا بإعدادات افتراضية محافظة—يمكن أن يقلل احتمال الأخطاء الحرجة أمنيًا.
هذا لا يجعل النهج الآخر "خاطئًا" بالضرورة. لكنه يعني أن المساومات تظهر في القرارات اليومية: هل نفعّل خدمة افتراضيًا؟ هل نقبل نظامًا فرعيًا معقّدًا؟ هل نعيد تصميم واجهة لتصبح أصعب في سوء الاستخدام؟
تركيز تأسيس OpenBSD كان هدفًا أمنيًا: عامل الأمن كقيد تصميم، لا كمُلحق. لكن الأهداف ليست هي نفسها النتائج. الأمن الحقيقي يُقاس عبر سنوات—من خلال الثغرات المكتشفة، وسرعة إصلاحها، ووضوح التواصل، ومدى تعلم المشروع من أخطائه.
نشأت ثقافة OpenBSD من هذا الفرض: افترض أن البرمجيات قد تفشل، ثم هندس الإعدادات والعمليات لتقلل احتمال الفشل.
يتعامل OpenBSD مع "التثبيت الافتراضي" كوع обещ أمني: يجب أن يكون النظام الطازج آمنًا بشكل معقول قبل أن تقرأ دليل ضبط، أو تضيف قاعدة جدار ناري، أو تبحث في ملفات الإعدادات الغامضة. هذا ليس راحة—إنه إجراء أمني.
إذا بقيت معظم الآلات قريبة من إعداداتها الافتراضية (كما هو الحال في الواقع)، فالإعدادات الافتراضية هي المكان الذي يُمنع فيه الخطر أو يتكاثر بصمت.
نهج "الآمن افتراضيًا" يفترض أن المسؤولين الجدد سيرتكبون أخطاء، سيكونون مشغولين، أو يتبعون نصائح قديمة. لذا يهدف النظام إلى البدء من خط دفاعي قابل للمرافعة: تعرض أدنى، سلوك متوقع، وإعدادات لا تفاجئك.
عندما تغيّر شيئًا، يجب أن تفعله عن قصد—لأنك تحتاج الخدمة—وليس لأن النظام الأساسي "مما يسر" وتمكينها.
تجسد هذه العقلية عمليًا اختيار ميزات محافظ وانحياز نحو خدمات شبكية أقل مفعّلة افتراضيًا. كل دايمون يستمع هو مكان جديد للأخطاء، وسوء التهيئة، وبيانات اعتماد منسية.
تهدف إعدادات OpenBSD الافتراضية إلى للحفاظ على سطح الهجوم الابتدائي صغيرًا، لذا يأتي الفوز الأمني الأول من عدم تشغيل أشياء لم تطلبها.
تقلل هذه المحافظة أيضًا عدد "بُنادق القدم"—الميزات القوية السهلة في سوء الاستخدام عندما تتعلم.
الإعدادات الافتراضية تساعد فقط إذا كان الناس يستطيعون فهمها وصيانتها. تؤكد ثقافة OpenBSD على وثائق واضحة وملفات إعداد مباشرة حتى يستطيع المسؤولون الإجابة عن أسئلة أساسية بسرعة:
تلك الوضوح مهم لأن إخفاقات الأمان غالبًا ما تكون تشغيلية: خدمة تُركت مفعّلة عن غير قصد، إعداد منسوخ بخيارات غير آمنة، أو افتراض أن "شخصًا آخر قد قوّى ذلك بالفعل".
يحاول OpenBSD جعل المسار الآمن هو السهل والواضح—بدءًا من أول إقلاع.
سمعة OpenBSD الأمنية ليست فقط عن تخفيفات ذكية أو إعدادات صارمة—بل هي عادة: افترض أن الأمن يتحسّن عندما يقرأ الناس الكود ويعيدونه بشكل متكرر ومتعمد.
"اقرأ الكود" أقل شعارًا وأكثر سير عمل: راجع ما تشحنه، استمر في مراجعته، واعتبر الغموض خطأ.
المراجعة المنهجية ليست فقط مسحًا للأخطاء الواضحة. عادة تشمل:
فكرة أساسية أن التدقيق غالبًا ما يهدف إلى منع فئات كاملة من الأخطاء، لا مجرد إصلاح مشكلة أُبلغت عنها.
تركز التدقيقات على المكونات التي تحلل مدخلات غير موثوقة أو تتعامل مع عمليات عالية الخطورة. الأهداف الشائعة تشمل:
هذه المناطق تجمع تعقيدًا مع تعرض—تمامًا حيث تنشط الثغرات الدقيقة.
مراجعة الكود المستمرة تتطلب وقتًا وخبرة مركزة. قد تُبطئ عمل الميزات، وليست ضمانًا: المراجعون يخطئون، والكود الجديد يمكن أن يعيد تقديم مشاكل قديمة.
دروس OpenBSD عملية أكثر منها سحرية: التدقيق المنضبط يقلل المخاطر بشكل ملموس عندما يُعامل كعمل هندسي مستمر، لا كمرور أمني لمرة واحدة.
الأمن ليس فقط عن إضافة حماية بعد حدوث خلل. دفع OpenBSD غريزة مختلفة: ابدأ بافتراض أن البرمجيات ستحوي أخطاء، ثم صمّم النظام بحيث تكون قدرة تلك الأخطاء محدودة.
"أقل الصلاحيات" يعني أن برنامجًا أو مستخدمًا يجب أن يمتلك فقط الأذونات التي يحتاجها لأداء مهمته—ولا شيء أكثر. إذا كان خادم ويب يحتاج فقط لقراءة ملف إعداده وخدمة ملفات من دليل واحد، فلا ينبغي أن يملك صلاحية قراءة مجلدات المستخدمين، أو تغيير إعدادات النظام، أو الوصول إلى الأجهزة الخام.
هذا مهم لأن الضرر عند حدوث استغلال يُحد بقدرة المكوّن المخترق.
البرامج المواجهة للشبكة تتعرض لمدخلات غير موثوقة طوال الوقت: طلبات ويب، محاولات دخول SSH، حزم مشوّهة.
يقسم فصل الصلاحيات البرنامج إلى أجزاء أصغر:
حتى لو وجد مهاجم ثغرة في الجزء المواجه للإنترنت، فلن يحصل بالضرورة على تحكم كامل بالنظام. سيهبط في عملية ذات حقوق قليلة وطرق أقل للتصعيد.
عزّز OpenBSD هذا التقسيم بأدوات عزل إضافية (مثل chroot والسياجات على مستوى نظام التشغيل). فكر فيها كتشغيل مكوّن معرض للخطر في غرفة مقفلة: يمكنه أداء مهمته الضيقة، لكنه لا يستطيع التجوال في المنزل.
قبل: دايمون كبير واحد يعمل بصلاحيات واسعة → اختراق جزء واحد، تُخترق كامل النظام.
بعد: مكوّنات صغيرة مفصولة بصلاحيات دنيا → اختراق جزء واحد يمنح موطئ قدم محدود ويقابل الحواجز في كل خطوة.
لسنوات، بدأت نسبة كبيرة من الاختراقات الحقيقية بفئة بسيطة من العيوب: أخطاء سلامة الذاكرة. تجاوزات السعة، الاستخدام بعد التحرير، وأخطاء مماثلة يمكن أن تتيح للمهاجم الكتابة فوق بيانات التحكم وتشغيل شيفرة عشوائية.
عامل OpenBSD تلك الحقيقة كمشكلة هندسية عملية: افترض أن بعض الأخطاء ستتسلل، ثم صمّم النظام بحيث يكون استغلالها أصعب، أكثر ضوضاءً، وأقل موثوقية.
ساعد OpenBSD على تطبيع تخفيفات أصبحت الآن مألوفة لكثير من الناس:
هذه الآليات ليست "دروعًا سحرية". هي مطبات تبطئ الهجوم—غالبًا فعّالة—تجبر المهاجمين على سلسلة خطوات إضافية، تتطلب تسريبات معلومات أفضل، أو تقبل موثوقية أقل.
الدرس الأعمق هو الدفاع متعدد الطبقات: التخفيفات تكسب وقتًا، تقلل دائرة الانفجار، وتحول بعض الثغرات إلى تحطمات بدلًا من استيلاءات. هذا مهم تشغيليًا لأنه يمكن أن يقصّر النافذة بين الاكتشاف والتصحيح، ويمكنه منع خطأ واحد من أن يتحول إلى حادث نظام كامل.
لكن التخفيفات ليست بديلاً عن إصلاح الثغرات. فلسفة OpenBSD جمعت مقاومة الاستغلال مع تصحيح مستمر ومراجعة: اجعل الاستغلال أصعب اليوم، واستمر في إزالة الأخطاء الأساسية غدًا.
سمعة OpenBSD الأمنية ليست مبنية على "المزيد من التشفير في كل مكان". بل مبنية على الصحة أولًا: واجهات أقل مفاجأة، واجهات برمجة واضحة، وسلوك يمكنك التعقل فيه تحت الضغط.
هذا التفكير يؤثر في كيفية دمج التشفير، كيف تُولّد العشوائية، وكيف تُصمم الواجهات بحيث تصبح الخيارات غير الآمنة أصعب ارتكابًا عن طريق الخطأ.
سمة متكررة في OpenBSD هي أن إخفاقات الأمان غالبًا ما تبدأ كأخطاء عادية: حالات حافة التحليل، أعلام غامضة، اقتطاع صامت، أو إعدادات مساعدة تُخفي الأخطاء.
يميل المشروع إلى تفضيل واجهات أصغر قابلة للتدقيق مع أوضاع فشل صريحة، حتى لو تطلب ذلك إزالة أو إعادة تصميم سلوك طويل الأمد.
واجهات واضحة تقلل أيضًا "بُنادق القدم" في التهيئة. إذا كان الخيار الآمن يتطلب متاهة من المفاتيح، فستنتهي كثير من النشرات غير آمنة رغم النوايا الحسنة.
نهج OpenBSD في التشفير محافظ: استخدم بديهيات مفهومة جيدًا، ادمجها بعناية، وتجنّب تمكين السلوكيات القديمة التي تبقى فقط لأجل التوافق الرجعي.
يظهر هذا في الإعدادات الافتراضية التي تفضّل خوارزميات قوية والاستعداد لإهلاك الخيارات الأضعف بدلًا من الاحتفاظ بها "في حالة الحاجة".
الهدف ليس تقديم كل مجموعة مفاتيح ممكنة—بل جعل المسار الآمن هو المسار العادي.
كثير من الأعطاب الواقعية تعود إلى عشوائية ضعيفة، تحليل غير آمن، أو تعقيد مخفي في طبقات التهيئة.
العشوائية الضعيفة يمكن أن تقوّض التشفير القوي، لذا تعامل الأنظمة الآمنة افتراضيًا مع البنية التحتية للغرفة العشوائية وواجهات العشوائية كأمر حاسم.
التحليل غير الآمن (المفاتيح، الشهادات، ملفات الإعداد، أو مدخلات الشبكة) هو متكرر آخر؛ الصيغ المتوقعة، والتحقق الصارم، والتعامل الآمن للسلاسل تقلل سطح الهجوم.
وأخيرًا، التعقيد الخفي في التهيئة هو خطر بحد ذاته: عندما يعتمد الأمان على قواعد ترتيب دقيقة أو تداخلات غير موثقة، تصبح الأخطاء حتمية.
يفضل OpenBSD تبسيط الواجهة واختيار إعدادات افتراضية لا ترث سلوكًا غير آمن قديمًا بصمت.
OpenSSH هو أحد أوضح الأمثلة على كيف هربت فلسفة أمان OpenBSD من حدود المشروع وأصبحت توقعًا افتراضيًا في أماكن أخرى.
عندما أصبح SSH الطريقة المعيارية لإدارة الأنظمة عن بعد، لم يكن السؤال "هل نشفر الدخول البعيد؟"—بل "أي تنفيذ نثق بتشغيله في كل مكان؟"
ظهر OpenSSH عندما واجه تنفيذ SSH الحر الأصلي (SSH 1.x) تغييرات في الترخيص واحتاجت البيئة لبديل متاح بشكل متساهل ويحظى بصيانة نشطة.
لم يقدم OpenBSD مجرد بديل؛ بل قدم إصدارًا تشكل بثقافته: تغييرات محافظة، وضوح في الكود، وانحياز نحو السلوك الآمن دون إجبار كل مسؤول على أن يكون خبيرًا.
هذا كان مهمًا على نطاق واسع لأن SSH يجلس على المسار الأكثر حساسية في كثير من البيئات: الوصول المتميز، الأتمتة على مستوى الأساطيل، والاسترداد.
عامل OpenBSD إدارة الوصول البعيد كمسار عالي المخاطر.
تهدِف إعدادات OpenSSH وميزاته المدعومة إلى دفع المسؤولين نحو أنماط أفضل: تشفير قوي، خيارات مصادقة معقولة، وسياجات تقلل التعرض العرضي.
هذا ما يبدو عليه "الآمن افتراضيًا" عمليًا: تقليل عدد بُنادق القدم المتاحة للمشغِّل تحت الضغط. عندما تدخل على خادم إنتاج في الثانية الثانية بعد منتصف الليل، تهم الإعدادات الافتراضية أكثر من مستندات السياسات.
صُمم OpenSSH ليكون قابلًا للسفر. منافذ إلى لينكس، BSDs، macOS، وأنظمة يونكس التجارية تعني أن قرارات OpenBSD الأمنية—APIs، اصطلاحات التهيئة، ومواقف التقوية—تنقلت مع الشيفرة.
حتى المؤسسات التي لم تشغّل OpenBSD مباشرة تبنّت افتراضات وصوله البعيد لأن OpenSSH أصبح القاسم المشترك.
التأثير الأكبر لم يكن نظريًا: ظهر في أنماط وصول المسؤول اليومي. اعتمدت الفرق على الإدارة البعيدة المشفرة، حسّنت سير عمل المفاتيح، وحصلت على أداة محكمة المراجعة يمكن نشرها في كل مكان تقريبًا.
مع الزمن، رفع هذا مستوى الأساس لما يبدو "طبيعيًا" لإدارة آمنة وجعل الوصول غير الآمن صعبًا في التبرير.
"الآمن افتراضيًا" ليس مجرد هدف تصميم—إنه وعد تُفي به في كل مرة تشحن فيها نسخة.
تعتمد سمعة OpenBSD كثيرًا على هندسة إصدارات منضبطة: إصدارات متوقعة، تغييرات محسوبة، وانحياز نحو الوضوح بدل البراعة.
يمكن أن تكون الإعدادات الافتراضية آمنة في اليوم الأول، لكن المستخدمين يختبرون الأمان عبر أشهر وسنوات من خلال التحديثات، والإشعارات، ومدى ثقتهم في تطبيق التصحيحات.
تنمو الثقة عندما تكون التحديثات منتظمة والتواصل ملموسًا. إشعار أمني جيد يجيب عن أربعة أسئلة بدون دراما: ما المتأثر؟ ما التأثير؟ كيف أصلح؟ كيف أتحقق؟
يميل أسلوب التواصل على طريقة OpenBSD إلى تجنّب الكلام المبهم حول الشدة والتركيز على التفاصيل القابلة للتنفيذ—نطاق الإصدارات، مراجع الرقع، وحلول مؤقتة قليلة العمل.
قواعد الإفصاح المسؤولة مهمة هنا أيضًا. التنسيق مع المُبلّغين، وضع جداول زمنية واضحة، ومنح الائتمان للباحثين يساعد في إبقاء الإصلاحات منظمة دون تحويل كل مسألة إلى واجهة إعلامية.
هندسة الإصدارات هي أيضًا إدارة مخاطر. كلما زادت تعقيدات سلسلة البناء والإصدار، زادت فرص التوقيع الخاطئ، أو القطع الخاطئة، أو تبعية مخترقة.
أنبوب بناء وإصدار أبسط—بناءات متكررة، أجزاء قليلة متحركة، ممارسات توقيع قوية، ومصدرية واضحة—يقلل فرص شحن الشيء الخاطئ.
تجنّب الرسائل المبنية على الخوف. استخدم لغة بسيطة، عرّف ماذا يعني "بعيد" و"محلي" و"تصعيد صلاحيات"، وكن صريحًا بشأن عدم اليقين. عندما تضطر للمضاربة، وسم ذلك.
قدّم مسارًا هادئًا "افعل هذا الآن" (التحديث أو التصحيح) ومسارًا "افعل هذا لاحقًا" (مراجعة التهيئة، المراقبة). عندما تكون العمليات والتصحيح والتواصل متسقة، يتعلم المستخدمون التحديث بسرعة—وهناك يصبح "الآمن افتراضيًا" ثقة دائمة.
سمعة OpenBSD الأمنية ليست فقط عن تخفيفات ذكية—هي أيضًا عن طريقة العمل.
أقرّ المشروع بفكرة أن الأمن مسؤولية مشتركة، وأن "الجيد بما فيه الكفاية" في الإعدادات الافتراضية (أو التصحيحات المهملة) ليست مقبولة لمجرد أنها تعمل.
بعض العادات تتكرر في فرق الهندسة الآمنة، وجعلها OpenBSD صريحة كان له أثر:
الآراء القوية يمكن أن تحسن الأمن بمنع الانحراف التدريجي للجودة: تُطعن الاختصارات الخطرة مبكرًا، ويُعامل التفكير الضبابي ("سيكون جيدًا") كعيب.
لكن تلك الشدة نفسها قد تقلل المساهمات إذا شعر الناس بعدم الأمان لطرح أسئلة أو اقتراح تغييرات. يفيد الأمن من التدقيق؛ والتدقيق يحتاج مشاركة.
يمكنك استعارة آليات ثقافة صارمة دون تكرار الاحتكاك بين الأشخاص.
طقوس عملية تنجح في معظم المنظمات:
الخلاصة: الأمن ليس ميزة تُضاف لاحقًا. هو معيار تُطبق—بشكل متكرر، ومرئي، وبعمليات تجعل الخيار الصحيح الأسهل.
“الآمن افتراضيًا” يعني أن إعدادات النظام الابتدائية تكون من قاعدة دفاعية معقولة: خدمات مكشوفة قليلة، أذونات محافظة، وخيارات بروتوكول/تشفير آمنة.
يمكنك بعد ذلك تخفيف القيود، لكن تفعل ذلك عن قصد—لذا يكون الخطر صريحًا بدلًا من أن يُورَث عن طريق الصدفة.
لأن الإعدادات الافتراضية هي المسار الذي تتبعه الغالبية العظمى من التوزيعات. إذا تم تمكين خدمة افتراضيًا فستعمل على كثير من الأنظمة لسنوات—غالبًا دون أن يتذكر أحد أنها موجودة.
عامل الإعداد الافتراضي كإجراء أمني ذي تأثير كبير: فهو يحدد سطح الهجوم الحقيقي لغالبية التثبيتات.
ابدأ بفحوصات التعرض الأساسية:
الهدف هو التأكد من أنه لا يوجد شيء قابل للوصول أو مخول «فقط لأنه جاء هكذا».
التدقيق هو مراجعة منهجية تهدف إلى تقليل أصناف كاملة من الأخطاء، وليس مجرد إصلاح مشكلة تم الإبلاغ عنها. نشاطات التدقيق الشائعة تتضمن:
إنها عمل هندسي مستمر، ليست مجرد «مرور أمني» لمرة واحدة.
«أقل الصلاحيات» يعني أن كل خدمة (وأي مكوّن داخلها) تحصل فقط على الأذونات التي تحتاجها لتنفيذ عملها.
خطوات عملية:
تقسيم الصلاحيات يفصل برنامجًا معرضًا للخطر إلى أجزاء:
إذا تم اختراق الجزء المعرض، ينزل المهاجم في عملية ذات حقوق محدودة، ما يقلل من مساحة الضرر ويصعّب التصعيد.
التدابير مثل W^X وASLR وحمايات المكدس تجعل أخطاء سلامة الذاكرة أصعب في الاستغلال.
عمليًا:
هي طبقة دفاعية متعددة المراحل، وليست بديلاً عن إصلاح الثغرات الأساسية.
أصبح OpenSSH انتشاريًا كأداة افتراضية للوصل البعيد، لذا فإن وضعه الأمني يؤثر على جزء كبير من الإنترنت.
من الناحية التشغيلية، SSH يجلس في المسار الأكثر حساسية (وصول المسؤول، أتمتة الأساطيل، الاسترداد الطارئ). الإعدادات الافتراضية المحافظة والتغييرات الحذرة تقلل احتمال أن يصبح «الاستخدام الطبيعي» نقطة ضعف شاملة.
الثقة تُبنى عندما تكون التحديثات والإشعارات قابلة للتنفيذ.
عملية إشعار/تحديث عملية يجب أن:
التصحيح المنتظم مع اتصال واضح هو كيف تبقى «الآمن افتراضيًا» حقيقيًا عبر الزمن.
اجعل المسار الآمن هو المسار الافتراضي، واطلب مراجعة لكل ما يزيد التعرض.
أمثلة:
وثّق الاستثناءات بمالكين وتواريخ انتهاء حتى لا يصبح الخطر دائمًا.