Cette page a été traduite par l'API Cloud Translation.

Présentation de Google Cloud Armor Adaptive Protection

Google Cloud Armor Adaptive Protection vous aide à protéger vos applications, sites Web et services Google Cloud contre les attaques par déni de service distribué (DDoS, Distributed Denial of Service) de couche 7, telles que les inondations de protocole HTTP et les autres activités malveillantes consistant à générer des flux de forte intensité sur la couche 7 (niveau application). Adaptive Protection crée des modèles de machine learning qui permettent de :

détecter les activités anormales et générer les alertes associées ;
générer une signature décrivant l'attaque potentielle ;
générer une règle WAF personnalisée dans Google Cloud Armor pour bloquer la signature.

Vous activez ou désactivez Adaptive Protection à l'échelle de stratégies de sécurité.

Les alertes concernant le trafic anormal (attaques potentielles), qui incluent les signatures des attaques, s'affichent dans le tableau de bord des événements Adaptive Protection, avec les journaux d'événements envoyés à Cloud Logging, où elles peuvent être analysées directement ou transférées vers un workflow en aval de surveillance de journaux ou d'événements liés à la sécurité. Des alertes d'attaques potentielles sont également générées sous forme de résultats dans Security Command Center.

Disponibilité d'Adaptive Protection

Les alertes Adaptive Protection complètes ne sont disponibles que si vous vous abonner à Google Cloud Armor Enterprise. Sinon, vous ne recevrez qu'une alerte de base, sans signature d'attaque ni possibilité de déployer une règle suggérée.

Si vos projets ne sont pas déjà enregistrés dans Cloud Armor Enterprise, consultez Utiliser Cloud Armor Enterprise pour des informations sur la procédure d'inscription.

Cloud Logging et Cloud Monitoring

Étant donné que l'utilisation d'Adaptive Protection nécessite une compréhension efficace du fonctionnement de la journalisation et des alertes dans Google Cloud, nous vous recommandons de vous familiariser avec Cloud Logging, les alertes et les règles d'alerte.

Pour obtenir des informations générales sur la journalisation, consultez la documentation Cloud Logging.
Pour en savoir plus sur les alertes, consultez la documentation Cloud Monitoring.
Pour obtenir des informations sur la journalisation spécifiques à Google Cloud Armor, consultez la section Utiliser la journalisation des requêtes.

Configurer et régler les alertes

Vous pouvez activer Adaptive Protection dans les projets dans lesquels des stratégies de sécurité Google Cloud Armor protègent déjà vos applications. Lorsque vous activez Adaptive Protection pour une stratégie de sécurité particulière, cette fonctionnalité est appliquée à tous les services de backend auxquels la stratégie de sécurité est associée.

Une fois qu'Adaptive Protection est activé, Il faut compter une période d'entraînement d'au moins une heure avant que cette fonctionnalité ne développe une base de référence fiable et commence à surveiller le trafic et générer des alertes. Au cours de la période d'entraînement, Adaptive Protection modélise le trafic entrant et les schémas d'utilisation propres à chaque service de backend, afin de constituer la base de référence pour chaque service de backend. Une fois la période d'entraînement terminée, vous recevez des alertes en temps réel lorsqu'Adaptive Protection identifie des anomalies (fréquence élevée ou volume important) dans le trafic dirigé vers l'un des services de backend associés à cette stratégie de sécurité.

Vous pouvez ajuster les alertes Adaptive Protection en fonction de plusieurs métriques. Les alertes, qui sont envoyées à Cloud Logging, incluent un niveau de confiance, une signature d'attaque, une règle suggérée et une estimation de taux de trafic de référence affecté associé à la règle suggérée.

Le niveau de confiance indique la fiabilité selon laquelle les modèles Adaptive Protection prédisent que le changement observé dans le modèle de trafic est anormal.
Les taux de trafic de référence affectés associés à la règle suggérée représentent le pourcentage du trafic de référence existant qui serait bloqué par la règle. Deux taux sont fournis. Le premier est le pourcentage correspondant au trafic vers le service de backend spécifique ciblé par une attaque. Le second est le pourcentage correspondant à tout le trafic qui passe par la règle de sécurité, y compris toutes les cibles de service de backend configurées (pas seulement celle qui est attaquée).

