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

این راهنما نحوه کارکرد رمزگذاری و رمزگشایی با استفاده از Google Workspace Client-side Encryption API را شرح می دهد.

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

داده ها را رمزگذاری کنید

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

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

   • هم نشانه احراز هویت و هم نشانه مجوز را تأیید کنید.
   • با انجام تطبیق بدون حروف بزرگ و کوچک در ادعاهای ایمیل، بررسی کنید که نشانه‌های مجوز و احراز هویت برای یک کاربر باشد.
   • هنگامی که رمز احراز هویت حاوی ادعای اختیاری google_email است، باید با استفاده از رویکردی که به حروف بزرگ و کوچک حساس نیست، با ادعای ایمیل در کد مجوز مقایسه شود. برای این مقایسه از ادعای ایمیل در نشانه احراز هویت استفاده نکنید.
   • در سناریوهایی که نشانه احراز هویت فاقد ادعای اختیاری google_email است، ادعای ایمیل در کد احراز هویت باید با ادعای ایمیل در کد مجوز، با استفاده از روشی که به حروف کوچک و بزرگ حساس نیست، مقایسه شود.
   • در سناریوهایی که Google برای ایمیلی که با حساب Google مرتبط نیست، کد مجوز صادر می‌کند، ادعای email_type باید وجود داشته باشد. این بخش مهمی از ویژگی دسترسی مهمان را تشکیل می دهد و اطلاعات ارزشمندی را برای KACLS فراهم می کند تا اقدامات امنیتی بیشتری را بر روی کاربران خارجی اعمال کند.
     • چند نمونه از نحوه استفاده KACLS از این اطلاعات عبارتند از:
     • برای تحمیل الزامات اضافی برای ورود به سیستم.
     • برای محدود کردن صادرکننده رمز احراز هویت به یک Guest IdP اختصاصی.
     • برای درخواست ادعاهای اضافی در مورد رمز احراز هویت.
     • اگر مشتری دسترسی مهمان را پیکربندی نکرده باشد، همه درخواست‌هایی که 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 مطابقت داشته باشد. این بررسی اجازه می دهد تا سرورهای بالقوه مرد میانی را که توسط خودی ها یا مدیران سرکش دامنه پیکربندی شده اند، شناسایی کند.
   • با استفاده از هر دو ادعای احراز هویت و مجوز، یک بررسی محیطی انجام دهید.

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 است، ادعای ایمیل در کد احراز هویت باید با ادعای ایمیل در کد مجوز، با استفاده از روشی که به حروف کوچک و بزرگ حساس نیست، مقایسه شود.
   • در سناریوهایی که Google برای ایمیلی که با حساب Google مرتبط نیست، کد مجوز صادر می‌کند، ادعای email_type باید وجود داشته باشد. این بخش مهمی از ویژگی دسترسی مهمان را تشکیل می دهد و اطلاعات ارزشمندی را برای KACLS فراهم می کند تا اقدامات امنیتی بیشتری را بر روی کاربران خارجی اعمال کند.
     • چند نمونه از نحوه استفاده KACLS از این اطلاعات عبارتند از:
     • برای تحمیل الزامات اضافی برای ورود به سیستم.
     • برای محدود کردن صادرکننده رمز احراز هویت به یک Guest IdP اختصاصی.
     • برای درخواست ادعاهای اضافی در مورد رمز احراز هویت.
     • اگر مشتری دسترسی مهمان را پیکربندی نکرده باشد، همه درخواست‌هایی که 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 در نشانه مجوز و لکه رمزگشایی شده مطابقت داشته باشد.

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

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

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