Thay đổi trong Edge cho Đám mây riêng tư 4.53.01

Tổng quan về những thay đổi

Edge cho Đám mây riêng tư 4.53.01 đã giới thiệu nhiều thay đổi giúp tăng cường trạng thái bảo mật của nền tảng, kết hợp các phiên bản phần mềm/Thư viện mới. Những thay đổi này ảnh hưởng đến:

  • Chính sách xác thực OAS (đặc tả OpenAPI)
  • Các chính sách hỗ trợ truy vấn JSONPath
  • Chính sách gọi Java dựa trên các thư viện không còn dùng nữa
  • OpenLDAP

Phần này mô tả nhiều loại thay đổi được giới thiệu trong phiên bản 4.53.01 có thể làm gián đoạn quy trình làm việc của bạn trong hoặc sau khi nâng cấp. Các phương pháp xác định những khu vực có thể gặp vấn đề và phương pháp giảm thiểu hoặc giải quyết cũng được đề cập.

Chính sách xác thực OAS (đặc tả OpenAPI)

Ngữ cảnh

Chính sách xác thực OAS xác thực các yêu cầu hoặc phản hồi đến dựa trên các quy tắc được xác định trong quy cách OpenAPI 3.0 (JSON hoặc YAML). Edge for Private Cloud 4.53.01 mang đến những điểm cải tiến cho chính sách OAS (đặc tả OpenAPI), tập trung vào việc xác thực chặt chẽ và chính xác hơn đối với nội dung phản hồi API.

Các thay đổi

Edge for Private Cloud 4.53.01 có 2 thay đổi quan trọng về cách chính sách OAS xác thực các phản hồi API, đảm bảo phù hợp hơn với quy cách OpenAPI của bạn:

  • Tình huống 1:
    • Hành vi trước đây: Nếu quy cách OpenAPI của bạn yêu cầu một phần nội dung phản hồi nhưng phản hồi thực tế từ chính sách mục tiêu hoặc chính sách cấp trên không có phần nội dung phản hồi , thì chính sách sẽ không gắn cờ đây là lỗi xác thực.
    • Hành vi hiện tại: Giờ đây, chính sách sẽ trả về chính xác một lỗi xác thực (ví dụ: defines a response schema but no response body found) trong trường hợp này, cho biết có sự không khớp giữa phản hồi dự kiến và phản hồi thực tế.
  • Tình huống 2:
    • Hành vi trước đây: Nếu quy cách OpenAPI của bạn nêu rõ rằng không có nội dung phản hồi nào được mong đợi, nhưng phản hồi thực tế từ chính sách mục tiêu hoặc chính sách nguồn bao gồm một nội dung, thì chính sách sẽ không dẫn đến lỗi.
    • Hành vi hiện tại: Giờ đây, chính sách này sẽ dẫn đến lỗi (ví dụ: No response body is expected but one was found) trong trường hợp này, đảm bảo rằng các phản hồi tuân thủ nghiêm ngặt lược đồ đã chỉ định.

Giải pháp giảm thiểu

Xác định mọi proxy hoặc luồng dùng chung mà chính sách xác thực OAS được định cấu hình với thẻ Source được đặt thành response hoặc những proxy/luồng xác thực phản hồi từ bất kỳ chính sách nào khác tạo ra phản hồi.

Sau khi xác định được một luồng proxy/luồng dùng chung, hãy đảm bảo có sự liên kết giữa Phản hồi và Quy cách OAS. Phản hồi phải hoàn toàn phù hợp với quy cách OpenAPI của bạn về sự hiện diện hoặc không có nội dung phản hồi. Bạn có thể sử dụng tính năng theo dõi Apigee tiêu chuẩn để xem xét các mẫu lưu lượng truy cập. Nếu mục tiêu trả về phản hồi không liên tục, hãy sử dụng các chính sách khác để xác thực mục tiêu đó trước chính sách OAS

  • Nếu tệp đặc tả OAS của bạn xác định một nội dung phản hồi, thì phản hồi từ chính sách mục tiêu hoặc chính sách nguồn phải luôn cung cấp một nội dung.
  • Nếu tệp đặc tả OAS không xác định nội dung phản hồi, thì chính sách mục tiêu hoặc chính sách nguồn không được gửi nội dung phản hồi.

