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

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

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

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

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

सुविधाएं

  • डेटा कंट्रोल: CMEK की मदद से, KMS कुंजी को मैनेज किया जा सकता है. आपके पास Cloud Firestore डेटाबेस में सेव किए गए डेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए इस्तेमाल की गई कुंजी को रोटेट करने, बंद करने, और मिटाने का विकल्प होता है.
  • परफ़ॉर्मेंस: सीएमईके से Cloud Firestore एसएलए पर कोई असर नहीं पड़ता.
  • ऑडिट करने की सुविधा: अगर आपने क्लाउड केएमएस (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 का इस्तेमाल करने वाले डेटाबेस में डेटा वापस लाने या क्लोन करने का विकल्प भी होता है.
  • Cloud Firestore, सीएमईके से सुरक्षित किए गए डेटाबेस की सीमित संख्या के साथ काम करता है.
  • हम Cloud Functions (पहली जनरेशन) के इंटिग्रेशन के साथ, सीएमईके सुरक्षा की सुविधा नहीं देते हैं. अगर आपको सीएमईके सुरक्षा चाहिए, तो Cloud Run फ़ंक्शन Firestore ट्रिगर (दूसरी जनरेशन) का इस्तेमाल करें.

CMEK से सुरक्षित किए गए डेटाबेस से डेटा को कैसे ट्रांसफ़र किया जा सकता है

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

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

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