เข้ารหัสและถอดรหัสข้อมูล

คู่มือนี้จะอธิบายวิธีการทำงานของการเข้ารหัสและการถอดรหัสโดยใช้ API การเข้ารหัสฝั่งไคลเอ็นต์ของ Google Workspace

คุณต้องอนุญาตบริการผู้ให้บริการข้อมูลประจำตัว (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 สามารถใช้ข้อมูลนี้มีดังนี้
     • เพื่อกำหนดข้อกำหนดการบันทึกเพิ่มเติม
     • หากต้องการจำกัดผู้ออกโทเค็นการตรวจสอบสิทธิ์ให้กับ IdP ของผู้เข้าร่วมโดยเฉพาะ
     • ต้องมีการอ้างสิทธิ์เพิ่มเติมในโทเค็นการตรวจสอบสิทธิ์
     • หากลูกค้ายังไม่ได้กำหนดค่าการเข้าถึงของผู้เข้าร่วม คำขอทั้งหมด โดยตั้งค่า email_type เป็น google-visitor หรือ customer-idp ได้ ถูกปฏิเสธ คำขอที่มี email_type เป็น google หรือไม่ได้ตั้งค่า email_type ควรได้รับการยอมรับต่อไป
   • ตรวจสอบว่าการอ้างสิทธิ์ role ในโทเค็นการให้สิทธิ์คือ "ผู้เขียน" หรือ "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 สามารถใช้ข้อมูลนี้มีดังนี้
     • เพื่อกำหนดข้อกำหนดการบันทึกเพิ่มเติม
     • หากต้องการจำกัดผู้ออกโทเค็นการตรวจสอบสิทธิ์ให้กับ IdP ของผู้เข้าร่วมโดยเฉพาะ
     • ต้องมีการอ้างสิทธิ์เพิ่มเติมในโทเค็นการตรวจสอบสิทธิ์
     • หากลูกค้ายังไม่ได้กำหนดค่าการเข้าถึงของผู้เข้าร่วม คำขอทั้งหมด โดยตั้งค่า email_type เป็น google-visitor หรือ customer-idp ได้ ถูกปฏิเสธ คำขอที่มี email_type เป็น google หรือไม่ได้ตั้งค่า email_type ควรได้รับการยอมรับต่อไป
   • ตรวจสอบว่าการอ้างสิทธิ์ role ในโทเค็นการให้สิทธิ์คือ "ผู้อ่าน" หรือ "writer"
   • ตรวจสอบว่าการอ้างสิทธิ์ kacls_url ในโทเค็นการให้สิทธิ์ตรงกับ URL ปัจจุบันของ KACLS วิธีนี้ช่วยในการตรวจจับผู้ที่อาจอยู่ตรงกลาง เซิร์ฟเวอร์ที่กำหนดค่าโดยคนภายในหรือผู้ดูแลระบบโดเมนที่หลอกลวง

2. ถอดรหัสส่วนต่อไปนี้โดยใช้อัลกอริทึมการเข้ารหัสที่ตรวจสอบสิทธิ์แล้ว

   • คีย์การเข้ารหัสข้อมูล (DEK)
   • ค่า resource_name และ perimeter_id จากโทเค็นการให้สิทธิ์
   • ข้อมูลที่ละเอียดอ่อนเพิ่มเติม

3. ตรวจสอบว่า resource_name ในโทเค็นการให้สิทธิ์และ BLOB ที่ถอดรหัสแล้ว ที่ตรงกัน

4. ดำเนินการตรวจสอบขอบเขตโดยใช้ทั้งการตรวจสอบสิทธิ์และการอ้างสิทธิ์การให้สิทธิ์

5. บันทึกการดำเนินการรวมถึงผู้ใช้ที่ทำให้เกิดการดำเนินการ resource_name และ เหตุผลที่ระบุในคำขอ

6. แสดง DEK ที่ไม่มีการรวมหรือการตอบกลับข้อผิดพลาดที่มีโครงสร้าง