Secret Management و Scoped Identities

خروجی محدود درس

Secret فقط یک رشته حساس نیست؛ یک شیء امنیتی با مالک، مصرف‌کننده، مجوز، مسیر retrieval، چرخه عمر و شواهد audit است. خروجی محدود این درس طراحی یک مدل محلی و قابل بازبینی است که در آن هر سرویس مصنوعی فقط به secret object لازم برای وظیفه خودش دسترسی دارد، مقدار secret هرگز وارد evidence نمی‌شود، و rotation/revocation به‌صورت state transition قابل مشاهده ثبت می‌شود. مقصد evidence این درس Secret Scope and Lifecycle Record v1 است و lab آن SEC010-LAB1 است.

این درس ادعا نمی‌کند که environment variable به‌تنهایی secret را امن می‌کند، همه سازمان‌ها باید از یک محصول secret manager استفاده کنند، dynamic secret در همه محیط‌ها ممکن است، یا یک cadence ثابت rotation برای همه secretها درست است. همچنین green شدن lab به معنی امن بودن production نیست. تمام identifierها opaque و ساختگی‌اند؛ هیچ credential واقعی، token واقعی یا secret value واقعی وارد fixture نمی‌شود.

1. Secret value با authority یکی نیست

یک خطای رایج این است که «داشتن مقدار secret» و «حق retrieve/use کردن secret» یکی فرض شود. در طراحی سالم‌تر، secret object شناسه‌ای دارد و workload identity باید policy مشخصی را satisfy کند تا فقط capability لازم را بگیرد. اگر wid-orders-api برای خواندن داده سفارش به secret://orders-read-v1 نیاز دارد، این نیاز هیچ مجوزی برای secret://batch-export-v1 ایجاد نمی‌کند. Least privilege باید روی object و capability قابل بازرسی باشد، نه فقط در توضیحات معماری.

در SEC010-LAB1 policy محلی اجازه‌ها را با opaque IDs تعریف می‌کند. هیچ value ذخیره یا چاپ نمی‌شود. Positive Evidence زمانی ایجاد می‌شود که identity درست secret object خودش را با capability مجاز retrieve کند. Negative Evidence زمانی ایجاد می‌شود که همان identity برای secret نامرتبط، wildcard scope یا capability خارج از وظیفه درخواست بدهد و تصمیم DENY ثبت شود.

2. inventory قبل از rotation

Rotation بدون inventory قابل اتکا نیست. قبل از اینکه بگوییم یک secret «rotate شد»، باید بدانیم مالک آن چیست، چه workloadهایی آن را مصرف می‌کنند، retrieval path چیست، چه identityهایی دسترسی دارند، revocation قبلی چگونه اثبات می‌شود و audit چه فیلدهایی را نگه می‌دارد. اگر این dependencyها نامشخص باشند، rotation می‌تواند outage بسازد یا credential قدیمی را بی‌صدا فعال نگه دارد.

Secret Scope and Lifecycle Record v1 برای هر object فیلدهای Secret Object، Owning Service، Workload Identity، Required Capability، Allowed Access، Human Access?، Retrieval Path، Rotation-Revocation Evidence، Audit Fields و Residual Risk را نگه می‌دارد. این جدول مقدار secret را ندارد. هدفش این است که بتوانیم بگوییم «کدام هویت به کدام شیء، برای چه کار، از چه مسیر و با چه شواهدی دسترسی دارد».

3. scoped workload identity بهتر از secret copy عمومی است

Copy کردن credential در source، config مشترک، پیام یا فایل دستی blast radius را افزایش می‌دهد و ownership را مبهم می‌کند. جایی که platform پشتیبانی می‌کند، workload identity محدود و retrieval خودکار می‌تواند تماس انسان با secret material و طول عمر credentialهای کپی‌شده را کاهش دهد. این اصل به معنی ممنوع بودن همه static secrets نیست؛ یعنی باید copy را یک تصمیم دارای ریسک بدانیم، نه default راحت.

در fixture، interactive API و batch worker هویت‌های جدا دارند. API فقط secret object خواندن orders را می‌بیند. Batch worker فقط object مربوط به export job را می‌بیند. درخواست cross-service باید DENY شود. Policy همچنین wildcard access را رد می‌کند. اگر یک engineer یا service به همه secretها دسترسی داشته باشد، «عملیات راحت‌تر» دلیل امنیتی کافی نیست.

