Изменения в Edge для частного облака 4.53.01

Обзор изменений

В версии Edge for Private Cloud 4.53.01 реализованы многочисленные изменения, повышающие безопасность платформы, а также обновлены версии необходимого ПО и библиотек. Изменения затронут следующие типы правил:

• Правила в отношении проверки спецификации OpenAPI
• Правила, поддерживающие запросы JSONPath
• Правила Java для выносок, которые зависят от устаревших библиотек.
• OpenLDAP
• Изменения поставщика криптографических услуг

Вы также можете использовать инструмент обнаружения изменений, чтобы выявить изменения в прокси, общих потоках или других артефактах в кластере, которые могут вызвать сбои в результате обновления.

Подробное описание изменений

В этом разделе описаны изменения, внесенные в версии 4.53.01, которые могут нарушить ваши рабочие процессы во время или после обновления. Также рассматриваются методы выявления потенциальных проблемных областей и методологии смягчения последствий или обходных решений.

Правила проверки спецификации OpenAPI

Контекст

Правила проверки OAS проверяют входящие запросы или ответы на соответствие правилам, определенным в спецификации OpenAPI 3.0 (JSON или YAML). В версии Edge for Private Cloud 4.53.01 улучшены правила OAS (спецификации OpenAPI). Теперь они обеспечивают более строгую и точную проверку тела ответа API.

Изменения

В версии Edge for Private Cloud 4.53.01 внесены два важных изменения в то, как правила OAS проверяют ответы API. Это позволяет обеспечить более точное соответствие спецификации 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.
• Правила проверки OAS проверяют ответ, полученный от других правил, которые генерируют ответы.

Если вы используете инструмент, он сгенерирует ответ в следующем формате:

Подробное описание столбцов в выходной таблице приведено в разделе Как интерпретировать результаты работы инструмента.

После того как вы определите прокси-сервер или общий поток, убедитесь, что ответ и спецификация OAS согласованы в отношении наличия или отсутствия тела ответа. Чтобы изучить закономерности трафика, можно использовать стандартную трассировку Apigee. Если целевой сервис периодически возвращает ответ, используйте другие правила для проверки ответа до того, как он будет передан правилу проверки OAS.

• Если в файле спецификации OAS определено тело ответа, ответ от целевого или вышестоящего правила всегда должен его содержать.
• Если в файле спецификации OAS не определено тело ответа, целевое или вышестоящее правило не должно его отправлять.

При необходимости обновите правила проверки OAS или целевое поведение, прежде чем пытаться выполнить обновление до версии Private Cloud 4.53.01. Чтобы свести к минимуму риск сбоев при обновлении рабочего кластера, сначала проверьте выявленные рабочие процессы в нерабочих средах.

Путь JSON

Контекст

В Edge для частного облака 4.53.01 внесены изменения в то, как выражения пути JSON используются в различных правилах. Выражения JSONPath можно использовать в правилах, например ExtractVariable, RegularExpressionProtection и Data masking, чтобы анализировать контент JSON или сохранять значения в переменных. Выражения JSONPath также можно использовать в шаблонах сообщений, чтобы динамически заменять переменные значениями во время выполнения прокси. Новые выражения и форматы JSONPath соответствуют последним стандартам JSON.

Изменения

Важно проверить существующие прокси API и общие потоки на наличие правил, в которых используются выражения JSONPath. Сюда относятся, в частности, правила извлечения переменных, защиты регулярных выражений и любые правила с шаблоном сообщения, использующим 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}). Значение этих переменных также необходимо проверить на предмет возможных изменений в поведении, описанных выше.

Подавление

Определите, какие прокси или общие потоки могут быть затронуты обновлением, с помощью инструмента обнаружения изменений или вручную, проверив прокси API на наличие описанных выше шаблонов. Если вы используете этот инструмент, в выходных данных будут указаны затронутый прокси-сервер или общий поток, соответствующие правила и все проблемные пути JSON, как показано в примере ниже:

Подробное описание столбцов в таблице выше приведено в разделе Как интерпретировать результаты работы инструмента.

Чтобы снизить риск, необходима комплексная стратегия. В ходе этого процесса необходимо выбрать подходящий путь обновления и применить необходимые исправления для обнаруженных выражений JSONPath.

