Zmiany w Edge for Private Cloud w wersji 4.53.01

Omówienie zmian

W wersji 4.53.01 Edge for Private Cloud wprowadzono wiele zmian, które zwiększają poziom bezpieczeństwa platformy, w tym zaktualizowane wersje oprogramowania i bibliotek. Zmiany te mają wpływ na:

  • Zasady weryfikacji OAS (specyfikacji OpenAPI)
  • Zasady obsługujące zapytania JSONPath
  • zasady wywołania Javy, które korzystają z wycofanych bibliotek;
  • OpenLDAP

W tej sekcji opisujemy różne rodzaje zmian wprowadzonych w wersji 4.53.01, które mogą zakłócić przepływy pracy w trakcie uaktualniania lub po nim. Omówimy też metody identyfikowania potencjalnych problemów oraz sposoby ich łagodzenia lub obejścia.

Zasady weryfikacji OAS (specyfikacji OpenAPI)

Kontekst

Zasady weryfikacji OAS weryfikują żądania lub odpowiedzi przychodzące pod kątem reguł zdefiniowanych w specyfikacji OpenAPI 3.0 (JSON lub YAML). Wersja 4.53.01 Edge for Private Cloud zawiera ulepszenia zasad OAS (specyfikacji OpenAPI), które koncentrują się na bardziej rygorystycznej i dokładniejszej weryfikacji treści odpowiedzi interfejsu API.

Zmiany

W wersji 4.53.01 Edge for Private Cloud wprowadziliśmy 2 ważne zmiany w sposobie, w jaki zasady OAS weryfikują odpowiedzi interfejsu API. Zapewniają one lepsze dopasowanie do specyfikacji OpenAPI:

  • Scenariusz 1:
    • Wcześniejsze działanie: jeśli specyfikacja OpenAPI wymagała treści odpowiedzi, ale rzeczywista odpowiedź z zasad docelowych lub nadrzędnych nie zawierała treści, zasady nie zgłaszały tego jako błędu weryfikacji.
    • Obecne działanie: w tej sytuacji zasady będą teraz prawidłowo zwracać błąd weryfikacji (np. defines a response schema but no response body found), co oznacza niezgodność między oczekiwaną a rzeczywistą odpowiedzią.
  • Scenariusz 2:
    • Wcześniejsze działanie: jeśli specyfikacja OpenAPI wyraźnie wskazywała, że nie oczekiwano treści odpowiedzi, ale rzeczywista odpowiedź z zasad docelowych lub nadrzędnych zawierała treść, zasady nie powodowały błędu.
    • Obecne działanie: w tym scenariuszu zasady spowodują błąd (np. No response body is expected but one was found), co zapewni, że odpowiedzi będą ściśle zgodne z określonym schematem.

Łagodzenie

Zidentyfikuj wszystkie serwery proxy lub współdzielone przepływy, w których zasada weryfikacji OAS jest skonfigurowana z tagiem Source ustawionym na response, lub te, które weryfikują odpowiedź z dowolnej innej zasady generującej odpowiedź.

Po zidentyfikowaniu przepływu proxy lub przepływu współdzielonego sprawdź zgodność odpowiedzi ze specyfikacją OAS. Odpowiedź musi być ściśle zgodna ze specyfikacją OpenAPI w zakresie obecności lub braku treści odpowiedzi. Aby sprawdzić wzorce ruchu, możesz użyć standardowego śledzenia Apigee. Jeśli docelowy zwraca odpowiedź z przerwami, przed zastosowaniem zasad OAS użyj innych zasad, aby ją zweryfikować.

  • Jeśli plik specyfikacji OAS definiuje treść odpowiedzi, odpowiedź z zasad docelowych lub nadrzędnych musi zawsze ją zawierać.
  • Jeśli plik specyfikacji OAS nie definiuje treści odpowiedzi, zasady docelowe lub nadrzędne nie mogą jej wysyłać.

