এনক্রিপ্ট & ডেটা ডিক্রিপ্ট করুন

Google Workspace ক্লায়েন্ট-সাইড এনক্রিপশন API ব্যবহার করে এনক্রিপশন এবং ডিক্রিপশন কীভাবে কাজ করে তা এই গাইডটি বর্ণনা করে।

এনক্রিপ্ট করা ফাইল শেয়ার করা ব্যবহারকারীদের দ্বারা ব্যবহৃত যেকোনও আইডেন্টিটি প্রোভাইডার (আইডিপি) পরিষেবাগুলিকে আপনাকে অবশ্যই অনুমতি দিতে হবে। আপনি সাধারণত তাদের সর্বজনীনভাবে উপলব্ধ .well-known ফাইলে প্রয়োজনীয় IdP বিবরণ খুঁজে পেতে পারেন; অন্যথায়, তাদের IdP বিবরণের জন্য প্রতিষ্ঠানের Google Workspace অ্যাডমিনিস্ট্রেটরের সাথে যোগাযোগ করুন।

ডেটা এনক্রিপ্ট করুন

যখন কোনও Google Workspace ব্যবহারকারী ক্লায়েন্ট-সাইড এনক্রিপ্ট করা (CSE) ডেটা সেভ বা স্টোর করার অনুরোধ করেন, তখন Google Workspace এনক্রিপশনের জন্য আপনার কী অ্যাক্সেস কন্ট্রোল লিস্ট সার্ভিস (KACLS) এন্ডপয়েন্ট ইউআরএলে একটি 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 URL-এর সাথে মেলে কিনা পরীক্ষা করুন। এই চেকটি অভ্যন্তরীণ বা দুর্বৃত্ত ডোমেন প্রশাসকদের দ্বারা কনফিগার করা সম্ভাব্য ম্যান-ইন-দ্য-মিডল সার্ভারগুলি সনাক্ত করার অনুমতি দেয়।
   • প্রমাণীকরণ এবং অনুমোদন দাবি উভয় ব্যবহার করে একটি পরিধি চেক করুন।

2. একটি প্রমাণীকৃত এনক্রিপশন অ্যালগরিদম ব্যবহার করে নিম্নলিখিত অংশগুলি এনক্রিপ্ট করুন:

   • ডেটা এনক্রিপশন কী (DEK)
   • অনুমোদন টোকেন থেকে resource_name এবং perimeter_id মান
   • কোনো অতিরিক্ত সংবেদনশীল তথ্য

3. ব্যবহারকারীর উদ্ভব, resource_name এবং অনুরোধে পাস করা কারণ সহ অপারেশনটি লগ করুন।

4. এনক্রিপ্ট করা অবজেক্টের পাশাপাশি Google Workspace-এর দ্বারা স্টোর করার জন্য একটি অস্বচ্ছ বাইনারি অবজেক্ট ফেরত দিন এবং পরবর্তী যেকোন কী আনর্যাপিং অপারেশনে যেভাবে আছে সেভাবে পাঠানো হবে। অথবা, একটি কাঠামোগত ত্রুটি উত্তর পরিবেশন করুন।

   • বাইনারি অবজেক্টে এনক্রিপ্ট করা DEK এর একমাত্র অনুলিপি থাকা উচিত, বাস্তবায়নের নির্দিষ্ট ডেটা এতে সংরক্ষণ করা যেতে পারে।

ডেটা ডিক্রিপ্ট করুন

যখন কোনও Google Workspace ব্যবহারকারী ক্লায়েন্ট-সাইড এনক্রিপ্ট করা (CSE) ডেটা খোলার অনুরোধ করেন, তখন Google Workspace আপনার KACLS এন্ডপয়েন্ট ইউআরএলে ডিক্রিপশনের জন্য একটি unwrap অনুরোধ পাঠায়। ঐচ্ছিক নিরাপত্তা চেক ছাড়াও, যেমন পরিধি এবং 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 দাবি reader বা writer ।
   • অনুমোদন টোকেনে kacls_url দাবি বর্তমান KACLS URL এর সাথে মেলে কিনা তা পরীক্ষা করুন। এটি অভ্যন্তরীণ বা দুর্বৃত্ত ডোমেন প্রশাসকদের দ্বারা কনফিগার করা সম্ভাব্য ম্যান-ইন-দ্য-মিডল সার্ভার সনাক্ত করার অনুমতি দেয়।

2. একটি প্রমাণীকৃত এনক্রিপশন অ্যালগরিদম ব্যবহার করে নিম্নলিখিত অংশগুলি ডিক্রিপ্ট করুন:

   • ডেটা এনক্রিপশন কী (DEK)
   • অনুমোদন টোকেন থেকে resource_name এবং perimeter_id মান
   • কোনো অতিরিক্ত সংবেদনশীল তথ্য

3. অনুমোদন টোকেন এবং ডিক্রিপ্ট করা ব্লব-এ resource_name মিলছে কিনা পরীক্ষা করুন।

4. প্রমাণীকরণ এবং অনুমোদন দাবি উভয় ব্যবহার করে একটি পরিধি চেক করুন।

5. ব্যবহারকারীর উদ্ভব, resource_name এবং অনুরোধে পাস করা কারণ সহ অপারেশনটি লগ করুন।

6. মোড়ানো DEK বা একটি কাঠামোগত ত্রুটির উত্তর ফেরত দিন।