讀軟體開發安全之道：概念、設計與實施02經典原則

1. CIA原則

1.1. 軟體安全都構建在資訊保安的三大基本原則之上，即機密性(confidentiality)、完整性(integrity)和可用性(availability)

1.2. 雙方交換的資料

• 1.2.1. 從技術上看，端點之間的資料交換本身就會削弱互動的機密性

• 1.2.2. 隱藏通訊資料量的一種方法是讓端點始終交換恆定數量的資料

• 1.2.3. 在實際流量較低的時候，則讓端點傳送虛擬資料包(dummy packet)來維持恆定的資料量

1.3. 授權是CIA各項原則中都固有的元素，它規定資料只能由合法的人員進行訪問、修改，資料可用性也只能交由合法人員進行管理

1.4. 機密性和完整性定義為防止未經授權地洩露或篡改資訊的行為原則

1.5. 可用性則會受到授權管理員的控制

1.6. 它們只有作為一個整體時才能有效地保護資料資產

2. 機密性

2.1. 不會洩露資訊

2.2. 只允許已授權的資料訪問

2.3. 維護機密性意味著按照一種僅授權者可讀的方式來保護隱私資訊

2.4. 必須認真判斷哪些資訊屬於隱私資訊

• 2.4.1. 最安全的做法是把所有從外部收集到的資訊都預設為隱私資訊，直到有明確的策略來進行界定，並且解釋清楚為什麼可以對這樣的設計方法進行適度的鬆綁

• 2.4.2. 一位終端使用者可能會理所當然地希望他們的資料是隱私資料（即使這些資訊被洩露也無傷大雅）​，除非他們明確告知某些資料並非隱私

• 2.4.3. 人們可能會把敏感資料輸入不同用途的文字欄位中

• 2.4.4. 資訊的收集、處理和儲存有可能需要滿足各類法律法規的要求，而很多人往往對這些法律法規一無所知

• 2.4.5. 我們不僅應該明確說出訪問規則，還應該解釋這些規則背後的主觀判斷。

2.5. 機密性洩露也有一個頻譜

• 2.5.1. 完全的資訊洩露是指攻擊者獲取到了完整的資料集，其中包括後設資料

• 2.5.2. 這個頻譜的另一端則是程度相當輕微的資訊洩露，比如內部錯誤訊息或者其他不會造成什麼後果的資訊被洩露了出去

• 2.5.3. 所有洩露受保護資料詳情的行為，在某種程度上都屬於機密性遭到破壞的情形

2.6. 去匿名化(denonymization)或者重標識(reidentification)

3. 完整性

3.1. 準確維護資料

3.2. 不允許未經授權的資料修改或者刪除

3.3. 完整性就是指資料的真實性和準確性，其宗旨是防止資料被隨意刪改

3.4. 除了透過技術手段防止資料遭到未經授權的篡改，一份準確的資料來源記錄（包括最初資料來源，以及之後授權的資料來源變更）也是相當重要、強大的完整性保障

3.5. 儲存重要資料的版本並且記錄它們的來源，這本身就是防止篡改攻擊的典型手段

3.6. 執行增量備份是一種理想的攻擊預防手段，因為增量資料儲存簡單，同時又以一系列快照的形式翔實地記錄了哪些資料執行過變更，以及它們在何時執行過變更

3.7. 篡改包括很多不同的方式，並不一定是修改儲存裝置當中的資料

• 3.7.1. 篡改可能發生在客戶端一側

• 3.7.2. 可能發生在客戶端和伺服器之間

• 3.7.3. 手段包括欺騙其中某一方修改資料，也包括在頁面上修改指令碼

3.8. 雖然永久丟失的資料也屬於不可用的資料，但是這類資料一般會被認為屬於完整性受到徹底破壞的情況

4. 可用性

4.1. 保障資料的可用性

4.2. 不允許出現嚴重延遲或者未經授權的資料訪問關閉

