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

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

คุณต้องเพิ่มบริการผู้ให้บริการข้อมูลประจำตัว (IdP) ที่ใช้โดยผู้ใช้ที่แชร์ไฟล์ที่เข้ารหัสไว้ในรายการที่อนุญาต โดยปกติแล้ว คุณจะพบรายละเอียด IdP ที่จำเป็นในไฟล์ .well-known ที่เผยแพร่แบบสาธารณะ หรือติดต่อผู้ดูแลระบบ Google Workspace ขององค์กรเพื่อขอรายละเอียด IdP

เข้ารหัสข้อมูล

เมื่อผู้ใช้ Google Workspace ส่งคำขอบันทึกหรือจัดเก็บข้อมูลที่เข้ารหัสฝั่งไคลเอ็นต์ (CSE) แล้ว Google Workspace จะส่งคําขอ wrap ไปยัง URL ปลายทาง KACLS เพื่อเข้ารหัส นอกเหนือจากการตรวจสอบความปลอดภัยที่ไม่บังคับ เช่น การตรวจสอบตามขอบเขตและการตรวจสอบตามการอ้างสิทธิ์ JWT แล้ว KACLS ของคุณยังต้องทําตามขั้นตอนต่อไปนี้ด้วย

1. ตรวจสอบผู้ใช้ที่ส่งคำขอ

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

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

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

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

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

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

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