Cập nhật chính sách xác thực OAS hoặc hành vi mục tiêu của bạn nếu cần trước khi bạn thử nâng cấp lên Private Cloud 4.53.01. Trước tiên, bạn nên xác thực những quy trình làm việc đã xác định như vậy trong môi trường không phải môi trường sản xuất để giảm thiểu nguy cơ gián đoạn trong quá trình nâng cấp cụm sản xuất.

Đường dẫn JSON

Ngữ cảnh

Edge cho Đám mây riêng tư 4.53.01 đã giới thiệu những thay đổi về cách sử dụng biểu thức đường dẫn JSON trong nhiều chính sách. Bạn có thể dùng biểu thức JSONPath trong các chính sách như chính sách ExtractVariable, chính sách RegularExpressionProtection, Data masking để phân tích cú pháp nội dung JSON hoặc lưu trữ các giá trị trong các biến. Bạn cũng có thể sử dụng biểu thức JSONPath trong mẫu thông báo chung để thay thế các biến bằng giá trị một cách linh động trong quá trình thực thi proxy. Các biểu thức và định dạng JSONPath mới tuân theo các tiêu chuẩn biểu thức JSON mới nhất.

Các thay đổi

Bạn cần xem xét các chính sách hiện có của API proxy/luồng dùng chung để sử dụng các biểu thức JSONPath. Điều này bao gồm nhưng không giới hạn ở chính sách Trích xuất biến, chính sách Bảo vệ bằng biểu thức chính quy hoặc bất kỳ chính sách nào có Mẫu thông báo bằng JSONPath.

Đầu vào JSON bên dưới được dùng để giải thích các thay đổi:

