ISPMとは？できることや必要とされる理由、導入の進め方を解説

SaaSやクラウドの利用拡大により、「誰がどのシステムにアクセスできるのか」を組織全体で把握し続けることは難しくなっています。さらに、AIエージェントやサービスアカウントなどの非人間ID（NHI：Non-Human Identity）も増え、管理対象は広がっています。

ISPM（Identity Security Posture Management）は、複数のサービスやシステムにまたがるIDやアクセス権限、認証設定を継続的に可視化・評価する取り組みです。リスクを把握し、どこから見直すかを判断して、必要な是正につなげます。

ISPM（Identity Security Posture Management：IDセキュリティ態勢管理）は、IDやアクセス権限、認証設定の状態を継続的に確認し、設定の不備や過剰な権限といったリスクを評価して、是正につなげる取り組みです。

対象は、従業員や委託先が使うIDと、サービスアカウントやAPIキーなどのNHIの両方です。

ISPMの「Posture」は状態や態勢を意味します。クラウドの設定不備を点検するCSPM（Cloud Security Posture Management）などで用いられてきた態勢管理の考え方を、ID領域に適用したものです。取り組みとしてのISPMを実務で回すために、情報の収集や評価を自動化するISPMツールも各社から提供されています。

攻撃者にとって、IDは狙いやすい入口です。令和7年に検挙された不正アクセス行為のうち9割以上は、他人のIDやパスワードを使う「識別符号窃用型」でした。IPAに届け出のあった不正アクセスの被害でも、原因として最も多かったのはID・パスワード管理の不備です。

その一方で、クラウドサービスの利用拡大や業務の自動化によってID管理は複雑化しています。従来の管理方法が追いつきにくくなっていることが、ISPMが求められる背景です。

SaaSやクラウドの利用拡大によりID管理が複雑化している

利用するSaaSやクラウドサービスが増えると、それだけ管理するアカウントや権限も増えます。また、同じ従業員でも、グループウェアでは一般ユーザー、経費精算のSaaSでは承認者というように、サービスごとに異なる権限を持たせる場合、管理はより複雑になります。

IdP（認証基盤）でシングルサインオンを導入すると、ログインの入口はそろいます。ただし、ログインした後に各サービスの中で何を閲覧・操作できるかは、それぞれのサービス側の設定で決まります。

IdPと連携していないSaaSに個別に作ったアカウントや、導入時に作ったまま残っている管理者アカウントは、IdPの画面には現れません。個別の管理画面を1つずつ確認するだけでは、組織全体で「誰が、どのサービスで、どこまでできるのか」を把握しきれないのです。

人だけでなくNHIも管理する必要がある

従業員など人が使うIDに加え、NHIを利用する場面も増えています。NHIとは、システムやアプリケーションが処理を行うために利用するIDです。
自動処理用のサービスアカウントやシステムアカウント、AIエージェントなどが該当し、それらが利用するAPIキーやOAuthトークンなどの認証情報も管理対象となります。

調査によって数値に幅はありますが、Entro Labsが分析した企業環境では、2025年上半期にNHIの数が人のIDの144倍に達し、その比率は前年から5割以上伸びました。
出典：The NHI & Secrets Risk Report - H1 2025 | Entro

NHIは自律的に動くことを前提に発行されるため、権限が大きめに付与されやすい特徴があります。また、人に紐づかないため、担当者の退職や異動に合わせて見直されず、アカウントや認証情報が残ることがあります。

2025年8月には、SaaS同士の連携に使われていたOAuthの認証情報が盗まれてデータが持ち出され、世界で数百の組織に影響が及ぶ事案も起きています。

定期的な棚卸しだけではIDや権限の変化を捉えきれない

不要なIDや過剰な権限を見直すための方法として、定期的な棚卸しがありますが、確認できるのは実施した時点の状態に限られます。

例えば、四半期ごとに棚卸しをしている場合、棚卸しの翌日に作業用の管理者権限を付与し、作業後の解除を忘れると、次の棚卸しまで最長で3カ月近く権限が残り続けます。
退職や契約終了の場面も同じです。令和7年に検挙された識別符号窃用型の不正アクセス399件のうち61件は、IDを知り得る立場にあった元従業員や知人等による犯行でした。
棚卸しと棚卸しの間に起きる変化まで拾うには、定期的な棚卸しに加え、ISPMのようにIDの作成や権限変更を継続的に確認する仕組みが求められています。

ISPMツールは、各システムからデータを収集してIDや権限を可視化し、リスクの検出・評価・是正・再評価を継続的に繰り返します。
どこまで自動化できるか、どの範囲の情報を取り込めるかは製品や連携先によって異なりますが、基本的な流れは共通しています。

ISPMの機能を具体的にイメージしやすくするため、外部の制作会社向けに発行した管理者アカウントが、契約終了後も残っているケースを例に見てみましょう。

分散したIDとアクセス権限のデータを収集し、全体像を可視化する

