O que são políticas de API Gateway?

Com o desenvolvimento da arquitetura cloud-native e de microsserviços, o papel dos gateways de API como portais de tráfego está se tornando cada vez mais crucial. Os gateways de API são responsáveis principalmente por receber o tráfego de solicitações e encaminhá-lo para os serviços upstream apropriados. As políticas do gateway de API determinam a lógica e as regras para gerenciar o tráfego, o que diretamente define o comportamento do tráfego de negócios.

O que são Políticas de Gateway de API

O gateway de API geralmente está localizado na frente de todos os serviços upstream. Quando um usuário envia uma solicitação para um serviço, a solicitação primeiro passa pelo gateway de API, e o gateway de API geralmente verifica várias coisas:

1. Verifica se a solicitação é legal. Ela vem de uma lista de usuários proibidos de acessar?
2. Verifica se a solicitação está autenticada e se o conteúdo acessado está autorizado.
3. Verifica se a solicitação aciona regras de restrição específicas, como limites de taxa.
4. Verifica para qual serviço upstream a solicitação deve ser encaminhada.

Após essa série de etapas, a solicitação é rejeitada ou chega corretamente ao serviço upstream especificado. Chamamos essas regras de processamento de políticas do gateway de API. Essas regras são continuamente adicionadas ao gateway pelo administrador do gateway enquanto ele está em execução. O gateway aceita essas regras e realiza comportamentos de processamento de tráfego correspondentes.

Tomando o gateway de API Apache APISIX como exemplo, existem dois tipos de informações de configuração do APISIX: o arquivo de configuração para inicialização do gateway, como config.yaml, este arquivo determina algumas configurações necessárias para o gateway iniciar normalmente. Além disso, os administradores podem criar dinamicamente várias regras e configurações através da Admin API durante a execução, como Route, Consumer, Plugin, etc. As políticas do gateway de API são várias regras e configurações criadas dinamicamente pelo administrador através da Admin API.

Este artigo irá detalhar os cenários dos quatro gateways de API, autenticação e autorização, segurança, processamento de tráfego e observabilidade, e como as políticas do gateway de API funcionam em cada cenário.

Política de Autenticação e Autorização

A autenticação pode confirmar a identidade do chamador da API, e a autorização restringe o chamador a acessar apenas recursos dentro da autorização.

Por exemplo, se um passageiro viaja para uma estação, ele usará seu documento de identidade para "autenticação" para confirmar sua identidade antes de entrar na estação. Após entrar na estação, ele mostrará seu bilhete ao funcionário para confirmação e será "autorizado" a entrar em um trem específico. O principal objetivo das políticas de autenticação e autorização é garantir que todas as solicitações encaminhadas para os serviços upstream sejam legais e que as solicitações acessem apenas recursos dentro do escopo de autorização. Algumas políticas padrão são as seguintes:

Autenticação Básica (Basic Auth)

A política de Autenticação de Acesso Básico é a técnica de controle de acesso mais simples. Geralmente, o proxy HTTP do usuário carrega um cabeçalho de solicitação para autenticação ao enviar uma solicitação, que geralmente é: Authorization: Basic <credentials>, e as credenciais incluem o ID do usuário e a senha necessários para a autenticação do usuário, separados por :. Este método não requer configurações complexas, como páginas de login e cookies. Ele é autenticado com base em informações simples de credenciais no cabeçalho da solicitação, geralmente um nome de usuário e senha, o que é simples de configurar e usar.

Um exemplo de uma solicitação cURL com autenticação básica é o seguinte, com username e password:

curl -i -u 'username:password' http://127.0.0.1:8080/hello

Deve-se notar que as informações em credentials não serão criptografadas durante a transmissão. Elas são apenas codificadas em base64, portanto, geralmente precisam ser usadas com HTTPS para garantir a segurança da senha.

