🔑 Juniper 帳號與密碼安全強化：local user、RADIUS/TACACS+ 整合與密碼原則設定
上一篇把 本機帳號、login class、管理介面存取控制 建好之後，設備數量一多就會碰到新問題：每台設備各自維護一份本機帳號，人員異動時要逐台改密碼、逐台停用帳號，稽核時也很難證明「離職員工是否還能登入設備」。這篇說明如何把 Juniper 交換器的認證，從本機帳號延伸整合到 RADIUS 或 TACACS+ 集中認證系統，以及密碼原則在稽核情境下常見的補強項目。
1️⃣ 為什麼要走集中認證
本機帳號在單台設備、小規模環境沒問題，但只要設備數量超過十台，就會出現幾個現實困境：
- 人員異動時無法「一次停用、全域生效」，只能逐台登入處理，容易遺漏。
- 密碼原則（長度、複雜度、變更週期）要在每台設備各自設定，版本一多就會不一致。
- 稽核要求「誰在何時登入哪台設備做了什麼」，本機帳號的 log 分散在各台設備上，彙整困難。
集中認證的做法是：設備上仍保留少量本機帳號（作為 AAA 伺服器失聯時的救援帳號），日常登入改走 RADIUS 或 TACACS+，帳號生命週期與稽核紀錄集中在後端系統管理。
2️⃣ RADIUS 與 TACACS+ 怎麼選
| 比較項目 | RADIUS | TACACS+ |
|---|---|---|
| 傳輸協定 | UDP（1812/1813） | TCP（49） |
| 封包加密範圍 | 僅加密密碼欄位 | 整個封包內容加密 |
| 認證與授權 | 認證（Authentication）與授權（Authorization）合併回應 | 認證、授權、記帳（AAA）三者分離，可個別控管 |
| 指令等級授權 | 不易做到逐條指令授權 | 可針對每一條 CLI 指令做授權判斷（command authorization） |
| 常見用途 | 大量使用者的網路存取認證（如 802.1X、VPN） | 網路設備管理者的 AAA，偏好用於設備治理 |
💡 如果只是要做「登入設備的帳號集中管理」，TACACS+ 通常是網路設備治理場景的主流選擇，尤其在需要記錄「誰下了哪一條指令」的稽核情境下，TACACS+ 的 command accounting 比 RADIUS 更貼近需求。RADIUS 則更常見於使用者端的網路存取認證。兩者也可以並存於不同用途，不互斥。
3️⃣ 設定 RADIUS 認證
set system radius-server 10.10.10.50 secret "your-shared-secret"
set system radius-server 10.10.10.50 port 1812
set system radius-server 10.10.10.50 timeout 5
set system radius-server 10.10.10.50 retry 2
set system authentication-order [ radius password ]
authentication-order 決定認證順序，這裡設定「先問 RADIUS 伺服器，伺服器沒回應才退回本機密碼認證」。這個順序很關鍵：如果只設 radius 而沒有 password 這個 fallback，一旦 RADIUS 伺服器斷線，會連本機帳號都登不進去，等於把自己鎖在門外。
4️⃣ 設定 TACACS+ 認證
set system tacplus-server 10.10.10.60 secret "your-shared-secret"
set system tacplus-server 10.10.10.60 port 49
set system tacplus-server 10.10.10.60 timeout 5
set system authentication-order [ tacplus password ]
語法邏輯與 RADIUS 一致，一樣要保留 password 作為 fallback。如果 TACACS+ 伺服器上有針對帳號設定對應的 login class（透過 Cisco-AVPair 或 Juniper 對應的 VSA 屬性），伺服器端回應的權限等級會覆蓋設備上本機的預設值。
5️⃣ 遠端帳號如何對應到 login class
遠端認證通過後，Junos 需要知道這個帳號該套用哪個 login class。做法有兩種：
- 伺服器端下發：AAA 伺服器（RADIUS/TACACS+）在回應中帶上對應的 class 屬性，設備直接採用。這是集中管理權限的正規做法，異動只要改伺服器端設定，不用碰任何一台交換器。
- 設備端預設：在設備上設定
remote-authentication對應規則，當伺服器沒有指定 class 時套用預設值。
set system authentication-order [ tacplus password ]
set system login user remote-users class read-only
上面這行是「找不到對應設定時的保底規則」：任何通過 TACACS+ 認證、但伺服器沒明確指定權限的帳號，一律先給 read-only，避免因為伺服器端漏設定 class 而讓帳號意外拿到過高權限。
6️⃣ 保留本機救援帳號
集中認證最怕的情境是「AAA 伺服器掛了，設備也進不去」。除了前面提到的 authentication-order fallback 之外，實務上會建議保留一到兩個本機救援帳號，密碼保管在實體保險櫃或密碼庫（如 Vault），只在 AAA 系統故障時使用，並且每次使用後都應該有登記與事後密碼更換的流程。
| 帳號類型 | 用途 | 權限建議 |
|---|---|---|
| root | 最終救援，僅限機房實體存取或 Console | super-user，密碼獨立保管 |
| 本機救援帳號（如 svc-emergency） | AAA 系統故障時的臨時登入 | super-user，密碼庫保管，使用後強制更換 |
| 日常管理帳號 | 透過 RADIUS/TACACS+ 集中認證 | 依伺服器端 class 對應動態指派 |
7️⃣ 密碼原則的稽核補強項目
延續上一篇的密碼複雜度設定，稽核情境下通常還會被要求以下幾項，這邊列出對應的 Junos 設定方向（實際門檻值務必依單位規範調整，不要照抄數字）：
set system login password minimum-length 10
set system login password minimum-changes 3
set system login password change-type character-sets
set system login password format sha512密碼「使用歷史限制」（例如不可重複使用前幾次密碼）與「強制到期變更」，Junos 本身在本機帳號上的原生支援有限，這也是走 TACACS+/RADIUS 集中認證的另一個現實理由：密碼歷史、到期提醒、複雜度稽核這些機制，交給後端 AAA 系統或身分識別系統（如 AD、LDAP 搭配 TACACS+）處理，會比在每台網路設備上土法煉鋼可靠得多。
8️⃣ 上線前檢查清單
| 項目 | 確認內容 |
|---|---|
| authentication-order | 已包含 fallback（password），非單一依賴 RADIUS/TACACS+ |
| 共用金鑰（shared secret） | 與 AAA 伺服器端一致，且未使用預設值 |
| 伺服器端 class 對應 | 已測試不同權限帳號實際登入後的權限是否正確 |
| 保底 class | 已設定 remote-users 預設低權限，避免漏設定變成過高權限 |
| 本機救援帳號 | 已保留，密碼獨立保管，使用後有更換流程 |
| AAA 伺服器斷線測試 | 已實際拔測，確認仍可用本機帳號登入 |
⚠️ 「AAA 伺服器斷線測試」這項務必實測，不要只看設定檔覺得邏輯對就當作沒問題——這類設定最常見的錯誤就是 fallback 語法寫對了，但實際測試時才發現 timeout 設太長，導致每次伺服器沒回應都要卡好幾分鐘才會退回本機認證。
📚 延伸閱讀（站內相關文章）
- Juniper 網路設備介紹 – Juniper 產品線與基本概念總覽。
- Windows AD 進階安全：Kerberos、NTLM、LDAP 強化指南 – 若後端集中認證走 AD/LDAP，這篇補充身分系統端的強化重點。
- FortiGate 自動備份與組態比對（CLI/Schedule/Diff） – 對照 FortiGate 在帳號與組態治理上的做法。
- FortiGate HA（FGCP）組態同步指南 – 多台設備管理一致性的實務案例。
- Junos PyEZ 自動化管理 – 帳號與認證架構穩定後，可進一步搭配自動化工具做組態管理。
✅ 結論與行動建議
帳號密碼從「本機管理」進化到「集中認證」，換來的是異動效率與稽核可追溯性，但代價是多了一個外部依賴（AAA 伺服器），所以 fallback 機制與斷線測試絕對不能省略。建議導入順序是：先在測試設備上完整驗證 RADIUS/TACACS+ 登入與權限對應，確認 fallback 正常運作後，再分批導入正式環境，並保留本機救援帳號作為最後防線。下一篇會接著進入 VLAN 建立與 Port 模式設定，把帳號安全這塊的地基收尾，正式進入交換器的網路設定主題。
沒有留言: