لماذا لا يصلح PPAP لأمن البريد الإلكتروني، وما الطريقة الصحيحة؟

«هل تشغيل إرسال ZIP محمي بكلمة مرور ثم إرسال الكلمة في رسالة لاحقة آمن حقاً؟» ما زال هذا السؤال يُطرح كثيراً. يبدو آمناً لأن الملف يبدو مشفّراً، لكن هنا يقع الفخ في العمل اليومي.

ما يُسمّى PPAP ضعيف كحماية من التنصّت، وغير كافٍ كإجراء ضد الإرسال الخاطئ، وفضلاً عن ذلك يعوق الفحص على مسار البريد، لذلك يصعب التوصية به في أمن البريد الحالي.¹²³⁴

يستند هذا المقال إلى وثائق رسمية ومصادر أولية يمكن التحقّق منها حتى أبريل 2026، ويعرض مشكلات PPAP وكيف يُستبدل في التشغيل العملي بشكل طبيعي.^12345678910

من يقرأ هذا المقال، وما الذي نفترضه

مصطلحات هذا المقال

نرتّب هنا، بسطر لكل مصطلح، الكلمات التي تظهر من الفصل 3 فصاعداً بلا شرح.

1. الخلاصة أولاً

الحديث عن إيقاف PPAP ليس حديثاً عن إيقاف التشفير. ما ينبغي إيقافه هو تصميم «تشفير المرفق كملف ZIP ثم إرسال كلمة المرور لاحقاً عبر منظومة البريد نفسها».

ما ينبغي التفكير فيه بدلاً من ذلك ثلاثة أمور.

1. اجعل البريد التجاري العادي يفترض حماية المسار مثل TLS / STARTTLS.⁷¹⁰
2. إن احتجت إلى أصالة الرسالة نفسها أو إلى تشفيرها، فاستخدم آلية مثل S/MIME.³⁵⁶
3. قرّب تسليم الملفات السرّية من التنزيل بعد المصادقة أو المشاركة بتحكّم في الوصول، لا من المرفق.⁴⁸⁹

باختصار، المهم ألا تحاول حل مشكلات البريد كلها بكلمة مرور ZIP.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما هو PPAP أصلاً

يقصد بـ PPAP هنا عادة التسلسل التالي.

1. ضع الملف في ZIP محمي بكلمة مرور
2. أرسل ZIP في الرسالة الأولى
3. أرسل كلمة المرور في الرسالة الثانية

يُفهم هذا التشغيل غالباً على أنه «آمن لأننا لم نرسل بالنص الواضح». لكن النطاق المحمي فعلاً محدود جداً.

المشكلة ليست أنه يبدو شاملاً، بل أن مظهر «يبدو آمناً نوعاً ما» يغطي فشله في حماية ما يهم فعلاً.

3. لماذا لا يصلح PPAP

3.1 ضعيف كحماية من التنصّت

رتّب مكتب مجلس الوزراء الياباني أن إرسال كلمة المرور تلقائياً عبر المسار نفسه الذي سلكه ملف ZIP أمر غير مناسب.¹ المهم هنا ليس هل شفّرت الملف فقط، بل كيف تسلّم المفتاح أيضاً؛ وإلا ضعُف معنى التصميم.

إن أرسلت لاحقاً عبر بيئة البريد نفسها، وصندوق الوارد نفسه، وإلى المستلم نفسه، صار من يرى ZIP ومن يرى كلمة المرور هما تقريباً الشخص نفسه. يتبقى عندئذٍ «واقعة التشفير» وحدها، من دون سرّية جوهرية قوية.

3.2 غير كافٍ كإجراء ضد الإرسال الخاطئ

هناك تشغيل يعتبر PPAP إجراءً ضد الإرسال الخاطئ، وهذا أيضاً ضعيف.

في نموذج إجابة اختبار مهندس تقنية المعلومات التطبيقية لدى IPA، تُذكر من مشكلات PPAP أن إرسال الرسالة الأصلية إلى العنوان الخطأ يجعل كلمة فك التشفير تصل إلى المستلم الخطأ نفسه.³ وفي وثائق الوكالة الرقمية (Digital Agency) ترتيب بالمعنى نفسه: إرسال كلمة المرور في رسالة منفصلة إلى الطرف نفسه لا يعمل كضبط ذي معنى، لأنها تذهب إلى الشخص نفسه.⁴

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

