As 14 principais estruturas de padrões de segurança em nuvem em 2026

Principais conclusões

• Os padrões de segurança na nuvem se enquadram em cinco tipos de aplicação, desde certificações e atestados até regulamentações, contratos e estruturas de controle.
• A norma ISO/IEC 27017 passou pela sua primeira reformulação completa desde 2015, o FedRAMP reescreveu seu regulamento e a CSA lançou a versão 4.1 do CCM.
• A aplicação de correções aparece em quase todas as normas aqui, mas apenas algumas estabelecem um prazo rígido para isso.
• A maior parte das dificuldades relacionadas à auditoria se acumula entre uma avaliação e outra, à medida que o acúmulo de correções aumenta e as configurações se desviam do padrão.

Grande parte do que sustenta uma empresa moderna hoje em dia depende de uma infraestrutura que não lhe pertence, e essa mudança alterou quem é responsável pela segurança. Além disso, multiplicou o número de regulamentos em equipe de segurança precisa cumprir simultaneamente. Os padrões de segurança na nuvem são esses conjuntos de regras, colocados por escrito.

Este artigo aborda o que são as normas de segurança na nuvem, por que o tipo de norma é importante e quais são as 14 mais relevantes para os programas de conformidade na nuvem em 2026.

O que é segurança na nuvem?

Segurança na nuvem é o conjunto de controles que protegem cargas de trabalho, identidades e dados em ambientes de nuvem, o que geralmente significa servidores administrados por terceiros. Abrange configuração, criptografia, gerenciamento de acesso, aplicação de patches e monitoramento nas arquiteturas IaaS, PaaS e SaaS. Na IaaS, o provedor cuida dos hosts físicos e do hipervisor, enquanto você é responsável por praticamente tudo a partir do sistema operacional convidado. No SaaS, o provedor opera a maior parte da pilha, de modo que sua função se limita à identidade, à configuração do locatário e ao uso que as pessoas fazem dos dados. O PaaS fica entre os dois.

O que são padrões de segurança na nuvem?

Os padrões de segurança na nuvem são requisitos publicados que definem o que significa “segurança suficiente” na nuvem e oferecem aos auditores e órgãos reguladores uma base concreta para a realização de testes. Alguns vêm acompanhados de um certificado efetivo, com prazo de validade e renovação. Outros geram um relatório de atestado, em vez de uma certificação de aprovação ou reprovação. Alguns têm caráter legal, com multas previstas em caso de descumprimento. Outros são orientações voluntárias que as organizações adotam porque um cliente, um auditor ou sua própria avaliação de riscos as indicam como necessárias.

Essa última categoria se sobrepõe ao que as pessoas costumam chamar de estruturas de segurança em nuvem: o NIST CSF, a Matriz de Controles em Nuvem (CCM) da CSA e conjuntos de referência semelhantes criados para orientação, e não para certificação. A sobreposição é real e ocorre nos dois sentidos. Muitas compilações de “padrões” incluem o NIST CSF e a CCM, embora ambos se definam como voluntários.

Este guia utiliza o termo “padrão” como termo genérico para os requisitos de segurança na computação em nuvem em sentido amplo, e classifica cada item de acordo com a forma como ele é efetivamente aplicado (certificação, atestado, regulamentação, exigência contratual ou estrutura de controle), em vez de traçar uma linha rígida entre “padrões” e “estruturas”.

Por que os padrões de segurança na nuvem são importantes

Há duas razões: elas condicionam a receita e condicionam o risco. Muitos compradores corporativos não assinam o contrato até que um relatório SOC 2 ou um certificado ISO esteja registrado. E os órgãos reguladores podem tomar medidas contra você por violações do GDPR ou da HIPAA, independentemente de você possuir um certificado ou não.

Para organizações orientadas à conformidade, as normas têm um papel mais concreto do que apenas sinalizar boas intenções. Elas traduzem a afirmação “levamos a segurança a sério” em uma linguagem de controle que um órgão regulador, um auditor ou uma equipe de compras possa realmente verificar.

