ارسم المسار، وحدّد حدود الثقة، واسأل ما الذي قد يسوء، ثم حوّل أهم النتائج إلى مهام. ساعة واحدة تكفي لمحاولة أولى مفيدة.
يستطيع فريق صغير إجراء [نمذجة تهديدات](/glossary/threat-modelling) مفيدة في نحو ساعة: ارسم كيف تتحرك البيانات في مسار أساسي واحد، وحدّد أين تتغير الثقة، واسأل ما الذي قد يسوء عند كل نقطة، ثم رتّب النتائج واكتب أهمها مهامَّ في الأداة التي تعملون بها. لا تحتاج في المرة الأولى إلى متخصص أمن ولا إلى برنامج خاص، بل إلى من يعرف المنتج، ولوحة بيضاء، ونطاق واضح.
يعرض هذا المقال الخطوات، وقائمة أسئلة تعيد استخدامها، ومثالًا تطبيقيًا. والمثال افتراضي ولا يصف مشروعًا حقيقيًا.
ابدأ بالأسئلة الأربعة
تعود معظم طرق نمذجة التهديدات إلى أربعة أسئلة شاع استخدامها في مجتمع الأمن بفضل كتابات آدم شوستاك (Adam Shostack). اجعلها جدول أعمال الساعة.
أبقِ المجموعة صغيرة: مطوّر يعرف الشيفرة، وشخص يملك قرارات المنتج، ومصمم أو مختبِر إن وُجد. يكفي ثلاثة إلى خمسة أشخاص. اختر مسارًا واحدًا، كالتسجيل والدفع، بدل المنتج كله.
ارسم مخطط تدفق بيانات يُقرأ في دقيقة
يستخدم مخطط تدفق البيانات أربعة أشكال. **الأطراف الخارجية** أشخاص أو أنظمة خارج سيطرتك، كالعميل أو مزوّد الدفع. **العمليات** أجزاء نظامك التي تؤدي عملًا، كتطبيق الويب أو واجهة API أو مهمة في الخلفية. **مخازن البيانات** هي قواعد البيانات وتخزين الملفات والذاكرة المؤقتة. **تدفقات البيانات** أسهم تبيّن أي بيانات تنتقل إلى أين.
اكتب على كل سهم ما يمر عبره (كلمة مرور، رمز بطاقة، سجل حجز) وكيف يمر (HTTPS، طابور رسائل، رفع ملف). فإن احتاج الرسم إلى أكثر من اثني عشر شكلًا تقريبًا فقد اخترت أكثر مما يلزم. ارسمه على لوحة بيضاء أو لوحة مشتركة مثل FigJam، ثم صوّره أو صدّره ليبقى بجانب الشيفرة.
تسلك معظم الهجمات تدفقًا من تدفقات البيانات، فالتدفق الذي نسيت رسمه تدفق لم يدافع عنه أحد.
حدّد حدود الثقة
حدّ الثقة خط يتغير عنده مستوى الثقة. ارسمه خطًا متقطعًا يقطع المخطط. وكل ما يعبره يستحق أكبر انتباه، لأنه المكان الذي يجب أن تتحقق فيه من هوية الطالب ومن سلامة البيانات.
- من الإنترنت إلى خادمك: كل ما يرسله المتصفح أو التطبيق مدخل لا تتحكم فيه.
- من نظامك إلى طرف ثالث، كخدمة الدفع أو البريد أو التحليلات.
- من دور مستخدم إلى آخر: من العميل إلى الموظف، ومن الموظف إلى المسؤول.
- من بيانات عميل إلى بيانات عميل آخر، في أي منتج يخدم أكثر من جهة.
- من شيفرتك إلى مسار البناء والنشر وحسابك السحابي.
كثيرًا ما تنسى الفرق لوحة الإدارة، والمهام الخلفية، وأدوات الدعم، ومسار النشر. وهي غالبًا أضعف الأجزاء حماية وأقواها صلاحية، فضعها على المخطط.
استخدم STRIDE قائمة أسئلة لا استمارة
STRIDE اختصار لستة أنواع من التهديدات. اطرح الأسئلة على كل عملية وكل مخزن بيانات وكل تدفق يعبر حدًّا، ودوّن كل ما يثير القلق. وتجاوز السؤال الذي لا ينطبق بوضوح.
| التهديد | ما الذي يكسره | السؤال |
|---|---|---|
| انتحال الهوية (Spoofing) | إثبات الهوية | هل يستطيع أحد أن ينتحل صفة مستخدم أو خدمة أو مسؤول؟ |
| العبث بالبيانات (Tampering) | سلامة البيانات | هل يستطيع أحد تغيير البيانات أثناء النقل أو التخزين أو داخل الطلب؟ |
| إنكار الفعل (Repudiation) | المساءلة | هل يستطيع أحد إنكار ما فعله لأننا لم نسجّله؟ |
| تسريب المعلومات (Information disclosure) | السرية | هل يستطيع أحد قراءة بيانات لا يحق له رؤيتها؟ |
| تعطيل الخدمة (Denial of service) | التوافر | هل يستطيع أحد أن يجعل الخدمة بطيئة أو ممتلئة أو متوقفة؟ |
| رفع الصلاحيات (Elevation of privilege) | التفويض | هل يستطيع أحد أن يفعل ما لا يسمح به دوره؟ |
STRIDE قائمة أسئلة وليست حصرًا. فإن لم يناسب قلقٌ ما أي حرف منها فدوّنه على أي حال، ثم قارن النتائج بقائمة [OWASP Top 10](/glossary/owasp-top-10) للثغرات الشائعة في الويب.
رتّب ما وجدته
توقّع قائمة من عشر إلى ثلاثين نتيجة. لن تتمكن من إصلاحها كلها، فرتّبها. يكفي مقياس من ثلاثة مستويات: قدّر لكل نتيجة حجم الضرر (منخفض أو متوسط أو مرتفع) وسهولة الاستغلال (صعب أو متوسط أو سهل). وما كان ضرره مرتفعًا واستغلاله سهلًا يأتي أولًا.
ثم اختر استجابة واحدة لكل نتيجة: **أزل** الخطر بتغيير التصميم، أو **خفّفه** بضابط أمني، أو **انقله** (كأن يحتفظ مزوّد الدفع ببيانات البطاقة)، أو **اقبله**. والخطر المقبول يحتاج إلى اسم بجانبه وموعد لإعادة النظر فيه، وإلا صار خطرًا نسيته.
مثال تطبيقي (افتراضي)
تخيّل فريقًا صغيرًا يبني تطبيقًا لحجز المواعيد. يسجّل العميل دخوله برابط يصله بالبريد، ويحجز موعدًا، ويدفع عبر مزوّد دفع خارجي. ويدير الموظفون الحجوزات من لوحة إدارة. هذا مثال مختلق للتوضيح، وليس مشروعًا حقيقيًا.
يضم المخطط عميلًا، وتطبيق ويب، وواجهة API، وقاعدة بيانات، ومزوّد دفع، ولوحة إدارة للموظفين. ويرسم الفريق ثلاثة حدود ثقة: من الإنترنت إلى API، ومن API إلى مزوّد الدفع، ومن العميل إلى الموظف. وعند المرور على STRIDE تظهر هذه النتائج:
- **تسريب المعلومات:** صفحات الحجز تستخدم أرقامًا متسلسلة في العنوان، فيستطيع عميل مسجّل الدخول تغيير الرقم وقراءة حجز غيره. وهذا من نوع ضعف التحكم في الوصول (Broken Access Control) المدرج في OWASP Top 10.
- **العبث بالبيانات:** يتضمن طلب الدفع السعر، والخادم يثق به، فقد يعدّله العميل قبل الإرسال.
- **رفع الصلاحيات:** لوحة الإدارة متاحة من الإنترنت العام وتعتمد رابط الدخول نفسه الذي يستخدمه العملاء.
- **إنكار الفعل:** يستطيع الموظفون إجراء استرداد للمبالغ، ولا شيء يسجّل من فعل ذلك.
- **انتحال الهوية:** رابط الدخول لا تنتهي صلاحيته ويمكن استخدامه أكثر من مرة.
- **تعطيل الخدمة:** نقطة الحجز تقبل عددًا غير محدود من الطلبات، فيستطيع سكربت واحد حجز كل المواعيد.
الترتيب بحسب الضرر وسهولة الاستغلال يضع ثلاث نتائج في المقدمة: التحقق من ملكية الحجز، والسعر الذي يرسله العميل، ولوحة الإدارة المفتوحة. والاستجابات محددة: تحقق من ملكية الحجز على الخادم، واحسب السعر على الخادم، وضع لوحة الإدارة خلف [المصادقة متعددة العوامل](/glossary/multi-factor-authentication) ودور مستقل. وتنتقل البقية إلى قائمة الأعمال.
حوّل النتائج إلى مهام
لا تستحق نمذجة التهديدات ساعتها إلا إذا غيّرت الخطة. اكتب كل قرار مهمةً عادية في الأداة التي يستخدمها الفريق، بجانب مهام الميزات، من خمسة أجزاء:
- عنوان من جملة واحدة يسمّي الخطر: يستطيع العملاء قراءة حجوزات غيرهم.
- مكانه: المسار والمكوّن وحدّ الثقة.
- الإصلاح، مكتوبًا بحيث يبدأ المطوّر دون أن يسأل.
- مسؤول عن التنفيذ.
- شرط الإنجاز، ويُفضَّل أن يكون اختبارًا: طلب حجز مستخدم آخر يُرفض.
احفظ المخطط وقائمة المخاطر المقبولة في المستودع، وراجع المخاطر المقبولة في كل مرة تعيد فيها النمذجة.
متى تعيد النمذجة
تعامل مع النموذج على أنه رسم حي لا وثيقة تنتهي. وأعد الجزء المعني منه عندما يتغير ما يغيّر الصورة:
- خدمة طرف ثالث جديدة أو تكامل جديد.
- دور مستخدم جديد أو طريقة دخول جديدة.
- نوع جديد من البيانات، خصوصًا المدفوعات أو الصحة أو الهوية أو بيانات الأطفال.
- مدخل جديد، كواجهة API عامة أو تطبيق جوال.
- حادثة أمنية، أو حادثة كادت تقع.
للتغييرات الصغيرة تكفي نظرة من عشرين دقيقة إلى المخطط أثناء مراجعة التصميم. نبدأ في أسفاليا كل مشروع بمراجعة للتهديدات، ويتعلم كل أعضاء الفريق نمذجة التهديدات؛ وتصف صفحة [خدمة نمذجة التهديدات](/services/cybersecurity/threat-modelling) كيف يبدو ذلك. وللصورة الأوسع اقرأ [دليل تطوير التطبيقات الآمنة](/guides/secure-app-development).