>
>
公開日
最終更新日
RBACとはユーザーの役割に応じてアクセス権限を制御する仕組みです。情シス担当者がSaaSや社内システムの権限を個人ごとに管理すると、入社・異動・退職のたびに設定漏れや過剰権限が発生しやすくなります。
RBACでは「営業担当」「経理承認者」「SaaS管理者」などのロールに必要な権限を定義し、ユーザーにはロールを付与します。権限の変更をロール単位に集約できるため、棚卸しや監査の対象を整理しやすくなります。
本記事では、RBACの読み方と基本構造に加え、ABACとの違い、条件付きアクセスを組み合わせるハイブリッド設計、ロール爆発を防ぐ運用ルールを扱います。SaaS管理における権限設計を見直す情シス担当者向けに、判断材料と実装手順を整理します。
RBACとは？読み方と基本の仕組み
RBACは「Role-Based Access Control」の略で、日本語では「役割ベースアクセス制御」と呼ばれます。読み方は「アールバック」または「アール・ビー・エー・シー」です。ユーザー個人に権限を直接付与するのではなく、営業、経理、情シス管理者といった業務上の役割（ロール）に権限をまとめ、そのロールをユーザーへ割り当てます。
たとえば、経費精算SaaSで「一般申請者」「部門承認者」「経理担当者」「システム管理者」という4つのロールを作り、それぞれに申請、承認、仕訳、設定変更といった操作権限を対応付けます。異動時はユーザーの所属ロールを変更することで、必要な権限をまとめて切り替えられます。
RBACは、誰が何をできるかを業務上の役割に結び付けるため、権限付与の判断基準を説明しやすくなります。一方で、ロールの粒度を細かくしすぎると、例外対応のたびにロールが増える「ロール爆発」が起こり、かえって管理が複雑になります。
RBACを構成する4つの要素
RBACの設計では、ユーザー、ロール、権限、リソースの関係を明確にします。NISTが定めるRBACの標準モデル（ANSI/INCITS 359）では、これらに加えて「セッション」（ユーザーがアクティブ化したロールの単位）が構成要素として定義されています。本記事では製品・実装上の整理として主要4要素を扱いますが、IAMツールやクラウド基盤の実装がセッション単位の権限制御に対応しているかどうかは、各製品の仕様書で確認できます。
ユーザー：従業員、派遣社員、委託先担当者、サービスアカウントなど、システムへアクセスする主体です。
ロール：業務や責任範囲を表す権限のまとまりです。例として「人事閲覧者」「人事管理者」「監査担当者」があります。
権限：閲覧、作成、編集、削除、承認、設定変更など、実行可能な操作です。
リソース：権限の対象となるデータ、フォルダ、帳票、SaaSの管理画面、APIなどです。
設計時は、「ユーザーにロールを付与する」「ロールに権限を付与する」「権限がリソースへの操作を許可する」という関係を分けて記録します。この分離により、同じ職務の人が増減しても、ロールの割り当てだけで対応できます。
下表は経費精算SaaSを例にしたロール設計マトリクスのサンプルです。自社環境では操作列を利用中のSaaSの権限一覧と照合し、ロールごとに「○（許可）」「×（禁止）」を埋めることで、設計上の空白や重複を可視化できます。
ロール名 | 申請 | 承認 | 仕訳・締め | 全件エクスポート | ユーザー設定変更 |
|---|---|---|---|---|---|
一般申請者 | ○ | × | × | × | × |
部門承認者 | ○ | ○（担当部門のみ） | × | × | × |
経理担当者 | ○ | × | ○ | ○ | × |
システム管理者 | × | × | × | ○ | ○ |
OSや社内ネットワークにおけるユーザー・グループ・権限の集中管理手法について詳しく知りたい方は、Active Directoryでのグループ管理と権限設計の基礎を解説した記事をご覧ください。
▲ RBACを構成する4つの基本要素とその関係性
RBACとABACの違いを比較
ABACは「Attribute-Based Access Control」の略で、「属性ベースアクセス制御」と呼ばれます。RBACが役割を中心にアクセス可否を判断するのに対し、ABACはユーザー、データ、操作、利用環境に付与された属性とポリシーを評価して判断します。
比較項目 | RBAC | ABAC |
|---|---|---|
判断の中心 | ユーザーに割り当てたロール | ユーザー・データ・操作・環境の属性 |
代表的な条件 | 経理担当者なら支払データを閲覧可能 | 経理担当者で、管理端末から、勤務時間内なら支払データを閲覧可能 |
得意な場面 | 職務が比較的安定した社内業務、SaaSの標準権限管理 | 時間帯、場所、端末状態、データ分類など動的な条件がある環境 |
運用上の負担 | ロール設計と定期見直しが中心 | 属性の信頼性、ポリシー、属性更新の管理まで対象が広がる |
注意点 | 例外が増えるとロール数が増えやすい | 条件が多すぎるとポリシーの検証が難しくなりやすい |
たとえば「人事部のメンバーは従業員台帳を閲覧できる」はRBACで表現しやすいルールです。一方、「人事部のメンバーであり、会社管理端末を使用し、社内ネットワークまたは多要素認証済みの接続で、機密区分が本人の担当範囲に一致する場合だけ閲覧できる」はABACや条件付きアクセスが適します。
2024年5月7日には、NISTがNoSQLデータベースにおけるアクセス制御を扱うNIST IR 8504（正式名称：Access Control Considerations for NoSQL Databases）を公開しています（原典：https://csrc.nist.gov/pubs/ir/8504/final）。同文書では、コレクション・ドキュメント・フィールドといったデータ階層ごとのアクセス制御方式としてRBACとABACの適用を整理しており、クラウドサービス、API、データ基盤をまたぐアクセス管理では、ロールだけでなく、データ分類や利用状況などの属性を扱う設計も検討対象として位置づけています。
▲ RBACとABACのアクセス制御メカニズムの比較
RBACとABACは併用できる
RBACとABACは二者択一ではありません。実務では、日常的な業務権限をRBACで管理し、リスクが高い操作や例外的なアクセスにだけ属性条件を重ねるハイブリッド構成が扱いやすい形です。
たとえば、SaaSの標準ロールとして「情シス管理者」を割り当てたうえで、管理画面へのアクセスには多要素認証済みであること、社給端末であること、接続元が許可済みネットワークであることを条件として設定します。これにより、通常の入社・異動・退職処理はロール付与で進めながら、特権操作には追加の制約をかけられます。
ただし、属性の値が古い、端末管理情報が欠けている、組織情報の同期が遅れるといった状態では、意図した制御になりません。ABACや条件付きアクセスを重ねる範囲では、ID管理基盤、MDM、HRシステムなど、属性の発生元と更新責任者も整理します。
属性情報や認証条件を統合管理して柔軟なアクセス制御を実現する基盤に関心がある場合は、IDaaSの基本機能やアクセス制御におけるメリットをあわせてご確認ください。
情シス向け：RBACの設計手順
RBACは、先にロール名を考えるよりも、現状のアカウントと権限を棚卸ししてから設計すると実態に合いやすくなります。次の順番で進めると、過剰権限や属人的な例外を見つけやすくなります。
対象システムを洗い出す：SaaS、社内システム、クラウド管理画面、共有ストレージ、VPN、開発基盤を一覧化します。
アカウントと特権を棚卸しする：現職者、休職者、退職者、外部委託先、共有アカウント、サービスアカウントを区別し、管理者権限や削除権限を抽出します。
業務単位で共通パターンを探す：同じ業務を担う人に共通する権限をまとめ、職務・責任・承認範囲に沿った候補ロールを作ります。
最小特権でロールを定義する：通常業務に必要な操作だけを基本ロールへ入れ、設定変更、全件エクスポート、権限変更などは特権ロールとして分けます。
例外権限を別管理する：一時的な兼務、プロジェクト参加、障害対応などは恒久ロールへ混ぜず、理由、承認者、付与日、終了日を記録します。
定期レビューを運用に組み込む：人事異動、組織改編、契約終了、SaaS導入・廃止のタイミングでロールと権限の差分を見直します。
ロール名は「営業」「管理者」のように曖昧な名称より、「Salesforce_営業閲覧」「経費精算_部門承認者」のように、対象システムと権限範囲が分かる名称にすると、棚卸し時の判断が速くなります。
下記は棚卸し開始時に確認する項目のチェックリストです。各項目を「現状値」として記録し、四半期または人事異動期ごとに比較することで、権限管理の変化を数値で追えます。
□ 利用中のSaaS・社内システムを一覧化済みか
□ 各システムの管理者（特権）アカウント数を把握済みか
□ 退職・契約終了後も残るアカウントがゼロか（残る場合は件数を記録）
□ 期限・終了日の定めがない例外権限の件数を把握済みか
□ 共有アカウント・サービスアカウントの利用目的と責任者が記録済みか
□ SCIMまたは手動プロビジョニングの同期状態を直近30日以内に確認済みか
定めたアクセス制御モデルに基づいてアカウント発行や権限割り当てを自動化する仕組みは、プロビジョニングの仕組みとユーザー権限割り当ての基礎で詳しく説明しています。
▲ 失敗を防ぐ情シス向けRBAC設計・運用の6手順
SaaS権限設計で確認したいポイント
SaaSでは、標準ロールの権限範囲が広いケースがあります。特に、ユーザー招待、SSO設定、監査ログ閲覧、請求情報変更、データエクスポート、APIトークン発行の権限は、通常利用者のロールと分離します。なお、ここで挙げる設計指針はSaaS製品ごとに対応状況が異なります。各SaaSの管理者向けドキュメントや権限一覧ページで実際のロール定義を確認し、標準ロールに含まれる操作が自社の意図した範囲と一致しているかを照合します。一致しない場合はカスタムロールの作成可否も同じドキュメントで確認できます。
また、接続元のネットワークアドレスだけを条件にしたアクセス制御は、VPNや社内ネットワークへの接続が必ずしも「社給端末かつ本人操作」を意味しないため、端末管理（MDM）や多要素認証と組み合わせることで制御の精度が上がります。
2026年8月時点の棚卸しでは、少なくとも「利用中のSaaS数」「各SaaSの管理者アカウント数」「退職・契約終了後も残っているアカウント数」「期限のない例外権限数」の4項目を数値で記録すると、権限管理の変化を追えます。たとえば、管理者アカウントが12件あり、そのうち4件の職務上の根拠を説明できない場合は、該当アカウントを共通ロールへ集約するか、期限付き例外として再承認する対象になります。
また、SaaSの管理画面で確認できるロール一覧と、IDプロバイダ側のグループ一覧が一致していない場合があります。SCIM連携を利用する環境では、IDプロバイダのプロビジョニング設定画面と、SaaS側のユーザー・ロール一覧を照合し、停止済みユーザーが残る場合は連携エラー、手動作成アカウント、同期対象外グループのいずれかとして扱います。
複数のSaaSへユーザー情報や権限設定を効率的に自動同期・管理したい方は、SCIMによる自動プロビジョニングの仕組みとSAMLとの違いを参考にしてください。
RBAC運用で起こりやすい失敗
RBACの導入後に起こりやすい失敗は、ロールを細分化しすぎることです。「営業東京第一課の新規担当者」「営業東京第一課の既存担当者」のように組織や一時的な事情をすべてロールへ反映すると、異動や組織変更のたびに設計が崩れます。職務として安定した共通部分はロールにし、短期的な差分は期限付きの例外権限として扱います。
もう一つは、管理者ロールを日常業務に使い続けることです。日常利用用のアカウントと管理操作用のアカウントを分け、権限変更や重要設定の操作履歴を監査ログで追える状態にします。SaaSの監査ログ画面で、ユーザー作成、権限変更、データ出力、APIキー発行を確認できる場合は、レビュー対象の操作として記録します。
RBACは一度設計して終わるものではありません。事業部の新設、M&A、SaaS入れ替え、委託先の変更などで業務と責任範囲が変わるため、ロールと実際の業務のずれを定期的に点検します。
まとめ
RBACは、ユーザーではなく役割に権限を割り当てることで、SaaSや社内システムのアクセス管理を整理する仕組みです。情シスでは、まず利用中のSaaS、アカウント、特権権限、退職者アカウントを棚卸しし、共通ロールと例外権限を分けて可視化します。
時間帯、端末状態、接続元などの動的条件が必要な範囲では、RBACを土台にABACや条件付きアクセスを重ねます。明日着手するなら、権限一覧から「誰に、なぜ、その権限があるか説明できないアカウント」を抽出し、ロールへの集約または期限付き例外権限への置き換えを始めます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
