Documentation du noeud final d'API QRadar et versions prises en charge
Vous accédez à l'API RESTful en envoyant des demandes HTTPS à des URL spécifiques (points d'extrémité) sur la console SIEM QRadar®. Pour envoyer ces demandes, utilisez l'implémentation de HTTP qui est intégrée au langage de programmation de votre choix. Chaque requête contient des informations d'authentification, et des paramètres qui modifient la requête.
QRadar et versions d'API
| Version de QRadar | Nouvelle version de l'API REST | Versions d'API REST prises en charge | Versions d'API REST obsolètes |
|---|---|---|---|
| 7.5.0 Mise à jour n° 14 | 27.0 | 27.0 26.0 25.0 |
24.x |
| 7.5.0 Mise à jour des paquets 12 et 13 | 26.0 | 26.0 25.0 24.0 |
23.x |
| 7.5.0 Mise à jour du paquet 11 | 25.0 | 25.0 24.0 23.0 |
22.x |
| 7.5.0 Mise à jour du paquet 10 | 24.0 | 24.0 23.0 22.0 |
21.x |
| 7.5.0 Mise à jour du paquet 9 | 23.0 | 23.0 22.0 21.0 |
20.x |
| 7.5.0 Mise à jour du paquet 8 | 22.0 | 22.0 21.0 20.0 |
19.x |
| 7.5.0 Mise à jour du paquet 7 | 21.0 | 21.0 20.0 19.0 |
18.x |
| 7.5.0 Package de mise à jour 6 | 20.0 | 20.0 19.0 18.0 |
17.x |
| 7.5.0 Module de mise à jour 3 | 19.0 | 19.0 18.0 17.0 |
16.x |
| 7.5.0 Module de mise à jour 2 | 18.0 | 18.0 17.0 16.0 |
15.x |
| 7.5.0 | 17.0 16.0 15.0 |
14.x | |
| 7.4.3 | 16.0 | 16.0 15.0 14.0 |
13.x |
| 7.4.2 | 15.0 | 15.0 14.0 13.1 13.0 |
12.x |
| 7.4.1 | 14.0 | 14.0 13.1 13.0 12.1 12.0 |
11.x |
| 7.4.0 Groupe de correctifs 1 | 13.1 | 13.1 13.0 12.1 12.0 |
10.x |
| 7.4.0 | 13.0 | 13.0 12.1 12.0 |
10.x |
Noeuds finaux d'API
Un point de terminaison API contient le site URL de la ressource à laquelle vous souhaitez accéder et l'action que vous souhaitez effectuer sur cette ressource. L'action est indiquée par la méthode HTTP de la demande : GET, POST, PUT ou DELETE.
Autorisations obligatoires pour accéder à l'API
- Nom d'utilisateur et mot de passe d'un utilisateur QRadar spécifié dans l'en-tête d'autorisation.
Vous spécifiez le nom d'utilisateur et le mot de passe en utilisant l'authentification de base HTTP. Bien que vous puissiez effectuer des requêtes API en fournissant un nom d'utilisateur et un mot de passe pour chaque requête, utilisez des jetons de service autorisés pour toutes les intégrations API avec QRadar. Seule l'option du nom d'utilisateur et du mot de passe est prise en charge pour l'affichage de la page Documentation.
Pour plus d'informations sur la création de rôles utilisateur, de profils de sécurité et d'utilisateurs, voir le manuel IBM QRadar -Guide d'administration.
- Un marqueur de service autorisé qui est spécifié dans l'en-tête SEC.
Pour vous authentifier en tant que service autorisé, vous créez un jeton d'authentification qui utilise des services autorisés. Les services autorisésQRadar ont des rôles et des profils de sécurité affectés qui contrôlent l'accès aux différentes ressources d'API.
Le jeton est valide jusqu'à la date d'expiration que vous avez spécifiée lors de la création du service autorisé.
Pour plus d'informations sur la création de rôles utilisateur, de profils de sécurité et de services autorisés, voir le manuel IBM QRadar -Guide d'administration.
Demandes et réponses de l'API
Lorsque vous envoyez une demande d'API, le serveur renvoie une réponse HTTP. La réponse HTTP contient un code de statut indiquant si la requête a réussi et les détails de la réponse dans le corps de la réponse. La plupart des ressources formatent cette réponse en JavaScript Object Notation (JSON). Vous pouvez utiliser les packages ou les bibliothèques JSON qui sont intégrés au langage de programmation que vous utilisez pour extraire les données.
Pour un exemple complet de ce processus, consultez l'exemple de code disponible à l'adresse GitHub ( https://github.com/ibm-security-intelligence/api-samples ).
En-têtes de version
Vous utilisez des en-têtes de version pour demander une version spécifique de l'API. Si vous ne fournissez pas d'en-tête de version, la version la plus récente de l'API est utilisée, ce qui peut interrompre les intégrations lors de la mise à niveau d' QRadar . Si vous fournissez un en-tête de version chaque fois que vous utilisez une API, il est plus facile de mettre à niveau vers les nouvelles versions de QRadar sans rupture de vos clients d'API.
Les API utilisent les composants majeurs et mineurs de gestion des versions sémantique. Des entiers naturels sont utilisés pour désigner les versions majeures de l'API, par exemple, '3'. Les versions mineures de l'API sont désignées par un composant majeur et mineur, par exemple, '3.1'. Vous pouvez définir l'en-tête de version à une version majeure ou mineure de l'API. Les changements qui sont compatibles avec les versions existantes sont introduits avec un numéro de version mineure incrémenté. Toutes les modifications incompatibles sont introduites avec un incrément de numéro de version majeure.
Quand une version majeure de l'API est spécifiée dans l'en-tête de la version sans un composant mineur, le serveur répond avec la dernière version mineure dans la version majeure de l'API. Par exemple, si le client demande la version '3', le serveur répond avec la version '3.1'. Si vous souhaitez utiliser la version 3.0, vous devez demander '3.0' dans l'en-tête de version. Si vous demandez une version supérieure à la dernière version d'un noeud final, la dernière version disponible de ce noeud final est renvoyée. Chaque noeud final est listé sous chaque version pour laquelle il est valide, même s'il est identique dans les versions plus récentes.
Dépréciation de noeud final
Un noeud final d'API est marqué comme déprécié pour indiquer qu'il est pas recommandé pour l'utilisation et sera supprimé dans une future version. Pour donner aux intégrations le temps d'utiliser une alternative, un noeud final déprécié continue à fonctionner pendant 2 versions avant d'être retiré. La page de documentation de l'API interactive indique qu'un noeud final est marqué comme étant déprécié. En outre, le message de réponse d'API pour un noeud final obsolète inclut l'en-têteDeprecated. Un noeud final d'API individuel ou une version complète des noeuds finaux d'API peut être marqué comme obsolète. Les noeuds finaux dépréciés continuent de fonctionner jusqu'à ce qu'ils soient retirés.
Quand un noeud final d'API termine le processus de dépréciation, il est supprimé. Les noeuds finaux qui sont retirés ne répondent plus correctement. Une tentative d'appeler un noeud final supprimé renvoie une erreur. UneHTTP 410 GoneUne réponse est renvoyée pour les noeuds finaux supprimés individuellement. UneHTTP 422 Unprocessable Entityest renvoyée pour les demandes d'une version qui n'est plus prise en charge.
Incluez l'en-tête de version dans les requêtes d'API pour appeler une version spécifique d'un noeud final d'API. Les intégrations d'API qui ne demandent pas explicitement une version particulière ne sont pas prises en charge. Si vous ne spécifiez pas une version, votre demande est dirigée vers la dernière version disponible. Si une version inclut une nouvelle version, incompatible d'un noeud final, votre intégration pourrait s'interrompre. Envoyez votre demande de version vers un emplacement dans votre code pour pouvoir facilement mettre à niveau des versions plus récentes lorsque celles-ci sont disponibles.