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

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

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

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

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

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

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