4.3 Segurança de infraestrutura e de nuvem

Visão geral e motivação

As aplicações rodam em infraestrutura, e hoje essa infraestrutura é em grande parte baseada em nuvem, definida por software e em constante mudança. Um único engenheiro agora pode provisionar um banco de dados, abrir um caminho de rede ou conceder uma permissão com um comando, numa escala e velocidade que o controle de mudanças tradicional jamais previu. Esse poder é exatamente o motivo de a configuração incorreta, e não os exploits exóticos, ser a principal causa de violações na nuvem. Um bucket de armazenamento acidentalmente público ou um papel de acesso amplo demais pode expor os dados de uma organização inteira em segundos.

Para as grandes empresas, a infraestrutura de nuvem abrange vários provedores, milhares de contas e uma mistura de serviços gerenciados, contêineres e funções serverless. A superfície de ataque não é um perímetro estático. É uma coleção viva e espalhada de recursos e identidades. Para o governo, a mesma complexidade encontra regimes rígidos de autorização, mandatos de residência de dados e fronteiras de classificação que moldam toda escolha arquitetural. Nos dois, a camada de identidade virou o novo perímetro: quem pode fazer o quê, a qual recurso, sob que condições.

Este capítulo cobre como proteger essa fundação: o gerenciamento de identidade e acesso (IAM), a segmentação de rede, a criptografia e o gerenciamento de chaves, a segurança de contêineres e de cargas serverless e o gerenciamento contínuo de postura que impede um parque de nuvem de ritmo acelerado de derivar para o perigo.

Princípios fundamentais

A identidade é o perímetro. As decisões de acesso dependem de identidade forte e de autorização refinada, não da localização na rede.
Menor privilégio, sempre. Toda identidade, humana ou de máquina, recebe as permissões mínimas necessárias, e nada além.
Segmente para conter. Divida redes e cargas de trabalho para que um comprometimento numa área não possa se espalhar livremente.
Criptografe em toda parte. Proteja os dados em trânsito e em repouso por padrão, com chaves bem gerenciadas.
Imutável e declarativo. Defina a infraestrutura como código (IaC), implante de modo imutável e trate a deriva como um defeito.
Verificação contínua. A postura não é uma auditoria única. Varra e imponha continuamente.
Configuração segura por padrão. O estado padrão de qualquer recurso deve ser trancado, não aberto.

Recomendações

Projete o gerenciamento de identidade e acesso deliberadamente

O IAM é a parte mais importante da segurança na nuvem, e a mais frequentemente mal gerenciada.

Usem o controle de acesso baseado em papéis (RBAC) para conceder permissões por função e o controle de acesso baseado em atributos (ABAC) onde forem necessárias decisões mais finas e sensíveis ao contexto (com base em tags, ambiente, classificação de dados ou horário).
Eliminem as credenciais estáticas de longa duração em favor de tokens de curta duração emitidos automaticamente e da federação de identidade de carga de trabalho.
Imponham a MFA (autenticação multifator) para todo acesso humano e exijam autenticação forte para ações privilegiadas.
Apliquem o menor privilégio com rigor: partam do zero e acrescentem permissões deliberadamente. Revisem e podem regularmente as permissões não usadas. O acesso tende a se acumular.
Separem funções para que nenhuma identidade isolada possa ao mesmo tempo fazer e aprovar mudanças sensíveis.
Usem contas ou projetos dedicados para criar fronteiras rígidas entre ambientes (produção, homologação, desenvolvimento) e entre unidades de negócio.

Segmente as redes e microssegmente as cargas de trabalho

As redes planas deixam os atacantes circularem para os lados depois que entram. Dividam e contenham.

Segmentem no nível da rede em camadas e zonas, permitindo apenas o tráfego que cada camada legitimamente precisa.
Apliquem a microssegmentação para que cargas de trabalho individuais se comuniquem apenas com os pares específicos de que precisam, imposta por política sensível à identidade e não por regras amplas de sub-rede.
Neguem por padrão o tráfego leste-oeste e exijam regras explícitas de permissão.
Ponham os repositórios de dados sensíveis em sub-redes privadas sem exposição direta à internet, alcançados apenas por caminhos controlados.
Usem conectividade privada com serviços gerenciados em vez de rotear pela internet pública sempre que possível.

Criptografe os dados e gerencie bem as chaves

