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

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

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

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

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

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

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

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

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

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

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

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

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