أمن التطبيقات: كيف تحمي تطبيقك وبيانات عملائك
حين يقرر صاحب عمل أن يبني تطبيقاً، يفكّر عادة في الشكل والسرعة وتجربة المستخدم، ويؤجّل سؤال الأمن إلى "ما قبل الإطلاق بأسبوع". المشكلة أن الأمن ليس طبقة تُضاف في النهاية، بل قرارات تُتخذ من أول يوم: أين تُخزّن كلمات المرور، كيف ينتقل رقم البطاقة بين الجوال والخادم، من يحق له رؤية بيانات أي عميل. أي خطأ في هذه القرارات لا يظهر في التجربة اليومية، لكنه ينفجر في أسوأ لحظة ممكنة.
في هذا الدليل نشرح أساسيات أمن التطبيقات لصاحب العمل غير التقني، مع أمثلة من واقع السوق السعودي حيث صار العميل أكثر وعياً بخصوصيته، وحيث صار نظام حماية البيانات الشخصية يُلزم الشركات بمسؤوليات واضحة. الهدف أن تعرف ما يجب أن تسأل عنه فريقك التقني، وأن تميّز بين تطبيق بُني بمسؤولية وآخر بُني على عجل.
ما الذي تحميه فعلاً؟
قبل الحديث عن الأدوات، اتفق مع فريقك على ما يستحق الحماية. ليست كل البيانات بنفس الحساسية، ومحاولة حماية كل شيء بنفس الدرجة تُهدر الجهد وتُضعف ما يهم فعلاً. ابدأ بجرد بسيط: ما البيانات التي يجمعها التطبيق، وأين تُخزّن، ومن يصل إليها.
- بيانات الهوية: الاسم، رقم الجوال، البريد، رقم الهوية أو الإقامة إن وُجد.
- بيانات الدفع: أرقام البطاقات أو رموز المحافظ — وهذه يُفضّل ألا تلمسها خوادمك أصلاً، بل تمرّ عبر بوابة دفع متوافقة مع معيار PCI DSS.
- بيانات السلوك: الموقع الجغرافي، سجل الطلبات، التفضيلات — تبدو بسيطة لكنها تكشف الكثير عن العميل.
- بيانات التشغيل: مفاتيح الـ API، كلمات مرور قواعد البيانات، شهادات الدخول — تسريبها يفتح الباب على مصراعيه.
حين تعرف ما لديك، يصبح من السهل ترتيب الأولويات: بيانات الدفع والهوية ومفاتيح الوصول في القمة، وما عداها بعدها. هذا الجرد وحده يكشف أحياناً أن التطبيق يجمع بيانات لا يحتاجها — وأبسط حماية لبيانات لا تجمعها أصلاً.
المصادقة: من يدخل، وكيف نتأكد
المصادقة هي البوابة الأولى، وأكثر نقطة يُهاجَم منها التطبيق. القاعدة الأساسية: لا تُخزّن كلمات المرور كنص واضح أبداً. تُخزّن مُجزّأة (hashed) بخوارزمية حديثة مثل bcrypt أو Argon2، بحيث يستحيل استرجاع كلمة المرور حتى لو تسرّبت قاعدة البيانات كاملة.
- افرض حداً أدنى معقولاً لقوة كلمة المرور دون مبالغة تدفع المستخدم لكتابتها على ورقة.
- أتح المصادقة الثنائية (2FA)، ولو عبر رمز يُرسل للجوال، خصوصاً للحسابات التي تتعامل بالمال.
- استخدم بروتوكولات موثوقة مثل OAuth 2.0 لتسجيل الدخول عبر حسابات أخرى، بدل بناء آلية دخول من الصفر.
- اجعل جلسات الدخول تنتهي بعد مدة معقولة، وامنح المستخدم زر تسجيل خروج يُبطل الجلسة فعلياً على الخادم لا على الجهاز فقط.
نقطة كثيراً ما تُنسى: التحكم بالصلاحيات بعد الدخول. أن يسجّل المستخدم دخوله شيء، وأن يصل إلى بيانات غيره شيء آخر. تأكد أن كل طلب للخادم يتحقق من هوية صاحبه وصلاحيته، لا أن يعتمد على إخفاء الزر في الواجهة. إخفاء الزر ليس أمناً.
التشفير: حماية البيانات وهي تتحرك وهي ساكنة
للتشفير وجهان يجب أن يُغطّيا معاً. الأول تشفير البيانات أثناء انتقالها بين التطبيق والخادم، وهذا يتحقق باستخدام HTTPS عبر شهادة TLS سارية على كل اتصال دون استثناء — لا صفحة دخول مشفّرة وبقية الطلبات مكشوفة. الثاني تشفير البيانات وهي مخزّنة في قاعدة البيانات أو على الجهاز.
على مستوى الجهاز، لا تخزّن بيانات حساسة في ملفات نصية أو في تخزين بسيط يسهل قراءته. استخدم ما يوفّره النظام نفسه: Keychain في iOS وKeystore في أندرويد لحفظ الرموز والمفاتيح. أما على الخادم فشفّر الحقول الحساسة، واحرص على أن مفاتيح التشفير لا تعيش في الكود نفسه بل في خدمة إدارة مفاتيح منفصلة.
- لا تُمرّر بيانات حساسة في رابط الـ URL — تُسجَّل في سجلات الخوادم والمتصفحات.
- عطّل تسجيل البيانات الحساسة في ملفات الـ logs أثناء التطوير، فهي تتسرّب من حيث لا تنتبه.
- إن كنت تتعامل مع الدفع، فوّض ذلك لبوابة دفع متخصصة بدل تخزين أرقام البطاقات بنفسك.
أخطاء شائعة تُكلّف غالياً
أغلب الاختراقات لا تأتي من ثغرة عبقرية، بل من خطأ بسيط تكرّر ولم ينتبه له أحد. هذه أكثر الأخطاء التي نراها في التطبيقات السعودية والعربية:
- وضع مفاتيح الـ API وكلمات مرور قواعد البيانات داخل كود التطبيق نفسه، حيث يمكن استخراجها من النسخة المنشورة.
- الثقة العمياء بأي بيانات يرسلها التطبيق — أي ثغرة حقن (injection) تبدأ من هنا. تحقّق من كل مُدخَل على الخادم.
- ترك خدمات الاختبار والإعدادات المفتوحة (debug) مفعّلة في النسخة المنشورة.
- نسيان تحديث المكتبات الخارجية، فتبقى ثغرات معروفة مفتوحة لأشهر.
- الاعتماد على "الأمن بالغموض": إخفاء رابط لوحة الإدارة بدل حمايتها بصلاحيات حقيقية.
- عدم وجود خطة لما بعد الاختراق: من يُبلَّغ، وكيف تُغلق الثغرة، وكيف يُخطَر العملاء المتأثرون.
النقطة الأخيرة مهمة قانونياً في السعودية: نظام حماية البيانات الشخصية يُلزم بإبلاغ الجهة المختصة وأصحاب البيانات في حالات تسرّب معيّنة. وجود خطة استجابة مكتوبة مسبقاً يحوّل الكارثة إلى موقف يمكن إدارته.
الخصوصية ليست الأمن — لكنها توأمه
الأمن يمنع الوصول غير المصرّح به للبيانات. الخصوصية تسأل سؤالاً أعمق: هل يحق لك جمع هذه البيانات أصلاً، وهل يعرف العميل بذلك؟ تطبيق آمن تماماً قد يكون منتهكاً للخصوصية إن جمع ما لا يحتاجه أو شاركه دون علم صاحبه.
- اجمع أقل قدر ممكن من البيانات (مبدأ تقليل البيانات) — ما لا تجمعه لا يمكن أن يتسرّب.
- اطلب صلاحيات الجهاز (الموقع، الكاميرا، جهات الاتصال) عند الحاجة الفعلية فقط، واشرح سبب الطلب.
- وفّر سياسة خصوصية واضحة بالعربية تشرح ما تجمعه ولماذا ومع من تشاركه.
- امنح المستخدم أدوات حقيقية: تعديل بياناته، سحب موافقته، وحذف حسابه.
هذه ليست مجرد ممارسات حسنة، بل صارت متطلبات يقيسها متجر التطبيقات والمستخدم والجهة التنظيمية معاً. التطبيق الذي يحترم خصوصية مستخدمه يكسب ثقة تُترجم إلى بقاء.
كيف تبني الأمن كعادة لا كحدث
الأمن الذي يُراجَع مرة قبل الإطلاق ثم يُنسى لا يصمد. التطبيق الحي يتغيّر، والمكتبات تظهر فيها ثغرات جديدة، ومهاجمون يطوّرون أساليبهم. اجعل الأمن جزءاً من دورة العمل المستمرة لا محطة تُعبر مرة واحدة.
- راجع الكود من منظور أمني عند كل تغيير مهم، لا مرة واحدة.
- حدّث المكتبات الخارجية دورياً وراقب التنبيهات الأمنية الخاصة بها.
- اطلب اختبار اختراق مستقلاً قبل الإطلاق وبعد أي تحديث كبير.
- احتفظ بسجلات وصول تُمكّنك من معرفة من فعل ماذا ومتى عند الحاجة.
في كادر نتعامل مع الأمن كقرار معماري من اليوم الأول، لا كطبقة دهان أخيرة. حين تُبنى المصادقة والتشفير والصلاحيات بشكل صحيح من البداية، يصبح إضافة المزايا لاحقاً أسهل وأكثر أماناً. وإن كان لديك تطبيق قائم تشكّ في متانته، فمراجعة أمنية مبكرة أرخص بكثير من إصلاح ما بعد التسرّب.
تفكّر في تطبيقات الجوال؟
احصل على فريق هندسي مخصص يبني هذا ويستمر عليه، بإدارة كاملة من كادر.
