1.3　經典原則

信息安全的指導原則可以追溯到計算機行業早期，彼時計算機還保存在上鎖的機房里，房間中還安裝著高架地板和空調，這些計算機也才剛剛開始連接到網絡當中。這些傳統信息安全原則簡直就是當代信息安全領域的“經典物理學”：很多應用適用這些信息安全模型，但并不是所有應用都適用，新開發的應用尤其不適合這些傳統模型。譬如在現代數據保護方面，人們對信息機密性那些巨細靡遺的思考和處理，在傳統信息安全原則中就難覓蹤跡。

基本原則可以輕而易舉地分為兩組，每組三項原則。第一組的三項原則可以稱為CIA原則，這三項原則定義了訪問數據的要求；第二組的三項原則關注的則是如何控制和監測數據訪問，我們稱之為黃金標準（gold standard）。這兩套原則相互依存，它們只有作為一個整體時才能有效地保護數據資產。

除了防止未經授權的數據訪問，還有一個問題是哪些組件和系統有權發起訪問。這是一個更加復雜的信任問題，它的復雜程度已經超出了信息安全的范圍。不過，為了保護數字系統，人們無法回避這個問題。

1.3.1　信息安全的CIA

傳統上，軟件安全都構建在信息安全的三大基本原則之上，即機密性（confidentiality）、完整性（integrity）和可用性（availability）。圍繞著數據保護的基本概念，這三大基本原則的意義其實都很直觀。

機密性：不會泄露信息——只允許已授權的數據訪問。

完整性：準確維護數據——不允許未經授權的數據修改或者刪除。

可用性：保障數據的可用性——不允許出現嚴重延遲或者未經授權的數據訪問關閉。

這些簡單的定義都對它們的目標和防御措施進行了描述。在審視設計方案時，我們應該考慮有哪些破壞信息安全的可能因素，同時考慮如何采取對應的防御措施。

CIA的三大組成部分代表的都是理想模型，而人們一定要避免在安全問題上追求完美。比如，即使是那些經過了可靠加密的網絡流量，只要竊聽者下定決心，那么他/她也能從這些流量中得出一些信息，比如雙方交換的數據量。從技術上看，端點之間的數據交換本身就會削弱交互的機密性。但是從實用角度上講，除非我們采取極端措施，否則這個問題無法解決，同時這個風險又實在太小，小到忽略它也不會對安全構成影響（隱藏通信數據量的一種方法是讓端點始終交換恒定數量的數據。在實際流量較低的時候，則讓端點發送虛擬數據包（dummy packet）來維持恒定的數據量）。哪些行為和數據量息息相關，攻擊者又會如何對這些信息加以利用？本書第2章會具體解釋類似的威脅評估方法。

讀者也許已經注意到：授權是CIA各項原則中都固有的元素，它規定數據只能由合法的人員進行訪問、修改，數據可用性也只能交由合法人員進行管理。界定哪些行為“合法”非常重要，而授權策略恰恰就是為此而生的，但授權策略并不包含在這些基本的數據保護概念中。授權策略相關內容會在后文的“黃金標準”部分進行探討。

1．機密性

維護機密性意味著按照一種僅授權者可讀的方式來保護隱私信息。這聽起來很容易，但是實踐起來就涉及很多復雜的問題。

首先，我們必須認真判斷哪些信息屬于隱私信息，這一點十分重要。設計文檔應該明確地對此加以區分。雖然乍看之下，哪些信息屬于敏感信息顯而易見，但是人們在這方面的看法常常大相徑庭，因此如果沒有明確的標準就會導致誤解。最安全的做法是把所有從外部收集到的信息都默認為隱私信息，直到有明確的策略來進行界定，并且解釋清楚為什么可以對這樣的設計方法進行適度的松綁。

下面是把數據視為隱私數據的一些原因，這些原因常常為人們所忽視。

● 一位終端用戶可能會理所當然地希望他們的數據是隱私數據（即使這些信息被泄露也無傷大雅），除非他們明確告知某些數據并非隱私。

● 人們可能會把敏感數據輸入不同用途的文本字段中。

● 信息的收集、處理和保存有可能需要滿足各類法律法規的要求，而很多人往往對這些法律法規一無所知（如果歐洲用戶訪問你的站點，這次訪問行為可能就需要符合歐盟的法律法規，例如《通用數據保護條例》）。

