رمزگذاری & رمزگشایی داده ها

این راهنما نحوه‌ی رمزگذاری و رمزگشایی را با استفاده از API رمزگذاری سمت کلاینت Google Workspace شرح می‌دهد.

شما باید هرگونه سرویس ارائه‌دهنده هویت (IdP) که توسط کاربرانی که فایل‌های رمزگذاری‌شده را به اشتراک می‌گذارند استفاده می‌شود را در فهرست مجاز قرار دهید. معمولاً می‌توانید جزئیات IdP مورد نیاز را در فایل .well-known که در دسترس عموم است، پیدا کنید؛ در غیر این صورت، برای دریافت جزئیات IdP با مدیر Google Workspace سازمان تماس بگیرید.

رمزگذاری داده‌ها

وقتی یک کاربر Google Workspace درخواست ذخیره یا نگهداری داده‌های رمزگذاری‌شده‌ی سمت کلاینت (CSE) را می‌دهد، Google Workspace یک درخواست wrap request) برای رمزگذاری به آدرس اینترنتی (URL) نقطه‌ی پایانی سرویس کنترل دسترسی کلیدی (KACLS) شما ارسال می‌کند. علاوه بر بررسی‌های امنیتی اختیاری، مانند بررسی‌های مبتنی بر محیط و ادعای JWT، KACLS شما باید مراحل زیر را انجام دهد:

1. کاربر درخواست‌کننده را اعتبارسنجی کنید.

   • هم توکن احراز هویت و هم توکن مجوز را اعتبارسنجی کنید.
   • با انجام تطبیق بدون حساسیت به حروف بزرگ و کوچک در ادعاهای ایمیل، بررسی کنید که توکن‌های مجوز و احراز هویت برای یک کاربر باشند.
   • وقتی توکن احراز هویت شامل ادعای اختیاری google_email باشد، باید با ادعای ایمیل در توکن مجوز با استفاده از رویکردی غیرحساس به حروف بزرگ و کوچک مقایسه شود. برای این مقایسه از ادعای ایمیل درون توکن احراز هویت استفاده نکنید.
   • در سناریوهایی که توکن احراز هویت فاقد ادعای اختیاری google_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 در توکن مجوز با URL فعلی KACLS مطابقت داشته باشد. این بررسی امکان شناسایی سرورهای بالقوه‌ی man-in-the-middle که توسط افراد داخلی یا مدیران دامنه‌ی جعلی پیکربندی شده‌اند را فراهم می‌کند.
   • با استفاده از ادعاهای احراز هویت و مجوز، یک بررسی محیطی انجام دهید.

2. بخش‌های زیر را با استفاده از یک الگوریتم رمزگذاری احراز هویت شده رمزگذاری کنید:

   • کلید رمزگذاری داده‌ها (DEK)
   • مقادیر resource_name و perimeter_id از توکن مجوز
   • هرگونه اطلاعات حساس اضافی

3. عملیات را ثبت کنید، از جمله نام کاربری که آن را آغاز کرده، resource_name و دلیل ارسال شده در درخواست.

4. یک شیء دودویی غیرشفاف را برگردانید تا توسط Google Workspace در کنار شیء رمزگذاری شده ذخیره شود و در هر عملیات رمزگشایی کلید بعدی به همان صورت ارسال شود. یا، یک پاسخ خطای ساختاریافته ارائه دهید.

   • شیء دودویی باید تنها کپی از DEK رمزگذاری شده را داشته باشد، داده‌های خاص پیاده‌سازی می‌توانند در آن ذخیره شوند.

رمزگشایی داده‌ها

وقتی یک کاربر Google Workspace درخواست باز کردن داده‌های رمزگذاری‌شده‌ی سمت کلاینت (CSE) را می‌دهد، Google Workspace یک درخواست unwrap به URL نقطه‌ی پایانی KACLS شما برای رمزگشایی ارسال می‌کند. علاوه بر بررسی‌های امنیتی اختیاری، مانند بررسی‌های مبتنی بر محیط و ادعای JWT، KACLS شما باید مراحل زیر را انجام دهد:

1. کاربر درخواست‌کننده را اعتبارسنجی کنید.

   • هم توکن احراز هویت و هم توکن مجوز را اعتبارسنجی کنید.
   • با انجام تطبیق بدون حساسیت به حروف بزرگ و کوچک در ادعاهای ایمیل، بررسی کنید که توکن‌های مجوز و احراز هویت برای یک کاربر باشند.
   • وقتی توکن احراز هویت شامل ادعای اختیاری google_email باشد، باید با ادعای ایمیل در توکن مجوز با استفاده از رویکردی غیرحساس به حروف بزرگ و کوچک مقایسه شود. برای این مقایسه از ادعای ایمیل درون توکن احراز هویت استفاده نکنید.
   • در سناریوهایی که توکن احراز هویت فاقد ادعای اختیاری google_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 در توکن مجوز با URL فعلی KACLS مطابقت داشته باشد. این کار امکان شناسایی سرورهای بالقوه‌ی man-in-the-middle که توسط افراد داخلی یا مدیران دامنه‌ی جعلی پیکربندی شده‌اند را فراهم می‌کند.

2. بخش‌های زیر را با استفاده از یک الگوریتم رمزگذاری احراز هویت شده رمزگشایی کنید:

   • کلید رمزگذاری داده‌ها (DEK)
   • مقادیر resource_name و perimeter_id از توکن مجوز
   • هرگونه اطلاعات حساس اضافی

3. بررسی کنید که resource_name در توکن مجوز و blob رمزگشایی شده مطابقت داشته باشند.

4. با استفاده از ادعاهای احراز هویت و مجوز، یک بررسی محیطی انجام دهید.

5. عملیات را ثبت کنید، از جمله نام کاربری که آن را آغاز کرده، resource_name و دلیل ارسال شده در درخواست.

6. DEK بدون پوشش یا یک پاسخ خطای ساختاریافته را برگردانید.