التشفير

كيف يشفّر Spun بياناتك، من تشفير واتساب إلى المكالمات الجماعية

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

نظرة سريعة

التشفير حسب السيناريو

فيما يلي كل نوع من البيانات يتعامل معه Spun، وكيف تتم حمايته بالضبط. لا نضع في عمود E2EE القيمة نعم إلا عندما لا يستطيع أي نظام من أنظمة Spun قراءة المحتوى.

السيناريو	أثناء النقل	أثناء التخزين	E2EE	ملاحظات
مكالمة صوتية 1:1 (Spun → Spun) DTLS-SRTP (WebRTC)	DTLS-SRTP (WebRTC)	لا يتم تخزينها	نعم	اتصال WebRTC مباشر من نظير إلى نظير. يتم التفاوض على المفاتيح بين الطرفين، ولا يحتفظ بها Spun أبدًا.
مكالمة فيديو 1:1 (Spun → Spun) DTLS-SRTP (WebRTC)	DTLS-SRTP (WebRTC)	لا يتم تخزينها	نعم	مثل المكالمة الصوتية. لا ترى خوادم الترحيل TURN سوى حزم مشفّرة عندما يفشل اتصال P2P المباشر.
مكالمة جماعية (3 مشاركين أو أكثر) TLS 1.2+ إلى SFU، وDTLS-SRTP للوسائط	TLS 1.2+ إلى SFU، وDTLS-SRTP للوسائط	التسجيل اختياري، ويُخزَّن في Cloudflare R2	لا	يفك LiveKit Cloud SFU تشفير الوسائط لتوجيهها إلى المشاركين الآخرين. هذه بنية SFU القياسية.
غرفة الترجمة (وضع P2P، ≤2 من المشاركين) DTLS-SRTP (WebRTC)	DTLS-SRTP (WebRTC)	لا تُخزَّن الترجمات إلا إذا كان التسجيل مفعّلًا	نعم	تنتقل إلى SFU إذا انضم مشارك ثالث، انظر الصف أعلاه.
غرفة الترجمة (وضع SFU، 3 مشاركين أو أكثر) TLS 1.2+ إلى SFU	TLS 1.2+ إلى SFU	لا تُخزَّن الترجمات إلا إذا كان التسجيل مفعّلًا	لا	يصل LiveKit SFU إلى الوسائط لترجمتها وإعادة مزجها.
رسائل واتساب (داخل واتساب) Signal Protocol (Meta)	Signal Protocol (Meta)	خوادم واتساب	جزئي	واتساب نفسه مشفّر من طرف إلى طرف (E2EE) بين المشاركين. لكن بمجرد أن يستلم مزوّد البوابة الخاص بك رسائلك الواردة نيابةً عنك، ترى البوابة وSpun النص الصريح، فهكذا يعمل صندوق الوارد.
رسائل واتساب (في Spun) TLS 1.2+	TLS 1.2+	PostgreSQL على Hetzner، معزولة لكل منظمة عبر RLS	لا	ضروري لعرض صندوق الوارد والبحث وميزات الذكاء الاصطناعي والأتمتة.
Spun Chat ورسائل الفريق TLS 1.2+	TLS 1.2+	PostgreSQL، معزولة عبر RLS	لا	نص صريح أثناء التخزين كي تكون الرسائل قابلة للبحث وللمعالجة بواسطة ميزات الذكاء الاصطناعي التي تفعّلها.
المرفقات (صور، فيديو، مستندات) TLS 1.2+ (Cloudflare R2 + S3 SigV4)	TLS 1.2+ (Cloudflare R2 + S3 SigV4)	Cloudflare R2، تشفير AES-256 أثناء التخزين بواسطة R2	لا	يدير R2 المفاتيح. يوقّع Spun روابط قصيرة الصلاحية لتقييد الوصول لكل منظمة.
بيانات بطاقات الدفع TLS 1.2+ مباشرةً إلى Stripe	TLS 1.2+ مباشرةً إلى Stripe	لا تصل إلى Spun أبدًا	جزئي	تجمع Stripe Elements بيانات البطاقة مباشرةً في المتصفح، فلا تصل أبدًا إلى خوادم Spun. لا نتلقى سوى معرّف عميل مُبهم.
مطالبات الذكاء الاصطناعي ومخرجاته TLS 1.2+ إلى مزوّد الذكاء الاصطناعي	TLS 1.2+ إلى مزوّد الذكاء الاصطناعي	تسجيل اختياري (مفتاح تبديل للمسؤول)	لا	تُرسل عبر TLS إلى OpenAI / AssemblyAI / وغيرها. يزيل إخفاء البيانات الشخصية (عند تفعيله) الحقول الحساسة قبل الإرسال.
النسخ الاحتياطية لقاعدة البيانات TLS 1.2+	TLS 1.2+	Hetzner / Cloudflare R2، تشفير AES-256 أثناء التخزين	لا	تشفير قياسي للنسخ الاحتياطية المُدارة.

