Boletins de segurança

Veja a seguir todos os boletins de segurança relacionados à Apigee.

Para receber os boletins de segurança mais recentes, siga um destes procedimentos:

  • Adicione o URL desta página ao seu leitor de feeds
  • Adicione o URL do feed diretamente ao seu leitor de feeds: https://cloud.google.com/feeds/apigee-security-bulletins.xml

GCP-2024-006

Publicado: 02/05/2024

Descrição Gravidade Observações

Quando um proxy de gerenciamento de APIs da Apigee se conecta a um endpoint de destino ou servidor de destino, o proxy não realiza a validação do nome do host para o certificado apresentado pelo endpoint ou servidor de destino por padrão. Se a validação do nome do host não estiver ativada usando uma das opções a seguir, os proxies da Apigee que se conectam a um endpoint ou servidor de destino poderão estar em risco de um ataque "man-in-the-middle" por um usuário autorizado. Para mais informações, consulte Como configurar o TLS da borda para o back-end (nuvem e nuvem privada).

Produtos afetados

As implantações de proxy da Apigee nas seguintes plataformas da Apigee foram afetadas:

  • Apigee Edge para nuvem pública
  • Apigee Edge para nuvem privada

O que devo fazer?

Os clientes podem usar uma das seguintes opções para ativar a validação:

Opção 1: adicionar uma configuração ao proxy

Para ativar a validação do endpoint ou servidor de destino, adicione uma configuração <CommonName> à seção SSLInfo do elemento <HTTPTargetConnection> na configuração de proxy, conforme mostrado:


<HTTPTargetConnection>
  <SSLInfo>
    <Enabled>true</Enabled>
    <TrustStore>ref://mytruststoreref</TrustStore>
    <CommonName>*.example.com</CommonName>
  </SSLInfo>
  <URL>https://my.example.com/</URL>
</HTTPTargetConnection>

Se essa configuração estiver presente no elemento <HTTPTargetConnection> da configuração do proxy, a Apigee usará o valor especificado em <CommonName> para a validação do nome do host. Caracteres curingas podem ser usados nesse campo.

A Apigee recomenda essa abordagem. É possível testar os proxies individualmente para confirmar se a validação está funcionando conforme o esperado, com possível interrupção mínima do tráfego. Para saber mais sobre como testar a validação do nome do host nos proxies e verificar as falhas, consulte Como usar a ferramenta de rastreamento.

Opção 2: definir uma flag no nível da organização

É possível definir uma flag no nível da organização da Apigee para ativar a validação do nome do host em todos os proxies e destinos implantados na organização. Se a flag features.strictSSLEnforcement estiver definida como true nas propriedades da organização, a validação do nome do host será aplicada sempre que o proxy se conectar a um endpoint ou servidor de destino.

Observação: embora essa opção possa ajudar a ativar o recurso em toda a organização, poderão ocorrer falhas na validação do nome do host se os destinos não apresentarem os certificados esperados.

  • Para implantações do Apigee Edge for Public Cloud:

    Entre em contato com o suporte do Google Cloud para definir a flag features.strictSSLEnforcement como true nas propriedades da organização.

    Observação: ativar essa flag aplicará a verificação de SSL a todos os ambientes em uma organização e a todos os proxies implantados nesses ambientes.

  • Para implantações do Apigee Edge for Private Cloud :

    A flag features.strictSSLEnforcement pode ser definida como true pelo administrador do sistema ou da organização. Para mais informações sobre como definir a flag, consulte Como atualizar as propriedades da organização.

    Observação: ao atualizar as flags no nível da organização usando a API Groups, inclua todas as flags atuais na solicitação POST para evitar a substituição das configurações anteriores.

    Depois que a flag é definida, é necessário reiniciar cada processador de mensagens individualmente para que a mudança entre em vigor. Use o comando a seguir:

    
