همزمان با ادغام سریع مدلهای زبانی بزرگ (LLMs) در زیرساختهای تولیدی سازمانها، بحثها بهطور خطرناکی از «چگونه این را بسازیم؟» به «چگونه این را ایمن کنیم؟» تغییر یافته است. در حالی که احراز هویت چه کسی بودن کاربر را تأیید میکند، مجوزدهی تعیین میکند که آن کاربر در زمینه هوش مصنوعی به چه چیزی دسترسی دارد. این تمایز حیاتی است زیرا مدلهای هوش مصنوعی اغلب دادههای حساس را از طریق پنجرههای زمینه خود در معرض نمایش قرار میدهند، که سیاستهای مجوزدهی قوی را برای پذیرش سازمانی غیرقابل مذاکره میسازد.
چالش منحصر به فرد مجوزهای هوش مصنوعی
امنیت API سنتی اغلب بر کنترل دسترسی مبتنی بر نقش (RBAC) ساده تکیه دارد. با این حال، برنامههای هوش مصنوعی متغیرهای پویایی را معرفی میکنند: پرسوجوی کاربر، زمینه بازیابی شده و خروجی مدل. ممکن است کاربری مجاز به پرسیدن یک سوال باشد، اما مجاز به مشاهده قطعه سند خاصی که از پایگاه داده برداری برای پاسخ به آن بازیابی شده، نباشد. این نیازمند رویکردی دقیقتر است که اغلب RBAC را با کنترل دسترسی مبتنی بر ویژگی (ABAC) ترکیب میکند.
در یک مدل ABAC، تصمیمگیریها بر اساس ویژگیهای کاربر، منبع، عمل و محیط انجام میشود. برای یک خط لوله هوش مصنوعی، این بدان معناست که مجوزها در مراحل متعددی ارزیابی شوند: قبل از اینکه پرسوجو به مدل برسد (ورودی پرامپت) و پس از بازیابی زمینه (دسترسی به دادههای برداری).
پیادهسازی مجوزدهی مبتنی بر سیاست
برای مدیریت این پیچیدگی، باید منطق مجوزدهی را از کد برنامه جدا کنیم. استفاده از یک موتور سیاست اختصاصی مانند Open Policy Agent (OPA) امکان مدیریت متمرکز و اعلانی سیاستها را فراهم میکند. این اطمینان حاصل میکند که قوانین امنیتی را میتوان بدون استقرار مجدد کل سرویس هوش مصنوعی بهروز کرد.
سناریویی را در نظر بگیرید که یک نماینده پشتیبانی از طریق یک LLM پایگاه داده مشتریان را پرسوجو میکند. سیستم باید اطمینان حاصل کند که نماینده فقط میتواند به دادههای مرتبط با منطقه خاص خود دسترسی داشته باشد. در اینجا نحوه ساختاردهی یک سیاست در Rego (زبان سیاست OPA) برای اعمال این مورد آورده شده است:
package ai.authorization
# اگر منطقه کاربر با منطقه رکورد مطابقت نداشته باشد، دسترسی را رد کنید
deny[msg] {
input.user.role == "support_agent"
input.request.context.record.region != input.user.allowed_regions[_]
msg := "دسترسی رد شد: منطقه کاربر با منطقه رکورد مطابقت ندارد"
}
# دسترسی را برای مدیران صرفنظر از منطقه مجاز کنید
allow {
input.user.role == "admin"
}
# رد پیشفرض
allow {
input.user.role == "user"
}
در این مثال، موتور سیاست درخواست را قبل از پردازش توسط LLM مداخله میکند. اگر input.request.context حاوی رکوردی از منطقهای باشد که کاربر مجاز به مشاهده آن نیست، موتور یک تصمیم رد را برمیگرداند و از نشت داده در منبع جلوگیری میکند.
اجرای زمان اجرا و فیلتر کردن زمینه
مجوزدهی فقط درباره مسدود کردن درخواستها نیست؛ بلکه درباره پاکسازی خروجیها نیز هست. حتی اگر کاربری مجاز به پرسیدن یک سوال باشد، پاسخ تولید شده ممکن است به طور ناخواسته حاوی اطلاعات شناسایی شخصی (PII) از یک منبع غیرمجاز باشد. لایههای امنیتی پیشرفته هوش مصنوعی یک «لایه فیلتر» پس از تولید را پیادهسازی میکنند.
این شامل استفاده از یک مدل سبکوزن ثانویه یا یک موتور قوانین مبتنی بر regex برای اسکن خروجیها برای الگوهای حساس است. اگر نقضی تشخیص داده شود، سیستم میتواند اطلاعات را حذف کند یا یک مکانیسم جایگزین را فعال کند، مانند بازگرداندن پاسخ عمومی «من به آن اطلاعات دسترسی ندارم».
import json
def sanitize_response(response: str, user_id: str) -> str:
"""
مرحله پسپردازش برای پاکسازی خروجی LLM بر اساس مجوزهای کاربر.
"""
sensitive_patterns = re.compile(r'\b\d{3}-\d{2}-\d{4}\b') # الگوی نمونه شماره بیمه اجتماعی
if not has_permission(user_id, "view_pii"):
sanitized = sensitive_patterns.sub("[REDACTED]", response)
return sanitized
return response
نتیجهگیری
ایمنسازی برنامههای هوش مصنوعی نیازمند یک تغییر پارادایم از بررسیهای مجوز ایستا به مجوزدهی پویا و آگاه از زمینه است. با پیادهسازی ABAC، استفاده از موتورهای سیاست مانند OPA و اجرای پاکسازی پس از تولید، توسعهدهندگان میتوانند خط لولههای هوش مصنوعی قوی بسازند که مرزهای داده را رعایت میکنند. همانطور که قابلیتهای هوش مصنوعی رشد میکند، سطح خطر امنیتی نیز افزایش مییابد. اولویت دادن به مجوزدهی اطمینان حاصل میکند که نوآوری به بهای انطباق و اعتماد تمام نمیشود.