Przed próbą przejścia na Private Cloud 4.53.01 zaktualizuj w razie potrzeby zasady weryfikacji OAS lub docelowe zachowanie. Aby zminimalizować ryzyko przerw w działaniu podczas uaktualniania klastra produkcyjnego, najpierw zweryfikuj zidentyfikowane przepływy pracy w środowiskach nieprodukcyjnych.

Ścieżka JSON

Kontekst

W wersji Edge for Private Cloud 4.53.01 wprowadzono zmiany w sposobie używania wyrażeń ścieżki JSON w różnych zasadach. Wyrażenia JSONPath można stosować w zasadach takich jak zasady ExtractVariable, zasady RegularExpressionProtection czy maskowanie danych, aby analizować zawartość JSON lub przechowywać wartości w zmiennych. Wyrażenia JSONPath można też stosować w ogólnym szablonie wiadomości, aby dynamicznie zastępować zmienne wartościami podczas wykonywania serwera proxy. Nowe wyrażenia i formaty JSONPath są zgodne z najnowszymi standardami wyrażeń JSON.

Zmiany

Sprawdź istniejące proxy interfejsu API lub współdzielone przepływy pod kątem zasad, które wykorzystują wyrażenia JSONPath. Dotyczy to m.in. zasad Extract Variables, Regular Expression Protection i wszelkich zasad z szablonem wiadomości korzystającym z JSONPath.

Poniższy plik JSON służy do wyjaśnienia zmian:

{
  "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. Zmiana działania symbolu wieloznacznego [*] JSONPath w przypadku wartości obiektów

    Zmieniliśmy działanie symbolu wieloznacznego [*], gdy jest on używany do uzyskiwania dostępu do wszystkich bezpośrednich wartości obiektu JSON. Wcześniej funkcja $.object[*] zwracała wartości bezpośrednie zawarte w jednym obiekcie JSON. W zaktualizowanych bibliotekach dane wyjściowe to teraz tablica zawierająca te wartości.

    Na przykład: $.store[*].

    Poprzednie działanie: 
    {
  "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"}
  ]
}
    Obecne działanie: 
    [
  [
    {"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"}]
  }
]
    Działanie:

    Zmień wyrażenie JSONPath, aby kierować na obiekt nadrzędny (np. $.store), i w ten sposób bezpośrednio kierować na wcześniej pobrane elementy.

  2. Kropka na końcu ścieżki JSONPath (.) powoduje błąd

    Wyrażenia JSONPath podlegają bardziej rygorystycznej weryfikacji. Wcześniej ścieżki kończące się nieprawidłową kropką na końcu (np. $.path.to.element.) były cicho ignorowane, a zapytanie nadal zwracało wynik, jeśli pasował poprzedni prawidłowy segment ścieżki. W nowej wersji takie nieprawidłowe ścieżki są prawidłowo identyfikowane jako nieprawidłowe i powodują błąd.

    Na przykład: $.store.book.

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

    Wszystkie dotychczasowe zasady, które używają wyrażeń JSONPath z niezamierzoną kropką na końcu, będą teraz zwracać błąd InvalidPathException.

    Działanie:

    Usuń kropkę z końca każdego wyrażenia JSONPath, które się nią kończy. Na przykład zmień $.store.book. na $.store.book.

  3. Zmiana struktury danych wyjściowych (..) rekurencyjnego przeszukiwania JSONPath

    W przypadku użycia operatora (..) (rekurencyjne przeszukiwanie) do znajdowania wszystkich wystąpień nazwanego elementu wyniki są zwracane w inny sposób. Wcześniej wszystkie znalezione elementy były spłaszczane do jednej listy. Zaktualizowane biblioteki zwracają teraz listę list, zachowując pierwotną strukturę grup, w których znaleziono elementy, zamiast jednej płaskiej listy.

    Na przykład: $..book

    Poprzednie działanie: 
    [
  {"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"}
]
    Obecne działanie: 
    [
  [
    {"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"}
  ]
]
    Działanie:

    Zaktualizuj logikę przetwarzania podrzędnego, aby uwzględnić nową strukturę zagnieżdżonej tablicy. Prawdopodobnie musisz przejść przez zewnętrzną tablicę JSONArray, a potem przez każdą wewnętrzną tablicę JSONArray, aby uzyskać dostęp do poszczególnych elementów.

  4. Indeksowanie JSONPath po wybraniu wielu elementów lub zastosowaniu filtra zwraca pustą tablicę

    Zmiana w działaniu występuje, gdy indeks (np. [0]) jest stosowany bezpośrednio po selektorze wielu elementów (np. [*]) lub filtrze ([?(condition)]). Wcześniej takie wyrażenia próbowały wybrać element o określonym indeksie z połączonych wyników. W nowej wersji te wyrażenia będą zwracać pustą tablicę ([]).

    Na przykład: $.store.book[*][0]

    Poprzednie działanie: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    Obecne działanie: 
    []
    Działanie:

    Jeśli musisz odfiltrować, a następnie pobrać konkretny element z odfiltrowanego zbioru, przetwórz odfiltrowaną tablicę zwróconą przez JSONPath, np. $..book[?(@.category == 'fiction')], a następnie pobierz [0] z poprzedniego wyniku.

  5. Zmiana danych wyjściowych ujemnego wycinania tablicy JSONPath

    W nowej wersji zmodyfikowano działanie wycinania tablicy z użyciem indeksów ujemnych (np. [-2:], [-1:]). Wcześniej podczas stosowania ujemnego wycinka do tablicy (wskazującego elementy od końca tablicy) stara wersja nieprawidłowo zwracała tylko jeden element z tego wycinka. Nowa wersja prawidłowo zwraca listę (tablicę) zawierającą wszystkie elementy, które mieszczą się w określonym zakresie ujemnym.

    Na przykład $.store.book[-2:]

    Poprzednie działanie: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    Obecne działanie: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    Działanie:

    Logika przetwarzania podrzędnego musi zostać zaktualizowana, aby iterować po zwróconej tablicy JSON i uzyskać żądane dane wyjściowe.

  6. JSONPath stricter preceding dot

    Wymagania dotyczące składni elementów, do których uzyskuje się dostęp bezpośrednio z katalogu głównego, są bardziej rygorystyczne. Gdy do elementów uzyskuje się dostęp bezpośrednio z katalogu głównego bez poprzedzającej kropki (np. $propertyelement), taka składnia jest teraz traktowana jako błąd i uniemożliwia wdrożenie serwera proxy.

    Na przykład $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"}
  ]
}

    Obecne działanie:

    Proxy will fail to deploy.

    Działanie:

    Zmień JSONPath, aby zawierał kropkę: $.propertyName (przykład: $.store). Dzięki temu prawidłowo określisz i pobierzesz wartość.

  7. Dynamiczne wyrażenia JSONPath

    Zwróć szczególną uwagę na zasady, w których wyrażenie JSONPath jest podawane przez zmienną (np. {myJsonPathVariable} lub {dynamicPath}). Wartość tych zmiennych również musi być sprawdzana pod kątem potencjalnych zmian w zachowaniu opisanych powyżej.

Łagodzenie

Aby temu zapobiec, konieczna jest kompleksowa strategia. Ten proces obejmuje wybór odpowiedniej ścieżki aktualizacji i zastosowanie niezbędnej poprawki w przypadku nieprawidłowych wyrażeń JSONPath.