3.3 يعوق فحص البرمجيات الخبيثة

هذه نقطة لا يجوز تفويتها بين مشكلات PPAP.

حذّرت IPA، بشأن رسائل هجوم Emotet التي ترفق ZIP محمياً بكلمة مرور، من أن تشفير المرفق يجعل احتمال أن تتجاوز منتجات الأمن على مسار التسليم الكشف والحجر، فيصل الملف إلى يد المستلم، احتمالاً مرتفعاً.²

قد يظن المرسل أنه «شفّر فصار آمناً»، لكن من جهة المستلم أو جهة الترحيل يصبح المرفق ملفاً يصعب فحص محتواه. من هذه الزاوية أيضاً لا يمكن القول إن PPAP منسجم مع دفاع البريد الحالي.

3.4 لا يضمن الأصالة ولا التحكّم في الوصول

لا يثبت PPAP أن المرسل هو الشخص الحقيقي. كما أنه لا يكاد يملك تحكّماً في الوصول: من نزّل ومتى، وهل يمكن الإلغاء لاحقاً، وهل يمكن فصل الصلاحيات بحسب المستلم.

في المقابل، تتناول IPA بريداً موقّعاً إلكترونياً مثل S/MIME، وهو يرتبط في السياق كبديل عن PPAP.⁵⁶ كما ترتّب وثائق أمن الويب لدى IPA أن المواقع التي تتعامل مع معلومات غير علنية تحتاج إلى مصادقة وتحكّم في الوصول.⁸

إن جمعت الأمرين، صار الجواب واضحاً إلى حد بعيد.

• إن أردت أصالة البريد أو كشف العبث فـ S/MIME
• إن أردت صلاحيات الاطلاع على الملف وإدارة الإلغاء فالتنزيل بعد المصادقة

إرسال كلمة مرور ZIP في رسالة منفصلة لا يجيب عن أيّ من هذين بشكل نظيف.

4. الطريقة الصحيحة هي الفصل بحسب الغرض

طلب «أريد أن أرسل بأمان» ليس طلباً واحداً في الواقع. إن لم تفصل هنا، انهار التصميم بمحاولة إنهاء كل شيء عبر PPAP.

4.1 البريد التجاري العادي

في البريد التجاري العادي، افترض أولاً حماية المسار مثل TLS / STARTTLS.⁷¹⁰ بعد ذلك، إن احتجت إلى أصالة المرسل أو كشف العبث أو تشفير نص الرسالة نفسه، فالمسار السليم هو دراسة S/MIME.³⁵⁶

4.2 تسليم الملفات السرّية

تريد تسليم الملف إلى الشخص المعني وحده، والتحكّم في صلاحية الاطلاع، والإلغاء لاحقاً. بهذه المتطلبات، يكون التنزيل بعد المصادقة أو المشاركة بتحكّم في الوصول أطبيع من المرفق.⁴⁸⁹

المتطلبات التالية مثلاً أسهل في الإدارة على جانب الويب منها كمرفق.

• التنزيل بعد تسجيل الدخول
• رابط محدود الأجل
• صلاحيات مختلفة بحسب المستلم
• الإبقاء على سجلّ عند الحاجة

حدّد الشروط الواجب تحقيقها قبل السؤال «ماذا نشتري؟»

الدخول من اسم المنتج يمنع المقارنة، لذا نرتّب الشروط أولاً. الفرق عن PPAP يتركّز في هذه الأسطر الستة.

الانتقال من يسار هذا الجدول إلى يمينه هو المعنى العملي لـ «إيقاف PPAP». وبالمعنى العكسي، إن كان البديل لا يحقق هذه الأسطر الستة، ففائدة الانتقال ضعيفة.

في حالات كثيرة يكفي نطاق العقد القائم

قبل شراء منتج جديد، راجع أولاً إلى أين يصل عقدك الحالي. في الحالات الشائعة يكون الأمر كالتالي.