A realidade: Ser aprovado em uma auditoria não prova que seus controles funcionem diariamente entre uma auditoria e outra. As auditorias de vigilância da ISO 27001 geralmente ocorrem uma vez por ano, e um período de observação do SOC 2 Tipo II pode durar quase um ano inteiro. Entre esses pontos de verificação, o acúmulo de patches aumenta, as configurações se desviam e novos serviços são ativados fora do escopo coberto pela última auditoria. Sem monitoramento contínuo, grande parte disso não virá à tona até a próxima avaliação. Nossa lista das atuais ameaças à segurança na nuvem abrange o que tende a se acumular nesse intervalo.

As 14 principais normas de segurança na nuvem

O tipo de norma que você está analisando determina o que você realmente precisa fazer a respeito. É ao confundir esses cinco tipos que as equipes acabam prometendo a um cliente um “certificado ISO 27017” que não existe como documento independente, ou dizendo a um auditor que são “certificados pelo NIST CSF”, quando o CSF nem sequer possui um programa de certificação.

1. ISO/IEC 27017 (Edição de 2026)

A ISO e a IEC mantêm essa norma em conjunto por meio de seu comitê técnico conjunto para segurança da informação, e a edição de 2026 é uma verdadeira reformulação, e não apenas uma atualização superficial. Publicada em julho de 2026, ela substitui totalmente a versão original de 2015 e adapta a norma à estrutura de controle da ISO/IEC 27002:2022, em substituição à estrutura de 2013 na qual ela se baseava.

A edição de 2015 trouxe sete controles adicionais para a nuvem com números CLD, abrangendo aspectos como o fortalecimento de máquinas virtuais e a devolução de ativos do cliente ao término do contrato. A edição de 2026 reduz as adições específicas para a nuvem a quatro: a divisão básica de responsabilidade compartilhada entre provedor e cliente, um acordo sobre as funções e responsabilidades de qualquer parceiro de serviço em nuvem envolvido, como um corretor ou auditor que faça parte da cadeia de suprimentos, a segregação em ambientes de computação virtual e a detecção e prevenção do uso não autorizado da nuvem.

A maior parte das orientações restantes sobre nuvem agora se apresenta na forma de notas específicas sobre nuvem, associadas aos próprios controles relevantes da norma ISO/IEC 27002:2022.

Assim como antes, não há um certificado independente para esse item. Ele é auditado como parte de uma certificação ISO/IEC 27001 cujo escopo inclui serviços em nuvem. Se a sua documentação de conformidade ainda citar o antigo conjunto de sete controles por meio de seus números CLD, ela estará se referindo a uma estrutura substituída, e um avaliador que estiver trabalhando com a edição de 2026 poderá muito bem sinalizar isso.

Isso é particularmente útil para provedores de nuvem que precisam comprovar o nível de maturidade em termos de controle para compradores corporativos, bem como para clientes que desejam que a divisão de responsabilidades em uma relação de nuvem seja formalizada de forma mais concreta do que apenas em uma conversa de vendas.

2. SOC 2

A certificação SOC 2 é emitida pela AICPA e funciona de maneira diferente da maioria dos itens desta lista. Uma empresa de contabilidade certificada examina seus controles e emite um relatório de parecer. Não existe um selo oficial de “certificação SOC 2”, independentemente do que a página inicial de um fornecedor possa sugerir.

A prova é baseada nos Critérios de Serviços de Confiança de 2017, com pontos de foco revisados que a AICPA publicou em 2022 para manter as orientações atualizadas em relação às novas tecnologias e ameaças. Os critérios subjacentes, por si só, não mudaram desde 2017. Existem cinco categorias: segurança, disponibilidade, integridade do processamento, confidencialidade e privacidade. A segurança é obrigatória em todos os relatórios SOC 2, e você adiciona as demais categorias com base no que se comprometeu com os clientes.

Os relatórios do Tipo I descrevem a estrutura dos controles em um determinado momento. Os relatórios do Tipo II descrevem a eficácia operacional ao longo de um período, geralmente entre três e doze meses, e é esse tipo que os compradores corporativos costumam solicitar. Nosso guia para atender e manter a conformidade com o SOC 2 aborda a tensão entre os compromissos de disponibilidade e as janelas de aplicação de patches.

3. RGPD