Vous pouvez filtrer les alertes dans Cloud Logging en fonction du niveau de confiance, des taux de trafic de référence affectés ou des deux. Pour en savoir plus sur le réglage des alertes, consultez la section Gérer les règles d'alerte.

Adaptive Protection vise à protéger les services de backend contre les attaques DDoS de couche 7 à volume élevé. Dans les scénarios suivants, les requêtes ne sont pas comptabilisées dans Adaptive Protection :

Requêtes diffusées directement à partir de Cloud CDN
Requêtes refusées par une stratégie de sécurité Google Cloud Armor

Modèles détaillés

Par défaut, Adaptive Protection détecte une attaque et suggère des mesures d'atténuation en fonction du trafic typique dirigé vers chaque service de backend. Cela signifie que un backend derrière un service de backend peut être surchargé, Adaptive Protection n'effectue aucune action, car le trafic d'attaque n'est pas anormale au niveau du service de backend.

La fonctionnalité de modèles précis vous permet de configurer des hôtes ou chemins spécifiques des unités précises analysées par Adaptive Protection. Lorsque vous utilisez des modèles précis, les mesures d'atténuation suggérées par la protection adaptative filtrent le trafic en fonction des hôtes ou des préfixes de chemin d'URL correspondants, ce qui permet de réduire les faux positifs. Chacun de ces éléments ces hôtes ou chemins est appelé unité de trafic précis.

Les signatures d'attaque identifiées ne ciblent que le trafic d'attaque dans un bloc de trafic précis, Toutefois, le filtrage s'applique toutes les requêtes correspondant à la règle déployée, de la même manière des configurations précises. Par exemple, si vous souhaitez qu'une règle déployée automatiquement ne correspondent qu'à un bloc précis du trafic, pensez à utiliser comme evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ....

En plus des préfixes d'hôte et de chemin d'URL, vous pouvez configurer des seuils d'alerte en fonction de certaines ou de toutes les options suivantes. Vous pouvez appliquer ces seuils aux unités de trafic précises ou au service de backend dans son ensemble, à l'exception du seuil de charge, qui ne peut être appliqué qu'au service de backend :

Charge : charge maximale du service de backend, selon l'équilibreur de charge d'application configuré. Cette option n'est pas disponible et n'est pas disponible pour les backends sans serveur Cloud Run, fonctions Cloud Run ou backends d'origine externe.
Requêtes absolues par seconde (RPS) : pic du trafic (en requêtes par seconde) que le service de backend ou l'unité de trafic reçoit.
Par rapport au nombre de RPS de référence: multiple de la valeur de référence moyenne à long terme le volume de trafic. Par exemple, une valeur de 2 représente un RPS égal au double de le volume de trafic de référence.

Pour en savoir plus sur la configuration de modèles précis, consultez Configurez Google Cloud Armor Adaptive Protection.

Utiliser et interpréter les alertes

Dès qu'Adaptive Protection détecte une suspicion d'attaque, un événement est généré dans le tableau de bord des événements Adaptive Protection, et un élément de journal est généré dans Cloud Logging. Cette alerte se trouve dans la charge utile JSON de l'élément de journal. L'élément de journal est généré sous la ressource Règle de sécurité du réseau dans Cloud Logging. Le message de journal identifie le service de backend attaqué et inclut un score de confiance indiquant le degré de confiance avec lequel Adaptive Protection évalue le changement de modèle de trafic identifié comme une anomalie. Le message de journal inclut également une signature d'attaque qui illustre les caractéristiques du trafic d'attaque, ainsi que des suggestions de règles Google Cloud Armor que vous pouvez appliquer pour limiter l'attaque.

Comprendre les signatures d'attaque

