सुरक्षित करने वाली ऐसी कुंजियां जिन्हें ग्राहक मैनेज करता है (CMEK)

Cloud Firestore में MongoDB के साथ काम करने वाले सभी डेटा को डिफ़ॉल्ट रूप से, Google के डिफ़ॉल्ट एन्क्रिप्शन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया जाता है. MongoDB के साथ काम करने वाला Cloud Firestore, इस एन्क्रिप्शन को मैनेज करता है. इसके लिए, आपको कुछ भी करने की ज़रूरत नहीं होती.

अगर आपको डेटा को सुरक्षित रखने वाली कुंजियों से जुड़ी किसी कानूनी या नियामक से जुड़ी ज़रूरी शर्तों का पालन करना है, तो Cloud Firestore के साथ MongoDB के साथ काम करने की सुविधा के लिए, ग्राहक की ओर से मैनेज की जाने वाली एन्क्रिप्शन कुंजियों (सीएमईके) का इस्तेमाल किया जा सकता है. आपके डेटा को सुरक्षित रखने वाली एन्क्रिप्शन कुंजियों को Google मैनेज करने के बजाय, MongoDB के साथ काम करने वाले आपके Cloud Firestore डेटाबेस को ऐसी कुंजी का इस्तेमाल करके सुरक्षित किया जाता है जिसे Cloud Key Management Service (Cloud KMS) में कंट्रोल और मैनेज किया जाता है.

इस पेज पर, MongoDB के साथ काम करने वाले Cloud Firestore के लिए सीएमईके के बारे में बताया गया है. सीएमईके के बारे में ज़्यादा जानकारी के लिए, Cloud KMS का यह दस्तावेज़ पढ़ें. इसमें यह भी बताया गया है कि इसे कब और क्यों चालू करना चाहिए:

Cloud Firestore के साथ MongoDB के साथ काम करने वाले वर्शन में, CMEK से जुड़े टास्क करने के निर्देशों के लिए, CMEK का इस्तेमाल करना लेख पढ़ें.

सुविधाएं

  • डेटा कंट्रोल: CMEK की मदद से, KMS कुंजी को मैनेज किया जा सकता है. Cloud Firestore में MongoDB के साथ काम करने वाले डेटाबेस में, डेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए इस्तेमाल की गई कुंजी को रोटेट, बंद, और डिस्ट्रॉय किया जा सकता है.
  • परफ़ॉर्मेंस: सीएमईके से Cloud Firestore एसएलए पर कोई असर नहीं पड़ता.
  • ऑडिट करने की सुविधा: अगर आपने Cloud KMS के लिए ऑडिट लॉगिंग की सुविधा चालू की है, तो कुंजी पर की गई सभी कार्रवाइयां लॉग की जाती हैं. इन्हें Cloud Logging में देखा जा सकता है.
  • संगठन की नीति से जुड़ी पाबंदियां: CMEK संगठन की नीति से जुड़ी पाबंदियों का इस्तेमाल करके, अपने संगठन में Cloud Firestore के साथ MongoDB के साथ काम करने वाले डेटाबेस के लिए, एन्क्रिप्शन से जुड़ी नीति के पालन की ज़रूरी शर्तों के बारे में बताया जा सकता है.

कीमत

Cloud KMS, कुंजी की लागत और उस कुंजी का इस्तेमाल करके किए गए किसी भी क्रिप्टोग्राफ़िक ऑपरेशन के लिए शुल्क लेता है. ज़्यादा जानकारी के लिए, Cloud KMS की कीमत देखें.

