彦坂菜奈子 | SQAT®.jp

2025年9月5日2025年9月28日

連載記事：企業の「攻め」と「守り」を支えるIoT活用とIoTセキュリティ
第２回　身近に潜むIoTセキュリティの脅威とは？─リスクと被害事例から学ぶ必要性

Security NEWS TOPに戻る
バックナンバー TOPに戻る

IoTの普及は企業活動を大きく変革する一方で、新たなセキュリティリスクを急速に拡大させています。スマートカメラや複合機といった身近な機器が攻撃の標的となり、情報漏洩や業務停止といった深刻な被害につながる事例も増加中です。本記事では、IoTセキュリティ特有の脅威や実際の被害事例を取り上げ、そのリスクを正しく理解することで、経営層やIT担当者が取るべき対策の必要性を明らかにします。

IoTセキュリティの特殊性

PCやサーバであればOSベンダーが月例パッチを配布し、管理者もGUIで容易に適用できます。ところが、IoTデバイスは制御用の軽量OSを採用しており、そもそも自動更新機能が実装されていない機種が少なくありません。屋外や高所に長期設置される機器の場合、物理的にアクセスしてUSB経由でアップデートする手間が大きく、結果として脆弱性が放置される確率が跳ね上がります。NIST SP 800-213は「設置場所と更新手段の乖離がIoT固有のリスクを増幅させる」と分析しています。

攻撃者がIoT機器を狙う３つの合理性

まず第１に台数の多さです。SonicWall社が公開している「2023 SonicWall Cyber Threat Report」によると、「世界のマルウェア感染端末の40％以上がIoT由来である」と指摘されています。第２に防御の甘さが挙げられます。JPCERT/CCが2024年に国内8,000台を調査*1したところ、Telnetや SSHのデフォルト認証情報がそのままのIoTデバイスが12％存在しました。第３は“隠密性”です。プリンタや監視カメラがマルウェアのC&C通信に使われても、ユーザは映像も印刷も通常どおり動くため気づきにくいという状況があります。

代表的な被害事例

2016年のMiraiボットネットはコンシューマー向けルーターとネットワークカメラに感染し、最大620GbpsのDDoSトラフィックを発生させ、米DNSプロバイダーDynを一時機能停止に追い込みました。2021年３月に表面化した Verkada社のスマートカメラ大量侵入事件では、管理者アカウント情報がGitHubに誤って公開され、テスラ工場や病院を含む15万台超の映像が外部から閲覧可能となりました。直近ではRapid7が2024年12月に公表したBrother製複合機の脆弱性（CVE-2024-22475ほか）も、認証バイパスによる遠隔コード実行が可能だったため、印刷ジョブを改ざんできるリスクが指摘されました*2

主要IoTセキュリティ事件年表（2016-2025年）

年	事件概要	影響・被害
2016	Miraiボットネットが家庭用ルーターやネットワークカメラを大量感染させ、620Gbps超のDDoS攻撃で米DNS大手Dynを一時停止*3	大規模サービス停止・インターネット障害
2017	国内外で小規模監視カメラへの不正ログインが相次ぎ、ライブ映像がストリーミングサイトに無断公開*4	プライバシー侵害・二次被害拡大
2018	スマート冷蔵庫を含む家電の脆弱性が複数報告され、メーカーが初のOTAアップデートを緊急配布*5	家電乗っ取りリスク・アップデート体制の課題顕在化
2019	スマートロックなど家庭IoT機器でデフォルト認証情報が放置され、遠隔でドア解錠される事例が報道*6	個人宅への侵入・安全確保への不安
2020	新型Mirai派生マルウェアが出現、IoT機器を踏み台にしたDDoS攻撃件数が前年比2倍に*7	ネットサービス障害・帯域逼迫
2021	Verkada社クラウド連携カメラの管理認証情報が流出し、15万台超の映像が外部閲覧可能に*8	大規模映像漏洩・企業ブランド毀損
2022	国内調査で初期パスワードのまま運用されるIoTデバイスが12%見つかり、ボット化被害が多発	ネットワーク踏み台化・社内横展開
2023	複数メーカーのスマート照明とセンサーでAPI認証不備が発覚し、遠隔操作や情報流出の恐れ*9	遠隔操作リスク・業務影響
2024	Brother製複合機に遠隔コード実行脆弱性（CVE-2024-22475など）が公表、修正ファーム未適用機が残存*10	印刷ジョブ改ざん・情報漏えい
2025	ランサムウェアが産業用IoT機器を暗号化し、生産ラインを停止させる事例が欧州で初報告*11	業務停止・身代金要求

※上記事例ソースはすべて一次ソース／一次レポートへの直接リンクもしくは、当該数値・事件を初報として扱った公式発表・専門調査記事です。

放置すると何が起こるのか

攻撃によってネットワーク経由で制御を奪われた生産ラインは、最悪の場合でシャットダウンや誤動作を招きます。IPAの試算では、主要部品メーカーが72時間停止した際のサプライチェーン損失は３００億円規模に及ぶとされています。さらに監視カメラ映像の流出は顧客や従業員のプライバシー侵害となり、個人情報保護法やGDPRの制裁金が発生する可能性も否定できません。攻撃が社会的信用の喪失に直結する点で、IoTセキュリティは経営課題と捉える必要があります。

国際・国内動向が示す「対策の必然性」

ETSI EN 303 645（欧州電気通信標準化機構）は「サイバーセキュリティを前提にIoTを設計せよ」という“セキュリティ・バイ・デザイン”指針を2020年に発効しました。日本でも総務省が2022年に『IoT セキュリティアクション』を改定し、企業規模を問わず「現状把握・リスク分析・対策実装・監視運用」というPDCAを回すことを推奨しています。こうした規制・ガイドラインは今後さらに強化されると見込まれ、早期に準拠体制を整えた企業ほど市場競争力を高める構図になりつつあります。

―第3回へ続く―

【連載一覧】

―第1回「今さら聞けないIoTとは？─IoTデバイスの仕組みと活用例で学ぶ基礎知識」―
―第2回「身近に潜むIoTセキュリティの脅威とは？─リスクと被害事例から学ぶ必要性」―
―第3回「企業が取り組むべき IoT セキュリティ対策とは？─実践例に学ぶ安全確保のポイント」―

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2025年9月5日2025年9月11日

AIコーディング入門
第5回：NHI（Non‑Human Identity）とAIエージェントのセキュリティ課題

AIコーディング5アイキャッチ（NHI（Non‑Human Identity）とAIエージェントのセキュリティ課題）

AIエージェントの普及に伴い、人間以外のアイデンティティ＝Non Human Identity（NHI）が新たなセキュリティ課題として浮上しています。本記事では、NHIのリスクとゼロトラストやポストゼロトラストといった最新アプローチを通じた解決策を解説し、今後のAIコーディングに求められる実践的な視点を示します。

※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

AIエージェント時代の新課題：Non Human Identity（NHI）

AIコーディング全般に関する課題の一つとしてAIエージェントが使用するアイデンティティ、Non Human Identity（NHI）に関する問題があります。こちらについてはSQAT.jpの記事「Non-Human Identities Top 10とは？自動化時代に求められる新しいセキュリティ視点」をご確認ください。

従来型セキュリティコントロールの限界

従来型のセキュリティコントロールはエージェントには効果がないとされています。従来のAppSecは静的環境を前提としている一方で、AIエージェントは動的な性質を持つことが要因となっています。また、予測困難なクエリを出力する可能性もあります。次の表で主要な理由をまとめています。

表1:従来型セキュリティコントロールがAIエージェントに適さない理由

側面	従来型システムの前提	Agentic AIの特性	不適合の理由
アイデンティティ管理	静的なユーザー/マシンアイデンティティ（OAuth, SAML）	動的で一時的なエージェントアイデンティティ	OAuthとSAMLは主に静的権限を持つ人間ユーザーとアプリケーション向けに設計されており、AIエージェントが必要とする細かく適応的なアクセス制御機能を提供できない
権限管理	長期間有効な権限とロールベースアクセス制御（RBAC）	コンテキスト依存の短期間権限	AIエージェントは、リスクレベル、ミッション目標、リアルタイムデータ分析などのコンテキスト要因に基づいて権限を動的に変更する必要がある
認証モデル	セッション期間中の一回認証	継続的認証と検証	AIエージェントは敵対的攻撃、進化する意図、変化する運用コンテキストなどの複雑性を導入し、一回の認証ではなく継続的な検証が必要
データ・指示分離	明確なデータと制御チャネル分離	データと指示の混在	GenAIモデルはデータと指示チャネルを結合するため、攻撃者がデータチャネルを通じてシステム操作に影響を与えることを可能にする
脅威モデル	既知の攻撃パターンと定義された攻撃面	新たな攻撃面と敵対的機械学習脅威	AIシステムは敵対的操作や攻撃に対してスペクタキュラーな失敗を起こすことがある

出典：次のソースより弊社にて翻訳、編集,Cloud Security Alliance “Agentic AI Identity Management Approach | CSA ” (Ken Huang, 2025),DHS ” Safety and Security Guidelines for Critical Infrastructure Owners and Operators ” (2024),NIST AI 100-2e2025 ” Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations” (2025)

ゼロトラストアプローチによる抑制策

従来型セキュリティコントロールの限界に対して、リスクの抑制策としてエージェントへのゼロトラスト思想の適用が提唱されています。ご存じの通りゼロトラスト思想は常に対象が信頼できないものであるというものです。AI、特に幅広い範囲を様々な権限を持って自律的に行動していくAIエージェントはAppSecに比べて動的で動作の予測が困難であるという特性から考えても、ゼロトラスト思想によるセキュリティアプローチによる抑制策の効果が期待できます。

表2:AIエージェントへのゼロトラスト原則の適用と有効性

ゼロトラスト原則	Agentic AIへの適用	有効性の根拠
継続的検証	AIエージェントは、正当なエンティティのみがリソースにアクセスできるよう、リアルタイムの認証・認可チェックを受けなければならない	AIエージェントの動的で自律的性質に対応
最小権限アクセス	AIエージェントは、タスク実行に必要な最低限のアクセス権のみを付与され、権限エスカレーションのリスクを軽減する	AIエージェントの予測不可能な行動による潜在的被害を制限
マイクロセグメンテーション	AI駆動環境は侵害されたエージェントが無関係なリソースにアクセスできないよう、横展開を制限するためセグメント化されるべき	エージェント間の相互作用による被害拡大を防止
異常検知と対応	AIの行動は期待されるパターンからの逸脱について継続的に監視され、異常が検出された際に自動応答をトリガーする	AIエージェントの行動異常を早期検出・対応
動的信頼評価	AIエージェントの履歴行動、異常検知、セキュリティ態勢に基づく動的信頼スコアの割り当てによる継続的な信頼性評価	エージェントのライフサイクル全体を通じた信頼性管理

