درون معماری جدید SaaS برای اجرای پرس‌وجوهای زبان طبیعی بدون ریسک امنیتی

تصور کنید یک خطای کوچک در دستور WHERE در یک پرس‌وجوی SQL تولیدشده توسط هوش مصنوعی، باعث شود داده‌های مالی محرمانه یک مشتری مستقیماً در اختیار مشتری دیگری قرار گیرد. این ریسک فاجعه‌بار، سال‌هاست که تبدیلِ جست‌وجوی داده‌ها با زبان طبیعی را به رویای خطرناکی برای ارائه‌دهندگان SaaS تبدیل کرده است. با این حال، یک راهنمای فنی که در ۳۱ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، معماری عملیاتی و آماده‌ای را تشریح کرد که هوش مصنوعی را به‌طور کامل از مرزهای امنیتی خارج می‌کند.

هر محصول SaaS در نهایت با درخواست داده‌ای مواجه می‌شود که برای آن برنامه‌ریزی نکرده است. برای مثال، ممکن است مشتری ایمیلی بفرستد و بپرسد: «می‌توانید بگویید در سه ماه گذشته، هر ماه چند صندلی فعال داشتیم؟». از آنجایی که داشبوردها فقط می‌توانند تعداد محدودی از سوالات پیش‌بینی‌شده را پاسخ دهند، مهندسان اغلب مجبور می‌شوند پرس‌وجوهای یک‌باره (one-off queries) بنویسند و نتایج را در پاسخ ایمیل کپی کنند. هدف نهایی این است که مشتریان بتوانند با زبان ساده بپرسند «نرخ ریزش (churn) ما در ماه گذشته چقدر بود؟» یا «کدام یک از پروژه‌های من بیشترین تیکت‌های باز را دارد؟» و پاسخ‌ها را مستقیماً از داده‌هایی که به نام آن‌ها ذخیره شده است، دریافت کنند. این نیاز به دسترسی زنده به داده‌ها، مشابه رویکردی است که افزونه Sohay برای متصل کردن داده‌های زنده ووکامرس به چت‌بات‌ها به کار گرفت تا پاسخ‌های دقیق‌تری به کاربران ارائه دهد.

بسیاری از اپلیکیشن‌های مدرن SaaS بر اساس مدل «چند‌مستاجری» (Multi-tenant) عمل می‌کنند. این بدان معناست که داده‌های هزاران مشتری مختلف در جداول یکسانی قرار دارند و تنها توسط یک ستون مانند tenant_id (یا account_id یا org_id) از یکدیگر متمایز می‌شوند. برای مثال، یک جدول subscriptions ممکن است شامل ستون‌هایی برای id ،tenant_id ،plan ،seats ،status (مانند 'active'، 'canceled' یا 'trialing') و created_at باشد.

به‌طور سنتی، توسعه‌دهندگان برای جلوگیری از نشت داده‌ها، فیلترهایی مانند AND tenant_id = $1 را به‌صورت دستی به تک‌تک پرس‌وجوها در کد اپلیکیشن اضافه می‌کنند. فراموش کردن تنها یک خط از این کد، منجر به یک نقض امنیتی فاجعه‌بار می‌شود. برای حل این مشکل، معماری پیشنهادی، مسئولیت جداسازی را از لایه‌ی اپلیکیشن به خودِ پایگاه‌داده منتقل می‌کند. این رویکرد تضمین می‌کند که فارغ از اینکه هوش مصنوعی چه کدی بنویسد، دیتابیس به‌صورت فیزیکی نمی‌تواند ردیف‌های متعلق به مستاجر (مشتری) دیگر را بازگرداند. این لایه‌ی حفاظتی در کنار راهکارهای پاک‌سازی PII برای جلوگیری از نشت داده‌های حساس در چت‌های B2B، امنیت جامع‌تری را برای سازمان‌ها فراهم می‌کند.

لایه اول: جداسازی در سطح دیتابیس

اولین خط دفاعی، قابلیت امنیت سطح ردیف (Row-Level Security یا RLS) در PostgreSQL است. RLS به مدیران اجازه می‌دهد سیاستی (Policy) را به یک جدول متصل کنند که ردیف‌ها را بر اساس مقدار یک متغیر در نشست (Session) زمان اجرا فیلتر کند. در این حالت، به‌جای اینکه پرس‌وجو مشخص کند کدام مستاجر مد نظر است، دیتابیس این موضوع را به‌طور خودکار اعمال می‌کند.

طبق گزارش dev.to، این فرآیند شامل فعال کردن RLS روی جدول هدف با استفاده از دستور ALTER TABLE subscriptions ENABLE ROW LEVEL SECURITY و ایجاد سیاستی است که tenant_id را با یک متغیر نشست، مانند app.current_tenant تطبیق دهد. وقتی یک پرس‌وجو می‌رسد، دیتابیس به‌طور بی‌صدا فیلتر مستاجر را به ابتدای اسکن اضافه می‌کند. همان‌طور که در یکی از نوشته‌های Crunchy Data آمده است، در این حالت «هیچ شانسی برای فراموش کردن فیلتر مستاجر وجود ندارد» زیرا Postgres از اساس اجازه اجرای پرس‌وجوی متقاطع بین مستاجران را نمی‌دهد.

