Tenant Isolation

۱) ورود موفق کاربر، اثبات Isolation نیست

در یک SaaS چندمستاجری ممکن است JWT معتبر باشد، Role درست باشد و Authorization هم allow بدهد؛ با این حال کاربر هنوز بتواند Resource مستاجر دیگری را بخواند. Tenant Isolation Boundary & Cross-Tenant Access Test Matrix v1 سؤال متفاوتی می‌پرسد: «آیا هر مسیر دسترسی، Resource را به Tenant همین Request محدود می‌کند؟»

۲) SaaS Identity را از همان ورودی Bind کن

user_id و tenant_id باید از یک Context کنترل‌شده بیایند. اگر API به کاربر اجازه دهد tenant_id دلخواه در Query/Header بفرستد و همان مقدار به‌عنوان Authority مصرف شود، مرز Isolation قابل اعتماد نیست. Tenant Context باید همراه Identity وارد سیستم شود و در لایه‌های بعدی قابل دریافت باشد.

۳) Resource Planeها را جداگانه فهرست کن

Isolation فقط Database نیست. Data Store، Object Storage، Cache، Queue/Topic، Search Index، Compute Job، Log/Metric، Admin Tool، Export و Control Plane می‌توانند مرز Tenant را بشکنند. هر Plane باید isolation_model و policy_enforcement_point خودش را داشته باشد.

۴) Enforcement Point را دقیق نام ببر

«ما Tenant-aware هستیم» Evidence نیست. مشخص کن Policy کجا enforce می‌شود: API Gateway، Service Handler، Repository Layer، Database Policy، IAM/ABAC، Cache Namespace، Queue Consumer یا Admin Proxy. اگر Enforcement فقط در UI باشد، Backend هنوز می‌تواند Cross-Tenant شود.

۵) Partition Key را با Tenant Scope هم‌راستا کن

در Pooling، یک resource_id به‌تنهایی ممکن است globally unique نباشد یا از مسیر دیگری قابل حدس باشد. Data Partition، Index Key و Cache Key باید Tenant Scope را صریح یا از طریق Policy معتبر حمل کنند. Cache Key بدون tenant_id می‌تواند داده درست را برای Tenant اشتباه برگرداند حتی وقتی Auth کاملاً معتبر است.

۶) Async Pathها را هم Tenant-aware نگه دار

Queue Producer ممکن است Tenant Metadata بنویسد، اما Consumer باید آن Context را verify و enforce کند. Shared Queue بدون Tenant-scoped consumer check یعنی Trust به Producer جایگزین Isolation شده است. Retry، DLQ و Batch Worker هم بخشی از همان Boundary هستند.

۷) Operational Tooling بخشی از Boundary است

Export، Support Console، Backfill Script و Admin Tool معمولاً قدرت بیشتری از مسیر عادی دارند. اگر Operations Query بتواند tenant_id دلخواه بگیرد، یک Bypass Path واقعی داری. Exception باید Owner، Scope، Audit Event و Authority مشخص داشته باشد؛ «فقط ادمین‌ها استفاده می‌کنند» کنترل کافی نیست.

۸) Positive Test و Negative Test هر دو لازم‌اند

Same-Tenant Positive Test نشان می‌دهد مسیر مجاز خراب نشده است. Cross-Tenant Negative Test نشان می‌دهد مرز واقعاً جلوی دسترسی Tenant دیگر را می‌گیرد. فقط Positive Test نمی‌تواند Isolation را ثابت کند؛ نتیجه در آن حالت HOLD می‌ماند.

۹) State را از Evidence قوی‌تر نکن

VERIFIED فقط وقتی مجاز است که Context، Enforcement، Partition و Test Evidence کامل باشد. شکست واقعی = FAILED. Evidence گمشده = UNKNOWN یا HOLD. Evidence قدیمی = STALE. تغییر مادی که Recompute نشده = PARTIAL. تناقض Authority = DISPUTED. Policy Block = BLOCKED.

۱۰) FACT را از MAKNOW DESIGN جدا نگه دار

راهنمای AWS می‌گوید Tenant Isolation از Authentication/Authorization جداست، Tenant Context باید همراه SaaS Identity در معماری جریان یابد و دسترسی به Resource باید Tenant-scoped شود. اما State Vocabulary، Matrix Fields و شرط «برای VERIFIED حتماً Negative Test داشته باش» تصمیم طراحی MAKNOW است، نه استاندارد عمومی AWS.

۱۱) Matrix را به Evidence وصل کن

جدول کاری، Tenant/User Context، Resource Plane، Enforcement Point، Partition Key، Positive/Negative Test، Bypass و Audit Event را کنار هم می‌گذارد تا Reviewer بتواند Verdict را بدون Hidden Reasoning بازتولید کند.

۱۲) Negative Case: Cache Key بدون tenant_id

فرض کن API و Database کاملاً Tenant-scoped هستند ولی Cache Key فقط product_id است. Tenant B می‌تواند پاسخ Cache مربوط به Tenant A را دریافت کند. Auth هنوز معتبر است، اما Cache Plane شکست خورده؛ State کل Boundary نمی‌تواند VERIFIED بماند.

۱۳) Negative Case: Operations Export با tenant_id دلخواه

یک Export Tool که Tenant را از Parameter اپراتور می‌گیرد، Bypass Path ایجاد می‌کند. حتی اگر استفاده محدود باشد، باید Context از Authority کنترل‌شده بیاید یا Exception Path مستقل، Audit‌شده و محدود داشته باشد. Arbitrary Override بدون این کنترل = FAILED.

۱۴) Transfer: Storage اختصاصی، Compute هنوز Pooled

برای یک Tenant پرریسک Storage را Dedicated می‌کنی. این فقط Data Plane را تغییر می‌دهد. Compute، Cache، Queue، Logs و Operations هنوز Tenant Context و Negative Test می‌خواهند. نتیجه baseline را کپی نکن؛ Matrix را Plane-by-Plane دوباره بساز.

۱۵) Completion Test

کار وقتی تمام است که Reviewer دیگر بتواند از روی Evidence آشکار همان Verdict را بازتولید کند: Tenant/User Binding، Context Source، Resource Planes، Isolation Model، Enforcement Point، Authorization Context، Partition Key، Same-Tenant Test، Cross-Tenant Test، Bypass Path، Failure Domain، Audit Event، State و Evidence Ref. هیچ Plane مهمی را با «احتمالاً امن است» سبز نکن.