4.3. 針對可用性的攻擊是網路世界無法迴避的現實問題，也是最難防禦的攻擊方式之一

4.4. 攻擊者向伺服器傳送過量的資料，透過看似合法的手段佔用海量服務資源，導致服務資源耗竭

4.5. 匿名的拒絕服務(Denial of Service，DoS)攻擊（一般都是為了索取贖金）幾乎可以威脅到一切網際網路服務，所以防禦這類攻擊是非常艱鉅的挑戰

• 4.5.1. 需要利用有能力承受大量負載的基礎設施來承載大規模的服務，同時維護系統的靈活性，確保在事件發生時基礎設施能夠迅速實現遷移

4.6. 攻擊者建立的惡意請求可以觸發錯誤，導致崩潰或者無限迴圈，最終破壞伺服器的服務

4.7. 其他的攻擊方式可以導致應用的儲存、計算或者通訊出現超載，或者使用破壞快取有效性的模式，這些都可以導致相當嚴重的問題

5. 黃金標準

5.1. gold standard

5.2. 如果CIA是安全系統的目標，那麼黃金標準描述的就是達到這個目標的方式

5.3. Aurum是黃金的意思，因此黃金的化學符號就是Au

5.4. 主體是指一切透過了可靠認證的實體，包括一個人、一家企業或單位、一個政府實體，以及一個應用、服務、裝置或者其他有權執行操作的物件

5.5. 認證(authentication)

• 5.5.1. 用高度可靠的方式來判斷主體的身份

• 5.5.2. 認證的過程，是指透過可靠的方式來建立主體證書可靠性的過程

5.6. 授權(authorization)

• 5.6.1. 僅允許透過認證的主體執行操作

• 5.6.2. 認證後的主體在執行資料訪問時，也會受到授權結果的限制

• 5.6.2.1. 授權會根據預先設定的規則允許或拒絕使用者的行為

• 5.6.3. 真正兌現授權決策的唯一方法，是確保使用系統的主體都是正常透過認證的主體

5.7. 審計(auditing)

• 5.7.1. 為主體所執行的操作維護一份可靠的記錄，以便進行監控

• 5.7.2. 如果一項服務保留了一個安全日誌，而這個日誌可以準確地記錄主體執行的操作（包括那些因為授權失敗而沒有成功執行的操作）​，那麼接下來管理員可以執行審計來對系統的操作進行監控，確保所有操作都是合理的

• 5.7.3. 如果希望實現強大的安全性，準確的審計日誌至關重要，因為它們提供了對真實事件的可靠記錄

• 5.7.4. 詳細的日誌可以為我們提供一份歷史記錄，揭示發生異常情況或者可疑事件時的準確情況

• 5.7.5. 審計則負責提供可靠的日誌，記錄誰、何時執行了什麼操作，再由技術人員定期審查違規行為，並保留追究違規者責任的權利

5.8. 黃金標準充當的是一種實現機制，旨在對CIA提供保護

5.9. 安全設計方案應該明確地把認證和授權這兩者分開，因為把認證和授權結合在一起往往會導致混亂

• 5.9.1. 如果能夠把兩者明確地分開，審計追蹤工作也會變得更加清晰

6. 認證

6.1. 認證的目的是，根據能夠證明主體真實身份的證書，測試該主體的真實身份與其所聲稱的身份是否一致

6.2. 認證服務也可能會使用一種更強形式的證書，譬如數字簽名或者挑戰碼

6.3. 數字簽名是一種更加理想的認證形式，因為數字簽名可以讓主體在不洩露密碼的情況下證明自己掌握金鑰

6.4. 證書提供的認證資訊

• 6.4.1. 所知之事(something you know)：如密碼

• 6.4.2. 所有之物(something you have)：如安全令牌

• 6.4.3. 自身屬性(something you are)：即生物特徵（如指紋、虹膜等）

• 6.4.4. 所處之地(somewhere you are)：經過驗證的所在地，如與安全場所中私有網路建立的連線

