A segurança da cadeia de fornecimento digital volta a estar no centro das atenções após a OpenAI revelar um incidente que afetou utilizadores da sua plataforma API. O caso, envolvendo a Mixpanel – empresa de analytics third-party utilizada pela gigante da inteligência artificial – demonstra como mesmo organizações com recursos significativos em cibersegurança podem ser comprometidas através dos seus parceiros tecnológicos.
Neste artigo do Blog Dolutech, analisamos em profundidade este incidente que expôs dados limitados de utilizadores da API OpenAI, explorando o vetor de ataque utilizado, as implicações para a gestão de risco de terceiros e as lições cruciais para organizações que operam sob regulamentações como a NIS2 e DORA.
Cronologia e Anatomia do Ataque
Linha Temporal do Incidente
O incidente seguiu uma cronologia reveladora sobre os desafios de deteção e resposta em ambientes de terceiros:
9 de novembro de 2025: A Mixpanel detetou atividade não autorizada nos seus sistemas, identificando um atacante com acesso a parte da infraestrutura da empresa.
25 de novembro de 2025: Após investigação interna, a Mixpanel partilhou com a OpenAI o dataset afetado, permitindo à empresa de IA avaliar o impacto nos seus utilizadores.
27 de novembro de 2025: A OpenAI iniciou o processo de notificação aos utilizadores afetados, demonstrando transparência ao informar todos os subscritores, mesmo aqueles não diretamente impactados.
Este intervalo de 16 dias entre a deteção e a partilha de dados com a OpenAI sublinha a complexidade das investigações forenses em ambientes cloud e a importância de protocolos de comunicação bem estabelecidos entre organizações e os seus fornecedores.
Vetor de Ataque: Smishing Campaign
A Mixpanel identificou o vetor inicial de compromisso como uma campanha de smishing – uma forma sofisticada de phishing conduzida através de mensagens SMS. Esta técnica tem registado crescimento exponencial, com dados de 2025 indicando que 76% das organizações foram alvo deste tipo de ataque, e as taxas de clique em SMS oscilam entre 8,9% e 14,5%, significativamente superiores aos 2% típicos do email.
O smishing é particularmente eficaz em contextos corporativos porque explora a confiança inerente que os utilizadores depositam em mensagens de texto, especialmente quando aparentam provir de fontes legítimas. Neste caso específico, os atacantes conseguiram comprometer credenciais de funcionários da Mixpanel, obtendo acesso a sistemas internos e à capacidade de exportar datasets de clientes.
Dados Potencialmente Expostos
A OpenAI clarificou que a exposição se limitou a informação de perfil associada à utilização da plataforma API (platform.openai.com), incluindo:
- Nomes fornecidos nas contas API OpenAI
- Endereços de email associados às contas
- Localização aproximada baseada em características do browser (cidade, estado, país)
- Informação de sistema: Sistema operativo e detalhes de browser
- Websites de referência
- IDs de organização/utilizador ligados a contas API
É crucial destacar que utilizadores do ChatGPT e outros produtos OpenAI não foram afetados – apenas utilizadores da plataforma API destinada a desenvolvedores e empresas que integram os modelos de IA nos seus produtos.
Dados NÃO Comprometidos
A OpenAI foi explícita sobre o que permaneceu seguro, um aspeto essencial para gestão de crise:
- Conteúdo de conversações (logs de chat)
- Pedidos e respostas API
- Dados de uso da API
- Passwords e credenciais
- Chaves API
- Detalhes de pagamento
- Documentos de identificação governamental
- Tokens de sessão e autenticação
Esta distinção é fundamental porque mitiga significativamente o risco imediato de compromisso de contas ou acesso não autorizado a sistemas dos clientes.
O Risco Crescente de Third-Party Breaches
Estatísticas Alarmantes
O incidente Mixpanel/OpenAI insere-se num padrão preocupante que caracteriza o panorama de cibersegurança atual. Dados de 2025 revelam que:
- 29% de todas as brechas de dados originam-se em fornecedores third-party
- 60% das organizações sofreram incidentes de segurança envolvendo terceiros
- O custo médio de uma brecha de dados nos EUA atingiu 9,48 milhões de dólares
Estes números refletem uma realidade em que a superfície de ataque das organizações se expandiu dramaticamente. Cada fornecedor, parceiro ou prestador de serviços representa um potencial vetor de compromisso – especialmente quando esses terceiros têm acesso a dados sensíveis ou sistemas críticos.
Casos Emblemáticos Recentes
O caso Mixpanel junta-se a uma série de incidentes high-profile que demonstram a urgência da gestão de risco de terceiros:
CDK Global (2024): Ataque ransomware que paralisou 15.000 concessionários automóveis, evidenciando como a falha de segurança de um único fornecedor pode desencadear efeitos em cascata através de toda a cadeia de fornecimento.
MOVEit (2023): Exploração de vulnerabilidade zero-day numa ferramenta amplamente utilizada para transferência de ficheiros, resultando em brechas massivas de dados em múltiplas organizações.
Change Healthcare (2023): Ataque que afetou o setor da saúde nos EUA, impactando faturação médica e cuidados aos pacientes, com consequências financeiras significativas.
Nós observamos que estes incidentes partilham características comuns: atacantes que visam deliberadamente fornecedores com medidas de segurança menos robustas para aceder indiretamente às suas verdadeiras targets – as organizações clientes com defesas mais sofisticadas.
Resposta ao Incidente: Ações Implementadas
Medidas Imediatas da Mixpanel
A resposta da Mixpanel ao incidente seguiu protocolos standard de resposta a incidentes, mas demonstrou a necessidade de rapidez em ambientes cloud:
- Revogação de sessões ativas: Todas as sessões potencialmente comprometidas foram terminadas
- Rotação de credenciais: Credenciais comprometidas foram imediatamente substituídas
- Bloqueio de IPs maliciosos: Endereços IP associados ao atacante foram bloqueados
- Reset global de passwords: Todos os funcionários da Mixpanel foram obrigados a alterar passwords
- Análise forense: Revisão completa de logs de autenticação, sessão e exportação de dados
Decisão da OpenAI: Terminação do Fornecedor
A resposta mais significativa foi a decisão da OpenAI de descontinuar completamente o uso da Mixpanel nos seus serviços de produção. Esta medida drástica envia uma mensagem clara: a confiança é fundamental nas relações com fornecedores, e uma brecha de segurança pode resultar em consequências comerciais imediatas.
A OpenAI também anunciou revisões de segurança expandidas em todo o seu ecossistema de fornecedores, elevando os requisitos de segurança para todos os parceiros e vendors. Esta abordagem proativa demonstra maturidade na gestão de risco de terceiros.
Implicações para Estratégias de Third-Party Risk Management
Limitações dos Métodos Tradicionais
A Dolutech identifica que muitas organizações ainda dependem de métodos antiquados para avaliar risco de fornecedores:
Questionários de segurança anuais: Fornecem apenas uma fotografia pontual da postura de segurança, sem visibilidade sobre mudanças ao longo do ano.
Certificações e compliance: Embora importantes, certificações como SOC 2 ou ISO 27001 não garantem proteção contra todos os vetores de ataque, especialmente engenharia social.
Avaliações externas: Scans externos fornecem dados limitados sobre controlos internos e práticas de segurança efetivas.
Abordagem Moderna: Monitorização Contínua
O incidente Mixpanel reforça a necessidade de evoluir para modelos de gestão de risco de terceiros baseados em:
Inventário centralizado: Manutenção de catálogo completo de todos os fornecedores third-party, incluindo fornecedores de fornecedores (fourth parties ou “Nth parties”).
Avaliação de criticidade: Classificação de fornecedores baseada em:
- Tipo de dados acedidos
- Nível de integração com sistemas críticos
- Impacto operacional potencial de uma disrupção
- Superfície de ataque introduzida
Monitorização em tempo real: Implementação de ferramentas que fornecem visibilidade contínua sobre a postura de segurança dos fornecedores, incluindo:
- Scanning contínuo de vulnerabilidades
- Alertas sobre mudanças em risk scores
- Intelligence sobre ameaças específicas ao setor
- Análise de comportamento anómalo
Cláusulas contratuais robustas: Contratos que definam claramente:
- Obrigações de segurança específicas
- Requisitos de encriptação e controlos de acesso
- Protocolos de notificação de brechas (timeframes específicos)
- Direito a auditorias e avaliações de segurança
- Consequências de falhas de segurança
Contexto Regulatório Europeu: NIS2, DORA e GDPR
NIS2: Diretiva de Segurança de Redes e Informação
A Diretiva NIS2, que os Estados-Membros da UE deviam ter transposto para legislação nacional até 17 de outubro de 2024, estabelece requisitos específicos sobre gestão de risco de terceiros:
Âmbito expandido: Ao contrário da diretiva original, a NIS2 aplica-se a todas as entidades médias e grandes (>50 funcionários ou >10 milhões € faturação anual) em setores essenciais e importantes, incluindo:
- Energia e transportes
- Saúde e infraestruturas digitais
- Gestão de resíduos e águas
- Administração pública
Medidas de segurança da cadeia de fornecimento: A NIS2 exige explicitamente que organizações:
- Implementem políticas de análise de risco de fornecedores
- Avaliem medidas de cibersegurança de third-parties
- Estabeleçam procedimentos para gestão de vulnerabilidades em fornecedores
Penalizações significativas: Multas até 10 milhões € ou 2% da faturação global anual, o que for superior, para entidades essenciais. Para entidades importantes, até 7 milhões € ou 1,4% da faturação.
Responsabilidade da gestão: A NIS2 coloca responsabilidade direta nos órgãos de gestão, tornando CISOs e administradores pessoalmente responsáveis por falhas de supervisão.
DORA: Resiliência Operacional Digital
O Regulamento DORA, que entrou em vigor a 17 de janeiro de 2025, é ainda mais prescritivo para o setor financeiro:
Gestão de risco ICT de terceiros: DORA dedica um pilar inteiro (Pilar IV) à gestão de risco de fornecedores ICT, exigindo:
- Due diligence pré-contratual: Avaliações rigorosas antes de estabelecer novas parcerias ICT
- Mapeamento completo: Registo de todos os prestadores de serviços ICT third-party e arranjos contratuais (prazo: 30 abril 2025)
- Estratégia de saída: Planos detalhados para migração ou substituição de fornecedores críticos
- Monitorização contínua: Supervisão permanente da performance e postura de segurança dos fornecedores
- Gestão de concentração: Identificação e mitigação de riscos de dependência excessiva de fornecedores únicos
Fornecedores ICT Críticos (CTPPs): As Autoridades Europeias de Supervisão (EBA, EIOPA, ESMA) designaram em novembro de 2025 fornecedores ICT críticos que estão sujeitos a supervisão direta, incluindo grandes cloud providers e empresas de analytics.
Testes de resiliência: DORA exige testes regulares que incluam cenários de falha de fornecedores third-party.
GDPR: Minimização e Responsabilidade de Dados
O incidente levanta questões importantes sob a perspetiva do GDPR:
Princípio da minimização de dados: Especialistas em segurança questionaram se a OpenAI precisava realmente de recolher via Mixpanel dados identificáveis como endereços de email e localização para melhoria de produto. O GDPR exige que apenas dados estritamente necessários sejam recolhidos e partilhados com terceiros.
Responsabilidade do controlador de dados: Mesmo quando os dados são processados por subprocessadores (como a Mixpanel), a responsabilidade última por proteção de dados permanece com o controlador (OpenAI). Isto significa que a OpenAI poderia enfrentar consequências regulatórias mesmo que a brecha tenha ocorrido nos sistemas de um terceiro.
Notificação de brechas: Embora não tenha havido necessidade de notificação formal às autoridades neste caso (dados expostos eram limitados e não altamente sensíveis), o princípio de notificação dentro de 72 horas aplica-se quando dados pessoais são comprometidos.
Cenário Português: CNCS e Transposição NIS2
Em Portugal, o Centro Nacional de Cibersegurança (CNCS) é a autoridade competente para implementação da NIS2. Organizações portuguesas devem estar atentas a:
Estado da transposição: Portugal, como muitos Estados-Membros, ainda está no processo de transposição completa da NIS2 para legislação nacional, com prazos de implementação que podem estender-se até outubro de 2026.
Reporting obrigatório: Entidades abrangidas pela NIS2 devem reportar incidentes significativos ao CNCS dentro de prazos específicos:
- Notificação inicial: 24 horas após conhecimento
- Notificação intermédia: 72 horas com avaliação inicial
- Relatório final: 1 mês com análise completa
Requisitos setoriais: Setores como banca, energia, saúde e telecomunicações enfrentam requisitos adicionais através de regulamentação setorial específica que complementa a NIS2.
Lições Estratégicas para CISOs e Gestores de Risco
1. Visibilidade Total da Cadeia de Fornecimento
Nós defendemos que organizações devem manter inventários dinâmicos e completos de todos os fornecedores, classificados por criticidade. O caso Mixpanel demonstra que mesmo fornecedores de analytics – frequentemente considerados de baixo risco – podem representar vetores de exposição significativos.
2. Avaliações Contextualizadas
Nem todos os fornecedores apresentam o mesmo nível de risco. Frameworks de avaliação devem considerar:
- Tipo e volume de dados acedidos: Dados identificáveis requerem controlos mais rigorosos
- Privilégios de acesso: Fornecedores com acesso a sistemas de produção representam maior risco
- Integração técnica: APIs e integrações profundas aumentam a superfície de ataque
- Maturidade de segurança do fornecedor: Tamanho e recursos não garantem segurança robusta
3. Preparação para Smishing e Engenharia Social
O vetor de ataque neste caso – smishing – destaca vulnerabilidades que ferramentas técnicas tradicionais não resolvem:
Treino específico: Funcionários devem receber formação sobre:
- Reconhecimento de mensagens SMS fraudulentas
- Procedimentos de verificação para pedidos não solicitados
- Canais seguros para reportar tentativas suspeitas
Simulações realistas: Implementar campanhas de simulação de smishing para avaliar preparação organizacional, semelhante às simulações de phishing por email.
Autenticação multi-fator resistente a phishing: Implementar MFA baseada em FIDO2 ou biometria, resistente a ataques de social engineering.
Políticas de verificação: Estabelecer políticas claras que exijam verificação out-of-band para pedidos sensíveis, especialmente aqueles recebidos via SMS ou canais não tradicionais.
4. Resposta e Comunicação de Incidentes
A transparência da OpenAI na comunicação do incidente estabelece um padrão positivo:
Notificação proativa: Mesmo utilizadores não diretamente afetados foram informados, demonstrando compromisso com transparência.
Clareza sobre impacto: Distinção clara entre dados expostos e dados não comprometidos ajudou a limitar pânico e permitiu aos utilizadores avaliar risco real.
Ações concretas comunicadas: A decisão de terminar relação com Mixpanel e implementar revisões expandidas demonstrou responsabilidade.
Organizações devem ter planos de comunicação de crise preparados que incluam:
- Templates de notificação para diferentes cenários
- Matriz de decisão sobre quando notificar autoridades e stakeholders
- Canais de comunicação redundantes
- Pontos de contacto designados para media e clientes
5. Arquitetura de Segurança Defensível
A Dolutech recomenda princípios arquiteturais que limitam impacto de compromissos de terceiros:
Zero Trust para integrações: Aplicar princípios de confiança zero a todas as integrações third-party:
- Autenticação contínua
- Privilégios mínimos necessários
- Microsegmentação de redes
- Monitorização de comportamento anómalo
Anonimização e pseudonimização: Sempre que possível, partilhar com terceiros apenas dados anonimizados ou pseudonimizados, minimizando impacto de exposição.
Segregação de ambientes: Manter separação clara entre ambientes de produção e integrações de analytics/observabilidade.
Rate limiting e controlo de exportação: Implementar controlos técnicos que limitem volume de dados que podem ser exportados por integrações third-party.
Exemplo Técnico: Implementação de Monitorização de Third-Party Access
Para organizações que procuram implementar monitorização robusta de acesso de terceiros, a Dolutech sugere a seguinte abordagem técnica:
# Script de monitorização de acesso third-party (exemplo conceptual)
import logging
from datetime import datetime, timedelta
from collections import defaultdict
class ThirdPartyAccessMonitor:
"""
Monitoriza padrões de acesso de integrações third-party
para detetar comportamento anómalo
"""
def __init__(self, threshold_requests=100, time_window_minutes=5):
self.access_log = defaultdict(list)
self.threshold_requests = threshold_requests
self.time_window = timedelta(minutes=time_window_minutes)
self.baseline_profiles = {}
def log_access(self, vendor_id, endpoint, data_volume, timestamp=None):
"""Regista tentativa de acesso de vendor"""
if timestamp is None:
timestamp = datetime.now()
access_entry = {
'endpoint': endpoint,
'data_volume': data_volume,
'timestamp': timestamp
}
self.access_log[vendor_id].append(access_entry)
# Verificar se comportamento é anómalo
if self.detect_anomaly(vendor_id):
self.raise_alert(vendor_id, access_entry)
def detect_anomaly(self, vendor_id):
"""Deteta padrões de acesso anómalos"""
recent_accesses = [
access for access in self.access_log[vendor_id]
if access['timestamp'] > datetime.now() - self.time_window
]
# Verificar volume de requests
if len(recent_accesses) > self.threshold_requests:
return True
# Verificar volume total de dados
total_data = sum(access['data_volume'] for access in recent_accesses)
if total_data > self.get_baseline_threshold(vendor_id):
return True
# Verificar acesso a endpoints não usuais
baseline_endpoints = self.baseline_profiles.get(vendor_id, {}).get('endpoints', set())
current_endpoints = {access['endpoint'] for access in recent_accesses}
if current_endpoints - baseline_endpoints:
return True
return False
def raise_alert(self, vendor_id, access_entry):
"""Gera alerta para SOC"""
alert_message = f"""
ALERTA: Comportamento anómalo detetado
Vendor ID: {vendor_id}
Endpoint: {access_entry['endpoint']}
Volume de dados: {access_entry['data_volume']} bytes
Timestamp: {access_entry['timestamp']}
Ação recomendada:
1. Revogar temporariamente acesso do vendor
2. Iniciar investigação forense
3. Contactar responsável do vendor
4. Rever logs de autenticação
"""
logging.critical(alert_message)
# Integração com SIEM/SOAR para resposta automática
def get_baseline_threshold(self, vendor_id):
"""Retorna threshold de dados baseado em baseline do vendor"""
baseline = self.baseline_profiles.get(vendor_id, {})
return baseline.get('max_data_volume', 1000000) # Default 1MBEste exemplo demonstra como organizações podem implementar monitorização proativa de comportamento de fornecedores, detetando padrões como:
- Volume anormal de requests
- Acesso a endpoints não usuais
- Exportação de volumes de dados acima do baseline
- Tentativas de acesso fora do horário normal
Medidas de Mitigação Recomendadas
A Dolutech compilou um conjunto de medidas práticas que organizações devem implementar:
Imediato (0-30 dias)
- Inventário de vendors: Criar lista completa de todos os fornecedores com acesso a dados ou sistemas
- Classificação de criticidade: Avaliar cada vendor quanto a risco potencial
- Revisão de permissões: Auditar e remover acessos excessivos ou desnecessários
- MFA universal: Garantir que todos os acessos third-party utilizam autenticação multi-fator
Curto prazo (1-3 meses)
- Avaliações de segurança: Conduzir avaliações de segurança de vendors de alto risco
- Revisão contratual: Atualizar contratos para incluir cláusulas específicas de segurança e notificação
- Formação em smishing: Implementar treino específico sobre ameaças de SMS phishing
- Planos de contingência: Desenvolver estratégias de saída para vendors críticos
Médio prazo (3-12 meses)
- Plataforma TPRM: Implementar solução dedicada de Third-Party Risk Management
- Monitorização contínua: Deploy de ferramentas de monitorização em tempo real
- Programa de simulação: Estabelecer simulações regulares de phishing e smishing
- Compliance NIS2/DORA: Preparar organização para requisitos regulatórios aplicáveis
Conclusão: A Era da Responsabilidade Partilhada
O incidente Mixpanel/OpenAI serve como recordatório de que na era digital, a segurança é fundamentalmente uma responsabilidade partilhada. Mesmo organizações com recursos significativos e expertise técnica profunda – como a OpenAI – permanecem vulneráveis através das suas cadeias de fornecimento.
Nós acreditamos que este caso marca um ponto de inflexão na forma como a indústria aborda gestão de risco de terceiros. A decisão da OpenAI de terminar imediatamente o uso da Mixpanel, apesar de ser um fornecedor estabelecido, sinaliza que tolerância para brechas de segurança em vendors está a diminuir rapidamente.
Para organizações em Portugal e na Europa, o timing deste incidente é particularmente relevante. Com a NIS2 ainda em transposição e DORA recentemente em vigor desde janeiro de 2025, existe uma janela crítica para implementar práticas robustas de gestão de risco de terceiros antes que penalizações regulatórias se tornem realidade.
As lições são claras:
- Visibilidade total sobre a cadeia de fornecimento não é opcional
- Monitorização contínua supera avaliações pontuais
- Formação em engenharia social é tão crítica quanto controlos técnicos
- Transparência na comunicação de incidentes protege reputação
- Preparação regulatória deve começar agora, não quando deadlines se aproximam
A Dolutech continuará a acompanhar desenvolvimentos neste caso e fornecerá análises sobre implicações mais amplas para o setor. A cibersegurança moderna exige vigilância constante não apenas dos nossos próprios sistemas, mas de todo o ecossistema digital em que operamos.
Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.
