退職した社員のアカウントが消されずに残っていたり、誰がどのシステムにどこまでアクセスできるのか把握しきれていなかったり。社内のアカウントと権限の管理に不安を感じていませんか。アイデンティティとアクセス管理（IAM）には「世間で実践されている定番のやり方」があり、それを一つずつ押さえていくことで、こうした抜け漏れを塞いでいけます。
本記事では、IAMのベストプラクティスを名前のついた実践項目として漏れなく一覧で整理し、各項目について「具体的に何をするか」「放置すると何が起きるか」まで掘り下げます。各項目はNISTやCISAなど公的機関の枠組みにもとづくため、自社の対策が標準に沿っているかを確かめる物差しとしても使えます。
一覧を自社の現状と突き合わせれば、できていない箇所がそのまま浮かび上がります。着手の優先順位や、すでに散らかってしまった運用の立て直し方、手作業では回らない部分をツールで補う考え方まで通して解説しますので、自社のIAMを点検するリストとしてご活用ください。
目次
一括ダウンロードする
アイデンティティとアクセス管理（IAM）のベストプラクティス一覧
アイデンティティとアクセス管理（IAM）は、「誰に・どのシステムに・どこまでの権限を」与えるかを管理する仕組みの総称です。ここでは、実際に取り組むべきベストプラクティスを項目ごとに整理します。まずは全体像を一覧で押さえ、自社の現状と突き合わせてみてください。
| ベストプラクティス項目 | 多要素認証（MFA）を全ユーザーに適用する | フィッシング耐性のある認証方式を優先する | シングルサインオン（SSO）で認証を集約する | 最小権限を徹底する | RBACとABACを使い分ける | 特権アカウントを分離し、常時付与しない | 特権操作を記録・監視する | 人間以外のID（サービスアカウント・ワークロードID）も管理する | 入退社・異動に合わせて権限を自動で付与・剥奪する | アクセス権を定期的に棚卸しする | 監視・監査でアクセスを可視化する | 条件付きアクセスでアクセス可否を動的に判断する | フェデレーション（SAML/OIDC）で環境を横断統合する |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 具体的にやること | パスワード単体のログインをなくし、全ユーザー・全サービスに適用する | パスキー（FIDO2/WebAuthn）など偽サイトで成立しない方式へ移行する | 認証経路を集約し、MFA・ポリシーを一箇所で強制する | 必要な最小限だけ付与し、ワイルドカード権限を避けロール単位で付与する | 役割単位（RBAC）に、属性・文脈（ABAC）を重ねて権限を設計する | 一般アカウントと分け、管理者権限は必要なときだけ付与する（JIT） | 誰が・いつ・何をしたかを記録し、異常を検知する | 自動処理用の認証情報も最小権限・棚卸しの対象にする | 人事情報の変更を起点にアカウント発行・停止を自動連動させる | 四半期ごとに妥当性を確認し、非アクティブなアカウントを停止する | 認証・権限変更・特権操作のログを取り、疑わしい挙動を検知する | ID・端末・場所・時間の条件で可否や追加認証を制御する | 標準規格でサービス・クラウド間のIDと認証を安全に連携する |
| 放置すると起きること | 認証情報が漏れると即座に侵入される | SMS・OTPは偽サイトで盗まれMFAを突破される | パスワードの使い回し・付箋メモで統制が崩れる | 権限肥大で乗っ取り時の被害が全社に広がる | 権限が個人単位に散らばり、付与・剥奪の抜けが生じる | 管理者権限の乗っ取りで被害が最大化する | 不正・誤操作に気づけず原因究明もできない | 強い権限のまま放置され侵入の足がかりになる | 退職者アカウントが残り続け、権限が積み上がる | 不要な権限・休眠アカウントが溜まり抜け穴になる | 異常や侵害の兆候を見逃す | 固定ルールでは巧妙な不正アクセスを防げない | 環境ごとにアカウントが分散し管理が煩雑になる |
これらの項目は、大きく認証の強化、権限の最小化、特権アカウントの管理、IDのライフサイクル管理、監視・監査による可視化、ゼロトラストによる統合という6つのまとまりに整理できます。以下では、このまとまりごとに各項目の具体的なやり方と、放置した場合のリスクを掘り下げます。
なぜこれらが「ベストプラクティス」なのか
ここで挙げた項目は、特定ベンダーの推奨ではなく、公的機関が示す枠組みに基づいています。米国国立標準技術研究所（NIST）は、本人確認・認証・フェデレーションを扱う「SP 800-63 デジタルアイデンティティ・ガイドライン」や、ゼロトラストの標準である「SP 800-207」を公開しています。これらが、各項目の裏づけとなる認知された基準です。
IAMを整える必要性は、実際の被害データからも裏づけられます。Verizonの年次調査「2025 Data Breach Investigations Report」では、認証情報の悪用（credential abuse）が初期侵入経路の第1位で全体の22%を占めると報告されています。盗まれた認証情報や放置されたアカウントが、侵入の入り口になっているのです。
出典・参考資料（3件）
認証を強くする（MFA・パスワードレス・SSO）
ここからは、「誰が入ってくるのか」を確実に見極める認証の実践を解説します。IAMの土台であり、最初に手をつけるべき領域です。
多要素認証（MFA）を全ユーザーに適用する
多要素認証（MFA）は、パスワードに加えてスマートフォンや生体認証など別の要素を組み合わせる仕組みです。導入効果は大きく、Microsoft Researchが2023年に公表した大規模調査では、MFAによって侵害リスクが全体で99.22%、認証情報がすでに漏えいしたアカウントでも98.56%低減したと報告されています。
重要なのは、適用範囲に穴を作らないことです。米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、メール・ファイル共有・金融関連を含むすべてのサービスの、すべてのユーザーにMFAを適用するよう一貫して促しています。一部の管理者だけ、重要システムだけという部分適用では、残った隙間が狙われます。
出典・参考資料（2件）
フィッシング耐性のある認証方式を優先する
同じMFAでも、方式によって強さは異なります。SMSや音声によるワンタイムパスワードは、偽サイトに入力させて盗む攻撃に弱く、CISAは最後の手段と位置づけています。一方で、パスキー（FIDO2/WebAuthn）は偽サイトでは認証が成立しない仕組みのため、フィッシングに強い方式です。
CISAはこのフィッシング耐性MFAを、最も目指すべき水準と位置づけ、次のように述べています。
phishing-resistant MFA is the gold standard and organizations should make migrating to it a high priority effort（フィッシング耐性MFAはゴールドスタンダードであり、組織はその移行を高い優先度で進めるべきである）
出典：Implementing Phishing-Resistant MFA｜CISA（2022年10月）
すぐに全社をパスキーへ移行できない場合でも、何もしないよりMFAを入れる方がリスクは下がります。まずは全ユーザーにMFAを適用し、順次フィッシング耐性のある方式へ切り替えていく進め方が現実的です。
シングルサインオン（SSO）で認証を集約する
シングルサインオン（SSO）は、一度の認証で複数のクラウドサービスへアクセスできる仕組みです。サービスごとに個別のパスワードを管理させると、使い回しや付箋メモが生まれ、かえって危険になります。認証経路をSSOに集約すれば、MFAやアクセスポリシーを一箇所で強制でき、統制の抜けを防げます。
CISAも、多くのホスト型メールやSSOシステムがパスキーに対応していることから、こうしたシステムを強化の出発点として推奨しています。SSOは利便性の向上だけでなく、認証強化の起点としても効果的です。
自社に多要素認証を導入するにあたり、どの認証方式の製品を選ぶかを具体的に比較したい場合は、認証方式・料金・タイプ別の選び方をまとめた以下の記事が参考になります。
多要素認証（MFA）システムおすすめ17選を徹底比較｜認証方式・料金・タイプ別の選び方
ID とパスワードだけのログインは、もはや「鍵をかけていない」のと同じ状態に近づいています。攻撃者は流出したパスワードのリストを使い回し、本物そっくりの偽サイトで認証情報を抜き取り、正規利用者になりすまして社内システムやクラウドサービスへ侵…
権限を最小限に絞る（最小権限・RBAC・ABAC）
認証で「誰が入るか」を確かめたら、次は「入った人に何をどこまで許すか」です。ここでは権限設計の実践を、原則論で終わらせず具体的な禁則まで掘り下げます。
最小権限を徹底する
最小権限とは、業務の遂行に必要な最小限の権限だけを与える考え方です。NISTのゼロトラスト標準（SP 800-207）も、アクセスルールを可能な限り細かくして、要求された操作に必要な最小限の権限を強制すべきだとしています。アカウントが乗っ取られても、与えられていた権限の範囲でしか被害が広がらないようにするのが狙いです。
徹底するには、「確認しましょう」では足りません。すべてを許可するワイルドカード権限（*）を避ける、権限は個人に直接付けず後述のロール単位で付与する、不要になった権限は速やかに外す、といった具体的な運用に落とし込みます。これにより、権限が積み重なって増えていく「権限肥大」を防げます。
出典・参考資料（1件）
- 出典：Zero Trust Architecture（SP 800-207）｜米国国立標準技術研究所（NIST）（リンク）
RBACとABACを使い分ける
権限の付け方には大きく2つの方式があります。RBAC（ロールベースアクセス制御）は、「経理部一般」「システム管理者」といった役割（ロール）に権限をまとめ、ユーザーを役割に割り当てる方式です。大人数に同じ権限をそろえて付与しやすく、運用が単純になります。RBACの規範的な定義は、米国規格「ANSI/INCITS 359」で標準化されています。
一方のABAC（属性ベースアクセス制御）は、利用者・対象データ・操作・環境（時間や場所など）の属性と、それらに基づくポリシーで可否を判断する方式です。NISTのガイド（SP 800-162）は、ABACを次のように定義しています。
ABAC is a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes.（ABACとは、利用者・対象・要求された操作、場合によっては環境条件といった属性を、ポリシーやルールに照らして評価することで操作の可否を判断する、論理的なアクセス制御の方式である）
出典：Guide to Attribute Based Access Control (ABAC)（SP 800-162）｜NIST
使い分けの目安は、まずRBACで役割ごとの基本的な権限をそろえ、「業務時間内だけ」「特定拠点からのみ」といった文脈での細かな制御が必要な部分にABACを重ねる形です。役割だけで表現しきれない動的な条件を、属性で補うと考えると整理しやすくなります。
出典・参考資料（2件）
特権アカウントを管理する（特権アクセス管理／PAM・JIT）
ここからは、乗っ取られると被害が最大になる管理者権限（特権アカウント）の扱いを解説します。分離・一時付与・記録の3つで統制するのが基本です。
特権アカウントを分離し、常時付与せず必要なときだけ与える（JIT）
日常業務でも管理者権限を持ったままにすると、そのアカウントが侵害されたときに被害が全社に及びます。対策は、普段使いの一般アカウントと管理者アカウントを分け、管理者権限は作業するその時だけ一時的に付与する「JIT（Just-In-Time）」の運用です。NISTのゼロトラスト標準も、リソースへのアクセスをセッション単位で許可する考え方を原則に掲げています。
特権操作を記録・監視する
特権アカウントで行われた操作は、誰が・いつ・何をしたかを後から追えるように記録します。重要な設定変更や権限付与が記録されていれば、不正や誤操作の早期発見につながり、万一の際の原因究明も可能になります。記録を取るだけでなく、通常と異なる操作を検知する監視とセットで運用することが大切です。
ここでの記録・監視は管理者権限（特権操作）に絞ったものです。全ユーザー・全アクセスを対象にした常時監視は、後の「監視・監査でアクセスを可視化する」で扱います。
人間以外のID（サービスアカウント・ワークロードID）も管理する
管理対象は人間のアカウントだけではありません。システム間連携やバッチ処理に使うサービスアカウント、クラウド上のワークロードに付与されるIDも、管理すべきIDです。NISTのゼロトラスト標準も、クライアントのIDにはユーザーアカウントだけでなくサービスIDが含まれ得ると明記しています。
これらは作成後に放置されがちで、強すぎる権限を持ったまま忘れ去られると侵入の足がかりになります。人間のアカウントと同様に、最小権限・定期的な棚卸し・利用状況の監視の対象に含めてください。
特に注意したいのが認証情報（シークレット）の扱いです。APIキーやアクセスキーをソースコードや設定ファイルに直接書き込むと、リポジトリやサーバーから流出した瞬間にそのまま悪用されます。認証情報は、専用のシークレット管理の仕組みで集中管理します。
そのうえで、できるだけ有効期限の短い一時的なトークンを使い、長期間使い回している固定のキーは定期的に作り直す（ローテーションする）のが基本です。CI/CDパイプラインなど自動処理で使う認証情報も、見落とされやすい一方で広い権限を持ちがちなため、人間のアカウントと同じ統制の対象に含めます。
出典・参考資料（1件）
- 出典：Zero Trust Architecture（SP 800-207）｜米国国立標準技術研究所（NIST）（リンク）
IDのライフサイクルを管理する（入退社の権限付与・剥奪と棚卸し）
退職者アカウントの放置や権限肥大は、現場で最も起こりやすい抜け漏れです。ここでは、入社から退職までの「IDのライフサイクル」を運用に乗せる実践を解説します。
入社・異動・退職に合わせて権限を自動で付与・剥奪する
入社時のアカウント作成（プロビジョニング）と、退職・異動時の権限剥奪（デプロビジョニング）を手作業に頼ると、対応漏れや遅れが必ず発生します。人事情報の変更を起点に、各サービスのアカウント発行・停止が自動で連動する仕組みを整えると、退職者アカウントが残り続ける事態を防げます。異動の際も、旧部署の権限を外し忘れず、権限が積み重なっていくのを抑えられます。
アクセス権を定期的に棚卸しする
自動化を整えても、設定漏れや例外運用で不要な権限は少しずつ溜まります。そこで、アクティブなアカウントと権限が今も妥当かを定期的に見直す「棚卸し」が必要です。頻度の目安として、セキュリティ基準のCIS Controls v8は、最低でも四半期ごとの妥当性確認を求めています。
Validate that all active accounts are authorized, on a recurring schedule at a minimum quarterly, or more frequently.（すべての有効なアカウントが認可されたものであることを、少なくとも四半期ごと、またはそれ以上の頻度で妥当性確認する）
出典：CIS Controls v8 Safeguard 5.1｜Center for Internet Security
使われていないアカウントの基準も具体的に示されています。CIS Controls v8 は、45日間利用のない休眠アカウントを無効化または削除するよう推奨しています。「非アクティブ45日で停止」のように自社のルールとして数値を決めておくと、判断がぶれません。
Delete or disable any dormant accounts after a period of 45 days of inactivity, where supported.（対応可能な場合、45日間利用のない休眠アカウントを削除または無効化する）
出典：CIS Controls v8 Safeguard 5.3｜Center for Internet Security
出典・参考資料（1件）
- 出典：CIS Controls v8（Control 5: Account Management）｜Center for Internet Security（リンク）
監視・監査でアクセスを可視化する（ログ・疑わしい挙動の検知）
権限を適切に設計しても、それが実際にどう使われているかを見ていなければ、異常に気づけません。ここでは、付与した権限を継続的に見張る運用フェーズの実践を解説します。
前章の特権操作の記録が管理者権限に絞った監視だったのに対し、ここでは全ユーザー・全アクセスを対象にした常時監視を指します。記録すべきログは、ログインの成否、権限の付与・変更、特権操作、重要な設定変更などです。
これらを取得・保管したうえで、普段と違う場所・時間帯からのサインイン、短時間での大量アクセス、権限昇格の試行といった疑わしい挙動を検知できるようにします。保管期間は、監査や事後の調査に耐えられるよう、自社の要件に応じて定めます。NISTのゼロトラスト標準も、保有するすべての資産の整合性とセキュリティ状態を継続的に監視・測定することを原則としています。
集めたログは、ためておくだけでは意味がありません。同標準は、資産やネットワークの現状について可能な限り情報を収集し、それをセキュリティ態勢の改善に活用すべきだとしています。検知した異常を、アクセスポリシーの見直しや権限の修正につなげる運用まで含めて設計してください。
出典・参考資料（1件）
- 出典：Zero Trust Architecture（SP 800-207）｜米国国立標準技術研究所（NIST）（リンク）
ゼロトラストでID基盤を統合する（IDを境界に・条件付きアクセス・フェデレーション）
これまでの個別実践を貫く設計思想が「ゼロトラスト」です。社内ネットワークの内側だからといって無条件に信用せず、アクセスのたびにIDを確かめる考え方で、ハイブリッドやマルチクラウドの環境を横断して統合します。NISTはゼロトラストを次のように定義しています。
Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.（ゼロトラストとは、ネットワークが侵害されているという前提のもとで、正確かつ最小権限のリクエスト単位のアクセス判断を下す際の不確実性を最小化するための、概念と考え方の集合である）
出典：Zero Trust Architecture（SP 800-207）｜NIST
条件付きアクセスでアクセス可否を動的に判断する
条件付きアクセスは、ID・デバイスの状態・場所・時間などの条件に応じて、アクセスの可否や追加認証の要否を動的に決める仕組みです。NISTのゼロトラスト標準も、アクセスは動的なポリシーで判断すべきで、クライアントのIDやアプリ、要求元の資産の状態、行動や環境の属性を含めて評価すると説明しています。「社内からは許可、海外の未知の端末からは追加認証」といった柔軟な制御が可能になります。
フェデレーション（SAML/OIDC）で環境を横断統合する
フェデレーションは、SAMLやOpenID Connect（OIDC）といった標準規格で、異なるサービスやクラウド間のIDと認証結果を安全に受け渡す仕組みです。社内システムとSaaS、複数のクラウドにまたがってIDを統一的に扱えるようになり、環境ごとにアカウントが分散するのを防げます。
認証やフェデレーションの具体的な要件は、NISTのデジタルアイデンティティ・ガイドライン（SP 800-63）が枠組みを示しています。
出典・参考資料（2件）
どこから手をつけるか（着手順・優先順位）
ここまでの項目をすべて一度に実施するのは現実的ではありません。優先順位をつけて段階的に進めるのが定石です。順番を決める軸は、被害の大きさと着手のしやすさの2つです。
CISAは、MFAの導入にあたって「どのリソースを侵害から守りたいか」「どのユーザーが高価値な標的か」という2つの問いから優先順位を考えるよう示しています。この考え方はIAM全体に応用できます。まず被害が大きい領域から着手するのが合理的です。
具体的な着手順の一例は、次のとおりです。乗っ取られた際の被害が最大になる管理者（特権アカウント）と、全社に関わる認証基盤から優先的に固めていく流れです。
- 全ユーザーへのMFA適用と、特権アカウントの分離（被害が最大の領域をまず塞ぐ）
- 退職者・休眠アカウントの棚卸しと停止（放置された入り口をなくす）
- SSOへの集約と、入退社に連動した権限の自動付与・剥奪（運用を仕組み化する）
- フィッシング耐性MFAへの移行、条件付きアクセス・監視の高度化（継続的に強化する）
出典・参考資料（1件）
- 出典：Implementing Phishing-Resistant MFA｜CISA（2022年10月）（リンク）
運用が散らかってしまったときの立て直し方（よくある失敗と処方）
すでに権限が肥大化し、退職者アカウントも残っている──そんな「散らかった」状態からの立て直しも、手順を踏めば進められます。よくある失敗と、その処方を整理します。
陥りがちな失敗は、退職者アカウントの消し忘れ、異動で積み上がった権限の放置、管理者権限の付けっぱなし、そして一部のユーザーだけMFAが未適用になっているケースです。いずれも、放置された認証情報が侵入の入り口になるという共通のリスクを抱えています。
立て直しの初手は、現状の棚卸しです。全アカウントと付与された権限をいったん洗い出し、退職者・休眠アカウントの即時停止と、明らかに過剰な権限の剥奪から着手します。危険な入り口を塞いだあとの強化の順序は、前章「どこから手をつけるか」のロードマップに沿って進めると迷いません。
棚卸しそのものを漏れなく進めるには、手順を決めておくと取りこぼしを防げます。まずIDプロバイダや各SaaSの管理画面・APIから全アカウントの一覧を書き出し、人事の在籍名簿と突き合わせて、名簿に無いアカウント（退職者や、持ち主の分からないアカウント）を洗い出します。次に最終ログイン日を確認し、長期間使われていない休眠アカウントを特定します。
最後に、残ったアカウントについて所属と役割に照らし、過剰な権限や異動で不要になった権限が付いていないかを確認します。危険度は退職者・不明・休眠の順に高いので、この順で停止していくと、限られた時間でも侵入の入り口になりやすいものから先に塞げます。
全社一斉ではなく、段階的な展開も有効です。CISAは、ヘルプデスクやIT管理者といったグループを最初のフェーズとして検討するよう示しています。影響範囲をコントロールしながら、運用の定着とともに対象を広げていくとよいでしょう。
出典・参考資料（1件）
- 出典：Implementing Phishing-Resistant MFA｜CISA（2022年10月）（リンク）
内部統制・コンプライアンス要件に対応する（J-SOX・個人情報保護法）
IAMの実践は、セキュリティ上の効果だけでなく、国内の法令・制度への対応という側面も持ちます。稟議や監査の場面で、IAM投資の根拠として説明できると役立ちます。
まず、個人情報保護法は、個人データを扱うほぼすべての事業者に「安全管理措置」を求めています。第23条は次のように定めており、アクセス制御・認証・権限管理といったIAMの実践が、この措置の中核を担います。
個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。
出典：個人情報の保護に関する法律 第23条｜e-Gov法令検索
同法は第24条で従業者の監督を、第25条で委託先の監督を求めており、入退社に伴う権限管理や、外部委託先のアクセス統制とも直結します。従業員のアカウントや委託先に付与する権限を適切に管理することは、法令上の要請でもあるのです。
加えて、上場企業やIPO準備企業では、金融商品取引法に基づく内部統制報告制度（J-SOX）への対応が必要です。金融庁の基準は内部統制を6つの基本的要素で整理しており、その一つ「ITへの対応」をIT統制として次のように定義しています。アクセス権の付与・分離やログ管理といったIAMの実践は、このIT統制の具体的な手立てとして位置づけられます。
ＩＴへの対応とは、組織目標を達成するために予め適切な方針及び手続を定め、それを踏まえて、業務の実施において組織の内外のＩＴに対し適切に対応することをいう。
出典：財務報告に係る内部統制の評価及び監査の基準（令和元年12月改訂）｜金融庁 企業会計審議会
J-SOXが直接の法的義務となるのは上場企業やその連結子会社などに限られ、非上場の中小企業に一律の義務が及ぶわけではありません。ただし、個人情報保護法の安全管理措置は広く適用されるため、規模にかかわらずIAMを整える意味は十分にあります。
出典・参考資料（2件）
一括ダウンロードする
手運用がつらい部分をツールで解決する（IDaaS・SaaS管理ツールの活用）
ここまでの実践のうち、入退社に伴う権限の付与・剥奪、SSOや多要素認証による認証の集約、SaaSアカウントの棚卸し、ログの監視といった領域は、手作業では負担が大きく抜け漏れも生じやすい部分です。こうした工程は、IDaaS（ID基盤のクラウドサービス）やSaaS管理ツールで仕組み化できます。
役割の異なる代表的なサービスを2つ紹介します。認証・ID基盤そのものを担うタイプと、利用中のSaaSアカウントの可視化・棚卸しを担うタイプです。
| サービス名 | CloudGate UNO | マネーフォワード Admina |
|---|---|---|
| 役割・レイヤ | ID基盤・認証レイヤ （IDaaS） | SaaS可視化・棚卸しレイヤ （SaaS管理） |
| 主に楽になる工程 | ログイン認証の集約 パスワード管理の負担解消 | SaaSアカウントの棚卸し 入退社時のアカウント対応 |
| SSO・多要素認証（MFA） | ●SSO・MFA・パスキーを自ら提供 | ×提供なし（IdPと連携して利用） |
| 入退社の権限付与・剥奪 | ●アカウント作成・更新・削除を自動化（プロビジョニング） | ●従業員マスター連携で退職者を検知・自動削除 |
| SaaSアカウントの可視化・棚卸し | ×SaaS可視化・棚卸しは対象外 | ●シャドーIT検知を標準搭載 |
| 月額料金 | 400〜600円/ユーザー （税抜。プランにより変動） | 50ID以下は無料 51ID以上は1IDあたり300円 |
| 無料トライアル | 30日間 | 14日間 |
| 詳細情報 | 公式資料を見る | オンライン相談を予約 |
CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNOは、ISR（株式会社インターナショナルシステムリサーチ）が自社開発するクラウド型のID基盤（IDaaS）です。シングルサインオン・多要素認証・アクセス制限・ID管理を一つのサービスにまとめ、本記事で挙げた「認証を強くする」「IDのライフサイクルを管理する」といった実践の土台を提供します。
認証面では、パスキー（FIDO2）によるパスワードレス認証や、Windows Hello・Touch ID/Face IDといった端末の生体認証に対応します。アクセス制限は「端末・場所・時間」の3つの軸で設定でき、たとえば私用端末からのアクセス禁止や、特定拠点・時間帯に限った利用といった制御が可能です。アカウントの作成・更新・削除を自動化するプロビジョニングも備えます。
料金はStandard Plusが月額400円、Enterprise Plusが月額500円、Smart Packが月額600円（いずれも1ユーザーあたり・税抜）で、30日間の無料体験が用意されています。ISMS（ISO/IEC 27001）やプライバシーマーク、FIDO2認定を取得しており、国産の自社開発と日本語サポートを特徴としています（2026年11月時点、公式サイトに基づく）。
認証をツールで仕組み化すると、手作業で回していた運用がどう変わるのか。提供元はMCB FinTechカタログの独自インタビューで、導入現場の例を次のように挙げています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。また、他社サービスからの乗り換え事例もございます。通常、設定の移行には時間がかかるものですが、当社のサポートによりわずか1週間で完了させたケースもあります。
マネーフォワード Admina（マネーフォワードｉ株式会社）
マネーフォワード Adminaは、従業員を軸に社内で使われているSaaSアカウントを可視化・棚卸しするSaaS管理ツールです。CloudGate UNOのようにログイン認証（SSO・多要素認証）そのものを提供するのではなく、Google WorkspaceやMicrosoft 365などのIdP（認証基盤）と連携して、「誰がどのSaaSを使っているか」を把握する役割を担います。
本記事の実践でいえば、アカウントの棚卸しと入退社時の対応に強みがあります。従業員マスターと連携したIDライフサイクル管理により、退職者のアカウントをアラートで検知して削除でき、退職日や雇用区分を条件にした自動削除も設定できます。情報システム部門が把握していないSaaS（シャドーIT）を検知する機能も標準で備えます。
料金は50ID以下であれば全機能を無料で利用でき、51ID以上は1IDあたり月額300円です。無料トライアルは14日間用意されています。Google Workspace・Microsoft 365・Oktaなどを従業員マスターとして連携し、その有効ID数で課金する仕組みです（2026年11月時点、公式サイトに基づく）。
ここで取り上げたのは役割の異なる2サービスの例です。IDaaS（ID基盤サービス）を横断で比較して自社に合う製品を選びたい場合は、主要なサービスの機能・料金・選び方・導入事例をまとめた以下の記事が役立ちます。
まとめ
IAMのベストプラクティスは、認証の強化・権限の最小化・特権アカウントの管理・IDライフサイクルの運用・監視と可視化・ゼロトラストによる統合という実践項目に整理できます。いずれもNISTやCISA、CIS Controlsといった公的な枠組みに裏づけられた、標準的な取り組みです。
まずは本記事の一覧を自社の現状と突き合わせ、できていない箇所を洗い出すことから始めてみてください。すべてを一度にではなく、被害の大きい領域（MFA・特権アカウント・退職者アカウント）から優先的に着手するのが現実的です。手作業で回らない部分は、IDaaSやSaaS管理ツールで仕組み化することで、継続できる運用に変えられます。
一括ダウンロードする
よくある質問（FAQ）
Q. IAM（アイデンティティとアクセス管理）とは何ですか？
A. IAM（アイデンティティとアクセス管理）とは、「誰に・どのシステムに・どこまでの権限を」与えるかを一元的に管理する仕組みの総称です。読み方は「アイアム」で、本人確認を行う認証と、権限を与える認可を軸に、アカウントの発行・権限設計・棚卸し・ログ監視までを扱います。
これらを適切に運用することで、退職者アカウントの放置や権限の過剰付与といった抜け漏れを防ぎ、ヒューマンエラーのリスクを下げられます。
Q. IAMとIDaaSは何が違うのですか？
A. IAMがアクセス管理の取り組み・考え方の全体を指すのに対し、IDaaSはその実践をクラウド上で支えるツール（ID基盤サービス）です。本記事で挙げたMFA・SSO・最小権限・IDライフサイクル管理といったベストプラクティスがIAMの中身で、それらを自社で手運用するか、IDaaSで仕組み化するかという関係になります。
IDaaSはシングルサインオン・多要素認証・アカウントの自動発行/停止などをまとめて提供するため、手作業では回りにくい運用の受け皿になります。
Q. IAMのベストプラクティスはどこから始めればよいですか？
A. 乗っ取られた際の被害が最大になる管理者（特権アカウント）と、全社に関わる認証基盤から優先的に固めるのが定石です。具体的には、全ユーザーへのMFA適用と特権アカウントの分離を最初に行い、次に退職者・休眠アカウントの棚卸しと停止、続いてSSOへの集約と入退社に連動した権限の自動付与・剥奪、という順序が現実的です。
被害の大きさと着手のしやすさの2軸で優先順位を決めると、限られたリソースでも効果の高い領域から着手できます。
Q. 中小企業や非上場企業でもIAMへの対応は必要ですか？
A. はい、企業規模や上場の有無にかかわらず必要です。内部統制報告制度（J-SOX）が直接の法的義務となるのは上場企業やその連結子会社などに限られますが、個人情報保護法の安全管理措置は個人データを扱うほぼすべての事業者に及びます。
アクセス制御・認証・権限管理といったIAMの実践は、この安全管理措置の中核を担うため、中小企業でも整える意味は十分にあります。まずはMFAの適用と退職者アカウントの停止など、負担の小さい項目から始めるとよいでしょう。
出典・参考資料（1件）
- 出典：個人情報の保護に関する法律（平成15年法律第57号）第23条｜e-Gov法令検索（リンク）
Q. IAMは自社運用とツール導入のどちらがよいですか？
A. 最小権限やMFAの方針といった設計は自社で決め、手作業では回らない運用部分をツールで仕組み化する組み合わせが現実的です。入退社に伴う権限の付与・剥奪、SSOや多要素認証による認証の集約、SaaSアカウントの棚卸し、ログの監視といった領域は、手運用だと対応漏れや遅れが生じやすい部分で、ツールに任せると属人化を避けられます。
まずは自社で手運用がつらいと感じている工程を洗い出し、その領域に強いツールから検討するとよいでしょう。
Q. IDaaSなどのツール導入にはどのくらいの費用がかかりますか？
A. 認証・ID基盤を担うIDaaSは1ユーザーあたり月額数百円から、SaaS管理ツールは一定のID数まで無料で使えるものもあり、規模と機能によって幅があります。本記事で紹介した例では、CloudGate UNOが月額400〜600円（1ユーザーあたり・税抜）、マネーフォワード Adminaが50ID以下は無料・51ID以上は1IDあたり月額300円（いずれも2026年11月時点）です。
多くの製品に無料体験やトライアルが用意されているため、まず自社環境で試してから判断するのが安全です。正確な費用は利用規模や必要機能で変わるため、各社の最新の料金資料で確認してください。
IDaaS・ID管理システムの料金・資料を一括チェック
MCB FinTechカタログでは、SSO・多要素認証・ID管理・SaaS管理に対応するサービスの最新資料を無料で一括請求できます。認証方式や料金、入退社の権限管理の自動化範囲などを比べられます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