जब MongoDB के साथ काम करने वाला Cloud Firestore, Cloud KMS कुंजी से एन्क्रिप्शन या डिक्रिप्शन की कार्रवाई करने के लिए कहता है, तब आपसे ऑपरेशन के लिए शुल्क लिया जाता है. ग्राहक की ओर से मैनेज की गई कुंजी का इस्तेमाल करके, एन्क्रिप्शन या डिक्रिप्शन की प्रोसेस हर पांच मिनट में होती है. यह डेटाबेस के अनुरोधों के साथ सिंक नहीं होती. Cloud Firestore के MongoDB के साथ काम करने की सुविधा से जनरेट होने वाली क्रिप्टोग्राफ़िक कार्रवाइयों की अनुमानित संख्या को देखते हुए, लागत आम तौर पर कम होती है. Cloud Audit Logs के लिए अतिरिक्त शुल्क लगता है. हालांकि, क्रिप्टोग्राफ़िक ऑपरेशनों की अनुमानित संख्या को देखते हुए, यह शुल्क आम तौर पर कम होता है.

CMEK से सुरक्षित डेटाबेस का इस्तेमाल करने पर, Cloud Firestore with MongoDB compatibility के लिए कोई अतिरिक्त शुल्क नहीं लिया जाता. साथ ही, Cloud Firestore with MongoDB compatibility की कीमत लागू होती रहती है.

अगर किसी डेटाबेस के लिए कुंजी रद्द की जाती है, तो स्टोरेज का शुल्क इस आधार पर लिया जाएगा कि कुंजी आखिरी दिन कितने साइज़ के लिए उपलब्ध थी. डेटाबेस का साइज़ कम होने तक, आपको स्टोरेज के लिए शुल्क देना होगा. ऐसा तब तक होगा, जब तक डेटाबेस मिट नहीं जाता या कुंजी फिर से उपलब्ध नहीं हो जाती.

CMEK की मदद से किस डेटा को सुरक्षित किया जाता है

MongoDB के साथ काम करने वाला CMEK-सुरक्षित डेटाबेस बनाने पर, आपकी Cloud KMS कुंजी का इस्तेमाल, जो डेटा एक्टिव नहीं है उसे सुरक्षित करने के लिए किया जाता है. इसमें वह डेटा शामिल है जिसे आपने डिस्क या फ़्लैश ड्राइव पर सेव किया है. इसमें इंडेक्स और बैकअप भी शामिल हैं. हालांकि, कुछ मामलों में छूट मिल सकती है. नीचे दिए गए डेटा टाइप को Google के डिफ़ॉल्ट एन्क्रिप्शन (सुरक्षित करने का तरीका) से एन्क्रिप्ट (सुरक्षित) किया जाता है, न कि CMEK कुंजी से:

  • ट्रांज़िट या मेमोरी में मौजूद डेटा
  • डेटाबेस का मेटाडेटा

उपलब्ध न होने वाली कुंजी की स्थिति को कैसे मैनेज किया जाता है

डेटा के हर अनुरोध पर, एन्क्रिप्ट और डिक्रिप्ट करने की कार्रवाइयां नहीं की जाती हैं. इसके बजाय, Cloud Firestore with MongoDB compatibility सिस्टम, हर पांच मिनट में Cloud KMS को पोल करता है. इससे यह पता चलता है कि कुंजी अब भी उपलब्ध है या नहीं. अगर कुंजी उपलब्ध होती है, तो यह सिस्टम एन्क्रिप्ट (सुरक्षित) और डिक्रिप्ट (सुरक्षित तरीके से बदलना) करने की कार्रवाइयां करता है.

अगर सिस्टम को पता चलता है कि कुंजी उपलब्ध नहीं है, तो Cloud Firestore के साथ MongoDB के साथ काम करने वाले डेटाबेस को किए गए सभी कॉल 10 मिनट के अंदर, INVALID_ARGUMENT गड़बड़ी दिखाएंगे. इनमें पढ़ने, लिखने, और क्वेरी करने के अनुरोध शामिल हैं. गड़बड़ी का यह मैसेज दिखेगा:

The customer-managed encryption key required by the requested
resource is not accessible.

