Правила мониторинга - Аналитика уязвимостей сторонних компонентов

Что вы найдете на этой странице

• Способы определения правил мониторинга
• Как настроить новые правила мониторинга
• Как настроить классические правила мониторинга устарело
• Как правила мониторинга влияют на покрытие
• Примеры правил мониторинга с использованием атрибутов и меток
• Часто задаваемые вопросы

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

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

Критерии мониторинга

В настоящее время существует два способа настройки правил мониторинга:

• На основе атрибутов ресурсов и меток Kubernetes Рекомендуется

• Подробнее см. в разделе Новые правила мониторинга.

• На основе тегов группы процессов, тегов хоста и зон управления

• Подробнее см. в разделе Классические правила мониторинга.

Чтобы начать мониторинг на основе ваших правил, необходимо активировать соответствующие критерии мониторинга. Два критерия не могут действовать одновременно. При активации одного другой деактивируется. Вы можете переключаться между ними в любое время.

Для сред, созданных на Dynatrace версии 1.313+, классические правила мониторинга на основе тегов группы процессов, тегов хоста и зон управления недоступны; вы можете настроить правила мониторинга на основе атрибутов ресурсов и меток Kubernetes.

Активация предпочтительных критериев мониторинга

Чтобы активировать предпочтительный способ определения мониторинга

1. В Dynatrace перейдите в Settings > Analyze and alert > Application Security > General settings > Third-party Vulnerability Analytics.

2. Выполните одно из следующих действий:

3. Чтобы активировать новые правила, включите Enable new monitoring rules.

4. Чтобы активировать классические правила, выключите Enable new monitoring rules.

Ваша настройка сохранится до тех пор, пока вы не измените ее снова.

Для сред, созданных на Dynatrace версии 1.313+, новые правила мониторинга активированы по умолчанию (никаких действий с вашей стороны не требуется).

Новые правила мониторинга

Рекомендуется

С помощью новых правил мониторинга вы можете определить, какие процессы, узлы Kubernetes и хосты должны отслеживаться.

• Правила для процессов основаны на атрибутах ресурсов.
• Правила для узлов Kubernetes и хостов основаны на метках Kubernetes.

Атрибуты ресурсов, связанные с Kubernetes (например, k8s.cluster.uid), применяются к группам процессов, а не к узлам Kubernetes. Чтобы включить или исключить узлы Kubernetes или хосты из мониторинга, необходимо определить правила на основе меток Kubernetes. Если вы настроите только правила на основе атрибутов ресурсов, узлы Kubernetes могут продолжать отслеживаться и генерировать использование, даже если связанные группы процессов исключены.

Определение правил

Вы можете определить новые правила мониторинга через веб-интерфейс Dynatrace или Settings API.

В Dynatrace

Правила для процессов

Правила для узлов Kubernetes и хостов

1. В Dynatrace перейдите в Settings > Analyze and alert > Application Security > Rules for third-party vulnerabilities (New).
2. На вкладке Resource attribute monitoring rules (...) выберите Add new rule.
3. Следуйте инструкциям на экране.

Поля ключа и значения условия являются полями свободного ввода текста. Подсказки на экране не являются обязательными. 4. Выберите Preview matching process group instances, чтобы убедиться, что условие соответствует ожидаемым процессам.

Все условия правила должны совпасть, чтобы правило применилось. 5. Выберите Save changes.

Для использования правил мониторинга на основе меток Kubernetes необходимо включить мониторинг Kubernetes.

1. В Dynatrace перейдите в Settings > Analyze and alert > Application Security > Rules for third-party vulnerabilities (New).
2. На вкладке Kubernetes monitoring rules (...) выберите Add new rule.
3. Следуйте инструкциям на экране.

Поля ключа и значения условия являются полями свободного ввода текста. Подсказки на экране не являются обязательными. 4. Выберите Preview matching Kubernetes nodes and hosts, чтобы убедиться, что условие соответствует ожидаемым узлам Kubernetes и хостам.

Все условия правила должны совпасть, чтобы правило применилось. 5. Выберите Save changes.

