A identidade é o novo perímetro

A lição anterior traçou uma linha entre o que um fornecedor de nuvem protege e o que cabe ao cliente proteger. Do lado do cliente, um elemento faz mais trabalho do que qualquer outro: a identidade — quem tem permissão para iniciar sessão, e o que pode depois fazer. Uma rede de escritório tradicional tinha uma parede e uma porta trancada; uma conta na nuvem tem um formulário de início de sessão, acessível a partir de qualquer lugar do mundo, a qualquer hora. Proteger esse início de sessão é, na prática, a maior parte do que significa "segurança na nuvem".

Como as contas são realmente comprometidas

A tomada de controlo de uma conta raramente envolve um atacante a invadir os sistemas de um fornecedor de nuvem. Normalmente segue o padrão de roubo de credenciais do curso de modelação de ameaças desta universidade: uma palavra-passe reutilizada de um serviço, sem relação, que sofreu uma fuga de dados, ou uma página de phishing convincente que simplesmente pede o início de sessão diretamente. Depois de um atacante ter credenciais válidas, a maioria dos serviços na nuvem não tem forma de as distinguir do verdadeiro dono da conta — e é exatamente por isso que o único controlo que a CISA destaca acima de todos os outros é a autenticação multifator (MFA).

MFA, e porque nem todas as formas são iguais

A CISA afirma claramente que "os utilizadores que ativam a MFA têm uma probabilidade significativamente menor de serem invadidos", porque uma palavra-passe roubada deixa de bastar sozinha. Mas a CISA também classifica as formas disponíveis de MFA pela resistência a phishing, e essa classificação importa: "a única autenticação amplamente disponível e resistente a phishing é a autenticação FIDO/WebAuthn" — a norma por trás das chaves de acesso (passkeys) e das chaves de segurança físicas, abordada no curso de criptografia. Um código por mensagem de texto é, nas palavras da CISA, ainda muito melhor do que não ter nenhum segundo fator, mas pode ser intercetado ou reencaminhado por um atacante suficientemente motivado; as notificações push baseadas em app, com correspondência de números, ficam a meio caminho. Para uma conta na nuvem que guarde algo sensível, ativar a opção de MFA mais forte que essa conta oferece é o passo de maior valor nesta lição.

OAuth: as permissões que concede a outras apps

Sempre que clica em "continuar com o Google" ou liga uma ferramenta de agendamento ao seu calendário, está a usar OAuth, descrito pela própria documentação da norma como "o protocolo padrão da indústria para autorização". A sua propriedade útil é que a app de terceiros nunca vê a sua palavra-passe — inicia sessão diretamente com o seu fornecedor, e depois aprova um conjunto específico e limitado de permissões, chamadas âmbitos (scopes), para essa app. O seu risco é exatamente essa concessão de permissão: uma app de agendamento que só precisa de ler os horários livres/ocupados do seu calendário pode pedir, e receber rotineiramente, permissão para ler e enviar e-mail em seu nome. Cada app ligada é uma concessão de acesso permanente que persiste até alguém a revogar, e é por isso que a última lição deste curso aborda a revisão dessa lista, e não apenas a sua configuração correta uma única vez.

Chaves expostas: a prima menos visível do OAuth

Ferramentas e integrações automatizadas autenticam-se muitas vezes com uma chave de API em vez de um início de sessão humano — uma cadeia longa que funciona como uma palavra-passe mas não é escrita por uma pessoa e muitas vezes não está protegida por MFA de todo. Essas chaves acabam expostas mais vezes do que a maioria das pessoas espera: coladas num pedido de suporte, submetidas por engano a um repositório de código, deixadas num ficheiro de configuração partilhado mais amplamente do que o previsto. Tratar uma chave de API com o mesmo cuidado que uma palavra-passe — nunca a partilhar em texto simples, substituí-la se puder ter sido exposta, e limitar o que ela pode fazer — fecha uma lacuna que a MFA, pensada para inícios de sessão humanos, não cobre.