{
  "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. Thay đổi về hành vi của ký tự đại diện [*] JSONPath đối với các giá trị đối tượng

    Hành vi của ký tự đại diện [*] đã thay đổi khi được dùng để truy cập vào tất cả các giá trị tức thì của một đối tượng JSON. Trước đây, $.object[*] sẽ trả về các giá trị tức thì được bao bọc trong một đối tượng JSON duy nhất. Với các thư viện đã cập nhật, đầu ra hiện là một mảng chứa các giá trị này.

    Ví dụ: $.store[*]:

    Hành vi trước đây: 
    {
  "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"}
  ]
}
    Hành vi hiện tại: 
    [
  [
    {"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"}]
  }
]
    Hành động:

    Thay đổi biểu thức JSONPath để chỉ nhắm đến đối tượng mẹ (ví dụ: $.store) nhằm nhắm đến trực tiếp các mục đã được truy xuất trước đó.

  2. Dấu chấm ở cuối JSONPath (.) trong đường dẫn gây ra lỗi

    Có quy trình xác thực nghiêm ngặt hơn đối với các biểu thức JSONPath. Trước đây, các đường dẫn kết thúc bằng một dấu chấm không hợp lệ (ví dụ: $.path.to.element.) sẽ bị bỏ qua một cách âm thầm và truy vấn vẫn trả về kết quả nếu phân đoạn đường dẫn hợp lệ trước đó khớp. Với phiên bản mới, những đường dẫn không đúng định dạng như vậy hiện được xác định chính xác là không hợp lệ và sẽ dẫn đến lỗi.

    Ví dụ: $.store.book.

    Hành vi trước đây: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
    Hành vi hiện tại: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    Mọi chính sách hiện có sử dụng biểu thức JSONPath có dấu chấm thừa ở cuối sẽ gặp lỗi InvalidPathException.

    Hành động:

    Xoá dấu chấm ở cuối khỏi mọi biểu thức JSONPath kết thúc bằng dấu chấm. Ví dụ: thay đổi $.store.book. thành $.store.book.

  3. Thay đổi cấu trúc đầu ra (..) của JSONPath recursive descent

    Có những thay đổi về cách trả về kết quả khi bạn dùng toán tử (..) (phân tích cú pháp từ trên xuống) để xác định vị trí của tất cả các lần xuất hiện của một phần tử được đặt tên. Trước đây, tất cả các phần tử được tìm thấy đều được làm phẳng thành một danh sách duy nhất. Các thư viện đã cập nhật hiện trả về một danh sách các danh sách, giữ nguyên cấu trúc nhóm ban đầu nơi tìm thấy các phần tử, thay vì một danh sách phẳng duy nhất.

    Ví dụ: $..book

    Hành vi trước đây: 
    [
  {"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"}
]
    Hành vi hiện tại: 
    [
  [
    {"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"}
  ]
]
    Hành động:

    Cập nhật logic xử lý hạ nguồn để tính đến cấu trúc mảng lồng nhau mới. Bạn có thể cần lặp lại thông qua JSONArray bên ngoài, sau đó lặp lại thông qua từng JSONArray bên trong để truy cập vào các phần tử riêng lẻ.

  4. Chỉ mục JSONPath sau khi chọn nhiều mục hoặc bộ lọc trả về mảng trống

    Có một thay đổi về hành vi khi một chỉ mục (ví dụ: [0]) được áp dụng ngay sau một bộ chọn nhiều mục (như [*]) hoặc một bộ lọc ([?(condition)]). Trước đây, những biểu thức như vậy sẽ cố gắng chọn mục tại chỉ mục được chỉ định từ kết quả kết hợp. Với phiên bản mới, các biểu thức này hiện sẽ trả về một mảng trống ([]).

    Ví dụ: $.store.book[*][0]

    Hành vi trước đây: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    Hành vi hiện tại: 
    []
    Hành động:

    Nếu cần lọc rồi lấy một mục cụ thể từ tập hợp đã lọc, hãy xử lý mảng đã lọc do JSONPath trả về, chẳng hạn như $..book[?(@.category == 'fiction')] rồi lấy [0] từ kết quả trước đó.

  5. Thay đổi đầu ra của thao tác phân đoạn mảng âm JSONPath

    Phiên bản mới đã sửa đổi hành vi của việc phân đoạn mảng âm (ví dụ: [-2:], [-1:]). Trước đây, khi áp dụng một lát âm cho một mảng (cho biết các phần tử từ cuối mảng), phiên bản cũ sẽ trả về không chính xác chỉ một mục từ lát đó. Giờ đây, phiên bản mới sẽ trả về chính xác một danh sách (mảng) chứa tất cả các phần tử nằm trong phạm vi phủ định được chỉ định.

    Ví dụ: $.store.book[-2:]

    Hành vi trước đây: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    Hành vi hiện tại: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    Hành động:

    Giờ đây, bạn phải cập nhật logic xử lý hạ nguồn để lặp lại mảng JSON được trả về nhằm nhận được đầu ra mong muốn.

  6. JSONPath có dấu chấm trước nghiêm ngặt hơn

    Có quy định nghiêm ngặt hơn về việc thực thi cú pháp cho các phần tử được truy cập trực tiếp từ thư mục gốc. Khi các phần tử được truy cập trực tiếp từ thư mục gốc mà không có dấu chấm ở trước (ví dụ: $propertyelement), cú pháp như vậy hiện được coi là lỗi và sẽ ngăn chặn việc triển khai proxy.

    Ví dụ: $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"}
  ]
}

    Hành vi hiện tại:

    Proxy will fail to deploy.

    Hành động:

    Thay đổi JSONPath để thêm dấu chấm: $.propertyName (ví dụ: $.store). Thao tác này sẽ nhắm đến và truy xuất giá trị một cách chính xác.

  7. Biểu thức JSONPath linh hoạt

    Hãy chú ý đến những chính sách mà biểu thức JSONPath được cung cấp bởi một biến (ví dụ: {myJsonPathVariable} hoặc {dynamicPath}). Giá trị của các biến này cũng phải được kiểm tra dựa trên những thay đổi tiềm ẩn về hành vi được nêu ở trên.

Giải pháp giảm thiểu

Để giảm thiểu, bạn cần có một chiến lược toàn diện. Quá trình này bao gồm việc quyết định đường dẫn cập nhật phù hợp và áp dụng bản sửa lỗi cần thiết cho các biểu thức JSONPath bị hỏng.

