Perubahan di Edge untuk Private Cloud 4.53.01

Ringkasan perubahan

Edge for Private Cloud 4.53.01 telah memperkenalkan beberapa perubahan yang meningkatkan postur keamanan platform, dengan menggabungkan versi software/Library yang telah diupdate. Perubahan ini memengaruhi:

  • Kebijakan validasi OAS (spesifikasi OpenAPI)
  • Kebijakan yang mendukung kueri JSONPath
  • Kebijakan panggilan Java yang mengandalkan library yang tidak digunakan lagi
  • OpenLDAP

Bagian ini menjelaskan berbagai jenis perubahan yang diperkenalkan dalam versi 4.53.01 yang dapat mengganggu alur kerja Anda selama atau setelah upgrade. Metode untuk mengidentifikasi potensi area masalah dan metodologi mitigasi atau solusi juga dibahas.

Kebijakan validasi OAS (spesifikasi OpenAPI)

Konteks

Kebijakan validasi OAS memvalidasi permintaan atau respons masuk terhadap aturan yang ditentukan dalam spesifikasi OpenAPI 3.0 (JSON atau YAML). Edge untuk Private Cloud 4.53.01 memberikan peningkatan pada kebijakan OAS (spesifikasi OpenAPI), yang berfokus pada validasi isi respons API yang lebih ketat dan akurat.

Perubahan

Edge untuk Private Cloud 4.53.01 memperkenalkan dua perubahan penting dalam cara kebijakan OAS memvalidasi respons API, sehingga memastikan keselarasan yang lebih dekat dengan spesifikasi OpenAPI Anda:

  • Skenario 1:
    • Perilaku sebelumnya: Jika spesifikasi OpenAPI Anda memerlukan isi respons, tetapi respons sebenarnya dari target atau kebijakan upstream tidak menyertakannya, kebijakan tidak akan menandai hal ini sebagai error validasi.
    • Perilaku saat ini: Kebijakan kini akan menampilkan error validasi dengan benar (contoh: defines a response schema but no response body found) dalam skenario ini, yang menunjukkan ketidakcocokan antara respons yang diharapkan dan respons sebenarnya.
  • Skenario 2:
    • Perilaku sebelumnya: Jika spesifikasi OpenAPI Anda secara eksplisit menyatakan bahwa tidak ada isi respons yang diharapkan, tetapi respons sebenarnya dari target atau kebijakan upstream menyertakan isi, kebijakan tidak akan menyebabkan kegagalan.
    • Perilaku saat ini: Kebijakan kini akan menghasilkan kegagalan (contoh: No response body is expected but one was found) dalam skenario ini, sehingga memastikan bahwa respons mematuhi skema yang ditentukan secara ketat.

Mitigasi

Identifikasi proxy atau alur bersama tempat kebijakan validasi OAS dikonfigurasi dengan tag Source yang ditetapkan ke response atau yang memvalidasi respons dari kebijakan lain yang menghasilkan respons.

Setelah proxy/alur bersama diidentifikasi, pastikan Penyelarasan antara Respons dan Spesifikasi OAS. Respons harus benar-benar sesuai dengan spesifikasi OpenAPI Anda terkait ada atau tidaknya isi respons. Anda dapat menggunakan rekaman aktivitas Apigee standar untuk meninjau pola traffic. Jika target menampilkan respons secara berselang-seling, gunakan kebijakan lain untuk memvalidasinya sebelum kebijakan OAS

  • Jika file spesifikasi OAS Anda menentukan isi respons, respons dari target atau kebijakan upstream harus selalu menyediakannya.
  • Jika file spesifikasi OAS Anda tidak menentukan isi respons, kebijakan target atau upstream tidak boleh mengirimkannya.

Perbarui kebijakan validasi OAS atau perilaku target Anda sesuai kebutuhan sebelum Anda mencoba upgrade ke Private Cloud 4.53.01. Anda harus memvalidasi alur kerja yang diidentifikasi tersebut di lingkungan non-produksi terlebih dahulu untuk meminimalkan risiko gangguan selama upgrade cluster produksi.

Jalur JSON

Konteks

Edge untuk Private Cloud 4.53.01 telah memperkenalkan perubahan pada cara penggunaan ekspresi jalur JSON dalam berbagai kebijakan. Ekspresi JSONPath dapat digunakan dalam kebijakan seperti kebijakan ExtractVariable, kebijakan RegularExpressionProtection, Penyamaran data untuk mengurai konten JSON atau menyimpan nilai dalam variabel. Ekspresi JSONPath juga dapat digunakan dalam pembuatan template pesan umum untuk mengganti variabel dengan nilai secara dinamis selama eksekusi proxy. Ekspresi dan format JSONPath baru mengikuti standar ekspresi JSON terbaru.

