日本企業のセキュリティ侵害から考える認証情報と権限の守り方

2025年9月29日にシステム障害が発生し、同日、初報が公表されました。2026年2月18日の報告によると、攻撃者は障害の約10日前に拠点のネットワーク機器を経由して侵入しています。正確な侵入日時は分かっていません。同社は、パスワードの弱点を利用して管理者権限が奪取されたとみていますが、機器の製品名や具体的な悪用手法は報告に記載していません。[1][2]

複数のサーバー等が暗号化され、一部の従業員端末からデータが窃取されたことは確認されています。受注・出荷業務にも影響しました。2026年7月17日には漏えいのおそれがある個人情報の範囲が修正されましたが、サーバー内の個人情報が外部に流出した事実は未確認とされています。[2][3]

公表された再発防止策には、リモートアクセスVPN装置の全面廃止、ネットワーク分離、認証・権限管理とEDRの強化、復旧訓練が含まれます。[2]

2025年10月19日にランサムウェアによる障害を検知し、初報を公表しました。12月12日の調査報告で確認されたのは、例外的に多要素認証（MFA）が適用されていなかった委託先向け管理者アカウントの不正利用です。認証情報が漏れた方法は解明されておらず、VPN機器の脆弱性を悪用した侵入の痕跡も確認されていません。[4][5]

被害は物流停止と情報流出に及び、バックアップも暗号化・削除されました。同社は、全リモートアクセスへのMFA、24時間365日の監視、権限管理とバックアップの見直しを対策として公表しています。[5]

2026年7月30日には、漏えいのおそれを否定できない個人情報約60万件への追加通知が発表されました。この追加分の漏えいや不正利用は確認されていません。通知対象を追加したもので、新たなシステム侵害が起きたという発表ではありません。[6]

2026年4月2日にGitHubへの不正アクセスが発生し、翌3日に検知・初報、6月2日に調査結果が公表されました。従業員のGitHub認証情報が個人開発用サーバーに意図せず置かれ、悪用されたことが確認されています。同社は、GitHub上で閲覧可能になった情報から別の認証情報が探索・取得され、社内業務用クラウドの管理領域に侵入されたと判断しています。[7][8]

認証情報等の取得と、個人情報を含むデータ1件のクエリ出力は確認されています。個人情報ファイルが外部へ転送された痕跡は未確認ですが、ログが不足しているため、閲覧された可能性は否定できないとしています。[8]

同社は、認証情報の無効化・更新、権限を限定した認証方式への移行、監査ログと監視体制の強化を実施したと報告しています。[8]

事例を自社の点検に使うなら、認証情報を一つ失った状態で、別のシステムや管理領域にどこまでアクセスできるかを確かめます。以下は公表内容から考えた対策で、各社の未公表の構成や被害原因を推定するものではありません。

点検箇所を、接続、権限、データ操作、復旧に分けて表にしました。3社すべてで、表にある攻撃段階が確認されたわけではありません。

表は横にスクロールできます。

まず、MFAが適用されていないアカウントと、その例外を認めた理由を確認します。人の認証にはフィッシング耐性のある方式を検討し、自動処理に人の共有IDや長期トークンを渡す構成は避けます。対応するCI環境なら、OIDCで短期間だけ有効な認証情報を使えます。ただし発行元、実行するワークロード、接続先の条件を限定する必要があります。有効期間を短くしても、広い権限を許せば、その間にできる操作は減りません。[9]

不正利用が分かった後の対応も、パスワード変更だけでは完了しません。有効なセッションやトークンを失効させ、追加されたIDや権限を点検する手順が必要です。その経緯を追えるよう、端末、ID基盤、クラウドの操作履歴を突き合わせ、ログは業務システムとは別の管理権限で保管します。ログ収集が止まったこと自体も通知対象にします。

アスクルでは、バックアップの暗号化・削除が復旧にも影響しました。自社の備えを確認する際は、業務管理者のIDが不正利用されてもバックアップを削除できないか、実際の権限で試します。削除・上書きを制限した保管とオフライン保管を環境に合わせて使い、隔離した環境で復元できることと、業務再開までの所要時間を確かめます。[5][10]

業務システムを操作するAIエージェントにも、接続先で使うIDと操作権限の設計が必要です。今回参照した資料では、3件の事件で攻撃者がAIを使ったかどうかは確認できません。ここで扱うのは、エージェントに権限を渡す側の設計です。

文書やツールの出力に「外部の宛先へ送る」と書かれていても、それだけで送信を許可してはいけません。操作を実行する前に、依頼者、操作の種類、対象、送信先をモデルの外で検査する設計を提案します。削除・公開・権限変更では、影響に応じて承認を求め、承認された対象と実際の操作を照合します。接続元や所有者だけで信頼せず、操作先ごとに認証・認可を確かめる考え方を、AIの実行にも適用します。[11]

監査ログでは、依頼者と使用ID、許可判断、実行結果を対応付け、秘密情報そのものは記録しない設計を提案します。Noah's ArkのGatewayは開発中であり、これらは設計上の提案です。掲載企業での導入や、防御効果の検証を報告するものではありません。

The disclosures from Asahi Group Holdings, ASKUL and CAMPFIRE describe different paths into company systems. ASKUL confirmed misuse of an administrator account exempt from MFA. CAMPFIRE traced misuse of a GitHub credential to a personal development server. Asahi believes password weaknesses were used to gain administrator privileges.[2][3][5][8]

Some details remain unresolved. ASKUL could not establish how the credentials leaked. CAMPFIRE confirmed a query output containing personal information, but found no traces of external file transfer; missing logs leave possible viewing unresolved. Asahi distinguishes confirmed leaks from employee devices from possible exposure of personal information on servers. The cited material does not establish attacker use of AI.[2][3][5][8]

For a practical review, start with what a compromised identity can reach: other systems, privileged operations, data and backups. Check MFA exceptions, limit machine credentials and their permissions, protect audit logs with separate administration, revoke active sessions and test restoration in isolation. For AI agents, check authorization outside the model and match approved actions to the operations actually executed.[9][10][11]

This article reviews public material available as of October 7, 2026. Noah's Ark did not conduct the named companies' forensic investigations or assessments and reports no original vulnerability discovery. Gateway is under development. The measures discussed here are design proposals, with no claim of deployment at these companies or validated protection.