[ التقارير والتحقيق ]

تقارير الفشل المشفرة والتعامل مع جانب المستلم

تشفير النقل المنفصل وتشفير الرسائل وحماية التخزين عند تصميم مدخل آمن لتقرير الفشل.

بواسطة فريق البحث EmailAuth · 5 دقائق قراءة

[النقاط الرئيسية]

  • تشفير النقل المنفصل وتشفير الرسائل وحماية التخزين عند تصميم مدخل آمن لتقرير الفشل.
  • تبقى قدرة التشفير غير المختبرة بمثابة بوابة تجميع مفتوحة.
في هذه الصفحة

لا يزال من الممكن أن يؤدي البريد الإلكتروني المشفر إلى تقرير تشخيصي غير آمن. RFC 9989 يحذر من احتمال ظهور رسالة مشفرة أو مؤمنة في الأصل في تقرير لم يتم إرساله بشكل آمن. ولذلك، يجب أن تكون الحماية من الإبلاغ عن الفشل مصممة للتقرير نفسه، وليس موروثة بالافتراض من الاتصال الأصلي.

هذا الدليل عبارة عن قائمة مرجعية للتصميم والقبول من جانب المستلم. لا يدعي أن كل جهاز استقبال تقارير يدعم الحمولات النافعة لتقرير الفشل المشفرة، ويصف جديدًا DMARC وضع علامة أو تقديم تكوين تم اختباره لمنتج معين. إنشاء قدرات فعلية مع أنظمة إعداد التقارير والاستهلاك قبل جمع المواد الحساسة.

ثلاث طبقات حماية منفصلة

تتعلق حماية النقل بالاتصالات التي تحمل التقرير. يتعلق التشفير على مستوى الرسالة بحمولة التقرير ومن يمكنه فك تشفيرها. تتعلق حماية التخزين بالبيانات والنسخ المحفوظة بعد الاستلام. تعالج هذه الطبقات مسارات تعريض مختلفة ولا تحل محل بعضها البعض.

لا تثبت خطوة SMTP المحمية أن المرفق يظل مشفرًا في صندوق بريد أو تصدير أو تذكرة. لا يثبت الملف المخزن المشفر أن كل خطوة نقل كانت محمية. كما أن نتيجة التوقيع أو المصادقة لا تثبت السرية. قم بوصف الحماية المحددة وحدودها بدلاً من وضع علامة على سير العمل بأكمله مشفر.

اتفق على ما يمكن أن يقدمه نظام إعداد التقارير

اسأل ما إذا كان المولد يمكنه إرسال تنسيق التقرير المطلوب من خلال مسار آمن متفق عليه، وما إذا كان يدعم تشفير الحمولة، وكيف يتم إنشاء هوية فك التشفير الخاصة بالمستهلك والحفاظ عليها. قم بتسجيل أي حدود للدعم، وسلوك الفشل، والرجوع المسموح به. لا تفترض أن URI الخاص بالإبلاغ يتفاوض تلقائيًا مع نظام تشفير متوافق.

RFC 9991 يشجع القنوات الآمنة ويسلط الضوء على التقليل والوجهات الخاضعة للرقابة. لا ينبغي تفسير آلية الإبلاغ عن ruf الخاصة بها على أنها ضمان عالمي للتشفير على مستوى الرسالة. إذا لم يكن من الممكن التحقق من وسائل الحماية المطلوبة، ففكر في عينات تشخيصية خاضعة للرقابة أو بيانات مجمعة بدلاً من قبول مجموعة حساسة أوسع بشكل افتراضي.

إعداد حدود فك التشفير

إذا كان تشفير الحمولة مدعومًا، فقم بتعيين ملكية مفاتيح المستلمين وخدمات فك التشفير المعتمدة وتسجيل الوصول والتدوير والاسترداد. احتفظ بالمفاتيح الخاصة بعيدًا عن تذاكر الدعم العادية ومخازن التقارير. حدد العملية التي يمكنها رؤية النص العادي وما إذا كانت هذه العملية تنشئ ملفات مؤقتة أو سجلات أو معاينات أو نسخًا لاحقة.

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

اختبر المسار بالكامل باستخدام تركيبات غير ضارة