RGPD, formalmente o Regulamento (UE) 2016/679, aplica-se a organizações estabelecidas na UE e a organizações fora da UE que ofereçam bens ou serviços a pessoas na UE ou monitorem o comportamento dessas pessoas. Especificamente no que diz respeito à nuvem, a distinção entre controlador e processador é o aspecto mais importante. É necessário um Acordo de Tratamento de Dados, garantias documentadas para transferências para fora do Espaço Econômico Europeu e um processo que permita ao controlador notificar a autoridade de supervisão sem demora injustificada e, quando viável, no prazo de 72 horas após tomar conhecimento de uma violação passível de notificação. Os processadores, por sua vez, devem informar os controladores sem demora injustificada.

As multas máximas chegam a 20 milhões de euros ou 4% do faturamento anual global, o que for maior.

4. HIPAA

A Lei de Portabilidade e Responsabilidade do Seguro Saúde (HIPAA) estabelece as diretrizes básicas para a proteção de informações de saúde nos EUA, sendo aplicada pelo Escritório de Direitos Civis do Departamento de Saúde e Serviços Humanos (HHS). Assim como o GDPR, trata-se de uma lei e não de uma estrutura voluntária. Ela se aplica a entidades abrangidas (prestadores de serviços de saúde, planos de saúde e centrais de processamento de dados de saúde) e a seus parceiros comerciais. Um provedor de nuvem que cria, recebe, mantém ou transmite informações eletrônicas de saúde protegidas (ePHI) em nome de uma entidade abrangida é considerado um parceiro de negócios, mesmo que nunca tenha acesso aos dados.

Um Acordo de Parceria Comercial (BAA) define as responsabilidades de cada parte e exige contratualmente que o provedor proteja as informações de saúde protegidas eletrônicas (ePHI). Um provedor de serviços em nuvem nessa função também é diretamente responsável pelo cumprimento dos requisitos aplicáveis da HIPAA, e essa responsabilidade não depende do BAA.

Os requisitos técnicos estão previstos na Regra de Segurança: controle de acesso, controles de auditoria, integridade, segurança de transmissão e análise de riscos. Uma proposta de atualização eliminaria a divisão atual entre especificações “obrigatórias” e “opcionais” e tornaria obrigatórias a criptografia, a autenticação multifatorial e um inventário documentado dos ativos tecnológicos, com apenas exceções limitadas. Até outubro de 2026, essa regra final ainda não havia sido publicada. A agenda regulatória do HHS agora indica julho de 2027 como meta, após a meta anterior, de maio de 2026, ter passado sem que a regra fosse publicada.

5. PCI DSS

O Conselho de Padrões de Segurança PCI publica esta norma, e a versão atual é a v4.0.1. O nome diz “padrão”, mas a aplicação é de natureza contratual. Seu banco adquirente e as operadoras de cartão são responsáveis pela aplicação, e não um órgão regulador governamental.

As datas relevantes para este caso já passaram. A versão 4.0 trouxe uma série de novos requisitos, e os 51 que tinham data de vigência futura passaram a ser obrigatórios em 31 de março de 2025. Todos eles já estão em vigor, sem nenhum período de carência disponível.

O PCI DSS também possui uma das exigências mais explícitas sobre a aplicação de patches desta lista. O requisito 6.3.3 estabelece que os patches para vulnerabilidades críticas devem ser aplicados no prazo de um mês após o lançamento, enquanto todos os demais patches aplicáveis seguem um prazo definido pela própria entidade com base em sua classificação de risco. A redação original da versão 4.0 ampliou brevemente esse prazo de um mês para abranger também os patches de alta gravidade. O conselho reverteu essa disposição para abranger apenas vulnerabilidades críticas na versão 4.0.1, que é o requisito atual, mais restrito. O requisito 11.3.1 exige, separadamente, a realização de varreduras internas de vulnerabilidades pelo menos uma vez a cada três meses e após qualquer alteração significativa.

6. ISO/IEC 27001 (Edição de 2022)

Ao contrário das normas ISO/IEC 27017 e 27018, a ISO/IEC 27001 oferece um certificado verdadeiro e independente. Um órgão de certificação credenciado audita seu sistema de gestão de segurança da informação e emite um certificado a cada três anos, com auditorias de vigilância anuais para garantir a conformidade nesse intervalo.

