डेटा को एन्क्रिप्ट (सुरक्षित) करें और उसे डिक्रिप्ट करें

इस गाइड में बताया गया है कि Google Workspace क्लाइंट-साइड एन्क्रिप्शन एपीआई का इस्तेमाल करके, एन्क्रिप्ट (सुरक्षित) करने और उसे डिक्रिप्ट करने की सुविधा कैसे काम करती है.

एन्क्रिप्ट (सुरक्षित) की गई फ़ाइलें शेयर करने वाले उपयोगकर्ता, पहचान देने वाली सेवा (IdP) की उन सभी सेवाओं को अनुमति दें जिनका इस्तेमाल किया जा रहा है. आम तौर पर, आपको ज़रूरी आईडीपी (IdP) की जानकारी, सार्वजनिक तौर पर उपलब्ध .well-known फ़ाइल में मिल सकती है. इसके अलावा, आईडीपी की जानकारी पाने के लिए, संगठन के Google Workspace एडमिन से संपर्क करें.

डेटा एन्क्रिप्ट (सुरक्षित) करें

जब Google Workspace का कोई उपयोगकर्ता, क्लाइंट-साइड एन्क्रिप्शन (सीएसई) वाले डेटा को सेव या सेव करने का अनुरोध करता है, तो Google Workspace आपके केएसीएलएस एंडपॉइंट के यूआरएल को एन्क्रिप्ट (सुरक्षित) करने के लिए, wrap अनुरोध भेजता है. पेरीमीटर और JWT पर दावा आधारित जांच जैसी वैकल्पिक सुरक्षा जांचों के अलावा, आपके केएसीएलएस को ये चरण पूरे करने होंगे:

1. अनुरोध करने वाले उपयोगकर्ता की पुष्टि करें.

   • पुष्टि करने वाले टोकन और ऑथराइज़ेशन टोकन, दोनों की पुष्टि करें.
   • ईमेल पर किए गए दावों का केस-इनसेंसिटिव मिलान करके, यह पक्का करें कि अनुमति और पुष्टि करने वाले टोकन एक ही उपयोगकर्ता के लिए हैं.
   • जब ऑथेंटिकेशन टोकन में वैकल्पिक google_email दावा शामिल होता है, तो इसकी तुलना, केस-इनसेंसिटिव तरीके का इस्तेमाल करके, अनुमति देने वाले टोकन में मौजूद ईमेल दावे से की जानी चाहिए. इस तुलना के लिए, पुष्टि करने वाले टोकन में ईमेल पते का इस्तेमाल न करें.
   • ऐसे मामलों में जहां पुष्टि करने वाले टोकन में वैकल्पिक google_email दावा मौजूद नहीं होता है, वहां पुष्टि करने वाले टोकन में मौजूद ईमेल पर किए गए दावे की तुलना, केस-इनसेंसिटिव तरीके से की जानी चाहिए. यह तुलना, ऑथराइज़ेशन टोकन में मौजूद ईमेल दावे से की जानी चाहिए.
   • अगर Google किसी ऐसे ईमेल के लिए अनुमति टोकन जारी करता है जो Google खाते से नहीं जुड़ा है, तो ऐसे में email_type का दावा मौजूद होना चाहिए. यह मेहमान ऐक्सेस की सुविधा का एक अहम हिस्सा है. इससे केएसीएलएस को बाहरी उपयोगकर्ताओं पर अतिरिक्त सुरक्षा उपाय लागू करने के लिए अहम जानकारी मिलती है.
     • केएसएलएस, इस जानकारी का इस्तेमाल कैसे कर सकता है, इसके कुछ उदाहरण यहां दिए गए हैं:
     • डेटा लॉग करने की अतिरिक्त ज़रूरी शर्तें लागू करने के लिए.
     • सिर्फ़ मेहमान आईडीपी (IdP) को पुष्टि करने वाला टोकन जारी करने की अनुमति देने के लिए.
     • पुष्टि करने वाले टोकन पर अतिरिक्त दावों की ज़रूरत के लिए.
     • अगर ग्राहक ने मेहमान ऐक्सेस को कॉन्फ़िगर नहीं किया है, तो ऐसे सभी अनुरोध अस्वीकार किए जा सकते हैं जिनमें email_type को google-visitor या customer-idp पर सेट किया गया है. google के email_type वाले या सेट नहीं किए गए email_type वाले अनुरोध स्वीकार किए जाते रहेंगे.
   • देखें कि अनुमति वाले टोकन में role दावा "लेखक" या "अपग्रेडर" है या नहीं.
   • देख लें कि अनुमति देने वाले टोकन में मौजूद kacls_url का दावा, मौजूदा केएसीएलएस यूआरएल से मेल खाता हो. इस जांच की मदद से, उन संभावित मैन-इन-द-मिडल सर्वर का पता लगाया जा सकता है जिन्हें इनसाइडर या नुकसान पहुंचाने वाले डोमेन एडमिन ने कॉन्फ़िगर किया है.
   • पुष्टि करने और अनुमति वाले दावों, दोनों का इस्तेमाल करके पेरीमीटर की जांच करें.

