相次ぐ情報漏えい。JPCERT/CCの注意喚起から考える、各領域でできる対策

みなさん、こんにちは、こんばんは、おはよーございます。
丸紅I-DIGIO 吉正です。

最近、あまりにも情報漏えいインシデントが多すぎます。

2026年10月8日、JPCERT/CCからも注意喚起が発報され、これは拡散すべき情報であると考えます。ぜひご確認ください。

何が起きているのか

9月末以降、日本企業での不正アクセスや情報漏えいの発表が相次いでおり、中には著名サービスも含まれていることから注目を集めています。

氏名・住所などの個人情報をはじめとして、免許証画像の流出等も発生していることから、二次被害含め不安が広まっています。

攻撃発生、検知、調査完了、公表の時期は事案ごとに異なり、9月末に情報開示が集中した面が大きいという側面もありますが、それにしても多すぎないか、というのが正直な感想です。

具体的にどんなインシデントがあったのかについては、有志の方がインシデントをまとめてくれていますので、参考にしてください。

政府としての動きも

日本政府としても、緊急で関係省庁会議を行い、サイバー対策を強化する方針を明確にしています。

また、AI活用で名高い、チームみらいの安野貴博党首も、サイバー攻撃能力の高いAIモデルが拡散しているとの懸念を示しています。

JPCERT/CCからの注意喚起

本題です。
本件について、JPCERT/CCが2026年10月8日に注意喚起を公表しました。

上記の記事では、技術情報はまだ限られているとしながら、把握している攻撃手法や対策が整理されています。BIツールや従業員向け管理システムでも被害が発生している点は、気に留めたいところです。

各セキュリティ領域で「企業の情シス・セキュリティ担当者」にできること

ここからは、注意喚起を踏まえ、実装に使える技術も含めて対策を領域別にざっと整理してみます。

SASE／SSE

主にZTNAを活用し、管理画面や社内向けBIツールへの接続を、許可した利用者や条件を満たす端末に限定する。アプリごとに接続できる範囲を絞る。

認証・ID

管理人のログインは多要素認証（MFA）で強化する。APIキーやトークンについても、必要最小限の権限、有効期限、漏えい時の無効化手段を確認する。

WAF・API保護

WAFによる攻撃リクエストの検知・遮断や、APIのリクエスト量の制限を検討する。アプリ側では、要求ごとに対象データや操作への権限を確認する。

脆弱性・設定管理

修正アップデートを適用し、不要な管理機能のインターネット公開を停止する。設定ファイルやバックアップを外部から取得できないかも点検する。

データ保護

DSPMなどで機密データの所在や保護の不足を把握する。DLPでは、検査対象となる通信経路で機密情報の持ち出しを検知・制御する。

監視・初動対応

認証・API・アプリのログを監視し、不審なアカウント作成や権限変更などを調査につなげる。検知後の連絡先や、アクセス停止・トークン無効化の手順も確認する。

対策同士をつなげて考える

昔からよく言われること。
セキュリティは多層防御が基本です。

例えば、ZTNAで管理系システムへの入口を絞り、MFAで本人確認を強化する。その先では、API側で「この利用者が、このデータを取得・変更してよいか」を確認する。接続、認証、操作権限には、それぞれ役割があります。

また、保存義務や利用目的を確認し、不要になったデータを残さないことも、今回挙げられている対策のひとつです。そのデータ本当に持ち続ける必要がありますか？という視点も忘れないようにしたいところです。

チーム一丸となって対応する

自分の担当範囲だけでは、確認しきれない項目もあると思います。

恐らく各社様、経営層含め注目度を集めていると思いますので、ぜひ情シスだけでなく、セキュリティ・開発・運用・委託先など含め共有し、「うちではどうなっているか」を持ち寄って見ていただきたいです。

見える・わかる・扱える状態とすることが、セキュリティ対策の第一歩になります。

まとめ

高度で巧妙なサイバー攻撃への対処は、決して簡単ではありません。

ただ一方で、最近相次いでいるインシデントを眺めていると、脆弱性への対応、公開範囲の見直し、適切な権限管理といった、基礎・基本を着実に押さえることの重要性を改めて感じます。こうした対策を日々の運用の中で徹底することが、高度な攻撃に備えるうえでも土台になるのだと思います。

今回の注意喚起は、すべての事案が同じ原因・手口だと示したものではありません。詳細や今後の更新は、ぜひ原文でご確認ください。

ご質問やご相談は、こちらからお気軽にどうぞ。

#丸紅IDIGIO #IT #セキュリティ