Chọn Phương thức nâng cấp phù hợp nhất với bạn:

  • Di chuyển mà không ngừng hoạt động

    Chiến lược này liên quan đến việc mua sắm một hoặc nhiều môi trường mới để bạn có thể kết nối các nút xử lý thông báo riêng biệt với môi trường đó. Bạn có thể đặt các nút xử lý thông báo như vậy để cài đặt 4.53.01 và có các proxy bằng biểu thức JSONPath hiện đại. Bạn có thể sử dụng các giá trị này trong quá trình nâng cấp và có thể ngừng sử dụng sau khi quá trình nâng cấp hoàn tất. Chiến lược này diễn ra liền mạch nhưng cần tạm thời mua thêm các nút bộ xử lý thông báo để hỗ trợ quá trình nâng cấp diễn ra suôn sẻ. Thông tin chi tiết ở bên dưới:

    • Tạo một môi trường mới và thêm các nút trình xử lý thông báo mới có phiên bản 4.53.01 vào môi trường mới này.
    • Tải gói proxy cho các proxy bị ảnh hưởng lên môi trường mới và áp dụng các bản sửa lỗi cần thiết như được giải thích trong phần khắc phục, đồng thời triển khai gói proxy đã cập nhật cho môi trường mới.
    • Chuyển hướng lưu lượng truy cập đến môi trường mới và huỷ triển khai các proxy bị ảnh hưởng khỏi môi trường cũ.
    • Nâng cấp các nút bộ xử lý thông báo gốc lên phiên bản 4.53.01. Triển khai các proxy có bản sửa lỗi cho JSONPath trong môi trường ban đầu.
    • Chuyển lưu lượng truy cập trở lại môi trường cũ, hiện có các trình xử lý thông báo trên 4.53.01 và proxy được hiện đại hoá cho các biểu thức jsonpath mới.
    • Xoá và ngừng hoạt động môi trường mới cũng như các nút liên kết.
  • Thời gian ngừng hoạt động và nâng cấp

    Chiến lược này liên quan đến việc tìm kiếm thời gian ngừng hoạt động cho API Proxy bằng cách sử dụng các biểu thức JSON Path bị lỗi. Điều này không đòi hỏi việc mua thêm các nút xử lý thông báo, nhưng gây ra sự gián đoạn cho lưu lượng truy cập API đối với các proxy bị ảnh hưởng.

    • Xác định các proxy bị ảnh hưởng cùng với các chính sách bị ảnh hưởng và tạo một bản sửa đổi mới cho tất cả các proxy bị ảnh hưởng.
    • Áp dụng các biện pháp khắc phục cần thiết bằng cách Triển khai các biện pháp khắc phục được giải thích trong phần khắc phục trong một bản sửa đổi mới của proxy. Đừng triển khai nội dung này vội.
    • Mua thời gian ngừng hoạt động cho (các) proxy bị ảnh hưởng.
    • Nâng cấp tất cả các trình xử lý thông báo lên Edge cho phiên bản đám mây riêng tư 4.53.01. Xin lưu ý rằng các proxy hiện có có thể gặp lỗi trên các trình xử lý thông báo mới nâng cấp.
    • Sau khi nâng cấp tất cả trình xử lý thông báo lên Edge cho phiên bản đám mây riêng tư 4.53.01 , hãy triển khai bản sửa đổi proxy mới tạo bằng biểu thức JSONPath cố định.
    • Tiếp tục lưu lượng truy cập trên các proxy đó.
  • Thiết kế lại Proxy trước khi nâng cấp

    Bạn có thể thiết kế lại chính proxy này trước khi nâng cấp lên Edge for Private Cloud 4.53.01. Thay vì dựa vào các biểu thức đường dẫn JSON cụ thể, bạn có thể nhận được kết quả tương tự bằng cách sử dụng một phương thức khác.

    Ví dụ: nếu đang sử dụng Chính sách trích xuất biến bằng đường dẫn JSON, bạn có thể thay thế chính sách đó bằng một chính sách Javascript trích xuất dữ liệu tương tự trước khi nâng cấp lên phiên bản mới hơn. Sau khi quá trình nâng cấp hoàn tất, bạn có thể thay đổi lại proxy để sử dụng JSON Path với các định dạng mới hơn.

Các thay đổi về JavaCallout

Ngữ cảnh

Edge cho đám mây riêng tư 4.53.00 trở về trước từng chứa một thư mục có tên là deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) chứa một loạt thư viện JAR. Bạn có thể sử dụng các thư viện này trong mã Java trong chính sách JavaCallout và có thể đã được mã Java tuỳ chỉnh của bạn sử dụng trực tiếp hoặc gián tiếp.

Các thay đổi

