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

คู่มือนี้อธิบายวิธีการเข้ารหัสและถอดรหัสโดยใช้ 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การอ้างสิทธิ์ ซึ่งเป็นส่วนสำคัญของฟีเจอร์การเข้าถึงของผู้มาเยือน โดยให้ข้อมูลที่มีประโยชน์แก่ KACL เพื่อบังคับใช้มาตรการรักษาความปลอดภัยเพิ่มเติมกับผู้ใช้ภายนอก
      • ตัวอย่างวิธีที่ 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 ปัจจุบัน การตรวจสอบนี้ช่วยให้ตรวจพบเซิร์ฟเวอร์ที่อาจเป็น การดักฟังข้อมูลที่กำหนดค่าโดยผู้ไม่หวังดีหรือผู้ดูแลระบบโดเมนที่ไม่ประสงค์ดี
    • ทำการตรวจสอบขอบเขตโดยใช้ทั้งการตรวจสอบสิทธิ์และการให้สิทธิ์ การอ้างสิทธิ์

  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 ควรได้รับการยอมรับต่อไป
    • เมื่อโทเค็นการตรวจสอบสิทธิ์มีอ้างสิทธิ์ 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 ที่ไม่ได้ห่อหรือการตอบกลับข้อผิดพลาดที่มีโครงสร้าง