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

คู่มือนี้อธิบายวิธีการเข้ารหัสและถอดรหัสโดยใช้ Google Workspace Client-side Encryption API

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

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 ต่อไป
   • เมื่อโทเค็นการตรวจสอบสิทธิ์มีการอ้างสิทธิ์ delegated_to ที่ไม่บังคับ โทเค็นดังกล่าวต้องมีการอ้างสิทธิ์ resource_name ด้วย และคุณต้องเปรียบเทียบการอ้างสิทธิ์ทั้ง 2 รายการนี้กับการอ้างสิทธิ์ 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 ในโทเค็นการให้สิทธิ์และ Blob ที่ถอดรหัสแล้วตรงกัน

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

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

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