Une alerte Adaptive Protection inclut une signature d'attaque, qui est une description des attributs de trafic de l'attaque potentielle. Vous utilisez la signature pour identifier et potentiellement bloquer l'attaque. Cette signature se présente sous deux formes : une table lisible par l'utilisateur et une règle WAF préconfigurée pour Google Cloud Armor, que vous pouvez déployer dans la stratégie de sécurité appropriée. Si vous utilisez n'est pas abonné à Cloud Armor Enterprise, la signature d'attaque n'est pas incluses dans l'alerte de base.

La signature se compose d'un ensemble d'attributs, tels que l'adresse IP source, des régions géographiques, des cookies, des user-agents, des référents et d'autres en-têtes de requête HTTP, ainsi que l'ensemble de valeurs de ces attributs qui seraient associées au trafic d'attaque potentiel. L'ensemble d'attributs n'est pas configurable par l'utilisateur. Les valeurs d'attribut dépendent des valeurs du trafic entrant vers votre service de backend.

Pour chaque valeur d'attribut indiquant selon Adaptive Protection une attaque potentielle, les éléments suivants sont répertoriés :

La probabilité d'attaque.
La proportion de l'attribut dans l'attaque, qui correspond au pourcentage du trafic d'attaque potentiel associé à cette valeur au moment où l'attaque a été détectée.
La proportion de l'attribut dans la base de référence, qui correspond au pourcentage du trafic de référence qui contenait cette valeur d'attribut au moment où l'attaque a été détectée.

La spécification des entrées Cloud Logging contient des détails sur les informations de chaque alerte.

Voici un exemple de table lisible par l'utilisateur contenant la signature d'une attaque potentielle :

Nom de l'attribut	Valeur	Type de correspondance	Probabilité de l'attaque	Proportion dans l'attaque	Proportion dans la base de référence
`UserAgent`	"foo"	Correspondance exacte	0,7	0,85	0.12
`UserAgent`	"bar"	Correspondance exacte	0,6	0,7	0,4
IP source	"a.b.c.d"	Correspondance exacte	0,95	0,1	0,01
IP source	a.b.c.e	Correspondance exacte	0,95	0,1	0,01
IP source	a.b.c.f	Correspondance exacte	0,05	0,1	0,1
`RegionCode`	Royaume-Uni	Correspondance exacte	0,64	0.3	0,1
`RegionCode`	IN	Correspondance exacte	0,25	0,20	0.3
`RequestUri`	/urlpart	Substring	0,7	0,85	0.12

Une alerte Adaptive Protection et le journal des événements Cloud Logging correspondants contiennent les éléments suivants :

Un ID d'alerte unique, ou alertID, utilisé pour faire référence à une alerte spécifique, en cas de commentaires utilisateur (plus d'informations ci-dessous).
Le service de backend attaqué, ou backendService.
Le score de confiance, ou confidence, qui est un nombre compris entre 0 et 1 indiquant dans quelle mesure le système Adaptive Protection évalue l'événement détecté comme une attaque malveillante.

Vous recevez également un ensemble de signatures et de règles caractérisant l'attaque détectée. Plus précisément, l'ensemble fournit une liste de headerSignatures, chacune correspondant à un en-tête HTTP et contenant une liste de significantValues pour l'en-tête spécifique. Chaque valeur significative est soit une valeur d'en-tête observée, soit une sous-chaîne de celle-ci.

Voici un exemple de signature :

...
headerSignatures: [
  0: {
   name: "Referer"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_EQUALS"
     proportionInAttack: 0.6
     proportionInBaseline: 0.01
     value: "foo.attacker.com"
    }
   ]
  }
...

L'alerte indique que la valeur foo.attacker.com dans l'en-tête Referer est importante pour la caractérisation de l'attaque. Plus précisément, 60 % du trafic d'attaque (proportionInAttack) a cette valeur Referer et seulement 1 % du trafic de référence parmi l'ensemble du trafic (proportionInBaseline) a cette même valeur Referer. De plus, parmi l'ensemble du trafic correspondant à cette valeur Referer, 95 % correspond au trafic d'attaque (attackLikelihood).