Perubahan

Penting untuk meninjau proxy API/alur bersama yang ada untuk kebijakan yang menggunakan ekspresi JSONPath. Hal ini mencakup, tetapi tidak terbatas pada, kebijakan Extract Variables, kebijakan Regular Expression Protection, atau kebijakan apa pun dengan Message Template yang menggunakan JSONPath.

Input JSON di bawah digunakan untuk menjelaskan perubahan:

{
  "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. Perubahan perilaku karakter pengganti JSONPath [*] untuk nilai objek

    Perilaku karakter pengganti [*] telah diubah saat digunakan untuk mengakses semua nilai langsung dari objek JSON. Sebelumnya, $.object[*] akan menampilkan nilai langsung yang digabungkan dalam satu objek JSON. Dengan library yang diperbarui, outputnya sekarang berupa array yang berisi nilai-nilai ini.

    Misalnya, $.store[*]:

    Perilaku sebelumnya: 
    {
  "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"}
  ]
}
    Perilaku saat ini: 
    [
  [
    {"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"}]
  }
]
    Tindakan:

    Ubah ekspresi JSONPath untuk menargetkan objek induk (contoh: $.store) guna menargetkan item yang diambil sebelumnya secara langsung.

  2. Titik di akhir JSONPath (.) dalam jalur menyebabkan error

    Ada validasi yang lebih ketat untuk ekspresi JSONPath. Sebelumnya, jalur yang diakhiri dengan titik di belakang yang tidak valid (contoh: $.path.to.element.) akan diabaikan tanpa pemberitahuan, dan kueri tetap menampilkan hasil jika segmen jalur valid sebelumnya cocok. Dengan versi baru, jalur yang salah format tersebut kini diidentifikasi dengan benar sebagai tidak valid dan akan menghasilkan error.

    Contoh, $.store.book.

    Perilaku sebelumnya: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
    Perilaku saat ini: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    Semua kebijakan yang ada yang menggunakan ekspresi JSONPath dengan titik di akhir yang tidak disengaja kini akan gagal dengan InvalidPathException.

    Tindakan:

    Hapus titik di bagian akhir dari ekspresi JSONPath yang diakhiri dengan titik. Misalnya, ubah $.store.book. menjadi $.store.book.

  3. Perubahan struktur output (..) turunan rekursif JSONPath

    Ada perubahan pada cara hasil ditampilkan saat menggunakan operator (..) (penurunan rekursif) untuk menemukan semua kemunculan elemen bernama. Sebelumnya, semua elemen yang ditemukan diratakan ke dalam satu daftar. Library yang diperbarui kini menampilkan daftar daftar, yang mempertahankan struktur pengelompokan asli tempat elemen ditemukan, bukan daftar datar tunggal.

    Contoh, $..book

    Perilaku sebelumnya: 
    [
  {"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"}
]
    Perilaku saat ini: 
    [
  [
    {"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"}
  ]
]
    Tindakan:

    Perbarui logika pemrosesan hilir Anda untuk memperhitungkan struktur array bertingkat yang baru. Anda mungkin perlu melakukan iterasi melalui JSONArray luar, lalu melakukan iterasi melalui setiap JSONArray dalam untuk mengakses setiap elemen.

  4. Pengindeksan JSONPath setelah pemilihan atau pemfilteran multi-item menampilkan array kosong

    Ada perubahan perilaku saat indeks (contoh: [0]) diterapkan segera setelah pemilih multi-item (seperti [*]) atau filter ([?(condition)]). Sebelumnya, ekspresi tersebut akan mencoba memilih item pada indeks yang ditentukan dari hasil gabungan. Dengan versi baru, ekspresi ini kini akan menampilkan array kosong ([]).

    Contoh, $.store.book[*][0]

    Perilaku sebelumnya: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    Perilaku saat ini: 
    []
    Tindakan:

    Jika ada kebutuhan untuk memfilter, lalu mendapatkan item tertentu dari kumpulan yang difilter, proses array yang difilter yang ditampilkan oleh JSONPath, misalnya, $..book[?(@.category == 'fiction')], lalu ambil [0] dari hasil sebelumnya.

  5. Perubahan output pengirisan array negatif JSONPath

    Versi baru telah mengubah perilaku pemotongan array negatif (contoh: [-2:], [-1:]). Sebelumnya, saat menerapkan pemotongan negatif ke array (menunjukkan elemen dari akhir array), versi lama akan salah menampilkan hanya satu item dari pemotongan tersebut. Versi baru kini menampilkan daftar (array) dengan benar yang berisi semua elemen yang berada dalam rentang negatif yang ditentukan.

    Misalnya $.store.book[-2:]

    Perilaku sebelumnya: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    Perilaku saat ini: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    Tindakan:

    Logika pemrosesan hilir kini harus diperbarui untuk melakukan iterasi melalui array JSON yang ditampilkan guna mendapatkan output yang diinginkan.

  6. Titik sebelumnya yang lebih ketat JSONPath

    Ada penerapan sintaksis yang lebih ketat untuk elemen yang diakses langsung dari root. Jika elemen diakses langsung dari root tanpa titik sebelumnya (contoh: $propertyelement), sintaksis tersebut kini dianggap sebagai error dan akan mencegah deployment proxy.

    Misalnya $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"}
  ]
}

    Perilaku saat ini:

    Proxy will fail to deploy.

    Tindakan:

    Ubah JSONPath Anda untuk menyertakan titik: $.propertyName (contoh: $.store). Tindakan ini akan menargetkan dan mengambil nilai dengan benar.

  7. Ekspresi JSONPath dinamis

    Perhatikan baik-baik kebijakan yang ekspresi JSONPath-nya sendiri disediakan oleh variabel (contoh: {myJsonPathVariable} atau {dynamicPath}). Nilai variabel ini juga harus diperiksa terhadap potensi perubahan perilaku yang diuraikan di atas.

