
مرز مشتری: جداسازی داده در سامانههای هوش مصنوعی مشترک
راهنمایی عملی برای تصمیم درباره اجزای اشتراکی و اختصاصی و حفظ مرز مشتری در بازیابی، حافظه، کش، ابزار، لاگ و ارزیابی سامانه هوش مصنوعی.
ادامه مطلبتیم ژرف ایآی

شرکتی سابقههای مشتری را در ذخیره و انتقال رمز میکند، سپس به سرور هوش مصنوعی میفرستد؛ جایی که میزبان، هایپروایزر، میانافزار، زماناجرا و برنامه بخشی از اعتمادند. وقتی مدل داده را به کار میگیرد، چه کسی آن را میبیند یا تغییر میدهد؟
محاسبات محرمانه میتواند کار را در محیط اجرای قابلاعتماد سختافزارمحور، یا TEE، محصور کند و این سطح تماس را کاهش دهد. اما خرید «ماشین مجازی محرمانه» ثابت نمیکند که مدل، کانتینر، راهانداز و سیاست مورد نظر داده را گرفتهاند. تصمیم خواننده این است: آیا تهدیدی در زمان استفاده وجود دارد که TEE واقعاً آن را کوچک کند، و آیا میتوان کلید داده و مدل را تا زمان اثبات تازه و کامل زماناجرای تأییدشده از دسترس خارج نگه داشت؟
این راهنما سازوکار، خطر باقیمانده و معماری قابلآزمون آزادسازی راز پس از گواهی را شرح میدهد.
پیش از مقایسه محصول، دارایی حفاظتشده، طرفی که نباید به آن دسترسی داشته باشد، لحظه افشا و شکست قابلپذیرش را نام ببرید:
سندهای مشتری و وزنهای اختصاصی مدل فقط در انتشار
R-27رمزگشایی شوند؛ مدیر ابر، هسته میزبان آلوده، هایپروایزر یا مشتری همسایه نتواند آنها را بخواند یا تغییر دهد. قطع خدمت پذیرفتنی است؛ اجرای بیصدا در زماناجرای تأییدنشده نیست.
این عبارت لایه نامطمئن و سازگاری رد امن با خدمت را روشن میکند.
NIST IR 8320 که در مه ۲۰۲۲ نهایی شد، امنیت سختافزارمحور را پایه امنیت لایهای سکو میداند. تحلیل ژرف: محاسبات محرمانه وقتی مفید است که ریشه سختافزاری رابطه اعتماد نامداری را تغییر دهد؛ نه برای داده عمومی، میزبان پذیرفتهشده یا خطر درون برنامه.
مهاجم را صریح دستهبندی کنید:
رده آخر تعیینکننده است. TEE مهمان را از بخشهایی از میزبان جدا میکند؛ کد ناامن داخل مهمان را امن نمیسازد.
محیط اجرای قابلاعتماد معمولاً سه ویژگی جدا میآورد:
این سه هممعنا نیستند. رمز حافظه شاید تمامیت ندهد؛ جداسازی بدون گواهی، استقرار را به ادعا تبدیل میکند؛ گواهی بدون تصمیم منبع بیاثر است.
مقاله فنی AMD درباره SEV-SNP مرز مشخصی دارد: حافظه خصوصی مهمان از هایپروایزر نامطمئن محافظت و با بازپخش، خرابسازی و نگاشت دوباره مقابله میشود. سند، دسترسپذیری مهمان را تضمین نمیکند، برای ورودیوخروجی مشترک TLS میخواهد و همه حملههای فیزیکی یا کانال جانبی را حذف نمیکند.
این مرز را تعمیم ندهید. نسل پردازنده، میانافزار، حالت TEE، سیاست مهمان، مسیر دستگاه، خدمت گواهی و استثناها را ثبت کنید. برچسب محصول، مدل تهدید نیست.
کنترل باید یک شکاف واقعی را ببندد:
| وضعیت بار کاری | ارزش TEE | پیام تصمیم |
|---|---|---|
| ورودی یا وزن حساس باید از بهرهبردار زیرساخت پنهان بماند | بالقوه زیاد | مدل تهدید ارائهدهنده و دستگاه باید صریحاً دسترسی آن بهرهبردار به متن آشکار را رد کند |
| چند طرف داده میآورند اما ورودی خام را به یکدیگر نمیدهند | بالقوه زیاد | مشخص کنید چه کسی زماناجرا را راستیآزمایی و چه کسی هر کلید را کنترل میکند |
| میزبان در مرز اعتماد پذیرفته شده و داده کمحساسیت است | اغلب کم | جداسازی، کنترل دسترسی و رمزنگاری عادی سادهتر است |
| تهدید اصلی تزریق دستور، ابزار ناامن، خطای مدل یا کاربر سوءاستفادهگر است | کم | کنترل برنامه را اصلاح کنید؛ کار زیانبار ممکن است بهدرستی داخل TEE اجرا شود |
| خدمت تحمل رد امن کلید یا قطع راستیآزما را ندارد | دوگانه | حالت تنزل امن بسازید یا این معماری را رد کنید |
رایانش سختسازیشده، ماشین محرمانه و enclave کوچک را مقایسه کنید. مهمان بزرگ سادهتر اما TCB بزرگتر است؛ enclave کد مورد اعتماد را کم میکند اما تغییر برنامه میخواهد. GPU و اتصال دستگاه گزینهها را محدودتر میکند.
هزینه چرخه عمر شامل تصویر قابلبازتولید، گواهی، مقدار مرجع، سیاست کلید، ظرفیت، شروع سرد، رخداد، بازیابی و توان تفسیر ادعای ردشده است.
هر متن آشکار را دنبال کنید: مشتری، درگاه، صف، حافظه CPU و GPU، بافر مشترک، کش، ذخیره موقت، خروجی، لاگ، dump، ردگیری و ابزار. هسته محافظتشده سودی ندارد اگر درگاه prompt را لاگ کند.
برای هر مرحله ثبت کنید:
TCB را تعریف کنید: هر سختافزار، میانافزار، راستیآزما، مهمان، زماناجرا، برنامه و سیاست که خرابیاش وعده را میشکند. خدمت غیرضروری مهمان نیز عضو آن است.
موجودی را به گذرنامه انتشار هوش مصنوعی وصل کنید. سیاست به هویت تغییرناپذیر مهمان، هسته، راهاندازی، برنامه، خدمت مدل، راهانداز و سیاست مدل نیاز دارد. latest مرجع نیست.
گواهی از راه دور، جریان شاهد است. RFC 9334، معماری RATS از IETF در ژانویه ۲۰۲۳، سه نقش را جدا میکند:
امضای معتبر، صادرکننده و تمامیت را ثابت میکند؛ نه سازگاری ادعاها با سیاست انتشار.
Google Cloud Attestation نمونه جاری است: تأییدیه میگیرد، شاهد را با مرجع و سیاست میسنجد و ادعای امضاشده میدهد. الگو: گواهیدهنده ← راستیآزما ← نتیجه ← سیاست طرف اتکاکننده ← تصمیم منبع.
سیاست طرف اتکاکننده را مانند کد نسخهبندی کنید:
| خانواده ادعا | پرسش پیش از آزادسازی |
|---|---|
| سختافزار و TEE | آیا فناوری، نسخه امنیتی، حالت محرمانه و وضعیت debug مجاز است؟ |
| میانافزار و راهاندازی | آیا میانافزار، secure boot، هسته، خط فرمان و سیاست مهمان مجاز است؟ |
| بار کاری | آیا چکیده تصویر یا برنامه دقیقاً هویت انتشار تأییدشده است؟ |
| دستگاه | آیا هر جا راز وارد حافظه GPU میشود، ادعای GPU، راهانداز، میانافزار و اتصال وجود دارد؟ |
| تازگی | آیا شاهد به nonce تازه یا سازوکار تازگی پذیرفتهشده مقید است؟ |
| نشست | آیا شاهد کلید عمومی گیرنده راز را در خود مقید کرده است؟ |
| بافت | آیا مشتری، محیط، منطقه، هدف و رده خطر با منبع میخواند؟ |
| لغو | آیا تأییدیه، گواهی، میانافزار و مقدار مرجع هنوز پذیرفتنی است؟ |
غیبت ادعا تأیید نیست؛ شاهد لازم GPU نباید «مورد اعتماد» فرض شود.
گواهی ماشین و ارسال کلید در اتصالی نامرتبط، امکان جایگزینی میگذارد. گیرنده راز باید همان بار کاری شاهد باشد.
الگوی مقاوم چنین است:
مایکروسافت این بخش را آزادسازی امن کلید مینامد: کلید فقط پس از اثبات TEE آزاد میشود. پرسشهای متداول Azure Attestation مقیدکردن کلید عمومی بار کاری به داده گواهیشده را برای ساخت کانال همان محیط مستند میکند.
گواهی، زماناجرا را توصیف میکند؛ هویت، فراخواننده را نام میبرد؛ مجوز، این دو را به مشتری، وظیفه و منبع وصل میکند. الگوی کوتاهعمر راهنمای واسطهگری اعتبارنامه را به کار ببرید. هیچ توکنی نباید اعتبارنامه مادر شود.
کلیدها را بر اساس دارایی و مالک جدا کنید. صاحب مدل و مشتری میتوانند زماناجرای یکسان اما ادعاهای متفاوت مشتری، جغرافیا، هدف و انقضا بخواهند. همه داراییها را پشت یک تصمیم attested=true پنهان نکنید.
هوش مصنوعی از مرز CPU و GPU میگذرد. حفاظت CPU ثابت نمیکند متن آشکار وارد GPU، راهانداز، میانافزار یا اتصال مجاز شده است. ادعاهای دستگاه باید با هم سنجیده شوند.
معماری مرجع محاسبات محرمانه NVIDIA ماشین محرمانه اندازهگیریشده، CPU و GPU محرمانه، راستیآزما، آزادسازی امن کلید و لاگ حریمخصوصیمحور میخواهد؛ همچنین پیش از آزادسازی کلید مدل، شاهد تازه CPU، GPU، مهمان، تنظیم راهاندازی و میانافزار را لازم میداند. مستندات گواهی NVIDIA که ۱ اوت ۲۰۲۶ بهروز شده، مسیر محلی و راه دور را برای GPUهای پشتیبانیشده H100 یا جدیدتر و سوئیچ چند GPU فهرست میکند.
اینها واقعیت فروشندهاند، نه اثبات استقرار. تحلیل ژرف: تصمیم مرکب در غیبت، کهنگی، debug، لغو یا ناسازگاری هر لایه رد امن دهد. نتیجه فروشندگان را یکدست کنید، اما ادعای مؤثر بر مدل تهدید را نه.
سیاست همچنان باید حافظه مشترک، DMA، ورودیوخروجی، کش مدل و اتصال چند GPU را پوشش دهد. «GPU گواهی شد» پاسخ جریان داده نیست.
ارائهدهنده مالک وزن مدل و مشتری مالک پرونده محرمانه است. هیچکدام به زیرساخت اعتماد ندارد و وزن به تصویر دلخواه داده نمیشود. R-27 شامل ماشین اندازهگیریشده، هسته ثابت، کانتینر کوچک، CPU/GPU مجاز، بازه راهانداز و میانافزار، debug خاموش و پالایه خروجی است.
ترتیب کار:
R-27 را برای همان نشست میدهد.MK-8 را برای نشست wrap میکند.T-41، هدف، منطقه، نگهداری و اختیار درخواست را میسنجد و فقط DK-93 را wrap میکند.اگر راهانداز، شاهد GPU، nonce، تصویر یا سیاست شکست بخورد، کلید همان مالک رد میشود. retry فقط روی میزبان تازه و تأییدشده مجاز است؛ نه ماشین عادی یا نتیجه دیروز.
این الگو تماس زیرساخت را کم میکند؛ درستی مدل، امنیت کانتینر، مجوز خروجی یا مشروعیت هدف را ثابت نمیکند.
وابستگیهای تازه میتوانند خدمت را متوقف کنند: تأییدیه، وضعیت گواهی، راستیآزما، مقدار مرجع، خدمت کلید، ظرفیت و سیاستی که بهروزرسانی ضروری را رد میکند. تکلیف هر شکست را تعریف کنید:
بازیابی را تمرین کنید. سیاست، مرجع امضا، وضعیت لغو و پیوستگی ممیزی باید حفظ شود؛ منطقه تازه ممکن است مرجع گواهی یا ادعای متفاوت داشته باشد. بازیابی نباید فقط برای رسیدن به RTO مجموعه مورد اعتماد را گسترده کند.
از خود شاهد محافظت کنید. RFC 9334 هشدار میدهد که شاهد میتواند جزئیات مفید میانافزار، نرمافزار، دستگاه یا کاربر را فاش کند. آن را کمینه، رمز، محدود و منقضی کنید. معیار راهنمای شواهد ممیزی روشن است: ورودی، سیاست، تصمیم و اثر را برای آزمون کنترل نگه دارید؛ نه تصویر یک نشان سبز.
کل مسیر را در برابر رایانش عادی بسنجید، نه فقط یک عدد throughput:
| بُعد | سنجه مفید |
|---|---|
| پوشش | کار حساس با ارزیابی همه ادعاهای لازم CPU، مهمان، GPU و دستگاه |
| تازگی | توزیع عمر شاهد هنگام آزادسازی؛ شمار رد بازپخش و استفاده دوباره nonce |
| سیاست | آزادسازی و رد به تفکیک نسخه سیاست، ادعا، محیط، مشتری و علت |
| TCB | اجزای اندازهگیریشده، خدمت ممتاز، تعداد بسته و انحراف چکیده |
| تماس کلید | آزادسازی بیرون سیاست، عمر راز، یافته dump و استثنای متن آشکار |
| تغییر امنیتی | زمان میان هشدار یا لغو فروشنده تا اصلاح مقدار مرجع و سیاست |
| قابلیت اتکا | دسترسپذیری راستیآزما و کلید، رد امن، عمر صف رمزشده و بازیابی |
| کارایی | گواهی، شروع سرد، بار مدل، حافظه، ورودیوخروجی، توان عملیاتی، دُم تأخیر و هزینه کار کامل |
مدل، بافت، batch، توپولوژی، مسیر داده و سیاست شکست واقعی را معیار بگیرید. سربار آغاز را از هزینه هر درخواست جدا کنید؛ میانگین میتواند پرتگاه شروع سرد یا ظرفیت را پنهان کند.
تا وقتی مالک به این پرسشها پاسخ مثبت نداده، داده یا وزن حساس آزاد نکنید:
پس از تغییر پردازنده، GPU، میانافزار، راهانداز، مهمان، راستیآزما، قالب، مرجع مقدار، مدیر کلید، زماناجرا، مشتری، منطقه یا توپولوژی تصمیم را بازبینی کنید. افشای کانال جانبی، رد توضیحناپذیر، استثنای اضطراری، نشت متن آشکار یا تمرین بازیابی نیز محرک بازبینی است.
اصل ماندگار «هوش مصنوعی را داخل enclave اجرا کنید» نیست؛ این است: رمزگشایی را مشروط به شاهد تازه و مقید به بار کاری کنید که حضور کامل زماناجرای تأییدشده را ثابت میکند. TEE فقط یک تهدید زیرساختی را باریک میکند؛ هرچه داخل آن است همچنان به کد امن، اختیار محدود، ارزیابی و بهرهبرداری پاسخگو نیاز دارد.

راهنمایی عملی برای تصمیم درباره اجزای اشتراکی و اختصاصی و حفظ مرز مشتری در بازیابی، حافظه، کش، ابزار، لاگ و ارزیابی سامانه هوش مصنوعی.
ادامه مطلب
راهنمای میدانی برای نسخهبندی، اعتبارسنجی، ترمیم و مصرف امن خروجی ساختیافته هوش مصنوعی؛ بدون یکیگرفتن انطباق با طرحواره، حقیقت و اختیار.
ادامه مطلب
OpenClaw را نصب و ایمن کنید و Gateway، مدل، workspace، کانال، حافظه، Skill، پلاگین، مرورگر، سابایجنت، task و اتوماسیون آن را یاد بگیرید.
ادامه مطلباگر این مطلب به یک سامانه واقعی در سازمان شما مربوط است، از خدمات و مطالعه موردی شروع کنید.