ترتيب الأولوية هو المشاركة مع مستلم محدد أولاً، والرابط المحمي بكلمة مرور خياراً تالياً. لا تستخدم الرابط المحمي بكلمة مرور إلا حين يتعذّر على المستلم تهيئة حساب، وانقل تلك الكلمة عبر الهاتف أو SMS أو مسار آخر غير البريد. إن سكبتها في منظومة البريد نفسها عدت إلى بنية PPAP وأنت تظن أنك استبدلتها.

الحد الأدنى إن بنيت الوظيفة بنفسك

إن أضفت وظيفة تنزيل على موقعك، فإن ما تفكّر فيه لا يتغيّر.

1. وسيلة لتعريف المستلم إمّا أن تصدر حساباً للمستلم، وإمّا أن تصدر لكل قضية عنوان URL يحمل رمزاً لمرة واحدة.
2. الأجل اجعل لكل من URL والرمز أجلاً. عند انتهاء الأجل لا تُخفِ الصفحة، بل أعد صراحة «انتهت الصلاحية».
3. عملية الإلغاء يلزم أن يستطيع المسؤول الإبطال فوراً من شاشة الإدارة. بغير ذلك لا تملك شيئاً تفعله حتى لو اكتشفت إرسالاً خاطئاً.
4. سجلّ الوصول سجّل متى، ومن أي IP، وأي ملف أُخذ. نقطة الفصل عند الحادثة هي القدرة على الإجابة: «هل وصل أم لم يصل؟»
5. حماية مكان حفظ الملف أي ألا يصبح الملف متاحاً لكل من عرف URL. ترتّب IPA أيضاً أن المواقع التي تتعامل مع معلومات غير علنية تحتاج إلى مصادقة وتحكّم في الوصول.⁸
6. التعامل مع جانب الرفع إن كنت تستلم من الطرف الآخر، فاجمع ذلك في الآلية نفسها. نموذج مخصّص للاستلام أكثر أماناً من مواصلة قبول مرفقات البريد.

من هذه الستة، البندان 2 و3 هما الفرق الحاسم عن PPAP. سواء بنيت أم اشتريت، ما يفتقدهما ليس بديلاً.

4.3 حين لا بد من المرفق

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

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

5. خطوات الاستبدال في الشركات الصغيرة والمتوسطة

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

5.1 ما توقفه أولاً

• التشفير التلقائي إلى ZIP
• الإرسال التلقائي المنفصل لكلمة المرور عبر منظومة البريد نفسها
• القاعدة الشاملة «كل ملف مهم يمر عبر PPAP»

5.2 ما تقرّره بعد ذلك

• ما يجوز إرساله بريداً عادياً
• ما يُحظر إرفاقه
• ما يُحوَّل إلى تنزيل بعد المصادقة
• كيف تكون إجراءات الموافقة عند الإرفاق على سبيل الاستثناء

5.3 فكرة الحد الأدنى من التكوين

يكفي في البداية الفصل إلى هذين المسارين.

1. البريد العادي
   • التواصل التجاري
   • S/MIME عند الحاجة
2. الملفات السرّية
   • تنزيل بعد المصادقة
   • ضبط الصلاحيات
   • مشاركة محدودة الأجل

إن بقي هذا غامضاً، عاد الميدان بسهولة إلى «لنفعل PPAP مؤقتاً».

6. مسار اتخاذ القرار

flowchart TD
    A[ماذا تريد تسليمه للمستلم؟] --> B{هل هو ملف عالي السرّية؟}
    B -- لا --> C[بريد تجاري عادي]
    C --> C1[أرسل مع افتراض TLS / STARTTLS]
    C --> C2[إن كانت الأصالة أو التشفير مهمين فـ S/MIME]

    B -- نعم --> D{هل يستطيع المستلم الاستلام بعد تسجيل الدخول؟}
    D -- نعم --> E[تنزيل بعد المصادقة / مشاركة بتحكّم في الوصول]
    E --> E1[اضبط الصلاحيات والأجل والإلغاء عند الحاجة]

    D -- لا --> F{هل المرفق لا غنى عنه؟}
    F -- نعم --> G[ملف مشفّر + كلمة مرور يدوية عبر مسار آخر]
    F -- لا --> E

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

المهم في هذا الرسم ألا تضع PPAP حلاً وسطاً لكل غرض. البريد وتسليم الملفات أسهل في التصميم إن فُصلا.