Ces valeurs indiquent que si vous bloquez toutes les requêtes contenant foo.attacker.com dans le champ d'en-tête Referer, vous parviendriez à bloquer 60 % du trafic d'attaque et 1 % du trafic de référence.

La propriété matchType spécifie la relation entre l'attribut dans le trafic d'attaque et la valeur significative. Il peut s'agir de MATCH_TYPE_CONTAINS ou de MATCH_TYPE_EQUALS.

La signature suivante correspond au trafic avec une sous-chaîne /api? dans l'URI de la requête :

...
headerSignatures: [
  0: {
   name: "RequestUri"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_CONTAINS"
     proportionInAttack: 0.9
     proportionInBaseline: 0.01
     value: "/api?"
    }
   ]
  }
...

Déployer les règles suggérées

Les alertes Adaptive Protection fournissent également une règle Google Cloud Armor suggérée, rédigée dans le langage des règles personnalisées. Cette règle peut être utilisée pour créer une règle dans une stratégie de sécurité Google Cloud Armor afin de limiter l'attaque. En plus de la signature, l'alerte inclut un taux de trafic de référence affecté, pour vous aider à évaluer l'impact du déploiement de la règle. Le taux de trafic de référence affecté correspond à une prévision de proportion du trafic de référence qui correspond à la signature d'attaque identifiée par Adaptive Protection. Si vous n'êtes pas abonné à Cloud Armor Enterprise, alertes de base envoyées par Adaptive Protection n'incluent pas de suggestions une règle Google Cloud Armor que vous pouvez appliquer.

Vous pouvez trouver une partie de la signature d'alerte, ainsi que le taux de trafic de référence affecté dans le message de journal envoyé à Cloud Logging. L'exemple suivant montre la charge utile JSON d'un exemple d'alerte ainsi que les libellés de ressource sur lesquels vous pouvez filtrer les journaux.

...
 jsonPayload: {
   alertId: "11275630857957031521"
   backendService: "test-service"
   confidence: 0.71828485
   headerSignatures: [

    0: {
     name: "RequestUri"
     significantValues: [
      0: {
       attackLikelihood: 0.88
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0.01
       value: "/"
      }
     ]
    }
    1: {
     name: "RegionCode"
     significantValues: [
      0: {
       attackLikelihood: 0.08
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.17
       proportionInBaseline: 0.28
       value: "US"
      }
      1: {
       attackLikelihood: 0.68
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.09
       proportionInBaseline: 0.01
       value: "DE"
      }
      2: {
       attackLikelihood: 0.74
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.05
       proportionInBaseline: 0
       value: "MD"
      }
     ]
    }
     2: {
     name: "UserAgent"
     significantValues: [
      0: {
       attackLikelihood: 0.92
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0
       value: "Unusual browser"
      }
      1: {
       attackLikelihood: 0.87
       proportionInAttack: 0.7
       proportionInBaseline: 0.1
       missing: true
      }
     ]
    }
   ]
   suggestedRule: [
    0: {
     action: "DENY"
     evaluation: {
       impactedAttackProportion: 0.95
       impactedBaselineProportion: 0.001
       impactedBaselinePolicyProportion: 0.001
     }
     expression: "evaluateAdaptiveProtection('11275630857957031521')"
    }
   ]
   ruleStatus: RULE_GENERATED
   attackSize: 5000
 }
 resource: {
    type: "network_security_policy",
    labels: {
      project_id: "your-project",
      policy_name: "your-security-policy-name"
    }
 },
}
}
...

Vous pouvez déployer des règles suggérées en copiant l'expression CEL figurant dans la signature de la règle, puis en la collant dans la condition de correspondance d'une nouvelle règle ou en cliquant sur le bouton Appliquer, dans le tableau de bord Adaptive Protection situé dans l'interface utilisateur de Google Cloud Armor.

