Está a ver a documentação do Apigee e do Apigee Hybrid.
Ver documentação do
Apigee Edge.
Este documento descreve como a Google gere as vulnerabilidades de segurança e as correções para o Apigee hybrid. Salvo indicação em contrário, o Apigee inclui o plano de gestão e o plano de dados.
Responsabilidade partilhada pela aplicação de patches
A aplicação de patches é uma responsabilidade partilhada entre a Google e o cliente. O Apigee X e o Apigee Hybrid têm responsabilidades partilhadas diferentes, uma vez que o plano de dados do Apigee Hybrid é totalmente gerido pelo cliente. Para obter informações sobre as responsabilidades partilhadas do Apigee Hybrid, consulte o artigo Modelo de responsabilidade partilhada do Apigee Hybrid.
Como são descobertas as vulnerabilidades
A Google adota uma abordagem proativa à segurança dos sistemas de software, utilizando princípios de design seguros por predefinição e implementando várias práticas de reforço da segurança.
Por exemplo, as aplicações em contentores alimentam as várias funcionalidades da plataforma de gestão de APIs da Apigee. As aplicações contentorizadas são implementadas no Kubernetes. As imagens de contentores são criadas com base em imagens base mínimas (por exemplo, imagens base sem distribuição) para máxima segurança e desempenho melhorado.
No entanto, mesmo os sistemas de software mais bem concebidos podem ter vulnerabilidades. Para encontrar essas vulnerabilidades e aplicar patches antes que possam ser exploradas, a Google fez investimentos significativos em várias frentes.
Análises de segurança
A Google identifica e corrige proativamente vulnerabilidades em diferentes tipos de imagens de contentores:
- Contentores originais: imagens de contentores criadas e distribuídas pela Google como parte da plataforma Apigee. Estas são aplicações proprietárias da Google que alimentam a plataforma de gestão de APIs Apigee, incluindo funcionalidades essenciais, como o encaminhamento de tráfego, a gestão de quotas e a gestão de chaves.
- Recipientes de terceiros: imagens de recipientes criadas pela comunidade de código aberto, mas distribuídas pela Google como parte da plataforma Apigee. Estes são principalmente componentes de código aberto usados pela plataforma para tarefas operacionais comuns, como registo, monitorização e gestão de certificados.
A Google analisa os contentores através da análise de contentores do registo de contentores para descobrir vulnerabilidades e patches em falta em contentores originais e de terceiros. Se estiverem disponíveis correções, a Google inicia o processo de aplicação de patches e lançamento. Estas análises são executadas regularmente (quando são publicadas novas imagens), bem como a pedido (antes de um lançamento), para maximizar as probabilidades de deteção de novas vulnerabilidades e planeamento de remediação ou mitigação antecipada.
Investigação de segurança
Além da análise automática, a Google descobre e corrige vulnerabilidades desconhecidas para os analisadores das seguintes formas:
- A Google realiza as suas próprias auditorias de segurança e conformidade, testes de penetração de aplicações e redes, testes de segmentação e deteção de vulnerabilidades de segurança em todos os componentes do Apigee.
As equipas especializadas da Google e os fornecedores de segurança de terceiros fidedignos realizam a sua própria investigação de ataques. - A Google colabora com outros parceiros da indústria e de software de código aberto que partilham
vulnerabilidades, investigação de segurança e patches antes do lançamento público da vulnerabilidade.
O objetivo desta colaboração é corrigir grandes partes da infraestrutura da Internet antes de a vulnerabilidade ser anunciada publicamente. Em alguns casos, a Google contribui com as vulnerabilidades encontradas para esta comunidade. Por exemplo, o Project Zero da Google descobriu e publicitou as vulnerabilidades Spectre e Meltdown. A equipa de segurança do Google Cloud também encontra e corrige regularmente vulnerabilidades na máquina virtual baseada em kernel (KVM).
Programas de Recompensa para Deteção de Vulnerabilidades
A Google interage ativamente com a comunidade de investigação de segurança através de vários programas de recompensas por vulnerabilidades. Um programa de recompensas de vulnerabilidades do Google Cloud dedicado oferece recompensas significativas, incluindo 133 337 $pela melhor vulnerabilidade na nuvem encontrada todos os anos. O programa abrange todas as dependências de software do Apigee.
OSS
A colaboração em segurança da Google ocorre a vários níveis. Por vezes, ocorre formalmente através 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 o Envoy. A colaboração também ocorre de forma informal devido à nossa interação com muitos projetos de código aberto, como o kernel do Linux, os tempos de execução de contentores, a tecnologia de virtualização e outros.
Embora sejam descobertas e corrigidas vulnerabilidades menos graves fora destes processos, a maioria das vulnerabilidades de segurança críticas é comunicada de forma privada através de um dos canais indicados anteriormente. Os relatórios antecipados dão tempo à Google antes de a vulnerabilidade se tornar pública para pesquisar como afeta o Apigee, desenvolver correções ou mitigações e preparar aconselhamento e comunicações para os clientes. Sempre que possível, a Google aplica patches a todos os clusters (para o Apigee X) antes do lançamento público da vulnerabilidade. Para o Apigee hybrid, as versões de patches são disponibilizadas regularmente para resolver vulnerabilidades de segurança nas imagens de contentores, e os clientes são incentivados a manter-se atualizados com as versões de patches mais recentes.
Como são classificadas as vulnerabilidades
A Apigee faz grandes investimentos no reforço da segurança em toda a pilha, incluindo a imagem base, as bibliotecas de terceiros e o software de aplicação de primeira parte, além de definir boas predefinições, configurações reforçadas em termos de segurança e componentes geridos. Em conjunto, estes esforços ajudam a reduzir o impacto e a probabilidade de vulnerabilidades.
A equipa de segurança do Apigee classifica as vulnerabilidades de acordo com o Common Vulnerability Scoring System (CVSS).
A tabela seguinte descreve as categorias de gravidade das vulnerabilidades:
| Gravidade | Descrição |
| Crítico | Uma vulnerabilidade facilmente explorável em todos os clusters por um atacante remoto não autenticado que leva ao comprometimento total do sistema. |
| Alto | Uma vulnerabilidade facilmente explorável para muitos clusters que leva à perda de confidencialidade, integridade ou disponibilidade. |
| Médio | Uma vulnerabilidade explorável 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 utilizador. |
| Baixo | Todas as outras vulnerabilidades. A exploração é improvável ou as consequências da exploração são limitadas. |
Como são comunicadas as vulnerabilidades e as correções
O objetivo da Google é mitigar as vulnerabilidades detetadas num período adequado aos riscos que representam. O Apigee está incluído no ATO provisório do FedRAMP do Google Cloud que exige que as vulnerabilidades conhecidas sejam corrigidas em prazos específicos de acordo com o respetivo nível de gravidade, conforme especificado no FedRAMP RA-5d. A ATO provisória do FedRAMP do Google Cloud não inclui componentes do plano de dados híbrido do Apigee (geridos pelo cliente), mas pretendemos ter os mesmos prazos de correção nesses produtos.
Vulnerabilidades detetadas pela análise proativa
A Google deteta vulnerabilidades de segurança através da análise proativa dos ficheiros binários e da infraestrutura subjacente que aloja a plataforma Apigee. A Apigee lança atualizações de patches regulares para resolver estas vulnerabilidades atempadamente, consoante a gravidade das CVE subjacentes. A aplicação de patches a uma vulnerabilidade envolve a atualização para uma nova versão híbrida do Apigee, seja uma atualização de versão secundária ou uma atualização de versão de patch, consoante a natureza da vulnerabilidade. Estas vulnerabilidades são, na sua maioria, resolvidas como parte das versões de patches mensais para o Apigee hybrid e incluídas nas atualizações de software regulares da nossa frota gerida no caso do Apigee X. Os patches de segurança são comunicados através das notas de lançamento do Apigee X e do Apigee híbrido.
A correção de algumas vulnerabilidades requer apenas uma atualização do plano de controlo, realizada automaticamente pela Google no Apigee, enquanto outras requerem a implementação de novos ficheiros binários no plano de dados. No caso do Apigee X, a Google encarrega-se da implementação dos novos ficheiros binários em toda a frota. Os clientes que executam o Apigee Apigee hybrid têm de aplicar a versão de patch aos respetivos clusters do Apigee hybrid para implementar os binários atualizados.
Para manter os clusters corrigidos e protegidos contra vulnerabilidades de todas as gravidades, recomendamos que aplique a versão de patch mais recente para qualquer versão secundária específica do Apigee hybrid. Para quem executa o Apigee hybrid no Anthos, a Google recomenda que atualize os componentes do Anthos, pelo menos, mensalmente.
Vulnerabilidades comunicadas pelos clientes
Com o Apigee hybrid, os clientes recebem ficheiros binários do Apigee para executar nos respetivos centros de dados ou nas respetivas plataformas de nuvem preferenciais. Como parte das normas de segurança de um cliente para lançar software em produção nos respetivos centros de dados, este pode executar uma série de testes de segurança. Estes testes podem incluir testes de penetração, análise de contentores, análise de código estático, etc. Estes testes podem comunicar possíveis vulnerabilidades no software Apigee. Antes de ativar estes pacotes nos respetivos centros de dados, os clientes têm de determinar se estes itens comunicados são exploráveis e, por conseguinte, um risco de segurança.
Vulnerabilidade com uma validação de conceito de exploração
Se o cliente identificar uma vulnerabilidade explorável e tiver uma prova de conceito (POC) sobre como explorar a vulnerabilidade, deve comunicar este problema através do Google Vulnerabilities Reward Program, que se encontra em goo.gle/vulnz. Isto comunica o problema à equipa de segurança da Google, que valida a prova de conceito e determina a respetiva gravidade e potencial impacto. O problema é, então, encaminhado para o Apigee. O cliente pode ser elegível para uma recompensa através do programa VRP.
Vulnerabilidade identificada por uma ferramenta automática
Se o cliente tiver gerado um relatório de possíveis vulnerabilidades no produto Apigee com base na análise estática ou noutra ferramenta ou técnica, mas não tiver provas de conceito sobre como explorar os problemas, estes itens podem ser comunicados ao apoio técnico através do portal de apoio técnico do Google Cloud. Ao comunicar o problema ao apoio técnico, o cliente tem um número de pedido para acompanhamento e pode ver atualizações e respostas ao relatório. Em seguida, a equipa de apoio técnico encaminha os problemas comunicados internamente, conforme adequado.
Identificadores CVE
Os clientes devem incluir o máximo de informações possível sobre a vulnerabilidade e, especificamente, incluir o identificador CVE, o nome da biblioteca/pacote, o nome da imagem do contentor, etc., para cada item. As CVEs permitem-nos saber que estamos a analisar a mesma vulnerabilidade. Se fornecer apenas uma descrição do problema ou outro número de seguimento proprietário, não é possível correlacionar o problema nas ferramentas de deteção nem nos processos de denúncia. Sem um CVE, a Google pode não conseguir responder ao item específico.
Resposta
Para itens comunicados ao apoio técnico com uma classificação de gravidade crítica ou elevada, os clientes podem esperar uma resposta através do sistema de pedidos de apoio técnico. Para itens comunicados ao VRP, consulte as regras e a documentação fornecida pelo programa.