Zero Trust چیست؟ معماری اعتماد صفر برای وب

Zero Trust به معنی «هر درخواست را با MFA آزاردهنده متوقف کن» یا خرید یک محصول ZTNA نیست. مسئله این است: دسترسی به یک Resource مشخص، در این Session، برای این User یا Workload، از این Device و Context، با چه سطح ریسکی مجاز است و تصمیم در کجا اجرا و ثبت می‌شود؟

برای اپلیکیشن وب، دیوار شبکه هنوز لازم است اما به‌تنهایی کافی نیست. حساب ادمین، API، CI/CD، Service account، Database و SaaS خارج از یک Perimeter واحد زندگی می‌کنند. معماری اعتماد صفر، اعتماد ضمنی براساس «داخل شبکه بودن» را حذف و آن را با Identity، Policy، least privilege، Enforcement و Telemetry جایگزین می‌کند. این راهنما Zero Trust را از شعار به نقشه اجرای قابل‌آزمون تبدیل می‌کند.

اگر این وضعیت را دارید	اولویت Zero Trust	شاهد عبور
پنل ادمین از اینترنت با Password باز است	Identity قوی، MFA مقاوم به Phishing، Policy و Recovery	تست Login، step‑up، revoke و break‑glass
VPN دسترسی Subnet گسترده می‌دهد	Resource-level access و Segment مرحله‌ای	کاربر فقط App مصوب را می‌بیند
Microserviceها با Secret بلندمدت حرف می‌زنند	Workload identity، Token کوتاه‌عمر و Policy	Rotation/revocation و unauthorized-call test
Log ورود دارید اما دلیل Allow/Deny مشخص نیست	Policy-decision telemetry و Correlation	Incident از Subject تا Resource بازسازی شود

Zero Trust چیست؟ تعریف دقیق NIST

NIST SP 800‑207 اعتماد صفر را مجموعه‌ای در حال تحول از الگوهای امنیتی می‌داند که تمرکز را از Perimeter ثابت شبکه به User، Asset و Resource منتقل می‌کند. به User یا Asset صرفاً براساس Location شبکه یا مالکیت سازمانی اعتماد ضمنی داده نمی‌شود؛ Authentication و Authorization پیش از برقراری Session با Resource انجام می‌شوند.

این تعریف دو اصلاح مهم دارد:

«Never trust» به معنی اعتماد صفر عددی نیست: سیستم با Signalهای ناقص، Risk و Policy تصمیم می‌گیرد؛
تمرکز روی Resource است: Website admin، API endpoint، Secret، Dataset یا Deployment action؛ نه صرفاً یک Subnet.

Zero Trust یک Architecture و Operating model است، نه Certification نهایی. ممکن است سازمان در Identity بالغ و در Device یا Data ابتدایی باشد.

هفت اصل NIST را برای وب چگونه ترجمه کنیم؟

اصل	ترجمه عملی برای اپلیکیشن وب	Evidence
همه Data source و Computing serviceها Resource هستند	Admin، API، DB، Object storage، Queue و CI/CD در Inventory	Resource catalog با Owner
Communication مستقل از Location امن است	TLS، Auth و Authorization حتی داخل VPC	Traffic policy و test
Access برای هر Session/Resource است	مجوز گسترده و دائمی به Scope محدود تبدیل شود	Token/session scope و TTL
Policy پویا و Context-aware است	Subject، Device، Resource، Action، Risk و Environment	Policy decision log
Integrity و Posture Asset پایش می‌شود	Device/Workload version، Patch و managed state	Posture freshness و exception
AuthN/AuthZ پویا و پیش از Access است	Step-up، revoke و re-evaluation در رخدادهای پرریسک	Negative/expiry/revoke tests
Telemetry برای بهبود Policy جمع می‌شود	Allow/Deny، Reason، anomaly و change feedback	Dashboard، alert و review

Zero Trust چه چیزی نیست؟

