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

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

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

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

যখন কোনও Google Workspace ব্যবহারকারী ক্লায়েন্ট-সাইড এনক্রিপ্টেড (CSE) ডেটা সংরক্ষণ বা সংরক্ষণ করার অনুরোধ করেন, তখন Google Workspace আপনার কী অ্যাক্সেস কন্ট্রোল লিস্ট সার্ভিস (KACLS) এন্ডপয়েন্ট URL-এ এনক্রিপশনের জন্য একটি wrap অনুরোধ পাঠায়। ঐচ্ছিক নিরাপত্তা পরীক্ষা, যেমন পেরিমিটার এবং JWT দাবি-ভিত্তিক চেক ছাড়াও, আপনার KACLS-কে নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করতে হবে:

1. অনুরোধকারী ব্যবহারকারীকে যাচাই করুন।

   • প্রমাণীকরণ টোকেন এবং অনুমোদন টোকেন উভয়ই যাচাই করুন।
   • ইমেল দাবিগুলিতে কেস-অসংবেদনশীল মিল করে যাচাই করুন যে অনুমোদন এবং প্রমাণীকরণ টোকেন একই ব্যবহারকারীর জন্য।
   • যখন প্রমাণীকরণ টোকেনে ঐচ্ছিক google_email দাবি থাকে, তখন কেস-অসংবেদনশীল পদ্ধতি ব্যবহার করে অনুমোদন টোকেনের ইমেল দাবির সাথে তুলনা করতে হবে। এই তুলনার জন্য প্রমাণীকরণ টোকেনের মধ্যে ইমেল দাবি ব্যবহার করবেন না।
   • যেসব পরিস্থিতিতে প্রমাণীকরণ টোকেনে ঐচ্ছিক google_email দাবি নেই, সেখানে প্রমাণীকরণ টোকেনের মধ্যে থাকা ইমেল দাবিটি কেস-ইনসেনসিটিভ পদ্ধতি ব্যবহার করে অনুমোদন টোকেনের ইমেল দাবির সাথে তুলনা করা উচিত।
   • যেসব পরিস্থিতিতে Google কোনও Google অ্যাকাউন্টের সাথে সম্পর্কিত নয় এমন কোনও ইমেলের জন্য অনুমোদন টোকেন জারি করে, সেখানে email_type দাবিটি অবশ্যই উপস্থিত থাকতে হবে। এটি অতিথি অ্যাক্সেস বৈশিষ্ট্যের একটি গুরুত্বপূর্ণ অংশ, যা KACLS-এর জন্য মূল্যবান তথ্য প্রদান করে যাতে বহিরাগত ব্যবহারকারীদের উপর অতিরিক্ত সুরক্ষা ব্যবস্থা প্রয়োগ করা যায়।
     • KACLS কীভাবে এই তথ্য ব্যবহার করতে পারে তার কিছু উদাহরণ হল:
     • অতিরিক্ত লগিং প্রয়োজনীয়তা আরোপ করা।
     • প্রমাণীকরণ টোকেন ইস্যুকারীকে একটি ডেডিকেটেড গেস্ট আইডিপিতে সীমাবদ্ধ রাখতে।
     • প্রমাণীকরণ টোকেনের উপর অতিরিক্ত দাবির প্রয়োজন।
     • যদি কোনও গ্রাহক গেস্ট অ্যাক্সেস কনফিগার না করে থাকেন, তাহলে email_type google-visitor অথবা customer-idp তে সেট করা থাকলে সমস্ত অনুরোধ প্রত্যাখ্যান করা যেতে পারে। google এর email_type অথবা unset 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 এন্ডপয়েন্ট URL-এ একটি unwrap অনুরোধ পাঠায়। ঐচ্ছিক নিরাপত্তা পরীক্ষা, যেমন পেরিমিটার এবং JWT দাবি-ভিত্তিক চেক ছাড়াও, আপনার KACLS-কে নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করতে হবে:

1. অনুরোধকারী ব্যবহারকারীকে যাচাই করুন।

   • প্রমাণীকরণ টোকেন এবং অনুমোদন টোকেন উভয়ই যাচাই করুন।
   • ইমেল দাবিগুলিতে কেস-অসংবেদনশীল মিল করে যাচাই করুন যে অনুমোদন এবং প্রমাণীকরণ টোকেন একই ব্যবহারকারীর জন্য।
   • যখন প্রমাণীকরণ টোকেনে ঐচ্ছিক google_email দাবি থাকে, তখন কেস-অসংবেদনশীল পদ্ধতি ব্যবহার করে অনুমোদন টোকেনের ইমেল দাবির সাথে তুলনা করতে হবে। এই তুলনার জন্য প্রমাণীকরণ টোকেনের মধ্যে ইমেল দাবি ব্যবহার করবেন না।
   • যেসব পরিস্থিতিতে প্রমাণীকরণ টোকেনে ঐচ্ছিক google_email দাবি নেই, সেখানে প্রমাণীকরণ টোকেনের মধ্যে থাকা ইমেল দাবিটি কেস-ইনসেনসিটিভ পদ্ধতি ব্যবহার করে অনুমোদন টোকেনের ইমেল দাবির সাথে তুলনা করা উচিত।
   • যেসব পরিস্থিতিতে Google কোনও Google অ্যাকাউন্টের সাথে সম্পর্কিত নয় এমন কোনও ইমেলের জন্য অনুমোদন টোকেন জারি করে, সেখানে email_type দাবিটি অবশ্যই উপস্থিত থাকতে হবে। এটি অতিথি অ্যাক্সেস বৈশিষ্ট্যের একটি গুরুত্বপূর্ণ অংশ, যা KACLS-এর জন্য মূল্যবান তথ্য প্রদান করে যাতে বহিরাগত ব্যবহারকারীদের উপর অতিরিক্ত সুরক্ষা ব্যবস্থা প্রয়োগ করা যায়।
     • KACLS কীভাবে এই তথ্য ব্যবহার করতে পারে তার কিছু উদাহরণ হল:
     • অতিরিক্ত লগিং প্রয়োজনীয়তা আরোপ করা।
     • প্রমাণীকরণ টোকেন ইস্যুকারীকে একটি ডেডিকেটেড গেস্ট আইডিপিতে সীমাবদ্ধ রাখতে।
     • প্রমাণীকরণ টোকেনের উপর অতিরিক্ত দাবির প্রয়োজন।
     • যদি কোনও গ্রাহক গেস্ট অ্যাক্সেস কনফিগার না করে থাকেন, তাহলে email_type google-visitor অথবা customer-idp তে সেট করা থাকলে সমস্ত অনুরোধ প্রত্যাখ্যান করা যেতে পারে। google এর email_type অথবা unset 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 অথবা একটি কাঠামোগত ত্রুটির উত্তর ফেরত দিন।