Este princípio no pilar de segurança do Google Cloud Well-Architected Framework fornece recomendações para incorporar recursos de segurança, controles e práticas robustos ao design de aplicativos, serviços e plataformas em nuvem. Da idealização às operações, a segurança é mais eficaz quando é incorporada como parte integrante de cada estágio do processo de design.
Visão geral do princípio
Como explicado em Uma visão geral do compromisso do Google com a segurança por design, seguro por padrão e seguro por design são frequentemente usados como sinônimos, mas representam abordagens distintas para criar sistemas seguros. Ambas as abordagens visam minimizar 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 estejam definidas para um modo seguro, o que minimiza a necessidade de os 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 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 consiste em antecipar possíveis ameaças e vulnerabilidades com antecedência e fazer escolhas de design que reduzam 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 o 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 desde o design nas cargas de trabalho em 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 atestados
- Criptografar dados em repouso e em trânsito
Escolher 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 uma 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, considere 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. Também é possível 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, 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.
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 impacto potencial (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 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 regulamentares. Por exemplo, a Cloud Security Alliance (CSA) fornece a matriz de controles do Cloud (CCM, na sigla em inglês). A avaliação de risco fornece um catálogo de riscos e os 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 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, é necessário reduzir as vulnerabilidades da 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 em potencial, 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 atestados 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 resolvê-las.
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 correção para corrigir 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 imagens, bem como comparativos de mercado, como o fornecido pelo Center of Internet Security (CIS).
Se você usa imagens personalizadas para as VMs do Compute Engine, precisa aplicar patches nelas 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 Container-Optimized OS selecionadas pelo Google. O Google corrige e atualiza essas imagens regularmente.
Se você usa o Google Kubernetes Engine (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 sensíveis à segurança, microsserviços e situações em que é fundamental minimizar o tamanho da imagem e a superfície de ataque.
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 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 Identity and Access Management (IAM) como a fonte de verdade, 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 é 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 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 implante-a novamente. Ative o acesso SSH aos contêineres subjacentes apenas em cenários de depuração específicos.
Para ajudar a proteger as configurações em todo o ambiente, use as políticas da organização para definir restrições ou proteções em recursos que afetam o comportamento dos recursos de nuvem. Por exemplo, é possível definir as seguintes políticas da organização e aplicá-las globalmente em uma organização do Google Cloud ou seletivamente no nível de uma pasta ou projeto:
- Desativar a alocação de endereços IP externo para VMs.
- Restringir a criação de recursos a localizações geográficas específicas.
- Desative a criação de contas de serviço ou das 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 os dados do cliente armazenados em repouso, sem que você precise fazer nenhuma ação necessária. Além da criptografia padrão, oGoogle Cloud oferece opções para criptografia de envelope e gerenciamento de chaves de criptografia. Identifique as soluções que melhor atendem aos seus requisitos de geração, armazenamento e rotação de chaves, seja para escolher as chaves para seu armazenamento, para computação ou para 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 alternar 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 provenientes 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 eles são transferidos para outros limites físicos que não são controlados pelo Google ou em nome dele. Todo o tráfego entre VMs 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 em conexões do Cloud VPN. É possível proteger o tráfego entre aplicativos na nuvem usando recursos de segurança como configurações de TLS e mTLS na Apigee e Cloud Service Mesh para aplicativos conteinerizados.
Por padrão, o Google Cloud criptografa dados em repouso e dados 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 a organização lida com dados confidenciais, é necessário mitigar as ameaças que prejudicam 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 fornece 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.