TLS, mTLS و Device Identity

این درس دربارهٔ دیدن آیکون قفل و نتیجه‌گیری «پس همه‌چیز امن است» نیست. مسئلهٔ واقعی این است که چهار مرز مستقل را از هم جدا کنیم: حفاظت کانال، راستی‌آزمایی هویت سرویس، احراز هویت دوطرفهٔ client/workload و مجوز انجام action. خروجی نهایی یادگیرنده Transport & Workload Identity Trust Record v1 است. آزمایشگاه SEC013-LAB1 فقط از metadata ساختگیِ certificate/SVID و trust-anchorهای opaque استفاده می‌کند؛ هیچ certificate واقعی، private key، endpoint بیرونی یا identity plane عملیاتی در این درس وجود ندارد.

1. TLS کانال را محافظت می‌کند، نه اینکه به‌تنهایی همهٔ هویت و مجوز را ثابت کند

TLS برای ایجاد یک کانال محافظت‌شده طراحی شده است. در SEC-013، claimهای پروتکلی TLS 1.3 به RFC9846 بسته می‌شوند؛ این RFC در 2026 جای RFC 8446 را گرفته است. این تغییر freshness مهم است، چون تکرار «RFC 8446 استاندارد جاری TLS 1.3 است» اکنون یک claim قدیمی محسوب می‌شود. بااین‌حال حتی اجرای صحیح TLS نیز به‌تنهایی نمی‌گوید endpoint مشاهده‌شده همان application identity مورد انتظار است، یا client مجاز به یک business action خاص است.

در evidence record باید ستون TLS Version Source مستقل از ستون Server Identity باشد. ممکن است کانال TLS برقرار شود ولی نام سرویس، trust anchor یا application identity مورد انتظار درست نباشد. بنابراین «handshake موفق» و «service identity verified» دو گزارهٔ متفاوت‌اند. در این درس، RFC9525 فقط برای boundary مربوط به representation/verification هویت سرویس در TLS استفاده می‌شود.

2. Service identity باید به expectation برنامه متصل باشد

برنامه باید بداند با چه سرویس منطقی صحبت می‌کند و evidence را به همان expectation متصل کند. یک certificate ساختگی با نام api.internal.example نباید برای endpoint مورد انتظار admin.internal.example کافی تلقی شود. آزمایشگاه این موضوع را بدون هیچ certificate واقعی مدل می‌کند: presented identity، expected identity و trust anchor همگی stringهای بی‌خطر هستند و decision model mismatch را رد می‌کند.

این distinction جلوی shortcut مهمی را می‌گیرد: «چون certificate معتبر است، پس endpoint همان سرویس درست است.» اعتبار زنجیره و هویت کاربردی دو سؤال جدا هستند. Evidence خوب باید failure boundary را نیز ثبت کند؛ wrong-name باید در service-identity verification رد شود، نه اینکه بعداً با authorization failure اشتباه گرفته شود.

3. mTLS احراز هویت client/workload است، نه business authorization

در mTLS هر دو طرف می‌توانند certificate ارائه کنند. این قابلیت می‌تواند client/workload identity را در یک PKI پیکربندی‌شده اثبات کند، اما هنوز مشخص نمی‌کند آن identity برای کدام operation مجاز است. در SEC-013، authentication و authorization دو gate مستقل‌اند. یک workload ممکن است به‌درستی authenticate شود ولی action admin.read برای آن ممنوع باشد.

SEC013-LAB1 این جداسازی را executable می‌کند. ابتدا server identity بررسی می‌شود، سپس client identity و trust domain، و در آخر action policy. Evidence record باید بتواند حالتی را ثبت کند که Authenticated? = yes ولی Authorized Action? = no. چنین negative evidence ارزشمندتر از یک happy-path ساده است، چون نشان می‌دهد مدل به‌اشتباه authentication را به authorization تبدیل نکرده است.

4. Trust anchor و trust domain باید صریح باشند