Thư mục không dùng nữa hiện đã bị xoá trong Edge cho phiên bản đám mây riêng tư 4.53.01. Trong trường hợp mã java của bạn dựa vào các thư viện như vậy, các proxy sử dụng lệnh gọi java như vậy sẽ không thành công khi bộ xử lý thông báo được nâng cấp lên phiên bản 4.53.01. Để tránh những lỗi như vậy, hãy làm theo các bước giảm thiểu dưới đây trước khi nâng cấp bộ xử lý thông báo lên phiên bản 4.53.01.

Giải pháp giảm thiểu

  1. Xem xét các chính sách Java-Callout và các tệp jar liên kết, đồng thời xác định xem có tệp nào tham chiếu hoặc sử dụng bất kỳ thư viện nào có trong thư mục "deprecated" (không dùng nữa) của trình xử lý thông báo hiện tại hay không. Xin lưu ý rằng lệnh gọi Java có thể đang sử dụng các tệp jar được tải lên dưới dạng tài nguyên ở cấp tổ chức hoặc môi trường. Hãy cân nhắc cả những thư viện này.
  2. Sau khi xác định được những thư viện không dùng nữa như vậy , bạn có thể làm theo một trong các phương pháp bên dưới để giảm thiểu vấn đề.
    • Vị trí tài nguyên (Nên dùng nếu bạn có một số ít tệp jar / thư viện trong thư mục không dùng nữa mà các tệp jar Java-Callout đang tham chiếu đến)
      • Tải các tệp jar không dùng nữa đã xác định lên dưới dạng một tài nguyên ở cấp độ mong muốn: bản sửa đổi proxy API, môi trường hoặc tổ chức.
      • Tiến hành nâng cấp phần mềm Apigee như bình thường.
    • Vị trí đặt thủ công (Bạn nên dùng nếu có nhiều tệp jar / thư viện mà tệp jar Java-Callout đang tham chiếu)
      • Trên mỗi nút của trình xử lý thông báo, hãy tạo một thư mục mới có tên external-lib tại đường dẫn $APIGEE_ROOT/data/edge-message-processor/.
      • Sao chép các tệp JAR đã xác định vào thư mục external-lib này từ thư mục không dùng nữa: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • Đảm bảo người dùng Apigee có thể đọc thư mục và các tệp jar cơ bản: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Tiến hành nâng cấp phần mềm Apigee như bình thường.

Thay đổi OpenLDAP

Ngữ cảnh

Bạn có thể dùng OpenLDAP trong Edge Private Cloud cho cả hoạt động xác thực và uỷ quyền. Trong Edge cho Private Cloud 4.53.01, phần mềm OpenLDAP do Apigee cung cấp đã được nâng cấp từ phiên bản 2.4 lên 2.6.

Các thay đổi

Trong OpenLDAP 2.6, tên phân biệt tương đối (RDN) bị giới hạn ở khoảng 241 byte/ký tự. Đây là hạn mức tối đa bắt buộc và không thể sửa đổi.

Tác động
  • Lỗi sao chép hoặc nhập xảy ra đối với các mục có RDN quá lớn.
  • Nếu bạn cố gắng tạo các thực thể như tổ chức, môi trường, vai trò tuỳ chỉnh, quyền, v.v., thì có thể bạn sẽ gặp thông báo lỗi: "message": "[LDAP: error code 80 - Other]".
  • Mọi DN dài hơn 241 byte trong LDAP của Apigee đều bị ảnh hưởng. Những DN như vậy sẽ ngăn chặn việc nâng cấp thành công phần mềm Apigee OpenLDAP và bạn sẽ phải làm theo các chiến lược giảm thiểu cho những mục như vậy trước khi có thể tiếp tục nâng cấp.

Nhìn chung, trong LDAP của Apigee, các DN dài có liên quan đến quyền vì chúng được tạo bằng cách nối nhiều thực thể. Những mục nhập quyền như vậy đặc biệt dễ gặp phải vấn đề khi nâng cấp.

Ví dụ: 

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

Thông thường, bạn sẽ có tên tổ chức, môi trường và vai trò có độ dài sao cho RDN trong LDAP nhỏ hơn 241 byte.

Giải pháp giảm thiểu

Trước khi nâng cấp lên phiên bản 4.53.01:

Các bước sau đây sẽ giúp xác minh sự hiện diện của các RDN dài trong cụm LDAP 2.4 hiện có.

