強化軟體開發資安要作的5件事

安全性設計這個議題無所不在，每個人都應該盡自己的本分，不只是開發團隊，還包括應用程式管理人員以及終端使用者。因此，也許有人要全面監控安全性，但並沒有單獨一位人員是安全性設計師。

這些年來一直有大量的討論是與IT的安全性有關的議題，有些是用類似網路大戰及網路恐怖主義等世界末日般的措辭。無庸置疑的，現在我們周遭的確是有很多網路犯罪，但如果看仔細一點，你會發現它們大部分的獵物都是幼稚的電腦使用者。當然，這並不能讓這種事變得比較能讓人接受，但這意味著我們能打造一套安全的IT應用程式，而最大的罩門則是人們。

無庸置疑的，組織應該要顧慮到網路間諜活動。大部分的攻擊都是仰賴在有人第一次不小心將惡意的程式載入到辦公室的PC上。有種有效的攻擊方式為魚叉式網路釣魚（spear phishing attack）──有人在被鎖定的目標組織中，收到一封看起來像是該組織中其他可信的人所寄來的電子郵件，信中夾帶的是個檔案。

這個檔案其實是一支程式，它可以開啟一個後門通向外部的機器，那部機器不太可能是攻擊的來源PC，而是某部被奴役的伺服器，代替攻擊者來發動攻擊。這個程式可讓攻擊者窺探、下載額外的程式、以及上傳資料。有許多種防禦的辦法可用來對抗這種攻擊：

●  教育使用者不要被釣魚式攻擊所欺騙。不過，也許你的組織中有人在為敵人做事，那樣的話這個方法就不管用了。

●  將電子郵件伺服器設定成會將執行檔過濾掉。不過比較難防止使用者去點擊連結以及偵測指向含有惡意軟體網站的連結，點擊這種連結被稱為偷渡式下載（drive-by download）。這種做法大部分都是可防堵的，但前提是：

●  該PC的軟體有保持更新到最新的版本

●  使用者不會利用管理者權限來進行日常的工作

●  防火牆有被開啟

我們又再次回到教育的問題了。

●  找一家安全性專業的公司來合作，並且盡快嘗試找出並且去除任何留有後門的程式。當然，在程式被載入與被去除之間有一段時間差。

●  確保會存取網際網路的PC不會有權限去存取任何敏感的資料。不幸的是，現在每個人都要能夠存取網際網路，而且人們想要在家工作，通常會使用含有敏感資料的PC來連接網際網路。

●  確保使用者存取的敏感資料是被加密過的。但對於PC載入的文件來說，有一種按鍵記錄程式（keystroke-logging program）能夠讀取使用者所按的鍵然後觀察所輸入的密碼。

●  試著避免讓間諜程式與其來源伺服器聯絡。不過許多間諜程式偽裝成一個Web瀏覽器來與來源伺服器聯絡，因此防堵這些間諜程式就等於得禁止所有Web的存取。

將資料庫的資料加密是很容易的，那可讓間諜程式要攻擊資料庫時變得比較困難，而且這些攻擊所造成的損害，其中大部分是由於機密文件遭竊、而不是資料庫的資料。然而，有些應用程式允許將資料庫的資料轉成試算表檔案，那樣會再次地開啟漏洞。

這些討論說明了設計一套安全系統的主要困難點：弱點在於人。人們通常想要被信任，假如他們可以自由決定，他們會很樂意地將具有特殊權限的使用者名稱與密碼告訴朋友或熟人，並且把機密的資訊傳送給任何一個聲稱他們需要該資訊的人。

這個推論是大家經常忽略的一點：我們應該設計一套能夠鼓勵良好行為的安全系統。尤其是，安全措施不應該讓人們在進行一般業務時變得比較困難，因為如果這樣的話，人們會去尋找方法，而通常來說他們最後還是會找到方法。例如，他們會打電話給身在其他部門的朋友，請他們將所需要的資訊透過電子郵件寄出來。你要營造一種文化，在這個文化下因為每個人都知道系統會允許他們看到他們想知道的資料，因此任何想要規避安全性的請求都會被以懷疑的態度看待。換句話說，太多與太少的安全性限制是一樣不好的。

