---
title: "Guide technique : connexions Web App Shield"
description: "Préparer les connexions des journaux, actions, configurations, identités et éventuels produits de sécurité des bases. Les exemples doivent être validés pour le produit, la version et la licence choisis."
url: https://www.alt-f1.be/fr/imperva/integration-architecture/
organization: ALT-F1 SRL, Brussels (VAT BE 0830.560.718)
---

# Guide technique : connexions Web App Shield

Comment la plateforme Imperva se branche sur votre SIEM, votre SOAR, votre CI/CD, votre identité, votre PKI et vos bases de données.

Source : Thales Cyber Security — Enterprise Security & Data Fabric Ecosystem. Chiffres de l’éditeur tels que publiés. ALT-F1 est le partenaire belge d’Imperva : nous ouvrons le compte, réglons les règles et construisons ces intégrations avec vos équipes. Le document original est conservé dans le dépôt du site (docs/imperva/).

## Chiffres clés

- **Protection:** Par service — Confirmer produit, sites et fonctions.
- **Bases de données:** Selon le produit — Vérifier les moteurs de la version choisie.
- **Journaux:** À mesurer — Vérifier délai, exhaustivité et reprise.
- **Accès:** Droits limités — Configurer identifiants et responsabilités des certificats.

## 1. Architecture de sécurité à deux plans

L’écosystème de sécurité Imperva fonctionne sur deux plans synchronisés : le plan applicatif en périphérie (inspection du trafic en une passe sur plus de 150 PoP) et le plan central des données (la Data Security Fabric, qui unifie l’audit des bases sur site et dans le cloud).

### Topologie du plan applicatif en périphérie (150+ PoP mondiaux)

- **Cœur Cloud WAF** (AppSec) — Inspection du trafic en une passe sur plus de 150 PoP, neutralisant en ligne le Top 10 OWASP, les règles personnalisées et les menaces zero-day. Sortie: HTTPS / TLS 1.3. Modèle de données / schéma: CEF / LEEF / JSON.
- **Advanced Bot Protection** (BotSec) — Analyse de la télémétrie du navigateur et injection dynamique de défis pour neutraliser l’automatisation malveillante sans friction pour l’utilisateur. Sortie: HTTPS / empreinte JS. Modèle de données / schéma: JSON / flux d’événements.
- **Account Takeover Protection** (Identité) — Évalue les flux d’identifiants compromis et les anomalies de comportement pour bloquer le credential stuffing et la force brute. Sortie: HTTPS / API REST. Modèle de données / schéma: Charge utile JSON.
- **Client-Side Protection** (WebSec) — Surveille le JavaScript tiers exécuté dans le navigateur pour stopper les attaques Magecart et le formjacking. Sortie: HTTP / inspecteur de scripts. Modèle de données / schéma: JSON / webhook.
- **Moteur de mitigation DDoS** (Infra) — Mitige en quelques secondes les attaques volumétriques L3/L4 et les attaques applicatives L7 complexes, avec la capacité des PoP mondiaux. Sortie: BGP L3/L4 / HTTP L7. Modèle de données / schéma: W3C / CEF.
- **Capteur RASP in-app** (Workload) — S’intègre dans les runtimes applicatifs pour stopper l’injection SQL, l’exécution de commandes et l’accès non autorisé aux fichiers. Sortie: IPC natif JVM / .NET. Modèle de données / schéma: Audit de processus interne.

### Plan central Data Security Fabric (DSF) (Passerelles avec et sans agent)

- **Passerelle à agent & agent hôte** (BD sur site) — Surveille l’activité des administrateurs de bases de données directement sur les serveurs relationnels, sessions console locales comprises. Sortie: IPC local / mémoire partagée. Modèle de données / schéma: Journal d’audit brut.
- **Passerelle cloud sans agent** (DBaaS cloud) — Collecte les flux d’audit natifs des bases cloud sur AWS RDS, Azure SQL et Google Cloud SQL, sans agent local. Sortie: API AWS CloudWatch / Event Hubs. Modèle de données / schéma: Audit cloud normalisé.
- **Cœur analytique DSF Hub** (Hub central) — Serveur big data central exécutant l’analyse UEBA, la rétention de conformité et la gestion des politiques d’entreprise. Sortie: TLS / HTTPS / gRPC. Modèle de données / schéma: Entrepôt de données sonargd.
- **Data Risk Analytics (DRA)** (Moteur ML) — Apprentissage automatique sur les pistes d’audit pour repérer les expositions de données à haut risque et les anomalies de comportement. Sortie: IPC interne du hub. Modèle de données / schéma: Narratif de score de risque.

