💡 先搞懂問題
想像一間三十人的貿易公司。剛創業時，所有檔案都放在同一個共用資料夾，誰需要什麼權限，就請資訊人員幫忙開，資訊人員通常也照單全收。這樣做很方便，幾年後卻開始出事。
第一，權限給得太寬。某次有人為了省事，把整個財務資料夾分享給「全公司」，從此業務也打得開薪資表。第二，異動沒有回收。從業務調到採購的同事，新的權限開了，舊的權限卻沒人記得關，幾年下來一個帳號累積了好幾個部門的鑰匙。第三，一個人包辦整件事。會計可以自己新增一家供應商，也可以自己核准付款給它，萬一起了歪念，沒有第二個人會發現。
這三個問題有一個共同點：系統沒有好好回答「這個人是誰、他該做什麼、他實際做了什麼」。帳號被盜時也一樣，攻擊者拿到的權限有多大，損害就有多大。
三種最常見的權限破口。紅色是「不該有、卻還在」的權限，也是帳號被盜時攻擊者能直接拿走的範圍。
要理解存取控制，可以想一棟辦公大樓的門禁。一樓警衛請你報上姓名，這是識別；他核對你的證件，確認你真的是本人，這是驗證；他發給你一張門禁卡，只開得了你那一層和茶水間，這是授權；你每刷一次卡，保全系統就留下一筆紀錄，這是紀錄。至於這張卡該開哪幾扇門由誰決定，各棟大樓做法不同：有的讓每間辦公室的主人自己配鑰匙，有的由保全系統依機密等級強制管制，有的依職稱統一發卡，有的規定晚上十點後所有門一律上鎖，有的則同時看你是誰、要進哪扇門、現在幾點、拿的是哪張卡再綜合判斷。
存取控制的基本構成。主體對客體提出請求，決策點比對政策後決定准或拒，結果一律寫進紀錄。
主體 Subject
提出存取請求的一方，可以是人，也可以是程式或服務帳號。對應大樓裡拿著門禁卡的員工或訪客。
🎮 互動實驗室
四個實驗室都在同一間公司裡進行：先看一次登入到留下紀錄的完整流程，再讓同一個請求經過五種模型，接著親手設計角色權限，最後看一位員工調職幾次後，帳號裡的權限會變成什麼樣子。
1AAA 四步驟逐步播放
業務專員阿哲早上要登入公司系統。選一個情境，按「▶ 下一步」，看請求依序經過識別、驗證、授權、紀錄，以及在哪一步被擋下。
準備開始
按「▶ 下一步」，從識別開始。
2同一個請求，五種模型怎麼判
同一間公司、同一個請求，交給五種存取控制模型各判一次。調整請求內容，看哪些模型改變了判斷、哪些條件對某個模型根本不重要。各模型的政策都是本實驗室自訂的示意設定。
3RBAC 角色權限矩陣與職務區隔偵測
左邊上方是角色權限矩陣：點格子替角色加上或拿掉權限。下方是人員：點角色名稱替人員指派或取消角色。右邊的付款流程圖會即時標出每一步有誰能做，一旦同一個人能完成兩個不該由同一人負責的步驟，就會畫出紅線。
4權限潛變：調職幾次之後
小林從業務起步，之後調到採購、支援一個財務專案、升任採購主管，最後離職。先選公司的管理方式，再按「▶ 下一個事件」。在「只加不減」模式下，隨時可以按「執行權限審查」，把被標出來的多餘權限點掉收回。
📘 原理補完
1. AAA：先確認你是誰，再決定你能做什麼
常聽到的「3A」指驗證（Authentication）、授權（Authorization）與紀錄（Accounting）。在驗證之前其實還有一步識別（Identification），也就是先宣稱身分，所以也有人把四步合稱 IAAA。考題若問 AAA 的三個 A，答案是驗證、授權、紀錄；可用性（Availability）是 CIA 三要素裡的 A，常被拿來當誘答。另外兩個長得很像的誘答是「存取」（Access）與「帳號管理」（Account Management），它們都和存取控制有關，但不是 3A 的正式成員。
- 識別：宣稱「我是誰」，例如輸入帳號、刷員工證。帳號必須一人一個、不可共用，否則後面的紀錄對不到具體的人。
- 驗證：證明宣稱屬實，靠所知（密碼）、所持（手機、安全金鑰）、所具（指紋、臉部）三類因子。多因子驗證要結合不同類型，細節見 MFA 與 FIDO2 教學頁。
- 授權：依政策決定能存取哪些客體、能做哪些動作。授權檢查要在伺服器端執行，而且每次請求都做。
- 紀錄：記下誰、何時、從哪裡、對什麼、做了什麼、結果是准或拒。Accounting 也譯作「計量」，它的目的是可歸責性（Accountability）：出事時能追到是誰做的，當事人也難以否認。日誌要送到當事人改不到的地方，系統管理員不應能刪改自己的操作紀錄。
單一登入（SSO）讓使用者登入一次就能使用多個系統，它集中處理的是驗證；每個系統仍然要各自做授權。一組帳密通行多個系統，也代表被盜時影響範圍更大，所以 SSO 通常搭配多因子驗證。SSO 背後常用的協定，以及授權為什麼要檢查到每一筆資料，放在下方「考點補強」說明。
2. 五種存取控制模型：誰決定、依據什麼
回到大樓的比喻，五種模型的差別不在門禁機長什麼樣子，而在「這張卡該開哪扇門」由誰說了算、依據什麼判斷。點下面的按鈕切換圖解。
自由存取控制（DAC, Discretionary Access Control）把決定權交給資源擁有者。作業系統的檔案權限、雲端硬碟的「分享」都是 DAC。它彈性高，缺點是權限會沿著分享一路擴散，而且以使用者身分執行的惡意程式，也能用同樣的權力改權限。
強制存取控制（MAC, Mandatory Access Control）由系統依客體的安全標籤和主體的安全等級強制比對，使用者與擁有者都不能自行更改，常見於軍事與政府機密系統。
角色基礎存取控制（RBAC, Role-Based）把權限綁在角色上，人員只被指派角色；調職時換角色即可，是企業最常用的做法，也最方便落實職務區隔。
規則基礎存取控制（RuBAC, Rule-Based）依事先訂好的規則判斷，例如「22:00 到 06:00 不得登入」「非公司 IP 不得連管理介面」，規則對所有人一體適用，防火牆規則就是典型例子。它和 RBAC 縮寫只差一個字母，要看全名：RBAC 問「你是什麼角色」，RuBAC 問「現在符不符合規則」。屬性基礎存取控制（ABAC, Attribute-Based）則把主體、客體、動作、環境等多種屬性一起放進政策裡動態計算，角色也只是其中一個屬性，所以可以看成 RBAC 的延伸。
| 模型 | 誰決定 | 依據 | 優點 | 限制 | 常見例子 |
|---|---|---|---|---|---|
| DAC | 資源擁有者 | 擁有者設定的存取清單（ACL） | 彈性高、使用者自主 | 權限易擴散、難集中控管 | 檔案權限、雲端硬碟分享 |
| MAC | 系統強制，擁有者也不能改 | 客體安全標籤 vs. 主體安全等級 | 防止資訊依個人意願外流 | 標籤維護成本高、不夠彈性 | 軍事與政府機密系統 |
| RBAC | 管理者集中定義角色並指派 | 使用者擔任的角色 | 人多也好管、易做職務區隔 | 情境一多角色越開越多；本身不看時間地點 | ERP、人資與財務系統 |
| RuBAC | 管理者訂規則，一體適用 | 時段、來源 IP 等條件 | 簡單、一致 | 單獨使用時不分身分 | 防火牆規則、登入時段限制 |
| ABAC | 管理者寫政策，系統每次計算 | 主體、客體、動作、環境屬性 | 最細緻，可隨情境調整 | 政策設計與屬性資料品質要求高 | 條件式存取、零信任授權 |
不少教科書把存取控制分成三大類：DAC、MAC，以及屬於「非自由決定」（Non-Discretionary）的 RBAC；規則式與 ABAC 是後來更常被單獨列出的做法。DAC 與 MAC 這兩個名詞，最早是由美國國防部的「可信任電腦系統評估準則」（TCSEC，俗稱橘皮書）正式定義的。一般認為 MAC 的安全強度高於 DAC，因為權限不會隨擁有者的意願外流，政策由安全管理者集中訂定。
對應到實際系統：Unix／Linux 檔案的擁有者、群組、其他人三組讀寫執行（rwx）權限，以及 Windows NTFS 的存取清單，都是 DAC，因為檔案擁有者可以自己修改；SELinux（由美國國家安全局 NSA 發展）則是在 Linux 上再加一層 MAC，所有程式與檔案都貼上安全標籤，受它管制的程式就算以 root 身分執行，也只能碰政策允許的檔案與連接埠。另外偶爾會看到「以身分為基礎的存取控制」（IBAC, Identity-Based），指存取清單直接列出個別使用者，一般視為 DAC 的一種形式。
3. ABAC 的四類屬性
美國 NIST SP 800-162 對 ABAC 的描述是：每一次請求，都把主體屬性、客體屬性、要做的動作與環境條件交給政策判斷。考題最常問的是哪一項屬於「環境屬性」，也就是和請求當下情境有關、與人和資料本身無關的條件，例如時間、地點、網路位置、裝置是否合規。部門、職級屬於主體屬性；資料分級、所屬部門屬於客體屬性。
ABAC 能依情境即時放寬或收緊，這正是零信任需要的能力，所以零信任架構常以 ABAC 或條件式存取落實「每次請求重新判斷」。代價是政策與屬性資料都必須準確，人資系統裡的部門若沒更新，政策再精細也會判錯。
黃色框是環境屬性。時間改成深夜或裝置換成未納管的手機，同一個人、同一份資料也會被拒。
4. Bell-LaPadula 與 Biba：MAC 的兩套讀寫規則
MAC 最常被引用的兩個理論模型剛好目標相反。Bell-LaPadula（BLP）保護的是機密性，規則是「不上讀、不下寫」：不能讀比自己等級高的資料，免得看到不該看的；也不能把東西寫進比自己等級低的地方，免得把機密抄到公開文件裡。Biba 保護的是完整性，規則是「不下讀、不上寫」：不讀比自己可信度低的資料，免得被錯誤資訊污染判斷；也不能寫入可信度更高的資料，免得低可信的來源竄改重要內容。
讀寫方向小遊戲
得分 0／0
5. 最小權限、需知原則、職務區隔與預設拒絕
這幾個原則常一起出現，但各自回答不同的問題：
這些原則都是存取控制的設計準則，目的是限制「誰能碰到什麼」。它們不是資料加密的理論基礎；加密解決的是資料被拿走之後能不能被讀懂，屬於另一套機制，兩者互相搭配。
最小權限用在特權帳號上，就是特權存取管理（PAM）與即時授權（JIT）：平時帳號沒有管理員權限，依核准的工單在限定時間內開通，時間到自動收回，帳號就算被盜，平時也打不開任何門。職務區隔在小公司常常拆不開，這時要用補償性控制頂上，例如把操作日誌即時送到當事人改不到的日誌伺服器、由主管定期覆核、關鍵交易設金額門檻需第二人確認。
6. 帳號與權限的生命週期
權限不是開通就結束。每次職務異動與每一輪審查，都要把不再需要的權限收回；任何階段一旦離職，都直接跳到最下面。
- 到職前：依職務做背景查核、簽署保密協定，再依職務需求提出權限申請，由權責主管核准「所需最小權限」。
- 開通：依角色開通，而不是「照某位同事的權限複製一份」，後者會把對方累積的多餘權限一起複製過來。
- 異動：調職時依新角色重新授權，同時收回舊職務的權限；支援專案或委外帳號要設到期日，綁定專案或合約期間，到期自動停用，不靠人工記得去關。
- 定期審查：由資料擁有者或主管確認每個人的權限是否仍有需要，資訊人員負責執行調整；特權帳號與高風險系統應更頻繁。
- 離職：當天停用帳號、撤銷遠端存取與權杖，收回設備與門禁卡；人資與資訊部門之間要有通知流程，才不會出現離職多月帳號仍能登入的情況。
📌 考點補強
前面把模型與原則的骨架講完了。這一節補上常和它們一起出現、卻容易被略過的細節：大樓門禁背後靠哪些協定串起來、授權為什麼要檢查到每一筆資料、職務區隔在資訊部門長什麼樣子，以及特權帳號與帳號管理的實務清單。最後用一個審核台把這些判斷練一遍。
1. 驗證與單一登入背後的協定
回到大樓的比喻。如果每棟分館都自己養一組警衛、自己印一本員工名冊，員工到每棟樓都得重新證明身分，離職時也要通知每一棟去刪名字。比較好的做法是設一個總服務台：名冊集中放在總服務台，各棟警衛遇到人就打電話回去查；或是讓人先到總服務台換一張通行證，之後憑通行證進各棟樓。回到資安，集中的名冊是目錄服務，打電話回去查對應 RADIUS、TACACS+ 這類集中驗證協定，換通行證則對應 Kerberos 的票證與 SAML 的斷言。
| 協定 | 主要用途 | 運作重點 | 常見場景 |
|---|---|---|---|
| RADIUS | 集中處理驗證、授權與計量（AAA） | 走 UDP（1812 驗證、1813 計量）；驗證與授權合在同一個回應裡；只加密密碼欄位 | VPN、企業版 Wi-Fi（802.1X） |
| TACACS+ | 集中處理 AAA，特別適合設備管理 | 走 TCP 49；驗證、授權、計量拆成獨立步驟，可逐條指令授權；標頭以外的封包內容全部加密 | 管理員登入路由器、交換器 |
| LDAP | 查詢與維護目錄裡的帳號、群組與屬性 | TCP 389，加密版 LDAPS 用 636；應用程式可以拿帳密向目錄「綁定」來確認身分 | 查詢 Active Directory、應用系統串接公司帳號 |
| Kerberos | 企業內網的單一登入 | 以票證運作，密碼不在網路上傳送；票證有期限，各主機需要時間同步 | Windows 網域登入後存取檔案伺服器 |
| SAML 2.0 | 跨網站、跨組織的單一登入與聯合身分 | 身分提供者（IdP）驗證後簽發 XML 斷言，服務提供者（SP）據此放行 | 用公司帳號登入雲端服務、合作夥伴入口網站 |
同樣屬於聯合身分標準的還有 WS-Federation；OAuth 2.0 與 OpenID Connect 是另一組常考標準，分工差別見地圖上的 SAML/OAuth/OIDC 節點。反過來看，SNMP 是用來監控與管理網路設備的協定，本身不是拿來驗證使用者身分的服務；SSL／TLS 保護的是傳輸通道，也不是聯合身分標準。
Kerberos 的兩張票：先向 AS 拿 TGT，再拿 TGT 向 TGS 換某個服務專用的 ST。
Kerberos 的重點是「兩張票、先後不能反」。使用者登入時，先向金鑰發放中心（KDC）裡的驗證服務（AS）證明身分，拿到一張票證授予票證（TGT, Ticket-Granting Ticket），作用像一日通行證；之後每要用一個服務，就拿 TGT 去找票證授予服務（TGS），換一張只對該服務有效的服務票證（ST, Service Ticket），再把 ST 出示給服務本身。
準備開始
小芳剛開機，要登入網域並打開檔案伺服器上的共用資料夾。
單一登入的好處是集中管理帳號與權限、使用者少記幾組密碼、少重複輸入。代價是所有系統都信任同一個身分提供者：它故障、憑證到期或信任設定被改壞時，串在後面的系統會一起登不進去，一組帳密被盜的傷害也跟著放大，所以通常要搭配多因子驗證。簡訊驗證碼是驗證方式，瀏覽器記住密碼是便利功能，兩者都不是 SSO 本身的特性。還要記得，SSO 只是讓你少登入幾次，不會讓各系統的權限自動變小，每個系統仍要依最小權限各自授權。
2. 授權要檢查到「這一筆」：物件層級授權
大樓門禁確認你能上 5 樓，卻沒檢查你打開的是不是自己的置物櫃，很多網站就是在這裡出事。假設網站用 /invoice?id=5031 顯示你的帳單，有人把網址改成 5032，伺服器如果只檢查「有沒有登入」，就會把別人的帳單送出去。這類弱點叫不安全的直接物件參照（IDOR, Insecure Direct Object Reference），在 OWASP Top 10 屬於「存取控制失效」（Broken Access Control），在 API 領域則稱為物件層級授權失效（BOLA）。
根本的修法是在伺服器端、每一次請求都確認「目前登入的人是否有權存取這一筆資料」，例如查詢時同時比對資料的擁有者。把編號換成難猜的亂數、在前端把編號藏起來，只是讓人比較難找到下一筆，缺少的授權檢查依然缺著；要求使用者再輸入一次密碼也沒用，因為那是在確認「你是誰」，問題卻出在「這筆資料是不是你的」。真正要補的，是應用程式在伺服器端那一段授權判斷。
3. 職務區隔在資訊部門長什麼樣子
前面實驗室用的是付款流程。資訊部門裡的職務區隔，大多也是同一個模式：發起、核准、執行分給不同人，再由一個沒有經手的人檢查。下表列出常見要拆開的組合：
| 作業 | 要拆給不同人的環節 | 一人包辦會發生什麼 |
|---|---|---|
| 系統變更 | 提出變更、核准變更、執行變更、確認結果 | 自己改、自己批、自己驗收，設定出錯或夾帶後門都沒人擋 |
| 程式開發 | 撰寫程式、程式碼審查、部署上線 | 開發者把未經審查的程式直接推上正式環境 |
| 權限管理 | 提出申請、主管核准、管理人員開通 | 申請人自己把權限打開，核准形同虛設 |
| 資料處理 | 登錄資料、覆核與送出 | 輸入錯誤或假資料直接生效 |
| 業務系統 | 業務使用者、系統管理者 | 部門主管兼任自家系統管理員，能改設定、改資料，還能刪紀錄 |
| 監督 | 執行操作、審查操作日誌 | 管理員審自己的日誌，等於自己查自己 |
和程式有關的還有三件事：開發、測試與正式環境要分開，開發人員不持有正式環境的部署權限，程式經審查與變更核准後，由維運人員或自動化部署流程上線；原始碼的存取要依職務限制；系統公用程式（能繞過一般控制的管理工具）要和應用程式分開存放，只給少數人使用。這些在 ISO/IEC 27001:2022 附錄 A 分別對應職務區隔（5.3）、原始碼存取（8.4）、特權公用程式的使用（8.18），以及開發、測試與正式環境的分隔（8.31）。
職務區隔的弱點是共謀：只要負責不同環節的人串通，拆開也擋不住，所以設計時就要考慮哪些人彼此的關係太近。能幫職務區隔落實的措施包括：用 RBAC 事先定義哪些角色不能同時指派給同一人、定期權限審查找出日積月累冒出來的衝突組合、職務輪調與強制休假。多因子驗證則是強化「你是誰」，和一件事要幾個人完成無關。小型組織實在拆不開時，用活動監控、稽核軌跡與管理監督補償；把所有責任都交給一個人「全權負責」，本身就不是控制措施。
4. 特權帳號與帳號管理：常考的實務清單
特權帳號是權限最大的一群，考題最常考下面這幾條：
- 系統內建的預設管理帳號（例如 Administrator、root、設備出廠帳號）不拿來做日常管理：能停用就停用，不能停用就改名、改掉預設密碼並限縮權限。
- 每位管理員一個具名帳號，不共用，也不把所有系統的管理密碼設成同一組；共用帳號會讓紀錄對不到人，一組密碼外洩也會一次失守所有系統。
- 監控特權帳號的登入時間、頻率與來源，非上班時段或短時間大量登入就告警；也可以建置 UEBA（User and Entity Behavior Analytics），先替每個帳號畫出平常的行為樣貌，再找出偏離的操作。
- 高風險操作採雙人控制（一人操作、另一人核可），並把整段操作錄影存證，事後可供稽核。
- 定期審查特權帳號的持有人與權限；有人離職或調職時，立即檢查他用過的系統帳號。
權限的申請流程也有幾個細節。申請要經主管核准，但實際設定要由權責的管理人員執行，而且核准紀錄、帳號與權限清查的紀錄都要留存，申請人不能拿著核准單自己去後台開權限。同事休假或留職停薪時，代理人需要的權限應該給，只是要限定範圍與期間、到期自動收回；一律拒絕，往往只會逼人改用借帳號的方式應付。存取控制政策則要寫成文件並公告，依職務訂定，內容納入業務的安全需求與法規、契約要求；存取日誌本身也是敏感資料，只開放給有需要的人查看。
我國的資通系統防護基準，也把幾項帳號控制寫成明確要求，例如：身分驗證連續失敗達一定次數就鎖定帳號一段時間（基準訂的是失敗五次、至少鎖定十五分鐘）；用預設密碼登入後必須立刻變更；逾期的臨時或緊急帳號要刪除或停用；閒置過久或超過使用期限要自動登出；遠端存取只能從事先定義並管理的存取點進來；權限檢查在伺服器端完成。
最後，大型組織會用身分治理與管理（IGA, Identity Governance and Administration）把上面這些流程自動化：到職、調職、離職時自動開通與回收權限（權限生命週期管理）；定期發起存取認證（英文稱 Access Certification），請主管逐一確認部屬的權限是否仍有需要；用角色探勘（Role Mining）分析現有權限的分布，把重複或過大的角色整理、重新設計。IGA 廣泛管全體帳號的權限，PAM 則深入管少數高權限帳號的使用過程，兩者互補。
5權限申請審核台
你是資安主管，桌上有十二張申請單或作業做法。逐張判斷「合格」或「不合格」，送出後會立刻看到涉及哪一個原則、為什麼。下方圓點是進度，也可以點圓點回到任一張重看。
已審 0／12，判斷正確 0
✅ 自我檢測
十題原創情境題，點選項立即顯示對錯與解析。
目前得分：0／10
🎯 重點整理
- 先識別（宣稱身分），再驗證（證明身分），接著授權（決定能做什麼），全程紀錄（可歸責）。3A 是驗證、授權、紀錄，不含可用性、存取或帳號管理。
- DAC 擁有者自己決定、可再分享；MAC 系統依標籤與等級強制，擁有者也改不了；RBAC 依角色集中指派；RuBAC 依一體適用的規則；ABAC 綜合主體、客體、動作與環境屬性。Unix 的 rwx 權限是 DAC，SELinux 是 MAC 的實作。
- 集中驗證與單一登入：RADIUS 走 UDP、驗證授權合一；TACACS+ 走 TCP 49、三個 A 分開、適合設備管理；LDAP 查目錄；Kerberos 先拿 TGT 再換 ST；SAML 用 XML 斷言做跨網站 SSO。SNMP 不是驗證服務。
- 授權要在伺服器端檢查到每一筆資料；改個編號就看到別人資料，是 IDOR（存取控制失效）。
- 時間、地點、網路位置、裝置合規屬於 ABAC 的環境屬性；部門與職級是主體屬性，資料分級是客體屬性。
- Bell-LaPadula 保機密性：不上讀、不下寫。Biba 保完整性：不下讀、不上寫。兩者方向相反。
- 最小權限管權限給多大，需知原則管資訊看多少，職務區隔管一件事拆給幾個人，預設拒絕讓沒寫到的一律不准。
- 職務區隔在資訊部門就是變更、上線、開權限都拆成發起、核准、執行，開發與正式環境分開；做不到時用日誌監控、主管覆核等補償性控制，再以強制休假、職務輪調輔助。特權帳號不共用、不用預設帳號，用 PAM 與 JIT，平時不持有、用時才開、到期收回。
- 權限潛變靠三件事處理：調職時依新角色重新授權並收回舊權限、專案與委外帳號設到期日、定期由擁有者審查；離職當天停用。