يمكن أن تكون توصية المصادقة صحيحة بينما يظل سير عمل التشغيل غير آمن. لوحة القيادة قد تحدد المفقودين محدد DKIM دون معرفة من يتحكم في DNS ، أو ما إذا كان المحدد المقترح ينتمي إلى المستأجر المقصود، أو ما إذا كان التغيير قد تمت الموافقة عليه. قم بتقييم كل قدرة على حدة بدلاً من التعامل مع الإجابة المعقولة كإذن للتصرف.
تتبع قرار واحد
اختر مهمة محدودة: قم بإعداد محدد جديد لمرسل الفواتير المعتمد مع الحفاظ على الموقع الحالي. سجل المجال ومالك الخدمة وهوية المرسل واسم مالك DNS المقترح والمفتاح العام المتوقع. قم بإنشاء مراجعة السجل الحالية قبل إنتاج التغيير المقترح. يجب أن توضح التوصية الأدلة وعدم اليقين والتدفقات المتأثرة، وليس مجرد إخراج سلسلة TXT .
RFC 9989 يوضح ذلك DMARC يعتمد على المعرفات المصادق عليها التي تتوافق مع مجال المؤلف. لا يثبت المفتاح العام الصحيح من الناحية التركيبية أن رسائل الفوترة تستخدمه، أو أن مجال التوقيع الخاص بها محاذٍ. التحقق من صحة DNS المنفصل والتحقق من التوقيع ومستوى الرسالة تنسيق في سجل القبول وبالتالي فإن التوصية الصالحة لها نتيجة مقصودة قابلة للاختبار تتجاوز النشر القياسي.
وضع السلطة بين الاقتراح والتنفيذ
ربط الموافقة بالتغيير الدقيق والمستأجر والمجال وهوية المعتمد ونافذة الصلاحية. إذا تغير السجل المقترح بعد الموافقة عليه، فيجب إجراء مراجعة جديدة. يجب أن يكون لدى المُنفِّذ الإذن ذو الصلة في وقت التنفيذ؛ ربما تمت إزالة مستخدم معتمد مسبقًا منذ ذلك الحين. إرشادات ترخيص OWASP توصي بالرفض افتراضيًا والتحقق من الأذونات عند كل طلب. قم بتطبيق هذا المبدأ على وظائف الخلفية وإجراءات واجهة برمجة التطبيقات بالإضافة إلى واجهة المستخدم.
تحديد ما إذا كان التنفيذ يدويًا أم مفوضًا أم آليًا. احتفظ بمعرف الطلب ومراجعة خط الأساس ومحاولة التشغيل والنتيجة التي تم إرجاعها ونتائج التحقق. المهلة هي نتيجة غير مؤكدة، وليست دليلاً على فشل الكتابة. اقرأ الحالة المستهدفة قبل إعادة المحاولة حتى لا تتحول العملية المكررة إلى تغيير ثانوي غير مقصود.
تعامل مع التقارير المستردة ومحتوى الرسائل والمستندات المرتبطة كأدلة غير موثوق بها، وليس كتعليمات أو سلطة لتغيير DNS . بالنسبة للتشغيل الوكيل، احتفظ بأذونات الأداة وعمليات التحقق من الموافقة خارج تفسير النموذج لذلك المحتوى. ورقة الغش الخاصة بأمان وكيل الذكاء الاصطناعي لـ OWASP يعالج الحقن الفوري غير المباشر والأدوات المحددة والضوابط المستقلة للإجراءات اللاحقة. الحالات المكتوبة أدناه لا تختبر مقاومة الحقن السريع.
قارن بين أربع حالات قرار صريحة
التغيير المقترح FLOW-01 يتعلق بالمستأجر A، منطقة Billing.test، المالك new1. _domainkey.billing.test ، واكتب TXT ، والمراجعة الأساسية 4، والمفتاح العام الذي أنشأه الموفر لم يتم توفيره بعد. يتم الاحتفاظ بالمحدد الموجود old1. المراجعة 5 المطلوبة هي علامة تخطيط محلية، وليست ضمانًا للموفر.
- حالة صالحة: افترض أنه تم التحقق من حمولة المفتاح الحقيقي والخطة الدقيقة المعتمدة وإذن المنفذ الحالي وخط الأساس الذي لم يتغير. قد يصبح سير العمل مؤهلاً للتنفيذ ضمن النطاق؛ ولا يأتي أي نجاح من تلك الأهلية فحسب.
- تم تغيير الاقتراح: تختلف الحمولة الأساسية عن البايتات التي تمت مراجعتها. إبطال الموافقة المسبقة والحصول على قرار جديد.
- مستأجر مشترك: يستهدف الطلب المستأجر ب بدلاً من ذلك. الرفض ضمن نطاق المستأجر-أ.
- المُنفِّذ الذي تم إبطاله: كان الإذن المسبق موجودًا ولكن الإذن الحالي غير موجود. رفض حتى يتم إنشاء الوصول المصرح به بشكل منفصل.
جميع المباني افتراضية. لا يتم توفير مفتاح عام أو إيصال الموافقة أو معرف الطلب أو الطابع الزمني أو الكتابة أو التجزئة أو اختبار التوقيع. لم يتم تغيير أي مراجعة في الذاكرة. يجب على الطيار الحقيقي أن يحتفظ بتلك القطع الأثرية وأدلة رسائل الفواتير الموثوقة قبل المطالبة بالنجاح التشغيلي.
الحكم على المساءلة بدلا من الطلاقة
يقدم محرك التوصية النصيحة. يحدد سير العمل المسؤول أيضًا من يمكنه الموافقة عليه، ومن يمكنه تنفيذه، وما الذي تغير وكيف تم التحقق من النتيجة. قارن الوقت الذي تقضيه في جمع الأدلة ومراجعة التغييرات ومعالجة حالات الفشل، وليس فقط الوقت اللازم لتوليد إجابة. قم بتضمين الحالات الفاشلة في المقام وتسجيل التدخل البشري بدلاً من إخفائه كإعداد.
أوقف البرنامج التجريبي عندما يكون التفويض أو هوية المستأجر أو حالة خط الأساس غامضة. يمكنك الاسترداد عن طريق استعادة التكوين المعتمد المعروف أو إعادة الموقع إلى محدده المحتفظ به بموجب خطة معتمدة. لا تعد بأن تصريح المصادقة يضمن وضع البريد الوارد: لا تزال سياسة المستلم وعوامل التسليم الأخرى سارية. اجعل مطالبات قدرة المنتج مقتصرة على الوظائف الموضحة بالفعل في البيئة التي تم تقييمها.