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

Caminhos de ameaça comuns no GCP

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

• Um utilizador, uma conta de serviço ou uma identidade de carga de trabalho com permissões excessivas pode transformar uma única credencial roubada num acesso alargado a vários projetos.
• Um endpoint de gestão exposto, uma porta de depuração ou uma regra de firewall permissiva podem contornar todos os controlos concebidos para o tráfego normal das aplicações.
• Um bucket de armazenamento público ou um URL assinado demasiado abrangente pode divulgar dados de clientes sem qualquer comprometimento visível da aplicação.
• As cargas de trabalho obsoletas criam um risco duradouro quando imagens antigas, namespaces esquecidos, contas de serviço não utilizadas e recursos sem responsável continuam a poder ser implementados.
• A falta de provas de auditoria, ou a sua retenção por pouco tempo, dificulta a identificação de quem alterou uma política, de quando começou o acesso e de que dados foram alcançados.
• Uma cópia de segurança não testada é apenas uma esperança. Falhas de restauro, retenção incompleta e chaves de encriptação inacessíveis podem transformar um evento de segurança numa perda permanente.

Identidade e acesso

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

Torne explícitos os limites dos recursos

Utilize a organização e as pastas para aplicar salvaguardas e separe o desenvolvimento, a pré-produção e a produção em projetos distintos ou em limites de confiança mais rigorosos. Aplique as políticas da organização ao nível mais elevado possível, restrinja a utilização de serviços e evite partilhar projetos de produção entre produtos não relacionados.

Conceda a função mínima no âmbito mais restrito

Prefira funções predefinidas ou personalizadas em vez de funções primitivas abrangentes, conceda-as a grupos e a identidades de cargas de trabalho e utilize condições do IAM quando um nome ou uma etiqueta de recurso permitir restringir o acesso. Reveja as permissões não utilizadas e remova o acesso permanente à produção que só deveria existir através de um procedimento de acesso de emergência (break-glass).

Remova as credenciais de longa duração

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

Rede e periferia

Parta do princípio de que algum defeito da aplicação acabará por ficar acessível a partir da rede. Limite aquilo a que esse defeito pode aceder.

Comece por negar tudo e adicione caminhos nomeados

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

Mantenha privados os nós e os planos de controlo

Desative os endereços IP externos nos nós do GKE. Prefira o endpoint privado do plano de controlo 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 um acesso amplo à Internet.

Publique apenas os serviços públicos intencionais

Exponha as aplicações através de um gateway ou balanceador de carga revisto, e não de endereços de pods ou nós expostos por acaso. Faça a terminação TLS com certificados geridos, restrinja os anfitriões e os caminhos de entrada, aplique limites de pedidos e de taxa e mantenha as interfaces de administração protegidas por acesso baseado na identidade.

Dados e segredos

Proteja os dados em repouso, em trânsito e em utilização e, depois, prove que os consegue recuperar. A descoberta de dados faz parte do controlo.

Evite o acesso público acidental

Aplique a prevenção de acesso público e o acesso uniforme ao nível do bucket no Cloud Storage. Classifique os buckets por sensibilidade, restrinja o acesso a objetos e chaves, ative o registo para dados de elevado valor e utilize chaves de encriptação geridas pelo cliente quando o seu modelo de risco ou de conformidade o 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 para o Git ou para imagens de contentores 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 cópias de segurança

Defina objetivos 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 às cópias de segurança e às chaves de encriptação contra a identidade da carga de trabalho. Restaure periodicamente num ambiente isolado, verifique os dados e registe o tempo decorrido e quaisquer passos manuais.

Reforço da segurança do GKE

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

Faça dos namespaces o contrato de isolamento

Separe equipas e ambientes em namespaces ou clusters, associe aí funções restritas do Kubernetes RBAC e aplique quotas de recursos e NetworkPolicies. Evite o acesso de escrita a todo o cluster para a entrega de aplicações e atribua a cada carga de trabalho a sua própria conta de serviço quando esta precisar de uma identidade distinta.

Admita apenas imagens e configurações fidedignas

Aplique o padrão restrito do Pod Security ou regras equivalentes do Policy Controller. Implemente imagens por digest imutável, analise-as para detetar vulnerabilidades, utilize a Binary Authorization quando a proveniência for importante e rejeite acessos inesperados ao anfitrião, escalamento de privilégios e associações de cluster-admin.

Remova privilégios desnecessários dos contentores

Execute como utilizador não root, remova as capacidades do Linux, utilize um sistema de ficheiros raiz só de leitura sempre que possível e aplique o perfil seccomp RuntimeDefault. Não monte o token da conta de serviço sem necessidade, evite contentores privilegiados e namespaces do anfitrião, mantenha a conta de serviço dos nós com as permissões mínimas e utilize Shielded Nodes com Container-Optimized OS.

Deteção e recuperação

Os controlos falham. Confie em provas e em ações ensaiadas, e não na convicção de que ninguém cometeu um erro.

Recolha as provas de que vai precisar

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

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

Configure alertas para exposição pública do armazenamento, alterações abrangentes à firewall ou ao IAM, chaves de contas de serviço inesperadas, recusas de admissão, exposição do plano de controlo, falhas de autenticação repetidas, registo desativado, cópias de segurança falhadas e certificados prestes a expirar. Encaminhe cada alerta para um responsável, com os passos para o confirmar ou rejeitar.

Ensaie a resposta

Escreva runbooks curtos para credenciais divulgadas, 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 provas e como repor o serviço. Teste os runbooks com as pessoas que os vão utilizar.

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

Se estiver a partir de uma linha de base incompleta, ordene o trabalho de forma a reduzir primeiro a exposição e a tornar repetíveis as revisões posteriores.

Dias 1 a 30: feche os caminhos óbvios

Faça o inventário dos projetos e dos responsáveis, remova credenciais não utilizadas e de longa duração, confirme os registos de auditoria, bloqueie buckets públicos, reveja as regras de firewall e as concessões do IAM mais abrangentes, identifique lacunas nas cópias de segurança 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

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

Dias 61 a 90: comprove e mantenha

Execute testes de restauro e um exercício de simulação de incidentes (tabletop), reveja o acesso privilegiado e a expiração de exceções, volte a analisar imagens e dependências, confirme que os responsáveis recebem os alertas e meça as lacunas que permanecem. Inclua as verificações num ciclo de revisão recorrente antes que as provas fiquem desatualizadas.

Utilize esta lista de verificação como ponto de partida. A Snow Tree pode aplicar a linha de base através da operação da plataforma gerida ou de um projeto de consultoria focado.

Plataforma gerida · Consultoria

Referências oficiais

Utilize as orientações atuais da Google como fonte técnica de referência quando as predefinições da plataforma ou as funcionalidades dos produtos mudarem.

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