在處理隱私信息的時候，我們應該判斷哪些訪問屬于合理的訪問行為。判斷人們何時、通過何種方式披露隱私信息就屬于信任決策范疇。我們不僅應該明確說出訪問規則，還應該解釋這些規則背后的主觀判斷。

機密性泄露也有一個頻譜。完全的信息泄露是指攻擊者獲取到了完整的數據集，其中包括元數據。這個頻譜的另一端則是程度相當輕微的信息泄露，比如內部錯誤消息或者其他不會造成什么后果的信息被泄露了出去。以部分信息泄露為例，我們可以設想一下給新的客戶分配序列號：心懷不軌的友商可以不斷注冊新客戶，從而獲取客戶的序列號，然后計算這些客戶編號的數值差來判斷各個時間段內企業的新客戶數量。所有泄露受保護數據詳情的行為，在某種程度上都屬于機密性遭到破壞的情形。

人們經常對那些看似無關痛癢的信息泄露付之一笑。然而，攻擊者利用信息的方式很有可能與開發人員的初衷大相徑庭。不僅如此，攻擊者也可以把多個信息片段組合起來，從而獲得遠比其中任何只言片語多得多的內容。僅僅獲取某個人的地址郵編或許用處不大，但是如果你還知道對方大致的年齡，同時也知道對方是一位醫學博士，你就可以把這些信息組合起來，在一個人口密度不高的區域中定位到這個人的位置。這個過程如今稱為去匿名化（denonymization）或者重標識（reidentification）。研究人員通過分析一個貌似由網飛公司發布的匿名數據集，就能在大量用戶賬戶與IMDB賬戶之間建立匹配關系。這說明了一個道理：你鐘愛的那些電影就足以出賣你的個人身份。

2．完整性

在信息安全這個語境里，完整性就是指數據的真實性和準確性，其宗旨是防止數據被隨意刪改。除了通過技術手段防止數據遭到未經授權的篡改，一份準確的數據來源記錄（包括最初數據源，以及之后授權的數據源變更）也是相當重要、強大的完整性保障。

保存重要數據的版本并且記錄它們的來源，這本身就是防止篡改攻擊的典型手段。這說起來十分簡單，就是保留一份良好的備份數據。執行增量備份是一種理想的攻擊預防手段，因為增量數據保存簡單，同時又以一系列快照的形式翔實地記錄了哪些數據執行過變更，以及它們在何時執行過變更。不過，完整性的需求不只是保護數據這么簡單，它還包括確保組件、服務器日志、軟件源代碼與版本，以及其他取證信息的完整性。這些取證信息可以在問題真的發生時，幫助我們判斷并找出遭到篡改之前的原始信息源。除了限制管理訪問之外，安全摘要（類似于校驗和）和數字簽名都可以用來執行強有力的完整性校驗，這些內容會在本書第5章進行介紹。

讀者應當切記，篡改包括很多不同的方式，并不一定是修改存儲設備當中的數據。比如在Web應用中，篡改可能發生在客戶端一側，也可能發生在客戶端和服務器之間；手段包括欺騙其中某一方修改數據，也包括在頁面上修改腳本，等等。

3．可用性

針對可用性的攻擊是網絡世界無法回避的現實問題，也是最難防御的攻擊方式之一。這類攻擊最簡單的形式是攻擊者向服務器發送過量的數據，通過看似合法的手段占用海量服務資源，導致服務資源耗竭。這表明信息會偶爾不可用。雖然永久丟失的數據也屬于不可用的數據，但是這類數據一般會被認為屬于完整性受到徹底破壞的情況。

匿名的拒絕服務（Denial of Service，DoS）攻擊（一般都是為了索取贖金）幾乎可以威脅到一切互聯網服務，所以防御這類攻擊是非常艱巨的挑戰。為了更好地防御這類攻擊，我們需要利用有能力承受大量負載的基礎設施來承載大規模的服務，同時維護系統的靈活性，確保在事件發生時基礎設施能夠迅速實現遷移。誰也不知道DoS攻擊的頻率和成本，因為很多受害者都是自行解決問題的。但毫無疑問的是，我們應該提前制定好詳細的計劃，為應對這類情況做好準備。