Wybierz metodę ścieżki uaktualnienia, która najbardziej Ci odpowiada:

  • Migracja bez przestojów

    Ta strategia polega na pozyskaniu co najmniej 1 nowego środowiska, aby można było podłączyć do niego osobne węzły procesora wiadomości. Węzły procesora wiadomości można skonfigurować tak, aby instalowały wersję 4.53.01 i miały serwery proxy z nowoczesnymi wyrażeniami JSONPath. Można ich używać podczas uaktualniania, a po jego zakończeniu można je wycofać. Ta strategia jest bezproblemowa, ale wymaga tymczasowego pozyskania dodatkowych węzłów procesora wiadomości, aby zapewnić płynne przejście na nową wersję. Szczegóły poniżej:

    • Utwórz nowe środowisko i dodaj do niego nowe węzły procesora wiadomości w wersji 4.53.01.
    • Prześlij pakiet proxy dla proxy, których dotyczy problem, do nowego środowiska i zastosuj niezbędne poprawki opisane w sekcji dotyczącej rozwiązania oraz wdróż zaktualizowany pakiet proxy w nowym środowisku.
    • Przekieruj ruch do nowego środowiska i wycofaj wdrożenie odpowiednich serwerów proxy ze starego środowiska.
    • Uaktualnij węzły oryginalnego procesora wiadomości do wersji 4.53.01. Wdróż w środowisku pierwotnym proxy, które zawierają poprawki dotyczące JSONPath.
    • Przekieruj ruch z powrotem do starego środowiska, w którym procesory wiadomości działają w wersji 4.53.01, a serwer proxy jest zmodernizowany pod kątem nowych wyrażeń jsonpath.
    • Usuń i wycofaj nowe środowisko oraz powiązane z nim węzły.
  • Przerwa i przejście na wyższą wersję

    Ta strategia polega na wywoływaniu przestojów w przypadku serwerów proxy interfejsu API za pomocą nieprawidłowych wyrażeń JSONPath. Nie wymaga to zakupu dodatkowych węzłów procesora wiadomości, ale powoduje zakłócenia w ruchu API w przypadku proxy, których dotyczy problem.

    • Zidentyfikuj serwery proxy, których dotyczy problem, wraz z zasadami, których to dotyczy, i wygeneruj nową wersję dla wszystkich serwerów proxy, których dotyczy problem.
    • Wprowadź niezbędne poprawki, wdrażając poprawki opisane w sekcji dotyczącej rozwiązywania problemów w nowej wersji proxy. Nie wdrażaj jeszcze tej wersji.
    • Zapewnij czas przestoju dla serwera proxy lub serwerów proxy, na które ma to wpływ.
    • Uaktualnij wszystkie procesory wiadomości do wersji Edge dla chmury prywatnej 4.53.01. Pamiętaj, że istniejące serwery proxy mogą nie działać na nowo uaktualnionych procesorach wiadomości.
    • Gdy wszystkie procesory wiadomości zostaną zaktualizowane do wersji 4.53.01 Edge dla chmury prywatnej , wdróż nowo utworzoną wersję serwera proxy z poprawionym wyrażeniem JSONPath.
    • wznowić ruch na takich serwerach proxy.
  • Przeprojektuj proxy przed uaktualnieniem

    Przed uaktualnieniem do wersji Edge for Private Cloud 4.53.01 możesz przeprojektować sam serwer proxy. Zamiast polegać na konkretnych wyrażeniach ścieżki JSON, możesz uzyskać ten sam wynik, korzystając z innej metody.

    Jeśli na przykład używasz zasady Extract Variable Policy ze ścieżką JSON, możesz zastąpić ją zasadą Javascript, która wyodrębnia podobne dane, zanim przejdziesz na nowszą wersję. Po zakończeniu przekształcania możesz przywrócić w serwerze proxy ścieżki JSON w nowszych formatach.

Zmiany w zasadzie JavaCallout

Kontekst

W wersjach Edge for Private Cloud 4.53.00 i starszych znajdował się katalog o nazwie deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated), który zawierał wiele bibliotek JAR. Te biblioteki były dostępne do użycia w kodzie Java w zasadach JavaCallout i mogły być używane przez Twój niestandardowy kod Java bezpośrednio lub pośrednio.

Zmiany

