تشفير بيانات العملاء: دليل الشركات لحماية محادثات واتساب

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

أبرز النقاط

لتشفير بيانات العملاء طبقتان: التشفير أثناء النقل (TLS) يحمي البيانات المتحركة، والتشفير أثناء التخزين (AES عادةً) يحمي البيانات المخزّنة.
رموز وصول القنوات ومفاتيح API وأسرار الويب هوك بيانات اعتماد. تسريب رمز واحد يكفي ليتصرف مهاجم باسم شركتك، لذا شفّرها على مستوى الحقل.
تشفير القرص يحمي قرصًا مسروقًا، لا خادمًا يعمل. أما التشفير على مستوى الحقل، بمفاتيح محفوظة خارج قاعدة البيانات، فيبقي تلك الحقول مشفّرة حتى داخل نسخة مسرّبة.
AES-256-GCM تشفير موثّق: يخفي البيانات ويكشف أي عبث بها، ويقوم على ألا تُستخدم قيمة nonce نفسها مرتين مع المفتاح نفسه.
التشفير لا يوقف من يملك صلاحية فك التشفير. منصة الرد الآلي بالذكاء الاصطناعي مضطرة لقراءة الرسائل كي تجيب عنها، لذا لا يقلّ التحكم في الوصول ومدد الاحتفاظ أهمية عن الخوارزمية نفسها.

ما الذي يجب أن يغطيه تشفير بيانات العملاء في شركة تعمل بالمحادثات

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

بيانات الاعتماد والأسرار. رموز وصول صفحات فيسبوك وواتساب للأعمال، ورموز بوتات تيليجرام، ومفاتيح مزوّدي الذكاء الاصطناعي، ومفاتيح مزوّدي الدفع، وأسرار الويب هوك.
البيانات الشخصية للعملاء. أرقام الهواتف، وعناوين البريد الإلكتروني، وعناوين التسليم، ومعرّفات العملاء. وفي تجارة المحادثات يكون رقم الهاتف غالبًا هوية العميل نفسها.
سجلات المحادثات والوسائط. النصوص الكاملة، والرسائل الصوتية، والصور، والفواتير التي يرسلها العملاء.
كلمات مرور الموظفين. وهذه يجب تجزئتها (hashing) لا تشفيرها، كما سيأتي لاحقًا.
أجهزة الفريق. الحواسيب والهواتف التي تفتح صندوق الوارد أو تحفظ ملفات مُصدَّرة. فعّل FileVault أو BitLocker، ورمز قفل الجهاز، والمسح عن بُعد.
النسخ. النسخ الاحتياطية، وملفات CSV المُصدَّرة، والسجلات، وقواعد بيانات التجربة، وهي غالبًا أقل حماية من بيئة الإنتاج.

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

التشفير أثناء التخزين مقابل التشفير أثناء النقل

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

الجانب	التشفير أثناء النقل	التشفير أثناء التخزين
يحمي من	التنصّت، والعبث، والخوادم المزيفة	سرقة الأقراص، وتسريب النسخ، وكشف النسخ الاحتياطية
المعيار المعتاد	TLS 1.2 أو TLS 1.3	AES-256، وغالبًا AES-256-GCM
أين ينطبق	من المتصفح إلى التطبيق، والويب هوك، واستدعاءات API	القرص، وقاعدة البيانات، والحقول المفردة، والنسخ الاحتياطية
لا يغطي	البيانات بعد وصولها وفك تشفيرها	البيانات قيد الاستخدام داخل تطبيق يعمل

يوجب معيار NIST SP 800-52 Rev. 2 على خوادم TLS الحكومية الأمريكية دعم TLS 1.2، ودعم TLS 1.3 بحلول يناير 2024. وهذا خط أساس معقول لأي شركة: اقبل TLS 1.2 و1.3، وعطّل ما هو أقدم.

لكن TLS يحمي الرحلة فقط. فـ WhatsApp Cloud API يسلّم طلبات الويب هوك عبر HTTPS، وتوضح وثائق Meta أن Cloud API يفك تشفير الرسائل الواردة ويمررها إلى الشركة، مع الاحتفاظ بالرسائل مدة 30 يومًا كحد أقصى. وبعد ذلك ينتقل الدور إلى التخزين وضوابط الوصول.

تشفير القرص وقاعدة البيانات والحقول

التشفير أثناء التخزين يأتي على طبقات:

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

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

AES-256-GCM: حجم المفتاح ونمط التشغيل

معيار AES معرّف في FIPS 197 بمفاتيح 128 و192 و256 بت. و AES-256 يستخدم أكبرها.

ونمط التشغيل لا يقل أهمية عن حجم المفتاح. فنمط GCM (NIST SP 800-38D) هو تشفير موثّق: يحافظ على سرية البيانات ويكشف ما إذا كان أحد قد غيّر النص المشفّر. ولا تُعِد استخدام قيمة nonce مع المفتاح نفسه أبدًا: فإعادة استخدامها تُبطل ضمانات GCM، لذا دع مكتبة مُصانة تولّد قيم nonce، ولا تكتب تشفيرك بنفسك أبدًا.

