GH GambleHub

مدلسازی تهدید و کنترل ریسک

1) اصول

1. معماری اول ما با زمینه ها، مرزهای اعتماد و جریان داده ها شروع می کنیم.
2. ریسک ≈ احتمال × تاثیر ما می سنجیم نه احساس.
3. دفاع در عمق کنترل بر روی هر لایه: کد → پروتکل → پلت فرم → مردم.
4. تغییر به چپ/راست. دروازه های اولیه در نظارت بر روابط عمومی + و واکنش در تحریک.
5. حریم خصوصی از طریق طراحی ما نه تنها تهدیدات امنیتی بلکه خطرات حریم خصوصی را نیز شبیه سازی می کنیم.
6. خودکار در صورت امکان سیاست ها به عنوان کد، چک خودکار، «خطوط قرمز».


2) موجودی: دارایی ها، اشخاص، مرزهای اعتماد

دارایی ها: داده ها (PII، امور مالی، اسرار)، منابع محاسباتی، کلید ها، دسترسی ها، فرآیندهای تجاری.
موضوعات: کاربران، خدمات، مدیران، شرکا، ارائه دهندگان خارجی.
مرزهای اعتماد: کاربران ↔ جلو، جلو ↔ دروازه API، خدمات ↔ پایگاه داده ها/کش ها/صف ها، مناطق/ابرها.
سطح حمله: نقاط ورودی (API، webhooks، UI، شبکه ها، CI/CD، زنجیره تامین).

DFD (به عنوان مثال، پری دریایی):
mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end

3) چارچوب های تهدید

STRIDE (безопасность): کلاهبرداری، دستکاری، انکار، افشای اطلاعات، انکار سرویس، ارتقاء امتیاز.
LINDDUN (приватность): ارتباط، قابلیت شناسایی، عدم رد، تشخیص، افشا، ناآگاهی، عدم انطباق.

پاستا (فرآیند): از اهداف کسب و کار و بازیگران تهدید → جزئیات فنی → سناریوهای آزمون

جدول (قطعه، اجزای × STRIDE):
کامپوننتانجمن هاتی تیتحقیق و توسعهمن و تود) طراحی و ساختالکترونیکیکنترل کردن
دروازه APImTLS/OIDC, WAF, نرخ محدود, ممیزی, HSTS
کافکاACLs, رویدادهای امضا شده, سهمیه, DLQs
پست هاTLS، RLS، KMS، مهاجرت با اعتبار

4) ارزیابی ریسک

رتبه بندی ریسک DREAD/OWASP یا CVSS برای آسیب پذیری ها.
احتمال (L): انگیزه/توانایی مهاجم، پیچیدگی، قرار گرفتن در معرض سطح.
تاثیر (I): امور مالی، خطرات قانونی، خرابی، نشت PD.
ریسک (R = L × I) → اولویت بندی و tritment: اجتناب/کاهش/انتقال/پذیرش.

ماتریس (مثال):

Impact
Low Med High Critical
Lik Low  L  L  M   H
Med  L  M  H   H
High M  H  High  Crit

ثبت ریسک (حداقل فیلدها): 'id, scenario, STRIDE, asset, L, I, R, owners, controls, status, revision date'.


5) کنترل: جلوگیری/تشخیص/پاسخ

جلوگیری از:
  • تأیید اعتبار/مجوز: OIDC/OAuth2، PoLP، RBAC/ABAC، اعتبارات خدمات کوتاه مدت.
  • اسرار/کلید: KMS/HSM، چرخش، نمی دانم، رمزگذاری FPE/زمینه.
  • پروتکل های امنیتی: TLS1 2 +، mTLS، امضاهای webhook، idempotency و ضد پخش.
  • اعتبار سنجی/بهداشت: طرح ها (JSON Schema/Proto)، محدودیت ها، عادی سازی.
  • جداسازی: سیاست های شبکه، تقسیم بندی، sandbox، فضای نام، bulkheads.
تشخیص دادن:
  • گزارش های حسابرسی (غیر قابل تشخیص)، همبستگی در SIEM، هشدار به ناهنجاری ها.
  • نظارت بر امضا و یکپارچگی (صادرات هش های مصنوعی، گواهی).
  • Honeytokens/canaries برای تشخیص نشت اولیه کلیدی.
پاسخ:
  • Runbook IR: طبقه بندی، جداسازی، یادآوری کلید، هشدارها، پزشکی قانونی.
  • خودکار کشتن سوئیچ/ویژگی پرچم، «لیست سیاه» از نشانه.
  • اطلاعیه های کاربران/تنظیم کننده ها در مورد حوادث PD.

6) SDL و دروازه های امنیتی

در ایده/طراحی: مدل تهدید (RFC/ADR)، چک لیست کنترل.
در حال توسعه: SAST/secret-scan، اسکن وابستگی (SCA)، سیاست وابستگی.
در مونتاژ: SBOM، امضای مصنوعی، سیاست آسیب پذیری (آستانه CVSS).
در این زمینه: OPA/Kyverno - سیاست IaC/آشکار (securityContext، سیاست های شبکه، حمل و نقل مخفی).
در فروش: IDS/WAF، تشخیص ناهنجاری، چک قناری، امنیت هرج و مرج (به عنوان مثال، گواهی منقضی شده).

