رایانش محرمانه چیست و چگونه از داده هنگام پردازش محافظت می‌کند؟

مرز اعتماد در پردازش داده

رمزنگاری سنتی معمولاً از داده در حالت ذخیره و هنگام انتقال محافظت می‌کند، اما برنامه برای پردازش باید داده را در حافظه قابل استفاده داشته باشد. رایانش محرمانه تلاش می‌کند این نقطه حساس را با محیط اجرای مورد اعتماد یا TEE محدود کند. داده و کد در یک ناحیه سخت‌افزاری محافظت‌شده اجرا می‌شوند و سازوکار attestation می‌تواند به طرف مقابل مدرکی بدهد که بارکاری روی پیکربندی مورد انتظار اجرا شده است.

این فناوری جایگزین همه کنترل‌های امنیتی نیست. مدیر زیرساخت ممکن است همچنان بتواند متادیتا، زمان‌بندی یا الگوی دسترسی را مشاهده کند و آسیب‌پذیری پردازنده، firmware یا برنامه همچنان مهم است. پیش از انتخاب راهکار باید مدل تهدید نوشته شود: از چه کسی محافظت می‌کنیم، چه چیزی محرمانه است و چه کسی کلید را نگه می‌دارد؟ سپس الگوریتم attestation، چرخه وصله، مدیریت کلید، محدودیت حافظه و امکان ممیزی مستقل بررسی شود.

تهدیدها، مرز اعتماد و انتخاب راهکار

در یک پروژه واقعی، بهتر است ابتدا دامنه کاربرد محدود و معیار پذیرش روشن تعریف شود. خط مبنا باید پیش از اجرای راهکار ثبت شود تا بتوان تغییر عملکرد را با وضعیت قبلی مقایسه کرد. آزمایش کنترل‌شده، ثبت نسخه نرم‌افزار و داده ورودی و مستندسازی شرایط اجرا، نتیجه را قابل تکرار می‌کند.

تصمیم نهایی باید بر پایه توازن میان دقت، پایداری، امنیت، هزینه و قابلیت نگه‌داری باشد. نمونه نمایشی معمولاً بهترین شرایط را نشان می‌دهد، اما محصول عملیاتی با خطای انسانی، داده ناقص، قطعی شبکه و محدودیت بودجه روبه‌روست. بنابراین یک برنامه پایش پس از استقرار و معیار توقف یا بازگشت به نسخه قبلی نیز لازم است.

مدل تهدید و سنجش محیط اجرای مورد اعتماد

رایانش محرمانه برای کاهش اعتماد لازم به لایه زیرساخت طراحی شده است. در معماری مبتنی بر TEE، بخشی از پردازش در محدوده‌ای اجرا می‌شود که سخت‌افزار برای جداسازی حافظه و کنترل دسترسی آن سازوکارهایی فراهم می‌کند. هدف این نیست که همه تهدیدها حذف شوند، بلکه داده و کد در زمان استفاده در برابر برخی دسترسی‌های ممتاز میزبان محافظت شوند.

فرایند attestation معمولاً شامل تولید یک گزارش رمزنگاری‌شده از وضعیت محیط اجراست. سرویس اعتبارسنجی، گزارش را با سیاست مورد انتظار مقایسه می‌کند: شناسه سخت‌افزار، اندازه‌گیری کد، نسخه firmware و وضعیت به‌روزرسانی می‌توانند در تصمیم دخیل باشند. تنها پس از موفقیت اعتبارسنجی، سرویس مدیریت کلید باید کلید یا داده حساس را آزاد کند. اعتماد به attestation بدون بررسی زنجیره گواهی و سیاست ابطال کافی نیست.

سه سطح حفاظت را باید تفکیک کرد: داده در حالت ذخیره، داده در حال انتقال و داده هنگام پردازش. رمزنگاری دیسک و TLS دو حالت اول را پوشش می‌دهند؛ TEE برای کاهش مواجهه داده در حافظه کاربرد دارد. رمزنگاری همریخت و محاسبات چندطرفه امن رویکردهای دیگری هستند که می‌توانند بدون آشکارسازی کامل داده محاسبه انجام دهند، اما هزینه محاسباتی و پیچیدگی متفاوتی دارند. انتخاب باید بر اساس مدل تهدید و بارکاری باشد.

TEE در برابر همه حملات مصون نیست. کانال جانبی، آسیب‌پذیری پردازنده، اشکال firmware، حمله به برنامه داخل enclave، خطای پیکربندی و افشای داده از طریق خروجی مجاز همچنان ممکن‌اند. اگر برنامه خودش داده را به مقصد نادرست ارسال کند، محرمانگی سخت‌افزاری مانع آن نمی‌شود. بنابراین کدنویسی امن، محدودسازی خروجی، پایش و مدیریت آسیب‌پذیری ضروری‌اند.