یک VPN جدید با نام ZTNA نیست؛
MFA برای هر Click مشتری نیست؛
جایگزین Secure coding، Patch، Backup، WAF یا Incident response نیست؛
فقط Microsegmentation شبکه نیست؛
اعتماد دائمی به Device «Managed» یا IP دفتر نیست؛
خرید Suite یک Vendor بدون Policy، Owner و Test نیست؛
پروژه Big Bang برای حذف همه ابزارهای قبلی نیست.

اگر محصولی با یک Agent وعده «Zero Trust کامل» می‌دهد، Boundary آن را بپرسید: چه Subject، Resource، Protocol و Decisionهایی را می‌بیند و چه چیزی بیرون می‌ماند؟

معماری منطقی Zero Trust: PE، PA و PEP

NIST سه جزء منطقی مهم را توضیح می‌دهد:

جزء	نقش	نمونه وب	Failure mode
Policy Engine (PE)	تصمیم نهایی Grant/Deny/Revoke	Risk/authorization service	Policy غلط یا Signal کهنه
Policy Administrator (PA)	برقراری/قطع مسیر براساس تصمیم	صدور config/token/session	تصمیم درست ولی اعمال‌نشده
Policy Enforcement Point (PEP)	اجرا در مسیر Subject→Resource	Reverse proxy، API gateway، sidecar یا App middleware	Bypass یا Fail-open ناخواسته

Control plane تصمیم و Policy را مدیریت می‌کند؛ Data plane ترافیک واقعی را عبور یا متوقف می‌کند. اگر Origin، Admin port یا Service endpoint مسیر Bypass داشته باشد، قوی‌ترین Policy engine بی‌اثر می‌شود.

Policy contract؛ واحد واقعی معماری اعتماد صفر

به‌جای Ruleهای پراکنده، برای هر Journey حساس یک قرارداد بسازید:

فیلد	سؤال	نمونه
Subject	چه User/Service/Device؟	عضو تیم مالی با Account فعال
Resource	کدام App/Data/Action؟	Export سفارش‌ها، نه کل Admin
Action	Read/Write/Approve/Deploy؟	Refund بالاتر از آستانه
Context	Device، Time، Location، Network؟	Device managed با Posture تازه
Assurance	Auth strength و Freshness؟	Phishing-resistant MFA و step-up
Decision	Allow/Deny/Challenge/Limit؟	Challenge سپس Approval دوم
Duration	Session/Token تا چه زمان؟	۱۵ دقیقه برای عملیات حساس
Evidence	چه چیزی ثبت می‌شود؟	Policy version، reason، correlation
Failure	Fail-closed/open/degraded؟	Write بسته، Read محدود
Owner/Review	چه کسی و چه زمانی؟	App owner؛ هر سه ماه/پس از Incident

Policy باید Version، Test و Change record داشته باشد. Rule امنیتی بدون Owner و Expiry به‌مرور یا بیش‌ازحد باز می‌شود یا کار را متوقف می‌کند.

پنج ستون CISA و قابلیت‌های بین‌ستونی

Zero Trust Maturity Model ۲.۰ از CISA مسیر بلوغ را در پنج ستون Identity، Devices، Networks، Applications & Workloads و Data می‌بیند؛ Visibility & Analytics، Automation & Orchestration و Governance نیز میان همه ستون‌ها امتداد دارند.

ستون	پرسش کلیدی وب	ضدالگو
Identity	چه انسان/Workloadی با چه Assurance؟	Role دائمی و Account مشترک
Device	Posture چقدر تازه و قابل اعتماد است؟	اعتماد صرف به User-Agent/Agent installed
Network	کدام Flow لازم و کجا Enforcement می‌شود؟	Flat network یا Allow کل Subnet
App/Workload	Identity و Authorization سرویس چیست؟	Shared secret بلندمدت
Data	کدام Record/Field با چه Purpose؟	Access به Database کامل

برنامه‌ای که فقط MFA دارد، Zero Trust کامل نیست؛ همان‌طور که Service mesh بدون Identity governance و Data policy کافی نیست.