अगर डेटाबेस में टाइम-टू-लिव (टीटीएल) नीतियां लागू हैं और कुंजी के उपलब्ध न होने पर, किसी भी समयसीमा खत्म होने की अवधि बढ़ जाती है, तो टीटीएल के हिसाब से डेटा मिटाने की प्रोसेस तब तक के लिए रुक जाएगी, जब तक कुंजी को फिर से लागू नहीं किया जाता. अगर डेटाबेस में लंबे समय से कोई ऑपरेशन चल रहा है, तो उस पर ये असर पड़ेंगे:

कुंजियों को किसी भी ऐसी स्थिति में अनुपलब्ध माना जाता है जिसमें Cloud Firestore with MongoDB compatibility को जान-बूझकर कुंजी ऐक्सेस करने की अनुमति नहीं दी जाती है. इसमें इस तरह का कॉन्टेंट शामिल है:

अगर कुंजी को वापस लाया जाता है, तो पोलिंग ऑपरेशन से पता चलता है कि कुंजी फिर से उपलब्ध है. आम तौर पर, ऐक्सेस कुछ ही मिनटों में फिर से चालू हो जाता है. हालांकि, कुछ मामलों में इसमें कुछ घंटे लग सकते हैं. ध्यान दें कि Cloud KMS कुंजियों पर कुछ कार्रवाइयों, जैसे कि किसी कुंजी को बंद करने या उसे नष्ट करने में तीन घंटे तक लग सकते हैं. MongoDB के साथ काम करने वाला Cloud Firestore, Cloud KMS में बदलाव लागू होने तक उन्हें नहीं पहचानता.

किसी कुंजी को फिर से चालू करने के लिए, स्थिति के हिसाब से ये काम किए जाते हैं:

  • बंद किए गए कुंजी वर्शन को फिर से चालू करना.
  • कुंजी के मिटाए गए वर्शन को वापस लाना. किसी कुंजी के वर्शन को हमेशा के लिए मिटाने से पहले, उसे मिटाने के लिए शेड्यूल किया जाता है. किसी कुंजी को सिर्फ़ उस अवधि के दौरान वापस लाया जा सकता है जब कुंजी के किसी वर्शन को खत्म करने के लिए शेड्यूल किया गया हो. हमेशा के लिए मिटाई गई कुंजी को वापस नहीं लाया जा सकता.
  • Cloud Firestore सर्विस एजेंट को कुंजी ऐक्सेस करने की अनुमति फिर से देना.

डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाते समय ध्यान रखने वाली बातें

CMEK की को रोटेट करने पर, Cloud Firestore with MongoDB compatibility, डेटाबेस को CMEK की के नए प्राइमरी वर्शन से फिर से एन्क्रिप्ट (सुरक्षित) करता है. फिर से एन्क्रिप्ट (सुरक्षित) करने की प्रोसेस के दौरान, पुराने और नए, दोनों वर्शन की सुरक्षा कुंजी उपलब्ध रखें. फिर से एन्क्रिप्ट (सुरक्षित) करने की प्रोसेस पूरी होने के बाद, सीएमईके कुंजी के पुराने वर्शन को बंद करने या मिटाने से डेटाबेस का ऐक्सेस बंद नहीं होगा. ऐसा इसलिए, क्योंकि इसे नए प्राइमरी कुंजी वर्शन से एन्क्रिप्ट (सुरक्षित) किया गया है.

डेटाबेस को सुरक्षित रखने के लिए इस्तेमाल किए जा रहे मुख्य वर्शन भी देखे जा सकते हैं. ज़्यादा जानकारी के लिए, इस्तेमाल की जा रही कुंजी देखना लेख पढ़ें.

बाहरी कुंजी के बारे में ध्यान रखने वाली बातें

Cloud EKM कुंजी का इस्तेमाल करने पर, Google के पास यह कंट्रोल नहीं होता कि बाहरी कुंजी मैनेजमेंट पार्टनर सिस्टम में, बाहरी तौर पर मैनेज की गई आपकी कुंजी उपलब्ध है या नहीं.

