تصور کنید یک کاربر ساده با یک پرسش دوستانه در چتبات، تمام دادههای محرمانه مشتریان دیگر شما را استخراج کند. اگر سیستم تحلیل دادههای شما بر پایه یک حساب خدماتی قدرتمند باشد، هر «سوال ساده» میتواند به یک کوئری مخرب در انبار داده تبدیل شود که تمام حصارهای امنیتی را دور میزند.
این مشکل زمانی رخ میدهد که رابطهای کاربری (UI) دارای چکهای امنیتی هستند، اما مسیر هوش مصنوعی — که مستقیماً به دیتابیس متصل است — این لایهها را نادیده میگیرد. در واقع، خطر اصلی نه در عنوان یک نمودار اشتباه، بلکه در کوئریهای انبار دادهای است که کاربر هرگز نباید اجازه اجرای آنها را داشته باشد.
زمینه: تلهٔ دسترسیها
امروزه کاربران میخواهند بپرسند «کدام حسابها این ماه در حال ریزش هستند؟» و فوراً پاسخ بگیرند. اما این نیاز، یک تلهٔ امنیتی ایجاد میکند. اگر تحلیلگر هوش مصنوعی شما از طریق یک حساب خدماتی (Service Account) — شبیه به یک کلید 万能 که تمام درهای ساختمان را باز میکند — متصل شود، هر سوال کاربر سطح دسترسی آن کلید قدرتمند را به ارث میبرد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، شکاف بین «توانایی مدل» و «حفاظهای سیستمی» همواره نقطه ضعف اصلی است. طبق گزارش منتشر شده در dev.to، شکست اصلی در اینجا «قطع شدن زنجیره هویت» است. در تحلیلهای سنتی، زنجیره به این صورت است: کاربر ← جلسه برنامه ← مجوز تحلیل ← کوئری دیتابیس. اما در هوش مصنوعی، زنجیره به این شکل تغییر میکند: کاربر ← جلسه برنامه ← سرویس هوش مصنوعی ← حساب خدماتی ← کوئری دیتابیس. در این حالت، انبار داده فقط یک هویت را میبیند: حساب خدماتی هوش مصنوعی.
به نقل از مستندات فنی توسعهدهندگان، از ژوئیه ۲۰۲۶، صنعت در حال گذار از الگوهای سادهٔ «چت با اسناد» به سمت «پرسش از دادههای زنده کسبوکار» است. این تغییر باعث شده نیاز به کوئریهای محدود به مستاجر (Tenant-scoped)، هویتهای قابل حسابرسی و تعاریف یکپارچه از متریکها به یک اولویت تبدیل شود. این پیچیدگی در مدیریت دسترسیها، در واقع بخشی از چالش بزرگتری است که در آن روابط دادهای به گلوگاه واقعی عاملهای هوش مصنوعی در سازمانها تبدیل میشوند و پیادهسازی امنیت ردیفی را دشوارتر میکنند.
معماری یک تحلیلگر امن
برای حل این مشکل، باید با هوش مصنوعی به عنوان یک «برنامهریز غیرقابل اعتماد» برخورد کرد، نه لایه اجرایی. مدل لزوماً بدخواه نیست، اما هر دادهای را که مرتبط به نظر برسد جستوجو میکند. یک طراحی امن باید یک خط لوله لایهای را پیاده کند:
پرسش کاربر ↓ بستر احراز هویت ↓ برنامهریز هوش مصنوعی ↓ درگاه تحلیل ↓ موتور سیاستگذاری ↓ لایه معنایی ↓ کامپایلر کوئری ↓ انبار داده ↓ نتیجه محدود شده + شواهد ↓ پاسخ یا نمودار
درگاه تحلیل (Analytics Gateway) مرز اصلی امنیتی است و پنج وظیفه حیاتی دارد:
- تایید هویت کاربر و مستاجر (Tenant)
- تصمیمگیری درباره مجموعهدادهها و متریکهای قابل مشاهده
- تبدیل تعاریف معنایی تایید شده به کوئریهای امن
- اعمال فیلترهای سطح ردیف و ستون
- ثبت پرسش، کوئری و تصمیمات سیاستگذاری برای حسابرسی (Audit)
این ساختار مرزی ایجاد میکند که مدل نتواند با «مهندسی پرامپت» (Prompt Engineering) — همان هنر سؤال درست پرسیدن برای دور زدن محدودیتها — آن را بشکند.
از SQL به قصد کاربر (Intent)
تبدیل مستقیم زبان طبیعی به SQL (NL2SQL) خطرناک است چون مدل ممکن است اتصال فیلتر مستاجر را فراموش کند، ستونهای حساس را انتخاب کند یا از جدولهای مخفی استفاده کند. الگوی امنتر، تبدیل «قصد به کوئری معنایی» است. در این مدل، هوش مصنوعی قصد کاربر را به یک فرمت ساختاریافته استخراج میکند:
- متریک: active_accounts
- ابعاد: [plan, region]
- فیلترها: [ { "field": "period", "operator": "last_30_days" } ]
- بصریسازی: bar_chart
سپس یک کامپایلر در سمت سرور، SQL را بر اساس سیاستهای تعریف شده میسازد. این کار تضمین میکند که مدل نتواند tenant_id را حذف کند یا دادههای حقوق و دستمزد را فراخوانی کند.
جزئیات: کنترلهای امنیتی
شیء بستر دسترسی (Access Context Object)
هر درخواست باید با یک بستر دسترسی که توسط سرور ساخته شده آغاز شود (هرگز نباید توسط مرورگر یا مدل ارسال شود). این شیء شامل userId ،tenantId و نقش کاربر (مثلاً admin یا viewer) است و تصمیم میگیرد در آن جلسه چه دادهای واقعاً وجود دارد.
کاتالوگ متریکها
برای جلوگیری از تعریفهای متناقض (مثلاً تعریف متفاوت «درآمد» در دو پاسخ مختلف)، باید یک کاتالوگ متریک بسازید. مدل میتواند این متریک را توضیح دهد، اما اجازه ندارد تعریف آن را بهصورت لحظهای تغییر دهد.
اجرای نظارت چندلایه
امنیت سطح ردیف (Row-Level Security یا RLS) — یعنی تعیین اینکه هر کاربر فقط رکوردهای مجاز خود را ببیند — باید در سه سطح اعمال شود:
- RLS بومی دیتابیس: قدرتمندترین روش که قانون در کنار داده قرار دارد (مانند Postgres).
- فیلترینگ درگاه: تزریق فیلترهای مستاجر توسط کد سرور (نه مدل) به کوئری.
- مجموعهدادههای معنایی محدود: مدل اصلاً نام جدولهای حساس را دریافت نمیکند.
حفاظت فراتر از ردیف
علاوه بر ردیفها، کنترل ستونها برای فیلدهایی مانند ایمیل یا کلیدهای API ضروری است. به جای نمایش مقادیر خام، از دستهبندیها (Bands) استفاده کنید؛ مثلاً به جای مبلغ دقیق صورتحساب، عبارت «محدوده ۱ تا ۵ هزار دلار» را نمایش دهید.
مدیریت هزینهها و پیگیریها
پرسشهای زبان طبیعی میتوانند کوئریهای بسیار سنگین ایجاد کنند. باید بودجهای برای تعداد ردیفهای بازگشتی، زمان اجرا و محدودیتهای Join تعیین کنید. اگر پرسشی بیش از حد گسترده بود، سیستم باید پاسخ دهد: «میتوانم پاسخ دهم اگر بازه زمانی را محدود کنید».
پرسشهای پیگیرانه (Follow-up) مسیرهای نشت داده مخفی هستند. عباراتی مثل «حالا این را با بقیه مقایسه کن»، کلمه «بقیه» میتواند به تمام مشتریان انبار داده اشاره کند. برای حل این مشکل، باید وضعیت گفتگو (Conversation State) شامل active_scope را ذخیره کنید.
ردپای حسابرسی: رسید پاسخ
هر پاسخ هوش مصنوعی باید یک «رسید پاسخ» (Answer Receipt) داشته باشد. این لاگ شامل هویت کاربر، قصد نرمالشده، فیلترهای اعمال شده و تعداد ردیفهای بازگشتی است تا هر پاسخ قابل بازسازی و بررسی باشد.
اشتباهات رایج
- قرار دادن فیلتر مستاجر در پرامپت (پرامپت راهنماست، سیاست اجرایی است).
- دادن دسترسی کامل به Schema (نام جدولها را لو ندهید).
- ارسال ردیفهای خام برای خلاصهسازی (فقط نتیجه تجمیعی را بفرستید).
- کش کردن پاسخها بدون کلیدهای Scope (کش باید شامل نقش و مستاجر باشد).
- اعتماد به نمودارهای تکمیلهای (نموداری با یک ستون میتواند درآمد یک مشتری خاص را فاش کند).
گام بعدی شما
- سه متریک امن (مثل روند استفاده یا حجم تیکتها) را انتخاب کرده و برای آنها بستر دسترسی سرور بسازید.
- یک درگاه تحلیل کوچک برای تبدیل کوئریهای معنایی و تزریق اجباری فیلترها طراحی کنید.
- تستهای «تلاش برای دسترسی به داده مستاجر دیگر» را در چرخه CI/CD خود بگنجانید.
اما مدیریت هزینه این کوئریها در مقیاس هزاران کاربر، چالشی دیگر است — به تحلیل ما درباره استراتژیهای کاهش هزینه استنتاج مراجعه کنید.
گفتگو