A identidade é o novo perímetro

A aula anterior traçou uma linha entre o que um provedor de nuvem protege e o que cabe ao cliente proteger. Do lado do cliente, um item pesa mais do que qualquer outro: a identidade — quem tem permissão para entrar, e o que essa pessoa pode fazer depois. Uma rede de escritório tradicional tinha um muro e uma porta trancada; uma conta na nuvem tem um formulário de login, acessível de qualquer lugar do planeta, a qualquer hora. Proteger esse login é, na prática, a maior parte do que significa “segurança na nuvem”.

Como as contas realmente são tomadas

A tomada de uma conta raramente envolve um atacante invadindo os sistemas de um provedor de nuvem. Ela costuma seguir o padrão de roubo de credenciais visto no curso de modelagem de ameaças desta universidade: uma senha reutilizada de um serviço não relacionado que vazou, ou uma página de phishing convincente que simplesmente pede o login diretamente. Uma vez que um atacante tem credenciais válidas, a maioria dos serviços de nuvem não tem como distingui-lo do verdadeiro dono da conta — e é exatamente por isso que o controle único destacado pela CISA acima de todos os outros é a autenticação multifator (MFA).

MFA, e por que nem todas as formas são iguais

A CISA afirma claramente que “usuários que ativam a MFA têm uma probabilidade significativamente menor de serem invadidos”, porque uma senha roubada sozinha deixa de ser suficiente. Mas a CISA também classifica as formas disponíveis de MFA por sua resistência ao phishing, e essa classificação importa: “a única autenticação amplamente disponível resistente a phishing é a autenticação FIDO/WebAuthn” — o padrão por trás das passkeys e das chaves de segurança físicas, abordado no curso de criptografia. Um código por mensagem de texto ainda é, nas palavras da CISA, muito melhor do que nenhum segundo fator, mas pode ser interceptado ou repassado por um atacante suficientemente motivado; notificações push de aplicativos com confirmação de número ficam no meio do caminho. Para uma conta na nuvem que guarda qualquer coisa sensível, ativar a opção de MFA mais forte que essa conta oferece é o passo de maior valor desta aula.

OAuth: as permissões que você concede a outros aplicativos

Toda vez que você clica em “continuar com o Google” ou conecta uma ferramenta de agenda ao seu calendário, você está usando OAuth, descrito pela própria documentação do padrão como “o protocolo padrão da indústria para autorização”. Sua propriedade útil é que o aplicativo de terceiros nunca vê sua senha — você faz login diretamente com seu provedor e depois aprova um conjunto específico e limitado de permissões, chamadas de escopos, para esse aplicativo. Seu risco é exatamente essa concessão de permissão: um aplicativo de agenda que só precisa ler os horários livres/ocupados do seu calendário pode pedir, e rotineiramente receber, permissão para ler e enviar e-mails em seu nome. Cada aplicativo conectado é uma concessão de acesso permanente que persiste até alguém revogá-la, e é por isso que a última aula deste curso trata de revisar essa lista, não apenas de configurá-la corretamente uma vez.

Chaves vazadas: a prima menos visível do OAuth

Ferramentas e integrações automatizadas costumam se autenticar com uma chave de API em vez de um login humano — uma sequência longa que funciona como uma senha, mas não é digitada por uma pessoa e muitas vezes não é protegida por MFA de forma alguma. Essas chaves acabam expostas com mais frequência do que a maioria das pessoas imagina: coladas em um chamado de suporte, enviadas por acidente para um repositório de código, deixadas em um arquivo de configuração compartilhado além do que era pretendido. Tratar uma chave de API com o mesmo cuidado que uma senha — nunca compartilhá-la em texto simples, trocá-la se houver possibilidade de exposição, e limitar o que ela pode fazer — fecha uma brecha que a MFA, feita para logins humanos, não cobre.