معماری Tenant-Aware: حذف خطاهای احراز هویت با اتصال سخت به مستاجر

یک شناسه‌ی دسته‌ای (Batch ID) لو رفته می‌تواند به یک ابزار خواندن متقاطع بین مستاجران (Cross-tenant read primitive) تبدیل شود، اگر هر عملیات در خط لوله، مالکیت فایل را دوباره چک نکند. برای تیم‌هایی که خط لوله‌های رسانه‌ای مبتنی بر هوش مصنوعی — مثل تولیدکننده‌های ویدیوهای تبلیغاتی فروشگاه‌های آنلاین — می‌سازند، مرز اعتماد باید «اتصال به مستاجر» (Tenant Binding) باشد، نه کیفیت خروجی ویدیو. کیفیت ویدیو تنها نیمی از تصمیم است؛ نیمه‌ی دیگر دانستن این است که رسانه‌های منبع، مشتقات و متادیتای شغل کجا می‌توانند سفر کنند، چه مدت باقی می‌مانند و کدام پردازشگر در واقع با آن‌ها تماس دارد.

این چالش زمانی رخ می‌دهد که شرکت‌های بیشتری از دموهای ساده به سمت اپلیکیشن‌های چندمستاجری (Multi-tenant) در مقیاس تولید حرکت می‌کنند. در این محیط‌ها، دانستن اینکه رسانه‌های منبع و مشتقات آن‌ها کجا می‌روند، به اندازه خودِ منطق پردازش حیاتی است. بسیاری از توسعه‌دهندگان از یک میان‌بر وسوسه‌انگیز شروع می‌کنند: قرار دادن یک شناسه‌ی دسته‌ای تصادفی در یک صف و اجازه دادن به هر ورکر (Worker) برای نظارت (Poll) بر آن؛ طراحی‌ای که برای دمو کردن آسان است اما دفاع از آن در یک حسابرسی امنیتی تقریباً غیرممکن است.

طبق یک راهنمای فنی که در ۲۲ سپتامبر ۲۰۲۶ منتشر شد، جایگزین امن‌تر، ثبت یک رکورد صریح برای هر مستاجر در کنار هر دارایی و شغل است. این بستر (Context) باید در تمام مراحل خط لوله منتقل شود تا اطمینان حاصل شود که هیچ مرحله‌ای، محموله‌ی صف را صرفاً به‌دلیل «شکل درست داشتن»، اعتماد نکند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد صفر (Zero Trust) باید در لایه‌ی داده‌ها نهادینه شود. این رویکرد برای جلوگیری از نشت منابع و داده‌ها حیاتی است، مشابه آنچه در مدیریت بودجه برای عامل‌های هوش مصنوعی جهت جلوگیری از هزینه‌های سرسام‌آور و نشت داده‌ها بررسی کردیم.

سازوکار قابلیت‌های محدودشده

برای اجرای این مدل، توسعه‌دهندگان باید با شناسه‌ها نه به‌عنوان ابزار احراز هویت، بلکه به‌عنوان قابلیت‌های محدودشده (Scoped Capabilities) برخورد کنند. یک ردیف در پایگاه‌داده برای MediaJob باید به‌صورت یک کلاس داده‌ای منجمد (Frozen Dataclass) ساختار یابد تا تغییرناپذیری (Immutability) آن تضمین شود. این رکورد باید صراحتاً شامل موارد زیر باشد:

• tenant_id: رشته‌ای منحصربه‌فرد برای شناسایی مالک.
• asset_id: شناسه‌ی دارایی رسانه‌ای خاص.
• batch_id: شناسه‌ی گروه پردازشی.
• stage: یک مقدار صریح (Literal) مانند «ارسال‌شده» (submitted)، «در حال پردازش» (processing)، «آماده» (ready)، «شکست‌خورده» (failed) یا «لغو شده» (cancelled).
• source_uri: مکان رسانه‌ی اصلی.
• derivative_uri: مکان اختیاری برای خروجی پردازش‌شده.

نکته‌ی حیاتی این است که شرط جست‌وجو (Lookup Predicate) باید حتماً شامل tenant_id باشد. سیستم نباید ابتدا یک شغل را با batch_id واکشی کند و سپس برای مستاجر فیلتر کند؛ بلکه مستاجر باید بخشی از پرس‌وجوی اولیه باشد (مثلاً job.tenant_id == requested_tenant). این کار از دسترسی غیرمجاز به نام فایل‌ها، مدت زمان ویدیو یا متادیتای پردازشگر جلوگیری می‌کند، مواردی که حتی در پاسخ‌های «فقط خواندنی» نیز ریسک بالایی دارند.

