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

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

  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 ที่ไม่ได้ห่อหรือการตอบกลับข้อผิดพลาดที่มีโครงสร้าง