Após a implementação dessa política no gateway, as solicitações sem credenciais não serão encaminhadas, a menos que as informações de autenticação corretas sejam carregadas na solicitação. Essa política implementa a verificação de acesso à API com o mínimo custo.

Autenticação por Chave (Key Auth)

A política de autenticação por chave restringe as chamadas de API adicionando chaves à API e usando chaves para controlar o acesso aos recursos. Apenas solicitações com a chave correta, que pode ser carregada no cabeçalho da solicitação ou na consulta, podem acessar os recursos. Geralmente, essa chave também pode ser usada para distinguir diferentes chamadores de API. Assim, diferentes políticas ou controles de recursos podem ser implementados para diferentes chamadores. Assim como a autenticação básica, a chave não é criptografada. Certifique-se de que a solicitação use HTTPS para garantir a segurança.

Tomando o plugin key-auth do APISIX como exemplo. O plugin precisa criar um Consumer com um valor de chave único através da Admin API:

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

Esta solicitação cria um Consumer chamado jack com o valor da chave jack-key.

Ao habilitar o plugin na rota, é necessário configurar a localização e o nome do campo da chave na solicitação. A configuração padrão da localização é header, e o nome do campo é apikey, então o código correto para solicitar esta rota é:

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

Assim que o APISIX receber esta solicitação, ele irá extrair a chave e corresponder ao Consumer jack de todas as chaves configuradas. Portanto, o gateway saberá que a solicitação foi enviada por jack. Se nenhuma chave correspondente for encontrada, pode ser considerada uma solicitação ilegal.

JSON Web Token (JWT)

JSON Web Token (JWT) é um padrão aberto que define uma maneira de transmitir informações com segurança entre partes na forma de objetos json. A política JWT pode combinar autenticação e autorização. Após a autorização do usuário, um token JWT será transmitido ao usuário, e o chamador carregará esse token em todas as solicitações subsequentes para garantir que a solicitação esteja autorizada.

No gateway de API, a autenticação JWT pode ser adicionada ao gateway através da política JWT. Assim, podemos separar a lógica de autenticação do código de negócios, e os desenvolvedores podem se concentrar mais na implementação da lógica de negócios. Tomando o plugin jwt-auth do APISIX como exemplo. O plugin deve ser habilitado e configurado no Consumer com sua chave única, chaves públicas e privadas para criptografia, algoritmo de criptografia, tempo de expiração do token, etc. Ao mesmo tempo, é necessário habilitar este plugin na rota e configurar o gateway para ler a localização e os campos do token, como header, query, cookie, etc. Este plugin adicionará uma API ao Gateway de API para emitir tokens. Antes de enviar a solicitação, é necessário solicitar a API que emite o token. O token precisa ser carregado na localização especificada de acordo com as informações de configuração ao enviar a solicitação. Após a solicitação chegar ao gateway, o gateway lerá o token da localização especificada da solicitação de acordo com as informações de configuração e verificará a validade do token. A solicitação pode ser encaminhada para o serviço upstream após a verificação.

Em comparação com as duas estratégias anteriores, a política JWT inclui uma opção para o tempo de expiração. O token emitido pode expirar com o tempo, mas o período de validade da Autenticação Básica e da Autenticação por Chave é permanente, a menos que o servidor altere a senha ou a chave. Além disso, a política JWT pode ser compartilhada entre vários serviços, o que é benéfico para cenários de single sign-on (SSO).

OpenID Connect

OpenID Connect é um método de autenticação e autorização baseado no protocolo OAuth2.0, fornecendo uma solução de aplicativo relativamente completa. A política OpenID Connect no gateway de API permitirá que o serviço upstream obtenha as informações do usuário do provedor de identidade (IdP), protegendo assim a segurança da API. IdPs comuns são Keycloak, Ory Hydra, Okta, Auth0, etc. Tomando o Apache APISIX como exemplo, o fluxo de trabalho da política OpenID Connect no gateway é o seguinte:

1. O cliente envia uma solicitação ao gateway
2. Após receber a solicitação, o gateway envia uma solicitação de autenticação ao IdP
3. O usuário será redirecionado para a página fornecida pelo IdP para completar a autenticação de login
4. O IdP redireciona para o gateway com o código de autenticação
5. O gateway solicita um Access Token ao IdP através do código para obter as informações do usuário
6. O gateway pode carregar as informações do usuário ao encaminhar a solicitação upstream

Este processo permite que a autenticação e a autorização sejam separadas do negócio, tornando a arquitetura mais granular.

Para mais métodos de autenticação e autorização do APISIX, consulte Autenticação de Gateway de API.

Política de Segurança

A política de segurança do gateway de API atua como um guardião para garantir o acesso seguro à API, permitindo que solicitações legais sejam encaminhadas pelo gateway e bloqueando solicitações ilegais no gateway. De acordo com o Projeto de Segurança de API da OWASP, existem muitas possíveis ameaças e ataques aos chamadores de API. Usar a política de segurança do gateway de API pode realizar verificações de segurança em todas as solicitações de API, o que desempenha um papel essencial na proteção da API contra essas ameaças de segurança.

A seguir estão várias políticas importantes de segurança do gateway de API:

Restrições de Acesso por IP

A política de restrição de IP restringe o acesso de clientes específicos à API, configurando determinados IPs ou CIDR em uma lista de permissões ou negações para proibir o acesso malicioso a dados sensíveis. Configurar adequadamente essa política melhorará significativamente a segurança da API e permitirá uma governança de segurança de API mais elevada.

Bloqueador de URI

A política de bloqueio de URI intercepta solicitações de API potencialmente perigosas, configurando algumas regras de URI. Por exemplo, alguns ataques de segurança detectam vulnerabilidades potenciais farejando o caminho do URI e, em seguida, atacam. O Apache APISIX fornece o plugin uri-blocker para bloquear solicitações de API perigosas. Também é possível configurar expressões regulares através do plugin uri-blocker. O gateway de API bloqueará a solicitação se ela corresponder à regra. Por exemplo, se configurarmos root.exe, admin, este plugin pode bloquear solicitações */root.exe e */admin para proteger ainda mais a segurança da API.

CORS

CORS (Compartilhamento de Recursos de Origem Cruzada) é a política de segurança do navegador para solicitações de domínio cruzado. Geralmente, antes de enviar uma solicitação xhr no navegador, o navegador verificará se o endereço da solicitação e o endereço atual estão na mesma origem. Solicitações dentro da mesma origem serão enviadas diretamente. Caso contrário, o navegador primeiro enviará uma solicitação de pré-voo de domínio cruzado do tipo OPTION. Haverá configurações relacionadas ao CORS no cabeçalho de resposta, como os métodos e as credenciais permitidas para serem carregadas nas solicitações de domínio cruzado. O navegador decidirá se enviará uma solicitação formal com base nessas informações. Para detalhes, consulte CORS.

Geralmente, a resposta contendo configurações de CORS é definida pelo serviço de back-end. Mas, se houver muitos serviços, será mais seguro e conveniente processá-los uniformemente no nível do gateway. A política CORS pode definir diferentes políticas de resolução de origem cruzada em diferentes APIs, e os serviços upstream não precisam mais lidar com essas lógicas.

CSRF

CSRF é um ataque de falsificação de solicitação entre sites, que faz com que os usuários finais realizem ações involuntárias no site em que estão autenticados. Este ataque geralmente é acompanhado por engenharia social (enviando um link malicioso à vítima por e-mail). Quando o usuário clica no link, o atacante usa a identidade autenticada da vítima para realizar operações de ataque no site. Do ponto de vista do site, qualquer comportamento é esperado porque o usuário já está logado.

