คู่มือนี้จะอธิบายวิธีการทำงานของการเข้ารหัสและการถอดรหัสโดยใช้ API การเข้ารหัสฝั่งไคลเอ็นต์ของ Google Workspace
คุณต้องอนุญาตบริการผู้ให้บริการข้อมูลประจำตัว (IdP) ที่ผู้ใช้ใช้ การแชร์ไฟล์ที่เข้ารหัส โดยปกติแล้ว คุณจะดูรายละเอียด IdP ที่จำเป็นได้ในส่วน ไฟล์ .well-known ที่พร้อมใช้งานแบบสาธารณะ หรือติดต่อหน่วยงาน รายละเอียด IdP ของผู้ดูแลระบบ Google Workspace
เข้ารหัสข้อมูล
เมื่อผู้ใช้ Google Workspace ส่งคําขอให้บันทึกหรือจัดเก็บที่เข้ารหัสฝั่งไคลเอ็นต์
(CSE) โดย Google Workspace จะส่ง wrap
คำขอไปยัง URL ปลายทางของ KACLS สำหรับการเข้ารหัส นอกเหนือจากตัวเลือก
การตรวจสอบความปลอดภัย เช่น การตรวจสอบขอบเขตและการตรวจสอบตามการอ้างสิทธิ์ JWT KACLS จะต้อง
ให้ทำตามขั้นตอนต่อไปนี้
ตรวจสอบผู้ใช้ที่ส่งคำขอ
- ตรวจสอบทั้งโทเค็นการตรวจสอบสิทธิ์ และโทเค็นการให้สิทธิ์
- ตรวจสอบว่าโทเค็นการให้สิทธิ์และการตรวจสอบสิทธิ์เป็นของผู้ใช้รายเดียวกันโดย จับคู่การอ้างสิทธิ์ทางอีเมลโดยไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
- เมื่อโทเค็นการตรวจสอบสิทธิ์มีการอ้างสิทธิ์
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 การตรวจสอบนี้ช่วยให้ตรวจพบ เซิร์ฟเวอร์แบบแทรกกลางการสื่อสารที่กำหนดค่าโดยคนภายในหรือโดเมนหลอกลวง - ดำเนินการตรวจสอบขอบเขตโดยใช้ทั้งการตรวจสอบสิทธิ์และการให้สิทธิ์ การอ้างสิทธิ์
เข้ารหัสส่วนต่อไปนี้โดยใช้อัลกอริทึมการเข้ารหัสที่ตรวจสอบสิทธิ์แล้ว
- คีย์การเข้ารหัสข้อมูล (DEK)
- ค่า
resource_name
และperimeter_id
จากโทเค็นการให้สิทธิ์ - ข้อมูลที่ละเอียดอ่อนเพิ่มเติม
บันทึกการดำเนินการรวมถึงผู้ใช้ที่ทำให้เกิดการดำเนินการ
resource_name
และ เหตุผลที่ระบุในคำขอแสดงผลออบเจ็กต์ไบนารีแบบทึบแสงที่ Google Workspace จะจัดเก็บไว้กับ ออบเจ็กต์ที่เข้ารหัสและส่งตามที่เป็นในการแยกคีย์ครั้งต่อๆ ไป การดำเนินการ หรือจะแสดงการตอบกลับข้อผิดพลาดที่มีโครงสร้าง
- ออบเจ็กต์ไบนารีควรมีสำเนาเดียวของ DEK ที่เข้ารหัส สามารถจัดเก็บข้อมูลเฉพาะเกี่ยวกับการใช้งานได้
ถอดรหัสข้อมูล
เมื่อผู้ใช้ Google Workspace ขอเปิดข้อมูลที่เข้ารหัสฝั่งไคลเอ็นต์ (CSE)
Google Workspace ส่งคำขอ unwrap
ลงใน URL ปลายทาง KACLS สำหรับการถอดรหัส นอกเหนือจากการรักษาความปลอดภัยที่ไม่บังคับ
เช่น การตรวจสอบขอบเขตและการตรวจสอบตามการอ้างสิทธิ์ JWT KACLS จะต้องดำเนินการ
ขั้นตอนต่อไปนี้
ตรวจสอบผู้ใช้ที่ส่งคำขอ
- ตรวจสอบทั้งโทเค็นการตรวจสอบสิทธิ์ และโทเค็นการให้สิทธิ์
- ตรวจสอบว่าโทเค็นการให้สิทธิ์และการตรวจสอบสิทธิ์เป็นของผู้ใช้รายเดียวกันโดย จับคู่การอ้างสิทธิ์ทางอีเมลโดยไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
- เมื่อโทเค็นการตรวจสอบสิทธิ์มีการอ้างสิทธิ์
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 วิธีนี้ช่วยในการตรวจจับผู้ที่อาจอยู่ตรงกลาง เซิร์ฟเวอร์ที่กำหนดค่าโดยคนภายในหรือผู้ดูแลระบบโดเมนที่หลอกลวง
ถอดรหัสส่วนต่อไปนี้โดยใช้อัลกอริทึมการเข้ารหัสที่ตรวจสอบสิทธิ์แล้ว
- คีย์การเข้ารหัสข้อมูล (DEK)
- ค่า
resource_name
และperimeter_id
จากโทเค็นการให้สิทธิ์ - ข้อมูลที่ละเอียดอ่อนเพิ่มเติม
ตรวจสอบว่า
resource_name
ในโทเค็นการให้สิทธิ์และ BLOB ที่ถอดรหัสแล้ว ที่ตรงกันดำเนินการตรวจสอบขอบเขตโดยใช้ทั้งการตรวจสอบสิทธิ์และการอ้างสิทธิ์การให้สิทธิ์
บันทึกการดำเนินการรวมถึงผู้ใช้ที่ทำให้เกิดการดำเนินการ
resource_name
และ เหตุผลที่ระบุในคำขอแสดง DEK ที่ไม่มีการรวมหรือการตอบกลับข้อผิดพลาดที่มีโครงสร้าง