ポストゼロトラストに向けた新しいアプローチ

ゼロトラストアプローチを基礎とし、さらに根本的な対策を行おうという動きもあります。表3 ポストゼロトラストアプローチに掲載したような多様なアプローチの検討など、一部は実装が進んでいます。

表3:ポストゼロトラストアプローチ

アプローチ	説明	実装例	利点
エフェメラル認証	AIエージェントの一時的性質を考慮し、短期間有効でコンテキスト認識のアイデンティティを生成するアプローチ	AWS STS一時的認証情報、GCPサービスアカウント偽装	長期認証情報の漏洩リスク排除、最小権限原則の自動実現
属性ベースアクセス制御（ABAC）	ユーザー役割、デバイスセキュリティ態勢、エージェント属性、データラベリング、エージェントツールセット、環境条件などの属性に基づくアクセス許可	AWS STS一時的認証情報、GCPサービスアカウント偽装	細粒度で動的なアクセス制御
Just-In-Time（JIT）アクセス	AIエージェントが必要な時のみ一時的権限を要求できる機能	動的権限プロビジョニングシステム	攻撃面の最小化、リアルタイム要求対応
行動ベース認証	静的認証情報や事前定義された役割だけでなく、AIエージェントのリアルタイム行動、過去の相互作用、リスク評価に基づく認証	機械学習ベース異常検知システム	侵害されたAIエージェントの検出向上
トラストスコアリング	AIエージェントの履歴行動、異常検知、セキュリティ態勢に基づく動的トラストスコア割り当て	リアルタイムリスクスコアリングシステム	信頼度に基づく動的権限調整
統合セキュリティ監視	AI開発環境とランタイム環境を統合したセキュリティ態勢管理と脅威保護システム	DevSecOpsパイプライン統合	開発フェーズからの早期脅威検出
データガバナンス統合	AIエージェントに対する統合的なデータセキュリティとコンプライアンス制御	自動データ分類・保護システム	データオーバーシェアリングとリーク防止

AIコーディングに求められる次世代セキュリティ戦略

AIエージェントの普及は、従来のセキュリティモデルを大きく揺さぶっています。Non Human Identity（NHI）の管理や、従来型コントロールでは対応しきれない動的な挙動、そして敵対的機械学習を悪用した新たな攻撃手法など、課題は複雑かつ広範です。本記事で紹介したゼロトラストやポストゼロトラストのアプローチは有効な一歩となりますが、それだけで十分ではありません。AIが協調的に動作するマルチエージェント環境では、脅威の拡大スピードも従来以上に速く、より総合的な戦略が求められます。

次回第6回は、これまでの議論を総括し、マルチエージェント時代の脅威モデルや未来の展望を整理します。AIコーディングの安全な発展に不可欠な「総評」として、今後の方向性を見極めていきます。

―第6回「総評：マルチエージェント時代の脅威と未来」へ続く―

【連載一覧】

第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」
第2回「プロンプト以外で効率化！開発体験の改善手法」
第3回「AIエージェント時代のコーディング：MCPとA2Aとは」
第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」
第5回「AIとセキュリティ：Non‑Human Identity とAIエージェントの課題」
第6回「AIエージェントのセキュリティ対策と今後の展望」

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2025年8月28日2025年9月28日

AIコーディング入門
第4回：MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装

Security NEWS TOPに戻る
バックナンバー TOPに戻る

AIコーディング4アイキャッチ（MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装）

前回記事で述べたように、AIエージェントの普及に伴い、MCP（Model Context Protocol）やA2A（Agent-to-Agent Protocol）の実装事例が増えています。しかし、標準化が進む一方で、脆弱性やセキュリティリスクも現実化しつつあります。本記事では、AIエージェントの基盤を支える標準プロトコル「MCP（Model Context Protocol）」と「A2A（Agent-to-Agent Protocol）」をさらに深く掘り下げ、AIエージェントを安全に活用するための設計指針と実装上の留意点を整理します。

※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

MCPの脆弱性

MCPの脆弱性の事例としては以下のものが挙げられます。

AsanaのMCPサーバの事例

プロジェクトやタスクを一元管理するプラットフォーム（SaaS）・Asanaが2025年5月から提供し始めたMCPサーバに脆弱性があったもの。脆弱性により、MCPを使用しているユーザーが、LLMと接続しているチャットインターフェース越しに他の組織のプロジェクト、チーム、タスクを含むAsanaオブジェクトを取得できた可能性があるとされています*12。前回ご紹介した「図4:MCP関連の主なセキュリティ課題」にも挙げたように、最小特権の付与の原則の徹底（SaaS提供事業者の場合にはテナント間の厳密な分離も含みます）、リクエストやLLMの生成クエリのログの記録といった課題が改めて浮き彫りになったといえます。

A2Aのセキュリティ課題

MAESTRO脅威モデリングに当てはめたときには以下のような問題があると指摘されています。なおMAESTRO脅威モデリングについては下表でご紹介します。

表:A2Aプロトコルのセキュリティ課題のMAESTROモデル分析

レイヤ	脅威	概要	被害を受ける人・組織	発生確率	影響	軽減策
1	メッセージ生成攻撃 (回避)	攻撃者が悪意のある入力を生成し、エージェントのモデルに誤った、偏った、または有害なメッセージを生成させ、通信中の安全メカニズムを迂回する。モデル出力の非決定論的性質が、これらの攻撃の検出と防止をより困難にする。	A2A エージェントを利用する組織、システムの利用者	高	大	入力検証: エージェントのモデルにコンテンツを送信する前に厳格な入力検証を実施する。入力をサニタイズする。出力検証: 生成されたメッセージのコンテンツに有害なコンテンツ、矛盾、または予期しない動作がないか確認する。コンテンツフィルタリングを使用する。非決定論的なモデルの動作に対する出力検証の堅牢性を高めるために、アンサンブル法や敵対的訓練などの技術を採用する。慎重なプロンプト設計: 敵対的攻撃の影響を受けにくいプロンプトを設計する。モデルをガイドするために少数ショットの例を使用する。
1	モデル抽出	A2A を介した過度または巧妙な対話により、プロプライエタリモデルの動作やパラメータに関する十分な詳細が提供され、モデルの推論または盗難が可能になる。エージェントの自律性が、予期しない情報漏洩につながる可能性のある、緩やかに制御された対話パターンを促進することで、この問題を増幅させる可能性がある。	モデル所有者、企業	低	大（潜在的に）	厳格なレート制限: セッション/ユーザー/エージェントごとの A2A 対話にレート制限を適用する。異常検出: プロービングやデータ抽出の試みを示唆する異常なクエリパターンを監視する。
2	データ汚染 (メッセージ部分)	攻撃者がエージェント間で交換されるメッセージに悪意のあるコンテンツを注入し、意思決定に使用されるデータを侵害する。エージェントの相互作用の動的な性質は、このデータポイズニングが急速に広がり、連鎖的な影響を及ぼす可能性があることを意味する。	エージェント、A2A エージェントの決定に依存する組織	中～高	大	強力な検証: ファイルの整合性チェック、DataParts のスキーマ検証、TextParts のコンテンツフィルタリングを含む、すべてのメッセージパーツに対する厳格な検証を実施する。最小特権: 最小特権の原則に基づいて、機密データへのエージェントのアクセスを制限する。出どころの追跡: メッセージ内のデータの出どころと系統を追跡し、信頼性を評価する。送信元エージェントのIDとデータに適用された変換を考慮するために出どころの追跡を拡張する。
2	機微情報の漏洩	エージェントが、過度に広範な権限、データ管理ミス、またはモデルの幻覚により、A2A 通信または成果物で意図せず機密情報（PII、機密情報）を公開する。	個人（PII の所有者）、機密情報を扱う組織	中	中～大	自動 PII 編集: 個人識別情報（PII）の検出と編集のための自動プロセスを採用する（例: Gemini のフィルター機能）。きめ細かなアクセス制御: エージェントの役割とタスクのコンテキストに応じて堅牢なアクセス制御を実装する。コンテキスト認識型ガードレール: エージェントが機密情報や制限された情報を共有するのを防ぐためにガードレールを追加する。
3	許可されていないエージェントのなりすまし	攻撃者が正当なエージェントになりすまし、機密情報にアクセスしたり、他のエージェントを操作したりする。変化する資格情報や検証可能なクレデンシャルによって示されるエージェント ID の動的な性質は、この脅威をさらに複雑にする。	他のエージェント、A2A プロトコルを利用する組織	中	大	分散型識別子（DIDs）: エージェントに ID 検証のために DID を使用することを義務付ける。ID の変更を検出するために、DID ドキュメントを定期的に更新および再検証するメカニズムを実装する。安全な認証: DID ベースの署名や相互 TLS などの強力な認証メカニズムを実装し、エージェントの ID を検証する。リプレイ攻撃を防ぎ、通信時に資格情報が有効であることを確認するために、タイムスタンプ付き署名を使用する。エージェントレジストリ: エージェントの正当性を検証するために、信頼されたエージェントレジストリを実装する。レジストリは動的なエージェント属性を処理できる必要があり、継続的に更新されるべきである。
	メッセージインジェクション攻撃	攻撃者が A2A メッセージに悪意のあるコンテンツを注入し、受信エージェントの動作を操作する。エージェントの自律性は、侵害されたエージェントが人間の介入なしに悪意のあるメッセージを伝播する可能性があるため、この脅威を増幅させる。	メッセージを受信するエージェント、操作されたエージェントによって制御されるシステム	高	大（潜在的に）	M デジタル署名: すべての A2A メッセージにデジタル署名を実装し、整合性と否認防止を確保する。メッセージが有効と見なされる前に、複数の信頼されたエージェントからの承認を必要とするマルチ署名スキームを実装する。入力検証: メッセージパーツやメタデータを含むすべてのメッセージコンテンツに厳格な入力検証を実施する。コンテンツフィルタリング: メッセージ内の悪意のあるコンテンツを検出してブロックするためにコンテンツフィルタリングを使用する。
	プロトコルダウングレード攻撃	攻撃者がエージェントに A2A プロトコルのセキュリティの低いバージョンを使用させる。非決定論的なエージェントの相互作用により、予測がより困難な追加の攻撃ベクトルが開かれる可能性がある。	A2A エージェント、A2A 通信に依存するシステム	低	大（潜在的に）	安全なプロトコルネゴシエーション: 相互認証を伴うトランスポート層セキュリティ（TLS）などの安全なプロトコルネゴシエーションメカニズムを実装し、エージェントが最も安全なプロトコルバージョンを使用するようにする。廃止ポリシー: 古いプロトコルバージョンに対する廃止ポリシーを明確に定義し、実施する。
	信頼できる企業を装った悪意のある A2Aサーバ	攻撃者が信頼できる企業や組織が運営しているように見せかけた悪意のある A2A サーバをセットアップし、エージェントを騙して通信させ、機密情報を漏洩させたり、悪意のあるタスクを実行させたりする可能性がある。	エージェント、ユーザー/組織（データ窃取の被害者）、A2A 運用に依存する組織、なりすまされた信頼できる企業（評判の損害）	中	大（潜在的に）	サーバ ID の分散型識別子（DIDs）: エージェントと同様に、A2A サーバは DID を使用して識別され、その DID ドキュメントは検証可能で定期的に更新されるべきである。A2A プロトコルは、サーバからエージェントへの通信に DID ベースの認証を義務付けるべきである。 Agent Cards の証明書透明性（CT）: SSL/TLS 証明書に似た証明書透明性（CT）のようなメカニズムを実装する。Agent Cards は公開ログ（例：ブロックチェーンや分散型台帳）に登録でき、エージェントが Agent Card が正当であり、改ざんされていないことを検証できるようにする。相互 TLS（mTLS）認証: エージェントと A2A サーバ間の相互 TLS（mTLS）認証を強制する。サーバードメインの DNSSEC: A2A サーバの Agent Card にドメイン名を含む URL が含まれている場合、DNSSEC でドメインを保護し、DNS スプーフィング攻撃を防ぐ。エージェントレジストリ検証: A2A サーバと対話する前に、エージェントは信頼されたエージェントレジストリを参照し、サーバが正当であることを検証すべきである。 Agent Card 署名検証: エージェントはサーバの公開鍵または DID を使用して Agent Card を暗号学的に検証し、カードが改ざんされていないことを確認すべきである。重要操作に対する多要素認証: 機密性の高い操作の場合、エージェントは A2A サーバと通信する前に多要素認証（MFA）を要求すべきである。行動分析とレピュテーションシステム: なりすましを示唆する異常なサーバ活動パターンを検出するために行動分析を実装する。監査とログ: エージェントと A2A サーバ間のすべての通信の詳細な監査ログを維持する。ハニーポットサーバー: 攻撃者を引きつけ、その技術に関する情報を収集するために、ハニーポット A2A サーバをデプロイする。
