סנכרון של מערכות זהות שונות

בקרת הגישה בחיפוש Google Cloud מבוססת על חשבון Google של המשתמש. כשמוסיפים תוכן לאינדקס, כל רשימות ה-ACL בפריטים חייבות לפתור למזהי משתמשים או למזהי קבוצות תקפים ב-Google (כתובות אימייל).

במקרים רבים, למאגר אין ידע ישיר לגבי חשבונות Google. במקום זאת, המשתמשים יכולים להיות מיוצגים על ידי חשבונות מקומיים או להשתמש בכניסה מאוחדת עם ספק זהויות ומזהה, שאינם כתובת האימייל של המשתמש, כדי לזהות כל חשבון. המזהה הזה נקרא מזהה חיצוני.

מקורות זהויות נוצרים באמצעות מסוף Admin ומאפשרים לגשר על הפער בין מערכות הזהויות באמצעות:

• הגדרת שדה משתמש מותאם אישית לשמירת מזהי משתמשים חיצוניים. השדה משמש לפתרון של מזהי חשבון חיצוניים לחשבון Google.
• מגדירים מרחב שמות לקבוצות אבטחה שמנוהל על ידי מאגר או ספק זהויות.

כדאי להשתמש במקורות זהות במקרים הבאים:

• המאגר לא יודע מהי כתובת האימייל הראשית של המשתמש ב-Google Workspace או ב-Google Cloud Directory.
• המאגר מגדיר קבוצות לבקרת גישה שלא תואמות לקבוצות שמבוססות על כתובות אימייל ב-Google Workspace.

מקורות זהויות משפרים את היעילות של הוספת הנתונים לאינדקס על ידי ניתוק הוספת הנתונים לאינדקס ממיפוי הזהויות. הפרדה כזו מאפשרת לדחות את החיפוש של המשתמש כשיוצרים רשימות ACL ומוסיפים פריטים לאינדקס.

פריסה לדוגמה

באיור 1 מוצגת דוגמה לפריסה שבה ארגון משתמש במאגרים מקומיים ובמאגרים בענן. בכל מאגר נעשה שימוש בסוג אחר של מזהה חיצוני כדי להפנות למשתמשים.

המאגר 1 מזהה את המשתמש באמצעות כתובת האימייל שאומתה באמצעות SAML. מכיוון שמאגר 1 יודע מהי כתובת האימייל הראשית של המשתמש ב-Google Workspace או ב-Cloud Directory, אין צורך במקור זהויות.

המאגר 2 משתלב ישירות עם ספרייה מקומית ומזהה את המשתמש לפי המאפיין sAMAccountName. מכיוון שמאגר 2 משתמש במאפיין sAMAccountName כמזהה חיצוני, נדרש מקור זהויות.

יצירת מקור זהויות

אם אתם צריכים מקור זהויות, תוכלו לעיין במאמר מיפוי זהויות משתמשים ב-Cloud Search.

צריך ליצור מקור זהויות לפני שיוצרים מחבר תוכן, כי המזהה של מקור הזהויות נדרש ליצירת רשימות ACL ולאינדקס נתונים. כפי שצוין קודם, יצירת מקור זהויות יוצרת גם מאפיין משתמש מותאם אישית ב-Cloud Directory. משתמשים במאפיין הזה כדי לתעד את המזהה החיצוני של כל משתמש במאגר. השם של הנכס נקבע לפי המוסכמה IDENTITY_SOURCE_ID_identity.

בטבלה הבאה מוצגים שני מקורות זהויות, אחד לאחסון שמות של חשבונות SAM (sAMAccountName) בתור מזהים חיצוניים, והשני לאחסון מזהי משתמשים (uid) בתור מזהים חיצוניים.

יוצרים מקור זהויות לכל מזהה חיצוני אפשרי שמשמש לתייחסות למשתמש בארגון.

בטבלה הבאה אפשר לראות איך משתמש עם חשבון Google ושני זהויות חיצוניות (id1_identity ו-id2_identity) והערכים שלהם מופיעים ב-Cloud Directory:

אפשר להפנות לאותו משתמש באמצעות שלושת המזהים השונים (כתובת האימייל ב-Google, sAMAccountName ו-uid) כשיוצרים רשימות ACL לצורך הוספה לאינדקס.

כתיבת רשימות ACL של משתמשים

משתמשים ב-method‏ getUserPrincpal() או ב-method‏ getGroupPrincipal() כדי ליצור חשבונות משתמשים באמצעות מזהה חיצוני שסופק.

הדוגמה הבאה ממחישה איך לאחזר הרשאות קובץ. ההרשאות האלה כוללות את השם של כל משתמש שיש לו גישה לקובץ.

/**
 * Sample for mapping permissions from a source repository to Cloud Search
 * ACLs. In this example, POSIX file permissions are used a the source
 * permissions.
 *
 * @return Acl
 * @throws IOException if unable to read file permissions
 */
static Acl mapPosixFilePermissionToCloudSearchAcl(Path pathToFile) throws IOException {
  // Id of the identity source for external user/group IDs. Shown here,
  // but may be omitted in the SDK as it is automatically applied
  // based on the `api.identitySourceId` configuration parameter.
  String identitySourceId = "abcdef12345";

  // Retrieve the file system permissions for the item being indexed.
  PosixFileAttributeView attributeView = Files.getFileAttributeView(
      pathToFile,
      PosixFileAttributeView.class,
      LinkOption.NOFOLLOW_LINKS);

  if (attributeView == null) {
    // Can't read, return empty ACl
    return new Acl.Builder().build();
  }

  PosixFileAttributes attrs = attributeView.readAttributes();
  // ...
}

בקטע הקוד הבא מוסבר איך ליצור חשבונות משתמשים שהם בעלים באמצעות המזהה החיצוני (externalUserName) שמאוחסן במאפיינים.

// Owner, for search quality.
// Note that for principals the name is not the primary
// email address in Cloud Directory, but the local ID defined
// by the OS. Users and groups must be referred to by their
// external ID and mapped via an identity source.
List<Principal> owners = Collections.singletonList(
    Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId)
);

לבסוף, בקטע הקוד הבא מוסבר איך ליצור חשבונות משתמשים שיש להם הרשאת קריאה לקובץ.

// List of users to grant access to
List<Principal> readers = new ArrayList<>();

// Add owner, group, others to readers list if permissions
// exist. For this example, other is mapped to everyone
// in the organization.
Set<PosixFilePermission> permissions = attrs.permissions();
if (permissions.contains(PosixFilePermission.OWNER_READ)) {
  readers.add(Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId));
}
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}
if (permissions.contains(PosixFilePermission.OTHERS_READ)) {
  Principal everyone = Acl.getCustomerPrincipal();
  readers.add(everyone);
}

אחרי שתיצרו רשימה של קוראים ובעלי גישה, תוכלו ליצור את רשימת ה-ACL:

// Build the Cloud Search ACL. Note that inheritance of permissions
// from parents is omitted. See `setInheritFrom()` and `setInheritanceType()`
// methods on the builder if required by your implementation.
Acl acl = new Acl.Builder()
    .setReaders(readers)
    .setOwners(owners)
    .build();

ב-API ל-REST הבסיסי נעשה שימוש בתבנית 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:

String namespace = "identitysources/" + idSource;
Group group = new Group()
    .setGroupKey(new EntityKey().setNamespace(namespace).setId(groupId))
    .setDescription("Demo group")
    .setDisplayName(groupName)
    .setLabels(Collections.singletonMap("system/groups/external", ""))
    .setParent(namespace);
try {
  CloudIdentity service = Utils.buildCloudIdentityService();
  Operation createOperation = service.groups().create(group).execute();

  if (createOperation.getDone()) {
    // Note: The response contains the data for a Group object, but as
    // individual fields. To convert to a Group instance, either populate
    // the fields individually or serialize & deserialize to/from JSON.
    //
    // Example:
    // String json = service.getJsonFactory().toString(response);
    // Group createdGroup =  service.getObjectParser()
    //     .parseAndClose(new StringReader(json), Group.class);
    System.out.printf("Group: %s\n",
        createOperation.getResponse().toString());
  } else {
    // Handle case where operation not yet complete, poll for
    // completion. API is currently synchronous and all operations return
    // as completed.
    // ...
  }
} catch (Exception e) {
  System.err.printf("Unable to create group: %s", e.getMessage());
  e.printStackTrace(System.err);
}

יצירת ACL לקבוצה

כדי ליצור ACL של קבוצה, משתמשים ב-method‏ getGroupPrincipal() כדי ליצור חשבון משתמש קבוצתי באמצעות מזהה חיצוני שסופק. לאחר מכן, יוצרים את ה-ACL באמצעות הכיתה Acl.Builder באופן הבא:

if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

מחברי זהויות

אפשר להשתמש במזהים חיצוניים שאינם של Google כדי ליצור רשימות ACL ולהוסיף פריטים לאינדקס, אבל המשתמשים לא יכולים לראות פריטים בחיפוש עד שהמזהים החיצוניים שלהם מומרים למזהה Google ב-Cloud Directory. יש שלוש דרכים לוודא שמערכת Cloud Directory מכירה גם את מזהה Google וגם את המזהים החיצוניים של המשתמש:

• לעדכן באופן ידני כל פרופיל משתמש בנפרד דרך מסוף Admin. תהליך זה מומלץ רק לצורך בדיקה ויצירת אב טיפוס באמצעות כמה פרופילים של משתמשים.
• למפות מזהי צד שלישי למזהי Google באמצעות Directory API. התהליך הזה מומלץ למי שלא יכול להשתמש ב-Identity Connector SDK.
• יצירת מחבר זהויות באמצעות Identity Connector SDK. ערכת ה-SDK הזו מפשטת את השימוש ב-Directory API למיפוי מזהי משתמשים.

מחברי זהויות הם תוכנות שמשמשות למיפוי מזהים חיצוניים מזהויות ארגוניות (משתמשים וקבוצות) לזהויות פנימיות של Google שבהן משתמש חיפוש Google Cloud. אם צריך ליצור מקור זהויות, צריך ליצור מחבר זהויות.

Google Cloud Directory Sync‏ (GCDS) הוא דוגמה למחבר זהויות. מחבר הזהויות הזה ממפה את פרטי המשתמשים והקבוצות מ-Active Directory של Microsoft אל Cloud Directory, יחד עם מאפייני המשתמשים שעשויים לייצג את הזהות שלהם במערכות אחרות.

סנכרון זהויות באמצעות ה-API ל-REST

משתמשים ב-method‏ update כדי לסנכרן זהויות באמצעות ה-API ל-REST.

מיפוי מחדש של זהויות

אחרי שממפים מחדש את הזהות של פריט למזהה אחר, צריך להוסיף את הפריטים מחדש לאינדקס כדי שהזהות החדשה תהיה תקפה. לדוגמה,

• אם תנסו להסיר מיפוי ממשתמש או למפות אותו מחדש למשתמש אחר, המיפוי המקורי יישמר עד שתוסיפו אותו מחדש לאינדקס.
• אם מוחקים קבוצה ממופה שנמצאת ב-ACL של פריט, ואז יוצרים קבוצה חדשה עם אותו groupKey, הקבוצה החדשה לא מספקת גישה לפריט עד שהפריט יתווסף מחדש לאינדקס.