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

এই নির্দেশিকায় গুগল ওয়ার্কস্পেস ক্লায়েন্ট-সাইড এনক্রিপশন এপিআই ব্যবহার করে এনক্রিপশন এবং ডিক্রিপশন কীভাবে কাজ করে তা বর্ণনা করা হয়েছে।

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

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

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

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

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

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

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

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

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

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