本ページでは、管理者が権限制御を設定する方法を説明します。
事前確認
設計が必要なケース
- 管理者のアクセスできるメンバー情報を詳細に制御したい
設計が不要なケース
- チーム内の管理者が全員システム管理者である
- 現時点の権限制御で充足している
また、このページを読む前に、以下のヘルプページで基本概念を理解しておくことをお勧めします。
権限制御の3要素
IT Expert Services SaaS管理における権限制御は、以下の3つの要素を組み合わせることで実現されます。
アセットグループ×管理権限グループ×管理権限
アセットグループ
「誰を」「何を」管理するかを定義する単位です。
メンバーやアプリなどのリソースを、部門・拠点・プロジェクトなどの軸でグループ化します。
例：
- 営業部
- 開発部
- 東京オフィス
- プロジェクトA
管理権限グループ
「どのアセットグループを管理できるか」を定義するグループです。
管理者を管理権限グループに所属させることで、特定のアセットグループに対する管理範囲を設定します。
例：
- 営業部管理者グループ → 営業部のアセットグループを管理
- 全社人事管理者グループ → 全てのアセットグループを管理
- IT管理者グループ → 営業部と開発部のアセットグループを管理
管理権限
管理者が「何ができるか」を定義する権限です。
管理者に対して、メンバー管理・アプリ管理などの具体的な操作権限を付与します。
-
主な管理権限：
- メンバー管理権限
- アプリ管理権限
- ファイル管理権限
- 備品管理権限
- 検知アプリ管理権限
- オートメーション
- アクセスグループ
- アラート機能
- 棚卸しアンケート
3要素の組み合わせによる権限制御
これら3つの要素を組み合わせることで、柔軟かつ細かな権限制御が可能になります。
| 要素 | 役割 | 具体例 |
|---|---|---|
| アセットグループ | 管理対象の範囲を定義 | 営業部のメンバー5名とアプリ10個をグループ化 |
| 管理権限グループ | 管理できるアセットグループを指定 | 「営業部管理者グループ」は「営業部」のアセットグループを管理できる |
| 管理権限 | 具体的な操作内容を定義 |
「営業部管理者グループ」に以下を付与
|
最小権限の原則
管理者には、業務に必要な最小限の権限のみを付与してください。
「念のため」と全ての権限を付与すると、セキュリティリスクが高まります。
- 閲覧のみ権限の活用：情報確認のみが必要な管理者には「閲覧のみ」権限を付与します。
- 段階的な権限付与：最初は限定的な権限から始め、必要に応じて追加します。
- 定期的な見直し：付与した権限が適切か、定期的に確認します。
アセットグループ×管理権限グループの組み合わせパターン
アセットグループと管理権限グループの組み合わせ方によって、様々な権限制御が可能です。
代表的なパターンを紹介します。
パターンA：部門別の独立管理（1対1）
| アセットグループ | 営業部 |
|---|---|
| 管理権限グループ | 営業部管理者 |
| 適用場面 | 組織構造がシンプルで、部門ごとに独立した管理が可能な場合 |
| メリット |
|
パターンB：統括管理者による複数部門管理（1対多）
| アセットグループ | 営業部、マーケティング部、カスタマーサクセス部 |
|---|---|
| 管理権限グループ | 事業部門統括管理者 |
| 適用場面 | 複数部門を統括する管理者が存在する場合 |
| メリット |
|
パターンC：役割別の専門管理（多対多）
| アセットグループ | 営業部、開発部 |
|---|---|
| 管理権限グループA |
営業部管理者（営業部のみ） 【付与する権限】
|
| 管理権限グループB |
開発部管理者（開発部のみ） 【付与する権限】
|
| 管理権限グループC |
アプリ管理専任者（営業部と開発部の両方のアプリを管理） 【付与する権限】
|
| 適用場面 | 機能別の専任管理者を配置する場合 |
| メリット |
|
最初はパターンAのシンプルな構成から始めて、組織の成長や管理ニーズに応じて、パターンBやCに移行することをお勧めします。
よくある失敗パターンと対策
実際の運用でよく見られる失敗パターンと、その対策を紹介します。
| 失敗パターン | 問題点 | 推奨される対策 |
|---|---|---|
| 過度な細分化 | 「東京営業1課」「東京営業2課」のようにアセットグループを細かく分けすぎると、管理が煩雑になり、兼務メンバーやアプリの配置に困ります。 | 「営業部」のような包括的な単位にし、詳細な権限制御は管理権限グループで対応します。 |
| 命名規則の不統一 | 「営業」「開発部」「Tokyo Office」など命名規則がバラバラだと、管理者が混乱します。 |
事前に命名規則を決定します。
|
| デフォルトアセットグループの放置 | 新規メンバーやアプリがデフォルトアセットグループに配置されたまま放置され、適切な管理ができなくなります。 | 定期的な棚卸しを実施し、適切なアセットグループへの移動を計画的に行います。 |