اختبار القبول التوضيحي: يقوم نظام الإبلاغ المتفق عليه بإرسال تجهيزات غير ضارة عبر المسار المعتمد. يمكن للمستهلك المعتمد معالجتها؛ لا يمكن لحساب غير مصرح به الوصول إلى النص العادي؛ ويتم تسجيل حالات الفشل دون كتابة محتوى الرسالة في السجلات العامة؛ والأدلة المصدرة تتبع عملية التنقيح المعتمدة.

قم أيضًا باختبار الحمولة غير القابلة للقراءة أو غير المتوقعة، وإمكانية فك التشفير المفقودة وأي إجراء موثق لنقل المفتاح. حدد ما إذا كانت النتيجة الآمنة هي العزل أو الرفض أو إعادة المحاولة المعتمدة. لا تتراجع أبدًا بصمت إلى توزيع النص العادي عندما يكون التشفير أحد متطلبات المجموعة. هذه اختبارات مقترحة، وليست ادعاءات بأن أي نظام قد اجتازها.

استخدم تركيبات مسماة ومصفوفة النتائج المتوقعة

تحتوي أداة التثبيت المقترحة -01 على العلامة REPORT-TEST-ONLY والعناوين المخترعة ضمن example.com فقط. الحساب "أ" هو الحساب الاختباري المعتمد لتقرير المستهلك؛ أما الحساب "ب" فهو حساب عادي لا يتمتع بإمكانية الوصول إلى التقارير. استخدم فقط تنسيق التشفير وترتيب مفتاح الاختبار الذي يدعمه كلا نظامي الاختبار بشكل صريح. لا يوجد مفتاح خاص للإنتاج أو رسالة حقيقية في هذا التمرين.

المصفوفة التالية افتراضية ولم يتم تشغيلها مقابل خدمة التقارير. وهو يصف نتائج القبول المطلوب التحقق منها، وليس الميزات التي وعد بها منتج مسمى.

  • إدخال الاختبار أو التشغيل: عملية تثبيت سليمة -01 باستخدام مفتاح الاختبار المعتمد؛ النتيجة المتوقعة للتحقق: يمكن لـ A قراءة تقرير الاختبار فقط داخل حدود التحليل المقيدة؛ الأدلة التي يجب الاحتفاظ بها: معرف الاختبار، والحساب المعتمد، والوقت والنتيجة، بدون المواد الأساسية
  • اختبار الإدخال أو العملية: يحاول B نفس الوصول؛ النتيجة المتوقعة للتحقق: لا يستطيع B الوصول إلى النص العادي أو خدمة فك التشفير؛ الأدلة التي يجب الاحتفاظ بها: حدث رفض الوصول وهوية الحساب
  • اختبار الإدخال أو التشغيل: عملية تثبيت-01 تحتوي على مفتاح اختبار خاطئ أو مفقود؛ النتيجة المتوقعة للتحقق: لا يوجد إصدار نص عادي؛ عزل أو رفض وفقا لتصميم الفشل المعتمد؛ لا يوجد احتياطي تلقائي للنص العادي؛ الدليل الذي يجب الاحتفاظ به: رمز الفشل ومرجع الحجر أو الرفض
  • اختبار الإدخال أو العملية: يعالج A نسخة تالفة عمدًا؛ النتيجة المتوقعة للتحقق: اكتشاف فشل المعالجة وعزله؛ لا تعرض محتوى جزئيًا أو تعامل معه بصمت كتقرير صالح؛ الأدلة التي يجب الاحتفاظ بها: معرف التركيبات التالفة ونتيجة الخطأ
  • اختبار الإدخال أو العملية: تكتمل المعالجة ويتم تشغيل عملية تنظيف العمل المؤقت؛ النتيجة المتوقعة للتحقق: لا تحتوي السجلات العامة على علامة تثبيت أو نص رسالة؛ تتم إزالة نسخ النص العادي المؤقتة وفقًا لقاعدة التنظيف المعتمدة؛ الأدلة التي يجب الاحتفاظ بها: فحص السجل وفحص المتجر المؤقت
  • إدخال الاختبار أو العملية: يقوم A بتصدير المستخلص التشخيصي المعتمد؛ النتيجة المتوقعة للتحقق: التصدير يحتوي فقط على الحقول المتفق عليها؛ لا يزال B غير قادر على الوصول إليه؛ الأدلة التي يجب الاحتفاظ بها: مراجعة قائمة حقول التصدير والتحقق من الوصول إلى الوجهة
  • القدرة المفقودة هي نتيجة اختبار لم يتم حلها، وليست تمريرة. قم بتسجيل النتائج الفعلية إلى جانب هذه المصفوفة عند إجراء اختبار معتمد. إذا كان من الممكن تحليل المدخلات التالفة بأمان بموجب تصميم موثق، فقم بمراجعة هذا السلوك بشكل واضح بدلاً من إضعاف النتيجة المتوقعة بعد الفشل.