Выберите подходящий способ перехода:

• Перенос без простоя

  Эта стратегия предполагает приобретение одной или нескольких новых сред, чтобы подключить к ним отдельные узлы обработчика сообщений. Такие узлы обработчика сообщений можно настроить на установку версии 4.53.01 и использовать прокси с современными выражениями JSONPath. Их можно использовать во время обновления, а после его завершения – отключить. Эта стратегия не требует от вас никаких действий, но предполагает временное приобретение дополнительных узлов обработчика сообщений для обеспечения плавного обновления. Подробная информация приведена ниже.

  • Создайте новую среду и добавьте в нее новые узлы обработчика сообщений версии 4.53.01.
  • Загрузите пакет прокси для затронутых прокси в новую среду и примените необходимые исправления, описанные в разделе "Устранение неполадок", а затем разверните обновленный пакет прокси в новой среде.
  • Перенаправьте трафик в новую среду и отмените развертывание затронутых прокси-серверов в старой среде.
  • Обновите исходные узлы обработчика сообщений до версии 4.53.01. Разверните прокси-серверы с исправлениями для JSONPath в исходной среде.
  • Переключите трафик обратно на старую среду, в которой теперь есть процессоры сообщений версии 4.53.01 и прокси-сервер, модернизированный для новых выражений jsonpath.
  • Удалите новую среду и связанные с ней узлы.
• Время простоя и обновления

  Эта стратегия предполагает, что прокси API будут недоступны из-за неверных выражений JSON Path. Это не требует приобретения дополнительных узлов обработчика сообщений, но приводит к сбоям в трафике API для затронутых прокси.

  • Определите прокси-серверы, на которые распространяются правила, и создайте новую версию для всех этих прокси-серверов.
  • Примените необходимые исправления, реализовав решения, описанные в разделе "Устранение неполадок", в новой версии прокси-сервера. Пока не развертывайте его.
  • Обеспечьте время простоя для прокси-сервера или серверов, которые влияют на работу.
  • Обновите все процессоры сообщений до версии Edge для частного облака 4.53.01. Обратите внимание, что существующие прокси-серверы могут не работать на обновленных процессорах сообщений.
  • После того как все процессоры сообщений будут обновлены до версии Edge для частного облака 4.53.01 , разверните новую версию прокси с исправленным выражением JSONPath.
  • Возобновить трафик на таких прокси-серверах.
• Измените прокси-сервер перед обновлением

  Вы можете переработать сам прокси-сервер до обновления до Edge для частного облака 4.53.01. Вместо того чтобы полагаться на определенные выражения пути JSON, вы можете получить тот же результат, используя другой метод.

  Например, если вы используете правило извлечения переменной с путем JSON, вы можете заменить его правилом JavaScript, которое извлекает похожие данные, прежде чем переходить на более новую версию. После завершения преобразования вы можете снова использовать JSON-пути с новыми форматами.

Изменения в JavaCallout

Контекст

В Edge для частного облака версии 4.53.00 и более ранних версий был каталог deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated), в котором хранились библиотеки JAR. Эти библиотеки были доступны для использования в коде Java в правиле JavaCallout и могли использоваться вашим пользовательским кодом Java напрямую или косвенно.

Изменения

Каталог deprecated теперь удален в Edge для частного облака версии 4.53.01. Если ваш код Java опирается на такие библиотеки, прокси-серверы, использующие такие вызовы Java, будут работать некорректно после обновления процессоров сообщений до версии 4.53.01. Чтобы избежать таких сбоев, выполните описанные ниже действия до обновления процессоров сообщений до версии 4.53.01.

Подавление

