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

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

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

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

תיאור מפורט של השינויים

בקטע הזה מתוארים השינויים שנוספו בגרסה 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.
  • מדיניות האימות של OAS מאמתת תשובה מכל מדיניות אחרת שמייצרת תשובה.

אם משתמשים בכלי, הוא ייצור פלט בפורמט הבא:

ארגון סביבה שם הארטיפקט סוג פריט מידע שנוצר בתהליך פיתוח (Artifact) גרסה קודמת שם מדיניות סוג מדיניות סוג ההשפעה שדה ספציפי להשפעה מידת הוודאות של ההשפעה מאמרי עזרה
org2 dev proxy2 שרת proxy 4 oas-validateresponse OASValidation oas_content_type_handling מקור=calloutresponse בינונית המדיניות בנושא אימות OAS
org1 prod proxy3 sharedflow 1 oas-spec-validation OASValidation oas_content_type_handling מקור=תגובה בינונית המדיניות בנושא אימות OAS

הסבר מפורט על העמודות בטבלת הפלט זמין בקטע הסבר על הפלט של הכלי.

אחרי שמזהים פרוקסי או זרימה משותפת, צריך לוודא שהתגובה ומפרט ה-OAS תואמים לגבי הנוכחות או היעדר של גוף התגובה. אפשר להשתמש בכלי 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), התחביר הזה נחשב עכשיו לשגיאה וימנע את פריסת ה-proxy.

    לדוגמה $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}). צריך לבדוק גם את הערך של המשתנים האלה בהשוואה לשינויים האפשריים בהתנהגות שצוינו למעלה.

צמצום הפגיעה

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

ארגון סביבה שם הארטיפקט סוג פריט מידע שנוצר בתהליך פיתוח (Artifact) גרסה קודמת שם מדיניות סוג מדיניות סוג ההשפעה שדה ספציפי להשפעה מידת הוודאות של ההשפעה מאמרי עזרה
org1 dev proxy1 שרת proxy 4 EV-ExtractRequestParams ExtractVariables שינוי בהתנהגות של התו הכללי [‎*] ב-JSONPath עבור ערכי אובייקט $.store[*] גבוהה שינוי בהתנהגות של התו הכללי [‎*] ב-JSONPath עבור ערכי אובייקט
org2 prod proxy2 sharedflow 1 EV-ExtractResponseParams ExtractVariables נקודה בסוף נתיבי JSONPath גורמת לשגיאה $.store.book. גבוהה נקודה בסוף הנתיב ב-JSONPath גורמת לשגיאה
org3 dev proxy3 שרת proxy 3 SC-FetchUserProfile ServiceCallout שינוי במבנה הפלט של JSONPath Recursive Descent (..) $..book גבוהה שינוי במבנה הפלט של JSONPath recursive descent (..)
org4 prod proxy4 sharedflow 2 RF-InvalidAuthToken RaiseFault הוספת אינדקס ל-JSONPath אחרי בחירה של כמה פריטים או סינון מחזירה עכשיו מערך ריק $.store.book[*][0] גבוהה הוספת אינדקס ל-JSONPath אחרי בחירה או סינון של כמה פריטים מחזירה מערך ריק
org5 בדיקה proxy5 שרת proxy 6 SC-FetchProfileDetails ServiceCallout שינוי בפלט של חיתוך מערך שלילי ב-JSONPath $.store.book[-2:] גבוהה שינוי בפלט של חיתוך מערך שלילי ב-JSONPath
org6 prod proxy6 שרת proxy 2 ML-LogRequestDetails MessageLogging נקודה קודמת מחמירה ב-JSONPath ‎$store גבוהה נקודה קודמת מחמירה ב-JSONPath
org7 בדיקה proxy7 שרת proxy 5 RF-InvalidTokenDetails RaiseFault ביטויי JSONPath דינמיים myJsonPathVariable בינונית ביטויים דינמיים של JSONPath

