月別アーカイブ: 2026年3月

VPNは本当に危ないのか

2026年3月26日
諸角 昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のない意見をいただければ幸いである。

「VPNは危険だ」という言説が広まっている。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、セキュリティベンダーはこぞって「脱VPN・ゼロトラスト移行」を訴えている。しかし実際のところ、VPNの何が問題で、どこまでが誇張なのか、冷静に整理できている組織は少ないのではないかと考えている。 本ブログでは、VPNをめぐるリスクの構造を三層に分けて整理し、国内の統計データの正確な読み方、よくある意見への答え、そして対策の方向性について考察する。

VPNのリスクは三層構造

VPNのリスクを「危ない」「危なくない」の二項で語ることには無理がある。問題は性質の異なる三つの層に分かれており、それぞれ対策も深刻度も異なる。

第一層:製品脆弱性(CVE)のリスク

Ivanti、Fortinet、Pulse Secure、NetScalerなど主要なVPN製品では、毎年複数の重大な脆弱性が報告されている。パッチが公開される前後の短期間に大規模な攻撃が観測されるケースも多く、このリスクの深刻さは「発生頻度」ではなく「防御困難性」にある。

ゼロデイ段階では組織側に取れる手段があまりない。さらに厄介なのは、パッチを適用した後でも安心できないケースがあることだ。2024年に確認されたCisco ASAへの「ArcaneDoor」攻撃では、攻撃者がファームウェアレベルにバックドアを仕込み、再起動後もアクセスを維持していたことが報告されている。英国NCSCはこの侵害の検出を「信じられないほど難しい」と評している。

国家支援型APTがこうした脆弱性の発見・悪用に多大なリソースを投じていることも、このリスクの性格を際立たせている。目的は金銭ではなく、長期潜伏・情報収集・将来の破壊活動の準備であることが多く、被害が表面化するのが数ヶ月後というケースもある。

第二層:認証情報管理のリスク

VPN経由の侵害としてよく引用されるColonial Pipeline事件(2021年)は、VPN製品の脆弱性が使われたわけではない。MFAが設定されていない休眠アカウントに、別の情報漏洩事案で入手したパスワードを使って侵入したケースであり、本質は「アカウント管理の失敗」である。

この区別は重要で、製品脆弱性への対策とアカウント管理の強化は、必要な対処が全く異なる。VPN経由の侵害を議論する際に両者が混同されると、対策の優先順位を誤ることになる。 認証情報侵害の深刻度が製品脆弱性より「相対的に低い」理由は、防御手段が明確に存在するからである。MFAを適切に実装し、退職者・外部委託先のアカウントを定期的に棚卸しし、パスワードポリシーを徹底するだけで、このリスクは大幅に低減できる。

第三層:設計思想の欠陥

これが最も根本的な問題である。VPNの設計思想には、現代の脅威環境と相容れない構造が二つある。

一つは、VPNアプライアンスが常時インターネットに公開された「公開ポート」を持つ点である。VPNは外部からの接続を受け付けるためにポートを開き続けなければならず、これが攻撃者のスキャン対象となるアタックサーフェスを恒常的に生み出している。後述するZTNAが実現する「ダークIP」、すなわちサーバーをインターネット上から不可視化し攻撃者がスキャンしても存在自体が見えない状態と、根本的に異なっている。公開ポートが存在する限り、脆弱性が発見されるたびに「侵入の入口」が生まれ続けることになる。

もう一つは、「一度認証すれば内部ネットワークを自由に動ける」という暗黙の信頼モデルであることである。侵害後のラテラルムーブメントを止める仕組みがなく、製品脆弱性でも認証情報侵害でも、内部に入られた後の被害拡大を抑制することが難しい。Colonial Pipeline事件で侵入者が約100GBのデータを2時間で窃取できたのも、この構造があったからである。 公開ポートによって「侵入される入口が常に存在する」こと、そして侵入後のラテラルムーブメントを許容してしまう設計が組み合わさることで、VPNは攻撃者にとって突破しやすく、突破後の被害も大きい構造になっている。この二点は、製品をより新しいものに替えたり、パッチを適切に当てたりするだけでは解決できない、アーキテクチャレベルの問題である。

「VPN問題」はVPN固有の問題か

ここで一度立ち止まって、「脱VPN」という議論はVPN特有の問題を論じているのか、それとも別の何かを論じているのかについて考えてみる。

結論から言うと後者の方に近いと言える。問題の本質は、「常時インターネットに公開され、内部ネットワークへの特権的なアクセスを持つ境界機器全般」に共通する構造的リスクである。ファイアウォール、ルーター、リモートデスクトップ、UTMなど、これらはすべて同じ構造を持っている。

2024年に複数の政府機関ネットワークへの侵入に使われた「ArcaneDoor」はCisco ASA(ファイアウォール)が標的だった。中国系APTのVolt Typhoonは、ルーターやファイアウォールを侵害してボットネット化し、他組織への攻撃の中継拠点として再利用するORB(Operational Relay Box)化の手法を用いている。これらはVPNとは別の機器だが、まったく同じ構造的問題を抱えている。 VPNが特に槍玉に挙がっているのは、第一にテレワークの普及でVPN機器の導入が急増し、アタックサーフェスが広がったこと、第二にランサムウェアの初期侵入経路として実績が積み重なり、報道での露出が増えたこと、第三に製品ベンダーが「脱VPN」をZTNA販売のマーケティングに活用していること、であると考えられる。つまり、「脱VPN」は正しい方向だが、VPNだけを替えれば終わりではなく、「境界機器に依存したアーキテクチャからどう脱却するか」が問題である。VPNはその最大かつ最も目立つ例に過ぎない。

国内統計データの正確な読み方

「ランサムウェア被害の63%がVPN機器経由」という数字は、セキュリティの議論で頻繁に引用されている。この数字の出所と正確な意味を確認しておきたい。

一次ソースは警察庁レポート

出所は警察庁「令和5年におけるサイバー空間をめぐる脅威の情勢等について」(2024年3月公表)である。ランサムウェア被害の有効回答115件を分析したもので、VPN機器からの侵入が73件(63%)、リモートデスクトップからが21件(18%)という結果が示されている。 翌年の令和6年上半期版(2024年9月公表)では、VPN機器47%、リモートデスクトップ36%と変化しており、リモートデスクトップ経由の急増が目立っている。これはVPN対策が進む一方で攻撃者が侵入経路をシフトさせていることを示唆しているものと考えられる。

この数字で言えること・言えないこと

言えること:国内ランサムウェア被害において、VPN機器が初期侵入経路として最多であることは事実として裏付けられている。

言えないこと:この数字はVPN経由の侵害が「脆弱性悪用」と「認証情報侵害」のどちらによるものかを分離していない。警察庁レポートでは、「VPN機器のぜい弱性を悪用したり、強度の弱い認証情報等を利用して侵入」と両者を一括して記載している。

参考値として、侵入経路とされた機器のパッチ適用状況を尋ねたアンケートでは、令和5年データで約6割が「未適用のパッチがあった」、約4割が「最新パッチを適用済み」と回答している。後者はゼロデイ攻撃または認証情報侵害の可能性を示唆するが、断定はできない。IIJニュースでも「VPN機器からの侵入はブルートフォースや過去に漏洩したアカウント情報による不正利用が原因であることも多い」と述べており、認証情報侵害の割合も相当程度あると考えられる。

その他の意見

「IPsec VPNにすれば解決するのでは?」

SSL VPNではなくIPsec VPNを使えばよい、という反論はよく出てくる。答えは「実装は改善されるが、設計思想の問題は解決されない」となる。 IPsecにすることで、Ivanti等のSSL VPN製品固有の脆弱性リスクは低減できるが、「公開ポートによるアタックサーフェス」と「認証後のラテラルムーブメントを許容する設計」という第三層の問題は変わらない。IPsecはVPNをより堅牢にするアプローチであり、問題の所在が設計思想にある以上、IPsecへの切り替えは根本的な解にはならない。