很多其他類型的可用性威脅的原理與此類似。對于一臺Web服務器來說，攻擊者創建的惡意請求可以觸發錯誤，導致崩潰或者無限循環，最終破壞服務器的服務。此外，其他的攻擊方式可以導致應用的存儲、計算或者通信出現超載，或者使用破壞緩存有效性的模式，這些都可以導致相當嚴重的問題。對軟件、配置或者數據進行未經授權的破壞都可能對可用性產生負面的影響（甚至對備份數據進行破壞，也有可能導致延遲）。

1.3.2　黃金標準

如果CIA是安全系統的目標，那么黃金標準描述的就是達到這個目標的方式。在拉丁語中，Aurum是黃金的意思，因此黃金的化學符號就是Au，碰巧信息安全的重要原則也都是以這兩個字母作為首字母的。

● 認證（authentication）：用高度可靠的方式來判斷主體的身份。

● 授權（authorization）：僅允許通過認證的主體執行操作。

● 審計（auditing）：為主體所執行的操作維護一份可靠的記錄，以便進行監控。

提示：這幾個單詞不僅長，而且長得差不多，讀者可能會遇到一些簡寫，即用authN代指認證、用authZ代指授權。這樣可以通過一種簡短的方式來清晰地區分這些術語。

所謂主體是指一切通過了可靠認證的實體，包括一個人、一家企業或單位、一個政府實體，以及一個應用、服務、設備或者其他有權執行操作的對象。

認證的過程，是指通過可靠的方式來建立主體證書可靠性的過程。系統往往會要求用戶證明自己了解用戶賬戶所對應的密碼，以此為注冊用戶執行認證。不過，認證的概念也可以更加寬泛。證書包括主體了解之事（如密碼）、所有之物（如令牌）或者主體自身的屬性（如生物數據）。在后文中，我們會詳細對證書進行探討。

認證后的主體在執行數據訪問時，也會受到授權結果的限制。授權會根據預先設定的規則允許或拒絕用戶的行為。例如，設置了訪問控制規則的文件系統可能會針對某些用戶把一部分文件設置為只讀。這就像在一家銀行中，柜員可能會把達到某個額度的交易記錄下來，但是如果額度過大，這次交易就需要得到經理的批準。

如果一項服務保留了一個安全日志，而這個日志可以準確地記錄主體執行的操作（包括那些因為授權失敗而沒有成功執行的操作），那么接下來管理員可以執行審計來對系統的操作進行監控，確保所有操作都是合理的。如果希望實現強大的安全性，準確的審計日志至關重要，因為它們提供了對真實事件的可靠記錄。詳細的日志可以為我們提供一份歷史記錄，揭示發生異常情況或者可疑事件時的準確情況。如果讀者發現某份重要的文件不見了，那么日志在理想情況下應該對此提供各類詳細信息，包括誰刪除了這份文件、何時刪除了這份文件等，以便技術人員以這份日志為依據，對此事進行深入調查。

黃金標準充當的是一種實現機制，旨在對CIA提供保護。本書此前把機密性和完整性定義為防止未經授權地泄露或篡改信息的行為原則，而可用性則會受到授權管理員的控制。真正兌現授權決策的唯一方法，是確保使用系統的主體都是正常通過認證的主體。審計則負責提供可靠的日志，記錄誰、何時執行了什么操作，再由技術人員定期審查違規行為，并保留追究違規者責任的權利。

安全設計方案應該明確地把認證和授權這兩者分開，因為把認證和授權結合在一起往往會導致混亂。如果能夠把兩者明確地分開，審計追蹤工作也會變得更加清晰。我們通過下面兩個現實生活中的例子，解釋為什么認證和授權應該分開。

● “你為什么把那個家伙放進保險庫？”“我也不知道，但是他一看就是合法人員啊?！?/p>

● “你為什么把那個家伙放進保險庫？”“他的ID卡上寫著Sam Smith，他還拿著支行經理手寫的紙條。”

第二種答復比第一種明顯要更加完整，因為第一種答復基本上一文不值，只能證明安保人員沒動腦子。即使保險庫被人入侵了，第二種答復可以提供詳細的信息以供人們進行調查：支行經理有權限放某人進入保險庫嗎？那個紙條是支行經理寫的嗎？如果安保人員保留了ID卡的復印件，這份復印件也可以幫助人們找到Sam Smith。如果支行經理寫的紙條上只是顯示“讓持條者進入保險庫”（相當于僅做了授權，沒有做認證），調查人員就很難弄清楚發生的情況，也很難調查出入侵者的真實身份。