2. किसी प्रमाणित एन्क्रिप्शन एल्गोरिदम का इस्तेमाल करके, नीचे दिए गए हिस्सों को एन्क्रिप्ट (सुरक्षित) करें:

   • डेटा एन्क्रिप्ट (सुरक्षित) करने की कुंजी (DEK)
   • ऑथराइज़ेशन टोकन में मौजूद resource_name और perimeter_id वैल्यू
   • कोई अन्य संवेदनशील जानकारी

3. कार्रवाई को लॉग करें. इसमें, कार्रवाई शुरू करने वाले उपयोगकर्ता, resource_name, और अनुरोध में दी गई वजह की जानकारी भी शामिल होनी चाहिए.

4. एन्क्रिप्ट (सुरक्षित) किए गए ऑब्जेक्ट के साथ, Google Workspace में सेव किए जाने वाले ओपेक बाइनरी ऑब्जेक्ट को वापस करें. साथ ही, बाद में होने वाली किसी भी कुंजी के खोलने के दौरान, इस ऑब्जेक्ट को ऐसे ही भेजा जाएगा. या स्ट्रक्चर्ड गड़बड़ी वाला जवाब दिखाएं.

   • बाइनरी ऑब्जेक्ट में, एन्क्रिप्ट (सुरक्षित) किए गए DEK की इकलौती कॉपी होनी चाहिए. लागू करने के तरीके से जुड़ा खास डेटा इसमें सेव किया जा सकता है.

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

डेटा डिक्रिप्ट करें

जब Google Workspace का कोई उपयोगकर्ता, क्लाइंट-साइड एन्क्रिप्शन (सीएसई) का डेटा खोलने का अनुरोध करता है, तो Google Workspace आपके केएसीएलएस एंडपॉइंट यूआरएल को डिक्रिप्शन के लिए, unwrap अनुरोध भेजता है. पेरीमीटर और JWT पर दावा आधारित जांच जैसी वैकल्पिक सुरक्षा जांचों के अलावा, आपके केएसीएलएस को ये चरण पूरे करने होंगे:

1. अनुरोध करने वाले उपयोगकर्ता की पुष्टि करें.

   • पुष्टि करने वाले टोकन और ऑथराइज़ेशन टोकन, दोनों की पुष्टि करें.
   • ईमेल पर किए गए दावों का केस-इनसेंसिटिव मिलान करके, यह पक्का करें कि अनुमति और पुष्टि करने वाले टोकन एक ही उपयोगकर्ता के लिए हैं.
   • जब ऑथेंटिकेशन टोकन में वैकल्पिक google_email दावा शामिल होता है, तो इसकी तुलना, केस-इनसेंसिटिव तरीके का इस्तेमाल करके, अनुमति देने वाले टोकन में मौजूद ईमेल दावे से की जानी चाहिए. इस तुलना के लिए, पुष्टि करने वाले टोकन में ईमेल पते का इस्तेमाल न करें.
   • ऐसे मामलों में जहां पुष्टि करने वाले टोकन में वैकल्पिक google_email दावा मौजूद नहीं होता है, वहां पुष्टि करने वाले टोकन में मौजूद ईमेल पर किए गए दावे की तुलना, केस-इनसेंसिटिव तरीके से की जानी चाहिए. यह तुलना, ऑथराइज़ेशन टोकन में मौजूद ईमेल दावे से की जानी चाहिए.
   • अगर Google किसी ऐसे ईमेल के लिए अनुमति टोकन जारी करता है जो Google खाते से नहीं जुड़ा है, तो ऐसे में email_type का दावा मौजूद होना चाहिए. यह मेहमान ऐक्सेस की सुविधा का एक अहम हिस्सा है. इससे केएसीएलएस को बाहरी उपयोगकर्ताओं पर अतिरिक्त सुरक्षा उपाय लागू करने के लिए अहम जानकारी मिलती है.
     • केएसएलएस, इस जानकारी का इस्तेमाल कैसे कर सकता है, इसके कुछ उदाहरण यहां दिए गए हैं:
     • डेटा लॉग करने की अतिरिक्त ज़रूरी शर्तें लागू करने के लिए.
     • सिर्फ़ मेहमान आईडीपी (IdP) को पुष्टि करने वाला टोकन जारी करने की अनुमति देने के लिए.
     • पुष्टि करने वाले टोकन पर अतिरिक्त दावों की ज़रूरत के लिए.
     • अगर ग्राहक ने मेहमान ऐक्सेस को कॉन्फ़िगर नहीं किया है, तो ऐसे सभी अनुरोध अस्वीकार किए जा सकते हैं जिनमें email_type को google-visitor या customer-idp पर सेट किया गया है. google के email_type वाले या सेट नहीं किए गए email_type वाले अनुरोध स्वीकार किए जाते रहेंगे.
   • देखें कि अनुमति देने वाले टोकन में role दावा "रीडर" या "लेखक" है या नहीं.
   • देख लें कि अनुमति देने वाले टोकन में मौजूद kacls_url का दावा, मौजूदा केएसीएलएस यूआरएल से मेल खाता हो. इससे इनसाइडर या नुकसान पहुंचाने वाले डोमेन एडमिन के कॉन्फ़िगर किए गए संभावित मैन-इन-द-मिडल सर्वर का पता लगाने में मदद मिलती है.

2. प्रमाणित एन्क्रिप्शन एल्गोरिदम का इस्तेमाल करके, नीचे दिए गए हिस्सों को डिक्रिप्ट करें:

   • डेटा एन्क्रिप्ट (सुरक्षित) करने की कुंजी (DEK)
   • ऑथराइज़ेशन टोकन में मौजूद resource_name और perimeter_id वैल्यू
   • कोई अन्य संवेदनशील जानकारी

3. देखें कि ऑथराइज़ेशन टोकन में मौजूद resource_name और डिक्रिप्ट किए गए ब्लॉब मेल खाते हैं या नहीं.

4. पुष्टि करने और अनुमति वाले दावे, दोनों का इस्तेमाल करके पेरीमीटर की जांच करें.

5. कार्रवाई को लॉग करें. इसमें, कार्रवाई शुरू करने वाले उपयोगकर्ता, resource_name, और अनुरोध में दी गई वजह की जानकारी भी शामिल होनी चाहिए.

6. रैप नहीं किया गया DEK या स्ट्रक्चर्ड गड़बड़ी का जवाब दें.

ध्यान दें: Google Takeout के अनुरोधों को डिक्रिप्ट करने के लिए, takeout_unwrap देखें.