#1 – Trích xuất dữ liệu LDAP

Sử dụng lệnh ldapsearch để tìm tên phân biệt (dn) và chuyển hướng đầu ra đến một tệp: 

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

Đảm bảo rằng tệp DN.ldif ở trên có các mục LDAP.

#2 – Xác định RDN dài

Tìm RDN vượt quá 241 byte/ký tự trong tệp DN.ldif ở trên:

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)

Nếu lệnh trên không tạo ra đầu ra nào, thì không có RDN nào trong chế độ thiết lập LDAP hiện tại vượt quá 241 byte/ký tự. Bạn có thể tiến hành nâng cấp như bình thường mà không cần lo ngại.

Nếu lệnh trên tạo ra một đầu ra, tức là có các RDN vượt quá 241 byte/ký tự. Đối với những mục như vậy, hãy làm theo các bước giảm thiểu như mô tả trong bước 3 trước khi tiến hành nâng cấp Edge cho Đám mây riêng 4.53.01.

#3 – Xử lý các RDN dài

Nếu bạn nhận được đầu ra từ bước 2, điều này cho thấy có các RDN vượt quá 241 byte/ký tự và hãy làm theo các bước giảm thiểu bên dưới:

Xem lại các mục LDAP vượt quá 241 byte.

  • Nếu đó là tên vai trò tuỳ chỉnh, Ứng dụng, Sản phẩm API hoặc các thực thể khác là yếu tố chính khiến RDN dài, hãy di chuyển sang sử dụng một thực thể thay thế có tên ngắn hơn.
  • Nếu tên tổ chức hoặc tên môi trường là yếu tố chính khiến RDN dài, bạn sẽ phải di chuyển sang một tổ chức hoặc môi trường khác có tên ngắn hơn.

Tiếp tục lặp lại các bước trên cho đến khi LDAP của bạn không còn RDN nào dài hơn 241 byte. Khi bạn đạt đến trạng thái này, hãy tiến hành nâng cấp phiên bản đám mây riêng như bình thường.

Thay đổi về Nhà cung cấp mật mã

Ngữ cảnh

Thay đổi này được chuyển từ Edge cho Đám mây riêng tư 4.53.00. Trong Edge for Private Cloud 4.53.00, nhà cung cấp dịch vụ mật mã nội bộ đã được cập nhật từ Bouncy Castle (BC) lên Bouncy Castle FIPS (BCFIPS) để bật tính năng hỗ trợ FIPS.

Các thay đổi

Nếu các chính sách JavaCallout dựa vào việc sử dụng trình cung cấp BC ban đầu, đặc biệt là khi sử dụng chức năng bảo mật đã được tăng cường trong trình cung cấp BCFIPS (ví dụ: sử dụng một cặp khoá chung cho cả hoạt động mã hoá và ký), thì bạn cần phải hiện đại hoá các chính sách JavaCallout đó. Các chính sách JavaCallout cố gắng tải trình cung cấp mật mã Bouncy Castle bằng tên BC có thể không thành công vì trình cung cấp mặc định đã thay đổi. Sau đó, những chính sách như vậy sử dụng nhà cung cấp BC có thể bị gián đoạn. Mọi chế độ triển khai tuỳ chỉnh dựa vào trình cung cấp BC cũ sẽ không còn truy cập được nữa và cần được xem xét cũng như triển khai lại.

Giải pháp giảm thiểu

Giải pháp khắc phục được đề xuất là sử dụng trình cung cấp BCFIPS. Những cách triển khai JavaCallout tuỳ chỉnh dựa vào trình cung cấp cũ sẽ cần được xem xét và triển khai lại bằng trình cung cấp Bouncy Castle FIPS. Bạn có thể truy cập vào trình cung cấp này bằng cách sử dụng chuỗi "BCFIPS".

Công cụ phát hiện thay đổi tự động

Chúng tôi dự định sẽ sớm phát hành một công cụ phát hiện thay đổi. Công cụ này có thể quét và xác định các proxy API, luồng dùng chung, tài nguyên và RDN LDAP có thể chịu ảnh hưởng của nhiều thay đổi được mô tả trong bài viết này. Công cụ này sẽ giúp xác định nhiều thực thể dễ gặp lỗi trong hoặc sau khi nâng cấp lên Edge cho Đám mây riêng tư 4.53.01.