سه مسیر متفاوت: مشتری، نیروی کار و Workload

مسیر	Resource	Signal اصلی	UX/Security balance
مشتری→وب	Account، سفارش، پرداخت	Identity، Session، رفتار و Transaction risk	Step-up فقط در Risk/Action حساس
کارمند/پیمانکار→Admin	CMS، Cloud، Analytics، Support	Federated identity، MFA، Device، Role	SSO، JIT و Approval
Service→Service	API، Queue، DB، Secret	Workload identity، token، attestation/context	Automation و short-lived credential

Copy کردن Policy ادمین روی مشتری Conversion را خراب می‌کند؛ Copy کردن Policy مشتری روی Admin ریسک را بالا می‌برد. Assurance باید با Impact و Threat model همان Journey متناسب باشد.

Identity انسانی؛ از Lifecycle تا Authentication

Identity backbone از Joiner/Mover/Leaver شروع می‌شود: چه کسی Account می‌سازد، Attribute و Role از کجا می‌آید، تغییر سمت چه زمانی اعمال و خروج چگونه Revoke می‌شود؟ SSO بدون Lifecycle می‌تواند دسترسی‌های پراکنده را فقط پشت یک Login متمرکز کند.

Account مشترک ادمین را حذف یا با مسیر Break-glass محدود و قابل ممیزی جایگزین کنید؛
Federation و Group mapping را با Source of truth منابع انسانی/قرارداد پیوند دهید؛
MFA را براساس Risk و Assurance انتخاب کنید؛ برای Admin، روش مقاوم به Phishing را در اولویت بگذارید؛
Recovery را هم‌سطح Login امن کنید؛ Helpdesk bypass می‌تواند MFA را بی‌اثر کند؛
Session، Refresh token، Device binding و Re-auth را برای Action حساس تعریف کنید؛
Service account را با User account مخلوط نکنید.

NIST SP ۸۰۰‑۶۳‑۴، منتشرشده در ۲۰۲۵ Risk management، Identity proofing، Authentication و Federation را به‌روز کرده است. برای انتخاب Passkey، TOTP، Backup code و Recovery پنل، راهنمای MFA و Passkey پنل مدیریت مکمل عملی است.

Authorization؛ Least privilege فراتر از RBAC

Authentication می‌گوید Subject کیست؛ Authorization می‌گوید چه Actionی روی کدام Object مجاز است. بسیاری از رخدادهای وب از حساب معتبر با مجوز بیش‌ازحد یا کنترل Object-level ناقص ناشی می‌شوند.

مدل	کاربرد	ریسک
RBAC	Roleهای پایدار مانند Editor/Finance	Role explosion و privilege accumulation
ABAC	Department، data class، device و time	Policy پیچیده و توضیح‌ناپذیر
ReBAC	Owner/member/manager رابطه‌ای	Graph/state ناسازگار
JIT/JEA	Access حساس موقت و به‌اندازه	Approval bottleneck یا تمدید خودکار

Deny by default را با Test مثبت و منفی اجرا کنید: User A نباید Object کاربر B را ببیند؛ Editor نباید Publish/Export/Role change کند؛ Token یک Audience نباید در API دیگر پذیرفته شود. مجوز در UI کافی نیست—Enforcement باید Server-side و نزدیک Resource باشد.

Device posture؛ Signal مفید، نه حقیقت مطلق

Device managed، Patch level، Disk encryption، Screen lock و EDR می‌توانند Risk signal باشند. اما Agent ممکن است غیرفعال، Telemetry کهنه یا Device قرض‌داده شده باشد. Freshness و Confidence هر Signal را وارد Policy کنید.

برای BYOD، میان Privacy و Security مرز بگذارید: چه داده‌ای از Device جمع می‌شود، Purpose و Retention چیست و گزینه دسترسی محدود از Browser وجود دارد؟ Posture failure نباید کاربر را بدون دلیل و مسیر Remedy رها کند.

