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 incorporada como parte integrante de cada etapa do processo de design.
Visão geral do princípio
Conforme explicado em Uma 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 com frequência de forma intercambiável, mas representam abordagens distintas para a criação de sistemas seguros. Ambas as abordagens visam minimizar vulnerabilidades e aumentar a segurança, mas diferem no escopo e na implementação:
- Segurança por padrão: se concentra em garantir que as configurações padrão de um sistema estejam definidas para um modo seguro, minimizando a necessidade de usuários ou administradores tomarem medidas para proteger o sistema. Essa abordagem visa fornecer 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 consiste em antecipar possíveis ameaças e vulnerabilidades e fazer escolhas de design que atenuem os riscos. Essa abordagem envolve o uso de práticas de programação seguras, a realização de revisões de segurança e a incorporação de segurança em todo o processo de design. A abordagem de segurança incorporada ao design é 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 uma parte integrante do design de um sistema.
Recomendações
Para implementar o princípio de segurança por design para cargas de trabalho na nuvem, considere as recomendações nas seções a seguir:
- Escolha componentes do sistema que ajudem a proteger suas cargas de trabalho
- Crie uma abordagem de segurança em camadas
- Use infraestrutura e serviços protegidos e atestados
- Criptografe dados em repouso e em trânsito
Escolha componentes do sistema que ajudem 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 o uso de 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 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, na sigla em inglês) que o Google usa e protege.
Sua infraestrutura precisa usar opções de rede, armazenamento e computação que ofereçam suporte à 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 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.
Crie 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 da pilha de aplicativos e 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 impacto) 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 robusto 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 que seja relevante para seus requisitos regulatórios. Por exemplo, a Cloud Security Alliance (CSA) fornece a matriz de controles do Cloud (CCM, na sigla em inglês). Sua avaliação de risco 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, é necessário reduzir as vulnerabilidades na 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 para 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, bem como proteções contratuais e atestações de terceiros. Além disso, um método de modelagem de ameaças, como o método de modelagem de ameaças de aplicativos OWASP, ajuda a identificar possíveis lacunas e sugere ações para resolver as lacunas.
Use infraestrutura e serviços protegidos e atestados
Essa recomendação é relevante para todas as áreas de foco.
Um programa de segurança maduro atenua novas vulnerabilidades, conforme descrito nos boletins de segurança. O programa de segurança também precisa fornecer soluções para corrigir vulnerabilidades em implantações atuais e proteger suas imagens de VM e contêiner. Você pode usar guias de reforço da proteção específicos para o SO e o aplicativo das imagens, bem como comparativos de mercado como o fornecido pelo Center of Internet Security (CIS).
Se você usar imagens personalizadas para as VMs do Compute Engine, será necessário corrigir as imagens. Como alternativa, use 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, você pode usar 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 é fundamental.
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 protegida oferecem 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, na sigla em inglês) 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 oferece suporte à autenticação de dois fatores do Google, que adiciona uma camada extra de segurança contra ataques de sequestro 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 reimplemente essa imagem. 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 barreiras de proteção 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 Google Cloud organização ou seletivamente no nível de uma pasta ou projeto:
- Desative a alocação de endereços IP externo para VMs.
- Restrinja a criação de recursos a locais geográficos específicos.
- Desative a criação de contas de serviço ou chaves delas.
Criptografe 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 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, Google Cloud o Google Cloud criptografa dados do cliente armazenados em repouso, sem que você tenha que intervir no processo. Além da criptografia padrão, Google Cloud 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, 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 conformidade, como a necessidade de girar as chaves de criptografia regularmente. O Autokey do Cloud KMS permite 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 de terceiros 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 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. Use o MACsec para criptografia de tráfego em conexões do Cloud Interconnect. O IPsec fornece criptografia para 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 no Apigee e no Cloud Service Mesh para aplicativos conteinerizados.
Por padrão, Google Cloud o Google Cloud criptografa dados em repouso e dados em trânsito em toda a 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, você precisa reduzir as ameaças que comprometem a confidencialidade e a integridade do aplicativo ou dos dados na memória do sistema. Para atenuar essas ameaças, use a computação confidencial, que fornece um ambiente de execução confiável para cargas de trabalho de computação. Para mais informações, consulte Visão geral de VMs confidenciais.