دو نکته فنی حیاتی وجود دارد که این سیستم را برای محیط‌های عملیاتی ایمن می‌کند:

• استفاده از SET LOCAL به‌جای SET: در محیط‌هایی که از Connection Poolerها استفاده می‌کنند، توسعه‌دهندگان باید از SET LOCAL استفاده کنند. این دستور، هویت مستاجر را تنها به یک تراکنش (Transaction) واحد متصل می‌کند. استفاده از دستور استاندارد SET باعث می‌شود مقدار برای کل نشست باقی بماند و در نهایت، به دلیل اینکه Poolerها اتصالات فیزیکی را بین درخواست‌های مختلف به اشتراک می‌گذارند، ممکن است هویت یک مشتری به مشتری بعدی منتقل شود.
• اندیس‌گذاری ترکیبی (Composite Indexing): از آنجایی که RLS عملاً عبارت tenant_id = ? را به ابتدای هر اسکن اضافه می‌کند، ستون tenant_id باید ستون پیشرو (Leading Column) در اندیس‌ها باشد. برای مثال، توسعه‌دهنده باید از CREATE INDEX idx_subs_tenant_status ON subscriptions (tenant_id, status) استفاده کند. بدون این کار، عملکرد پرس‌وجوها در جداول بزرگ می‌تواند تا دو مرتبه بزرگی (۱۰۰ برابر) افت کند.

لایه دوم: کارگزار MCP

در حالی که RLS جداسازی را مدیریت می‌کند، یک کارگزار (Broker) برای مدیریت اتصال مورد نیاز است؛ زیرا شما نمی‌توانید رشته اتصال (Connection String) دیتابیس را برای مشتری ایمیل کنید. این راهنما بر پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) تأکید می‌کند که یک استاندارد باز برای اتصال دستیارهای هوش مصنوعی به ابزارهای داده است. کارگزار در واقع به عنوان دروازه‌بان بین هوش مصنوعی و دیتابیس عمل می‌کند.

وقتی مشتری سوالی می‌پرسد، کارگزار توالی مشخصی از عملیات را انجام می‌دهد:

۱. توکن OAuth مشتری را برای استخراج tenant_id منحصر‌به‌فرد او اعتبارسنجی می‌کند.
۲. یک اتصال به دیتابیس با استفاده از اعتبارنامه‌های امنی باز می‌کند که مدل هوش مصنوعی هرگز آن‌ها را نمی‌بیند.
۳. دستور SET LOCAL app.current_tenant = <tenant_id> را با استفاده از شناسه استخراج‌شده اجرا می‌کند.
۴. کد SQL تولیدشده توسط هوش مصنوعی را — که اکنون به‌طور خودکار توسط RLS فیلتر شده است — اجرا کرده و تنها نتایج فیلترشده را بازمی‌گرداند.

این ساختار چندین تضمین امنیتی ارائه می‌دهد:

• عدم افشای اعتبارنامه‌ها: کارگزار اتصال دیتابیس را در اختیار دارد؛ مدل هوش مصنوعی و کلاینت هرگز اعتبارنامه‌های خام، توکن‌ها یا اسرار (Secrets) را نمی‌بینند.
• جلوگیری از نشت متقاطع: RLS هر پرس‌وجو را در سطح دیتابیس بر اساس tenant_id فیلتر می‌کند، حتی اگر هوش مصنوعی یک پرس‌وجوی بد یا اشتباه بنویسد.
• جلوگیری از تغییرات تصادفی: با دادن یک نقش «فقط خواندنی» (Read-only/SELECT only) به کارگزار، هوش مصنوعی می‌تواند داده‌ها را کاوش کند اما نمی‌تواند آن‌ها را تغییر دهد یا حذف کند.
• ابطال دسترسی: توکن‌های OAuth به‌صورت متمرکز قابل ابطال هستند و این تضمین می‌کند که هیچ رمز طولانی‌مدتی در پرامپت‌ها، لاگ‌های چت یا فایل‌های تنظیمات باقی نمی‌ماند.
• قابلیت حسابرسی (Auditability): کارگزار برای هر درخواست، سوال زبان طبیعی، SQL تولیدشده و نتیجه را ثبت (Log) می‌کند.

توسعه‌دهندگان می‌توانند این کارگزار را خودشان بسازند یا از یک سرور MCP مدیریت‌شده استفاده کنند. برای مثال، Draxlr پیاده‌سازی‌ای ارائه می‌دهد که از طریق OAuth متصل شده و به‌طور پیش‌فرض Read-only است.

پیشگیری از خطاهای رایج در پیاده‌سازی