4. human access باید تصمیم آگاهانه باشد

گاهی operator به secret نیاز ندارد؛ فقط باید بتواند job را اجرا کند یا rotation را trigger کند. بنابراین Human Access? در evidence باید صریح باشد. NO_DIRECT_READ با CAN_TRIGGER_ROTATION یکی نیست. کنترل بهتر می‌تواند capability عملیاتی را بدون نمایش secret material بدهد. در این درس هیچ human credential واقعی مدل نمی‌شود؛ فقط policy boundary مصنوعی ثبت می‌شود.

اگر human direct-read واقعاً لازم باشد، evidence باید دلیل، scope و residual risk را نگه دارد. نبودن دلیل نباید با default broad access جبران شود. Audit نیز باید identity و event را نشان دهد، نه مقدار secret را.

5. rotation و revocation دو بخش یک transition هستند

ساخت secret identifier جدید کافی نیست. Rotation معتبر در این lab باید نشان دهد: identifier جدید active شده، consumerهای declared به reference جدید منتقل شده‌اند، identifier قبلی revoked شده، و audit event ثبت شده است. اگر old reference هنوز usable باشد، lifecycle evidence ناقص است. اگر consumer update نشده باشد، ممکن است outage یا fallback ناامن ایجاد شود.

Positive Evidence برای rotation شامل new_active=true، old_revoked=true، consumers_updated=true و audit_event_present=true است. Negative Evidence با حذف هر کدام از این invariants ایجاد می‌شود و transition باید DENY_ROTATION_INCOMPLETE بگیرد. این مدل cadence جهانی تعیین نمی‌کند؛ فقط completeness یک transition محدود را می‌سنجد.

6. revocation باید قابل مشاهده باشد

Revocation فقط یک برچسب policy نیست. اگر secret old revoked شده باشد، attempt بعدی برای استفاده از همان identifier باید DENY شود و event قابل audit باقی بماند. نگه‌داشتن اثر تلاش برای secret revoked به incident response کمک می‌کند، درحالی‌که خود secret value نباید log شود.

در این lab audit event تنها identity_id، secret_id، decision، lifecycle_event و timestamp مصنوعی را ثبت می‌کند. هر ورودی با کلیدهایی مثل secret_value، plaintext, token یا password از evidence حذف می‌شود. Redaction به معنی پنهان کردن evidence تصمیم نیست؛ باید metadata تصمیم باقی بماند.

7. audit بدون secret material

Audit باید بتواند پاسخ بدهد: چه identity، چه secret object، چه decision و چه lifecycle event. ولی نباید secret material را دوباره به log leak کند. Secret scanning بعد از حادثه مفید است، اما جای access control، inventory، retrieval boundary یا lifecycle را نمی‌گیرد. بنابراین در artifact، audit_fields یک فهرست metadata است و field مربوط به value وجود ندارد.

Negative Evidence مهم است: اگر fixture عمداً payloadی با کلید secret_value به audit builder بدهد، خروجی باید آن کلید را حذف کند و فقط metadata مجاز را نگه دارد. این test نشان می‌دهد «لاگ کردن همه چیز برای debug» یک shortcut قابل قبول نیست.

8. retrieval path بخشی از trust boundary است

Secret object ممکن است درست scope شده باشد ولی retrieval path نامناسب باشد. قرار دادن secret در source repository، shared config یا artifact قابل دانلود می‌تواند scope identity را دور بزند. در این lesson retrieval path فقط reference محلی و synthetic است و هیچ external secret manager فراخوانی نمی‌شود. هدف مشاهده decision rule است، نه آموزش محصول خاص.

Policy fixture برای هر identity list دقیقی از object/capability دارد. retrieve و use capabilityهای مستقل‌اند. اگر service فقط retrieve دارد ولی use ندارد، درخواست use باید DENY شود. این separation کمک می‌کند مدل از «می‌تواند secret را ببیند، پس هر کاری می‌تواند بکند» فاصله بگیرد.

9. secret lifecycle از creation تا retirement