## 2. Sortie de télémétrie et protocoles

Choisissez canal, format et destination pris en charge. Le graphique de délais est illustratif : mesurez livraison complète et délai de bout en bout lors de la recette.

Latence moyenne de transport des journaux par canal :

- Splunk HEC: 12 s
- Streaming Kafka: 1 s
- Syslog TLS: 3 s
- Dépôt objet S3: 45 s
- API pull SIEM: 180 s

À retenir : les mécanismes push (Splunk HEC, Kafka) ingèrent en moins de 15 secondes ; l’interrogation par API subit des délais par lots et une limitation de débit (HTTP 429).

### CEF — exemple

```
CEF:0|Imperva|Incapsula|1.0|20001|SQL Injection Attempt|7|cs12=BLOCK cs17=CVE-2023-1234 fileType=SQLi filePermission=Rule_1092 c-ip=198.51.100.45 cn1=403 cs-sessionid=sess_8893412a
```

- `cs12 / cs-responseaction` — Décision de mitigation finale appliquée (PASSED, BLOCK, CAPTCHA).
- `cs17 / cs-cve` — CVE corrélée par la Threat Research.
- `fileType / filePermission` — Classification de l’attaque (SQLi, XSS) et identifiant de signature déclenchée.
- `c-ip / cn1` — IP source du client et code de statut HTTP retourné.

### LEEF — exemple

```
LEEF:2.0|Imperva|Incapsula|1.0|WAF_BLOCK|dev01|src=198.51.100.45|usrName=john_doe|proto=HTTPS|action=BLOCK|cat=CrossSiteScripting|ruleId=89432
```

- `src / usrName` — IP d’origine et identité utilisateur authentifiée.
- `action / cat` — Action appliquée et catégorie de menace normalisée.
- `ruleId` — Identifiant de la règle de politique de sécurité dans le moteur Imperva.

### JSON — exemple

```
{
  "timestamp": 1729864200,
  "client_ip": "198.51.100.45",
  "attack_type": "Bot_Automation",
  "action": "CAPTCHA_CHALLENGE",
  "cve_id": "CVE-2024-8891",
  "bot_classification": "Malicious_Scraper"
}
```

- `client_ip / timestamp` — Origine IPv4/IPv6 du client et horodatage epoch.
- `bot_classification` — Classe d’empreinte (bon bot, scraper, navigateur headless).
- `action` — Mitigation appliquée (PASSED, CHALLENGE, DROPPED).

### W3C — exemple

```
2026-10-25 13:50:00 198.51.100.45 POST /api/checkout 403 1092 "Imperva_WAF_Block" "Mozilla/5.0"
```

- `date time c-ip` — Horodatage UTC et IP du client.
- `cs-method cs-uri-stem` — Verbe HTTP et chemin demandé.
- `sc-status cs(User-Agent)` — Code de statut HTTP et user agent du client.

### Enveloppe cryptographique hybride

1. **Compression de la charge utile** — Les journaux bruts sont compressés en micro-lots au PoP de périphérie.
2. **Chiffrement symétrique AES-256** — Chaque lot est chiffré avec une clé de session symétrique générée.
3. **Enveloppement de clé RSA** — La clé de session est chiffrée avec la clé publique RSA fournie par l’entreprise.
4. **Contrôle d’intégrité MD5** — L’en-tête du fichier porte une somme MD5 pour détecter toute altération.

## 3. SIEM et lacs de données de sécurité

Choisissez la plateforme d’analyse et vérifiez connecteur, correspondance des données et accès. Les étapes sont des exemples de configuration, pas la preuve d’une connexion active.

### Pipeline d’intégration Microsoft Sentinel

Pipeline d’extraction serverless : une Azure Function App déployée dans le tenant du client récupère les journaux via l’API SIEM d’Imperva et les normalise dans Log Analytics.

- Modèle d’intégration: Azure Function App (Python), déclencheur temporisé
- Modèle de données: ASIM (table CommonSecurityLog)
- Authentification: ID + clé d’API ; clé privée RSA dans Key Vault
- Périmètre de télémétrie: Cloud WAF, bots, ATO, DDoS, journaux d’audit