Чтобы начать мониторинг на основе предпочтительного критерия мониторинга, убедитесь, что он активирован.

Вы можете редактировать, отключать, включать или удалять правила в любое время.

Через Settings API

Вы можете просматривать или изменять правила с помощью Settings API.

Правила для процессов

Правила для узлов Kubernetes и хостов

• Чтобы просмотреть правило мониторинга, используйте запрос GET an object. Установите следующие параметры:

• schemaIds=builtin:appsec.third-party-vulnerability-rule-settings

• scopes=tenant

Пример ответа JSON

{


"items": [


{


"objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACQ1YWYzOWNiZC0xM2I0LTNlZmItYTViYi1iYzljNTgyOTQxNze-71TeFdrerQ",


"value": {


"enabled": true,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_OFF"


},


"resourceAttributeConditions": [


{


"resourceAttributeKey": "dt.entity.host",


"matcher": "EQUALS",


"resourceAttributeValue": "HOST-ABD42981B3D483AC"


}


],


"metadata": {


"comment": ""


}


}


},


{


"objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACQ4NDQ1OGRjNC1lM2Q2LTM2MGYtOWQyYy1lNmYwMTY1MzAwMza-71TeFdrerQ",


"value": {


"enabled": false,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_ON"


},


"resourceAttributeConditions": [


{


"resourceAttributeKey": "attribute_2",


"matcher": "EXISTS"


}


],


"metadata": {


"comment": ""


}


}


},


{


"objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACRjNzk3M2I4YS1kYmFjLTMxMzAtYjdjMy0zYjYxNGMxOWU1NzK-71TeFdrerQ",


"value": {


"enabled": false,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_OFF"


},


"resourceAttributeConditions": [


{


"resourceAttributeKey": "my.app.name",


"matcher": "EQUALS",


"resourceAttributeValue": "cool-app"


}


],


"metadata": {


"comment": ""


}


}


}


],


"totalCount": 3,


"pageSize": 100


}

* Чтобы изменить правило мониторинга, используйте запрос POST an object.

Пример тела запроса JSON

[


{


"value": {


"enabled": true,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_OFF"


},


"resourceAttributeConditions": [


{


"resourceAttributeKey": "dt.entity.host",


"matcher": "EQUALS",


"resourceAttributeValue": "HOST-ABD42981B3D483AC"


}


],


"metadata": { "comment": "" }


},


"schemaId": "builtin:appsec.third-party-vulnerability-rule-settings",


"scope": "tenant"


},


{


"value": {


"enabled": false,


"vulnerabilityDetectionControl": { "monitoringMode": "MONITORING_ON" },


"resourceAttributeConditions": [


{


"resourceAttributeKey": "attribute_2",


"matcher": "EXISTS"


}


],


"metadata": { "comment": "" }


},


"schemaId": "builtin:appsec.third-party-vulnerability-rule-settings",


"scope": "tenant"


},


{


"value": {


"enabled": false,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_OFF"


},


"resourceAttributeConditions": [


{


"resourceAttributeKey": "my.app.name",


"matcher": "EQUALS",


"resourceAttributeValue": "cool-app"


}


],


"metadata": {


"comment": ""


}


},


"schemaId": "builtin:appsec.third-party-vulnerability-rule-settings",


"scope": "tenant"


}


]

• Чтобы просмотреть правило мониторинга, используйте запрос GET an object. Установите следующие параметры:

• schemaIds=builtin:appsec.third-party-vulnerability-kubernetes-label-rule-settings

• scopes=tenant

Пример ответа JSON