IT應用程式的安全原則

安全設計的目標很容易解釋：去控制哪些人可以做哪些事。我們可將這個分解成以下幾點：

●  認證設計。你要決定如何辨識使用者，並決定他們需要給出什麼樣的證據來證明他們就是所宣稱的那些人。

●  存取控制設計。你要給不同的用戶群組（或個別使用者）不同的存取權限。考慮在一套應用程式中所有可能的命令集合，每個用戶群組可以使用這個命令集合中的一個子集合命令。此外你也可能要對資料的存取進行控制，例如，線上銀行的客戶雖然都有同樣的命令集合，但是被限制只能用在自己所擁有的帳戶上。

●  使用者管理設計。你須決定如何新增使用者、刪除使用者、添加權限、以及移除權限等。你也要決定由誰來負責使用者的管理。

●  安全防護。你須定義如何設定伺服器以及如何寫程式，才不會有安全漏洞讓有心人規避認證程序或存取控制。你還需要做些保護以避免遭受破壞與對抗資源竊賊－即惡意地讓你的應用程式部分或全面性的無法使用。

●  安全監控設計。你須決定如何找出應用程式所受到的攻擊，以及如何蒐集攻擊的紀錄。

IT應用程式設計團隊也許不會被允許去執行（或沒有能力執行）各方面的安全設計。安全防護特別仰賴在伺服器的安全、網路安全、以及實體安全等，這些都是很深的技術主題。因此取而代之的，IT應用程式設計者們通常只會對IT作業部門提出需求，讓他們提供一套安全的系統來運行他們的應用程式。假如你採用的是某個雲端廠商，很多伺服器安全、網路安全、及實體安全都將會是該廠商的責任。

IT應用程式設計團隊不被允許執行各方面安全性設計的另一個原因是，在組織中已經有個安全部門會去吩咐某些部分的安全設計，特別是認證（也許是採用全公司的認證機制）、安全管理、以及安全監控等技術領域。

認證

做認證最簡單也是最常見的方法，就是讓使用者利用用戶名稱與密碼來登入。有許多反對這樣設計的理由。第一，實務上密碼很容易被猜到。有非常驚人的人數只是簡單地將密碼設定為「password」這幾個字母，這就是為何有些網站強迫你選擇一個含有八個以上、混合數字與大小寫字母的原因。第二，人們到頭來會有很多密碼，各用在他們使用的許多應用程式上，而由於他們無法全部記住，於是就會將它們寫下來，不然他們就是會在很多不同的應用程式上使用相同的密碼。第三，假如有人在偷看、或者是你並不知道有個按鍵記錄程式在執行，他們就能夠看到你輸入了什麼。

與很多線上企業（而且是知名的）相比，銀行似乎是比較擔心最後這個問題，也許是一般企業比較害怕受到較沒安全意識的客戶拒絕使用 ，因為那些正是大多數的人。在我的經驗裡，銀行會問一些額外的問題，例如「你母親的娘家姓什麼？」，而且還會讓部分密碼空著，讓你只需要針對它從密碼中隨機選擇的三個字元來輸入。

將部分密碼空白的原因是為了給按鍵記錄程式創造一些難度。下一次你登入時，你被要求輸入的會是另外不同的三個字元，因此按鍵記錄程式在重新組合出完整的密碼之前，必須觀察你登入很多次。增加按鍵記錄程式困難度的另一個方法，就是設計一種利用移動滑鼠與點擊滑鼠來提交密碼的方法，而不是利用打字的方式，例如，你可提供一個隨機排列字元的虛擬鍵盤。

認證最脆弱的區域就是密碼的復原──換句話說，就是使用者忘記密碼時的處理步驟。主要的問題有：

●  你怎麼保證你有將新的密碼傳送給正確的人？

●  你怎麼防止密碼被中途攔截？

有些組織認為將新密碼傳送到一個電子郵件地址就夠了，但利用簡訊傳送也許比較安全一點。其他會問類似這樣的問題，「你母親的娘家姓什麼？」然後在線上或透過電話將密碼給你。只要是想認真入侵你帳號的人將會知道這些問題的答案。還有另外一些應用程式會透過信件或使用混合的方法（一部份密碼用傳統郵件來送、另一部份以電子郵件來送）來傳遞新的密碼。雖然使用者會感到有點痛苦，但是這樣做安全多了。和以往一樣，最佳的方法是哪一種，要視你需要讓應用程式多麼安全而定。