Katalog deprecated został usunięty w Edge w chmurze prywatnej w wersji 4.53.01. Jeśli Twój kod Java korzysta z takich bibliotek, serwery proxy używające takich wywołań Java przestaną działać po uaktualnieniu procesorów wiadomości do wersji 4.53.01. Aby uniknąć takich awarii, przed uaktualnieniem procesorów wiadomości do wersji 4.53.01 wykonaj poniższe czynności.

Łagodzenie

  1. Sprawdź zasady Java-Callout i powiązane z nimi pliki JAR oraz określ, czy któreś z nich odwołują się do bibliotek znajdujących się w katalogu „deprecated” na bieżących procesorach wiadomości lub z nich korzystają. Pamiętaj, że wywołania Java mogą korzystać z plików JAR przesłanych jako zasoby na poziomie organizacji lub środowiska. Sprawdź też te biblioteki.
  2. Po zidentyfikowaniu takich wycofanych bibliotek możesz zastosować jedną z tych metod , aby rozwiązać problem.
    • Umieszczanie zasobów (zalecane, jeśli masz niewielką liczbę plików JAR lub bibliotek z wycofanego katalogu, do których odwołują się pliki JAR Java-Callout).
      • Prześlij zidentyfikowane wycofane pliki JAR jako zasób na wybranym poziomie: wersji proxy interfejsu API, środowiska lub organizacji.
      • Przeprowadź aktualizację oprogramowania Apigee w zwykły sposób.
    • Ręczne umieszczanie (zalecane, jeśli masz dużą liczbę plików JAR lub bibliotek, do których odwołują się pliki JAR Java-Callout).
      • W każdym węźle procesora wiadomości utwórz nowy katalog o nazwie external-lib w ścieżce $APIGEE_ROOT/data/edge-message-processor/.
      • Skopiuj zidentyfikowane pliki JAR do tego katalogu external-lib z katalogu, który jest już nieaktualny: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • Sprawdź, czy katalog i podstawowe pliki JAR są czytelne dla użytkownika Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Przeprowadź aktualizację oprogramowania Apigee w zwykły sposób.

Zmiana OpenLDAP

Kontekst

OpenLDAP można używać w Edge Private Cloud zarówno do uwierzytelniania, jak i autoryzacji. W Edge for Private Cloud 4.53.01 oprogramowanie OpenLDAP dostarczane przez Apigee zostało uaktualnione z wersji 2.4 do 2.6.

Zmiany

W OpenLDAP 2.6 względna nazwa wyróżniająca (RDN) jest ograniczona do około 241 bajtów/znaków. To ograniczenie jest nieprzekraczalne i nie można go zmienić.

Wpływ
  • W przypadku wpisów z nadmiernie dużymi nazwami RDN występują błędy replikacji lub importu.
  • Próba utworzenia podmiotów, takich jak organizacje, środowiska, role niestandardowe, uprawnienia itp., może spowodować wyświetlenie komunikatu o błędzie: "message": "[LDAP: error code 80 - Other]".
  • Dotyczy to wszystkich nazw wyróżniających dłuższych niż 241 bajtów w LDAP Apigee. Takie nazwy wyróżniające uniemożliwią pomyślne uaktualnienie oprogramowania Apigee OpenLDAP. Zanim będzie można kontynuować uaktualnianie, należy zastosować strategie ograniczania ryzyka związane z tymi elementami.

W LDAP Apigee długie nazwy wyróżniające są zwykle powiązane z uprawnieniami, ponieważ powstają przez połączenie wielu elementów. Takie wpisy uprawnień są szczególnie podatne na problemy z uaktualnianiem.

Na przykład 

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

Zwykle nazwy organizacji, środowiska i roli mają taką długość, że nazwy względne w LDAP są mniejsze niż 241 bajtów.

Łagodzenie

Przed uaktualnieniem do wersji 4.53.01:

Poniższe kroki pomogą Ci sprawdzić, czy w istniejącym klastrze LDAP 2.4 występują długie nazwy RDN.

1. Wyodrębnij dane LDAP

Użyj polecenia ldapsearch, aby znaleźć nazwę wyróżniającą (dn) i przekierować dane wyjściowe do pliku: 

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

Upewnij się, że plik DN.ldif zawiera wpisy LDAP.

2. Identyfikowanie długich nazw RDN

Znajdź nazwy RDN przekraczające 241 bajtów/znaków w pliku DN.ldif powyżej:

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)

Jeśli powyższe polecenie nie wygeneruje żadnych danych wyjściowych, oznacza to, że żadne nazwy RDN w obecnej konfiguracji LDAP nie przekraczają 241 bajtów/znaków. Możesz kontynuować uaktualnianie.

Jeśli powyższe polecenie wygeneruje dane wyjściowe, oznacza to, że istnieją nazwy RDN przekraczające 241 bajtów lub znaków. W przypadku takich elementów przed przejściem na Edge for Private Cloud 4.53.01 wykonaj czynności opisane w kroku 3.

3. Obsługa długich nazw RDN

Jeśli w kroku 2 otrzymasz dane wyjściowe, oznacza to, że istnieją nazwy RDN przekraczające 241 bajtów/znaków. Wykonaj poniższe czynności:

Sprawdź wpisy LDAP, które przekraczają 241 bajtów.

  • Jeśli nazwa roli niestandardowej, aplikacji, produktu interfejsu API lub innych elementów jest głównym czynnikiem powodującym długość nazwy RDN, przejdź na używanie alternatywnego elementu o krótszej nazwie.
  • Jeśli głównym powodem długiego RDN jest nazwa organizacji lub środowiska, musisz przenieść się do innej organizacji lub środowiska o krótszej nazwie.

Powtarzaj powyższe kroki, aż w LDAP nie będzie już względnych nazw wyróżniających dłuższych niż 241 bajtów. Gdy osiągniesz ten stan, przeprowadź uaktualnienie wersji chmury prywatnej w zwykły sposób.

Zmiany dostawcy kryptografii

Kontekst

Ta zmiana została przeniesiona z wersji 4.53.00 Edge for Private Cloud. W Edge for Private Cloud 4.53.00 wewnętrzny dostawca kryptografii został zaktualizowany z Bouncy Castle (BC) do Bouncy Castle FIPS (BCFIPS), aby umożliwić obsługę FIPS.

Zmiany

Jeśli zasady JavaCallout opierają się na używaniu oryginalnego dostawcy BC, zwłaszcza w przypadku korzystania z funkcji zabezpieczeń, które zostały wzmocnione w dostawcy BCFIPS (np. używanie wspólnej pary kluczy do szyfrowania i podpisywania), takie zasady JavaCallout będą wymagać modernizacji. Zasady JavaCallout, które próbują wczytać dostawcę kryptografii Bouncy Castle za pomocą nazwy BC, mogą się nie powieść, ponieważ domyślny dostawca uległ zmianie. Takie zasady korzystające z dostawcy BC mogą później przestać działać. Wszelkie niestandardowe implementacje korzystające ze starego dostawcy BC nie będą już dostępne i będą wymagać sprawdzenia i ponownego wdrożenia.

Łagodzenie

Zalecanym obejściem jest użycie dostawcy BCFIPS. Niestandardowe implementacje JavaCallout, które korzystały ze starego dostawcy, będą wymagać sprawdzenia i ponownej implementacji przy użyciu dostawcy Bouncy Castle FIPS, do którego można uzyskać dostęp za pomocą ciągu znaków „BCFIPS”.

Narzędzie do automatycznego wykrywania zmian

Wkrótce udostępnimy narzędzie do wykrywania zmian. To narzędzie będzie mogło skanować i identyfikować proxy interfejsu API, współdzielone przepływy, zasoby i nazwy wyróżniające LDAP, na które mogą mieć wpływ różne zmiany opisane w tym artykule. To narzędzie powinno pomóc w identyfikowaniu różnych podmiotów, które mogą ulec awarii podczas lub po uaktualnieniu do Edge for Private Cloud w wersji 4.53.01.