QRadar Documentação do terminal de API e versões suportadas
Você acessa a API RESTful enviando solicitações HTTPS para URLs específicos (pontos de extremidade) no QRadar® SIEM Console. Para enviar essas solicitações, use a implementação HTTP que é construída na linguagem de programação de sua escolha. Cada solicitação contém informações de autenticação e parâmetros que modificam a solicitação.
QRadar e versões de API
| QRadar versão | Versão da API de REST apresentada | Versões da API REST suportadas | Versões da API de REST descontinuadas |
|---|---|---|---|
| 7.5.0 Pacote de atualização 12 e 13 | 26.0 | 26.0 25.0 24.0 |
|
| 7.5.0 Pacote de atualização 11 | 25.0 | 25.0 24.0 23.0 |
|
| 7.5.0 Pacote de atualização 10 | 24.0 | 24.0 23.0 22.0 |
|
| 7.5.0 Pacote de atualização 9 | 23.0 | 23.0 22.0 21.0 |
|
| 7.5.0 Pacote de atualização 8 | 22.0 | 22.0 21.0 20.0 |
|
| 7.5.0 Pacote de atualização 7 | 21.0 | 21.0 20.0 19.0 |
|
| 7.5.0 Pacote de Atualização 6 | 20.0 | 20.0 19.0 18.0 |
17.x |
| 7.5.0 Pacote de Atualização 3 | 19.0 | 19.0 18.0 17.0 |
16.x |
| 7.5.0 Pacote de Atualização 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 Pacote de correção 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 |
Terminais de API
Um terminal de API contém a URL do recurso que você deseja acessar e a ação que você deseja concluir nesse recurso. A ação é indicada pelo método de HTTP da solicitação: GET, POST, PUT ou DELETE.
Permissões necessárias para acessar a API
- Um nome de usuário e senha para um usuário do QRadar especificado no cabeçalho de autorização.
Você especifica o nome de usuário e a senha usando a autenticação básica HTTP. Embora seja possível fazer solicitações da API fornecendo um nome de usuário e uma senha para cada solicitação, use tokens de serviço autorizado para todas as integrações da API com o QRadar. Somente a opção de nome de usuário e senha é suportada para visualizar a página Documentação.
Para obter mais informações sobre como criar funções de usuário, perfis de segurança e usuários, consulte o IBM QRadar Administration Guide.
- Um token de serviços autorizados que é especificado no cabeçalho SEC.
Para autenticar como um serviço autorizado, você cria um token de autenticação que usa serviços autorizados. QRadar serviços autorizados têm funções e perfis de segurança designados que controlam o acesso aos vários recursos da API.
O token é válido até a data de expiração que você especificou quando criou o serviço autorizado.
Para obter mais informações sobre como criar funções de usuário, perfis de segurança e serviços autorizados, consulte Guia de Administração do IBM QRadar.
Solicitações e respostas da API
Quando você envia uma solicitação da API, o servidor retorna uma resposta HTTP. A resposta HTTP contém um código de status para indicar se a solicitação foi bem-sucedida e os detalhes da resposta no corpo de resposta. A maioria dos recursos formatam essa resposta como JavaScript Object Notation (JSON). É possível usar os pacotes ou as bibliotecas JSON integrados à linguagem de programação usada para extrair os dados.
Para obter um exemplo completo desse processo, consulte o código de amostra em GitHub ( https://github.com/ibm-security-intelligence/api-samples ).
Cabeçalhos de versão
Você usa cabeçalhos de versão para solicitar uma versão específica da API. Se você não fornecer um cabeçalho de versão, a versão mais recente da API será usada, o que pode quebrar integrações quando QRadar for atualizado. Se você fornecer um cabeçalho de versão toda vez que usar uma API, é mais fácil fazer upgrade para versões mais recentes do QRadar sem interromper seus clientes da API.
As APIs usam os componentes principal e secundário de versão semântica. Números naturais são usados para designar versões principais da API, por exemplo, '3'. Versões secundárias da API são designadas com um componente principal e secundário, por exemplo, '3.1'. É possível configurar o cabeçalho de versão para um versão principal ou secundária da API. Mudanças compatíveis com versões existentes são introduzidas com um número de versão secundária incrementado. Quaisquer mudanças incompatíveis são introduzidas com um incremento de número da versão principal.
Quando uma versão principal da API for especificada no cabeçalho de versão sem um componente secundário, o servidor responde com a versão secundária mais recente dentro da versão principal da API. Por exemplo, se o cliente solicitar a versão '3', o servidor responde com a versão '3.1'. Se você deseja usar a versão 3.0, deve-se solicitar '3.0' no cabeçalho de versão. Se você solicitar uma versão maior que a versão mais recente de um terminal, a versão mais recente disponível desse terminal será retornada. Cada terminal é listado sob cada versão para a qual ele for válido, mesmo se ele estiver inalterado nas versões mais recentes.
Descontinuação de terminal
Um terminal de API é marcado como descontinuado para indicar que não é recomendado para uso e que será removido em uma liberação futura. Para dar as integrações tempo para uma usar uma alternativa um endpoint descontinuado continua a funcionar por pelo menos uma liberação antes de ser removido. A página de documentação da API interativa indica que um endpoint foi marcado como descontinuado. Também, a mensagem de resposta da API para um terminal obsoletado inclui o cabeçalhoDeprecated. Um terminal de API individual ou uma versão inteira de terminais de API podem ser marcados como reprovados. Os endpoints descontinuados ainda continuam a funcionar até eles serem removidos.
Quando um terminal da API conclui o processo de descontinuação, ele será removido. Os terminais que foram removidos não respondem mais com sucesso. Uma tentativa de chamar um terminal removido retorna um erro. UmaHTTP 410 Goneresposta é retornado para terminais removidos individuais. UmaHTTP 422 Unprocessable Entityresposta é retornada para pedidos de uma versão que não é mais suportada.
Inclua o cabeçalho de versão em solicitações da API para chamar uma versão específica de um terminal da API. Integrações de API que não solicitam explicitamente uma versão específica não são suportadas. Se você não especificar uma versão, sua solicitação será direcionada para a versão mais recente disponível. Se uma liberação incluir uma nova versão incompatível de um terminal, sua integração pode ser interrompida. Coloque sua versão de solicitação em um local em seu código para facilitar o upgrade conforme versões mais recentes se tornam disponíveis.