1. **Déclencheur temporisé et lecture de Key Vault** — L’Azure Function s’exécute selon le planning et récupère les identifiants d’API et la clé privée RSA dans Azure Key Vault.
2. **Récupération via l’API et déchiffrement** — Se connecte à l’API SIEM d’Imperva en TLS, télécharge le lot compressé et le déchiffre en mémoire.
3. **Ingestion dans Log Analytics** — Envoie les enregistrements CEF normalisés à l’API d’ingestion Azure Monitor, vers l’espace de travail Log Analytics.
4. **Normalisation par le parseur ASIM** — Le parseur ImpervaWAFCloud mappe les champs CEF bruts sur le schéma CommonSecurityLog pour la chasse inter-charges de travail.

### Splunk Enterprise et Splunk Cloud

Streaming haut débit vers le HTTP Event Collector (HEC) de Splunk pour les événements de périphérie, associé à l’add-on jSonar qui interroge directement la base sonargd du DSF Hub.

- Modèle d’intégration: Push Splunk HEC + add-on DSF jSonar
- Modèle de données: Splunk CIM (modèles Web et Network)
- Authentification: Jeton HEC ; mTLS, TLS 1.3
- Périmètre de télémétrie: Accès WAAP en périphérie + pistes d’audit DSF


### Chemin d’intégration IBM QRadar DSM

Événements au format LEEF via Syslog TLS ou collecte par API REST, mappés par le Device Support Module (DSM) Imperva dans le moteur QRadar Sense Analytics.

- Modèle d’intégration: Syslog sur TLS (TCP 6514) / API REST cloud
- Modèle de données: Mappage d’événements LEEF
- Authentification: TLS mutuel, vérification par paire de clés
- Périmètre de télémétrie: Menaces WAF, protection réseau, alertes DSF


### Google Security Operations (Chronicle)

Ingestion automatisée via des buckets Google Cloud Storage dans Google SecOps, avec normalisation des charges JSON brutes en événements Unified Data Model (UDM).

- Modèle d’intégration: Bucket d’export GCS / API d’ingestion Chronicle
- Modèle de données: Unified Data Model (UDM)
- Authentification: Clé de compte de service GCP / OAuth 2.0
- Périmètre de télémétrie: Cloud WAF, protection contre les bots, prise de contrôle de comptes


### Pipeline d’ingestion Elastic Security et Elasticsearch

Filebeat ou Elastic Agent consomme les exports de journaux S3/Blob et fait passer les enregistrements par les pipelines d’ingestion Elastic pour alimenter les champs Elastic Common Schema (ECS).

- Modèle d’intégration: Filebeat / Elastic Agent, plugin d’entrée S3
- Modèle de données: Elastic Common Schema (ECS)
- Authentification: Rôle IAM AWS / jeton SAS Azure
- Périmètre de télémétrie: Journaux WAAP, empreintes de bots, audit RASP


## 4. SOAR bidirectionnel et réponse automatisée

Précisez les événements déclencheurs et les actions à approuver. Les messages montrent une structure ; validez authentification, reprises et actions autorisées avant usage.

### DDoS volumétrique L7

1. **Détection:** Attack Analytics regroupe une rafale de 45 000 req/s venant de 12 pays en un seul narratif de DDoS L7 actif.
2. **Envoi:** Le webhook HTTPS sortant se déclenche avec son jeton d’authentification à secret partagé.
3. **Enrichissement:** Le playbook Cortex XSOAR interroge l’API REST d’Imperva pour obtenir les chemins d’URL les plus attaqués.
4. **Application:** Une commande API fait passer la règle WAF du mode alerte à un défi JavaScript dynamique actif.

```json
{
  "event_type": "WebsiteDdosStart",
  "account_id": "10023456",
  "site_name": "checkout.enterprise.com",
  "threat_level": "CRITICAL",
  "rps_peak": 45000,
  "mitigation_method": "Dynamic Adaptive Challenge"
}
```

### Prise de contrôle de compte

1. **Détection:** Le module ATO identifie 12 000 tentatives de validation d’identifiants depuis des proxys résidentiels.
2. **Envoi:** Le webhook envoie une alerte de prise de contrôle avec la liste des noms d’utilisateur compromis.
3. **Enrichissement:** Le playbook SOAR lance une vérification croisée dans Entra ID pour les comptes concernés.
4. **Application:** Le SOAR appelle l’API pour terminer les sessions actives et bloquer les plages IP fautives.