1. Проверьте правила Java Callout и связанные с ними JAR-файлы с помощью инструмента обнаружения изменений или вручную. Проверьте, не упоминаются ли в правилах библиотеки, которые находятся в каталоге "deprecated" текущих обработчиков сообщений.

   Если вы используете инструмент, предоставленный Apigee, для обнаружения вышеуказанных проблем, он создаст отчет, как показано в таблице ниже . В частности, оно предназначено для правил, в которых упоминаются JAR-файлы, находящиеся в каталоге $APIGEE_ROOT/edge-message-processor/lib/deprecated более ранних версий Edge для частного облака.

   Инструмент создает отчеты в следующем формате:

   Организация	Среда	Название объекта	Тип объекта	Версия	Название политики	Тип политики	Тип влияния	Поле "Влияние"	Достоверность влияния	Документация
   org1	Нет	Нет	org-level-jar	Нет	Нет	java-callout	Обнаружена устаревшая библиотека для simple-javacallout-o1-jar-1.jar	['Обнаружено использование класса org.apache.commons.io.FileUtils из commons-io-2.5.jar, обнаружено использование класса org.apache.commons.io.input.XmlStreamReaderException из commons-io-2.5.jar']	Высокий	Изменения в JavaCallout
   org3	env3	Нет	env-level-jar	Нет	Нет	java-callout	Обнаружена устаревшая библиотека для fat-javacallout-e3-jar-1.jar	['Обнаружено использование класса org.apache.http.impl.auth.NTLMSchemeFactory из httpclient-4.5.2.jar']	Высокий	Изменения в JavaCallout
   org1	env1	p1	proxy-level-jar	1	Нет	java-callout	Обнаружена устаревшая библиотека для simple-javacallout-p1-jar-1.jar	['Обнаружено использование класса org.apache.commons.lang3.builder.ToStringBuilder из commons-lang3-3.4.jar', 'Обнаружено использование класса org.apache.commons.lang3.Validate из commons-lang3-3.4.jar']	Высокий	Изменения в JavaCallout

   Подробное описание столбцов в таблице выше приведено в разделе Как интерпретировать результаты работы инструмента.

2. После того как вы определите устаревшие библиотеки , вы можете устранить проблему одним из следующих способов:
   • Размещение ресурсов (рекомендуется, если у вас небольшое количество JAR-файлов или библиотек из устаревшего каталога, на которые ссылаются JAR-файлы Java-Callout)
     • Загрузите определенные устаревшие JAR-файлы в качестве ресурса на нужном уровне: редакции прокси-сервера API, среды или организации.
     • Выполните обновление ПО Apigee обычным способом.
   • Размещение вручную (рекомендуется, если у вас много JAR-файлов или библиотек, на которые ссылаются JAR-файлы Java-Callout)
     • На каждом узле обработчика сообщений создайте новый каталог external-lib по пути $APIGEE_ROOT/data/edge-message-processor/.
     • Скопируйте найденные JAR-файлы в каталог external-lib из устаревшего каталога: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
     • Убедитесь, что каталог и файлы JAR доступны для чтения пользователю Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib.
     • Выполните обновление ПО Apigee обычным способом.

Изменения в OpenLDAP

Контекст

OpenLDAP можно использовать в Edge Private Cloud как для аутентификации, так и для авторизации. В Edge для частного облака 4.53.01 ПО OpenLDAP, поставляемое Apigee, было обновлено с версии 2.4 до 2.6.

Изменения

В OpenLDAP 2.6 относительное уникальное имя (RDN) ограничено примерно 241 байтом/символом. Это ограничение нельзя изменить.

• При репликации или импорте записей с очень большими RDN возникают ошибки.
• При попытке создать объекты, например организации, среды, специальные роли, разрешения и т. д., может появиться сообщение об ошибке "message": "[LDAP: error code 80 - Other]".
• Проблема затрагивает все различающиеся имена длиной более 241 байта в LDAP Apigee. Такие различающиеся имена не позволят успешно обновить программное обеспечение Apigee OpenLDAP, и вам придется следовать стратегиям устранения неполадок для таких элементов, прежде чем вы сможете продолжить обновление.

Как правило, в LDAP Apigee длинные различающиеся имена связаны с разрешениями, поскольку они создаются путем объединения нескольких объектов. Такие записи разрешений особенно подвержены проблемам при обновлении.

Пример:

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

Как правило, названия организаций, сред и ролей имеют такую длину, что относительные уникальные имена в LDAP не превышают 241 байт.

Подавление

Перед обновлением до версии 4.53.01

Чтобы проверить наличие длинных относительных различающихся имен в существующем кластере 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

