• 發行項

桌面檔案安全性和循規

Wes Miller

身為 IT 專家，您可能會面臨應該互補的目標往往反而相互對抗的窘境。安全性與循規就是兩個這樣的組織目標，達到其中一個目標應該能夠補強另一個目標。可惜，實際情況往往不然。本專欄旨在描述

為何保持安全性並不一定代表會與您所需的計劃相符，以及為何保持循規通常不代表安全性，或至少說明如果循規真的等於安全性，為何您沒有獲得應有的安全性。

安全性並非選擇題

SDL 資源

循規通常會涉及外部加諸在組織、產業、公司或產品上的需求 (人事、作業程序、基礎結構、技術等等)。有時循規必須遵守產業內部所公布的標準 (譬如付款卡業資料安全性標準，即 PCI-DSS)。在理想的情況下，這些需求與標準會符合組織現已運作的計劃，至少在某種程度上相符。隨著採用標準日益普及，只要您還想讓企業營運，就無法再忽視它；最後您必須毅然投入，然後盡可能達到最佳效益。

另外一種循規往往比較麻煩。我指的是政府所頒佈的計劃，例如美國健康保險流通與責任法案 (HIPAA) 和沙賓法案，這些計劃在執行上和時間上都沒有您選擇的餘地。

有關遵循法規的重點是，它通常都有一套「由上而下」的方法。一般來說，您會看到用來定義計劃的餅乾壓模式範本，您必須審視您的產品和作業程序，然後設法讓產品和作業程序緊扣交付給您的怪異範本。您不僅要了解循規計劃的用意，更重要的是，若不遵循或無法遵循這些計劃，將有什麼法律或財務方面的後果 (若有的話)。

雖然我們都贊同許多循規計劃的主旨，但付諸執行往往很困難，而且可能不符合所要的目標。而且很遺憾地，這些計劃很多都沒有實質作用 (也就是說，計劃失敗時，並沒有直接的法律或財務後果)。

老實說，身為病患，我沒辦法充分說明 HIPAA 對我的好處是什麼。我只能說，HIPAA 害我去看醫生的時候多了好多文件要填。更糟的是，這些計劃可能產生無心之過。您是否曾試圖將重要的醫療資訊從某位醫生或診所轉交到另一位醫生手上？若無書面授權，無論是多緊急的資訊，怎麼也辦不到。

重點是，從很多角度來說，某些循規計劃變成是選擇題計劃。這表示您設計或修改作業程序或產品完全都是為了遵守循規計劃。就像我經常問我的三歲小孩的一個問題：「這麼做好嗎？」

另一方面，安全性是一種由下而上的計劃 — 前提是執行的方法正確。無論您是設計軟體產品或公司新網路的架構，都要謹記評量兩次而非一次這個關鍵概念。舉例來說，當您設計產品架構，一個完善的草創方案必須界定通訊、當地語系化、版本等等，同時它也應該描述打從一開始就建置在應用程式中的安全性項目 (而且在整個開發過程中您也應該繼續調查和調整這些安全性項目)。

若您是沿用舊有應用程式或架構 (相信大部分人都是)，同樣必須執行我在本專欄中一再強調的深度安全性檢查。如果您不了解事情的來龍去脈，怎麼可能確認安不安全？如需 Microsoft® 安全性開發生命週期 (SDL) 的詳細資訊，請參閱資訊看板「SDL 資源」。

顧全大局

我還記得早期被灌輸安全性不只是實作加密、存取控制清單 (ACL) 或 TLS，或公開金鑰基礎結構 (PKI) 而已的觀念。真正的安全性有賴於掌握大局：了解某版本的通訊協定為何被刪除或從來不受支援；為何新的配置能夠阻止攔截式攻擊；您的第二版產品為何比第一版安全得多，雖然第一版執行比較快。而且您也必須知道您的基礎結構的各部組件如何彼此搭配運作。

另一方面，循規表示運用您的技術並確保所建置的基礎結構符合特定條件。有些計劃，例如付款卡業資料安全性標準 (PCI-DSS) 或北美電力可靠度委員會 (North American Electric Reliability Council，NERC)，都是立意良善而且可以促進真正的安全性改革。但是到頭來 — 您必須根據這些「循規計劃」什錦拼盤來調配您自己的特定專案以及有限的可用資源，因而妥協安全性計劃。

安全性向來不受軟體開發青睞。很多人一定曾在公司中碰過安全性問題「晚點再處理」的情況。循規計劃之所以會存在，就是因為這種風氣 — 安全性不用急著處理 — 行不通，而且向來如此。

綽綽有餘

我最近換了個工作。我目前任職於德州奧斯汀的一家新創公司，這家公司專門建置應用程式安全清單技術，這項技術有點類似我們使用 Winternals 的 Protection Manager 產品所建置的技術。我特別喜歡跟客戶討論一件事，就是客戶覺得自己目前的技術有多安全 — 更明確的說，客戶認為他們所採用的技術組合能夠保障多少基礎結構的安全性。雖然這些技術大多很安全而且不會敞開安全性漏洞的大門，但是有一句我常聽到的評論讓我有點愕然，就是系統「已經夠安全了」。

循規計劃很奇妙 — 要就遵守，不然就不遵守。責任完全在您，不遵守計劃的代價通常是罰金、刑罰或從組織中剔除。但通常並不足以確保真的會有什麼改變。

如果是政府明訂的計劃，我常會碰到一種態度：「只要夠應付稽核員就行了」，或是寧願不要將循規架構付諸執行，因為相關法規 (例如 HIPAA) 並未充分援助強制執行 — 也就是說，不投保就上路，以後再面對可能的後果，這麼做的成本低多了。

