Guias de Segurança
Onde fica o mínimo de segurança de uma organização? Seis prioridades deduzidas dos incidentes reais do Japão em 2026
O mínimo de segurança para organizações, deduzido dos incidentes reais do Japão em 2026: dispositivos expostos, contas de terceirizados, volume, logs, dados e repriorização.
Para quem: empresas e organizações com funcionários e terceirizados que precisam decidir onde fica o seu «mínimo» de segurança. Desenvolvedores independentes e projetos pequenos devem ver o checklist básico de segurança para desenvolvedores independentes. Este artigo retrabalha como controles organizacionais o que este site analisou a partir dos próprios comunicados de cada organização sobre os incidentes do Japão em 2026. Não inclui passos de ataque.
Seis buracos que os incidentes revelaram
Todos são casos que este site analisou a partir dos comunicados oficiais das organizações (as análises detalhadas estão nas versões em japonês e inglês).
| O que foi divulgado | O buraco revelado | O mínimo organizacional |
|---|---|---|
| Agência Digital: entrada por uma vulnerabilidade em dispositivo VPN; em entrevista coletiva, explicou-se que as correções estavam sendo aplicadas por turnos | Corrigir dispositivos expostos «na fila» | (1) Fechar dispositivos de entrada com prazo |
| Agência Digital: detectado acesso em massa a arquivos de um servidor pela conta de um operador de manutenção | Permissões e vigilância de contas que não são de funcionários | (2) Restringir contas de manutenção, terceirizados e ex-funcionários |
| Aflac: o ataque parecia uso normal e não foi detectado de imediato; faltavam funções para vigiar e controlar consultas em massa em pouco tempo | O volume de requisições válidas uma a uma | (3) Vigiar volume e horário |
| Sakura Internet: o acesso não autorizado ao sistema de vendas ocorreu de abril de 2023 a março de 2026; entre as medidas, revisar o alcance e a retenção dos logs | Sem como olhar para trás ao perceber | (4) Manter logs o bastante |
| Gyazo: os metadados vazados eram majoritariamente anteriores a janeiro de 2019 | Dados mantidos depois de deixarem de ser necessários | (5) Não guardar dados desnecessários |
| Adobe Commerce: correção publicada em 11 de agosto, exploração confirmada (KEV) 44 dias depois, com o aviso ainda dizendo «prioridade 2, sem exploração conhecida» | Adiar confiando na avaliação da publicação | (6) Repriorizar pelo KEV |
Como ler esta tabela: não para culpar, mas para se verificar
Cada organização investigou após o incidente e publicou a causa e as medidas. Este site usa esses relatórios não como história alheia, mas como checklist de «temos o mesmo buraco?». Nenhum desses buracos pertence só a organizações especialmente descuidadas. No caso da KDDI, a entrada foi uma vulnerabilidade que nem o próprio fornecedor conhecia, então a premissa de que a entrada pode ser vedada com perfeição não se sustenta. É exatamente por isso que os itens (2) a (5) — o lado de «não deixar se espalhar depois de entrar» — fazem parte do mínimo.
Os seis mínimos e o primeiro passo de cada um
(1) Feche os dispositivos expostos à internet com prazo
Dispositivos VPN, gateways de área de trabalho remota, painéis de administração de firewall: liste todo dispositivo acessível diretamente pela internet, com modelo, versão e responsável pela atualização. Nas estatísticas da Agência Nacional de Polícia do Japão, 61 de 92 respostas válidas sobre a via de infecção por ransomware foram dispositivos VPN.
Primeiro passo: para cada dispositivo da lista, defina um número — quantos dias você permite antes de fechar uma vulnerabilidade confirmada como explorada (KEV). Corrigir «por turnos» é o mesmo formato do caso da Agência Digital.
(2) Restrinja as contas de manutenção, terceirizados e ex-funcionários, e deixe-as visíveis
Toda organização tem contas de pessoas que não são funcionárias: empresas de manutenção, terceirizados, gente que já saiu. Elas costumam receber permissões amplas por conveniência, e não fica claro quem é o dono.
Primeiro passo: liste todas as contas de não funcionários e atribua a cada uma um responsável interno e uma data de expiração. Depois, em ordem: habilitar só quando em uso, restringir a origem de conexão e exigir autenticação de dois fatores resistente a phishing. Coloque o desligamento da conta no mesmo formulário da admissão.
(3) Vigie o volume e o horário
No caso da Aflac, o ataque parecia igual ao uso normal. Se cada consulta é válida isoladamente, verificá-las uma a uma não o detém. O que resta é quantos registros saíram por hora e a atividade à noite e nos fins de semana.
Primeiro passo: na função que mais devolve dados de clientes, adicione um limite por conta e por hora e um alerta que chegue a uma pessoa específica aos 80% desse limite. Em servidores de arquivos e armazenamento em nuvem, alerte para downloads em massa várias vezes acima do normal.
(4) Mantenha os logs o bastante para olhar para trás
No caso da Sakura Internet, o acesso não autorizado começou cerca de três anos antes de ser detectado. Sem logs desse período, não dá para dizer nem o que aconteceu nem o que não aconteceu.
Primeiro passo: mantenha por pelo menos 12 meses três tipos: autenticação (sucessos e falhas), consultas e exportações de dados e ações administrativas, usando como referência o padrão de cartões de pagamento PCI DSS. Se faltar espaço, proteja esses três antes dos logs de acesso web.
(5) Não guarde dados de que não precisa mais
No caso da Gyazo, os metadados vazados eram sobretudo informações ligadas a imagens enviadas anos antes. O tamanho de um vazamento é definido por quantos dados você tinha naquele momento. Dados que você não tem não podem vazar.
Primeiro passo: para cada tipo de dado de clientes, escreva uma linha: para que serve e até quando é guardado. O que você não conseguir justificar nessa linha é candidato a exclusão ou anonimização. Verifique também se não restam dados de usuários que cancelaram (no caso da Sakura Internet, os dados de associado eram mantidos após o cancelamento, a menos que a saída fosse solicitada à parte).
(6) Repriorize pelo KEV, não pela avaliação da publicação
Na Adobe Commerce, o aviso da correção dizia «prioridade 2, sem exploração conhecida», e 44 dias depois a CISA confirmou a exploração. No núcleo do WordPress, foram três dias.
Primeiro passo: prepare uma forma de ser avisado quando um produto que você usa entrar no KEV, e torne regra reordenar a fila de correções quando isso acontecer. O procedimento está em Qual CVE corrigir primeiro: CVSS, EPSS e KEV.
Estreitar a entrada
(1) fechar dispositivos expostos com prazo / (6) repriorizar pelo KEV
Limitar até onde um invasor chega
(2) contas de manutenção, terceirizados e ex-funcionários / (5) não guardar dados desnecessários
Perceber a invasão e poder olhar para trás
(3) vigiar volume e horário / (4) manter logs o bastante
O que muda entre uma pessoa e uma organização
O que uma organização acumula (onde os incidentes começam)
- Contas que não são suas (manutenção, terceirizados, ex-funcionários)
- Dispositivos de que ninguém se lembra (a VPN que o instalador montou, um ambiente de teste antigo)
- Anos de dados armazenados (associados que cancelaram, metadados antigos)
- Uma vigilância de «alguém deve estar olhando» (a ferramenta existe; o responsável, não)
O que o mínimo organizacional faz
- Dá a tudo um responsável interno e uma expiração
- Gerencia dispositivos expostos com uma lista e prazos de correção
- Registra por que e até quando os dados são guardados, e apaga o que não se justifica
- Configura alertas com um número e um destinatário, e testa se chegam
A visão deste site: o mínimo é decidir quem percebe, por qual número e quando
Colocando os relatórios em fila, chama a atenção que muitas organizações já tinham produtos de segurança. A Aflac tinha funções para detectar e bloquear acessos não autorizados, e fez revisões de projeto e testes de invasão antes do lançamento. Mesmo assim o ataque não foi contido, porque não tinha a forma que previam.
Por isso este site recomenda medir o mínimo de uma organização não por «o que implantamos», mas por «está decidido quem percebe, acima de qual número e quando». A lista de ferramentas implantadas ajuda numa auditoria; na noite do incidente, só um alerta com limite e destinatário faz um telefone tocar. Conferir que o alerta não continua indo para o e-mail de um ex-funcionário já é um primeiro passo.
Pessoas e governança — para os seis continuarem funcionando
Os seis mínimos não são tarefas pontuais. Pessoas mudam de função, dispositivos se multiplicam, dados se acumulam. Para mantê-los, tenha pelo menos o seguinte.
- Um responsável: quem mantém a lista e os prazos de cada um dos seis.
- Um inventário trimestral: atualizar as listas de dispositivos, contas de não funcionários e dados (a abordagem está no checklist de inventário).
- Um treinamento que comece por «como verificar um contato»: depois de qualquer incidente, aumentam as mensagens que se passam pela organização. Ensine funcionários e clientes a conferir pelo site oficial.
- Colocar nos contratos com fornecedores o tratamento de contas e logs: o acesso de manutenção e de terceirizados não é gerenciado por ninguém se o contrato não disser quem.
Leia a seguir
- Decidir: Qual CVE corrigir primeiro: CVSS, EPSS e KEV
- Contas: qual método de 2FA é mais seguro / o checklist de inventário
- Versão individual: o checklist básico de segurança para desenvolvedores independentes
- Casos passados: o vazamento de dados da Benesse (abuso interno em terceirizado) / o ransomware da KADOKAWA / Niconico (sem segmentação, propagação para toda a empresa)
FAQ
QPor onde uma organização deve começar na segurança?
O mais seguro é começar por onde incidentes reais romperam a defesa. Os grandes incidentes do Japão em 2026 revelaram uma vulnerabilidade em dispositivo VPN (a Agência Digital), acesso em massa a arquivos de um servidor pela conta de um operador de manutenção (o mesmo caso), consultas em massa em pouco tempo que não puderam ser contidas (Aflac) e cerca de três anos de acesso não autorizado sem detecção (Sakura Internet). A partir disso, este site define seis mínimos: dispositivos expostos, contas de manutenção e terceirizados, vigilância de volume, retenção de logs, dados que não se guardam e repriorização.
QQual a diferença para o checklist de desenvolvedores independentes?
Organizações acumulam contas que não são delas (terceirizados, empresas de manutenção, ex-funcionários), dispositivos de que ninguém se lembra e anos de dados armazenados. A maioria dos incidentes começa nessas coisas sem dono claro. A versão individual trata de proteger suas próprias chaves e segredos; a versão organizacional, de dar um dono ao que não tem.
QComprar um EDR ou um SIEM não basta?
Produtos são um meio, não o mínimo. A Aflac informou que tinha funções para detectar e bloquear acessos não autorizados, mas não conseguiu detectar esse ataque de imediato porque o acesso parecia uso normal. O que importa é decidir acima de qual número, para quem e quando sai um alerta — e testar que ele realmente chega.
QPequenas empresas deveriam fazer o mesmo?
As seis ideias valem para qualquer porte. Com pouco orçamento ou pessoal, comece por três: uma lista de dispositivos expostos à internet, como VPNs, com prazo de correção; um inventário de contas de manutenção e terceirizados; e um limite por hora com alerta na função que mais devolve dados.