A criptografia só é tão forte quanto o gerenciamento de chaves por trás dela.

Criptografem em trânsito com o TLS (Transport Layer Security) atual em toda parte, inclusive no tráfego interno entre serviços.
Criptografem em repouso por padrão todo armazenamento, banco de dados e cópia de segurança.
Gerenciem as chaves com um Serviço de Gerenciamento de Chaves (KMS) e usem um Módulo de Segurança de Hardware (HSM) para as chaves de maior garantia e para exigências regulatórias.
Rotacionem as chaves numa agenda e suportem a rotação rápida diante de suspeita de comprometimento.
Controlem e auditem quem pode usar e gerenciar as chaves separadamente de quem pode acessar os dados, para que a custódia das chaves imponha a separação de funções.
Considerem chaves gerenciadas pelo cliente onde a regulação ou a confiança contratual exige que a organização detenha as chaves e não o provedor.

Proteja contêineres, Kubernetes e serverless

Cada modelo de computação traz seus próprios riscos.

Contêineres: construam a partir de imagens-base mínimas e confiáveis, varram as imagens em busca de vulnerabilidades antes da implantação, rodem sem root, tornem os sistemas de arquivos somente leitura sempre que possível e nunca embutam segredos nas imagens.
Kubernetes: habilitem o RBAC e delimitem de modo estreito as contas de serviço, apliquem políticas de rede para a microssegmentação, usem controladores de admissão e motores de política para impor padrões, restrinjam contêineres privilegiados, isolem cargas sensíveis e mantenham o plano de controle e os nós corrigidos.
Serverless: apliquem o menor privilégio ao papel de execução de cada função (uma fonte comum de permissões em excesso), validem todas as entradas de eventos, gerenciem os segredos pelo armazenamento de segredos da plataforma e monitorem padrões anômalos de invocação.

Qualquer que seja o modelo, mantenham o ambiente de execução corrigido e as imagens frescas. Um contêiner só é tão seguro quanto o software dentro dele.

Gerencie continuamente a postura de segurança na nuvem

A nuvem muda rápido demais para que auditorias manuais periódicas acompanhem.

Adotem ferramentas de Cloud Security Posture Management (CSPM) para detectar continuamente configurações incorretas, exposição pública e violações de política entre contas.
Definam a política de segurança como código e imponham-na na hora da implantação para que configurações ruins sejam bloqueadas antes de entrar.
Prefiram a prevenção (proteções que impedem a configuração incorreta) à detecção (alertas depois do fato) e combinem as duas.
Mantenham um inventário exato de recursos e identidades. Vocês não conseguem proteger o que não enxergam.
Acompanhem e remedeiem a deriva entre a infraestrutura como código declarada e o estado real em execução.

Compromissos: prós e contras

Decisão	Prós	Contras
RBAC	Simples, compreensível, fácil de auditar	Grosseiro, explosão de papéis em escala
ABAC	Refinado, sensível ao contexto, escala com tags	Complexo de projetar e de raciocinar
Chaves gerenciadas pelo provedor (KMS)	Fácil, integrado, baixo ônus operacional	O provedor detém a custódia. Menos controle
Chaves gerenciadas pelo cliente/HSM	Controle total, atende a mandatos rígidos	Ônus operacional, risco de perder as chaves
Proteções preventivas	Impedem a configuração incorreta antes de acontecer	Podem bloquear trabalho legítimo, exigem ajuste
Apenas CSPM detectivo	Flexível, sem bloqueio	O dano pode ocorrer antes da detecção
Microssegmentação	Forte contenção do movimento lateral	Complexidade operacional, proliferação de políticas

A troca dominante é controle versus ônus operacional. Controles mais apertados (chaves gerenciadas pelo cliente, microssegmentação estrita, ABAC) reduzem o risco, mas exigem especialização e manutenção que as equipes pequenas têm dificuldade de sustentar. O nível certo depende da sensibilidade dos dados e das regulamentações aplicáveis. Uma abordagem pragmática sobrepõe padrões seguros fortes para todos e depois reserva rigor extra para os sistemas de maior risco, e favorece proteções automatizadas que fazem da escolha segura o padrão e não uma disciplina manual.

Perguntas para discutir com sua equipe

