PR

AIの高性能化でサイバー攻撃はどう変わる?企業の情報漏洩と基本対策

セキュリティ

AIを使った攻撃が国内でも確認されています。企業が見直したいのは、未更新のシステムやAPIの権限不備など、攻撃に利用される弱点です。直近の漏えい事例から、攻撃の変化と点検する箇所を整理します。

2026年10月17日時点の公表情報に基づきます。事例は9月17日〜10月17日の公表分から選んでおり、攻撃の発生日とは異なります。

AIは調査や弱点探しを効率化する

JPCERT/CCは10月15日、攻撃者がAIを使い、既知の脆弱性の探索やAPI経由の攻撃を行っていたと公表しました。JPCERT/CCの調査結果

AIが情報収集、偽メッセージや攻撃用コードの作成を支援する例
英国国家サイバーセキュリティセンター(NCSC)の評価を基にした利用例。作業時間や成功率を示す図ではありません。

NCSCも、AIが既存の攻撃を効率化し、脆弱性の公表から悪用までの時間をさらに短くすると見込んでいます。企業には、更新や点検を急ぐ必要性が増しています。NCSCの評価

ただし、今回取り上げる各社の被害で、AIの利用が個別に証明されたわけではありません。 使われたAIが無料だったか、AIだけで攻撃の全工程を実行したかも、この調査からは分かりません。

公開アプリから、裏側のサーバーが狙われる

情報通信研究機構(NICT)は10月13日、公開Androidアプリを解析し、接続先のサーバーを狙う「A2B攻撃」を公表しました。NICTの注意喚起

APIは、アプリがサーバーへ情報の取得や操作を依頼する窓口です。アプリから接続先や通信の仕組みを調べられ、サーバー側に弱点があると攻撃につながります。

NICTの注意喚起を基にした概念図。すべての被害がこの流れで起きたわけではありません。

画面に操作ボタンを出さない、APIの場所を案内しないといった対策だけでは不十分です。 サーバー側で、利用者と操作権限を確認する必要があります。同様の問題は、iOSアプリやWebサービスでも起こり得ます。NICTの解説

直近の漏えいでは、異なる原因が報告されている

各社の公式発表では、APIの不正利用、管理者アカウントの侵害、設定不備などが報告されています。原因の詳細が調査中の事例もあります。

公表日・サービスなど公表された主な規模手口・原因
10月15日・ソースネクスト会員情報22,519,960件が流出した可能性会員情報取得APIの不正利用。原因の詳細は調査中。公式発表
10月9日・skyticketサーバーへの不正アクセスで約1,464万件流出など管理機能の不正操作、業務管理システムの脆弱性、予約ページのアクセス制御不備。公式発表
10月6日・スカラコミュニケーションズ「i-ask」最大5社、延べ713,126件が漏えいした可能性管理サイトへの不正ログイン後に不正プログラムを設置。公式発表
10月6日・楽天ドライブ保存データ15,382アカウント分などの取得・閲覧管理用アカウントの認証情報を不正取得。公式発表
9月28日・集英社「HAPPY PLUS COMMUNITY」ブロガー2,835人分の個人情報など同社は、情報管理用ソフトウェアの設定不備を起点に、API認証情報への攻撃と不正な特権アカウント作成が行われたと説明。公式発表・PDF
10月1日・チケプラ最大107人分の情報が別の利用者に表示された可能性表示内容を一時保存するキャッシュの設定変更が原因。不正アクセスは確認されていない。公式発表
流出の確認と、流出・閲覧の可能性は区別が必要です。件数・人数・アカウント数も異なり、単純に合算できません。スカラの件数には同じ人の複数回の問い合わせを含みます。

古いログも漏えいの対象になる

skyticketは10月16日の第2報で、最大6,140人分のカード情報などの流出を公表しました。カード情報を保管しない方式へ移行した後も、古い決済ログが残っていました。暗号化に使う情報も取得され、カード情報が読み取られるおそれがあるとしています。skyticketの第2報

現在のデータベースだけでなく、移行前のデータや古いログ、バックアップにも不要な情報が残っていないか確認が必要です。

委託先の侵害が複数社へ広がることも

スカラの事例では、同じサーバー上の複数企業の情報に被害が及んだ可能性があります。

同社の公表内容を基にした概念図。実際のシステム構成を示すものではありません。

委託先に渡す情報と権限、他社の利用環境との分離、事故時の連絡体制も点検しましょう。

企業が優先して見直したい対策

