Nuvem e contêineres: responsabilidade compartilhada, CSPM/CASB, K8s RBAC, secrets

A ideia que organiza o assunto

Aviso sobre o tamanho desta base. Este tópico tem um único item no corpus. O título promete quatro assuntos — responsabilidade compartilhada, CSPM e CASB, RBAC do Kubernetes e gestão de segredos —, e apenas o primeiro é cobrado; CSPM, CASB, RBAC do Kubernetes e segredos não aparecem em nenhum item. Não há frequência a medir aqui, e nada nesta nota deve ser lido como padrão observado. O grosso do material de nuvem que realmente cai neste concurso está no tópico de características, modelos de serviço e regiões, com 106 itens.

Dito isso, o único item existente testa exatamente a régua que resolve quase todo item de segurança em nuvem, e vale aprendê-la bem: quem controla o recurso responde por ele.

O provedor controla o prédio, a energia, o hardware, o hipervisor e a rede que liga tudo — logo responde pela segurança da nuvem. O cliente controla o que põe lá dentro: os dados, a classificação deles, quem tem acesso, como as coisas estão configuradas — logo responde pela segurança na nuvem. Nada disso é negociável por contrato genérico; decorre de quem tem a mão no recurso.

O que muda entre IaaS, PaaS e SaaS não é a régua, é onde cai a fronteira: quanto mais o provedor gerencia (sistema operacional, tempo de execução, aplicação), mais para cima a linha sobe. Mas três coisas ficam do lado do cliente em qualquer modelo: os dados, as identidades e a configuração. É por isso que a maior parte dos incidentes de nuvem é de configuração errada, e por isso a nuvem nunca é “segura por padrão” para quem a usa mal.

Como funciona

A divisão pelo controle. Em IaaS o provedor entrega a infraestrutura virtual pronta e segura — datacenter, hardware, virtualização, rede física — e o cliente assume tudo daí para cima: sistema operacional convidado, correções, firewall da instância, rede virtual, aplicação, dados. Em PaaS o provedor absorve também o sistema operacional e o tempo de execução; o cliente fica com o código, a configuração da plataforma, os dados e os acessos. Em SaaS o provedor opera a aplicação inteira, e ao cliente restam os dados, as identidades, as permissões e as configurações de compartilhamento — que é, justamente, onde os vazamentos de SaaS acontecem.

Privacidade não se terceiriza. Quando o cliente é controlador de dados pessoais, é ele quem decide o que é coletado, para qual finalidade e por quanto tempo — e responde por isso mesmo operando sobre infraestrutura de terceiro. O provedor, na posição de operador, responde por proteger a infraestrutura onde esses dados são armazenados, processados e transportados, o que inclui a proteção da comunicação dentro do seu domínio. Inverter essas duas metades — dar ao provedor a decisão sobre coleta e processamento, ou jogar sobre o usuário a proteção do canal que corre na infraestrutura alheia — é o erro do único item do tópico.

O que o provedor deve, além do mínimo. Nenhuma descrição que reduza o dever do provedor a uma ou duas atividades sobrevive: segurança física, isolamento entre locatários, gestão do hipervisor, disponibilidade da rede, cifragem em repouso e em trânsito oferecida como serviço, registro de auditoria e notificação de incidentes compõem o pacote. É por isso que a palavra apenas aplicada ao provedor costuma marcar item errado.

O que decide os itens

Segurança da nuvem × segurança na nuvem:

provedor — segurança da nuvem	cliente — segurança na nuvem
instalações, energia, refrigeração	dados e sua classificação
hardware e hipervisor	identidades, permissões, chaves
rede física e isolamento entre locatários	configuração dos serviços contratados
disponibilidade e resiliência da plataforma	quem coleta o quê, com que finalidade
proteção do transporte na sua infraestrutura	cifragem ponta a ponta da própria aplicação

Onde cai a fronteira, por modelo:

responsável por	IaaS	PaaS	SaaS
infraestrutura física e virtualização	provedor	provedor	provedor
sistema operacional e correções	cliente	provedor	provedor
tempo de execução e middleware	cliente	provedor	provedor
aplicação	cliente	cliente	provedor
dados, identidades e configuração	cliente	cliente	cliente

A régua única — pergunte quem controla o recurso. Quem controla responde. Dado, identidade e configuração são sempre do cliente; instalação física, hipervisor e rede física são sempre do provedor.

Controlador × operador — quem decide a finalidade e os meios do tratamento é controlador e não deixa de sê-lo por contratar nuvem; o provedor que trata em nome dele é operador. A responsabilidade pela privacidade acompanha a decisão, não a máquina.

Como a CEBRASPE derruba você aqui

Esta seção não é uma medição. O tópico tem um item, e uma frequência de um não é frequência. O que segue combina o único padrão observado com traps conhecidos do assunto, cada um rotulado.

Inversão das duas metades da responsabilidade — o único padrão observado (1 de 1 item). O item transfere ao provedor o que é decisão do cliente e ao cliente o que corre na infraestrutura do provedor: “sendo os provedores de nuvem, nesse caso, responsáveis apenas por proteger a coleta e o processamento de dados”. Repare que a frase reúne dois vícios: o apenas, que estreita indevidamente o dever do provedor, e a troca de lados. A defesa é aplicar a régua item a item, recurso a recurso, em vez de julgar a frase pelo tom.

Fixar a fronteira no modelo errado — conhecido, ainda não medido neste tópico. Itens que dão ao provedor o sistema operacional em IaaS, ou ao cliente a aplicação em SaaS, deslocam a linha um degrau. Guarde os dois extremos e interpole: em IaaS o cliente começa no sistema operacional; em SaaS o cliente termina nos dados e nos acessos.

Absolutizar um dos lados — conhecido, ainda não medido neste tópico. Toda a infraestrutura, apenas, exclusivamente, integralmente responsável: o modelo é compartilhado por definição, e qualquer frase que entregue o conjunto a um só lado tende a estar errada.

Confundir o que a nuvem entrega com o que ela garante — conhecido, ainda não medido neste tópico. O provedor oferece cifragem, registro, segmentação e autenticação forte; ativá-los e configurá-los corretamente é do cliente. Recurso disponível não é recurso aplicado.

Erros clássicos

Achar que contratar nuvem transfere a responsabilidade. Ela se divide conforme o controle. O que se terceiriza é a execução, nunca a prestação de contas — especialmente perante a lei de proteção de dados, em que o controlador segue sendo o cliente.

Dar ao provedor a decisão sobre coleta e processamento. Quem decide o que coletar, com que finalidade e por quanto tempo é quem opera o serviço, não quem o hospeda.

Supor que o dado está protegido porque o provedor é certificado. Certificação atesta os controles do provedor sobre a parte dele. Um bucket aberto por configuração do cliente vaza com a mesma facilidade em um provedor certificado.

Tratar a fronteira como fixa entre os modelos. Ela sobe de IaaS para SaaS. O que não muda é a base: dados, identidades e configuração ficam sempre com o cliente.