Network و ZTNA؛ دسترسی App به‌جای ورود به Subnet

VPN رمزنگاری و Remote access مفید ارائه می‌دهد، اما بعضی Deploymentها پس از اتصال Route گسترده به شبکه می‌دهند. ZTNA معمولاً می‌کوشد Subject را فقط به Resource مصوب متصل کند و Resource را از Discovery عمومی دور نگه دارد.

موضوع	VPN سنتی گسترده	ZTNA Resource-level
واحد دسترسی	Network/Subnet	App/Resource
Trust بعد اتصال	گاهی گسترده‌تر	Policy per session/resource
Discovery	ممکن است Resourceهای شبکه دیده شوند	کاهش Exposure در طراحی درست
Legacy protocol	پوشش خوب	بسته به Connector/Protocol
مهاجرت	موجود	مرحله‌ای؛ همزیستی ممکن است

ZTNA همیشه سریع‌تر نیست. مسیر Edge، Connector، Inspection، IdP و Network کاربران تعیین‌کننده‌اند. VPN را تا زمانی که Protocol و Recovery لازم دارند حذف نکنید؛ ابتدا Resourceهای پرریسک و سازگار را منتقل کنید.

Microsegmentation و Service-to-Service

Microsegmentation باید از Data flow مجاز بیاید: Web→API، API→DB و Worker→Queue؛ نه از ترسیم VLANهای بیشتر. Egress نیز مهم است: Workload نفوذشده نباید به هر مقصد اینترنتی یا Secret store دسترسی داشته باشد.

برای Cloud-native، NIST SP 800‑207A Policy در لایه Network و Identity، Gateway، Service identity و Service mesh را برای محیط چندمکان تشریح می‌کند. mTLS هویت و رمزنگاری مسیر را کمک می‌کند، اما Authorization business، صدور/Rotation/Revoke identity، Policy drift و App vulnerability را خودکار حل نمی‌کند.

کنترل	سؤال پذیرش	Failure test
Workload identity	به Instance/Service درست و کوتاه‌عمر صادر می‌شود؟	Credential کپی‌شده
mTLS	هر دو طرف و Trust domain معتبرند؟	Certificate expired/revoked
Service policy	Method/Path/Action محدود است؟	Service مجاز، endpoint غیرمجاز
Egress	Destination و DNS/Proxy کنترل می‌شود؟	Exfiltration simulation

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

هر API call نیازمند Authentication نیست—Endpoint عمومی هم وجود دارد—اما هر Resource حساس باید Authorization روشن داشته باشد. API Gateway تنها PEP ممکن است؛ Object-level authorization معمولاً به Context داخل App نیاز دارد.

Issuer، Audience، Scope، Expiry و Signature Token را اعتبارسنجی کنید؛
Authorization code با PKCE و Flowهای جاری را متناسب با Client انتخاب کنید؛
Token را در Log، URL و Analytics افشا نکنید؛
Refresh token rotation/revocation و replay detection را طراحی کنید؛
برای عملیات پرریسک sender-constrained token را در Threat model بررسی کنید؛
Rate limit را با Identity/Account/Resource ترکیب کنید، نه فقط IP؛
Webhook را با Signature، Timestamp، Replay window و Idempotency محافظت کنید.

RFC ۹۷۰۰، Best Current Practice امنیت OAuth ۲.۰ در ۲۰۲۵ Threatها و روش‌های منسوخ/ناامن را به‌روز کرده است. برای BOLA/BOPLA، JWT، Gateway و Webhook نیز راهنمای امنیت API و OWASP را ببینید.

Zero Trust جای امنیت اپلیکیشن را نمی‌گیرد

User معتبر و Device سالم هنوز می‌تواند Input مخرب بفرستد یا از Authorization gap سوءاستفاده کند. Secure development، Threat modeling، Dependency، Secret management، Injection prevention، Session security، Error handling و Business logic test مستقل‌اند.

OWASP ASVS 5.0.0 مبنایی برای Requirement و Verification کنترل‌های فنی اپلیکیشن است. ZTA تصمیم Access را تقویت می‌کند؛ ASVS کمک می‌کند خود Resource پس از Access نیز مقاوم باشد.

Data-centric security؛ هدف نهایی Policy

مرحله	کنترل	Evidence
Discover/Classify	Data owner، sensitivity، purpose	Data inventory
Access	Row/field/action authorization	Decision log و negative test
Use	Masking، export limit، watermark در صورت نیاز	Journey test
Move	TLS، destination و DLP متناسب	Flow map
Store	Encryption، key boundary و backup	Key/restore evidence
Retain/Delete	Retention، legal hold و deletion	Lifecycle report

«Encrypt everywhere» بدون Key access policy و Restore test کافی نیست. Export مشتری، گزارش مالی و Backup ممکن است Sensitivity متفاوت داشته باشند و Policy یکسان نخواهند.

Telemetry؛ تصمیم را قابل توضیح و Incident را قابل بازسازی کنید

برای هر Decision حداقل Timestamp، Subject/Workload pseudonymous ID، Resource، Action، Result، Reason code، Policy version، Assurance، Posture freshness، Risk band و Correlation ID را ثبت کنید. Password، Token و Data حساس را در Log نگذارید.

Metric	هدف	Guardrail
Access decision latency	اثر PEP/PE بر Journey	p95/p99 per resource
Deny/Challenge rate	Attack یا Policy friction	تفکیک true/false positive
Stale posture/identity	Signal freshness	Expiry و degraded policy
Privilege age	Access دائمی	JIT/Review overdue
Bypass coverage	Resource بیرون Enforcement	صفر برای Crown jewel
Revoke propagation	زمان قطع واقعی	End-to-end drill

برای Correlation، Cardinality، Alert و SLO، راهنمای Observability و مانیتورینگ لحظه‌ای را کنار Security telemetry استفاده کنید.

Threat scenarioها را به Control و Evidence وصل کنید

سناریو	کنترل‌های ZT	کنترل مکمل	آزمون
Password ادمین سرقت شده	MFA، device/risk policy، JIT	Recovery امن و detection	Login از Context جدید
Laptop پیمانکار آلوده	Posture، resource scope، session revoke	EDR و BYOD isolation	Posture stale/noncompliant
Token API دزدیده شده	TTL، audience/scope، sender constraint	Secret/log hygiene	Replay از Client دیگر
Service نفوذ کرده	Workload identity، segment، egress	Runtime/app security	Lateral/exfil attempt
Insider مجاز Data صادر می‌کند	Action/data policy، step-up، dual approval	DLP و review	Bulk export anomaly
IdP قطع شده	Resilient session/decision design	DR و break-glass	Dependency failure game day

Performance و Availability؛ هزینه Decision را Budget کنید

هر PEP، Token exchange، posture lookup و policy call می‌تواند Latency و Dependency اضافه کند. Zero Trust نه ذاتاً کندتر است و نه سریع‌تر. مسیر قبل/بعد را با p50/p95/p99، Authentication completion، Decision latency و Journey success بسنجید.

ریسک	کاهش ریسک	Trade-off
PE در Hot path کند	Policy نزدیک PEP، cache کوتاه و bounded	Revocation freshness
IdP outage	HA، session policy و break-glass	Security در حالت degraded
Step-up زیاد	Risk/action-based challenge	False negative
Connector/Proxy bottleneck	Capacity، multi-zone و load test	Cost/complexity
Fail-open ناخواسته	Failure policy per action	Availability write/read

Fail-open/closed را سراسری تعیین نکنید. شاید مشاهده Status عمومی در حالت Degraded مجاز و تغییر Role یا Export Data بسته باشد.

Firewall و WAF در Zero Trust هنوز چه نقشی دارند؟

Network firewall، Security group، Origin protection و WAF Defense-in-depth هستند. WAF Identity governance را جایگزین نمی‌کند؛ ZTNA نیز Injection، DDoS یا Bot را خودکار حل نمی‌کند. Policyها باید هم‌پوشانی روشن داشته باشند.

