Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- A segurança na nuvem consiste nos controles, políticas e ferramentas que protegem dados, aplicativos e infraestrutura na nuvem.
- A responsabilidade compartilhada divide as tarefas de segurança entre você e o provedor, e essa divisão varia de acordo com o modelo de serviço.
- No IaaS, o sistema operacional convidado e suas atualizações são de sua responsabilidade, e não do provedor.
Os provedores de nuvem operam os centros de dados, o hardware e a camada de virtualização na qual suas cargas de trabalho estão hospedadas. Além disso, tudo depende do modelo de serviço. Na IaaS, o sistema operacional convidado, as contas de usuário e os dados armazenados ficam todos do seu lado da linha, e essa linha se desloca à medida que você migra para plataformas gerenciadas e SaaS.
É nessa linha dinâmica que tendem a surgir brechas de segurança. É fácil presumir que o provedor se encarrega de um tarefa de correção ou de configuração que, na verdade, é de sua responsabilidade.
O que é segurança na nuvem?
A segurança na nuvem é a combinação de controles, políticas e ferramentas que protegem dados, aplicativos e infraestrutura em execução em ambientes de nuvem. Ela abrange as camadas de identidade, rede, carga de trabalho e dados, e se aplica independentemente de você executar máquinas virtuais, plataformas gerenciadas ou software fornecido por um fornecedor.
Às vezes, você verá a expressão “segurança baseada em nuvem” sendo usada para ferramentas de segurança que, por sua vez, são fornecidas a partir da nuvem. Nesse contexto, o termo abrange a função mais ampla de proteger o que é executado na nuvem, incluindo até mesmo os servidores Linux que suportam grande parte dessas cargas de trabalho.
Isso é importante porque uma única configuração incorreta, uma conta com permissões excessivas ou um servidor sem patches pode expor dados ou deixar um serviço fora do ar. Alguns desses riscos permanecem independentemente do modelo de serviço escolhido, conforme mostra a matriz abaixo.
O que é o modelo de responsabilidade compartilhada na segurança na nuvem?
O modelo de responsabilidade compartilhada define quais tarefas de segurança são de responsabilidade do provedor de nuvem e quais são de sua responsabilidade. Um equívoco comum é achar que o provedor se responsabiliza pela segurança de tudo o que hospeda. Na prática, essa divisão varia de acordo com o modelo de serviço e pode mudar de um serviço para outro.
A AWS, a Microsoft e o Google abordam o assunto de maneiras ligeiramente diferentes. A Microsoft publica uma matriz por modelo de serviço. A AWS separa a segurança “da” nuvem — ou seja, a infraestrutura do provedor — da segurança “na” nuvem — ou seja, tudo o que você coloca nela. O Google vai um passo além com o que chama de “destino compartilhado”, em que o provedor assume um papel mais ativo para ajudar os clientes a alcançarem uma configuração segura. A própria Microsoft descreve sua matriz como uma orientação ilustrativa que não altera os termos do seu contrato; portanto, considere qualquer um desses modelos como um guia e verifique seu contrato e a documentação do serviço específico que você utiliza.
Como a responsabilidade se distribui entre IaaS, PaaS e SaaS
Os serviços em nuvem se enquadram em três modelos de serviço: infraestrutura como serviço (IaaS), plataforma como serviço (PaaS) e software como serviço (SaaS). Quanto mais partes da pilha o provedor gerencia, menos você precisa lidar diretamente; no entanto, algumas responsabilidades permanecem a seu cargo nos três modelos. A matriz atual da Microsoft, adaptada a seguir, mostra como o trabalho se divide.
| Área de responsabilidade | IaaS | PaaS | SaaS |
| Dados do cliente | Você | Você | Você |
| Configurações e ajustes | Você | Você | Você |
| Identidades e usuários | Você | Você | Você |
| Dispositivos clientes | Você | Você | Compartilhado |
| Aplicações | Você | Compartilhado | Compartilhado |
| Controles de rede | Você | Compartilhado | Provedor |
| Sistema operacional | Você | Provedor | Provedor |
| Servidores físicos, rede e data center | Provedor | Provedor | Provedor |
Fonte: Microsoft Learn, “Responsabilidade compartilhada na nuvem”. Adaptado: “Cliente” e “Microsoft” aparecem como “Você” e “Provedor”, a coluna “local” foi omitida e as linhas referentes a hosts físicos, rede e data center foram combinadas em uma única.
A Microsoft também lista quatro responsabilidades que permanecem a seu cargo, independentemente do modelo de serviço: dados, terminais, contas e gerenciamento de acesso. Os dispositivos clientes aparecem como “Compartilhados” no SaaS porque a Microsoft pode ajudar a gerenciá-los nesse modelo, mas proteger esses terminais continua sendo sua responsabilidade.
Infraestrutura como Serviço (IaaS)
Com o IaaS, você aluga recursos de computação, armazenamento e rede, como o Amazon EC2, o Azure Virtual Machines ou o Google Compute Engine. O provedor é responsável pela infraestrutura física e pela camada de virtualização. Você se encarrega do sistema operacional convidado (SO convidado), dos softwares instalados e da configuração de rede.
A AWS deixa isso bem claro. Os clientes que implantam uma instância EC2 são responsáveis pelo “gerenciamento do sistema operacional convidado (incluindo atualizações e patches de segurança)”, além de qualquer software que instalem e da configuração do grupo de segurança em cada instância. A AWS também lista o gerenciamento de patches como um controle compartilhado: a AWS aplica patches na infraestrutura, e os clientes aplicam patches em seus sistemas operacionais convidados e aplicativos. A matriz da Microsoft concorda com isso para IaaS e atribui a responsabilidade pelo sistema operacional a você.
Plataforma como Serviço (PaaS)
Plataformas gerenciadas, como o Azure App Service, o Azure Functions e o Azure SQL Database — que a Microsoft classifica como PaaS —, transferem uma parte maior do trabalho para o provedor. O provedor fica responsável pelo sistema operacional, pelo ambiente de execução e pelo middleware. Os controles de aplicativos e de rede passam a ser compartilhados. Você fica responsável pela configuração do aplicativo, pela segurança do código, pelos controles de acesso e pelas bibliotecas que inclui na sua implantação.
As versões de tempo de execução também são descontinuadas de acordo com cronogramas publicados e, quando isso acontece, o trabalho de migração recai sobre você.
Software como Serviço (SaaS)
O SaaS, como o Microsoft 365 ou o Dynamics 365, transfere para o provedor praticamente toda a pilha de tecnologia. O Google explica da seguinte forma: no SaaS, o provedor assume a maior parte das responsabilidades de segurança, e você continua sendo responsável por seus controles de acesso e pelos dados que decidir armazenar. A Microsoft trata os dispositivos clientes como uma área compartilhada nesse contexto. Ela pode oferecer alguns recursos de gerenciamento de dispositivos, mas a proteção dos terminais e a conformidade continuam sendo de sua responsabilidade.
Quais são as responsabilidades dos provedores de nuvem
Os provedores lidam com as camadas mais próximas do hardware. A documentação da Microsoft divide sua parte em algumas áreas, e a AWS estabelece uma divisão semelhante.
Infraestrutura física
A segurança do data center é de responsabilidade do provedor: instalações, controles de acesso físico e controles ambientais, além dos servidores físicos que hospedam suas cargas de trabalho.
Fundamentos de Redes
Os roteadores, switches e o cabeamento dentro do data center são de responsabilidade do provedor. No PaaS, a Microsoft fornece uma base de segurança de rede, e no SaaS ela gerencia a segurança de rede. Regras de firewall e segmentação para suas próprias instâncias permanecem sob seu controle no IaaS.
Virtualização e camadas de host
O hipervisor e o sistema operacional do host também pertencem ao provedor. A AWS descreve que sua parte da responsabilidade abrange desde o sistema operacional do host e a camada de virtualização até a segurança física das instalações, o que deixa o sistema operacional convidado fora desse escopo.
Documentação de conformidade
A AWS, a Microsoft e o Google Cloud publicam, cada uma, documentação de conformidade. A AWS afirma que os clientes podem utilizar sua documentação de controles e conformidade para realizar suas próprias avaliações e verificações de controles. Além disso, indica aos clientes documentos de atestado de auditoria de terceiros para que possam determinar quais controles já estão em vigor e quais ainda precisam ser implementados. A Microsoft publica relatórios de auditoria por meio de seu Portal de Confiança de Serviços, e o Google Cloud oferece relatórios de auditoria e certificações por meio do seu Gerenciador de Relatórios de Conformidade. Alguns recursos da Microsoft e do Google exigem que você faça login, e certos materiais são compartilhados sob termos de confidencialidade.
Quais são as responsabilidades das organizações?
No IaaS, você é responsável pela maior parte da pilha. Isso começa com a aplicação de patches no sistema operacional convidado e no kernel de cada instância, incluindo aquelas iniciadas a partir de imagens antigas, e se estende aos aplicativos que você executa e às bibliotecas que eles utilizam, mesmo aquelas que você nunca escolheu diretamente.
Você também configura a rede. Na IaaS, isso significa grupos de segurança, regras de firewall e segmentação. Na PaaS, significa controles de rede no nível do aplicativo. O registro de logs e o monitoramento também ficam a seu cargo. No Google Cloud, por exemplo, os logs de auditoria de acesso a dados estão desativados por padrão para todos os serviços, exceto alguns do BigQuery; portanto, para a maioria dos serviços, você não os terá até que os ative.
O backup e a recuperação variam de acordo com o serviço. No Amazon EC2, você mesmo configura instantâneos ou políticas de backup para seus volumes, por meio de ferramentas como o AWS Backup ou o Amazon Data Lifecycle Manager. O Amazon RDS ativa os backups automatizados por padrão, mas cabe a você decidir por quanto tempo eles serão mantidos.
Para conhecer práticas seguras de desenvolvimento e implantação, consulte nosso guia sobre melhores práticas de segurança de software.
Tipos de medidas de segurança na nuvem
Estruturas de segurança na nuvem geralmente abrangem áreas como as cinco abaixo.
Gerenciamento de Identidade e Acesso
Funções, políticas, contas de serviço e federação costumam determinar o que uma credencial comprometida pode acessar. Privilégio mínimo, autenticação multifatorial em contas de usuários e a rotação regular (ou remoção definitiva) de chaves estáticas, tudo isso restringe esse alcance. Contas de serviço criadas para tarefas pontuais devem passar por uma revisão periódica, e tudo o que não for mais necessário deve ser eliminado.
Proteção de dados e criptografia
Primeiro, classifique os dados por nível de confidencialidade e, em seguida, decida quem ficará responsável pelas chaves. As chaves gerenciadas pelo provedor são mais simples de administrar, enquanto as chaves gerenciadas pelo cliente oferecem maior controle sobre a rotação e a revogação. Seja qual for a sua escolha, registre quais conjuntos de dados utilizam cada tipo de chave.
Controles e segmentação de rede
Grupos de segurança, ACLs de rede, pontos de extremidade privados e perímetros de serviço controlam quais sistemas podem se comunicar entre si. A segmentação limita até onde uma carga de trabalho comprometida pode se espalhar, e a filtragem do tráfego de saída limita a quais recursos essa carga de trabalho pode acessar externamente.
Carga de trabalho e aplicação de patches no sistema operacional convidado
Na IaaS, a aplicação de patches é uma das tarefas recorrentes mais complexas que você realiza. O Linux é amplamente utilizado em servidores de nuvem e de hospedagem, e uma atualização do kernel tradicionalmente exige a reinicialização da instância. Em um grande parque de servidores, encontrar uma janela de manutenção para cada reinicialização pode atrasar a aplicação dos patches.
Os provedores oferecem ferramentas para isso. O AWS Systems Manager Patch Manager, a aplicação automática de patches no sistema operacional convidado das VMs do Azure e o Google Cloud VM Manager Patch podem automatizar a aplicação de patches no sistema operacional convidado de suas instâncias. Cada um deles pode reiniciar a instância como parte do processo e cada um tem seu próprio escopo. A aplicação automática de patches do Azure, por exemplo, abrange apenas patches classificados como “Críticos” ou “de Segurança”. De qualquer forma, o próprio sistema operacional convidado permanece sob sua responsabilidade na IaaS.
Correção dinâmica segue um caminho diferente e aplica correções de segurança do kernel a um sistema em execução. Algumas distribuições e provedores oferecem suas próprias soluções de correção dinâmica para plataformas selecionadas; assim, um parque de máquinas que mistura distribuições pode acabar tendo que lidar com várias ferramentas. O KernelCare oferece correção dinâmica do kernel do Linux para mais de 70 versões de distribuições Linux, permitindo que você corrija vulnerabilidades do kernel em servidores de nuvem e de hospedagem em execução sem precisar agendar uma reinicialização.
Registro e monitoramento
Serviços como o AWS CloudTrail, o Azure Monitor e o Google Cloud Audit Logs registram as atividades em seu ambiente. O envio de logs para uma conta ou projeto separado dificulta que uma violação em um ambiente apague sua própria trilha de auditoria, especialmente quando o acesso ao destino é rigidamente restrito. Auditorias de segurança regulares auditorias de segurança ajudam a confirmar se os logs abrangem o que você precisa.
Como as ameaças comuns à nuvem se relacionam com suas responsabilidades
As ameaças na nuvem tendem a seguir o princípio da responsabilidade compartilhada, o que facilita identificar aquelas em relação às quais você pode tomar medidas. De acordo com matriz da Microsoft, configurações incorretas e identidades comprometidas são de sua responsabilidade nos três modelos de serviço. As vulnerabilidades do sistema operacional são de sua responsabilidade no IaaS e passam a ser do provedor no PaaS e no SaaS. Se você criar e distribuir suas próprias imagens de contêiner e dependências, elas continuarão sendo de sua responsabilidade, independentemente da plataforma em que forem executadas. Nossa publicação sobre ameaças à segurança na nuvem aborda cada categoria em profundidade.
Sistemas sem patches e em fim de vida útil seguem a mesma regra na IaaS, onde a manutenção do sistema operacional é de sua responsabilidade. Uma instância na nuvem pode continuar em funcionamento por anos com uma imagem criada há muito tempo. Quando sua distribuição Linux, ambiente de execução ou framework chega ao fim de vida útil, o fornecedor deixa de publicar atualizações de segurança; no entanto, a carga de trabalho geralmente continua atendendo ao tráfego enquanto a migração é planejada. O Endless Lifecycle Support (ELS) da TuxCare fornece patches de segurança para distribuições Linux, ambientes de execução, frameworks e aplicativos em fim de vida útil após o término do suporte padrão dos fornecedores, o que lhe dá margem para migrar no seu próprio ritmo.
Desafios comuns relacionados à responsabilidade compartilhada
A fila avança a cada atendimento
Em um serviço gerenciado do Kubernetes, o provedor opera o plano de controle, e o que acontece com os nós de trabalho depende da opção que você escolher. No Amazon EKS, a AWS assume mais responsabilidades à medida que você passa de nós autogerenciados para grupos de nós gerenciados e, por fim, para o Fargate. Mesmo com grupos de nós gerenciados, você ainda precisa iniciar a atualização para uma versão mais recente da AMI, e o EKS então a implementa em todos os seus nós. Um modelo baseado em um serviço pode induzir você ao erro em relação ao próximo, portanto, verifique a documentação sobre as responsabilidades de cada serviço.
A aplicação de correções pode ficar a cargo de equipes diferentes
Se a equipe de engenharia de plataforma é responsável pela estrutura de contas, as equipes de aplicativos são responsáveis por suas próprias implantações e a equipe de segurança é responsável pelas políticas, a aplicação de patches no sistema operacional convidado pode ficar a cargo de qualquer uma dessas três equipes. Indique um responsável. Uma pergunta útil para sua próxima revisão é: quem aplicou o patch no kernel da instância de produção mais antiga e quando isso ocorreu?
Casos esquecidos são fáceis de deixar passar despercebidos
Uma instância que nunca foi incluída no seu inventário de ativos também não aparecerá nos seus relatórios de patch. Comparar esse inventário com suas listas de recursos na nuvem e dados de faturamento pode revelar sistemas que nenhuma equipe reivindicou.
Dicas de segurança na nuvem para 2026
Leia a documentação de responsabilidades de um novo serviço antes de implantá-lo, e não depois. Aplique patches no sistema operacional convidado e patches no kernel em cada ambiente de IaaS. Reforce a segurança de identidade com o princípio do privilégio mínimo, autenticação multifatorial e rotação regular de credenciais estáticas, e decida quem detém as chaves de criptografia para cada conjunto de dados (e anote isso).
No âmbito operacional, envie os registros de sistema para uma conta ou projeto separado e verifique se os alertas chegam a uma pessoa. Planeje sistemas que tenham vida útil superior ao suporte do fornecedor, incluindo ambientes de execução e imagens base. E elabore seu fluxo de trabalho de resposta a incidentes antes de precisar dele, pois o meio de um incidente não é o momento certo para começar.
Execute ambientes seguros com a TuxCare
No IaaS, o provedor garante a segurança da infraestrutura, e o sistema operacional convidado em cada instância permanece sob a responsabilidade da sua equipe. As dependências de código aberto que você incorpora ao seu próprio software também são de sua propriedade, independentemente de onde ele seja executado. Suporte contínuo ao longo do ciclo de vida fornece patches de segurança para distribuições Linux, ambientes de execução, frameworks e aplicativos em fim de vida útil, para que a migração possa seguir seu cronograma, em vez do prazo imposto pelo fornecedor. O SecureChain oferece às suas compilações pacotes de código aberto verificados, analisados contra malware e continuamente atualizados para JavaScript, Python, Java, Go, Rust e PHP. E O KernelCare aplica patches de segurança do kernel a servidores Linux em execução sem a necessidade de reinicialização, de modo que as correções do kernel não precisam esperar por uma janela de manutenção.
Para saber como a aplicação de patches se encaixa em uma rotina mais ampla de nuvem, leia nosso guia sobre gerenciamento de patches na nuvem.
