تغییرات در Edge برای Private Cloud 4.53.01

مروری بر تغییرات

Edge for Private Cloud 4.53.01 تغییرات متعددی را ارائه کرده است که وضعیت امنیتی پلتفرم را بهبود می بخشد و نسخه های به روز نرم افزار/کتابخانه ها را در خود جای داده است. این تغییرات بر:

  • خط مشی اعتبارسنجی OAS (مشخصات OpenAPI).
  • خط‌مشی‌هایی که از جستارهای JSONPath پشتیبانی می‌کنند
  • خط مشی فراخوانی جاوا که بر کتابخانه های منسوخ تکیه دارد
  • 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 دو تغییر مهم را در نحوه اعتبارسنجی پاسخ‌های API توسط خط‌مشی OAS معرفی می‌کند و از همسویی نزدیک‌تر با مشخصات OpenAPI شما اطمینان می‌دهد:

  • سناریو 1:
    • رفتار قبلی: اگر مشخصات OpenAPI شما به یک بدنه پاسخ نیاز داشت، اما پاسخ واقعی از خط مشی هدف یا بالادستی شامل یکی نبود، خط‌مشی این را به‌عنوان یک خطای اعتبارسنجی علامت‌گذاری نمی‌کند.
    • رفتار فعلی: خط‌مشی اکنون به درستی یک خطای اعتبارسنجی را برمی‌گرداند (مثال: defines a response schema but no response body found ) در این سناریو، نشان‌دهنده عدم تطابق بین پاسخ مورد انتظار و واقعی است.
  • سناریو 2:
    • رفتار قبلی: اگر مشخصات OpenAPI شما به صراحت بیان می‌کرد که هیچ بدنه پاسخی انتظار نمی‌رود، اما پاسخ واقعی از سیاست هدف یا بالادست شامل یک بدنه می‌شود، این خط‌مشی منجر به شکست نمی‌شود.
    • رفتار فعلی: این خط‌مشی اکنون منجر به شکست می‌شود (مثال: No response body is expected but one was found ) در این سناریو، تضمین می‌کند که پاسخ‌ها کاملاً به طرح مشخص شده پایبند هستند.

کاهش

هر پروکسی یا جریان مشترکی را که در آن خط‌مشی اعتبارسنجی OAS با یک برچسب Source تنظیم شده برای response یا آنهایی که پاسخ را از هر خط‌مشی دیگری که پاسخ ایجاد می‌کند، تأیید می‌کنند، پیکربندی کنید.

هنگامی که یک پروکسی/جریان مشترک شناسایی شد، از همسویی بین Response و OAS Specification اطمینان حاصل کنید. پاسخ باید کاملاً با مشخصات OpenAPI شما در مورد وجود یا عدم وجود بدنه پاسخ مطابقت داشته باشد. می توانید از ردیابی استاندارد Apigee برای بررسی الگوهای ترافیکی خود استفاده کنید. اگر هدف به طور متناوب پاسخ را برمی‌گرداند، قبل از خط‌مشی OAS از سیاست‌های دیگر برای تأیید اعتبار استفاده کنید

  • اگر فایل مشخصات OAS شما یک بدنه پاسخ را تعریف می کند، پاسخ از خط مشی هدف یا بالادست همیشه باید یکی را ارائه کند.
  • اگر فایل مشخصات OAS شما بدنه پاسخگویی را تعریف نمی کند، خط مشی هدف یا بالادست نباید آن را ارسال کند.

قبل از اینکه بخواهید به Private Cloud 4.53.01 ارتقا دهید، سیاست اعتبارسنجی OAS یا رفتار هدف خود را در صورت لزوم به روز کنید. برای به حداقل رساندن خطر اختلال در طول ارتقاء خوشه تولید، ابتدا باید چنین جریان های کاری شناسایی شده را در محیط های غیر تولیدی خود تأیید کنید.

مسیر JSON

زمینه

Edge for Private Cloud 4.53.01 تغییراتی را در نحوه استفاده از عبارات مسیر JSON در خط مشی های مختلف ایجاد کرده است. عبارات JSONPath را می توان در خط مشی هایی مانند سیاست ExtractVariable ، خط مشی RegularExpressionProtection ، پوشش داده برای تجزیه محتوای JSON یا ذخیره مقادیر در متغیرها استفاده کرد. عبارات JSONPath همچنین می توانند در قالب پیام های عمومی برای جایگزینی متغیرها با مقادیر به صورت پویا در طول اجرای پروکسی استفاده شوند. عبارات و قالب های جدید JSONPath از آخرین استانداردهای عبارت JSON پیروی می کنند.