E2EE = مشفّر من طرف إلى طرف. «نعم» تعني أن Spun نفسه لا يستطيع قراءة البيانات. «جزئي» تعني تشفيرًا من طرف إلى طرف داخل طرف ثالث (Stripe، واتساب)، مع بقاء الجزء الذي نتعامل معه مرئيًا لـ Spun.

أثناء النقل

كل ما ينتقل بين متصفحك وخوادمنا والمعالجين الفرعيين لدينا مشفّر عبر TLS.

TLS 1.2+ في كل اتصال عبر الشبكة

كل حركة البيانات بين المتصفح ↔ Spun، وSpun ↔ بوابة واتساب، وSpun ↔ OpenAI / AssemblyAI / Deepgram / Sarvam / Azure، وSpun ↔ Stripe مشفّرة عبر TLS. إصدارات البروتوكول الأقدم معطّلة على موازن الأحمال.

طبقة حافة أمامية عبر Cloudflare

تُنهي Cloudflare اتصال TLS عند الحافة ثم تعيد التشفير حتى الخادم الأصلي. تربط شهادات الخادم الأصلي الطلبات بخوادم Hetzner لدينا. حماية WAF وDDoS مفعّلة دائمًا.

روابط موقّعة قصيرة الصلاحية

تستخدم تنزيلات الوسائط روابط S3 SigV4 موقّعة مسبقًا تقتصر على كائن واحد، ولها مدة صلاحية ثابتة. حتى الرابط المسرَّب يتوقف عن العمل بمجرد انتهاء صلاحيته.

أثناء التخزين

البيانات المخزّنة معزولة لكل منظمة بواسطة أمان على مستوى الصفوف في PostgreSQL، ولا يمكن الوصول إلى الوسائط إلا عبر روابط موقّعة تقتصر على كائن واحد.

PostgreSQL مع أمان على مستوى الصفوف

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

ألمانيا أولًا، مع خلية واحدة في الولايات المتحدة

تعمل الخلية الرئيسية، وتضم طبقة التحكم وخوادم التطبيقات وPostgreSQL وRedis، في Hetzner نورنبرغ (ألمانيا، الاتحاد الأوروبي). وتعمل خلية ثانية في ماناساس، فرجينيا. كل منظمة مرتبطة بخلية واحدة فقط، وكل منظمة جديدة تُنشأ على خلية الاتحاد الأوروبي.

Cloudflare R2 للوسائط

تُخزَّن الصور ومقاطع الفيديو والصوت والمستندات في Cloudflare R2. لا يتم الوصول إليها أبدًا عبر عنوان حاوية تخزين عام، بل فقط عبر رابط موقّع يقتصر على كائن واحد.

المكالمات الصوتية ومكالمات الفيديو

ما هو تشفير حقيقي من طرف إلى طرف، وما ليس كذلك، ولماذا. لا نسوّق المكالمات الجماعية على أنها مشفّرة من طرف إلى طرف لأنها ليست كذلك.