تغطية حياة النص العادي

بعد فك التشفير، قم بتقييد الوصول والاحتفاظ فقط بما يحتاجه غرض التشخيص. قم بتضمين إعادة توجيه البريد وتنزيلات المحللين وفهارس البحث ومرفقات الأحداث والنسخ الاحتياطية في خريطة البيانات. التشفير عند الاستلام لا يمنع المستخدم المصرح له أو التكامل من إنشاء نسخة نص عادي غير ضرورية.

قم بتسجيل الأدلة الداعمة لكل طبقة حماية وأصحاب النظام والقيود التي لم يتم حلها. استخدم تاريخ المراجعة لتأكيد استمرار التوافق وعناصر التحكم في الوصول. والنتيجة التي يمكن الدفاع عنها هي حدود معالجة التقارير التي تم التحقق منها مع وجود فجوات واضحة، وليس عبارة عامة تفيد بأن البريد المشفر يجعل الإبلاغ عن الفشل آمنًا.

احتفظ بقرار القدرة منفصلاً عن خطة الاختبار

تفترض الحالة المكتوبة ENC-01 أن المستهلك يدعم الحمولات المشفرة ولكن دعم المولد غير معروف. وبالتالي، لم يتم إرسال Fixture-01، وكل نتيجة مصفوفة معلقة. يجب على مالك المجموعة الحصول على التوافق الموثق قبل السماح بإجراء اختبار غير ضار؛ لا يؤدي نجاح TLS إلى صندوق البريد إلى توافق الحمولة. لا تقم بتمكين تناول التقارير الأولية على نطاق أوسع لمجرد وجود خدمة فك التشفير. لم يتم استخدام أي مفتاح أو حساب أو تقرير.

[ الوجبات الجاهزة ]

تبقى قدرة التشفير غير المختبرة بمثابة بوابة تجميع مفتوحة.

[ حسب الدور ]

ماذا يعني هذا بالنسبة لك

اختر دورك للخطوات العملية التالية.

تكنولوجيا المعلومات / مدير البريد

اختبار التعامل مع المستلم من النهاية إلى النهاية

يقدم فك التشفير حدود نص عادي تحتاج إلى ضوابط واضحة.

الخطوات التالية

  1. استخدم تركيبات قبول غير ضارة.
  2. التحقق من الفشل وسلوك التناوب.
  3. منع تسرب النص العادي إلى السجلات.

كبير مسؤولي أمن المعلومات / SecOps

حماية التقرير بعد التسليم

لا يؤدي التشفير إلى إزالة مخاطر البيانات الحساسة أو المحتوى الضار.

الخطوات التالية

  1. تعيين المفتاح وأمناء الوصول.
  2. مراجعة الصادرات والنسخ الاحتياطية.
  3. تتطلب موافقة صريحة على السلوك الاحتياطي.

المؤسس / غير التقنية

تتطلب حدود الحماية التي تم التحقق منها

يمكن لعلامة التشفير إخفاء الفجوات بين النقل والمعالجة والتخزين.

الخطوات التالية

  1. قم بتعيين إجراءات حماية البيانات المطلوبة.
  2. اطلب دليلاً على الدعم الفعلي.
  3. اختر أدلة أقل تدخلاً عندما يكون الدعم غير كافٍ.

[ الأسئلة الشائعة ]

الأسئلة المتداولة

هل تشفير الرسالة الأصلية يحمي تقرير الفشل؟

ليس تلقائيا. قد يتم إرسال التقرير أو الاحتفاظ به بشكل مختلف ويمكن أن يعرض معلومات من الرسالة الأصلية.

هل تشفير النقل هو نفس تشفير الحمولة؟