برای Default deny، Ingress/Egress، Origin، WAF tuning، Rate limit و Rollback، راهنمای فایروال و WAF سایت را ببینید.

پیاده‌سازی Zero Trust برای وب موجود

۱. Crown jewel و Journey را انتخاب کنید

از «کل سازمان» شروع نکنید. Admin access، Production deploy یا Export داده را انتخاب کنید. Subject، Resource، Action، Data و Impact را مشخص کنید.

۲. Flow و مسیرهای Bypass را کشف کنید

DNS، Public endpoint، VPN، SSH، Service account، API key، Cloud console و Break-glass را ثبت کنید. Shadow admin و حساب پیمانکار خارج Directory را پیدا کنید.

۳. Baseline و Policy contract بسازید

چه کسی امروز دسترسی دارد، از کجا و چند بار؟ Least privilege را با واقعیت کاری تطبیق دهید. Deny blind بدون Baseline می‌تواند عملیات را قطع کند.

۴. PEP را در Observation mode قرار دهید

اگر فناوری اجازه می‌دهد ابتدا تصمیم فرضی و دلیل را Log کنید. False positive، Deviceهای ناشناخته و Integrationهای Legacy را تحلیل کنید؛ Data حساس را در Log کپی نکنید.

۵. Enforce را با گروه Canary شروع کنید

Adminهای کم‌تعداد، Resource پرریسک و Window پشتیبانی‌شده انتخاب کنید. Support و Break-glass حاضر باشند. موفقیت Login کافی نیست؛ عملیات واقعی و revoke را تست کنید.

۶. Scope را بر Risk گسترش دهید

Admin→Cloud/CI/CD→Internal apps→Service-to-service→Data actions. هر مرحله Gate و Observation window دارد. NIST SP ۱۸۰۰‑۳۵ نهایی در ژوئن ۲۰۲۵ ۱۹ پیاده‌سازی نمونه و درس‌های Integration ارائه می‌کند؛ آن‌ها Reference هستند، نه Blueprint کپی‌شدنی بدون Risk assessment.

Rollout، Rollback و Break-glass

فاز	Guardrail	Rollback
Observe	Coverage و reason code کامل	خاموش‌کردن shadow decision
Canary	Access success، latency و Support ticket	Policy version قبلی
Enforce low risk	False deny زیر آستانه	Scope exception با expiry
Enforce crown jewel	Break-glass/revoke drill پاس	Emergency policy دو نفره
Steady state	Drift، privilege age و bypass پایش	Versioned policy restore

Break-glass نباید Password مشترک در پیام‌رسان باشد. Credential/Hardware امن، دو نفره، Alert فوری، Session record، محدودیت زمان و Review بعد استفاده تعریف کنید. اگر Control plane یا IdP قطع شد، تیم باید بداند چه عملیات امن می‌ماند.

امنیت CI/CD و دسترسی Production

Pipeline یک Crown jewel است: Repository، Runner، Artifact، Cloud role و Secret می‌توانند Policy chain را دور بزنند. Human deploy دائمی را به Workflow مصوب، Token کوتاه‌عمر، OIDC/Workload identity، Environment protection و Approval متناسب تبدیل کنید.

راهنمای CI/CD امن Artifact provenance، OIDC، Runner threat model، Progressive delivery و Rollback را پوشش می‌دهد. Zero Trust access بدون Software supply-chain security، اعتماد را فقط تا درِ Deployment می‌رساند.

ملاحظات Zero Trust برای تیم و کسب‌وکار ایرانی