一種為應用程式認證的方法為單一登入（single sign-on）。這個想法是讓使用者登入一次即可操作很多套應用程式。因此如果登入比一般還要複雜一些，使用者也比較不會覺得有問題，而且使用者也可享受只需記住一組密碼的好處。它的缺點是如果有人發現了某個使用者的密碼，同時會有很多套應用程式可被入侵，而非只有一套。再者，人們常會離開在電腦時還保留登入狀態一段時間，那樣可能讓有人有機會使用你的機器，在你離開座位、前去開會、或是去吃午餐時假裝是你來進行某些活動。你可透過被稱為OpenID的Web技術來進行單一登入，這樣做時必須要有一個Web網站（Google或Facebook都是典型的例子）負責處理登入。

當使用者連到這種應用程式時，該應用程式會發送出一個訊息給另外那個Web網站來認證。應用程式會收到返回的訊息，告訴它登入是否成功。假如你想要實際看個例子，試著登入stackoverflow.com，這是個很有用的網站，專門回答程式設計方面的問題。雖然OpenID是個運作得很好也很健全的技術，而且帶來單一登入Web的好處，但如果我在經營一家銀行的話，我就不會信任說某人的Google登入是特別安全的。為應用程式開發一套安全計畫時，有一部份要做的工作是，你要在承擔多少風險、以及讓使用者享受多少方便之間取得一個平衡點。

存取控制

使用者一旦通過認證，他們便開始進入一個會期（session）當中。在很多（也許佔大部分）應用程式中，程式必須利用認證流程所提供的使用者識別，找出該使用者所屬的用戶群組。

應用程式中的存取控制方式是由應用程式來決定。對於安全性的理解有個會讓人混淆的地方是，包括作業系統、資料庫軟體、交易監控程式、以及Web伺服器軟體等全都聲稱會進行存取控制。它們的確會做，不過所做的程度非常有限，而且它們通常假設一支程式是由一個使用者使用的，這在Web伺服器上的應用程式來說顯然不是這個一回事。

應用程式中的存取控制主要是要確保：

●  應用程式存取控制。只有特定一組人被允許使用這套應用程式。

●  功能存取控制。在一套應用程式中，特定用戶群組的成員會被允許去存取一些額外的任務。例如，也許會有額外的功能可以讓經理級的人員使用。要實行這樣的機制，最好的方法是在畫面上只出現該使用者能夠執行的作業。例如，經理級人員的網頁上也許會比別人多了幾個額外的按鈕。

●  資料存取控制。例如，在線上銀行交易中，你所看到的資料只限於是你自己帳戶所擁有的。

在書籍或文獻中說明的還有另一種型式的存取控制，那就是安全性層級。這是相當在電腦上將文件標示為機密、最高機密、以及其他等等的機密等級字樣，而這個想法是使用者具有一個許可級別，讓他們能夠根據級別來決定可以看到那些文件。（可以讓他們的文件寫入層級高於閱讀層級！）我從未被要求過從事類似這樣的系統，不過我在某些高度安全的環境工作過，例如銀行與執法單位。許多廣為人知的間諜案例，例如Robert Hanssen與Edward Snowden，其不尋常的一面就是他們能設法弄到手的文件之數量與涵蓋範圍。這留給人們的印象是，到底CIA有沒有實施多重等級的安全控管，他們當時並沒有好好的實施。

然而，我曾被要求實現複雜的存取控制類型，我寫過一套應用程式來記錄營業工作檢討，其存取控制的規則是，經理級人員能夠看到他們所在層級以下的所有資料，不只包括他們管轄的作業，也包括該管理層級以下的所有資料。他們能夠看到比自己層級低的，但不能看層級高的。

使用者管理