6.5. 你的所知之事可能洩露，你的所有之物可能失竊，你的所處之地有很多方法可以加以操縱，就連你的自身屬性都有可能被偽造（甚至如果遭到盜用，我們連修改都很困難）​

6.6. 使用者使用兩項認證要素總比使用一項認證要素要好

6.7. 只要條件允許，我們就應該依靠現成、可靠的認證服務，而不應該動輒“自力更生”​

6.8. 認證的過程應該包括對證書進行校驗，並給出認證透過或者認證失敗的響應訊息

• 6.8.1. 不要採用認證“部分成功”的做法，這樣等於在暗示駭客可透過不斷試錯來破解密碼

• 6.8.2. 如果希望降低暴力破解密碼的風險，常見的做法是讓認證密碼從根本上很難透過計算破解，或者在認證流程中引入一些延遲

• 6.8.3. 一般來說，認證模組會給主體頒發一個令牌，主體在認證中使用令牌即可，這樣就可以避免後續被要求執行完整的認證過程

6.9. 安全繫結認證實體後可以用兩種基本方式進行入侵

• 6.9.1. 攻擊者可以盜用受害者的身份

• 6.9.2. 接受認證的主體也有可能與其他人相勾結，把自己的身份資訊洩露給別人，甚至把自己的身份強加給別人

• 6.9.2.1. 幾個人分享同一個付費訂閱的節目就屬於這種入侵方式

7. 授權

7.1. 各類系統會透過業務邏輯、訪問控制列表或者其他正式的訪問策略來實現授權功能

7.2. 匿名授權（即不進行認證的授權）適用的場合可以說寥寥無幾

• 7.2.1. 根據時間設定訪問限制（比如，僅允許員工在工作時間訪問資料庫）也是匿名授權的一個示例

7.3. 應該透過一項單一的要素來實施授權，不要讓授權程式碼散佈在整個程式碼庫中，否則這會是運維和審計人員的一場噩夢

• 7.3.1. 應該依靠某一項公共框架來唯一地提供訪問授權

7.4. 授權機制遠比傳統作業系統提供的簡單讀/寫訪問控制要細緻得多

• 7.4.1. 人們可以設計更加強大的授權機制，以便在不損失重要功能的前提下對訪問進行限制，提升安全性

• 7.4.2. 基於屬性的訪問控制(Attribute-based Access Control，ABAC)

• 7.4.3. 基於策略的訪問控制(Policy-based Access Control，PBAC)

• 7.4.4. 基於角色的訪問控制(Role-based Access Control，RBAC)可以在認證和授權之間建立起一座橋樑

• 7.4.4.1. RBAC會根據分配給認證主體的角色(role)來提供訪問授權，這樣就可以透過統一的框架簡化訪問控制

• 7.4.4.2. RBAC並不會為每個人單獨定義訪問許可權，而會根據每個人的職責指定一個或者多個角色，從而為人們自動分配相關聯的唯一許可權

• 7.4.4.3. 在更高階的RBAC模型中，一個人可以擁有多個角色，人們可以為不同的訪問主動選擇使用不同的角色

7.5. 對於某些資料來說，只讀訪問的訪問級別依然過高，密碼就屬於這類資料

• 7.5.1. 認證服務無法從證書資料庫中讀取明文密碼，但是它可以讀取摘要值，它會用這個值來與前端伺服器提供的值進行比較

• 7.5.2. 認證服務就可以對證書進行校驗了，但認證服務永遠無法訪問任何密碼

• 7.5.3. 除非介面設計能夠提供這類安全方案，否則它們會失去這樣一個減少資料洩露可能性的機會

8. 審計

8.1. 為了讓組織機構能夠對系統的行為進行審計，系統必須基於所有對運維安全至關重要的資訊生成一份可靠的日誌

• 8.1.1. 日誌中包括認證和授權事件、系統啟動與關閉、軟體更新、管理訪問等

