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への対応も今後取り組んでいかなければならない課題である。

        参考資料

        以上

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

        CSAジャパン関西支部では、「海外に学ぶSMBのクラウドセキュリティ基礎(AIセキュリティ編)(1)」(https://cloudsecurityalliance.jp/newblog/2025/07/14/smb_aisec_1/)および「海外に学ぶSMBのクラウドセキュリティ基礎(AIセキュリティ編)(2)」(https://cloudsecurityalliance.jp/newblog/2025/09/16/smb_aisec_2/)で、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発された人工知能(AI)セキュリティ固有のガイドを紹介したが、今回は、エージェンティックAIのガバナンスについて取り上げる。

        シンガポール政府が世界初のエージェンティックAIガバナンス文書を発行

        2026年1月19日、シンガポール情報通信メディア開発庁(IMDA)は、「エージェンティックAI向けモデルAIガバナンスフレームワーク」(https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf)を公開している。現時点で、エージェンティックAIに特化した包括的なガバナンス文書を発行したケースとしては、本書が世界初となる。

        本文書は、エージェンティックAIの導入に伴う新たなリスクに対して、組織が信頼性と安全性を確保しながら活用できるように支援することを目的としており、以下のような構成になっている。

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

        1. エージェンティックAIの紹介
          1.1 エージェンティックAIとは?
           1.1.1 エージェントの中核構成要素
           1.1.2 マルチエージェント構成
           1.1.3 エージェント設計がその限界と能力に与える影響
          1.2 エージェンティックAIのリスク
           1.2.1 リスクの発生源
           1.2.2 リスクの種類
        2. エージェンティックAI向けモデルAIガバナンスフレームワーク
          2.1 リスクを事前に評価し、制限する
           2.1.1 エージェント導入に適したユースケースの特定
           2.1.2 エージェントの限界と権限を定義することで設計段階からリスクを制限
          2.2 人間の意味ある責任を確保する
           2.2.1 組織内外における責任の明確な割り当て
           2.2.2 意味ある人間による監督を設計に組み込む
          2.3 技術的な制御とプロセスを実装する
           2.3.1 設計・開発段階における技術的制御の活用
           2.3.2 導入前のエージェントのテスト
           2.3.3 導入時の継続的な監視とテスト
          2.4 エンドユーザーの責任を可能にする
           2.4.1 ユーザーの多様性とニーズの違い
           2.4.2 エージェントと直接やり取りするユーザー
           2.4.3 エージェントを業務プロセスに統合するユーザー
          附表A:参考資料 .
          附表B:フィードバックと事例の募集

        エージェンティックAIを構成する6つのコアコンポーネント

        本フレームワークにおいて、エージェンティックAIシステムとは、AIエージェントを用いて、特定の目的を達成するために複数のステップにわたる計画を立てて実行できるシステムを指す。一般的に、エージェントは、ユーザーが定めた目標を達成するために、ある程度自律的に計画を立て、行動を実行する能力(例:ウェブ検索やファイルの作成など)を備えていることが多い。

        エージェントは言語モデルの上に構築されており、以下のような6つの中核的要素により構成される。

        1. モデル(Model):
          • SLM(小規模言語モデル)、LLM(大規模言語モデル)、またはMLLM(マルチモーダル大規模言語モデル)で構成され、エージェントの中核となる推論・計画エンジンとして機能する。指示を処理し、ユーザーの入力を解釈し、文脈に応じた応答を生成する。
        2. 指示(Instructions):
          • エージェントの役割、能力、行動上の制約を定義する自然言語によるコマンド。たとえば、LLMに与えるシステムプロンプトなどが該当する。
        3. 3メモリ(Memory):
          • LLMがアクセス可能な情報で、短期記憶または長期記憶として保存されるデータ。過去のユーザーとのやり取りや外部知識ソースからの情報を取得できるようにするために追加されることがある。
        4. 計画と推論(Planning and Reasoning):
          • モデルは通常、推論と計画を行うように訓練されており、タスクを達成するために必要な一連のステップを出力できる。
        5. ツール(Tools):
          • エージェントがファイルやデータベースへの書き込み、デバイスの制御、取引の実行など、他のシステムとやり取りしながら行動を実行するための手段です。モデルはタスクを完了するためにツールを呼び出す。
        6. プロトコル(Protocols):
          • エージェントがツールや他のエージェントと通信するための標準化された方法。たとえば、Model Context Protocol(MCP)はエージェントがツールと通信するためのプロトコルであり、Agent2Agent Protocol(A2A)はエージェント同士が通信するための標準を定義している。

        エージェンティック AI向けモデルAIガバナンス・フレームワーク(MGF)は、エージェント型AIに関するリスクと、それらのリスクを管理するための新たなベストプラクティスを、組織が体系的に把握できるようにするための枠組みである。リスクが適切に管理されれば、組織はより安心してエージェンティックAIを導入することができるとしている。

        エージェンティックAI実装に際して考慮すべき4つの領域

        このMGFは、自社でAIエージェントを開発する場合でも、外部のエージェントソリューションを利用する場合でも、エージェンティックAIの導入を検討している組織を対象としている。これまでのモデルガバナンス・フレームワークを基盤として、エージェントに関して組織が考慮すべき4つの主要な領域を以下のように整理している。

        1. リスクを事前に評価し、制限する
          ・組織は、エージェントによって新たに生じるリスクを考慮し、内部の構造やプロセスを適応させる必要がある。その第一歩は、エージェントの行動によってもたらされるリスクを理解することであり、エージェントが取り得る行動の範囲、行動の可逆性、エージェントの自律性の度合いなどが関係する。
          ・リスクを早期に管理するために、組織は計画段階でエージェントの影響範囲を制限する設計(例:ツールや外部システムへのアクセス制限)を行うことが推奨される。また、エージェントの行動が追跡可能かつ制御可能であるように、堅牢なID管理やアクセス制御を導入することも重要である。
        2. 人間の意味ある責任を確保する
          ・エージェンティックAIの導入に「ゴーサイン」が出た後は、人間の責任を確保するための措置を講じる必要がある。ただし、エージェントの自律性が高まることにより、従来の静的なワークフローに基づく責任の割り当てが複雑化する可能性がある。さらに、エージェントのライフサイクルには複数のステークホルダーが関与するため、責任の所在が分散するリスクもある。
          ・組織内外の関係者の責任範囲を明確に定義し、技術の進化に応じて迅速に対応できるよう、適応的なガバナンス体制を整備することが重要である。特に、ヒューマン・イン・ザ・ループ(HITL:Human-in-the-Loop)の設計は、自動化バイアスへの対処を含めて再考する必要がある。たとえば、重大な判断や不可逆な行動には人間の承認を必須とするチェックポイントを設けることや、人間による監督が時間とともに有効に機能しているかを定期的に監査することが求められる。
        3. 技術的な制御とプロセスを実装する
          ・エージェントを安全かつ信頼性の高い形で運用するために、ライフサイクル全体にわたって技術的な対策を講じる必要がある。
          ・開発段階では、計画機能、ツール、成熟途上のプロトコルなど、エージェンティック AI特有の新しい構成要素に対して、技術的制御を組み込むことが重要である。これにより、新たな攻撃対象領域から生じるリスクに対応できる。
          ・導入前には、エージェントの基本的な安全性と信頼性(実行精度、ポリシー遵守、ツール使用の適切性など)を検証する必要がある。これには、従来とは異なる新しいテスト手法が求められる。
          ・導入時および導入後には、エージェントが環境と動的に相互作用するため、すべてのリスクを事前に予測することは困難である。そのため、段階的な導入と継続的なモニタリングが推奨される。
        4. エンドユーザーの責任を可能にする
          ・エージェントの信頼性ある導入は、開発者だけでなく、それを使用するエンドユーザーの責任ある利用にも依存する。
          ・責任ある利用を促すために、最低限として、ユーザーにはエージェントの行動範囲、アクセス可能なデータ、ユーザー自身の責任について明確に伝える必要がある。
          ・組織は、人間とエージェントの相互作用を適切に管理し、効果的な監督を行うための知識を従業員に提供するトレーニングを実施することも検討すべきである。これは、従業員が自身の専門性や基本的なスキルを維持しながら、エージェントと協働できるようにするためである。  シンガポールサイバーセキュリティ庁のサイバーセキュリティ認証プログラムに準拠したAIセキュリティガイドラインが、AIシステム全般(モデル、データ、インフラ)を対象とし、セキュリティ・バイ・デザイン、攻撃耐性、アクセス制御の観点から、技術的セキュリティ対策(設計・運用)に焦点を当てているのに対して、本フレームワークは、エージェンティックAIを対象とし、リスク評価、責任分担、技術制御、ヒューマン・イン・ザ・ループの観点から、ガバナンス、責任、リスク管理、ユーザー教育に焦点を当てている。

        AIセキュリティ認証プログラムは、エージェンティックAIを含むAIシステム全般の技術的な安全性と堅牢性を担保するための基盤を提供する一方、エージェンティック AI向けモデルAIガバナンスフレームワークは、エージェンティックAIの設計・導入・運用におけるリスク管理と責任の明確化を通じて、信頼性ある社会実装を支援する。両者は、技術とガバナンスの両輪として、シンガポールにおけるAIの安全・信頼・倫理的な活用を支える枠組みとなっている。

        エージェンティックAI固有のセキュリティ課題

         シンガポールのエージェンティックAI向けモデルAIガバナンスフレームワークは、クラウドセキュリティアライアンス(CSA)の公開情報の中で、「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」(2025年5月12日公開、https://cloudsecurityalliance.org/blog/2025/05/12/agentic-ai-understanding-its-evolution-risks-and-security-challenges)と、「エージェンティックAIにおけるアイデンティティ/アクセス管理:新たなアプローチ」(2025年8月18日公開、https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach)を参照している。

        前者の「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」では、エージェンティックAIのセキュリティ課題として、安全性(エージェントが有害な行動を取らないようにする)およびセキュリティ(悪意ある攻撃者による悪用を防ぐ)を挙げた上で、以下のような脅威例を挙げている。

        ・意図の破壊・目標の操作:プロンプトインジェクションなどにより、エージェントの目的を誤認させる。
        ・メモリポイズニング:履歴やデータストアを改ざんし、意思決定を誤らせる。
        ・連鎖的なハルシネーション:LLMが誤情報を生成し、それがシステム全体に波及する。

        そして、エージェンティックAIのセキュリティが重要な理由として、以下のような点を挙げている。

        ・データやシステムの悪用リスク:アクセス権限を持つエージェントが乗っ取られると深刻な被害に遭う
        ・予期せぬ結果:モデルの非決定性により、意図しない行動が発生する可能性がある
        ・自律性のリスク:人間の関与が減ることで、過剰な自律性が暴走する恐れがある
        ・規制・コンプライアンス対応:将来的にはエージェンティックAIにも特有の法的要件が課される見込みである

        エージェンティックAIは、自律性・適応性・複雑なタスク処理能力を備えた次世代AIとして期待される一方で、新たなセキュリティリスクやガバナンス課題をもたらす。これに対応するには、従来のサイバーセキュリティに加え、以下の通りAI特有のリスクに対応した新しいフレームワークとプロアクティブな対策が不可欠だとしている。

        ・新たなガバナンス基準やフレームワークが必要(例:OWASP Top 10 for LLM Apps、MITRE OCCULTなど)。
        ・設計段階からのセキュリティ重視、エージェントの認証・認可・監視の強化が求められる

        エージェンティックAIで進化するアイデンティティ/アクセス管理

         次に、後者の「エージェンティックAIにおけるアイデンティティ/アクセス管理:新たなアプローチ」では、エージェンティックAIにおけるアイデンティティ/アクセス管理(IAM)が、従来のID管理システムとは根本的に異なるパラダイムシフトを示している点を強調している。従来のIAMプロトコルは、予測可能な人間のユーザーや静的なアプリケーションを対象に設計されていたが、エージェンティックAIシステムは自律的に動作し、動的な意思決定を行い、リアルタイムで適応可能なきめ細かなアクセス制御を必要とする。

        しかしながら、OAuth 2.1やSAMLといった従来のプロトコルは、粗い粒度の静的な性質や、マシンレベルの高速な認証処理への非対応、そして自律的なAIの運用に必要な文脈認識の欠如といった理由から、エージェンティックAIには適していない。

        この課題に対する解決策としては、以下の機能を統合した包括的なフレームワークが求められる。

        ・ゼロトラスト・アーキテクチャ
        ・分散型ID管理
        ・動的なポリシーベースのアクセス制御
        ・継続的な監視

        これにより、安全性・説明責任・コンプライアンスを確保したAIエージェントの導入が可能になるとしている。

        従来のIAMシステムは、主に人間のユーザーや静的なマシンIDを対象に、OAuth、OpenID Connect(OIDC)、SAMLなどのプロトコルを通じて設計されてきた。しかし、これらのシステムは、複数の知的エージェントが相互に連携して動作するマルチエージェントシステム(MAS)のような、動的・相互依存的・一時的な性質を持つAIエージェントのスケーラブルな運用には本質的に不十分である。

        CSAは、以下の通り新たなエージェンティックAI向けアイデンティティ/アクセス管理(IAM)フレームワークの必要性を提唱している。

        1. 既存プロトコルの限界の分析:
          まず、マルチエージェントシステム(MAS)に既存のプロトコルを適用した際の限界を分解し、粗い粒度の制御、単一エンティティへの最適化、文脈認識の欠如がなぜ効果的でないのかを具体例を交えて説明する。
        2. 新たなIAMフレームワークの提案:
          エージェントの能力、出自、行動範囲、セキュリティ姿勢を包括的に表現できる、検証可能なリッチなエージェントアイデンティティ(ID)に基づいたフレームワークを提案する。これには、分散型識別子(DID)と検証可能な資格情報(VC)を活用する。

        このフレームワークには以下の要素が含まれる。

        ・Agent Naming Service(ANS):
        エージェントの安全かつ能力認識に基づく発見(ディスカバリ)を可能にする命名サービス。
        ・動的かつきめ細かなアクセス制御メカニズム:
        属性ベースアクセス制御(ABAC)、ポリシーベースアクセス制御(PBAC)、ジャストインタイム(JIT)アクセスなどを活用する。
        ・統合されたグローバルセッション管理とポリシー強制レイヤー:
        リアルタイム制御と一貫したアクセス権の取り消しを、異種のエージェント通信プロトコル間で実現する。

        さらに、ゼロ知識証明(ZKP)を活用することにより、プライバシーを保護しながら属性情報を開示し、ポリシー準拠を検証可能にする方法についても検討するとしている。

        CSAは、この新しいIAMパラダイムのアーキテクチャ、運用ライフサイクル、革新的な貢献点、セキュリティ上の考慮事項を概説し、エージェンティックAIとその複雑なエコシステムに必要な信頼性・説明責任・セキュリティの基盤構築を目指すとしている。

        このようにみていくと、シンガポールは、エージェンティックAIの社会実装に向けたガバナンスとセキュリティの両面で世界をリードしている。シンガポールサイバーセキュリティ庁のAIセキュリティガイドラインとシンガポール情報通信メディア開発庁のエージェンティックAI向けフレームワークは、相互補完的に機能し、信頼性あるAI活用の基盤構築に寄与している。その中で、クラウドセキュリティアライアンスのクラウドセキュリティおよびAIセキュリティ関連文書も有効活用されている。

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

        ISMSを基盤としたゼロトラストの展開

        CSAジャパン ゼロトラストWG 諸角昌宏

        ゼロトラストに取り組んでいる組織が増えている中、ゼロトラストの戦略を曖昧にしたままセキュリティ製品の導入に走っているケースが見受けられる。ゼロトラストは、今までのセキュリティの考え方、特にリスク管理の延長線上にある考え方である。すべてのアクセスを検証する、最小権限の原則、継続的な監視とログ分析など、今までのどちらかというと静的なセキュリティ対策に対して、動的なセキュリティ対策にしていくことにより、現在のITシステムの環境に適合させていこうというものである。したがって、ゼロトラストの考え方や戦略を正しく理解し、自組織に適用していくことが求められる。

        本ブログのベースになっている「ISMSを基盤としたゼロトラストの展開」資料では、ゼロトラストの考え方を理解するために3つのゼロトラスト導入戦略(NIST SP800-207、CISA成熟度モデル、NSTACモデル)を説明し、ゼロトラストの考え方や戦略の理解を深めたうえで、ISMSフレームワークにゼロトラストを採用する方法について考察している。したがって、ゼロトラストの戦略についてはそちらの資料を参照していただくこととし、本ブログではISMSフレームワークにゼロトラストを採用する方法についての考察を説明する。

        なぜISMSフレームワークにゼロトラストを採用する方法を考えたか?

        まず、ISMSフレームワークにゼロトラストを採用する方法を考察した理由について説明する。

        ゼロトラストは、セキュリティ対策としては適切なものであるが、リスク管理として重要である情報資産の重要性について言及されていない。特定非営利活動法人デジタル・フォレンジック研究会のコラム第896号:「ゼロトラストアプローチとリスク論的アプローチ」(https://digitalforensic.jp/2025/10/20/column896/)において佐々木良一 理事(東京電機大学 名誉教授 兼同大学サイバーセキュリティ研究所 客員教授)が以下のように述べている。「ゼロトラストの考え方自体は適切なものであるが、同時にリスクアセスメントを中心とするリスク論的アプローチも併用しないと適切な対策にならない」。リスクについて、上記コラムでは「リスク=損害の大きさ×損害の発生確率」という工学分野の確率論的リスク評価の定義を使っている。情報セキュリティにおいてリスクは、「リスク=影響度x発生確率」と表現されるが、概念的には同じであり、ここでは影響の方が損害より広い概念として捉え、「損害の大きさ=影響度」と捉えることとする。ここで、ゼロトラストは、「損害の発生確率」と結び付けることができるが、「損害の大きさ」(対象システムの重要性)についてはカバーされていない。したがって、ゼロトラストにおいてリスク論的アプローチを併用することが重要であるということになる。 そこで、「ISMSを基盤としたゼロトラストの展開」資料では、リスク管理プロセスにゼロトラストを統合させることでこれを実現することを考察した。さらに、リスク管理プロセス(ISO 31000 / ISO 27005)にゼロトラストを統合させるという概念的な話よりは、リスク管理プロセスを中核に据えているISMS(ISO/IEC27001)のプロセスにゼロトラストを統合することで、より実際に利用できる方法となると考えた。ISMSは、日本では約60%の組織が認証を取得しているように広く普及しており、このフレームワークにゼロトラストを統合させることが有効であると考えた。なお、リスク管理プロセスにゼロトラストを統合させるには、NISTのサイバーセキュリティフレームワーク(CSF)などをベースにすることも考えられるので、ISMSに限定する話ではないことは述べておく。

        ISMSフレームワークにゼロトラストを統合させる方法

        ISMSを基盤としたゼロトラストの展開」資料では、以下の仮想のインターネットオーダーシステムを用いて、これに必要となるISMSのプロセスとそれに統合するゼロトラストについて説明している(本ブログの図は、すべてこの資料より引用している)。詳細については、そちらの資料を参照していただくとして、ここではそのポイントとなる以下の点について説明する。

        1. 資産特定の考え方
        2. リスクアセスメントにおけるリスクスコアの考え方
        3. 適用宣言書の考え方
        4. モニタリングおよびレビューの考え方

        1. 資産特定の考え方
        資産特定として、ゼロトラストで説明されているプロテクトサーフェスを用いた。プロテクトサーフェスは、ビジネス情報システムとして資産の集まりとして管理する方法で、理解しやすく、関連する一連のトランザクションフロー、アーキテクチャ要素、アクセスポリシーの作成が容易となる。したがって、プロテクトサーフェスごとに管理することで、従来の資産ごとに比べて管理しやすいことになる。また、ゼロトラストの段階的な導入をこのプロテクトサーフェスごとに行うことができるため、既存の資産はISMSで管理しながら、定義できたプロテクトサーフェスから順次ゼロトラスト化していくことが可能になる。もちろん、対象となる資産を従来ISMSで用いたものをそのまま扱うことも可能であるが、プロテクトサーフェスとして管理することの方がメリットがあると考えている。
        以下が、オンラインオーダーシステムを想定したプロテクトサーフェスの例である。

        2. リスクアセスメントにおけるリスクスコアの考え方
        リスクスコアとして、CISAのゼロトラスト成熟度モデルの成熟度を使用し、以下の観点でリスクスコアを計算する。

        • 影響度:資産の重要性に基づいてプロテクトサーフェスの重要度を評価

        • 発生確率:ゼロトラスト成熟度で評価

        ここで、発生確率として成熟度を使用する理由であるが、CISA成熟度モデル(従来 → 初歩 → 高度 → 最適)を「セキュリティコントロールの強度」とみなし、成熟度が上がるほど発生確率が低下するとして評価に利用することができると考える。また、成熟度の向上に応じてリスクスコアがどう下がるかを定量的に評価することが可能になると考える。

        以下が、オンラインオーダーシステムを想定したリスクスコアの例である。なお、発生確率は同じレベルにおいても振れ幅を考慮して数値化している。なお、ここではプロテクトサーフェス単位でリスクスコア化しているが、プロテクトサーフェスに含まれるトランザクションフロー単位、あるいは、プロテクトサーフェスに含まれるそれぞれの柱単位にリスクスコアすることも可能である。

          3. 適用宣言書の考え方
          ISMSでは管理策に基づいた適用宣言書が必須となる。ここは、ISO/IEC27001の管理策に対してプロテクトサーフェスとしてどのような管理になるかを記述し作成することができると考える。
          以下が、オンラインオーダーシステムを想定した適用宣言書の例の一部である。

          4. モニタリングおよびレビューの考え方
          ここでは、ゼロトラストの特徴であるリアルタイム性を持たせたリアルタイム/継続的なモニタリングと自動化による改善を行うことを考える。ログ、テレメトリ、ユーザー行動分析(UEBA)などを用いて、リアルタイムにアクセスを監視し、継続的評価とポリシーの調整を繰り返すことで、ゼロトラストの成熟度を高めるように進める。これにより、ISMSを動的かつ継続的に補完することができるものと考える。
          以下が、オンラインオーダーシステムを想定したモニタリングおよび改善の例である。

          まとめ:ISMSフレームワークにゼロトラストを統合させるメリット

          ここで述べた方法によるメリットをまとめると以下の3点になる。

          1. ゼロトラスト化においてリスク論的アプローチを併用することを実現できる。
          2. ISMSの延長線上にゼロトラストを統合させていくことで、ゼロトラストを1から始めることによる労力、投資を抑えることができる。
          3. リモートワークの普及、クラウドサービスの普及拡大など、ゼロトラストの導入は組織の喫緊の課題であり、ISMSフレームワークをベースとすることでスムーズな移行およびスモールスタートが可能である。既存のISMSはそのまま維持・継続しながら、プロテクトサーフェスごとにできるところからやり、ステップアップしていくという方法が取れる。

          このような点から、ISMSという既存のフレームワークを利用することで、ゼロトラストへの効果的な移行が可能になると考えられる。今後は、これを実際にユースケース化していくことを考えていきたい。

          以上

          クラウドファースト時代における特権アクセス管理解説

          CSAジャパン 諸角 昌宏

          特権的なアクセス権限は、ユーザーに異なる役割が割り当てられるあらゆる環境でセキュアに管理する必要がある。適切なコントロールが講じられていない場合に、組織は内部での不正利用や外部からの脅威に曝される。このような状況において、PAM(特権アクセス管理、Privileged access management)の重要性が高まっている。
          本ブログでは、PAMの現在の位置づけを整理した上で、CSA本部がクラウドファースト時代における特権アクセス管理、Managing Privileged Access In a Cloud-First World」として公開した資料に基づいて、クラウドファースト環境における特権アクセス管理のベストプラクティスについて解説する。

          PAMとは?

          まず、PAMの定義を明確にしたい。PAMというと、どうしても製品のイメージが強い。また、PAMの日本語訳である「特権アクセス管理」という言葉から考えられるのは、管理者が使用する特権アカウントをいかにセキュアにするか、つまり、特権を付与されているアイデンティティとアクセス管理を行う製品というイメージになる。しかしながら、WikipediaでPAMを検索すると、「Privileged access management(略称:PAM、別名:特権アクセス管理)は、組織内の特権アカウントの制御、監視、保護に焦点を当てたサイバーセキュリティ上重要なアイデンティティ管理である」としている。ここで「アイデンティティ管理」という部分については上記の特権アカウントの管理ということになるが、「組織内の特権アカウントの制御、監視、保護に焦点」を当てるという部分があり、単なる認証/認可だけではなく特権アクセスのセキュリティ統制を含んでいるといえる。そうすると、PAMを製品として捉えるのではなく、特権アクセスを付与・利用・監視・記録・不要になった場合の無効化を総合的に行うための統制モデルと考える必要がある。

          また、Gartnerは、PAMが必要な機能としてJust-In-Time(JIT)や Zero Standing Privileges(ZSP)という用語を使っており、特権というのは常設されるべきでなく、必要な瞬間に付与し必要無くなったら直ちに削除するということを要件としている。

          また、PAMと関連する用語としてIAM 、IGA、CIEMがあるが、これらとPAMとの違いは、IAM 、IGA、CIEMが「誰にどの権限を持たせるか」を管理するのに対して、PAMは「その権限をいつ、どのように使わせるか」を管理すると考える必要がある。 以上のことから考えて、PAMは、特権アクセスに対して、最小特権、時間制限、制御および監視を適用するセキュリティ統制であると考えるのが妥当である。その上で、PAM製品はその概念を技術的に実装する手段という位置づけになる。

          PAMの背景

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

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

          このように、特権アカウントあるいは特権を持っていることがデータ侵害に大きく影響していることがわかる。では、特権というものが厳密に管理されていればデータ侵害は起こらないのだろうか?理論的には以下の4つの前提がすべて満たされれば外部攻撃によるデータ侵害は極めて成立しにくいと言える(ここでは、外部からのデータ侵害に絞って考える)。

          • アカウント侵害ができない
          • 権限昇格が不可能である
          • 過剰権限が存在しない
          • 認可・設計・設定・運用が正しい

          しかしながら、現実のシステムではこの前提がほぼ崩れることになる。その理由は、設計・運用が「常に」維持できるものではなく、システム・人間・環境が「時間とともに変化する」からだということができる。変化により「正しかった設計」が「不正確」になってしまう。緊急対応での一時設定、トラブル回避の例外措置、手作業の微調整などにより、設定が意図せずドリフトする。業務優先のショートカット、「今回はいいだろう」という対応、引き継ぎ漏れ・理解不足などにより人間は必ず逸脱を引き起こしてしまう。また、使われていないアカウント、放置されたAPIキー、シャドーアカウントなどにより、存在を認識していないものは管理できないという可視性の問題も起こる。 このような設計・運用が「常に」維持できないという問題は、監査で確認することが求められているが、それをさらに確実にしていくには、自動化と継続的なモニタリングが必要であり、特権アカウントや特権アクセスが慎重に管理され、状況が認識されることが必要になる。これを支援するのがPAMの役割と考える。また、最小特権および時間制限という観点から、PAMは、ユーザーに業務に必要な最小限のアクセス権のみを、必要な期間のみ与えるための機能を提供することが必要になる。

          効果的なPAMによるコントロール

          PAMによるコントロールとして以下の点が必要となる。

          • 最小特権(Least Privilege)
            最小特権の原則をデフォルトで強制する。人/非人間の双方に、必要な権限のみを付与し、それ以上の権限は付与すべきではない。
          • 必要な期間のみ(Just In Time、JIT)
            特権は恒常的に付与せず、永続的な特権アカウントからジャストインタイム(JIT)や時間制限付きアクセスモードへ移行する。
          • ポリシー駆動(Policy-based Control)
            特権アクセスは事前定義されたポリシーに基づいて制御する。裁量ではなく、ポリシーに基づいて制御する。
          • 自動化(Automation)
            特権の付与・剥奪・管理プロセスは自動化する。未使用または期限切れのアカウントには自動失効機能を適用する。
          • 継続的モニタリング(Continuous Monitoring)
            特権アクセスの利用状況は継続的に監視・記録する。継続的にモニタリングし、新たに作成された特権アカウント、役割の変更、または予期せぬ特権の昇格を検出する。

          「特権は恒常的に付与しない」は可能か?

          ここでは、「クラウドファースト時代における特権アクセス管理」には記述されていないが、PAMによるコントロールを整理する中で気になった点として「特権は恒常的に付与しない」ということが可能なのかという点について考察してみる。
          特権を恒常的に付与しないことは、攻撃に可能な時間と影響範囲を最小化できるため重要である。恒常的な特権付与は、アカウント侵害時に即座に高権限を悪用されるリスクを内包するため、攻撃可能時間が無限になり、また特権取得を明確な監査イベントとして管理することができない。半面、特権を恒常的に付与せずJITとした場合、セキュリティが向上する代わりに、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時の障害対応において時間がかかってしまう(JITの承認者がすぐに対応できないなど)ことになる。

          PAM運用においては、特権付与の承認レベルに応じて以下のようなモデルが一般的に用いられる。

          • 事前承認JIT
            これは、特権の付与にあたって承認が必要となる。流れとしては、申請→承認→JIT付与→作業→自動失効となる。この場合、特権が必要な場合には常に事前承認が必要となるため、統制の観点では最強となる。したがって、高リスクの作業を必要とする場合に適している。ただし、緊急性が求められる場合には対応できないことが発生する可能性がある。
          • 無承認JIT(自己承認/ポリシー自動)
            これは、承認者が存在しない、別の言い方をすると自己承認JITというものである。流れとしては、本人要求→ポリシー判定→即JIT→作業→自動失効となる。この場合、承認者は存在しない。ガバナンスの観点では弱くなるが、ログが生成されるので監視・監査は可能である。したがって、これは低~中のリスクの作業に対して日常運用で用いることが考えられる。
          • 事後承認(先に付与、後でレビュー)
            これは、まず特権を付与し、使用した後でレビューする方式となる。流れとしては、JIT即時付与→作業→自動失効→後日レビュー(理由・操作内容)となる。承認なしで作業が行われるため、緊急対応や夜間対応の時に用いることが考えられる。

          これらの機能をうまく運用することで、セキュリティの向上、緊急時の障害対応などを「特権を恒常的に付与しない」形で実現できる。ただし、運用方針をしっかり定めておくことが重要となる。

          さて、上記の機能を使って「特権を恒常的に付与しない」運用をPAMを使って実現できるのであるが、常時特権を持ったアカウント(root等)は必要ないということにはならない。それは、非常事態として、PAMも認証基盤も壊れてしまった場合に最後に「必ず入れる道」を残す必要があるからである。いわゆる「Break-glass」である(注:Break-glassという考え方自体は「クラウドファースト時代における特権アクセス管理」に直接記載されているものではなく、実運用上一般的に用いられている設計パターンとして用いている)。認証基盤、PAM、管理プレーンなどが壊れた場合や緊急対応を必要とする重大インシデントへの対応などではどうしても「最後の管理者」が必要となる。そうすると、基本はPAMを使った「特権を恒常的に付与しない」運用を行い、緊急のためにBreak-glassで対応するという運用が必要となる。しかし、Break-glassを前提すべきではなく、あくまで基本はPAMを使った「特権を恒常的に付与しない」運用にすべきである。つまり、Break-glass は「存在させるが、通常は使わない」前提で設計する必要がある。

          もう一つ、特権というか権限を常時付与することが求められることとして、部門/業務等で日常的に必要な権限の付与がある。これには、業務で必要となる権限、機械的に付与される権限などがあり、「必要な時だけ権限を付与」ということがそもそも成り立たない。しかしながら、この部門/業務等で常時付与される権限は、侵害の起点となることが多く、権限昇格やラテラルムーブメントを引き起こすことにもなりうる。これを考えると、PAMは「全体の権限を統合管理する基盤」ではなく、あくまで管理者権限、IAMの高権限ロールを対象にしていて、情報システムそのものを破壊できるような高権限を管理することを目的とし、部門/業務等で日常的に必要な権限はIAM/IGAの範囲と考えるのが妥当である。まとめると、PAMは「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる。

          クラウドファースト環境における特権アクセス管理のベストプラクティス10選

          クラウドファースト時代における特権アクセス管理」では、クラウド環境における特権アクセス管理のベストプラクティスとして以下の10項目を挙げている。ここでは、その概要を説明する。

          1. ジャストインタイムアクセス(JIT)およびジャストイナフアクセス(JEA)を活用し、常時付与された特権を排除する
            • 永続的な管理者権限を廃止し、「必要な作業に必要な期間だけ最小権限」を動的に付与してアタックサーフェスを削減する。
            • 攻撃者は「常時存在する管理者権限」を狙うことが多いため、これを排除することで侵害リスクが大きく減少する。
          2. 自動化による特権アクセスの検出とインベントリ
            • シャドーアカウントを含むすべての特権アカウントを自動発見・棚卸しし、見えない特権(シャドー特権)を可視化し排除する。
            • クラウドでは「誰も把握していない管理権限」が必ず増えるため、これを可視化し排除することが重要である。
          3. きめ細かなアクセス制御と役割分担の導入
            • RBAC/PBACにより職務の分離と最小特権を徹底し、単一アカウントへの過剰集中を防止する。
            • 「管理者」という大雑把な権限をやめ、職務単位で分解し権限付与する。これにより、1アカウントを侵害することで全ての権限を持ってしまうという構造を壊すことができる。
          4. 権限付与、使用状況、および特権アクセス管理の行動パターンを分析する
            • 特権の使われ方を継続的に分析し、異常行動・過剰権限・リスク傾向を早期検知する。
            • 単にログを取るだけでなく、普段と違う操作、異常な時間帯、権限の使われ方の変化などを行動として分析する。クラウドでは、特に正規アカウントを使った侵害が起こるため、正規アカウントによる異常操作を見つける必要がある。
          5. 包括的な特権セッションのモニタリングおよび監査の有効化
            • すべての特権操作を記録・可視化し、フォレンジック・説明責任・規制対応を可能にする。
            • インシデント後に、誰が何をしたかを説明できるようにし、統制や復旧をスムーズに行えるようにする。
          6. すべての重要な資産とアイデンティティにPAMを拡張する
            • サーバーだけでなく、SaaS、業務アプリ、クラウド管理プレーンまでPAM対象に含める。
            • PAMの対象をSaaS管理プレーン、業務アプリ、クラウド管理APIまで広げることで、SaaSや業務アプリ側の侵害を防ぐ。
          7. 非人間アイデンティティとワークロードアクセスをセキュアにする
            • サービスアカウント、API、ボット、AIエージェントにもJIT・最小特権・監査を適用する。
            • 人ではなく、サービスアカウントやAIエージェントにも適用することでセキュアにする。
          8. セキュアなリモートおよびサードパーティアクセス
            • ベンダーや外部委託先のアクセスも一時的・監査可能を前提として制御する。
            • ベンダーや委託先に対しても、永続IDを渡さず時間限定や操作記録付きでアクセスさせるようにすることでセキュアにする。
          9. PAMをDevOps、CI/CDのInfrastructure-as-Code(IaC)ワークフローに統合する
            • PAMをDevOps、CI/CDのInfrastructure-as-Code(IaC)ワークフローに統合し、コード経由の特権漏洩や設定ミスを防止する。
            • CI/CD、Terraform などの中の特権もPAM管理下に置くことで、コード内シークレットの問題を解決する。
          10. 強固なガバナンスとコンプライアンスの確立
            • PAMログと統制をSOX/PCI DSS/NIST等の証跡として活用し、監査対応を自動化する。
            • PAMログを、そのまま監査証跡、規制対応、経営報告に使えるようにする。これにより、PAMを経営統制のインフラとする。

          まとめ

          本ブログでは、PAMの定義、PAMの守備範囲について説明した。また、現代のデータ侵害の起点となる特権の扱いとして、「「特権は恒常的に付与しない」は可能か」という点について、PAMの機能を中心に考察した。さらに、クラウドファースト環境における特権アクセス管理のベストプラクティスについてその概要を説明した。

          PAMは今後、必須の機能となるが、「全体の権限を統合管理する基盤」ではなく「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる点は理解しておく必要がある。

          以上

          SaaS 環境でよくあるセキュリティリスクと対策

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

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

          2026年01月20日 18:30-20:00 開催

          問題点の概要

          BetterCloud社が公開した「Common SaaS security risks, horrifying recent breaches, and mitigation tips」において、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例、そしてそれらへの対策について解説している。第3回SaaSセキュリティリーグでは、ここで述べられている7つのセキュリティリスクについて、実際にSaaSのセキュリティ管理を行っている立場からディスカッションした。また、主なSaaSセキュリティリスクを軽減する方法(資料内の FAQ)の有効性についてディスカッションした。

          SaaS 環境でよくあるセキュリティリスク

          BetterCloud社が公開した資料で挙げられている7つのセキュリティリスクは以下である。

          1. 設定ミス(Misconfigurations)
            • 誤った設定により脆弱点が露出。
            • 例:認証不要のページに内部データが公開された Salesforce サイト。設定ミスが侵害につながった典型例。
          2. オフボーディングの遅延(Delayed offboarding)
            • 退職者アカウントが削除されずに残ると、データへの不正アクセスや情報窃取につながる危険性。
            • 例: Cash Appでの退職者によるデータ抜き出し事件を紹介。
          3. 管理者権限の過剰付与(Excessive admin privileges)
            • 権限の過剰なユーザーがいると、侵害時の被害拡大リスクが高まる
            • 例:Verkada の内部カメラ映像が暴露された事件。
          4. 認証情報の漏洩(Compromised credentials)
            • フィッシングや盗難によるアカウント侵害が依然として主要なリスク。
            • 例:Okta 社のサポートチケット情報にアクセスされた事例。
          5. 過剰なアプリ権限(Overly permissive app data access)
            • サードパーティアプリに対して不要なデータアクセスを許可してしまうと、意図せぬ情報漏洩につながる。
            • 例: OneDriveで、アプリ連携(OAuth権限/スコープ)により過剰なデータアクセスが起こり得るリスクが指摘されているケース。
          6. 不十分な第三者統合(Insecure third-party integrations)
            • 連携サービス側の脆弱性が本体システムへ影響を与える可能性。
            • 例:Okta 侵害 → Cloudflare の Atlassian への不正アクセスに波及。
          7. 不適切なファイル共有(Improper file sharing practices)
            • 誰でもアクセス可能な公開リンクなどにより、機密データが漏洩する危険性。
            • 例:日本のゲーム会社 Ateam が Google Drive の公開リンクを誤設定し、長期間データ公開状態となった事件。

          セキュリティリスクに対するディスカッション

          上記SaaS 環境でよくあるセキュリティリスクについて、実際にどのように問題点として捉えているか、既に解決済みなのか、あるいは、どのような検討が行われているかについてディスカッションを行った。

          1. 設定ミス(Misconfigurations)
            組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。
            組織全体で利用するSaaSの場合は、情報システム部門が直接対応しているので対策が取れている。部門等で利用するSaaSの場合は、情報システム部門が助言はするが直接対応はしていない。部門と委託先(SaaSの調達・管理を委託)が協力して対応できているところはできているが、部門が独自にやっている場合は難しい。情報システム部門としてチェックをしているが、数が多いため難しい場合がある。したがって、基本的な運用としては、監査において定期的なチェックを行うこととしている。
          2. オフボーディングの遅延(Delayed offboarding)
            退職者アカウントについては管理できている。作業漏れの対策として、棚卸を定期的に実施している。部門で管理しているSaaSアカウントは、手動で管理するのは限界であり、人事システムとの連携が行えるようにIGA(Identity Governance and Administration)を利用することを検討している。人事システムとの連携ができるIGAは有効なツールになると考えている。その上で棚卸を実施し、定期的にチェックする。
          3. 管理者権限の過剰付与(Excessive admin privileges)
            過剰権限、過剰設定を確認するチェックシートを作って管理している。チェックシートの中で最小権限等の指示を行っている。管理者権限の付与に対する対応は、どうしてもアナログにならざるを得ない。というのは、誰に対してどのような権限を付与するかについてはシステムオーナーしか分からないため、どうしても個別の対応になってしまう。したがって、情報システム部門としては、過剰権限になっていないかどうかのチェックを行うことで対応している。
            SSPMが過剰な権限を指摘してくれるので、SSPMを利用して管理を行うのは有効であるが、以前から指摘されているSSPMのコストの問題がある。
            管理者権限等の特権の管理としてPAM(Privileged Access Management)があり、これを利用することも考えられるが、現状はIaaSで一部利用している程度でSaaSでは利用していない。
          4. 認証情報の漏洩(Compromised credentials)
            この問題も、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。組織全体で利用するSaaSでは、情報システム部門が管理しているため、条件付きアクセスの設定を付けることでアカウント侵害を防いでいる。しかしながら、部門等で利用するSaaSでは、どこまで徹底できているかは不明な部分がある。
            認証情報については、アクセス元のチェック、端末認証等を導入して対応している。これにより、モニタリングができているので、もしアカウントの漏洩が発生すれば、情報システム部門から注意するという運用ができている。
          5. 過剰なアプリ権限(Overly permissive app data access)
            API連携の申請が来るケースがあり、情報システム部門でチェックしている。サードパーティアプリから不要なデータアクセスをされるケースには、APIアクセスキーのローテーションで対応している。最近課題として出てきているのは、Microsoft graphAPIに対する連携の依頼が多くなっていることである。組織全体にアクセスできる権利を要求されることがあり、他の部門のデータも見られてしまう可能性があり注意が必要である。
            以前(第1回SaaSセキュリティリーグ)指摘されたが、AIが社内の見えないところを見てしまう、つまり、AIが社内の機密データを見つけて公開してしまう問題がある。自律型AIの権限をどうするのかは今後課題となる。
          6. 不十分な第三者統合(Insecure third-party integrations)
            上記5で検討した内容と同様。
          7. 不適切なファイル共有(Improper file sharing practices)
            ファイル共有については、ルール化をどう定義するかが難しいポイントである。Microsoft 365では、外部DLP製品に頼らず、自社クラウドの標準機能として DLP を公式に提供している。このDLP機能を使ってクラウドストレージサービスの共有問題に対応している。Google Driveについては、ダウンロードはOKにしているが、アップロードはNGとする対応を取っている。これは、CASB/SGWでコントロールしている。また、クラウドストレージに外部公開する場合には申請が必要で、申請があれば特定領域を共有できるようにするという運用でカバーしている。

          主なSaaSセキュリティリスクを軽減する方法

          以下の12個が、BetterCloud社が公開した資料でSaaSセキュリティリスクを軽減する方法の概要をFAQとして記述したものである。

          1. Q1. SaaS ベンダーのセキュリティリスク評価はどのように行うべきか?
            SaaS ベンダー評価では、次の点を確認する必要がある:
            • SaaS プラットフォームの運用するデータセンターやインフラのセキュリティ体制データ暗号化(保存時/移動時)の仕組みアクセス制御(認証・認可)の方式実施済みのセキュリティ監査や認証(たとえばSOC 2など)
            • サードパーティ連携や API のセキュリティ設計・権限付与の仕組み
              これらの評価を自動化ツールで継続的にチェックすると、ベンダー変更や構成変化にも適応しやすくなる。
          2. Q2. 多要素認証(MFA)をどのように強制するか?
            • できる限りすべてのユーザーに MFA を必須化する
            • MFA未設定のユーザーにはログインを拒否するルールを設ける
            • 権限レビューを定期的に実施し、認証強度を維持する
          3. Q3. 従業員向けにはどんなセキュリティ教育をすべきか?
            • 最新のフィッシング手法の理解
              → フィッシング攻撃による認証情報漏洩防止
            • ファイル共有の責任ある利用法
              → 過度に公開リンクを作らない/意図しない共有範囲を避ける
          4. Q4. SaaS 全体のセキュリティを常に把握する方法?
            「可視性の欠如」がSaaSリスクの根底にある。自動化された可視化/監視ツールの導入が有効。これによって次が可能になる:
            • 新規・非承認アプリの検出(シャドーIT)
            • ユーザーアクセスログとファイル共有状況の自動監視
            • 外部共有や不正アクセスのリアルタイムアラート
          5. Q5. 「Super Admin(管理者権限)」の数を制限する方法?
            • セキュリティポリシーとしてアプリ毎に許容する最大Super Admin数を定め、しきい値を超えたらアラートを出す仕組みを設定
            • 単純な管理者数の制御だけでなく、不適切な権限拡大を未然に検知する
          6. Q6. ユーザーのオフボーディング(退職時処理)はどう自動化するか?
            • SaaS 管理プラットフォームでは、退職者やロールチェンジの際にアカウントを自動無効化・権限削除するワークフローを設定可能。
            • これにより「幽霊アカウント」問題や放置されたアクセス権限のリスクを抑制できる。
          7. Q7. 定期的なコンテンツスキャンをどのように実行するか?
            ファイルやデータをスキャンして以下を特定する:
            • 機密データ(PII、顧客情報、知的財産など)の所在
            • 過剰な共有設定ファイル
            • 不適切なアクセス権限が付与されたファイル
              これも自動化ツールが必要で、人手ベースでは難しい。
          8. Q8. どのようなファイル共有モニタリングが必要か?
            • 外部共有の過剰検出
            • 許可範囲の過度な広さ(過剰権限)
            • 非アクティブ共有の把握と削除
              これらのモニタリングにより、ファイル共有に起因する漏洩リスクを削減可能。
          9. Q9. ファイル共有方針を強制する方法?
            • 教育に加え、自動化された定期的なファイル権限のクリーニングやポリシー例外を検出する仕組みを運用することで、方針遵守を強制する。
          10. Q10. SaaS セキュリティポスチャを高める最良の方法?
            • 強力なSSPM機能を持つ管理プラットフォームを使い、継続的な可視化、監査、ポリシー施行、自動リメディエーションを実施する。
          11. Q11. インシデント発生時の即時対応(IR)計画はなぜ重要か?
            • 侵害疑いを検知したら、影響範囲の隔離、パスワード変更、侵害アカウントの停止、ファイル共有のブロックなどを迅速に行うIR計画が必要である。
            • これはインシデントの被害拡大を防ぐうえで極めて重要である。
          12. Q12. ルート原因分析(Root-Cause Analysis)はいつ行うべきか?
            侵害の封じ込め後に実施。分析の対象は以下:
            • 初期侵入経路
            • 誤設定や脆弱性
            • データ抽出・ラテラルムーブメントのプロセス
            • 影響した他 SaaS との関連
              これらにより恒久的な改善策が設計できる。

          主なSaaSセキュリティリスクを軽減する方法に関するディスカッション

          上記の12個の対策に対して、ディスカッションした内容を以下に記述する。

          1. MFAの強制について
            機密情報等を扱うSaaSについては、MFAは必須である。また、SSOへの対応も有効であり、SAMLで管理を行っている。これは、部門等で利用するSaaSで機密情報を扱う場合においても強制している。
            また、MFAができない場合には、グローバルIP等で制限を掛けることでSaaSへのアクセスを制限している。グローバルIPによる制限は、完全ではないが、想定外の国やネットワークからの直接アクセスが防げるということで有効である。
            また、業務に合わせて端末レベルでの制御も行っている。
          2. 従業員向けのセキュリティ教育
            従業員教育は必ず実施しているが、きちんと理解されているかどうかは疑問なところもある。今後の対策として、教育を超えてシステム的な対策が必要であると考える。例として、一般的な内容ではなく、自分が直面するような問題・危機感を持たせるような(シナリオ的)教育を進めることが有効である。
            また、日常的な観点に基づいてコンテンツ化することも有効である。
          3. SaaS セキュリティポスチャを高める方法
            これには、SSPMが有効であるが、実際にはコストの観点から広め切れていない。セキュリティの可視化ができないとリスクが分からないので、うまくSSPMを使う方法を考えていきたいし、ベンダー側の対応も期待したい。
          4. インシデント対応
            SaaSのインシデントレスポンスでは、インシデントの検知の報告が、SaaS側ではなく利用者側からの報告ベースになることが多い。あるいは、代理店が検知して対応してくれるケースがある。これは、SaaS側からのインシデントの報告が十分でないことを意味しており、特に部門で利用するSaaSの場合この傾向が顕著である。

          まとめ

          今回は、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例とそれらへの対策について、BetterCloud社が公開した資料をベースにディスカッションを行った。「あるある」的な内容ではあるが、実際にディスカッションしてみて以下の点が明確になった。

          1. あらためて、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。情報システム部門が直接対応しきれない部門等で利用するSaaSへの対応をチェックリストや監査を通してうまく進めていくことが求められる。
          2. 特権アカウントおよび権限付与の扱いが、SaaS利用においても重要になっている。これは、人手による対応では厳しい状況となっており、IGAやPAM等を効果的に使っていくことが求められる。
          3. API連携の問題がクローズアップされてきている。これは、自組織側の管理だけではなく、連携元の管理にも依存してくるため、どのように連携して対応していくかを検討する必要がある。
          4. SaaSのインシデント対応が重要になる。インシデントの報告がSaaS側からきちんと行われないと、利用者側で対応することができない。しかしながら、現状は、SaaS側からの報告があまり行われていないようである。利用者とSaaS側とのより良い連携が求められている。
          5. いつも話題となるが、SSPMのカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

          以上

          開発者向けクラウドネイティブセキュリティの基礎(ワークロードセキュリティ編)(2)

          前回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみたが、今回は、AIの普及とともに急増する人間以外のアイデンティティ(NHI:Non-Human Identity)に焦点を当てる。

          ノンヒューマン・アイデンティティ(NHI)とAIワークロードの関係

          クラウドセキュリティアライアンス(CSA)のブログ記事「ノンヒューマン・アイデンティティ管理」(関連情報(https://cloudsecurityalliance.org/blog/2024/07/15/non-human-identity-management))によると、ノンヒューマン・アイデンティティ(NHI)とは、現代の企業システムにおいて、マシン同士や人とマシンとの間のアクセスおよび認証を安全に行うためのデジタル・ゲートキーパーとして機能するものである。イノベーションの推進により、マイクロサービス、サードパーティ製ソリューション、クラウドベースのプラットフォームの導入が進み、相互に接続されたシステムの複雑なネットワークが形成されているという背景がある。

          そしてノンヒューマン・アイデンティティ管理(NHIM)とは、非人間の識別情報のライフサイクル全体を統制・自動化するプロセスであり、以下のような項目が含まれるとしている。

          ・発見と分類
          ・プロビジョニング(識別情報の作成と割り当て)
          ・所有者の割り当て
          ・状態の監視と異常検知
          ・保管庫への格納と安全な保存
          ・資格情報のローテーション(定期的な更新)
          ・コンプライアンス対応
          ・廃止(使用終了時の適切な処理)

          他方、AIワークロードとは、機械学習モデルのトレーニング、推論、データ処理、API連携など、AIが関与する一連の処理やタスクのことを指す。AIワークロードはクラウドやオンプレミス環境で自動的に実行されることが多く、人間の介在なしに動くのが特徴となっている。

          AIワークロードは、以下のような人間以外のエンティティによって構成されていることが多い:

          ・AIモデル自体(例:推論エンジン)
          ・スクリプトやバッチ処理
          ・APIクライアント
          ・コンテナやマイクロサービス
          ・CI/CDパイプラインの自動化ツール

          これらはすべて人間ではないが、システムにアクセスし、機密データを扱い、他のサービスと通信する存在となっている。そこで、誰が何にアクセスしているのかを明確にするためには、NHIの管理が不可欠になる。

          NHIに対するリスク認識と具体的セキュリティ対策のアンバランス

          CSAでは、ボット、APIキー、サービスアカウント、OAuthトークン、シークレットなどノンヒューマン・アイデンティティ(NHI)セキュリティで見落とされがちな側面を理解するために、2024年6月にオンライン調査を実施し、ITおよびセキュリティ専門家から818件の回答を得た。この結果を取りまとめたのが、2024年9月11日に公開された「ノンヒューマン・アイデンティティ・セキュリティの現状」である(関連情報(https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report))。

          この報告書では、以下の点について洞察を提供している。

          ・NHIとそのセキュリティリスクに関する認識
          ・現在のNHIのセキュリティ対策、ポリシー、管理
          ・サードパーティベンダーとの接続に関する課題
          ・APIキーの現在の管理とポリシー

          主な調査結果は以下の通りである。

          ・NHI攻撃の防止に高い自信を持つ組織はわずか15%で、69%が懸念を表明している。これは、リスクを認識しているものの、現在のセキュリティ対策に自信がないことを示している。
          ・主な問題点としては、サービス アカウントの管理、監査と監視、アクセスと権限の管理、NHI の検出、ポリシーの適用などが挙げられる。
          ・APIキーのオフボーディングと失効に関する正式なプロセスを設けている組織はわずか20%であった。APIキーのローテーション手順を設けている組織はさらに少ない。
          ・多くの組織は、NHI向けに特別に設計されていないセキュリティツールを混在して使用している結果、一貫性と有効性が欠如している。
          ・有望な傾向として、NHI セキュリティ機能への投資が増加している。組織の 24% が今後 6 か月以内に、36% が今後 12 か月以内に投資する予定としている。

          新たなノンヒューマン・アイデンティティ(NHI)のリスクとは?

          前述のブログでは、MITRE ATT&CK Matrix for Enterprise(関連情報(https://attack.mitre.org/matrices/enterprise/))を参照しながら、管理されていないノンヒューマン・アイデンティティ(NHI)が、以下のような攻撃者の戦術・技術に関与することがあるとしている。

          初期アクセス:攻撃者がネットワークへの侵入を試みる段階
          ・サプライチェーンの侵害(T1195)
          ・信頼された関係性の悪用(T1199)
          ・正規アカウントの悪用(T1078)
          永続化:攻撃者がアクセスを維持しようとする段階
          ・アカウント操作(T1098)
          ・アカウントの新規作成(T1136)
          ・正規アカウントの悪用(T1078)
          資格情報へのアクセス:攻撃者が権限昇格や横展開を目的に、認証情報を盗もうとする段階
          ・パスワードストアからの資格情報取得(T1555)
          ・保護されていない資格情報の取得(T1552)
          ・アプリケーションのアクセストークンの窃取(T1528)

          そして攻撃者は、以下のような脅威ベクトルを通じてノンヒューマン・アイデンティティ(NHI)を悪用し、アクセスを獲得するとしている。

          1. 放置された特権NHI(資格情報のローテーションなし):
            ・特権アクセスを持ちながらも、所有者不在や責任の所在不明、資格情報の未更新により放置されたアカウントは、攻撃者にとって格好の標的となる。
          2. 退職者に晒された未ローテーションのシークレット:
            ・退職した従業員が依然としてアクセス可能なシークレットがローテーションされずに残っている場合、特にそれがインターネット上でアクセス可能で特権を持っていると、重大なリスクとなる。
          3. 放置されたストレージアカウント
            ・長期間使用されていないストレージアカウントは、古い設定のまま放置されていることが多く、機密データが不正アクセスや漏洩の危険にさらされる可能性がある。
          4. 有効期限が50年以上のアクティブなシークレット:
            ・極端に長い有効期限を持つシークレットは、攻撃者にとって脆弱性を突くための長期間のチャンスを提供してしまい、セキュリティリスクが高まる。
          5. 未使用のアクセスポリシーを含むボールト(保管庫)
            ・使われていないアクセスポリシーが残されたボールトは、見落とされがちなセキュリティギャップとなり、意図しないアクセス権を通じて機密リソースやデータへの不正アクセスを許す可能性がある。

          AIエージェントで複雑化するノンヒューマン・アイデンティティの保護

          CSAの「AIエージェント時代におけるノンヒューマン・アイデンティティの保護」(2025年4月29日公開)では、人間1人に対して45のノンヒューマン・アイデンティティが存在しており、AIエージェントの普及によりこの数はさらに増加すると指摘している(関連情報(https://cloudsecurityalliance.org/artifacts/securing-non-human-identities-in-the-age-of-ai-agents-rsac-2025))。

          AIエージェントは、サービスアカウント、APIキー、シークレット情報のようなNHIを使ってシステムにアクセスする。これらは組織の機密データや重要なシステムにアクセスするための鍵となるため、攻撃者にとって格好の標的になる。

          しかしながら、従来のアイデンティティ・アクセス管理(IAM)は静的なアプリケーションや人間のユーザー向けに設計されており、AIエージェントのような存在には対応しきれない。AIエージェントは、自律的に意思決定を行い、タスクごとに一時的なIDを使い分けて、他のAIエージェントに権限を委譲するといった特徴を持つため、新しいIAMの枠組みが必要となる。

          CSAでは、ノンヒューマン・アイデンティティ(NHI)について、以下のようなセキュリティ課題を挙げている。

          ・NHIに関する可視性の欠如:多くの組織が、どのNHIがどこで使われているかを把握できていない
          ・アクセス権の過剰付与:最小権限の原則が徹底されていない
          ・認証情報の管理不備:APIキーやシークレットが適切に保護・ローテーションされていない

          これらに対して、以下のような対策を推奨している。

          ・NHIの発見・分類・監視の自動化
          ・エージェンティックIAMの導入
          ・ゼロトラスト原則に基づいたアクセス制御

          適切なノンヒューマン・アイデンティティ管理プラットフォームの選び方

          AIに代表される新技術の導入とともに、アイデンティティが新たなセキュリティ境界となる中で、人間のアイデンティティだけに注目していたのでは不十分な状況となっている。今や、ノンヒューマン・アイデンティティ管理(NHIM)は、アイデンティティ&アクセス管理(IAM)における大きな転換点となっている。

          非人間エンティティの特有の要件に対応するために、NHIMプラットフォームには以下の基本要件を満たすことが求められる。

          1. 包括的かつコンテキストに基づく可視性:
            ・非人間アイデンティティの全体像を把握することが不可欠である。
            ・NHIMプラットフォームは、使用状況、依存関係、エコシステム内の関係性を含む包括的な可視性を提供すべきである。
          2. ハイブリッドクラウド全体での対応力:
            ・NHIMプラットフォームは、従来のインフラの枠を超え、ハイブリッドクラウド環境全体でシームレスに動作する必要がある。
            ・AWS、Azure、Google Cloudなどの主要なIaaSだけでなく、PaaSやSaaS、オンプレミス環境もカバーすべきである。
          3. アクティブなポスチャー管理:
            ・脅威が進化する中で、リアルタイムでのセキュリティ状態の評価とリスク軽減のための能動的な対策が不可欠となる。
            ・NHIMプラットフォームは、これを可能にする機能を備えている必要がある。
          4. ライフサイクル管理と自動化:
            ・プロビジョニングから資格情報のローテーション、廃止に至るまで、NHIのライフサイクル管理は自動化されるべきである。
            ・NHIMプラットフォームは、これらのタスクを自動化し、運用効率とセキュリティの両立を実現する機能を提供すべきである。
          5. シークレット管理ツールやPAMとの連携:
            ・主要なシークレット管理ソリューションと統合できること。
            ・特権アクセス管理(PAM)ソリューションと連携し、発見されたシークレットを安全に保管・管理できることが求められる。
          6. 開発者に優しい設計:
            NHIMプラットフォームは、堅牢なAPIを備え、アプリケーションやサービスとの統合が容易であるべきである。
            ・Infrastructure as Code(IaC)ツール、ITサービス管理(ITSM)システム、ログフレームワーク、開発ツールなど、運用スタックとのシームレスな統合も重要である。

          必要なエコシステムとの統合機能や各種機能を備えた堅牢なノンヒューマン・アイデンティティ管理(NHIM)プラットフォームを導入することにより、組織は非人間アイデンティティを効果的に管理し、セキュリティ体制を強化し、自動化やシステム間連携の利点を最大限に活用することができるとしている。

           なお特権アクセス管理(PAM)に関連して、CSAでは、2025年11月24日に「クラウドファースト時代における特権アクセス管理」を公開している(関連情報(https://cloudsecurityalliance.org/artifacts/managing-privileged-access-in-a-cloud-first-world)、日本語版(https://www.cloudsecurityalliance.jp/site/?p=41892))。

          OWASP Non-Human Identities Top 10とは?

          参考までに、CSAと連携するOWASPでは、「OWASP Non-Human Identities Top 10」を公開している(関連情報(https://cloudsecurityalliance.org/blog/2025/06/30/introducing-the-owasp-nhi-top-10-standardizing-non-human-identity-security))。具体的な10項目は、以下の通りである。

          ・NHI1:2025 – 不適切なオフボーディング
          不適切なオフボーディングとは、サービスアカウントやアクセスキーなどのノンヒューマン・アイデンティティ(NHI)が不要になった際に、適切に無効化または削除されないことを指す。監視されていない、または廃止されたサービスが脆弱なまま残る可能性があり、それに関連するNHIが攻撃者に悪用され、機密性の高いシステムやデータへの不正アクセスにつながるおそれがある。
          ・NHI2:2025 – シークレット漏えい
          シークレット漏えいとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ(NHI)が、ソフトウェア開発ライフサイクル全体を通じて、許可されていないデータストアに漏えいすることを指す。たとえば、ソースコードにハードコーディングされたり、平文の設定ファイルに保存されたり、公的なチャットアプリで送信されたりすると、これらのシークレットは露出しやすくなり、悪意ある第三者に悪用されるリスクが高まる。
          ・NHI3:2025 – 脆弱なサードパーティNHI
          サードパーティのノンヒューマン・アイデンティティ(NHI)とは、統合開発環境(IDE)やその拡張機能、サードパーティのSaaSを通じて、開発ワークフローに広く統合されている。もしサードパーティの拡張機能が、セキュリティの脆弱性や悪意あるアップデートによって侵害された場合、それを悪用して認証情報を盗んだり、付与された権限を不正に使用されたりする可能性がある。
          ・NHI4:2025 – 安全でない認証
          開発者は、内部および外部(サードパーティ)のサービスをアプリケーションに頻繁に統合する。これらのサービスは、システム内のリソースにアクセスするために、認証情報を必要とする。しかし、一部の認証方式はすでに非推奨であったり、既知の攻撃に対して脆弱であったり、古いセキュリティ慣行により安全性が低いと見なされたりしている。安全でない、または時代遅れの認証メカニズムを使用すると、組織は重大なリスクにさらされる可能性がある。
          ・NHI5:2025 – 過剰な特権を与えられたNHI
          アプリケーションの開発や保守の過程で、開発者や管理者がノンヒューマン・アイデンティティ(NHI)に、その機能に必要以上の権限を付与してしまうことがある。こうした過剰な権限を持つNHIが、アプリケーションの脆弱性やマルウェア、その他のセキュリティ侵害によって侵害されると、攻撃者はその過剰な権限を悪用する可能性がある。
          ・NHI6:2025 – 安全でないクラウド展開構成
          CI/CD(継続的インテグレーションおよび継続的デプロイ)アプリケーションは、コードのビルド、テスト、そして本番環境へのデプロイを自動化するために、開発者に広く利用されている。これらの統合には、クラウドサービスとの認証が必要であり、通常は静的な認証情報やOpenID Connect(OIDC)を使用して実現される。静的な認証情報は、コードリポジトリ、ログ、設定ファイルなどを通じて、意図せず漏えいする可能性がある。もしこれらが侵害されると、攻撃者に対して永続的かつ特権的なアクセス権を与えてしまう恐れがある。一方、OIDCはより安全な選択肢であるが、IDトークンが適切に検証されていなかったり、トークンクレームに厳格な条件が設定されていなかったりすると、不正なユーザーがその弱点を突いてアクセスを得る可能性がある。
          ・NHI7:2025 – 長きにわたるシークレット
          長期間有効なシークレットとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ(NHI)が、非常に長い有効期限を持っていたり、まったく期限切れにならないように設定されていたりする状態を指す。こうしたシークレットが漏えいした場合、有効期限が長いために、攻撃者が時間の制限なく機密サービスへアクセスできてしまうリスクがある。
          ・NHI8:2025 – 環境の分離
          環境の分離とは、クラウドアプリケーションのデプロイにおける基本的なセキュリティ対策であり、開発・テスト・ステージング・本番といった環境を分けて運用することを指す。アプリケーションのデプロイプロセスやライフサイクル全体において、ノンヒューマン・アイデンティティ(NHI)が頻繁に使用される。しかし、同じNHIを複数の環境、特にテスト環境と本番環境で使い回すと、重大なセキュリティ脆弱性を招く可能性がある。
          ・NHI9:2025 – NHIの再利用
          同じノンヒューマン・アイデンティティ(NHI)を、異なるアプリケーション、サービス、またはコンポーネント間で使い回すことは、たとえそれらが一緒にデプロイされていたとしても、重大なセキュリティリスクを引き起こす。もしある領域でNHIが侵害された場合、攻撃者はその認証情報を悪用して、同じ資格情報を使用している他のシステム部分にも不正アクセスできてしまう可能性がある。
          ・NHI10:2025 – 人間におけるNHIの使用
          アプリケーションの開発や保守の過程で、開発者や管理者が本来は適切な権限を持つ人間のIDで実行すべき手作業を、ノンヒューマン・アイデンティティ(NHI)を使って行ってしまうことがある。このような運用は、NHIに過剰な権限を与える原因となり、また人間と自動化の活動が区別できなくなることで、監査や責任追跡が困難になるなど、重大なセキュリティリスクを引き起こす。

           今後、「OWASP Non-Human Identities Top 10」に関しては、CI/CDやIaC(Infrastructure as Code)、サードパーティ統合など、クラウドネイティブな開発環境におけるNHIの利用実態に即したベストプラクティスの整備が期待されている。

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