שינויים ב-Edge for Private Cloud 4.53.01

סקירה כללית של השינויים

ב-Edge for Private Cloud 4.53.01 בוצעו כמה שינויים שמשפרים את רמת האבטחה של הפלטפורמה, כולל שילוב של גרסאות מעודכנות של תוכנות וספריות. השינויים האלה משפיעים על:

  • מדיניות אימות של OAS (מפרט OpenAPI)
  • מדיניות שתומכת בשאילתות JSONPath
  • מדיניות של קריאה ל-Java שמסתמכת על ספריות שהוצאו משימוש
  • OpenLDAP

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

מדיניות אימות של OAS (מפרט OpenAPI)

הקשר

מדיניות האימות של OAS מאמתת בקשות או תגובות נכנסות בהתאם לכללים שמוגדרים במפרט OpenAPI 3.0 (JSON או YAML). ‫Edge for Private Cloud 4.53.01 כולל שיפורים במדיניות OAS (מפרט OpenAPI), עם דגש על אימות מדויק יותר של גופי התגובה של ה-API.

השינויים

בגרסה Edge for Private Cloud 4.53.01 יש שני שינויים חשובים באופן שבו מדיניות OAS מאמתת תגובות של API, כדי להבטיח התאמה טובה יותר למפרט OpenAPI:

  • תרחיש 1:
    • התנהגות קודמת: אם מפרט ה-OpenAPI דרש גוף תגובה, אבל התגובה בפועל ממדיניות היעד או במעלה הזרם לא כללה גוף תגובה, המדיניות לא סימנה את זה כשגיאת אימות.
    • ההתנהגות הנוכחית: המדיניות תחזיר עכשיו בצורה נכונה שגיאת אימות (לדוגמה: defines a response schema but no response body found) בתרחיש הזה, כדי לציין חוסר התאמה בין התגובה הצפויה לתגובה בפועל.
  • תרחיש 2:
    • התנהגות קודמת: אם במסמך מפרט OpenAPI צוין במפורש שלא צפוי גוף תגובה, אבל התגובה בפועל ממדיניות היעד או במעלה הזרם כללה גוף, המדיניות לא הייתה גורמת לכשל.
    • ההתנהגות הנוכחית: המדיניות תגרום עכשיו לכשל (לדוגמה: No response body is expected but one was found) בתרחיש הזה, כדי להבטיח שהתשובות יתאימו באופן מדויק לסכימה שצוינה.

צמצום הפגיעה

מזהים את כל ה-proxy או את כל הזרימות המשותפות שבהם מדיניות האימות של OAS מוגדרת עם תג Source שמוגדר לערך response, או את כל ה-proxy או את כל הזרימות המשותפות שבהם מתבצע אימות של התגובה מכל מדיניות אחרת שמפיקה תגובה.

אחרי שמזהים פרוקסי או זרימת נתונים משותפת, צריך לוודא שיש התאמה בין התגובה לבין מפרט ה-OAS. התגובה צריכה להיות תואמת באופן מדויק למפרט OpenAPI בנוגע לנוכחות או להיעדר של גוף תגובה. אפשר להשתמש בכלי Apigee trace הרגיל כדי לבדוק את דפוסי התנועה. אם היעד מחזיר תגובה לסירוגין, צריך להשתמש במדיניות אחרת כדי לאמת אותה לפני מדיניות OAS

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

לפני שמנסים לשדרג ל-Private Cloud 4.53.01, צריך לעדכן את מדיניות האימות של OAS או את התנהגות היעד לפי הצורך. מומלץ לאמת את תהליכי העבודה האלה בסביבות שאינן סביבות ייצור, כדי לצמצם את הסיכון לשיבושים במהלך שדרוג אשכול הייצור.

נתיב JSON

הקשר

ב-Edge for Private Cloud 4.53.01 בוצעו שינויים באופן השימוש בביטויי נתיב JSON במדיניות שונות. אפשר להשתמש בביטויי JSONPath במדיניות כמו ExtractVariable policy,‏ RegularExpressionProtection policy וData masking כדי לנתח תוכן JSON או לאחסן ערכים במשתנים. אפשר גם להשתמש בביטויי JSONPath בתבניות כלליות של הודעות כדי להחליף משתנים בערכים באופן דינמי במהלך ההפעלה של ה-proxy. הביטויים והפורמטים החדשים של JSONPath תואמים לתקנים העדכניים ביותר של ביטויי JSON.

השינויים