Geralmente, o serviço de back-end do site precisa adicionar middleware adicional para lidar com essa parte da lógica, e os métodos de prevenção também têm padrões específicos. Usar a política CSRF pode prevenir esse ataque e realizar o processamento de segurança CSRF na camada do gateway para simplificar a complexidade lógica dos serviços upstream.

Política de Processamento de Tráfego

A política de processamento de tráfego garante principalmente que a carga upstream do gateway de API para o encaminhamento de tráfego esteja dentro de um intervalo saudável. Ao mesmo tempo, a solicitação é reescrita sob demanda antes de ser encaminhada ou retornada ao chamador. Esse tipo de política é principalmente sobre funcionalidades como limitação de taxa, circuit breaker, cache e reescrita.

Limitação de Taxa (Rate Limiting)

No caso de recursos limitados, há um limite para as capacidades de serviço que a API pode fornecer. Se a chamada exceder esse limite, o serviço upstream pode falhar e causar algumas reações em cadeia. A limitação de taxa pode evitar tais casos e pode efetivamente prevenir que as APIs sejam atacadas por DDOS (Ataque de Negação de Serviço).

Podemos configurar uma janela de tempo e o número máximo permitido de solicitações na política de limitação de taxa. O gateway de API rejeitará solicitações que excedam o número máximo permitido e retornará uma mensagem de erro de limite de taxa. A solicitação não será permitida até que o número de solicitações seja menor que o limite ou a próxima janela de tempo seja aberta.

A variável para contagem de solicitações pode ser definida na solicitação ou como um cabeçalho de solicitação específico, por exemplo, para definir a política de limitação de taxa correspondente de acordo com diferentes IPs para obter melhor flexibilidade.

Circuit Breaker

A política de circuit breaker do API pode fornecer a capacidade de circuit breaker para serviços upstream. Ao usar essa política, você precisa definir os códigos de status de serviços upstream saudáveis e não saudáveis para que o gateway julgue o status dos serviços upstream. Além disso, também é necessário definir o limite de solicitações para acionar uma interrupção ou restaurar a saúde. Quando o serviço upstream retorna continuamente códigos de status não saudáveis ao gateway, o gateway interromperá o serviço upstream por algum tempo. Durante esse período, o gateway não encaminhará mais solicitações para o upstream, mas retornará diretamente um erro. Isso pode evitar que os serviços upstream sofram um "efeito avalanche" de continuar a receber solicitações devido a erros e proteger os serviços de negócios. Após esse período, o gateway tentará encaminhar a solicitação para o upstream novamente. Se ainda retornar um código de status não saudável, o gateway continuará a interromper por um tempo mais longo (dobrado). Até que o upstream retorne um certo número de códigos de status saudáveis, o gateway acreditará que o serviço upstream está de volta à saúde e continuará a encaminhar o tráfego para o nó upstream.

Nessa política, também é necessário definir o código de status e a informação que precisa ser retornada quando não estiver saudável. Quando o serviço upstream não estiver saudável, a solicitação é retornada diretamente no nível do gateway para proteger a estabilidade dos serviços de negócios.

Divisão de Tráfego (Traffic Splitting)

A política de divisão de tráfego pode controlar dinamicamente o encaminhamento de tráfego para diferentes serviços upstream em proporção. É vantajoso em lançamentos canário e implantação azul-verde.

O lançamento canário permite que apenas algumas solicitações usem o novo serviço, enquanto a outra parte permanece no serviço antigo. Se o novo serviço permanecer estável, você pode aumentar a proporção e gradualmente transferir todas as solicitações para o novo serviço até que a proporção seja totalmente alterada para completar a atualização.

O lançamento azul-verde é outro modo de lançamento, que lança uma nova versão durante o período de pico sem interromper o serviço. Ambos os serviços, antigo e novo, coexistem. Normalmente, o ambiente de produção (azul) é copiado para um contêiner idêntico, mas separado (verde). Lança novas atualizações para o ambiente verde e, em seguida, lança ambos, verde e azul, para produção. O ambiente verde pode então ser testado e reparado enquanto o usuário ainda está acessando o sistema azul. As solicitações podem então ser redirecionadas para o ambiente verde usando alguma política de balanceamento de carga. O ambiente azul pode então ser mantido em espera como uma opção de recuperação de desastres ou para a próxima atualização.

