在探討過防火牆規則動態調整與漏洞揭露後,我們必須面對一個殘酷的事實:企業最常被攻破的入口,往往不是堅不可摧的邊界防火牆,而是管理不善的帳號與憑證。
根據各家資安威脅報告,超過八成的入侵事件起源於「遭竊的有效憑證(Valid Accounts)」。在日常維運現場,有兩大系統掌管著整座公司的數位命脈:
雲端協作核心:以 Google Workspace(GWS) 為代表的企業信箱與檔案庫,裡面沉澱了公司所有的機密郵件、合約與業務資料。
地端維運核心:管理著資料庫與正式服務的 Linux 伺服器叢集,通常透過 SSH 協定進行特權管理。
如果這兩處節點依然停留在「簡單帳密登入」、「密碼多年不換」或「工程師共用 root 帳號」,前面的網路微隔離與 WAF 防禦做得再好,攻擊者只要拿到一組帳密,就能大搖大擺地從正門走進去。
Day 20,我們不談複雜的高深理論,而是從一線維運真正落地出發,剖析如何利用 GWS 管理後台與 Linux 底層配置,把身分存取的防線死死守住。
許多企業導入 Google Workspace 後,預設只讓同仁自訂密碼,這在現代威脅面前等同門戶大開。在 GWS Admin Console 中,維運人員必須建立三道硬性基線:
同仁習慣設定「生日+姓名」或在多個外部網站共用同一組密碼,一旦外部網站外洩名單,攻擊者便利用「憑證填充(Credential Stuffing)」長驅直入。
在 GWS 後台強制設定「要求全員啟用 2SV」,並給予新進員工 1~3 天的寬限期(Grace Period),過期未綁定則限制存取。
在安全設定中,盡可能引導同仁使用 Google Authenticator 或 Google 提示(推播),逐步停用容易遭受 SIM 卡劫持(SIM Swapping)的傳統簡訊(SMS)代碼;針對具備高權限的 IT 與資安管理員,強制要求使用 實體安全性金鑰(FIDO2 / YubiKey),徹底免疫反向代理釣魚。
同仁在日常工作中常隨意點擊「使用 Google 帳號登入」各類第三方不明外掛或排程工具,賦予其讀取 Gmail 與 Drive 的龐大權限。
管理員必須定期進入 安全性 > API 控制項,盤點已授權的第三方 App,封鎖未經審核的未受信任應用程式,避免外包工具成為資料外洩的跳板。
人員離職時,單純在後台修改密碼是不夠的,因為手機或筆電上的 OAuth Token 依然有效。標準的除役動作必須包含:
點擊「登出所有工作階段(Sign out of all sessions)」,強制吊銷所有發放中的 Token。
刪除所有已指派的 App 密碼(App Passwords)與備用碼。
走出雲端,進入機房內部,Linux 主機的 SSH 是工程師最親密的工具,卻也是資安稽核的重災區。在 /etc/ssh/sshd_config 中,必須落實以下防線:
Bash
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
禁止 Root 直連意味著所有維運人員必須以具備個人身分的帳號登入,再透過 sudo 提權。這在 CISSP 責任歸屬(Accountability) 與 ISO 27001 稽核軌跡 中至關重要——日誌裡記錄的不再是無臉的 root,而是能精準追溯到「誰在幾點幾分下了什麼指令」。
淘汰早期長度不足的 RSA(如 1024/2048 位元)金鑰,全面推動同仁生成 Ed25519 演算法金鑰(ssh-keygen -t ed25519)。它不僅體積小、計算效率高,且具備更高的抗碰撞與抗側信道攻擊能力。同時,要求金鑰在生成時必須設定 Passphrase 加密,防止工程師筆電遺失時私鑰被直接盜用。
除了 SSH 本身的配置,在主機防火牆層級必須落實「來源 IP 白名單」:
嚴禁 SSH 連接埠(預設 22 或自訂 Port)對外公網(0.0.0.0/0)直接開放。
僅允許來自內部堡壘機(Bastion Host)、辦公室出口固定 IP,或是 GlobalProtect VPN 網段的封包連入。
資安成熟度從來不需要盲目堆砌昂貴、生僻的軟體名稱。
當我們把 Google Workspace 的 2FA 政策推廣到每位同仁身上、把離職帳號的 Token 撤銷流程做成無法跳過的標準工單;當我們在 Linux 伺服器上無情地關閉 PermitRootLogin、讓每一把 SSH Key 都可被追溯——我們就是在用最扎實的工程手段,踐行著資安架構中最神聖的原則:最小特權與不可否認性。
守住了身分與特權,企業的內部基石才能在面對狂風暴雨時,真正做到堅若磐石。