Edge for Private Cloud 4.53.01 sürümündeki değişiklikler

Değişikliklere genel bakış

Edge for Private Cloud 4.53.01, yazılım/kitaplıkların güncellenmiş sürümlerini içeren platformun güvenlik duruşunu iyileştiren çeşitli değişiklikler sunar. Bu değişiklikler şunları etkiler:

  • OAS (OpenAPI Specification) doğrulama politikası
  • JSONPath sorgularını destekleyen politikalar
  • Kullanımdan kaldırılan kitaplıklara dayanan Java çağrı politikası
  • OpenLDAP

Bu bölümde, 4.53.01 sürümünde kullanıma sunulan ve yükseltme sırasında veya sonrasında iş akışlarınızı bozabilecek çeşitli değişiklik türleri açıklanmaktadır. Potansiyel sorun alanlarını belirleme yöntemleri ve azaltma ya da geçici çözüm metodolojileri de ele alınır.

OAS (OpenAPI Specification) doğrulama politikası

Bağlam

OAS doğrulama politikası, gelen istekleri veya yanıtları OpenAPI 3.0 spesifikasyonunda (JSON veya YAML) tanımlanan kurallara göre doğrular. Edge for Private Cloud 4.53.01, OAS (OpenAPI spesifikasyonu) politikasında geliştirmeler sunar. Bu geliştirmeler, API yanıt gövdelerinin daha katı ve doğru şekilde doğrulanmasına odaklanır.

Değişiklikler

Edge for Private Cloud 4.53.01, OAS politikasının API yanıtlarını doğrulama şekliyle ilgili iki önemli değişiklik yaparak OpenAPI spesifikasyonunuzla daha uyumlu olmasını sağlar:

  • Senaryo 1:
    • Önceki davranış: OpenAPI spesifikasyonunuzda yanıt metni zorunlu olmasına rağmen hedef veya yukarı akış politikasından gelen gerçek yanıtta yanıt metni yoksa politika bunu doğrulama hatası olarak işaretlemiyordu.
    • Mevcut davranış: Politika artık bu senaryoda doğru şekilde bir doğrulama hatası (örnek: defines a response schema but no response body found) döndürerek beklenen ve gerçek yanıt arasında bir uyuşmazlık olduğunu belirtiyor.
  • Senaryo 2:
    • Önceki davranış: OpenAPI spesifikasyonunuzda açıkça yanıt metni beklenmediği belirtilmesine rağmen hedef veya yukarı akış politikasından gelen gerçek yanıtta bir metin varsa politika başarısızlıkla sonuçlanmazdı.
    • Mevcut davranış: Bu politika artık bu senaryoda bir hataya (örnek: No response body is expected but one was found) neden olacak ve yanıtların belirtilen şemaya sıkı sıkıya bağlı kalmasını sağlayacak.

Çözüm

OAS doğrulama politikasının Source etiketi response olarak ayarlanmış şekilde yapılandırıldığı veya yanıt oluşturan başka bir politikadan gelen yanıtı doğrulayan tüm proxy'leri ya da paylaşılan akışları belirleyin.

Bir proxy/paylaşılan akış tanımlandıktan sonra yanıt ile OAS spesifikasyonu arasında uyum olduğundan emin olun. Yanıt, yanıt gövdesinin varlığı veya yokluğuyla ilgili olarak OpenAPI spesifikasyonunuzla tam olarak uyumlu olmalıdır. Trafik kalıplarınızı incelemek için standart Apigee izlemeyi kullanabilirsiniz. Hedef aralıklı olarak yanıt döndürüyorsa OAS politikasından önce doğrulamak için diğer politikaları kullanın.

  • OAS spesifikasyon dosyanız bir yanıt gövdesi tanımlıyorsa hedef veya yukarı akış politikasından gelen yanıt her zaman bir yanıt gövdesi sağlamalıdır.
  • OAS spesifikasyon dosyanızda bir yanıt gövdesi tanımlanmamışsa hedef veya yukarı akış politikası bir yanıt gövdesi göndermemelidir.