```json
{
  "event_type": "AccountTakeoverAlert",
  "target_endpoint": "/api/v1/auth/login",
  "attack_vector": "Credential_Stuffing",
  "compromised_accounts_detected": 142,
  "action_requested": "Invalidate_Sessions"
}
```

### Exfiltration de base de données

1. **Détection:** DSF Data Risk Analytics détecte un SELECT anormal qui extrait 500 000 enregistrements d’identité nationale.
2. **Envoi:** Une alerte haute priorité part vers Splunk SOAR par le courtier d’événements Kafka.
3. **Enrichissement:** Le playbook récupère l’identité du DBA et la compare aux tickets de maintenance planifiée.
4. **Application:** Le DSF Hub applique une restriction Data Level Security (DLS) et révoque l’accès du compte de service.

```json
{
  "event_type": "DatabaseDataExfiltration",
  "database_instance": "prod-customer-db-aws",
  "db_user": "app_svc_reporting",
  "records_extracted": 500000,
  "action_taken": "Revoke_DLS_Permissions"
}
```

### Violation de script côté client

1. **Détection:** Client-Side Protection détecte un fichier JavaScript externe non autorisé modifié sur la page de paiement.
2. **Envoi:** Le webhook envoie une alerte Magecart / violation de script au pipeline DevSecOps.
3. **Enrichissement:** Le playbook SOAR crée un ticket Jira attribué à l’ingénierie sécurité applicative.
4. **Application:** L’API Imperva restreint le domaine du script en attendant une autorisation manuelle, comme l’exige PCI DSS 4.0.

```json
{
  "event_type": "ClientSideScriptViolation",
  "page_url": "https://enterprise.com/checkout/pay",
  "script_source": "https://malicious-cdn.com/tracker.js",
  "compliance_impact": "PCI_DSS_Violation"
}
```

## 5. DevSecOps, IaC et CI/CD

Relisez et testez les configurations avant application. Le code généré est un point de départ ; vérifiez versions, paramètres, identifiants et retour arrière.

```hcl
resource "incapsula_site_v3" "production_site" {
  name       = "api.enterprise.com"
  type       = "PUBLIC_CLOUD"
  cloud_type = "AWS"
}

resource "incapsula_data_centers_configuration" "dc_config" {
  site_id = incapsula_site_v3.production_site.id

  data_center {
    name       = "primary_origin"
    ip_or_host = "10.0.12.44"
    server {
      ip     = "10.0.12.44"
      active = true
    }
  }
}

resource "incapsula_waf_security_rule" "custom_protection" {
  site_id     = incapsula_site_v3.production_site.id
  rule_action = "api.rule_action.block"
  name        = "Enforce-Security-Policy"
  filter      = "Header.User-Agent == 'BadBotEngine' | Header.Authorization == ''"
}
```

Gérer la création du site, la validation du certificat SSL et le provisionnement des règles par Terraform élimine la dérive de configuration du pipeline CI/CD.

### Synchronisation du schéma OpenAPI et sécurité positive

Dans le pipeline de déploiement (GitLab CI, GitHub Actions), les développeurs poussent la spécification OpenAPI (Swagger) mise à jour vers le module Imperva API Security via son API REST.

- Impose en périphérie les routes, méthodes HTTP et types de paramètres valides.
- Détecte les API fantômes : des points de terminaison actifs non documentés.
- Identifie les API zombies : des routes dépréciées qui reçoivent encore du trafic.

### Capteurs RASP dans la charge de travail

Les micro-agents Runtime Application Self-Protection (RASP) se déploient dans le runtime applicatif (JVM, .NET CLR, Node.js, pods Kubernetes) sans règle réseau en périphérie.

- Surveillent les tampons mémoire, l’accès au système de fichiers et les requêtes brutes vers la base.
- Neutralisent les exploits zero-day (désérialisation, injection SQL) en temps réel.
- Mitigation dans le thread, sans aller-retour vers la périphérie.

## 6. Fédération d’identité, PKI d’entreprise et mTLS à deux niveaux

Séparez connexion administrateur et authentification du transport. Vérifiez les fonctions du produit, notamment les deux connexions d’un montage TLS mutuel.