مدیریت تبار و نگهداری

حفظ یک تبار (Lineage) سخت‌گیرانه — از دارایی منبع تا دسته‌ی ارسالی و در نهایت مشتق تأییدشده — به دو دلیل ضروری است:

۱. به تیم‌های پشتیبانی اجازه می‌دهد تا با ردیابی زنجیره، دقیقاً تشخیص دهند کدام مستاجر مالک یک خروجی خاص است.
۲. یک مجموعه‌ی دقیق برای عملیات پاک‌سازی فراهم می‌کند تا از اتصال تصادفی مشتقات به منبع اشتباه در هنگام تلاش‌های مجدد (Retries) جلوگیری شود.

در یک خط لوله‌ی کوچک برای ویدیوهای تبلیغاتی، مراحل باید صریح باقی بمانند: اعتبارسنجی پرامپت و تصویر منبع، ارسال دسته، بررسی وضعیت (Poll)، دریافت نتیجه و در نهایت انتشار در فروشگاه. هر انتقال باید نتیجه‌ی مرحله‌ی قبل را بررسی کند.

سیاست‌های نگهداری (Retention) نیز باید به‌عنوان عملیات احراز شده مدیریت شوند. منطقه (Region) یک ورودی سیاست است، نه یک کامنت در کد. توسعه‌دهندگان باید مناطق مجاز مستاجر را همراه با شغل ثبت کنند و هر ارائه‌دهنده‌ای که نمی‌تواند الزامات اقامت داده‌ها (Residency Requirements) را برآورده کند، پیش از شروع آپلود رد کنند. حذف داده‌ها نیز باید یک عملیات احراز شده در برابر تبار محدود به مستاجر باشد.

نقش لایه‌ی مسیریابی

در حالی که APIهای ارکستراسیون کارها را توزیع می‌کنند، آن‌ها به‌طور خودکار اقامت داده‌ها، حذف قراردادی یا یک توافق‌نامه‌ی امضا شده برای پردازش داده‌ها را تضمین نمی‌کنند. اینجاست که لایه‌ی مسیریابی مثل Infrai در پشته (Stack) قرار می‌گیرد. Infrai یک رابط REST یکپارچه فراهم می‌کند که به یک ورکر اجازه می‌دهد قرارداد HTTP خود را حفظ کند، حتی اگر پردازشگر تخصصی زیرین تغییر کند.

فراخوانی‌های مستند شده برای جریان رسانه‌ای شامل موارد زیر است:

• POST /v1/image/batch/submit
• GET /v1/image/batch/status/{id}
• GET /v1/image/get/{id}

Infrai همچنین یک قرارداد «تکرارناپذیری» (Idempotency) مستند را با استفاده از هدر Idempotency-Key و یک جایگزین (Fallback) مشتق شده از سرور اجرا می‌کند. این قابلیت اجازه می‌دهد تلاش‌های مجدد به‌صورت ایمن انجام شوند، به‌طوری که کلید از ترکیب tenant_id و asset_id و مرحله‌ی منطقی شغل ساخته شود (مثلاً f"{tenant_id}:{asset_id}:submit"). بررسی وضعیت (Polling) باید در یک حالت نهایی (Terminal State) متوقف شود، زیرا حلقه‌های نامحدود هم مشکل عملیاتی ایجاد می‌کنند و هم با طولانی کردن دسترسی به نتایج، مسائل حریم خصوصی ایجاد می‌کنند.

مقایسه گزینه‌های پردازش رسانه

ارائه‌دهندگان مختلف بسته به نیازهای قراردادی مستاجر، نقاط قوت متفاوتی دارند و این گزینه‌ها قابل جایگزینی ساده نیستند:

• Infrai: بهترین گزینه برای پایداری قرارداد و تعویض بک‌اِندها بدون بازنویسی کد ورکر. مرزی که باید تایید شود: منطقه، نگهداری و شرایط حذف پردازشگر زیرین انتخاب شده.
• AWS Elemental MediaConvert: ایده‌آل برای کنترل‌های عمیق پخش (Broadcast) و الگوهای بومی AWS. مرزی که باید تایید شود: یکپارچگی خاص AWS و سطح سیاست‌ها.
• Google Cloud Transcoder API: قوی‌ترین گزینه برای تیم‌هایی که بر اساس IAM و مناطق گوگل کلاود استاندارد شده‌اند. مرزی که باید تایید شود: مدل‌های دسترسی و منابع خاص کلاود.
• Cloudinary: جریان کاری راحت برای تحویل و تغییر شکل دارایی‌ها. مرزی که باید تایید شود: آیا مدل‌های تحویل و نگهداری با قراردادهای مستاجر مطابقت دارد.
• Imgix: مناسب برای تحویل تصاویر مبتنی بر URL و کشینگ. مرزی که باید تایید شود: دسترسی به منبع (Origin)، پاک‌سازی کش و معناشناسی حذف در سطح مستاجر.
• ImageKit: مفید زمانی که CDN دارایی‌ها و تغییرات تصویر در مرکز پشته قرار دارند. مرزی که باید تایید شود: مناطق پردازشگر و کنترل‌های نگهداری.
• Uploadcare: راهکاری عملی برای مدیریت آپلودها و رسانه‌ها برای تیم‌های محصول. مرزی که باید تایید شود: شرایط پردازشگر و ذخیره‌سازی برای بارهای کاری تحت نظارت.

چک‌لیست پیاده‌سازی

برای تیم‌های پایتونی که در حال ارسال یک سیستم ارزیابی (Eval Harness) هستند، این راهنما یک چک‌لیست چهار سوالی برای بررسی کد پیشنهاد می‌دهد تا اطمینان حاصل شود خط لوله واقعاً نسبت به مستاجر آگاه (Tenant-aware) است:

۱. آیا هر پرس‌وجوی خواندن، لغو و حذف شامل اتصال به مستاجر است؟
۲. آیا یک تلاش مجدد می‌تواند به‌طور ایمن با همان کلید تکرارناپذیری منطقی اجرا شود؟
۳. آیا تبار منبع-به-مشتق پیش از اجرای پاک‌سازی ثبت شده است؟
۴. آیا قرارداد ارائه‌دهنده صراحتاً منطقه، نگهداری، حذف و زیرپردازشگرها را نام برده است؟

عدم پاسخ به این سوالات منجر به سیستمی می‌شود که در دمو کار می‌کند اما در محیط تولیدِ تحت نظارت (Regulated) شکست می‌خورد. یک کلیپ ۱۵ ثانیه‌ای که عالی به نظر می‌رسد اما از یک منطقه جغرافیایی ممنوعه عبور کرده است، یک شغل شکست‌خورده است، نه یک پیروزی.

این تغییر دیدگاه، تمرکز را از «آیا کد کار می‌کند» به «داده‌ها کجا هستند» منتقل می‌کند. این رویکرد توسعه‌دهندگان را مجبور می‌کند مرز پردازشگر را یک الزام قانونی و انطباقی بدانند، نه یک جزئیات فنی. تیم‌های تدارکات و حقوقی باید شرایط پردازشگر را به‌طور جداگانه تایید کنند، زیرا یک لایه‌ی مسیریابی نمی‌تواند تضمین‌های اقامت داده را به صورت مصنوعی ایجاد کند.

برای اعتبارسنجی این رویکرد، توسعه‌دهندگان باید با ثبت نرخ پذیرش رندر، زمان میانه تا رسیدن به نتیجه‌ی آماده، بایت‌های منتقل شده به ازای هر ویدیوی پذیرفته شده، تعداد تلاش‌های مجدد و درصد شغل‌های رد شده توسط سیاست مستاجر شروع کنند.

گام بعدی شما

• در کد خود بررسی کنید که آیا tenant_id در لایه‌ی SQL/NoSQL به‌عنوان بخشی از کلید جست‌وجو (Predicate) استفاده شده یا صرفاً بعد از دریافت داده فیلتر می‌شود.
• برای هر عملیات حساس، یک کلید تکرارناپذیری (Idempotency Key) بر اساس شناسه‌ی مستاجر و مرحله‌ی شغل تعریف کنید.
• لیست ارائه‌دهندگان رسانه‌ای خود را بر اساس مناطق اقامت داده (Data Residency) بازبینی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.