Pour déployer la règle, vous devez créer une règle dans la stratégie de sécurité Google Cloud Armor qui protège les services de backend ciblés identifiés par l'alerte. Lors de la configuration de la règle, copiez et collez l'expression CEL contenue dans l'alerte dans le champ Match condition (Condition de correspondance) de la règle, puis définissez l'action de la règle sur deny. Dans l'exemple ci-dessus, vous copiez l'expression evaluateAdaptiveProtection('11275630857957031521') depuis la section suggestedRule de l'alerte.

Nous vous recommandons vivement de commencer par déployer la règle en mode preview, afin de pouvoir évaluer son impact sur le trafic de production. Lorsque vous effectuez cette opération, Google Cloud Armor journalise l'action et le trafic associé chaque fois que la règle est déclenchée, mais aucune action n'est effectuée sur le trafic correspondant.

En outre, si votre stratégie de sécurité est associée à plusieurs services de backend, vérifiez si les effets de la nouvelle règle ont des effets indésirables sur l'un des services de backend. Dans ce cas, configurez de nouvelles stratégies de sécurité pour réduire les effets indésirables, et associez-les aux services de backend appropriés.

Nous vous recommandons de définir pour la nouvelle règle une priorité plus élevée que celles de toutes les règles dont l'action est définie sur Autoriser (ou règles d'autorisation). En effet, pour produire l'impact attendu et un effet maximal sur la limitation de l'attaque, la règle doit être déployée à la priorité logique la plus élevée pour garantir que tout le trafic correspondant est bloqué par la règle. Les règles d'une stratégie de sécurité Google Cloud Armor sont évaluées dans l'ordre de priorité suivant : l'évaluation s'arrête après le déclenchement de la première règle correspondante et l'action associée à la règle est engagée. Si vous devez accorder une exception pour une partie du trafic ou certains clients spécifiques à partir de cette règle, vous pouvez créer une règle d'autorisation avec une priorité plus élevée, c'est-à-dire avec une valeur numérique plus faible. Pour plus d'informations sur la priorité des règles, consultez la page Ordre d'évaluation des règles.

Déployer automatiquement les règles suggérées

Vous pouvez également configurer Adaptive Protection pour déployer automatiquement les règles suggérées. Pour activer le déploiement automatique des règles, vous devez créer une règle d'espace réservé avec la priorité et l'action de votre choix à l'aide de l'expression evaluateAdaptiveProtectionAutoDeploy() dans la condition de correspondance. Cette règle renvoie true pour les requêtes qu'Adaptive Protection identifie comme du trafic associé à une attaque, et Google Cloud Armor applique l'action à la requête d'attaque. Tous les types d'actions Google Cloud Armor, tels que allow, deny, throttle et redirect, sont acceptés. En outre, vous pouvez utiliser le mode Preview pour consigner que la règle a été déclenchée, sans effectuer l'action configurée.

Si vous utilisez un proxy en amont, tel qu'un CDN tiers, devant votre équilibreur de charge d'application externe, nous vous recommandons de configurer le champ userIpRequestHeaders pour ajouter l'adresse IP (ou les plages d'adresses IP) de votre fournisseur à une liste d'autorisation. Cela empêche Adaptive Protection d'identifier par erreur l'adresse IP source du proxy comme participant à une attaque. Au lieu de cela, il examine le champ configuré par l'utilisateur pour l'adresse IP source du trafic avant qu'il n'arrive au proxy.

Pour en savoir plus sur la configuration du déploiement automatique des règles, consultez la page Déployer automatiquement les règles suggérées par Adaptive Protection.

État de la règle

Si aucune règle n'est présentée lorsque vous tentez de déployer une règle suggérée, vous pouvez utiliser le champ ruleStatus pour déterminer la cause.

 ]
ruleStatus: RULE_GENERATED
attackSize: 5000
}

Le tableau suivant décrit les valeurs possibles du champ et leur signification.

