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

इस गाइड में बताया गया है कि Google Workspace Client-side Encryption API का इस्तेमाल करके, एन्क्रिप्शन और डिक्रिप्शन कैसे काम करता है.

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

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

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

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

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

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

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

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

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

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

डेटा को डिक्रिप्ट करना

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

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

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

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

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

3. पुष्टि करें कि अनुमति देने वाले टोकन और डिक्रिप्ट किए गए blob में मौजूद resource_name मेल खाते हों.

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

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

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