الصوت والفيديو 1:1، تشفير حقيقي من طرف إلى طرف

عندما يتصل مستخدمان من Spun ببعضهما، يُشفَّر الصوت والفيديو عبر DTLS-SRTP من طرف إلى طرف بين المتصفحين. لا ينقل خادم Spun سوى إشارات SDP. وحتى إذا اضطر Cloudflare TURN إلى ترحيل الاتصال (بسبب NAT المتماثل أو جدران الحماية)، فلن يرى سوى حزم مشفّرة.

المكالمات الجماعية (3 أو أكثر)، مشفّرة أثناء النقل وليست مشفّرة من طرف إلى طرف

تستخدم المكالمات الصوتية ومكالمات الفيديو الجماعية وغرف الترجمة متعددة المشاركين LiveKit Cloud بوصفه SFU (وحدة إعادة توجيه انتقائية). تُشفَّر الوسائط عبر DTLS-SRTP بين كل تطبيق عميل وSFU، لكن SFU يفك التشفير عند الاستلام لتوجيهها إلى المشاركين الآخرين. هذه بنية SFU القياسية، وهي ليست مشفّرة من طرف إلى طرف.

غرف الترجمة، P2P أولًا متى أمكن

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

لماذا لا ندّعي تشفيرًا كاملًا من طرف إلى طرف في المكالمات الجماعية

يدعم LiveKit وضع تشفير اختياريًا من طرف إلى طرف (باستخدام Encoded Insertable Streams API) يحمي الوسائط حتى من SFU. هذا الوضع غير مفعّل حاليًا في مكالمات Spun الجماعية، إذ تتطلب إضافته آلية لتبادل المفاتيح بين المشاركين، وتوافقًا مُتحقَّقًا منه للمتصفحات وبرامج الترميز في كل تطبيق عميل مدعوم.

إذا كان التشفير الكامل من طرف إلى طرف للمكالمات الجماعية متطلبًا لديك، فتواصل معنا على [email protected]، فهو ضمن خارطة الطريق وسنشاركك آخر المستجدات.

المدفوعات والهوية

تتولى معالجات متخصصة البيانات الأكثر حساسية، بحيث لا يراها Spun ولا يخزّنها أبدًا.

بيانات البطاقة تذهب مباشرةً إلى Stripe

تجمع Stripe Elements أرقام البطاقات ورموز CVC وتواريخ الانتهاء داخل إطار iframe يرسلها مباشرةً إلى Stripe، متجاوزًا خوادم Spun بالكامل. لا نتلقى سوى معرّف مُبهم للعميل أو لوسيلة الدفع. Stripe حاصلة على شهادة PCI-DSS Level 1.

كلمات المرور مُجزّأة بـ Argon2

تستخدم الحسابات المعتمدة على البريد الإلكتروني وكلمة المرور Argon2id مع قيمة salt خاصة بكل مستخدم. لا نحتفظ بكلمات المرور كنص صريح ولا نسجّلها. يفوّض تسجيل الدخول عبر Google Sign-In المصادقة إلى Google بالكامل، فلا توجد أي كلمة مرور في Spun لتلك الحسابات.

توقيع مفاتيح API وwebhooks

كل حمولات webhook الواردة من أطراف ثالثة (واتساب، Stripe، webhooks الإضافات) موقّعة بـ HMAC-SHA256 ويتم التحقق منها على الخادم. رموز API الخاصة بالإضافات هي JWT قصيرة الصلاحية (RS256) مع نقطة نهاية JWKS منشورة.

رسائل واتساب: حدود التشفير من طرف إلى طرف

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

لديك أسئلة أخرى؟

للحصول على تفاصيل تقنية محددة (مجموعات التشفير، وجهات إصدار الشهادات، وسياسة تدوير المفاتيح، وغيرها) أو لطلب الرد على استبيان أمني، راسلنا على [email protected].

اطّلع على المعالجين الفرعيين لدينا العودة إلى نظرة عامة على الخصوصية