مفاهیم رمزگذاری

جریان کلی

• شما یک کلید اصلی را در ابر خود کنترل می‌کنید که OpenAI هرگز آن را نمی‌بیند

• کلید اصلی شما برای رمزگذاری کلیدهای رمزگذاری داده (DEKها) که OpenAI استفاده می‌کند به کار می‌رود

• OpenAI از DEKها برای رمزگذاری داده‌های شما در حالت ذخیره‌شده استفاده می‌کند. یک DEK با کلید اصلی شما رمزگذاری می‌شود و یک eDEK (DEK رمزگذاری‌شده) ایجاد می‌کند که همراه با داده‌های شما ذخیره می‌شود

• برای خواندن داده‌ها، OpenAI eDEK را می‌گیرد، از KMS شما می‌خواهد آن را به DEK رمزگشایی کند، و سپس داده‌های شما را رمزگشایی می‌کند

رمزگذاری EKM چگونه کار می‌کند؟

برای اطلاعات تفصیلی، لطفاً به مقاله ما مراجعه کنید: نمای کلی مدیریت کلید سازمانی OpenAI (EKM)

آیا OpenAI DEKهای من را ذخیره می‌کند؟

خیر؛ ما DEKهای رمزگذاری‌شده (eDEKها) را ذخیره می‌کنیم که توسط KMS شما تولید می‌شوند. برای رمزگشایی داده‌ها، از KMS شما می‌خواهیم eDEK را دوباره به DEK رمزگشایی کند.

آیا OpenAI DEKهای من را کش می‌کند؟

بله؛ فقط در حافظه. این کار برای بهبود کارایی انجام می‌شود تا در هر درخواست رمزگذاری/رمزگشایی داده، KMS شما فراخوانی نشود. DEKها هرگز در فضای ذخیره‌سازی نوشته نمی‌شوند.

مجوزهای ابری

OpenAI چه مجوزهایی روی KMS من خواهد داشت؟

فقط همان مجوزهایی که از طریق خط‌مشی تنظیم‌شده به ما اعطا می‌کنید. ما فقط دست‌کم به عملیات Encrypt/Decrypt نیاز داریم. لطفاً به‌جای استفاده دوباره از کلیدهای موجودی که کاربردهای تولیدی دارند، یک کلید جدید نیز در KMS ابری خود برای OpenAI ایجاد کنید.

OpenAI چه زمانی مجوز دسترسی به KMS من را دریافت می‌کند؟

همه این مراحل باید انجام شده باشند:

1. شما هویت OpenAI را شناسایی کرده‌اید (از طریق trust policy، workload identity و غیره، بسته به ارائه‌دهنده ابر).

2. شما یک خط‌مشی برای دسترسی به KMS ایجاد کرده‌اید.

3. شما به هویت OpenAI مجوز دسترسی به خط‌مشی را اختصاص داده‌اید.

اگر فقط KMS را بدون انجام همه این مراحل ایجاد کنید، OpenAI دسترسی نخواهد داشت.

آیا باید کلید اصلی خود را در ابر خودم ذخیره کنم؟

نه؛ نحوه مدیریت کلید اصلی‌تان به خودتان بستگی دارد. می‌توانید یک راهکار مدیریت‌شده ابری داشته باشید یا راهکاری خارجی که کلیدتان جداگانه در آن ذخیره شود. OpenAI فقط باید عملیات encrypt/decrypt را روی KMS شما فراخوانی کند؛ اینکه کلید اصلی در عمل چگونه encrypt/decrypt را انجام می‌دهد، جزئیات پیاده‌سازی است که برای ما شفاف نیست.

چرخه عمر کلید

چرخش DEK/eDEK (کنترل‌شده توسط OpenAI)

DEKها/eDEKها هر چند وقت یک‌بار چرخش می‌شوند؟

هر ۲۴ ساعت در مسیر رمزگذاری (درخواست یک جفت کلید DEK/eDEK)

هر ۱ ساعت برای مسیر کلید رمزگشایی (DEK -> eDEK)

آیا وقتی DEK تغییر می‌کند باید کاری انجام دهم؟

خیر؛ چرخش DEK/eDEK در داخل OpenAI انجام می‌شود. تا زمانی که کلید اصلی شما معتبر بماند، هر eDEK رمزگذاری‌شده با کلید اصلی شما همچنان می‌تواند به DEK رمزگشایی شود و سپس از آن برای رمزگشایی داده‌های شما استفاده شود.

چرخش و ابطال کلید اصلی (کنترل‌شده توسط شما)

چرخش کلید و ابطال کلید هر چند وقت یک‌بار انجام می‌شود؟

این موضوع را شما تعیین می‌کنید، زیرا OpenAI به کلید اصلی شما دید ندارد.

تفاوت بین چرخش کلید و ابطال کلید چیست؟

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

اگر کلید اصلی خود را باطل کنم چه اتفاقی می‌افتد؟

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

ابطال با چه سرعتی اثر می‌گذارد؟

