در بارهای کاری هوش مصنوعی و محاسبات سنگین، سیستمعامل فقط بستری برای اجرای برنامه نیست؛ بخشی از مسیر داده، زمانبندی محاسبات، دسترسی به حافظه و صحت عملیاتی سامانه است. تغییر نسخهٔ کرنل، درایور یا کتابخانهٔ سطح پایین میتواند بدون تغییر کد مدل، عملکرد، مصرف حافظه، پایداری و حتی تکرارپذیری نتیجه را تغییر دهد.
امنیت این زیرساخت نیز از همین زنجیره پیروی میکند. اگر کرنل، درایور GPU، runtime کانتینر و ابزار تخصیص منابع با هم سازگار و قابل ممیزی نباشند، کنترلهای لایهٔ مدل بر بستری شکننده اجرا میشوند. از این منظر، امنیت AI از کرنل و GPU آغاز میشود، هرچند به آنها محدود نمیماند.
سازگاری خاموش، از شکست آشکار خطرناکتر است
ناسازگاری باینری همیشه با crash آغاز نمیشود. سیستم بوت میشود، سرویس بالا میآید و بار کاری اجرا میشود، اما رفتار زمانبندی، مدیریت حافظه یا وقفهها کمی تغییر کرده است. در آموزش طولانی یا شبیهسازی HPC، همین تفاوت میتواند به افت عملکرد، توقف نادر یا نتیجهٔ غیرقابل بازتولید منجر شود.
رابط باینری کرنل و ماژولها قراردادی نادیدنی است. برخی زیستبومها با ثابتنگهداشتن ABI و backportکردن وصلهها تلاش میکنند این قرارداد را در چرخهای طولانی حفظ کنند. برخی دیگر تغییر را میپذیرند، اما آن را با بستهبندی ماژول، آزمون و مسیر بازگشت مهار میکنند. هیچ رویکردی بهتنهایی درستتر نیست؛ پرسش اصلی این است که سازمان بداند چه چیز ثابت مانده، چه چیز تغییر کرده و چگونه نتیجه را اعتبارسنجی میکند.
در محیط آفلاین، این موضوع سختتر است. درایوری که پس از ارتقای کرنل به build محلی نیاز دارد، کامپایلر، header، سورس و ابزار توسعه را به سامانهٔ عملیاتی وارد میکند. این کار هم سطح حمله را افزایش میدهد و هم شکست کامپایل را به قطع کامل دسترسی GPU پیوند میزند. بستهٔ ازپیشساخته و آزمودهشده میتواند این ریسک را کم کند، مشروط بر اینکه زنجیرهٔ تولید و امضای آن قابل اعتماد باشد.
GPU یک قطعهٔ جانبی معمولی نیست
در بار کاری کلاسیک، خرابی یک شتابدهنده ممکن است فقط عملکرد را کم کند. در AI، GPU میتواند شرط امکان اجرای مدل باشد. ظرفیت و پهنایباند حافظه تعیین میکند مدل در سامانه جا میشود یا نه؛ توپولوژی ارتباطی بر مقیاس آموزش اثر میگذارد و درایور و runtime مسیر دسترسی همهٔ بارهای کاری به این دارایی را کنترل میکنند.
برای انتخاب سختافزار باید میان نوع کارت، فرمفکتور، توان، اتصال و کاربرد تفکیک کرد. مجموعهٔ راهنمای انتخاب GPU این تصمیم را از منظر سختافزار و استقرار بررسی میکند. از منظر امنیتی، همان BOM نهایی اهمیت دارد: مدل و part number واقعی کارت، firmware، نسخهٔ درایور، سرور پشتیبانیکننده و مسیر بهروزرسانی باید یک واحد اعتبارسنجی تلقی شوند.
قابلیتهایی مانند MIG در برخی GPUهای مرکز داده امکان تقسیم سختافزاری یک GPU به نمونههای جدا با سهم مشخصی از پردازنده، cache و حافظه را میدهند. این جداسازی برای محیط چندمستاجره از time-slicing نرمافزاری قویتر است، اما فعالسازی و حفظ آن به هماهنگی کرنل، درایور، ابزار مدیریتی و runtime کانتینر وابسته است. پیکربندی MIG که پس از reboot از بین میرود یا با ارتقای درایور تغییر میکند، کنترل پایدار محسوب نمیشود.
کانتینر وابستگی GPU به میزبان را حذف نمیکند
NVIDIA Container Toolkit و ابزارهای مشابه اجازه میدهند برنامه داخل کانتینر به GPU میزبان دسترسی پیدا کند. کتابخانههای فضای کاربر میتوانند داخل image قرار گیرند، اما درایور کرنل روی میزبان است. در نتیجه نسخهٔ image، libnvidia-container، runtime و درایور باید با هم سازگار باشند.
این همان نقطهای است که تصور «کانتینر همهچیز را ثابت کرده» شکست میخورد. image برنامه شاید تغییرناپذیر باشد، اما میزبان و درایور همچنان تغییر میکنند. اگر این دو چرخه جداگانه و بدون آزمون مشترک اداره شوند، یک وصلهٔ امنیتی کرنل میتواند مسیر GPU را از کار بیندازد و یک ارتقای درایور میتواند محیطی را که مدل روی آن اعتبارسنجی شده تغییر دهد.
به همین دلیل، image مدل و نرمافزار، نسخهٔ درایور، کرنل، firmware و پیکربندی GPU باید در قالب یک «پروفایل اجرای تأییدشده» ثبت شوند. آزمون پذیرش نیز نباید به دیدهشدن کارت با nvidia-smi محدود بماند؛ بار کاری واقعی، تخصیص حافظه، اجرای چندمستاجره، reboot و مسیر بازگشت باید آزموده شوند. مقالهٔ کانتینر، مرز امنیتی مستقل نیست جزئیات نقش میزبان را توضیح میدهد.
داده، مدل و GPU سه دارایی بههمپیوستهاند
در معماری کلاسیک، داده در پایگاه داده، نرمافزار در کد و سختافزار در نقش بستر دیده میشد. در AI این تفکیک فرو میریزد. داده رفتار مدل را شکل میدهد، مدل عصارهٔ سرمایهگذاری دادهای و محاسباتی است و GPU شرط آموزش یا استنتاج در مقیاس مورد نیاز است.
- داده ممکن است طبقهبندیشده، منحصربهفرد یا حاصل عملیات واقعی باشد. مسمومیت یا نشت آن مستقیماً تصمیم سامانه را تغییر میدهد.
- مدل فقط یک فایل اجرایی نیست؛ وزنها و معماری آن دارایی فکری و عملیاتیاند. سرقت آن میتواند سرمایهگذاری سازمان را در اختیار مهاجم قرار دهد.
- GPU منبعی کمیاب، گران و وابسته به زنجیرهٔ تأمین است. سوءاستفادهٔ محاسباتی، قطع سرویس یا اختلال در درایور میتواند توان عملیاتی را بدون تخریب داده از بین ببرد.
از این رو، سیاست دسترسی نباید این سه را جداگانه ببیند. کاربری که اجازهٔ اجرای job دارد لزوماً نباید به دادهٔ خام یا فایل وزن دسترسی مستقیم داشته باشد. سرویسی که مدل را بارگذاری میکند نباید اختیار تغییر image یا درایور میزبان را داشته باشد. مدیر زیرساخت نیز الزاماً نباید محتوای دادهٔ آموزش را ببیند. این تفکیک نقطهٔ اتصال امنیت زیرساخت با اصول هوش مصنوعی بدون اعتماد است.
تهدید میتواند بدون نفوذ کلاسیک رخ دهد
در نرمافزار سنتی، رفتار عمدتاً در کد صریح است. در AI، بخشی از منطق در دادهٔ آموزش و وزنهای مدل نهفته است. مهاجم میتواند بدون نصب بدافزار یا شکستن کانتینر، داده را مسموم کند، از خروجی مدل اطلاعات استنباط کند، با نمونهٔ خصمانه تصمیم را منحرف سازد یا بهروزرسانی مدل را هدف بگیرد.
این تهدیدها نشان میدهند «امنیت اجرا» معادل «امنیت تصمیم» نیست. کرنل و GPU باید امن و پایدار باشند، اما چرخهٔ داده، آموزش، ارزیابی، استقرار و خروجی نیز باید منشأ، مجوز و شواهد خود را داشته باشد. تفاوت این دو دامنه در مقالهٔ از معماری بدون اعتماد تا هوش مصنوعی بدون اعتماد تشریح شده است.
زنجیرهٔ تأمین سختافزار را از مدل تهدید حذف نکنیم
GPUهای ردهبالا تحت زنجیرهٔ تأمین پیچیده و محدودیتهای صادراتی قرار دارند. در سازمان حساس، نباید اصالت firmware، مسیر تأمین، مالکیت قبلی، امکان بهروزرسانی و وابستگی به سرویس سازنده را بدیهی فرض کرد. این به معنای ادعای وجود سازوکار مخفی در یک محصول مشخص نیست؛ به معنای واردکردن احتمال دستکاری، قطع پشتیبانی یا محدودشدن دسترسی در مدل تهدید است.
تنوع تأمین، آزمون سختافزاری پیش از استقرار، ایزولاسیون شبکهٔ مدیریت، ثبت نسخهٔ firmware و پایش رفتار غیرعادی میتوانند این ریسک را کاهش دهند. کارت مصرفی و مرکز داده نیز جایگزین کامل یکدیگر نیستند؛ تنوع باید با نیاز واقعی حافظه، پایداری و مقیاس سازگار باشد، نه صرفاً برای افزودن نامهای متفاوت به فهرست خرید.
ثبات، به معنی منجمدکردن همیشگی نیست
منجمدکردن کرنل و درایور، تکرارپذیری کوتاهمدت ایجاد میکند اما آسیبپذیری و ناسازگاری با سختافزار جدید را انباشته میسازد. بهروزرسانی مداوم نیز محیط اعتبارسنجیشده را بیثبات میکند. راهحل، چرخهٔ تغییر کنترلشده است: پروفایل نسخه، مخزن داخلی، staging متناظر، بار آزمون واقعی، snapshot، rollout مرحلهای و بازگشت ازپیشتعریفشده.
امنیت زیرساخت AI نه با خرید GPU پایان مییابد و نه با نصب درایور آغاز میشود. این امنیت محصول یک زنجیرهٔ قابل اثبات از firmware و کرنل تا داده، مدل و خروجی است. هر حلقهای که خارج از حاکمیت تغییر کند، میتواند کل قابلیت هوش مصنوعی را از وضعیت معتبر خارج سازد.