1．認證

認證的目的是，根據能夠證明主體真實身份的證書，測試該主體的真實身份與其所聲稱的身份是否一致。認證服務也可能會使用一種更強形式的證書，譬如數字簽名或者挑戰碼。這些證書的形式可以證明主體擁有與其身份相關聯的私鑰，瀏覽器就是這樣通過HTTPS來認證Web服務器的。數字簽名是一種更加理想的認證形式，因為數字簽名可以讓主體在不泄露密碼的情況下證明自己掌握密鑰。

證書提供的認證信息包括下面這幾類。

● 所知之事（something you know）：如密碼。

● 所有之物（something you have）：如安全令牌。在虛擬世界中，所有之物也包括某種類型的證書、密碼或者簽名文檔，這些信息必須是無法偽造的。

● 自身屬性（something you are）：即生物特征（如指紋、虹膜等）。

● 所處之地（somewhere you are）：經過驗證的所在地，如與安全場所中私有網絡建立的連接。

在這些認證方法中，有很多方法都是相當簡單的。你的所知之事可能泄露，你的所有之物可能失竊，你的所處之地有很多方法可以加以操縱，就連你的自身屬性都有可能被偽造（甚至如果遭到盜用，我們連修改都很困難）。在當今網絡世界，認證基本上已經在網絡中得到了普及，認證行為幾乎每時每刻都在發生，甚至有時認證這項任務比現實世界中的身份認證都要復雜。例如，在網絡中，瀏覽器會充當信任代理的主體。瀏覽器會首先在本地執行認證，并且瀏覽器只有在認證成功的前提下才會把加密的證書發送給服務器。系統通常會使用多個認證要素來避免認證信息遭到盜用的問題，同時頻繁地進行審計也是認證的一大重要后盾。用戶使用兩項認證要素總比使用一項認證要素要好（但也好不了太多）。

不過，當人們加入一家公司、建立自己的賬戶，或者在忘記密碼后請技術支持團隊恢復自己的訪問時，組織機構必須能夠判斷人員的真實身份，才能為他們分配證件。

比如，在我入職谷歌公司的時候，所有新員工在周一上午集合，我們對面是幾位IT管理員。他們按照新員工名冊一一檢查了我們的護照或者其他身份證件。檢查無誤之后，他們才發給我們工牌和公司的筆記本電腦，并讓我們設置自己的登錄密碼。

IT團隊檢查我們的證書（也就是我們的身份證件等），就是為了判斷我們提供的材料是否能夠準確無誤地證明我們的身份。這份證書所提供的安全性取決于很多因素，包括官方證件及其支持文件（如出生證明）的完整性和準確性、偽造這些證件的難度、非法獲得這些證件的難度等。在理想的情況下，一份從出生時注冊身份一直更新至今的信息鏈，應該在我們的一生中都能夠保存完整，這樣才能唯一地標識我們的身份信息。安全地標識一個人的身份的難度很高。因此，為了保留一些隱私和自由，人們寧愿在日常生活中選擇不那么嚴格的措施。本書的重點并不是如何鑒別一個人的身份，而是前文剛剛提到的黃金標準。身份管理這個更加復雜的問題這里不贅述。

只要條件允許，我們就應該依靠現成、可靠的認證服務，而不應該動輒“自力更生”。哪怕是簡單的密碼認證也很難安全地落實。如何安全處理自己已經忘掉的密碼更是一個麻煩的問題。一般來說，認證的過程應該包括對證書進行校驗，并給出認證通過或者認證失敗的響應消息。不要采用認證“部分成功”的做法，這樣等于在暗示黑客可通過不斷試錯來破解密碼。如果希望降低暴力破解密碼的風險，常見的做法是讓認證密碼從根本上很難通過計算破解，或者在認證流程中引入一些延遲（詳見本書第4章介紹的“避免可預測性”）。

在對用戶進行認證之后，系統必須找到一種方式來安全地綁定主體身份。一般來說，認證模塊會給主體頒發一個令牌，主體在認證中使用令牌即可，這樣就可以避免后續被要求執行完整的認證過程。這里的關鍵在于，主體可以借助代理（如瀏覽器），直接把認證令牌作為一種證明自己身份的信物，為未來的身份認證請求提供一種安全的方式。這種方式會代表認證主體來綁定存儲的令牌，在未來收到請求的時候提供令牌即可。網站往往會通過瀏覽會話所關聯的安全Cookie來達到這個目的。不過，針對其他主體和界面，也有很多不同的方法。

安全綁定認證實體后可以用兩種基本方式進行入侵。第一種方式顯而易見，那就是攻擊者可以盜用受害者的身份。此外，接受認證的主體也有可能與其他人相勾結，把自己的身份信息泄露給別人，甚至把自己的身份強加給別人。幾個人分享同一個付費訂閱的節目就屬于這種入侵方式。網站對這種方式基本上無能為力，因為主體和令牌之間的綁定關系本來就是比較松散的，何況這種關系還取決于主體自己是否愿意合作。

2．授權

到底應該允許還是應該拒絕重要的操作行為？這類問題應該根據主體在認證時確立的身份來決定。各類系統會通過業務邏輯、訪問控制列表或者其他正式的訪問策略來實現授權功能。

匿名授權（即不進行認證的授權）適用的場合可以說寥寥無幾。在現實生活中，匿名授權相當于拿著車站公共儲物柜的鑰匙存取個人物品。根據時間設置訪問限制（比如，僅允許員工在工作時間訪問數據庫）也是匿名授權的一個示例。

針對一項資源，應該通過一項單一的要素來實施授權，不要讓授權代碼散布在整個代碼庫中，否則這會是運維和審計人員的一場噩夢。因此，應該依靠某一項公共框架來唯一地提供訪問授權。精良的設計方案可以幫助開發人員正確地處理系統?？傊?，無論何時何地，都建議從眾多標準的授權模型中選擇其一，而不是使用混搭的方案。

基于角色的訪問控制（Role-based Access Control，RBAC）可以在認證和授權之間建立起一座橋梁。RBAC會根據分配給認證主體的角色（role）來提供訪問授權，這樣就可以通過統一的框架簡化訪問控制。比如一家銀行，柜員、經理、貸款專員、保安、財務審計師和IT管理員等占了一半的角色。RBAC并不會為每個人單獨定義訪問權限，而會根據每個人的職責指定一個或者多個角色，從而為人們自動分配相關聯的唯一權限。在更高級的RBAC模型中，一個人可以擁有多個角色，人們可以為不同的訪問主動選擇使用不同的角色。

授權機制遠比傳統操作系統提供的簡單讀/寫訪問控制要細致得多。人們可以設計更加強大的授權機制，以便在不損失重要功能的前提下對訪問進行限制，提升安全性。這些更高級的授權模型包括基于屬性的訪問控制（Attribute-based Access Control，ABAC）、基于策略的訪問控制（Policy-based Access Control，PBAC）等。

讀者想想銀行柜員的例子，就可以發現對授權進行精細化可以達到收緊策略的目的。

限速：一位柜員每小時可能最多處理20筆交易。如果超出了這個數量，這些交易就很可疑了。

每日時間：交易必須在工作時間內完成。

不服務自己：禁止柜員用他們的個人賬戶進行交易。

多個主體：超過10000美元的交易需要經理批準（以此消除一個壞人一次性就可以轉走大量資金的風險）。

最后，對于某些數據來說，只讀訪問的訪問級別依然過高，密碼就屬于這類數據。系統往往會通過比較明文密碼的摘要的方式來校驗密碼，以免泄露明文密碼。用戶名和密碼都會被發送給一臺前端服務器，由前端服務器計算密碼的摘要值，然后把摘要值發送給認證服務，同時迅速摧毀這個明文密碼的一切痕跡。認證服務無法從證書數據庫中讀取明文密碼，但是它可以讀取摘要值，它會用這個值來與前端服務器提供的值進行比較。通過這種方式，認證服務就可以對證書進行校驗了，但認證服務永遠無法訪問任何密碼。因此，即使認證服務遭到入侵，也不會導致密碼被泄露出去。除非界面設計能夠提供這類安全方案，否則它們會失去這樣一個減少數據泄露可能性的機會。本書會在4.2.2節進一步探討這個話題。

