O caso
A nuvem era segura. A planilha de clientes ficou pública.
O Isaac guardou a planilha de clientes da loja num armazenamento na nuvem e, para um parceiro baixar o arquivo mais rápido, liberou o acesso a qualquer pessoa com o link. Semanas depois, os dados dos clientes apareceram num fórum.
O data center do provedor nunca foi invadido. A porta que ficou aberta era dele.
Este post parte de Fundamentos da Nuvem e de Modelos de Serviço na Nuvem.
O problema
Nuvem segura não é dado seguro
Os provedores gastam em segurança muito mais do que uma loja pequena conseguiria: guardas, câmeras, energia redundante, equipes dedicadas, hardware trocado antes de falhar. Isso não impede que o Isaac exponha os próprios dados com uma configuração errada.
A maior parte dos vazamentos na nuvem vem de configuração e acesso, e não de ataque à infraestrutura do provedor.
A solução
Responsabilidade compartilhada
Todo provedor trabalha com o mesmo princípio, o modelo de responsabilidade compartilhada (shared responsibility model). Ele divide a segurança em duas partes:
- Segurança da nuvem (security of the cloud): é do provedor. Inclui o prédio, o hardware, a rede global e a virtualização.
- Segurança na nuvem (security in the cloud): é sua. Inclui os dados que você coloca lá, quem pode acessá-los e como você configura os serviços.
A linha entre as duas partes é a mesma da pilha de Modelos de Serviço: quanto mais gerenciado o serviço, mais camadas o provedor assume. Só que duas camadas nunca saem das suas mãos: os dados e as contas de acesso.
Cada provedor desenha o seu próprio quadro, com mais ou menos linhas. A lógica é a mesma: o que fica sob o seu controle fica sob a sua responsabilidade.
Acessos
Quem pode fazer o quê
Como os acessos são seus, a nuvem traz um serviço só para eles: o IAM (Identity and Access Management, gerenciamento de identidades e acessos). Ele responde a duas perguntas: quem é você e o que você pode fazer.
- Identidade (identity): um usuário, um grupo ou uma aplicação que precisa acessar algo.
- Política (policy): a regra que diz quais ações essa identidade pode fazer, em quais recursos.
- Papel (role): um conjunto de permissões que se atribui a uma identidade, em vez de dar permissões uma a uma.
| AWS | Azure | Google Cloud | Oracle Cloud | |
|---|---|---|---|---|
| Serviço de acessos | IAM | Microsoft Entra ID e Azure RBAC | IAM | OCI IAM |
Menor privilégio (least privilege)
Dê a cada pessoa e a cada aplicação só as permissões de que precisam, e só pelo tempo necessário.
Na loja: o parceiro que baixa a planilha só pode ler aquele arquivo.
Autenticação multifator (multi-factor authentication, MFA)
Além da senha, um segundo fator: um código no celular, uma chave física. Uma senha vazada deixa de bastar.
Na loja: o painel da nuvem pede senha e código.
Conta raiz guardada (root account)
A conta que criou tudo tem poder total. Proteja-a com MFA e use contas comuns no dia a dia.
Na loja: só o Isaac sabe a senha da conta raiz, e ele quase não a usa.
Credenciais temporárias (temporary credentials)
Chaves de acesso que não expiram vazam e ficam esquecidas. Prefira credenciais que valem por pouco tempo.
Na loja: o sistema de pedidos recebe um papel, em vez de uma chave colada no código.
Não confunda
Autenticação × autorização
Dois termos que as provas adoram trocar. Os dois acontecem em sequência, e cada um responde a uma pergunta diferente.
Autenticação (authentication)
“Você é quem diz ser?”
- Exemplo
- Entrar no painel com senha e código do celular.
- Foco
- Provar a identidade.
Autorização (authorization)
“O que você pode fazer?”
- Exemplo
- Poder ler os arquivos, mas não apagá-los.
- Foco
- Definir as permissões depois de identificado.
Na prática
O que fazer em cada situação
| Situação | O que fazer |
|---|---|
| Um parceiro precisa baixar um arquivo | Dar permissão de leitura só nesse arquivo, e por tempo limitado |
| Um serviço precisa chamar outro | Atribuir um papel ao serviço, sem chave fixa no código |
| A conta raiz foi usada no dia a dia | Criar contas comuns, ativar MFA na raiz e guardá-la |
| Uma pessoa mudou de função | Rever as permissões dela, em vez de somar as novas às antigas |
Termos-chave
Seis termos para fixar
Toque no cartão para ver a definição.
Teste rápido
Três perguntas, estilo prova
01
Uma empresa usa um software SaaS. Quem é responsável pelos dados que ela guarda nele?
02
Um desenvolvedor só precisa ler arquivos de um armazenamento. Qual permissão aplica o menor privilégio?
03
Qual destas responsabilidades é do provedor em qualquer modelo de serviço?
A pergunta de prova sobre segurança costuma ser a mesma: de quem é a responsabilidade? A resposta segue a pilha. O provedor assume as camadas mais baixas, e você nunca se livra dos dados nem dos acessos. Com o IAM, o menor privilégio e o MFA bem configurados, a maior parte dos vazamentos como o do Isaac deixa de acontecer. O próximo passo da trilha é Armazenamento na Nuvem.