A revisão de 2022 reformulou significativamente o Anexo A, consolidando 114 controles em 93 e agrupando-os em quatro temas. Onze controles totalmente novos foram introduzidos junto com essa reestruturação, incluindo inteligência de ameaças, segurança da informação para serviços em nuvem e prevenção de vazamento de dados.

O prazo para a transição da edição de 2013 encerrou-se em 31 de outubro de 2025, e os certificados ainda na edição de 2013 não são mais válidos. Se sua organização não realizou a transição, espere passar por uma nova auditoria de certificação inicial, em vez de uma auditoria de transição mais simplificada.

7. ISO/IEC 27018 (Edição de 2025)

Mantida pelo mesmo comitê da ISO/IEC que a ISO/IEC 27017, esta norma possui uma estrutura semelhante. Ela não é certificável de forma independente. Trata-se de uma orientação que complementa um SGSI baseado na ISO/IEC 27001, e algumas entidades certificadoras realizam avaliações com base nela juntamente com uma auditoria da 27001. Atualmente, está em sua terceira edição, publicada em agosto de 2025 para substituir a versão de 2019, com seus controles realinhados à ISO/IEC 27002:2022 e um novo Anexo B adicionado.

Enquanto o 27017 aborda a segurança na nuvem de maneira ampla, a norma 27018 aborda bem um aspecto específico: a proteção de informações de identificação pessoal (PII) em nuvens públicas nas quais o provedor atua como processador de PII. Isso inclui no escopo o consentimento, a limitação da finalidade, a divulgação de quaisquer subprocessadores, a transparência sobre onde os dados são processados e armazenados e a exclusão assim que o relacionamento for encerrado.

É a solução ideal para provedores de nuvem pública que buscam um conjunto reconhecido de controles de privacidade que se alinhe perfeitamente às obrigações dos processadores previstas no GDPR.

8. CSA STAR e a Matriz de Controles em Nuvem

A Cloud Security Alliance mantém ambos os elementos aqui, e é fácil confundir um com o outro. A Matriz de Controles em Nuvem (Cloud Controls Matrix) é a própria estrutura de controles. O STAR é o programa de garantia desenvolvido com base nela. A CCM v4.1 foi lançada no final de janeiro de 2026 com 11 novos controles, elevando o total para 207 nos mesmos 17 domínios.

O STAR possui três níveis. O Nível 1 é uma autoavaliação gratuita baseada no questionário CAIQ, publicada em um registro público que qualquer pessoa pode consultar. O Nível 2 acrescenta uma avaliação independente realizada por terceiros, frequentemente conduzida em paralelo a um projeto de certificação ISO 27001 ou SOC 2 já em andamento. A CSA também descreve um Nível 3 baseado em auditoria contínua, mas os registros que você realmente encontrará são os do Nível 1 e do Nível 2.

O valor prático está no próprio registro. Se você estiver avaliando um provedor de nuvem que tenha publicado informações no STAR, as respostas do CAIQ estarão disponíveis publicamente, com detalhes suficientes para serem comparadas com o restante das evidências apresentadas. Basta lembrar que as respostas do Nível 1 são autodeclaradas.

9. NIST SP 800-53 (Versão 5.2.0)

O NIST publica esse documento como um catálogo de controles, e não como uma certificação, e ele constitui a base para as diretrizes do FedRAMP, além de servir de referência para diversos mapeamentos de controles do setor privado.

A versão 5.2.0 foi lançada em 27 de agosto de 2025, e todos os responsáveis pela aplicação de patches devem se familiarizar com ela. Emitida em resposta a uma ordem executiva federal sobre segurança de atualizações de software, ela incluiu um aprimoramento na análise da causa raiz para problemas e falhas do sistema, que abrange atualizações com falha (SI-02(07)), um aprimoramento na sintaxe de registro (SA-15(13)) e um novo controle de projeto de resiliência cibernética (SA-24).

A atualização trata o próprio fluxo de correções como uma superfície de ataque que deve ser protegida, e não apenas as vulnerabilidades que esse fluxo se destina a corrigir.

10. Estrutura de Segurança Cibernética 2.0 do NIST

O NIST também publica essa norma, e a versão 2.0 foi lançada em fevereiro de 2024. Trata-se de uma orientação voluntária, sem um processo de certificação e sem a necessidade de atender a um auditor.

CSF 2.0 acrescentou uma sexta função, Governar, além das cinco originais: Identificar, Proteger, Detectar, Responder e Recuperar. Também ampliou o escopo para além do foco em infraestruturas críticas que caracterizou a versão 1.1, e agora se destina a organizações de qualquer tamanho ou setor.

Pense nisso como o organograma do seu programa de segurança, com os controles detalhados das normas 800-53, CIS ou CCM mapeados abaixo dele. O CSF não é muito bom em indicar o que você deve configurar, mas é excelente em apontar o que você esqueceu de atribuir a um responsável.

11. FedRAMP

Administrado pelo PMO do FedRAMP, subordinado à GSA, o FedRAMP autoriza o uso de serviços em nuvem por órgãos federais dos EUA, e o ano de 2026 trouxe sua maior reformulação em anos.

O FedRAMP lançou as Regras Consolidadas para 2026 no final de junho. Elas entraram em vigor em 4 de julho de 2026, o que deu início a uma fase de adoção antecipada, e o FedRAMP 20x está previsto para substituir a Rev5 ao longo do tempo. O vocabulário mudou junto com a estrutura. “Autorização” passou a ser “Certificação FedRAMP”, os níveis de impacto deram lugar às classes de certificação de A a D, e os provedores não mantêm mais Planos de Ação e Marcos (POA&Ms). Em vez disso, eles mantêm registros de vulnerabilidades e uma lista de Pontos Fracos Aceitos, enquanto as agências ainda podem elaborar seus próprios POA&Ms para ações e decisões de risco de sua responsabilidade.

As datas relevantes dependem da sua situação atual. Se você já possui uma certificação Rev5, as Regras Consolidadas passam a ser obrigatórias em 1º de janeiro de 2027, embora alguns conjuntos de regras tenham suas próprias datas de vigência e períodos de carência, e o último desses períodos de carência termine em 1º de fevereiro de 2028. Se você ainda estiver planejando uma solicitação Rev5, o FedRAMP deixará de aceitar novas solicitações em 11 de junho de 2027 e, a partir dessa data, a única opção será a certificação 20x. Se sua documentação ainda indicar “FedRAMP Moderate ATO”, trata-se de terminologia da Rev5, e o prazo que se aplica a você é 1º de janeiro de 2027, quando as Regras Consolidadas passarão a ser obrigatórias. Ainda há tempo, mas não muito. 

A criptografia validada pela FIPS ainda é importante neste contexto, embora as novas regras restrinjam seu escopo. O FedRAMP agora exige que a criptografia FIPS 140 proteja dados confidenciais e deseja que os provedores documentem onde a utilizam, para que as agências possam avaliar se ela é adequada para seus próprios sistemas. No AlmaLinux, o TuxCare Enterprise Support fornece atualizações em conformidade com o FIPS para o conjunto completo de pacotes FIPS (kernel, OpenSSL, libgcrypt, NSS e GnuTLS) por meio das Atualizações de Segurança Estendidas para versões secundárias selecionadas. Tanto o AlmaLinux 9.2 quanto o 9.6 possuem certificados CMVP ativos para todos os cinco módulos, sendo que o mais recente foi emitido em agosto de 2026. 

12. Diretiva NIS2

NIS2, formalmente a Diretiva (UE) 2022/2555, funciona de maneira diferente de um regulamento, pois se trata de uma diretiva. A diretiva é vinculativa para os Estados-membros, mas as obrigações para as empresas só entram em vigor depois que cada Estado a transpõe para a legislação nacional, e esse processo tem ocorrido de forma desigual em todo o bloco.

