RBAC（役割ベースアクセス制御）
ユーザーに役割（ロール）を割り当てることで、データやシステム機能へのアクセスを柔軟に管理できます。
📋 概要
RBAC（Role-Based Access Control）は、ユーザーに「役割（ロール）」を割り当て、その役割に応じてアクセス権限を制御する仕組みです。SURP MDMでは、4つの標準ロールと柔軟な権限設定により、セキュアで効率的なデータ管理を実現します。
主な特徴
- 役割ベースの権限管理: ユーザーごとではなく役割ごとに権限を管理
- 4つの標準ロール: システム管理者、テナント管理者、編集者、閲覧者
- きめ細かいアクセス制御: リソースごとに読取・作成・更新・削除を制御
- 画面レベルの制御: 役割に応じて表示される画面を制限
- API アクセス制御: APIキーにスコープを設定してアクセスを制限
👥 標準ロール一覧
1. System Admin（システム管理者）
権限レベル: 最高
できること:
- 全テナントの管理
- テナントの作成・削除
- 全システム設定へのアクセス
- 全データへの完全なアクセス
想定ユーザー: SaaS運営者、システム運用チーム
注意: システム管理者は tenant_id='system' の特別なテナントに所属します。通常の企業ユーザーにこの役割を割り当てないでください。
2. Admin（テナント管理者）
権限レベル: 高
できること:
- マスター定義の作成・編集・削除: データ構造の設計
- ユーザー管理: ユーザーの招待、役割変更、削除
- マスターデータの全操作: 作成・編集・削除・エクスポート・インポート
- 承認のスキップ: 承認設定があっても直接データを保存
- APIキー管理: APIキーの作成・削除
- テナント設定: 全般的なテナント設定の変更
- プロビジョニング設定: 外部システムとの連携設定
- 監査ログの閲覧: すべての操作履歴の確認
できないこと:
- 他のテナントのデータへのアクセス
- サブスクリプションプランの変更（支払い情報の変更）
想定ユーザー: 企業の情報システム部門、IT管理者
3. Editor（編集者）
権限レベル: 中
できること:
- マスターデータの作成・編集・削除: 通常のデータ操作
- CSVインポート・エクスポート: データの一括操作
- 承認リクエストの作成: 承認設定があるマスターでは承認申請
- 承認・却下: 承認者として指定されている場合
- ファイルのアップロード・削除: 添付ファイルの管理
- 変更履歴の閲覧: 自分のテナントのデータ履歴
- AI機能の利用: AI入力支援、検証、データクレンジング
できないこと:
- マスター定義の作成・編集
- ユーザー管理
- テナント設定の変更
- APIキーの管理
- 監査ログの閲覧
想定ユーザー: 人事部門、総務部門、データ管理担当者
4. Viewer（閲覧者）
権限レベル: 低
できること:
- マスターデータの閲覧: すべてのマスターデータの参照
- CSVエクスポート: データのダウンロード（読み取り専用）
- 変更履歴の閲覧: データの変更履歴の確認
- 承認リクエストの閲覧: 自分の申請や全体の承認状況の確認
- AI検索の利用: AIを使ったデータ検索
- レポートの閲覧: 各種レポートの参照
できないこと:
- データの作成・編集・削除
- CSVインポート
- ファイルのアップロード・削除
- 承認・却下の実行
- マスター定義の閲覧・編集
- ユーザー管理
- 全ての設定変更
想定ユーザー: 一般社員、データ参照のみが必要な部門
🎯 役割の選び方
最小権限の原則
セキュリティのベストプラクティスとして、必要最小限の権限を付与します。
例:
- データを見るだけでよい → Viewer
- データを編集する必要がある → Editor
- システム全体を管理する → Admin
役割ごとの割り当て目安
| 部門 | 推奨ロール | 理由 |
|---|---|---|
| 情報システム部門 | Admin | システム全体の管理が必要 |
| 人事部門（管理者） | Editor | 従業員データの編集が必要 |
| 人事部門（一般） | Viewer | 従業員データの参照のみ |
| 総務部門 | Editor | 備品・施設データの編集が必要 |
| 経理部門 | Editor | 勘定科目などの編集が必要 |
| 営業部門 | Viewer | 顧客データの参照のみ |
| 一般社員 | Viewer | 基本的に参照のみ |
🎯 マスター単位の権限設定
基本的なロール（Admin / Editor / Viewer）に加えて、特定のマスター定義ごとに詳細な権限を設定できます。
概要
マスターごとに、ユーザーやロールに対して以下の4つの権限を個別に制御できます：
- 読取（Read）: データの閲覧
- 作成（Create）: 新規レコードの作成
- 更新（Update）: 既存レコードの編集
- 削除（Delete）: レコードの削除
使用例
例1: 人事マスターのアクセス制限
要件: 人事マスター（従業員情報）は人事部のみ編集可能にしたい
設定:
| ユーザー/ロール | Read | Create | Update | Delete |
|---|---|---|---|---|
| 人事部（Admin） | ✅ | ✅ | ✅ | ✅ |
| 人事部（Editor） | ✅ | ✅ | ✅ | ❌ |
| 一般社員（Viewer） | ✅ | ❌ | ❌ | ❌ |
| 営業部（Editor） | ❌ | ❌ | ❌ | ❌ |
結果: 営業部のEditorでも、人事マスターは閲覧すらできません。
例2: 商品マスターの部門別権限
要件: 商品マスターは部門によって権限を分ける
設定:
| ユーザー/ロール | Read | Create | Update | Delete |
|---|---|---|---|---|
| 商品企画部 | ✅ | ✅ | ✅ | ✅ |
| 営業部 | ✅ | ❌ | ✅ | ❌ |
| 在庫管理部 | ✅ | ❌ | ✅ | ❌ |
| 一般社員 | ✅ | ❌ | ❌ | ❌ |
結果:
- 商品企画部：全権限
- 営業部・在庫管理部：閲覧と更新のみ（在庫数や価格の更新）
- 一般社員：閲覧のみ
例3: 機密マスターの完全非公開
要件: 役員報酬マスターは経営層のみアクセス可能
設定:
| ユーザー/ロール | Read | Create | Update | Delete |
|---|---|---|---|---|
| 社長・役員 | ✅ | ✅ | ✅ | ✅ |
| その他全員 | ❌ | ❌ | ❌ | ❌ |
結果: 指定されたユーザー以外は、マスターの存在自体が見えません。
設定手順
ステップ1: マスター定義の詳細画面を開く
- ダッシュボード → マスター定義一覧
- 権限を設定したいマスター定義をクリック
ステップ2: 権限設定タブを開く
- 「権限設定」タブをクリック
ステップ3: 権限を追加
- 「権限を追加」ボタンをクリック
- ユーザーまたはロールを選択
- 権限（Read / Create / Update / Delete）をチェック
- **「保存」**をクリック
ステップ4: 権限の確認
設定した権限が一覧表示されます：
| ユーザー/ロール | Read | Create | Update | Delete | 操作 |
|----------------|------|--------|--------|--------|------|
| 人事部 山田太郎 | ✅ | ✅ | ✅ | ✅ | 編集・削除 |
| 営業部 佐藤花子 | ✅ | ❌ | ❌ | ❌ | 編集・削除 |権限の優先順位
複数の権限設定が競合する場合、最も高い権限が適用されます。
例:
- ロール「Editor」で Update = ❌
- ユーザー「佐藤花子」で Update = ✅
- 結果：佐藤花子は Update 可能
デフォルト権限
マスター単位の権限設定がない場合、基本ロールの権限が適用されます：
| ロール | Read | Create | Update | Delete |
|---|---|---|---|---|
| Admin | ✅ | ✅ | ✅ | ✅ |
| Editor | ✅ | ✅ | ✅ | ✅ |
| Viewer | ✅ | ❌ | ❌ | ❌ |
注意事項
- Admin ロールは、マスター単位の権限設定を無視して常に全権限を持ちます
- 権限設定は即座に反映されます（キャッシュなし）
- 権限がない操作を実行しようとすると、403エラーが表示されます
🛠️ ユーザーへの役割割り当て方法
ステップ1: ユーザー管理画面を開く
- ダッシュボード → ユーザー
- 役割を変更したいユーザーを選択
アクセス権限: Admin ロールのみ
ステップ2: 役割を変更
- ユーザーの「編集」ボタンをクリック
- 「ロール」のドロップダウンから役割を選択
- System Admin（通常は使用しない）
- Admin
- Editor
- Viewer
- 「保存」ボタンをクリック
ステップ3: 変更の確認
役割を変更すると、即座に反映されます。
- 変更されたユーザーは次回ログイン時に新しい権限が適用されます
- 現在ログイン中の場合、再ログインすると新しい権限が有効になります
🔒 リソースごとのアクセス制御
SURP MDMでは、以下のリソースごとにアクセス制御が行われます。
マスターデータ
| ロール | 閲覧 | 作成 | 編集 | 削除 | エクスポート | インポート |
|---|---|---|---|---|---|---|
| System Admin | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Admin | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Editor | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Viewer | ✅ | ❌ | ❌ | ❌ | ✅ | ❌ |
マスター定義
| ロール | 閲覧 | 作成 | 編集 | 削除 |
|---|---|---|---|---|
| System Admin | ✅ | ✅ | ✅ | ✅ |
| Admin | ✅ | ✅ | ✅ | ✅ |
| Editor | ❌ | ❌ | ❌ | ❌ |
| Viewer | ❌ | ❌ | ❌ | ❌ |
ユーザー管理
| ロール | 一覧表示 | 招待 | 編集 | 削除 |
|---|---|---|---|---|
| System Admin | ✅ | ✅ | ✅ | ✅ |
| Admin | ✅ | ✅ | ✅ | ✅ |
| Editor | ❌ | ❌ | ❌ | ❌ |
| Viewer | ❌ | ❌ | ❌ | ❌ |
承認ワークフロー
| ロール | 閲覧 | 申請 | 承認 | 却下 |
|---|---|---|---|---|
| System Admin | ✅ | ✅ | ✅ | ✅ |
| Admin | ✅ | ✅ | ✅（承認スキップ可） | ✅ |
| Editor | ✅ | ✅ | ✅（承認者の場合） | ✅（承認者の場合） |
| Viewer | ✅ | ❌ | ❌ | ❌ |
ファイル管理
| ロール | 閲覧 | アップロード | ダウンロード | 削除 |
|---|---|---|---|---|
| System Admin | ✅ | ✅ | ✅ | ✅ |
| Admin | ✅ | ✅ | ✅ | ✅ |
| Editor | ✅ | ✅ | ✅ | ✅ |
| Viewer | ✅ | ❌ | ✅ | ❌ |
監査ログ
| ロール | 閲覧 | 統計情報 |
|---|---|---|
| System Admin | ✅ | ✅ |
| Admin | ✅ | ✅ |
| Editor | ❌ | ❌ |
| Viewer | ❌ | ❌ |
APIキー管理
| ロール | 一覧 | 作成 | 削除 |
|---|---|---|---|
| System Admin | ✅ | ✅ | ✅ |
| Admin | ✅ | ✅ | ✅ |
| Editor | ❌ | ❌ | ❌ |
| Viewer | ❌ | ❌ | ❌ |
注意: APIキー認証では、APIキー管理エンドポイントにアクセスできません（セキュリティ上の理由）。
プロビジョニング
| ロール | 閲覧 | 連携設定 | 実行 |
|---|---|---|---|
| System Admin | ✅ | ✅ | ✅ |
| Admin | ✅ | ✅ | ✅ |
| Editor | ❌ | ❌ | ❌ |
| Viewer | ❌ | ❌ | ❌ |
🔑 APIキーとスコープ
APIキーを使った外部システム連携では、スコープによってアクセス範囲を制限できます。
APIキースコープ一覧
| スコープ | 説明 | 許可される操作 |
|---|---|---|
| read | 読み取り専用 | GET, HEAD, OPTIONS |
| write | 書き込み | POST, PUT, PATCH |
| delete | 削除 | DELETE |
スコープの組み合わせ
APIキーには複数のスコープを同時に設定できます。
例:
readのみ → データの参照のみ可能read+write→ データの参照と作成・更新が可能read+write+delete→ すべての操作が可能
APIキーでアクセスできないエンドポイント
セキュリティ上の理由で、以下のエンドポイントはAPIキー認証ではアクセスできません:
- APIキー管理:
/api/v1/api-keys - サブスクリプション管理:
/api/v1/subscriptions - 個人通知:
/api/v1/notifications
これらの機能にアクセスするには、通常のユーザー認証（JWT）が必要です。
💡 よくある質問
Q1. ユーザーの役割は後から変更できますか?
A: はい、いつでも変更できます。
Admin ロールのユーザーがユーザー管理画面からいつでも変更可能です。変更は即座に反映されます。
Q2. 役割を変更すると、既存のデータはどうなりますか?
A: データは変更されません。
役割の変更は、そのユーザーのアクセス権限のみを変更します。過去に作成・編集したデータはそのまま残ります。
Q3. 自分で自分の役割を変更できますか?
A: できません。
セキュリティ上の理由で、自分自身の役割は変更できません。他のAdmin ロールのユーザーに変更してもらう必要があります。
Q4. Admin が1人しかいない場合、その人を削除できますか?
A: システムが警告を表示しますが、削除は可能です。
Admin が0人になると、ユーザー管理ができなくなるため、最低1人のAdmin を残すことを推奨します。Admin が0人になった場合は、System Admin に連絡してください。
Q5. Editor が承認者に指定されている場合、承認できますか?
A: はい、承認できます。
承認ワークフローでは、承認者として指定されているユーザーは、自分のロールに関係なく承認・却下が可能です。
Q6. Viewer でも承認リクエストを見ることができますか?
A: はい、閲覧のみ可能です。
Viewer は承認リクエストの一覧と詳細を閲覧できますが、承認・却下の操作はできません。
Q7. APIキーのスコープを後から変更できますか?
A: 現在のバージョンでは、APIキーのスコープは変更できません。
スコープを変更したい場合は、既存のAPIキーを削除して、新しいスコープで新規作成してください。
Q8. 役割ごとに表示される画面が異なりますか?
A: はい、役割によって表示される画面が制限されます。
例えば、Viewer には「マスター定義」や「ユーザー管理」のメニューが表示されません。Admin のみが全ての画面にアクセスできます。
🛡️ セキュリティのベストプラクティス
1. 最小権限の原則
ユーザーには、業務に必要な最小限の権限のみを付与します。
例:
- データを見るだけでよい → Viewer
- データを編集する必要がある → Editor
- 「念のため」でAdmin を付与しない
2. 定期的な権限レビュー
3ヶ月に1回程度、各ユーザーの役割が適切かレビューします。
確認項目:
- 退職者のアカウントが無効化されているか
- 部署異動で権限が不要になったユーザーがいないか
- 過剰な権限を持つユーザーがいないか
3. 複数のAdmin を設定
Admin が1人だけだと、その人が不在の時に管理操作ができません。最低2〜3人のAdmin を設定することを推奨します。
4. APIキーのスコープを最小限に
外部システム連携でAPIキーを使用する場合、必要最小限のスコープのみを付与します。
例:
- データ参照のみが必要 →
readのみ - データの作成・更新が必要 →
read+write - 削除が必要な場合のみ →
deleteを追加
5. APIキーの定期的なローテーション
セキュリティ強化のため、APIキーは定期的に再作成します（3〜6ヶ月に1回程度）。
🔗 関連機能
📞 サポート
RBAC（役割ベースアクセス制御）に関する質問は、よくある質問をご覧いただくか、システム管理者にお問い合わせください。