Cross-tenant Leakage

1. سبز بودن API به‌تنهایی اثبات isolation نیست

در یک سامانه multi-tenant ممکن است درخواست در لایه API برای Tenant A درست authorize شود، اما همان request بعداً از یک query بدون scope، cache key مشترک، message ناقص در queue یا object prefix اشتباه عبور کند و داده Tenant B را بخواند یا تغییر دهد. مسئله این درس همین فاصله میان «authorization اولیه» و «حفظ tenant context در تمام مسیر» است. OWASP نیز cross-tenant leakage و broken tenant isolation را از ریسک‌های اصلی معماری multi-tenant می‌داند و تأکید می‌کند tenant context باید از هویت تأییدشده سمت سرور مشتق و در لایه‌های downstream حفظ شود. [OWASP-MULTITENANT]

2. Tenant ID یک selector است، نه مدرک authorization

وجود tenant_id در header، query parameter یا payload فقط می‌گوید caller چه tenantی را انتخاب کرده است؛ این مقدار به‌تنهایی حق دسترسی را ثابت نمی‌کند. context معتبر باید به principal احراز‌شده و membership یا service authorization فعلی متصل شود. اگر downstream component دوباره یک tenant ID کنترل‌نشده از ورودی بگیرد، isolation می‌تواند شکسته شود حتی وقتی middleware اولیه درست بوده است. [OWASP-MULTITENANT]

3. Isolation را به‌صورت invariant منفی تعریف کنید

برای هر boundary مشترک سؤال ثابت این است: «آیا Tenant A می‌تواند داده، state یا side effect متعلق به Tenant B را بخواند، بنویسد یا دریافت کند؟» پاسخ قابل‌قبول باید منفی باشد و با evidence مستقیم پشتیبانی شود. داشتن tenant_id در schema، cache key یا log کافی نیست؛ باید نشان دهید enforcement واقعاً روی مسیر اجرا شده است.

4. Database فقط یکی از مرزهاست

یک query با WHERE tenant_id = ... یا RLS می‌تواند لایه database را درست ببندد، اما cache، object storage، queues، background jobs و audit/read APIs هنوز می‌توانند leakage ایجاد کنند. بنابراین تشخیص این درس یک boundary map می‌سازد و وضعیت هر مرز را مستقل ثبت می‌کند. یک پاس شدن query به معنی recovery کامل نیست.

5. Cache key باید contextی را حمل کند که نتیجه به آن وابسته است

OWASP توصیه می‌کند برای داده‌ای که به tenant وابسته است tenant identifier در cache key باشد و cache separation جای authorization را نگیرد. [OWASP-MULTITENANT] اگر دو tenant از key یکسان مانند user:42 استفاده کنند، cache hit می‌تواند پاسخ صحیح دیتابیس را دور بزند و داده tenant دیگر را برگرداند. containment در چنین حالتی باید shared entries آسیب‌پذیر را invalidate یا partition کند.

6. Queue و background job نیز authorization boundary هستند

async work نباید tenant context را فقط به‌عنوان یک رشته بدون اعتبار حمل کند. producer path باید context معتبر را ثبت کند و consumer باید scope عملیات را دوباره enforce کند. OWASP صریحاً توصیه می‌کند verified tenant context در tenant-scoped asynchronous work حمل شود و consumer authorization را دوباره برقرار کند. [OWASP-MULTITENANT]

7. Object storage به prefix یا metadata قابل enforce نیاز دارد

در storage، مسیرهایی مثل tenant-a/... فقط وقتی isolation ایجاد می‌کنند که policy یا access layer exact object و operation را authorize کند. prefix naming صرفاً convention است، نه control. OWASP برای tenant-owned objects partitioning و authorization روی object دقیق را توصیه می‌کند. [OWASP-MULTITENANT]

8. Tenant Isolation Breach Evidence Record v1

Artifact اصلی این درس رکوردی است با این ابعاد: Actor Tenant، Resource Tenant، Verified Tenant Context، API Decision، DB Scope، Cache Namespace، Queue Context، Storage Prefix، Exposure Observation، First Failed Boundary، Containment، Negative Isolation Test، Closure State و Residual Shared State. هر خانه باید یکی از چهار نوع باشد: observed، authority-backed، inference یا UNKNOWN.

9. First failed boundary را از symptom نهایی جدا کنید

دیدن داده Tenant B در response فقط symptom را نشان می‌دهد. علت ممکن است cache باشد، query باشد یا object storage. برای پیدا کردن اولین failure باید boundaryها را یکی‌یکی با contrast probe کنترل کنید. اگر شواهد کافی نیست، state را OPEN/UNRESOLVED نگه دارید؛ حدس زدن اولین boundary باعث repair اشتباه می‌شود.

10. Negative control برای حذف alternative لازم است

اگر suspect شما cache است، همان request را با cache bypass یا namespace صحیح اجرا کنید و بقیه context را ثابت نگه دارید. اگر leakage ناپدید شد، alternativeهای دیگر ضعیف‌تر می‌شوند؛ اما این هنوز فقط fixture همان درس را توضیح می‌دهد. نتیجه را به «کل سامانه امن است» تعمیم ندهید.

11. Containment و recovery یکی نیستند

Containment می‌تواند fail-closed کردن route، invalidate کردن cache، pause کردن queue consumer یا block کردن object release باشد. این اقدامات blast radius را محدود می‌کنند اما علت را لزوماً برطرف نمی‌کنند. recovery زمانی قابل دفاع است که boundary معیوب اصلاح شود و یک negative isolation test مستقل نشان دهد cross-tenant read/write دیگر رخ نمی‌دهد.

12. Closure باید multi-boundary باشد

بعد از fix کردن cache، database، queue و storage را هم دوباره بررسی کنید. OWASP نیز isolation را در چند لایه—database، cache/session، API، file storage و audit—به‌صورت مجموعه‌ای از controls مطرح می‌کند. [OWASP-MULTITENANT] بنابراین closure این درس فقط وقتی بسته می‌شود که fixture مربوط به همه مرزهای لمس‌شده negative isolation را پاس کند یا وضعیت نامشخص صریحاً به review منتقل شود.

13. Transfer: failure می‌تواند مرزش را عوض کند

در changed-context fixture، cache namespace اصلاح شده اما object-storage prefix خراب می‌شود. اگر learner فقط label قبلی «cache leak» را تکرار کند، transfer شکست خورده است. باید record از evidence جدید بازسازی شود و first failed boundary تازه ثبت شود.

14. Lab: هشت fixture و 64 assertion

Lab کاملاً local و synthetic است: دو tenant ساختگی، recordهای جعلی و state cardهای deterministic. هشت case شامل safe baseline، database leak، cache leak، queue leak، storage leak، blocked cross-tenant attempt، evidence ناقص و transfer mutation هستند. evaluator مدیریتی برای هر case هشت خروجی را می‌سنجد؛ در مجموع 64 assertion. هیچ target واقعی، credential واقعی یا customer data استفاده نمی‌شود.

15. Exit checklist و مرز ادعا

قبل از خروج باید بتوانید: tenant context معتبر را نام ببرید؛ database/cache/queue/storage را مستقل بررسی کنید؛ حداقل یک alternative را با negative evidence رد کنید؛ UNKNOWN را حفظ کنید؛ containment را از closure جدا کنید؛ transfer fixture را از نو تحلیل کنید؛ و روشن بگویید که موفقیت این Lab فقط isolation همان fixture مصنوعی را ثابت می‌کند، نه امنیت کامل یک سرویس واقعی.