{


"items": [


{


"objectId": "vu9U3hXa3q0AAAABAEdidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LWt1YmVybmV0ZXMtbGFiZWwtcnVsZS1zZXR0aW5ncwAGdGVuYW50AAZ0ZW5hbnQAJDBhZDRhNTRjLWY3MDMtM2M2OC1iOTQ5LTkxNTA2YTc2Mzc5Zr7vVN4V2t6t",


"value": {


"enabled": true,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_ON"


},


"kubernetesLabelConditions": [


{


"kubernetesLabelKey": "dummy-label",


"matcher": "CONTAINS",


"kubernetesLabelValue": "HOST"


},


{


"kubernetesLabelKey": "dummy-label",


"matcher": "STARTS_WITH",


"kubernetesLabelValue": "value:"


},


{


"kubernetesLabelKey": "dummy-label",


"matcher": "EQUALS",


"kubernetesLabelValue": "HOST-1C2B7B7A2613CBFD"


}


],


"metadata": {


"comment": ""


}


}


}


],


"totalCount": 1,


"pageSize": 100


}

* Чтобы изменить правило мониторинга, используйте запрос POST an object.

Пример тела запроса JSON

[


{


"value": {


"enabled": true,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_OFF"


},


"kubernetesLabelConditions": [


{


"kubernetesLabelKey": "kubernetes.io/os",


"matcher": "EQUALS",


"kubernetesLabelValue": "linux"


}


],


"metadata": {


"comment": ""


}


},


"schemaId": "builtin:appsec.third-party-vulnerability-kubernetes-label-rule-settings",


"scope": "tenant"


},


{


"value": {


"enabled": true,


"vulnerabilityDetectionControl": {


"monitoringMode": "MONITORING_OFF"


},


"kubernetesLabelConditions": [


{


"kubernetesLabelKey": "dummy-label",


"matcher": "CONTAINS",


"kubernetesLabelValue": "HOST"


},


{


"kubernetesLabelKey": "dummy-label",


"matcher": "STARTS_WITH",


"kubernetesLabelValue": "value:"


},


{


"kubernetesLabelKey": "dummy-label",


"matcher": "EQUALS",


"kubernetesLabelValue": "HOST-1C2B7B7A2613CBFD"


}


],


"metadata": {


"comment": ""


}


},


"schemaId": "builtin:appsec.third-party-vulnerability-kubernetes-label-rule-settings",


"scope": "tenant"


}


]

Оценка правил мониторинга

После добавления, редактирования или удаления правила может потребоваться до 10 минут для вступления изменений в силу по всей системе. Настроенные правила мониторинга оцениваются периодически (при внутренних запусках) и по запросу (через вызовы REST API).

Исключение: после исключения ранее отслеживаемой сущности из мониторинга может потребоваться до 70 минут для вступления изменений в силу по всей системе. Подробнее см. в разделе Как рассчитывается покрытие хостов.

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

• Если правило соответствует конкретной сущности, используется настроенный режим (Мониторинг или Не отслеживать), и последующие правила для этой конкретной сущности не оцениваются.
• Если ни одно правило не соответствует конкретной сущности, используется настроенный режим по умолчанию (Мониторинг или Не отслеживать).

Классические правила мониторинга

Хотя классические правила на основе зон управления и тегов продолжают работать, их планируется объявить устаревшими. Мы настоятельно рекомендуем перейти на новые правила на основе атрибутов ресурсов или меток Kubernetes. Автоматическая миграция невозможна; подробнее см. в разделе Часто задаваемые вопросы.

Классические правила мониторинга основаны на тегах группы процессов, тегах хоста и зонах управления.

Определение правил

Вы можете определить классические правила мониторинга через веб-интерфейс Dynatrace или Settings API.

В Dynatrace

Чтобы добавить новое правило

1. Перейдите в Settings > Analyze and alert > Application Security > Rules for third-party vulnerabilities classic.
2. Выберите Add new rule, чтобы добавить новое правило.
3. Введите запрашиваемую информацию (режим, свойство, оператор условия и значение условия).

Свойство Process tag применяется к группам процессов, а не к процессам. 4. Выберите Save changes.

Вы можете редактировать, отключать, включать или удалять правила в любое время.

Через Settings API

Вы можете просматривать или изменять правила с помощью Settings API.

• Чтобы просмотреть правило мониторинга, используйте запрос GET an object. Установите следующие параметры:

• schemaIds=builtin:appsec.rule-settings

