การควบคุมการเข้าถึงใน Google Cloud Search จะอิงตามบัญชี Google ของผู้ใช้ เมื่อจัดทำดัชนีเนื้อหา ACL ทั้งหมดในรายการจะต้องเปลี่ยนเป็นผู้ใช้ Google ที่ถูกต้องหรือ รหัสกลุ่ม (อีเมล)
ในหลายกรณี ที่เก็บไม่ได้มีความรู้เรื่อง Google โดยตรง บัญชี แต่ผู้ใช้อาจแสดงโดยบัญชีในเครื่องหรือ การลงชื่อเข้าใช้แบบรวมศูนย์ด้วยผู้ให้บริการข้อมูลประจำตัวและรหัสอื่นๆ มากกว่าอีเมลของผู้ใช้เพื่อระบุแต่ละบัญชี รหัสนี้เรียกว่า รหัสภายนอก
แหล่งที่มาของข้อมูลประจำตัวที่สร้างขึ้นโดยใช้คอนโซลผู้ดูแลระบบจะช่วยเชื่อมโยงช่องว่างนี้ระหว่าง โดยใช้ระบบการระบุตัวตนตาม
- การกำหนดช่องผู้ใช้ที่กำหนดเอง เพื่อจัดเก็บรหัสภายนอก ช่องนี้ใช้เพื่อแก้ไขรหัสภายนอกไปยัง Google ของคุณได้
- กำหนด Namespace สำหรับกลุ่มความปลอดภัย จัดการโดยที่เก็บหรือ ผู้ให้บริการข้อมูลประจำตัว
ใช้แหล่งที่มาของข้อมูลประจำตัวในกรณีต่อไปนี้
- ที่เก็บไม่มีความรู้เกี่ยวกับที่อยู่อีเมลหลักของ ผู้ใช้ใน Google Workspace หรือ Google Cloud Directory
- ที่เก็บจะกำหนดกลุ่มสำหรับการควบคุมการเข้าถึงที่ไม่ตรงกัน สำหรับกลุ่มที่ใช้อีเมลใน Google Workspace
แหล่งที่มาของข้อมูลประจำตัวช่วยปรับปรุงประสิทธิภาพการจัดทำดัชนีโดยการแยกการจัดทำดัชนี จากการจับคู่ข้อมูลประจำตัว การแยกส่วนช่วยให้คุณค้นหาผู้ใช้ได้ช้าลง เมื่อสร้าง ACL และการจัดทำดัชนีรายการ
ตัวอย่างการทำให้ใช้งานได้
รูปที่ 1 แสดงตัวอย่างการติดตั้งใช้งานทั้งภายในองค์กรและระบบคลาวด์ องค์กรใช้ที่เก็บ ที่เก็บแต่ละรายการจะใช้ประเภท รหัสภายนอกที่อ้างอิงถึงผู้ใช้
ที่เก็บ 1 ระบุผู้ใช้โดยใช้ที่อยู่อีเมลที่ยืนยัน SAML เพราะ ที่เก็บ 1 มีความรู้เกี่ยวกับที่อยู่อีเมลหลักของผู้ใช้ใน ไม่จำเป็นต้องใช้แหล่งที่มาของข้อมูลประจำตัว Google Workspace หรือ Cloud Directory
Repository 2 ผสานรวมกับไดเรกทอรีภายในองค์กรโดยตรง และ
ระบุผู้ใช้ตามแอตทริบิวต์ sAMAccountName
เนื่องจากที่เก็บ 2
ใช้แอตทริบิวต์ sAMAccountName
เป็นรหัสภายนอก แหล่งที่มาของข้อมูลประจำตัวคือ
ที่จำเป็น
สร้างแหล่งที่มาของข้อมูลประจำตัว
หากต้องการแหล่งที่มาของข้อมูลประจำตัว โปรดดูหัวข้อจับคู่ข้อมูลประจำตัวของผู้ใช้ใน Cloud Search
คุณต้องสร้างแหล่งที่มาของข้อมูลประจำตัวก่อนสร้างเครื่องมือเชื่อมต่อเนื้อหาเนื่องจาก
คุณจะต้องใช้รหัสแหล่งที่มาของข้อมูลประจำตัวเพื่อสร้าง ACL และข้อมูลดัชนี ตามที่กล่าวไว้
ก่อนหน้านี้ การสร้างแหล่งที่มาของข้อมูลประจำตัวยังสร้าง
พร็อพเพอร์ตี้ผู้ใช้ที่กำหนดเอง
ในไดเรกทอรีระบบคลาวด์ ใช้พร็อพเพอร์ตี้นี้เพื่อบันทึกรหัสภายนอกสำหรับ
ผู้ใช้ในที่เก็บของคุณ ตั้งชื่อพร็อพเพอร์ตี้โดยใช้
IDENTITY_SOURCE_ID_identity
ตารางต่อไปนี้แสดงแหล่งที่มาของข้อมูลประจำตัว 2 แหล่ง โดยแหล่งหนึ่งใช้เก็บชื่อบัญชี SAM (sAMAccountName) เป็นรหัสภายนอก และอีกรหัสสำหรับเก็บรหัสผู้ใช้ (uid) เป็นรหัสภายนอก
แหล่งที่มาของข้อมูลประจำตัว | พร็อพเพอร์ตี้ผู้ใช้ | รหัสภายนอก |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
สร้างแหล่งที่มาของข้อมูลประจำตัวสำหรับรหัสภายนอกที่เป็นไปได้แต่ละรายการที่ใช้เพื่อ กล่าวถึงผู้ใช้ในองค์กรของคุณ
ตารางต่อไปนี้แสดงวิธีที่ผู้ใช้มีบัญชี Google และรหัสภายนอก 2 รหัส (id1_identity และ id2_identity) และค่าต่างๆ จะปรากฏใน Cloud Directory ดังนี้
ผู้ใช้ | อีเมล | id1_identity | id2_identity |
---|---|---|---|
Ann | ann@example.com | ตัวอย่าง | 1001 |
คุณสามารถอ้างอิงผู้ใช้รายเดียวกันโดยใช้รหัสที่แตกต่างกัน 3 รหัส (อีเมล Google, sAMAccountName และ uid) เมื่อสร้าง ACL สำหรับการจัดทำดัชนี
เขียน ACL ของผู้ใช้
ใช้เมนู getUserPrincpal() หรือ getGroupPrincipal() วิธีสร้างผู้ใช้หลักโดยใช้รหัสภายนอกที่ให้ไว้
ตัวอย่างต่อไปนี้แสดงวิธีการเรียกสิทธิ์ในไฟล์ เหล่านี้ สิทธิ์จะมีชื่อของผู้ใช้แต่ละรายที่มีสิทธิ์เข้าถึงไฟล์
ข้อมูลโค้ดต่อไปนี้แสดงวิธีสร้างผู้ใช้หลักที่เป็นเจ้าของ
โดยใช้รหัสภายนอก (externalUserName
) ที่จัดเก็บไว้ในแอตทริบิวต์
สุดท้าย ข้อมูลโค้ดต่อไปนี้จะแสดงวิธีสร้างผู้ใช้หลักที่ เป็นผู้อ่านไฟล์
เมื่อมีรายชื่อผู้อ่านและเจ้าของแล้ว คุณสามารถสร้าง ACL ได้โดยทำดังนี้
REST API ที่สำคัญจะใช้รูปแบบ
identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
สำหรับรหัสเมื่อสร้างผู้ใช้หลัก จะอ้างอิงกลับไปยังตารางก่อนหน้า
หากคุณสร้าง ACL ด้วย id1_identity
(SAMAccountName) ของ Ann รหัสจะ
แก้ไขเป็น:
identitysources/id1_identity/users/example/ann
รหัสนี้เรียกว่ารหัสกลางของผู้ใช้ เนื่องจากมีการเชื่อมโยงระหว่างรหัสภายนอกกับรหัส Google ที่จัดเก็บไว้ ด้วย Cloud Directory
หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับการสร้างโมเดล ACL ที่ใช้สำหรับที่เก็บ โปรดดู ACL
แมปกลุ่ม
นอกจากนี้ แหล่งที่มาของข้อมูลประจำตัวยังทำหน้าที่เป็นเนมสเปซสำหรับกลุ่มที่ใช้ใน ACL คุณสามารถ ใช้ฟีเจอร์เนมสเปซนี้เพื่อสร้างและแมปกลุ่มที่ใช้สำหรับการรักษาความปลอดภัย เฉพาะหรืออยู่ในที่เก็บ
ใช้ Cloud Identity Groups API เพื่อสร้างกลุ่มและจัดการการเป็นสมาชิก ในการเชื่อมโยงกลุ่มกับ ให้ใช้ชื่อทรัพยากรแหล่งที่มาของข้อมูลประจำตัวเป็นเนมสเปซของกลุ่ม
ข้อมูลโค้ดต่อไปนี้แสดงวิธีสร้างกลุ่มโดยใช้ Cloud Identity Groups API:
สร้าง ACL ของกลุ่ม
หากต้องการสร้าง ACL ของกลุ่ม ให้ใช้เมธอด getGroupPrincipal() วิธีสร้างผู้ใช้หลักของกลุ่มโดยใช้รหัสภายนอกที่กำหนดให้ จากนั้นสร้าง ACL โดยใช้ Acl.Builder ดังนี้
เครื่องมือเชื่อมต่อข้อมูลประจำตัว
แม้ว่าคุณจะใช้รหัสภายนอก ที่ไม่ใช่ของ Google เพื่อสร้าง ACL และรายการดัชนีได้ ผู้ใช้จะไม่เห็นรายการในการค้นหาจนกว่ารหัสภายนอกจะเปลี่ยนเป็น รหัสในไดเรกทอรีระบบคลาวด์ มี 3 วิธีที่จะตรวจสอบว่า Cloud Directory จะรู้ทั้งรหัส Google และรหัสภายนอกของผู้ใช้ ดังนี้
- อัปเดตโปรไฟล์ผู้ใช้แต่ละรายการด้วยตนเองผ่านคอนโซลผู้ดูแลระบบ ขอแนะนำให้ใช้วิธีนี้สำหรับการทดสอบและสร้างต้นแบบโดยใช้โปรไฟล์ผู้ใช้เพียงไม่กี่โปรไฟล์เท่านั้น
- แมปรหัสภายนอกกับรหัส Google โดยใช้ Directory API เราแนะนำขั้นตอนนี้สำหรับผู้ที่ไม่สามารถใช้ Identity Connector SDK
- สร้างเครื่องมือเชื่อมต่อข้อมูลประจำตัว โดยใช้ Identity Connector SDK SDK นี้ช่วยลดความซับซ้อนในการใช้ Directory API เพื่อแมปรหัส
เครื่องมือเชื่อมต่อข้อมูลประจำตัวเป็นโปรแกรมที่ใช้แมปรหัสภายนอกจากองค์กร ข้อมูลประจำตัว (ผู้ใช้และกลุ่ม) ให้กับข้อมูลประจำตัวภายในของ Google ที่ Google ใช้ Cloud Search หากต้องสร้างแหล่งที่มาของข้อมูลประจำตัว คุณต้อง สร้างเครื่องมือเชื่อมต่อข้อมูลประจำตัว
Google Cloud Directory Sync (GCDS) คือ ตัวอย่างของเครื่องมือเชื่อมต่อข้อมูลประจำตัว เครื่องมือเชื่อมต่อข้อมูลประจำตัวนี้จะจับคู่ผู้ใช้และ ข้อมูลกลุ่มจาก Active Directory ของ Microsoft ไปยัง Cloud Directory ด้วยแอตทริบิวต์ผู้ใช้ที่อาจแสดงตัวตนของผู้ใช้ในระบบอื่นๆ
ซิงค์ข้อมูลประจำตัวโดยใช้ REST API
ใช้เมธอด update
เพื่อซิงค์ข้อมูลประจำตัวโดยใช้ REST API
การแมปข้อมูลประจำตัวอีกครั้ง
หลังจากรีแมปข้อมูลประจำตัวของรายการกับข้อมูลประจำตัวอื่นแล้ว คุณต้องจัดทำดัชนีรายการอีกครั้ง ให้กับข้อมูลประจำตัวใหม่ ตัวอย่างเช่น
- หากคุณพยายามนำการแมปออกจากผู้ใช้ หรือแมปกับผู้ใช้รายอื่น การแมปต้นฉบับจะยังคงอยู่จนกว่าคุณจะจัดทำดัชนีใหม่
- หากคุณลบกลุ่มที่แมปแล้วซึ่งมีอยู่ใน ACL ของรายการ แล้วสร้างกลุ่ม
กลุ่มใหม่ที่มี
groupKey
เดิม แต่กลุ่มใหม่จะไม่สามารถให้สิทธิ์เข้าถึง จนกว่าจะมีการจัดทำดัชนีรายการอีกครั้ง