अगर बाहरी तौर पर मैनेज की गई कुंजी उपलब्ध नहीं है, तो Cloud Firestore with MongoDB compatibility, कुंजी के कैश मेमोरी वर्शन का इस्तेमाल करके डेटाबेस के सभी ऑपरेशन को एक घंटे तक जारी रखता है.

अगर एक घंटे बाद भी, MongoDB के साथ काम करने वाला Cloud Firestore, Cloud KMS से कनेक्ट नहीं हो पाता है, तो MongoDB के साथ काम करने वाला Cloud Firestore, सुरक्षा के लिहाज़ से डेटाबेस को ऑफ़लाइन कर देता है. डेटाबेस को किए गए कॉल पूरे नहीं होंगे. आपको INVALID_ARGUMENT गड़बड़ी का मैसेज दिखेगा, जिसमें ज़्यादा जानकारी शामिल होगी.

बाहरी कुंजियों का इस्तेमाल करते समय ध्यान रखने वाली अन्य बातों के बारे में जानने के लिए, Cloud External Key Manager का दस्तावेज़ देखें.

बैकअप लें और बहाल करें

बैकअप में, एन्क्रिप्शन के उसी तरीके का इस्तेमाल किया जाता है जिसका इस्तेमाल उस डेटाबेस में किया जाता है जिससे आपने बैकअप बनाया है. जब सीएमईके से सुरक्षित किया गया, MongoDB के साथ काम करने वाला Cloud Firestore डेटाबेस बैकअप बनाता है, तो वह बैकअप को उस प्राइमरी कुंजी के वर्शन से एन्क्रिप्ट (सुरक्षित) करता है जिसका इस्तेमाल बैकअप बनाते समय किया गया था.

MongoDB के साथ काम करने वाला Cloud Firestore, सीएमईके डेटाबेस का पहला बैकअप तब बनाता है, जब बैकअप शेड्यूल चालू करने के 24 घंटे पूरे हो जाते हैं.

MongoDB के साथ काम करने वाले Cloud Firestore के बैकअप के बारे में ज़्यादा जानने के लिए, डेटा का बैक अप लेना और उसे वापस लाना लेख पढ़ें.

बैकअप से वापस लाए गए डेटाबेस में, डिफ़ॉल्ट रूप से एन्क्रिप्शन की उसी तकनीक का इस्तेमाल किया जाता है जिसका इस्तेमाल बैकअप में किया गया था. डेटाबेस को वापस लाने के दौरान, एन्क्रिप्शन के किसी दूसरे टाइप को इन तरीकों से तय किया जा सकता है:

  • नई कुंजी का इस्तेमाल करके, CMEK डेटाबेस में वापस लाएं.
  • ऐसे नॉन-सीएमईके डेटाबेस में वापस लाएं जो Google के डिफ़ॉल्ट एन्क्रिप्शन का इस्तेमाल करता है.
  • ऐसे डेटाबेस में वापस लाएं जिसमें बैकअप की तरह ही एन्क्रिप्शन का इस्तेमाल किया गया हो.

बैकअप से, MongoDB के साथ काम करने वाले Cloud Firestore डेटाबेस को वापस लाने के बारे में ज़्यादा जानने के लिए, डेटाबेस के बैकअप से डेटा वापस लाना लेख पढ़ें. CMEK से सुरक्षित किए गए, Cloud Firestore के MongoDB के साथ काम करने वाले डेटाबेस को बैकअप से वापस लाने के बारे में ज़्यादा जानने के लिए, CMEK से सुरक्षित किए गए डेटाबेस को वापस लाना लेख पढ़ें.

क्लोन बनाएं

