قبل إطلاق تطبيق مبني بالذكاء الاصطناعي تحقق من ستة محاور: الدخول (رموز OTP محدودة ومنتهية الصلاحية)، والصلاحيات (كل مستخدم يرى بياناته فقط، وكل موظف يرى ما يحتاجه فقط)، والدفع (عبر بوابة مرخصة والمبلغ يُحسب في الخادم)، والبيانات والملفات (أقل قدر ممكن، مشفرة، ورفع مقيد)، والمفاتيح السرية (في الخادم فقط)، والاستضافة (HTTPS ونسخ احتياطي وتراجع ومراقبة). ثم كرر المراجعة شهرياً وبعد كل ميزة كبيرة.
- قائمة تحقق امنية للتطبيقات
- كيف احمي تطبيقي من الاختراق
- اختبار امان التطبيق قبل الاطلاق
- حماية بيانات العملاء في التطبيق
- security checklist للتطبيقات بالعربي
كيف تستخدم قائمة التحقق الأمنية هذه؟
هذه قائمة تحقق أمنية لتطبيقك المبني بالذكاء الاصطناعي، مكتوبة لصاحب مشروع لا يقرأ الكود. لست مطالباً بفهم كل التفاصيل التقنية، بل بالتأكد أن كل بند متحقق، إما باختبار تجريه بنفسك أو بسؤال توجهه للوكيل ويجيب عنه بدليل. إن أردت أولاً فهم لماذا تظهر الثغرات في الكود المولّد، فابدأ بـهل الكود الذي يكتبه الذكاء الاصطناعي آمن؟.
قسّمنا البنود إلى ثلاث درجات حتى لا تتأخر عن الإطلاق بسبب كماليات، ولا تطلق وأنت تفتقد أساسيات:
| الدرجة | متى | أمثلة |
|---|---|---|
| حرج | قبل أي إطلاق، ولو لعشرة عملاء | الصلاحيات، المفاتيح السرية، حساب السعر في الخادم، HTTPS |
| مهم | خلال الشهر الأول بعد الإطلاق | سجل العمليات الإدارية، اختبار استعادة النسخة، مراجعة الأدوار |
| مع النمو | عندما يكبر الفريق أو البيانات | تحقق ثنائي إلزامي للموظفين، مراجعة أمنية خارجية، خطة استجابة للحوادث |
الحسابات وتسجيل الدخول
- [حرج] رمز التحقق OTP ينتهي خلال دقائق قليلة، ويُستخدم مرة واحدة فقط.
- [حرج] حد لعدد مرات طلب الرمز لكل رقم ولكل جهاز، مع انتظار بين الطلبات، وحد لمحاولات إدخال الرمز الخاطئ.
- [حرج] حسابات الإدارة محمية بكلمة مرور قوية أو دخول بالجوال، ولا يوجد حساب «admin» بكلمة مرور افتراضية.
- [مهم] تسجيل الخروج يُنهي الجلسة فعلاً، وتنتهي الجلسات الخاملة لحسابات الإدارة بعد مدة معقولة.
- [مهم] رسالة تنبيه عند الدخول لحساب الإدارة من جهاز جديد.
- [مع النمو] تحقق ثنائي إلزامي للموظفين، ودخول موحد SSO للشركات التي تطلبه.
- [مع النمو] للتطبيقات التي تحتاج تحققاً من الهوية: نفاذ في السعودية أو UAE PASS في الإمارات بدل رفع صور الهويات.
استغلال رموز التحقق مشكلة مالية قبل أن تكون أمنية، لأن كل رسالة لها تكلفة. التفاصيل الكاملة في كيف تمنع التسجيلات الوهمية واستغلال رموز التحقق.
الصلاحيات والوصول إلى البيانات
هذا المحور هو الأهم، لأن أكثر الثغرات تكراراً في التطبيقات السريعة هي أن يرى مستخدم بيانات غيره. القاعدة: أقل صلاحية تكفي لأداء العمل.
- [حرج] كل طلب بيانات يتحقق في الخادم أن المستخدم يملك هذه البيانات، لا في الواجهة فقط. اختبره بحسابين وبتغيير الأرقام في الروابط.
- [حرج] صفحات الإدارة لا تفتح لغير المسجلين ولا للعملاء، حتى لو عرفوا الرابط.
- [حرج] الدور (مالك، مدير، موظف، عميل) يُحدد في الخادم ولا يمكن تغييره من الواجهة.
- [مهم] كل دور مكتوب في جدول: ماذا يرى وماذا يعدّل وماذا يحذف. موظف التوصيل يرى عنوان الطلب المسند له فقط، لا كل العملاء.
- [مهم] سجل تدقيق للعمليات الحساسة: من حذف طلباً، من غيّر سعراً، من صدّر قائمة العملاء.
- [مهم] تصدير البيانات الكاملة (قوائم العملاء) محصور في المالك.
- [مع النمو] مراجعة دورية للحسابات: احذف حسابات الموظفين الذين غادروا في نفس اليوم.
الدفع والمال
- [حرج] الدفع يتم عبر بوابة مرخصة (mada وApple Pay وVisa وMastercard وTabby وTamara وغيرها)، وتطبيقك لا يخزّن أرقام البطاقات أبداً.
- [حرج] المبلغ النهائي يُحسب في الخادم من الأسعار المخزنة، والخصومات تُتحقق في الخادم؛ لا يُقبل أي سعر يأتي من المتصفح.
- [حرج] الطلب لا يُعلَّم «مدفوعاً» إلا بعد تأكيد البوابة للخادم مباشرة، لا لأن المتصفح عاد لصفحة النجاح.
- [مهم] التحقق 3D Secure مفعّل حسب إعدادات البوابة.
- [مهم] الاسترجاع (Refund) لا يملكه إلا المالك أو دور مالي محدد، ويُسجَّل في سجل التدقيق.
- [مهم] الفاتورة الإلكترونية تُصدر بالضريبة الصحيحة ورمز QR حيث يلزم.
للتعمق في هذا المحور اقرأ أساسيات أمان الدفع: 3D Secure وPCI.
البيانات والملفات والمفاتيح السرية
- [حرج] المفاتيح السرية (بوابة الدفع، الرسائل، الذكاء الاصطناعي) محفوظة في إعدادات الخادم، لا في كود الواجهة ولا في تطبيق الجوال. راجع مفاتيح API والأسرار.
- [حرج] رفع الملفات يقبل الصيغ المسموحة فقط (صور، PDF) بحجم أقصى، والملفات الخاصة كالهويات والتقارير لا تفتح برابط عام.
- [حرج] رسائل الخطأ للمستخدم عامة ومفهومة، والتفاصيل التقنية تذهب للسجلات فقط.
- [مهم] اجمع أقل قدر من البيانات: لا تطلب تاريخ الميلاد أو رقم الهوية إن لم تحتجه فعلاً.
- [مهم] البيانات مشفرة أثناء النقل (HTTPS) وأثناء التخزين حيث تتيح المنصة ذلك.
- [مهم] سياسة خصوصية واضحة بالعربية والإنجليزية، وطريقة لطلب حذف الحساب.
- [مع النمو] مدد احتفاظ محددة: متى تُحذف الطلبات القديمة والسجلات وبيانات الحسابات المحذوفة.
الاستضافة والنشر والتعافي
- [حرج] كل الصفحات تعمل عبر HTTPS وأي رابط http يُحوَّل تلقائياً.
- [حرج] النطاق ومسجّل النطاق وحساب البريد محمية بتحقق ثنائي؛ من يسيطر على النطاق يسيطر على تطبيقك.
- [مهم] التعديلات تُجرَّب في بيئة تجربة قبل الإنتاج. اقرأ بيئة التجربة والإنتاج.
- [مهم] نسخ احتياطي يومي، وجرّبت استعادة نسخة مرة واحدة على الأقل، وتعرف كيف تتراجع عن نشر سيئ في دقائق.
- [مهم] مراقبة توفر التطبيق مع تنبيه لك إذا توقف.
- [مع النمو] استضافة داخل الدولة إن كان قطاعك أو عملاؤك يتطلبونها، وخطة استجابة مكتوبة لحادثة تسرب.
نفّذ القائمة مع الوكيل خطوة بخطوة
- 1اطلب تقريراً لا تعديلاً
ابدأ ببرومبت المراجعة أدناه، واطلب جدولاً بالنتائج قبل أي تغيير.
- 2أصلح الحرج أولاً
اطلب إصلاح كل بند حرج على حدة، واختبره بنفسك قبل الانتقال للتالي.
- 3اختبر بالحسابين
بعد الإصلاحات، كرر اختبار الحسابين وتغيير الأرقام واختبار الزائر.
- 4انشر وراقب
انشر الإصلاحات، وراقب السجلات والتنبيهات في الأيام الأولى.
- 5جدول المهم ومع النمو
ضع بنود الدرجتين التاليتين في تقويمك، لا في ذاكرتك.
نفّذ مراجعة أمنية كاملة للتطبيق على ستة محاور: الدخول ورموز OTP، الصلاحيات والأدوار، الدفع، البيانات والملفات والمفاتيح السرية، الاستضافة والنسخ الاحتياطي، والسجلات. لكل محور اعرض جدولاً: البند، الحالة (متحقق / غير متحقق / غير واضح)، الدليل (أين في الكود أو الإعدادات)، والإصلاح المقترح، ورتّب حسب الخطورة. ركّز خصوصاً على: أي صفحة أو طلب بيانات لا يتحقق من ملكية المستخدم في الخادم، وأي سعر يُقبل من المتصفح، وأي مفتاح سري خارج الخادم. لا تعدّل شيئاً قبل موافقتي، ثم أصلح البنود الحرجة واحداً واحداً.
جرّبه في فنّانروتين أمني بعد الإطلاق
| التكرار | ماذا تفعل |
|---|---|
| بعد كل ميزة كبيرة | اختبار الحسابين، واختبار الزائر، ومراجعة الصلاحيات للصفحات الجديدة |
| أسبوعياً | نظرة على تنبيهات المراقبة وتكلفة رسائل التحقق وطلبات الاسترجاع غير المعتادة |
| شهرياً | مراجعة حسابات الموظفين والأدوار، وتحديث المكتبات، وتشغيل برومبت المراجعة الأمنية |
| كل ثلاثة أشهر | تجربة استعادة نسخة احتياطية، ومراجعة سياسة الخصوصية، وتدوير المفاتيح السرية المهمة |
| قبل المواسم الكبرى | قبل رمضان والجمعة البيضاء: اختبار الضغط على الدفع، ومراجعة حدود الرموز، وتجميد التعديلات الكبيرة |
الأمان ليس جداراً تبنيه مرة واحدة، بل باب تتأكد كل ليلة أنه مقفل.
الخلاصة
- ابدأ بالبنود الحرجة قبل الإطلاق: الصلاحيات، المفاتيح السرية، حساب السعر في الخادم، وحدود رمز التحقق.
- مبدأ أقل صلاحية: كل موظف وكل مستخدم يرى ما يحتاجه فقط.
- لا تخزّن بيانات البطاقات في تطبيقك أبداً؛ دع بوابة الدفع تتولاها.
- النسخ الاحتياطي الذي لم تجرّب استعادته ليس نسخاً احتياطياً بعد.
- الأمان روتين وليس مهمة لمرة واحدة: راجع شهرياً وبعد كل ميزة كبيرة.
أسئلة شائعة
كيف احمي تطبيقي من الاختراق؟
ما هي اهم بنود الامان قبل اطلاق التطبيق؟
هل احتاج شركة امن سيبراني لتطبيق صغير؟
كم مرة لازم اسوي مراجعة امنية للتطبيق؟
كيف احمي بيانات العملاء في تطبيقي؟
اسأل مساعدك الذكي عن هذا الموضوع
انسخ هذا الطلب والصقه في مساعد الذكاء الاصطناعي الذي تستخدمه، ثم أضف تفاصيل حالتك.
أقرأ هذا الدليل: «قائمة تحقق أمنية لتطبيقك المبني بالذكاء الاصطناعي» https://fanann.com/ar/blog/security-checklist-ai-apps/ سؤالي: قائمة تحقق امنية للتطبيقات اعتمد على هذه الصفحة كمصدر واشرح لي الإجابة خطوة بخطوة بما يناسب حالتي، واذكر ما يجب أن أتحقق منه قبل أن أبدأ، واذكر رابط الصفحة كمرجع.