Esse princípio no pilar de segurança do framework de arquiteturaGoogle Cloud oferece recomendações para incorporar recursos, controles e práticas de segurança robustos ao design de aplicativos, serviços e plataformas em nuvem. Da ideação às operações, a segurança é mais eficaz quando está integrada como parte integrante de cada estágio 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, os termos seguro por padrão e seguro por design são usados com frequência de forma intercambiável, mas representam abordagens distintas para criar sistemas seguros. Ambas as abordagens têm como objetivo minimizar as vulnerabilidades e melhorar a segurança, mas diferem em escopo e implementação:
- Seguro por padrão: foca em garantir que as configurações padrão de um sistema sejam definidas em um modo seguro, minimizando a necessidade de que usuários ou administradores tomem medidas para proteger o sistema. Essa abordagem tem como objetivo oferecer um nível básico de segurança para todos os usuários.
- Segurança por 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 é sobre antecipar possíveis ameaças e vulnerabilidades e fazer escolhas de design que mitigam 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 integração da segurança em todo o processo de design. A abordagem de segurança por design é uma filosofia abrangente que orienta o processo de desenvolvimento e ajuda a garantir que a segurança não seja um elemento posterior, mas parte integrante do design de um sistema.
Recomendações
Para implementar o princípio de segurança por design nas cargas de trabalho na nuvem, considere as recomendações nas seções a seguir:
- Escolher componentes do sistema que ajudam a proteger suas cargas de trabalho
- Criar uma abordagem de segurança em camadas
- Usar infraestrutura e serviços reforçados e certificados
- Criptografar dados em repouso e em trânsito
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 de sistema robustos, incluindo componentes de 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, você também precisa considerar 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 operações seguras 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 para a 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
Essa 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 profunda.
Use os recursos de segurança em cada componente da plataforma. Para limitar o acesso e identificar os limites do possível impacto (ou seja, o raio de explosão) em caso de um 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 externos regulatórios. 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). Sua avaliação de riscos fornece um catálogo de riscos e controles de segurança correspondentes para mitigá-los.
Ao realizar a avaliação de risco, lembre-se de que você tem um acordo de responsabilidade compartilhada com o 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 diferem entre os serviços IaaS, PaaS e SaaS de cada provedor de nuvem.
Depois de identificar possíveis riscos, você precisa projetar e criar um plano de mitigação que use controles técnicos, administrativos e operacionais, além de proteções contratuais e declarações de terceiros. Além disso, um método de estimativa de ameaça, como o método de estimativa de ameaça do aplicativo OWASP, ajuda a identificar possíveis lacunas e sugere ações para corrigir as lacunas.
Usar infraestrutura e serviços reforçados e certificados
Essa recomendação é relevante para todas as áreas de foco.
Um programa de segurança maduro mitiga novas vulnerabilidades, conforme descrito nos boletins de segurança. O programa de segurança também precisa fornecer remediação para corrigir vulnerabilidades em implantações existentes e proteger suas VMs e imagens de contêineres. É possível usar guias de proteção específicos para o SO e o aplicativo das imagens, além de comparativos de mercado, como o fornecido pelo Center for Internet Security (CIS).
Se você usa imagens personalizadas para suas VMs do Compute Engine, é necessário corrigir as imagens por conta própria. Como alternativa, 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 SO otimizadas para contêineres selecionadas pelo Google. O Google corrige e atualiza essas imagens regularmente.
Se você usa o GKE, recomendamos ativar o upgrade automático de nós para que o Google atualize os nós do cluster com os patches mais recentes. O Google gerencia os 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 sensíveis à segurança, microsserviços e situações em que minimizar o tamanho da imagem e a superfície de ataque é essencial.
Para cargas de trabalho sensíveis, use a VM protegida, que impede que códigos maliciosos sejam carregados durante o ciclo de inicialização da VM. As instâncias de VM protegidas fornecem segurança de inicialização, monitoram a integridade e usam o Módulo da 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 permissões de 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 os contêineres 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 interativamente. Se o contêiner precisar ser alterado, 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 as políticas da organização para definir restrições ou limites em recursos que afetam o comportamento dos ativos na nuvem. Por exemplo, é possível definir as seguintes políticas da organização e aplicá-las globalmente em uma Google Cloud organização ou seletivamente no nível de uma pasta ou de um projeto:
- Desative a alocação de endereços IP externos para VMs.
- Restringir a criação de recursos a locais geográficos específicos.
- Desative a criação de contas de serviço ou das chaves delas.
Criptografar dados em repouso e em trânsito
Essa 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 importante 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, Google Cloud criptografa os dados do cliente armazenados em repouso, sem que você precise fazer nada. Além da criptografia padrão, Google 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, 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 de compliance ou regulamentares, como a necessidade de alternar chaves de criptografia regularmente. O Cloud KMS Autokey permite automatizar o provisionamento e a atribuição de CMEKs. Além disso, é possível usar suas próprias chaves originadas de um sistema de gerenciamento de chaves de terceiros com o Gerenciador de chaves externas do Cloud (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 outros limites físicos nã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 em conexões do Cloud Interconnect. O IPsec fornece criptografia para o tráfego por conexões do Cloud VPN. É possível proteger o tráfego de um aplicativo para outro na nuvem usando recursos de segurança, como configurações de TLS e mTLS na Apigee e Cloud Service Mesh para aplicativos contêineres.
Por padrão, Google Cloud criptografa dados em repouso e em trânsito pela rede. No entanto, os dados não são criptografados por padrão enquanto estão em uso na memória. Se a sua organização lida com dados confidenciais, você precisa 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.