Private Cloud 4.53.01'e yükseltmeyi denemeden önce OAS doğrulama politikasını veya hedef davranışınızı gerektiği gibi güncelleyin. Üretim kümesi yükseltmesi sırasında kesinti riskini en aza indirmek için bu tür tanımlanmış iş akışlarını önce üretim dışı ortamlarınızda doğrulamanız gerekir.

JSON dosyasının yolu

Bağlam

Edge for Private Cloud 4.53.01, JSON yolu ifadelerinin çeşitli politikalarda kullanılma şeklini değiştirdi. JSONPath ifadeleri, JSON içeriğini ayrıştırmak veya değerleri değişkenlerde depolamak için ExtractVariable politikası, RegularExpressionProtection politikası, Veri maskeleme gibi politikalarda kullanılabilir. JSONPath ifadeleri, değişkenleri proxy yürütme sırasında değerlerle dinamik olarak değiştirmek için genel mesaj şablonlarında da kullanılabilir. Yeni JSONPath ifadeleri ve biçimleri, en son JSON ifade standartlarına uygundur.

Değişiklikler

JSONPath ifadelerini kullanan politikalar için mevcut API proxy'lerini/paylaşılan akışları incelemek önemlidir. Bu durum; Değişkenleri Ayıklama politikası, Normal İfade Koruması politikası veya JSONPath kullanan Mesaj Şablonu'na sahip tüm politikaları kapsar ancak bunlarla sınırlı değildir.

Aşağıdaki JSON girişi, değişiklikleri açıklamak için kullanılır:

{
  "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. Nesne değerleri için JSONPath joker karakteri [*] davranış değişikliği

    Bir JSON nesnesinin tüm anlık değerlerine erişmek için kullanıldığında [*] joker karakterinin davranışı değiştirildi. Daha önce $.object[*], tek bir JSON nesnesine sarılmış anlık değerleri döndürüyordu. Güncellenen kitaplıklarla birlikte çıkış artık bu değerleri içeren bir dizi oluyor.

    Örneğin, $.store[*]:

    Önceki davranış: 
    {
  "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"}
  ]
}
    Şu anki davranış: 
    [
  [
    {"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"}]
  }
]
    İşlem:

    Daha önce alınan öğeleri doğrudan hedeflemek için JSONPath ifadesini yalnızca üst nesneyi hedefleyecek şekilde değiştirin (örnek: $.store).

  2. Yollardaki (.) JSONPath sondaki nokta hataya neden oluyor

    JSONPath ifadeleri için daha katı bir doğrulama vardır. Daha önce, geçersiz bir sondaki nokta (örnek: $.path.to.element.) ile biten yollar sessizce yoksayılıyordu ve önceki geçerli yol segmenti eşleştiyse sorgu yine de bir sonuç döndürüyordu. Yeni sürümde, bu tür hatalı biçimlendirilmiş yollar artık geçersiz olarak doğru şekilde tanımlanıyor ve hataya neden oluyor.

    Örneğin, $.store.book.

    Önceki davranış: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
    Şu anki davranış: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    JSONPath ifadelerini istenmeden eklenen bir nokta ile kullanan mevcut politikalar artık InvalidPathException ile başarısız olacak.

    İşlem:

    Nokta ile biten tüm JSONPath ifadelerindeki sondaki noktayı kaldırın. Örneğin, $.store.book. değerini $.store.book olarak değiştirin.

  3. JSONPath yinelemeli alt öğe (..) çıkış yapısı değişikliği

    Adlandırılmış bir öğenin tüm oluşumlarını bulmak için (..) (özyinelemeli iniş) operatörü kullanılırken sonuçların döndürülme şeklinde değişiklikler yapıldı. Daha önce, bulunan tüm öğeler tek bir listede birleştiriliyordu. Güncellenen kitaplıklar artık tek bir düz liste yerine, öğelerin bulunduğu orijinal gruplandırma yapısını koruyarak liste listesi döndürüyor.

    Örneğin, $..book

    Önceki davranış: 
    [
  {"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"}
]
    Şu anki davranış: 
    [
  [
    {"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"}
  ]
]
    İşlem:

    Aşağı akış işleme mantığınızı, yeni iç içe dizi yapısını hesaba katacak şekilde güncelleyin. Tek tek öğelere erişmek için büyük olasılıkla dıştaki JSONArray'da ve ardından her bir içteki JSONArray'da yineleme yapmanız gerekir.

  4. Çoklu öğe seçimi veya filtrelemeden sonra JSONPath dizine ekleme işlemi boş dizi döndürüyor

    Bir dizin (örnek: [0]) çok öğeli seçiciden ([*] gibi) veya filtreden ([?(condition)]) hemen sonra uygulandığında davranışta değişiklik olur. Daha önce bu tür ifadeler, belirtilen dizindeki öğeyi birleştirilmiş sonuçlardan seçmeye çalışırdı. Yeni sürümde bu ifadeler artık boş bir dizi ([]) döndürecek.

    Örneğin, $.store.book[*][0]

    Önceki davranış: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    Şu anki davranış: 
    []
    İşlem:

    Filtreleme yapıldıktan sonra filtrelenen kümeden belirli bir öğenin alınması gerekiyorsa örneğin, JSONPath tarafından döndürülen filtrelenmiş diziyi $..book[?(@.category == 'fiction')] işleyin ve ardından önceki sonuçtan [0] öğesini alın.

  5. JSONPath negatif dizi dilimleme çıkış değişikliği

    Yeni sürümde negatif dizi dilimleme davranışı değiştirildi (örnek: [-2:], [-1:]). Daha önce, bir diziye negatif dilimleme uygulandığında (dizinin sonundaki öğeleri belirtme), eski sürüm bu dilimden yalnızca tek bir öğeyi yanlış şekilde döndürüyordu. Yeni sürüm artık belirtilen negatif aralığa giren tüm öğeleri içeren bir listeyi (dizi) doğru şekilde döndürüyor.

    Örneğin $.store.book[-2:]

    Önceki davranış: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    Şu anki davranış: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    İşlem:

    Artık istenen çıktıyı almak için döndürülen JSON dizisinde yineleme yapacak şekilde sonraki işleme mantığının güncellenmesi gerekiyor.

  6. JSONPath'te daha katı ön nokta

    Doğrudan kökten erişilen öğeler için söz dizimi daha katı bir şekilde uygulanır. Öğelere, kökten doğrudan erişildiğinde (örnek: $propertyelement) bu söz dizimi artık hata olarak kabul ediliyor ve proxy dağıtımını engelliyor.

    Örneğin $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"}
  ]
}

    Şu anki davranış:

    Proxy will fail to deploy.

    İşlem:

    JSONPath'inizi noktayı içerecek şekilde değiştirin: $.propertyName (örnek: $.store). Bu, değeri doğru şekilde hedefler ve alır.

  7. Dinamik JSONPath ifadeleri

    JSONPath ifadesinin kendisinin bir değişken tarafından sağlandığı politikalara (örnek: {myJsonPathVariable} veya {dynamicPath}) dikkat edin. Bu değişkenlerin değeri de yukarıda belirtilen olası davranış değişikliklerine göre kontrol edilmelidir.

Çözüm

Bu durumu azaltmak için kapsamlı bir strateji gereklidir. Bu süreçte, uygun güncelleme yoluna karar verilir ve JSONPath ifadelerinin bozulmasıyla ilgili gerekli düzeltme uygulanır.