O prazo para transposição era 17 de outubro de 2024. Em julho de 2026, a Comissão Europeia levou a Irlanda, a Espanha, a França e os Países Baixos ao Tribunal de Justiça da UE por não terem notificado a transposição completa e solicitou ao tribunal que impusesse sanções financeiras. A Holanda colocou em vigor sua Lei de Segurança Cibernética em 15 de agosto de 2026 e, em meados de setembro, a Irlanda, a Espanha e a França ainda estavam trabalhando nas respectivas leis. Como a NIS2 é uma diretiva, as obrigações das entidades privadas dependem da legislação nacional de transposição de cada Estado-Membro; portanto, verifique a legislação nacional aplicável em vez de presumir um efeito direto uniforme. A NIS2 exige que os Estados-Membros responsabilizem os órgãos de gestão nos termos da legislação nacional, e as normas nacionais devem permitir a aplicação de multas às entidades essenciais de, no mínimo, 10 milhões de euros ou 2% do faturamento anual mundial, o que for maior.

A NIS2 abrange entidades em 18 setores, incluindo provedores de computação em nuvem, serviços de data center e provedores de serviços de segurança gerenciados.

13. DORA

A Lei sobre Resiliência Operacional Digital, Regulamento (UE) 2022/2554, entrou em vigor em janeiro de 2023 e passou a ser plenamente aplicável em 17 de janeiro de 2025. As Autoridades de Supervisão Europeias coordenam sua implementação.

A DORA se aplica diretamente às entidades financeiras em toda a UE e se baseia em cinco pilares: gestão de riscos de TIC, notificação de incidentes, testes de resiliência operacional digital, gestão de riscos de terceiros em TIC e compartilhamento de informações.

O pilar dos terceiros é aquele que os provedores de nuvem tendem a ignorar. As entidades financeiras precisam incorporar os requisitos da DORA em seus contratos de TIC, e um provedor designado como prestador de serviços de TIC de importância crítica fica sob a supervisão direta de um Supervisor Líder indicado pelas ESAs. Isso significa que vender infraestrutura para bancos da UE pode colocá-lo no âmbito de aplicação da DORA, mesmo que você próprio não seja uma entidade financeira.

14. Padrões de Referência CIS e Controles CIS v8.1

O Centro de Segurança na Internet publica aqui dois recursos relacionados: os Controles, um conjunto priorizado de medidas de proteção, e os Padrões de Referência, que são diretrizes de configuração específicas para cada plataforma. Nenhum dos dois é certificável no sentido tradicional.

CIS Controls v8.1, lançado em junho de 2024, organiza 18 controles priorizados em três Grupos de Implementação com base no risco, nos recursos e na complexidade, de modo que uma equipe pequena e uma grande empresa não tenham que atender às mesmas expectativas iniciais. Os Benchmarks do CIS são a contrapartida no nível de configuração: guias de fortalecimento escritos para plataformas específicas, incluindo AWS Foundations, Azure Foundations, GCP, Kubernetes e principais distribuições do Linux.

Os benchmarks são o ponto em que os padrões deixam de ser abstratos e passam a indicar qual configuração você deve alterar. Muitas ferramentas de gerenciamento de postura na nuvem já vêm com verificações do CIS Benchmark prontas para uso, o que as torna um dos pontos de partida mais fáceis desta lista.

Para o AlmaLinux, o Suporte Empresarial da TuxCare inclui assistência para o fortalecimento da segurança, que mapeia os controles CIS e STIG para estruturas de conformidade, como PCI DSS e ISO 27001.

Melhores práticas para segurança na nuvem

As normas indicam o que deve ser comprovado. Essas cinco práticas mostram como as equipes, na prática, produzem essas evidências.

Avaliações periódicas de segurança

Realize avaliações em uma periodicidade definida, em vez de apenas quando um auditor entrar em contato. A periodicidade varia de acordo com a norma — algumas estabelecem ciclos anuais, outras são baseadas no risco, sem intervalo fixo. O Requisito 12.5.2 do PCI DSS acrescenta um exercício anual de confirmação do escopo, além da periodicidade que você escolher.

Os aspectos econômicos indicam que vale a pena continuar com isso. O Relatório da IBM sobre o Custo de uma Violação de Dados em 2026 estima o custo médio global de uma violação em US$ 4,99 milhões, um aumento de 12% e um novo recorde que reverte a breve queda registrada no ano anterior.

