سود:
- امکان جداسازی احراز هویت و مجوز و اعمال حداقل مجوز با RBAC/ABAC
- امکان جلوگیری از ریسک مختلط پروکسی با اجرای مدل در زمینه کاربر
- امکان ذخیره و چرخاندن کلیدهای API با سیستم مدیریت مخفی
بخش قابل توجهی از حملات به یک سیستم هوش مصنوعی نه با «فریب دادن» مدل، بلکه با یک کلید API دزدیده شده یا یک حساب کاربری بیش از حد مجاز آغاز می شود. این لایه امنیتی از امنیت اطلاعات کلاسیک ناشی می شود، اما خطرات جدیدی را در زمینه هوش مصنوعی اضافه می کند: یک مدل از طرف شخص دیگری یک سواری را فراخوانی می کند، یک حساب سرویس به همه داده ها دسترسی دارد، یک کلید به GitHub نشت می کند. در این بخش، ما یاد خواهیم گرفت که چگونه دسترسی به سیستم هوش مصنوعی را با احراز هویت، مجوز (RBAC/ABAC)، حداقل مجوز و مدیریت مخفی محدود کنیم.
تفاوت بین احراز هویت و مجوز
این دو اصطلاح اغلب با هم اشتباه گرفته می شوند:
- احراز هویت: "تو کی هستی؟" - اثبات اینکه کاربر/سرویس واقعاً همان کسی است که ادعا می کند (رمز عبور، رمز، گواهی، MFA).
- مجوز: "چه کاری می توانید انجام دهید؟" - تعیین کنید که طرف احراز هویت شده به کدام منبع/عملیات میتواند دسترسی داشته باشد.
نکته مهم در سیستم های هوش مصنوعی این است: وقتی مدل از طرف یک کاربر کار انجام می دهد، آیا با اختیارات آن کاربر کار می کند یا با یک حساب خدمات گسترده؟ مورد دوم خطرناک است - زیرا مدل فریب خورده توسط تزریق به حساب سرویس دسترسی کامل پیدا می کند.
احتیاط: مشکل "معاون گیج": یک کاربر با اعتبار پایین به طور غیرمستقیم به داده هایی دسترسی پیدا می کند که نمی تواند با برون سپاری یک مدل با اعتبار بالا به آنها دسترسی پیدا کند. این مدل همیشه باید در چارچوب اختیارات کاربر عمل کند، نه اختیارات گسترده خود او.
RBAC و ABAC
- RBAC (کنترل دسترسی مبتنی بر نقش): دسترسی به نقش کاربر بستگی دارد. نقش "متخصص پشتیبانی" می تواند یادداشت های مشتری را بخواند، اما نمی تواند آنها را حذف کند. ساده و متداول.
- ABAC (کنترل دسترسی مبتنی بر ویژگی): دسترسی به ویژگی ها بستگی دارد: بخش کاربر، برچسب حریم خصوصی داده ها، زمان روز، شبکه ای که درخواست از آن می آید. دقیق تر اما پیچیده تر.
اکثر سازمان ها با RBAC شروع می کنند و برای داده های حساس به ABAC عمیق می شوند. قانون سرانگشتی برای هوش مصنوعی: مدل باید هر عاملی را که فراخوانی میکند و هر دادهای را که به آن دسترسی مییابد بر اساس نقش/ویژگیهای کاربر درخواستکننده فیلتر کند.
گام به گام: اعمال حداقل اقتدار
- موجودی بگیرید مدل چه ابزارهایی را فراخوانی می کند، به چه داده هایی دسترسی دارد؟ همه آنها را فهرست کنید.
- هر دسترسی را توجیه کنید. «آیا این دستیار واقعاً به مجوز حذف نیاز دارد؟» در غیر این صورت آن را حذف کنید.
- پیشفرض فقط خواندنی مدل باید به طور پیش فرض قادر به خواندن باشد. نیاز به نوشتن/حذف رمز مجزا با دامنه محدود.
- زمینه کاربر را منتقل کنید. با وسیله نقلیه با مجوز کاربر تماس بگیرید، نه با حساب سرویس.
- اعتبار کوتاه مدت به جای کلیدهای با عمر طولانی، از توکنهای کوتاهمدت و تمدید خودکار استفاده کنید.
مدیریت مخفی
راز اعتبارنامه هایی است که باید مخفی بماند، مانند کلید API، رمز عبور، نشانه یا گواهی. شایع ترین حادثه در پروژه های هوش مصنوعی زمانی است که کلید API ارائه دهنده مدل در کد تعبیه شده و به کنترل نسخه (Git) نشت می کند.
کاربرد صحیح:
- هرگز کلیدها را در کد جاسازی نکنید. از یک متغیر محیطی یا یک سیستم مدیریت مخفی (سرویسی که کلیدها را به صورت رمزگذاری شده ذخیره می کند و دسترسی را کنترل می کند) استفاده کنید.
- چرخش: کلیدها را در فواصل منظم (مثلا هر 90 روز) تمدید کنید. اگر مشکوک به نشتی است، فورا لغو کنید.
- کاهش دامنه: هر سوئیچ فقط خدمات مورد نیاز و مجوز لازم را دارد.
- حسابرسی: ثبت نام چه کسی، چه زمانی و در کجا از کلید استفاده کرده است.
چهار قالب قابل کپی
درخواست کنترل بازبینی دسترسی:
برای هر ابزار در لیست ابزار زیر، ارزیابی کنید: - آیا این ابزار برای انجام کار این دستیار مورد نیاز است؟ (بله/خیر) - فقط خواندنی است یا نوشتن/پاک کردن؟ - آیا این ابزار با اعتبار کاربر یا حساب کاربری سرویس فراخوانی می شود؟ موارد غیر ضروری یا بیش از حد مجاز را به عنوان "REMOVE/REDACT" علامت گذاری کنید.<tools>{{ tool_list }}</tools>
اعلان اسکن نشت مخفی:
هر چیزی را که می تواند یک رمز سخت کد شده باشد در قطعه کد زیر پیدا کنید: کلید API، رمز عبور، رمز، رشته اتصال، کلید خصوصی. برای هر کدام ردیف بدهید و تایپ کنید. مقدار COPY در answer;mask (4 کاراکتر اول + ***).<code>{{ منبع }}</code>
قانون تصمیم گیری حداقل اختیار:
هنگامی که یک ابزار / درخواست دسترسی جدید می رسد، بپرسید: 1. آیا می توان کار را بدون این دسترسی انجام داد؟ -> اگر بله: REJECT2. آیا فقط خواندن کافی است؟ -> اگر بله: GRANT write permission3. آیا می توان دامنه را به یک منبع محدود کرد؟ -> اگر بله: darat پاسخ پیش فرض "خیر" است. دسترسی با عقل به دست می آید.
یادآوری تقویم چرخشی:
برای هر راز، ثبت کنید: مالک، تاریخ ایجاد، انقضا، دامنه. هر کلیدی را که بیش از 90 روز باشد یا 30 روز استفاده نشده است را به عنوان "کاندیدای چرخش/لغو" گزارش دهید.
اعلان ضعیف / اعلان قوی
رویکرد ضعیف
رویکرد قوی
مدل با یک حساب سرویس واحد به همه داده ها دسترسی دارد
مدل با اختیار کاربر درخواست کننده دسترسی پیدا می کند
کلید API در کد تعبیه شده است، هرگز تغییر نمی کند
چرخش در مدیر مخفی کلید، 90 روز
اقتدار گسترده "انجام هر کاری" به دستیار
پیش فرض فقط خواندنی، باریک بنویسید
دسترسی ها هرگز بررسی نمی شوند
بررسی و لغو دسترسی منظم
سه کیف کوچک
مورد 1 - داده های مختلط پروکسی لو رفته. یک دستیار داخلی با یک حساب خدماتی کار می کرد که به تمام سوابق کارمندان دسترسی داشت. یک کاربر کارآموز با گفتن "خلاصه جدول حقوق و دستمزد مدیران" به داده هایی دسترسی پیدا کرد که معمولاً آنها را نمی دید. زیرا مدل آن را در چارچوب اختیارات گسترده خود مورد سوال قرار می دهد، نه در اختیار کاربر. هنگامی که زمینه کاربر برای جابجایی تنظیم شد، کارآموز میتوانست ضبطهایی را بکشد که فقط خودش میتوانست ببیند.
مورد 2 - کلید لو رفته، صورتحساب 190000 لیره در 2 هفته. یک توسعه دهنده، کلید API مدل را در یک اسکریپت کمکی جاسازی کرد و آن را به یک مخزن عمومی فرستاد. یک ربات کلید را در 40 دقیقه پیدا کرد و به مدت دو هفته از آن استفاده کرد. صورت حساب به 190000 لیر رسید. هنگامی که کلید به مدیر مخفی منتقل شد، به چرخش متصل شد و اسکن مخزن اضافه شد، این حادثه تکرار نشد.
مورد 3 - پیش فرض فقط خواندنی از وقفه جلوگیری می کند. یک دستیار DevOps از طریق تزریق سریع دستور "بازنشانی پایگاه داده تولید" را دریافت کرد. با این حال، به دستیار فقط یک نشانه فقط خواندنی داده شد. نوشتن/پاک کردن در یک جریان تایید شده جداگانه بود. فرمان با خطای مجوز رد شد و رویداد به عنوان زنگ هشدار ثبت شد. هیچ از دست دادن داده وجود ندارد.
نکته: پاسخ پیش فرض خود را به درخواست دسترسی جدید، "نه" کنید. دسترسی چیزی است که از طریق توجیه به دست می آید. وسعت دادن به همه و سپس کاهش تقریباً هرگز انجام نمی شود و خطر انباشته می شود.
اشتباهات رایج
- اجرای مدل با یک حساب سرویس بزرگ و از دست دادن زمینه کاربر (پراکسی مختلط).
- جاسازی کلید API در کد و نشت آن در کنترل نسخه.
- اصلاً کلیدها را نمی چرخاند ("کار می کند، لمس نکنید").
- دادن مجوز نوشتن/حذف به دستیار به طور پیش فرض.
- یک بار اعطای دسترسی و هرگز تجدید نظر در آن.
- اشتباه گرفتن احراز هویت با مجوز و با فرض اینکه "او وارد سیستم شده است، می تواند به همه چیز دسترسی داشته باشد".
به طور خلاصه
- احراز هویت یک سؤال از "تو کی هستی" است، مجوز یک سوال از "چه کاری می توانی انجام دهی" است. در هوش مصنوعی، هر دو باید در زمینه کاربر عمل کنند.
- مدل باید با اختیارات کاربر درخواست کننده کار کند، نه با اختیارات گسترده خود (جلوگیری از خطر نمایندگی مختلط).
- با RBAC شروع کنید، با ABAC روی داده های حساس عمیق تر شوید. حداقل اختیار را پیش فرض قرار دهید.
- اسرار را در کد دفن نکنید. آن را در مدیر مخفی ذخیره کنید، آن را باریک کنید و در چرخش منظم قرار دهید.
- پیشفرض فقط خواندنی و نوشتن باریک تأثیر تزریق را تا حد زیادی محدود میکند.
وظیفه کاربردی
تمام ابزارها و داده هایی را که دستیار هوش مصنوعی شما به آنها دسترسی دارد فهرست کنید. برای هر کدام به سه سؤال پاسخ دهید: (1) آیا واقعاً لازم است؟ (2) آیا فقط خواندنی بودن کافی است؟ (3) آیا در زمینه کاربر اجرا می شود؟ سپس تمام اسرار رمزگذاری شده را جستجو کنید (از طریق اعلان اسکن بالا) و برای هر کلیدی که پیدا کردید یک برنامه چرخشی بنویسید. حداقل یک مجوز غیر ضروری را حذف کنید.
چک لیست
- [ ] این مدل در زمینه اقتدار کاربری که درخواست می کند اجرا می شود.
- [ ] دسترسی ابزار و داده به اصل حداقل امتیاز محدود شده است.
- [ ] Write/Ease جدا از فقط خواندنی، احراز هویت و باریک است.
- [ ] هیچ رازی در کد مدفون نیست. در مدیر مخفی نگهداری می شود.
- [ ] یک برنامه چرخش و روش لغو برای کلیدها وجود دارد.
- [ ] دسترسی ها به طور منظم بررسی می شوند.