安全性也常碰到相同的障礙，不過我覺得至少它比較具體。若身為開發人員或執行者的您先主動告知主管：省略規格中的區段 foo 將使得產品遭受攻擊的機率大幅提高，至少在產品出貨或部署完成後，您可以理直氣壯的說：「我早說過了」。我在處理循規計劃的經驗是，計劃的執行往往是急就章，而且預算少得可憐。目標純粹是符合計劃所要求的最低標準 — 因此我想可能只能滿足計劃的表面字義而非內在精神。

決定您的定位

安全性和循規資源

如果我說您應該要盡可能確保產品和組織的安全性，聽起來可能太理想化，但實際上大部分的循規計劃的確是因建構不良或更常見的自以為是而發起的折衷方案。很遺憾地，在我們身處的世界中，「綽綽有餘」就只是綽綽有餘而已。但是在安全性的世界中不吃「綽綽有餘」這一套。身為 IT 專案人員的我們可以將循規計劃牢記在心，試著在精神與實務雙方面滿足這些條件，但同時也必須確保我們建置的基礎結構不僅是盡量安全，而是要務必安全。換句話說，藉由真正的安全性來保持循規，而不是單純應付循規計劃。

最重要的是，退一步想想您所建置的技術，它屬於商業軟體的一部份，還是要整合至大型系統的一組技術。我必須一再強調，了解系統的相扣環節、這些環節的搭配運作方式以及系統面臨的重大威脅，這些都很重要。

根據您所處的產業，不同的循規計劃對您的重要性可能不定。您可能會在日常生活中遇到這些循規計劃，或只有在設計新專案或技術時遇到。或者，這些循規計劃也許只有在處理特別指定的循規檢閱或稽核時出現。這些都無所謂。我並不認為應該忽略循規計劃，但我懷疑您敢不敢挑戰現狀，不只把目標放在應付交付給您負責的循規計劃，而是執行完整的安全性檢閱來徹底了解您的技術，然後在執行循規檢閱的同時建立其模型。

有什麼好損失的？

畢竟，不遵守循規計劃的罰則似乎含糊不清。不循規會讓您面臨風險，而循規計劃正是要防範這種情況。其後果雖然看起來很模糊不清或遙不可及，但卻是真實存在的。它們可能也不會對您 (個人) 產生影響。記得要務實，但做好最壞情況的打算。

如果您從嚴格的安全性角度來看同一件事，威脅應該顯而易見 — 而且更重要的是，您應該能夠立即識別出開放安全性漏洞的潛在成本。

我與很多人討論過此主題，他們都強調循規計劃有時曖昧不明 — 因為循規計劃常會留下許多解讀空間。不過，一旦您進行了安全性檢閱，安全性疏忽的情況就並非如此了。受忽略的安全性所產生的立即威脅，應該非常清楚明白。否則，您可能需要重新考慮安全性檢閱的相關人事；您可能缺乏關鍵的小組成員來協助您確認解決方案中的實際問題。

原地打轉

在去年的安全性專題專欄中，我討論過＜如何不遺失資料＞(technet.microsoft.com/magazine/cc162325)。一年過去了，更多系統遭到侵害，更多遺失的未加密膝上型電腦，還有更多個人資料落入可疑者的手中。很難說我們是否達成任何進展。我們為何還在原地打轉？計劃的執行常受到延遲，並且是在激少的預算和過份耗用的資源下試圖以最短的時間提供最多的功能。

可惜，這種環境會導致極度匱乏的最低限度工作變成基準。而這種方式絕對無法確保解決方案的安全性或循規，而且也並非計劃時程或成本的關鍵。

我個人堅信：

  1. 若您無意保障解決方案的安全性，就不應建置它。
  2. 每次新增功能時，您都必須在開始前先設計其中的安全性。
  3. 如果您的組織不願意在工程流程內建置安全性，您應該質疑公司或組織的整體目標為何。

組織所擁有的客戶或合作夥伴個人資料越來越多，而組織有責任保障這些資料的安全性。可惜的是，在我們所處的世界中，並不將安全性視為應有的預設選項，而且員工也無法大膽質疑組織對安全性所做的努力。

當安全性 (非循規) 無法落實時，隨之而來的反應往往是：「該是時候保障系統安全了」，「身份竊盜保險」就成為標準的責任方案來取悅客戶、學生、病患和員工，而這些人的個人資料還有潛在的財務健全都有洩漏之虞。

我們常在太短的時間內被要求太多，獲得的卻太少。但是我們身為 IT 專業人員有責任質疑安全性為何不是主要重點，為何管理階層總是只從循規計劃或安全性失敗，以及實際或可能的法律威脅 (這可能會讓組織蒙羞或面臨風險) 的層面來思考安全性。

接受我的挑戰

最重要的是，我請求您挑戰現狀。如果您被交代要達成循規目標 — 請盡量確保您在這麼做的時候，並非只把時間浪費在滿足別人的安全性概念上。您應該要確認您的目標是保障系統安全性，在此同時，也要定義足夠的程序或基礎結構來達成循規計劃。如需本主題的詳細資訊，請參閱「安全性和循規資源」資訊看板。

總之，循規往往不是尋求安全性的正途。但是只要能正確的實作和調整安全性，通常就能通往循規之道。

Wes Miller 在位於德州奧斯汀的 CoreTrace (www.CoreTrace.com) 擔任資深技術產品經理。他之前任職於 Winternals Software，並且曾在 Microsoft 擔任專案經理一職。您可以透過電子郵件與 Wes 聯絡：technet@getwired.com。

© 2008 Microsoft Corporation 和 CMP Media, LLC.保留所有權利；未經允許，嚴禁部分或全部複製.