كيف تخزّن مفاتيح API ورموز الوصول بأمان

اختر بحسب حاجتك إلى استرجاع القيمة الأصلية:

شفّر الأسرار التي تحتاج إلى إرسالها إلى جهة أخرى: رموز وصول واتساب وإنستغرام، ورموز بوتات تيليجرام، ومفاتيح مزوّدي الذكاء الاصطناعي ومفاتيح الدفع. استخدم AES-GCM على مستوى الحقل بمفتاح محفوظ خارج قاعدة البيانات.
جزّئ (hash) الأسرار التي تتحقق منها فقط: كلمات المرور، ومفاتيح API للشركاء، والرموز لمرة واحدة. التجزئة لا يمكن فك تشفيرها إلى الأصل، لكن القيم القصيرة أو سهلة التخمين قابلة للكسر بالقوة الغاشمة، لذا استخدم تجزئة بطيئة مثل Argon2id أو bcrypt لكلمات المرور، و HMAC بمفتاح للرموز.
أبقِها خارج السجلات ورسائل الأخطاء وأدوات التحليلات وعناوين URL.
حدّد النطاق ودوّر الرموز. اطلب الصلاحيات التي يحتاجها الرمز فقط، واستبدل الرموز عند مغادرة أي شخص يملك صلاحية الوصول.

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

أساسيات إدارة مفاتيح التشفير

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

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

التحكم في الوصول ومبدأ الحد الأدنى من الصلاحيات: التشفير وحده لا يكفي

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

والمنطق نفسه ينطبق على ما قبلها في السلسلة. فـ الورقة البيضاء لأمان واتساب لا تعدّ المحادثات مع الشركات التي تستخدم Cloud API مشفّرة من طرف إلى طرف، لأن الرسائل لا تُسلّم مباشرة إلى طرف تتحكم فيه الشركة. راجع WhatsApp Business Cloud API مقابل تطبيق الأعمال قبل اختيار إعدادك.

لذا فالطبقة التالية تدور حول من يستطيع الوصول إلى البيانات:

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

النسخ الاحتياطية والملفات المُصدَّرة ومدد الاحتفاظ

النسخ الاحتياطية نسخ كاملة من بيانات العملاء، وغالبًا ما يُحتفظ بها مدة أطول وتُراقَب أقل من بيئة الإنتاج. شفّر ملفات النسخ الاحتياطي، وقيّد من يستطيع تنزيلها، واختبر الاستعادة بما فيها استرجاع المفاتيح، واحذف ملفات CSV القديمة التي تبادلها الفريق عبر البريد أو المحادثات.

وللتشفير وزن قانوني أيضًا. فالمادة 32 من اللائحة العامة لحماية البيانات (GDPR) تسمّي التشفير تدبيرًا أمنيًا، والمادة 34(3)(أ) تعفي المتحكم من إبلاغ الأفراد المتضررين بالخرق إذا جعل التشفير البيانات غير مفهومة لغير المصرّح لهم. أما واجب المادة 33 بإبلاغ الجهة الرقابية خلال 72 ساعة من العلم بالخرق فمنفصل عن ذلك. كما يحدد نظام حماية البيانات الشخصية السعودي (PDPL) وقانون KVKK التركي مهلة 72 ساعة لإبلاغ الجهة المنظمة.

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

أسئلة اطرحها على أي مزوّد محادثات أو نظام CRM

قبل ربط قنواتك، استخدم هذه الأسئلة عن أمان مزوّدي الشات بوت في صيغة استبيان مكتوب:

ما إصدارات TLS التي تقبلها نقاط النهاية لديكم؟
ما البيانات المشفّرة أثناء التخزين، وعند أي طبقة؟ وهل يشمل ذلك محتوى الرسائل؟
هل رموز وصول القنوات ومفاتيح API مشفّرة على مستوى الحقل، وأين يُحفظ المفتاح؟
هل النسخ الاحتياطية مشفّرة، ومن يستطيع الوصول إليها؟
هل يستطيع موظفوكم قراءة محادثاتنا، وهل يُسجَّل هذا الوصول؟
ما الأدوار والصلاحيات التي يمكننا ضبطها لفريقنا؟
كيف تُعزل بياناتنا عن بيانات العملاء الآخرين؟
هل تُستخدم محادثاتنا في تدريب نماذج ذكاء اصطناعي، لديكم أو لدى مزوّدي الذكاء الاصطناعي؟
من هم معالجو البيانات الفرعيون لديكم، وأين تُخزَّن البيانات؟
هل توقّعون اتفاقية معالجة بيانات (DPA)، وكم تستغرق عملية حذف البيانات بعد مغادرتنا؟

وكن متشككًا في إجابات مثل "تشفير بمستوى عسكري" أو "كل البيانات مشفّرة بالكامل". المزوّد الجدير بالثقة يسمّي الخوارزمية والطبقة والثغرات.

ما الذي يشفّره Raabt ويحميه اليوم

كل بند أدناه يعكس الوضع الفعلي في كود Raabt حتى سبتمبر 2026.

