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

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

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

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

Cloud Firestore की मदद से, सीएमईके से जुड़े टास्क पूरे करने के निर्देश पाने के लिए, सीएमईके का इस्तेमाल करना लेख पढ़ें.

सुविधाएं

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

कीमत

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

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

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

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

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

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

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

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

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

अगर सिस्टम को पता चलता है कि कुंजी उपलब्ध नहीं है, तो 10 मिनट के अंदर Cloud Firestore डेटाबेस को किए गए सभी कॉल, FAILED_PRECONDITION गड़बड़ी दिखाते हैं. इनमें पढ़ने, लिखने, और क्वेरी करने के कॉल शामिल हैं. साथ ही, The customer-managed encryption key required by the requested resource is not accessible मैसेज भी दिखता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्लोन बनाएं

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

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

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

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

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

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

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

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

सीमाएं

  • CMEK से सुरक्षित किए गए डेटाबेस के लिए, कुंजी नहीं बदली जा सकती. कुंजियों को घुमाया जा सकता है, चालू किया जा सकता है, और बंद किया जा सकता है.
  • CMEK से सुरक्षित किए गए डेटाबेस, सिर्फ़ इकाई और दस्तावेज़ के डेटा के लिए Key Visualizer का इस्तेमाल कर सकते हैं. इंडेक्स डेटा के लिए इसका इस्तेमाल नहीं किया जा सकता.
  • मौजूदा डेटाबेस पर सीएमईके की सुविधा चालू नहीं की जा सकती. CMEK की सुविधा सिर्फ़ नए डेटाबेस पर चालू की जा सकती है. साथ ही, डेटाबेस बनाते समय ही इसे चालू करना ज़रूरी है. अगर आपको किसी मौजूदा नॉन-सीएमईके डेटाबेस में मौजूद डेटा को सीएमईके से सुरक्षित डेटाबेस में माइग्रेट करना है, तो अपना डेटा एक्सपोर्ट करें. इसके बाद, डेटा को सीएमईके से सुरक्षित नए डेटाबेस में इंपोर्ट करें. आपके पास, बिना CMEK वाले डेटाबेस से CMEK वाले डेटाबेस में डेटा वापस लाने या क्लोन करने का विकल्प भी होता है.
  • Cloud Firestore, सीएमईके से सुरक्षित किए गए डेटाबेस की सीमित संख्या के साथ काम करता है.
  • Cloud Functions (पहली जनरेशन) के इंटिग्रेशन के साथ, हम सीएमईके सुरक्षा की सुविधा नहीं देते हैं. अगर आपको सीएमईके सुरक्षा चाहिए, तो Cloud Run फ़ंक्शन Firestore ट्रिगर (दूसरी जनरेशन) का इस्तेमाल करें.

CMEK से सुरक्षित किए गए डेटाबेस से डेटा कैसे बाहर जा सकता है

  • आपका ऐप्लिकेशन जिस डेटा को कॉपी करता है उसे उसके उपयोगकर्ता किसी भी तरीके से सेव कर सकते हैं. Cloud Firestore डेटा को ऐक्सेस करने वाले किसी भी ऐप्लिकेशन के लिए, सुरक्षा से जुड़े सही कंट्रोल ज़रूरी होते हैं. इससे यह पक्का किया जा सकता है कि डेटा को सिर्फ़ वे लोग ऐक्सेस कर पाएं जिनके पास ज़रूरी अनुमति है. ज़्यादा जानकारी के लिए, सुरक्षा के नियम और IAM देखें.

  • CMEK से सुरक्षित किए गए डेटाबेस से डेटा को, बिना CMEK वाले डेटाबेस में ले जाया जा सकता है. इसके लिए, बैकअप लेने और डेटा वापस पाने की सुविधा, क्लोन बनाने या इंपोर्ट और एक्सपोर्ट का इस्तेमाल करें. सिर्फ़ उन उपयोगकर्ताओं को ये कार्रवाइयां करने की अनुमति दें जिनके पास अनुमति है. इसके लिए, IAM कंट्रोल का इस्तेमाल करें. इसके अलावा, CMEK की संगठन से जुड़ी नीति की शर्तों का इस्तेमाल करके, यह ज़रूरी किया जा सकता है कि रीस्टोर या क्लोन किए गए सभी डेटाबेस और इंपोर्ट के लिए इस्तेमाल किए गए सभी Cloud Storage बकेट, CMEK से सुरक्षित हों.

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