Implementar a segurança incorporada ao design

Last reviewed 2025-02-05 UTC

Esse princípio no pilar de segurança do Google Cloud Well-Architected Framework fornece recomendações para incorporar recursos, controles e práticas de segurança robustos ao design de aplicativos, serviços e plataformas de nuvem. Da ideação às operações, a segurança é mais eficaz quando está incorporada como uma parte integral de cada etapa do processo de design.

Visão geral do princípio

Conforme explicado em Visão geral do compromisso do Google com a segurança por design, segurança por padrão e segurança por design são usados de forma intercambiável, mas representam abordagens distintas para a criação de sistemas seguros. As duas abordagens visam minimizar vulnerabilidades e aumentar a segurança, mas diferem em escopo e implementação:

  • Segurança por padrão: foca em garantir que as configurações padrão de um sistema estejam definidas em um modo seguro, minimizando a necessidade de usuários ou administradores tomarem medidas para proteger o sistema. Essa abordagem visa oferecer um nível básico de segurança para todos os usuários.
  • Segurança incorporada ao design: enfatiza a incorporação proativa de considerações de segurança em todo o ciclo de vida de desenvolvimento de um sistema. Essa abordagem antecipa possíveis ameaças e vulnerabilidades e faz escolhas de design que reduzem os riscos. Essa abordagem envolve o uso de práticas de programação seguras, a realização de análises de segurança e a incorporação da segurança em todo o processo de design. A abordagem de segurança desde a concepção é uma filosofia abrangente que orienta o processo de desenvolvimento e ajuda a garantir que a segurança não seja uma reflexão tardia, mas sim uma parte integrante do design de um sistema.

Recomendações

Para implementar o princípio de segurança por design nas suas cargas de trabalho na nuvem, considere as recomendações nas seções a seguir:

Escolha componentes do sistema que ajudam a proteger suas cargas de trabalho

Essa recomendação é relevante para todas as áreas de foco.

Uma decisão fundamental para a segurança eficaz é a seleção de componentes robustos do sistema, incluindo hardware e software, que constituem sua plataforma, solução ou serviço. Para reduzir a superfície de ataque de segurança e limitar possíveis danos, considere cuidadosamente os padrões de implantação desses componentes e as configurações deles.

No código do aplicativo, recomendamos que você use bibliotecas, abstrações e frameworks de aplicativos simples, seguros e confiáveis para eliminar classes de vulnerabilidades. Para verificar vulnerabilidades em bibliotecas de software, use ferramentas de terceiros. Você também pode usar o Assured Open Source Software, que ajuda a reduzir os riscos para sua cadeia de suprimentos de software usando pacotes de software de código aberto (OSS) que o Google usa e protege.

Sua infraestrutura precisa usar opções de rede, armazenamento e computação que ofereçam suporte a uma operação segura e estejam alinhadas aos seus requisitos de segurança e níveis de aceitação de risco. A segurança da infraestrutura é importante para cargas de trabalho internas e voltadas à Internet.

Para informações sobre outras soluções do Google que oferecem suporte a essa recomendação, consulte Implementar a segurança shift-left.

Criar uma abordagem de segurança em camadas

Esta recomendação é relevante para as seguintes áreas de foco:

  • Segurança de IA e ML
  • Segurança da infraestrutura
  • Gerenciamento de identidade e acesso
  • Segurança de dados

Recomendamos que você implemente a segurança em cada camada do aplicativo e da pilha de infraestrutura aplicando uma abordagem de defesa em profundidade.

Use os recursos de segurança em cada componente da sua plataforma. Para limitar o acesso e identificar os limites do possível impacto (ou seja, o raio de explosão) em caso de incidente de segurança, faça o seguinte:

  • Simplifique o design do sistema para acomodar a flexibilidade sempre que possível.
  • Documente os requisitos de segurança de cada componente.
  • Incorpore um mecanismo seguro para atender aos requisitos de resiliência e recuperação.

Ao projetar as camadas de segurança, faça uma avaliação de risco para determinar os recursos de segurança necessários para atender aos requisitos de segurança internos e regulatórios externos. Recomendamos que você use um framework de avaliação de risco padrão do setor que se aplique a ambientes de nuvem e seja relevante para seus requisitos regulamentares. Por exemplo, a Cloud Security Alliance (CSA) fornece a matriz de controles do Cloud (CCM, na sigla em inglês). Ela fornece um catálogo de riscos e controles de segurança correspondentes para reduzir esses riscos.

Ao realizar a avaliação de risco, lembre-se de que você tem um acordo de responsabilidade compartilhada com seu provedor de nuvem. Portanto, os riscos em um ambiente de nuvem são diferentes dos riscos em um ambiente local. Por exemplo, em um ambiente local, é preciso reduzir as vulnerabilidades para a pilha de hardware. Por outro lado, em um ambiente de nuvem, o provedor de nuvem assume esses riscos. Além disso, lembre-se de que os limites das responsabilidades compartilhadas variam entre os serviços de IaaS, PaaS e SaaS para cada provedor de nuvem.

Depois de identificar os riscos potenciais, crie um plano de mitigação que use controles técnicos, administrativos e operacionais, além de proteções contratuais e atestados de terceiros. Além disso, um método de estimativa de ameaças, como o método de estimativa de ameaças do aplicativo OWASP, ajuda a identificar possíveis lacunas e sugere ações para resolvê-las.

Usar infraestrutura e serviços reforçados e atestados

Essa recomendação é relevante para todas as áreas de foco.