محدودیت	ریسک	راهکار
Eligibility/تحریم/تغییر Terms	تعلیق IdP/ZTNA/SIEM	استفاده با هویت واقعی، Contract/Export/Exit و گزینه جایگزین
پرداخت و FX	عدم Renewal سرویس امنیتی	Owner مالی، Alert، Reserve و graceful exit
اختلال شبکه/مسیر خارجی	IdP/PE/Connector دور از دسترس	Multi-ISP probe، timeout، HA و degraded policy
SMS OTP	تأخیر، SIM risk و عدم تحویل	Passkey/security key/TOTP و Recovery آزموده
Remote/VPN variability	Location/IP false positive	IP فقط یک Signal؛ Identity/device/action ترکیبی
Support timezone	MTTR بالا	Severity/escalation و Runbook داخلی
داده/حریم خصوصی	Telemetry بیش‌ازحد یا خروج داده	Minimization، Retention و بررسی حقوقی

راهکار ابری را با اطلاعات کشور یا هویت نادرست به Control حیاتی تبدیل نکنید. Dependency امنیتی‌ای که هر لحظه ممکن است از دسترس سازمان خارج شود، خود یک Risk concentration است.

حریم خصوصی و تجربه کاربر

Context بیشتر می‌تواند Decision بهتر بسازد، اما جمع‌آوری بی‌حد Location، Device و Behavior ریسک حریم خصوصی ایجاد می‌کند. برای هر Signal Purpose، Necessity، Retention، Access و Redress تعریف کنید.

Policy باید قابل توضیح باشد: «به‌دلیل Device posture منقضی، دسترسی Write نیاز به تأیید دارد» بهتر از «Access denied» است. مسیر Remedy امن—Update، Helpdesk، Device جایگزین یا Access محدود—بخش معماری است.

خرید ابزار Zero Trust؛ سؤال‌های Due diligence

موضوع	سؤال	Evidence
Coverage	کدام Protocol/Resource/Device واقعاً پوشش دارد؟	Pilot روی Journey واقعی
Policy	Version، test، simulation و reason code دارد؟	Policy change drill
Identity	Federation، SCIM، workload identity و revoke؟	Joiner/mover/leaver test
Availability	PEP/Connector/IdP failure چگونه است؟	Failure game day و SLA
Telemetry	Export/API، latency، retention و redaction؟	SIEM integration
Security	Admin، key، update و supply chain؟	Assurance package
Iran/Contract	Eligibility، Billing، Support و Data location؟	تأیید مکتوب جاری
Exit	Policy، log، identity map و config قابل خروج؟	Export/import sample

License را بر User/Device/Connector/Traffic/Log volume و محیط‌های Test/DR مدل کنید. هزینه Integration، Policy engineering، Helpdesk و مهاجرت را کنار Subscription ببینید.

معیارهای بلوغ و موفقیت

Outcome	Metric	ضد Metric
کاهش دسترسی ضمنی	درصد Crown jewel پشت PEP بدون bypass	تعداد License
Least privilege	Privilege age، JIT coverage، unused access	تعداد Role
کنترل Identity	Phishing-resistant MFA و revoke time	فقط MFA enabled
کاهش Blast radius	مسیرهای lateral مجاز و failure test	تعداد Segment
Detection	Decision correlation و MTTD/MTTR سناریو	Log volume
UX/Availability	Access success، challenge rate، p95 latency	کمترین Deny

درجه بلوغ را به تفکیک ستون و Resource ثبت کنید. Average کل می‌تواند Crown jewel بدون Enforcement را پنهان کند.

برنامه ۳۰/۶۰/۹۰ روزه

بازه	خروجی	Gate
روز ۱ تا ۳۰	Crown jewel، Flow، Identity inventory، Baseline، Policy contract	Owner/Bypass/Break-glass روشن
روز ۳۱ تا ۶۰	Admin Pilot، MFA/SSO/lifecycle، PEP observe، telemetry	False deny/latency/revoke drill پاس
روز ۶۱ تا ۹۰	Enforce، Service identity، Segment، data action، game day	Guardrail و incident/runbook پذیرفته

بعد از ۹۰ روز، برنامه تمام نشده است. Policy review، access certification، credential rotation، Vendor change، new resource onboarding و Failure drill باید عملیات دوره‌ای شوند.