چرخه عمر درس شامل create/provision، bounded retrieval/use، rotate، revoke و retire است. هر مرحله باید owner و evidence قابل بررسی داشته باشد. هیچ cadence ثابت global تعیین نمی‌شود. بعضی secretها کوتاه‌عمرند و بعضی وابستگی بیشتری دارند؛ تصمیم باید با threat model و consumer context دفاع شود.

یک lifecycle row خوب به‌جای جمله «کلید ماهانه rotate شود» می‌نویسد کدام object، کدام consumer، چه trigger، چه evidence برای new active و old revoked، و چه residual risk باقی می‌ماند. این سطح از specificity از checklist فاصله می‌گیرد.

10. Positive Evidence

Positive Evidence در baseline شامل سه نوع observation است. اول، wid-orders-api فقط secret object مربوط به orders را با capability مجاز می‌گیرد. دوم، cross-service request رد می‌شود. سوم، rotation کامل باعث active شدن reference جدید و revoke شدن reference قدیمی می‌شود. هر observation باید با policy و fixture قابل trace باشد.

گزارش فقط نتیجه ALLOW را نمی‌نویسد؛ decision reason و object identity را هم ثبت می‌کند. اگر evidence نتواند مشخص کند چرا access مجاز بود، برای owner review کافی نیست.

11. Negative Evidence

Negative Evidence شامل wildcard access، unrelated secret access، missing revocation، missing consumer update و تلاش برای وارد کردن secret value به audit است. هدف تولید failure قابل کنترل است، نه شکستن سیستم واقعی. تمام probeها harmless و local هستند.

وجود negative evidence مانع این خطای استدلالی می‌شود که «چون happy path کار کرد، policy امن است». Security claim باید حداقل یک boundary rejection را نیز نشان دهد.

12. Changed-context transfer

در transfer، یک batch worker و یک interactive API capability و lifetime متفاوت دارند. learner نباید policy baseline را copy کند. باید از صفر مشخص کند هر workload چه objectی لازم دارد، human access چیست، retrieval path چگونه است و rotation/revocation چه dependencyهایی دارد. Artifact transfer عمداً blank است تا تصمیم learner از قبل پر نشده باشد.

اگر batch job کوتاه‌عمر است، ممکن است temporary identity و narrow object scope منطقی باشد. Interactive API ممکن است long-running consumer باشد و rotation rollout متفاوتی بخواهد. این تفاوت‌ها نشان می‌دهد یک cadence یا access matrix جهانی کافی نیست.

13. Assessment و blocking boundaries

Assessment این درس پنج نوع سؤال دارد: retrieval، application، diagnosis، decision و transfer. سؤال application، diagnosis و transfer blocking هستند. پاسخ باید به evidence واقعی lab اشاره کند. اگر learner value واقعی وارد کند، wildcard را مجاز بداند، یا old reference را بدون revocation active نگه دارد، completion معتبر نیست.

AI می‌تواند بعد از تعریف objective پیشنهاد probe بدهد یا evidence مشاهده‌شده را مرتب کند؛ اما اجازه ندارد secret واقعی بسازد، evidence جعلی تولید کند یا تصمیم نهایی residual risk و owner acceptance را بدهد.

14. Freshness و source boundary

Claimهای current فقط به OWASP-SECRETS متصل‌اند. این منبع برای lifecycle، fine-grained access control، automation/rotation و IAM scoping استفاده می‌شود. Vendor-specific configuration خارج از scope است. Review due برابر 2026-10-02 است و authoring در 2026-09-16 انجام می‌شود؛ voluntary recheck همان source boundary را تأیید کرده و authority جدید اضافه نشده است.

15. Residual Risk

حتی اگر همه gateهای fixture PASS شوند، production security ثابت نشده است. Product-specific IAM behavior، deployment compromise، supply chain، incident response، key material protection و availability خارج از این lab هستند. Residual Risk باید همین محدودیت را صریح نگه دارد.

16. جمع‌بندی

قاعده فشرده درس این است: secret value را از access authority جدا کن؛ scope هویت را حداقلی نگه دار؛ lifecycle و rotation/revocation را با consumer evidence ببند؛ audit را بدون secret material ثبت کن. Secret Scope and Lifecycle Record v1 باید هم ALLOW و هم DENY را نشان دهد و transfer را بدون decisive scaffold به learner بسپارد.