類似像Facebook這樣的應用程式主要是有由使用者作自我管理的，使用者們決定他們自己的帳號名稱與密碼。線上銀行以及線上購物應用程式也是一樣，不過在申請線上存取與核准線上存取之間，銀行可能會做一些延遲。不過對於組織內部的應用程式而言就不是這樣了，通常來說，當人們更換工作時，他們應該要被授權來使用他們即將要使用的新應用程式，而且（這部分比較難）必須把他們舊工作用到的應用程式之存取權限撤銷。有個大問題是，很少有組織具有適當的流程來精確且一致地執行這個工作。常見的原因是每套應用程式都有不同的人或團隊來負責做安全性的管理。

使用者管理有可能會是個安全漏洞的來源。與其說是系統管理者帶有不懷好意的心態來指定使用權限並造成明顯的漏洞，根本的原因通常是懶惰、太傻、或是太天真地相信他們的同事。我曾經寫過一套幾乎在各方面都很安全的程式，但是我讓系統管理者替一位新使用者設定初始帳號與密碼，這個系統管理者設計了一套簡單的策略將姓名與初始設定值轉成帳號與密碼。很不幸地，如果你透過這位系統管理者得到帳號名稱與密碼，你就能很容易地猜出規則來產生其他每個人的帳號名稱與密碼。使用者雖然可以透過更改密碼來保護他們自己，但有多少人改了他們的密碼呢？一個也沒有。當時我真該做的事就是讓新使用者密碼透過隨機的方式來產生，這樣可以讓該應用程式更加安全。安全性的解決辦法通常很簡單，只是你必須知道問題是什麼。

安全防護

以下是機密洩漏的可能方式（無疑的這只是其中一部份）：

●  盜取或猜測密碼。

●  在使用者不知情的狀況下使用已經認證成功的管道。這個想法本質上就是去盜取並再次利用會期資料。有許多防範的方法來對抗，一種是讓伺服器定期地提供新的會期識別給客戶端程式。關閉已經完成的會期也是很重要的。不幸的是，除非使用者進行登出，否則在Web上很難偵測會期在何時結束。唯一的解決辦法是利用逾時倒數，這就是為何你在一短暫時間沒繼續使用線上銀行應用程式之後它會逾時，而你必須再登入一次。

    相對危險的是在你PC上運行的程式能夠在背後偷偷的利用你的會期資料來進行活動。

●  訊息攔截。假設你是透過開放的無線網路來存取一套應用程式，就像在網路咖啡店裡一樣。其他人有可能把他們的PC設置成無線的集線器，然後監視流經這個集線器的所有資料。在網際網路上對抗這種問題的做法通常是利用TLS或SSL加密。

●  應用程式意外地提供了一項沒有做存取控制檢查的命令。這是一種程式設計疏失，不過同樣的，如果你知道有這個問題，那是很容易修復的。

●  從伺服器做檔案資料傳輸。伺服器也許設置成支援可以將檔案複製過去，或從那裡複製出來（通常是透過FTP──檔案傳輸協議），因此這個操作可以載入應用程式檔案以及複製任何錯誤的日誌檔。這種檔案傳輸的密碼必須是安全的。

●  在伺服器上讀寫資料檔案或資料庫。IT作業部門最可能需要做這件事，即使只是將軟體更新成最新版本。他們必須確保做這些作業時是被安全地進行。你可將重要資料加密，因此如果伺服器洩漏了資料，這些資料仍舊是安全的。

●  將程式安裝並執行於伺服器上。同樣的，這是IT作業部門所需要的他們必須以安全的方式來進行。

●  讀取備份資料。資料庫中的資料在用來備份的資料庫中也存有一份複本。解決辦法是將資料加密。

這些項目當中，有一些是IT應用程式設計者的責任，有些是程式設計師的，但很多都是IT作業部門與系統管理人員的責任。（摘錄自第12章）

 

 書籍資料 

寫給PM、RD與設計師看的設計需求分析作者簡介

Chris Britton／著

松崗出版

售價：580元

 作者簡介 

Chris Britton

曾經在許多IT業務相關領域任職過。他從1970年代就開始在IT領域裡從事COBOL及Algol的程式設計，並在1976 年加入了Burroughs（後來與Sperry合併成Unisys），之後很快地成為大型主機系統的資料庫專家。