※本文根據本公司內部討論、經驗及一般安全性原則彙整而成。並非特定企業、組織的官方見解,也不代表特定廠商的內部實作。
✅ 免責聲明 #
-
本文內容旨在介紹資訊系統的一般設計與營運思維,並不保證對所有組織的安全性與適用性。
-
實際導入時,建議根據自身組織規模、產業、風險承受度、法規及合約義務等因素,諮詢專家意見並進行內部審查。
-
對於因依據本文進行之營運、設定、組織變更等所導致的任何損害,作者及所屬組織概不負責。
前言:一人「全知」狀態既強大又危險 #
在基礎架構、雲端、安全性領域中,
「無所不能、無所不知的”神級工程師”」往往備受重視。
然而,這同時也潛藏著以下風險:
-
該人員離職後營運將無法運作(Bus Factor 為 1)
-
權限過度集中,誤操作或事件發生時影響致命
-
從安全性角度來看,形成「內部犯罪風險」高的結構
在大型雲端服務、金融機構、SWIFT 等領域,
為避免此問題,「任何人都無法掌控全局的架構」已逐漸成為常識。
不過,同樣做法若直接套用於中小型組織,
管理成本將暴增,現場將難以負荷……這也是現實情況。
因此,本文整理了**即使中小型至中型組織也易於導入的「輕量零信任分割模型」**。
模型目標 #
本模型的目標是達成以下狀態。
-
✅ 消除一人「全知且全能操作」的狀態
-
✅ 日常營運不會過於複雜
-
✅ 緊急時能確實應對(考慮緊急處理)
「零信任」聽起來或許很誇張,
但在此只需理解為“人員與系統都僅能存取所需資源”即可。
步驟1:將角色分為 3 類(領域分割) #
首先從超簡單的方式開始,
將系統分為 3 個領域來思考。
A. 基礎架構負責人 #
-
虛擬化平台(VMware / Proxmox / Hyper-V 等)
-
作業系統(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. 維護管理者（基礎架構／應用程式管理） #
-
虛擬機建立・刪除
-
儲存磁碟區新增
-
網路設定變更
-
中介軟體更新・設定變更
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 標準化部署
-
即使使用 Shell Script 也可以,將手動作業腳本化
重點在於,
「減少人員直接操作主控台的次數」
這個方向。
步驟5：秘密資訊交給「系統」而非「人」管理 #
SSH 私密金鑰、API 金鑰、密碼、憑證——
重要的是不要將這些資訊放在個人的本機電腦或個人管理中。
代表性方法 #
-
密碼管理器(1Password、Bitwarden、KeePass 等)
-
秘密管理服務(Vault、AWS Secrets Manager 等)
-
不要以明文方式放在 Git 中(進行加密/轉換為參照ID)
透過系統端的權限控制「誰可以存取哪些秘密」,
目標是建立秘密不與個人綁定的結構。
步驟6:設計文件也要「分割」 #
如果文件也做成一整塊,
就只有完全理解它的人才會變得強大。
因此,設計文件也要依照角色進行分割。
-
網路設計文件(基礎設施負責人 A 管理)
-
伺服器組態・角色清單(基礎設施/應用程式共通)
-
應用程式組態文件(應用程式負責人 B 管理)
-
認證・IAM 設計文件(安全負責人 C 管理)
-
記錄・稽核設計文件(安全負責人 C)
比起「全部由一個人撰寫,只有一個人理解的設計文件」,
「由多人撰寫,依照角色分開的設計文件」更加健全。
步驟7:事先決定緊急時的「兩階段模式」 #
組織越小,
越需要避免**「緊急時誰都無法處理而陷入困境」**的模式。
因此,要區分平時和緊急時的規則。
平時 #
-
權限分離為 D1 / D2 / D3 進行營運
-
危險操作原則上僅限 D3
緊急時 #
-
例如決定「服務全面停止」「重大事件」等條件
-
領導者 + 安全負責人等2人以上同意後暫時提升權限
-
復原後取消提升,確認・檢視操作記錄
如此一來,
「平時保持分離」
「僅在真正需要時,確實留下痕跡並暫時解禁『神模式』」
可以取得這樣的平衡。
總結:「不需要神級工程師」不是理想論,而是設計問題 #
本文介紹的輕量模型總結如下。
-
將角色分割為基礎設施 / 應用程式 / 安全 3 個領域
-
將權限分為 3 個層級（操作 / 管理 / 安全），消除「隨時、什麼都能做的人」
-
妥善保留操作日誌，確保能追蹤「誰做了什麼」
-
將基礎架構與設定自動化/IaC 化，把「人腦中的知識」轉化為程式碼
-
讓系統而非人員持有機密資訊
-
依角色分割並管理設計文件
-
制定規則，僅在緊急情況下「經雙人核准後開啟神模式」
這些是大型雲服務商、金融機構、SWIFT 等採用的概念，
經過調整後能讓中小型企業至中型規模的現場也能無負擔使用的模型。
結語 #
「一個人全部都知道」的狀態，
短期來看非常方便，
但長期來看從業務持續性、安全性、組織健全性的角度來看會成為重大風險。
換句話說，
只要逐步推進「分割」「分離」「自動化」，
就能脫離「依賴神級工程師的組織」。
本文內容僅供參考，
希望各位能依照各公司的情況進行調整運用。