O desvio de escopo é o tipo de falha que merece atenção especial. Imagine uma equipe de SaaS com 40 pessoas que cria um ambiente de teste para uma migração, esquece de desativá-lo e o deixa fora dos limites avaliados por meses.

Se uma avaliação não identificar absolutamente nada, é provável que o escopo tenha sido definido de forma muito restrita. Se ela identificar as mesmas três falhas a cada trimestre, o problema está na responsabilidade pela correção, e não na detecção.

Análise de vulnerabilidades

Execute varreduras autenticadas a partir de dentro do ambiente, além de quaisquer varreduras externas. As varreduras externas não autenticadas não detectam vulnerabilidades no nível dos pacotes em cargas de trabalho em execução, que é onde, na verdade, se encontram muitas das vulnerabilidades exploráveis.

A frequência mínima varia bastante de acordo com a norma. O PCI DSS exige varreduras internas e externas a cada três meses e após qualquer alteração significativa, e as varreduras externas exigidas devem ser realizadas por um Provedor de Varredura Aprovado. As normas técnicas da DORA exigem varreduras automatizadas de vulnerabilidades pelo menos uma vez por semana nos ativos de TIC que suportam funções críticas ou importantes, testes anuais dos sistemas por trás dessas funções e testes de penetração orientados por ameaças pelo menos a cada três anos para as entidades designadas por seus órgãos reguladores. A atualização proposta para a HIPAA exigiria varreduras automatizadas pelo menos a cada seis meses e testes de penetração pelo menos uma vez por ano. Os Controles CIS v8.1 exigem varreduras automatizadas de ativos internos pelo menos trimestralmente (Medida de Proteção 7.5) e de ativos expostos externamente pelo menos mensalmente (Medida de Proteção 7.6). A NIS2 mantém uma abordagem baseada no risco e deixa os detalhes a cargo de cada Estado-membro.

Comparar os resultados com o catálogo de vulnerabilidades exploradas conhecidas da CISA antes de priorizar a correção. Uma pontuação CVSS por si só fará com que uma vulnerabilidade de 7,5 que está sendo explorada ativamente fique enterrada sob uma pilha de pontuações teóricas de 9,8 sem exploração conhecida.

As regras de cadência acima pressupõem que um scanner relate com precisão o que já foi corrigido; no entanto, no Linux, essa suposição costuma falhar. As distribuições fazem o backport de correções de segurança sem alterar o número da versão do upstream, e um patch aplicado na memória sem a necessidade de reinicialização pode nem mesmo aparecer em uma verificação da versão do pacote. O TuxCare Radar verifica o status real dos patches, incluindo patches que não exigem reinicialização e correções cobertas pelo ELS que uma simples verificação de versão deixaria de detectar; assim, um ciclo de varredura não se transforma em uma reconciliação manual entre o que o scanner indica e o que seus registros de patches mostram.

Controles de acesso rigorosos

Exigir a autenticação multifatorial em todas as contas de usuários com acesso ao console, sem exceções para proprietários de serviços ou prestadores de serviços. A norma PCI DSS v4.x estendeu a autenticação multifatorial (MFA) além dos administradores para todos os acessos ao ambiente de dados dos titulares de cartões, com uma exceção restrita para contas que utilizam autenticação resistente a phishing, e a atualização proposta da HIPAA segue a mesma linha.

Além do MFA, defina como padrão o acesso baseado em funções e no princípio do privilégio mínimo, e revise-o pelo menos trimestralmente. Mantenha as identidades humanas e das máquinas separadas, sem que credenciais compartilhadas de contas de serviço permaneçam nos pipelines de CI. Opte por credenciais de curta duração em vez de chaves de API de longa duração, sempre que o provedor oferecer suporte a elas. E documente seu processo de admissão, transferência e desligamento, pois os auditores costumam fazer amostragens desse processo.

Criptografia de dados

Criptografar dados em repouso e em trânsito deve ser considerado uma expectativa básica. O gerenciamento de chaves é o ponto em que as auditorias costumam apresentar falhas: quem detém as chaves, com que frequência elas são renovadas e se é possível demonstrar exatamente o que o provedor pode ou não descriptografar.

