タグ: セキュリティ

投稿日:

AIコーディング入門
第6回：AIエージェントのセキュリティ対策と今後の展望

Share

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

AIコーディング入門アイキャッチ（AIエージェントのセキュリティ対策と展望）

AIエージェントは従来のアプリケーションとは異なる特性を持ち、セキュリティ対策も新しい技術との統合が求められます。次世代の手法を取り入れることで、未知の脅威に対応し信頼性を確保するアプローチが検討されています。「AIコーディング入門」の最終回では、AIエージェントを取り巻くセキュリティ対策について解説します。

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

AIエージェントとセキュリティの新たな課題

AIエージェントのセキュリティ対策には新しい技術の適用も必要となります。例えば前回「第5回:NHI（Non‑Human Identity）とAIエージェントのセキュリティ課題」の表3:ポストゼロトラストアプローチでご紹介したエフェメラル認証には量子耐性暗号が必要となりますし、AIエージェントが一貫したセキュリティポリシーを維持しながら複数システム間で動作できるアイデンティティのフェデレーション、入出力の異常や悪意のある動作の検知のための継続的監視など、次世代のセキュリティ技術との統合アプローチも検討されています。

表1:AIエージェントセキュリティと新規技術の統合

技術領域統合方法期待効果
量子耐性暗号エフェメラル認証は量子耐性アルゴリズムやゼロ知識証明などの新興技術と共に進化する可能性将来の暗号解読攻撃への対応
アイデンティティ連合（Identity Federation）AIエージェントが一貫したセキュリティポリシーを維持しながら複数システム間で動作できるアイデンティティ連合機能マルチクラウド・ハイブリッド環境での統一セキュリティ
解釈可能AI説明可能AIシステムによる透明で理解可能な意思決定プロセスAIエージェントの行動予測性と信頼性向上
継続的監視AI システムの入力と出力の異常または悪意のある動作を監視し、脅威検出のためにAI行動分析を適用リアルタイム脅威検出と対応
形式的検証ニューラルネットワークの敵対的堅牢性を証明するSMTソルバーや抽象解釈技術の活用数学的に証明可能なセキュリティ保証
フェデレーテッドラーニング対策ビザンチン耐性集約ルールによるモデルポイズニング攻撃の防御分散学習環境での信頼性確保
出典：次のソースより弊社にて翻訳、編集,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)

まとめ

ここまででまとめてきた通り、Agenticコーディングの一要素であるAIエージェントにはすでに多くのセキュリティ課題が存在していることが知られています。また、様々な対策の検討も進んでいます。AIによるコーディングそのものにも課題があり、エージェントについてもエージェントそのものの課題に加えてエージェントとアプリケーション間、マルチエージェント間のプロトコルの仕様及び実装上のセキュリティ課題が存在します。さらに、従来型のAppSec寄りのセキュリティアプローチはAIエージェントのセキュリティ対策としては不十分であることもご説明した通りです。今までにないエンティティであるAIエージェントに対して、セキュリティ対策も今までにない技術を取り入れて進んでいくことは間違いないところでしょう。AIエージェントをサービスの一つとして利用する、またはAIエージェントを自社サービス向けに開発する場合、現在進行形で新しい課題や新しい対策が次々に現れてくる状況であることを認識しながら、適時判断と対応ができる体制をまずは整えることが重要ではないでしょうか。また、今後導入を検討される場合はAIやAIエージェントのメリットを十分に生かしつつ、利用中に新しく提供されるセキュリティ対策や新しいセキュリティポリシー、セキュリティアプローチといったものを柔軟に受け入れて消化していけることも重要になるでしょう。

今までのAppSecとは全く異なるもの、それがAIエージェントであり、今までのコーディングと全く異なるものがAgenticコーディングなのです。

付録: マルチエージェントの脅威モデリング：MAESTROとは

最後に、「第4回：MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」でご紹介した、A2Aプロトコルのセキュリティ上の課題の際に触れた、マルチエージェント環境の脅威モデリングであるMAESTROについて解説します。

図1:MAESTROの7レイヤ アーキテクチャ

MAESTROの7レイヤ アーキテクチャ

OWASPが定義したMAESTROについて解説された記事をもとに記載しています。

MAESTROモデリングはマルチエージェント環境の複雑な環境・エコシステムを評価する目的でOWASPが定義した脅威評価モデルです。エージェントが複数に及び、関連するサービスも多岐にわたる前提での評価に必要な階層型の評価フレームワークを提供しています。このモデルはマルチエージェントシステムの構築・実装・防御関係者やセキュリティ専門家、プラットフォームエンジニアなどが幅広く利用することを想定されているものです。