חשוב לבדוק אם יש מדיניות ב-API proxies או ברכיבי Shared Flow קיימים שמשתמשת בביטויי JSONPath. זה כולל, בין היתר, את המדיניות בנושא חילוץ משתנים, המדיניות בנושא הגנה על ביטויים רגולריים או כל מדיניות עם תבנית הודעה באמצעות JSONPath.

קלט ה-JSON שלמטה משמש להסבר על השינויים:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}
  1. שינוי בהתנהגות של התו הכללי [*] ב-JSONPath לגבי ערכי אובייקטים

    ההתנהגות של התו הכללי [*] השתנתה כשמשתמשים בו כדי לגשת לכל הערכים המיידיים של אובייקט JSON. בעבר, הפונקציה $.object[*] הייתה מחזירה את הערכים המיידיים עטופים באובייקט JSON יחיד. בספריות המעודכנות, הפלט הוא עכשיו מערך שמכיל את הערכים האלה.

    לדוגמה, $.store[*]:

    התנהגות קודמת: 
    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
    התנהגות נוכחית: 
    [
  [
    {"category": "reference", "author": "Nigel Rees", "price": 8.95},
    {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
    {"category": "fiction", "author": "Herman Melville", "price": 8.99}
  ],
  {
    "color": "red",
    "book": [{"author": "Abc"}]
  }
]
    פעולה:

    משנים את ביטוי ה-JSONPath כך שיכוון ישירות לאובייקט ההורה (לדוגמה: $.store) כדי לכוון ישירות לפריטים שאוחזרו קודם.

  2. נקודה בסוף נתיבי JSONPath‏ (.) גורמת לשגיאה

    יש אימות מחמיר יותר לביטויי JSONPath. בעבר, נתיבים שהסתיימו בנקודה לא חוקית (לדוגמה: $.path.to.element.) היו מתעלמים בשקט, והשאילתה עדיין הייתה מחזירה תוצאה אם קטע הנתיב הקודם היה תואם. בגרסה החדשה, נתיבים כאלה עם פורמט שגוי מזוהים עכשיו בצורה נכונה כלא תקינים, ויוצג לגביהם שגיאה.

    לדוגמה: $.store.book.

    התנהגות קודמת: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
    התנהגות נוכחית: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    כל כללי המדיניות הקיימים שמשתמשים בביטויי JSONPath עם נקודה לא מכוונת בסוף הביטוי ייכשלו עכשיו עם InvalidPathException.

    פעולה:

    מסירים את הנקודה בסוף כל ביטוי JSONPath שמסתיים בנקודה. לדוגמה, שינוי של $.store.book. ל-$.store.book.

  3. שינוי במבנה הפלט של (..) JSONPath recursive descent

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

    לדוגמה: $..book

    התנהגות קודמת: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"},
  {"author":"Abc"}
]
    התנהגות נוכחית: 
    [
  [
    {"category":"reference","author":"Nigel Rees","price":8.95},
    {"category":"fiction","author":"Evelyn Waugh","price":12.99},
    {"category":"fiction","author":"Herman Melville","price":8.99}
  ],
  [
    {"author":"Abc"}
  ]
]
    פעולה:

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

  4. אינדקס JSONPath אחרי בחירה של כמה פריטים או אחרי מסנן מחזיר מערך ריק

    יש שינוי בהתנהגות כשמחילים אינדקס (לדוגמה: [0]) מיד אחרי בורר מרובה פריטים (כמו [*]) או מסנן ([?(condition)]). בעבר, ביטויים כאלה ניסו לבחור את הפריט באינדקס שצוין מתוך התוצאות המשולבות. בגרסה החדשה, הביטויים האלה יחזירו עכשיו מערך ריק ([]).

    לדוגמה: $.store.book[*][0]

    התנהגות קודמת: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    התנהגות נוכחית: 
    []
    פעולה:

    אם יש צורך לסנן ואז לקבל פריט ספציפי מתוך קבוצת הפריטים המסוננים, מעבדים את המערך המסונן שמוחזר על ידי JSONPath, לדוגמה, $..book[?(@.category == 'fiction')] ואז לוקחים את [0] מהתוצאה הקודמת.

  5. שינוי בפלט של חיתוך מערך שלילי ב-JSONPath

    בגרסה החדשה שונה אופן הפעולה של חיתוך מערכים שליליים (לדוגמה: [-2:], [-1:]). בעבר, כשמחילים חיתוך שלילי על מערך (שמציין רכיבים מסוף המערך), הגרסה הישנה החזירה באופן שגוי רק פריט אחד מהחיתוך הזה. הגרסה החדשה מחזירה עכשיו בצורה נכונה רשימה (מערך) שמכילה את כל הרכיבים שנמצאים בטווח השלילי שצוין.

    לדוגמה $.store.book[-2:]

    התנהגות קודמת: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    התנהגות נוכחית: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    פעולה:

    עכשיו צריך לעדכן את לוגיקת העיבוד במורד הזרם כדי לבצע איטרציה במערך ה-JSON שהוחזר ולקבל את הפלט הרצוי.

  6. נקודה קודמת מחמירה יותר ב-JSONPath

    יש אכיפה מחמירה יותר של התחביר לגבי רכיבים שאליהם ניגשים ישירות מהשורש. כשניגשים לרכיבים ישירות מהשורש בלי נקודה לפני (לדוגמה: $propertyelement), התחביר הזה נחשב עכשיו לשגיאה וימנע פריסת פרוקסי.

    לדוגמה $store,

    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}

    התנהגות נוכחית:

    Proxy will fail to deploy.

    פעולה:

    משנים את ה-JSONPath כך שיכלול את הנקודה: $.propertyName (לדוגמה: $.store). כך המערכת תטרגט ותאחזר את הערך בצורה נכונה.

  7. ביטויי JSONPath דינמיים

    חשוב לשים לב למדיניות שבה ביטוי ה-JSONPath עצמו מסופק על ידי משתנה (לדוגמה: {myJsonPathVariable} או {dynamicPath}). צריך לבדוק גם את הערך של המשתנים האלה בהשוואה לשינויים האפשריים בהתנהגות שצוינו למעלה.

