معماری اعتماد صفر

خلاصه ای کوتاه

Zero Trust (ZT) یک مدل امنیتی است که در آن محیط شبکه دیگر به عنوان یک منطقه قابل اعتماد در نظر گرفته نمی شود. هر درخواست (کاربر → برنامه، سرویس → سرویس، دستگاه → شبکه) به صراحت تأیید، مجاز و رمزگذاری شده است، با توجه به سیگنال های متنی (هویت، وضعیت دستگاه، مکان، خطر، رفتار). هدف به حداقل رساندن شعاع انفجار، کاهش خطر حرکت جانبی و ساده سازی انطباق است.

اصول اعتماد صفر

1. بدون اعتماد صریح - اعتماد از شبکه/VPN/ASN به ارث برده نمی شود.
2. دسترسی حداقل لازم است: سیاست «ارائه تنها آنچه در حال حاضر مورد نیاز است».
3. تأیید مداوم: جلسات و نشانه ها به طور مرتب برای ریسک و زمینه ارزیابی می شوند.
4. فرض سازش: تقسیم بندی، مشاهده پذیری، مهار سریع و چرخش های کلیدی.
5. رمزگذاری در همه جا: TLS 1. 2+/1. 3 و mTLS در داخل برنامه های داده، DNS محافظت شده، اسرار در KMS/HSM.

چشم انداز هدف و دامنه های کنترل

هویت: انسان (IdP: SSO، MFA، passkeys/FIDO2)، ماشین آلات (SPIFFE/SVID، x509/mTLS).
دستگاه: انطباق با سیاست های (MDM/EDR, دیسک رمزگذاری شده, تکه, فرار از زندان/ریشه - ممنوع).
شبکه: microsegmentation L3/L7، دروازه ZTNA/SDP، مش سرویس (Envoy/Istio/Linkerd).
برنامه های کاربردی/API ها: mTLS، OIDC/JWT، امضاهای درخواست (HMAC)، محدودیت نرخ، DLP/ماسک.
داده ها: طبقه بندی (عمومی/محرمانه/محدود)، نشانه گذاری/رمزگذاری در سطح زمینه.
قابلیت مشاهده: گزارش های تأیید اعتبار/مجوز متمرکز، تجزیه و تحلیل رفتاری، SLO/SLA.

معماری مرجع (توسط هواپیما شکسته)

کنترل هواپیما: IdP/CIAM، PDP/PEP (OPA/Envoy)، کاتالوگ سیاست، PKI/CA، صلاحیت دستگاه.
Data Plane: دسترسی پروکسی (ZTNA)، پروکسی جانبی (Envoy) برای سیاست mTLS و L7، دروازه های سرویس GW/API ها.
مدیریت هواپیما: کاتالوگ خدمات، CMDB، CI/CD، مدیریت مخفی (Vault/KMS)، حسابرسی متمرکز.

درخواست جریان (کاربر → برنامه):

1. شناسایی (SSO + MFA مقاوم در برابر فیشینگ) → 2) ارزیابی دستگاه (وضعیت MDM) → 3) پروکسی ZTNA mTLS را برای کاربرد → 4) PDP (سیاست ها) تصمیم می گیرد بر اساس ویژگی ها (ABAC/RBAC) → 5) ارزیابی مجدد ریسک مداوم (زمان، جغرافیایی، ناهنجاری ها).

هویت و مجوز

IdP/SSO: OIDC/SAML، MFA پیش فرض، ترجیحا FIDO2 (کلید عبور).
RBAC/ABAC: نقش ها + ویژگی های زمینه (وضعیت دستگاه، بخش، مشخصات ریسک).
دسترسی فقط در زمان (JIT): امتیازات موقت با لغو خودکار ؛ شکستن شیشه - به شدت تنظیم شده است.
mTLS برای ماشین آلات: SPIFFE/SVID یا PKI داخلی با گواهینامه های کوتاه مدت ؛ انتشار چرخشی اتوماتیک.

دستگاه ها و زمینه

وضعیت: نسخه OS/EDR، شامل رمزگذاری دیسک، فایروال ؛ غیر سازگار → حداقل دسترسی یا بلوک.
گواهی: هویت دستگاه + گواهی های امضا شده (MDM/Endpoint).
محدودیت های شبکه: مسدود کردن تونل های شخص ثالث، DNS اجباری شرکت ها، محافظت در برابر نشت DNS/WebRTC.