4	T4.1: DoS 攻撃	攻撃者が A2A サーバにリクエストを殺到させ、エージェントが通信不能になる。エージェントの自律的な性質は、DoS 攻撃がエコシステム全体に急速に連鎖する可能性があることを意味する。	A2A サーバ、A2A サービスを利用するユーザー/組織、エージェントエコシステム	中～高	大	堅牢なインフラストラクチャ: ダウンタイムを最小限に抑えるために、冗長で地理的に分散されたインフラストラクチャを使用する。 DDoS 防御: 堅牢な DDoS 緩和策を実装する。レート制限: 過剰なリクエストを防ぐためにレート制限を実装する。リアルタイムのネットワーク状況とエージェントの活動パターンに基づいて調整される適応型レート制限を実装する。
5	ログデータの隠蔽・改ざん	攻撃者が悪意のある活動を隠蔽するためにログエントリを変更または削除する。エージェントの動作の複雑で予測不可能な性質は、正当な活動と、操作されたログによって隠蔽された悪意のある行動を区別することをより困難にする。	セキュリティチーム、監査担当者、インシデントレスポンダー、ログの整合性に依存する組織	中	大（潜在的に）	安全なログ記録インフラストラクチャ: 強力なアクセス制御を備えた安全なログ記録インフラストラクチャを使用する。ログ整合性監視: チェックサムまたはデジタル署名を使用してログデータの整合性を検証する。異常検出: エージェントの固有の非決定論性を考慮に入れた高度な異常検出技術を採用する。
6	エージェントの認証情報への認可されないアクセス	攻撃者がエージェントの資格情報（例: 秘密鍵）にアクセスし、エージェントになりすまして悪意のある行動を実行できるようにする。エージェントが検証可能な資格情報を動的に取得および提示するため、侵害されたエージェントは迅速に強力な新しい能力を獲得し、損害の可能性を拡大させる。	エージェント所有組織、侵害されたエージェントがアクセスするシステム	高	大	安全な鍵ストレージ: エージェントの資格情報をコードに直接埋め込まない。ハードウェアセキュリティモジュール（HSM）または安全な鍵管理サービスを使用する。鍵のローテーション: エージェントの資格情報を定期的にローテーションする。多要素認証: ユーザーが実際に制御していることを確認するために MFA を使用する。
	機微情報へのコンプライアンスの欠如	エージェントが PII を含むデータを適切な保護なしに送信、受信、処理する。エージェントの自律性がこれらの脅威を強める。	機密データを扱う組織（法的・経済的罰則）、個人（PII の所有者）	中～高	大（潜在的に。法的・経済的罰則を伴う）	データ最小化: 個人データの収集を削減する。仮名化/匿名化:。データ暗号化: エンドツーエンドの暗号化と鍵の保護を確実にする。
	委任権限の濫用	実装の脆弱性により、エージェントが与えられた権限を超える可能性がある。	権限を委譲した組織、エージェントが動作するシステム	（明示されていない。なお実装に依存する可能性が高い）	（明示されていないが一般的に委任権限の濫用による影響は大きい）	明示的なユーザー同意:。詳細な監査:。厳格なトークン検証:。
7	悪意のあるエージェントの相互作用	侵害されたエージェントが他のエージェントと相互作用し、危害を与えたり、脆弱性を悪用したり、予期しない結果を引き起こしたりする。エージェントの ID が変化し、動作が予測不可能なため、あるエージェントが他のエージェントよりも大きな損害を引き起こす可能性を予測することは困難である。	エコシステム内の他のエージェント、エージェントに接続されたシステム	中～低	高（潜在的に影響度が高いと想定される）	安全なエージェント間通信: エージェント間の相互作用に安全な通信プロトコルと認証メカニズムを使用する。エージェントレピュテーションシステム: エージェントの動作を追跡し、悪意のあるエージェントを識別するためにレピュテーションシステムを実装する。レピュテーションシステムは、エージェントの ID の動的な性質を処理でき、操作に耐性がある必要がある。サンドボックス化: 侵害されたエージェントの影響を制限するために、エージェントを相互に隔離する。エージェントが定義された境界を超えるのを防ぐために、ランタイム監視とポリシー実施を実装する。

出典：「Threat Modeling Google’s A2A Protocol with the MAESTRO Framework」6: Threat Modeling Results: Applying MAESTRO Layer by Layerより弊社翻訳
※ 本図はOWASPが定義するMAESTROモデルをベースに記載されたhttps://cloudsecurityalliance.org/blog/2025/04/30/threat-modeling-google-s-a2a-protocol-with-the-maestro-frameworkの6: Threat Modeling Results: Applying MAESTRO Layer by Layerを弊社にて翻訳、表に編集しなおしたものです。

AIエージェント時代における標準プロトコルのリスク管理

AIエージェントの普及に伴い、MCPやA2Aといった標準プロトコルは不可欠な基盤となりつつあります。しかし、標準化による利便性の裏側には、同じ脆弱性が広範囲に拡散するリスクが潜んでいます。リスク管理の基本は「標準＝安全」と思い込まず、実装ごとにセキュリティ要件を精査することです。特にアクセス制御、暗号化、監査ログといった基礎的な対策をプロトコルレベルで徹底する必要があります。

さらに今後は、従来の「人間を前提としたセキュリティモデル」では対応できない課題が顕在化していくことが予想されます。次回第5回では、Non Human Identity（NHI）の登場や制御不能なAIエージェントといった新たな脅威に焦点を当て、従来型セキュリティの限界とその打開策について考察します。

―第5回「AIとセキュリティ：Non‑Human Identity とAIエージェントの課題」へ続く―

【連載一覧】

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月3日（水）13:00～14:00
「止まらないサイバー被害、その“対応の遅れ”はなぜ起こる？～サイバー防衛の未来を拓く次世代XDR：大規模組織のセキュリティ運用を最適化する戦略的アプローチ～」

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2025年8月28日2025年9月28日

連載記事：企業の「攻め」と「守り」を支えるIoT活用とIoTセキュリティ
第１回：今さら聞けないIoTとは？─IoTデバイスの仕組みと活用例で学ぶ基礎知識―

Security NEWS TOPに戻る
バックナンバー TOPに戻る

はじめに：連載の背景

新聞やビジネス誌を開くと「IoTとは」という見出しを見かける日も多くなりました。しかし、IT部門や経営層の会議で実際に自社では何をどう活用するのかと議論が始まると、抽象論のまま立ち往生してしまう例が多いのも事実です。本連載では「IoTデバイスの基本」「IoTセキュリティの脅威」「企業が実践すべき対策」を三回にわたって解説します。最後まで読むことで、読者の皆様が社内で議論を前に進めるための土台が整えられることを願っています。

「Internet of Things」誕生の背景

IoTという造語は 1999年、英 Auto-ID Center（現MIT Auto-ID Lab）でRFID研究に携わっていたケビン・アシュトン氏が提唱したのが始まりとされています。当時はネットワークに常時接続するセンサーは高価で、実用化は一部の製造ラインに限られていました。ところが2010年代に入り、3G／4G回線の広域整備とWi-Fiチップの低価格化が進んだことで導入コストが急速に低下し、クラウドが解析基盤を提供する現在の「IoT構造」が定着しました。総務省『情報通信白書令和5年版』によれば、世界のIoT機器（以降、本記事内ではIoTデバイスまたはIoT機器と表記します）の稼働台数は2022年時点で約147億台、2025年には270億台超へ倍増すると見込まれています。

IoT機器の台数推移（2022-2025年）

参考：IoT Analytics「IoT 2022: Connected Devices Growing 18% to 14.4 Billion Globally」,「State of IoT 2024: Number of connected IoT devices growing 13% to 18.8 billion globally」(PDF)

IoTアーキテクチャの四層モデル

