تشفير البيانات وفك تشفيرها

يوضّح هذا الدليل آلية عمل التشفير وفك التشفير باستخدام واجهة برمجة التطبيقات لميزة "التشفير من جهة العميل" في Google Workspace.

يجب إضافة أي خدمات موفِّر هوية (IdP) يستخدمها المستخدمون عند مشاركة الملفات المشفَّرة إلى القائمة المسموح بها. يمكنك عادةً العثور على تفاصيل موفِّر الهوية المطلوبة في ملف ‎ .well-known المتاح للجميع، وإلا يمكنك التواصل مع مشرف Google Workspace في المؤسسة للحصول على تفاصيل موفِّر الهوية.

تشفير البيانات

عندما يطلب مستخدم Google Workspace حفظ بيانات مشفَّرة من جهة العميل (CSE) أو تخزينها، تُرسِل Google Workspace طلبًا wrap إلى عنوان URL لنقطة نهاية KACLS من أجل التشفير. بالإضافة إلى عمليات فحص الأمان الاختيارية، مثل عمليات التحقّق من المحيط والعمليات المستندة إلى مطالبات JWT، يجب أن تُجري وحدات تحكّم الوصول إلى الخدمات (KACLS) الخطوات التالية:

1. التحقّق من هوية المستخدم الذي يطلب إجراء ذلك

   • تحقَّق من صحة كلّ من الرمز المميّز للمصادقة والرمز المميّز للتفويض.
   • تأكَّد من أنّ رمزَي التفويض والمصادقة هما للمستخدم نفسه من خلال إجراء مطابقة لا تراعي حالة الأحرف في مطالبات البريد الإلكتروني.
   • عندما يحتوي رمز المصادقة على المطالبة الاختيارية google_email، يجب مقارنته بمطلب البريد الإلكتروني في رمز الموافقة باستخدام نهج لا يراعي حالة الأحرف. لا تستخدِم مطالبة البريد الإلكتروني ضمن رمز مصادقة مقارنة البيانات هذه.
   • في الحالات التي لا يتضمّن فيها الرمز المميّز للمصادقة المطالبة الاختيارية google_email، يجب مقارنة المطالبة بالبريد الإلكتروني ضمن الرمز المميّز للمصادقة بالمطالبات بالبريد الإلكتروني في الرمز المميّز للتفويض، باستخدام طريقة لا تراعي حالة الأحرف.
   • في السيناريوهات التي تُصدر فيها Google رمز مميّزًا للتفويض لعنوان بريد إلكتروني غير مرتبط بحساب على Google، يجب توفُّر المطالبة بموجب email_type. ويشكّل ذلك جزءًا مهمًا من ميزة "إمكانية وصول الضيف"، حيث يوفّر معلومات قيمة لقوائم التحكّم بالوصول إلى مفاتيح التشفير (KACLS) لفرض تدابير أمان إضافية على مستخدمي الحسابات الخارجية.
     • في ما يلي بعض الأمثلة على كيفية استخدام سياسة KACLS لهذه المعلومات:
     • لفرض متطلبات تسجيل إضافية
     • لتقييد جهة إصدار رمز المصادقة بموفِّر هوية مخصّص لجلسات الضيوف
     • لطلب بيانات إضافية في رمز المصادقة
     • إذا لم يضبط العميل إعدادات "إمكانية وصول الضيف"، يمكنه رفض جميع الطلبات التي تم ضبطemail_type فيها على google-visitor أو customer-idp. من المفترض أن يستمر قبول الطلبات التي تحتوي على قيمة email_type‏= google أو التي لم يتم ضبط قيمة email_type لها.
   • تأكَّد من أنّ المطالبة role في الرمز المميّز للتفويض هي "كاتب" أو "مُحدِّث".
   • تأكَّد من أنّ مطالبة 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، يجب أن تُجري واجهة برمجة تطبيقات Kerberos الخطوات التالية:

1. التحقّق من هوية المستخدم الذي يطلب إجراء ذلك

   • تحقَّق من صحة كلّ من الرمز المميّز للمصادقة والرمز المميّز للتفويض.
   • تأكَّد من أنّ رمزَي التفويض والمصادقة هما للمستخدم نفسه من خلال إجراء مطابقة لا تراعي حالة الأحرف في مطالبات البريد الإلكتروني.
   • عندما يحتوي رمز المصادقة على المطالبة الاختيارية google_email، يجب مقارنته بمطلب البريد الإلكتروني في رمز الموافقة باستخدام نهج لا يراعي حالة الأحرف. لا تستخدِم مطالبة البريد الإلكتروني ضمن رمز مصادقة مقارنة البيانات هذه.
   • في الحالات التي لا يتضمّن فيها الرمز المميّز للمصادقة المطالبة الاختيارية google_email، يجب مقارنة المطالبة بالبريد الإلكتروني ضمن الرمز المميّز للمصادقة بالمطالبات بالبريد الإلكتروني في الرمز المميّز للتفويض، باستخدام طريقة لا تراعي حالة الأحرف.
   • في السيناريوهات التي تُصدر فيها Google رمز مميّزًا للتفويض لعنوان بريد إلكتروني غير مرتبط بحساب على Google، يجب توفُّر المطالبة بموجب email_type. ويشكّل ذلك جزءًا مهمًا من ميزة "إمكانية وصول الضيف"، حيث يوفّر معلومات قيمة لقوائم التحكّم بالوصول إلى مفاتيح التشفير (KACLS) لفرض تدابير أمان إضافية على مستخدمي الحسابات الخارجية.
     • في ما يلي بعض الأمثلة على كيفية استخدام سياسة KACLS لهذه المعلومات:
     • لفرض متطلبات تسجيل إضافية
     • لتقييد جهة إصدار رمز المصادقة بموفِّر هوية مخصّص لجلسات الضيوف
     • لطلب بيانات إضافية في رمز المصادقة
     • إذا لم يضبط العميل إعدادات "إمكانية وصول النزلاء"، يمكنه رفض جميع الطلبات التي تم ضبطemail_type فيها على google-visitor أو customer-idp. من المفترض أن يستمر قبول الطلبات التي يكون فيها email_type‏= google أو email_type غير محدّد.
   • تأكَّد من أنّ المطالبة role في رمز التفويض هي "قارئ" أو "كاتب".
   • تأكَّد من أنّ مطالبة kacls_url في رمز التفويض تتطابق مع عنوان URL الحالي لـ KACLS. يتيح ذلك رصد هجمات "الرجل في المنتصف" المحتملة التي يتم ضبطها من قِبل موظّفين داخليين أو مشرفي نطاق غير مرغوب فيهم.

2. فك تشفير الأجزاء التالية باستخدام خوارزمية تشفير مصادق عليه:

   • مفتاح تشفير البيانات (DEK)
   • قيمتَا resource_name وperimeter_id من رمز التفويض
   • أي بيانات حسّاسة إضافية

3. تأكَّد من تطابق resource_name في رمز التفويض والملف المشفَّر.

4. يمكنك إجراء فحص للحدود باستخدام كلّ من مَطالبات المصادقة والترخيص.

5. سجِّل العملية، بما في ذلك المستخدم الذي بدأها وresource_name و الأسباب التي تم تمريرها في الطلب.

6. يجب عرض مفتاح الجلسة غير المُشفَّر أو ردّ خطأ منظَّم.