Japan's Four Major 2026 Data Breaches (KDDI, Aflac, Digital Agency, Sakura): Different Ways In, the Same Fix — Better Detection

One of the causes Aflac named was that "functions to monitor and control large volumes of data queries in a short time were lacking". Give every API or screen that returns customer data a cap on records per request and per hour, plus an alert to a human as usage approaches the cap. Even with a valid login, pulling tens of thousands of records in a short time does not look like how people use a system. How to decide what to count, per whom, and up to what number, is covered in rate limiting and abuse control.

There are three layers where you can measure.

In the application: count records per account inside the search, listing and export paths; this is the only layer that knows who pulled how much.
In front of it: nginx limit_req or a CDN rate-limiting rule, capping requests per second or minute per endpoint.
In the platform: Google Workspace’s alert centre and Microsoft 365’s audit log and alert policies can notify on bulk downloads and exports (what you get depends on your plan).

Start with one endpoint: the one that returns the most records. Give it a per-account hourly cap and an alert at 80% of that cap. One endpoint that actually pages a human beats a complete design that is still being written.

The first item in Aflac's remediation is stronger "authentication at access and authorisation at data query". Whether someone could log in (authentication) and whether they may see a particular record (authorisation) are separate questions, and if the second is not checked record by record, a properly logged-in user can query other people's data. The difference is explained in authentication vs authorisation, and the classic flaw in IDOR.

In the Sakura Internet case, access to the sales management system began about three years before it came to light. If the logs for that period are gone when you notice, you can say neither what happened nor what did not. Sakura too listed a review of log scope and retention. If storage only allows a few weeks, a realistic split is to keep at least authentication and data-query logs for much longer.

A number to anchor on: the payment-card standard (PCI DSS) requires 12 months of retention with the most recent three months immediately available. Even outside payments, that is a usable starting point.

Keep at least three kinds: authentication (successes and failures), data queries and exports, and administrative actions. Web-server access logs alone will not tell you who took how many records.

The flaw exploited in the KDDI case was one the vendor itself did not know about when it was found. No fix existed at the time. Since some intrusions cannot be prevented even with perfect patching, the ability to notice suspicious activity and outbound traffic on servers — the EDR KDDI deployed to every server is one example — is what remains.

None of this means preventing intrusion matters less. The Digital Agency case came in through a VPN appliance vulnerability. Not leaving known vulnerabilities open is still the most cost-effective defense there is. For VPN appliances, see VPN appliances are the main way in for ransomware; for ordering the work, see prioritising with CVSS, EPSS and KEV.