شبکه و میکروسگمنتیشن

از بین بردن VLAN های «مسطح»: در عوض، بخش/VRF و سیاست در L7.
سرویس مش: پروکسی های جانبی ارائه mTLS، مجوز سیاست (OPA/EnvoyFilter)، تله متری.
ZTNA/SDP: دسترسی به یک برنامه خاص، نه به شبکه ؛ kliyent↔broker↔app، سیاست در PDP.
دسترسی از راه دور: جایگزینی VPN «ضخیم» با یک پروکسی برنامه ؛ تونل های Fallback به مسیرها/بنادر محدود می شوند.

سیاست ها و موتور راه حل

PDP/PEP: نقطه تصمیم گیری سیاست (OPA/Styra، سرو и пр.) + نقطه اجرای سیاست (نماینده/Istio/دروازه).
مدل سیاست: قوانین اعلانی (Rego/Cedar)، ویژگی های استاتیک و متنی، ارزیابی ریسک.

مثال رگو (ساده شده):

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

راه حل های ردیابی: ورود «ورودی »/« نتیجه »/« توضیح» برای حسابرسی.

رمزگذاری پیش فرض و اعتماد

TLS 1. 2+/1. 3 در همه جا، مجموعه های رمزنگاری دقیق، HSTS، مهر و موم OCSP.
mTLS در داخل: servis↔servis فقط با گواهینامه های متقابل ؛ کلید های کوتاه مدت (ساعت/روز).
اسرار: KMS/HSM، اسرار پویا (خرک)، TTL کوتاه، حداقل امتیاز برای برنامه های کاربردی.

💡 > مشاهده، SLO و پاسخ

معیارها (حداقل مجموعه):

احراز هویت و موفقیت مجوز (٪)، زمان تصمیم گیری P95 PDP، P95 TLS-handshake.
درصد درخواست های مسدود شده توسط سیاست (ناهنجاری/نادرست).
در دسترس بودن کارگزاران ZTNA و کنترل کننده مش.
نسبت دستگاه های سازگار و روند.

SLO (نمونه):

در دسترس بودن ZTNA ≥ 99. 95٪ در ماه ؛ p95 authZ تصمیم گیری ≤ 50 мс"
درصد درخواستها با mTLS 99 ≥. 9%».
نه بیشتر از 0. 1٪ شکست دسترسی نادرست/روز"

هشدار: انفجار انکار، تخریب دست دادن p95، زنجیره های نامعتبر، کاهش نسبت دستگاه های سازگار، ناهنجاری های جغرافیایی/ASN.

حرکت از محیط به صفر اعتماد: نقشه راه

1. موجودی: برنامه های کاربردی، جریان داده ها، مصرف کنندگان، حساسیت (PII/کارت/پرداخت).

2. هویت و MFA: SSO و MFA مقاوم در برابر فیشینگ برای همه

3. زمینه دستگاه: MDM/EDR، سیاست های اساسی انطباق، بلوک غیر سازگار.
4. Microsegmentation مسیرهای اولویت: پرداخت، دفتر پشت، مدیر ؛ mTLS را وارد کنید.
5. ZTNA برای دسترسی کاربر: انتشار برنامه ها از طریق یک پروکسی، «VPN گسترده» را حذف کنید.
6. سیاست های ABAC: PDP متمرکز، قوانین اعلام شده، حسابرسی.
7. فرمت مش سرویس: S2S mTLS، سیاست L7، تله متری.
8. اتوماسیون و SLO: هشدار، آزمایش سیاست (CI سیاسی)، روزهای بازی "اگر IdP در دسترس نباشد چه می شود ؟ ».

ویژگی برای iGaming/fintech

تقسیم بندی دامنه سفت و سخت: پرداخت/PII/ضد تقلب/محتوا - محیط و سیاست های جداگانه ؛ دسترسی فقط از طریق ZTNA

تعامل با PSP/بانک ها: اجازه لیست توسط ASN/محدوده، mTLS به PSP-endpoints، زمان به کیف پول نظارت و authZ شکست.
ارائه دهندگان محتوا و شرکا: دسترسی موقت JIT API، نشانه های TTL کوتاه، ممیزی ادغام.
انطباق: PCI DSS/GDPR - به حداقل رساندن داده ها، DLP/pseudonymization، ورود به سیستم دسترسی به جداول حساس.

