保管庫の切り方の考え方は、組織の大きさによらず同じです。それでも、人数と情報システム部門の体制によって落ち着く形は変わります。小さな組織で細かく切れば見直しが回らなくなり、大きな組織で少なく切れば、広すぎる保管庫が生まれます。このページでは、規模によらない共通の土台、50人未満、50〜300人、300人以上の3つの構成例、次の規模に移るときの手順、規模より先に構成を左右する条件を説明します。どれも出発点の例です。切り方の軸は保管庫の分割パターン、グループ会社とMSPの構成はテナント構成の選択（単独、親子、グループ会社、MSP）で扱います。
規模によらない共通の土台
どの規模でも、最初に次の5つをそろえます。
所有者を2人以上にします。所有者は全ての共有保管庫を管理できるので、人選がそのまま機密度の高い保管庫の設計に効きます。- 全員向けの保管庫には、全員に見えて困らないものだけを入れます。
- 管理用の保管庫を、情報システム部門の一般の保管庫とは別に作ります。SaaSの管理者アカウント、ドメインとDNS、ネットワーク機器などが対象です。
- 退職と異動の引き継ぎに使う保管庫を1つ用意します。
- 保管庫を作れる人と、名前の付け方を決めます。
3つの規模の構成例
保管庫の数は目安です。見せる相手が同じなら、例より少なくて構いません。
50人未満の組織
情報システム部門が兼任の1〜2人という体制を想定します。保管庫は5〜10本に収め、情報システム部門だけが作ります。チームメンバーからは保管庫の作成を外しておきます。
| 保管庫 | 中身 | アクセス |
|---|---|---|
| 全員向け | 来客用のネットワーク、全社共通のライセンス | 全員 |
| 部門ごと（2〜4本） | 部門の業務用アカウント | 部門のグループ |
| 管理用 | SaaSの管理者アカウント、ドメイン、ネットワーク機器 | 情報システム部門の担当者 |
| 役員と人事 | 給与、労務、契約 | 担当者のみ |
| 引き継ぎ用 | 退職と異動の受け皿 | 情報システム部門の担当者 |
グループは画面で作る手動のもので足ります。この規模では、情報システム部門の担当者がMicrosoft 365やGoogle Workspaceの管理者も兼ねていることが多く、アカウントの復旧を切り離せません。分けられない場合は、復旧の操作を監査ログで追ってください。役員と人事の保管庫は所有者から隠せないため、誰が所有者かを役員に説明しておきます。
50〜300人の組織
情報システム部門に専任が数人いる体制を想定します。保管庫は15〜40本になります。部門の保管庫を共通と機密の2本に分け、拠点が複数あれば拠点の保管庫を足します。外部の委託先と共有するものは、相手ごとに保管庫を分けます。
| 保管庫 | 中身 | アクセス |
|---|---|---|
| 全員向け | 来客用のネットワーク、全社共通のライセンス | 全員 |
| 部門の共通 | 部門の業務用アカウント | 部門のグループ |
| 部門の機密 | 銀行、給与、採用など、部門の一部の人だけが扱うもの | 部門内の担当者のグループ |
| 拠点ごと | 拠点の設備、来客用のネットワーク | 拠点のグループ |
| 委託先ごと | 委託先と共有するもの | 委託先のゲストと社内の担当者 |
| 管理用 | SaaSの管理者アカウント、ドメイン、ネットワーク機器 | 情報システム部門の担当者 |
| 引き継ぎ用 | 退職と異動の受け皿 | 情報システム部門と引き継ぐ担当者 |
グループはIDプロバイダーから届く形に寄せます。部門のグループと保管庫を1対1にすると、入社と異動はIDプロバイダー側の所属の変更だけで済みます。保管庫の作成は部門の責任者を集めたカスタムグループに渡し、ヘルプデスクには必要なパーミッションだけを付けたカスタムグループを作ります。
300人以上の組織
情報システム部門のほかに、部門ごとの担当者がいる体制を想定します。保管庫の数は部門の数に比例して増えるので、本数より、責任者が決まっているかを管理の指標にします。
部門の保管庫の保管庫の管理は部門の責任者に渡します。情報システム部門は、管理用の保管庫、全員向けの保管庫、命名の承認を持ちます。システムの保管庫は本番と検証に分け、自動化から読ませる値は用途ごとの専用の保管庫にします。保管庫のアクセスの変更は、Events ReportingでSIEMに送って追います。設計はログの保管とアラートの設計で扱います。
次の規模に移るとき
組織が大きくなったら、構成を1つ上の規模に寄せます。次の順で進めると、途中でアクセスが途切れません。
- 命名の規則を文書にし、部門の責任者に伝えます。
保管庫の作成を部門の責任者のグループに渡します。- 手動のグループをIDプロバイダーのグループに置き換えます。新しいグループに保管庫のアクセスを与えてから、古いグループを外します。
- 広くなりすぎた保管庫を分けます。
広い保管庫からアイテムを移しても、移動元に削除済みのアイテムが残ります。切り直すときの注意は避けるべき設計で扱います。
規模より先に効く条件
人数より、次の条件の方が構成を大きく変えることがあります。
- 外部の委託先が多い組織では、委託先ごとの保管庫とゲストが中心になります。1Password Businessの契約には20人分のゲストが含まれます。
- 開発部門がある組織では、環境ごとの保管庫とサービスアカウントの設計が先に要ります。考え方は開発者向け機能の位置付けで扱います。
- 監査や認証の対象になる組織では、保管庫ごとに管理の責任者と見直しの記録が求められます。記録の残し方は保管庫とアクセス権の棚卸しで扱います。
- グループ会社をまとめる場合は、1つのアカウントに収めるか、親子の構成にするかを先に決めます。