「VPNを止めたらレガシーアプリが動かなくなる」

「VPNを止めたらレガシーアプリが動かなくなる」という懸念は、ZTNAの実装方式を選べば多くの場合解決できるが完全ではないと言える。

ZTNAには主に二種類の実装がある。主流の「L7プロキシ型」はHTTP/Sのヘッダーやセッション情報を読んでポリシー評価を行うため、独自TCP/UDPプロトコルに依存するレガシー基幹系・VoIP・映像伝送などは通信の解釈が難しく、対応が困難である。一方「L4トンネル型」(WireGuardベース等)はポート・IP単位で制コントロールするため、RDP・SSH・非HTTP/Sプロトコルにも対応しやすい。L7型と比べてポリシーの粒度は粗くなるが、VPNとは異なり認証後もネットワーク全体へのアクセスを許可するわけではなく、ラテラルムーブメントの抑制やダークIPの維持といったZTNAの本質的な利点は保たれる。

ただし実装方式にかかわらず対処できない領域が残る。OT機器・医療機器・産業用PLC等にはエージェントを導入できないため、ZTNAの管理下に置けない。この部分は「動かなくなる」のではなく「ZTNAで管理できない」という問題であり、VPNとのハイブリッド運用か別の手段を検討する必要がある。

結論として、「VPNを止めたらレガシーアプリが動かなくなる」は全体としては正しくなく、L4型ZTNAの選択と移行設計で大半は解決できることになる。残る課題はOT/IoT環境に限定されることになると考えられる。

「VPNを使い続けることは現状維持ではないのか?」

現状維持にもコストとリスクは発生する。アプライアンスのライセンス・運用・パッチコストの増大、侵害時の対応コストなどである。「今すぐ移行できないからVPNを続ける」という判断は、既知のリスクを可視化しないまま保有し続けることを意味する。

ZTNAへの移行は答えになるか

ZTNAがVPNの根本的な代替となりうる理由は、前述した設計思想の欠陥を直接解決するからである。その上で、この問いについて考えてみる。

ZTNAが解決するもの

  • ダークIP:ZTNAゲートウェイ経由でのみアクセスを許可し、サーバーのIPアドレス自体をインターネット上から不可視化する。公開ポートがなくなることでアタックサーフェスが根本から消える。
  • 最小権限アクセス:ネットワーク全体ではなくアプリケーション・リソース単位でアクセスをコントロールする。侵害されてもラテラルムーブメントの被害を局所化できる。
  • 継続的なコンテキスト認証:ユーザーIDだけでなく、デバイスの健全性・接続元・行動パターンをリアルタイムで評価し、リスクに応じてアクセスをコントロールする。
  • 可視性の向上:誰が・何に・どこから・いつアクセスしたかを完全に記録できる。

ZTNAが解決が難しいもの

ZTNAを過信することも危険である。設計思想は優れていても、実装と運用が伴わなければ新たなリスクを生むことになる。

  • ポリシー設計の複雑さ:最小権限ポリシーの設計ミスは直接セキュリティホールに繋がる。VPNの「とりあえずつなぐ」運用から、精緻なポリシー管理への転換が必要である。
  • IdP依存:ZTNAはID基盤との連携が前提であり、IdPが単一障害点になりうる。ID基盤の整備が課題になることも多い。
  • ベンダーロックイン:標準化が未成熟でベンダーごとに実装が異なる。製品選定は長期的な視点が必要である。
  • レガシー環境の限界:ZTNAの主流であるL7プロキシ型はHTTP/Sと相性が良い一方、非HTTP/Sプロトコルへの対応は粒度が粗くなる。L4トンネル型(WireGuardベース等)はRDP・SSHなど非HTTP/Sにも対応しやすく、ラテラルムーブメントの抑制やダークIPの維持といったZTNAの本質的な利点は保たれる。OT機器・PLCなどエージェントを導入できないデバイスについても、SDPアーキテクチャではゲートウェイ側にネットワークコネクタを設置することで保護下に置くことができる。ただしOT環境特有のリアルタイム性・可用性要件への対応は設計段階で十分な検討が必要となる。

AIがVPN問題をどう変えるか

VPNをめぐる脅威環境は、AIの普及によって構造的に変化しつつある。攻撃側・防御側の双方でAIが使われるようになっており、その影響を把握しておくことは今後のセキュリティ戦略に不可欠である。AIは攻撃者にとって、これまで専門知識や時間を要していた作業を自動化・低コスト化するツールになっている。VPNをめぐる文脈で特に影響が大きい点は以下の三つであると考える。

第一は、マルウェアおよびエクスプロイトコードの自動生成である。警察庁は2024年に、生成AIを悪用してランサムウェアと思われる不正プログラムが作成された国内事例を公表している。従来、ランサムウェアの開発には高度な技術力が必要だったが、生成AIの登場でそのハードルが大幅に下がっている。RaaSのエコシステムと組み合わさることで、技術力の低い攻撃者でも洗練された攻撃が可能になりつつある。

第二は、脆弱性スキャンと初期侵入の自動化である。AIを使った自動スキャンツールは、インターネット上に公開されたVPNアプライアンスのバージョン情報や応答パターンから脆弱性の有無を高速に判定し、CVEが公開されたその日のうちに大量のターゲットへ攻撃を試みることができる。VPNの「公開ポートが常にアタックサーフェスになる」という設計上の問題は、AIによる自動スキャンの存在によってさらに深刻化している。かつては人間の攻撃者が手動で探索していた侵入口が、今や24時間自動で探索され続けている。

第三は、フィッシングと認証情報窃取の精度向上である。VPN経由の侵害の相当の割合が認証情報の漏洩を起点とすることは前述の通りであるが、AIを使ったフィッシングメールは文章の自然さ・ターゲティングの精度が飛躍的に向上しており、従来の「日本語が不自然なメール」という見分け方が通用しなくなってきている。また、AIによる音声・動画の偽造(ディープフェイク)を使って経営幹部になりすます攻撃も報告されており、ソーシャルエンジニアリングのリスクが全体的に高まっている。

まとめると、AIの普及は、VPNが持つ三つのリスクをいずれも悪化させる方向に作用する。製品脆弱性はAI自動スキャンによって即日悪用されるリスクが高まり、認証情報侵害はAI精度向上によるフィッシングで窃取しやすくなり、マルウェア展開は自動生成ツールの普及で参入障壁が下がる。「公開ポートが常にアタックサーフェスになる」という設計上の問題は、AI時代においてより高速・大規模に突かれる環境に変わりつつあるといえる。

まとめ

ここまでの内容を踏まえ、IT部門・情報システム担当が今取るべきアクションを、時間軸と優先度で整理してみたい。「脱VPN」は方向性として正しいが、すべてを同時に進める必要はない。重要なのは、リスクを可視化した上で、組織の状況に応じた順序で手を打つことである。

今すぐ着手すべきこと(製品・アーキテクチャを問わない基本対策)

これらはZTNAへの移行の有無にかかわらず、現時点で実施しなければならない最低限の対策である。AIによる攻撃の高度化を考慮すると、後回しにするほどリスクが増大することになる。

  • VPN機器のファームウェア・パッチ適用状況を棚卸しし、未適用のものを即時適用する。サポート終了機器が存在する場合は、更新計画を立てる
  • すべてのVPNアカウントにMFAを設定する。特に退職者・外部委託先・長期未使用のアカウントを優先的に無効化する(ゾンビアカウントの排除)
  • VPN接続ログの監視を強化する。通常と異なる接続元IP・時間帯・通信量の異常をアラートできる仕組みを整備する
  • IPA、JPCERTの脆弱性情報にサブスクライブし、使用中のVPN・ファイアウォール製品に関するCVEを即座に検知できる体制を作る

中期的に進めること(ZTNAへの移行の準備と段階的実施)