多くの国際標準では「デバイス層・ネットワーク層・プラットフォーム層・アプリケーション層」という四つの階層で IoTシステムを整理します。デバイス層では温度や振動を“測る”センサーと、モーターやリレーを“動かす”アクチュエータが中心的な役割を担います。ネットワーク層ではWi-Fi、Bluetooth Low Energy、LoRaWAN、NB-IoT、5Gなど目的に応じた通信技術が選択され、プラットフォーム層ではAWS IoT CoreやMicrosoft Azure IoT Hub、NTT Communications Things Cloud^®などがデータの収集・蓄積・分析をつかさどります。最上位のアプリケーション層が可視化ダッシュボードや制御アプリを提供し、ユーザ企業はそこから意思決定を行うという構造です。

参考：NIST SP 800-213「IoT Device Cybersecurity Guidance for the Federal Governent: Establishing IoT Device Cybersecurity Requirements」,GeeksforGeek「Architecture of Internet of Things (IoT)」,Zipit Wireless Blog「4 Layers of IoT Architecture Explained」

身近に増えるIoTデバイスの実像

今や一般家庭にも浸透するスマートスピーカーは、音声認識マイクと温湿度センサーを内蔵し、クラウド側で音声コマンドを解析してエアコンや照明を制御します。オフィス向けではネットワークカメラがクラウド映像分析サービスと連携し、不審者や深夜の残業者を自動検知します。製造現場で稼働する振動センサーは0.1秒単位でモーターの揺れを測定し、閾値しきいちを超える振幅を捉えると、PLC（Programmable Logic Controller）へ緊急停止信号を返します。農業分野では土壌水分センサーと気象APIを組み合わせ、最適な潅水量を算定してポンプを自動起動するスマート農業システムが普及し始めました。医療分野のウェアラブル端末は心拍・SpO₂・体温をクラウドに送信し、医師が専用アプリで異常を見逃さない仕組みを構築しています。

IoT例から見えるビジネスインパクト

製造業の典型的なIoT事例は予知保全です。独Bosch Rexroth社はラインに5,000個のセンサーを実装し、振動データと過去の故障ログをAIが突き合わせることでダウンタイムを25％削減したと発表しています。小売業では米WalmarがRFIDと重量センサーを併用してリアルタイム在庫を可視化し、欠品率を16％下げたことで年間10億ドル規模の機会損失を回避したと報告しました。日本国内でも関西電力がスマートメーター経由で収集した使用電力データを解析し、節電インセンティブのプログラムを顧客へ提示することでピークカットに成功した事例が公表されています。

導入メリットの裏に潜む注意点

リアルタイムデータに基づく迅速な意思決定、業務の自動化、新規サービス創出という恩恵は大きいものの、IoTセキュリティが後手に回るとその利点は一瞬で吹き飛びます。総務省『IoT セキュリティガイドライン ver 1.0』では、「初期パスワードのまま運用」「ファームウェアの自動更新機能が無効」といった“ありがちな設定”を放置すると、攻撃者にネットワークの踏み台として悪用される危険性が高いと明示しています。次回以降、脅威と対策を深掘りしますが、まずは“便利さとリスクは表裏一体”であると認識することが企業リーダーへの第一歩です。

―第2回へ続く―

【連載一覧】

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2025年8月26日2025年8月26日

【初心者向け】ペネトレーションテスト（侵入テスト）とは？目的・方法・費用ガイド

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ペネトレーションテスト（侵入テスト）とは、実際の攻撃者と同じ手法を用いてシステムやネットワークに侵入を試みることで、セキュリティ上の弱点を明らかにする検証手法です。脆弱性診断との違いや、実施の流れを理解することで、自社に最適なセキュリティ対策を選択できるようになります。本記事では、ペネトレーションテストの目的や手順、費用感、活用のメリットまでわかりやすく解説します。

サービス紹介動画（ペネトレーションテスト）

ペネトレーションテストとは

ペネトレーションテストとは、主に企業ネットワークや、Webアプリケーションなどに不正に侵入することができるかどうかをテストすることです。英語の「 penetration 」には「貫通」、「 penetrate 」には「貫く」「見抜く」などの意味があります。「ペンテスト」と略されたり、「侵入テスト」と呼ばれることもあります。

サイバー攻撃者はまず不正侵入し、その後、情報を盗んだり、バックドアを仕掛けたり、あるいは破壊工作などを行います。それらすべての端緒となる不正侵入を許すかどうかを調べるのが、ペネトレーションテストの役割です。

ペネトレーションテストは、システムやネットワークに対する不正侵入や攻撃が可能かどうかを確認するためのテスト手法です。このテストは、単に脆弱性を見つけるだけではなく、それらが実際に悪用される可能性があるかどうかを判断することに重点を置いています。これにより、システムのセキュリティ状態の把握や実装されているセキュリティ対策の有効性を検証することができます。

ペネトレーションテストが必要な業界と業種

ペネトレーションテストは、特にセキュリティが重要視される業界や業種で必要とされます。
金融、医療、政府機関、ITサービスなど、機密情報を扱うすべての業界で、ペネトレーションテストの実施は必要不可欠です。これらの業界では、データ漏洩やシステム障害が重大な結果を招く可能性があるため、定期的なテストが推奨されます。

ペネトレーションテストが必要な３つの業種

脆弱性診断の結果見つかった脆弱性を悪用して、攻撃が本当に成功するのかを検証するために、ペネトレーションテストが実施されることがあります。あくまで一般論ですが、ペネトレーションテストが必要な業種や事業として、以下の３つが挙げられます。

１．生命・生活に直接影響を与える事業やサービス
第一に、生命や生活に影響を及ぼす業種が挙げられます。具体的には、水道・電気・ガス・道路・交通等の社会インフラや、病院、ビル管理、工場のシステムなどです。

２．資産に影響を与える個人情報を扱うサービス
個人情報を保有する事業やサービスにも、ペネトレーションテストが必要な場合が多いでしょう。とりわけ銀行や証券会社、クレジットカード、仮想通貨取引所などの金融、大規模なWebサービスやECサイト、住民データを扱う自治体や官公庁などが挙げられます。

３．事業継続に影響を与える機密情報を扱うシステム
重要な営業機密や知的財産を保有する企業もペネトレーションテストの実施が望ましいといえるでしょう。

特に、クローズモデルの知財戦略に基づいて特許を取得しない方針の企業が、サイバー攻撃によって機密情報を盗まれ、他の企業に国内外で特許申請･取得された場合、事業継続に関わる重大な影響が懸念されます。

また、データ自体に価値はあるが、特許法や不正競争防止法では保護対象とならないようなデータについては、セキュリティ対策によって保護を図る必要があります。

ペネトレーションテストと脆弱性診断との違い

ペネトレーションテストは、脆弱性診断とは異なるアプローチを取ります。

脆弱性診断はシステムの脆弱性を特定することに焦点を当てていますが、ペネトレーションテストはその脆弱性を利用して実際に攻撃を試み、システムのセキュリティを実際に検証します。この違いは、単にリスクを特定するのではなく、そのリスクが実際にどのように悪用され得るかを理解することにあります。

以下に「対象」「目的」「範囲」、必要な「期間」の４つの観点から、ペネトレーションテストと脆弱性診断の違いを示します。

	ペネトレーションテスト	脆弱性診断
対象	脆弱性診断同様、ネットワークやWebアプリケーションを対象にしますが、ときに警備員をあざむいて建物に侵入できるかどうか等の物理的侵入テストが行われることもあります。	ネットワークやWebアプリケーションが対象となります。
目的	脆弱性診断は脆弱性を発見して報告することが主な業務ですが、ペネトレーションテストは脆弱性をもとに不正アクセスし、ネットワーク等に侵入することが目的となります。	脆弱性を検知・検出すること。
範囲	広い範囲の網羅性を重視する脆弱性診断と異なり、ペネトレーションテストは侵入することが目的であるため、脆弱性診断とは反対に、狭く深く、ときに針の穴のような侵入できる一点を探します。	広く網羅的に脆弱性の有無を探します。
期間	ペネトレーションテストは、とにかく侵入が成功するまでトライし続ける作業であるため、脆弱性診断よりも長い期間を要する場合が少なくありません。ただし、一般論として、優秀なペネトレーションテストサービスであればあるほど、短い期間で侵入が成功します。	探すものが事前に決まっているためペネトレーションテストよりも通常は短い期間で完了します。

ペネトレーションテスト実施のステップ

ペネトレーションテストサービスは提供する企業によってそれぞれ個性がありますが、大きく分けると下記の手順で実施されます。

Step1.ヒアリング

目的に応じ、たとえば「顧客データベース」など、ペネトレーションテストを行う対象を決定します。そして「顧客データベース」が外部から攻撃されるのか、あるいは内部犯行なのか、想定する攻撃シナリオを作成し、最後に、ペネトレーションテストを行う期間を決定します。

Step2.実施

対象によってさまざまな実施方法があります。公開されているWebアプリケーションであればリモートから実施することができます。内部犯行の危険性をテストする場合ならオフィス内から実施することもあるでしょう。

Step3.完了

「侵入に成功したとき」あるいは反対に、「侵入に成功できないまま期間が終了したとき」のいずれかをもってペネトレーションテストは完了します。どちらの結果にも意味があります。侵入に成功した場合は、その報告を受けて防御力を高める必要性を認識することになり、侵入に失敗した場合は、一定の防御力を保持できている目安となります。

Step4.報告

ペネトレーションテスト事業者からの報告書提出や報告会が行われます。具体的にどういうプロセスで、どういう技術を用いて侵入し、重要なデータがどこまで閲覧可能だったのか、どんなことができてしまう危険性があったのか、など管理者の気にかかることが詳細に報告されます。

ペネトレーションテストのメリットとデメリット

メリット

攻撃者視点でリスクを把握できる
発見された問題を経営層や現場に説得力をもって説明できる
実際の被害想定を踏まえた改善が可能

デメリット

費用や工数が脆弱性診断よりも高い傾向にある
診断範囲が限られることがある
実施時の負荷に配慮が必要

ペネトレーションテストの費用相場

ペネトレーションテストの費用は、対象システムの規模や診断範囲によって異なります。一般的にはあくまで一般的な相場として「脆弱性診断の１.５倍から２倍」程度、数百万円程度が目安ですが、小規模のWebアプリケーションなら数十万円から実施可能な場合もあります。

ペネトレーションテストの重要性

主に以下のような理由により、企業・組織において、ペネトレーションテストを実施することは重要です。

実際の攻撃シナリオの検証
セキュリティ対策の有効性評価
コンプライアンス要件の遵守
ビジネスリスクの低減