Mitigasi

Untuk memitigasi, diperlukan strategi yang komprehensif. Proses ini melibatkan penentuan jalur update yang sesuai dan penerapan perbaikan yang diperlukan untuk ekspresi JSONPath yang rusak.

Pilih Metode Jalur Upgrade yang paling sesuai untuk Anda:

  • Migrasi Tanpa Periode Nonaktif

    Strategi ini melibatkan pengadaan satu atau beberapa lingkungan baru sehingga Anda dapat menghubungkan node pemroses pesan yang terpisah ke lingkungan tersebut. Node pemroses pesan tersebut dapat disetel untuk menginstal 4.53.01 dan memiliki proxy dengan ekspresi JSONPath modern. Ini dapat digunakan selama upgrade dan dapat dihentikan setelah upgrade selesai. Strategi ini lancar, tetapi melibatkan pengadaan sementara node pemroses pesan tambahan untuk mendukung upgrade yang lancar. Berikut detailnya:

    • Buat lingkungan baru dan tambahkan node pemroses pesan baru versi 4.53.01 ke lingkungan baru ini.
    • Upload paket proxy untuk proxy yang terpengaruh ke lingkungan baru dan terapkan perbaikan yang diperlukan yang dijelaskan di bagian perbaikan & deploy paket proxy yang diperbarui ke lingkungan baru.
    • Alihkan traffic ke lingkungan baru dan batalkan deployment proxy yang terpengaruh dari lingkungan lama.
    • Upgrade node pemroses pesan asli ke 4.53.01. Deploy proxy yang memiliki perbaikan untuk JSONPath di lingkungan asli.
    • Alihkan traffic kembali ke lingkungan lama, yang kini memiliki pemroses pesan di 4.53.01 dan proxy yang dimodernisasi untuk ekspresi jsonpath baru.
    • Hapus dan nonaktifkan lingkungan baru dan node terkait.
  • Periode nonaktif dan upgrade

    Strategi ini melibatkan pengadaan periode nonaktif untuk Proxy API menggunakan ekspresi JSON Path yang salah. Hal ini tidak memerlukan pengadaan node pemroses pesan tambahan, tetapi menyebabkan gangguan pada traffic API untuk proxy yang terpengaruh.

    • Identifikasi proxy yang terpengaruh dengan kebijakan yang terpengaruh dan buat revisi baru untuk semua proxy yang terpengaruh.
    • Terapkan perbaikan yang diperlukan dengan Menerapkan perbaikan yang dijelaskan di bagian perbaikan dalam revisi baru proxy. Jangan terapkan ini dulu.
    • Dapatkan waktu nonaktif untuk proxy yang terpengaruh.
    • Upgrade semua pemroses pesan ke Edge untuk Private Cloud versi 4.53.01. Perhatikan bahwa proxy yang ada mungkin gagal di pemroses pesan yang baru diupgrade.
    • Setelah semua pemroses pesan diupgrade ke Edge untuk versi cloud pribadi 4.53.01 , deploy revisi proxy yang baru dibuat dengan ekspresi JSONPath yang diperbaiki.
    • Melanjutkan lalu lintas di proxy tersebut.
  • Mendesain ulang Proxy sebelum upgrade

    Anda dapat mendesain ulang proxy itu sendiri sebelum mengupgrade ke Edge untuk Private Cloud 4.53.01. Daripada mengandalkan ekspresi jalur JSON tertentu, Anda bisa mendapatkan hasil yang sama dengan menggunakan metode lain.

    Misalnya, jika Anda menggunakan Kebijakan Ekstrak Variabel dengan jalur JSON, Anda dapat mengganti kebijakan tersebut dengan kebijakan Javascript yang mengekstrak data serupa sebelum mengupgrade ke versi yang lebih baru. Setelah upgrade selesai, Anda dapat mengubah proxy kembali menggunakan Jalur JSON dengan format yang lebih baru.