هویت workload بدون trust boundary معنی کامل ندارد. اگر verifier نداند کدام trust anchor یا trust domain برای context معتبر است، یک identity string به‌تنهایی assurance ایجاد نمی‌کند. در fixture محلی دو context داریم: internal_api و admin_endpoint. هر context expected server identity، trust anchor، allowed client trust domain و action map مستقل دارد.

در changed-context transfer، یادگیرنده حق ندارد policy internal_api را عیناً به admin_endpoint کپی کند. باید trust record جدید بسازد، چون client identity و authorization scope متفاوت است. این قاعده در template انتقال با copy_primary_identity_policy_forbidden=true ثبت شده است.

5. SPIFFE/SVID فقط در boundary تعریف‌شده استفاده می‌شود

SPIFFE-X509-SVID برای مفهوم workload identity، SPIFFE ID و trust domain استفاده می‌شود. در این درس هیچ SPIRE server، Workload API واقعی یا certificate issuance عملیاتی اجرا نمی‌شود. Fixture فقط یک رکورد synthetic مانند spiffe://prod.example/workload/orders-api دارد تا یادگیرنده بتواند trust-domain mismatch را از authorization mismatch جدا کند.

SVID معتبر نشان می‌دهد identity document تحت authority یک trust domain قابل verify است؛ این به‌تنهایی اثبات نمی‌کند workload compromise نشده یا برای هر business action مجاز است. بنابراین residual risk باید صریح بماند: compromise خود workload، policy اشتباه در issuer و authorization misconfiguration خارج از اثبات محدود این lab هستند.

6. Failure evidence باید در همان boundary درست ثبت شود

چهار failure مهم داریم: expired identity، wrong server name، wrong trust domain و unauthorized action. هر failure باید در gate درست متوقف شود. اگر certificate منقضی باشد، قبل از authorization باید رد شود. اگر server name اشتباه باشد، service identity verification شکست می‌خورد. اگر client trust domain نامعتبر باشد، client authentication شکست می‌خورد. اگر identity معتبر است ولی action مجاز نیست، failure boundary باید authorization باشد.

این تفکیک برای عیب‌یابی اهمیت دارد. عبارت «TLS کار نکرد» برای همهٔ این failureها بیش‌ازحد مبهم است. Evidence record باید Failure Boundary و Evidence را جدا ثبت کند تا implementation observation با security inference قاطی نشود.

7. Worked example: internal API

سناریوی baseline، ارتباط synthetic با internal_api است. TLS version source برابر RFC9846 است. server expected/presented identity هر دو api.internal.example هستند. trust anchor برابر trust:corp-service-root است. client identity برابر spiffe://prod.example/workload/orders-api و trust domain برابر prod.example است. action orders.read برای این identity مجاز است.

اجرای مدل باید سه مشاهده تولید کند: SERVER_IDENTITY_VERIFIED، CLIENT_AUTHENTICATED و ALLOW_ACTION. این سه observation به‌ترتیب channel/service identity، client identity و authorization را پوشش می‌دهند. یک ردیف کامل evidence شامل Connection / TLS Version Source / Server Identity / Client Identity / Trust Anchor / Authenticated? / Authorized Action? / Failure Boundary / Evidence / Residual Risk است.

8. Negative Evidence: wrong name و unauthorized action

در probe اول presented server identity را به admin.internal.example تغییر می‌دهیم درحالی‌که expected identity همان api.internal.example است. نتیجه باید DENY_SERVER_IDENTITY_MISMATCH باشد. این failure نباید به authorization layer برسد.

در probe دوم identity client معتبر باقی می‌ماند ولی action از orders.read به admin.read تغییر می‌کند. نتیجه باید DENY_ACTION_UNAUTHORIZED باشد. این‌بار client همچنان authenticated است. ثبت این تفاوت در Negative Evidence نشان می‌دهد policy از shortcut «هر certificate معتبر = همهٔ عملیات مجاز» جلوگیری می‌کند.

9. Negative Evidence: wrong trust domain و expired identity

