概念地圖・Bell–LaPadula 安全格
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：系統
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
安全格：看得到的資料，可以往哪裡送
永生花工作室的助理，把未公開婚禮名單複製到共用交件資料夾；登入資格一路有效，資料也跨過了原先設定的保密邊界。Bell–LaPadula 安全格把這個漏洞攤開：使用者、執行中的程式與檔案各有安全標籤，每一次讀取與寫入都得比對。密級只是其中一半，還有資料所屬的類別。看過某份資料，後面的另存、附加與轉交就有方向限制——保密責任跟著內容走。
密級之外，還有類別集合
把主體想成助理這次工作階段正在使用的程式，把客體想成它碰到的檔案。以下固定主體的目前安全級別為內部{A}，逐一代入四個允許標籤；表中「允許」都以個別操作也取得 DAC 自主存取授權為前提。
| 客體標籤 | 讀取 | 只寫附加 | 讀寫修改 |
|---|---|---|---|
| 公開∅ | 允許 | 拒絕：向下寫 | 拒絕：標籤不同 |
| 內部{A} | 允許 | 允許 | 允許 |
| 內部{B} | 拒絕：缺少B | 拒絕：對象缺少A | 拒絕：標籤不同 |
| 機密{A，B} | 拒絕：超過目前級別 | 允許 | 拒絕：標籤不同 |
支配要同時通過兩關：密級較高或相同，類別集合包含對方。內部{A}與內部{B}互不可比；在圖中這四個允許標籤內，兩者的上確界是機密{A，B}，下確界是公開∅。這是標籤簡化示意，只討論這四種組合——實際系統若允許更多組合，格也要跟著重畫。
Bell 與 LaPadula 在1976年原始報告區分主體的最高安全級別與目前安全級別，並以 get-read、get-append、get-write 規則處理不同操作。本文以須遵守星號性質的非受信任主體為例：最高核准密級須支配目前級別；讀取對象由目前級別支配，只寫附加的對象須支配目前級別，讀寫修改則要求同標籤。通常說的「無讀上、無寫下」，就在防止高密內容被帶往較低的邊界——同時還得通過 DAC，安全格合格並不自動開門。
每次存取都要檢查的支配關係
一、先找這次工作階段的標籤。工作室負責人可能核准助理接觸機密{A，B}，但助理此刻只在內部{A}工作階段處理婚禮訂單。要查的是正在執行操作的主體目前級別，以及它是否落在最高核准範圍內。拿員工職稱或帳號最高資格直接填表，會跳過這一層——登入成功只完成了部分檢查。自問：目前標籤與最高核准密級是否分清？
二、把類別當集合逐項核對。A可代表婚禮訂單，B可代表企業贈禮委託。兩份都叫「內部文件」，助理手上的{A}仍缺少B。機密{A，B}包含兩邊，才適合成為跨案彙整的接收端。別把同部門、同主管或共用雲端空間當作集合包含——標籤必須落到實際客體，下載副本也要接得住。自問：類別集合是否真的包含對方？
三、拆開「存檔」背後的動作。助理把新增的花材數量送進機密{A，B}收件端，可設計成只寫附加。若畫面先載入整張高密彙整表，再讓助理改一格，它就含有讀取與修改；在目前內部{A}的工作階段應被拒絕。同一個「送出」按鈕，後面的存取型態足以改變判決——還要逐項確認 DAC 是否授權。自問：操作是讀、只寫附加、還是讀寫修改？
永生花工作室的名單權限，走一遍
底下這家台灣中部的永生花工作室，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。客戶名單、訂單與流程均為虛構。A代表婚禮訂單，B代表企業贈禮；工作室只使用圖上的四種標籤。
- 先固定助理的狀態：主管為助理設定的最高核准密級是機密{A，B}，今天處理婚禮訂單的程式則以內部{A}執行。主管另外給它指定檔案的讀取、修改與附加權限。最高資格與當前操作分開記。
- 讀資料時逐份驗：公開∅的花盒尺寸表與內部{A}的婚禮交件單，標籤檢查通過。內部{B}的企業贈禮名冊、機密{A，B}的綜合彙整表，讀取請求都遭拒絕。即使主管已核准最高資格，這個工作階段仍有自己的邊界。
- 把新增需求送往彙整端：助理在內部{A}交件單補上緞帶色號，這是同標籤讀寫修改；再將新增需求附加到機密{A，B}收件端，系統只回傳收件狀態，沒有帶回彙整內容。兩項操作都先確認 DAC 授權。送達高密端後，讀回仍要重新判斷。
- 攔住共用交件資料夾：若該資料夾被標為公開∅，把內部{A}婚禮名單複製進去就違反無寫下。改送內部{B}也遭拒絕，因為對方類別不含A。主管請助理保留原單，另由經核准的受信任程序製作可對外提供的交件摘要。改檔名、遮一欄，資料都不會自行降密。
這家工作室要守住的接縫，出現在「已經看過」之後。助理為了讓現場交件更快，把名單移到容易取得的位置，便可能擴大收件範圍。只寫附加介面讓需求往高密端匯集；公開交件資料則需要獨立審核用途與內容。前者避免回傳高密資料，後者處理授權降密。兩條流程都要有人負責，並保留決策紀錄——今天趕交件的方便，不能直接變成明天沿用的資料分類。以上為說明結構用的示意情境，僅供理解框架之用。
安全格什麼時候會騙你
- 把保密方向當成完整的安全保證。Bell–LaPadula 關心資訊洩漏。低密主體向高密端附加資料，可能符合這套保密條件；新增內容是否正確、是否污染彙整結果，仍須另一套控制。談完整性的 Biba 模型有不同方向與目的。工作室收到的花材數量應經驗證，才進正式交件單——標籤合法也可能送來錯資料。
- 以為畫面關住，其他通道也一起關住。安全格仰賴實作正確地約束主體與客體。側通道、回應時間、錯誤訊息，以及有例外權限的受信任程式，都要另外檢查。只寫收件端若在錯誤訊息吐出既有客戶姓名，介面名稱仍叫附加，實際上已有資訊回流——每一段回應內容都得納入存取分析。
- 把分類正確當作自然成立。一份未公開婚禮名單若起初被貼成公開∅，後面的規則可能一路放行。反過來，所有資料都貼到機密{A，B}，日常交件會到處受阻，成員也容易轉向未受控副本。分類需要維護者、判斷依據與複核時點——政策越一致，貼錯標籤的後果也越一致。
分享按鈕後面的接收者
名單被打開以後，保密責任才剛進入下一段路。
新人把婚禮時程交給工作室，是為了讓花禮準時到場。對方願意提供的資訊，帶著明確用途與期待；每一次另存、轉交與附加，都在延續這份託付。《痛點》的 P.A.I.N. 提醒我們回到承受後果的人：交件人需要哪幾欄，主管為什麼要彙整，客戶知不知道誰會收到。這張圖畫得出標籤之間的支配關係，畫不出客戶對一次轉交的安心程度。合理的存取條件還要接上合理用途，才能讓交付承諾落地——今晚挑一份即將送出的交件單，先刪去接收者用不到的欄位，再讓負責分類的人確認輸出版本與授權範圍。
關於安全格，常被問到的幾件事
Bell–LaPadula 的「無讀上、無寫下」怎麼記？
對本文的非受信任主體，讀取時由目前安全級別支配對象；只寫附加時由對象支配目前級別。上下還包含類別集合的條件，所以兩個內部標籤也可能互不可比。圖上的讀箭頭指向被存取的對象，資訊則從對象進入讀取者；因此保密資訊流仍可向上匯集。這套方向要連同 DAC 授權一起檢查。
有機密資格，為什麼還不能打開機密檔？
最高核准密級界定主體可被允許運作的上限，目前安全級別則描述這個工作階段的狀態。本文助理的上限雖是機密{A，B}，目前仍在內部{A}；讀取機密{A，B}的請求因此被拒絕。調整目前級別需走系統允許的狀態轉換與授權程序——把帳號切到更高標籤，也會影響後續寫入的去向。
向上寫入，是否代表可以修改高密檔案？
向上允許的是符合條件的只寫附加：將內容送入對象而不觀察既有內容。一般試算表編輯會先讀出資料，再修改或覆寫，屬於讀寫操作；在本文條件下要求相同標籤。介面是否真的做到只寫，需要檢查回應、預覽與錯誤訊息。按鈕叫「上傳」或「新增」，不足以證明它符合這個存取模式。
把姓名刪掉，就能把檔案改成公開嗎？
刪除欄位是內容處理，降密是授權決策。剩下的日期、地點、聯絡備註或組合資訊，仍可能保留敏感內容；原標籤應持續生效，直到受信任的核准程序確認輸出符合公開條件。工作室可事先定義交件摘要需要哪些欄位、誰可核准、如何留存紀錄，再由制度允許的程序輸出——臨時改標籤會打斷保護鏈。
權限標籤的安排，可以接到每次請求都重新驗證的治理流程。往下讀零信任政策決策，把這次請求的身分、資源與環境一起檢查；再用NIST 網路安全框架安排分類、監測與事件處理的責任，讓那份交件單從建立到轉交都有可追查的依據。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。