• scopes=tenant

Пример ответа JSON

{


"items": [


{


"objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkYTc4NjY0NGItZmVjNC0zNzliLWI0MWItNThmYzgzOWZmYWY5vu9U3hXa3q0",


"value": {


"enabled": true,


"mode": "MONITORING_OFF",


"property": "PROCESS_TAG",


"operator": "EQUALS",


"value": "super secret process"


}


},


{


"objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkNDhkZGYxNDMtYzc2Mi0zYzIwLWI1ODAtNTNhODEwOGZlMDBivu9U3hXa3q0",


"value": {


"enabled": true,


"mode": "MONITORING_ON",


"property": "HOST_TAG",


"operator": "NOT_EQUALS",


"value": "Test"


}


},


{


"objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkNmY1NjZkNmItYWMyNy0zOTg2LWE1OGItNTU2ZTI1NTE5NTcyvu9U3hXa3q0",


"value": {


"enabled": false,


"mode": "MONITORING_ON",


"property": "MANAGEMENT_ZONE",


"operator": "EQUALS",


"value": "Monitorme"


}


}


],


"totalCount": 3,


"pageSize": 100


}

* Чтобы изменить правило мониторинга, используйте запрос POST an object.

Пример тела запроса JSON

[


{


"value": {


"enabled": true,


"mode": "MONITORING_ON",


"property": "HOST_TAG",


"operator": "EQUALS",


"value": "REST"


},


"scope": "tenant",


"schemaId": "builtin:appsec.rule-settings"


},


{


"value": {


"enabled": true,


"mode": "MONITORING_OFF",


"property": "PROCESS_TAG",


"operator": "NOT_EQUALS",


"value": "Test-Process"


},


"scope": "tenant",


"schemaId": "builtin:appsec.rule-settings"


}


]

Для сред Kubernetes необходимо добавить теги как на хост, так и на узел Kubernetes.

Оценка правил мониторинга

• После добавления, редактирования или удаления правила может потребоваться до 15 минут для вступления изменений в силу по всей системе. Настроенные правила мониторинга оцениваются периодически (при внутренних запусках) и по запросу (через вызовы REST API).

Независимо от контекста вызова, оценка правил остается одинаковой: для заданного набора сущностей алгоритм решает, должна ли конкретная сущность отслеживаться. Правила обрабатываются по порядку до первого совпадения. Мы рекомендуем делать каждое правило уникальным. * Если у вас есть правило для зоны управления или тега, и вы добавляете сущность в ту же зону управления или добавляете тот же тег к сущности, может потребоваться до 15 минут (или дольше для более сложных сред), пока изменение не отразится в вашем правиле мониторинга.

Например, если у вас есть правило Не отслеживать, если тег хоста равен 'testsystem', и вы добавляете тег testsystem к хосту, может потребоваться до 15 минут, пока вновь отмеченный хост не перестанет отслеживаться. * Если правило соответствует конкретной сущности, используется настроенный режим (Мониторинг, Не отслеживать), и последующие правила для этой конкретной сущности не оцениваются. * Если ни одно правило не соответствует конкретной сущности, используется глобальный режим контроля обнаружения уязвимостей сторонних компонентов.

Влияние на покрытие

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

Последняя версия Dynatrace Для обзора того, как ваши правила мониторинга влияют на общее покрытие, см. Оценка покрытия.

Сценарии использования для новых правил мониторинга

Ниже приведены некоторые распространенные сценарии определения правил мониторинга для уязвимостей сторонних компонентов на основе атрибутов ресурсов и меток Kubernetes.

Мониторинг только процессов на определенных хостах

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.
2. Найдите хост, на котором вы хотите отслеживать процессы (например, через Infrastructure & Operations).
3. Скопируйте имя хоста (например, exchange.mycompany.local) из обзора.

4. Добавьте новое правило мониторинга на основе атрибутов ресурсов:

5. Установите Third-party vulnerability control в значение Monitor.

