تحديد نطاق البوابة الصادرة
يستخدم هذا الدليل وثائق AsyncOS 16.0 General Deployment لـ Cisco Secure Email Cloud Gateway، الذي يعود تاريخ فصل مصادقة البريد الإلكتروني الخاص به إلى 3 أكتوبر 2024. وهي عبارة عن خطة تكوين وقبول مقيدة بالإصدار، وليست مطالبة بشأن الإصدار الأخير أو مستأجر تم فحصه. يقوم سير عمل التوقيع الموثق بإنشاء مفتاح، وربط ملف تعريف المجال، ونشر مواد التحقق من نظام أسماء النطاقات DNS ، وتمكين تسجيل الدخول إلى السياسة الصادرة. مسار واجهة المستخدم الرسومية الموصوف هو سياسات البريد، وسياسات تدفق البريد، ثم RELAYED، ثم توقيع DomainKeys/ DKIM ، متبوعًا بالإرسال والالتزام. التحقق الوارد منفصل عن التوقيع الصادر. يمكن أن يؤدي عدم تطابق الملف الشخصي إلى ترك رسالة بدون توقيع. دليل مصادقة البريد الإلكتروني من سيسكو
يوفر سير العمل المحدود هذا نقطة بداية معمارية. أنها لا توفر للمستأجر محددأو المفتاح الخاص أو مخزون IP الصادر أو المعتمد SPF إذن. تعتبر بقية هذه المقالة طريقة مراجعة أصلية لربط سير العمل الموثق بأدلة البروتوكول. قبل تنفيذه، يجب على المسؤول المسؤول التأكد من إصدار البوابة الفعلي وعناصر التحكم المدعومة وتغيير السلطة ومسار الرسالة. لم يتم الوصول إلى أي بوابة ولم يتم إنشاء أي مفتاح أو سياسة أو رسالة هنا.
ابدأ بعقد الطريق
قم بتدوين مكان ظهور الرسالة والنظام الذي يقوم بإجراء اتصال SMTP الخارجي النهائي. قم بتضمين أي ترحيل للتطبيق، ونظام صندوق البريد الرئيسي، والبوابة، وترحيل المتلقين للمعلومات، والخروج المواجه للمستلم. والغرض من ذلك هو تحديد النقطة التي يجب فيها تقييم التوقيع وتفويض نظام التعرف على هوية SPF ، وليس جمع كل عنوان شبكة داخلي. احتفظ بالتكوين الحساس في سجل التغيير الذي يتم التحكم فيه بالمؤسسة بدلاً من تضمينه في مقالة مشتركة على نطاق واسع.
لكل مسار، سجل المجال المرئي المتوقع، SMTP البريد من المجال والمقصود DKIM مجال التوقيع. وهذه هويات مختلفة حتى عندما تجعلها المنظمة تبدو متشابهة عمدًا. يقوم نظام التعرف على SPF بتقييم هوية SMTP ذات الصلة وعنوان الاتصال. يتحقق DKIM من التوقيع المرتبط بمجال التوقيع الخاص به. DMARC يربط المعرفات المؤهلة المصادق عليها بمجال المؤلف المرئي. إن وجود البوابة في المسار لا يمثل هوية مصادق عليها في حد ذاته. RFC 7208 ، الأقسام 2.3-2.4 RFC 6376 ، القسم 3.5 RFC 9989 ، القسم 4.4
يجب أن يتضمن عقد المسار استثناءات: الإشعارات الآلية والمرسلون المفوضون والتطبيقات ذات الرؤوس غير العادية والبريد الذي يتجاوز البوابة المقصودة. لا تقبل تكوينًا يعتمد فقط على رسالة واحدة مناسبة للموظفين. حدد المسارات المميزة التي تتطلب دليلاً والتي تقع بشكل واضح خارج نطاق النشر. يؤدي هذا إلى إنشاء حدود قابلة للمراجعة بدلاً من بيان غير مدعوم يفيد بأن جميع رسائل البريد الإلكتروني الخاصة بالشركة تمت مصادقتها.
فصل المنشور الرئيسي عن قبول التوقيع
يشتمل نشر DKIM على مسؤوليتين متميزتين على الأقل. يقوم الموقع بحماية المفتاح الخاص واستخدامه، بينما يجعل DNS مادة التحقق المقابلة قابلة للاكتشاف. يوفر التوقيع نطاقًا محددًا وتوقيعًا يحدد موقع المفتاح. إن نشر قيمة TXT ذات المظهر المعقول لا يثبت أن البوابة تمتلك المفتاح المطابق أو أنها توقع المسار المقصود. وعلى العكس من ذلك، فإن تمكين التوقيع لا يثبت أن السجل العام متاح للمستلمين. RFC 6376 ، الأقسام 3.5 و 3.6.2.2
استخدم سجل التغيير الذي يربط مجال التوقيع المعتمد أو المحدد أو بصمة المفتاح العام أو المعرف غير السري المكافئ ومالك DNS والسياسة المقصودة بنفس عملية النشر. لا تقم أبدًا بلصق المفاتيح الخاصة في ورقة العمل. احصل على متطلبات التشفير وإدارة المفاتيح الحالية من التنفيذ المدعوم وسياسة الأمان المؤسسي بدلاً من نسخ الحد الأدنى التاريخي من دليل أقدم. لا توفر هذه المخطوطة عمدًا أي مادة أساسية قابلة لإعادة الاستخدام أو أمر إنشاء المفاتيح.
قم بمراجعة مالك DNS الدقيق بشكل مستقل عن عرض المحرر. قد يتم توسيع تسمية المحدد النسبي بواسطة واجهة DNS ، بينما قد يتطلب الاسم الكامل معالجة مختلفة. احتفظ بالاسم المؤهل بالكامل المقصود ومحتوى TXT المنطقي قبل النشر. سلاسل متعددة في واحد سجل TXT ليست نفس الشيء مثل سجلات الموارد المتنافسة المتعددة. يجب التحقق من تقسيم العرض أو علامة الاقتباس في السياق بدلاً من معاملته تلقائيًا على أنه تلف. RFC 1035 ، الأقسام 3.3.14 و5.1
قم بمراجعة SPF عند حدود الخروج الحقيقية
لا تخترع إضافة SPF على مستوى Cisco بناءً على اسم المنتج. ويعتمد الترخيص ذو الصلة على البنية التحتية الفعلية للصادر ومجال المغلف. يجب على المشغل المسؤول الحصول على معلومات الخروج المعتمدة الحالية، وتسويتها مع المرسلين الشرعيين الحاليين، ومراجعة السياسة الكاملة الناتجة. يمكن أن تمثل البوابة المستضافة ومنصة صندوق البريد الرئيسي والتطبيق احتياجات ترخيص مختلفة حتى عندما تتم إدارتها جميعًا بواسطة نفس الفريق.
يجب نشر نظام التعرف SPF كـ TXT ضمن النطاق المناسب. متعددة قابلة للتطبيق سجلات SPF إنتاج خطأ بدلاً من دمجها في قائمة مسموح بها أكبر. تنطبق ميزانية التقييم أيضًا على مصطلحات استعلام DNS التي يتم تقييمها بشكل متكرر، وليس فقط عدد سلاسل التضمين المرئية في سياسة المستوى الأعلى. راجع سلوك التبعية قبل إضافة خدمة أخرى واحتفظ بخطة التراجع التي لا تؤدي إلى إزالة المرسلين الحاليين بصمت. RFC 7208 ، الأقسام 3.1-3.3 و4.6.4
لا تتوافق بالضرورة نتيجة تمرير نظام التعرف على هوية المرسل SPF لنطاق المغلف الذي يتحكم فيه الموفر مع المجال المرئي للمؤسسة. عندما يعتمد المسار على DKIM المحاذي، احتفظ بهذا الاختيار بشكل صريح. يتطلب DMARC نتيجة مؤهلة لنظام التعرف على هوية المرسل SPF أو DKIM ، ولكن قد يفرض المشروع أو المزود متطلبات مسبقة إضافية. لا تقم بتحويل المسارات البديلة للبروتوكول إلى إذن لتجاهل متطلبات التنفيذ. RFC 9989 ، القسم 4.4
أنشئ تسلسلًا للأدلة بدلاً من لقطة شاشة للنجاح
يحتوي تسلسل القبول المقترح على نقاط تفتيش منفصلة لنية التكوين ونظام DNS المنشور والرسائل المستلمة فعليًا. أولاً، تأكد من أن تكوين المستأجر المدعوم يطابق عقد المسار المعتمد. ثانيًا، احتفظ بملاحظات DNS المعتمدة مع اسم المالك ونوعه وقيمته المنطقية ووقت المراقبة. ثالثاً، تقييم الرسالة المعتمدة المستلمة خارج نظام الإرسال وتسجيل المعرفات ذات الصلة ونتائج المصادقة دون نشر المراسلات الخاصة.
عندما لا تتفق الأدلة، قم بتشخيص الطبقة قبل تغيير السياسة. تمثل الرسالة غير الموقعة مشكلة مختلفة عن الرسالة الموقعة التي لا يمكن العثور على مفتاح التحقق الخاص بها. يختلف التوقيع الصالح ولكن غير المحاذي عن التوقيع الذي تم إبطاله بواسطة تعديل الرسالة. تختلف ملاحظة DNS من ذاكرة التخزين المؤقت القديمة عن السجل المعتمد غير الصحيح. تمنع هذه الفروق الفريق من إضعاف DMARC لإخفاء مشكلة التوقيع أو التوجيه التي لم يتم حلها. التحقق DKIM و DMARC تنسيق هي تقييمات ذات صلة ولكنها منفصلة. RFC 6376 ، الأقسام 3.5-3.6 RFC 9989 ، القسم 4.4
التشخيص الخيالي: طريق مفقود من الخطة
في شركة خيالية، North Quay Parts، يقوم فريق المراسلة بإعداد التوقيع للمراسلات العادية. لا يزال تطبيق الحسابات يستخدم مسار ترحيل معتمدًا مختلفًا. يرى المراجع نتيجة ناجحة لرسالة واحدة للموظفين ويقترح وضع علامة على النطاق بأكمله مكتملًا. لا يتم تمثيل أي شركة أو اختبار أو نتيجة فعلية في هذا السيناريو.
تتوقف المراجعة عند عدم تطابق النطاق. تتم إضافة مسار التطبيق إلى المخزون، ويتم توثيق مظروفه وهويات المؤلف، ويتم تعيين مسؤولية التوقيع الخاصة به. لا يعتقد الفريق أن التطبيق يجتاز نفس سياسة البوابة. كما أنه يتجنب استبدال SPF بمثال خدمة واحدة أو تغيير DMARC لمجرد الحصول على مؤشر أخضر. ويظل القبول معلقًا حتى يحصل كل مسار داخل النطاق على دليل معتمد مناسب.
ورقة عمل قبول النشر الفارغة
- منتج البوابة وإصدارها وتاريخ الوثائق المعمول بها: ____.
- مالك التكوين ومالك DNS والموافق على الإصدار: ____.
- فئة الرسالة والمسار المعتمد عبر المخرج النهائي: ____.
- المتوقع من، البريد من، ومجالات توقيع DKIM : ____.
- اقتران السياسة/الملف الشخصي المدعوم والاستثناءات التي لم يتم حلها: ____.
- مرجع سجل التحقق العام والمحدد، باستثناء الأسرار: ____.
- مرسلو نظام التعرف على SPF الحاليين، والتفويض المقترح ومراجعة التبعية: ____.
- مالك DNS المقصود والأدلة الرسمية الحالية ووقت المراقبة: ____.
- أدلة الرسائل المستلمة الفعلية المعتمدة وتقييم التوافق: ____.
- شروط التراجع والتناقضات التي لم يتم حلها وقرار الموافقة: ____.
ورقة العمل فارغة ولم يتم تنفيذ أي خطوة تشغيلية. تظل أدلة التنفيذ الأصلية، والمراجعة البشرية، وقابلية تطبيق المصدر الحالي، وطرق الإنتاج، والفحوصات المرئية/إمكانية الوصول، وإصدار المالك مفتوحة. لا يزال قبول المصادقة لا يضمن التسليم أو سلامة الرسالة أو شرعية طلب العمل. RFC 9989 ، القسم 2.4