التشفير على مستوى الحقل: الحقول الحساسة مشفّرة على مستوى التطبيق بخوارزمية AES-256-GCM. والكتابات الجديدة تستخدم مفتاحًا مشتقًا عبر HKDF-SHA256، والقيم الأقدم يُعاد تشفيرها به عند حفظها في المرة التالية. ويرفض التطبيق الإقلاع بلا مفتاح طوله 32 حرفًا على الأقل.
ما الذي يُشفَّر: بيانات الاعتماد والرموز (رموز وصول القنوات لفيسبوك وإنستغرام وواتساب وتيليجرام، ومفاتيح API لمزوّدي الذكاء الاصطناعي والدفع، وأسرار الويب هوك)، وبيانات تواصل مختارة (أرقام هواتف العملاء وبريدهم الإلكتروني وعناوين الطلبات).
التجزئة: كلمات المرور تستخدم Argon2id (ذاكرة 19 ميبي بايت، وعدد تكرارات 2)، وتجزئات bcrypt الأقدم تُرقَّى عند تسجيل الدخول. وأسرار مفاتيح API للشركاء تُخزَّن كتجزئات SHA-256 فقط.
تسجيل الدخول: تسجيل الدخول بالبريد وكلمة المرور يتطلب رمزًا لمرة واحدة يُرسل إلى بريد المستخدم قبل إصدار أي جلسة (وتسجيل الدخول عبر Google لا يستخدم هذا الرمز). وتُخزَّن الرموز كتجزئات HMAC-SHA256 فقط، وتنتهي صلاحيتها وتعمل مرة واحدة.
وصول الفريق: أربعة أدوار (المالك، والمسؤول، والوكيل، والمشاهد) بصلاحيات لكل قسم. ولا يمكن تفويض صلاحية الفوترة لغير المالك.
العزل: نقاط النهاية الخاصة بالشركات تتأكد أن صاحب الطلب عضو نشط في تلك الشركة، وترد بـ "غير موجود" فيما عدا ذلك.
الويب هوك والوسائط: طلبات الويب هوك من Meta تُرفض بلا توقيع X-Hub-Signature-256 صالح، وطلبات تيليجرام تتطلب رمزًا سريًا، والمرفقات تُقدَّم فقط عبر روابط موقّعة تنتهي صلاحيتها.
البنية التحتية: التطبيق غير مكشوف مباشرة للإنترنت؛ إذ تصل إليه حركة المرور العامة عبر Cloudflare Tunnel. وسجلات أخطاء قاعدة البيانات لا تتضمن أبدًا معاملات الاستعلام، فتبقى أرقام الهواتف وعناوين البريد الإلكتروني خارج تلك السجلات.
سجل تدقيق مشرفي المنصة: إجراءات مشرفي المنصة تُكتب في سجل تدقيق للإضافة فقط (من، وماذا، ومتى، وعنوان IP، مع لقطات قبل وبعد وحجب الأسرار). وهذا ليس سجلًا لرسائل العملاء.

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

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

قائمة تحقق تشفير بيانات العملاء: ترتيب التنفيذ للفرق الصغيرة

تشفير البيانات في الشركات الصغيرة ينجح أكثر بترتيب ثابت يبدأ بما يسبب أكبر ضرر عند تسريبه:

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

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

ما البيانات التي يجب على الشركة تشفيرها؟

ابدأ بكل ما يمنح صلاحية وصول أو يحدد هوية شخص: رموز القنوات، ومفاتيح API، وأسرار الويب هوك، وأرقام هواتف العملاء وبريدهم الإلكتروني وعناوينهم. ثم غطِّ سجلات المحادثات، وأجهزة الفريق، وكل نسخة احتياطية أو ملف مُصدَّر.

ما الفرق بين التشفير أثناء النقل والتشفير أثناء التخزين؟

التشفير أثناء النقل، وهو TLS عادةً، يحمي البيانات وهي تتنقل بين الأجهزة والخوادم وواجهات API. والتشفير أثناء التخزين، وهو AES عادةً، يحمي البيانات المخزّنة.

هل تشفير AES-256 كافٍ لحماية بيانات العملاء؟

AES-256 قوي، لكن الخوارزمية نادرًا ما تكون نقطة الضعف. فنقاط الإخفاق الشائعة هي سوء تخزين المفاتيح، وإعادة استخدام قيم nonce، وتوسيع صلاحيات الموظفين، ونسخ احتياطية بلا حماية.

كيف تخزّن مفاتيح API ورموز الوصول بأمان؟

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

إذا كنت أستخدم HTTPS، فهل بياناتي محمية على الخادم؟

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

ماذا أسأل مزوّد نظام CRM أو الشات بوت عن أمان البيانات؟

اسأل عن إصدارات TLS التي يقبلونها، وما المشفّر أثناء التخزين وعند أي طبقة، وأين تُحفظ المفاتيح، وهل يُسجَّل وصول الموظفين إلى المحادثات، ومن هم معالجو البيانات الفرعيون وأين تُخزَّن البيانات، وهل تُستخدم المحادثات في تدريب نماذج الذكاء الاصطناعي، وهل يوقّعون اتفاقية معالجة بيانات (DPA) بمهلة حذف محددة.

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