قائمة تحقق أمنية للتطبيقات المبنية بالذكاء الاصطناعي: ما يجب فحصه قبل الإطلاق

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

منشئو التطبيقات بالذكاء الاصطناعي بارعون في جعل الميزات تعمل، لكنهم ليسوا حذرين تلقائيًا، لأن «الحذر» نادرًا ما يرد في الطلب. وأغلب المشكلات أدناه تنشأ من أشياء لم يطلبها أحد، لذا فإن الحل غالبًا هو أن تطلبها أنت.

كيف تستخدم هذه القائمة

اعمل عليها بالترتيب، ولكل بند افعل أمرين: اطلب من الذكاء الاصطناعي أن يتأكد من معالجته، واختبره بنفسك. فالذكاء الاصطناعي يستطيع كتابة فحص صلاحيات، لكن الاختبار وحده يخبرك أنه يعمل. والبنود مُعلَّمة كالتالي:

• يجب — افعله قبل أن يستخدم أي شخص آخر التطبيق.
• ينبغي — افعله قبل أن يكون لديك مستخدمون حقيقيون أو بيانات حقيقية.
• لاحقًا — يستحق الفعل مع نمو التطبيق.

إذا كان لديك ساعة واحدة فقط، فنفّذ كل بنود يجب.

1. المصادقة: من هذا؟

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

• يجب: كل صفحة تعرض بيانات خاصة تتطلب تسجيل الدخول. الاختبار: سجّل الخروج، ثم الصق رابط صفحة خاصة مباشرة في المتصفح.
• يجب: كل نقطة نهاية في الواجهة البرمجية خلف تلك الصفحات تتطلب تسجيل الدخول أيضًا، لا الصفحة وحدها. الاختبار: سجّل الخروج، وافتح تبويب الشبكة في أدوات المطور، وأعد طلبًا أرسله التطبيق وأنت مسجّل الدخول.
• يجب: كلمات المرور مخزنة بعد تجزئتها (hashing) باستخدام خوارزمية بطيئة لتجزئة كلمات المرور، لا نصًا عاديًا. توصي إرشادات OWASP لتخزين كلمات المرور بـArgon2id أولًا، مع scrypt أو bcrypt أو PBKDF2 بدائل. اسأل: «كيف تُخزَّن كلمات المرور؟»
• ينبغي: تنتهي صلاحية روابط إعادة تعيين كلمة المرور، ولا تعمل إلا مرة واحدة.
• ينبغي: ملفات تعريف الارتباط للجلسة معلّمة بـSecure وHttpOnly وSameSite، ويؤدي تسجيل الخروج إلى إنهاء الجلسة على الخادم.
• لاحقًا: وفّر المصادقة الثنائية، أو تسجيل الدخول عبر مزوّد يدعمها.

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

2. التفويض: ما المسموح لهم بفعله؟

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

• يجب: كل عملية قراءة أو تحديث أو حذف تتحقق على الخادم من أن السجل يخص المستخدم الحالي (أو فريقه).
• يجب: اختبر ذلك: أنشئ حسابين، A وB. كمستخدم A، افتح أحد سجلاته وانتبه إلى المعرّف في الرابط أو في طلب الشبكة. سجّل الدخول كمستخدم B واطلب المعرّف نفسه. يجب أن يحصل B على خطأ، لا على بيانات A.
• يجب: صفحات الإدارة ونقاط نهاية الإدارة في الواجهة البرمجية تتحقق من دور المستخدم على الخادم. إخفاء رابط الإدارة ليس حمايةً.
• يجب: لا يستطيع المستخدمون تغيير دورهم أو سعرهم أو رصيدهم أو حقول المالك بتعديل الطلب. الاختبار: في تبويب الشبكة، انظر إلى ما يرسله تحديث الملف الشخصي. إذا تضمّن حقولًا مثل role أو isAdmin، فاطلب من الذكاء الاصطناعي تجاهلها من جهة العميل.
• ينبغي: المعرّفات في الروابط يصعب تخمينها (معرّفات عشوائية بدلًا من 1 و2 و3). وهذا ليس بديلًا عن فحوص الصلاحيات، لكنه يحدّ من الضرر حين يغيب أحدها.

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

3. الوصول على مستوى الصف في قاعدة البيانات

«الوصول على مستوى الصف» يعني أن كل صف في الجدول (حجز واحد، أو فاتورة واحدة) لا يظهر إلا للمستخدمين الذين ينتمي إليهم. وهناك طريقتان شائعتان لفرضه:

أي من الطريقتين يمكن تنفيذه جيدًا. وما يهم:

• يجب: إذا كان المتصفح يتصل بقاعدة البيانات مباشرة (تسمح بعض منتجات قواعد البيانات المستضافة بذلك)، تكون قواعد الصفوف مفعّلة على كل جدول. وبدونها، يستطيع أي شخص يملك المفتاح العام قراءة الجدول كله.
• يجب: الاستعلامات تُرشَّح بالمستخدم الحالي أو الفريق، لا بمعرّف يرسله المتصفح.
• ينبغي: البيانات المشتركة (مشاريع الفريق) لها قاعدة واضحة لتحديد من ينتمي إلى الفريق، تُطبَّق في مكان واحد.

