Lista de verificação de reforço da segurança do GCP para equipes pequenas e médias

Caminhos de ameaça comuns no GCP

A maioria dos incidentes na nuvem começa com uma pequena lacuna de responsabilidade ou de configuração. Procure esses caminhos antes que um invasor o faça.

• Um usuário, uma conta de serviço ou uma identidade de carga de trabalho com permissões excessivas pode transformar uma única credencial roubada em acesso amplo a vários projetos.
• Um endpoint de gerenciamento exposto, uma porta de depuração ou uma regra de firewall permissiva podem contornar todos os controles projetados para o tráfego normal da aplicação.
• Um bucket de armazenamento público ou um URL assinado amplo demais pode expor dados de clientes sem nenhum comprometimento visível da aplicação.
• Cargas de trabalho obsoletas criam um risco duradouro quando imagens antigas, namespaces esquecidos, contas de serviço sem uso e recursos sem responsável continuam podendo ser implantados.
• Evidências de auditoria ausentes ou retidas por pouco tempo dificultam identificar quem alterou uma política, quando o acesso começou e quais dados foram atingidos.
• Um backup não testado é apenas uma esperança. Falhas de restauração, retenção incompleta e chaves de criptografia inacessíveis podem transformar um evento de segurança em perda permanente.

Identidade e acesso

Trate a identidade como o principal plano de controle. Cada pessoa, processo de automação e carga de trabalho deve ter uma identidade própria com uma finalidade delimitada.

Torne explícitos os limites dos recursos

Use a organização e as pastas para aplicar barreiras de proteção e separe desenvolvimento, homologação e produção em projetos distintos ou em limites de confiança mais rígidos. Aplique políticas da organização no nível mais alto possível, restrinja o uso de serviços e evite compartilhar projetos de produção entre produtos não relacionados.

Conceda o papel mínimo no escopo mais restrito

Prefira papéis predefinidos ou personalizados em vez de papéis primitivos amplos, conceda-os a grupos e a identidades de carga de trabalho e use condições do IAM quando um nome de recurso ou uma tag puder restringir o acesso. Revise as permissões não usadas e remova o acesso permanente à produção que só deveria existir por meio de um procedimento de acesso de emergência (break-glass).

Remova credenciais de longa duração

Use a Workload Identity Federation for GKE para que os pods recebam credenciais de curta duração sem chaves de conta de serviço exportadas. Bloqueie a criação e o upload de chaves com a política da organização sempre que possível, faça o inventário das chaves restantes e crie alertas para alterações de alto risco no IAM nos Cloud Audit Logs.

Rede e borda

Parta do princípio de que algum defeito da aplicação acabará ficando acessível pela rede. Limite o que esse defeito pode acessar.

Comece negando tudo e adicione caminhos nomeados

Use regras de firewall da VPC com privilégio mínimo e NetworkPolicies do Kubernetes para o tráfego de pods. Separe os ambientes em redes distintas, documente cada caminho de entrada e remova regras amplas de depuração que permitem portas de gerenciamento ou todos os protocolos a partir de grandes intervalos de endereços.

Mantenha privados os nós e os planos de controle

Desative endereços IP externos nos nós do GKE. Prefira o endpoint privado do plano de controle baseado em DNS e, quando um endpoint IP for inevitável, restrinja-o com redes autorizadas. Dê às cargas de trabalho um caminho de saída deliberado em vez de acesso amplo à internet.

Publique apenas os serviços públicos intencionais

Exponha as aplicações por meio de um gateway ou balanceador de carga revisado, e não por endereços de pods ou nós expostos por acaso. Faça a terminação TLS com certificados gerenciados, restrinja hosts e caminhos de entrada, aplique limites de solicitações e de taxa e mantenha as interfaces de administração protegidas por acesso baseado em identidade.

Dados e segredos

Proteja os dados em repouso, em trânsito e em uso e, depois, comprove que você consegue recuperá-los. A descoberta de dados faz parte do controle.

Evite o acesso público acidental

Aplique a prevenção do acesso público e o acesso uniforme no nível do bucket no Cloud Storage. Classifique os buckets por sensibilidade, restrinja o acesso a objetos e chaves, ative a geração de registros para dados de alto valor e use chaves de criptografia gerenciadas pelo cliente quando seu modelo de risco ou de conformidade exigir.

Mantenha os segredos fora das imagens e do código-fonte

Armazene as credenciais no Secret Manager e conceda acesso a uma identidade de carga de trabalho e a uma versão do segredo específicas. Faça a rotação dos segredos de forma deliberada, evite copiá-los no Git ou em imagens de contêiner e não trate os Kubernetes Secrets comuns como um limite de proteção completo.

Teste a recuperação, não apenas a criação de backup