Size en uygun yükseltme yolu yöntemini seçin:

  • Sıfır Kapalı Kalma Süresiyle Taşıma

    Bu strateji, ayrı ileti işlemci düğümlerini bağlayabilmeniz için bir veya daha fazla yeni ortam tedarik etmeyi içerir. Bu tür ileti işlemci düğümleri, 4.53.01 sürümünü yükleyecek şekilde ayarlanabilir ve modern JSONPath ifadeleri içeren proxy'lere sahip olabilir. Bu cihazlar, yeni sürüme geçiş sırasında kullanılabilir ve yeni sürüme geçiş tamamlandıktan sonra devre dışı bırakılabilir. Bu strateji sorunsuz olsa da sorunsuz bir yükseltmeyi desteklemek için geçici olarak ek ileti işlemcisi düğümleri tedarik etmeyi içerir. Ayrıntılar aşağıda verilmiştir:

    • Yeni bir ortam oluşturun ve bu yeni ortama 4.53.01 sürümünün yeni mesaj işleme düğümlerini ekleyin.
    • Etkilenen proxy'ler için proxy paketini yeni ortama yükleyin, düzeltme bölümünde açıklanan gerekli düzeltmeleri uygulayın ve güncellenen proxy paketini yeni ortama dağıtın.
    • Trafiği yeni ortama yönlendirin ve etkilenen proxy'leri eski ortamdan kaldırın.
    • Orijinal ileti işlemci düğümlerini 4.53.01 sürümüne yükseltin. Orijinal ortamda JSONPath ile ilgili düzeltmeler içeren proxy'leri dağıtın.
    • Trafiği, artık 4.53.01 sürümünde mesaj işlemcileri ve yeni jsonpath ifadeleri için modernleştirilmiş bir proxy'ye sahip olan eski ortama geri yönlendirin.
    • Yeni ortamı ve ilişkili düğümleri silin ve hizmetten kaldırın.
  • Kapalı kalma süresi ve yükseltme

    Bu strateji, hatalı JSON yolu ifadeleri kullanarak API proxy'leri için kapalı kalma süresi elde etmeyi içerir. Ek mesaj işlemcisi düğümleri satın almayı gerektirmez ancak etkilenen proxy'ler için API trafiğinde kesintiye neden olur.

    • Etkilenen politikalarla etkilenen proxy'leri belirleyin ve etkilenen tüm proxy'ler için yeni bir düzeltme oluşturun.
    • Gerekli düzeltmeleri, düzeltme bölümünde açıklanan düzeltmeleri vekil sunucunun yeni bir revizyonunda uygulayarak yapın. Bunu henüz dağıtmayın.
    • Etkilenen proxy'ler için kapalı kalma süresi ayarlayın.
    • Tüm ileti işlemcileri, özel bulut sürümü 4.53.01 için Edge'e yükseltin. Mevcut proxy'lerin, yeni yükseltilen ileti işlemcilerinde başarısız olabileceğini unutmayın.
    • Tüm ileti işlemciler Edge for private cloud sürüm 4.53.01'e yükseltildikten sonra , düzeltilmiş JSONPath ifadesiyle yeni oluşturulan proxy düzeltmesini dağıtın.
    • Bu tür proxy'lerde trafiğe devam edin.
  • Yükseltmeden önce Proxy'yi yeniden tasarlama

    Edge for Private Cloud 4.53.01'e yükseltmeden önce proxy'yi yeniden tasarlayabilirsiniz. Belirli JSON yolu ifadelerini kullanmak yerine farklı bir yöntemle aynı sonucu elde edebilirsiniz.

    Örneğin, JSON yoluyla bir Değişken Ayıklama Politikası kullanıyorsanız daha yeni sürüme yükseltmeden önce politikayı benzer verileri ayıklayan bir JavaScript politikasıyla değiştirebilirsiniz. Yükseltme işlemi tamamlandıktan sonra, proxy'nizi daha yeni biçimlerle JSON yollarını kullanacak şekilde değiştirebilirsiniz.

JavaCallout değişiklikleri

Bağlam

Private Cloud için Edge 4.53.00 ve önceki sürümlerinde, bir dizi JAR kitaplığı içeren deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) adlı bir dizin bulunuyordu. Bu kitaplıklar, JavaCallout politikası'ndaki Java kodunda kullanılabilir ve özel Java kodunuz tarafından doğrudan veya dolaylı olarak kullanılmış olabilir.

Değişiklikler

Desteği sonlandırılan dizin, Private Cloud için Edge 4.53.01 sürümünde kaldırıldı. Java kodunuz bu tür kitaplıklara bağlıysa mesaj işlemciler 4.53.01 sürümüne yükseltildiğinde bu tür Java çağrılarını kullanan proxy'ler başarısız olur. Bu tür hataları önlemek için ileti işlemcileri 4.53.01 sürümüne yükseltmeden önce aşağıdaki azaltma adımlarını uygulayın.