צמצום הפגיעה

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

בוחרים את השיטה לשדרוג שמתאימה לכם:

  • העברה ללא זמן השבתה

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

    • יוצרים סביבה חדשה ומוסיפים לסביבה החדשה צמתים חדשים של מעבד הודעות בגרסה 4.53.01.
    • מעלים את חבילת ה-proxy ל-proxies שהושפעו לסביבה החדשה ומבצעים את התיקונים הנדרשים שמוסברים בקטע התיקון ופורסים את חבילת ה-proxy המעודכנת בסביבה החדשה.
    • להפנות את התנועה לסביבה החדשה ולבטל את הפריסה של ה-proxies המושפעים מהסביבה הישנה.
    • שדרוג של צמתי מעבד ההודעות המקורי לגרסה 4.53.01. פריסת שרתי proxy עם תיקונים ל-JSONPath בסביבה המקורית.
    • מעבירים את תנועת הגולשים חזרה לסביבה הישנה, שכוללת עכשיו מעבדי הודעות בגרסה 4.53.01 ושרת proxy שעבר מודרניזציה לביטויים חדשים של jsonpath.
    • מוחקים את הסביבה החדשה ואת הצמתים שמשויכים אליה.
  • זמן השבתה ושדרוג

    האסטרטגיה הזו כוללת השבתה של שרתי proxy ל-API באמצעות ביטויי JSON Path פגומים. השינוי לא מחייב רכישה של צמתים נוספים לעיבוד הודעות, אבל הוא גורם לשיבוש בתנועת ה-API עבור שרתי proxy מושפעים.

    • מזהים את ה-proxies שהושפעו מהשגיאה ואת המדיניות שהושפעה, ויוצרים גרסה חדשה לכל ה-proxies שהושפעו.
    • מבצעים את התיקונים הנדרשים על ידי יישום התיקונים שמוסברים בקטע 'תיקון' בגרסה חדשה של ה-proxy. אל תבצעו פריסה עדיין.
    • משיגים זמן השבתה לשרת ה-proxy או לשרתי ה-proxy שמושפעים.
    • שדרוג כל מעבדי ההודעות ל-Edge לגרסה 4.53.01 של ענן פרטי. שימו לב: יכול להיות שהפרוקסי הקיימים ייכשלו במעבדי ההודעות ששודרגו לאחרונה.
    • אחרי שמשדרגים את כל מעבדי ההודעות לגרסה 4.53.01 של Edge לענן פרטי , פורסים את הגרסה החדשה של ה-proxy עם ביטוי JSONPath שתוקן.
    • להפעיל מחדש את התנועה בשרתי proxy כאלה.
  • עיצוב מחדש של שרת ה-Proxy לפני השדרוג

    אפשר לעצב מחדש את ה-proxy לפני השדרוג ל-Edge for Private Cloud 4.53.01. במקום להסתמך על ביטויי נתיב JSON ספציפיים, אפשר להשתמש בשיטה אחרת כדי לקבל את אותה התוצאה.

    לדוגמה, אם אתם משתמשים במדיניות Extract Variable עם נתיב JSON, אתם יכולים להחליף את המדיניות במדיניות Javascript שמחלצת נתונים דומים לפני השדרוג לגרסה החדשה יותר. אחרי שהשדרוג יושלם, תוכלו לשנות את ה-proxy בחזרה לשימוש בנתיבי JSON עם פורמטים חדשים יותר.