O APISIX suporta ambos os lançamentos através do plugin traffic-split, tornando a implantação de negócios mais conveniente e confiável.

Reescrita de Resposta (Response Rewrite)

Na arquitetura moderna de microsserviços, existem muitos protocolos diferentes entre os serviços e não há formatos uniformes de dados de resposta. Se essa lógica de transcodificação for implementada separadamente em seus respectivos serviços, haverá código lógico redundante, o que é difícil de gerenciar. Algumas políticas de reescrita de resposta podem lidar com a conversão de protocolo, reescrita do corpo da solicitação e outras lógicas.

O APISIX fornece um plugin Response Rewrite para modificar as informações de Body ou Header retornadas pelos serviços upstream e suporta adicionar ou remover cabeçalhos de resposta, definir regras para modificar o corpo da resposta, etc. É útil em cenários como definir cabeçalhos de resposta CORS para solicitações de origem cruzada ou definir localização para redirecionamento.

Por outro lado, o APISIX fornece proxy-rewrite para reescrita de solicitação. O plugin também pode lidar com o conteúdo da solicitação encaminhado para o serviço upstream. Você pode reescrever o URI da solicitação, o método, o cabeçalho da solicitação, etc., o que fornece conveniência para o processamento de negócios em muitos cenários.

Injeção de Falhas (Fault Injection)

A injeção de falhas é um método de teste de software que garante o comportamento correto de um sistema introduzindo erros intencionalmente. Geralmente, o teste é feito antes da implantação para garantir que não haja falhas potenciais no ambiente de produção. Em alguns cenários de teste de caos, é necessário injetar alguns erros no serviço para verificar sua confiabilidade.

A injeção de falhas de software pode ser categorizada em injeção em tempo de compilação e injeção em tempo de execução. A injeção em tempo de compilação refere-se a alterar algum código ou lógica na escrita do software. A injeção em tempo de execução testa o comportamento do software configurando erros no ambiente de execução do software. A política de injeção de falhas pode simular falhas em solicitações de rede de aplicativos através da injeção em tempo de execução. Ao selecionar uma proporção na política, as solicitações nessa proporção executarão a lógica de falha, como retornar com um tempo de atraso ou retornar diretamente o código de erro e a mensagem de erro configurados para o chamador. Dessa forma, a adaptabilidade do software pode ser aumentada, permitindo que os desenvolvedores vejam algumas possíveis situações de erro com antecedência e façam modificações adaptativas aos problemas antes do lançamento.

Conversão de Protocolo (Protocol Conversion)

A política de conversão de protocolo pode converter entre alguns protocolos padrão, como solicitações HTTP comuns e gRPC. O Apache APISIX fornece o plugin grpc-transcode que pode transcodificar e encaminhar a solicitação HTTP para serviços do tipo gRPC. A resposta é retornada ao cliente no formato HTTP. Dessa forma, o cliente pode se concentrar apenas no HTTP sem se preocupar com o tipo de gRPC upstream.

Política de Observabilidade

Observabilidade refere-se à capacidade de medir o status operacional do sistema através dos dados de saída do sistema. Em alguns sistemas simples, como o número de componentes do sistema é relativamente pequeno, o bug pode ser encontrado analisando o status de cada componente quando ocorre um erro. No entanto, em um sistema distribuído de grande escala, o número de vários componentes de microsserviços é enorme, e é irrealista verificar os componentes um por um. Nesse momento, o sistema precisa ser observável. A observabilidade fornece visibilidade de um sistema extenso e, quando ocorre um problema, pode fornecer aos engenheiros o controle necessário para identificar o problema.