امنیت زنجیره تامین و CI/CD

امضاهای مصنوعی (SLSA/Provenance): امضاهای کانتینری (cosign)، سیاست پذیرش در K8s.
SBOM و آسیب پذیری ها: نسل SBOM (CycloneDX)، دروازه سیاست در خط لوله.

اسرار در CI: فدراسیون OIDC به ابر KMS ؛ ممنوعیت استفاده از کلیدهای استاتیک

چرخش: مکرر، اتوماتیک ؛ لغو اجباری در حوادث

اشکالات رایج و ضد الگوهای

«ZTNA = VPN جدید»: انتشار یک شبکه به جای برنامه ها Zero Trust نیست.
بدون بررسی دستگاه: MFA است، اما دستگاه های آلوده/ریشه دسترسی پیدا می کنند.
تنها کاربر فوق العاده: عدم JIT و نقش های جداگانه.
سیاست ها در کد خدمات: حسابرسی مرکزی/به روز رسانی امکان پذیر نیست.
mTLS جزئی: بخشی از خدمات بدون mTLS → یک حلقه «نشت».
صفر UX: درخواست MFA بیش از حد، بدون SSO ؛ نتیجه - مقاومت در برابر دستورات.

راهنمای کوچک برای انتخاب فن آوری

دسترسی کاربر: کارگزار ZTNA/SDP + IdP (OIDC، FIDO2 MFA).
امنیت در سرویس: سرویس مش (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID یا Vault PKI با TTL کوتاه.
سیاستمداران: OPA/رگو یا سرو ؛ فروشگاه در Git، بررسی در CI (سیاست آزمون).
سیاههها و تله متری: OpenTelemetry → تجزیه و تحلیل متمرکز، تشخیص ناهنجاری.

تنظیمات نمونه (قطعات)

نماینده (TLS متقابل بین خدمات)

yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

OPA/Rego: دسترسی به گزارش ها فقط از «امور مالی»، از دستگاه های سازگار، در طول ساعات کاری

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

چک لیست پیاده سازی صفر اعتماد

1. فعال کردن SSO و FIDO2 MFA برای همه کاربران و مدیران.
2. وضعیت دستگاه (MDM/EDR) را با قفل غیر سازگار وارد کنید.
3. دسترسی کاربر را به ZTNA (هر برنامه) انتقال دهید، VPN را فقط برای کانال های S2S باریک بگذارید.
4. در داخل - mTLS به طور پیش فرض + گواهینامه های کوتاه مدت.
5. سیاست های متمرکز (PDP/OPA)، فروشگاه در Git، تست در CI.
6. دامنه های حساس بخش (پرداخت/PII/دفتر پشتی) و محدود کردن شرق به غرب.
7. تنظیم تله متری، SLO و هشدار در auth/authZ، mTLS به اشتراک گذاری، سیگنال های وضعیت.
8. انجام «روزهای بازی» (شکست IdP، نشت کلید، افت کارگزار) و رفع SOPs/rollbacks.

سوالات متداول

آیا Zero Trust به طور کامل جایگزین VPN می شود ؟

برای دسترسی کاربر - بله، به نفع ZTNA. برای تنه های S2S، VPN/IPsec ممکن است باقی بماند، اما با mTLS و سیاست های سختگیرانه.

آیا ZT می تواند UX را بدتر کند ؟

اگر بی فکرانه با SSO + FIDO2، MFA تطبیقی و دسترسی به هر برنامه، UX به طور معمول بهبود می یابد.

آیا لازم است یک سرویس مش را معرفی کنیم ؟

نه همیشه. اما برای یک محیط میکروسرویس بزرگ، مش به طور اساسی mTLS/policy/telemetry را ساده می کند.

مجموع

Zero Trust یک محصول نیست بلکه یک رشته معماری است: هویت به عنوان یک محیط جدید، زمینه دستگاه، دسترسی به برنامه (ZTNA)، microsegmentation و mTLS در همه جا، سیاست های متمرکز و قابلیت اطمینان قابل اندازه گیری است. با پیروی از نقشه راه و چک لیست، سطح حمله را کاهش می دهید، سرعت حسابرسی را افزایش می دهید و امنیت پایدار را بدون «اعتماد پیش فرض» به دست می آورید.