nuvem
13 artigos com esta tag
Vazamento de dados pessoais do Suntory Group (cerca de 90.000 funcionários e pessoal de parceiros, e outros grupos): nomes e e-mails vazados após acesso não autorizado a um serviço de nuvem externo, e o que candidatos e clientes devem fazer
O Suntory Group anunciou em 2 de novembro de 2026 que confirmou um acesso não autorizado de terceiros a um serviço de nuvem externo usado pelo grupo, e que alguns dos arquivos baixados pelo terceiro continham informações pessoais. Detectou anomalias em 28 de outubro e bloqueou o acesso, e em 29 de outubro confirmou que havia informações pessoais. As informações pessoais cujo vazamento foi confirmado até 1º de novembro se dividem em sete grupos: nomes e e-mails de cerca de 90.000 funcionários do grupo e funcionários de empresas parceiras; e-mails de 7.323 pessoas cadastradas no fim de 2023 no programa de experiência corporativa Mar de Shine; dados de cadastro da My Page de candidatos e outros (nome, e-mail, telefone etc.) de 7.173 candidatos à seleção aberta da trilha de negócios do recrutamento de recém-formados 2026 da Suntory Holdings; nomes e telefones de 1.097 pessoas salvos em dois celulares corporativos da Suntory Beverage Solution; nomes, e-mails e telefones de 324 funcionários da Monte Bussan e funcionários de empresas parceiras; nomes e informações de local de entrega de 96 clientes de entrega da Izutsu Maisen e da equipe que fez a entrega; e nomes e cargos de 25 funcionários de parceiros comerciais da Suntory. Cartões de crédito e outros dados de pagamento não estão incluídos. Nenhum uso indevido havia sido confirmado na data do comunicado. A empresa diz que está contatando individualmente as pessoas afetadas. Nossa conclusão: não abra links de mensagens que dizem ser da Suntory ou de uma empresa do grupo sobre seleção, ofertas de emprego, entregas ou negócios; confira pelo site oficial que você mesmo abrir ou pelos contatos da página do comunicado.
Incidente de segurança da Trigger.dev (novembro de 2026): chaves de API root e variáveis de ambiente acessadas em 0,66% dos clientes; regenere as chaves e troque os segredos
A Trigger.dev, plataforma para executar tarefas em segundo plano e agentes de IA, divulgou um incidente de segurança em 1º de novembro de 2026 e publicou um relatório de acompanhamento em 6 de novembro. A empresa diz que alertas da infraestrutura sinalizaram atividade anômala em 1º de novembro, que a julgou maliciosa e bloqueou o atacante. O incidente afetou 0,66% de todos os clientes. O atacante obteve chaves de API root de alguns ambientes de clientes; uma chave root dá acesso total às configurações de um ambiente, incluindo suas variáveis de ambiente. Em alguns ambientes o atacante também listou execuções, implantações e agendamentos recentes, o que retornou IDs, nomes de tarefas, chaves de idempotência de execuções, status das execuções, tags, metadados e erros de implantações, IDs externos de agendamentos e metadados de execuções. A empresa diz que não encontrou indício de que outros dados de clientes, outros serviços, seus próprios bancos de dados de produção ou contas do painel de clientes tenham sido acessados. Ela não divulga o vetor de ataque, para proteger a investigação e os clientes. Os clientes afetados foram contatados por e-mail (em 1º e 2 de novembro) e por um banner no painel (sem informar quando), e as chaves de API potencialmente afetadas foram revogadas. Clientes afetados devem regenerar suas chaves de API e trocar as credenciais dos ambientes afetados, como senhas de bancos de dados e chaves de API de terceiros, revogando as antigas no provedor. A empresa diz que clientes que não receberam aviso de impacto não foram afetados, que os segredos de assinatura de webhooks não foram expostos e que as implantações auto-hospedadas não foram afetadas. Avaliação deste site: confira primeiro o e-mail e o banner do painel e, se você foi afetado, regenere as chaves e troque as credenciais como a empresa orienta.
Invasão à produção da Chainstack (plataforma de nós blockchain e API): o que desenvolvedores e operadores de dApps devem fazer com os dados de conta e as credenciais de nó
Em um comunicado datado de 3 de novembro de 2026, a Chainstack diz que um invasor externo chegou a parte de sua infraestrutura por meio de um componente de terceiros: um ambiente de desenvolvimento em 26 de outubro e parte da produção em 29 de outubro; ela detectou e cortou o acesso em 31 de outubro, e a investigação foi encerrada em 2 de novembro. As informações que podem ter sido expostas de um banco de dados de contas de clientes são nomes de organização, nomes dos titulares das contas, os e-mails dos membros da organização e hashes de senha. Sistemas que guardam credenciais de nó também foram acessados; a empresa não tem evidências de que tenham sido lidas, mas as trata como expostas. Diz que não armazena dados de meios de pagamento, que nós, console e API não foram modificados e que o serviço continuou. Não é informado o número de clientes. Conclusão deste site: os usuários devem trocar a senha, trocar as credenciais de nó e as chaves de API da plataforma, e substituir os endpoints embutidos em apps, CI e front-ends.
Acesso não autorizado e vazamento de dados na PingCAP (TiDB Cloud) (até cerca de 50.000 registros no Japão): o que os administradores de organizações do TiDB Cloud devem fazer com dados de conta, histórico do editor SQL e tickets de suporte
A PingCAP diz que entre 9 de setembro e 7 de outubro de 2026 (horário dos EUA) um terceiro usou credenciais roubadas para entrar em sistemas internos e copiar dados, e que o vazamento de até cerca de 50.000 registros pessoais no Japão foi constatado (aviso em japonês). As categorias que a empresa confirmou como afetadas (variam conforme o cliente) são os dados de conta do TiDB Cloud (nomes de usuário, endereços de e-mail, associações de organização e projeto, histórico de execução e erros do editor SQL e informações de consultas, ou seja, tickets de suporte), as informações comerciais e de cobrança (nomes, e-mails, nomes de empresa, telefones, pedidos, condições de pagamento, configurações de cobrança) e a parte de chave pública, criptografada, das chaves de API do TiDB Cloud. A empresa diz que não confirmou vazamento de cartões de crédito nem acesso não autorizado ao próprio TiDB Cloud, e que as chaves privadas não foram expostas. A unidade que o número mede (pessoas ou registros) não é informada. O aviso em inglês da empresa diz também que código-fonte foi obtido. Conclusão deste site: os administradores de organizações do TiDB Cloud devem trocar as chaves de API, revisar os logs de acesso, os membros e as funções, e alterar as credenciais que possam ter sido coladas no editor SQL ou em um ticket de suporte.
Acesso não autorizado ao site de empregos MyBRANDS e possível vazamento de dados pessoais (até cerca de 135 mil contas): o que devem fazer candidatos e contatos de empresas com nome, dados de contato e histórico profissional
A iDA Co., Ltd. (Japão) anunciou em 30 de outubro de 2026 que um acesso não autorizado de terceiro ao ambiente de servidores de seu site de empregos MyBRANDS pode ter vazado as informações de pessoas cadastradas, tanto candidatos quanto contatos de empresas. Segundo a empresa, uma chave de acesso à nuvem usada por uma contratada foi usada indevidamente por um terceiro em 21 e 22 de outubro, e em 26 de outubro ela soube que havia registros de envio de dados ao exterior a partir de uma cópia do banco de dados. Não conseguiu confirmar o que continham os dados enviados, então notifica partindo do princípio de que toda a informação que mantinha está incluída. O alcance é de até cerca de 135 mil contas em 30 de outubro, incluindo pessoas que já saíram do serviço. As informações são nome, endereço de e-mail, telefone, perfil (como o histórico profissional) e senha de login (armazenada como valor transformado), e variam conforme o cadastro. Ela não mantinha dados de cartão de crédito nem de conta bancária, que portanto não estão incluídos. Nome, e-mail, telefone e endereço eram armazenados criptografados, mas a chave para descriptografá-los também pode ter sido levada, segundo a empresa. Até agora não foi confirmado uso indevido (dano secundário). Conclusão deste site: troque a senha em qualquer outro serviço que compartilhe a do MyBRANDS (contatos de empresas, também em sistemas internos) e confira por um canal oficial as mensagens que se apresentem como de recrutador ou de abordagem direta, e não pelos links ou números delas.
Incidente de segurança da Northflank (outubro de 2026): variáveis de ambiente armazenadas que devem ser tratadas como descriptografadas e uso indevido de chaves de API de IA
Em 30 de outubro de 2026 (UTC), a plataforma de implantação em nuvem Northflank publicou um incidente de segurança em sua página de status. Um alerta de ameaça de um fornecedor de segurança chegou às 11:43 UTC; a empresa implantou correções a partir das 12:02 UTC, orientou os clientes a trocar as variáveis de ambiente às 13:40 UTC e, às 13:58 UTC, a presumir que todas as variáveis de ambiente foram descriptografadas. Às 15:12 UTC sua página de status já registrava que vários usuários relatavam que suas chaves de IA haviam sido usadas e, às 23:38 UTC, dizia que usuários relataram uso não autorizado de chaves de API de IA armazenadas na plataforma. Em 31 de outubro habilitou os registros de auditoria para todos os clientes e foi liberando a rotação de segredos dos complementos, um tipo de cada vez. Em uma atualização de 2 de novembro (11:09 UTC, status Monitoring) disse acreditar ter contido o ataque na hora seguinte ao primeiro alerta, que as cargas de trabalho em execução não foram afetadas e que não viu sinais de que as cargas de trabalho ou seus dados tenham sido acessados, e que o ataque parecia focado em segredos do plano de controle. Auditores forenses independentes estão revisando, ela revogou tokens de acesso, sessões, integrações com sistemas de controle de versão (VCS) e funções IAM entre contas (portanto os usuários precisam entrar de novo e reconectar as integrações), e prometeu uma análise de causa raiz quando os achados forem confirmados. Em uma atualização de 6 de novembro (10:09 UTC) disse que a primeira descriptografia conhecida de segredos ocorreu entre 02:39 e 03:08 UTC de 30 de outubro, antes do primeiro alerta, às 11:43 UTC; que o exploit foi corrigido em até 60 minutos após o aviso e os clientes foram notificados em até duas horas; que não encontrou indício de que cargas de trabalho de clientes ou seus dados tenham sido acessados; e que trabalhou com provedores upstream para revogar credenciais quando possível. A revisão forense continua. O número de clientes afetados, como o atacante entrou e quais provedores de IA estiveram envolvidos não foram divulgados. Avaliação deste site: revogue todos os segredos que você guardou na Northflank no serviço que os emitiu, depois confira o uso e a cobrança de cada provedor de IA e defina limites de gastos.
Incidente de segurança da Zeabur (outubro de 2026, 3,22 milhões de variáveis de ambiente lidas): quais segredos trocar e o que os usuários devem fazer
Em 19 de outubro de 2026, a plataforma de deploy de aplicações Zeabur publicou um relatório preliminar sobre um incidente de segurança ocorrido em 14 e 15 de outubro (UTC). A empresa afirma que um invasor usou credenciais internas vazadas da Zeabur para entrar em seu cluster compartilhado, em alguns Dedicated Servers e em sistemas internos e, por fim, leu o banco de dados da plataforma entre 16:10 e 16:47 UTC de 15 de outubro. Ela confirmou que foram lidos 3.218.965 registros de variáveis de ambiente (nomes e valores) e dados de 321.810 contas (e-mail, nome de usuário, número de telefone e outros), além de 566 chaves de API do zSend, que ela revogou. A empresa diz que a causa raiz é responsabilidade da Zeabur: credenciais administrativas de longa duração eram armazenadas em texto puro e podiam ser usadas a partir da internet. Ela pede a todos os usuários que substituam todas as senhas e chaves armazenadas na Zeabur, mesmo que já as tenham substituído após outro incidente em agosto. A Zeabur havia anunciado em 17 de outubro que encerrará as atividades em 31 de dezembro de 2026 e, em 22 de outubro, fixou 30 de novembro de 2026 como prazo para pedidos de ressarcimento de perdas causadas pelo incidente. A opinião deste site: trate todo segredo que você já colocou em uma variável de ambiente da Zeabur como conhecido por outra pessoa, revogue-o primeiro no serviço que o emitiu e verifique faturas e logs a partir de 14 de outubro.
Acesso não autorizado à Nikkei (cerca de 1,83 milhão de registros): nomes, e-mails e outros dados vazaram em cerca de 150 mil — o que os usuários devem fazer
Em 16 de outubro de 2026, a Nikkei Inc., editora de jornais do Japão, anunciou que um serviço de nuvem usado por ela no desenvolvimento de sistemas foi acessado sem autorização e que, até o dia 16, cerca de 1,83 milhão de registros de informações pessoais haviam vazado. Cerca de 150 mil continham ao menos um dos seguintes dados: nome, endereço de e-mail, endereço postal, número de telefone ou data de nascimento, e cerca de 120 mil deles incluíam um endereço de e-mail. Os cerca de 1,68 milhão restantes eram apenas identificadores que, sozinhos, não identificam uma pessoa. Não havia informações de cartão de crédito. Segundo a empresa, as credenciais de acesso ao serviço de nuvem foram roubadas de alguma forma, e o acesso não autorizado ocorreu da madrugada à manhã de 7 de outubro. A empresa desativou as credenciais usadas e comunicou o incidente à Comissão de Proteção de Informações Pessoais do Japão em 11 de outubro. Até o dia 16, não foram confirmados danos secundários, como uso indevido dos dados, nem queda de sistema ou adulteração de dados. A empresa diz que notificará individualmente as pessoas cujos dados forem confirmados como vazados. A empresa do grupo Nikkei National Geographic informou em 22 de outubro que havia informações de alguns usuários de seus serviços. Não foram divulgados quais serviços têm usuários afetados, as quantidades por tipo de dado nem como as credenciais foram roubadas. Avaliação deste site: não use links nem números de telefone de e-mails ou ligações que digam ser da Nikkei; confirme no site oficial.
Variáveis de ambiente da Railway possivelmente expostas (outubro de 2026, até 1,85% dos workspaces): quais segredos rotacionar e o que os usuários devem fazer
Em 21 de outubro de 2026 (UTC), a Railway anunciou que detectou atividade anômala envolvendo sistemas que armazenam variáveis de ambiente de clientes, e que um terceiro não autorizado pode ter acessado variáveis de ambiente criptografadas e, em parte delas, obtido o conteúdo descriptografado. Segundo o relatório preliminar datado de 22 de outubro (disponibilizado às 16:38 UTC de 23 de outubro, conforme a página de status), o ataque ocorreu de 13:58 UTC de 20 de outubro até 03:32 UTC de 22 de outubro. Começou com tentativas de escalonamento de privilégios na infraestrutura de build; em 21 de outubro, credenciais do ambiente de CI foram usadas e um subconjunto de variáveis de ambiente criptografadas foi descriptografado. No máximo 1,85% de todos os workspaces (cerca de 100.000 workspaces, segundo a empresa) tiveram algumas variáveis de ambiente potencialmente comprometidas. A empresa afirma que nenhuma conta de usuário da Railway foi acessada e não descartou o acesso ao código-fonte até o relatório final. O invasor parece ter buscado chaves de API de provedores de IA. A Railway recomenda que todos os usuários rotacionem os segredos armazenados antes de 21 de outubro, removam o acesso público de rede aos bancos de dados e revisem os logs de auditoria do GitHub e de registries (como o Docker Hub). Conclusão deste site: mesmo que você não tenha sido contatado, trate os segredos armazenados na Railway como expostos, reemita-os na origem e faça o redeploy antes de revogar os valores antigos.
O que é shadow AI? Os riscos do uso de IA que a empresa não enxerga, e o que organizações e pessoas devem fazer
Shadow AI é o uso, no trabalho, de ferramentas de IA que a empresa não aprovou ou não gerencia (chatbots, extensões de navegador com IA, assistentes de programação, IA de atas de reunião, agentes de IA conectados a contas de trabalho). É a forma de IA da shadow IT. Os principais riscos: os dados confidenciais ou pessoais inseridos podem ser armazenados pelo provedor e, conforme o plano e as configurações, usados para treinamento (os termos para consumidores e para empresas diferem); concessões OAuth e chaves de API dão a ferramentas de terceiros acesso a e-mail e drives; erros nas respostas e problemas de licença; e obrigações de leis de privacidade e de auditoria. Só proibir empurra o uso para fora da vista, então ofereça uma ferramenta aprovada com termos empresariais que não treinam com as entradas, uma regra curta sobre quais dados podem ser inseridos, SSO e controles de administrador, revisão regular de concessões OAuth e extensões, e um canal para perguntar antes.
Subdomain takeover (DNS pendente): como um registro DNS esquecido deixa atacantes usarem o seu domínio
Apague um recurso na nuvem sem apagar o registro DNS e você tem uma entrada pendente: qualquer um pode assumir aquele subdomínio criando um recurso com o mesmo FQDN. Os seus servidores ficam intactos enquanto um subdomínio legítimo serve conteúdo do atacante. O dano não é só aparência — é comum os apps exporem cookies de sessão a subdomínios curinga, então o subdomínio sequestrado consegue lê-los. E a documentação rejeita explicitamente a crença de que um certificado protege você. A correção é colocar a ordem de exclusão nos seus procedimentos e ferramentas, em vez de depender da memória.
O que é SSRF (Server-Side Request Forgery)
SSRF abusa de URLs vindas de entrada externa para fazer um servidor acessar recursos internos (IPs internos, metadados de nuvem). Se você busca URLs, precisa de uma allowlist de destinos, bloqueio de alvos internos e proteção contra contornos por redirecionamento/DNS rebinding. Foi a causa do vazamento da Capital One.
Vazamento da Capital One (2019) — como um SSRF expôs mais de 100M de registros, e como se defender
Um único SSRF alcançou o endpoint de metadados → credenciais IAM temporárias com privilégios excessivos → cópia em massa do S3, vazando cerca de 106M de registros. Cada etapa poderia tê-lo interrompido. No seu ambiente: IMDSv2, IAM de menor privilégio e uma allowlist para requisições de saída.