脆弱性診断とは異なり、ペネトレーションテストは単に脆弱性を発見するだけでなく、それらが実際に悪用される可能性があるかどうかを重視します。これにより、システムのセキュリティ状態を詳細に把握し、実装されているセキュリティ対策の有効性を検証することができます。

特に金融、医療、政府機関、ITサービス業界など、高度なセキュリティが要求される分野では、セキュリティ対策の一環としてペネトレーションテストが法令やガイドラインで義務付けられている場合があります。

ペネトレーションテストを実施する会社の適切な選び方

ペネトレーションテストを実施する際には、専門知識と経験を持つ信頼できる会社を選ぶことが重要です。セキュリティテストの専門家であること、業界の最新の脅威に精通していること、そして過去の成功事例を持つことが、良いサービスプロバイダーの特徴です。また、テストの範囲、方法、報告の詳細さなど、サービスの質にも注意を払う必要があります。

ペネトレーションテストは経験とセンスが求められる仕事であるため、優良事業者選びはとても重要です。前述したとおり「優秀なペネトレーションテストサービスであればあるほど、短い期間でテストが終了（＝侵入に成功）」します。ペネトレーションテストの見積額はエンジニアの拘束時間とも相関しますので、予算にもかかわってきます。大きく以下の３つのポイントを、いいペネトレーションテスト会社選びの参考にしてください。

１．丁寧なヒアリングにもとづいてシナリオを考えてくれるか

システム構成や業務手順、ときには組織構成など、実際のサイバー攻撃を行う際に参照するとされる、さまざまな情報をもとにして、実施するサービスの適用範囲、留意事項、制限などを聞き、顧客の目的や要望、要件に沿ったペネトレーションテストの攻撃シナリオを考えてくれる会社を選びましょう。

２．技術者の経験と勘、クリエイティビティ

ペネトレーションテストはときに針の穴を通すような隙間を見つけ出して侵入を成功させる業務です。技術者のこれまでの経験、保有資格などを確かめ、技術者の層が厚い会社を選びましょう。

３．診断実績

過去のペネトレーションテストの実施社数や件数、リピート社数なども、いいペネトレーションテスト会社選びの参考になります。

ペネトレーションテストのツール

ここまで述べてきたとおりペネトレーションテストとは、丁寧なヒアリングのもとで作成した攻撃シナリオに基づいて、経験豊かな技術者が実施するクリエイティブな手作業です。ペネトレーションテストをすべて自動で行うツールは存在しません。

ただし、ペネトレーションテストを行う技術者が、いわば「工具」「道具箱」のように用いるツールは数多くあります。代表的なものとして、オープンソースプロジェクトである Metasploit が提供する、さまざまなツール群が挙げられます。

セキュリティ企業に依頼せずに、自分でMetasploit が提供するツールを用いて、公開されている脆弱性などを用いて攻撃を実行することは可能です。しかし、その結果を読み解いたり、優先順位をつけたりするノウハウには経験と知見が必要とされます。

また、自宅に置いたサーバに研究目的でツールを走らせるような場合でも、不用意にこうしたツールを使用したり、不適切な方法で攻撃用のエクスプロイトを取得・保管したりすると「不正アクセス行為の禁止等に関する法律」や「不正指令電磁的記録に関する罪（刑法刑法168条の2及び168条の3）」等にも触れる犯罪となる危険性もあることを忘れてはいけません。

まとめ

・ペネトレーションテストとは、システム・ネットワークへの不正侵入や攻撃が成立するか確
　認するテスト手法の一つ
・特にセキュリティが重要視される業界や業種、金融、医療、政府機関、ITサービス業界など
　で、ペネトレーションテストの実施が必要不可欠
・脆弱性の有無を判定する脆弱性診断と異なり、ペネトレーションテストでは脆弱性自体を見
　つけることよりも不正侵入や攻撃が成立するかどうかの判断を優先する
・事前ヒアリングが丁寧で、優秀な技術者が在籍する、診断実績の多い会社を探す

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2025年8月22日2025年9月28日

AIコーディング入門
第3回：AIエージェント時代のコーディング：MCPとA2Aとは

Security NEWS TOPに戻る
バックナンバー TOPに戻る

生成AIを活用したコーディングの現場で、いま最も注目されているトピックのひとつが「AIエージェント」です。エージェントは人間の最小限の指示をもとに計画・推論・実行を繰り返す自律的な仕組みであり、シングルエージェントからマルチエージェントまで多様なアーキテクチャが登場しています。さらに通信の標準化を担うMCP（Model Context Protocol）やA2A（Agent-to-Agent）といったプロトコルの整備が進み、エコシステム全体に大きな影響を与えています。本記事では、AIエージェントの基本構造、利点とリスク、新しい標準プロトコルの動向について解説します。

※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

AIエージェントとは何か

生成AIを使用したコーディングのなかでも昨今注目を浴びているのがAIエージェント（Agentic AI）を用いたAgenticコーディングです。Agenticコーディングの前にまずはAIエージェントの動きを見てみましょう。AIエージェントは人間による最低限の指示や監督をもとに計画・推論・実行を繰り返す、自律的処理を行うAIです。

シングルエージェントの仕組み

まずはわかりやすい、単一のエージェントのみが動くシングルエージェントのアーキテクチャを見てみましょう。下図はシングルエージェントのアーキテクチャを示したものです。

図1:シングルエージェントのアーキテクチャ

シングルエージェントのアーキテクチャの図 — 参考：OWASP LLM Applications & Generative AI Top 10（https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/）, p.8より弊社翻訳

シングルエージェントモデルではアプリケーションからの入出力（人間による指示）をもとに単一のエージェントが自律的にルーチンを実行し、LLMモデルや関連サービスとの間の連携を図り、出力を行います。人による監督はHuman in the loop（HITL）という形で行われます。この図の中でいうAIアプリケーション（及びエージェント）が各種サービスやデータベースなどと通信する際、昨今ではMCP (Model Context Protocol)を用いた標準化された通信プロトコルが用いられていることが増えています。MCPについては後程解説します。

マルチエージェントの仕組み

一方マルチエージェントのアーキテクチャは下図のとおりです。

図2:マルチエージェントのアーキテクチャ

マルチエージェントのアーキテクチャの図 — 参考：OWASP LLM Applications & Generative AI Top 10（https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/）, p.10より弊社翻訳

マルチエージェントの場合はAIアプリケーション（及びエージェント）と各種サービス、DBなどとのMCPでの通信に加えて、エージェント間の通信（図中のマルチエージェント通信）が必要となります。エージェント間の通信を標準化したものがA2A（Agent2Agent）プロトコルになります。こちらも後程解説します。

AIエージェントの利点とリスク

AIエージェントを利用する場合、人間の監督・指示が最低限で済む一方で、以下のような利点と課題・リスクが存在します。

図3:AIエージェントの利点と課題・リスク

上記に挙げたAIエージェントのリスクのうち、「誤行動・報酬設計の欠陥」と「倫理・説明責任」を取り上げて解説します。

誤行動・報酬設計の欠陥

報酬のミススペックによりエージェントが意図しない行動をとることを指します*2。最近の報告ではエージェントが自身の地位を脅かされる場合や、目標の対立が発生した場合に内通者のような不正行動を低率ながら遂行する可能性が指摘されています*2。

倫理・説明責任

AIエージェントの自律判断の責任を負うのは誰かという問題。倫理的な問題に加えて著作権に代表されるような法的な問題に加えて、信頼性・公平性といった問題についての課題も指摘されています*3https://arxiv.org/pdf/2502.00289v3。

新しい標準プロトコル：MCPとA2A

ここ最近、「MCP」や「A2A」といったキーワードを目にする機会が増えているのではないでしょうか。ここでは簡単にMCPとA2Aについてご紹介します。

MCP（Model Context Protocol）とは

MCPとはAIアプリケーションがLLMにコンテキストを提供する方法を標準化するプロトコルで、Anthropicによって仕様が策定され、現在はオープンソース化されています。現在C#、Java、Kotlin、Python、Ruby、Swift、TypeScript向けのSDKが提供されており、幅広い言語環境で利用できること、AIアプリケーションのUSB-Cポートとして標準化されていること、そして認証認可にOAuth2.1を用いることが必須要件となっている点など、順次仕様が変更されており、新しいプロトコルとして注目を浴びています。またオープンソースであることやそのコンセプトから多くの実装例がすでに存在しています。一方でセキュリティ上の問題点も指摘されています。

図4:MCP関連の主なセキュリティ課題

MCP関連のセキュリティ課題（仕様レベル・実装上の問題、AI・MCA独特の脆弱性、一般的な問題）

A2A（Agent-to-Agent）とは

A2AはGoogleが立ち上げたエージェント間の通信プロトコルで、2025年6月にLinux財団に寄付され、Linux財団を中心に開発が進められています。こちらはGoogleのVertexなどを皮切りに実装が始まっています。A2Aプロトコルはマルチエージェントでの処理のニーズの増大、クラウドでのベンダーロックイン問題の影響でベンダーロックインの回避への強い要求があったことや、AIエージェントに対するコンプライアンスやガバナンス要求（EUのAI法など）の高まりといったところにうまくマッチしたものとも言えます。

AIエージェントは今後の開発を大きく変える存在ですが、その基盤を支えるのがMCPやA2Aといった標準プロトコルです。次回第4回では、これらの仕組みをより詳しく掘り下げ、エンジニアが知っておくべき活用ポイントを解説します。

―第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」へ続く―

【参考情報】

【連載一覧】

―第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」―
―第2回「プロンプト以外で効率化！開発体験の改善手法」―
―第3回「AIエージェント時代のコーディング：MCPとA2Aとは」―
第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」
第5回「AIとセキュリティ：Non‑Human Identity とAIエージェントの課題」
第6回「AIエージェントのセキュリティ対策と今後の展望」

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2025年8月14日2025年9月28日

狙われる医療業界2025 医療機関を標的とするサイバー攻撃

Security NEWS TOPに戻る
バックナンバー TOPに戻る

前回の記事の公開から約5年が経ちましたが、医療機関を標的とするサイバー攻撃の脅威はむしろ増加しています。特にランサムウェアによる被害は国内外問わず深刻化し、患者の命が危険に晒されてしまう可能性も出てきています。いまやインシデントを“他人事”とせず、「命を守るもの」という認識で組織一丸となってセキュリティ対策の見直しをすることが重要です。本記事では医療機関へのサイバー攻撃の脅威とセキュリティ対策の見直しのためのポイントをご紹介します。

