導入編／テナントの初期設定

権限設計の考え方

NinjaOneの権限設計の判断基準を説明します。機能と対象の2つの軸、最小権限の原則、ヘルプデスクやインフラ運用など役割別の設計例、設計時のチェックポイントを紹介します。

誰に何を許可するかを設計します。操作手順はユーザーの追加とロールで説明しているので、ここでは設計の判断基準を扱います。

権限が及ぶ範囲

NinjaOneの権限は2つの軸で決まります。この2つを分けて考えると設計が整理できます。

軸	制御する内容
機能の軸	何ができるか。レポートの実行、スクリプトの実行、リモート接続など
対象の軸	どのOrganizationのデバイスを扱えるか

機能の軸だけを設計して対象の軸を忘れると、ヘルプデスク担当者が全顧客のデバイスを操作できる状態になります。MSPでは特に注意が必要です。

必要な権限だけを与え、足りなければ後から追加する。これが基本です。

逆の進め方、つまり広めに与えて後から絞る方法は、実務ではまず機能しません。一度使えていた機能を取り上げると業務が止まるため、結局そのまま残ります。

権限のレベルはドロップダウンで選びます。初期値はNo Accessです。

初期値がNo Accessである点は設計上ありがたい仕様です。何も設定しなければ何もできないため、意図せず広い権限を与えてしまう事故が起きにくくなっています。

利用者からの問い合わせを受け、簡単な対応を行う役割です。

Policyやパッチ適用を設計・実行する役割です。

状況を把握するだけで、変更は行わない役割です。経営層や監査担当に向いています。

担当するOrganizationだけを見せる設定は、MSPでは必須です。顧客Aの担当者が顧客Bのデバイス情報を見られる状態は、契約上の問題になり得ます。

社内利用でも、グループ会社を別Organizationで管理している場合は同様の配慮が必要です。

設計が終わったら、次を確認してください。

#	確認内容
1	管理者権限を持つユーザーが2人以上いるか
2	管理者権限を持つユーザーが必要以上に多くないか
3	ヘルプデスク担当がPolicyを編集できる状態になっていないか
4	担当外のOrganizationが見える状態になっていないか
5	退職者のアカウントが有効なまま残っていないか
6	スクリプト実行を許可した相手が、その影響範囲を理解しているか

6番目は特に重要です。スクリプトの実行権限は、実質的にデバイス上で任意のコマンドを実行できる権限です。リモート接続の権限より影響が大きいことを、付与する側も受ける側も認識しておく必要があります。

【運用のポイント】権限は四半期に一度見直してください。異動や退職の反映漏れは、時間が経つほど気付きにくくなります。見直しの手順は日常運用チェックリストにまとめています。