डिफ़ॉल्ट रूप से, किसी दूसरे डेटाबेस से क्लोन किए गए डेटाबेस में, सोर्स डेटाबेस की तरह ही एन्क्रिप्शन मेकैनिज़्म का इस्तेमाल किया जाता है. डेटाबेस को क्लोन करते समय, इनमें से किसी एक तरीके का इस्तेमाल करके, एन्क्रिप्शन का कोई दूसरा टाइप तय किया जा सकता है:

  • नई तय की गई कुंजी के साथ, सीएमईके डेटाबेस में क्लोन करें.
  • ऐसे नॉन-सीएमईके डेटाबेस में क्लोन करें जो Google के डिफ़ॉल्ट एन्क्रिप्शन का इस्तेमाल करता है.
  • (डिफ़ॉल्ट) ऐसे डेटाबेस में क्लोन करें जो सोर्स डेटाबेस की तरह ही एन्क्रिप्शन का इस्तेमाल करता है.

MongoDB के साथ काम करने वाले Cloud Firestore डेटाबेस को क्लोन करने के बारे में ज़्यादा जानने के लिए, डेटाबेस क्लोन करना लेख पढ़ें. CMEK से सुरक्षित किए गए, MongoDB के साथ काम करने वाले Cloud Firestore डेटाबेस को क्लोन करने के बारे में ज़्यादा जानने के लिए, CMEK से सुरक्षित किए गए डेटाबेस को क्लोन करना लेख पढ़ें.

कुंजी ट्रैकिंग

कुंजी ट्रैकिंग का इस्तेमाल करके, उन संसाधनों को देखा जा सकता है जिन्हें कोई कुंजी सुरक्षित करती है. उदाहरण के लिए, MongoDB के साथ काम करने वाले Cloud Firestore डेटाबेस. कुंजी को ट्रैक करने के बारे में ज़्यादा जानने के लिए, कुंजी के इस्तेमाल की जानकारी देखना लेख पढ़ें.

सीएमईके और कुंजी की उपलब्धता

कुंजियां उपलब्ध न होने या बंद होने पर, सीएमईके की सुविधा वाले डेटाबेस में ये समस्याएं हो सकती हैं:

  • आपके पास ऐसी सीएमईके डेटाबेस को मिटाने का विकल्प होता है जिसमें उपलब्ध न होने वाली कुंजियां हों.

  • CMEK की सुविधा वाले डेटाबेस को बनाते समय, Google Cloud Console में उपलब्ध कुंजियों की सूची में बंद की गई कुंजियां नहीं दिखती हैं. अगर आपने मैन्युअल तरीके से बंद की गई कोई कुंजी डाली है, तो डेटाबेस बनाने की प्रोसेस पूरी नहीं होगी. साथ ही, आपको INVALID_ARGUMENTगड़बड़ी 400 का मैसेज दिखेगा.

सीमाएं

  • CMEK से सुरक्षित किए गए डेटाबेस के लिए, कुंजी नहीं बदली जा सकती. कुंजियों को घुमाया जा सकता है, चालू किया जा सकता है, और बंद किया जा सकता है.

  • मौजूदा डेटाबेस पर सीएमईके की सुविधा चालू नहीं की जा सकती. सीएमईके की सुविधा सिर्फ़ नए डेटाबेस पर चालू की जा सकती है. साथ ही, डेटाबेस बनाते समय ही इसे चालू करना ज़रूरी है. अगर आपको किसी मौजूदा नॉन-सीएमईके डेटाबेस में मौजूद डेटा को सीएमईके से सुरक्षित डेटाबेस में माइग्रेट करना है, तो अपना डेटा एक्सपोर्ट करें. इसके बाद, डेटा को सीएमईके से सुरक्षित नए डेटाबेस में इंपोर्ट करें. आपके पास, बिना CMEK वाले डेटाबेस से CMEK वाले डेटाबेस में डेटा वापस लाने या क्लोन करने का विकल्प भी होता है.

  • Cloud Firestore, सीएमईके से सुरक्षित किए गए डेटाबेस की सीमित संख्या के साथ काम करता है.

आगे क्या करना है