مثال گیت (Policy as Code, pseudo-Rego):
rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}

7) زنجیره تامین و اعتماد به مصنوعات

SBOM در هر تصویر/بسته ؛ به روز رسانی وابستگی - از طریق ربات/سیاست.
SLSA/منبع: مجامع تجدید پذیر، امضاها، گواهینامه ها.
ظروف: حداقل تصاویر، بدون ریشه، قابلیت رها کردن، FS فقط خواندنی.
اسکن IaC: Terraform/Helm - سیاست رمزگذاری، پورت های باز، قوانین شبکه.


8) حفظ حریم خصوصی و انطباق

LINDDUN-نقشه تهدیدات حریم خصوصی، به حداقل رساندن داده ها، pseudonymization/anonymization.
سیاست های نگهداری: TTL/retention، «حق حذف»، ممیزی دسترسی به PD.
محلی سازی: محدودیت های جغرافیایی، «داده ها در منطقه باقی می مانند».
شفافیت: پردازش، اطلاع رسانی و رضایت سیاهههای مربوط.


9) ابرها و محیط

Zero Trust: احراز هویت هر درخواست، mTLS/OPA بین سرویس ها.
تقسیم بندی: VPC/subnets/SG، نقاط پایانی خصوصی، کنترل خروج.
کلید/اسرار: KMS، چرخش، اعتبارات کوتاه در CI (فدراسیون OIDC).
رزرو/DR: پشتیبان گیری رمزگذاری شده، کلید به طور جداگانه، تمرینات بازیابی.


10) تیم های قرمز/بنفش و تمرینات روی میز

تیم قرمز: تست فرضیه تهدید، مهندسی اجتماعی، بهره برداری زنجیره ای.
تیم بنفش: اشکال زدایی مشترک از تشخیص/هشدار، بهبود playbooks IR.
Tabletop: اسکریپت «گواهی منقضی شده»، «کلید های نشت شده»، «سازش زنجیره تامین». "نتیجه کنترل ها و معیارهای به روز شده است.


11) معیارهای بلوغ و مدیریت

پوشش:٪ از خدمات با مدل تهدید فعلی و DFD.
ایمنی MTTD/MTTR، نسبت حوادث گرفتار شده توسط کنترل.
نرخ عبور سیاست در CI، زمان بستن آسیب پذیری ها با انتقاد.
حریم خصوصی:٪ از مجموعه داده ها با TTL/ILM، سهم دسترسی با توجیه.
ممیزی: منظم بودن بازنگری ثبت ریسک (سه ماهه).


12) الگوهای مصنوعی

12. کارت ریسک 1 (مثال)


Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High  Impact: High  Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts  Статус: Reduce (в работе)
Дата пересмотра: 2025-12-01

12. 2 چک لیست طراحی

دارایی ها و PII شناسایی شده ؟ مرزهای اعتماد مشخص شده است ؟

آیا حلقه های DFD/داده تشکیل شده و به ADRs نقشه برداری می شوند ؟

STRIDE/LINDDUN عبور هر فلش DFD ؟

ریسک ریسک انتخاب شده ؛ صاحبان/مهلت/وزارت دفاع ؟

سیاست ها به عنوان کد اضافه شده (دروازه OPA/Kyverno/CI) ؟

برنامه نظارت/هشدار و IR-runbook به روز شد ؟

حریم خصوصی: به حداقل رساندن، رمزگذاری، TTL/حفظ، محلی سازی ؟

12. 3 سیاست وب هک (شبه کد)

python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 200

13) ضد الگوهای

اسرار طولانی مدت در متغیرهای محیطی/repo

مدل تهدید «برای نمایش» بدون DFD/ناوردا.
«محیط فوق العاده» بدون تأیید اعتبار سرویس به سرویس داخلی.
سیاست های تعبیه شده به عنوان کد → کتابچه راهنمای کاربر «فراموش شده».
سیاهههای مربوط با PD بدون استتار و بدون احتباس/TTL.
نادیده گرفتن زنجیره تامین (بدون SBOM/امضا/اسکن).
قبول بدون مالک و تاریخ تجدید نظر.


14) ادغام در فرآیندها

RFC/ADR - هر راه حل معنی دار شامل بخش تهدید و کنترل است.
Docs-as-Code: مدل تهدید، DFD، ثبت ریسک در نسخه کنار کد.
دروازه های انتشار: هنگامی که سیاست های SAST/SCA/SBOM شکست می خورند یا کنترل های شدید از دست رفته، انتشار مسدود می شود.
آموزش: playbooks برای توسعه دهندگان (اسرار، امضا، PoLP)، tabletop معمولی.


نتیجه گیری

مدل سازی تهدید یک عمل مهندسی مدیریت ریسک است، نه یک سند یک بار. تعریف دارایی ها و مرزهای اعتماد، اعمال STRIDE/LINDDUN، اندازه گیری ریسک، ثبت نام آن و اجرای کنترل ها به عنوان کد با جاسازی آنها در CI/CD و عملیات. با معیارهای بلوغ و تجدید نظر منظم، شما ایمنی را به یک توانایی معماری قابل پیش بینی تبدیل می کنید - با قیمت قابل درک، اثر و سرعت.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.