تغییرات

بررسی پروکسی‌های API موجود/جریان‌های مشترک برای خط‌مشی‌هایی که از عبارات JSONPath استفاده می‌کنند، مهم است. این شامل خط‌مشی Extract Variables، خط‌مشی حفاظت از بیان منظم یا هر خط‌مشی با الگوی پیام با استفاده از 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 (..)

    هنگام استفاده از عملگر (..) (نزول بازگشتی) برای مکان یابی همه رخدادهای یک عنصر نامگذاری شده، تغییراتی در نحوه بازگشت نتایج وجود دارد. پیش از این، همه عناصر یافت شده در یک لیست واحد مسطح شدند. کتابخانه های به روز شده اکنون لیستی از لیست ها را برمی گردانند و ساختار گروه بندی اصلی را که عناصر پیدا شده اند حفظ می کنند، نه یک لیست مسطح واحد.

    مثلاً $..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 باشد. اینها را می توان در حین ارتقا استفاده کرد و پس از تکمیل ارتقاء می توان آنها را از رده خارج کرد. این استراتژی یکپارچه است اما شامل تهیه موقت گره‌های پردازشگر پیام اضافی برای پشتیبانی از یک ارتقاء روان است. جزئیات زیر:

  • خرابی و ارتقا

    این استراتژی شامل تهیه خرابی برای پراکسی های API با استفاده از عبارات مسیر JSON معیوب است. این نیازی به تهیه گره های پردازشگر پیام اضافی ندارد، اما باعث اختلال در ترافیک API برای پراکسی های تحت تأثیر می شود.

    • پروکسی‌های آسیب‌دیده را با خط‌مشی‌های تحت‌تأثیر شناسایی کنید و یک تجدیدنظر جدید برای همه پراکسی‌های آسیب‌دیده ایجاد کنید.
    • با اجرای اصلاحات توضیح داده شده در بخش اصلاح در یک ویرایش جدید از پروکسی، اصلاحات لازم را اعمال کنید. هنوز این را مستقر نکنید.
    • برای پراکسی/پراکسی های تاثیرگذار، زمان خرابی را تهیه کنید.
    • همه پردازشگرهای پیام را برای نسخه ابر خصوصی 4.53.01 به Edge ارتقا دهید. توجه داشته باشید که پراکسی های موجود ممکن است در پردازشگرهای پیام که به تازگی ارتقا یافته اند، از کار بیفتند.
    • هنگامی که همه پردازشگرهای پیام برای نسخه ابر خصوصی 4.53.01 به Edge ارتقا یافتند، نسخه پروکسی جدید ایجاد شده را با عبارت JSONPath ثابت اجرا کنید.
    • از سرگیری ترافیک در چنین پراکسی هایی.
  • طراحی مجدد پروکسی قبل از ارتقا

    می‌توانید قبل از ارتقا به Edge برای Private Cloud 4.53.01، خود پراکسی را دوباره طراحی کنید. به‌جای تکیه بر عبارات مسیر JSON خاص، می‌توانید با استفاده از روشی متفاوت به همان نتیجه برسید.

    برای مثال، اگر از یک Extract Variable Policy با مسیر JSON استفاده می‌کنید، می‌توانید خط‌مشی را با یک خط‌مشی جاوا اسکریپت جایگزین کنید که داده‌های مشابه را قبل از ارتقا به نسخه جدیدتر استخراج می‌کند. پس از تکمیل ارتقا، می‌توانید پروکسی خود را به استفاده از مسیرهای JSON با فرمت‌های جدیدتر تغییر دهید.

JavaCallout تغییر می کند

زمینه

Edge برای ابر خصوصی 4.53.00 و قبل از آن حاوی دایرکتوری به نام deprecated ( $APIGEE_ROOT/edge-message-processor/lib/deprecated ) بود که حاوی مجموعه‌ای از کتابخانه‌های JAR بود. این کتابخانه ها برای استفاده در کد جاوا در خط مشی JavaCallout در دسترس بودند و می توانستند توسط کد جاوا سفارشی شما به طور مستقیم یا غیرمستقیم استفاده شوند.