Инструмент обнаружения изменений использует сгенерированный LDIF-файл, чтобы определить RDN LDAP, превышающие 241 байт/символ.

Инструмент будет создавать отчеты в следующем формате:

Подробное описание столбцов в таблице выше приведено в разделе Как интерпретировать результаты работы инструмента.

Если команда выше не выдает никаких результатов, значит ни один из RDN в существующей конфигурации LDAP не превышает 241 байт/символ. Вы можете продолжить обновление как обычно.

Если указанная выше команда выдает результат, это означает, что в сертификате есть RDN, длина которых превышает 241 байт/символ. Для таких объектов выполните действия по устранению неполадок, описанные в шаге 3, прежде чем переходить на Edge для частного облака 4.53.01.

3. Обрабатывайте длинные имена RDN

Если на шаге 2 вы получили выходные данные, это означает, что в RDN превышено ограничение в 241 байт/символ. В этом случае выполните следующие действия:

Проверьте записи LDAP, размер которых превышает 241 байт.

• Если длинное имя RDN вызвано названием специальной роли, приложения, продукта API или другого объекта, перейдите на использование альтернативного объекта с более коротким названием.
• Если длинное относительное различающееся имя в основном обусловлено названием организации или среды, вам придется перейти в другую организацию или среду с более коротким названием.

Повторяйте описанные выше действия, пока в LDAP не останется RDN длиной более 241 байта. После этого можно будет обновить версию личного облака обычным способом.

Изменения поставщика криптографических услуг

Контекст

Это изменение перенесено из Edge для частного облака 4.53.00. В Edge для частного облака 4.53.00 внутренний поставщик криптографии был обновлен с Bouncy Castle (BC) до Bouncy Castle FIPS (BCFIPS), чтобы включить поддержку FIPS.

Изменения

Если правила JavaCallout полагаются на использование исходного поставщика BC, особенно при использовании функций безопасности, которые были усилены в поставщике BCFIPS (например, при использовании общей пары ключей для шифрования и подписи), такие правила JavaCallout необходимо модернизировать. Правила JavaCallout, пытающиеся загрузить поставщика криптографии Bouncy Castle с помощью имени BC, могут не работать, поскольку поставщик по умолчанию изменился. В результате правила, в которых используется поставщик BC, могут перестать работать. Все специальные реализации, использующие старого поставщика данных о местоположении, станут недоступны. Их нужно будет проверить и реализовать заново.

Подавление

Рекомендуется использовать поставщика BCFIPS. Реализации Custom JavaCallout, которые полагались на старого поставщика, необходимо пересмотреть и реализовать заново, используя поставщика Bouncy Castle FIPS, доступ к которому можно получить с помощью строки "BCFIPS".

Инструмент обнаружения изменений

Мы создали инструмент обнаружения изменений, который позволяет выявлять прокси Apigee, правила и общие потоки, на которые может повлиять переход на Edge для частного облака 4.53.01. Этот инструмент создает отчет о развернутых прокси, общих потоках и OpenLDAP, на которые повлияли изменения, а также предоставляет ссылки на руководства и стратегии, относящиеся к этим прокси или общим потокам.

Требования

1. Для работы этого инструмента требуется компьютер на базе RHEL.
2. На хост-виртуальной машине должна быть установлена и правильно настроена JRE 8, чтобы скрипты инструмента могли выполняться.
3. Для работы инструмента требуется правильная конечная точка (URL) сервера управления и действительные учетные данные администратора для аутентификации и получения данных.
4. Для извлечения пакетов, создания журналов и хранения выходных данных инструменту требуется доступ к указанному рабочему каталогу (например, /tmp). Убедитесь, что в этом каталоге достаточно места на диске и есть необходимые разрешения на чтение и запись.
5. Для обнаружения длинных RDN (более 241 символа или байта) инструмент требует LDIF-файл, созданный с помощью команды ldapsearch в разделе OpenLDAP change - Extract LDAP data (Изменение OpenLDAP – извлечение данных LDAP).

Как запустить инструмент

После того как вы выполните все перечисленные выше требования, скачайте инструмент, указав имя пользователя и пароль от Apigee, которые вы используете для доступа к репозиторию Apigee. После скачивания извлеките файлы из архива.

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.1.zip -o /tmp/change-detector-for-4.53.01_1.0.1.zip