A coleta de dados pode ser implementada dentro dos componentes do aplicativo. O gateway de API é a entrada de todo o tráfego, portanto, implementar os recursos de observabilidade do sistema no gateway de API pode refletir o uso da API do sistema. Uma política de observabilidade do Gateway de API pode ajudar todas as equipes:

• Uma equipe de engenheiros pode monitorar e resolver problemas de API.
• A equipe de produtos pode entender o uso da API para descobrir o valor de negócio por trás dela.
• As equipes de vendas e crescimento podem monitorar o uso da API, observar oportunidades de negócios e garantir que as APIs entreguem os dados corretos.

As políticas de observabilidade são geralmente divididas em três categorias de acordo com o tipo de dados de saída: Rastreamento (Tracing), Métricas (Metrics) e Registros (Logging).

Rastreamento (Tracing)

Em um sistema distribuído de grande escala, a relação entre os serviços é intrincada. O rastreamento (link tracking) pode rastrear o link completo de chamada, análise de dependência entre aplicativos e estatísticas de solicitação em aplicativos distribuídos. Quando ocorre um problema no sistema, pode ajudar os engenheiros a determinar o escopo e a localização da investigação.

A política de rastreamento pode integrar outros sistemas de rastreamento de chamadas distribuídas no Gateway de API para coletar e registrar informações. Por exemplo, integrar serviços como Zipkin e SkyWalking no gateway de API para coletar dados e comunicação entre serviços. Portanto, essa política permite que os engenheiros saibam qual log ver para uma sessão específica ou chamadas de API relacionadas e verifiquem o escopo de solução de problemas.

Métricas (Metrics)

Métricas referem-se aos dados de observação de um software coletados durante um intervalo de tempo da operação do serviço. Esses dados são estruturados por padrão, o que facilita a consulta e a visualização. Pode-se aprender o status operacional do sistema através da análise desses dados.

A política de métricas pode integrar serviços como Prometheus ou Datadog no gateway de API para fornecer capacidades de monitoramento e alarme para o sistema. Essa política coleta dados durante a operação do gateway através de várias interfaces do gateway de API e relata os dados para Prometheus ou Datadog. Ao visualizar esses dados, os desenvolvedores podem ver o status de execução do gateway, as informações estatísticas das solicitações de API e outros gráficos estatísticos.

Registros (Logging)

O log é um registro de texto de eventos do sistema em um momento específico. O log é o primeiro lugar a ser verificado quando ocorre um problema no sistema. Os engenheiros dependem do conteúdo do log para descobrir o que aconteceu com o sistema e a solução correspondente. O conteúdo do log é geralmente dividido em log de solicitação de API e log de execução do gateway. O log de solicitação de API registra todos os registros de solicitação de API durante a operação do gateway de API. Os engenheiros podem aprender as informações de acesso à API através desses registros e descobrir e solucionar solicitações anormais em tempo hábil. O log de operação do gateway contém registros de todos os eventos que ocorreram durante o funcionamento do gateway. Quando o gateway de API está anormal, pode ser usado como uma base essencial para solução de problemas.

A política de registro pode armazenar os logs no gateway de API no disco do servidor ou enviá-los para outros servidores de log, como servidor de log HTTP, servidor de log TCP, servidor de log UDP, etc., ou outros sistemas de log como Kafka, RocketMQ, Clickhouse.

Resumo

Este artigo introduz quatro políticas comumente usadas em gateways de API: autenticação e autorização, segurança, processamento de tráfego e observabilidade. O Gateway de API recebe o tráfego de solicitação antes de todos os serviços upstream, controla onde e como as solicitações são encaminhadas e rejeita ou restringe diretamente solicitações inseguras e não autorizadas. As políticas do Gateway de API podem configurar todos esses comportamentos.

Para mais informações relacionadas ao gateway de API, visite blogs e API7.ai para mais suporte comercial.