1. **Niveau 1 : mTLS client-vers-Imperva** (Identité entrante à haute assurance) — Conçu pour les applications bancaires mobiles, les API B2B et les réseaux IoT. Le client établit une poignée de main mutuelle TLS 1.3 avec le PoP Imperva le plus proche. Le PoP vérifie les listes de révocation (CRL) et authentifie l’autorité de certification du client. `X-Imperva-Client-Cert-SAN: SubjectAltName: email:api-client@enterprise.com, CN=MobileAppClientV2`
2. **Inspection par le PoP et injection d’en-tête** (Extraction d’identité) — Le PoP Imperva termine la session TLS de niveau 1, inspecte la charge utile avec les règles WAF, bots et limitation de débit, et extrait les attributs d’identité vérifiés du client (SAN, nom commun, émetteur). Il les injecte dans un en-tête HTTP chiffré avant de transmettre. `X-Imperva-Client-Cert-Verified: TRUE; Serial=883920192; Issuer=EnterpriseInternalCA`
3. **Niveau 2 : mTLS Imperva-vers-origine** (Protection de l’origine en sortie) — Pour protéger les serveurs d’origine contre le contournement direct, Imperva présente un certificat client émis par l’entreprise lors de l’ouverture de la connexion TCP vers l’équilibreur de charge d’origine. L’origine rejette toute requête sans ce certificat vérifié. `Connection: TLS_AES_256_GCM_SHA384; ClientCertPresented: ImpervaOriginClientCertV3`

### Fédération d’identité SAML 2.0

Fédère l’authentification administrative avec Microsoft Entra ID, Okta et ADFS. Les assertions d’attributs mappent les groupes de sécurité de l’annuaire sur des niveaux RBAC granulaires et sur les périmètres de conformité Data Level Security (DLS) de la Data Security Fabric.

### Vérifier les fonctions cryptographiques

Vérifiez protocoles, certificats et algorithmes de chaque connexion dans la documentation actuelle. Une étiquette de chiffrement classique ne prouve pas une fonction post-quantique.

## 7. Data Security Fabric et le parc de bases de données

L’audit des bases est un périmètre produit distinct de la protection web. Vérifiez moteurs, licences, droits et exports dans la documentation actuelle. Capacité clé : le moteur sonargd du DSF Hub exécute l’analyse comportementale (UEBA) pour détecter les anomalies des utilisateurs privilégiés et les altérations de schéma sans alourdir la licence SIEM.

Répartition du périmètre des bases :

- Relationnel (Oracle, SQL Server): 45 %
- DBaaS cloud (RDS, Azure SQL): 25 %
- Big data (Snowflake, BigQuery): 18 %
- NoSQL (MongoDB, Cassandra): 12 %

Catalogue :

- **Oracle (RAC et Exadata)** (Agent / sans agent) — Surveille l’IPC en mémoire partagée locale et les instances cloud.
- **Microsoft SQL Server** (Agent / sans agent) — Suivi d’audit complet pour SQL Server sur site et Azure SQL.
- **Amazon RDS et Aurora** (Passerelle sans agent) — Ingère les flux d’audit CloudWatch sans logiciel sur l’hôte.
- **PostgreSQL et AlloyDB** (Agent / sans agent) — Analyse SQL approfondie sur PostgreSQL open source et entreprise.
- **Snowflake** (Passerelle sans agent) — Collecte d’audit pour l’entrepôt de données cloud d’entreprise.
- **MongoDB et Couchbase** (Sans agent / agent) — Surveillance des requêtes JSON de bases documentaires et analyse UEBA.
- **Google BigQuery** (Passerelle sans agent) — Ingestion de l’audit de l’entrepôt serverless via les API GCP.
- **Apache Cassandra** (Passerelle à agent) — Suivi de l’activité de l’anneau NoSQL distribué.
- **SAP HANA** (Passerelle à agent) — Audit de base en mémoire et application des politiques.
- **Databricks et Hadoop** (Passerelle sans agent) — Audit des requêtes du lac de données et prévention des fuites.

- **Sortie Kafka sous la seconde** — Télémétrie de base de données au format JSON livrée à Apache Kafka pour les moteurs antifraude temps réel.
- **Connectivité ODBC / JDBC** — Les responsables conformité interrogent l’historique des accès directement depuis Power BI et Tableau.
- **Coffre froid à long terme** — Fichiers d’audit partitionnés et compressés exportés vers S3 ou Blob pour les obligations réglementaires de sept ans (SOX, PCI).