3．審計

為了讓組織機構能夠對系統的行為進行審計，系統必須基于所有對運維安全至關重要的信息生成一份可靠的日志。日志中包括認證和授權事件、系統啟動與關閉、軟件更新、管理訪問等。審計日志也同樣必須能夠抗篡改。在理想情況下，最好是連管理員也無法插手修改這些日志，這樣可以將其視為絕對可靠的記錄信息。審計是黃金標準中的一個重要環節，因為網絡中總是會發生這樣或那樣的事件，認證和授權策略的漏洞也總是難免的。審計可以自始至終為人們提供必要的信息。在工作中，當授權主體做出與人們信任相悖的行為時，審計信息可以幫助人們規避由此帶來的風險。

如果處理得當，審計日志可以為日常檢測、系統性能級別評測、錯誤和可疑行為檢測帶來巨大幫助，也可以在事件發生后用于判斷攻擊實際發生的時間和評估攻擊帶來的損失。切記，要想對一個數字系統進行徹底的保護，不僅要正確地實施策略，還要成為一位負責任的信息資產管家。審計可以確?？煽康?、通過了認證的主體在自己的權限范圍內采取的操作都是合理的。

在2018年5月，推特[1]公布了一個讓人尷尬的bug：他們發現在不經意地修改了一段代碼之后，原始登錄密碼就直接顯示在他們的內部日志當中。雖然這件事導致密碼遭到濫用的可能性不高，但是它會打擊用戶的信心，因此絕對不應該發生。日志應該記錄操作的細節，但是不存儲任何實際的隱私信息，這樣才能把信息泄露的可能性降到最低，畢竟技術人員中有很多人日常就會查看這些日志。關于如何滿足這樣的需求，本書附錄A中的設計文檔示例詳細列出了滿足標準的日志記錄工具。

---

[1]　已更名為“X”。

系統也必須有能力阻止人們通過篡改日志來掩飾那些惡意的操作，如果攻擊者有能力修改日志，他們當然會把自己的操作痕跡清除得干干凈凈。對于那些特別敏感的高風險日志，應該由不同管理和操作團隊負責的獨立系統來管理其審計日志，以防內部肇事者掩蓋自己的操作痕跡。雖然做不到盡善盡美，但是獨立系統的存在本身就會對那些“耐人尋味”的業務產生強大的抑制作用，這就像一排高度有限的柵欄和一處位置顯眼的視頻監控攝像頭就可以有效地防御入侵一樣。

此外，任何嘗試規避獨立系統的行為都會顯得相當可疑，每一項錯誤的操作都會給攻擊者造成嚴重的影響。一旦被發現，他們也很難對自己的罪行進行抵賴。

不可抵賴性（non-repudiability）是審計日志的一項重要的屬性。如果日志顯示，一位有名有姓的管理員在某個時間點允許了一條命令，之后系統立刻就崩潰了，那么這次系統崩潰的責任就很難推卸給別人。反之，如果一家單位讓多名管理員分享同一個賬戶（千萬不要這樣做），這家單位就無法判斷誰執行了哪些操作，每個人也就都有了抵賴的口實。

最后，審計日志只有在人們監控日志內容時才能發揮作用，因此務必認真地分析那些異常事件，然后不斷跟進，并且在必要情況下采取合理的行動。為了達到這樣的目的，我們應該遵循Goldilocks原則，即日志記錄的數量和規模應當適宜。一方面，日志數量過大就會讓人們更容易忽視日志的內容，畢竟人們很難從大量嘈雜無序的日志中提取出有用的信息。另一方面，缺少細節的日志則有可能遺漏關鍵的信息。因此，找到一個合理的平衡點會是一項長期且艱巨的任務。

1.3.3　隱私

除了信息安全的基礎（即CIA和黃金標準）之外，本書要介紹的另一基本話題與信息隱私這個領域有關。安全和隱私的邊界很難清晰地界定，它們既緊密相關又大不相同。在本書中，我會把重點放在它們的共同點上，但也不會去統一這兩個概念，而是把安全和隱私都包含在構建軟件的流程這個話題中。

為了尊重人們的數字信息隱私，我們必須考慮其他人為因素，對機密性原則進行擴展。這些因素包括：