OpenAI برای کارایی و تاب‌آوری، DEKها را در حافظه کش می‌کند. ابطال معمولاً ظرف یک ساعت، پس از انقضای کلیدهای کش‌شده و ناموفق بودن اعتبارسنجی مجدد، اثر می‌گذارد.

آیا می‌توان ابطال را به‌طور ایمن آزمایش کرد؟

آزمایش ابطال در فضای کاری تولیدی توصیه نمی‌شود، زیرا داده‌های موجود را به‌طور دائمی غیرقابل دسترسی می‌کند. بااین‌حال، مشتریان می‌توانند (و باید) ابطال را در یک محیط سندباکس آزمایش کنند تا رفتار صحیح را بررسی و فرض‌های اعتماد خود را اعتبارسنجی کنند.

اگر کلیدی به‌طور دائمی باطل شود، آیا می‌توان فضای کاری را با اتصال یک کلید جدید بازیابی کرد؟

خیر. وقتی کلید از دست برود، داده‌ها طبق طراحی غیرقابل بازیابی هستند. تنها راه اصلاح، راه‌اندازی یک فضای کاری جدید است.

اگر فضای کاری به‌دلیل تغییرات کلید غیرقابل دسترسی شود، چه باید بکنیم؟

راهکار اصلاحی مورد انتظار، ایجاد یک فضای کاری جدید است. به‌روزرسانی KMS داده‌های موجود را بازیابی نخواهد کرد.

اگر تصمیم بگیریم استفاده از CMEK را متوقف کنیم، برنامه عقب‌گرد چیست؟

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

وقتی کلید اصلی خود را می‌چرخانم چه اتفاقی می‌افتد؟

مواد رمزنگاری جدیدی برای رمزگذاری تولید می‌شود، بنابراین درخواست‌های رمزگذاری جدید از کلید جدید استفاده خواهند کرد. بااین‌حال، شناسه KMS (ARN یا نام کلید) همان قبلی باقی می‌ماند و داده‌های قدیمی همچنان قابل رمزگشایی هستند. بسیاری از ارائه‌دهندگان ابر، چرخش خودکار کلید را ارائه می‌دهند (AWS، GCP، Azure).

آیا وقتی کلید اصلی خود را می‌چرخانم، OpenAI داده‌های قدیمی‌تر را دوباره رمزگذاری می‌کند؟

خیر. مواد رمزنگاری جدید فقط برای رمزگذاری داده‌های جدید استفاده خواهند شد.

چقدر طول می‌کشد تا چرخش کلید یا ابطال کلید اثر بگذارد؟

۱ ساعت. دلیلش این است که DEK/eDEKها در حافظه کش می‌شوند و ما این ورودی‌ها را هر ساعت با KMS شما دوباره اعتبارسنجی می‌کنیم.

تغییر شناسه KMS

آیا تغییر شناسه KMS ابطال کلید است یا چرخش کلید؟

ابطال کلید. یک کلید نمی‌تواند داده‌هایی را که با کلید دیگری رمزگذاری شده‌اند رمزگشایی کند.

آیا OpenAI می‌تواند در تغییر شناسه KMS برای یک فضای کاری ChatGPT به من کمک کند؟

اگر تأیید کنید که قصدتان ابطال کلید است، می‌توانیم برای انجام این کار در یک فضای کاری ChatGPT به شما کمک کنیم. توجه داشته باشید که وقتی KMS ARN به‌روزرسانی شود، داده‌های قدیمی‌تر همچنان غیرقابل دسترسی می‌مانند؛ بنابراین پس از این تغییر، ترکیبی از داده‌های غیرقابل دسترسی و قابل دسترسی خواهید داشت.

آیا OpenAI می‌تواند در تغییر شناسه KMS برای یک پروژه API به من کمک کند؟

اگر از API استفاده می‌کنید، API بایگانی و ایجاد پروژه‌های جدید را آسان می‌کند؛ بنابراین لطفاً به‌جای آن، پروژه‌ای را که داده‌هایش در هر صورت قابل دسترسی نیست بایگانی کنید، یک پیکربندی EKM جدید نزد OpenAI ثبت کنید، و یک پروژه API جدید با کلید KMS جدید بسازید.

اگر بخواهم به‌طور منظم شناسه KMS خود را شخصاً تغییر دهم چه؟

این کار توصیه نمی‌شود، زیرا احتمالاً نمی‌خواهید کلید خود را به‌طور منظم باطل کنید. بااین‌حال، اگر از ارائه‌دهنده ابری استفاده می‌کنید که از نام مستعار کلید KMS پشتیبانی می‌کند، همچنان می‌توانید این کار را انجام دهید (نمونه AWS). می‌توانید آن نام مستعار کلید KMS را نزد OpenAI ثبت کنید و سپس در ارائه‌دهنده ابری خود، هر زمان که خواستید شناسه KMS زیربنایی را که نام مستعار به آن اشاره می‌کند جابه‌جا کنید تا ابطال کلید انجام شود.

رفتار نسخه بتا در مقایسه با GA