הסבר מפורט על העמודות בטבלת הפלט שלמעלה מופיע בקטע הסבר על הפלט של הכלי.

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

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

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

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

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

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

    • מזהים את ה-proxies שהושפעו מהשגיאה ואת המדיניות שהושפעה, ויוצרים גרסה חדשה לכל ה-proxies שהושפעו.
    • מבצעים את התיקונים הנדרשים על ידי יישום התיקונים שמוסברים בקטע 'תיקון' בגרסה חדשה של ה-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 המשויכים באמצעות הכלי לזיהוי שינויים או באופן ידני. בודקים אם יש מדיניות שמפנה לספריות שמופיעות בספרייה 'הוצא משימוש' של מעבדי ההודעות הנוכחיים.

    אם אתם משתמשים בכלי שסופק על ידי Apigee לזיהויים שלמעלה, הכלי ייצור דוח כמו שמוצג בטבלה הבאה . באופן ספציפי, הוא מטרגט מדיניות שמתייחסת לקובצי JAR שנמצאים בספרייה $APIGEE_ROOT/edge-message-processor/lib/deprecated בגרסאות ישנות יותר של Edge for Private Cloud.

    הכלי ייצור דוחות בפורמט הבא:

    ארגון סביבה שם הארטיפקט סוג פריט מידע שנוצר בתהליך פיתוח (Artifact) גרסה קודמת שם מדיניות סוג מדיניות סוג ההשפעה שדה ספציפי להשפעה מידת הוודאות של ההשפעה מאמרי עזרה
    org1 ללא ללא org-level-jar ללא ללא java-callout זוהתה ספרייה שיצאה משימוש ב-simple-javacallout-o1-jar-1.jar ‪['Detected use of class org.apache.commons.io.FileUtils from commons-io-2.5.jar, 'Detected use of class org.apache.commons.io.input.XmlStreamReaderException from commons-io-2.5.jar'] גבוהה שינויים ב-JavaCallout
    org3 env3 ללא env-level-jar ללא ללא java-callout זוהתה ספרייה שיצאה משימוש ב-fat-javacallout-e3-jar-1.jar ['זוהה שימוש בכיתה org.apache.http.impl.auth.NTLMSchemeFactory מתוך httpclient-4.5.2.jar'] גבוהה שינויים ב-JavaCallout
    org1 env1 p1 proxy-level-jar 1 ללא java-callout זוהתה ספרייה שיצאה משימוש ב-simple-javacallout-p1-jar-1.jar ‪['Detected use of class org.apache.commons.lang3.builder.ToStringBuilder from commons-lang3-3.4.jar', 'Detected use of class org.apache.commons.lang3.Validate from commons-lang3-3.4.jar'] גבוהה שינויים ב-JavaCallout

    הסבר מפורט על העמודות בטבלת הפלט שלמעלה מופיע בקטע הסבר על הפלט של הכלי.

  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 ארוכים

הכלי לזיהוי שינויים משתמש בקובץ LDIF שנוצר כדי לזהות שמות RDN של LDAP שעולים על 241 בייט או תווים.

הכלי ייצור דוחות בפורמט הבא:

ארגון סביבה שם הארטיפקט סוג פריט מידע שנוצר בתהליך פיתוח (Artifact) גרסה קודמת שם מדיניות סוג מדיניות סוג ההשפעה שדה ספציפי להשפעה מידת הוודאות של ההשפעה מאמרי עזרה
ללא ללא cn=really-long-name,ou=userroles,o=edge-platform,ou=organizations,dc=apigee,dc=com קובץ ldif ללא ללא ללא Ldap RDN exceeds 241 chars cn=really-long-name גבוהה שינוי OpenLDAP

הסבר מפורט על העמודות בטבלת הפלט שלמעלה מופיע בקטע הסבר על הפלט של הכלי.

אם הפקודה שלמעלה לא מפיקה פלט, סימן שלא קיימים שמות יחסיים (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'.

כלי לזיהוי שינויים

פיתחנו כלי לזיהוי שינויים, שיעזור לכם לזהות שרתי proxy של Apigee, מדיניות ורכיבי Shared Flow שעשויים להיות מושפעים במהלך המעבר ל-Edge for Private Cloud 4.53.01 ואחריו. הכלי הזה יוצר דוח שמפרט את ה-proxies, את התהליכים המשותפים ואת OpenLDAP שהושפעו מהשינויים, ומספק הפניות למדריכים ולשיטות ספציפיות שרלוונטיות ל-proxies או לתהליכים המשותפים שזוהו.

דרישות מוקדמות

  1. כדי להריץ את הכלי הזה, נדרשת מכונה שמבוססת על RHEL.
  2. צריך להתקין את JRE 8 ולהגדיר אותו בצורה נכונה במכונה הווירטואלית המארחת כדי לאפשר לסקריפטים של הכלי לפעול.
  3. כדי להשתמש בכלי, צריך להזין את נקודת הקצה (כתובת ה-URL) הנכונה של שרת הניהול ופרטי כניסה אדמינסטרטיביים תקינים לאימות ולאחזור נתונים.
  4. הכלי דורש גישה לספריית עבודה ייעודית (למשל, /tmp) כדי לחלץ חבילות, ליצור יומנים ולאחסן פלט. מוודאים שיש מספיק מקום בדיסק בספרייה הזו ושיש לה הרשאות קריאה/כתיבה מתאימות.
  5. הכלי דורש את קובץ ה-LDIF באמצעות הפקודה ldapsearch בקטע OpenLDAP change - Extract LDAP data כדי לזהות את ה-RDN הארוך יותר מ-241 תווים או בייטים.

הפעלת הכלי

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

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.0.zip -o /tmp/change-detector-for-4.53.01_1.0.0.zip
unzip /tmp/change-detector-for-4.53.01_1.0.0.zip

אחרי שההורדה מסתיימת, אפשר להריץ את הפקודה הבאה כדי לראות את כל האפשרויות הזמינות בכלי:

./change-detector --help

כדי להריץ את הכלי, משתמשים בפקודה הבאה ומחליפים את ערכי ה-placeholder בפרטים שלכם:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

כדי לזהות את רשומות ה-RDN הגדולות ב-LDAP, מריצים את הפקודה הבאה:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

הכלי יוצר פלט בפורמט JSON או CSV שאפשר להשתמש בו ישירות או לייבא אותו לכלי שקריא לאנשים, כמו Google Sheets.

הסבר על הפלט של הכלי

ארגון

הוא מצביע על שם הארגון שבו נמצא הארטיפקט. בשינוי OpenLDAP, הערך יהיה None.

סביבה

הסביבה הספציפית (לדוגמה: dev,‏ test,‏ prod) בארגון. בשינוי OpenLDAP, הערך יהיה None.

בשינויים ב-Java Callout, אם Artifact Type=env-level-jar, הערך בשדה הזה יהיה None.

שם פריט המידע שנוצר בתהליך הפיתוח (Artifact)

בשדה הזה מצוין השם של שרת ה-proxy או של הזרימה המשותפת. בשינוי OpenLDAP, בשדה הזה מוצגת ישות ה-LDAP של ה-RDN.

בשינויים של Java Callout, אם הערך של Artifact Type הוא env-level-jar או org-level-jar, הערך של השדה הזה יהיה None.

סוג פריט מידע שנוצר בתהליך פיתוח (Artifact)

  • בעמודה הזו מצוין סוג הארטיפקט, proxy או shared flow, עבור שינויים ב-OAS וב-JSON.
  • בשינוי של Java Callout, בעמודה הזו מפורטים המקום או הרמה שבהם קובץ ה-JAR המושפע הועלה. אפשר לאחסן משאבים (קבצי JAR) באחת משלוש רמות: org-level,‏ env-level ו-proxy-level.
  • בשינוי OpenLDAP, השדה הזה מציין את קובץ ה-LDIF שבו נעשה שימוש בכלי.

גרסה קודמת

הוא מצביע על הגרסה שנפרסה של ה-proxy או התהליך המשותף הרלוונטיים. בשינוי OpenLDAP, הערך יהיה None.

שם מדיניות

השם של המדיניות הספציפית שזוהתה כבעיה פוטנציאלית. בשינוי OpenLDAP, הערך יהיה None.

סוג המדיניות

הוא מצביע על סוג המדיניות. בשינוי OpenLDAP, הערך יהיה None.

סוג ההשפעה

  • בשדה הזה מתואר סוג השינוי הספציפי שזוהה בשרת proxy או בתהליך משותף.
  • במקרה של שינוי ב-Java Callout, הכלי מצביע על ה-Java Callout המושפע שיש לו הפניות לקובצי ה-JAR שנמצאים בספרייה $APIGEE_ROOT/edge-message-processor/lib/deprecated בגרסאות ישנות יותר של Edge for Private Cloud, באופן הבא בעמודה הזו.
  • deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR
  • בשינוי OpenLDAP, בשדה הזה מוצג אם ה-RDN של ישות LDAP כלשהי חרג מ-241 בייטים או תווים.

השפעה על שדה ספציפי

  • בשינוי OAS, השדה הזה הוא שם המשתנה שמשמש בתג מקור של המדיניות.
  • בשינוי JSON, השדה הזה מציג את הביטוי או הרכיב המדויק של JSONPath שסומן כבעיה פוטנציאלית.
  • במקרה של שינוי ב-Java Callout, השדה הזה מכיל את הפרטים של המחלקות המדויקות ואת השם של קובץ ה-JAR התואם (שנמצא בספרייה $APIGEE_ROOT/edge-message-processor/lib/deprecated בגרסאות ישנות יותר של Private Cloud) שנעשה בו שימוש או שהוא מפנה אליו בקובץ ה-JAR של JavaCallout שהושפע. אם לא יבוצעו פעולות לתיקון הבעיה, השדרוג לגרסה 4.53.01 ייכשל.
  •  ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
        Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
      .. , .. , ]
  • בשינוי OpenLDAP, בשדה הזה מוצג ה-RDN של ישות ה-LDAP, שכולם חורגים מ-241 בייט או תווים.

מידת הוודאות של ההשפעה

  • בשדה הזה מצוין רמת הוודאות שבה הכלי זיהה פריט מסוים. הערכים בעמודה הזו יכולים להיות גבוהה או בינונית (יכול להיות שנוסיף עוד ערכים בהמשך).

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

  • בזיהויים שקשורים לשינויים ב-JavaCallout וב-OpenLDAP, הערך בעמודות של ודאות ההשפעה יהיה תמיד גבוה.

מאמרי עזרה

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