ZTNA移行の前提条件を整えながら、リスクの高い部分から順に置き換えていく。完璧な計画を待つより、部分的にでも移行を始めることの方が重要である。

  • ID基盤の整備:ZTNAはIdPとの連携が前提となる。Active Directoryのクラウドへのリフト、Entra ID等の整備を先行させる必要がある
  • 外部委託先・サードパーティのリモートアクセスをVPNからZTNAに置き替える。ゾンビアカウントリスクが最も集中する領域であり、効果が出やすい
  • SaaSアクセスにZTNA/SWGの要素を導入し、クラウドへのバックホール問題を解消しながらゼロトラストの経験を蓄積する
  • VPN機器が担っている機能(拠点間通信等)を棚卸しし、ZTNA、SD-WAN、SASEのどの組み合わせで代替するとかの設計を行う

長期的な目標(アーキテクチャの完全転換)

  • テレワーク、全社員のリモートアクセスをZTNAに完全移行し、物理的なVPNアプライアンスを廃止する
  • 「インターネットに公開されたポートを持つ境界機器」をネットワーク設計から排除し、ダークIPアーキテクチャを実現する
  • 継続的なポスチャ評価(デバイス健全性・コンテキスト認証)を全アクセスに適用し、AIを活用した異常検知と組み合わせる

経営層への説明

IT部門から経営層へのエスカレーションでは、技術的な詳細より「リスクの受容判断を経営として行う必要がある」という点を明示することが重要である。

  • 「VPNを維持することはゼロコストの現状維持ではない。既知のリスクを保有し続けるという意思決定だ」と明示する
  • インシデント発生時の対応コスト(調査・復旧・賠償・事業停止損失)とZTNA移行投資を比較したROI試算を提示する
  • 「今すぐ全廃」ではなく「段階移行ロードマップ」として提示することで、意思決定のハードルを下げる
  • AIによる攻撃の高度化を根拠として、「従来より速いスピードで脆弱性が突かれる環境になっている」という脅威環境の変化を説明する

VPNは問題のない技術ではなく、既知のリスクを抱えたまま動いているインフラである。製品脆弱性・認証情報管理・設計思想の三層すべてに問題があり、AIの普及がその脅威を加速させている。「脱VPN」の方向性は正しく、いつ・どこから始めるかという段階的なアプローチが望ましいと考える。

以上

開発者向けクラウドネイティブセキュリティの基礎(アプリケーションセキュリティ編)(2)