آیا هنگام استفاده از نسخه بتای رمزگذاری در محیط تولید، ریسک‌های شناخته‌شده یا تغییرات در سطح سیستم وجود دارد؟

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

آیا برای گذار از بتا به GA به مراحل مهاجرت نیاز خواهد بود؟

خیر. فضاهای کاری‌ای که از نسخه بتای رمزگذاری استفاده می‌کنند، بدون هیچ اقدام کاربر به‌طور خودکار در GA پشتیبانی خواهند شد.

جزئیات فنی بیشتر

رمزگذاری پاکتی و مجوزها

آیا برای EKM باید مجوزهای GenerateDataKey را به OpenAI اعطا کنیم؟

خیر. OpenAI فقط به مجوزهای Encrypt و Decrypt روی کلید KMS شما نیاز دارد. مجوز GenerateDataKey برای یکپارچه‌سازی EKM لازم نیست.

آیا OpenAI برای داده‌های مشتری از رمزگذاری پاکتی استفاده می‌کند؟

بله. OpenAI از یک مدل رمزگذاری پاکتی استفاده می‌کند:

• KMS مشتری: کلیدهای رمزگذاری کلید (KEKها) را مدیریت می‌کند. OpenAI هرگز KEKها را نمی‌بیند یا ذخیره نمی‌کند.

• زیرساخت OpenAI: کلیدهای رمزگذاری داده (DEKها) را تولید و مدیریت می‌کند. هر DEK پیش از ذخیره‌سازی با KEK شما رمزگذاری (wrap) می‌شود.

• جریان داده:

  • داده‌های مشتری با یک DEK رمزگذاری می‌شود.

  • آن DEK با KEK شما رمزگذاری می‌شود و یک eDEK تولید می‌کند.

  • eDEK در کنار داده‌های رمزگذاری‌شده ذخیره می‌شود.

  • برای رمزگشایی داده‌ها، OpenAI از KMS شما می‌خواهد eDEK را رمزگشایی کند، DEK را دریافت می‌کند و محتوا را رمزگشایی می‌کند.

چرا OpenAI این مدل را به‌جای سپردن مدیریت هر دو KEK و DEK به KMS انتخاب کرد؟

دو رویکرد رایج برای رمزگذاری پاکتی وجود دارد:

KEKها و DEKهای مدیریت‌شده با KMS:

مزایا: پیاده‌سازی ساده‌تر و بی‌نیازی از نگهداری زیرساخت رمزگذاری.

معایب: هر درخواست رمزگذاری/رمزگشایی به KMS ارسال می‌شود، که تأخیر و هزینه را افزایش می‌دهد و یک نقطه خرابی منفرد ایجاد می‌کند.

KEKهای مدیریت‌شده با KMS / DEKهای مدیریت‌شده با OpenAI (رویکرد ما):

مزایا: تأخیر و هزینه بسیار کمتر، مقیاس‌پذیری و قابلیت اطمینان بهتر، و ادامه کار در زمان قطعی‌های جزئی KMS (تا سقف TTL کش DEK).

معایب: پیاده‌سازی کمی پیچیده‌تر در سمت OpenAI.

این طراحی به OpenAI امکان می‌دهد ضمن به حداقل رساندن ریسک عملیاتی و هزینه برای مشتریان، تضمین‌های امنیتی قوی ارائه دهد.

DEKها هر چند وقت یک‌بار چرخش می‌شوند؟

هر DEK تقریباً هر ۶۰ دقیقه یک‌بار چرخش می‌شود. این کار جداسازی زمانی فراهم می‌کند — حتی اگر یک DEK به‌نحوی به خطر بیفتد، اثر آن به داده‌های رمزگذاری‌شده در همان بازه یک‌ساعته محدود می‌شود.

حجم درخواست‌های KMS و مشاهده‌پذیری

تعداد درخواست‌های KMS که می‌بینیم بسیار کمتر از تعداد پیام‌های کاربر است. آیا این اعداد باید با هم برابر باشند؟

خیر، رابطه مستقیمی با هم نخواهند داشت.

از آنجا که OpenAI به‌دلایل کارایی، DEKها را در حافظه کش می‌کند، فراخوانی‌های KMS فقط زمانی انجام می‌شوند که لازم باشد یک DEK رمزگشایی شود — نه در هر عملیات رمزگذاری یا رمزگشایی. در نتیجه، باید انتظار موارد زیر را داشته باشید:

• درخواست‌های KMS کمتر از تعاملات کاربر.

• افزایش‌های مقطعی هنگامی که DEKهای کش‌شده منقضی می‌شوند (تقریباً هر ساعت) یا زمانی که باید به داده‌های رمزگذاری‌شده قدیمی‌تر دسترسی پیدا شود.

• فراخوانی‌های اضافی هنگام بازیابی داده‌های تاریخی، مثلاً وقتی کاربری یک گفت‌وگوی طولانی‌مدت را ادامه می‌دهد و باید DEKهای قدیمی‌تر بارگذاری شوند.

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