Dokumentation zu QRadar -API-Endpunkten und unterstützte Versionen
Sie greifen auf die RESTful API zu, indem Sie HTTPS Anfragen an bestimmte URLs (Endpunkte) auf der QRadar® SIEM-Konsole senden. Hierzu verwenden Sie die in der Programmiersprache Ihrer Wahl integrierte HTTP-Implementierung. Jede Anforderung beinhaltet Authentifizierungsinformationen sowie Parameter für die Modifizierung der Anforderung.
QRadar und API-Versionen
| QRadar -Version | REST-API-Version eingeführt | Unterstützte REST-API-Versionen | Veraltete REST-API-Versionen |
|---|---|---|---|
| 7.5.0 Update-Paket 12 und 13 | 26.0 | 26.0 25.0 24.0 |
|
| 7.5.0 Update-Paket 11 | 25.0 | 25.0 24.0 23.0 |
|
| 7.5.0 Update-Paket 10 | 24.0 | 24.0 23.0 22.0 |
|
| 7.5.0 Update-Paket 9 | 23.0 | 23.0 22.0 21.0 |
|
| 7.5.0 Update-Paket 8 | 22.0 | 22.0 21.0 20.0 |
|
| 7.5.0 Update-Paket 7 | 21.0 | 21.0 20.0 19.0 |
|
| 7.5.0 Aktualisierungspaket 6 | 20.0 | 20.0 19.0 18.0 |
17.x |
| 7.5.0 Aktualisierungspaket 3 | 19.0 | 19.0 18.0 17.0 |
16.x |
| 7.5.0 Aktualisierungspaket 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 Fixpack 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 |
API-Endpunkte
Ein API-Endpunkt enthält die URL der Ressource, auf die Sie zugreifen möchten, und die Aktion, die Sie auf dieser Ressource ausführen möchten. Die Aktion wird von der HTTP-Methode der Anforderung angegeben: GET, POST, PUT oder DELETE.
Erforderliche Berechtigungen für den Zugriff auf die API
- Ein Benutzername und Kennwort für einen QRadar -Benutzer, der im Berechtigungsheader angegeben ist.
Benutzername und Kennwort geben Sie mit der HTTP-Basisauthentifizierung an. Auch wenn Sie für jede einzelne API-Anforderung einen Benutzernamen und ein Kennwort angeben können, empfiehlt sich für alle API-Integrationen mit QRadar die Verwendung autorisierter Service-Tokens. Die Dokumentationsseite kann nur nach einer Authentifizierung durch Benutzername und Kennwort angezeigt werden.
Weitere Informationen zum Erstellen von Benutzerrollen, Sicherheitsprofilen und Benutzer finden Sie im IBM QRadar -Administrationshandbuch.
- Autorisiertes Service-Token, das im SEC-Header angegeben wird.
Zur Authentifizierung als autorisierter Service erstellen Sie ein Authentifizierungstoken, das autorisierte Services verwendet. Den berechtigten QRadar -Services sind Rollen und Sicherheitsprofile zugewiesen, die den Zugriff auf die verschiedenen API-Ressourcen steuern.
Das Token ist bis zu dem Ablaufdatum gültig, das Sie bei der Erstellung des autorisierten Service angegeben haben.
Weitere Informationen zum Erstellen von Benutzerrollen, Sicherheitsprofilen und autorisierten Services finden Sie im IBM QRadar Administration Guide.
API-Anforderungen und Antworten
Wenn Sie eine API-Anforderung senden, gibt der Server eine HTTP-Antwort zurück. Die HTTP-Antwort enthält einen Statuscode, der angibt, ob die Anforderung erfolgreich war, sowie die Details der Antwort im Antworthauptteil. Die meisten Ressourcen formatieren diese Antwort als JavaScript Object Notation (JSON). Zum Extrahieren der Daten können Sie die in Ihre Programmiersprache integrierten JSON-Pakete oder -Bibliotheken verwenden.
Ein vollständiges Beispiel für diesen Vorgang finden Sie in dem Beispielcode in GitHub ( https://github.com/ibm-security-intelligence/api-samples ).
Versionsheader
Mit Versionsheadern können Sie eine bestimmte API-Version anfordern. Wenn Sie keinen Versionsheader bereitstellen, wird die neueste Version der API verwendet, wodurch Integrationen möglicherweise unterbrochen werden, wenn für QRadar ein Upgrade durchgeführt wird. Es empfiehlt sich daher, in jeder API-Anforderung einen Versionsheader anzugeben, um sicherzustellen, dass Ihre API-Clients auch nach einem Upgrade auf eine neuere Version von QRadar noch funktionieren.
Die APIs verwenden den Haupt- und Nebenversionsstandard der semantischen Versionierung. Zur Bezeichnung der Hauptversionen einer API werden natürliche Zahlen verwendet, zum Beispiel '3'. Nebenversionen werden durch die Nummer der Hauptversion und eine Zahl für die Nebenversion getrennt durch einen Punkt bezeichnet, zum Beispiel '3.1'. Im Versionsheader können Sie eine Haupt- oder eine Nebenversion der API angeben. Änderungen an einer API, die kompatibel mit der aktuellen Hauptversion der API sind, werden mit der nächst höheren Nebenversionsnummer eingeführt. Mit der aktuellen Hauptversion inkompatible Änderungen werden mit der nächst höheren Hauptversionsnummer eingeführt.
Wenn im Versionsheader eine Hauptversion der API ohne Nebenversion angegeben ist, antwortet der Server mit der höchsten Nebenversion der angegebenen Hauptversion der API. Fordert der Client beispielsweise Version '3' an, so antwortet der Server eventuell mit Version '3.1'. Möchten Sie Version 3.0 verwenden, müssen Sie im Versionsheader explizit '3.0' angeben. Wenn die im Versionsheader angeforderte Version höher als die letzte Version des Endpunkts ist, wird die höchste verfügbare Version dieses Endpunkts zurückgegeben. Jeder Endpunkt wird unter der jeweiligen Version, unter der er gültig ist, aufgeführt, selbst wenn er in den neueren Versionen nicht geändert wurde.
Einstellung der Unterstützung für Endpunkte
Ein API-Endpunkt, dessen Verwendung nicht mehr empfohlen wird, weil er in künftigen Versionen entfernt wird, wird als deprecated (nicht mehr weiter unterstützt) gekennzeichnet. Um Ihnen bei Integrationen Zeit für Alternativen zu lassen, funktioniert ein nicht mehr weiter unterstützter Endpunkt noch mindestens eine weitere Version lang, bevor er entfernt wird. In der interaktiven API-Dokumentation finden Sie Hinweise auf Endpunkte, deren Unterstützung demnächst eingestellt wird. Außerdem enthält die API-Antwortnachricht für einen veralteten Endpunkt den HeaderDeprecatedEin einzelner API-Endpunkt oder eine vollständige Version von API-Endpunkten kann als veraltet markiert werden. Nicht mehr unterstützte Endpunkte funktionieren jedoch weiterhin, bis sie tatsächlich entfernt werden.
Nach Abschluss des Einstellungsprozesses wird ein API-Endpunkt entfernt. Entfernte Endpunkte antworten nicht mehr erfolgreich. Der Aufruf eines entfernten Endpunkts resultiert in einem Fehler. EineHTTP 410 GoneDie Antwort wird für einzelne entfernte Endpunkte zurückgegeben. EineHTTP 422 Unprocessable EntityAntwort wird für Anforderungen für eine Version zurückgegeben, die nicht mehr unterstützt wird.
Schließen Sie den Versionsheader in API-Anforderungen ein, wenn Sie eine bestimmte Version eines API-Endpunkts aufrufen möchten. API-Integrationen ohne explizite Anforderung einer bestimmten Version werden nicht unterstützt. Wenn Sie keine Version angeben, wird Ihre Anforderung an die höchste derzeit verfügbare Version weitergeleitet. In diesem Fall kann es passieren, dass Ihre Integration nicht mehr funktioniert, wenn diese Version eine neue, inkompatible Endpunktversion enthält. Am besten geben Sie die angeforderte Version immer an der gleichen Stelle im Code an. Sie erleichtern sich dadurch bei Verfügbarkeit neuer Versionen die Aktualisierung Ihres Codes.