6. Выберите Add new condition и введите следующие данные:

   • Resource attribute key: host.name
   • Matcher: equals
   • Resource attribute value: имя хоста из шага 3.
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым процессам.
   • Сохраните правило.

Мониторинг только Java-процессов на определенных хостах

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.
2. Найдите хост, на котором вы хотите отслеживать процессы (например, через Infrastructure & Operations).
3. Скопируйте имя хоста (например, exchange.mycompany.local) из обзора.

4. Добавьте новое правило мониторинга на основе атрибутов ресурсов:

5. Установите Third-party vulnerability control в значение Monitor.

6. Чтобы создать условие, соответствующее хосту, выберите Add new condition и введите следующие данные:

   • Resource attribute key: host.name
   • Matcher: equals
   • Resource attribute value: имя хоста из шага 3.

   • Чтобы создать условие, соответствующее технологии, выберите Add new condition и введите следующие данные:

   • Resource attribute key: java.main.class

   • Matcher: exists
   • Проверьте предварительный просмотр, чтобы убедиться, что условия соответствуют ожидаемым процессам.
   • Сохраните правило.

Исключение .NET-процессов определенных хостов из мониторинга

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Monitor.
2. Найдите хост, на котором вы хотите отслеживать процессы (например, через Infrastructure & Operations).
3. Скопируйте имя хоста (например, exchange.mycompany.local) из обзора.

4. Добавьте новое правило мониторинга на основе атрибутов ресурсов:

5. Установите Third-party vulnerability control в значение Do not monitor.

6. Чтобы создать условие, соответствующее хосту, выберите Add new condition и введите следующие данные:

   • Resource attribute key: host.name
   • Matcher: equals
   • Resource attribute value: имя хоста из шага 3.

   • Чтобы создать условие, соответствующее технологии, выберите Add new condition и введите следующие данные:

   • Resource attribute key: dotnet.dll.file

   • Matcher: exists
   • Проверьте предварительный просмотр, чтобы убедиться, что условия соответствуют ожидаемым процессам.
   • Сохраните правило.

Мониторинг только процессов с пользовательским атрибутом ресурса

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.
2. Добавьте пользовательские атрибуты ресурсов (например, {"stage":"production"}) к вашим сущностям.

3. Добавьте новое правило мониторинга на основе атрибутов ресурсов:

4. Установите Third-party vulnerability control в значение Monitor.

5. Выберите Add new condition и введите следующие данные:

   • Resource attribute key: ключ пользовательского атрибута ресурса из шага 2 (например, stage)
   • Matcher: equals
   • Resource attribute value: значение пользовательского атрибута ресурса из шага 2 (например, production)
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым процессам.
   • Сохраните правило.

Мониторинг только процессов определенной группы процессов

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.
2. Найдите группу процессов, в которой вы хотите отслеживать процессы (например, через приложение Technologies & Processes Classic).
3. Скопируйте идентификатор группы процессов (например, PROCESS_GROUP-0123456789ABCDEF) из URL.

4. Добавьте новое правило мониторинга на основе атрибутов ресурсов:

5. Установите Third-party vulnerability control в значение Monitor.

6. Выберите Add new condition и введите следующие данные:

   • Resource attribute key: dt.entity.process_group
   • Matcher: equals
   • Resource attribute value: идентификатор группы процессов из шага 3.
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым процессам.
   • Сохраните правило.

Мониторинг только процессов, работающих в определенном пространстве имен Kubernetes

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.

2. Добавьте новое правило мониторинга на основе атрибутов ресурсов:

3. Установите Third-party vulnerability control в значение Monitor.

4. Выберите Add new condition и введите следующие данные:

   • Resource attribute key: k8s.namespace.name
   • Matcher: equals
   • Resource attribute value: имя пространства имен, которое должно отслеживаться
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым процессам.
   • Сохраните правило.

Мониторинг только узлов Kubernetes и хостов с ОС на базе Linux для уязвимостей Kubernetes

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.

2. Добавьте новое правило мониторинга Kubernetes:

3. Установите Third-party vulnerability control в значение Monitor.