Onde vocês vão traçar fronteiras rígidas de conta ou projeto, e o que pertence dentro de cada uma? Contas e projetos dedicados criam a contenção mais forte que a nuvem oferece, para que um comprometimento no desenvolvimento não alcance a produção e uma unidade de negócio não toque os dados de outra. Decidam o seu esquema de fronteiras antes que o parque cresça para milhares de contas, porque adaptar o isolamento a uma estrutura plana é lento e arriscado. Em trabalhos corporativos e governamentais, essas fronteiras também mapeiam bem para a separação de ambientes, a classificação de dados e os limites de raio de impacto que os auditores esperam ver. Levem um diagrama atual de quais cargas dividem hoje uma conta e marquem onde um único papel amplo demais abrange produção e não produção. Se dados sensíveis ficam na mesma conta que cargas experimentais, essa é a fronteira a corrigir primeiro.
Qual é o seu padrão para quem pode gerenciar chaves versus quem pode acessar os dados criptografados? A criptografia é tão forte quanto o gerenciamento de chaves, e separar a custódia das chaves do acesso aos dados transforma o seu KMS num ponto de imposição da separação de funções. Decidam quem pode criar, rotacionar e usar chaves e garantam que esse conjunto não se sobreponha às pessoas que podem ler os dados que essas chaves protegem. Para sistemas regulados e governamentais, isso muitas vezes conduz a escolha entre chaves gerenciadas pelo provedor e chaves gerenciadas pelo cliente ou HSMs, que trazem mais controle e mais risco operacional de perder chaves. Levem as políticas de chaves atuais e verifiquem se alguma identidade isolada consegue ao mesmo tempo gerenciar uma chave e ler os dados por trás dela, porque essa é uma lacuna silenciosa comum. Se a custódia e o acesso não estão divididos, a criptografia em repouso está protegendo vocês menos do que o painel sugere.
Como vocês tornarão os padrões seguros inescapáveis na sua landing zone em vez de meramente recomendados? A configuração incorreta, e não os exploits exóticos, é a principal causa de violações na nuvem, e a correção são proteções preventivas que bloqueiam um banco de dados público ou um bucket sem criptografia antes de entrarem, não alertas depois do fato. Decidam quais políticas vocês imporão na hora da implantação (sem armazenamento público, criptografia ligada por padrão, tags obrigatórias) e quais apenas detectarão e reportarão. Para uma grande equipe, codificar isso em landing zones e modelos de infraestrutura como código significa que toda nova conta herda a proteção sem esforço por equipe, transformando a segurança de um imposto recorrente num investimento único. Levem o último mês de achados de configuração incorreta e perguntem quais deles uma proteção preventiva teria impedido de vez. Se o seu gerenciamento de postura é só detectivo, o dano pode ocorrer antes que alguém veja o alerta, então movam as verificações de maior impacto para a prevenção.
Como vocês eliminam as credenciais estáticas de longa duração sem quebrar a automação que silenciosamente depende delas? As chaves de acesso embutidas que nunca expiram estão entre as causas mais comuns de violações na nuvem, porque uma única chave vazada num script, num log ou num repositório entrega ao atacante um acesso durável. A atração concorrente é operacional: os trabalhos legados de CI, as tarefas agendadas e as integrações de terceiros muitas vezes presumem que existe uma chave estática, e migrá-las para tokens de curta duração ou para a federação de identidade de carga de trabalho leva tempo de engenharia que ninguém agendou. Para uma grande equipe, um caminho de migração compartilhado (emitir tokens automaticamente, definir um padrão de expiração e alarmar sobre qualquer nova chave de longa duração) impede que cada grupo invente sua própria resposta mais fraca. Levem um inventário de toda credencial estática em uso, sua idade, seu raio de impacto e se o sistema que ela alimenta aceita hoje a identidade federada. Em contextos corporativos e governamentais, liguem o prazo aos ciclos de auditoria e de autorização, porque uma credencial que sobrevive à pessoa que a criou é exatamente o achado que trava uma autorização contínua.
Quando um recurso está mal configurado ou uma chave é comprometida, com que rapidez vocês conseguem detectar, conter e remediar, e vocês mediram isso? Um bucket público ou um papel amplo demais só é tão perigoso quanto a janela em que permanece aberto, então o tempo médio de detecção e de remediação é o número que de fato limita a sua exposição. A tensão é entre as proteções preventivas que impedem o erro na hora da implantação e o gerenciamento de postura detectivo que pega o que escapa, e vocês precisam de números honestos para os dois, e não da suposição reconfortante de que as proteções cobrem tudo. Levem o último trimestre de achados de configuração incorreta e de deriva com carimbos de data e hora, a mediana do tempo da introdução à remediação e o registro de ensaios da rotação por comprometimento de chave. Para parques corporativos e governamentais que abrangem milhares de contas, combinem quem é dono da remediação de um achado de que a equipe de ninguém é obviamente dona, porque um alerta sem responsável é um alerta que envelhece até virar incidente.
Como vocês manterão a postura de segurança consistente entre várias nuvens, contas e equipes sem desacelerar todo mundo? Os parques multinuvem e multiconta se fragmentam depressa: cada provedor tem seu próprio modelo de IAM, seus próprios padrões e suas próprias ferramentas de postura, então uma política imposta num lugar caduca em silêncio em outro. A troca é entre o controle central que garante a consistência e a autonomia local que deixa as equipes se moverem depressa, e inclinar-se demais para qualquer lado ou gera gargalo na entrega ou deixa os padrões derivarem. Levem o mapa atual de cobertura: quais contas herdam as proteções da landing zone, quais não são gerenciadas e onde o mesmo controle é expresso de três maneiras diferentes entre os provedores. Para uma organização grande ou pública, acrescentem o ângulo da auditoria, porque os auditores esperam um padrão defensável aplicado em toda parte, e um controle que existe na sua nuvem principal mas não na secundária é uma lacuna que um atacante ou avaliador determinado achará primeiro.

