Snowflake corta as palavras-passe das contas de serviço: e agora, quem paga a fatura?

A Snowflake está a entrar na fase final do plano que elimina o início de sessão só com palavra-passe na sua plataforma de dados na nuvem. Depois de obrigar os utilizadores humanos a usar autenticação multifator, a empresa avança agora para o capítulo mais difícil: as contas de serviço — os utilizadores não humanos que alimentam pipelines de ETL, integrações de BI, tarefas de CI/CD e scripts automatizados. Segundo a documentação oficial, a chamada Fase 3 é aplicada às contas de forma faseada ao longo de um período de três meses, entre agosto e outubro de 2026, com notificação prévia da data de imposição para cada conta. Para muitas organizações, a mudança técnica é trivial; o problema é descobrir quantas credenciais estáticas existem realmente espalhadas pela infraestrutura.

O que muda exatamente

A Snowflake descreve o objetivo de forma direta: exigir autenticação multifator (MFA) a todos os utilizadores humanos que usem palavra-passe e proibir palavras-passe em todos os utilizadores de serviço, que passam a ter de recorrer a um método de autenticação mais forte. A distinção entre os dois mundos é feita através de um atributo do objeto de utilizador. Os administradores usam o parâmetro TYPE para definir se um utilizador é humano ou de serviço: TYPE=PERSON identifica pessoas, um valor não definido ou nulo é tratado como utilizador humano, e TYPE=SERVICE identifica contas de serviço.

Existe ainda uma categoria de transição. O tipo LEGACY_SERVICE foi criado para ajudar os clientes a migrar contas de serviço para formas seguras de autenticação e permite temporariamente que um utilizador se autentique com palavra-passe, mesmo tratando-se de uma aplicação ou serviço. Esse tipo de utilizador está, ele próprio, a ser gradualmente descontinuado no âmbito deste plano. Fornecedores que integram com a plataforma têm vindo a avisar os seus clientes de que os utilizadores LEGACY_SERVICE começam a ser descontinuados em agosto de 2026.

Nem todos os ambientes estão abrangidos. A Snowflake indica que as fases não se aplicam a contas de leitor (reader), contas de teste (trial) nem ao Snowflake Postgres, onde continua a ser possível iniciar sessão com palavra-passe de fator único.

Cronologia da eliminação das palavras-passe

Convém sublinhar que estas datas não são imutáveis. A própria Snowflake nota que as datas da Fase 3 não correspondem a um pacote de alteração de comportamento e estão sujeitas a alterações. A Fase 1, pelo contrário, foi implementada através do processo habitual de behavior change release, com pacotes mensais cuja aplicação segue o ciclo de vida definido para cada pacote. O calendário também já foi revisto: quando o plano foi comunicado publicamente, em finais de 2024, a expectativa era que, em novembro, a Snowflake bloqueasse todas as tentativas de início de sessão com palavra-passe de fator único, afetando tanto utilizadores humanos em sessões interativas como utilizadores de serviço com acesso programático. Na prática, o corte para as contas de serviço acabou por escorregar para 2026.

Porque é que a parte difícil só começa agora

Impor MFA a pessoas é um exercício conhecido de gestão de mudança. Já as identidades não humanas não têm telemóvel nem chave de segurança. Como a própria plataforma reconheceu, a maioria dos eventos de autenticação no Snowflake está associada a identidades não humanas ou a acesso programático, que não se adequa a MFA. O resultado é que a migração implica tocar em ligações que muitas vezes ninguém documentou: conetores de terceiros, agendadores, notebooks, scripts herdados e credenciais coladas em ficheiros de configuração.

Há também um custo operacional que não desaparece com a mudança. Substituir uma palavra-passe por um par de chaves RSA resolve o problema imediato, mas transfere o esforço para a gestão do ciclo de vida das chaves — geração, rotação, armazenamento seguro e auditoria. É precisamente esse ponto que a Snowflake tem procurado atacar com a federação de identidade de carga de trabalho (workload identity federation, WIF). Trata-se de um método de autenticação serviço-a-serviço que permite a aplicações, serviços ou contentores autenticarem-se junto da Snowflake usando o sistema de identidade nativo do fornecedor de nuvem, como funções do AWS IAM, o Microsoft Entra ID ou contas de serviço do Google Cloud. A vantagem apontada é eliminar a necessidade de gerir e armazenar credenciais de longa duração, como palavras-passe, chaves de API, pares de chaves e tokens de acesso programático.

A funcionalidade ficou disponível de forma geral em agosto de 2025 e a Snowflake descreve-a como o método de autenticação recomendado e preferencial para utilizadores do tipo SERVICE, ou seja, para cargas automatizadas, aplicações e ferramentas de terceiros. Mais recentemente, a plataforma alargou o modelo aos casos em que são as próprias cargas de trabalho da Snowflake a aceder a serviços externos, através de tokens de identidade de curta duração obtidos com a função SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN.