שינויים ב-JavaCallout

הקשר

ב-Edge for private cloud בגרסה 4.53.00 ובגרסאות קודמות הייתה ספרייה בשם deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) שכללה הרבה ספריות JAR. הספריות האלה היו זמינות לשימוש בקוד Java במדיניות JavaCallout, ואפשר היה להשתמש בהן בקוד Java מותאם אישית באופן ישיר או עקיף.

השינויים

הספרייה deprecated הוסרה מ-Edge לענן פרטי בגרסה 4.53.01. אם קוד ה-Java שלכם מסתמך על ספריות כאלה, פרוקסי שמשתמש בקריאות כאלה ל-Java ייכשל כשהמעבדים של ההודעות ישודרגו לגרסה 4.53.01. כדי למנוע כשלים כאלה, צריך לבצע את השלבים הבאים לצמצום הסיכון לפני שמשדרגים את מעבדי ההודעות לגרסה 4.53.01.

צמצום הפגיעה

  1. בודקים את מדיניות Java-Callout ואת קובצי ה-jar המשויכים, ומזהים אם יש ביניהם הפניה לספריות שנמצאות בספרייה deprecated של מעבדי ההודעות הנוכחיים או שימוש בהן. שימו לב שאולי יש קריאות ל-Java שמשתמשות בקובצי JAR שהועלו כמשאבים ברמת הארגון או הסביבה. כדאי גם לעיין בספריות האלה.
  2. אחרי שמזהים ספריות כאלה שהוצאו משימוש , אפשר לפתור את הבעיה באחת מהשיטות הבאות.
    • מיקום משאבים (מומלץ אם יש לכם מספר קטן של קובצי JAR או ספריות מהספרייה שהוצאה משימוש, שקובצי ה-JAR של Java-Callout מפנים אליהם)
      • מעלים את קובצי ה-JAR שהוצאו משימוש כמשאב ברמה הרצויה: תיקון של שרת proxy של API, סביבה או ארגון.
      • ממשיכים בשדרוג התוכנה של Apigee כרגיל.
    • מיקום ידני (מומלץ אם יש לכם מספר גדול של קובצי JAR או ספריות שקובצי ה-JAR של Java-Callout מפנים אליהם)
      • בכל צומת של מעבד ההודעות, יוצרים ספרייה חדשה בשם external-lib בנתיב $APIGEE_ROOT/data/edge-message-processor/.
      • מעתיקים את קובצי ה-JAR שזוהו אל הספרייה external-lib הזו מהספרייה שהוצאה משימוש: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • מוודאים שמשתמש Apigee יכול לקרוא את הספרייה ואת קובצי ה-JAR הבסיסיים: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • ממשיכים בשדרוג התוכנה של Apigee כרגיל.

שינוי ב-OpenLDAP

הקשר

אפשר להשתמש ב-OpenLDAP ב-Edge Private Cloud גם לאימות וגם להרשאה. ב-Edge for Private Cloud 4.53.01, תוכנת OpenLDAP שסופקה על ידי Apigee שודרגה מגרסה 2.4 לגרסה 2.6.

השינויים

ב-OpenLDAP 2.6, שם יחסי ייחודי (RDN) מוגבל לכ-241 בייטים או תווים. המגבלה הזו היא מכסה מקסימלית שמוגדרת מראש ואי אפשר לשנות אותה.

השפעה
  • שכפול או ייבוא נכשלים עבור רשומות עם RDN גדול מדי.
  • ניסיון ליצור ישויות כמו ארגונים,סביבות, תפקידים בהתאמה אישית, הרשאות וכו' עשוי להוביל להודעת השגיאה: "message": "[LDAP: error code 80 - Other]".
  • כל DN באורך של יותר מ-241 בייט ב-LDAP של Apigee מושפע. אם יש רשומות כאלה, השדרוג של תוכנת Apigee OpenLDAP לא יצליח, ותצטרכו לפעול לפי אסטרטגיות לצמצום הסיכון לפני שתוכלו להמשיך בשדרוג.

באופן כללי, ב-LDAP של Apigee, שמות DN ארוכים קשורים להרשאות כי הם נוצרים על ידי שרשור של כמה ישויות. רשומות הרשאה כאלה נוטות במיוחד לגרום לבעיות בשדרוג.

לדוגמה, 

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

