Documentación de punto final de API de QRadar y versiones soportadas
Puede acceder a la API RESTful enviando solicitudes HTTPS a URL específicas (puntos finales) en la consola QRadar® SIEM. Para enviar estas solicitudes, utilice la implementación de HTTP compilada en el lenguaje de programación de su elección. Cada solicitud contiene información de autenticación y parámetros que modifican la solicitud.
QRadar y versiones de API
| QRadar versión | Versión de API REST introducida | Versiones de API REST soportadas | Versiones de API REST en desuso |
|---|---|---|---|
| 7.5.0 Actualización de los paquetes 12 y 13 | 26.0 | 26.0 25.0 24.0 |
|
| 7.5.0 Paquete de actualización 11 | 25.0 | 25.0 24.0 23.0 |
|
| 7.5.0 Paquete de actualización 10 | 24.0 | 24.0 23.0 22.0 |
|
| 7.5.0 Paquete de actualización 9 | 23.0 | 23.0 22.0 21.0 |
|
| 7.5.0 Paquete de actualización 8 | 22.0 | 22.0 21.0 20.0 |
|
| 7.5.0 Paquete de actualización 7 | 21.0 | 21.0 20.0 19.0 |
|
| 7.5.0 Paquete de actualización 6 | 20.0 | 20.0 19.0 18.0 |
17.x |
| 7.5.0 Paquete de actualización 3 | 19.0 | 19.0 18.0 17.0 |
16.x |
| 7.5.0 Paquete de actualización 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 |
Puntos finales de API
Un punto final de API contiene el URL del recurso al que desea acceder y la acción que desea completar en ese recurso. La acción se indica con el método HTTP de la solicitud: GET, POST, PUT o DELETE.
Permisos necesarios para acceder a la API
- Un nombre de usuario y una contraseña para un usuario de QRadar que se especifica en la cabecera de autorización.
Especifique el nombre de usuario y la contraseña utilizando la autenticación básica HTTP. Aunque puede crear solicitudes de API proporcionando un nombre de usuario y una contraseña para cada solicitud, utilice las señales de servicio autorizados para todas las integraciones de API con QRadar. La opción de nombre de usuario y contraseña solo se soporta para la visualización de la página de documentación.
Para obtener más información sobre cómo crear roles de usuario, perfiles de seguridad y usuarios, consulte la publicación IBM QRadar Guía de administración.
- Una señal de servicios autorizados que se especifica en la cabecera SEC.
Para autenticarse como servicio autorizado, cree una señal de autenticación que utiliza servicios autorizados. Los servicios autorizados de QRadar tienen roles y perfiles de seguridad asignados que controlan el acceso a los distintos recursos de API.
La señal es válida hasta la fecha de caducidad que ha especificado al crear el servicio autorizado.
Para obtener más información sobre cómo crear roles de usuario, perfiles de seguridad y servicios autorizados, consulte la publicación IBM QRadar Guía de administración.
Solicitudes y respuestas de API
Cuando envía una solicitud de API, el servidor devuelve una respuesta HTTP. La respuesta HTTP contiene un código de estado para indicar si la solicitud ha tenido éxito y los detalles de la respuesta en el cuerpo de respuesta. La mayoría de los recursos dan formato a esta respuesta como JavaScript Object Notation (JSON). Puede utilizar bibliotecas o paquetes JSON compilados en el lenguaje de programación que utiliza para extraer los datos.
Para ver un ejemplo completo de este proceso, consulte el código de ejemplo en GitHub ( https://github.com/ibm-security-intelligence/api-samples ).
Cabeceras de versión
Utilice cabeceras de versión para solicitar una versión específica de la API. Si no proporciona una cabecera de versión, se utiliza la versión más reciente de la API, lo que puede interrumpir las integraciones cuando se actualice QRadar . Si proporciona una cabecera de versión cada vez que utiliza una API, facilita la actualización a versiones más recientes de QRadar sin interrumpir a sus clientes de API.
Las API utilizan componentes principales y menores del mantenimiento de versiones semánticas. Los números naturales se utilizan para designar versiones principales de la API, por ejemplo, '3'. Las versiones secundarias de la API se designan con un componente principal y uno menor, por ejemplo, '3.1'. Puede establecer la cabecera de versión en una versión principal o menor de la API. Los cambios compatibles con versiones existentes se introducen con un número de versión menor incrementado. Los cambios incompatibles se introducen con un incremento de número de versión principal.
Cuando se especifica una versión principal de la API en la cabecera de versión sin un componente menor, el servidor responde con la versión menos más reciente dentro de la versión de API principal. Por ejemplo, si el cliente solicita la versión '3', el servidor responde con la versión '3.1'. Si desea utilizar la versión 3.0, debe solicitar '3.0' en la cabecera de versión. Si solicita una versión mayor que la versión más reciente de un punto final, se devuelve la versión más reciente disponible de ese punto final. Cada punto final se lista bajo cada versión para la que es válido, aunque no cambie en las versiones más recientes.
Punto final en desuso
Un punto final de API se marca como en desuso para indicar que no se recomienda su uso y que se eliminará en un release futuro. Para dar tiempo a que las integraciones utilicen una alternativa, un punto final en desuso continúa funcionando durante al menos 1 release antes de que se elimine. La página de documentación de la API interactiva indica que un punto final está marcado como en desuso. Además, el mensaje de respuesta de la API para un punto final en desuso incluye la cabeceraDeprecated. Un punto final de API individual o una versión completa de puntos finales de API se pueden marcar como en desuso. Los puntos finales en desuso continúan funcionando hasta que se eliminan.
Cuando un punto final de API completa el proceso de dejar en desuso, se elimina. Los puntos finales que se eliminan ya no responden correctamente. El intento de llamar a un punto final eliminado devuelve un error. UnaHTTP 410 Gonese devuelve una respuesta para puntos finales eliminados individuales. UnaHTTP 422 Unprocessable Entityse devuelve una respuesta para las solicitudes de una versión que ya no está soportada.
Incluya la cabecera de versión en las solicitudes de API para llamar a una versión específica de un punto final de API. Las integraciones de API que no solicitan explícitamente una versión particular no se soportan. Si no especifica una versión, la solicitud se dirige a la versión más reciente disponible. Si un release incluye una versión nueva incompatible de un punto final, la integración puede interrumpirse. Debe tener la versión de solicitud en una ubicación en el código para facilitar la actualización cuando hay versiones más nuevas disponibles.