2020年12月公開の記事「狙われる医療業界―「医療を止めない」ために、巧妙化するランサムウェアに万全の備えを」をまだご覧になっていない方はぜひ、この機会にご一読ください。

世界的に高まる医療分野へのサイバー攻撃

ランサムウェアによる被害は世界中で後を絶たず、いまや医療分野は重要な標的の一つとされています。米国のセキュリティ監視サイトRansomware.liveの統計によれば、2025年時点でランサムウェア被害を受けた業種の中で、医療・ヘルスケア関連は第3位に位置しています。医療業界が金融や行政に並ぶほどの標的となっている現実は、決して無視できません。

Ransomware.live統計円グラフ（ランサムウェア被害を受けた業界） — 出典：Ransomware.live「Ransomware Statistics for 2025」（https://www.ransomware.live/stats）

国内でも相次ぐ深刻な被害事例

日本国内でも、深刻な被害事例が相次いで報告されています。たとえば2024年3月、鹿児島県の国分生協病院では、ランサムウェアによるサイバー攻撃により、電子カルテをはじめとする複数のシステムが使用できなくなり、患者の診療に支障が出るという被害が発生*4しました。また、同年の5月に起きた岡山県精神科医療センターでは、外来診療の一部を中止せざるを得ない事態に追い込まれました*2。このように、サイバー攻撃は単に業務の一時停止を招くだけでなく、医療提供そのものに影響を与え、患者の命を危険に晒す恐れがあるという点で、他業種におけるサイバー被害とはその意味において一線を画します。

サイバー攻撃は“日常の医療”を止めうる

Silobreaker社がまとめた医療業界に関する分析レポートでも、ヘルスケア分野に対するサイバー脅威の増加は顕著であり、医療情報の価値の高さとシステムの脆弱性が攻撃を呼び込んでいると指摘されています。国内外でのこうした事例は、「サイバー攻撃が日常の医療を止め得る存在である」という現実を強く物語っています。特に日本では、「まさかうちが」という意識が依然として根強く残っているのが現状ですが、医療機関はすでに、攻撃者にとって“おいしいターゲット”であることを自覚すべき時期に来ています。

攻撃者はなぜ医療機関を狙うのか

攻撃側の論理①わきの甘さ＝「機会要因」の存在

医療機関がサイバー攻撃の標的になる。―これはもはや偶発的なものではなく、確かな傾向として定着しつつあります。過去の記事でも言及しましたが、2025年現在ではその背景にある“攻撃側の論理”がより鮮明になってきています。

多くの人が誤解しがちなのは、「医療機関は狙われている」という表現があたかも特定の施設に対して意図的な攻撃が行われている、という印象を与えてしまう点です。確かに、一部には病院のネットワークやデータに照準を合わせた標的型攻撃も存在します。しかし実態としては、多くの場合、攻撃者は最初から「病院を狙って」いるわけではありません。攻撃者は、不特定多数の組織や端末に対して無差別にスキャンをかけ、リモートアクセスサービスやVPN機器、ファイル共有サーバといった、公開された情報から侵入経路を探しています。そしてその中で、意図せず医療機関が引っかかるのです。つまり、標的にされたのではなく、“侵入可能だったから侵入された”というのが現実なのです。

医療機関では古いシステムが更新されずに残っている、または、ネットワークの分離が不完全なまま稼働していることがあります。また、パスワードの使い回し、脆弱性が放置されたソフトウェア、機器の寿命サイクルの見落としなど、基本的なセキュリティ対策に隙があることが少なくありません。そして、攻撃者にとっては、それこそが格好の「入り口」になるのです。

攻撃側の論理②「動機」金になる標的としての医療機関

ランサムウェア攻撃を実行するサイバー攻撃者の目的は、金銭的な利益です。医療機関には、個人情報（診療記録、保険情報、連絡先など）や経営上の内部資料、研究データといった売買可能な資産が豊富にあります。また、医療機関は儲かっているように思われており、そのうえで業務の中断が患者の生命に直結するため、身代金の支払いに応じやすいに違いない、と見られているわけです。つまり、医療機関が狙われるのは、「わきが甘いから侵入しやすい」＋「金銭的利益を得やすい重要なデータの宝庫である」＝“コストパフォーマンスに優れた良い標的”と見なされているからと考えられます。

2020年以降医療サイバーセキュリティはどう変わったのか

制度とガイドラインの整備が進む

前回の記事からの5年間で、医療分野のサイバーセキュリティを取り巻く制度やガイドラインも着実に充実してきています。例えば2025年5月に、厚生労働省から「医療機関等におけるサイバーセキュリティ対策チェックリスト（令和7年5月版）」が公開され、以前に比べて具体的かつ実践的な内容になっています。クラウド環境やBCP（事業継続計画）への配慮、IoT・BYODといった新たなリスクへの言及も盛り込まれています。

また、CSIRT（Computer Security Incident Response Team）を設けたり、EDR（Endpoint Detection and Response）などの対策製品を導入したりする医療機関も増えてきました。CSIRTを中心とした地域単位の訓練や、院内外のネットワーク構成の共有と点検を含む取り組みが、学術会議や業界団体の枠組みとして増加しています*3。サイバー攻撃に備える土台作りは、着実に進みつつあるといえるでしょう。

2025年いまだ残る基本的な課題

一方で、5年前と変わらぬ問題を目にする場面も少なくありません。その一つが、「パスワード管理」です。初期設定のまま放置されたアカウント、業務上の利便性から生まれる使い回し。こうしたわきの甘さが、攻撃者の入り口になることは以前から分かっていたはずですが、2024年の岡山県精神科医療センターの事例などを見ると、なおも同様の傾向が残っていることがうかがえます。また、電子カルテやシステムのクラウド化に対しても、依然として現場では極端な見方が交錯しているように思えます。「クラウドだから安全」と根拠のない安心感を持つ一方で、「クラウドだから怖い」「電子カルテという形式そのものが危ない」といった漠然とした不安も根強く見受けられます。

どちらにしても共通するのは、仕組みやリスクを正しく理解しないまま思い込んでいるケースが少なくないということです。実際には、クラウドの活用は有効な手段のひとつでありつつも、アクセス制御や端末管理、ネットワーク構成など、設定次第でその安全性は大きく変化します。こういった基本的な理解の重要性や注意点は、5年前から現在も変わらずに示され続けてきたものですが、いまだに“本質的な理解”が広がり切っていないように見受けられます。

基本的な課題の根底には、インシデントを“自分事”として捉えづらい空気があるのかもしれません。実際に深刻な被害を受けた他機関の事例を目にしても、「うちには関係ない」とどこかで思ってしまう感覚。それは、ごく自然な反応である一方で、取り返しのつかないインシデントに繋がりかねません。

自組織のセキュリティ対策の見直しを

医療機関向けチェックリストやガイドラインの活用

ここまで見てきたように、医療機関に対するサイバー攻撃は後を絶たず、その影響は診療の継続性や患者の安全、そして組織の信頼性にまで及びます。「自分たちは大丈夫だろう。」「人命最優先で、他を考えている余裕はない。」―そのように考えがちですが、日々の業務に追われている医療現場こそ、今一度立ち止まって、対策の棚卸しを行うことが求められています。対策の見直しにあたっては、厚生労働省が公開している「医療機関等におけるサイバーセキュリティ対策チェックリスト（令和7年5月版）」の活用が効果的です。

厚生労働省「医療機関等におけるサイバーセキュリティ対策チェックリスト（令和７年５月）」https://www.mhlw.go.jp/content/10808000/001253950.pdf

本チェックリストは、技術的な対策だけでなく、組織体制や訓練、業者選定の観点まで網羅されており、現場レベルでも活用しやすい実践的な内容となっています。また、業界全体で参照される基準として、次のようなガイドラインも押さえておくとよいでしょう。

厚生労働省「医療情報システムの安全管理に関するガイドライン　第6.0版（令和5年5月）」
経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」

これらの資料には、医療の特殊性を踏まえた対応策が具体的に記載されており、ベンダや関係業者との連携の際にも参考となります。

現場の声と経営的視点をつなげる「可視化」

セキュリティ対策は単なる技術的作業にとどまらず、組織全体で「守るべきもの」を共通認識することが大切です。そのためにも、経営層が積極的に関与し、現場の声を聴きながら継続的な投資と改善を進めていくことが求められます。医療機関にとって、セキュリティはコストではなく、患者の信頼と組織の生命線であることを改めて認識すべきです。その助けになるのが、リスクの「可視化」です。

仮に端末のひとつがマルウェアに感染したとき、その端末が院内のどの機器と通信しているのか、そこから電子カルテや予約システムにアクセスされたりしないか、バックアップはきちんと機能するかなどなど…。こうした攻撃時の経路や起きうる事象をあらかじめ可視化し、把握しておくことは、被害拡大の防止やインシデント対応の迅速化に大きな効果をもたらすのみならず、経営層の理解を得ることにもつながります。可視化によって得られる「想定していなかった侵入経路」「明らかになる不十分なセキュリティ対策」「攻撃発生時に起きうる具体的な被害」といった情報が、経営層や多くの医療従事者に理解してもらい、組織全体で防御力を高めるための重要な意思決定のための正しい判断材料となりえるでしょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。詳細・お見積りについてのご相談は、以下のフォームよりお気軽にお問い合わせください。後ほど、担当者よりご連絡いたします。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

また費用の問題から十分な初動対応ができないといった問題が発生しかねない状況を憂え、SQAT^® 脆弱性診断サービスのすべてに、サイバー保険を付帯させていただいています。

サイバー保険付帯の脆弱性診断サービス

BBSecのSQAT^® 脆弱性診断サービスすべてが対象となります。また、複数回脆弱性診断を実施した場合、最新の診断結果の報告日から1年間有効となります。詳細はこちら。
https://www.bbsec.co.jp/service/vulnerability-diagnosis/cyberinsurance.html
※外部サイトにリンクします。

エンドポイントセキュリティ

組織の端末を24時間365日体制で監視し、インシデント発生時には初動対応を実施します。
https://www.bbsec.co.jp/service/mss/edr-mss.html
※外部サイトにリンクします。

インシデント初動対応準備支援

体制整備や初動フロー策定を支援します。
https://www.bbsec.co.jp/service/evaluation_consulting/incident_initial_response.html
※外部サイトにリンクします。

ウェビナー開催のお知らせ

2025年8月20日（水）13:00～13:30
「EC加盟店・PSP必見！クレジットカード・セキュリティガイドライン6.0版対応ウェビナー」

