Pular para conteúdo

Segurança da Plataforma e Ciclo de Vida

Segurança não depende de um componente único. Ela é aplicada em camadas, para que a falha de uma não exponha a aplicação inteira.

As camadas de segurança da plataforma, da aplicação até o datacenter

Cada camada cobre o que a de cima deixa passar — e o nível de proteção pode ser adaptado por ambiente, sem exigir que toda aplicação use exatamente a mesma configuração.

Sistema operacional dos workers

A solução não depende de uma única distribuição Linux. Os worker nodes usam o sistema operacional adequado aos requisitos de compatibilidade e segurança do projeto: distribuições mínimas, distribuições Cloud Native, sistemas imutáveis, distribuições corporativas ou perfis com hardening específico.

O critério de escolha considera compatibilidade da aplicação, superfície de ataque, gestão de ciclo de vida e requisitos de conformidade. O objetivo é manter o SO do worker como uma camada de plataforma controlada, sem serviços e componentes desnecessários.

O hardening aplicado pode incluir:

  • instalação mínima, com remoção ou desativação de serviços desnecessários;
  • atualizações controladas, em janela;
  • políticas restritivas de permissão de sistema de arquivos;
  • acesso SSH restrito ou desabilitado, conforme o perfil;
  • hardening de kernel;
  • configurações alinhadas a CIS Benchmarks quando requerido ou contratado.

Camada Kubernetes

Na plataforma são aplicados:

  • RBAC de menor privilégio — service accounts com o mínimo necessário;
  • Pod Security Standards — restrição a contêineres privilegiados;
  • Isolamento por namespace — separação entre times, ambientes e aplicações;
  • Execução como não-root, com capabilities reduzidas do Linux;
  • Sistema de arquivos raiz somente leitura, quando a aplicação suporta;
  • Políticas de recursos — requests, limits e cotas por namespace;
  • Auditoria e monitoramento do plano de controle.

Rede com Cilium

A camada de rede do cluster usa Cilium, o que permite aplicar conectividade e segurança diretamente às cargas, com políticas baseadas em identidade em vez de endereços IP:

Recurso O que entrega
Network Policies L3/L4 Controle explícito de quem fala com quem
Políticas por identidade Regras que sobrevivem à troca de IP dos pods
Segmentação por namespace Isolamento entre ambientes e times
Observabilidade de rede Visibilidade de fluxos permitidos e bloqueados
Criptografia entre nós Tráfego node-to-node cifrado, quando previsto na arquitetura

Na prática, o frontend fala com a API, a API fala com o banco, e o frontend não fala com o banco. Isso reduz movimentação lateral caso uma aplicação seja comprometida.

As políticas são definidas conforme os requisitos de isolamento de cada cluster — não existe um conjunto único imposto a todos os ambientes.

Ciclo de vida gerenciado

Os clusters rodam versões estáveis e suportadas do Kubernetes. A InteSys gerencia o ciclo de vida da plataforma:

  • planejamento de upgrade e acompanhamento de versões suportadas;
  • atualização progressiva dos worker nodes, sem parada do ambiente;
  • compatibilidade entre componentes e atualização da CNI;
  • validação das cargas após cada atualização;
  • substituição controlada de nós;
  • monitoramento de saúde do cluster.

O objetivo é manter a plataforma atualizada sem transferir a complexidade operacional dessa manutenção para o time do cliente.

Divisão de responsabilidades

Camada Responsável
Datacenter, rede e infraestrutura InteSys (ou o provedor escolhido para aquela região)
Sistema operacional dos workers e hardening InteSys
Control plane, upgrades e CNI InteSys
Políticas de rede, RBAC e namespaces InteSys, conforme requisitos do cliente
Aplicações, imagens e dependências Cliente
Esquema, dados e regras de negócio Cliente

A InteSys não substitui o time de desenvolvimento

O modelo mais comum é a InteSys assumir plataforma, rede, segurança de infraestrutura e ciclo de vida, enquanto o time do cliente segue dono das aplicações que rodam sobre ela.

Páginas Relacionadas