Policyとは：設計の考え方

NinjaOneの運用品質は、Policyの設計でほぼ決まります。個別の設定手順に入る前に、Policyが何を制御し、どう分割すべきかという設計の考え方を説明します。ここを固めてからPolicyの作成と適用に進んでください。

Policyが制御する範囲

Policyは、デバイスに対して「何を監視し、何を自動実行し、何を通知するか」をまとめて定義した設定の集合です。次のものが含まれます。

• 監視条件（Condition）としきい値
• パッチ適用のスケジュールと承認の方針
• Scheduled Automationsの実行内容とタイミング
• アンチウイルスやバックアップの動作設定
• SysTrayなど、エンドユーザーから見える部分の表示

一方で、Policyでは制御しないものもあります。ユーザーの権限、Organizationの構造、通知の宛先そのものはPolicyの外側で管理します。ここを混同すると「Policyを分けたのに通知先が変わらない」という行き違いが起きます。通知の宛先は通知先（メール・SMS・ウェブフック）の設定、権限は権限設計の考え方を参照してください。

Policyとデバイスの関係

押さえておくべき点は3つです。

1. 1台のデバイスに適用されるPolicyは1本です。複数のPolicyを重ねて適用することはできません
2. Policyの割り当てはDevice Roleを軸に行われ、OrganizationとLocationの階層に沿って決まります
3. 新しく登録されたデバイスには、所属先に設定されたPolicyが自動で適用されます

3番目が設計を先に済ませるべき理由です。Agentを展開してからPolicyを考え始めると、既に稼働しているデバイスの設定を後追いで変更することになります。最初の10台を登録するまでに設計を決めてください。

割り当ての階層

Policyは、Device RoleごとにOrganizationまたはLocationの単位で割り当てます。

つまり「このOrganizationのWindows Serverにはこのポリシー」という指定の仕方になります。Location単位で上書きすることもできます。詳しくは親ポリシーと継承・上書きで扱います。

この構造から、Device Roleの設計とPolicyの設計は連動することが分かります。Device Roleを分けなければPolicyも分けられません。分類の考え方はタグとDevice Rolesによる分類を参照してください。

もう1つ、PolicyにはDevice classという属性があります。作成時に指定するもので、後から変更できません。

Device classの例	対象
Windows Desktops and Laptops	Windowsクライアント
Windows Server	Windows Server
Mac Desktops and Laptops	macOSクライアント
Mac Server	macOSサーバー
Linux Workstation	Linuxクライアント
Linux Server	Linuxサーバー

クライアントとサーバーが別の区分になっている点に注目してください。同じWindowsでも、クライアント用のPolicyをサーバーに適用することはできません。製品の仕様として、サーバーとクライアントの分離が強制されます。

したがって、下記のパターンAで挙げた4本という構成は、最小構成であると同時に製品の構造にも沿ったものになります。

設計を始める前に決める4つのこと

紙の上で先に答えを出しておくと、Policyの本数と構造が自然に決まります。

1つめは、監視の対象が何種類あるかです。サーバーとクライアントを同じしきい値で監視することはできません。CPU使用率が90%で数時間続くことは、バッチサーバーでは正常でも、営業担当のノートPCでは異常です。

2つめは、パッチ適用のタイミングを何パターン用意するかです。「平日夜間に再起動していい」「月末は絶対に再起動できない」「24時間稼働で計画停止時のみ」。このパターン数が、Policyを分ける主な理由になります。

3つめは、例外をどこまで許容するかです。例外を認めるほど運用は柔軟になりますが、把握できなくなります。デバイス単位の上書きは「原則禁止、認める場合は台帳に記録」と決めておくのが現実的です。

4つめは、誰がPolicyを変更できるかです。Policyの変更は該当する全デバイスに一斉に効きます。変更権限は絞り、記録が残る運用にしてください。

推奨する構成パターン

パターンA：OS別に分ける（50台以下）

最小構成です。まずはこの4本から始めてください。

Policy名	対象
Server-Windows	Windows Server
Workstation-Windows	Windowsクライアント
Workstation-macOS	macOS
Server-Linux	Linux

台数が少ないうちは、これ以上分けても管理の手間が増えるだけです。

パターンB：用途別に分ける（標準構成）

台数が増えたら、再起動の可否を軸に分割します。共通設定はParent Policyに置き、子Policyには差分だけを持たせます。

Parent: Common-Base（監視・インベントリー・アンチウイルスの共通設定）
  ├─ Server-Windows-Maintenance　　（平日夜間に再起動可）
  ├─ Server-Windows-24h　　　　　　（計画停止時のみ再起動）
  ├─ Workstation-Windows-Standard
  └─ Workstation-Windows-Developer（開発者端末。ソフトウェア制御を緩和）

パターンC：MSPの場合

顧客ごとにPolicyを作ると、顧客数が増えた時点で管理できなくなります。共通のParent Policyを持ち、顧客固有の要件だけを子Policyで差分化してください。分ける単位は顧客ではなくSLAの種類です。

Parent: MSP-Base
  ├─ SLA-24x7　　　（24時間対応の顧客層）
  └─ SLA-Business　（平日日中対応の顧客層）
       └─ SLA-Business-CustomerA（この顧客だけの例外がある場合のみ作る）

顧客専用の子Policyは、例外が実際に発生してから作ります。先回りして顧客数だけ用意しないでください。

避けた方がいい設計

設計	何が起きるか
デバイスごとにPolicyを作る	台数分の設定が発生し、共通の変更が全台に行き渡らない
1本のPolicyに全て詰め込む	例外のたびに上書きが増え、どのデバイスがどの設定なのか追えなくなる
Policy名に日付や担当者名を入れる	引き継ぎ時に意味が失われる。「用途＋OS＋条件」で命名する
検証せずに本番Policyを変更する	該当する全デバイスに即座に反映される。検証用の子Policyを1本用意しておく
空のPolicyを残しておく	誤って割り当てられたときに監視が無効になり、しかも気付けない
WindowsとLinuxを同じPolicyにする	Linuxで動作しない設定が有効に見え、状態の把握を誤る

見直しのサイクル

Policyは作って終わりではありません。四半期に一度、次の点を確認してください。

• どのPolicyにも属していないデバイスがないか
• デバイス単位の上書きが想定を超えて増えていないか
• 適用台数が0のPolicyが残っていないか
• しきい値が実態に合っているか（アラート設計のベストプラクティス）