Para cargas de trabalho regulamentadas, a implementação é tão importante quanto a própria escolha do algoritmo. Os sistemas federais dos EUA geralmente exigem módulos criptográficos validados pela norma FIPS 140-3 sempre que a criptografia aprovada é obrigatória, e os contratos comerciais também os exigem cada vez mais. O TLS 1.2 é o mínimo exigido, e o TLS 1.3 é a meta, sempre que sua pilha de tecnologia for compatível com ele.

Atenção: A criptografia em repouso com chaves gerenciadas pelo provedor atende a muitos requisitos de conformidade, mas o que ela realmente protege é contra a exposição na camada de armazenamento, como um disco roubado ou mídia descartada de forma inadequada. Ela não oferece nenhuma proteção contra uma credencial comprometida dentro da sua própria conta que tenha permissão para descriptografar. Os auditores raramente insistem nessa distinção. Os invasores exploram isso rotineiramente.

Aplicações regulares de patches e atualizações

É nesse ponto que a maioria dos programas de conformidade em nuvem fracassa discretamente. Os controles parecem simples no papel, mas se mostram difíceis de aplicar na prática, pois aplicar patches em um kernel de produção geralmente implica uma reinicialização, e uma reinicialização implica negociar uma janela de manutenção com todos aqueles que dependem desse tempo de atividade.

O relógio é explicitamente mencionado em várias normas:

Um prazo de 30 dias parece generoso até você levar em conta as etapas reais envolvidas: triagem, teste, agendamento, notificação, reinicialização, verificação e documentação. Em uma frota de algumas centenas de hosts com SLAs de tempo de atividade a serem cumpridos, isso pode consumir a maior parte do mês antes mesmo que o patch chegue ao ambiente de produção.

Considerações finais

Escolha suas normas primeiro com base nas obrigações legais e, em seguida, na demanda dos clientes, e pare por aí. Implementar as normas ISO 27001, SOC 2 e CSA STAR ao mesmo tempo só porque a página de confiança de um concorrente lista todas as três é o que faz com que equipes de segurança de pequeno porte desperdicem um ano inteiro com documentação, em vez de se dedicarem aos controles.

Há um aspecto que permanece constante, independentemente das normas que se aplicam a você. Quase todas elas exigem que você identifique e corrija vulnerabilidades conhecidas, além de ter evidências que possam ser apresentadas quando solicitado. O tipo de certificação varia. A forma de fiscalização também varia. Mas, na maioria desses programas, é nas operações de aplicação de patches que essas evidências são apresentadas dentro do prazo ou deixam a desejar.

Suporte contínuo ao longo do ciclo de vida garante que as atualizações de segurança continuem sendo fornecidas para sistemas operacionais, ambientes de execução de linguagens e bibliotecas em fim de vida útil, mesmo após o término do suporte do fornecedor, de modo que um componente sem suporte possa continuar recebendo correções, em vez de se tornar uma lacuna de conformidade permanente. Para as dependências de código aberto utilizadas por suas cargas de trabalho na nuvem, o SecureChain oferece às equipes registros privados filtrados para pacotes em JavaScript, Python, Java, Go, Rust e PHP, o que dá suporte ao tipo de controle da cadeia de suprimentos descrito nas normas ISO/IEC 27017 e CCM v4.1. O TuxCare Enterprise Support abrange a criptografia validada pela FIPS e o fortalecimento de conformidade que ambientes federais e outros regulamentados frequentemente exigem. E o o KernelCare aplica patches no kernel sem a necessidade de reinicialização, de modo que o cumprimento dos prazos estabelecidos pela PCI DSS e normas semelhantes não depende da aprovação de uma janela de manutenção. Você continua testando, verificando e documentando como faria com qualquer outro patch, mas a reinicialização é eliminada da programação.

Tem dúvidas sobre quais dessas normas se aplicam ao seu ambiente ou onde exatamente estão as lacunas nas evidências do seu programa de conformidade? Fale com um especialista em segurança da TuxCare.

Resumo

Nome do artigo

As 14 principais estruturas de padrões de segurança em nuvem em 2026

Descrição

ISO 27017, SOC 2, FedRAMP, NIS2, DORA e outras. O que cada norma de segurança em nuvem exige de você em 2026 e como ela é efetivamente aplicada.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora