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

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

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

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

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

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

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

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

פריסה לדוגמה

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

Repository 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:

אפשר להפנות לאותו משתמש באמצעות שלושת המזהים השונים (כתובת האימייל של 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), המזהה צריך לפתור את הבעיה:

identitysources/id1_identity/users/example/ann

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

למידע נוסף על בניית מודלים של רשימות 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. התהליך הזה מומלץ למי שלא יכול להשתמש ב-SDK של מחבר הזהויות.
• יוצרים מחבר זהויות באמצעות ה-SDK של מחבר הזהויות. ערכת ה-SDK הזו מפשטת את השימוש ב-Directory API למיפוי מזהים.

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

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

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

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

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

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

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