2025年8月27日（水）13:00～14:00
「【最短7営業日で診断＆報告】サイバー保険付帯脆弱性診断「SQAT® with Swift Delivery」のご紹介」

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2025年8月4日2025年8月22日

【長期休暇前の見直しを！】ネットワーク図が消えた瞬間─ランサムウェア時代のインシデント対応を左右する“準備”の質

Security NEWS TOPに戻る
バックナンバー TOPに戻る

インシデントレスポンス・フォレンジック記事アイキャッチ画像（パソコンと火のイメージ）

長期休暇は攻撃者にとっての“ゴールデンタイム”─攻撃の隙を突かれ、組織のネットワーク図や構成情報が暗号化されてしまえば、インシデント初動対応やフォレンジック調査に大きな支障が生じます。本記事ではランサムウェア攻撃の実例を交えつつ、サイバー攻撃への対策の要点を解説します。

図面サーバが暗号化された実例が突きつけた現実

2021年1月、プエルトリコ財務省（Hacienda）の共有サーバがランサムウェア「Ryuk」によって暗号化されました。困難を極めたのは業務システムそのものではなく、インシデント対応の羅針盤となるIDSログとネットワーク図まで人質に取られたことでした。CompSec Direct社は、外部のDFIR（Digital Forensics & Incident Response）チームが構成を把握するまでに数時間を費やし、その間オンライン納税が全面停止した結果、１日あたり2000万ドルを超える税収が失われたと報告しています。さらに同様のリスクが民間企業にも差し迫っています。Microsoft Igniteで発表されたランサムウェアバックアップ戦略ガイド「Ransomware attack recovery plan」では、「ネットワーク図やCMDBは攻撃者が真っ先に狙う復旧用ドキュメントであり、失えば復元計画そのものが成立しなくなる」と警鐘を鳴らしています。

ネットワーク図はフォレンジック調査とCSIRTの羅針盤

マルウェア感染が判明した直後、CSIRT（Computer Security Incident Response Team）はネットワークをどこで遮断すべきか、どのホストでメモリダンプやパケットキャプチャを始めるべきかを瞬時に決めなければなりません。その判断を支える“地図”こそ最新のネットワーク図です。AWS Incident Response「Document and centralize architecture diagrams」でも、アーキテクチャ図を一元的に保管し常に更新しておくことが「迅速かつ正確な封じ込めの前提」と明示しています。

フォレンジック担当者にとっても図面は欠かせません。感染セグメントの境界を論理的に隔離し、ログ残存率の高い経路を優先してトラフィックを保存し、横展開を想定したホストに的を絞ってメモリを取得する—こうした分単位のオペレーションは、正確な構成情報があって初めて迷いなく実行できます。図面が欠落した状態では、調査は手探りになり、感染拡大のリスクが急激に高まります。

攻撃者が真っ先に狙う“復旧用ドキュメント”

近年のランサムウェアは単にシステムを暗号化するだけでなく、復旧の要となるバックアップやドキュメントを破壊・窃取する二重・三重恐喝が主流です。Microsoftは前述した「Ransomware attack recovery plan」の中で、図面を含む復旧ドキュメントを必ずイミュータブルまたはオフラインの領域へ隔離し、管理者権限を奪われても書き換えられないように設計することを強調しています。この”文書奪取型”の攻撃は、組織が身代金を支払わざるを得ない状態へ追い込む目的で計画的に行われます。したがって、図面の退避先をシステムとは別レイヤーに置く設計思想そのものが、ランサムウェア時代の事業継続計画（BCP）の根幹となります。

三層バックアップと3-2-1 ルール—図面を守るための冗長化設計

攻撃者がドキュメントを狙う前提を踏まえ、Microsoft Azureや多くのクラウド事業者は「三層バックアップ」を基準として推奨しています。第一層は多要素認証を必須化したオンラインバックアップで、日常的な迅速リストアを担います。第二層はクラウドのイミュータブルストレージで、週次コピーを保管し、管理者権限の奪取による改ざんを防ぎます。第三層は完全オフラインの隔離媒体で月次アーカイブを保持し、最悪のシナリオでも“最後の砦”として機能します。この三層構造の流れは下図の通りです。

三層バックアップは、しばしば「三つのコピー・二種類の媒体・一つはオフサイト」という 3-2-1ルールとも呼ばれ、ログやアプリケーションデータだけでなくネットワーク図のような復旧必須ドキュメントにもそのまま適用できます。重要なのは、図面を単なるPDFとして保存するのではなく、バージョン管理システムやIaC（Infrastructure as Code）ツールで変更履歴を残し、更新が発生するたびに自動でイミュータブル層へ複製する運用プロセスを組み込む点にあります。

長期休暇は“攻撃者のゴールデンタイム”

大型連休や年末年始は、内部管理者の不在や監視体制の手薄さを突く格好のタイミングです。実際、米CISAと FBIは2021年のレイバー・デー (Labor Day=労働者の日)を前に、「過去の大規模ランサムウェア攻撃は、週末や祝日の直前に集中する傾向がある」と共同アドバイザリ「Ransomware Awareness for Holidays and Weekends」を公開し、平時よりも高い警戒レベルを求めました。

国内でも2024年4月、独立行政法人情報処理推進機構（IPA）が「2024年度ゴールデンウイークにおける情報セキュリティに関する注意喚起」を発表し、「長期休暇中は管理者が長期間不在になるため、インシデント発生時の対応が遅れ、休暇明けの業務継続に影響が及ぶ恐れがある」と警告しています。連休を狙った攻撃が成功しやすい背景には、VPNやリモートデスクトッププロトコル（RDP）のパッチ未適用、監視ログの見落としといった“人的スキマ”が重層的に生じる点があります。

「連休前点検」と「連休後フォロー」を年間行事に

休暇入りの二週間前を目安に、ネットワーク図とCMDB（構成管理データベース）の最新版をイミュータブル層へ複製し、外部ベンダーとも共有確認を行う—これだけで、もし連休中に図面サーバが暗号化されても代替コピーを即座に展開できます。さらに休暇明け初日に、ログの異常値とバックアップ整合性をチェックする“フォローアップ窓”を設ければ、潜伏期間の長いマルウェアを早期に検知できます。

平時にベンダー契約を結び、図面を安全に共有する

インシデント対応は社内リソースだけで完結しない局面が多くあります。経済産業省が公開した中小企業向け手引きでも、専門知識が不足する場合は外部ベンダーへ速やかに支援を依頼するよう明記されています。ところが緊急時に初めて見積もりを取得し、社内決裁を経て、機密保持契約（NDA）を交わすようでは手遅れになりかねません。またNIST SP 800-61 Rev.3でも、外部サービスプロバイダーとの契約には責任分界点・連絡フロー・緊急時の権限を事前に文書化し、図面や資産リストを暗号化して共有しておくべきだと指摘しています。

図面を平時から共有しておけば、ベンダーは現地到着と同時に封じ込めポイントやログ取得手順を提示できる―これが、初動を数十分で完了させるか、半日を失うかの分岐点となります。

図面更新運用「変更が起きた瞬間にバックアップを取る」

ネットワーク構成は日々変化します。クラウドのセキュリティグループを1行書き換えるだけでも、感染経路や封じ込め手順は一変します。したがって、図面更新の責任を特定の担当者に寄せるのではなく、CI/CDのパイプラインに組み込んで自動化するアプローチが有効です。例えば、IaCテンプレートを最新版にマージすると同時に、図面を自動生成し、イミュータブル層へコミットする―こうして「変更＝バックアップ」のトリガーを組織文化として定着させることで、人為的な更新漏れを防止できます。

クラウド・オンプレミスを跨ぐハイブリッド環境への適用のポイント

ハイブリッド環境では、クラウド側のアーキテクチャ図とオンプレの物理配線図を統合的に管理する必要があります。AWS Systems Manager Application ManagerやAzure Arcなどのサービスを活用すると、マルチクラウド／オンプレ資産を単一のリポジトリへ収集できる。こうして得られたメタデータをエクスポートし、Visioやdraw.ioで図面化して保管すれば、プラットフォームを跨いだ封じ込め手順を迅速に策定できます。

90日で構築する“図面と契約”のロードマップ

まず、30日以内に既存図面の所在を棚卸しし、漏れや重複を洗い出します。次の30日で三層バックアップを設計し、イミュータブル層とオフライン層へのコピーサイクルを自動化します。最後の30日でMSSPやクラウドベンダーとの契約書に図面共有条項を追加し、緊急連絡網と責任分界点を明文化します。こうした段階的な取り組みを通じて、図面が失われても数分で代替コピーを展開できる体制が完成します。

まとめ：今日から始める“図面と契約”の棚卸し

ネットワーク図は初動対応の生命線であり、失えば封じ込めもフォレンジックも大幅に遅れます。図面そのものが攻撃者の標的になる現実を踏まえ、イミュータブルストレージと完全オフライン媒体を組み合わせた三重の防御を施すことが不可欠です。さらに、平時からMSSPやフォレンジックベンダーと契約し、暗号化した図面を安全に共有しておけば、いざという時に“地図を持った専門家”が数分で封じ込めを開始できます。図面が手元にあるか否かで、インシデント対応は「数時間」で済むか「数日」を要するかが決まります。ランサムウェアが猛威を振るう2025年、まずはバックアップ設計とベンダー契約を棚卸しし、次の長期休暇を迎える前に備えを万全にしましょう。

サイバーインシデント緊急対応

【参考情報】

Microsoft Ignite,[Ransomware attack recovery plan]（ランサムウェア対策のバックアップ計画）
https://learn.microsoft.com/en-us/security/ransomware/protect-against-ransomware-phase1
AWS,Security Incident Response,[Document and centralize architecture diagrams]（アーキテクチャ図の文書化と一元化）
https://docs.aws.amazon.com/security-ir/latest/userguide/document-and-centralize-architecture-diagrams.html
CISA,FBI,Cybersecurity Advisory,[Ransomware Awareness for Holidays and Weekends],Last RevisedFebruary 10,2022
https://www.cisa.gov/sites/default/files/publications/AA21-243A-Ransomware_Awareness_for_Holidays_and_Weekends.pdf
IPA「2024年度ゴールデンウイークにおける情報セキュリティに関する注意喚起」
https://www.ipa.go.jp/security/anshin/heads-up/alert20240422.html
経済産業省「中小企業のためのセキュリティインシデント対応の手引き」
https://www.meti.go.jp/policy/netsecurity/sme_incident.html
NIST SP 800-61 Rev. 3
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年8月5日（火）14:00～15:00
「企業サイトオーナー向けユーザーからのレピュテーションを高めるWebサイトの在り方-Webサイトを取り巻くリスク・規制・要請とユーザビリティ向上-」