Perspectiva por setor

Startup. A velocidade e a sobrevivência vencem, então apoiem-se inteiramente nos padrões seguros que vêm de graça: criptografia em repouso ligada, armazenamento privado a menos que um humano o abra, MFA na conta raiz e a identidade de carga de trabalho embutida do provedor em vez de chaves de acesso coladas. Não levantem uma plataforma de CSPM nem microssegmentação feita à mão que vocês não conseguem manter. Uma única proteção que bloqueia um banco de dados aberto à internet compra a maior parte da proteção por uma tarde de trabalho. Mantenham tudo em infraestrutura como código desde o início para que o endurecimento escale com vocês e não vire uma reescrita depois.

Pequena empresa. Sem engenheiro de segurança dedicado e com orçamento apertado, prefiram serviços gerenciados cujos padrões já são endurecidos e cujo gerenciamento de chaves é feito por vocês, em vez de construir a sua própria disciplina de KMS. Tratem a segurança na nuvem como uma questão de higiene de configuração: saibam quais buckets e bancos de dados existem, mantenham-nos privados, exijam MFA e liguem as verificações nativas de postura do provedor que vêm sem custo extra. Ao comprar ferramentas, favoreçam as que sinalizam de fábrica a exposição pública e o armazenamento sem criptografia, porque esses dois erros causam a maioria das violações evitáveis.

Grande empresa. O problema real é a consistência entre milhares de contas e muitas equipes, então o trabalho é trabalho de plataforma: landing zones que provisionam toda conta endurecida, proteções impostas como política como código e CSPM varrendo continuamente a deriva. Padronizem o modelo de IAM, as regras de custódia de chaves e a linha de base de segmentação para que os grupos parem de reinventar versões mais fracas e meçam a postura em todo o parque em vez de confiar na palavra de cada equipe. Orcem a engenharia contínua para manter as políticas atuais à medida que os provedores acrescentam serviços e o parque cresce.

Governo. As regras de contratação, os mandatos de residência de dados e os regimes de autorização moldam toda escolha, então os controles de segurança fazem as vezes de evidência de auditoria. Favoreçam o gerenciamento de chaves validado pela FIPS com custódia separada do acesso aos dados, regiões isoladas que mantêm os dados dentro das fronteiras nacionais e imagens de contêiner assinadas e varridas, com controle estrito de admissão. Publiquem as salvaguardas que puderem, alimentem o gerenciamento contínuo de postura diretamente na autorização contínua e exijam que os fornecedores divulguem seus padrões de configuração e suportem os controles de segmentação e de custódia de chaves que as suas fronteiras de classificação demandam.

Exemplos