État de la règle	Description
RULE_GENERATED	Une règle utilisable a été générée normalement.
BASELINE_TOO_RECENT	Délai insuffisant pour accumuler du trafic de référence fiable. Un délai d'une heure est nécessaire pour générer des règles.
NO_SIGNIFICANT_VALUE_DETECTED	Aucun en-tête n'a de valeur significative associé au trafic d'attaque, donc aucune règle n'a pu être générée.
NO_USABLE_RULE_FOUND	Impossible de créer une règle utilisable.
ERREUR	Une erreur non spécifiée s'est produite lors de la création de la règle.

Surveiller, envoyer des commentaires et signaler les erreurs d'événements

Vous devez disposer des autorisations suivantes pour afficher le tableau de bord Adaptive Protection ou interagir avec lui.

compute.securityPolicies.list
compute.backendServices.list
logging.logEntries.list

Après avoir activé Adaptive Protection sur une stratégie de sécurité Google Cloud Armor, vous pouvez consulter la page suivante dans le panneau Sécurité du réseau > Google Cloud Armor. Il affiche le volume du trafic au fil du temps pour la stratégie de sécurité et le service de backend sélectionnés, ainsi que la durée sélectionnée. Toutes les instances d'attaques potentielles signalées par Adaptive Protection sont annotées sur le graphique et répertoriées sous le graphique. Lorsque vous cliquez sur un événement d'attaque spécifique, une fenêtre latérale avec la signature de l'attaque et la règle suggérée s'affichent au format tabulaire. Ces informations figurent dans les entrées de journal Cloud Logging qui sont décrites dans la spécification des entrées Cloud Logging. Cliquez sur le bouton Appliquer pour ajouter la règle suggérée à la même stratégie de sécurité.

Tableau de bord Adaptive Protection (cliquez sur l'image pour l'agrandir)

Détails de l'alerte Adaptive Protection — Tableau de bord Adaptive Protection (cliquez sur l'image pour l'agrandir)

Tous les résultats de la fonctionnalité Adaptive Protection ne sont pas nécessairement considérés comme une attaque, étant donné les facteurs d'environnement et de contexte qui sont propres au service de backend protégé. Si vous déterminez que l'attaque potentielle décrite par l'alerte correspond à un comportement normal ou accepté, vous pouvez signaler une erreur d'événement pour contribuer à l'entraînement des modèles Adaptive Protection. À côté de chaque événement d'attaque répertorié sous le graphique se trouve un bouton qui affiche une fenêtre interactive, vous permettant de signaler une erreur d'événement avec certaines informations de contexte (facultatives). Le signalement d'une erreur d'événement permet de réduire la probabilité d'erreurs similaires à l'avenir. Au fil du temps, cela améliore la précision de la fonctionnalité Adaptive Protection.

Surveillance, alertes et journalisation

La télémétrie Adaptive Protection est envoyée à Cloud Logging et à Security Command Center. Le message de journal Adaptive Protection envoyé à Cloud Logging est décrit dans les sections précédentes de ce document. Une entrée de journal est générée chaque fois que la fonctionnalité Adaptive Protection détecte une attaque potentielle, et chaque entrée contient un score de confiance indiquant la fiabilité de l'anomalie signalée par le modèle pour le trafic observé. Pour affiner les alertes, vous pouvez configurer une stratégie d'alerte dans Cloud Logging afin de ne déclencher une alerte que lorsqu'un message de journal Adaptive Protection affiche un score de confiance supérieur à un seuil spécifié par l'utilisateur. Nous vous recommandons de commencer par un seuil faible, avec un niveau de confiance supérieur à 0,5, afin d'éviter de passer à côté d'avertissements d'attaques potentielles. Le seuil de confiance de la stratégie d'alerte peut être augmenté au fil du temps si les alertes présentent un taux inacceptable de trafic de référence affecté.

Le tableau de bord Security Command Center contient également les résultats d'Adaptive Protection. Ils se trouvent sur la fiche Google Cloud Armor dans la catégorie Attaques DDoS d'applications. Chaque résultat inclut les détails du service, le score de confiance et la signature associés à l'attaque, et un lien vers l'alerte spécifique dans le tableau de bord Adaptive Protection. La capture d'écran suivante est un exemple de détection d'une tentative d'attaque DDoS sur une application :

