O modelo de responsabilidade compartilhada

De quem é a culpa pelo bucket vazio

Um time sobe um bucket de armazenamento para guardar os arquivos que os usuários da sua aplicação enviam. Para ganhar tempo durante os testes, ativa o acesso público, com a ideia de fechar isso antes do lançamento. Esquece. Seis meses depois, um pesquisador de segurança encontra o bucket inteiro a uma busca de distância, cada arquivo enviado legível para qualquer pessoa com o link. Quem falhou: o provedor de nuvem ou o time?

O time falhou. Não porque digitou um comando errado, mas porque tratou uma decisão que sempre foi sua como se o provedor já tivesse tomado por ele. Essa lacuna entre o que um provedor protege e o que um cliente configura é exatamente o que o modelo de responsabilidade compartilhada existe para fechar.

Segurança da nuvem, segurança na nuvem

A AWS chama a própria metade da divisão de "segurança da nuvem": os data centers físicos, os racks dentro deles, o hypervisor que divide um servidor físico em várias máquinas virtuais, e a rede global que conecta as regiões da AWS. Você nunca vê nada disso, e nunca aplica patch em nada disso. Azure e Google Cloud descrevem a mesma divisão para as próprias plataformas, com outras palavras, mas na mesma forma.

A sua metade é "segurança na nuvem": tudo o que você constrói, configura e guarda usando os serviços que o provedor entrega. Isso sempre inclui seus dados e suas políticas de acesso. Dependendo do serviço escolhido, também pode incluir o sistema operacional convidado e o código da sua aplicação.

A fronteira se move com o modelo de serviço

Essa divisão não fica travada em um único lugar. Ela desliza ao longo da pilha, dependendo de quanto da pilha você pediu para o provedor gerenciar.

Leia a tabela de cima para baixo, não coluna por coluna: as 2 primeiras linhas quase nunca passam para o provedor, e as 2 últimas quase nunca passam para o cliente. As linhas do meio são onde vivem as decisões mais interessantes, e onde acontecem a maioria das questões de prova e das falhas de configuração reais.

Exemplo prático: a mesma funcionalidade, dois modelos de serviço

Digamos que um time roda uma API em Node.js em uma máquina virtual Ubuntu. A AWS cuida do servidor físico, do hypervisor e da rede entre zonas de disponibilidade. O time cuida de aplicar patch no Ubuntu quando uma vulnerabilidade de kernel aparece, de configurar o security group para que só a porta 443 fique acessível, e de rotacionar a chave SSH usada para acessar a máquina. Isso é IaaS: pesado do lado do cliente na tabela.

Agora o mesmo time reconstrói a funcionalidade de upload como um bucket S3 mais uma função Lambda que redimensiona imagens assim que chegam. A AWS passa a gerenciar todo o patch do sistema operacional e do runtime do ambiente de execução da Lambda; não existe mais nenhum servidor para o time aplicar patch. O que continua sendo do time: a política de acesso do bucket S3, a role IAM que a função assume e o que essa role pode acessar, e se os arquivos guardados estão criptografados. Sair de IaaS para um serviço serverless no estilo PaaS removeu uma linha inteira do lado do cliente na tabela. Não removeu a primeira linha.

O que nunca atravessa a linha

Não importa se é IaaS, PaaS ou SaaS, 2 coisas continuam sendo tarefa do cliente em todos os casos: os próprios dados, incluindo a classificação e as escolhas de criptografia, e o gerenciamento de identidade e acesso, ou seja, quem consegue entrar e o que pode fazer depois de entrar. Um provedor pode criptografar um disco por padrão, mas só o cliente decide quais arquivos são sensíveis o bastante para restringir ainda mais, e só o cliente decide quem no time tem acesso a eles. As próximas 2 lições deste tópico cobrem exatamente essas 2 linhas em detalhe: identidade primeiro, depois criptografia.

Equívoco: um certificado que você não conquistou

É tentador presumir que, se o seu provedor de nuvem tem certificação SOC 2 ou ISO 27001, a sua própria aplicação herda essa certificação. Não herda. O certificado do provedor cobre a infraestrutura que ele opera: os data centers, o hypervisor, o funcionamento interno dos serviços gerenciados. Se os controles de acesso, as configurações de criptografia e as práticas de tratamento de dados da sua aplicação atendem a um determinado padrão é uma auditoria separada, e só você consegue produzir evidências para ela. A última lição deste tópico volta exatamente a essa lacuna e mostra como os times a fecham na prática.

Dicas para a prova: lendo uma questão de responsabilidade compartilhada

A armadilha a observar: uma questão que menciona um serviço gerenciado ou serverless e espera que você presuma que o provedor agora é dono de tudo. Ele é dono de mais do que era em IaaS, mas dados e identidade nunca cruzam essa linha.

Onde isso deixa você

Conforme você se move de IaaS em direção a SaaS, a fatia do provedor na tabela cresce e a do cliente encolhe, mas as 2 primeiras linhas, dados e identidade, nunca cruzam essa linha em nenhuma direção. Aprender a ler um cenário e posicioná-lo corretamente nessa tabela é a habilidade mais cobrada em fundamentos de segurança na nuvem. A próxima lição abre por completo a metade da identidade: como a nuvem de fato confirma quem você é e decide o que você pode fazer depois de saber disso.