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

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

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

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

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

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

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

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