مشاركة ملفات بثقة صفرية: لا تثق بأحد، شفّر كل شيء

مشاركة ملفات الثقة الصفرية تفترض أن الشبكة معادية، والخادم مخترق، وجهاز المستقبل ربما مُصاب — ثم تُشفّر وفقاً لذلك. تُشفَّر الملفات في متصفح المُرسِل بـ AES-256-GCM قبل أن يصل أي بايت إلى الشبكة، تُشتق المفاتيح من كلمة مرور مع ملح مخزّن في جزء URL، ويتعامل الخادم مع نص مشفر معتم فحسب. هذا هو نموذج التشغيل المُقنَّن في NIST SP 800-207 مُطبَّقاً على نقل الملفات: تحقق صراحةً، امنح أدنى صلاحية، وافترض الاختراق في كل طبقة.

الافتراضات الثلاثة التي تقود التصميم

تبدأ الثقة الصفرية بثلاثة مسلّمات. أولاً، النقل مخترق — البروكسيات المؤسسية تفحص TLS، وشبكة Wi-Fi المقهى تُشغّل ARP spoofing، ونقاط استراق السمع على الشبكات الفقارية للدول القومية موجودة (وثّقها سنودن عام 2013، ولا تزال تعمل وفقاً لتقرير Bloomberg 2024). ثانياً، الخادم مخترق — مزودو السحابة يُخترقون (AWS في 2019، Microsoft في 2023)، والمسؤولون ينقلبون، واستدعاءات القضاء تأتي بهدوء. ثالثاً، جهاز المستقبل ربما مُصاب — يشغّل موظف Chrome قديم الإصدار، وبرامج خبيثة تحصد الملفات المفككة تشفيرياً. كل قرار تصميمي ينبثق من هذه الافتراضات الثلاثة.

التشفير على جانب العميل كمبدأ أول

إذا كان الخادم يستطيع رؤية النص الصريح، فهذا ليس ثقة صفرية. كل شيء يبدأ بمتصفح المُرسِل الذي يُشغّل Web Crypto API: توليد مفتاح 256 بتاً، اشتقاقه من كلمة مرور المستخدم بـ PBKDF2 عند 600,000 تكرار، تشفير الملف بـ AES-256-GCM، ثم فقط بعد ذلك بثّ النص المشفر إلى الخادم. أثبت Firefox Send أن هذا يعمل على نطاق المستهلكين قبل أن تغلقه Mozilla في 2020. الخلفاء الحديثون — HexaTransfer وWormhole وSkiff — يلتقطون النمط. يحمل الخادم بايتات لا يستطيع قراءتها.

مواد المفاتيح لا تغادر نقاط النهاية

يجب أن يصل مفتاح فك التشفير إلى المستقبل دون لمس الخادم. آليتان تنجحان. أولاً، حيلة جزء URL: يعيش المفتاح بعد # في رابط التنزيل، والمتصفحات لا ترسله في طلبات HTTP. ثانياً، المفاتيح المشتقة من كلمة مرور: يُخبر المُرسِل المستقبلَ بكلمة مرور عبر قناة منفصلة (Signal، مكالمة هاتفية، 1Password Psst!)، ويعيد متصفح المستقبل اشتقاق المفتاح. يُبعد كلاهما مواد المفاتيح عن سجلات الخادم وذواكر CDN المؤقتة ونسخ قواعد البيانات الاحتياطية — وهو ما يهم عندما يحدث الاختراق الحتمي.

التحقق من الكود الذي يعمل في المتصفح

الثقة الصفرية على جانب العميل أصعب من جانب الخادم لأن الخادم يشحن JavaScript التي تُجري التشفير. خادم خبيث قد يدفع حزمة مُخترقة لمستخدم مستهدف واحد. التخفيفات: انشر تجزئات SHA-384 لكل إصدار، وقّعها بـ Sigstore أو مفتاح PGP مؤسسي، وشجّع المستخدمين المتمرسين على التحقق بامتدادات المتصفح مثل Code Verify (تشحنها Meta لـ WhatsApp Web). رؤوس CSP مع script-src 'self' وSubresource Integrity تمنع الحقن من CDNs مخترقة. لا شيء من هذا مثالي، لكنه يُضيّق سطح الهجوم.

المصادقة بلا أسرار مشتركة مخزّنة