لا، فهو يحمي الاتصال، في حين أن تشفير الحمولة يقيد الوصول إلى بيانات الرسالة المشفرة نفسها.

هل يضمن ruf محتوى التقرير المشفر؟

لا. تحقق من قدرات المولد والمستهلك الفعلي بدلاً من افتراض التشفير الشامل للحمولة.

هل التوقيع الصحيح يجعل المحتوى سريًا؟

لا. إن دليل المصادقة أو النزاهة لا يشكل في حد ذاته السرية.

ما الذي ينتمي إلى اختبار القبول من جانب المتلقي؟

تحقق من حدود النص العادي المسموح بها، ومعالجة الفشل، والتسجيل، والنسخ المؤقتة، وعمليات التصدير اللاحقة باستخدام تركيبات غير ضارة.

هل يمكن الوثوق بالمحتوى الذي تم فك تشفيره باعتباره آمنًا؟

لا، فقد لا يزال محتوى الرسالة الأصلية المضمن يحتوي على تصيد احتيالي أو برامج ضارة.

هل يجب إعادة إرسال التقارير المشفرة غير القابلة للقراءة بنص عادي؟

فقط إذا كان التصميم المعتمد صراحة يسمح بذلك. لا تتجاوز بصمت متطلبات التشفير.

ما الذي يجب حمايته بعد فك التشفير؟

النص العادي والملفات المؤقتة والسجلات ونسخ المحللين والصادرات والنسخ الاحتياطية المحتفظ بها ضمن دورة حياة البيانات المعتمدة.

[ مصادر ]

مصادر

  1. RFC 9989 : مصادقة الرسائل وإعداد التقارير والمطابقة على أساس المجال

    الأقسام §4.4 · §5.3.1 · §5.3.5 · §7.4 · §11.7

  2. RFC 9991 : الإبلاغ عن فشل DMARC

    الأقسام §2 · §5 · §7 · §8

[ مسرد ]

مسرد

محاذاة المعرف
العلاقة المطلوبة بين نطاق المؤلف ومجال SPF أو DKIM الذي تمت مصادقته لـ DMARC .
طلب التقارير المجمعة (rua)
علامة DMARC تحدد الوجهات لتقارير المصادقة المجمعة.
طلب الإبلاغ عن الفشل (ruf)
علامة DMARC تحدد الوجهات لمعلومات الإخفاق المحتملة الخاصة بالرسالة.
خيارات الإبلاغ عن الفشل (fo)
شروط تقرير الفشل المطلوبة، والتي يتم أخذها في الاعتبار فقط مع وجهة ruf؛ ولا يغيرون شرط مرور DMARC .
التصرف المبلغ عنه
المعالجة المتعلقة بـ DMARC التي أبلغ عنها المتلقي، تختلف عن تدقيق التسليم النهائي الكامل.
تغطية التقارير
يتم تمثيل أجهزة الاستقبال والفترات وحركة المرور المرصودة في مجموعة تقارير متاحة، وليس بالضرورة كل البريد المرسل.
جدول الاحتفاظ
قاعدة معتمدة مبنية على الغرض للاحتفاظ بفئة سجلات محددة والتخلص منها، بما في ذلك الاستثناءات والنسخ.

مصدر المؤسسة

لماذا كبار المؤسسات المالية والحكومات تقاعدوا من لوحات معلومات أمان البريد الإلكتروني الخاصة بهم.

تبيع لك منصات مصادقة البريد الإلكتروني التقليدية لوحة تحكم وتطلب من مهندسيك القيام بهذا العمل. في البيئات عالية المخاطر، تعني المراقبة اليدوية تأخير التنفيذ، والانحراف في التكوين، ونطاقات الظل غير الخاضعة للمراقبة.

EmailAuth هي منصة مصدر البريد الإلكتروني الوكيل. وكلاؤنا ينفذون p=reject، حافظ على محاذاة المرسلين الخارجيين وانقل نطاقاتك إلى كاملها RFC 9989 الامتثال، وهو معيار DMARC الجديد، مع إمكانية التدقيق البشري في الحلقة.

الحكومات المؤسسات الكبيرة المؤسسات المالية من المستوى الأول

SaaS · إيجار مخصص · Air-gapped محليًا · تشفير BYOK

قاعدة المعرفة