前回のアプリケーションセキュリティ編(1)(https://cloudsecurityalliance.jp/newblog/2026/02/22/apsec_1/)では、AIシステムのうちエージェンティックAI固有のセキュリティ課題や対策について取り上げた。今回は、AIシステムの橋渡し役を担うAPIのセキュリティに焦点を当てる。

LLMアプリケーションを支えるAPIセキュリティ

クラウドセキュリティアライアンス(CSA)の2021年5月11日付ブログ記事「OWASP APIセキュリティ Top 10の理解」(関連情報(https://cloudsecurityalliance.org/blog/2021/05/11/understanding-the-owasp-api-security-top-10/))では、CSAとグローバルレベルで連携するOWASPのドキュメントの中で、アプリケーション・プログラミング・インターフェース(API)特有の脆弱性やセキュリティリスクを理解し、それらを軽減するための戦略とソリューションに焦点を当てた「OWASP APIセキュリティ Top 10」初版(2019年12月公開)を紹介している(関連情報(https://owasp.org/API-Security/editions/2019/en/0x11-t10/)。その後2023年6月、OWASPは「OWASP APIセキュリティ Top 10」第2版を公開している(関連情報(https://owasp.org/API-Security/editions/2023/en/0x11-t10/))。第2版のAPIセキュリティTop 10各項目は、以下の通りである。

・API1:2023 BOLA (オブジェクトレベルの認可不備) :
IDを指定してデータを得る際、他人のデータにアクセスできてしまう問題(最重要)。
・API2:2023 認証の不備:
パスワードやトークンの管理、JWTの検証ミスなど。
・API3:2023 オブジェクトプロパティレベルの認可不備:
特定のフィールド(例:管理用フラグ)の読み取りや書き換えを許してしまう問題。
・API4:2023 制限のないリソース消費:
呼び出し回数やデータ量の制限がなく、DoS状態や高額請求を招く問題。
・API5:2023 機能レベルの認可不備:
一般ユーザーが管理者用APIエンドポイントを実行できてしまう問題。
・API6:2023 機密性の高いビジネスフローへの無制限アクセス:
買い占めやスパムなど、正規の機能でも自動化されるとビジネスに害を及ぼすケース。
・API7:2023 SSRF (サーバーサイドリクエストフォージェリ) :
APIサーバーを踏み台にして、内部ネットワークに攻撃を仕掛けられる問題。
・API8:2023 セキュリティ設定のミス:
不要な機能の有効化、古いパッチ、不適切なCORS設定など。
・API9:2023 不適切なインベントリ管理:
放置された旧バージョン(ゾンビAPI)や未把握のAPI(シャドウAPI)の放置。
・API10:2023 APIの安全でない利用:
連携先のサードパーティAPIから届くデータを盲信し、検証せず処理してしまう問題。

 さらにCSAは、2025年5月9日付で、「LLMのためのOWASP Top 10:CSAによる戦略的防御プレイブック」(関連情報(https://cloudsecurityalliance.org/blog/2025/05/09/the-owasp-top-10-for-llms-csa-s-strategic-defense-playbook))と題するブログ記事を公開している。ここでは、OWASPの「LLMアプリケーションのためのOWASP Top 10 (2025年版)」(2024年11月17日公開、関連情報(https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/))を紹介している。LLMアプリケーションのためのOWASP Top 10各項目は、以下の通りである。

・LLM01:2025 プロンプトインジェクション:
ユーザー入力によってモデルの挙動が意図せず変更される。ジャイルブレイク(脱獄)も含む。
・LLM02:2025 機密情報の漏えい:
モデルが学習・出力する内容により、個人情報や知的財産が漏えいする可能性。
・LLM03:2025 サプライチェーンの脆弱性:
トレーニングデータや外部モデルの改ざん・汚染によるリスク。
・LLM04:2025 データおよびモデルのポイズニング:
故意に不正なデータを混入させて、モデルの出力を操作する攻撃。
・LLM05:2025 出力の不適切な取り扱い:
モデルの出力を無検証で使用することにより、誤情報や有害な結果を招く。
・LLM06:2025 過剰なエージェンシー:
モデルが過度に自律的に判断・行動することで、制御不能なリスクが生じる。
・LLM07:2025 システムプロンプトの漏えい:
内部設定や指示が外部に漏れることで、攻撃者に悪用される可能性。
・LLM08:2025 過剰なリソース消費:
LLMが過剰な計算資源を消費し、サービス停止やDoSにつながる。
・LLM09:2025 不適切なアクセス制御:
モデルや関連システムへのアクセス制御が不十分で、情報漏洩や改ざんのリスクがある。
・LLM10:2025 ガバナンスとコンプライアンスの欠如:
法規制や倫理的枠組みに対する配慮が不足し、企業リスクを高める。

CSAは、「LLMアプリケーションのためのOWASP Top 10」を実行可能なセキュリティファーストの指針へと対応づけることにより、組織が責任を持って、かつレジリエントにAIを導入できるよう支援することを目指すとしている。

なお、LLMアプリケーションのためのOWASP Top 10では、LLMアプリケーションにおけるAPIの役割を、以下のように位置付けている。

・APIは外部アプリケーションがLLMの機能を利用するためのゲートウェイである。
・APIは外部アプリケーションとLLMとの通信のルールを定めている。
・APIはアプリケーションからのリクエストをLLMに渡し、生成されたコンテンツを再びアプリケーションに返す仲介役である。
・APIキーやトークンによる認証を通じて、アクセス制御を行うことにより、不正利用やデータ漏えいのリスクを軽減する。

AIで急増するM2MトラフィックがもたらすAPIの変容

次に、CSAのブログ記事「AI時代におけるAPIセキュリティ」(関連情報(https://cloudsecurityalliance.org/blog/2025/09/09/api-security-in-the-ai-era))では、API(アプリケーション・プログラミング・インターフェース)の利用形態の変容について触れている。かつてAPIは、主にWebやモバイルアプリの舞台裏で機能する統合レイヤーであったが、現在ではAIシステム、クラウドサービス、そして分散型アプリケーションにとっての「主要なゲートウェイ」となっている。

このようなAPIの変容は、単なる規模の変化にとどまらず、脅威モデルそのものに変化をもたらしている。大規模言語モデル(LLM)を搭載したAIシステムは、膨大な量のデータを消費・生成する。そのデータの多くは、従来のネットワーク・インターフェースに比べて監視が不十分になりがちなAPIを通じて流れている。事実上、APIは企業の機密データにおける「正面玄関」であり、「配送トラック」であり、時には「金庫」そのものになっているのが実情である。

セキュリティ企業Traceableの報告書(関連情報(https://www.traceable.ai/2025-state-of-api-security))によると、APIに関連するデータ侵害は増加傾向にあり、その検知も不十分である。さらに、AIによるAPI利用の導入が、攻撃の量と種類の両面を拡大させている。

かつてAPIの呼び出しの多くは、ポータルへのログイン、データのリクエスト、フォームの送信といった「人間による操作」がトリガーとなっていた。しかし現在では、マシン・ツー・マシン(M2M)トラフィックを介して、AIシステムが自律的かつ大規模なスケールでAPIの呼び出しを行っている。かつては1日に数百回程度だったAPIへのアクセスが、AI駆動のワークロードによって、今や1分間に数千回ものリクエストが発生するようになっている。

また、AIエージェントは複数のAPIを連鎖させ、次にどのエンドポイントにアクセスすべきかを複雑に判断することも可能である。これらのツールは、ユーザーのプロンプトや環境データに基づいて多様なリクエストを生成するため、比較対象となる固定されたベースライン(基準)のパターンが存在せず、異常検知をより困難なものにしている。

攻撃者はAIを悪用してペイロード(データ本体)を改ざんし、悪意のあるコードを難読化したり、単純なシグネチャベースのルールを回避する「合成(synthetic)」リクエストシーケンスを生成したりする。数百ものAPIを抱える組織にとって、露出したすべてのエンドポイントをカバーできるよう検知ルールを迅速に修正・更新し続けることは困難である。WAF(Web Application Firewall)のルールやOWASP Top 10の対策だけに依存していては、大きなセキュリティギャップが残ることになる。

生成AIツールは、公開されているAPIドキュメントを自動的に解析し、即座に実行可能な攻撃シナリオを生成できるため、攻撃側の手作業を劇的に削減する。また、モデルの学習、知的財産の窃盗、あるいは競合情報の収集といった目的のために、公開APIからのデータ収集を自動化することも可能になっている。

AI主導の統合が進むことにより、APIの採用は加速している。コンテンツAPI、データAPI、サービスAPI、ストリーミングAPI、さらにはその他の派生形が、多くのチームが追跡や保護を行える速度を超えて次々と登場している。この急速な拡大従って、以下のようなリスクが顕在化しつつある。

・シャドウAPI(Shadow APIs): セキュリティレビューを回避して公開された、ドキュメント化されていないエンドポイント。
・ゾンビAPI(Zombie APIs): 更新が停止しているにもかかわらず、アクセス可能な状態で放置された古いAPI。
・孤立したAPI(Orphaned APIs): 組織内に明確な所有者が存在しないエンドポイント。

特に、社内のAI実験のために開発されたAPIは、適切なドキュメント化やバージョン管理が欠如していることが多く、結果として長期的な「セキュリティ上の負債」となる。さらに、AIシステムはサードパーティAPIの連鎖(チェイン)に依存する場合があり、組織が直接制御できない外部の脆弱性が持ち込まれるリスクもある。ベンダー側でのAPI変更により、通知なくセキュリティ上の退行(リグレッション)が発生する可能性も否定できない。

そこでこのブログでは、以下の通り、11の実行可能な推奨事項とベストプラクティスを提示している。

1.リアルタイムのAPIインベントリの構築と維持:
クラウド、オンプレミス、コンテナ、エッジの全環境をスキャンし、APIを自動検出するツールを導入する。それらを「公開」「パートナー用」「内部用」に分類し、AIシステムに関連するものはタグ付けする。インベントリチェックをCI/CDに統合し、デプロイ前に新しいAPIが登録されるようにする。また、ネットワークやアプリの目録と定期的に照合し、シャドウAPIや放置されたAPIを特定しておく。

  1. AI統合APIへの「ポジティブセキュリティモデル」の採用:
    OpenAPIやSwaggerの仕様書を使用して、「正当な」トラフィックの定義を明確に行う。APIゲートウェイでスキーマ検証を強制し、仕様に一致しないリクエストは拒否する。AIによる過剰なリクエストを防ぐためにレート制限を適用する。また、振る舞い検知を導入してAIエージェントの標準的なパターンを学習させ、逸脱をリアルタイムで検知する。このモデルは固定せず、APIの変更に合わせて更新し続ける生きたプロセスとして扱うこと。
  2. APIの認証と認可の保護:
    自動期限切れ機能を持つ短命トークンを導入し、キーを定期的にローテーションする。認証情報はシークレット管理プラットフォームで安全に保管しておく。マシン・ツー・マシン(M2M)のAPIコールにはmTLS(相互認証TLS)を必須とする。OAuth 2.0のスコープやABAC(属性ベースアクセス制御)ルールを適用し、トークンの権限を制限しておく。特にAIエンドポイントでは、権限過剰を防ぐため、学習データのアップロード、推論、モデル管理などの機能ごとに権限を分離する。
  3. APIドリフト(仕様乖離)と不正な変更の監視:
    稼働中のAPIの挙動と承認済み仕様を比較する、自動化された「ドリフト検知」をセットアップしておく。すべてのAPI仕様にバージョン管理を導入し、特にAI関連の変更にはコードレビューを義務付ける。ドリフト監視とエンドポイントのフィンガープリント(指紋認証)を組み合わせることにより、ガバナンス外で追加された新しい機能やパラメータを迅速に発見できるようにする。
  4. データ漏えいの検知と遮断:
    APIゲートウェイにDLP(データ損失防止)ルールを実装し、外部へのレスポンスに個人識別情報(PII)、APIキー、知的財産などの機密パターンが含まれていないかスキャンする。正規表現やAIベースのコンテンツフィルタを用いて、より深い検査を行っておく。異常に大きなレスポンスペイロード、特にAIエンドポイントからのものには警告を発する。「LLMに接続されたAPI経由で財務データが流出する場合にフラグを立てる」といったコンテキストに基づくルールを適用し、漏えいが確認された場合はリアルタイムで遮断することを検討しておく。
  5. 敵対的AI(Adversarial AI)の脅威への備え:
    プロンプトインジェクション、不正な形式のデータ、モデル回避の試みなど、悪意のある入力を用いてAPIをテストする。AIモデルに到達する前に、すべてのテキスト、ファイル、画像入力に対して無害化を行う。ポイズニング(学習データ汚染)が検知された場合に備え、安全なモデルバージョンに巻き戻すためのロールバック計画を維持しておく。開発者が敵対的なパターンを認識し、AIの出力を信頼する前に検証できるようトレーニングを行い、開発ライフサイクルに「AI安全性の視点」を組み込む。
  6. API主導の侵害に対するインシデントレスポンスの強化:
    IP、トークンID、リクエストのフィンガープリントを含む詳細なAPIログをSIEM(セキュリティ情報イベント管理)に集約する。連絡先、封じ込め手順、復旧プロセスを詳述したAPI専用のランブックを整備しておく。APIの連鎖攻撃やAI関連の不正利用を含むシミュレーションを実施し、対応ワークフローの有効性を検証して、検知から対応までの時間を短縮する。
  7. DevSecOpsへのAPIセキュリティの組み込み:
    CI/CDパイプラインにおいて、静的・動的テストによるAPIスキャンを自動化する。安全でないエンドポイントの導入や認証のバイパスを許すビルドは避ける。AI向けAPIを本番公開する前には、セキュリティ部門の承認を必須とする。依存関係スキャンを利用して、AI関連ライブラリにパッチが適用されていることを確認する。仕様検証やファジーテストは、定期的なレビューだけでなく、継続的インテグレーションの一部として組み込む。
  8. 組織内におけるAPIセキュリティ専門知識の育成:
    OWASP API Top 10、AI APIのリスク、敵対的機械学習の脅威に関するターゲットを絞ったトレーニングを実施する。開発者、セキュリティエンジニア、AIスペシャリストが定期的に知見を共有する場を作っておく。セキュリティ会議やワークショップへの参加を奨励し、社内ハッカソンでAPIの攻防シナリオをシミュレートすることにより、実践的なスキルを向上させる。
  9. 初日からの「最小権限の原則」の適用:
    すべてのAPIに対して、ロールベース(RBAC)および属性ベース(ABAC)のアクセス制御を使用する。「推論用」と「モデル学習用」でトークンを分けるなど、きめ細かなスコープを割り当てておく。機密性の高いAPIエンドポイントへのアクセスを、承認されたIP範囲やデバイスに制限する。管理者アクションには一時的な認証情報を発行し、使用後は直ちに失効させます。権限がビジネスニーズと一致しているか、定期的に監査を行っておく。
  10. データ・サプライチェーンの保護:
    デプロイ前にすべてのAIモデル資産(アーティファクト)に署名し、検証を行っておく。すべてのデータパイプラインを保護し、転送中のデータは暗号化する。リリース前にAIライブラリを含むすべての依存関係に脆弱性がないかスキャンする。データセットとモデルのバージョン管理を徹底しておく。APIの統合においてもソフトウェア部品構成表(SBOM)の原則を適用し、すべてのコンポーネントを追跡・検証できるようにする。

APIはもはや、単なるバックエンドの利便性のためのツールではない。AI時代において、APIはデジタルビジネスの「中枢を担う動脈」である。その露出度、複雑性、そして変化の速度は劇的に増大しており、それらを標的とする脅威も同様に高度化している。継続的な可視化(継続的なモニタリング)と、適応型の「AIを考慮したセキュリティプラクティス」を組み合わせることのできるITおよびセキュリティの専門家こそが、組織を保護するための最善のポジションを確保することになるだろうと結論付けている。

米国NISTがクラウドネイティブシステムのAPI保護ガイドライン更新版を公開

米国立標準技術研究所(NIST)は、2026年3月16日、「NIST SP 800-228-upd1クラウドネイティブシステムにおけるAPI保護のためのガイドライン」(関連情報(https://csrc.nist.gov/pubs/sp/800/228/upd1/final))を公開した。本書は、2025年6月27日に公開された同ガイドライン初版(関連情報(https://csrc.nist.gov/News/2025/nist-releases-sp-800-228))の更新版である。

現代のエンタープライズITシステムは、組織のビジネスプロセスを支える統合手段として、一連のAPIに依存している。APIを安全にデプロイするためには、APIライフサイクルの各フェーズにおけるリスク要因や脆弱性の特定、および管理策や保護措置の開発が必要となる。今回の更新版ガイドラインでは、この目的を達成するために以下の側面を扱っている。

(a) APIの開発およびランタイムにおける様々なアクティビティ中のリスク要因、または脆弱性の特定と分析
(b) APIのプリランタイム(実行前)およびランタイム(実行時)の各段階において推奨される、基本的および高度な管理策と保護措置
(c) セキュリティ実務者が、リスクに基づいた段階的なアプローチで自社のAPIを保護できるよう、これらの管理策を実現するための様々な実装オプションに関する長所と短所の分析

 本更新版ガイドラインは、以下のような構成になっている。

エグゼクティブ・サマリー

  1. はじめに
    1.1. ゼロトラストとAPI:消失する境界
    1.2. APIライフサイクル
    1.3. 本文書の目的
    1.4. 他のNIST文書との関係
    1.5. 本文書の構成
  2. APIのリスク:脆弱性とエクスプロイト(攻撃)
    2.1. 企業インベントリにおけるAPIの可視性の欠如
    2.2. 認可の欠如、誤り、または不十分な認可
    2.3. 認証の不備(Broken Authentication)
    2.4. 制限のないリソース消費
    2.4.1. 制限のないコンピューティングリソースの消費
    2.4.2. 制限のない物理リソースの消費
    2.5. 権限のない呼び出し元への機密情報の漏えい
    2.6. 入力データの検証不十分
    2.6.1. 入力バリデーション
    2.6.2. 悪意のある入力からの保護
    2.7. クレデンシャルの正規化:管理策のための準備段階
    2.7.1. 境界をまたぐゲートウェイ
    2.7.2. サービスIDはあるがユーザーIDがないリクエスト
    2.7.3. ユーザーIDはあるがサービスIDがないリクエスト
    2.7.4. ユーザーIDとサービスIDの両方を持つリクエスト
    2.7.5. 他システムへのアウトリーチ
    2.7.6. 「混乱した代理人(Confused Deputy)」問題の緩和
    2.7.7. アイデンティティの正規化
  3. APIに推奨される管理策
    3.1. プリランタイム(実行前)保護
    3.1.1. 基本的なプリランタイム保護
    3.1.2. 高度なプリランタイム保護
    3.2. ランタイム(実行時)保護
    3.2.1. 基本的なランタイム保護
    3.2.2. 高度なランタイム保護
  4. API保護の実装パターンとトレードオフ
    4.1. 中央集約型APIゲートウェイ
    4.2. ハイブリッドデプロイメント
    4.3. 分散型ゲートウェイパターン
    4.4. 関連技術
    4.4.1. Webアプリケーションファイアウォール(WAF)
    4.4.2. ボット検知
    4.4.3. 分散型サービス拒否(DDoS)攻撃の緩和
    4.4.4. APIエンドポイント保護
    4.4.5. Web Application and API Protection (WAAP)
  5. 結論とまとめ
    参考文献
    附表A. API分類の体系
    A.1. 公開度に基づくAPI分類
    A.2. 通信パターンに基づくAPI分類
    A.3. アーキテクチャスタイルまたはパターンに基づくAPI分類(APIタイプ)
    A.4. データの機密性に基づくAPI分類
    附表B. DevSecOpsのフェーズと関連するAPI管理策のクラス
    附表C. ランタイム中に設定される制限のタイプ
    附表D. リスクカテゴリ別のAPIリスク一覧
    附表E. APIライフサイクル段階別の推奨セキュリティ管理策一覧
    附表F. 変更履歴

APIは、企業のデジタルインフラにアプリケーションを統合する上で極めて重要な役割を果たしている。物理的・論理的なアプリケーションがいずれも高度に分散している現状を踏まえ、NISTは、APIが外部に公開されているか、あるいは企業インフラ内の他のアプリケーションによって消費されるものであるかにかかわらず、ゼロトラスト原則に基づいて運用することを推奨している。すべてのソフトウェアと同様に、APIは反復的なライフサイクル(開発、構築、デプロイ、運用)を経て、これらは大きく「プリランタイム(実行前)」と「ランタイム(実行時)」の段階に分類される。

APIデプロイメントの急激な拡散、それらが動作する異種混合のインフラ、そしてAPIが可能にする貴重な企業データへのアクセスは、これらが攻撃の標的になる背景となっている。APIセキュリティを確保するために適切な保護手段や管理策を特定するには、脆弱性とそれらを悪用する可能性のある攻撃ベクトルの詳細な分析が前提条件となる。このNIST文書では、正式なスキーマの欠如、不適切なインベントリ管理、堅牢な認証・認可サポートの欠如、リソース消費の不適切な監視、機密情報の漏洩に対する不十分な制御など、脆弱性を引き起こすさまざまなリスク要因を分析している。

本ガイドラインで推奨される管理策は、「プリランタイム保護」と「ランタイム保護」に分類されている。さらに、企業がリスクに基づいた段階的なアプローチでデジタル資産を保護できるよう、これらは「基本保護」と「高度な保護」に細分化されている。プリランタイム保護はAPI仕様のパラメータ(構文的および意味的側面)に焦点を当て、ランタイム保護はAPIのリクエストおよびレスポンス操作(暗号化された通信チャネル、適切な認証・認可など)に焦点を当てている。

このガイドラインは、各タイプの保護、デプロイ、またはパターンの利点と欠点を説明することにより、推奨される管理策を構成・適用するための実用的かつ標準的な実装オプションを提示している。NISTは、これにより、実務者が情報に基づいた意思決定を行い、自社にとって堅牢でコスト効率の高いAPIセキュリティインフラを実現することを可能にするとしている。

APIは今やビジネスの中枢を担う動脈となりつつある。従来の境界型防御に頼るのではなく、継続的な可視化とAIの特性を考慮した適応型セキュリティへのシフトが不可欠となっている。

CSAジャパン関西支部メンバー
DevSecOps/サーバーレスWGリーダー
笹原英司

CSAIについて

2026年3月24日
CSAジャパン 理事 諸角昌宏

RSAC2026でアナウンスのあったCSAI Foundationについて、公開されている情報を元にまとめてみました。

目的

AIが、単なる支援ツールから、ワークフローを調整し、デジタルインフラ全体で連携し、意思決定を行うことができる自律システムへと急速に進化しています。そのような状況を受けて、CSAIは、AIのセキュリティ、セーフティ、トラストを推進することを使命としてクラウドセキュリティアライアンス(CSA)によって、設立されました。

CSAIは、商業主導の取り組みでは提供できない、AIセキュリティにおける不可欠なリーダーシップを提供します。それは、エコシステム全体が依拠できる、中立的かつ標準に基づいたガードレールです。この独立した研究は、実世界のエージェンティックAIシステムをセキュアに保つために必要な運用上のトラストインフラを構築するというCSAIの役割に直接反映されます。

CSAI、2026年ミッション

以下の6つの戦略プログラムを行います:

  1. AIリスクオブザバトリー エージェントの実環境における動作・障害・リスクをリアルタイムで可視化。次世代CVE Numbering Authority(CNA)の運営も含む。
  2. エージェンティックベストプラクティス 企業向けのセキュアなエージェント実施ガイドライン、ID優先のアクセス制御、ランタイム認可ガバナンスなど。
  3. 教育・資格認定 TAISE資格のCxO向け・エージェント専門家向け・高校生向けへの拡充。エージェンティックAIサミットシリーズの開催。
  4. CxOtrust CISOs・CIOs・CAIOsを対象とした経営層向けラウンドテーブルや取締役会向けリスク報告フレームワークの提供。
  5. グローバルアシュアランス&トラスト CSA STARのAIシステムへの拡張(ISO 42001・SOC 2準拠)、AIを活用した自動監査エンジン「Valid-AI-ted」の開発。
  6. フューチャーフォワード エージェント向けTAISE資格認定、エージェント相互作用のテスト環境「CSA Pod」、そして将来のAIによる壊滅的リスクを研究する「Catastrophic Risk Annex」。

これらの取り組みは、独立した研究を実践的なプログラムへと転換し、エージェンティックコントロールプレーンをリアルタイムのリスクインテリジェンス、実施可能なベストプラクティス、および継続的なアシュアランスにわたって実際に保護するものとなります。

以上

クラウドセキュリティは不要か? ~ クラウドセキュリティは情報セキュリティの一部として整理すべきか

2026年3月23日
諸角 昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のない意見をいただければ幸いである。

クラウドが企業のインフラとして本格的に普及し始めた2000年代後半、セキュリティは最大の懸念事項として繰り返し取り上げられた。「データをどこに置くかわからない」「自分でコントロールできない」。そうした不安を背景に、CSAの設立(2009年)、ISO/IEC 27017の策定(2015年)、各CSPによるセキュリティフレームワークの整備など、クラウドセキュリティのベストプラクティスを積み上げるための取り組みが業界全体で重ねられてきた。
そうした積み重ねを経た今、「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という意見を耳にするようになった。ある意味では成熟の証とも言える。ただ、この意見には「概ね妥当だが、そのまま受け入れるには少し注意が必要」と筆者は考えている。クラウド環境ではリスクの発生メカニズムが変わり、責任の所在が分断され、従来の情報セキュリティだけでは見落としが生まれやすい構造がある。「一部である」ことは正しい。しかし「だから特別な考慮は不要」とはならないと考える。本ブログでは、その理由を整理し、具体的にどのようなリスクを念頭に置くべきかを示していきたいと考えている。

命題の構造

「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という主張には、以下の2つの前提が埋め込まれていると考えられる。

  1. 前提① クラウドセキュリティの原則は情報セキュリティと共通している
  2. 前提② 共通しているなら、情報セキュリティとして一括して扱えばよい

前提①は「概ね妥当」と言えそうである。CIAの三要素(機密性・完全性・可用性)はクラウドにも適用される。リスク評価・インシデントレスポンスの考え方も情報セキュリティの原則がそのまま使える。その意味では「一部である」という捉え方に一定の合理性がある。
ただし、前提②は必ずしも自明ではないように思われる。「同じ原則が適用できる」ことと「同じ対策で十分である」こととは、少し異なる話ではないだろうか。では、なぜ同じ対策では十分でないのか。その理由を考えるには、クラウド環境におけるリスクの性格を少し丁寧に見ておく必要がある。

クラウド環境でリスクはどう変わるか

ここで、「同じ対策では不十分」という感覚の背景には、クラウド環境がリスクの発生メカニズムを変えているという事実がある。ここで少し立ち止まって、「クラウド固有のリスク」という言葉自体を問い直してみたい。設定ミス・過剰権限・データの不適切な公開・認証の不備など、これらはいずれもクラウド以前から存在していたリスクであり、クラウドが新たに生み出したものではない。より実態に近い言い方は「クラウドで特に考慮が必要なリスク」であると言える。リスクの種類が固有なのではなく、リスクの顕在化しやすさ・影響規模・発生メカニズムが、クラウド環境において特殊な形をとる、ということだと考える。以下に、同じリスクがクラウドで増幅されやすい4つの構造的な理由を上げる。

  1. スケール:APIひとつの設定ミスが数百万件規模のデータに即時影響しうる
  2. 速度:IaCの導入などによりミスが複製・展開される速度が人間の確認速度を超えやすい
  3. 境界の曖昧さ:「内側は安全」という境界が流動的で自明でなくなっている
  4. 責任の分断:CSPと利用者の責任分断により「誰が対処するか」が見えにくくなる

こうした増幅のメカニズムを理解すると、「情報セキュリティの一部として扱えば十分か」という問いへの答えが少し見えてくる。この点について、国際規格の体系はひとつの示唆を与えてくれる。

ISO/IEC 27001と27017が示す規格上のヒント

ISO/IEC 27001の改訂の歴史と、27017との関係を辿ると、「情報セキュリティの一部ではあるが、専門的な深さは別途必要」という考え方が、規格の構造としても反映されてきたように見える。

規格クラウドセキュリティの扱い
ISO/IEC 27001:2013クラウドを独立して扱っていない。供給者関係(A.15)の中にクラウド利用が包含される形にとどまり、クラウド固有の考慮事項は規定されていない。
ISO/IEC 27001:2022新たに「A.5.23 クラウドサービスの利用における情報セキュリティ」を独立した管理策として追加。クラウドサービスの取得・利用・管理・終了のライフサイクル全体にわたるポリシーとプロセスの確立を求めている。ただし「何をすべきか」の入口レベルの規定にとどまっている。
ISO/IEC 2701727001の補完規格(ガイダンス規格)。クラウド固有のセキュリティ管理策を実装レベルで規定。CSPとCSCそれぞれの責任を明示し、仮想環境の分離・管理者権限の制限・クラウド環境の監視・データ削除の確認など、27001では扱われないクラウド固有の管理策を追加している。

27001:2022でA.5.23が独立した管理策として追加されたことは、ISO/IECがクラウドを「供給者関係の延長」として扱うだけでは不十分と判断した結果と見ることができる。同時に、A.5.23が「入口レベル」にとどまることで、27017との役割分担がより明確になったとも言えそうだ。27001:2022が「クラウドを使う組織が最低限押さえるべきこと」を示し、27017が「実装レベルの詳細なコントロール」を補うという二層構造となっている。加えて27017の特徴として、CSPとCSC双方に対して異なる管理策を定めている点が挙げられる。これは27001:2022にはない視点であり、「クラウドにおけるセキュリティ責任は一者に帰属しない」という責任共有モデルの考え方を、規格レベルで反映したものと捉えることができる。

27001:2013の時点では「27001だけでは不十分だから27017が生まれた」という話であったが、27001:2022でA.5.23が追加された。しかしながら、27001本体がクラウドを取り込んだにもかかわらず、それでも27017は廃止されず、補完規格として併存し続けている。つまり「27001にクラウドが入れば27017は不要になる」とはならなかった。これは「入口レベルの要求事項」と「実装レベルの詳細なコントロール」は、同一のフレームワークでは代替できないということを示していると考えられる。

ベンダーニュートラルな概念はまだ必要か

AWS、Azure、GCPといったCSPは、自社サービスに特化した詳細なセキュリティ文書を継続的に更新している。また、CSAガイダンスは、V4まではクラウドセキュリティの概念を中心とした内容であったが、V5ではより具体的な実装レベルの内容にシフトしている。こうした状況の中で、ベンダーニュートラルにクラウドセキュリティの概念を説明することに、まだ意味はあるのだろうか。 筆者は、意味はあると考えるが、「誰にとっての意味か」は以前より明確に問われるようになってきているように感じる。

立場ベンダーニュートラルな概念の必要性
実装担当者(単一CSP)CSPの文書で実装が回る場面は多い。ただし、概念の裏付けなく手順だけを習得している場合、「設定は文書通りにやったはずなのになぜ問題が起きたか」という状況につながる可能性がある。
実装担当者(マルチクラウド)マルチクラウドの横断的リスク管理にはCSP固有の知識だけでは不十分と考えられる。ベンダーニュートラルな概念が明示的に求められる場面と言える。
設計・アーキテクトCSPの選定・評価・責任境界の設計は、特定CSPの操作知識よりも概念的な基盤が判断の軸になる。
セキュリティ評価・監査複数CSPを横断して評価するには、共通の基準軸が必要になる。
経営・ガバナンス層投資判断・リスク許容・規制対応は、概念レベルの理解が前提になる。

CSAガイダンス v5が具体策にシフトした背景には、CSPの文書との競合というより、「概念だけでは実務で参照されにくくなった」という現実への対応があると思われる。ただし逆説的に、具体策の詳細が増すほど、その具体策をどのCSPに、どの優先順位で適用するかを判断するための概念的基盤の価値は相対的に高まるものと考えられる。

まとめ

ここまでの内容を振り返ると、「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という考え方には、一定の合理性があることがわかる。クラウドセキュリティの原則は情報セキュリティと共通しており、CIA三要素やリスク評価の考え方はクラウド環境にもそのまま適用できる。

ただし、「原則が共通している」ことと「同じ対策で十分である」こととは、少し異なる話ではないかと考える。クラウド環境では、同じリスクがスケール・速度・責任の分断・境界の曖昧さという4つの構造的な特性によって増幅されやすい。この点を踏まえると、「情報セキュリティの一部ではあるが、クラウド特有の深さは別途必要」というのが、この問いへのひとつの答えではないかと考える。 ISO/IEC 27001:2022がA.5.23としてクラウドを独立コントロールに加えたこと、27017がCSPとCSC双方への管理策を別途定めていること、そしてベンダーニュートラルな概念が設計・評価・ガバナンスの立場では依然として必要とされていること。これらはいずれも、クラウドセキュリティが「情報セキュリティに吸収されて完結する」のではなく、「情報セキュリティの基盤の上に専門的な理解が積み重なる」という構造を示唆しているのではないかと考えられる。

付録:クラウドで特に考慮が必要なリスク

以下は「クラウドで特に考慮が必要なリスク」をまとめたものである。ISO/IEC 27017が定めるクラウド固有の管理策領域を骨格にしつつ、実務・インシデント事例・規制の観点を加えて整理した。各リスクはクラウド固有というよりも、オンプレミスでも存在するリスクがクラウドの構造的特性(スケール・速度・責任分断・動的変化)によって増幅・複雑化したものとして捉えるとわかりやすい。

データセキュリティ領域

  1. データの所在地・主権(Data Residency / Sovereignty)
    • 意図せぬリージョンへのデータ複製・分散リスク、SaaSでは制御できないリスク
    • CSPのレプリケーション設定により意図せず越境移転が発生するリスク
    • 国ごとのデータローカライゼーション規制(ロシア、中国P等)との抵触
    • マルチリージョン構成時の法的管轄の競合
  2. データの残存性(Data Remanence)
    • クラウドストレージ削除後、実際にデータが消去されたかを確認できない
    • スナップショット・バックアップの削除漏れ
    • CSPが同一物理メディアを別テナントに再割り当てする際のデータ残存
    • ログ・一時ファイルへ機微データ等が意図せず記録されるケース
  3. 暗号化鍵管理
    • CSP管理の鍵を使う場合、CSPによるデータアクセスを完全には排除できない
    • BYOK(Bring Your Own Key)とHYOK(Hold Your Own Key)の選択とトレードオフ
    • 鍵のローテーション失敗による大規模な復号不能リスク
    • HSM(Hardware Security Module)のクラウド実装における信頼性評価
  4. データ分類とラベリング
    • 複数クラウドサービス間でのデータ分類ポリシーの一貫性維持が困難
    • 非構造化データ(S3オブジェクト等)への分類適用の難しさ
    • 開発環境への本番データのコピーにおける漏洩のリスク

インフラ・プラットフォーム領域

  1. ハイパーバイザーセキュリティ
    • VMエスケープ攻撃
    • サイドチャネル攻撃によるテナント間情報漏洩
    • ハイパーバイザー自体の脆弱性は利用者側で対処不能
  2. コンテナセキュリティ
    • コンテナイメージの脆弱なベースイメージへの依存
    • コンテナランタイムの脆弱性によるホスト侵害
    • Kubernetesのデフォルト設定の甘さ(etcdのピア認証がデフォルト無効、保存データの暗号化が非デフォルト)
    • コンテナ間のネットワーク分離不備によるラテラルムーブメント
    • 特権コンテナの不適切な使用
  3. サーバーレスセキュリティ
    • 関数の実行環境が短命なためフォレンジックが困難
    • イベントインジェクション(悪意あるイベントソースによるファンクション・トリガー)
    • 依存パッケージの脆弱性管理が見えにくい
    • タイムアウト設定の不備によるDoS
  4. ストレージセキュリティ
    • オブジェクトストレージの公開設定ミス(S3バケット等)
    • 署名付きURL(Pre-signed URL)の有効期限管理不備
    • ブロックストレージのスナップショット共有設定ミス
    • バックアップストレージへのランサムウェア感染の波及
  5. ネットワークセキュリティ
    • クラウドリソースのネットワークアクセス制御設定ミスによる意図しない公開
    • VPCピアリングの推移的ルーティングの設計誤解によるリスク
    • パブリックIPアドレスの意図しない割り当て
    • クラウドネイティブなDDoS攻撃(コスト増大を狙った攻撃)
    • サービスエンドポイントの設定漏れによるインターネット経由のアクセスのリスク

IAM・アクセス管理領域

  1. IAMポリシーの複雑性
    • ポリシーの組み合わせによる意図しない権限の継承
    • インラインポリシーと管理ポリシーの混在による可視化困難
    • 条件付きポリシー(IP制限等)の設定ミス
    • リソースベースポリシーとIDベースポリシーの競合
  2. 過剰権限
    • 「とりあえず管理者権限」による最小権限原則の形骸化
    • 使われていないロール・ユーザーの放置
    • 長期アクセス鍵の放置(ローテーションなし)
    • クロスアカウントロールの過剰な信頼関係設定
  3. 認証情報の露出
    • ハードコードされたAPIキー
    • EC2インスタンスメタデータエンドポイント経由の認証情報窃取
    • CI/CDパイプラインへのシークレットのハードコード
    • ログへの認証情報の誤出力
  4. フェデレーション・シングルサインオン
    • IdPの侵害によるクラウド環境全体への影響波及
    • SAMLレスポンスの署名検証不備
    • OAuthのオープンリダイレクト悪用
    • JWTの署名アルゴリズム混乱攻撃

アプリケーション・DevSecOps領域

  1. CI/CDパイプラインのセキュリティ
    • パイプラインへの悪意あるコードの注入
    • ビルド環境の汚染によるサプライチェーン攻撃
    • アーティファクトリポジトリへの不正アクセス
    • デプロイ権限の過剰付与
  2. IaC(Infrastructure as Code)
    • TerraformやCloudFormationの設定ミスが大量環境に一括展開される
    • IaCテンプレートへのシークレットの埋め込み
    • ドリフト(実環境とIaC定義のずれ)による設定管理の崩壊
    • モジュール・プロバイダの脆弱性(サプライチェーンリスク)
  3. APIセキュリティ
    • クラウドサービス間通信のAPIキー管理不備
    • APIゲートウェイの認証バイパス
    • レートリミットの不備によるDoS
    • GraphQLの過剰なデータ露出

可視性・運用領域

  1. ログ・モニタリング
    • CloudTrail・Audit Logのデフォルト無効による証跡の欠如
    • ログの保存コストを理由にした無効化・期間短縮
    • マルチクラウド環境でのログの集約困難
    • 攻撃者によるCloudTrailの無効化(検知回避)
    • ログの改ざん防止設定の欠如
  2. 設定管理の継続的監視
    • リソースの動的な増減による設定管理対象の常時変化
    • 管理されていないクラウドリソースの把握困難
    • 設定変更の速度がレビューの速度を超える問題
    • CSPのサービス仕様変更による既存設定の無効化
  3. インシデントレスポンスの困難性
    • 揮発性環境(コンテナ・サーバーレス)でのフォレンジック証拠の消失
    • CSPへの証拠保全要請の手続き的複雑さ
    • マルチリージョン・マルチクラウドでの攻撃経路の追跡困難
    • メモリフォレンジックがクラウド環境では原則不可能

法的・コンプライアンス領域

  1. 責任共有モデルの誤解
    • CSPと利用者の責任境界をサービスモデルごとに正確に把握していない
    • 「CSPが対応してくれると思っていた」という認識齟齬
    • 契約上の責任と技術的な責任の乖離
  2. クロスボーダー規制
    • GDPRのSCC(標準契約条項)要件を満たさないデータ移転
    • 各国当局によるCSPへのデータ開示要求への対応義務(CLOUD法)
    • 規制ごとに異なる「個人データ」の定義の適用困難
  3. 監査・証拠保全
    • マルチテナント環境での監査証跡の独立性確保
    • 米国をはじめとする訴訟制度における電子証拠開示(eDiscovery)でのクラウドデータの収集手続き
    • CSPのSOC2レポートの評価能力の欠如(読めても解釈できない問題)

その他のリスク

  1. マルチクラウド固有のリスク
    • クラウド間のID連携の複雑性
    • セキュリティポリシーの一貫した適用が困難
    • 最も弱いクラウド環境が全体の侵入口になる
  2. AIワークロードのリスク
    • クラウド上のLLM基盤へのプロンプトインジェクション経由のデータ抽出
    • 学習データへの不正アクセスによるモデル汚染
    • 推論APIの過剰公開

以上

SaaS 環境におけるPAM利用について

第4回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第4回会議の内容をまとめて公開する。

問題点の概要

CSAが公開した「クラウドファースト時代における特権アクセス管理」では、「特権アカウントは侵害において常に最も標的とされ最も深刻な被害をもたらす攻撃経路である」と指摘している。その理由として以下2点を上げている。

  1. ガートナー社の調査:インシデントの50%以上が、アイデンティティ、アクセス、特権の管理不備に起因
  2. ベライゾン社のData Breach Investigations Report(DBIR):データセキュリティインシデントの80%が、侵害または悪用されたクレデンシャル(特権・非特権を含む)に関連している

      現代のPAMの中核となる原則は最小特権であり、ユーザーは業務に必要な最小限のアクセス権のみを、必要な期間のみ保持すべきであるということで、ジャストインタイム(JIT)およびジャストイナフアクセス(JEA)モデルへの移行が求められている。また、特権アカウントや特権アクセスを慎重に管理するために監査で確認することが求められているが、それをさらに確実にしていくには自動化と継続的なモニタリングが必要であり、PAMはこれを支援することができる。

      このような状況を受けて、今回のSaaSセキュリティリーグでは、PAMの利用状況の現状、問題点、考慮事項等についてディスカッションした。

        ディスカッション内容

        1. PAMの利用状況
          現在は、PAMの利用を始めたという状況で、徐々に利用範囲を広げている状況である。したがって、対象範囲を絞って重要なシステムのサーバーにおける特権管理としてサーバーOS上のユーザーをまず対象として開始している。
          PAMの利用方法としては、アカウント管理とログ・監視をメインにして利用している。利用方法の検討もまだ始まったばかりであり、今後の方向性について議論している状況である。SaaSへの利用についてはまだこれからである。また、監督官庁からPAMの利用を推奨されていたり、PCIDSSでPAM的なものを入れる要件があるため導入しているが、PAMの有効性についてはまだあまり感じていない。
          このような状況の中ではあるが、PAMの機能としての特権の承認プロセスやログ管理機能に対する要求があり、この観点での利用が広がっていく可能性がある。
          なお、JITはあまりやられていない状況である。

        2. 管理者にとって JITは現実的か?
          JITは、特権を恒常的に付与しないことで攻撃に可能な時間と影響範囲を最小化できる一方、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時対応時の対応が遅れる可能性があると考えられる。このような背景を受けて、JITがどのように利用できるかであるが、一般的な管理・運用としては有効と思われるが、運用上できるのかどうかの検討が必要と思われるということであった。また、システムの管理は特権アカウントを使って行うという既存の運用方法があり、JIT運用そのものが社内でも抵抗が強いことが分かった。
          SaaSでの利用の観点で行くと、SaaS自体がJIT機能を持っていない状況では難しいということである。なお、IaaS/PaaSでは、JITの仕組みを使っているケースが多いので利用可能である。

        3. NHI(サービスアカウント等)をどう扱うべきか?
          NHIの利用としてSaaS間の連携は結構行われており、この部分において連携方法等を検討しているとのことである。agenticAIについては、まだ社内で使われている状況ではないので、NHI等の連携の問題はまだ明確ではない。
          NHIのアイデンティティとアクセス管理は、台帳を用いた手動による管理を行っており、連携においてどのくらいの権限を与えるかについて検討が必要である。AIに関しては、付与する権限は情報収集的な読み取り権限のみとかシステムに影響を与えない権限のみを与えることで管理している。

        まとめ

        現状、PAMの本格導入を行っているケースは少ないものと思われる。
        攻撃に可能な時間と影響範囲を最小化できる特徴を持ったJITについては、まだ検討段階が多いようである。常時特権を持つアカウントによる管理に慣れている状況もあり、文化の変更も伴う。導入に向けては、ユースケースが広がることが必要であると思われる。
        AIにどこまで権限を持たせるかはすでに問題になってきている。AIの利活用とデータ保護の問題は、今後大きな問題になってくると思われる。合わせて、NHIによるアプリ連携の課題やagenticAIへの対応も今後取り組んでいかなければならない課題である。

        参考資料

        以上