دسکتاپ، Worker و محاسبات محلی · فصل ۱ — Device Identity، Tauri، Tray و Admin CLI · 174
Human Identity vs Device Identity
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Human Identity vs Device Identity». می‌تواند «Human Identity vs Device Identity» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خلاصهٔ درس
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Human Identity vs Device Identity».
می‌تواند «Human Identity vs Device Identity» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خروجی این درس
می‌تواند «Human Identity vs Device Identity» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
پیش‌نیازها
1. مسئله: اسم کاربر و اسم دستگاه، هویت نیستند
فرض کنید لپ‌تاپ render-07 را دو ادمین استفاده می‌کنند. نام کاربری ویندوز عوض می‌شود، دیسک تعویض و اپ دوباره نصب می‌شود، اما دستگاه در موجودی سازمان همان node باقی می‌ماند. اگر os_user، hostname، شناسه نصب و credential را یک چیز فرض کنید، بعد از اولین تغییر ساده دیگر معلوم نیست چه کسی، روی کدام node، با کدام enrollment و با کدام credential عمل کرده است. هدف این درس جدا کردن این لایه‌هاست.
2. مرز مالکیت LOC-001
LOC-001 فقط قرارداد Human Identity vs Device Identity را مالک است. Commandهای Tauri در LOC-002 و Capability/CSP در LOC-003 هستند. این درس نمی‌گوید یک WebView چه Commandی را می‌تواند صدا بزند؛ می‌گوید وقتی یک عملیات به actor_id و node_id نیاز دارد، این شناسه‌ها از کدام رکورد معتبر آمده‌اند و چه رویدادهایی binding آن‌ها را تغییر داده‌اند.
3. چهار هویت را جدا نگه دارید
حداقل چهار محور دارید: human_subject_id برای شخص، human_account_id برای حسابی که شخص استفاده می‌کند، node_id برای node منطقی سازمان، و installation_id/enrollment_id برای نمونه نصب و ثبت فعلی. credential_id هم یک ماده هویتی قابل Rotation/Revocation است، نه خود node. این جداسازی اجازه می‌دهد هر لایه lifecycle مستقل داشته باشد.
4. NIST چه چیزی را ثابت می‌کند و چه چیزی را نه
NIST SP 800-63-4 درباره Identity Proofing، Authentication و Federation کاربران انسانی مثل کارمند یا پیمانکار است. این برای فهم مرز هویت انسان مفید است، اما استاندارد device enrollment MAKNOW نیست. از NIST نمی‌توان نتیجه گرفت که hostname، MAC address یا یک ویژگی سخت‌افزاری به‌تنهایی هویت معتبر node است.
5. SPIFFE چه الگوی متفاوتی نشان می‌دهد
SPIFFE نشان می‌دهد compute/workload identity می‌تواند از هویت انسان جدا باشد: SPIFFE ID در یک Trust Domain قرار می‌گیرد و SVID سند قابل‌اعتبارسنجی برای ارائه آن هویت است. ما از این ایده فقط برای مرزبندی مفهومی استفاده می‌کنیم. یک desktop node به‌خاطر استفاده از این واژه‌ها SPIFFE-compliant یا دارای hardware identity اثبات‌شده نمی‌شود.
6. Username و Hostname را Attribute بدانید
os_user=alice یا hostname=render-07 اطلاعات مفیدی هستند، اما Authority نهایی نیستند. Username می‌تواند rename شود؛ hostname می‌تواند تکرار یا restore شود. این Attributeها باید کنار evidence هویتی ثبت شوند تا در Audit کمک کنند، ولی تغییرشان به‌تنهایی نباید node جدید بسازد یا credential قبلی را معتبر کند.
7. حساب کاربری با شخص یکی نیست
یک انسان ممکن است حسابش rename، disable یا replace شود. human_subject_id باید تاریخچه شخص را حفظ کند و human_account_id یک binding قابل تغییر باشد. وقتی Alice از acct-alice-01 به acct-alice-02 مهاجرت می‌کند، node و device record الزاماً تغییر نمی‌کنند. Audit باید رویداد account change را ثبت کند، نه اینکه گذشته را بازنویسی کند.
8. Node با Installation یکی نیست
Node یک هویت منطقی/سازمانی است؛ Installation یک نمونه اجرایی از نرم‌افزار روی آن node است. بعد از reimage یا reinstall ممکن است node-render-07 حفظ شود، اما installation_id و enrollment_id جدید لازم باشد. اگر نصب قدیمی را بدون مرز lifecycle ادامه دهید، credential و state قدیمی می‌توانند به نصب جدید نشت کنند.
9. Credential یک state قابل Rotation و Revocation است
Credential باید issuer، subject، expiry و state روشن داشته باشد. Rotation نباید شناسه انسان یا تاریخچه node را عوض کند. Revocation هم نباید eventهای قبلی را پاک کند؛ باید یک رویداد append-only بسازد. اگر credential قدیمی بعد از reinstall از backup پیدا شد، وجود فایل به معنی مجاز بودن reuse نیست.
10. Binding انسان به Node باید رویداد صریح باشد
وقتی یک ادمین به node اضافه، حذف یا جایگزین می‌شود، یک binding_event_id با reason و زمان ایجاد کنید. داشتن دو ادمین روی یک laptop نباید دو device identity تولید کند. برعکس، عوض شدن owner/operator نباید node را مجبور کند تاریخچه قبلی را به شخص جدید نسبت دهد.
11. Reinstall: هویت node حفظ، enrollment تازه
در reimage تمیز، اگر موجودی سازمان تشخیص می‌دهد همان device/node در سرویس باقی است، node_id می‌تواند حفظ شود؛ اما installation/enrollment قبلی پایان می‌یابد و credential آن revoke می‌شود. نصب جدید installation_id, enrollment_id و credential تازه می‌گیرد. این separation جلوی «hostname یکسان پس credential قبلی قابل استفاده است» را می‌گیرد.
12. Clone collision: کپی state هویت ایجاد نمی‌کند
اگر image دیسک render-07 روی سخت‌افزار دیگری clone شود و همان node_id/install_id/credential ظاهر شود، نباید آن را continuation عادی فرض کنید. این یک IDENTITY_COLLISION است. تصمیم fail-closed باید BLOCK باشد تا node جدید re-enroll شود و inventory conflict بررسی شود.
13. حالت‌های غیرموفق را حفظ کنید
همه چیز PASS یا FAIL ساده نیست. Credential می‌تواند REVOKED یا EXPIRED باشد؛ installation می‌تواند UNBOUND باشد؛ evidence می‌تواند UNKNOWN باشد. این stateها را به success تبدیل نکنید. DEFER یعنی Evidence کافی برای تصمیم قوی‌تر ندارید، نه اینکه سیستم تقریباً قابل اعتماد است.
14. Lab: Node Identity Separation Matrix & Enrollment Record v1
در lab://LOC-001/LOC001-LAB1 هشت Fixture مصنوعی دارید. برای هر مورد Human identity، Node identity، Installation state، Credential state، Binding state، Conflict state، Decision و Reason را ثبت کنید. سناریوها شامل baseline، rename حساب، ادمین دوم، reinstall تمیز، reuse credential revoked، enrollment نامتصل، clone collision و reassignment هستند. هدف حفظ lifecycle واقعی است، نه مجبور کردن همه Caseها به PASS.
15. Transfer: واگذاری دستگاه و تعویض دیسک بدون پاک کردن تاریخچه
همان دستگاه فیزیکی را به Carol واگذار کنید و دیسک را عوض کنید. Inventory record و node_id می‌توانند باقی بمانند؛ binding Alice باید پایان‌یافته ثبت شود؛ Carol binding جدید می‌گیرد؛ installation/enrollment و credential تازه ساخته می‌شوند؛ credential قبلی revoke می‌ماند. خروجی صحیح تاریخچه را نگه می‌دارد و authority فعلی را از گذشته جدا می‌کند.
منابع رسمی و مرز ادعا
- NIST SP 800-63-4 — Digital Identity Guidelines:
https://csrc.nist.gov/pubs/sp/800/63/4/final - SPIFFE — Identity and Verifiable Identity Document:
https://spiffe.io/docs/latest/spiffe-specs/spiffe-id/
K1 و K2 واقعیت‌های منبعی هستند که در 2026-09-17 دوباره بررسی شدند. K3 (جداسازی node/device از human) و K4 (append-only lifecycle برای rotation/revocation/re-enrollment) قواعد طراحی MAKNOW هستند و به‌عنوان الزام NIST یا SPIFFE معرفی نمی‌شوند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
LOC-001-Q1 boundary
Why can a hostname or OS username be recorded as useful evidence without being sufficient node identity authority?
LOC-001-Q2 application
A user's account is renamed but the node enrollment is unchanged. Which identifiers should change and which should remain stable?
LOC-001-Q3 diagnosis
After reinstall, a backup contains an old revoked credential. What must the identity matrix record before any runtime use?
LOC-001-Q4 conflict
The same installation and credential appear on a different hardware signal after disk-image cloning. What state should be preserved and why?
LOC-001-Q5 transfer
Reassign one physical device to a new operator while replacing its disk. Describe the human binding, node identity, installation/enrollment, credential, and historical audit changes.
ملاک‌های ارزیابی (rubric)
A sufficient artifact:
- keeps human subject/account, logical node/device, installation/enrollment, and credential identifiers distinct;
- treats hostname, OS username, and hardware observations as attributes rather than standalone trust proof;
- preserves REVOKED, EXPIRED, UNBOUND, UNKNOWN and collision states without promoting them to success;
- records explicit human-to-node binding and credential lifecycle events;
- handles reinstall, clone collision, and reassignment without rewriting historical identity;
- states what NIST/SPIFFE sources support and what remains a MAKNOW design choice;
- produces a bounded decision with reason and a clear re-enrollment/recheck trigger when evidence is incomplete or conflicting.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
This is an offline synthetic identity-lifecycle lab. Implement evaluate_case in starter.py, inspect the supplied fixtures, and keep human identity, logical node identity, installation/enrollment identity, and credential state separate.
Your matrix must preserve non-success states instead of treating a familiar hostname, OS username, or copied install record as proof. Test account rename, a second administrator on one node, clean reinstall, revoked-credential reuse, an unbound post-disk-change state, cloned-state collision, and a reassignment transfer.
Run python run_checks.py for learner-visible structural checks. Use only the synthetic records supplied here; no production credentials, hardware identifiers, account data, external network calls, or privileged OS changes are needed.