Quando o MFA não é suficiente

A regra número um da segurança em nuvem é: "usarás MFA em todos os momentos". Por quê? Bem, ao migrar para a computação em nuvem pública, o senhor essencialmente pega todas as suas interfaces administrativas, consolida-as em um único portal ou API e então… coloca-as na Internet protegidas por nome de usuário, senha e (talvez) MFA. Mesmo quando se utiliza uma federação.

Mas acontece que nem mesmo o MFA é sempre suficiente, como se viu em diversas violações de grande porte, incluindo a ocorrida na Uber.

Essa é uma das diferenças mais críticas a compreender entre a nuvem e a infraestrutura tradicional, e é por isso que o senhor continua ouvindo a frase "a identidade é o novo perímetro". Antes da nuvem, gerenciávamos nosso datacenter de dentro de redes privadas (ou por meio de pontos de acesso controlados, como VPNs e jump boxes). Com a nuvem, tudo isso está na Internet por padrão, e é difícil restringir o acesso, especialmente agora que damos suporte com mais frequência a funcionários e administradores remotos.

O MFA é uma forma eficaz de proteger a autenticação de usuários/administradores. Temos inúmeras opções, que vão das um pouco mais seguras (MFA baseado em mensagens) às realmente seguras (chaves de hardware). Mas o problema, mesmo com o MFA, é que os usuários têm acesso persistente com privilégios persistentes. Se o senhor atribuir uma função a um usuário, ele poderá usar essas permissões a qualquer momento após a autenticação. Os atacantes sabem disso e desenvolveram uma série de técnicas para obter acesso autenticado. Eles:

• abusam de credenciais estáticas, especialmente quando não há MFA em uso.
• burlam algumas formas de MFA. Por exemplo, fazem SIM swap para interceptar mensagens de texto enviadas a telefones.
• aplicam engenharia social em administradores para desativar o MFA ou redefini-lo para um dispositivo sob seu controle.
• aplicam engenharia social em usuários para capturar um código de MFA.
• roubam credenciais de sessão do sistema de um usuário depois que ele já se autenticou e as utilizam a partir de um sistema sob o controle do atacante.

Uma vez obtido o acesso, o atacante passa a explorar privilégios e, por fim, utiliza-os para atividades maliciosas.

O privilégio mínimo é uma mentira

O problema central é que concedemos permissões não com base no que alguém precisa fazer em determinado momento, mas no que poderá precisar fazer no futuro. Os usuários, especialmente os administradores, têm o conjunto máximo de permissões para todas as ações possíveis. Todos os padrões de segurança do planeta dizem que o IAM deve ser de negação padrão e privilégio mínimo, mas isso é meio que uma mentira, já que o conjunto de "privilégios mínimos" é definido pelo conjunto máximo de privilégios de que eles precisarão em algum momento, não o tempo todo.

Mesmo quando permitimos que os usuários alternem funções e usem permissões diferentes em sessões diferentes, eles quase sempre continuam tendo acesso a essas funções sempre que quiserem. Na realidade, o privilégio mínimo deveria ser limitado no tempo, e não apenas vinculado ao usuário. Historicamente, gerenciamos permissões atribuindo funções, e as funções têm permissões dentro de um escopo. "Você é administrador nestas 5 contas e usuário comum nas outras 98". Muitas vezes, atribuímos até várias funções a um mesmo usuário; elas combinam permissões ou o usuário pode alternar entre funções ao realizar tarefas diferentes.

Imagine o quanto seria mais difícil para um atacante se eliminássemos os privilégios persistentes. Em vez de o usuário se autenticar e ter acesso a todas as suas permissões, ele teria acesso com um conjunto bem reduzido de permissões e precisaria escalar privilégios para qualquer ação potencialmente danosa.

Acrescente segurança com autorizações dinâmicas

Não estou propondo que se acabe com o MFA ou com outras medidas de segurança no nível da autenticação. Elas continuam sendo de importância vital, mas às vezes não são suficientes. Isso é especialmente verdadeiro na segurança em nuvem, devido ao grau maior de exposição inerente à Internet. Mas a nuvem também tem vantagens, entre elas a federação baseada em sessões e as autorizações granulares (até o nível de chamadas de API individuais).

Em vez de conceder aos usuários acesso persistente a todas as permissões de que possam vir a precisar, concedemos a eles um acesso mais limitado, e eles então solicitam acesso a privilégios elevados. Esse conceito não é novo; é o que os produtos de gerenciamento de usuários privilegiados usam há anos. Mas esses produtos ainda dependem, com frequência, de técnicas pouco práticas, como sessões intermediadas por proxy e rotação de senhas temporárias. A nuvem é inerentemente mais flexível, já que os modelos nativos de IAM são baseados em sessões por natureza e os privilégios são definidos em documentos de política (normalmente escritos em JSON).

É assim que funcionam ferramentas como o nosso FireMon Authorization Control. Ou consulte o Netflix ConsoleMe como exemplo de código aberto. Os usuários solicitam acesso quando precisam, e as plataformas usam políticas para determinar o que é necessário para a aprovação. Quando essas condições são atendidas, como a autorização de um gestor ou colega, o usuário fica autorizado a usar uma função por uma sessão. As plataformas podem até inserir condições, como "permitir esta sessão apenas a partir do endereço IP que a solicitou". Essas solicitações são normalmente feitas fora de banda e usam canais paralelos, como ChatOps, para aprovações, tornando o processo propositalmente ruidoso, sobretudo no caso de acessos sensíveis a produção.

A segurança no nível da autorização, na prática, facilita a vida de todos, de desenvolvedores e usuários a administradores de segurança. O senhor não precisa conhecer antecipadamente todo o conjunto de permissões possíveis. Em vez disso, os usuários pedem o que precisam quando precisam. As políticas determinam o caminho de menor atrito para conceder esse acesso sem comprometer a segurança. Ferramentas como o ChatOps permitem que um desenvolvedor solicite acesso a uma nova conta e obtenha uma resposta em segundos, em vez de precisar abrir um chamado em um sistema de tickets que poderia levar dias ou semanas.

Ao acrescentar segurança à autorização, reduzimos o impacto de credenciais roubadas e autenticações comprometidas, ao mesmo tempo em que diminuímos o atrito e a sobrecarga.