8.2. 審計日誌也同樣必須能夠抗篡改

• 8.2.1. 最好是連管理員也無法插手修改這些日誌，這樣可以將其視為絕對可靠的記錄資訊

8.3. 網路中總是會發生這樣或那樣的事件，認證和授權策略的漏洞也總是難免的

• 8.3.1. 審計可以自始至終為人們提供必要的資訊

8.4. 在工作中，當授權主體做出與人們信任相悖的行為時，審計資訊可以幫助人們規避由此帶來的風險

8.5. 如果處理得當，審計日誌可以為日常檢測、系統效能級別評測、錯誤和可疑行為檢測帶來巨大幫助，也可以在事件發生後用於判斷攻擊實際發生的時間和評估攻擊帶來的損失

• 8.5.1. 審計日誌只有在人們監控日誌內容時才能發揮作用，因此務必認真地分析那些異常事件，然後不斷跟進，並且在必要情況下采取合理的行動

8.6. 系統也必須有能力阻止人們透過篡改日誌來掩飾那些惡意的操作

• 8.6.1. 如果攻擊者有能力修改日誌，他們當然會把自己的操作痕跡清除得乾乾淨淨

• 8.6.2. 對於那些特別敏感的高風險日誌，應該由不同管理和操作團隊負責的獨立系統來管理其審計日誌，以防內部肇事者掩蓋自己的操作痕跡

• 8.6.3. 一排高度有限的柵欄和一處位置顯眼的影片監控攝像頭就可以有效地防禦入侵

8.7. 不可抵賴性(non-repudiability)是審計日誌的一項重要的屬性

• 8.7.1. 任何嘗試規避獨立系統的行為都會顯得相當可疑，每一項錯誤的操作都會給攻擊者造成嚴重的影響

• 8.7.2. 一旦被發現，他們也很難對自己的罪行進行抵賴

8.8. 應該遵循Goldilocks原則，即日誌記錄的數量和規模應當適宜

• 8.8.1. 找到一個合理的平衡點會是一項長期且艱鉅的任務

9. 隱私

9.1. 安全和隱私的邊界很難清晰地界定，它們既緊密相關又大不相同

9.2. 為了尊重人們的數字資訊隱私，我們必須考慮其他人為因素

• 9.2.1. 客戶希望人們採用的資訊收集與使用方式

• 9.2.2. 明確界定如何合理使用和披露資訊的策略

• 9.2.3. 與收集和使用各類資訊相關的法律法規

• 9.2.4. 處理個人資訊有關的政治、文化和心理等因素

9.3. 保護隱私殊非易事，明智的做法是讓使用資料的行為儘可能透明

9.4. 收集資訊必須擁有明確的目標，保留資訊必須保證資訊確有價值

• 9.4.1. 不要因為資訊“將來有可能用到”就隨隨便便收集，這樣做的風險很高，絕不是什麼好做法

• 9.4.2. 如果未來合法使用某些資料的必要性不高，最合理的做法就是安全地刪除這些資料

• 9.4.3. 只要資料洩露的風險超過了保留這些資料的益處，我們就應該刪除這些資料

• 9.4.4. 最好的策略往往就是刪除這樣的郵件，而不是想著“說不定哪天用得到”​，於是就一直保留著所有的資料

9.5. 人是操作幾乎所有數字系統的主體，雖然操作的方式不一而足

• 9.5.1. 把保護隱私融入軟體的設計之中

9.6. 人們必須明確表達出自己對隱私問題的關注

• 9.6.1. 隱私策略和安全性不同，隱私策略能夠在一定程度上權衡資訊服務會在多大程度上利用客戶的資料

9.7. 當使用者的期望和實際的隱私策略相脫節時，或者當使用者違反了明確的安全策略時，隱私問題就會暴露出來

• 9.7.1. 使用者違反安全策略則是因為安全策略仍然不夠清晰，或者負責人對其熟視無睹，又或者這些安全策略在一場安全事故中遭到了破壞