تغییرات

دایرکتوری منسوخ شده اکنون در Edge برای نسخه ابر خصوصی 4.53.01 حذف شده است. در صورتی که کد جاوا شما به چنین کتابخانه‌هایی متکی باشد، پراکسی‌هایی که از چنین فراخوان‌های جاوا استفاده می‌کنند، زمانی که پردازشگرهای پیام به نسخه 4.53.01 ارتقاء می‌یابند، از کار می‌افتند. برای جلوگیری از چنین خرابی‌هایی، قبل از ارتقاء پردازنده‌های پیام به نسخه 4.53.01، مراحل کاهش دهنده زیر را دنبال کنید.

کاهش

  1. خط‌مشی‌های Java-Callout و jar‌های مرتبط را بررسی کنید و شناسایی کنید که آیا هر یک از آنها به کتابخانه‌های موجود در فهرست «منسوخ» پردازنده‌های پیام فعلی شما اشاره می‌کنند یا از آنها استفاده می‌کنند. توجه داشته باشید که فراخوان های جاوا ممکن است از شیشه های بارگذاری شده به عنوان منابع سطح سازمان یا محیط استفاده کنند. این کتابخانه ها را نیز در نظر بگیرید.
  2. هنگامی که چنین کتابخانه های منسوخ را شناسایی کردید، می توانید یکی از روش های زیر را برای کاهش مشکل دنبال کنید.
    • قرار دادن منبع (توصیه می‌شود اگر تعداد کمی از jar/کتابخانه‌های دایرکتوری منسوخ دارید که توسط جاوا-Callout ارجاع داده می‌شوند)
      • شیشه های منسوخ شده شناسایی شده را به عنوان منبع در سطح مورد نظر بارگذاری کنید: ویرایش پروکسی API، محیط یا سازمان.
      • به روز رسانی نرم افزار Apigee را طبق معمول ادامه دهید.
    • قرار دادن دستی (توصیه می شود اگر تعداد زیادی شیشه/کتابخانه دارید که توسط جاوا-Callout ارجاع داده می شود)
      • در هر گره پردازشگر پیام، یک دایرکتوری جدید به نام external-lib در مسیر $APIGEE_ROOT/data/edge-message-processor/ ایجاد کنید.
      • JARهای شناسایی شده را از دایرکتوری منسوخ شده در این فهرست راهنمای خارجی کپی کنید: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • اطمینان حاصل کنید که دایرکتوری و شیشه های زیرین توسط کاربر Apigee قابل خواندن هستند: 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 تحت تأثیر قرار می گیرد. چنین DN هایی از ارتقای موفقیت آمیز نرم افزار 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 - داده های LDAP را استخراج کنید

از دستور 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 بایت / کاراکتر است. برای چنین مواردی، قبل از ادامه ارتقاء Edge for Private Cloud 4.53.01، مراحل کاهش را همانطور که در مرحله 3 توضیح داده شده است، دنبال کنید.

شماره 3 - RDN های طولانی را مدیریت کنید

اگر خروجی از مرحله 2 دریافت شود، نشان دهنده وجود RDN های بیش از 241 بایت/نویسه است و مراحل کاهش زیر را دنبال کنید:

ورودی های LDAP که بیش از 241 بایت هستند را مرور کنید.

  • اگر نام نقش سفارشی، برنامه، محصول API یا موجودیت‌های دیگر است که عامل اصلی طولانی شدن RDN است، به استفاده از یک موجودیت جایگزین با نام کوتاه‌تر بروید.
  • اگر نام سازمان یا نام محیط است که عامل اصلی RDN طولانی است، باید به سازمان یا محیط دیگری با نام کوتاه‌تر مهاجرت کنید.

به تکرار مراحل بالا ادامه دهید تا زمانی که LDAP شما دارای RDN بیشتر از 241 بایت نباشد. هنگامی که به این وضعیت رسیدید، طبق معمول نسخه ابر خصوصی را ارتقا دهید.

تغییرات ارائه دهنده رمزنگاری

زمینه

این تغییر انتقالی از Edge برای 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 برای Private Cloud 4.53.01 مستعد شکست هستند کمک کند.