Um programa de segurança avançado mitiga novas vulnerabilidades, conforme descrito nos boletins de segurança. O programa de segurança também precisa oferecer correção para resolver vulnerabilidades em implantações atuais e proteger as imagens de VM e contêiner. É possível usar guias de proteção específicos para o SO e o aplicativo das suas imagens, além de comparativos de mercado como o fornecido pelo Center of Internet Security (CIS).

Se você usa imagens personalizadas para suas VMs do Compute Engine, precisa corrigir as imagens por conta própria. Se preferir, use as imagens de SO selecionadas fornecidas pelo Google, que são corrigidas regularmente. Para executar contêineres em VMs do Compute Engine, use imagens do Container-Optimized OS selecionadas pelo Google. O Google corrige e atualiza essas imagens regularmente.

Se você usa o GKE, recomendamos ativar os upgrades automáticos de nós para que o Google atualize os nós do cluster com os patches mais recentes. O Google gerencia planos de controle do GKE, que são atualizados e corrigidos automaticamente. Para reduzir ainda mais a superfície de ataque dos contêineres, use imagens distroless. As imagens distroless são ideais para aplicativos, microsserviços e situações sensíveis à segurança em que minimizar o tamanho da imagem e a superfície de ataque é fundamental.

Para cargas de trabalho sensíveis, use a VM protegida, que impede o carregamento de código malicioso durante o ciclo de inicialização da VM. As instâncias de VM protegida fornecem segurança de inicialização, monitoram a integridade e usam o Módulo de plataforma confiável virtual (vTPM).

Para ajudar a proteger o acesso SSH, o Login do SO permite que os funcionários se conectem às VMs usando as permissões do gerenciamento de identidade e acesso (IAM) como a fonte confiável, em vez de confiar em chaves SSH. Portanto, não é necessário gerenciar chaves SSH em toda a organização. O login do SO vincula o acesso de um administrador ao ciclo de vida do funcionário. Assim, quando os funcionários mudam de função ou saem da organização, o acesso deles é revogado com a conta. O login do SO também é compatível com a autenticação de dois fatores do Google, que adiciona uma camada extra de segurança contra ataques de invasão de conta.

No GKE, as instâncias de aplicativos são executadas em contêineres do Docker. Para ativar um perfil de risco definido e impedir que os funcionários façam alterações nos contêineres, verifique se eles são sem estado e imutáveis. O princípio de imutabilidade significa que os funcionários não modificam o contêiner nem o acessam de forma interativa. Se o contêiner precisar ser mudado, crie uma nova imagem e implante-a novamente. Ative o acesso SSH aos contêineres subjacentes somente em cenários de depuração específicos.

Para ajudar a proteger globalmente as configurações em todo o ambiente, use políticas da organização para definir restrições ou proteções em recursos que afetam o comportamento dos seus recursos de nuvem. Por exemplo, é possível definir as seguintes políticas da organização e aplicá-las globalmente em uma organização Google Cloud ou seletivamente no nível de uma pasta ou projeto:

  • Desative a alocação de endereços IP externo para VMs.
  • Restringir a criação de recursos a locais geográficos específicos.
  • Desativar a criação de contas de serviço ou chaves delas.

Criptografar dados em repouso e em trânsito

Esta recomendação é relevante para as seguintes áreas de foco:

  • Segurança da infraestrutura
  • Segurança de dados

A criptografia de dados é um controle fundamental para proteger informações sensíveis e uma parte essencial da governança de dados. Uma estratégia eficaz de proteção de dados inclui controle de acesso, segmentação de dados e residência geográfica, auditoria, e implementação de criptografia com base em uma avaliação cuidadosa dos requisitos.

Por padrão,o Google Cloud criptografa dados de clientes armazenados em repouso, sem que você precise fazer nada. Além da criptografia padrão, oGoogle Cloud oferece opções para criptografia de envelopes e gerenciamento de chaves de criptografia. Identifique as soluções que melhor se adaptam às suas necessidades de geração, armazenamento e rotação de chave, seja para chaves de armazenamento, computação ou cargas de trabalho de Big Data. Por exemplo, as chaves de criptografia gerenciadas pelo cliente (CMEKs) podem ser criadas no Cloud Key Management Service (Cloud KMS). As CMEKs podem ser baseadas em software ou protegidas por HSM para atender aos requisitos regulatórios ou de compliance, como a necessidade de girar chaves de criptografia regularmente. Com o Cloud KMS Autokey, é possível automatizar o provisionamento e a atribuição de CMEKs. Além disso, é possível trazer suas próprias chaves de um sistema de gerenciamento de chaves terceirizado usando o Cloud External Key Manager (Cloud EKM).

Recomendamos que os dados sejam criptografados em trânsito. O Google criptografa e autentica dados em trânsito em uma ou mais camadas de rede quando eles são transferidos para fora dos limites físicos que não são controlados pelo Google ou em nome dele. Todo o tráfego de VM para VM em uma rede VPC e entre redes VPC com peering é criptografado. É possível usar o MACsec para criptografar o tráfego nas conexões do Cloud Interconnect. O IPsec oferece criptografia para o tráfego em conexões do Cloud VPN. É possível proteger o tráfego de aplicativo para aplicativo na nuvem usando recursos de segurança como configurações de TLS e mTLS na Apigee e Cloud Service Mesh para aplicativos contêinerizados.

Por padrão,o Google Cloud criptografa dados em repouso e em trânsito na rede. No entanto, os dados não são criptografados por padrão enquanto estão em uso na memória. Se sua organização lida com dados confidenciais, é necessário reduzir as ameaças que comprometem a confidencialidade e a integridade do aplicativo ou dos dados na memória do sistema. Para mitigar essas ameaças, use a Computação confidencial, que oferece um ambiente de execução confiável para suas cargas de trabalho de computação. Para mais informações, consulte Visão geral de VMs confidenciais.