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

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

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

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

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

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

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

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

פריסה לדוגמה

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

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

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

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

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

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

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

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

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

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

כתיבת רשימות 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 של קבוצה, משתמשים בשיטה 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. יש שלוש דרכים לוודא ש-Cloud Directory מכיר גם את מזהה Google וגם את המזהים החיצוניים של המשתמש:

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

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

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

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

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

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

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

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