این معماری برای امن ماندن، نیازمند پایبندی سخت‌گیرانه به چندین قانون دیتابیس است. به‌طور پیش‌فرض، مالکان جدول (Table Owners) در Postgres از سیاست‌های RLS عبور می‌کنند. برای جلوگیری از این اتفاق، توسعه‌دهندگان باید دستور ALTER TABLE subscriptions FORCE ROW LEVEL SECURITY را روی تمام جداول وابسته به مستاجر اجرا کنند.

علاوه بر این، نقش‌هایی که دارای امتیاز BYPASSRLS یا دسترسی Superuser هستند، تمام سیاست‌ها را نادیده می‌گیرند. بنابراین کارگزار باید با استفاده از یک نقش اختصاصی، کم‌دسترسی و فقط خواندنی متصل شود. در نهایت، چون RLS به‌طور پیش‌فرض برای جداول جدید غیرفعال است، اضافه کردن سیاست مستاجر باید به بخشی اجباری از چک‌لیست مهاجرت (Migration) دیتابیس تبدیل شود، یا توسعه‌دهندگان باید تستی بنویسند که در صورت نبود سیاست RLS برای یک جدول، با خطا مواجه شود.

سایر اشتباهات حیاتی که باید از آن‌ها اجتناب کرد عبارتند از:

• اعتماد به هوش مصنوعی برای اضافه کردن فیلتر: اگر تنها حفاظ شما پرامپتی باشد که به هوش مصنوعی می‌گوید «بر اساس مستاجر فیلتر کن»، در واقع هیچ حفاظی ندارید. RLS است که اشتباهات هوش مصنوعی را بی‌ضرر می‌کند.
• استفاده از SET به‌جای SET LOCAL: این مورد همچنان نامحسوس‌ترین دلیل نشت داده در محیط‌های دارای Connection Pool است.
• نبود اندیس‌های ترکیبی: نتایجی که درست هستند اما کند بازمی‌گردند، زمانی که مشتریان منتظر پاسخ هستند، همچنان به عنوان «باگ» شناخته می‌شوند.

مسیر یک درخواست در عمل

تصور کنید مشتری می‌پرسد: «تعداد صندلی‌های فعال ما در پایان ماه پیش چقدر بود؟». هوش مصنوعی که تنها به Schema (ساختار) دسترسی دارد و نه به خودِ داده‌ها، یک دستور ساده تولید می‌کند: SELECT sum(seats) AS active_seats FROM subscriptions WHERE status = 'active'.

کارگزار، زمینه نشست (Session Context) را با استفاده از توکن مشتری، روی آن مشتری خاص تنظیم می‌کند. سپس RLS محدوده تابع sum را تنها به ردیف‌های متعلق به آن مستاجر محدود می‌کند. مشتری عدد درست — برای مثال ۱۴۲ — را دریافت می‌کند، بدون اینکه هرگز SQL را یاد گرفته باشد یا دسترسی مستقیم به دیتابیس داشته باشد. این مکانیسم فارغ از اینکه کاربر از طریق Claude، Cursor، ChatGPT یا یک جعبه چت داخلی اپلیکیشن سوال بپرسد، یکسان عمل می‌کند، زیرا جداسازی در دیتابیس است، نه در کلاینت.

این سازوکار، هوش مصنوعی را از یک «عامل امنیتی مورد اعتماد» به یک «ابزار رفاهی ساده برای نوشتن دستورات SELECT» تبدیل می‌کند. امنیت در اینجا ریاضیاتی و ساختاری است، نه احتمالی.

این تغییر در رویکرد به این معناست که درخواست‌های «می‌توانید این عدد را برای ما استخراج کنید؟» دیگر به یک تیکت پشتیبانی دستی برای مهندسان تبدیل نمی‌شود، بلکه به یک ویژگی «سلف‌سرویس» تبدیل می‌گردد. این امر صنعت را از «مهندسی پرامپت» برای امنیت، به سمت «مهندسی معماری» سوق می‌دهد.

برای توسعه‌دهندگان، گام فوری بعدی، حسابرسی (Audit) پرس‌وجوهای فعلی چند‌مستاجری است. اگر منطق جداسازی شما صرفاً در کد اپلیکیشن قرار دارد، شما تنها به اندازه یک دستور WHERE فراموش‌شده با یک نشت داده فاصله دارید. انتقال به RLS تنها راه ایمن برای در معرض قرار دادن داده‌های عملیاتی در اختیار مدل‌های زبانی بزرگ (LLMs) است.

گام بعدی شما

• بررسی کنید آیا منطق جداسازی داده‌های شما فقط در لایه‌ی کد اپلیکیشن است یا در سطح دیتابیس؛ اگر اولی است، شما در یک قدمی نشت داده هستید.
• برای پیاده‌سازی سریع، از سرورهای مدیریت‌شده MCP مانند Draxlr که به‌صورت پیش‌فرض Read-only هستند استفاده کنید.
• در چک‌لیست مهاجرت دیتابیس خود، فعال‌سازی RLS را برای تمام جداول حساس به tenant اجباری کنید.

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