اگر client identity با trust domain dev.example ارائه شود ولی context فقط prod.example را بپذیرد، مدل باید DENY_CLIENT_TRUST_DOMAIN بدهد. اگر identity status برابر expired باشد باید DENY_CLIENT_IDENTITY_EXPIRED ثبت شود. این دو probe فقط metadata ساختگی را تغییر می‌دهند؛ هیچ certificate یا private key واقعی وجود ندارد.

10. Authorization بعد از authentication

در evidence table دو ستون جدا برای Authenticated? و Authorized Action? داریم. این طراحی عمداً اجازه می‌دهد یک ردیف authenticated ولی unauthorized باشد. اگر این دو ستون به یک boolean مشترک تبدیل شوند، lesson outcome از بین می‌رود، چون learner دیگر نمی‌تواند فرق mTLS authentication و business authorization را نشان دهد.

در policy baseline، هر context action map مستقل دارد. orders-api فقط actionهای محدود internal API را دارد و admin-console actionهای محدودی برای admin endpoint. هیچ wildcard authorization تعریف نشده است.

11. Trust record باید observation را از inference جدا کند

Evidence می‌تواند output واقعی مدل محلی را نگه دارد، مانند SERVER_IDENTITY_VERIFIED / CLIENT_AUTHENTICATED / ALLOW_ACTION. Residual Risk باید inference محدود باشد، مثلاً: «این fixture فقط metadata و policy محلی را می‌سنجد و compromise واقعی workload، issuer یا endpoint را ثابت نمی‌کند.»

این تفکیک مانع overclaim می‌شود. Green output از lab اثبات production security نیست. حتی اگر همه probeها سبز باشند، owner acceptance باید خالی بماند تا انسان تصمیم نهایی را مستقل بگیرد.

12. Changed-context transfer: admin endpoint

در انتقال مستقل، context به admin_endpoint تغییر می‌کند. expected server identity، client identity و action scope با internal API متفاوت است. learner باید trust record جدید بسازد و نمی‌تواند نتیجهٔ قبلی را کپی کند. اگر orders-api به admin endpoint برسد، حتی با trust domain معتبر، action admin باید مجاز نشود مگر policy مشخصاً آن identity را اجازه داده باشد.

Transfer template از قبل final_decision یا residual_boundary را پر نمی‌کند. این blankness بخشی از human-accountability contract است؛ AI می‌تواند test case پیشنهاد کند اما نتیجه نهایی risk/authorization را به‌جای learner نمی‌نویسد.

13. Positive Evidence و Negative Evidence

Positive Evidence شامل baseline سالم با server identity صحیح، client identity معتبر، trust domain صحیح و action مجاز است. Negative Evidence باید حداقل یک wrong-name و یک authenticated-but-unauthorized case داشته باشد. Evidence ناقص که فقط happy path را ثبت کند، برای این lesson کافی نیست.

14. Residual Risk

این lab certificate parsing، real handshake، PKI operations، CRL/OCSP، production issuer، hardware identity یا device attestation را اثبات نمی‌کند. همچنین valid certificate یا SVID را معادل uncompromised workload نمی‌گیرد. این محدودیت‌ها باید صریح در artifact باقی بمانند.

15. مرز منابع و freshness

RFC9846 برای TLS 1.3 جاری استفاده می‌شود و RFC 8446 را obsolete کرده است. RFC9525 برای service identity verification استفاده می‌شود. SPIFFE-X509-SVID فقط برای workload identity/trust-domain concepts است. هیچ‌کدام از این منابع مجوز business action خاصی برای محیط شما تعریف نمی‌کنند.

16. خروجی نهایی

در پایان SEC013-LAB1 باید Transport & Workload Identity Trust Record v1 شامل Positive Evidence، Negative Evidence، transfer مستقل و residual risk داشته باشد. owner_acceptance باید در starter خالی باشد. خروجی محلی proof تولید نیست و production proof در این درس ممنوع است.