בדרך כלל, שמות הארגון, הסביבה והתפקיד יהיו באורך כזה ששמות ה-RDN ב-LDAP יהיו קצרים מ-241 בייטים.

צמצום הפגיעה

לפני השדרוג לגרסה 4.53.01:

השלבים הבאים יעזרו לכם לאמת את הנוכחות של שמות RDN ארוכים באשכול LDAP 2.4 הקיים.

#1 - Extract LDAP data

משתמשים בפקודה ldapsearch כדי למצוא את השם הייחודי (dn) ומפנים את הפלט לקובץ: 

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

מוודאים שקובץ ה-DN.ldif שלמעלה מכיל רשומות LDAP.

‫#2 – זיהוי של שמות RDN ארוכים

מאתרים את ה-RDN שחורגים מ-241 בייטים/תווים בקובץ DN.ldif שלמעלה:

cat /tmp/DN.ldif |  grep '^dn:' | gawk -F',|dn: ' '{ rdn = $2; char_count = length(rdn); cmd = "echo -n \"" rdn "\" | wc -c"; cmd | getline byte_count; close(cmd); if (char_count > 241 || byte_count > 241) { print rdn, "(chars: " char_count ") (bytes: " byte_count ")"; }}'
o=VeryLongOrgNameWithMoreThan241Chars.... (chars: 245) (bytes: 245)
cn=VeryLongCustomRoleNameWithMoreThan241Chars.... (chars: 258) (bytes: 258)

אם הפקודה שלמעלה לא מפיקה פלט, סימן שלא קיימים שמות RDN בהגדרת ה-LDAP הקיימת שעולים על 241 בייט או תווים. אפשר להמשיך בשדרוג כרגיל.

אם הפקודה שלמעלה יוצרת פלט, זה מצביע על נוכחות של שמות יחסיים (RDN) שגודלם עולה על 241 בייט או תווים. לגבי פריטים כאלה, צריך לפעול לפי השלבים לתיקון שמתוארים בשלב 3 לפני שממשיכים בשדרוג ל-Edge for Private Cloud 4.53.01.

#3 - Handle long RDNs

אם מתקבל פלט משלב 2, המשמעות היא שיש RDNs באורך של יותר מ-241 בייט/תווים, וצריך לבצע את שלבי ההקלה הבאים:

בודקים את רשומות ה-LDAP שגדולות מ-241 בייט.

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

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

שינויים בספק ההצפנה

הקשר

השינוי הזה הוא המשך של שינוי שבוצע ב-Edge for Private Cloud 4.53.00. ב-Edge for Private Cloud 4.53.00, ספק ההצפנה הפנימי עודכן מ-Bouncy Castle ‏ (BC) ל-Bouncy Castle FIPS ‏ (BCFIPS) כדי להפעיל תמיכה ב-FIPS.

השינויים

אם מדיניות JavaCallout מסתמכת על שימוש בספק BC המקורי, במיוחד כשמשתמשים בפונקציונליות אבטחה שהוקשחה בספק BCFIPS (לדוגמה, שימוש בצמד מפתחות משותף להצפנה ולחתימה), יהיה צורך לעדכן את מדיניות JavaCallout. יכול להיות שמדיניות JavaCallout שמנסה לטעון את ספק ההצפנה Bouncy Castle באמצעות השם BC תיכשל, כי ספק ברירת המחדל השתנה. יכול להיות שכללי מדיניות כאלה שמשתמשים בספק BC יישברו בהמשך. לא תהיה יותר גישה להטמעות בהתאמה אישית שמסתמכות על ספק ה-BC הישן, ויהיה צורך לבדוק אותן ולהטמיע אותן מחדש.

צמצום הפגיעה

הפתרון העקיף המומלץ הוא להשתמש בספק BCFIPS. הטמעות מותאמות אישית של JavaCallout שהסתמכו על הספק הישן יצטרכו להיבדק ולהטמע מחדש באמצעות ספק Bouncy Castle FIPS, שאפשר לגשת אליו באמצעות המחרוזת 'BCFIPS'.

כלי אוטומטי לזיהוי שינויים

אנחנו מתכננים להשיק בקרוב כלי לזיהוי שינויים. הכלי הזה יוכל לסרוק ולזהות פרוקסי של API, רכיבים משותפים, משאבים ושמות יחסיים מובחנים (RDN) של LDAP, שעשויים להיות מושפעים משינויים שונים שמתוארים במאמר הזה. הכלי הזה אמור לעזור לזהות ישויות שונות שעלולות להיכשל במהלך השדרוג ל-Edge for Private Cloud 4.53.01 או אחריו.