2025年8月20日（水）13:00～13:30
「EC加盟店・PSP必見！クレジットカード・セキュリティガイドライン6.0版対応ウェビナー」

最新情報はこちら

2025年7月10日2025年8月14日

ドメイン名偽装で検知を回避するWordPressマルウェアの脅威と対策

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2025年7月、セキュリティ企業SucuriがWordPressを狙う新たなマルウェア攻撃を発見・公表しました。今回公表された「SEOスパム型WordPressプラグイン」による攻撃は従来の攻撃と比較して手口が巧妙化しており、世界中のWebサイト管理者にとって深刻な脅威となっています。本記事では、攻撃の手口と被害の特徴、そして有効な対策について解説します。

contents

お問い合わせ

お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

攻撃手法

ドメイン偽装によるマルウェア検知回避

今回発見されたマルウェアは、感染したWordPressサイトのドメイン名をそのままプラグイン名やフォルダ名に偽装して設置されます。これにより、管理者や一般ユーザーがファイル一覧を確認しても、正規のプラグインと見分けがつきにくい構造になっています。この偽プラグインは高度に難読化されたコードで構成されており、セキュリティ対策ソフトによる検知も困難です。

検索エンジン限定のSEOスパム注入

SEOスパムの注入は、Googleなどの検索エンジンのクローラを検知した場合のみ実行されます。通常の訪問者には正規のページが表示されるため、管理者も異常に気付きにくく、発見が遅れる原因となります。検索エンジンのみにスパムコンテンツを返すことで、検索順位の操作や不正なトラフィック誘導が行われます。

C2サーバとの通信と外部指令の受信

この偽プラグインの内部には、base64で難読化されたC2（コマンド＆コントロール）サーバ※ のドメイン情報が隠されています。偽プラグインは定期的にC2サーバへ外部リクエストを送り、攻撃者からの指示を受け取ります。これにより、スパム内容の動的な更新や追加のマルウェア配布など、攻撃の手口が柔軟に変化する仕組みが実装されています。

※C2（コマンド＆コントロール）サーバ…サイバー攻撃者が外部から侵害システムと通信を行い、命令と制御を行う目的で用いられる。

マルウェアによる被害と影響

この種のマルウェアは、通常の利用者やサイト管理者が直接アクセスした場合には一切異常を示さないため、発見が遅れがちです。Googleなどの検索エンジン経由でのみスパムが表示されるため、被害に気付いたときにはすでに検索結果にスパムページが表示されていたり、検索順位が大幅に下落しているケースも多く、ブランドイメージや集客に深刻な影響を与えたりするおそれがあります。また今回の例は、WordPressのプラグインエコシステムを悪用したサプライチェーン攻撃の一例とも言えます。公式リポジトリを介さず、外部から導入されたプラグインやテーマを通じて感染が広がるため、信頼できる配布元からのみソフトウェアを導入することが重要です。

有効な対策と管理者が取るべき予防措置

Webサイト管理は特に以下のような対策を取り、異常が見られた場合は速やかに専門家へ相談することをおすすめします。

WordPressのプラグインやテーマは必ず公式リポジトリや信頼できるベンダーからのみ入手する
不審なファイルや見覚えのないプラグインが存在しないか、定期的にサーバ内を確認する
セキュリティプラグインやWebアプリケーションファイアウォール（WAF）、管理画面への多要素認証を導入する
Google Search Console等で検索結果の異常を監視する

まとめ

SEOスパム型の偽装WordPressプラグインは、検索エンジンのクローラを標的にしてスパムコンテンツを注入し、通常の訪問者には正規ページを返すという極めて巧妙な手口です。攻撃者は感染サイトのドメイン名をそのままプラグイン名やフォルダ名に偽装し、管理者の目を欺きます。さらに、コード内部にはbase64で難読化されたC2サーバ情報が隠され、外部からの指令に応じて動的にスパム内容を更新できる仕組みも組み込まれています。

このような手法は、発見が遅れやすく、検索順位の下落やサイトの信頼性低下など、経営や運営に深刻な影響を及ぼすリスクがあります。特に、公式リポジトリを介さないプラグインやテーマの導入が感染経路となるケースが多いため、日常的なセキュリティ意識と運用管理の徹底が不可欠です。

被害を最小限に抑えるためには、信頼できる配布元からのみソフトウェアを導入する、サーバ内の不審なファイルやプラグインを定期的に点検する、Google Search Consoleなどで検索結果の異常を監視するなど、複数の対策を組み合わせることが重要です。

BBSecでは：セキュリティソリューションの活用

高度なサプライチェーン攻撃や難読化マルウェアに対抗するため、ブロードバンドセキュリティでは多層防御の観点から次のようなソリューションを強くおすすめします。

エージェント型Webサイトコンテンツ改ざん検知サービス

WordPressサイトのファイルやディレクトリの改ざんをリアルタイムで監視し、異常があれば即座にアラートを発します。正規のプラグイン名を偽装した不審なファイルの追加や書き換えも検知しやすく、被害の早期発見に役立ちます。

https://www.bbsec.co.jp/service/vd-maintenance/manipulation.html
※外部サイトにリンクします。

脆弱性診断サービス

WordPress本体やプラグイン、テーマの設定や実装に潜む既知の脆弱性を定期的に洗い出すサービスです。悪用されやすい箇所を事前に把握し、攻撃の入り口を減らします。診断結果に基づき、不要なプラグインの削除や設定の見直しを行うことで、リスク低減につながります。

ペネトレーションテスト

実際の攻撃者の視点でお客様のシステムに実装済みのセキュリティを検証するサービスです。自動化された攻撃だけでなく、手動による高度な手法も用いるため、通常の診断では見つけにくいサプライチェーンリスクや運用上の盲点も洗い出すことが可能です。

これらのサービスを組み合わせて導入することで、巧妙化するマルウェア攻撃などへの対応力を大幅に高めることができます。BBSecとしては、エージェント型改ざん検知、脆弱性診断、ペネトレーションテストをパッケージ化した多層防御ソリューションを強くご提案いたします。これにより、WordPressサイト運営者の方が安心してビジネスを継続できる環境づくりをサポートいたします。ご希望の方には、無料相談や初回診断も承っております。お気軽にご相談ください。

お問い合わせ

お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

【参考情報】

ウェビナー開催のお知らせ

2025年7月16日（水）14:00～15:00
「進化するランサムウェア攻撃-国内最新事例から学ぶ！被害を防ぐ実践ポイント10項目を解説-」

2025年7月23日（水）14:00～15:00
「急増するフィッシング攻撃の実態と対策〜企業を守る多層防御とは〜」

2025年7月30日（水）13:00～13:50
「Webサイトの脆弱性はこう狙われる！OWASP Top 10で読み解く攻撃と対策」

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2025年7月2日2025年7月8日

JCDSC「カードセキュリティフォーラム 2025」講演レポート

概要

2025年6月27日（金）、日本カード情報セキュリティ協議会（JCDSC）主催「カードセキュリティフォーラム 2025」にて弊社社員が講演登壇を行いました。クレジットカードセキュリティをテーマに、クレジットカードセキュリティガイドライン【6.0版】、PCI DSSv4.0.1対応をテーマにしたセッションのほか、PCI SSCの認定セキュリティ評価機関であるQSA（Qualified Security Assessor）3社、株式会社ブロードバンドセキュリティ、国際マネジメントシステム認証機構(ICMS)、NRIセキュアテクノロジーズ株式会社によるパネルディスカッションも行われました。

弊社講演内容

「PCI DSS v4.0.1運用の課題とベストプラクティス対応状況」

QSA 3社により、PCI DSS v4.0.1の運用とベストプラクティス課題について、顧客企業が対応に苦心した事例を紹介・解説し、ポイントについてパネルディスカッションを行いました。パネラーとして、弊社QSAの宮坂が登壇しました。

パネリスト：
①国際マネジメントシステム認証機構(ICMS)
②株式会社ブロードバンドセキュリティ
③NRIセキュアテクノロジーズ株式会社

「PCI DSS v4.0.1対応と有事の備え」／伊藤祐生雄（株式会社ブロードバンドセキュリティ）

PCI DSS v4.0.1対応で求められるログ監視の自動化は、早期検知・早期対応による被害最小化と、カード情報漏洩や外部からの不正アクセス・マルウェア感染といったリスクに対し、有事対応力を高める鍵となります。フォレンジック事業者（PCI Forensic Investigator）として最新インシデント事例を交えながら、インシデントに強い体制づくりを支える新MDRサービス「G-MDR^TM」をご紹介しました。

「クレカ・セキュリティガイドライン【6.0版】改定ポイント／木下祐希（株式会社ブロードバンドセキュリティ）

カード不正利用被害が深刻化する中、最新のクレジットカード・セキュリティガイドライン6.0版では、加盟店の脆弱性対策強化とPSPの支援責任が明確化されました。本講演では改定ポイントを整理し、実効性ある対策とPSPが果たすべき役割について解説しました。

そのほかの講演内容はこちら
※外部サイトにリンクします。

今後ともブロードバンドセキュリティ（BBSec）を引き続きどうぞよろしくお願い致します。

当サイト「SQAT.jp」について

SQAT.jpは、株式会社ブロードバンドセキュリティセキュリティサービス本部の管理・運営によるサイトです。

株式会社ブロードバンドセキュリティとは

株式会社ブロードバンドセキュリティ（BroadBand Security, Inc./BBSec）は、2000年の創業以来、様々なニーズに対応するセキュリティサービス事業を展開してまいりました。セキュリティ・コンサルティング、デジタル・フォレンジック、脆弱性診断、マネージドセキュリティサービスなど、対応分野を次々と拡大。ITセキュリティのエキスパートとして、豊富な知識と経験に裏打ちされた高品質のサービスをお届けしています。

セキュリティサービス本部とは

セキュリティサービス本部は脆弱性診断を主サービスとするエンジニアリング本部です。エンジニア、アナリスト、ホワイトハッカー等から編成された精鋭チームが、お客様システムに潜む脆弱性を検証し、改善案を提示するサービスを提供しています。お客様は金融機関・インターネット事業者などの民間企業から、官公庁をはじめとする公共機関まで幅広く、これまでに延べ10,300組織、64,280を超えるシステムの健全化に貢献しています。（2025年6月時点）