Çözüm

  1. Java-Callout politikalarınızı ve ilişkili JAR'ları inceleyin. Bunlardan herhangi birinin, mevcut ileti işlemcilerinizin "kullanımdan kaldırılan" dizininde bulunan kitaplıklara referans verip vermediğini veya bu kitaplıkları kullanıp kullanmadığını belirleyin. Java çağrıları, kuruluş veya ortam düzeyinde kaynaklar olarak yüklenen JAR dosyalarını kullanabilir. Şu kitaplıkları da göz önünde bulundurun.
  2. Bu tür kullanımdan kaldırılmış kitaplıkları belirledikten sonra sorunu azaltmak için aşağıdaki yöntemlerden birini uygulayabilirsiniz.
    • Kaynak yerleştirme (Java-Callout JAR'ları tarafından referans verilen, kullanımdan kaldırılmış dizinden az sayıda JAR / kitaplığınız varsa önerilir)
      • Belirlenen kullanımdan kaldırılmış JAR'ları, istenen düzeyde (API proxy düzeltmesi, ortam veya kuruluş) kaynak olarak yükleyin.
      • Apigee yazılımını her zamanki gibi yükseltmeye devam edin.
    • Manuel Yerleştirme (Java-Callout JAR'ları tarafından referans verilen çok sayıda JAR / kitaplığınız varsa önerilir)
      • Her ileti işlemci düğümünde, $APIGEE_ROOT/data/edge-message-processor/ yolunda external-lib adlı yeni bir dizin oluşturun.
      • Belirlenen JAR'ları, kullanımdan kaldırılan dizinden bu external-lib dizinine kopyalayın: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • Dizin ve temel JAR'ların Apigee kullanıcısı tarafından okunabildiğinden emin olun: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Apigee yazılımını her zamanki gibi yükseltmeye devam edin.

OpenLDAP değişikliği

Bağlam

OpenLDAP, Edge Private Cloud'da hem kimlik doğrulama hem de yetkilendirme için kullanılabilir. Edge for Private Cloud 4.53.01'de, Apigee tarafından gönderilen OpenLDAP yazılımı 2.4 sürümünden 2.6 sürümüne yükseltildi.

Değişiklikler

OpenLDAP 2.6'da, göreceli ayırt edici ad (RDN) yaklaşık 241 bayt/karakterle sınırlıdır. Bu sınırlama, zorunlu kılınan bir üst sınırdır ve değiştirilemez.

Etki
  • Aşırı büyük RDN'lere sahip girişlerde replikasyon veya içe aktarma hataları oluşur.
  • Kuruluşlar,ortamlar, özel roller, izinler vb. gibi öğeler oluşturmaya çalışırken "message": "[LDAP: error code 80 - Other]" hata mesajı gösterilebilir.
  • Apigee'nin LDAP'sinde 241 bayttan uzun olan tüm DN'ler etkilenir. Bu tür DN'ler, Apigee OpenLDAP yazılımının başarılı bir şekilde yükseltilmesini engeller. Yükseltme işlemine devam edebilmek için bu tür öğelerle ilgili azaltma stratejilerini uygulamanız gerekir.

Genel olarak, Apigee'nin LDAP'sinde uzun DN'ler, birden fazla öğe birleştirilerek oluşturuldukları için izinlerle ilgilidir. Bu tür izin girişleri özellikle yükseltme sorunlarına yatkındır.

Örneğin, 

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

Genellikle, LDAP'deki RDN'lerin 241 bayttan küçük olması için kuruluş, ortam ve rol adlarınızın uzunluğu yeterli olur.

Çözüm

4.53.01 sürümüne yükseltmeden önce:

Aşağıdaki adımlar, mevcut LDAP 2.4 kümenizde uzun RDN'lerin varlığını doğrulamanıza yardımcı olur.

#1 - LDAP verilerini ayıklama

ldapsearch komutunu kullanarak ayırt edici adı (dn) bulun ve çıkışı bir dosyaya yönlendirin: 

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

Yukarıdaki DN.ldif dosyasında LDAP girişleri olduğundan emin olun.

#2 - Uzun RDN'leri belirleme

Yukarıdaki DN.ldif dosyasında 241 baytı/karakteri aşan RDN'leri bulun:

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)

Yukarıdaki komut herhangi bir çıkış üretmezse mevcut LDAP kurulumundaki hiçbir RDN 241 baytı/karakteri aşmıyor demektir. Yükseltme işlemine her zamanki gibi devam edebilirsiniz.

Yukarıdaki komut bir çıktı oluşturursa 241 baytı/karakteri aşan RDN'lerin varlığı belirtilir. Bu tür öğeler için Edge for Private Cloud 4.53.01 yükseltme işlemine devam etmeden önce 3. adımda açıklanan azaltma adımlarını uygulayın.

#3 - Uzun RDN'leri işleme

2. adımda çıktı alınırsa 241 baytı/karakteri aşan RDN'lerin varlığı söz konusudur. Bu durumda aşağıdaki azaltma adımlarını uygulayın:

241 baytı aşan LDAP girişlerini inceleyin.

  • RDN'nin uzun olmasına neden olan temel faktör özel rol adı, uygulama, API ürünü veya diğer öğelerse daha kısa bir ada sahip alternatif bir öğe kullanmaya geçin.
  • Uzun RDN'ye asıl katkıda bulunan kuruluş adı veya ortam adıysa daha kısa bir ada sahip farklı bir kuruluşa ya da ortama geçmeniz gerekir.

LDAP'nizdeki RDN'ler 241 bayttan kısa olana kadar yukarıdaki adımları tekrarlayın. Bu duruma ulaştıktan sonra özel bulut sürümünü her zamanki gibi yükseltmeye devam edin.

Kriptografi sağlayıcı değişiklikleri

Bağlam

Bu değişiklik, Edge for Private Cloud 4.53.00 sürümünden aktarılmıştır. Edge for Private Cloud 4.53.00'da, FIPS desteğini etkinleştirmek için dahili kriptografi sağlayıcı Bouncy Castle'dan (BC) Bouncy Castle FIPS'e (BCFIPS) güncellendi.

Değişiklikler

JavaCallout politikaları, özellikle BCFIPS sağlayıcısında güvenliği artırılmış güvenlik işlevleri (örneğin, hem şifreleme hem de imzalama için ortak bir anahtar çifti kullanma) kullanılırken orijinal BC sağlayıcısının kullanılmasını gerektiriyorsa bu tür JavaCallout politikalarının modernleştirilmesi gerekir. BC adını kullanarak Bouncy Castle kriptografi sağlayıcısını yüklemeye çalışan JavaCallout politikaları, varsayılan sağlayıcı değiştiği için başarısız olabilir. BC sağlayıcısını kullanan bu tür politikalar daha sonra bozulabilir. Eski BC sağlayıcısına dayanan özel uygulamalara artık erişilemeyecek. Bu uygulamaların incelenmesi ve yeniden uygulanması gerekecek.

Çözüm

Önerilen geçici çözüm, BCFIPS sağlayıcısını kullanmaktır. Eski sağlayıcıya dayanan özel JavaCallout uygulamalarının incelenmesi ve "BCFIPS" dizesi kullanılarak erişilebilen Bouncy Castle FIPS sağlayıcısı kullanılarak yeniden uygulanması gerekir.

Otomatik değişiklik algılama aracı

Yakında bir değişiklik algılama aracı yayınlanacak. Bu araç, bu makalede açıklanan çeşitli değişikliklerden etkilenme olasılığı olan API proxy'lerini, paylaşılan akışları, kaynakları ve LDAP RDN'lerini tarayıp tanımlayabilir. Bu araç, Edge for Private Cloud 4.53.01'e yükseltme sırasında veya sonrasında arızalanmaya yatkın çeşitli varlıkların tanımlanmasına yardımcı olur.