برای ارزیابی راهکار، نوع سخت‌افزار و نسل پردازنده، محدودیت حافظه، پشتیبانی از شتاب‌دهنده، زمان راه‌اندازی، افت کارایی، شیوه attestation، چرخه وصله و امکان مهاجرت میان ارائه‌دهندگان را بررسی کنید. یک آزمون عملی باید نشان دهد کلیدها چه زمانی آزاد می‌شوند، در صورت شکست اعتبارسنجی چه رخ می‌دهد و چگونه می‌توان محیط آسیب‌پذیر را از سرویس خارج کرد.

سناریوی مناسب می‌تواند تحلیل مشترک داده‌های مالی یا سلامت باشد؛ چند سازمان می‌خواهند مدل یا پرس‌وجو را روی داده‌های حساس اجرا کنند، بی‌آنکه اپراتور زیرساخت به داده خام دسترسی داشته باشد. قرارداد پردازش، کنترل هویت، ثبت دسترسی و حداقل‌سازی داده همچنان لازم‌اند. رایانش محرمانه یک لایه دفاعی در معماری است، نه جایگزین حکمرانی داده.

چرخه اعتماد در یک سامانه رایانش محرمانه

در یک استقرار واقعی، فعال‌کردن قابلیت TEE تنها قدم اول است. ابتدا باید مشخص شود چه کسی به میزبان، hypervisor، firmware، سیستم‌عامل مهمان، برنامه و کلیدها دسترسی دارد. سپس باید مرز اعتماد تعریف شود: آیا هدف محافظت از داده در برابر مدیر زیرساخت ابری است، یا تهدیدهای داخل خود برنامه نیز در دامنه قرار دارند؟ بدون این مرزبندی، عبارت «داده محرمانه است» ادعایی مبهم باقی می‌ماند.

معماری معمول شامل workload محافظت‌شده، سرویس attestation، سرویس مدیریت کلید و سامانه هویت است. محیط اجرا هنگام راه‌اندازی اندازه‌گیری رمزنگاری‌شده تولید می‌کند. سرویس attestation آن را با سیاست مورد انتظار مقایسه می‌کند و نتیجه‌ای قابل اعتبارسنجی صادر می‌کند. سرویس کلید فقط در صورت برآورده‌شدن شروط، کلید رمزگشایی یا دسترسی لازم را آزاد می‌کند. این زنجیره باید در برابر replay، جعل هویت سرویس و استفاده از نسخه قدیمی و آسیب‌پذیر مقاوم باشد.

سیاست attestation نباید صرفاً بر شناسه سخت‌افزار تکیه کند. اندازه‌گیری تصویر برنامه، نسخه firmware، وضعیت وصله امنیتی، تنظیمات راه‌اندازی و شناسه workload ممکن است اهمیت داشته باشند. سیاست بیش از حد سخت‌گیرانه می‌تواند پس از هر به‌روزرسانی مجاز سرویس را از کار بیندازد؛ سیاست بیش از حد سهل‌گیرانه نیز محیط ناامن را تأیید می‌کند. به همین دلیل باید فرایند تغییر نسخه، تأیید، انقضای گواهی و ابطال تعریف شود.

نکته مهم دیگر این است که TEE از داده در برابر همه خروجی‌ها محافظت نمی‌کند. اگر برنامه داده حساس را در پاسخ API، log، پیام خطا یا فایل موقت افشا کند، حفاظت حافظه مانع نشت نخواهد شد. خروجی‌ها باید حداقل‌سازی شوند، دسترسی شبکه محدود باشد و logها از نظر داده حساس بازبینی شوند. همچنین داده‌ای که برای پردازش به حافظه رمزگشایی می‌شود، همچنان در معرض آسیب‌پذیری‌های نرم‌افزاری داخل workload قرار دارد.

در آزمون کارایی، workload واقعی را با و بدون محیط محرمانه اجرا کنید. زمان شروع، throughput، تأخیر صدک ۹۵ و ۹۹، مصرف حافظه، هزینه انتقال داده و محدودیت شتاب‌دهنده را بسنجید. بارهای کوچک ممکن است عمدتاً از سربار راه‌اندازی اثر بگیرند، در حالی که پردازش‌های طولانی با محدودیت حافظه یا I/O روبه‌رو شوند. نتیجه یک benchmark عمومی را نمی‌توان بدون آزمون به همه برنامه‌ها تعمیم داد.

برنامه بازیابی نیز باید از ابتدا طراحی شود. اگر attestation شکست بخورد، کلید نباید آزاد شود؛ اگر گواهی باطل شود، workload باید از دریافت داده جدید محروم شود؛ و اگر ارائه‌دهنده سخت‌افزار تغییر کند، باید مسیر مهاجرت و چرخش کلید وجود داشته باشد. نسخه پشتیبان داده رمز‌شده بدون برنامه بازیابی کلید، پشتیبان قابل استفاده‌ای نیست. مسئولیت نگه‌داری کلید، سیاست چرخش و دسترسی اضطراری باید مستند باشد.