Perubahan JavaCallout

Konteks

Edge untuk private cloud 4.53.00 dan yang lebih lama dulu berisi direktori bernama deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) yang berisi banyak library JAR. Library ini tersedia untuk digunakan dalam kode Java di kebijakan JavaCallout dan dapat digunakan oleh kode Java kustom Anda secara langsung atau tidak langsung.

Perubahan

Direktori tidak digunakan lagi kini dihapus di Edge untuk Private Cloud versi 4.53.01. Jika kode Java Anda mengandalkan library tersebut, proxy yang menggunakan panggilan Java tersebut akan gagal saat pemroses pesan diupgrade ke versi 4.53.01. Untuk menghindari kegagalan tersebut, ikuti langkah-langkah mitigasi di bawah sebelum mengupgrade pemroses pesan ke versi 4.53.01.

Mitigasi

  1. Tinjau kebijakan Java-Callout dan JAR terkait Anda, lalu identifikasi apakah ada kebijakan yang mereferensikan atau menggunakan library apa pun yang ada di direktori “deprecated” message-processor Anda saat ini. Perhatikan bahwa panggilan Java dapat menggunakan JAR yang diupload sebagai resource tingkat organisasi atau lingkungan. Pertimbangkan juga library ini.
  2. Setelah mengidentifikasi library yang tidak digunakan lagi tersebut , Anda dapat mengikuti salah satu metode di bawah untuk mengurangi masalah ini.
    • Penempatan resource (Direkomendasikan jika Anda memiliki sejumlah kecil JAR / library dari direktori yang tidak digunakan lagi yang dirujuk oleh JAR Java-Callout)
      • Upload JAR yang diidentifikasi sebagai tidak digunakan lagi sebagai resource di tingkat yang diinginkan: revisi proxy API, lingkungan, atau organisasi.
      • Lanjutkan upgrade software Apigee seperti biasa.
    • Penempatan Manual (Direkomendasikan jika Anda memiliki banyak JAR / library yang dirujuk oleh JAR Java-Callout)
      • Di setiap node pemroses pesan, buat direktori baru bernama external-lib di jalur $APIGEE_ROOT/data/edge-message-processor/.
      • Salin JAR yang diidentifikasi ke direktori external-lib ini dari direktori yang tidak digunakan lagi: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • Pastikan direktori dan JAR yang mendasarinya dapat dibaca oleh pengguna Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Lanjutkan upgrade software Apigee seperti biasa.

Perubahan OpenLDAP

Konteks

OpenLDAP dapat digunakan di Edge Private Cloud untuk autentikasi dan otorisasi. Di Edge untuk Private Cloud 4.53.01, software OpenLDAP yang dikirimkan oleh Apigee diupgrade dari versi 2.4 ke 2.6.

Perubahan

Di OpenLDAP 2.6, nama yang dibedakan relatif (RDN) dibatasi hingga sekitar 241 byte/karakter. Batasan ini adalah batas atas yang diterapkan dan tidak dapat diubah.

Dampak
  • Kegagalan replikasi atau impor terjadi untuk entri dengan RDN yang terlalu besar.
  • Upaya untuk membuat entitas seperti organisasi, lingkungan, peran khusus, izin, dll. dapat menghasilkan pesan error: "message": "[LDAP: error code 80 - Other]".
  • DN yang lebih panjang dari 241 byte di LDAP Apigee akan terpengaruh. DN tersebut akan mencegah upgrade software Apigee OpenLDAP yang berhasil dan Anda harus mengikuti strategi mitigasi untuk item tersebut sebelum dapat melanjutkan upgrade.

