امنیت، هویت، استقرار و تاب‌آوری · فصل ۶ — Chaos، Feature Flags، Rollout و ADR · 110
Auth/Audit Foundation در سیستم واقعی
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Auth/Audit Foundation در سیستم واقعی». می‌تواند برای «Auth/Audit Foundation در سیستم واقعی» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Auth/Audit Foundation در سیستم واقعی».
می‌تواند برای «Auth/Audit Foundation در سیستم واقعی» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «Auth/Audit Foundation در سیستم واقعی» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
1. مسئله واقعی: ورود موفق، مجوز عمومی نیست
یک سیستم ممکن است کاربر را درست شناسایی کند و همچنان اجازه‌ی عمل اشتباه را بدهد. «Authentication» فقط پاسخ می‌دهد این درخواست به کدام هویت نسبت داده شده است؛ «Authorization» تصمیم می‌گیرد همان هویت برای این resource و action مشخص مجاز است یا نه. در این درس هر نتیجه باید به یک درخواست مصنوعی، principal، resource، action، تصمیم server-side و evidence قابل بررسی متصل شود. صفحه‌ی login یا وجود session به‌تنهایی هیچ مجوزی برای action حفاظت‌شده ثابت نمی‌کند [OWASP-AUTHN][OWASP-AUTHZ].
2. زنجیره‌ی پایه را قبل از کدنویسی ببین
مدل این درس یک زنجیره‌ی محدود است: request → authentication context → principal → protected action → authorization decision → outcome → security/audit event → correlation → review evidence. اگر یکی از این حلقه‌ها دیده نشود، نتیجه نباید با حدس پر شود. Auth-Audit Runtime Foundation Record v1 دقیقاً برای همین ساخته می‌شود: observation، inference و policy choice را از هم جدا می‌کند و وضعیت‌های OPEN را نگه می‌دارد.
3. Authentication چه چیزی را ثابت می‌کند؟
Authentication هویت را در مرز این fixture محلی تأیید می‌کند: آیا session مصنوعی معتبر است و principal قابل نسبت‌دادن داریم یا نه. خروجی آن باید محدود باشد؛ مثلاً authenticated=true و principal=user-17. این مشاهده هنوز نمی‌گوید user-17 می‌تواند گزارش مالی بخواند، کلید مدیریتی بچرخاند یا تنظیمات یک tenant دیگر را تغییر دهد. آن پرسش متعلق به authorization است [OWASP-AUTHN].
4. Authorization باید server-side و برای action مشخص باشد
برای هر protected action، policy باید روی server-side بررسی شود. ماتریس کوچک این درس resource، action و شرط مجوز را صریح می‌کند. OWASP روی least privilege، deny by default و بررسی permission برای هر request تأکید می‌کند [OWASP-AUTHZ]. در fixture ما اگر route حفاظت‌شده authorization middleware نداشته باشد، حتی وجود audit event هم failure را جبران نمی‌کند؛ کنترل پیشگیرانه حذف شده است.
5. Deny by Default یعنی unknown را allow نکن
Deny by default یعنی نبودن rule صریح، principal ناشناخته، action ناشناخته یا context ناکافی به allow تبدیل نشود. این قاعده مخصوص نقش‌ها نیست؛ در مدل role-based، relationship-based یا attribute-based همان اصل باقی می‌ماند. در record باید policy evidence نشان دهد چرا یک allow یا deny صادر شده است، نه اینکه فقط outcome نهایی ثبت شود.
6. Least Privilege را با تست منفی قابل مشاهده کن
یک happy path کافی نیست. کاربر کم‌اختیار مصنوعی را authenticate کن و از او یک admin-only action بخواه. نتیجه‌ی درست باید deny باشد و reason code قابل دفاع داشته باشد. این تست منفی، سوءبرداشت «چون وارد شده پس می‌تواند انجام دهد» را مستقیم falsify می‌کند. اگر route action را allow کند، status باید blocker بماند حتی اگر بعداً همه چیز در log ثبت شده باشد.
7. Audit بعد از تصمیم می‌آید، جای تصمیم را نمی‌گیرد
Audit evidence برای بازبینی «چه اتفاقی افتاد» است؛ authorization control تعیین می‌کند «آیا باید اجازه داده می‌شد». اگر route بدون authorization check اجرا شود ولی logger رویداد allowed ثبت کند، سیستم هنوز foundation قابل قبول ندارد. Logging نمی‌تواند مجوز ازدست‌رفته را پس از وقوع بازسازی کند. این تمایز باید در هر row record روشن بماند [OWASP-LOGGING].
8. یک audit event قابل استفاده چه چیزهایی دارد؟
در این درس حداقل actor/principal، target/resource، action، outcome، reason code، event time، request/correlation id و event source ثبت می‌شود. هدف جمع‌کردن داده‌ی بیشتر نیست؛ هدف attribution کافی برای یک review محدود است. اگر actor یا correlation اشتباه باشد، وجود event به‌تنهایی closure نمی‌دهد. چنین rowی OPEN باقی می‌ماند تا evidence درست فراهم شود.
9. Correlation پل میان request، decision و event است
request id یا correlation id باید اجازه دهد درخواست ورودی، authorization decision و audit event همان interaction را به هم وصل کنیم. اگر action درست باشد ولی correlation به request دیگری اشاره کند، attribution قابل اتکا نیست. در fixture یکی از سناریوها عمداً actor/correlation را غلط می‌گذارد تا نشان دهد «log وجود دارد» با «evidence قابل نسبت‌دادن وجود دارد» یکی نیست.
10. Sensitive Data Exclusion یک gate است، نه تزئین
OWASP Logging guidance هشدار می‌دهد که logging باید امنیتی و مفید باشد بدون اینکه secretهای حساس را افشا کند [OWASP-LOGGING]. در این درس bearer token کاملاً مصنوعی است، اما همان هم نباید در audit sink ظاهر شود. اگر logger مقدار Bearer SYNTHETIC-SECRET-... را بنویسد، package آموزشی آن case را blocker می‌داند. راه درست، ثبت actor/context لازم و redaction یا omission secret است.
11. Event Source و Trust Zone را صریح ثبت کن
همه‌ی eventها ارزش اثباتی یکسان ندارند. eventی که از client یا trust zone ضعیف می‌آید ممکن است ناقص یا قابل جعل باشد. بنابراین record باید event_source و محدودیت trust را مشخص کند. در این درس audit sink محلی append-only برای test است، اما این به معنی non-repudiation قانونی یا tamper-proof production logging نیست؛ چنین ادعایی خارج از scope می‌ماند [OWASP-LOGGING].
12. Missing Audit Evidence را با Authorization Failure اشتباه نکن
دو failure جدا داریم: ممکن است authorization درست deny کند اما event مورد انتظار ثبت نشود؛ یا ممکن است authorization check اصلاً اجرا نشود و logger همچنان چیزی ثبت کند. اولی gap در evidence/audit است و دومی blocker در control. repair باید همان boundary را هدف بگیرد. ترکیب این دو در یک برچسب «security مشکل دارد» تشخیص را مبهم می‌کند.
13. Auth-Audit Runtime Foundation Record v1 را پر کن
برای هر request این ستون‌ها را ثبت کن: Request، Authn State، Principal، Resource، Action، Policy Evidence، Authz Decision، Reason، Audit Event، Correlation، Sensitive-data Check، Supported/Open و Repair. observation و inference را جدا بنویس. اگر principal، source trust یا correlation ناقص است، OPEN دقیق‌تر از یک PASS ساختگی است. این record یک artifact آموزشی MAKNOW است، نه template رسمی OWASP.
14. Repair فقط وقتی بسته می‌شود که probe شکست‌خورده دوباره سبز شود
برای route بدون authorization check، repair یعنی check را در همان server-side boundary برگردانی و تست low-privilege را دوباره اجرا کنی. برای deny بدون audit، repair یعنی event قابل نسبت‌دادن بسازی و همان case را rerun کنی. برای secret leak، repair باید test redaction را پاس کند. یک تغییر بزرگ و نامرتبط evidence خوبی نیست؛ repair باید محدود، قابل تکرار و متصل به failure probe باشد.
15. Transfer: از Role Matrix به Relationship/Attribute Rules
در fixture دوم نام actionها عوض می‌شود، authentication و audit component جدا هستند و authorization به role ساده متکی نیست. باید evidence chain را از صفر بسازی: principal، relationship/attribute، target، action، policy evidence، decision و event correlation. اگر بدون کپی‌کردن ماتریس fixture اول بتوانی allow/deny و OPEN را دفاع کنی، مهارت منتقل شده است. نام مدل authorization عوض می‌شود؛ استاندارد evidence ثابت می‌ماند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ملاک‌های ارزیابی (rubric)
| Dimension | Sufficient evidence |
|---|---|
| Owned model correctness | Authentication and authorization remain distinct; protected actions use explicit server-side decision evidence. |
| Evidence quality | Request, principal, resource, action, decision, reason, and event evidence are traceable and observation is separated from inference. |
| Negative evidence | At least one plausible shortcut is falsified: missing authorization, missing audit, bad attribution, or secret leakage. |
| Sensitive-data boundary | Synthetic secrets are excluded/redacted from learner-visible audit evidence. |
| Transfer independence | The changed-context relationship/attribute case is solved without copying the original role matrix. |
Blocking failures: treating authentication as universal authorization; accepting an unguarded protected action because it was logged; accepting secret-bearing logs; inventing attribution/correlation; or replacing missing evidence with certainty.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Use the eight deterministic local fixtures in fixtures/cases.json.
For each case:
- identify authentication state and principal attribution;
- verify whether the protected action has a server-side authorization check;
- evaluate deny-by-default and the explicit policy evidence;
- record the allow/deny outcome and reason;
- verify whether the audit event is attributable to the same actor/action;
- verify request/audit correlation;
- confirm the synthetic secret is absent from logged fields; and
- classify the row as supported, blocker, or OPEN with a bounded repair.
Implement build_record(case) in starter.py. Learner files contain no hidden expected classifications. All identities, secrets, resources, and events are synthetic and local; no network or real account is used.