احراز هویت مشخص میکند شما کی هستید؛ مجوزدهی تصمیم میگیرد که چه کارهایی میتوانید انجام دهید. تعداد رو به افزایشی از اپلیکیشنهای مبتنی بر هوش مصنوعی، هویت کاربر را تنها یک بار در هنگام ورود تأیید میکنند و سپس اجازه میدهند عامل (agent) زیربنایی در طول بقیه نشست (session) روی هر منبعی فعالیت کند؛ این کار در واقع دادن یک «چک سفید امضا» به آن عامل است. این نوع طراحی، راه را برای نشت ناخواسته دادهها، ارسال ایمیلهای ناخواسته یا حتی بهروزرسانیهای مخرب پایگاه داده باز میکند و هر بار که یک دستیار هوش مصنوعی میتواند چندین ابزار را با تأخیر میلیثانیهای فراخوانی کند، این ریسک افزایش مییابد.
چرا این اشتباه تکرار میشود
بیشتر توسعهدهندگان هوش مصنوعی، صفحه ورود را تنها دروازه امنیتی میدانند. کد، رمز عبور یا یک توکن را درخواست میکند، نشست را به عنوان «احراز هویت شده» علامتگذاری میکند و سپس فرض میکند که هر درخواست بعدی ایمن است. در یک اپلیکیشن وب سنتی، کلیکهای کندِ یک کاربر انسانی، یک نقطه کنترل طبیعی ایجاد میکند؛ یک انسان قبل از زدن دکمه «حذف»، مکث میکند. اما یک عامل هوش مصنوعی میتواند دهها فراخوانی ابزار را در عرض چند ثانیه انجام دهد. اگر پلتفرم فقط بپرسد «آیا کاربر وارد شده است؟»، هر فراخوانی همان امتیاز بدون محدودیت را به ارث میبرد.
علت اصلی، راحتی و آسانی است. تیمها اغلب یک حساب کاربری سرویس (service account) تکگانه و طولانیمدت را برای کل اپلیکیشن اختصاص میدهند تا کد مجبور به مدیریت چندین توکن یا محدوده (scope) نباشد. آن حساب معمولاً دارای مجوزهای گستردهای است—خواندن، نوشتن، حذف—در تمام پروژهها. وقتی یک دستیار هوش مصنوعی در آن نشست اجرا میشود، بهطور خودکار آن حقوق را به ارث میبرد، صرفنظر از اینکه آیا وظیفه فعلی واقعاً به آنها نیاز دارد یا خیر.
آنچه در خطر است
- نشت دادهها – عاملی که پس از ورود کاربر میتواند هر فایلی را بخواند، ممکن است بهطور ناخواسته اسناد محرمانه را در پاسخی که بعداً در خارج از سازمان به اشتراک گذاشته میشود، وارد کند.
- اقدامات ناخواسته – دستیار هوش مصنوعیِ یک مهندس پشتیبانی ممکن است صرفاً به این دلیل که نشستِ مهندس هنوز فعال است، یک پرسوجوی SQL خام را روی پایگاههای داده عملیاتی اجرا کند، حتی اگر آن پرسوجو با تیکتی که در حال رسیدگی به آن است، بیارتباط باشد.
- انطباق با مقررات – بسیاری از قوانین حفاظت از دادهها ایجاب میکنند که دسترسیها به حداقل میزان لازم محدود شود. یک مدل مجوزدهی کلی میتواند این اصول را نقض کرده و منجر به بازرسیها یا جریمهها شود.
- هزینه عملیاتی – اشتباهاتی که باعث حذف یا تغییر رکوردها میشوند، تیمها را مجبور به بازگرداندن تغییرات (roll back)، بررسی علتهای اصلی و بازسازی اعتماد کاربران میکنند—که همگی باعث اتلاف وقت و هزینه میشوند.
مرحله مفقوده: مجوزدهی به ازای هر اقدام
مجوزدهی باید در هر «در» در داخل سیستم ارزیابی شود، نه فقط در ورودی اصلی. سوال از «این شخص کیست؟» به «آیا این اقدام خاص روی این منبع خاص میتواند همین الان انجام شود؟» تغییر میکند. پیادهسازی این بررسی نیازمند بازطراحی کامل نیست؛ بلکه تنها به تغییر از یک پرچم (flag) واحد برای نشست، به توکنهای کوتاهمدت و محدودشده (scoped tokens) نیاز دارد.
نحوه عملکرد در عمل
- درخواست توکن با یک محدوده مشخص – وقتی عامل هوش مصنوعی نیاز به فراخوانی یک ابزار دارد، ابتدا توکنی دریافت میکند که دقیقاً مجوزهای مورد نیاز را فهرست میکند (مثلاً
read:ticketیاexecute:sql_query). - اعتبارسنجی توکن برای هر فراخوانی – قبل از اجرای ابزار، سرویس بررسی میکند که آیا توکن شامل محدوده مورد نیاز هست و آیا توکن منقضی شده است یا خیر.
- مطابقت منبع با محدوده – اگر درخواست یک پروژه یا پایگاه داده خاص را هدف قرار دهد، توکن باید صراحتاً اجازه دسترسی به آن شناسه را صادر کرده باشد.
- رد یا اجازه – اگر هر یک از بررسیها با شکست مواجه شود، فراخوانی رد شده و عامل خطایی دریافت میکند که میتواند آن را به کاربر نمایش دهد.
تفاوت در کد ساده است. یک رویکرد «بد» ممکن است به این شکل باشد:
if session.is_authenticated():
tool.run(params)
یک رویکرد «خوب» بررسی را گسترش میدهد:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
الگوی دوم چند خط اضافه میکند اما سیستم را مجبور میکند که برای هر عملیات، سوال درستی را بپرسد.
استانداردهایی که کار را آسانتر میکنند
محدودههای OAuth 2.0 در حال حاضر روشی پرکاربرد برای محدود کردن کارهای یک توکن ارائه میدهند. توسعهدهندگان با صدور توکنهای دسترسی کوتاهمدت که محدودههایی مانند project:1234:write یا email:send را کدگذاری میکنند، میتوانند برای انجام مرحله تأیید بر کتابخانههای موجود تکیه کنند.
روش جدیدتر Rich Authorization Requests (RFC 9396) این ایده را گسترش میدهد و به کلاینت اجازه میدهد به جای تعریف از پیش یک لیست ایستا، مجوزهای دقیق را در زمان اجرا درخواست کند. این انعطافپذیری زمانی مفید است که یک گردش کار هوش مصنوعی ممکن است نیاز داشته باشد بر اساس قصد کاربر، قابلیتها را در لحظه اضافه یا حذف کند.
استدلال مخالف: سادگی در مقابل امنیت
برخی تیمها استدلال میکنند که بررسیهای مربوط به هر اقدام (per-action checks)، باعث افزایش تأخیر و پیچیدگی کد میشود، بهویژه زمانی که دستیار هوش مصنوعی باید ابزارهای زیادی را با توالی سریع فراخوانی کند. آنها اشاره میکنند که استفاده از یک توکن نشست (session token) واحد، از بار اضافیِ دریافت و اعتبارسنجی یک توکن جدید برای هر فراخوانی جلوگیری میکند. با این حال، این معامله، منجر به افزایش چشمگیر احتمال سوءاستفاده میشود. سرویسهای مدرن اعتبارسنجی توکن بهگونهای طراحی شدهاند که در مقیاس میکروثانیه عمل کنند و رفتوبرگشتهای اضافی شبکه (network round-trip) را میتوان بدون قربانی کردن «اصل حداقل دسترسی» (principle of least privilege)، بهصورت دستهای یا کششده انجام داد. در محیطهایی که یکپارچگی دادهها و انطباق با قوانین غیرقابل مذاکره هستند، کاهش ریسک بر هزینه ناچیز عملکردی غلبه میکند.
آنچه باید در آینده زیر نظر داشت
- پذیرش توکنهای محدودشده (scoped tokens) در SDKهای هوش مصنوعی – بهروزرسانیهای ابزارهای اصلی پلتفرمهای هوش مصنوعی را دنبال کنید؛ بسیاری از آنها شروع به ارائه توابع کمکی برای محدودههای (scopes) مبتنی بر OAuth کردهاند.
- چارچوبهای سیاستبهعنوان-کد (Policy-as-code) – راهکارهای نوظهور به تیمها اجازه میدهند قوانین مجوزدهی را در یک فایل بیانی (declarative) تعریف کنند و آنها را بهطور خودکار در زمان اجرا (runtime) اعمال نمایند.
- لاگهای حسابرسی که تصمیمات مربوط به هر اقدام را آشکار میکنند – با ثبت هر بررسی مجوز توسط پلتفرمهای بیشتر، سازمانها دید بهتری نسبت به این موضوع پیدا خواهند کرد که کدام اقدامات هوش مصنوعی مجاز یا مسدود شدهاند، که این امر به اصلاح سیاستهای آینده کمک میکند.
نتیجهگیری
در نظر گرفتن یک نشستِ واردشده (logged-in session) به عنوان مجوزی برای انجام هر کاری، نسخهای برای پیامدهای ناخواسته است. با انتقال تصمیم مجوزدهی از لحظه ورود به هر فراخوانی جداگانه ابزار — و با بهرهگیری از توکنهای محدودشده و کوتاهمدت — برنامههای هوش مصنوعی میتوانند راحتیِ عوامل خودگردان (autonomous agents) را حفظ کنند و در عین حال از دادهها محافظت کرده، با مقررات مطابقت داشته باشند و از حوادث پرهزینه جلوگیری کنند. خطوط اضافی کد، بهای اندکی برای سیستمی است که هر بار که تلاشی برای انجام یک اقدام صورت میگیرد، سوال درست را میپرسد.