Startup. Uma pequena startup roda tudo numa única conta de nuvem e não consegue pôr uma equipe de plataforma, então se apoia em padrões que já vêm seguros: criptografia em repouso ligada por padrão, buckets de armazenamento privados a menos que um humano os abra explicitamente e MFA exigida na conta raiz. Em vez de chaves de acesso de longa duração coladas no CI, usa a identidade de carga de trabalho embutida do provedor, de modo que o pipeline recebe credenciais de curta duração automaticamente. Uma única proteção gratuita que sinaliza qualquer banco de dados aberto à internet poupa a startup do erro de nuvem mais comum e mais caro, ao custo de uma tarde para configurar.

Grande empresa. Uma empresa de mídia que opera milhares de contas em dois provedores de nuvem impõe um padrão de landing zone: toda conta é provisionada a partir de um modelo com criptografia em repouso ligada por padrão, nenhum acesso público ao armazenamento, tags obrigatórias e uma linha de base de políticas de proteção. O CSPM varre continuamente a deriva, e a federação de identidade de carga de trabalho eliminou as chaves de longa duração dos sistemas de CI. Quando um desenvolvedor tenta acidentalmente abrir um banco de dados à internet, uma política preventiva bloqueia a mudança e abre um chamado automaticamente.

Governo. Uma agência vizinha à defesa opera numa região de nuvem isolada com a residência de dados imposta por política para que nenhum dado saia das fronteiras nacionais. As chaves mais sensíveis vivem em HSMs validados pela FIPS (Federal Information Processing Standards), com a custódia das chaves separada do acesso aos dados para impor a separação de funções. Os clusters Kubernetes usam políticas de rede estritas e controles de admissão. Toda imagem de contêiner é varrida e assinada antes de poder rodar. O gerenciamento contínuo de postura alimenta diretamente a evidência de autorização contínua da agência.

Justificativa de negócio: motivações, ROI e TCO

A segurança de infraestrutura de nuvem é onde um pequeno investimento evita perdas catastróficas, dignas de manchete. O custo total de propriedade inclui as ferramentas de CSPM, os serviços de gerenciamento de chaves, o tempo de engenharia para projetar um IAM de menor privilégio e a segmentação e o esforço contínuo para manter as políticas atuais. Esses custos são reais mas modestos. O custo de pulá-los é um único recurso mal configurado expondo um banco de dados inteiro de clientes, junto com as multas regulatórias, os custos de notificação e o dano duradouro à marca que se seguem. As violações por configuração incorreta na nuvem estão entre os incidentes mais comuns e mais evitáveis do setor.

A automação e a reutilização amplificam o ROI. Codifiquem padrões seguros em landing zones e modelos de infraestrutura como código, e cada nova conta e carga de trabalho herda a proteção sem esforço por equipe, transformando a segurança de um imposto manual recorrente num investimento único de plataforma. Para governos e empresas reguladas, um forte gerenciamento de postura também reduz o custo das auditorias e da autorização contínua ao produzir evidência automaticamente. Ao defender o caso junto à liderança, enfatizem que a camada de identidade e de configuração é agora o principal vetor de violação, que a configuração incorreta é evitável e que as proteções cortam tanto o risco quanto o atrito da revisão manual.

Antipadrões e armadilhas

Permissões coringa. Conceder acesso amplo * “para fazer funcionar” e nunca apertá-lo.
Chaves estáticas de longa duração. Chaves de acesso embutidas em scripts e CI que nunca expiram e eventualmente vazam.
Redes planas. Sem segmentação, de modo que um host comprometido alcança tudo.
Público por acidente. Armazenamento e bancos de dados expostos à internet por configurações padrão ou descuidadas.
Criptografia sem disciplina de chaves. Ligar a criptografia mas deixar o acesso às chaves totalmente aberto ou nunca rotacioná-las.
Segredos embutidos em imagens. Credenciais embutidas em imagens de contêiner que se espalham por onde a imagem roda.
Papéis serverless com permissões em excesso. Funções que recebem muito mais do que precisam porque o escopo foi pulado.
Postura só de auditoria. Detectar configurações incorretas depois do fato em vez de preveni-las na hora da implantação.
Ignorar a deriva. Deixar o ambiente em execução divergir da infraestrutura como código até que ninguém saiba o estado real.

Modelo de maturidade