Defina metas de ponto de recuperação (RPO) e de tempo de recuperação (RTO), mantenha cópias fora do domínio de falha da produção e proteja o acesso aos backups e às chaves de criptografia contra a identidade da carga de trabalho. Restaure periodicamente em um ambiente isolado, verifique os dados e registre o tempo decorrido e todas as etapas manuais.

Reforço da segurança do GKE

O GKE protege o plano de controle gerenciado, mas a configuração do cluster, os namespaces, as políticas de admissão e as cargas de trabalho continuam sob sua responsabilidade.

Faça dos namespaces o contrato de isolamento

Separe equipes e ambientes em namespaces ou clusters, vincule neles papéis restritos do Kubernetes RBAC e aplique cotas de recursos e NetworkPolicies. Evite acesso de gravação em todo o cluster para a entrega de aplicações e dê a cada carga de trabalho a própria conta de serviço quando ela precisar de uma identidade distinta.

Admita apenas imagens e configurações confiáveis

Aplique o padrão restrito do Pod Security ou regras equivalentes do Policy Controller. Implante imagens por digest imutável, verifique se há vulnerabilidades nelas, use a Binary Authorization quando a procedência importar e rejeite acessos inesperados ao host, escalonamento de privilégios e vinculações de cluster-admin.

Remova privilégios desnecessários dos contêineres

Execute como usuário não root, remova as capacidades do Linux, use um sistema de arquivos raiz somente leitura sempre que possível e aplique o perfil seccomp RuntimeDefault. Não monte o token da conta de serviço sem necessidade, evite contêineres privilegiados e namespaces do host, mantenha a conta de serviço dos nós com o mínimo de permissões e use Shielded Nodes com Container-Optimized OS.

Detecção e recuperação

Controles falham. Baseie-se em evidências e em ações ensaiadas, não na confiança de que ninguém cometeu um erro.

Colete as evidências de que você vai precisar

Mantenha os Cloud Audit Logs e os registros de sistema e de cargas de trabalho do GKE em um destino central, com retenção adequada às suas necessidades de investigação. Ative seletivamente os registros de auditoria de acesso a dados para dados sensíveis, restrinja o acesso aos registros e registre as alterações administrativas no IAM, no firewall, no armazenamento e na configuração do cluster.

Crie alertas para alterações relevantes para a segurança

Crie alertas para exposição pública do armazenamento, alterações amplas de firewall ou de IAM, chaves de conta de serviço inesperadas, negações de admissão, exposição do plano de controle, falhas de autenticação repetidas, geração de registros desativada, backups com falha e certificados prestes a expirar. Encaminhe cada alerta para um responsável, com as etapas para confirmá-lo ou descartá-lo.

Ensaie a resposta

Escreva runbooks curtos para credenciais vazadas, dados expostos publicamente, cargas de trabalho comprometidas e perda de regiões ou projetos. Inclua quem pode autorizar a contenção, como revogar o acesso, como preservar evidências e como restaurar o serviço. Teste os runbooks com as pessoas que vão usá-los.

Uma lista de verificação priorizada de 30, 60 e 90 dias

Se você está partindo de uma linha de base incompleta, organize o trabalho para reduzir primeiro a exposição e tornar repetíveis as revisões posteriores.

Dias 1 a 30: feche os caminhos óbvios

Faça o inventário dos projetos e responsáveis, remova credenciais sem uso e de longa duração, confirme os registros de auditoria, bloqueie buckets públicos, revise as regras de firewall e as concessões do IAM mais amplas, identifique lacunas nos backups de produção e corrija qualquer endpoint público sem responsável. Atribua um responsável e um prazo a cada constatação.

Dias 31 a 60: torne a linha de base repetível

Leve a configuração de rede, identidade e cargas de trabalho para infraestrutura como código revisada e entrega GitOps. Adote Workload Identity, nós privados, Pod Security restrito, verificação de imagens confiáveis, registros centralizados e alertas para as alterações mais importantes.

Dias 61 a 90: comprove e mantenha

Execute testes de restauração e um exercício de simulação de incidentes (tabletop), revise o acesso privilegiado e a expiração de exceções, faça uma nova varredura de imagens e dependências, confirme que os responsáveis recebem os alertas e meça as lacunas restantes. Coloque as verificações em um ciclo de revisão recorrente antes que as evidências fiquem desatualizadas.

Use esta lista de verificação como ponto de partida. A Snow Tree pode aplicar a linha de base por meio da operação da plataforma gerenciada ou de um projeto de consultoria focado.

Plataforma gerenciada · Consultoria

Referências oficiais

Use as orientações atuais do Google como fonte técnica de referência quando os padrões da plataforma ou os recursos dos produtos mudarem.

• Google Cloud: práticas recomendadas para reforçar a segurança do cluster do GKE
• Google Cloud: práticas recomendadas de segurança do GKE