【連載一覧】

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

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

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

  • 2025年9月17日（水）14:00～15:00
    「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」
  • 2025年9月24日（水）12:50～14:00
    「製造業・自動車業界のためのサプライチェーン対策 -攻撃事例から学ぶ企業を守るセキュリティ強化のポイント-」
  • 2025年10月1日（水）13:00～14:00
    「2025年10月Windows10サポート終了へ 今知るべきサポート切れのソフトウェアへのセキュリティ対策ガイド」

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

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

    Share

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

    IoT活用とIoTセキュリティアイキャッチ画像（IoTセキュリティの脅威）

    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年）

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

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

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

    Share
    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エージェントの履歴行動、異常検知、セキュリティ態勢に基づく動的信頼スコアの割り当てによる継続的な信頼性評価エージェントのライフサイクル全体を通じた信頼性管理
    出典：次のソースより弊社にて翻訳、編集,Cloud Security Alliance “Agentic AI Identity Management Approach | CSA ” (Ken Huang, 2025),DHS ” Safety and Security Guidelines for Critical Infrastructure Owners and Operators” (2024)

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

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

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

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

    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
    「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

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

    Share

    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 エージェントを利用する組織、システムの利用者高大入力検証: エージェントのモデルにコンテンツを送信する前に厳格な入力検証を実施する。入力をサニタイズする。
    出力検証: 生成されたメッセージのコンテンツに有害なコンテンツ、矛盾、または予期しない動作がないか確認する。コンテンツフィルタリングを使用する。非決定論的なモデルの動作に対する出力検証の堅牢性を高めるために、アンサンブル法や敵対的訓練などの技術を採用する。
    慎重なプロンプト設計: 敵対的攻撃の影響を受けにくいプロンプトを設計する。モデルをガイドするために少数ショットの例を使用する。
    モデル抽出A2A を介した過度または巧妙な対話により、プロプライエタリモデルの動作やパラメータに関する十分な詳細が提供され、モデルの推論または盗難が可能になる。エージェントの自律性が、予期しない情報漏洩につながる可能性のある、緩やかに制御された対話パターンを促進することで、この問題を増幅させる可能性がある。モデル所有者、企業低大（潜在的に）厳格なレート制限: セッション/ユーザー/エージェントごとの A2A 対話にレート制限を適用する。
    異常検出: プロービングやデータ抽出の試みを示唆する異常なクエリパターンを監視する。
    2データ汚染 (メッセージ部分)攻撃者がエージェント間で交換されるメッセージに悪意のあるコンテンツを注入し、意思決定に使用されるデータを侵害する。エージェントの相互作用の動的な性質は、このデータポイズニングが急速に広がり、連鎖的な影響を及ぼす可能性があることを意味する。エージェント、A2A エージェントの決定に依存する組織中～高大強力な検証: ファイルの整合性チェック、DataParts のスキーマ検証、TextParts のコンテンツフィルタリングを含む、すべてのメッセージパーツに対する厳格な検証を実施する。
    最小特権: 最小特権の原則に基づいて、機密データへのエージェントのアクセスを制限する。
    出どころの追跡: メッセージ内のデータの出どころと系統を追跡し、信頼性を評価する。送信元エージェントのIDとデータに適用された変換を考慮するために出どころの追跡を拡張する。
    機微情報の漏洩エージェントが、過度に広範な権限、データ管理ミス、またはモデルの幻覚により、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 サーバをデプロイする。
    4T4.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エージェントの課題」へ続く―

    【連載一覧】

    第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」
    第2回「プロンプト以外で効率化！開発体験の改善手法」
    第3回「AIエージェント時代のコーディング：MCPとA2Aとは」
    第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」
    第5回「AIとセキュリティ：Non‑Human Identity とAIエージェントの課題」
    第6回「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
    「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

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

    Share

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

    IoT活用とIoTセキュリティアイキャッチ画像（IoTデバイスの基本）

    はじめに：連載の背景

    新聞やビジネス誌を開くと「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回へ続く―

    【連載一覧】

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

    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
    「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

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

    Share

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

    AIコーディング3アイキャッチ（AIエージェント時代のコーディング）

    生成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エージェントの利点・課題・リスク

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

    誤行動・報酬設計の欠陥

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

    倫理・説明責任

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

    新しい標準プロトコル：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月3日（水）13:00～14:00
    「止まらないサイバー被害、その“対応の遅れ”はなぜ起こる？～サイバー防衛の未来を拓く次世代XDR：大規模組織のセキュリティ運用を最適化する戦略的アプローチ～」
  • 2025年9月10日（水）14:00～15:00
    「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」
  • 2025年9月17日（水）14:00～15:00
    「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

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

    Share

    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

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

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

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

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

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

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

    • 最新情報はこちら

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

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    セキュリティトピックス動画申し込みページリンクへのバナー画像
    投稿日:

    記録破りのDDoS攻撃！サイバー脅威の拡大と企業が取るべき対策とは？

    Share

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

    近年、DDoS攻撃の規模と頻度が急激に増加しており、企業や組織にとって無視できない脅威となっています。特に、2024年第4四半期には、過去最大規模となる5.6テラビット毎秒（Tbps）のDDoS攻撃が確認され、サイバー攻撃の新たな段階へと突入したことがわかりました。この攻撃は、わずか80秒間で1万3,000台以上のIoTデバイスを利用して実行され、Cloudflare社のDDoS防御システムによって自動的に検出・ブロックされました。

    お問い合わせ

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

    DDos攻撃の事例として、SQAT.jpでは日本航空へのサイバー攻撃の実態についても解説しています。こちらもあわせてぜひご覧ください。
    「【徹底解説】 日本航空のDDoS攻撃被害の実態と復旧プロセス」
    「Dos攻撃とは？DDos攻撃との違い、すぐにできる3つの基本的な対策」

    DDoS攻撃の増加と進化する手口

    2024年第4四半期には、Cloudflare社が軽減したDDoS攻撃の件数が690万件にのぼり、前四半期比16%、前年比83%の増加を記録しました。さらに、1Tbpsを超える大規模攻撃の件数は前四半期比で1,885%も増加し、これまで以上に大規模な攻撃が常態化しつつあります。

    HTTP DDoS攻撃では、既知のボットネットによる攻撃が全体の73%を占め、11%は正規のブラウザを装った攻撃、10%は疑わしいHTTPリクエストによる攻撃でした。ネットワーク層（L3/L4）攻撃では、SYNフラッド（38%）、DNSフラッド（16%）、UDPフラッド（14%）が主要な手法として確認されています。また、Miraiボットネットの亜種による攻撃が特に顕著であり、2024年第4四半期には、この攻撃手法の使用頻度が131%も増加しました。

    企業が直面するDDoS攻撃のリスクとは？

    DDoS攻撃がもたらす影響は多岐にわたります。最も直接的な被害は、システムのダウンによる業務停止であり、企業の信用低下や顧客離れにつながる可能性があります。また、近年増加している「ランサムDDoS攻撃（Ransom DDoS）」では、攻撃を受けた企業が身代金の支払いを要求されるケースが増えています。2024年第4四半期には、Cloudflare社の顧客でDDoS攻撃を受けた顧客のうち、12%が身代金の支払いを求められ、前年同期比で78%の増加を記録しました。

    業界別にみると、通信業界が最も多くの攻撃を受け、次いでインターネット関連業界、マーケティング・広告業界が標的となっています。特に、金融業界は依然としてサイバー犯罪者にとって魅力的なターゲットとなっており、資金詐取を目的とした攻撃が増加しています。

    DDoS攻撃から企業を守るための対策

    DDoS攻撃の脅威が拡大するなか、企業は効果的な防御策を講じる必要があります。特に、以下のような対策が推奨されます。

    1. 常時オンのDDoS防御システムの導入
      DDoS攻撃の多くは短時間で発生するため、人間の対応では間に合わないケースが多いです。自動検知・防御機能を備えたDDoS対策ソリューションを導入することで、攻撃を迅速に無力化できます。
    1. ネットワーク層とアプリケーション層の両方を保護
      DDoS攻撃には、L3/L4（ネットワーク層）攻撃とL7（アプリケーション層）攻撃があります。両方の層に対する防御対策を講じ、ファイアウォールやWAF（Web Application Firewall）を活用することが重要です。
    1. ゼロトラストアーキテクチャの採用
      攻撃者の侵入を最小限に抑えるために、ゼロトラストモデルを導入することも有効です。認証・認可プロセスを強化し、アクセス制御を厳格化することで、不正なトラフィックを遮断できます。
    1. クラウドベースのDDoS対策の活用
      オンプレミスのDDoS対策はコストが高く、攻撃の規模が拡大するにつれて対応が難しくなります。クラウドベースのDDoS防御サービスを活用することで、スケーラブルなセキュリティ対策を実現できます。
    1. 定期的な脆弱性診断とインシデント対応計画の策定
      攻撃のリスクを最小限に抑えるために、定期的なセキュリティ監査を実施し、DDoS攻撃を想定したインシデント対応計画を策定することが不可欠です。特に、SLA（サービスレベルアグリーメント）を明確にし、攻撃発生時の対応フローを事前に決めておくことが重要です。

    今後のDDoS攻撃トレンドと企業が取るべきアクション

    DDoS攻撃は今後さらに巧妙化し、大規模化すると予想されています。特に、AIを活用したボットネット攻撃や、IoTデバイスを悪用した攻撃が増加する見込みです。さらに、特定の企業や業界を標的とした「高度な標的型攻撃（APT）」の手法がDDoS攻撃にも応用される可能性があります。

    企業は、単に防御するだけでなく、プロアクティブなセキュリティ戦略を採用し、攻撃を未然に防ぐ体制を構築する必要があります。DDoS攻撃はもはや一部の企業だけの問題ではなく、あらゆる業界にとって喫緊の課題となっています。

    常に最新の脅威情報を把握し、効果的な防御策を講じることで、企業のシステムとデータを守ることができます。DDoS攻撃のリスクを最小限に抑えるためには、今すぐ適切な対策を実施することが求められるでしょう。

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

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

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

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

  • 2025年2月19日（水）14:00～15:00
    「Web担当者に求められる役割とは？Webサイトのガバナンス強化とセキュリティ対策を解説」
  • 2025年2月26日（水）13:00～14:00
    「AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク」
  • 2025年3月5日（水）13:00～14:00
    「ランサムウェア対策の要！ペネトレーションテストとは？-ペネトレーションテストの効果、脆弱性診断との違い-」
  • 2025年3月12日（水）14:00～15:00
    「サイバー攻撃に備えるために定期的な脆弱性診断の実施を！-ツール診断と手動診断の比較-」

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

    2038年問題とは？-2000年問題の再来？2038年問題の影響と解決方法-

    Share

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

    本記事では最近話題の「2038年問題」について解説します。2038年問題は狭義のサイバーセキュリティと関連するものではありませんが、そのまま放置してしまうとサイバーインシデントを引き起こす可能性がある問題となります。対応に準備に時間を要する問題であることから、読者の皆さまに早い段階から関心を持っていただければと考えています。

    2000年問題を振り返る

    初期のプログラミング言語（FORTRANやCOBOL注 1) など）はデータ型に日付型がなかったため、文字列を割り当てて日付として処理をしていました。

    この時、日付を文字列で処理する際、1960年代～80年代の人類は自分が作ったプログラムがその後長く使われるなどと思わず、「とりあえずYY-MM-DDで表示すればデータ量削減にもなるし、いいだろう」と考え、慣例として西暦年を下２桁で処理していました。

    図1：2000年問題の原因となった表示方法

    何しろ今とは異なりCPUもメモリも、貧弱でも超高価な時代です。資源の節約は必要な限り実行しなければならない課題だったといえます。しかし、1990年代に入ったところで人類はふと気づきます。「これはもしや、西暦年の下２桁だけだと2000年になった時、処理上1900年に戻ってしまうのでは？」と。

    図2：2000年問題

    そうして、1990年代半ばからプログラムの書き換えが行われ、それまで下２桁だった西暦年を4桁に変更し、万が一の時のために1999年12月31日から2000年1月2日までの間、一部のIT業界の人たちが正月返上で出勤して不測の事態に備えたのが2000年問題です。

    2000年問題では実際、2000年1月1日当日、特に何かが起こることはありませんでした。その背景は以下の通りです。

    2000年問題が2000年1月1日に何も問題とならなかった背景

    • COBOLやFORTRANなどのレガシー言語で古くに書かれたアプリケーションやマイコンなど対象が限定されていたこと
      （※C言語などの比較的新しい言語は日付型をデータ型に持っていたため関係がなかった。）
    • 発生日が明確だったこと
    • 対策が西暦年の2桁を4桁表示に変更するという方法に集約されていたこと
    • 数年間にわたって事前の対策がとられていたこと

    限定的な対象に対し、事前に入念な準備を行ったことが功を奏し、インシデントが発生しなかったことが2000年問題の結果です。

    計算機とデータ型：2038年問題の技術的背景

    さて2024年現在、コンピューター・タブレット端末・スマートフォンなど、見た目などから計算機であることがわかりづらいようになっていますが、やはりコンピューターは計算機です。実際アプリケーションを動かすにしてもプログラムがされていて、プログラムの実行には必ず計算が伴います。そして、プログラム上でデータを処理するためにはデータの種類を定めるデータ型というものがあります。

    データ型の例

    データ型例
    文字列（str）今ご覧になっているいわゆる文字列のこと
    整数型（int）1, 2, 50, 1065, -5などの整数（負の数も含む）
    浮動小数点型（float）3.14, -0.001, 356.25などの小数点を含む数（負の数も含む）
    ブーリアン型（bool）真（True）か偽（False）のいずれかで表わされる
    日付型（date）世界標準時（UTC）を基準として、1970年1月1日からの経過秒数を表すタイムスタンプデータ。整数型データで表わされる

    2000年問題のときはFORTRANやCOBOLに日付型が存在せず、文字型で処理していたこと、また限られた資源を節約するために下2桁で年を表していたことが原因でした。一方、2038年問題は日付型のタイムスタンプデータを格納する整数型のデータ長（ビット幅）の実装が原因となるものです。

    SQAT.jpでは以下の記事で2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介しています。こちらもあわせてご覧ください。
    「【続】プログラミング言語の脆弱性対策を考える：2024」

    2038年問題の技術的課題

    符号付32ビット整数型から符号付64ビット整数型への移行の壁

    前述したデータ型の例の表にもあるように日付型は絶対的な日付を表すものではなく、1970年1月1日午前0時0分を基準日時（エポックタイム）としてそこからの経過秒数をタイムスタンプデータとしてあらわすものです。C言語ではtime_tと呼ばれるこのデータでは、タイムスタンプデータを格納するのは符号付32bitの整数型となっています。符号付整数型は最初の1bitを正負符号のために使用します。符号の1ビットがあるため、実際に日付データ用に利用できるのは正負を表す最初の１ビットを除く31ビットで、利用できるビット長は（231-1）=2,147,483,647秒となります。よって基準日時からおよそ68年を上限として演算・表示ができるものとなります。

    図3：符号付32bitであらわした2038年1月19日3時14分7秒

    図3は1970年1月1日午前0時0分から2,147,483,647秒が経過した、2038年1月19日3時14分7秒（※うるう秒は考慮しておりません）の符号付32bit整数型でのtime_tの状態です。一番左側の符号0は正の値を表しており、1970年1月1日午前０時０分から2,147,483,647秒、正の方向に経過したことを示します。

    さて、二進法の常で右側の31bitがすべて1になった場合、通常一番左側の1ビット目が1になります（二進法の繰り上がり）。

    図4：符号付32bitのままで2038年1月19日3時14分8秒になった場合

    1970年1月1日午前0時0分から2,147,483,648秒経過すると図4のようになります。符号付の場合、一番左側の符号1は負の値を表すため、1970年1月1日午前0時0分から2,147,483,647秒、負の方向に遡った1901年12月13日20時45分52秒を示します。つまり放置しておくと日付データが大きく誤ることとなります。この問題が最も深刻になるのは符号付32bitのtime_tを何らかの形で参照し、それを正しいものという前提で処理しているプログラムが、2038年1月19日の時点（または2038年1月19日以降の日付を参照する時点）で未改修のまま残ってしまうことで影響を及ぼしてしまうことなのです。

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

  • 2024年12月18日（水）14:00～15:00
    「脆弱性診断の新提案！スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー」

    • 最新情報はこちら

    2038年問題を回避する3つの対応策

    対策として考えられる方法はいくつかありますが、根本的な対策は以下の3つになります。

    1. time_tを符号付64bit整数型に変更する
    2. time_tを符号なし32bit整数型に変更する
    3. time_tの基準日時を1970年1月1日午前0時0分から別の日時に移動する

    主要OS・アプリケーションの2038年問題対応状況

    2038年問題の影響が一番大きく出ると当初予想されていたのが各種OSです。以下に各OSの対応状況を記載します。

    各OSの対応状況

    OS
    Linux64bitアーキテクチャ向けには当初より64bitのtime_tを提供。
    32bitアーキテクチャについてはLinux Kernel 5.6で64bit化対応済み。5.4/5.5についてもバックポートで対応済み。*4
    FreeBSD原則として64bit対応済みだが、i386アーキテクチャの32bitアーキテクチャのみ非対応。I386アーキテクチャについては符号なしの32bit整数型 time_tを提供*2
    Windows64bitで1601年1月1日0時からの100n sec単位の差分計算をしていることから2038年問題は対象外といわれている*3
    macOSmacOS10.0(Cheetah)で基準時を2001年1月1日0時に変更しており、2038年問題は対象外。また、32bitアプリケーションはmacOS 10.15(Catalina)以降では使用できない*4

    表にもある通り、最新のOSであればほぼ問題なく2038年問題をクリアできることがわかります。問題はOSの機能を補完する各種ドライバやライブラリ群、また、そのうえで動くアプリケーションでしょう。それぞれ確認は必要となりますが、代表的なものの対応状況は以下の通りです。

    ライブラリ/アプリケーション名対応状況
    GNU C Library (glibc)バージョン2.34でx86アーキテクチャ上での64bit整数型time-tに対応。ただしx86アーキテクチャ上のglibcのtime_t自体は32bitのままで、_TIME＿BITSプリプロセッサマクロが64に設定されていて、かつLFSが有効な場合にのみ利用可能などの制限あり*5
    NFSNFSv4（RFC7530）秒単位のデータは符号付64bitであることが定義されている*6（※2.2.1 nfstime4の項を参照）
    XFSLinux 5.10でオプションとしてナノ秒単位を64bitで計算・表示する「big timestamps」を追加し、2486年まで対応できるように修正。ただしデフォルトで追加が反映されるものではなく有効に設定する必要がある*7
    MySQL8.0.28でFROM_UNIXTIME(), UNIX_TIMESTAMP(), CONVERT_TZ() の64bit対応。ただしOS側が64bit対応である必要あり（いずれの関数もOSの日付型データを参照するため）*8
    MariaDB11.5.1でタイムスタンプを2106年02月07日6時28分15秒まで拡張*9
    Visual C++32bitであえて指定されていない限りは64bitがデフォルト値*10

    上記はごく一部の対応状況ですが、仮に対応していても制限事項がつくものが存在する点に注意が必要です。ここまで記載した内容で何となくお気づきの方もいらっしゃるかもしれませんが、2038年問題は発生する可能性がある箇所が2020年問題に対して格段に多いため、時間がかかることが予想されます。

    2000年問題と2038年問題の違い

    • 対象がOS/ライブラリからアプリケーション、機器類まで非常に幅が広い
    • 2000年当時に比べて格段にデジタル化が進んでいる
    • 対策方法が一様ではないものや、現在動いているシステムに対して即時変更をかけられないものがある

    企業が取るべき2038年問題対策：自社システムの診断方法

    自社のプログラムの調査は?

    さて、「PCやサーバなんかを買ってきたものの、自社で作ったものはどうすればいいの？」というケースもあるでしょう。自社で作ったものは…そうです。自分たちで調べるしかないのです。実際に調査をして対応をした事例がまとめられた論文が公開されています。

    組込み機器開発における2038年問題への対応事例

    https://www.ipsj.or.jp/dp/contents/publication/39/S1003-1809.html

    この事例では製品のライフサイクルがもともと20年前後を想定していることから、まずは2038年を最低限クリアすることを要件として調査を開始しています。このケースは組み込み機器になりますが、その単体の機器でもOS部分を含む総行数330万行のコードから符号付32bit整数型のtime_tを明示的に使用する箇所およそ3500か所が発見されています。

    この事例でとられたステップを簡単にまとめます。

    この事例では3500か所に対して5.8人月で実行された修正作業もさることながら、そのレベルの工数で抑制するために事前の洗い出しや対策案の立案、修正作業の手順策定といったところの重要さが感じられます。特に対策案を選定するにあたって要件が明確だったことが対策案の選定を容易にしたことがわかることから、作業開始前（せめて対策案の選定前）に要件を明確にしておくことの重要さを実感させられます。

    さて、2038年問題に該当するコードを検出するためのツールは日本の研究者も含め、いくつかのGitHubレポジトリからリリースされています。最近では立命館大学のサイバーセキュリティ研究室によるY2k38チェッカーがリリースされています。

    Y2k38チェッカーチェッカー作者によるプレゼン資料

    こういったチェッカーは自社開発のプログラム資産のざっとしたチェックに使えるでしょう。また、チェッカー以前の問題として、まずは自社のプログラム資産が2038年問題の影響を受けないか、そろそろ確認を行い、準備を始める期間に入ってきたといえるかもしれません。

    組み込み機器とは？：2038年問題の最大の影響

    実はここまでにあまり触れていない、最大の2038年問題があります。それは、先ほどの論文の事例にもある組み込み機器の問題です。

    組み込み機器といわれてもピンとこない方もいらっしゃるかもしれません。身近な例でいうと家電製品を制御するために組み込まれているコンピューターになります。一番パソコンに近いものであれば最近のハードディスク内蔵か外付け対応のテレビが挙げられます。このほかにも例えば電車に乗るときの自動改札機、切符販売機、水道や電気ガスなどのメーター類や街中で見かけるデジタルサイネージなども組み込み機器です。ほかにも工場のセンサー類やオートメーション用の機器類、配電設備や浄水・配水設備などのインフラ設備、病院の検査機器などにも組み込み機器が用いられています。

    先ほどの事例のようにライフサイクルが決まっていて、そのライフサイクルの間のみ使用するというのが利用者（消費者）側に正しく認識されていれば問題ないのですが、実際のところ、組み込み機器こそライフサイクルを超えて、転売などをされて使い続けられるケースが多く、販売業者も製造業者もすべての出荷品の現状をトレースできないケースがあるといわれています。特に償却期間が5年を超えるような固定資産については入れ替えの検討なども含めて対応する必要が出てくることから、そろそろ取りまとめを始めなければならないでしょう。また、個人向けのIoT機器や家電のように、長期間の利用は想定されていない（売り切りに近い）製品については直前になって買い替えが必要といったアナウンスが出てくる可能性もあるでしょう。

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

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    まとめ

    2038年問題は日付データが誤ることで社会的に大きな影響を与える可能性があります。本記事公開日（2024年12月）時点ではまだまだ先の問題と思っている方が多いと思いますが、そろそろロードマップを書き始めないと対策に取る時間が足りなくなる可能性があります。これを念頭に置き、早めの対策方法を考えておく必要があるでしょう。

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

    注：
    1)FORTRAN
    ・数学分析用を目的としたプログラミング言語
    ・データ型は整数、実数、複素数、文字、論理の５種類
    　COBOL
    ・1950年代終わりに開発されたプログラミング言語
    ・データ型は文字、数字、数字編集の３種類

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    投稿日:

    APIとは何か（2）～APIの脅威とリスク～

    Share

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

    APIセキュリティは、現代のビジネスにおいて不可欠な課題です。シリーズ第2回の今回は、APIを悪用した攻撃手法や、OWASP（Open Web Application Security Project）よりリリースされている「OWASP API Security Top 10」で取り上げられるリスクの詳細を解説します。インジェクション攻撃やDDoS攻撃、APIキーの悪用、アクセス制御に関する脆弱性など、主要な脅威を紹介しながら、APIが悪用された場合の影響について解説します。

    前回記事（シリーズ第1回）「APIとは何か～基本概念とセキュリティの重要性～」はこちら。

    APIとは～前回からの振り返り

    日頃からインターネットなどのネットワークを使用することが多い今日、現代における多くの企業はAPIに大きく依存しており、今やAPIは不可欠なものとなっています。Akamai社のレポート「The API Security Disconnect」によると、調査対象となった企業の約8割以上が2023年に行った調査において、「過去12か月以内にAPIセキュリティをより重視した」と回答しています。しかし、2022年～2024年で調査した回答者のうち、半数以上が、APIのセキュリティインシデントの影響により顧客の信頼を失い、さらにそこからほぼ半数は生産性の低下や従業員の信頼の低下にもつながったといいます。

    また、SNS事業者が提供するAndroid版アプリに存在した脆弱性が悪用された結果、膨大な量のアカウント情報が漏洩した事例*11も報告されています。これは攻撃者が大量の偽アカウントを使用し、様々な場所から大量のリクエストを送信し、個人情報（ユーザ名・電話番号）を照合するというものでした。

    APIが悪用されるとどうなるか

    APIが悪用された場合、多岐にわたる深刻な影響が生じます。特に、認証や認可の不備は深刻なセキュリティホールとなり得ます。攻撃者はこれらの脆弱性を悪用して不正アクセスを行い、機密データや個人情報を盗み出す恐れがあります。また、認可が適切に設定されていないと、本来は外部からアクセスできないはずのデータにまで侵入され、第三者からデータの改ざんや不正操作が可能となってしまいます。さらに、APIを標的にしたDDoS攻撃によりサービスがダウンし、正規ユーザが利用できなくなることで、企業の信用失墜や業務の中断といったダメージを引き起こします。これらの影響は、経済的損失だけでなく、法的問題やブランドイメージの毀損など、長期的な悪影響をもたらすため、APIのセキュリティ強化が不可欠です。

    APIを悪用した攻撃の事例はいくつか報告されていますが、いずれの攻撃も、「OWASP API Security Top 10」で挙げられている問題と関連性があります。

    OWASP API Security Top 10

    APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASPが、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したものです。

    https://owasp.org/API-Security/editions/2023/en/0x11-t10/ より当社作成

    「OWASP API Security Top 10」上位のリスク

    特に上位5つの項目については、以下のような重大なリスクにつながるため、リリース前に十分な対策が施されていることを確認すべきです。

    • 不正アクセス
    • なりすまし
    • 情報漏洩
    • サービス運用妨害（DoS）

    主なセキュリティ脅威

    インジェクション攻撃

    インジェクション攻撃は、悪意のあるコードをAPIに挿入し、不正な操作を行う攻撃です。APIの入力データを検証せずに処理している場合、攻撃者にデータベースへのアクセスを許すリスクが生じます。特にSQLインジェクションやコマンドインジェクション攻撃が多く、攻撃を受けてしまった場合、データベースの情報漏洩やシステムの制御不備などの被害があります。

    認証およびセッション管理の不備の脆弱性を悪用

    APIの認証とセッション管理の不備を悪用することで、攻撃者は不正アクセスやなりすましを行います。パスワード強度が不十分な場合やトークンの管理が適切に行われていない場合、セッションハイジャックや不正に重要な情報を閲覧されることによってデータの漏洩が発生するリスクがあります。適切な認証管理およびセッション管理を行うことが重要です。

    DDoS攻撃

    DDoS攻撃は、複数のPCからアクセスされることによる膨大な量のリクエストをAPIに一斉に送り込むことで、システムのリソースを枯渇させ、サービスの提供を妨害する攻撃です。APIの特性上、処理を高速に行うために外部からのリクエストを許容する必要がありますが、その柔軟性が悪用されます。攻撃者はボットネットを利用し、大量のトラフィックを発生させてサーバのリソースを消費させます。これにより、顧客はサービスが利用できず、自組織においても業務に多大な影響を及ぼします。APIを保護するためには、トラフィックの監視やレート制限、WAF（Webアプリケーションファイアウォール）などのセキュリティ対策が重要です。

    APIキーの悪用

    APIキーは、APIへのアクセスを制御するために利用されますが、攻撃者に奪われると不正利用のリスクが生じます。盗まれたAPIキーは無制限のアクセスやサービスの悪用に使われる恐れがあります。安全な管理や無制限にアクセスができないように適切なアクセス制御を実施すること等が重要です。

    アクセス制御の不備による影響

    APIのアクセス制御の不備の脆弱性を悪用することで、攻撃者は許可されていないデータや機能にアクセスできます。適切な権限設定がされていない場合、データの漏洩や不正な操作の実行のリスクがあります。権限の設定など適切なアクセス制御が求められます。

    思わぬデータの公開や改ざん

    APIの設計や実装の不備により、データが意図せず公開・改ざんされるリスクがあります。適切な認証・認可がないと、攻撃者が内部の機密情報にアクセスすることが可能になります。例えば、本来ならシステム管理者のみがアクセスできる設定画面または顧客情報やシステムに関する情報などの重要情報が格納されている場所に攻撃者がアクセスできてしまった場合、システムの設定を変更されたり重要情報が奪取されたりする恐れがあります。また、過剰に情報を提供するAPIレスポンスや暗号化されていないデータ転送も、情報漏洩や改ざんの危険性を高めます。データ保護には、適切なアクセス制御と暗号化の実装が不可欠です。

    アカウント乗っ取り

    不正アクセスによってユーザアカウントが乗っ取られ、APIを悪用される可能性があります。一度アカウントが乗っ取られると、攻撃者は個人情報の閲覧や不正操作、さらには他のシステムへの攻撃拡大を図る可能性があります。多要素認証（MFA）の導入やAPIキーの適切な管理、ログイン試行の監視など、セキュリティ対策の強化が必要です。

    まとめ

    現代の企業にとってAPIによるアプリケーション連携は不可欠ですが、その悪用によるセキュリティリスクも増加しています。APIを悪用した攻撃の事例は、「OWASP API Security Top 10」に関連しています。主なセキュリティ脅威には、インジェクション攻撃、認証やセッション管理の不備、DDoS攻撃、APIキーの悪用、アクセス制御の脆弱性、不適切なデータ公開や改ざん、アカウント乗っ取りなどがあります。これらは重大なリスクを孕んでいるため不正アクセス、なりすまし、機密データの盗難を含む情報漏洩、データ改ざん、サービスのダウンによるサービス低下や業務への影響、ひいては企業の信用失墜といった深刻な結果を招きます。こうした被害を防ぐため、APIの設計段階から適切なセキュリティ対策を行い、監視やアクセス制御の強化が不可欠です。

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

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像