O incidente que está por trás desta decisão

A origem desta política é conhecida. Em 2024, uma campanha em larga escala explorou credenciais válidas de clientes da plataforma. A Mandiant descreveu que o agente de ameaça identificado como UNC5537 obteve acesso a instâncias de vários clientes com credenciais roubadas, sobretudo por campanhas de infostealers que infetaram sistemas não pertencentes à Snowflake, resultando na exportação de um volume significativo de dados e em tentativas de extorsão direta às vítimas e de venda dos dados em fóruns criminosos. A investigação não encontrou indícios de que os acessos tenham resultado de uma brecha no ambiente empresarial da Snowflake; todos os incidentes analisados foram associados a credenciais de clientes comprometidas.

Os números ajudam a perceber a escala e o padrão. Um relatório da Mandiant referiu cerca de 165 organizações afetadas pela campanha. A maioria das credenciais utilizadas provinha de infeções antigas por infostealers, algumas com origem em 2020, envolvendo famílias como VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA e METASTEALER, e pelo menos 79,7% das contas visadas tinham exposição prévia de credenciais. Além da ausência de MFA e de credenciais expostas há muito tempo e nunca rodadas, as instâncias comprometidas também não usavam listas de permissão de rede. O reforço posterior alinhou-se com compromissos públicos: a empresa enquadrou o bloqueio das autenticações de fator único no compromisso Secure by Design da CISA, do qual é signatária.

Passos concretos de mitigação

• Inventariar todos os objetos de utilizador e classificar explicitamente o atributo TYPE, em vez de depender do comportamento por omissão — recorde-se que um TYPE não definido ou nulo é tratado como utilizador humano.
• Identificar todas as contas ainda em LEGACY_SERVICE e mapeá-las às aplicações, conetores e agendadores que dependem delas.
• Escolher o método de substituição por caso de uso: federação de identidade de carga de trabalho para cargas em nuvem, OAuth para aplicações e par de chaves quando não existir alternativa.
• Testar em ambientes de desenvolvimento antes de remover a palavra-passe e só depois executar o ALTER USER definitivo em produção.
• Confirmar que os conetores e drivers usados suportam o novo método — vários fabricantes de ferramentas de dados já retiraram a opção de utilizador e palavra-passe das suas integrações.
• Reforçar controlos complementares, como políticas de rede e políticas de autenticação, e monitorizar autenticações anómalas durante e após a migração.

Porque é que isto importa em Portugal

Muitas organizações portuguesas — de retalhistas a seguradoras, passando por prestadores de serviços de dados — usam plataformas analíticas na nuvem como camada central de reporting. Uma interrupção não planeada de pipelines de dados não é apenas um problema de TI: pode afetar reporting regulatório, faturação e decisões operacionais. E, quando os dados envolvidos são pessoais, uma credencial estática comprometida numa conta de serviço com acesso amplo pode transformar-se rapidamente numa violação de dados com obrigações de notificação à CNPD ao abrigo do RGPD.

Do lado da segurança, o tema encaixa nas exigências do Regime Jurídico da Ciberseguranca aprovado pelo Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2, onde a gestão de acessos, a autenticação multifator e a segurança da cadeia de fornecimento estão entre as medidas esperadas das entidades abrangidas. Para as entidades sob supervisão do CNCS, ser capaz de demonstrar que as identidades não humanas estão inventariadas, com credenciais rotativas ou efémeras, é hoje um requisito prático de maturidade — e não uma boa prática opcional. Para as PME, a lição é mais simples: qualquer credencial de integração que nunca foi rodada é um risco silencioso, independentemente do fornecedor de nuvem.

Perguntas frequentes

A minha conta Snowflake vai deixar de funcionar de repente?

Não de forma imediata para todos. A Snowflake indica que a Fase 3 é aplicada às contas de forma faseada durante um período de três meses e que cada cliente recebe uma notificação com a data de imposição para a sua conta. Ainda assim, integrações que continuem a usar palavra-passe deixarão de autenticar-se após essa data.

Que métodos de autenticação passam a ser aceites para contas de serviço?

As alternativas passam por métodos de autenticação forte, como par de chaves, OAuth e federação de identidade de carga de trabalho. A Snowflake apresenta a federação de identidade de carga de trabalho como o método recomendado e preferencial para utilizadores do tipo SERVICE.

O que é o tipo de utilizador LEGACY_SERVICE?

É um tipo de transição que permite temporariamente que uma aplicação ou serviço se autentique com palavra-passe, criado para ajudar os clientes a migrar para formas seguras de autenticação. O plano prevê a sua descontinuação gradual.

Esta mudança aplica-se a contas de teste ou de leitor?

Não. A documentação da Snowflake refere que estas fases não se aplicam a contas de leitor, contas de teste nem ao Snowflake Postgres, onde continua a ser possível iniciar sessão com palavra-passe de fator único.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Snowflake, pela Mandiant/Google Cloud e por outras fontes técnicas citadas.