رایانش محرمانه را با رمزنگاری همریخت و محاسبات چندطرفه امن یکسان نگیرید. در TEE، داده برای اجرای برنامه در یک محیط سخت‌افزاری محافظت‌شده رمزگشایی می‌شود؛ در رمزنگاری همریخت، برخی محاسبات روی داده رمز‌شده انجام می‌شود؛ و در محاسبات چندطرفه، چند طرف سهم‌هایی از داده یا محاسبه را نگه می‌دارند. این روش‌ها می‌توانند مکمل باشند، اما هزینه، مدل اعتماد و نوع کاربردشان متفاوت است.

برای مطالعه تکمیلی، مستندات رسمی کنسرسیوم Confidential Computing و راهنمای انتشارات امنیتی NIST نقطه شروع مناسبی هستند. هنگام انتخاب محصول، مستندات فنی همان نسل سخت‌افزار و گزارش ارزیابی مستقل را نیز بررسی کنید؛ پشتیبانی اسمی از TEE به‌تنهایی تضمین‌کننده سطح امنیت مورد نیاز نیست.

الگوی استقرار: پردازش داده حساس در محیط ابری

فرض کنید چند سازمان می‌خواهند تحلیل مشترکی روی داده‌های حساس انجام دهند، اما هیچ‌کدام نمی‌خواهند داده خام خود را در اختیار اپراتور زیرساخت یا شریک دیگر قرار دهند. رایانش محرمانه می‌تواند بخشی از این مسئله را با اجرای بار کاری در محیط اجرای مورد اعتماد یا TEE حل کند. با این حال، TEE به‌تنهایی سیاست استفاده از داده، صحت کد یا قانونی‌بودن تحلیل را تضمین نمی‌کند؛ این موارد باید در معماری کلی پوشش داده شوند.

چرخه اعتماد معمولاً با راه‌اندازی محیط امن آغاز می‌شود. سخت‌افزار و زنجیره بوت، وضعیت محیط را اندازه‌گیری می‌کنند و یک گواهی یا گزارش attestation ارائه می‌شود. سرویس اعتبارسنج باید امضای گزارش، تازگی آن، نسخه firmware، شناسه محیط و سیاست مجاز را بررسی کند. تنها پس از تأیید، سرویس مدیریت کلید اجازه می‌دهد کلید یا داده محرمانه به محیط برسد. دریافت attestation قدیمی یا بررسی‌نشده نباید برای آزادسازی کلید کافی باشد.

باید دقیقاً مشخص کنید چه چیزی داخل مرز اعتماد قرار می‌گیرد. کد برنامه، کتابخانه‌ها و داده رمزگشایی‌شده ممکن است درون TEE باشند، اما ورودی و خروجی، زمان‌بندی، الگوی دسترسی حافظه یا اندازه پیام می‌توانند از بیرون مشاهده شوند. برخی حملات کانال جانبی از همین نشانه‌ها استفاده می‌کنند. بنابراین تحلیل تهدید باید نوع مهاجم، سطح دسترسی او، سخت‌افزار هدف و اطلاعاتی را که قرار است محرمانه بماند روشن کند.

مدیریت کلید یکی از حساس‌ترین بخش‌هاست. کلیدها را در کد یا تصویر کانتینر قرار ندهید؛ آن‌ها را پس از اعتبارسنجی هویت محیط و بر اساس سیاست کوتاه‌عمر تحویل دهید. چرخش کلید، ابطال گواهی، بازیابی پس از خرابی و رفتار در زمان عدم دسترسی به سرویس attestation باید از قبل آزمایش شوند. اگر یک محیط از نظر امنیتی نامعتبر شد، باید امکان توقف پردازش و جلوگیری از دریافت کلیدهای جدید وجود داشته باشد.

کارایی را با بار واقعی بسنجید. رمزگذاری حافظه، فراخوانی‌های مرزی میان محیط امن و عادی، محدودیت حافظه محافظت‌شده و سربار attestation می‌توانند بر تأخیر اثر بگذارند. benchmark باید زمان راه‌اندازی، توان عملیاتی، مصرف حافظه، تأخیر صدک‌های بالا و رفتار زیر بار هم‌زمان را ثبت کند. نتیجه یک آزمون ساده در محیط توسعه، معیار کافی برای سرویس تولیدی نیست.

در نهایت، TEE را با کنترل‌های مکمل ترکیب کنید: رمزنگاری داده در انتقال و ذخیره‌سازی، حداقل‌سازی داده، کنترل دسترسی، ثبت ممیزی، وصله امنیتی میزبان و بازبینی کد. رایانش محرمانه بخشی از مدل دفاع در عمق است، نه جایگزینی برای امنیت سیستم‌عامل، برنامه یا فرایند سازمانی.

برای انتخاب فناوری، مستندات رسمی Intel SGX، AMD SEV و کنسرسیوم Confidential Computing را با توجه به سخت‌افزار و محیط استقرار بررسی کنید. قابلیت‌ها و مرزهای اعتماد میان نسل‌ها و پیاده‌سازی‌ها یکسان نیستند.