4. Выберите Add new condition и введите следующие данные:

   • Kubernetes label key: kubernetes.io/os
   • Matcher: equals
   • Kubernetes label value: linux
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым узлам Kubernetes.
   • Сохраните правило.

Мониторинг только экземпляров EC2 для уязвимостей Kubernetes

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.

2. Добавьте новое правило мониторинга Kubernetes:

3. Установите Third-party vulnerability control в значение Monitor.

4. Выберите Add new condition и введите следующие данные:

   • Kubernetes label key: kubernetes.io/hostname
   • Matcher: ends with
   • Kubernetes label value: .ec2.internal
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым узлам Kubernetes.
   • Сохраните правило.

Исключение узлов на базе ARM из мониторинга уязвимостей Kubernetes

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Monitor.

2. Добавьте новое правило мониторинга Kubernetes:

3. Установите Third-party vulnerability control в значение Do not monitor.

4. Выберите Add new condition и введите следующие данные:

   • Kubernetes label key: kubernetes.io/arch
   • Matcher: contains
   • Kubernetes label value: arm
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым узлам Kubernetes.
   • Сохраните правило.

Мониторинг всех Java-процессов, кроме демонстрационного Java-приложения на хостах разработки

1. В Dynatrace перейдите в Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics и установите Global third-party vulnerability detection control в значение Do not monitor.
2. Скопируйте полное квалифицированное имя (FQN) главного Java-класса вашего демонстрационного приложения (например, com.example.my.DemoMain).
3. Найдите хост разработки, на котором вы не хотите отслеживать процесс демонстрационного приложения (например, через Infrastructure & Operations).
4. Скопируйте имя хоста (например, exchange.mycompany.local) из обзора.

5. Добавьте новое правило мониторинга на основе атрибутов ресурсов, чтобы исключить процесс демонстрационного приложения на хосте разработки:

6. Установите Third-party vulnerability control в значение Do not monitor.

7. Чтобы создать условие, соответствующее хосту разработки, выберите Add new condition и введите следующие данные:

   • Resource attribute key: host.name
   • Matcher: equals
   • Resource attribute value: имя хоста из шага 4.

   • Чтобы создать условие, соответствующее процессу демонстрационного приложения, выберите Add new condition и введите следующие данные:

   • Resource attribute key: java.main.class

   • Matcher: equals
   • Resource attribute value: главный класс из шага 2.
   • Проверьте предварительный просмотр, чтобы убедиться, что условия соответствуют ожидаемым процессам.
   • Сохраните правило.
   • Добавьте новое правило мониторинга на основе атрибутов ресурсов, чтобы отслеживать все оставшиеся Java-процессы:

8. Установите Third-party vulnerability control в значение Monitor.

9. Чтобы создать условие, соответствующее технологии, выберите Add new condition и введите следующие данные:

   • Resource attribute key: java.main.class
   • Matcher: exists
   • Проверьте предварительный просмотр, чтобы убедиться, что условие соответствует ожидаемым процессам.
   • Сохраните правило.

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

Часто задаваемые вопросы

Имеет ли значение порядок правил?

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

Можно ли автоматически перенести существующие классические правила мониторинга на новые?

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

Требуется ли перезапуск процесса после включения или отключения правила мониторинга?

Классические правила мониторинга

Перезапуск не требуется. Для получения дополнительной информации см. Часто задаваемые вопросы: Требуется ли перезапуск после включения или отключения функции или функциональности Application Security?

Что происходит, если добавляется применимое правило Не отслеживать?

Новые правила мониторинга Классические правила мониторинга

• Новые уязвимости для процессов, соответствующих правилу, не будут создаваться.
• Существующие уязвимости, относящиеся только к соответствующим процессам, будут разрешены.

Что происходит, если правило Не отслеживать удаляется или больше не применяется?

Новые правила мониторинга Классические правила мониторинга

• Новые уязвимости для процессов, соответствующих правилу, будут создаваться.
• Связанные разрешенные уязвимости будут повторно открыты.

Связанные темы

• Часто задаваемые вопросы по Application Security