apigee-service edge-message-processor restart

    Para reverter essa alteração, use a mesma API Organization para definir a flag como false e, em seguida, reinicie cada processador de mensagens.

    Observação: ativar essa flag aplicará a verificação de SSL a todos os ambientes em uma organização e a todos os proxies implantados nesses ambientes. No entanto, se <IgnoreValidationErrors> for definido como true, todos os erros de validação detectados serão ignorados.

A Apigee recomenda implementar essa mudança primeiro em ambientes que não sejam de produção, para garantir que a validação funcione conforme o esperado e não resulte em interrupções na produção. Caso a validação do nome do host falhe para algum destino, a seguinte mensagem de falha será retornada:


{"fault":{"faultstring":"SSL Handshake failed java.security.cert.CertificateException: No subject alternative DNS name matching example.com found.","detail":{"errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"}}}
 Alto

GCP-2023-032

Publicado: 2023-10-13

Atualizado em: 03/11/2023

Descrição Gravidade Observações

Atualização de 03/11/2023: foi adicionado um problema conhecido relacionado ao Apigee Edge para nuvem privada.

Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias implementações do protocolo HTTP/2 (CVE-2023-44487), incluindo o serviço de entrada da Apigee (Anthos Service Mesh) usado pela Apigee X e Apigee híbrida. A vulnerabilidade pode levar a um DoS da funcionalidade de gerenciamento da API Apigee.

Produtos afetados

  • Apigee X

    As implantações da Apigee X que são acessíveis por meio de um balanceador de carga de rede do Google Cloud (camada 4) ou de um balanceador de carga de camada 4 personalizado serão afetadas. Um hotfix foi aplicado a todas as instâncias da Apigee X.

  • Apigee híbrida

    As instâncias da Apigee híbrida que permitem que solicitações HTTP/2 cheguem à entrada da Apigee serão afetadas. Os clientes precisam verificar se os balanceadores de carga na entrada da Apigee híbrida permitem que solicitações HTTP/2 cheguem ao serviço de entrada da Apigee.

  • Apigee Edge para nuvem privada

    Os componentes do servidor de gerenciamento e do roteador do Edge para nuvem privada estão expostos à Internet e podem estar vulneráveis. Embora o HTTP/2 esteja ativado na porta de gerenciamento de outros componentes específicos do Edge relativos ao Edge para nuvem privada, nenhum deles está exposto à Internet. Em componentes que não são do Edge, como Cassandra, Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que você siga as etapas em Problemas conhecidos com o Edge para nuvem privada a fim de lidar com a vulnerabilidade do Edge para nuvem privada.

Produtos não afetados

  • Apigee X

    As instâncias da Apigee X que são acessadas apenas pelos balanceadores de carga de aplicativo do Google Cloud (camada 7) não serão afetadas. Isso inclui implantações com HTTP/2 ativado para proxies gRPC.

  • Gateway da API Google Cloud

    A API Gateway do Google Cloud não foi afetada.

  • Apigee Edge Cloud

    O Apigee Edge Cloud não é afetado por essa vulnerabilidade.

O que devo fazer?

  • Apigee X

    Atualização de 03/11/2023: a vulnerabilidade foi resolvida por meio da atualização das instâncias da Apigee X, lançada em 13/10/2023. Consulte as Notas de lançamento para saber mais.

  • Apigee híbrida

    Os clientes da Apigee híbrida precisam fazer upgrade para uma das seguintes versões de patch:

  • Apigee Edge para nuvem privada

    Os usuários do Apigee Edge para nuvem privada podem seguir as instruções publicadas em Problemas conhecidos com o Edge para nuvem privada a fim de desativar explicitamente o HTTP/2 para os componentes expostos.

Quais vulnerabilidades serão corrigidas?

A vulnerabilidade CVE-2023-44487 pode levar a um ataque de DoS na funcionalidade de gerenciamento da API Apigee.

Alto CVE-2023-44487