● 客戶希望人們采用的信息收集與使用方式；

● 明確界定如何合理使用和披露信息的策略；

● 與收集和使用各類信息相關的法律法規；

● 與處理個人信息有關的政治、文化和心理等因素。

隨著軟件在人們生活中所扮演的角色愈發重要，人們和軟件之間的聯系也變得越來越緊密。軟件開始涉足人們生活的敏感領域，這就催生了很多復雜的問題。過去發生的那些信息事故和濫用導致的事故讓人們越來越清醒地認識到其中存在的風險。隨著社會開始通過法律的方式來應對這些新的挑戰，妥善處理個人信息的難度也水漲船高。

在軟件安全領域，人們對從業者提出了下列要求：

● 要考慮到收集和共享數據會給客戶和相關人員帶來哪些影響；

● 要把可能的問題都標記下來，并且在必要的時候請教相關專家；

● 應該針對隱私信息的使用方式建立明確的策略和指導方針并嚴格遵守；

● 要把這些策略和指導方針轉化成強制執行的軟件代碼；

● 要維護一份準確的記錄，包括獲取、使用、共享和刪除數據的歷史信息；

● 對數據訪問授權和特殊訪問行為進行審計，確保這些行為符合安全策略。

如果說對系統控制進行維護、為人們提供合法訪問是一份既簡單又枯燥的安全工作，那么涉及隱私信息的工作就很難找到一個合適的字眼來形容了。隨著社會開始通過收集數據來深入探索人們的未來，我們仍然堅定捍衛人們維護自己隱私的愿望，并且制定保障人們隱私的規范。保護隱私殊非易事，明智的做法是讓使用數據的行為盡可能透明。這就包括讓所有人都能輕而易舉地讀懂我們的策略、收集盡可能少的數據，尤其是涉及個人身份的數據信息。

收集信息必須擁有明確的目標，保留信息必須保證信息確有價值。除非設計方案中就規劃好了合規的用法，否則應該避免提前收集這樣的信息。不要因為信息“將來有可能用到”就隨隨便便收集，這樣做的風險很高，絕不是什么好做法。如果未來合法使用某些數據的必要性不高，最合理的做法就是安全地刪除這些數據。針對那些特別敏感的數據，或者為了實現最大程度的隱私保護，我們應該采用直截了當的手段：只要數據泄露的風險超過了保留這些數據的益處，我們就應該刪除這些數據。有時候，保留幾年前的電子郵件確實比較方便，但是這種做法恐怕難以滿足任何清晰的商業需求。反之，內部電子郵件如果通過某種方式泄露了出去，有人就可能需要為此承擔責任。所以，最好的策略往往就是刪除這樣的郵件，而不是想著“說不定哪天用得到”，于是就一直保留著所有的數據。

處理信息隱私的完整流程超出了本書的范疇，但是對任何系統（只要這個系統的目的是收集人們的數據）的設計來說，隱私和安全性都是兩個緊密相關的屬性。畢竟，人是操作幾乎所有數字系統的主體，雖然操作的方式不一而足。采用強大的隱私保護方式是建立強大安全性的必經之路，所以本章的目標就是喚起人們的意識，即把保護隱私融入軟件的設計之中。

雖然保護隱私是一個復雜的問題，但是解決隱私問題的一大最佳實踐卻是人盡皆知的：人們必須明確表達出自己對隱私問題的關注。隱私策略和安全性不同，隱私策略能夠在一定程度上權衡信息服務會在多大程度上利用客戶的數據?！拔覀儠磸褪褂媚銈兊臄祿€會把這些數據賣給別人”，這當然是隱私保護的一個極端，但“早晚有一天我們不會再給你們的數據提供保護”也稱不上是合理的安全立場。當用戶的期望和實際的隱私策略相脫節時，或者當用戶違反了明確的安全策略時，隱私問題就會暴露出來。用戶的期望和隱私策略脫節是因為安全人員沒有向用戶主動解釋他們處理數據的方式。用戶違反安全策略則是因為安全策略仍然不夠清晰，或者負責人對其熟視無睹，又或者這些安全策略在一場安全事故中遭到了破壞。

提示：本書附錄D包含CIA和黃金標準的匯總表格，以茲讀者參考。