مدلسازی تهدید چیست؟
مدلسازی تهدید (Threat Modeling) فعالیتی است که تیم، پیش از ساخت یا هنگام تغییر یک سامانه، نظام‌مند می‌پرسد چه چیزی می‌تواند اشتباه پیش برود و چه کنترلی باید در طراحی گنجانده شود. چارچوب رایجش چهار پرسش است:
- چه چیزی می‌سازیم؟ — مرز سامانه، مؤلفه‌ها، داده‌ها و بازیگران.
- چه چیزی می‌تواند اشتباه پیش برود؟ — شناسایی تهدید با روشی ساختاریافته مثل STRIDE.
- چه می‌کنیم؟ — تصمیم برای هر تهدید: کنترل، پذیرش، انتقال یا حذف قابلیت.
- خوب انجامش دادیم؟ — بازبینی پس از پیاده‌سازی.
تفاوت کلیدی با سایر فعالیت‌های امنیتی این است که مدلسازی تهدید به کد نگاه نمی‌کند، به تصمیم نگاه میکند. «چرا کاربر عادی اصلاً باید بتواند شناسه‌ی فاکتور را در آدرس بفرستد؟» یک سؤال طراحی است، نه باگ پیاده‌سازی — و اگر پاسخ درست در طراحی نباشد، دقت در کدنویسی آن را جبران نمی‌کند.
STRIDE — رایج‌ترین روش شناسایی تهدید
STRIDE شش دستهی تهدید را نام می‌برد و برای هر مؤلفه پرسیده میشود. ارزشش در کامل بودن نیست، در یادآوری منظم است: تیم به‌جای «فکر کردن به حملات»، شش پرسش مشخص را روی هر عنصر اجرا میکند.
| حرف | تهدید | ویژگی نقض‌شده | نمونه‌ی وب |
|---|---|---|---|
| S | جعل هویت (Spoofing) | احراز هویت | پذیرش توکنی که امضایش راستی‌آزمایی نشده — نک. JWT |
| T | دستکاری (Tampering) | یکپارچگی | تغییر قیمت در بدنه‌ی درخواست پرداخت |
| R | انکار (Repudiation) | انکارناپذیری | نبود رد ممیزی برای عملیات مالی |
| I | افشای اطلاعات | محرمانگی | پاسخ API فیلدهایی را برمی‌گرداند که UI نمایش نمی‌دهد |
| D | اختلال سرویس | دسترس‌پذیری | اندپوینت گزارش‌گیری بدون سقف پارامتر |
| E | ارتقای دسترسی | مجوزدهی | پذیرش فیلد role در بدنه‌ی به‌روزرسانی پروفایل |
در عمل پرکاربردترین ستون‌ها E و I هستند — هم‌خوان با دادهی OWASP که کنترل دسترسی شکسته را در رتبه‌ی یک نگه داشته است.
نمودار جریان داده و درخت حمله
نمودار جریان داده (DFD) زبان مشترک جلسه است و لازم نیست زیبا باشد: موجودیت بیرونی، فرایند، مخزن داده و جریان داده. عنصر پنجم مهم‌ترین است — مرز اعتماد، خطی که نشان می‌دهد داده از یک ناحیه‌ی اعتماد به ناحیه‌ی دیگر می‌رود.
قاعده‌ی طلایی: تهدیدها روی مرزهای اعتماد متمرکزند. هر جا جریانی از مرزی عبور میکند باید احراز هویت، مجوزدهی، اعتبارسنجی و ثبت رخداد باشد. بیشتر یافتههای جدی تست نفوذ در نگاه به عقب جریانی‌اند که از مرزی عبور کرده بی‌آنکه کسی بداند مرزی وجود دارد — مثل «سرویس داخلی است پس احراز هویت لازم ندارد» که مسیر SSRF را باز می‌گذارد.
درخت حمله مکمل و از بالا به پایین است: در ریشه هدف مهاجم نوشته میشود («خواندن فاکتور مشتری دیگر») و شاخه‌ها راه‌های رسیدن به آن را باز می‌کنند — IDOR روی اندپوینت فاکتور، دسترسی به فایل ذخیره‌شده، یا گرفتن نشست از راه XSS. بهترین بازده را روی یک دارایی بحرانی دارد.
نسبت مدلسازی تهدید با تست نفوذ
| مدلسازی تهدید | تست نفوذ | |
|---|---|---|
| زمان | پیش از کدنویسی یا هنگام تغییر طراحی | روی سامانهی ساخته‌شده |
| ورودی | معماری، مستندات، دانش تیم | سامانهی در حال اجرا |
| می‌یابد | کنترلهای غایب و فرض‌های نادرست | کنترلهای ناقص یا قابل دور زدن |
| هزینه‌ی رفع | پایین — هنوز چیزی ساخته نشده | بالاتر — بازکاری و انتشار دوباره |
| خروجی | فهرست تهدید با تصمیم و مسئول | گزارش یافته با شواهد و شدت |
در استاندارد PTES هم «مدلسازی تهدید» یکی از هفت فاز اجرای تست است — آنجا به معنای مدلسازی مهاجم و دارایی پیش از شروع آزمون. رابطه‌ی درست این است: مدل تهدید ورودی خوبی برای تعیین دامنهی تست می‌دهد و متدولوژی تست نفوذ بازخوردی می‌دهد که مدل بعدی را دقیقتر میکند.
اجرای عملی: چه زمانی، چه کسانی، خروجی چیست
چه زمانی؟ نه در هر اسپرینت و نه یکبار برای همیشه؛ نقاط طبیعی: قابلیت جدیدی که با پول، هویت یا دادهی حساس سروکار دارد، یکپارچگی با سرویس بیرونی، تغییر مدل نقشها، و مهاجرت معماری.
چه کسانی؟ جلسهی مؤثر ۴ تا ۸ نفره و ۶۰ تا ۹۰ دقیقه است: معمار یا توسعهدهندهی ارشد، مالک محصول، یک نفر از عملیات و یک تسهیلگر با دانش امنیت. اما مدلسازی تهدید وظیفهی تیم امنیت نیست؛ اگر تیم توسعه نقش فعال نداشته باشد، خروجی سندی میشود که کسی نمی‌خواندش.
خروجی چه شکلی است؟ نه گزارش صد صفحه‌ای؛ یک نمودار ساده به‌همراه فهرستی از تهدیدها که هر ردیفش تصمیم، مسئول و وضعیت دارد و در همان ابزار پیگیری کار تیم ثبت میشود:
Element : POST /api/v1/invoices (crosses trust boundary)
STRIDE : E - Elevation of Privilege
Threat : user reads another tenant's invoice
Control : scope query by session tenant, enforced in data layer
Owner : team-billing Status: planned Ref: SEC-114بزرگ‌ترین مانع مهارت نیست، عادت است؛ تیمی که یکبار جلسهی درست را تجربه کند، دفعه‌ی بعد خودش شروع میکند. آموزش عملی همین جلسه روی سامانهی واقعی تیم، بخشی از دوره‌ی سازمانی توسعه‌ی امن است.
نگاشت به A06:2025 و باورهای غلط
مدلسازی تهدید مستقیماً به A06:2025 طراحی ناامن (Insecure Design) نگاشت میشود، و جمله‌ی کلیدی خودِ OWASP بهترین توصیف موضوع است: «یک طراحی امن هم می‌تواند نقص پیاده‌سازی داشته باشد که به آسیب‌پذیری منجر شود؛ اما یک طراحی ناامن با پیاده‌سازی بی‌نقص هم رفع نمی‌شود.»
OWASP سه ستون برای این دسته تعریف میکند: مدیریت الزامات و منابع، طراحی امن (که مدلسازی تهدید در آن قرار دارد)، و چرخه‌ی عمر توسعه‌ی امن. راهکارهایش هم همین‌هاست: گنجاندن مدلسازی تهدید در پالایش طراحی، کتابخانه‌ای از الگوهای امن، آزمون برای سناریوهای سوءاستفاده، و جداسازی لایه‌ها و مستأجران در طراحی. شناسه‌های CWE پرکاربرد: CWE-501 (نقض مرز اعتماد)، CWE-269 و CWE-434.
«ما تست نفوذ می‌دهیم، پس نیازی به مدلسازی تهدید نداریم.» این دو یک چیز را نمی‌سنجند. تست نفوذ کنترلهای موجود را میآزماید؛ اگر کنترلی اصلاً طراحی نشده باشد، تستر نبودش را گزارش میکند اما در بدترین زمان ممکن — پس از ساخت و اغلب پس از انتشار. باور غلط قرینه هم هست: «مدلسازی تهدید کردیم پس امنیم.» مدل تهدید فرض‌ها را می‌سنجد، نه کد را؛ راستی‌آزمایی پیاده‌سازی همچنان به بازبینی کد و تست نفوذ نیاز دارد.
پرسش‌های متداول
مدلسازی تهدید چه زمانی باید انجام شود؟
در نقاط تصمیم طراحی: قابلیت جدیدی که با پول، هویت یا دادهی حساس سروکار دارد، یکپارچگی با سرویس بیرونی، تغییر مدل نقشها و احراز هویت، و مهاجرت معماری. انجام آن در هر اسپرینت لازم نیست و یکبار برای همیشه هم کافی نیست؛ مدل باید با هر تغییر معنادار معماری بازبینی شود.
چه کسانی باید در جلسهی مدلسازی تهدید حاضر باشند؟
چهار تا هشت نفر: معمار یا توسعهدهندهی ارشد، مالک محصول، یک نفر از عملیات یا زیرساخت، و یک تسهیلگر با دانش امنیت. نکتهی مهم این است که مدلسازی تهدید وظیفهی تیم امنیت نیست؛ اگر تیم توسعه نقش فعال نداشته باشد، خروجی به سندی تبدیل میشود که کسی نمیخواند.
تفاوت STRIDE و درخت حمله چیست؟
STRIDE از پایین به بالا کار میکند: برای هر عنصر سامانه شش دستهی تهدید را بررسی میکنید و پوشش نسبتاً کاملی بهدست میآورید. درخت حمله از بالا به پایین است: یک هدف مهاجم را در ریشه میگذارید و مسیرهای رسیدن به آن را باز میکنید. STRIDE برای پوشش سیستماتیک بهتر است و درخت حمله برای تمرکز عمیق روی یک دارایی بحرانی.
آیا مدلسازی تهدید جای تست نفوذ را میگیرد؟
خیر. مدلسازی تهدید کنترلهای غایب را پیش از ساخت پیدا میکند و تست نفوذ کنترلهای موجود اما ناقص را روی سامانهی واقعی میآزماید. این دو مکملاند: خروجی مدل تهدید به تعیین دامنهی تست کمک میکند و یافتههای تست، مدل تهدید بعدی را دقیقتر میکند.