## 8. Matrice d’intégration et feuille de route

| Domaine | Système cible | Direction | Protocole / interface | Format de données | Objectif |
|---|---|---|---|---|---|
| SIEM | Splunk Enterprise / Cloud | Sortant | HTTPS / HEC API | JSON, CEF | Ingestion des événements bruts et mappage Splunk CIM |
| SIEM | Microsoft Sentinel | Entrant | REST API (Azure Function) | CEF (ASIM) | Récupération automatisée des journaux et corrélation avec Defender |
| SIEM | IBM QRadar | Sortant | Syslog over TLS (TCP 6514) | LEEF | Flux de renseignement sur les menaces et offenses Sense Analytics |
| SIEM | Elastic Security | Entrant | Filebeat / S3 plugin | JSON (ECS) | Stockage des journaux dans Elasticsearch pour la chasse aux menaces |
| Storage | Amazon S3 | Sortant | S3 REST object API | Compressed JSON / CEF | Stockage froid chiffré et flux découplés vers le lac de données |
| SOAR | Palo Alto Cortex XSOAR | Bidirectionnel | REST API / webhooks | JSON | Blocage d’IP, invalidation de sessions, triage automatisés |
| SOAR | Splunk SOAR / Chronicle | Bidirectionnel | REST API / webhooks | JSON | Playbooks automatisés de confinement des menaces |
| IaC | HashiCorp Terraform | Entrant | Provider API (imperva/incapsula) | HCL / JSON state | Provisionnement déclaratif des sites, règles et certificats SSL |
| CI/CD | GitLab / GitHub Actions | Entrant | REST API / OpenAPI | JSON / YAML | Synchronisation de la sécurité positive et découverte des API fantômes |
| Workload | Kubernetes / pod RASP | In-app | RASP micro-sensor | Native system calls | Neutralisation des exploits zero-day dans le runtime |
| ITSM | ServiceNow | Bidirectionnel | ServiceNow Table API | JSON | Création automatisée d’incidents SIR et synchronisation CMDB |
| ITSM | Jira Service Management | Sortant | Jira REST API | JSON | Suivi des autorisations de scripts pour la conformité PCI DSS |
| Identity | Okta / Entra ID | Entrant | SAML 2.0 / SCIM | XML assertions | SSO administratif et mappage des rôles RBAC |
| PKI | Thales CipherTrust | Bidirectionnel | Native registration token | Crypto objects | Gestion du cycle de vie des clés de bases de données et tokenisation |
| PKI | GlobalSign CA | Entrant | Automated ACME / DNS | X.509 certificates | Émission et renouvellement des certificats SSL/TLS en périphérie |
| SASE | Cato Networks | Peering | Remote port forwarding | Encapsulated TCP/IP | Sécurisation des ressources d’origine privées sans IP publique |
| Streaming | Apache Kafka | Sortant | Kafka protocol / rsyslog | JSON / audit logs | Streaming haut débit de l’audit des bases vers l’analytique |
| BI | Tableau / Power BI | Entrant | ODBC / JDBC | SQL tabular | Reporting de conformité pluriannuel |

## Mise en œuvre en quatre phases

1. **Fondation identité et PKI** — Fédération SSO SAML 2.0; Bouclier d’origine mTLS à deux niveaux; Mise en place SSL ACME GlobalSign; Préparation cryptographique PQC
2. **Télémétrie et activation du SOC** — Pipelines de dépôt vers le stockage objet; Parseurs SIEM (ASIM / CIM); Webhooks sortants vers le SOAR; Alertes ChatOps en temps réel
3. **DevSecOps et politique en tant que code** — Déploiement du provider Terraform; Synchronisation du schéma OpenAPI dans le CI/CD; Capteurs RASP dans la charge de travail; Découverte automatique des API fantômes
4. **Extension hybride des données DSF** — Infrastructure centrale DSF Hub; Passerelles cloud sans agent; Déploiement des agents hôtes sur site; Streaming Kafka sous la seconde

ALT-F1 est le partenaire belge d’Imperva : nous ouvrons le compte, réglons les règles et construisons ces intégrations avec vos équipes. Devis en un jour ouvrable : https://www.alt-f1.be/fr/quote/