انکرپشن کے تصورات
اعلی سطحی فلو
آپ اپنے cloud میں ایک ماسٹر کی کو کنٹرول کرتے ہیں جسے OpenAI کبھی نہیں دیکھتا
آپ کی ماسٹر کی data encryption keys (DEKs) کو انکرپٹ کرنے کے لیے استعمال ہوتی ہے، جنہیں OpenAI استعمال کرتا ہے
OpenAI آپ کے محفوظ حالت میں موجود ڈیٹا کو انکرپٹ کرنے کے لیے DEKs استعمال کرتا ہے. DEK آپ کی ماسٹر کی سے انکرپٹ ہو کر eDEK (encrypted DEK) بناتا ہے، جسے آپ کے ڈیٹا کے ساتھ محفوظ کیا جاتا ہے
ڈیٹا پڑھنے کے لیے OpenAI eDEK لیتا ہے، آپ کے KMS سے اسے DEK میں ڈکرپٹ کرنے کی درخواست کرتا ہے، اور پھر آپ کا ڈیٹا ڈکرپٹ کرتا ہے
EKM انکرپشن کیسے کام کرتی ہے.
تفصیلی معلومات کے لیے براہ کرم ہمارا مضمون دیکھیں: OpenAI Enterprise Key Management (EKM) کا جائزہ
کیا OpenAI میرے DEKs کو اسٹور کرتا ہے.
نہیں، ہم encrypted DEKs (eDEKs) اسٹور کرتے ہیں، جو آپ کے KMS کے ذریعے generate کیے جاتے ہیں. data کو decrypt کرنے کے لیے، ہم آپ کے KMS سے eDEK کو واپس DEK میں decrypt کرنے کو کہتے ہیں.
کیا OpenAI میرے DEKs کو cache کرتا ہے.
ہاں، صرف memory میں. یہ کارکردگی کے لیے ہے، تاکہ ہر data encrypt/decrypt request پر آپ کے KMS کو hit کرنے سے بچا جا سکے. DEKs کبھی storage میں نہیں لکھے جاتے.
Cloud اجازتیں
میرے KMS پر OpenAI کے پاس کون سی اجازتیں ہوں گی.
صرف وہ اجازتیں جو آپ اپنی مقرر کردہ پالیسی کے ذریعے ہمیں دیتے ہیں. ہمیں کم از کم Encrypt/Decrypt آپریشنز درکار ہیں. براہ کرم OpenAI کے لیے اپنے cloud KMS میں نئی کی بھی بنائیں، بجائے اس کے کہ پروڈکشن مقاصد کے لیے استعمال ہونے والی موجودہ keys دوبارہ استعمال کریں.
OpenAI کو میرے KMS تک رسائی کی اجازتیں کب ملتی ہیں.
یہ سب steps مکمل ہو چکے ہونے چاہئیں:
آپ نے OpenAI کی identity کو recognize کیا ہو (trust policy، workload identity وغیرہ کے ذریعے، cloud provider پر منحصر ہے).
آپ نے KMS تک رسائی کے لیے policy بنائی ہو.
آپ نے OpenAI کی identity کو policy تک رسائی کی permission assigned کی ہو.
اگر آپ یہ سب steps کیے بغیر صرف KMS بنا دیتے ہیں، تو OpenAI کے پاس access نہیں ہوتی.
کیا مجھے اپنی ماسٹر کی اپنے cloud میں اسٹور کرنی ہوگی.
نہیں، اپنی ماسٹر کی کا نظم کیسے کرنا ہے یہ آپ پر منحصر ہے. آپ cloud-managed حل رکھ سکتے ہیں، یا ایسا external حل جہاں آپ کی key الگ سے محفوظ ہو. OpenAI کو صرف آپ کے KMS پر encrypt/decrypt آپریشنز کال کرنے کی ضرورت ہے؛ ماسٹر کی اصل میں encrypt/decrypt کیسے انجام دیتی ہے، یہ نفاذ کی تفصیل ہے جو ہمارے لیے غیر واضح رہتی ہے.
کی لائف سائیکل
DEK/eDEK روٹیشن (OpenAI کے زیر کنٹرول)
DEKs/eDEKs کتنی بار روٹیٹ کیے جاتے ہیں.
انکرپشن پاتھ پر ہر 24 گھنٹے بعد (DEK/eDEK کی جوڑی کی درخواست کرتے وقت)
ڈکرپشن کی پاتھ کے لیے ہر 1 گھنٹے بعد (DEK -> eDEK)
DEK بدلنے پر کیا مجھے کچھ کرنا ہوگا.
نہیں، DEK/eDEK روٹیشن OpenAI کے اندر کی جاتی ہے. جب تک آپ کی ماسٹر کی valid رہتی ہے، آپ کی ماسٹر کی سے encrypted کوئی بھی eDEKs بدستور DEK میں decrypt کیے جا سکتے ہیں، جسے پھر آپ کے data کو decrypt کرنے کے لیے استعمال کیا جاتا ہے.
ماسٹر کی روٹیشن اور تنسیخ (آپ کے زیر کنٹرول)
کی روٹیشن اور کی تنسیخ کتنی بار ہوتی ہے.
یہ آپ طے کرتے ہیں، کیونکہ OpenAI کو آپ کی ماسٹر کی کی visibility نہیں ہوتی.
کی روٹیشن اور کی تنسیخ میں کیا فرق ہے.
کی تنسیخ پرانی keys سے انکرپٹ کیے گئے ڈیٹا تک رسائی ہٹا دیتی ہے. کی روٹیشن نئی key استعمال کر کے ڈیٹا انکرپٹ کرتی ہے، مگر پرانے ڈیٹا تک پڑھنے کی رسائی برقرار رکھتی ہے.
اگر میں اپنی ماسٹر کی منسوخ کر دوں تو کیا ہوگا.
اگر کوئی کی منسوخ کر دی جائے یا اجازتیں ہٹا دی جائیں، تو cached keys کی میعاد ختم ہونے کے بعد ورک اسپیس بالآخر غیر فعال ہو جائے گی. اس وقت OpenAI محفوظ شدہ ڈیٹا کو مزید ڈکرپٹ نہیں کر سکے گا اور نہ ہی نیا ڈیٹا انکرپٹ کر سکے گا. عملاً، ڈیٹا “shredded” ہو جاتا ہے.
تنسیخ کتنی جلد اثر انداز ہوتی ہے.
OpenAI کارکردگی اور resilience کے لیے DEKs کو میموری میں cache کرتا ہے. تنسیخ عموماً ایک گھنٹے کے اندر اثر انداز ہو جاتی ہے، جب cached keys کی میعاد ختم ہو جاتی ہے اور دوبارہ توثیق ناکام ہو جاتی ہے.
کیا تنسیخ کو محفوظ طریقے سے ٹیسٹ کیا جا سکتا ہے.
پروڈکشن ورک اسپیس میں تنسیخ کی جانچ تجویز نہیں کی جاتی کیونکہ اس سے موجودہ ڈیٹا مستقل طور پر ناقابل رسائی ہو جائے گا. تاہم، صارفین درست رویے کی تصدیق اور اپنے اعتماد سے متعلق مفروضات کی توثیق کے لیے sandbox ماحول میں تنسیخ کی جانچ کر سکتے ہیں، اور کرنی بھی چاہیے.
اگر کوئی کی مستقل طور پر منسوخ کر دی جائے، تو کیا نئی کی منسلک کر کے ورک اسپیس بحال کی جا سکتی ہے.
نہیں. کی ضائع ہو جانے کے بعد، ڈیٹا ڈیزائن کے لحاظ سے ناقابل بازیافت ہوتا ہے. واحد حل نئی ورک اسپیس بنانا ہے.
اگر key changes کی وجہ سے ورک اسپیس ناقابل رسائی ہو جائے تو ہمیں کیا کرنا چاہیے.
متوقع حل نئی ورک اسپیس بنانا ہے. KMS کو اپ ڈیٹ کرنے سے موجودہ ڈیٹا بحال نہیں ہوگا.
اگر ہم CMEK استعمال کرنا بند کرنے کا فیصلہ کریں تو backout plan کیا ہے.
فی الحال کوئی backout plan نہیں ہے. CMEK کے ساتھ ورک اسپیس بننے کے بعد، اس سے وابستہ تمام data customer-managed keys سے encrypted ہوتا ہے اور ان کے بغیر access نہیں کیا جا سکتا. CMEK کا استعمال بند کرنے کا واحد طریقہ نئی ورک اسپیس بنانا ہے؛ موجودہ encrypted data مستقل طور پر ناقابل رسائی رہے گا.
جب میں اپنی ماسٹر کی روٹیٹ کرتا ہوں تو کیا ہوتا ہے.
انکرپشن کے لیے نیا cryptographic material بنایا جائے گا، اس لیے نئی encryption requests نئی key استعمال کریں گی. تاہم، KMS شناخت کنندہ (ARN یا key name) وہی رہتا ہے اور پرانا ڈیٹا اب بھی ڈکرپٹ کیا جا سکتا ہے. بہت سے cloud providers automatic key rotation پیش کرتے ہیں (AWS, GCP, Azure).
کیا میری ماسٹر کی روٹیٹ کرنے پر OpenAI پرانے ڈیٹا کو دوبارہ انکرپٹ کرتا ہے.
نہیں. نیا cryptographic material صرف نئے data کو encrypt کرنے کے لیے استعمال ہوگا.
کی روٹیشن یا کی تنسیخ کے اثر انداز ہونے میں کتنا وقت لگتا ہے.
1 گھنٹہ. اس کی وجہ یہ ہے کہ DEK/eDEKs کو in-memory cache کیا جاتا ہے، اور ہم ہر گھنٹے آپ کے KMS کے ساتھ ان entries کی دوبارہ توثیق کرتے ہیں.
KMS شناخت کنندہ بدلنا
کیا KMS شناخت کنندہ بدلنا کی کی تنسیخ ہے یا کی روٹیشن.
کی کی تنسیخ. ایک کی دوسری کی سے انکرپٹ کیے گئے ڈیٹا کو ڈکرپٹ نہیں کر سکتی.
کیا OpenAI کسی ChatGPT ورک اسپیس کے لیے میرا KMS شناخت کنندہ بدلنے میں میری مدد کر سکتا ہے.
اگر آپ تصدیق کریں کہ مقصد آپ کی key منسوخ کرنا ہے، تو ہم ChatGPT ورک اسپیس کے لیے اس میں آپ کی مدد کر سکتے ہیں. نوٹ کریں کہ KMS ARN اپ ڈیٹ ہونے پر پرانا ڈیٹا ناقابل رسائی ہی رہے گا، اس لیے تبدیلی کے بعد آپ کے پاس ناقابل رسائی اور قابل رسائی ڈیٹا کا مجموعہ ہوگا.
کیا OpenAI کسی API پروجیکٹ کے لیے میرا KMS شناخت کنندہ بدلنے میں میری مدد کر سکتا ہے.
اگر آپ API استعمال کر رہے ہیں، تو API پروجیکٹس کو آرکائیو کرنا اور نئے پروجیکٹس بنانا آسان بناتا ہے، اس لیے بہتر ہے کہ وہ پروجیکٹ آرکائیو کر دیں جس کا ڈیٹا بہرحال قابل رسائی نہیں ہے، OpenAI کے ساتھ نئی EKM کنفگ رجسٹر کریں، اور نئی KMS کی کے ساتھ نیا API پروجیکٹ بنائیں.
اگر میں خود اپنا KMS شناخت کنندہ باقاعدگی سے بدلنا چاہوں تو کیا ہوگا.
یہ تجویز نہیں کیا جاتا، کیونکہ غالباً آپ اپنی key کو باقاعدگی سے منسوخ نہیں کرنا چاہیں گے. تاہم، اگر آپ ایسا cloud provider استعمال کرتے ہیں جو KMS key alias کو support کرتا ہے، تو آپ پھر بھی یہ کر سکتے ہیں (AWS مثال). آپ وہ KMS key alias OpenAI کے ساتھ register کر سکتے ہیں، اور پھر اپنے cloud provider پر کسی بھی وقت alias کے underlying KMS identifier کو بدل کر key revocation جاری کر سکتے ہیں.
Beta بمقابلہ GA رویہ
کیا production میں encryption beta استعمال کرتے وقت کوئی known risks یا system-level changes ہیں.
beta environment عملی طور پر GA کے مساوی ہے، اور کسی migration steps کی توقع نہیں ہے. بنیادی risk یہ ہے کہ کچھ edge-case features ابھی encrypted content کو support نہ کرتے ہوں، کیونکہ code paths نامکمل ہیں. یہ rare ہیں اور فعال طور پر resolve کیے جا رہے ہیں. ان ممکنہ مسائل کے باوجود data مکمل طور پر encrypted اور protected رہتا ہے.
کیا beta سے GA پر جانے کے لیے کوئی migration steps ہوں گے.
نہیں. encryption beta استعمال کرنے والی ورک اسپیسز GA میں کسی user action کے بغیر خودکار طور پر supported ہوں گی.
اضافی تکنیکی تفصیلات
Envelope Encryption & اجازتیں
کیا ہمیں EKM کے لیے OpenAI کو GenerateDataKey اجازتیں دینی ہوں گی.
نہیں. OpenAI کو آپ کی KMS کی پر صرف Encrypt اور Decrypt اجازتیں درکار ہیں. GenerateDataKey اجازت EKM انٹیگریشن کے لیے ضروری نہیں ہے.
کیا OpenAI صارف کے ڈیٹا کے لیے envelope encryption استعمال کرتا ہے.
ہاں. OpenAI envelope encryption ماڈل استعمال کرتا ہے:
Customer KMS: Key Encryption Keys (KEKs) کا نظم کرتا ہے. OpenAI کبھی KEKs کو نہیں دیکھتا اور نہ انہیں اسٹور کرتا ہے.
OpenAI Infrastructure: Data Encryption Keys (DEKs) بناتا اور ان کا نظم کرتا ہے. ہر DEK کو اسٹوریج سے پہلے آپ کے KEK کے ساتھ encrypt (wrap) کیا جاتا ہے.
Data Flow:
Customer data کو DEK کے ساتھ انکرپٹ کیا جاتا ہے.
اس DEK کو آپ کے KEK کے ساتھ انکرپٹ کیا جاتا ہے، جس سے eDEK بنتا ہے.
eDEK کو encrypted data کے ساتھ محفوظ کیا جاتا ہے.
ڈیٹا ڈکرپٹ کرنے کے لیے OpenAI آپ کے KMS سے eDEK ڈکرپٹ کرنے کی درخواست کرتا ہے، DEK حاصل کرتا ہے، اور content کو ڈکرپٹ کرتا ہے.
OpenAI نے KMS کو KEKs اور DEKs دونوں کا نظم کرنے دینے کے بجائے یہ ماڈل کیوں چنا.
Envelope encryption کے دو عام طریقے ہیں:
KMS کے زیر انتظام KEKs اور DEKs:
فوائد: نفاذ آسان ہے، انکرپشن انفراسٹرکچر برقرار رکھنے کی ضرورت نہیں.
نقصانات: ہر انکرپشن/ڈکرپشن درخواست KMS تک جاتی ہے، جس سے لیٹنسی اور لاگت بڑھتی ہے، اور ناکامی کا ایک واحد نقطہ پیدا ہوتا ہے.
KMS کے زیر انتظام KEKs / OpenAI کے زیر انتظام DEKs (ہمارا طریقہ):
فوائد: latency اور cost نمایاں طور پر کم، scalability اور reliability بہتر، اور جزوی KMS outages کے دوران operation جاری رہتا ہے (DEK cache TTL تک).
نقصانات: OpenAI کی طرف implementation قدرے زیادہ complex ہے.
یہ ڈیزائن OpenAI کو مضبوط security guarantees فراہم کرنے کے قابل بناتا ہے، جبکہ صارفین کے لیے operational risk اور cost کم رہتی ہے.
DEKs کتنی بار روٹیٹ کیے جاتے ہیں.
ہر DEK تقریباً ہر 60 منٹ بعد روٹیٹ کیا جاتا ہے. یہ وقتی isolation فراہم کرتا ہے — اگر کسی طرح کوئی DEK compromised بھی ہو جائے، تو اثر صرف اس ایک گھنٹے کی window میں encrypted data تک محدود رہے گا.
KMS Request Volume & Observability
ہمیں صارف کے پیغامات کی تعداد کے مقابلے میں KMS درخواستیں بہت کم نظر آتی ہیں. کیا یہ اعداد ملنے چاہئیں.
نہیں، یہ براہ راست مربوط نہیں ہوں گے.
چونکہ OpenAI کارکردگی کی خاطر DEKs کو میموری میں cache کرتا ہے، اس لیے KMS calls صرف تب کی جاتی ہیں جب کسی DEK کو ڈکرپٹ کرنے کی ضرورت ہو، ہر encryption یا decryption operation پر نہیں. اس کے نتیجے میں، آپ کو یہ توقع رکھنی چاہیے:
صارف کی interactions کے مقابلے میں KMS requests کم ہوں گی.
کبھی کبھار spikes آئیں گے جب cached DEKs کی میعاد ختم ہو گی (تقریباً ہر گھنٹے) یا جب پرانے encrypted data تک رسائی درکار ہو گی.
اضافی calls historical data حاصل کرتے وقت ہوں گی، مثلاً جب کوئی صارف طویل گفتگو جاری رکھتا ہے اور پرانے DEKs لوڈ کرنے پڑتے ہیں.
KMS requests کی درست تعداد caching state، صارف کے رویے، data access patterns، اور گفتگو کی طوالت پر منحصر ہوتی ہے، اس لیے یہ message volume سے براہ راست مربوط نہیں ہوگی.