DAY11 PAM、JIT、Zero Trust、工作負載身分

• 一. 特權存取管理 PAM
  • 1-1 什麼是特權帳號？
  • 1-2 特權存取管理 PAM
  • 1-3 常設性權限 Standing Privilege
• 二. 即時存取 / 授權 JIT
• 三. 零信任 Zero Trust
  • 3-1 持續驗證 Continuous Verification
• 四. 工作負載身分 Workload Identity
  • 4-1 硬編碼憑證 Hardcoded Credentials
  • 4-2 工作負載 Workload
  • 4-3 工作負載身分同盟 Workload Identity Federation
  • 4-4 託管身分
• DAY11 重點

• PAM（特權存取管理）
• JIT（即時授權）
• Zero Trust（零信任）
• Workload Identity（工作負載身分）

一. 特權存取管理 PAM

1-1 什麼是特權帳號？

特權：

• 新增 / 刪除使用者
• 修改權限
• 修改伺服器設定
• 查看大量敏感資料
• 關閉安全功能
• 安裝軟體
• 修改資料庫

例如：

• 系統管理員帳號
• 最高權限帳號
• 資料庫管理員帳號
• 雲端管理員帳號

權限越大，被盜用或濫用時造成的損害越大

1-2 特權存取管理 PAM

專門管理：

• 高權限帳號
• 高權限存取
• 高風險操作

例如：

• 誰申請？
• 為什麼要？
• 何時取得？
• 要用多久？
• 做了什麼？
• 用完是否回收了？

全部管理記錄下來

1-3 常設性權限 Standing Privilege

即使現在沒有工作需要，

高權限仍一直存在。

例如：

明明一年只有 1 個月需要管理員權限，

但：

系統讓他 365 天都有管理員權限

攻擊者只要在其中一天取得了他的帳號，

就可以：

隨意使用管理員權限

👤 IPAS 115-1 Q30

為了落實：

最小權限原則

並消除：

常設性管理員權限

帶來的風險，

現代特權存取管理傾向：

即時存取 JIT 策略

下列何者最符合 JIT 的運作模式？

答案：

D：平時權限為零，只在核准的工單期間動態賦予，用完立刻回收

這就是：

JIT

二. 即時存取 / 授權 JIT

平常不給權限，

需要時才暫時給，

時間到就收回來。

例如：

MIKEY 教練平常是一般權限。

今天他需要修改會員資料。

提交工單。

核准後：

10:00～11:00 暫時取得管理員權限

11:00：

自動收回權限

即時存取 / 授權與最小權限的關係

最小權限

只給：

工作所需權限

即時存取 / 授權

只在：

需要的時間

給權限。

三. 零信任 Zero Trust

永不預設信任

不管來自：

• 內網
• 外網

都持續進行驗證。

每次存取都應該做：

身分驗證

例如：

• 多因素驗證
• 帳號驗證

檢查設備

例如：

• 作業系統是否更新
• 是不是私人電腦
• 防毒有沒有在執行
• 硬碟有沒有加密

檢查情境

例如：

• 哪個 IP 登入

評估風險

這次存取風險為：

• 高？
• 中？
• 低？

動態決定權限

不要：

一次給全部權限

👤 IPAS 115-1 Q32

企業導入零信任架構時，

下列哪一項最為正確？

答案：

C：無論存取來源為何，所有存取請求都經過持續驗證與動態授權

重點

不要預設相信。

要經過驗證後，

再授權給適當權限。

就算第一次完成信任，

後續連線期間也須：

持續驗證

3-1 持續驗證 Continuous Verification

信任不是永久狀態，

需要持續進行驗證。

例如：

MIKEY 正常登入：

• 台灣
• 使用公司電腦
• 正常上班時間

但突然：

裝置狀態有異常

風險提高了。

系統需要：

重新進行驗證

ABAC 與 Zero Trust

ABAC 很常用在零信任架構中。

可以利用 ABAC 的各種屬性搭配，

來檢查：

• 裝置
• IP
• 時間
• 角色

並依照不同的組合來：

動態授權

四. 工作負載身分 Workload Identity

簡單來說就是：

應用程式向其他服務證明自己是誰的一種方式

而且：

不需要自己保管密碼以及金鑰

4-1 硬編碼憑證 Hardcoded Credentials

例如：

工程師可能會直接在程式碼寫：

database_username = admin
database_password = 123456

這就是：

硬編碼憑證

也就是：

密碼 / 金鑰直接寫死在程式碼裡

外洩風險極高！

一旦 .git 不小心放在公開的地方，

就容易造成：

程式碼內的密碼被外洩

一旦外洩，

攻擊者就可以：

• 透過金鑰登入對應的服務
• 獲得權限

4-2 工作負載 Workload

正在執行工作的：

• 程式
• 應用程式
• 服務
• 自動化系統

例如：

• Web App 網頁應用
• Server 伺服器
• Cloud Function 雲端
• Container 容器

這些雖然不是人，

但它們也需要：

做身分驗證

工作負載身分

給這些程式 / 服務：

擁有自己的身分

例如：

Web App
↓
我需要讀取這個資料庫
↓
身分服務驗證
↓
沒錯，是 Web App
↓
給短期憑證
↓
存取資料庫

👤 IPAS 115-1 Q29

軟體開發團隊正在導入自動化 CI/CD 流程，

應用程式需頻繁存取後端資料庫。

為了避免：

將憑證寫死在程式碼中

下列何項驗證策略最為適切？

答案：

使用工作負載身分同盟或託管身分，透過短期憑證進行驗證

4-3 工作負載身分同盟

Workload Identity Federation

讓兩個不同系統的工作負載，

透過設定好的可信任身分關係，

取得：

短期憑證

而不用：

長期保存密碼 / 金鑰

4-3-1 為什麼要是短期憑證，而不是長期？

長期憑證

假設：

一年的長期憑證時間

一旦不小心被偷了，

很長時間都有可能：

被偷偷使用

短期憑證

假設：

憑證只發放一小時

就算不小心外洩了，

可利用的時間也較短。

與 JIT 有點像，

大致都是要讓權限不要處在：

長期存在的狀態

4-4 託管身分

誰負責運行我的工作負載，

誰就負責：

管理身分與憑證

工作負載本身：

不用處理

DAY11 重點

今天大部分都在講一件事：

不要給太多、太久，也不要永久信任！

PAM

負責管高權限

JIT

負責管權限存在多久

Zero Trust

告訴我永遠不要預設相信

Workload Identity

程式中不要寫死密碼，也不要長期持有