ISPMツールは、IdPやSaaS、クラウドなどからID・権限・設定の情報を収集し、誰がどのシステムにどのような権限を持っているかを一元的に可視化します。

これにより、IdPで管理しているIDに加え、各サービスに個別に作成されたアカウントや、サービスアカウント、APIキーなども含め、どこにどのようなIDや権限があるかを一覧で把握できます。個別の管理画面では横に並べて見られなかった、IdPを経由せずにログインできる管理者アカウントや、作成した担当者が異動した後も使われ続けているAPIキーも、この一覧で見えるようになります。

ISPMツールがモデルケースのSaaSとの連携に対応していれば、制作会社用の管理者アカウントも一覧に現れます。IdPに対応するIDがないアカウントとして区別されるため、持ち主のはっきりしない管理者アカウントが残っていることが、この段階で分かります。

リスクを検出し、対応の優先順位を付ける

ISPMツールは、退職者に紐付いたID、所有者・利用目的が不明なNHI、過剰な権限、長期間使われていない休眠ID、多要素認証（MFA）が適用されていないIDなど、セキュリティ上のリスクを検出します。

検出したリスクは、権限の強さやアクセスできる情報の重要度などをもとに評価し、対応の優先順位を付けます。モデルケースのアカウントは管理者権限を持ち、MFAが設定されておらず、SaaSには顧客リストが保存されています。同じ評価で、90日以上ログインのない一般ユーザーのIDが見つかったとしても、先に対応すべきなのは管理者アカウントのほうです。どちらも使われていないIDですが、悪用されたときに届く範囲が大きく違います。

収集と評価は一度きりではなく継続的に行われるため、新規アカウントの作成や権限の追加、認証設定の変更など、新たに生じたリスクも検出の対象になります。

是正と再評価を支援する

ISPMツールは、検出したリスクに対して、不要なIDの停止や権限の削除、認証設定の変更など、推奨される対応を提示します。休眠IDや未使用の権限など、見直すべき対象を明確にすることで、管理者の判断を支援します。

モデルケースの管理者アカウントであれば、推奨される対応はアカウントの停止です。ただし、制作会社との契約が本当に終わっているか、このアカウントで動かしているメール配信などがないかは、ツールからは分かりません。停止する前に、SaaSを契約したマーケティング部門に確認します。

製品によっては、IAMやIGAなどの既存システムと連携し、あらかじめ設定したルールに基づいてアカウントの停止や権限の変更まで自動で行えます。
是正後の状態もあらためて評価します。停止したアカウントが次の評価でリスクとして上がってこないことを確かめ、誰が、いつ、なぜ停止したかを履歴に残します。この履歴は、棚卸しや監査、関係部門への報告で、放置されていたアカウントにどう対応したかを説明する材料になります。

ISPMとIAM・IGA・PAM・ITDR・CSPMは、いずれもセキュリティやID管理に関わる領域ですが、主な役割が異なります。IAMやPAMはアクセスを許可・制御する仕組み、ITDRは攻撃が起きたときに検知して対応する仕組みです。ISPMは攻撃が起きる前の段階で、これらの設定や権限に弱点が残っていないかを評価します。

それぞれの違いとISPMとの関係を、以下の表で整理します。

これらは必ずしも同じ階層の概念ではなく、対象や機能が一部重なります。実際の製品でも、IGAとISPMの機能をまとめて提供するものがあり、境界は製品ごとに異なります。

ISPMの導入では、自社のID管理における課題を整理し、どこから着手するかを明確にしたうえで、必要な機能や運用方法を具体化していきます。
全社一斉ではなく、まずは管理者権限を持つIDや、顧客情報・財務情報を扱うシステムから段階的に取り組み、可視化・評価・是正・再評価を継続できる形を整えることがポイントです。

対象とするID・権限・システムの範囲を決める

まず、ISPMで管理する対象を、利用者・用途、権限、システムの3つの観点から整理します。

• 利用者・用途：従業員、委託先などの外部関係者、自動処理やAIエージェントに使うNHI
• 権限：一般利用者の権限、設定変更や重要データの操作ができる管理者権限
• システム：IdP、SaaS、クラウド、自社内で運用するオンプレミス環境

対象となるシステムを洗い出したら、それぞれの担当部門（システムの持ち主）と、扱う情報の重要度を一覧にします。この一覧が、後の優先順位付けと、是正を誰に依頼するかを決める土台になります。

現状のID管理状況とリスクを把握する

対象を決めたら、現在のID管理がどのような手順で行われているかを確認します。入社・異動・退職の連絡がどの部署からいつ届き、誰が各システムのIDを作成・削除しているのか。権限の申請と承認、棚卸しの頻度、MFAの適用範囲、NHIを作るときのルールの有無もあわせて整理します。

手順を並べてみると、「退職の連絡はIdPの担当者には届くが、IdPと連携していないSaaSの担当者には届かない」「NHIを作るときの申請ルールがない」といった、抜けやすい箇所が見えてきます。

こうした箇所が、ISPMツールで重点的に確認したい範囲です。現状と目標の差を整理し、優先的に解決すべき課題を明確にしましょう。

ISPMに求める機能と連携範囲を決める

現状の課題が見えたら、対象として定めたIDやシステムについて、どこまで可視化・評価・是正したいかを決め、ISPMツールに求める機能と連携範囲を絞り込みます。製品を比較する際は、主に以下の点を確認します。

製品によって対応範囲は異なります。比較の軸は機能の数より、現状の確認で見えた抜けやすい箇所を検出でき、既存環境と連携できるかどうかです。

是正と継続運用の体制を整える

ISPMでリスクを検出した後に対応を進められるよう、あらかじめ社内の役割分担や手順を決めておきます。まず、対応の要否を判断する責任者と、権限削除や設定変更を実施する部門を明確にします。

あわせて、情報システム部門・セキュリティ部門・各業務部門の役割を整理し、変更時の手順も定めます。リスクが検出されたからといって一律に是正するのではなく、誤検知や業務への影響を確認しながら対応を進めることが大切です。

例えば、年に一度の決算処理でしか使わないアカウントは、休眠IDとして検出される場合があります。夜間の自動処理に使うサービスアカウントを所有者不明として停止すれば、翌朝の業務が止まるおそれもあります。検出結果はシステムの担当部門が業務への影響を確かめてから是正に回す、という流れにしておくと、こうした事態を避けやすくなります。
対応後も状態を再評価し、新たなリスクが発生していないか継続的に確認します。

ISPMを導入する際は、IDや権限を適切に管理するための基本施策も併せて整えます。

ISPMは、これらの基本施策を代替するものではありません。基本施策でリスクを抑えつつ、ISPMでIDや権限の状態を継続的に可視化・評価し、必要な見直しにつなげましょう。

ISPMで見つかったリスクは、是正して終わりではありません。システムの担当部門と調整しながら対応し、その後も状態を確認し続ける運用があって、はじめて効果につながります。

ＪＢＣＣグループでは、社員約2,000人に対し、業務効率化のために構築したAIエージェント約1,800体が稼働しています。また、2026年9月には、Oktaが提供する「Okta Identity Security Posture Management（Okta ISPM）」をグループ全社のITシステムに導入しました。まず社員のIDについて権限や利用状況を継続的に可視化する仕組みを整え、今後はAIエージェントなどのNHIにも対象を広げていきます。この社内での可視化と是正の実践で得た知見を、お客様の支援に生かしていきます。

ＪＢＣＣでは、Oktaを活用したIDaaSの導入・運用を支援しています。IDの一元管理やMFA、IDプロビジョニングなどの導入に加え、オプションで認証ログをもとにIDの利用状況やリスクを可視化するなど、導入後の運用にも対応しています。

また、セキュリティリスクの可視化や対策の優先順位付け、ID管理基盤の構築・運用も支援しています。
ID管理やセキュリティリスクの可視化、継続的な運用にお悩みの場合は、ＪＢＣＣへご相談ください。

IDセキュリティの可視化・運用について相談する

Q. ISPMと定期的なID棚卸しは何が違うのですか？

大きな違いは、IDや権限の状態を確認する頻度です。定期的な棚卸しでは実施時点の状態を確認するのに対し、ISPMはIDや権限の変化を継続的に可視化・評価します。
そのため、棚卸しの間に追加された権限や、使われなくなったアカウントなども把握しやすくなります。

Q. IDaaSでシングルサインオン（SSO）を導入していれば、ISPMは不要ですか？

SSOとISPMは役割が異なります。IdP（認証基盤）でログインの入口を一元化しても、各SaaS内でどのような権限を持っているかや、IdPと連携していないアカウントまで一元的に把握できるとは限りません。
ISPMは、複数のサービスやシステムにまたがるIDやアクセス権限、認証設定を可視化・評価し、見直すべきリスクの把握を支援します。

Q.なぜ人が使うIDだけでなく、非人間ID（NHI）も管理する必要があるのですか？

AIエージェントやサービスアカウントなどのNHIが増え、管理対象が広がっているためです。
NHIは自律的に処理を行うことを前提に発行されるため、大きな権限が付与されることがあります。また、人に紐付かないため、担当者の退職や異動に合わせて見直されず、アカウントや認証情報が残ることもあります。

ISPMは、IDやアクセス権限、認証設定の状態を継続的に確認し、リスクの検出から是正までをつなげる取り組みです。IDがSaaSごとに分散し、AIエージェントなどのNHIが増え、権限が日々変わる環境では、定期的な棚卸しや認証の一元化だけでは見えない部分が残ります。

IAMやPAMといった既存の仕組みや、最小権限・MFAなどの基本施策を、ISPMが置き換えるわけではありません。それらが意図どおりに働いているかを確かめ続けるのが、ISPMの役割です。

導入を検討する際は、管理者権限を持つIDと重要なシステムに対象を絞り、ID管理の手順のどこに抜けがあるかを確認するところから始めると進めやすくなります。検出したリスクに誰がどう対応するかまで決めておくと、導入後の運用が回りやすくなります。