O novo caminho de ataque ao SaaS: quando um login legítimo dá acesso à aplicação errada

O que mudou

O ataque nem sempre começa com o roubo de uma password. A Microsoft observou três vias: chamadas de engenharia social que levavam utilizadores a autorizar uma aplicação OAuth controlada pelo atacante, comprometimento através de integrações e fluxos de trabalho de confiança e configurações incorretas de acesso de convidados.

Depois de autorizada, uma aplicação ligada pode herdar as permissões legítimas do utilizador e fazer pedidos à API com aparência normal. Isto pode permitir descobrir dados do CRM, manter acesso e extrair informação, gerando menos sinais de autenticação do que uma tomada de conta convencional.

A Microsoft esclarece que esta atividade não resultou de uma vulnerabilidade inerente ao Salesforce. A fragilidade estava no modelo de confiança envolvente: quem pode aprovar aplicações, que integrações continuam ligadas, a que dados chegam os convidados e se a atividade das aplicações está a ser monitorizada.

Por que razão o MFA é necessário—mas não chega

Um MFA forte e resistente a phishing continua a ser essencial. A Microsoft anunciou separadamente que o Entra ID começará a tornar as passkeys o método de autenticação predefinido a partir de 1 de setembro de 2026, e o NCSC recomenda métodos de MFA mais fortes para serviços empresariais.

No entanto, uma passkey protege o início de sessão; não torna automaticamente segura cada decisão de consentimento, integração externa ou configuração de convidados. Se um colaborador já autenticado for manipulado para aprovar uma aplicação maliciosa, o token resultante pode dar acesso sem que o atacante tenha de voltar a iniciar sessão como esse colaborador.

Numa PME, a segurança de identidade precisa por isso de duas camadas: proteger o login humano e governar as aplicações autorizadas a agir em nome das pessoas.

Um plano de controlo prático para PMEs

Comece pela visibilidade. Crie um inventário das aplicações ligadas ao Microsoft 365, Google Workspace, CRM, contabilidade, suporte e marketing. Registe o responsável, a finalidade, as permissões, os dados alcançados e a última utilização de cada integração.

Depois, reduza a confiança permanente. Limite o consentimento dos utilizadores quando a plataforma o permitir, exija revisão para permissões de alto impacto, remova integrações sem utilização, reveja contas de convidados e separe identidades de administração do trabalho diário.

Por fim, torne os controlos operacionais. Guarde registos de identidade e aplicações, crie alertas para novas ligações com privilégios elevados, defina um procedimento para revogar tokens, teste exportações e backups e atribua a alguém a responsabilidade de rever alterações de acesso—não apenas de instalar produtos de segurança.

Como a brianda.cloud pode ajudar

A brianda.cloud pode mapear identidades e integrações SaaS, rever permissões e acessos de convidados, reforçar MFA e a adoção de passkeys, ligar alertas úteis e alinhar estes controlos com firewall gerida, backups e recuperação.

O resultado é uma superfície de confiança menor e um caminho de resposta claro se uma aplicação, token ou integração externa se tornar suspeita. O primeiro passo é uma revisão focada de acessos, não uma migração disruptiva de plataforma.