unzip /tmp/change-detector-for-4.53.01_1.0.1.zip

После завершения загрузки вы можете выполнить следующую команду, чтобы посмотреть все доступные варианты инструмента:

./change-detector --help

Чтобы запустить инструмент, используйте следующую команду, заменив плейсхолдеры своей информацией:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

Чтобы обнаружить большие записи RDN LDAP, выполните следующую команду:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

Инструмент создает выходные данные в формате JSON или CSV, которые можно напрямую использовать или импортировать в удобный для восприятия инструмент, например Google Таблицы.

Как интерпретировать результаты работы инструмента

Организация

Указывает на название организации, в которой находится артефакт. Для OpenLDAP это будет None.

Среда

Определенная среда (например, dev, test, prod) в организации. Для OpenLDAP это будет None.

Если тип объекта – env-level-jar, то для изменений вызова Java это поле будет иметь значение None.

Название объекта

В этом поле указано название прокси-сервера или общего потока. Для изменения OpenLDAP в этом поле отображается объект LDAP RDN.

Если для изменений вызова Java в поле "Тип артефакта" указано значение env-level-jar или org-level-jar, то в этом поле будет указано значение None.

Тип объекта

• Для изменений OAS и JSON в этом столбце указывается тип артефакта: прокси или общий поток.
• В случае с изменением Java Callout в этом столбце приводится информация о месте или уровне, на котором был загружен затронутый JAR-файл. Ресурсы (JAR-файлы) можно хранить на одном из трех уровней: org-level, env-level, proxy-level.
• В случае с OpenLDAP это поле указывает на файл LDIF, используемый в инструменте.

Версия

Она указывает на развернутую версию затронутого прокси-сервиса или общего потока. Для OpenLDAP это будет None.

Название политики

Название правила, которое может быть нарушено. Для OpenLDAP это будет None.

Тип политики

Указывает на тип правил. Для OpenLDAP это будет None.

Тип влияния

• В этом поле описывается тип изменений, обнаруженных в прокси-сервере или общем потоке.
• При обнаружении изменений, связанных с вызовами Java, инструмент указывает на затронутый вызов Java, который ссылается на JAR-файлы, присутствующие в каталоге $APIGEE_ROOT/edge-message-processor/lib/deprecated более старых версий Edge для частного облака, следующим образом:

deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR

• Если вы используете OpenLDAP, в этом поле будет указано, превышает ли RDN какого-либо объекта LDAP 241 байт или символ.

Поле, относящееся к влиянию

• В случае изменения спецификации OAS это поле содержит название переменной, используемой в теге Источник правила.
• Если проблема связана с JSON, в этом поле будет указано точное выражение JSONPath или элемент, который был отмечен как потенциальная проблема.
• Для изменения Java Callout в этом поле содержатся сведения о классах и название соответствующего JAR-файла (присутствует в каталоге $APIGEE_ROOT/edge-message-processor/lib/deprecated более ранних версий частного облака), используемого/упоминаемого в затронутом JAR-файле JavaCallout, что приведет к сбоям при обновлении до версии 4.53.01, если не принять меры.

 ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
    Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
  .. , .. , ]

• В случае с OpenLDAP в этом поле отображается RDN объекта LDAP, длина которого превышает 241 байт или символ.

Вероятность влияния

• В этом поле указана степень уверенности, с которой инструмент обнаружил определенный объект. В этом столбце могут быть указаны значения Высокий или Средний (в будущем могут быть добавлены другие значения).

  Значение Высокая означает, что инструмент определил очень высокую вероятность того, что после обновления до версии 4.53.01 элемент приведет к сбою приложения. Значение Средний указывает на то, что инструмент не может однозначно определить наличие уязвимости и для этого потребуется больше стратегий (например, захват трассировки для наблюдения за разрешенными переменными во время выполнения прокси).

• Для обнаружений, связанных с изменениями JavaCallout и OpenLDAP, в столбцах "Вероятность влияния" всегда будет указано значение Высокая.

Документация

В этом столбце приведена ссылка на документацию Apigee (соответствующие разделы этой статьи), в которой описана проблема и способы ее устранения.