اشتباه‌های رایج پیاده‌سازی Zero Trust

شروع با خرید Tool: Resource، Threat و Policy هنوز روشن نیست.
Big Bang: Legacy، Recovery و Support بدون مسیر می‌مانند.
MFA=Zero Trust: Authorization، Device، Workload، Data و Telemetry حذف می‌شوند.
اعتماد دائمی به Managed device: Posture freshness و User risk نادیده می‌مانند.
Network-only segmentation: Object/action authorization داخل App غایب است.
PEP با مسیر Bypass: Origin/Admin/API مستقیم قابل دسترسی می‌مانند.
Fail-closed سراسری: Outage IdP کل کسب‌وکار را متوقف می‌کند.
Fail-open سراسری: کنترل هنگام بحران حذف می‌شود.
Log بیشتر بدون Reason: Decision قابل توضیح نیست و Secret نشت می‌کند.
SMS به‌عنوان تنها Recovery: تحویل/سیم‌کارت به Single point of failure تبدیل می‌شود.
حذف زودهنگام VPN: Protocol Legacy و Break-glass از دست می‌روند.
اعتماد به درصدهای بازاریابی: Baseline و Threat سنجیده نمی‌شوند.

سؤالات متداول درباره Zero Trust

آیا Zero Trust یعنی هرگز به هیچ کاربری اعتماد نکنیم؟

یعنی براساس Location یا مالکیت، اعتماد ضمنی و دائمی ندهیم. Access با Identity، Resource، Action، Device/Context، Assurance و Risk تصمیم‌گیری و در طول عمر Session بازبینی می‌شود.

تفاوت Zero Trust و ZTNA چیست؟

Zero Trust معماری و مدل عملیاتی گسترده‌ای برای Identity، Device، Network، Workload و Data است. ZTNA یک قابلیت دسترسی شبکه/اپلیکیشن و فقط بخشی از آن معماری است.

آیا با Zero Trust دیگر به VPN و فایروال نیاز نداریم؟

نه. VPN ممکن است برای Protocol/Recovery باقی بماند و Firewall/WAF همچنان Defense-in-depth ارائه می‌کنند. دسترسی گسترده VPN را می‌توان مرحله‌ای به Resource-level محدود کرد.

اولین قدم اجرای Zero Trust برای سایت چیست؟

یک Crown jewel و Journey پرریسک—مثلاً Admin یا Production deploy—را انتخاب، Subject/Resource/Action/Flow/Bypass را Inventory و Baseline کنید. سپس Policy contract، MFA/Identity و PEP را در Pilot اجرا کنید؛ «فقط MFA برای همه» نسخه واحد نیست.

آیا Zero Trust عملکرد سایت را کند می‌کند؟

ممکن است Decision و Proxy Latency اضافه کنند یا مسیر VPN قدیمی را کوتاه کنند؛ نتیجه تضمینی نیست. p95/p99، access success و dependency failure را پیش و پس از Pilot بسنجید و Failure policy را per action طراحی کنید.

جمع‌بندی: از اعتماد ضمنی به تصمیم قابل‌آزمون

Zero Trust زمانی واقعی است که برای Resource حساس بدانید چه Subjectی، با چه Assurance و Context، چه Actionی را تا چه زمان می‌تواند انجام دهد؛ PEP مسیر Bypass نداشته باشد؛ تصمیم ثبت و قابل توضیح باشد؛ و Failover، Revoke و Break-glass در Drill کار کنند. از Admin یا Deploy پرریسک شروع کنید، Observe و Canary داشته باشید و بلوغ را ستون‌به‌ستون گسترش دهید.

اگر برای Threat model، Policy contract، انتخاب ابزار یا Pilot اعتماد صفر نیاز به همراهی دارید، از فرم درخواست مشاوره مایندیو Resourceهای حساس، IdP، Cloud، VPN و مسیرهای دسترسی فعلی را ارسال کنید.

خدمات مایندیو

تست ریل

تیمی

تسکی

برچسب‌ها