JPCERT/CCは、一般向けアプリだけでなく、データ分析用のBIツールや従業員向け管理システムの被害も報告しています。社内向けの用途でも、公開範囲と権限の確認が必要です。JPCERT/CCの注意喚起

APIでは、本人確認と権限確認を行う

「認証」は本人の確認、「認可」はその人に許された操作かの確認です。ログインできても、他人の情報を見てよいとは限りません。

OWASPのAPI保護ガイドを基にした例。共有などで権限を与えるサービスでは、許可条件が異なります。

開発・保守会社には、次の3点を確認してください。

  • 他人の情報や管理者用の操作へ、不正にアクセスできないか。
  • 画面に表示しないAPIも含め、サーバー側で権限を確認しているか。
  • 正規アプリ以外からの通信でも、許可しない操作を拒否できるか。

秘密情報と大量アクセスへの備えを見直す

API認証に使う共通の秘密鍵や、長期間有効な認証情報をアプリへ埋め込まない設計にします。JPCERT/CCの推奨対策

APIの利用を許可するトークンは、権限・有効期限を絞り、漏えい時に無効化できるようにします。短時間の大量アクセスの制限と異常検知も必要です。ただし、利用回数の制限だけでは権限の不備は直りません。JPCERT/CCのAPI対策

機器・アカウント・保管データも点検する

点検するもの確認すること
管理者アカウントパスワード以外の要素も確認する多要素認証と、接続元の制限
退職者・委託先の権限不要なアカウントや接続権限の停止
VPN・サーバー・Webシステム更新状況、独自開発部分の脆弱性、不要な外部公開
サーバー間の接続侵害後に別のシステムへ被害が広がりにくい接続範囲・権限
設定変更後の動作別の利用者の情報が表示・取得されないか
保管データ法令・契約上の保存義務を確認し、不要なデータを残さない運用
JPCERT/CCの注意喚起と警察庁の対策案内、各社の事例を基にした確認項目です。必要なログには保存期間と閲覧権限を定め、暗号化したデータと鍵も両方保護します。

従業員へのフィッシング対策も続けましょう。自然な文章のメールでも、本物とは限りません。

バックアップと、被害発覚時の対応を備える

ランサムウェアには、データの暗号化と情報公開の脅しを組み合わせる「二重恐喝」もあります。

情報を盗み、データの暗号化と情報公開の脅しを組み合わせる二重恐喝の流れ
警察庁の手口解説を基にした代表例。すべての被害がこの順序で進むわけではありません。

バックアップで復旧できても、盗まれた情報は取り戻せません。 情報窃取への対策と、業務を復旧する備えは両方必要です。バックアップは攻撃で一緒に暗号化・削除されにくい場所へ保存し、復元も確認しましょう。警察庁の対策案内

USB接続の外付けハードディスクも保存先の一例です。バッファロー HD-PCG2.0U3-GWA(2TB)を楽天市場で確認できます(広告)。容量や対応OSを確認し、バックアップ後は接続を外して保管してください。Supported by Rakuten Developers

不審なアカウントや大量の情報取得を見つけたら、保守会社や専門の対応担当へ連絡し、次の対応を進めます。

  • アクセス・操作の記録を保全する。
  • 影響範囲を調べ、被害拡大を防ぐ。
  • 不正な権限を停止し、漏えいした認証情報を変更・無効化する。

更新の適用だけで、侵害後の問題まで解消するとは限りません。NICTの対策案内も参考に、侵害の有無を確認してください。

平時から連絡先と初動手順を決めておきましょう。相談先にはJPCERT/CCの対応窓口、対策の手引きにはIPAの中小企業向けガイドラインがあります。

ユーザー側の対策は?「パスワードは漏れる前提」で備える

「大手だから安心」「自分は狙われない」は禁物です。 サービス側からの流出も想定し、自分のアカウントを守る備えをしましょう。IPAの不正ログイン対策

  • MFA(多要素認証)を有効にする。 パスワードに加え、スマホなどでも本人確認する仕組みです。メール・金融・SNSなど、対応するサービスで設定しましょう。
  • パスワードを使い回さない。 サービスごとに長く異なるものを使い、1か所の流出から別のアカウントへ被害が広がるのを防ぎましょう。
  • メールやSMSのリンクからログインしない。 「情報が流出したので再設定を」と急かされても、公式アプリや登録済みのブックマークから確認を。認証コードも他人に教えないでください。

被害が出てからでは遅いこともあります。まずは普段使うメールのMFA設定を、今日確認してください。

コメント

タイトルとURLをコピーしました