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

इस गाइड में बताया गया है कि 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 पर सेट करने वाले सभी अनुरोध अस्वीकार किए जा सकते हैं. google की email_type वैल्यू वाले अनुरोध या 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 पर सेट करने वाले सभी अनुरोध अस्वीकार किए जा सकते हैं. google की email_type वैल्यू वाले अनुरोध या 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 या स्ट्रक्चर्ड गड़बड़ी का जवाब वापस भेजें.