※本記事は、弊社内での議論・経験および一般的なセキュリティ原則をもとにまとめた内容です。特定企業・組織の公式見解や、特定ベンダーの内部実装を示すものではありません。
✅ 免責事項 #
-
本記事の内容は、情報システムの一般的な設計・運用の考え方を紹介するものであり、すべての組織に対して安全性・適合性を保証するものではありません。
-
実際の導入にあたっては、自社の規模・業種・リスク許容度・法規制・契約義務などを踏まえ、専門家の助言や内部レビューを行うことを推奨します。
-
本記事に基づいて行われた運用・設定・組織変更等により発生したいかなる損害についても、著者および所属組織は一切の責任を負いません。
はじめに：一人が「全部知っている」状態は強くて危険 #
インフラ・クラウド・セキュリティの世界では、
「何でもできて何でも知っている“神エンジニア”」が重宝されがちです。
しかし同時に、これはこんなリスクも孕んでいます：
-
その人がいなくなったら運用が回らない（Bus Factor が 1）
-
権限が集中しすぎて、誤操作・インシデント時の影響が致命的
-
セキュリティ的にも「内部犯行リスク」が高い構造になる
大規模クラウドや金融機関、SWIFT などの世界では、
この問題を避けるために 「誰も全体を支配できない構造」 が常識になりつつあります。
とはいえ、同じことをそのまま中小規模の組織でやろうとすると、
管理コストが爆増して現場がもたない……という現実もあります。
そこで本記事では、**中小〜中規模組織でも導入しやすい「軽量ゼロトラスト分割モデル」**を整理してみました。
モデルのゴール #
このモデルで目指すのは、次のような状態です。
-
✅ 一人が「全部知っていて・全部触れる」状態をなくす
-
✅ それでも日々の運用は複雑になりすぎない
-
✅ いざという時はちゃんと動ける（緊急対応も考慮）
「ゼロトラスト」と聞くと大げさに聞こえますが、
ここでは “人もシステムも、必要なものにだけアクセスさせる” ぐらいのイメージで OK です。
ステップ1：役割を 3 つに分ける（ドメイン分割） #
まずは超シンプルに、
システムを 3 つのドメインに分けて考えるところから始めます。
A. インフラ担当 #
-
仮想基盤（VMware / Proxmox / Hyper-V など）
-
OS（Linux / Windows）
-
ストレージ
-
基本ネットワーク
-
バックアップ基盤
B. アプリ担当 #
-
Web / API サーバ
-
ミドルウェア（Nginx / Apache / Redis / MQ など）
-
データベース
-
CI/CD パイプライン
-
アプリケーション設定・デプロイ
C. セキュリティ・認証担当 #
-
IAM / アカウント管理
-
VPN / SSO / AD / LDAP
-
権限設計
-
証明書・鍵管理
-
ログ・監査基盤
ポイント：
同一人物が A + B + C の全部をフル権限で握らない ようにする。
小さい組織でも、
-
メイン担当 + サブ担当
-
あるいは「ここまでは触れるが、ここから先は別の人に依頼」
という線引きを明文化しておくだけで、リスクはかなり下がります。
ステップ2：権限レベルを「3段階だけ」用意する #
ゼロトラストと聞くと、細かい RBAC やロール設計をイメージしがちですが、
小規模現場ではやりすぎると破綻します。
そこであえて 3段階だけに絞ります。
D1. オペレーター（運用オペ） #
-
監視やログ閲覧
-
サービスの再起動
-
簡単なコンフィグ変更
-
手順書どおりの操作
D2. メンテナンス管理者（インフラ／アプリ管理） #
-
VM 作成・削除
-
ストレージボリューム追加
-
ネットワーク設定変更
-
ミドルウェア更新・設定変更
D3. セキュリティ管理者（IAM / 認証） #
-
アカウント作成・削除
-
ロール・グループの定義変更
-
パスワードポリシー変更
-
VPN / 鍵 / 証明書のライフサイクル管理
絶対ルール：
D2（メンテナンス管理者） と D3（セキュリティ管理者）を
同一人物が“常時”兼任しない。
つまり、「VM も IAM も何でもできるスーパー管理者」を常態化させない。
どうしても人数的に兼任が必要なら、
-
普段はどちらか片方だけを有効にしておき
-
もう片方は緊急用の昇格手順＋ログ付きで一時利用
という形にするのがおすすめです。
ステップ3：操作ログを「ちゃんと残す」だけでもかなり強い #
完璧な権限設計ができなくても、
「誰がいつ何をしたか」が追えるだけで、抑止力と安心感が段違いです。
例 #
-
仮想基盤：監査ログ（Proxmox / vCenter の Audit Log など）
-
OS：
journalctl/auditd -
ネットワーク機器：syslog 集約
-
IaC / Git：コミットログ・Pull Request
最低ラインとして：
-
重要コンポーネントはすべて何らかの形でログ出力を有効化
-
ログはできれば一箇所に集約（syslog サーバやログ基盤）
-
「誰が・いつ・どのアカウントで・何をしたか」が分かる形にする
ログが残るだけで、
「勝手なことをしづらい環境」が自然とできあがります。
ステップ4：自動化・IaCで「人の頭の中」をシステムに出す #
属人化の大きな原因は、
「設定や構成が、その人の頭の中にしかない」
ことです。
ここを壊す最短ルートが、**自動化と IaC（Infrastructure as Code）**です。
例 #
-
Terraform でクラウド／仮想基盤の構成管理
-
Ansible で OS / ミドルウェア設定の共通化
-
GitHub Actions / GitLab CI でデプロイを標準化
-
シェルスクリプトでもよいので、手作業をスクリプト化
ポイントは、
「人が直接コンソールを触る回数を減らしていく」
という方向性です。
ステップ5：秘密情報は「人」ではなく「システム」に預ける #
SSH 秘密鍵、API キー、パスワード、証明書——
こういった情報を 個人のローカルPCや個人管理に置かないことが重要です。
代表的な方法 #
-
パスワードマネージャ（1Password, Bitwarden, KeePass など）
-
Secrets 管理サービス（Vault, AWS Secrets Manager 等）
-
Git に平文で置かない（暗号化／参照ID化する）
「誰がどの秘密にアクセスできるか」をシステム側の権限で制御することで、
個人に秘密が紐づかない構造を目指します。
ステップ6：設計ドキュメントも「分割」しておく #
ドキュメントも一枚岩にしてしまうと、
それを全部理解している人だけが強くなります。
そこで、設計書も役割ごとに分割しておきます。
-
ネットワーク設計書（インフラ担当 A が管理）
-
サーバ構成・役割一覧（インフラ／アプリ共通）
-
アプリケーション構成書（アプリ担当 B が管理）
-
認証・IAM 設計書（セキュリティ担当 C が管理）
-
ログ・監査の設計書（セキュリティ担当 C）
「全部一人で書いて、一人しか理解していない設計書」よりも、
「複数人で書いて、役割ごとに分かれている設計書」の方が健全です。
ステップ7：緊急時のための“二段階モード”を決めておく #
小さな組織ほど、
**「緊急時に誰も何もできなくて詰む」**パターンを避ける必要があります。
そこで、平時と緊急時でルールを分けます。
平時 #
-
権限は D1 / D2 / D3 に分離して運用
-
危険な操作は原則として D3 のみ
緊急時 #
-
例えば「サービス全面停止」「重大インシデント」などの条件を決める
-
リーダー + セキュリティ担当など 2名以上の合意で一時的に権限昇格
-
復旧後は昇格を戻し、操作ログを確認・レビュー
そうすることで、
「普段は分離したまま」
「本当に必要な時だけ、ちゃんと痕跡を残して一時的に“神モード”を解禁」
というバランスを取ることができます。
まとめ：「神エンジニア不要」は理想論ではなく、設計の問題 #
本記事で紹介した軽量モデルをまとめると、次のようになります。
-
インフラ / アプリ / セキュリティの 3 ドメインに役割を分割する
-
権限を 3 段階（オペ / 管理 / セキュリティ）に分け、「常時・何でもできる人」をなくす
-
操作ログをきちんと残し、「誰が何をしたか」を追える状態にする
-
インフラ・設定を自動化/IaC化し、「人の頭の中」をコードに落とす
-
秘密情報は人ではなくシステムに持たせる
-
設計書も役割ごとに分割して管理する
-
緊急時だけ“2名承認付きで神モードを解禁”するルールを決める
これらは、大手クラウドや金融機関・SWIFT などで使われている考え方を、
中小〜中規模の現場でも無理なく使えるように薄めたモデルです。
おわりに #
「一人が全部知っている」状態は、
短期的にはものすごく便利ですが、
長期的には ビジネス継続性・セキュリティ・組織の健全性の観点から大きなリスクになります。
逆に言うと、
少しずつでも「分割」「分離」「自動化」を進めていけば、
“神エンジニア前提の組織” から脱却していけるということでもあります。
本記事の内容はあくまで一つのたたき台なので、
各社の事情に合わせてアレンジしていただければ幸いです。