7. سوء فهم شائع

7.1 «الملف مشفّر كـ ZIP، إذن هو آمن»

حتى مع التشفير، إن ضعُف أسلوب تسليم المفتاح لم يكفِ الإجراء. وفضلاً عن ذلك قد يعوق ZIP المحمي بكلمة مرور الفحص على المسار.¹²

7.2 «رسالة منفصلة تكفي»

الإرسال اللاحق إلى المستلم نفسه عبر منظومة البريد نفسها لا يصير ضبطاً قوياً.¹⁴

7.3 «إيقاف PPAP يعني أننا لن نستطيع الإرفاق»

ليس كذلك. أنت فقط تفرّق بين البريد العادي وS/MIME والتنزيل بعد المصادقة وكلمة المرور عبر مسار آخر عند الاستثناء.

7.4 «S/MIME للشركات الكبيرة وغير واقعي»

ننظر إلى جاهزية الطرف الآخر، لكن على الأقل هو أقوم من PPAP تجاه ما تريد حمايته. ولمن لا يناسبه S/MIME يبقى التنزيل بعد المصادقة خياراً آخر.

8. خلاصة

سبب ضعف PPAP أنه يسهّل الشعور بأن التشفير قد جعل الأمر آمناً. في الواقع تبقى المشكلات التالية:

• الإرسال المنفصل عبر منظومة البريد نفسها يضعف السرّية
• غير كافٍ كإجراء ضد الإرسال الخاطئ
• ZIP المحمي بكلمة مرور يعوق الفحص على المسار
• لا يضمن أصالة المرسل ولا التحكّم في الوصول¹²³⁴

إذن ما ينبغي فعله ليس إطالة عمر تشغيل يشبه PPAP بتعديل طفيف. احمِ البريد بوصفه بريداً، وصمّم تسليم الملفات بوصفه تسليم ملفات.

إن لخّصنا بجملة واحدة، فهكذا:

إيقاف PPAP ليس إيقاف التشفير، بل إيقاف ضبط خاطئ واستبداله بضبط يوافق الغرض.

مقالات ذات صلة

• كيف يمكن للشركات الصغيرة والمتوسّطة تصميم البريد الجماعيّ دون أن تحبس نفسها مع مزوّد واحد
• كيف تربط المقالات بصفحات الخدمات عبر internal links
• كيف تبني صفحة خدمة لشركات B2B التقنيّة

المراجع

مقالات ذات صلة

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

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

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

أسئلة شائعة حول موضوع هذه المقالة.

ما هو PPAP؟

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

لماذا يُعدّ PPAP خطراً؟

هناك أربع مشكلات رئيسة. أولاً، إرسال كلمة المرور عبر منظومة البريد نفسها يجعل من يرى ملف ZIP ومن يرى الكلمة هما تقريباً الشخص نفسه، فيضعف الإجراء كحماية من التنصّت. ثانياً، إن أخطأ العنوان وصلت كلمة فك التشفير إلى المستلم الخطأ أيضاً، فلا يكفي كإجراء ضد الإرسال الخاطئ. ثالثاً، ملف ZIP المحمي مشفّر، فيصعب على منتجات الأمن على مسار التسليم كشفه أو حجره، وقد استُخدم فعلياً في رسائل هجوم مثل Emotet. رابعاً، لا يضمن أصالة المرسل ولا التحكّم في الوصول.

إذا توقّفنا عن PPAP، فماذا نستخدم؟

الأساس أن نفصل بحسب الغرض إلى ثلاثة مسارات. البريد التجاري العادي يفترض حماية المسار بـ TLS / STARTTLS، وإن احتجت إلى أصالة الرسالة نفسها أو إلى تشفيرها فاستخدم S/MIME. أمّا تسليم الملفات السرّية فالأولى ألا يكون مرفقاً، بل تنزيلاً بعد المصادقة أو مشاركة بتحكّم في الوصول، حتى يمكن ضبط الصلاحيات والروابط محدودة الأجل والإلغاء. المهم ألا تحاول حل كل مشكلة في البريد بكلمة مرور ZIP.

ماذا نفعل إن كان لا بد من الإرسال كمرفق؟

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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