4. الأسرار ومفاتيح الواجهة البرمجية

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

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

بعض المفاتيح مصممة لتكون علنية، مثل مفتاح Stripe القابل للنشر (pk_…)، أو مفتاح خرائط مقيّد بنطاقك. والقاعدة تنطبق على المفاتيح التي تمنح قدرة، لا على كل نص يشبه المفتاح.

5. التحقق من المدخلات

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

• يجب: يتم التحقق على الخادم، لا في المتصفح وحده. فالفحوص في المتصفح للراحة، ويستطيع أي شخص تجاوزها.
• يجب: استعلامات قاعدة البيانات تستخدم معاملات (parameters)، لا نصوصًا مُلصقة من مدخلات المستخدم (وهذا يمنع حقن SQL). اطلب من الذكاء الاصطناعي التأكد من ذلك.
• يجب: النص الذي يدخله المستخدمون يُعرض كنص، لا يُنفَّذ كـHTML. الاختبار: اكتب <b>hello</b> كاسمك. يجب أن ترى الوسوم، لا نصًا عريضًا.
• ينبغي: ملفات الرفع تتحقق من النوع والحجم، ولا تُقدَّم الملفات المرفوعة من النطاق الرئيسي لتطبيقك بوصفها صفحات قابلة للتشغيل.
• ينبغي: الأخطاء التي تظهر للمستخدمين بسيطة («حدث خطأ ما»)، والتفاصيل تُسجَّل في سجلات الخادم فقط.
• ينبغي: الـwebhooks القادمة من خدمات مثل Stripe تتحقق من توقيع المزوّد قبل التصرف. اطّلع على ما هو الـwebhook.

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

6. حدود الطلبات وإساءة الاستخدام

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

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

7. المكتبات (Dependencies)

تُبنى التطبيقات من حزم مفتوحة المصدر، وأحيانًا تحمل الحزم ثغرات معروفة.

• ينبغي: اطلب من الذكاء الاصطناعي فحص الثغرات المعروفة (في مشاريع JavaScript، يُستخدم npm audit أو ما يعادله في مدير الحزم لديك)، وتحديث ما يتأثر منها.
• ينبغي: احذف الحزم التي لم يعد التطبيق يستخدمها.
• ينبغي: احذر من الحزم التي لدى عدد قليل جدًا من المستخدمين، أو التي تبدو أسماؤها أخطاء إملائية لحزم شائعة.
• لاحقًا: أعد الفحص كل شهر أو شهرين، أو فعّل التنبيهات الآلية إذا كانت شيفرتك على GitHub.

8. النسخ الاحتياطية والاستعادة

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

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

9. قبل الإطلاق

• يجب: يستخدم الموقع الحي HTTPS في كل مكان.
• يجب: تُزال البيانات التجريبية وحسابات الاختبار وصفحات التصحيح من مرحلة التطوير.
• ينبغي: توضح سياسة الخصوصية البيانات التي تجمعها ولماذا، وهي مطلوبة في كثير من الأماكن إذا جمعت بيانات شخصية. ولا تدّعِ شهادات (مثل SOC 2 أو HIPAA) لا تملكها.
• ينبغي: لديك طريقة يتواصل بها الناس معك بشأن الثغرات الأمنية، وتعرف كيف تعيد توليد كل مفتاح بسرعة.

لمراجعة أوسع قبل الإطلاق تتجاوز الأمن، اطّلع على كيف تنقل نموذجًا أوليًا بالذكاء الاصطناعي إلى الإنتاج.

متى تحتاج إلى مراجعة من مختص

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

الأمن عند البناء على Mythex

لا يتضمن Mythex لوحة فحص أمني، لذا فإن قائمة التحقق أعلاه هي العملية الواجب اتباعها. وبعض الأمور التي تساعد:

• أسرار المشروع. خزّن المفاتيح من خلال إعدادات المشروع ← الأسرار، أو عبر بطاقة الأسرار التي يعرضها الوكيل في المحادثة، حتى تبقى خارج شيفرتك ورسائلك. وبعد تغيير سر لتطبيق حي، أعد النشر.
• وضعا التخطيط والسؤال. اطلب من الوكيل مراجعة الصلاحيات دون تعديل: «في وضع Ask، اعرض كل مسار في الواجهة البرمجية وفحص الصلاحيات الذي يقوم به».
• الأمر /test يجعل الوكيل يتصفح المعاينة كمستخدم، وهو مفيد لاختبار الحسابين في القسم 2.
• نقاط الحفظ (Checkpoints) تتيح لك التراجع عن تغيير أفسد شيئًا.

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

الأسئلة