Umumnya, di LDAP Apigee, DN yang panjang terkait dengan izin karena dibuat dengan menggabungkan beberapa entity. Entri izin tersebut sangat rentan terhadap masalah upgrade.

Misalnya, 

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

Biasanya, Anda akan memiliki nama organisasi, lingkungan, dan peran dengan panjang sedemikian rupa sehingga RDN di LDAP menjadi lebih kecil dari 241 byte.

Mitigasi

Sebelum upgrade ke 4.53.01:

Langkah-langkah berikut akan membantu memverifikasi keberadaan RDN panjang di cluster LDAP 2.4 yang ada.

#1 - Ekstrak data LDAP

Gunakan perintah ldapsearch untuk menemukan nama khusus (dn) dan mengalihkan output ke file: 

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

Pastikan file DN.ldif di atas memiliki entri LDAP.

#2 - Mengidentifikasi RDN panjang

Temukan RDN yang melebihi 241 byte/karakter dari file DN.ldif di atas:

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)

Jika perintah di atas tidak menghasilkan output, berarti tidak ada RDN dalam penyiapan LDAP yang ada yang melebihi 241 byte/karakter. Anda dapat melanjutkan upgrade seperti biasa.

Jika perintah di atas menghasilkan output, hal ini menunjukkan adanya RDN yang melebihi 241 byte/karakter. Untuk item tersebut, ikuti langkah-langkah mitigasi seperti yang dijelaskan di langkah#3 sebelum melanjutkan upgrade Edge untuk Private Cloud 4.53.01.

#3 - Menangani RDN panjang

Jika output diterima dari langkah#2, hal ini menunjukkan adanya RDN yang melebihi 241 byte/karakter dan ikuti langkah-langkah mitigasi di bawah:

Tinjau entri LDAP yang melebihi 241 byte.

  • Jika nama peran kustom, Aplikasi, produk API, atau entitas lain adalah faktor utama yang menyebabkan RDN menjadi panjang, migrasikan ke penggunaan entitas alternatif dengan nama yang lebih pendek.
  • Jika nama organisasi atau nama lingkungan yang menjadi kontributor utama RDN panjang, Anda harus bermigrasi ke organisasi atau lingkungan lain dengan nama yang lebih pendek.

Terus ulangi langkah-langkah di atas hingga LDAP Anda tidak memiliki RDN yang lebih panjang dari 241 byte. Setelah Anda mencapai status ini, lanjutkan upgrade versi cloud pribadi seperti biasa.

Perubahan Penyedia Kriptografi

Konteks

Perubahan ini merupakan kelanjutan dari Edge for Private Cloud 4.53.00. Di Edge untuk Private Cloud 4.53.00, penyedia kriptografi internal diupdate dari Bouncy Castle (BC) ke Bouncy Castle FIPS (BCFIPS) untuk mengaktifkan dukungan FIPS.

Perubahan

Jika kebijakan JavaCallout mengandalkan penggunaan penyedia BC asli, terutama saat menggunakan fungsi keamanan yang telah diperkuat di penyedia BCFIPS (misalnya, menggunakan pasangan kunci umum untuk enkripsi dan penandatanganan), kebijakan JavaCallout tersebut harus dimodernisasi. Kebijakan JavaCallout yang mencoba memuat penyedia kriptografi Bouncy Castle menggunakan nama BC dapat gagal karena penyedia default telah berubah. Kebijakan tersebut yang menggunakan penyedia BC dapat rusak. Semua penerapan kustom yang mengandalkan penyedia BC lama tidak akan dapat diakses lagi dan perlu ditinjau serta diterapkan ulang.

Mitigasi

Solusi yang direkomendasikan adalah menggunakan penyedia BCFIPS. Implementasi JavaCallout kustom yang mengandalkan penyedia lama harus ditinjau dan diimplementasikan ulang menggunakan penyedia Bouncy Castle FIPS, yang dapat diakses menggunakan string "BCFIPS".

Alat deteksi perubahan otomatis

Alat deteksi perubahan akan segera dirilis. Alat ini akan dapat memindai dan mengidentifikasi proxy API, alur bersama, resource, dan RDN LDAP yang berpotensi terpengaruh oleh berbagai perubahan yang dijelaskan dalam artikel ini. Alat ini akan membantu mengidentifikasi berbagai entitas yang rentan terhadap kegagalan selama atau setelah upgrade ke Edge untuk Private Cloud 4.53.01.