كلمات المرور المُرسَلة عبر البريد والمخزّنة في قواعد بيانات الخوادم هي نقيض الثقة الصفرية. استبدلها بمفاتيح مرور WebAuthn مربوطة بجهاز المستقبل — المفتاح الخاص لا يغادر Secure Enclave قط، والخادم يخزّن المفتاح العام فقط. للنقل الفردي، استخدم OPAQUE (RFC 9380) للمصادقة بكلمة مرور لا تُرسَل ولا تُخزَّن من الخادم. الروابط السحرية المُرسَلة إلى عناوين بريد مُتحقق منها مسبقاً تقدّم مساراً وسطاً: إنتروبيا الرمز (128 بتاً) تحلّ محلّ الحاجة إلى سر مخزّن.

تصنيف النقل حسب الحساسية

لا يستحق كل ملف الضوابط ذاتها. يجب أن تتيح خدمة مشاركة الملفات ذات الثقة الصفرية للمُرسِلين تصنيف الرفع: عام (بلا كلمة مرور، صلاحية 7 أيام)، داخلي (كلمة مرور، صلاحية 48 ساعة)، سري (كلمة مرور + مصادقة ثنائية، صلاحية 4 ساعات، تنزيل واحد)، مقيّد (مفتاح مرور + ربط IP + صلاحية 15 دقيقة). أتمتة التصنيف بحسب نوع الملف عند الإمكان: إقرار ضريبي .pdf → سري؛ عقد .docx → داخلي؛ تصميم تسويقي .psd → عام. يُسمّي NIST SP 800-171 هذا معالجة المعلومات غير السرية الخاضعة للتحكم، وينعكس بنظافة على سير عمل النقل.

معاملة جهاز المستقبل كغير موثوق

بمجرد فكّ بوب تشفير ملاحظة قانونية بحجم 5 ميجابايت لأليس، تجلس في مجلد التنزيلات. إذا اخترق أحدهم حاسوبه المحمول، يتسرب الملف. تمتد تفكير الثقة الصفرية إلى هنا: شجّع المستقبلين على فك التشفير في مساحة تخزين مؤقتة (Tails OS، أو جلسة ضيف Chrome OS)، وتجنّب فك التشفير على أجهزة مشتركة، والمسح بقوة بعد الاستخدام. لعمليات النقل عالية المخاطر، استخدم عارضات محمية تُفكّك التشفير في علامة تبويب متصفح معزولة وتمنع التنزيل — يرى المستقبل الـ .pdf لكن لا يحصل على البايتات على القرص. هذا واضح أنه يُضرّ بتجربة المستخدم؛ احجزه للطبقة العليا.

التسجيل بلا تحوّل إلى نظام مراقبة

يُسجّل مسار تدقيق الثقة الصفرية ما يجب لإدارة الحوادث والامتثال، لا أكثر. جزّئ عناوين IP يومياً، وخزّن عائلات User-Agent فقط (لا السلاسل الكاملة)، ولا تسجّل كلمات المرور أو المفاتيح قط، واحتجز للحدّ الأدنى الذي تتطلبه كل لائحة — 90 يوماً لأغراض المادة 30 من GDPR، و6 سنوات لـ HIPAA 164.316. يعيش السجل نفسه على تخزين قابل للإلحاق فقط (S3 Object Lock، وضع الامتثال) حتى لا يستطيع مسؤول مخترق إخفاء مساره. نشر جذور Merkle يومياً على لوحة إعلانات عامة يُضيف تحققاً خارجياً.

أين تلتقي الثقة الصفرية بالواقع القانوني

الثقة الصفرية لا تُعفيك من طلبات إنفاذ القانون. تُغيّر ما يمكنك تقديمه — نصاً مشفراً لا تستطيع فكّ تشفيره، وتجزئات IP لا يمكن عكسها، وسجلات من وصل إلى أي جزء. هذا عادةً كافٍ لإرضاء أمر قضائي صحيح مع إبقاء بيانات المستخدم بعيدة عن المراقبة الجماعية. انشر تقرير شفافية (النموذج القديم لـ Twitter) يُظهر أحجام الطلبات ومعدلات الاستجابة. وثّق تقليل بياناتك في سياسة الخصوصية حتى يفهم المستخدمون المقايضات: يمكنك التحقق من نقل ملف، لكن لا يمكنك قراءته أو تحديد هوية المستقبل بيقين.

جرّبها على hexatransfer.com — مجاني، بدون حساب، حتى 10 جيجابايت.