Nível 1: Iniciar. Provisionamento manual conduzido por quem precisa de um recurso. Permissões coringa amplas e chaves estáticas de longa duração. Redes planas sem segmentação. Criptografia aplicada de forma inconsistente, se tanto. Nenhum gerenciamento de postura. As configurações incorretas só aparecem depois que um incidente força a pergunta.

Nível 2: Desenvolver. Aparecem alguns papéis de IAM e a MFA, e a criptografia em repouso é ligada para os principais repositórios, mas a prática varia de equipe para equipe. Existem camadas básicas de rede sem negação por padrão. As revisões de configuração acontecem periodicamente e à mão. A infraestrutura é definida em parte como código, então o endurecimento depende de qual grupo provisionou a conta.

Nível 3: Padronizar. O RBAC e o ABAC de menor privilégio com credenciais de curta duração são documentados e impostos em toda a organização. A segmentação usa negação por padrão no tráfego leste-oeste. A criptografia em trânsito e em repouso está ligada por padrão, com chaves no KMS numa agenda de rotação e custódia separada do acesso aos dados. O endurecimento de contêineres e do Kubernetes é um padrão, e o CSPM roda contra políticas definidas e aplicadas de modo consistente em toda conta.

Nível 4: Gerenciar. A postura é medida, não presumida. Vocês acompanham métricas nomeadas contra linhas de base e metas: a parcela de identidades dentro da sua linha de base de menor privilégio, o tempo médio de detecção e de remediação de configurações incorretas e de deriva, a cobertura de proteções e de CSPM entre as contas, a conformidade com a rotação de chaves e a contagem de credenciais de longa duração remanescentes. Os achados passam por triagem pelo raio de impacto, a remediação tem um responsável e um objetivo de nível de serviço, e os dados de tendência desses números conduzem para onde vai o próximo esforço de endurecimento.

Nível 5: Orquestrar. Os padrões seguros são embutidos em landing zones e na infraestrutura como código para que todo recurso nasça endurecido, e os controles se adaptam conforme o parque e o quadro de ameaças mudam. A microssegmentação usa política sensível à identidade. Chaves gerenciadas pelo cliente e HSMs protegem os sistemas de maior garantia, com separação de custódia. As proteções preventivas bloqueiam a configuração incorreta na hora da implantação, a deriva é detectada e remediada automaticamente e a evidência de postura alimenta a autorização contínua de forma automática. A segurança é integrada à entrega e ao planejamento de riscos, e a organização rotineiramente aposenta e redimensiona controles à medida que provedores, serviços e regulamentações mudam.

Ideias para discussão

Onde o ABAC vale a sua complexidade versus ficar com o RBAC no seu ambiente?
Como vocês eliminam as credenciais de longa duração sem quebrar a automação legada?
Qual é a divisão certa entre as proteções preventivas e o gerenciamento de postura detectivo?
Quais sistemas justificam chaves gerenciadas pelo cliente ou HSMs, dado o custo operacional deles?
Como vocês impedem que as permissões de menor privilégio se acumulem em silêncio de volta ao privilégio excessivo?
Como a complexidade multinuvem deve mudar a sua abordagem de postura e de política consistentes?

Principais conclusões

A identidade é o novo perímetro. Invistam num IAM de menor privilégio com credenciais de curta duração.
Segmentem as redes e microssegmentem as cargas de trabalho para conter o comprometimento.
Criptografem em trânsito e em repouso por padrão e gerenciem as chaves com KMS/HSM e separação de custódia.
Endureçam contêineres, Kubernetes e serverless. Mantenham ambientes de execução e imagens corrigidos.
Prefiram proteções preventivas à detecção depois do fato e gerenciem a postura continuamente.
Embutam padrões seguros em landing zones e na infraestrutura como código para que a proteção escale automaticamente.
A configuração incorreta, e não os exploits exóticos, é a principal causa de violações na nuvem, e é evitável.

Referências e leitura complementar

National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
Centre for Internet Security, CIS Benchmarks (cloud providers, Kubernetes, Docker)
Cloud Security Alliance, Cloud Controls Matrix and Security Guidance for Cloud Computing
NIST, SP 800-190: Application Container Security Guide
Liz Rice, Container Security
Marco Lancini and others, Cloud security posture and detection engineering literature
Provider Well-Architected security pillars (as vendor-neutral architectural guidance)