Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.
Neste documento, descrevemos como o Google gerencia vulnerabilidades e patches de segurança para a Apigee híbrida. Salvo indicação contrária, a Apigee inclui o plano de gerenciamento e o plano de dados.
Responsabilidade do patch compartilhado
A aplicação de patches é uma responsabilidade compartilhada entre o Google e o cliente. A Apigee X e a Apigee híbrida têm diferentes responsabilidades compartilhadas, já que o plano de dados da Apigee híbrida é totalmente gerenciado pelo cliente. Para informações sobre as responsabilidades compartilhadas da Apigee híbrida, consulte Modelo de responsabilidade compartilhada da Apigee híbrida.
Como as vulnerabilidades são descobertas
O Google adota uma abordagem proativa para a segurança dos sistemas de software, usando princípios de design Secure por padrão e implementação de várias práticas de aumento da segurança.
Por exemplo, aplicativos conteinerizados potencializam os vários recursos da plataforma de gerenciamento de APIs da Apigee. Os aplicativos conteinerizados são implantados no Kubernetes. As imagens de contêiner são criadas com base em imagens de base mínimas (por exemplo, imagens básicas de distroless) para maior segurança e desempenho aprimorado.
No entanto, mesmo os melhores sistemas de software podem ter vulnerabilidades. Para encontrar essas vulnerabilidades e corrigi-las antes de serem exploradas, o Google fez investimentos significativos em várias frentes.
Verificações de segurança
O Google identifica e corrige proativamente vulnerabilidades em diferentes tipos de imagens de contêiner:
- Contêineres primários: imagens de contêiner criadas e distribuídas pelo Google como parte da plataforma Apigee. Esses são os aplicativos reservados do Google que servem como base para a plataforma de gerenciamento de APIs da Apigee, incluindo funcionalidades principais, como roteamento de tráfego, gerenciamento de cotas e gerenciamento de chaves.
- Contêineres de terceiros: imagens de contêiner criadas pela comunidade de código aberto, mas distribuídas pelo Google como parte da plataforma Apigee. Na maioria das vezes, eles são componentes de código aberto usados pela plataforma para tarefas operacionais comuns, como geração de registros, monitoramento e gerenciamento de certificados.
O Google verifica os contêineres usando o Container Registry Container Analysis para descobrir vulnerabilidades e falta de patches em contêineres próprios e de terceiros. Se as correções estiverem disponíveis, o Google vai iniciar o processo de correção e liberação. Essas verificações são executadas regularmente (quando novas imagens são publicadas), assim como sob demanda (antes de uma versão) para maximizar as chances de detectar novas vulnerabilidades e planejamento de remediação ou mitigação antecipada.
Pesquisa de segurança
Além da verificação automatizada, o Google descobre e corrige vulnerabilidades desconhecidas aos scanners das seguintes maneiras.
- O Google realiza auditorias de segurança e conformidade próprias, testes de penetração da rede
e do aplicativo, testes de segmentação e descoberta de vulnerabilidades de segurança em todos os
componentes da Apigee.
Equipes especializadas do Google e fornecedores confiáveis de terceiros conduzem suas próprias pesquisas de ataque. - O Google colabora com outros parceiros de software de código aberto e do setor que compartilham vulnerabilidades, pesquisa de segurança e patches antes do lançamento público da vulnerabilidade.
O objetivo desta colaboração é aplicar patches às principais partes da infraestrutura da Internet antes que a vulnerabilidade seja anunciada para o público. Em alguns casos, o Google contribui com as vulnerabilidades encontradas para essa comunidade. Por exemplo, o Projeto Zero do Google descobriu e divulgava as vulnerabilidades do Spectre e Meltdown. A equipe de segurança do Google Cloud também encontra e corrige regularmente as vulnerabilidades na máquina virtual baseada em kernel (KVM, na sigla em inglês).
Programas de fidelidade por vulnerabilidade
O Google envolve ativamente a comunidade de pesquisa de segurança por meio de vários programas de recompensa por vulnerabilidade. Um deles, dedicado ao Google Cloud, oferece recompensas significativas, incluindo US$ 133.337 para a melhor vulnerabilidade de nuvem encontrada a cada ano. O programa abrange todas as dependências de software da Apigee.
OSS
A colaboração de segurança do Google acontece em muitos níveis. Às vezes, ocorre por meio de programas em que as organizações se inscrevem para receber notificações de pré-lançamento sobre vulnerabilidades de software para produtos como o Kubernetes e Envoy. A colaboração também acontece de maneira informal devido ao nosso engajamento com muitos projetos de código aberto, como o kernel do Linux, ambientes de execução de contêiner, tecnologia de virtualização e outros.
Embora vulnerabilidades menos graves sejam descobertas e corrigidas fora desses processos, as vulnerabilidades de segurança mais graves são informadas de modo privado por meio de um dos canais listados anteriormente. Os relatórios antecipados dão ao Google tempo antes que a vulnerabilidade se torne pública para pesquisar como ela afeta a Apigee, desenvolver patches ou mitigações e preparar orientações e comunicações para os clientes. Quando possível, o Google corrige todos os clusters (para a Apigee X) antes do lançamento público da vulnerabilidade. Para a Apigee híbrida, as versões de patch são disponibilizadas regularmente para lidar com as vulnerabilidades de segurança nas imagens de contêiner. Além disso, os clientes são incentivados a se manter atualizados com as versões de patch mais recentes.
Como as vulnerabilidades são classificadas
A Apigee faz grandes investimentos em aumento da proteção de segurança em toda a pilha, incluindo a imagem de base, as bibliotecas de terceiros e o software de aplicativo primário, além de definir bons padrões, configurações de aumento de segurança e componentes gerenciados. Combinados, esses esforços ajudam a reduzir o impacto e a probabilidade das vulnerabilidades.
A equipe de segurança da Apigee classifica vulnerabilidades de acordo com o Common Vulnerability Scoring System (CVSS).
Veja na tabela a seguir as categorias de gravidade de vulnerabilidade:
| Gravidade | Descrição |
| Crítico | Uma vulnerabilidade facilmente explorada em todos os clusters por um invasor remoto não autenticado que leva ao comprometimento total do sistema. |
| Alta | Uma vulnerabilidade fácil de explorar para muitos clusters que levam à perda de confidencialidade, integridade ou disponibilidade. |
| Média | Uma vulnerabilidade que pode ser explorada para alguns clusters em que a perda de confidencialidade, integridade ou disponibilidade é limitada por configurações comuns, dificuldade de exploração, acesso necessário ou interação do usuário. |
| Baixa | Todas as outras vulnerabilidades. A exploração é improvável ou as consequências da exploração são limitadas. |
Como as vulnerabilidades e os patches são comunicados
O objetivo do Google é reduzir as vulnerabilidades detectadas em um período apropriado para os riscos que elas representam. A Apigee está incluído no ATO provisório FedRAMP do Google Cloud, que exige que as vulnerabilidades conhecidas sejam corrigidas em períodos específicos de acordo com o nível de gravidade delas, conforme especificado no FedRAMP RA-5d. O ATO provisório do FedRAMP do Google Cloud não inclui componentes do plano de dados da Apigee híbrida (gerenciados pelo cliente), mas buscamos os mesmos prazos de correção para esses produtos.
Vulnerabilidades detectadas pela verificação proativa
O Google detecta vulnerabilidades de segurança verificando proativamente os binários e a infraestrutura subjacente que hospeda a plataforma Apigee. A Apigee lança atualizações de patch regulares para resolver essas vulnerabilidades em tempo hábil, dependendo da gravidade das CVEs subjacentes. A aplicação de patch em uma vulnerabilidade envolve o upgrade para uma nova versão híbrida da Apigee; um upgrade de versão secundária ou de versão de patch, dependendo da natureza da vulnerabilidade. Essas vulnerabilidades são resolvidas principalmente como parte de versões de patch mensais da Apigee híbrida e são incluídas nas atualizações de software regulares para nossa frota gerenciada no caso da Apigee X. Os patches de segurança são comunicados pelas notas da versão para a Apigee X e a Apigee híbrida.
A correção de algumas vulnerabilidades exige apenas um upgrade do plano de controle, realizado automaticamente pelo Google na Apigee, enquanto outras exigem a implantação de novos binários no plano de dados. No caso da Apigee X, o Google cuida do lançamento dos novos binários para toda a frota. Os clientes que executam a Apigee híbrida precisam aplicar a versão de patch aos clusters híbridos da Apigee para implantar os binários atualizados.
Para manter os clusters corrigidos e protegidos contra vulnerabilidades de todas as gravidades, recomendamos aplicar a versão de patch mais recente para qualquer versão secundária da Apigee híbrida. Para as pessoas que executam a Apigee híbrida no Anthos, o Google recomenda fazer upgrade dos componentes do Anthos pelo menos uma vez ao mês.
Vulnerabilidades informadas pelo cliente
Com a Apigee híbrida, os clientes recebem binários da Apigee para execução nos próprios data centers ou nas plataformas de nuvem que preferirem. Como parte dos padrões de segurança do cliente para lançar software na produção nos próprios data centers, ele pode executar uma série de testes de segurança. Isso pode incluir testes de penetração, verificação de contêiner, verificação de código estático etc. esses testes podem relatar possíveis vulnerabilidades no software da Apigee. Antes de ativar esses pacotes nos data centers, os clientes precisam determinar se esses itens denunciados podem ser explorados e, portanto, um risco de segurança.
Vulnerabilidade com uma exploração de prova de conceito
Se o cliente identificar uma vulnerabilidade que pode ser explorada e tiver uma prova de conceito (POC, na sigla em inglês) sobre como explorá-la, será necessário informar o problema usando o Programa de fidelidade por vulnerabilidades do Google, disponível em goo.gle/vulnz. Isso informa o problema à equipe de segurança do Google que validará a prova de conceito e determinará a gravidade e o possível impacto. O problema será encaminhado à Apigee. O cliente pode estar qualificado para uma recompensa pelo programa VRP.
Vulnerabilidade identificada por uma ferramenta automatizada
Se o cliente tiver gerado um relatório de possíveis vulnerabilidades no produto da Apigee com base em verificação estática ou outra ferramenta ou técnica, mas não tiver provas de conceito sobre como explorar os problemas, esses itens podem ser relatados no portal de suporte do Google Cloud. Ao informar o problema ao suporte, o cliente tem um número de tíquete para a acompanhamento e pode ver atualizações e respostas no relatório. A equipe de suporte encaminhará os problemas relatados internamente.
Identificadores CVE
Os clientes precisam incluir o máximo de informações possível sobre a vulnerabilidade e incluir especificamente o identificador CVE, o nome da biblioteca/pacote, o nome da imagem do contêiner etc. para cada item. Com as CVEs, sabemos que estamos analisando a mesma vulnerabilidade. Fornecer apenas uma descrição do problema ou outro número de rastreamento reservado não permite a correlação do problema com ferramentas de detecção ou processos de relatório. Sem uma CVE, o Google pode não responder ao item específico.
Resposta
Para os itens relatados ao suporte com pontuação de gravidade crítica ou alta, os clientes podem esperar uma resposta pelo sistema de tíquetes de suporte. Para saber os itens informados ao VRP, consulte as regras e a documentação fornecidas pelo programa.