Découverte d'une attaque DDoS d'application. — **attaque DDoS de l'application** (cliquez pour agrandir).

Spécification des entrées Cloud Logging

L'alerte Adaptive Protection envoyée à Cloud Logging se compose d'une entrée de journal contenant les éléments suivants :

Score de confiance de l'alerte : fiabilité selon laquelle l'événement observé par Adaptive Protection est bien une attaque.
Déploiement automatique : valeur booléenne indiquant si une défense automatique a été déclenchée.
Signature de l'attaque.
- Nom de l'attribut : nom de l'attribut qui correspond à la valeur (Value) ci-dessous, tel qu'un nom d'en-tête de requête particulier ou une origine géographique.
- Valeur : valeur à laquelle correspond l'attribut dans le trafic malveillant.
- Type de correspondance : relation entre Value et l'attribut dans le trafic associé à l'attaque. La valeur est égale à un attribut dans le trafic associé ou en est une sous-chaîne.
- Probabilité d'attaque : probabilité qu'une requête donnée soit malveillante, étant donné que l'attribut concerné de cette requête correspond à Value.
- Proportion dans l'attaque : pourcentage du trafic d'attaque potentiel correspondant à Value.
- Proportion dans la base de référence : pourcentage du trafic de référence normal qui correspond à Value.
Règle suggérée
- Condition de correspondance : expression à utiliser dans la condition de correspondance des règles pour identifier le trafic malveillant.
- Taux de trafic de référence affecté : prévision du pourcentage de trafic légitime vers le service de backend spécifique ciblé par une attaque qui est capturé par la règle suggérée.
- Taux de trafic de référence affecté dans la règle : prévision du pourcentage de trafic légitime vers tous les services de backend dans la même règle de sécurité, capturé par la règle suggérée.
- Taux de trafic d'attaque affecté : prévision du pourcentage de trafic d'attaque qui est capturé par la règle suggérée.
État de la règle : détails supplémentaires sur la génération de règles.

Présentation du machine learning et confidentialité

Données d'entraînement et données de détection
- Adaptive Protection crée plusieurs modèles pour détecter les attaques potentielles et identifier leurs signatures. Les signaux utilisés par ces modèles pour déterminer si une attaque est en cours sont établis à partir des métadonnées observées du trafic de requêtes entrantes provenant de vos projets. Ces métadonnées incluent : l'adresse IP source, la géographie source et les valeurs de certains en-têtes de requêtes HTTP.
- Les caractéristiques réelles utilisées par les modèles sont des propriétés statistiques dérivées des signaux mentionnés ci-dessus. En d'autres termes, les données d'entraînement des modèles n'incluent pas les valeurs réelles de métadonnées, telles que les adresses IP et/ou les valeurs d'en-tête de requête.
- Un ensemble commun de modèles de détection, qui ne sont entraînés qu'avec des données artificielles, sont partagés par tous les clients afin de déterminer si une attaque se déroule ou non, lorsqu'Adaptive Protection est activé pour la première fois. Lorsque vous signalez un faux événement d'attaque et que les modèles sont mis à jour à l'aide de signaux de trafic spécifiques à vos projets, ces modèles sont alors spécifiques à vos projets et ne sont utilisés par aucun autre client.
Données pour générer des signatures
- Lorsqu'Adaptive Protection détermine qu'une attaque potentielle est en cours, il génère une signature d'attaque qui va permettre d'atténuer efficacement et rapidement l'attaque. Pour ce faire, après avoir activé Adaptive Protection sur une stratégie de sécurité, les métriques de trafic et les métadonnées de requête concernant un service de backend (associé à la stratégie de sécurité) sont enregistrées de manière continue afin d'apprendre les caractéristiques du trafic de référence.
- Étant donné qu'Adaptive Protection a besoin d'apprendre le trafic de référence, un délai maximal d'une heure peut être nécessaire avant que des règles limitant les attaques potentielles soient générées.