[從電影看資安] 眼睛是靈魂之窗 - 天使與魔鬼

天使與魔鬼 講的由湯姆漢克所演出的蘭登教授，為了追蹤一宗疑似古老魔鬼教派「光明會」報復的冒險故事。故事裡反派分子用來報復的工具是一種稱之為反物質的東西，是現代科學實驗下的產品。這個實驗室就是大名鼎鼎的 CERN，網站的出現可是要拜 CERN 所賜。想當然爾，這麼重要的東西絕對是應該好好加以保護的。在實驗室最核心的部分，採用了生物辨識技術。反派分子為了順利取得所需的反物質，只好犧牲研究計劃的主持人，就是為了取得他身上的生物特徵。

這就是計畫主持人，請注意他那憂鬱的雙眼。 

實驗室的核心區域使用生物辨識技術管制人員進出。

掃描眼睛以便進行判別。

見鬼了嗎？

反派分子為了取得反物質，挖了計劃主持人的眼睛，以便進入核心區域。

以眼睛為主的生物辨識技術，主要有虹膜 (Iris) 與視網膜 (Retina) 兩種，其中虹膜的技術使用較為廣泛。跟其他的生物特徵技術相比，虹膜與視網膜的技術都必須在近距離內才能夠作用，不像人臉辨識技術從比較遙遠的距離就可以進行。但是這些技術又不像使用指紋或掌紋一般需要實際接觸掃描設備，所以可以避免一些接觸所產生的問題。儘管如此，畢竟眼睛是比較敏感的器官，所以一般人要接受這樣的驗證方式還是會有比較大的心理障礙。尤其是虹膜技術必須將光束打到眼睛進行一段時間的掃描，因此在推廣上必須克服使用者的心理抗拒。

視網膜 (Retian) 在眼球的後方，而虹膜  (Iris) 在前方。

虹膜技術與視網膜技術相較之下，雖然視網膜幾乎不會產生重複的情形，但是因為要進行有效的判別比較不容易，所以虹膜技術反而擁有較佳的 Crossover Error Rate (CER)。此外虹膜也不像視網膜般容易因為生病而受到改變，但是虹膜卻會因為年紀的變化而有所改變，儘管這樣的變化可能要經過數十年才會產生影響。視網膜技術檢測的是眼睛後方視網膜的血壓，因此將眼睛取下後會很難通過驗證，算是視網膜技術不同於其他生物辨識技術的一個特色。

最後問各位一個問題，天使與魔鬼 的影片中，CERN 實驗室使用的是虹膜技術還是視網膜技術？

[從電影看資安] 印表機大變身 - 口是心非

在上一篇的 文章 中，我談到有關社交工程的議題。在這篇文章中，我要大家分享的內容同樣來自於 口是心非 這部電影。

在片中男主角的陣營想盡辦法想要偷取敵方陣營的機密資料，當然網際網路也是不可放棄的一個管道。不過根據劇中角色的描述，敵方陣營的網路防禦能力跟美國國防部的五角大廈一樣嚴密，所以無法成功入侵。好在男主角陣營這邊發現了另外一個可行的管道，那就是敵方陣營新採購的影印機。透過在影印機內安裝惡意程式的手法，後來男主角的陣營成功入侵敵方陣營的其他設備，並於日後順利傳出機密資料。

主角陣營稱讚敵方的網路防禦機制。

像五角大廈是一種恭維還是諷刺？

天無絕人之路，影印機也可以成為入侵的管道。

有錢好辦事，買通設備廠商進行改造的工作。

影印機用來攔截訊號流量雖然是不允許的，但是卻很有創意。

影印機也可以當作跳板，尋找其他的受害設備。

女主角利用被駭的影印機成功將機密資料傳遞出去。

這裡有兩個地方可以跟各位分享，第一個就是木馬的觀念。現在談到木馬，很多人都會聯想到所謂的木馬程式。事實上，木馬一詞來自於希臘神話的特洛伊木馬，所以指的不單是程式這類虛擬的事物。躲在特洛伊木馬內的士兵，伺機而動，等待最佳的時機從內破壞敵方的堡壘。而躲在影印機內的惡意程式，同樣伺機而動，準備入侵其他網路上的設備。在這個例子中，木馬指的影印機本身，而不是那個惡意程式。通常要避免遭受木馬的攻擊，就是盡量避免接收來路不行的東西 (不管是硬體還是軟體)。但是以片中的例子而言，我們就需要探討下一個主題，也就是影印機的管理。

事實上，現在很多所謂的印表機、影印機，都已經整合成多功能事務機。雖然功能更加齊全與複雜，但是同時也為組織帶來更多未知的危害。舉例來說，多功能事務機通常具備更優良的快取功能，而這些快取資料包含各式各樣的資料，甚至是公司的機密資料。當機器送修時，這些快取內的資料往往也就隨著機器一起移至維護廠商，其所造成的危害我想就不需要再多作說明了。不管是叫做印表機、影印機或是多功能事務機，這些設備早已經不再只是 IT (甚至是總務) 的負責範圍，更應該明確的納入資訊安全的管理範圍。至於這些機器要怎麼管？這裡有張 清單 可供參考。

相關連結：

• Multifunction Device Hardening Checklist
• Surprising Security Threat: Take Steps Now to Safeguard Print Devices and Printed Data
• How To Ensure Multifunction Printer Security and Compliance
• Locking Down the Multifunction Printer

[從電影看資安] 天上掉下來的帥哥 - 口是心非

電影 口是心非 講的是商業間諜的故事，雖然評價有點兩極，但是有別於一般電影結局時主角們總是能夠來個奇蹟式的逆轉勝，口是心非的結局顯得有趣多了。雖然商業間諜的目標不一定是數位形式的資訊，但是以現今的商業環境而言，很多重要資訊都已經變成了數位的形式。由此衍生一個很重要的問題，資訊安全的範圍在哪裡？如果將數位資訊與傳統 (非數位) 資訊分開看待，那麼兩邊能否達到相同程度的保護是必須詳加確認的。另外一方面，如果將兩者一併看待，那麼負責單位的權責又該如何重新界定？這些問題沒有一定的標準答案，但是每個組織卻都必須找到一個最適合自己的平衡點。

此一議題我先在此打住，我今天要分享的是另外一個資訊安全的議題 - 社交工程。電影中有一幕是男主角這邊發現敵方陣營有一個獨立的辦公室，這個辦公室主要負責處理公司的出差及與旅遊事宜，其安全措施自然與總公司不可相提並論。但是對作戰而言，任何資訊都是不可放過的，所以男主角這邊決定前往竊取一些相關資料。男主角在電影中利用社交工程的手法，假裝在一個酒吧裡與該辦公室的女職員不期而遇。男主角表示自己因為來不及趕上飛機前往參加救助行動而煩惱不已，此時女職員自告奮勇提供協助，將男主角帶進辦公室前往處理班機的事宜。當然這一舉動，讓男主角取得了大門的密碼，之後順利取得所需的資料。

男主角與女職員不期而遇，而且”剛好”是鄰居。背景調查當然不可少。

男主角不自主地透露出需要協助的困境。 

女職員帶著男主角前往辦公室，女職員還有些基本概念，要求男主角不要偷看她的密碼。不過講歸講，男主角不但用眼睛看，還用手機拍了下來。 

女職員的”善行”被發現後，即使已經知道這是一場騙局，女職員依舊深覺能夠幫助別人並獲得男主角的感激是很美好的一件事。

這是一個很典型的社交工程手法，通常社交工程可以分成四個步驟：

1. 研究目標組織，也就是片中的敵對公司。在片中男主角的陣營了解到這個獨立辦公室的存在與價值。
2. 選定目標，也就是片中的女職員。
3. 發展關係。以片中的情形而言，就是無助的帥哥醫生與寂寞芳心的女職員。
4. 利用關係達到目的。以片中情形而言就是進入辦公室並取得門鎖的密碼。

雖然第四個步驟才是主要的目的，但是前三個步驟可是一點都不能馬虎。唯有確實做好前三個步驟，才能確保第四個步驟一舉成功。通常在第三個步驟會有各種不同的可能性，包含假冒高階主管、協力廠商、無助的路人、凶狠的惡徒、迷人的異性等等，利用這些假冒的身分並搭配上人性的弱點，以求順利達成目的。

社交工程是一個很有效，也很難防範的攻擊手法。或許聽起來不如 XSS、Zero Day Attack 這些名詞這麼炫、這麼讓人覺得高深，但是其所造成的危害卻是令人不可小覷。要避免遭受社交工程手法的攻擊，除了一般性的防範措施外，最重要的就是有效的員工資訊安全教育訓練，提高所有員工對於異常事件的警戒心，以避免成為有心分子手中的待宰羔羊。此外，就像詐騙集團會不斷改變手法一樣，社交工程也沒有固定的形式，所以持續性的教育訓練更形重要。下次當你遇到天上掉下來的帥哥/美女時，你不需要拒他於千里之外，但是也千萬別失去理智，做出了平常不該做的事情。

[個人意見] Facebook 該怎麼管？

延續前一篇的話題，既然 Facebook 不是一個要不要的選擇題，而是要如何面對與管理，那麼有甚麼好的建議嗎？ IDC 於今年中發表了一份 white paper ，主題是如何有效的強化使用 Web 2.0 網站 (如 Facebook) 時的安全性。裡面提到十大需要考量的重點：

1. Dynamic Web 2.0 defenses
2. Real-time content classification
3. Employee access
4. Data loss prevention
5. Application control
6. Remote access
7. Unified policy management
8. Comprehensive reporting and logging
9. Performance and scalability
10. The server side of Web 2.0

而資安廠商 McAfee 則提出了七個需求事項：

1. Deploy real-time reputation-based URL and message filtering for all domains-even those not yet categorized
2. deploy anti-malware protection utilizing real-time, local “intent-based” analysis of code to protect against unknown threats, as well as structure-based, anti-malware protection for known threats
3. implement bi-directional filtering and application control at the gateway for all web traffic, including web protocols from HTTP to IM and encrypted traffic
4. Data leakage protection on all key and web messaging protocols
5. Ensure that all caches and proxies are “security-aware” for safety and efficiency gains
6. Design security infrastructure for layering of defenses with minimal number of secure devices
7. Use comprehensive access, management, and reporting tools

在此我不會針對每一點加以說明，有興趣的讀者可以參考相關連結。我要特別提出的是管理 Web 2.0 不是單向的任務，而是雙向的任務。從外到內可能衍生的問題主要為惡意程式的引入與對於員工工作效率的負面影響，由內到外的問題主要則為機密資料外洩。此外，由於多數 Web 2.0 網站透過外掛程式或 mashup 來提供更豐富的功能，所以除了管理主要的網站服務外，這些外掛程式與 mashup 的管理也是必要的項目之一。以 Facebook 的偷菜遊戲而言，如果能夠阻擋偷菜遊戲而非整個 Facebook 就可以提供更細緻的管理能力。而由於隱匿技術的廣泛應用 (通道技術、匿名式存取服務，甚至是加密技術)，是否能夠有效地管理這些隱形的行為又是另外一個考量的重點。而因為現在很多攻擊手法都是在合法的網站中植入惡意的程式或連結，或者是大量產生新的網址，所以傳統上利用網址判斷惡意與否已經不符使用，而必須更即時的檢查網路傳遞的內容，並決定是否將會產生危害。簡而言之，管理 Web 2.0 的安全性，必須全面檢測網路傳遞的資料才有可能達成，所謂的全面包含流量的方向、使用的協定、加密與否、使用的設備(PC、NB、手機)、使用的媒介(有線網路、無線網路、電信網路)等等。

說到底，這些都還是技術性的解決方案。相較於技術性的解決方案，管理性的解決方案卻更形重要，但是卻也容易受到忽視。管理性的解決方案至少包含政策的制定以及使用者的教育訓練，如果這兩件事情沒有確實進行，有再好的技術性解決方案終究只能治標，甚至因為造成反彈與誤解而產生了反效果。屆時可真的是賠了夫人又折兵。

 

相關連結：

• Best Practices for Securing Web 2.0
• Seven Design Requirements for Web 2.0 Threat Prevention
• Adding Application Control to Your Security Toolbox

[個人意見] Facebook 是萬惡的罪魁 ?

Facebook 偷菜引發的爭議至今餘波盪漾，今天最新的相關新聞是台北市的學校也開始禁止使用 Facebook ，因而造成部分教師的反彈。新聞標題下的是”學校禁facebook 被罵管太多”，對此我個人相當不以為然。公私部門想要管理 Facebook ，甚至是所有網路使用行為，並不是管太多，甚至是絕對必要的作為。但是片面性的全面禁止，顯示出的是主管單位對於問題的不瞭解，或者該說是不關心。

Facebook^註 對於工作(效率)的影響是好是壞，至今仍有相當的爭議。甚至一些提出數據的研究報告，正反兩方的意見都有。其實這倒也沒甚麼好奇怪的，就是因為有爭議，才會有這麼多不同的研究報告，不是嗎？我在此不想討論 Facebook 究竟是好是壞這種永遠沒有正確答案的議題。我只能說人不是可以線性預測的”工具”，而且現在大部分的工作也不是線性的工作。工作時間長短跟產出的質與量不是正比的關係，而且短期的工作效率跟長期的工作效率也不全然是正比的關係。更重要的是每個人都不同，每個團隊的文化也不同，所以 Facebook 所產生的影響也會不同。

以積極面來說，如何利用 Facebook 幫助業務的進行，是主管單位必須加以好好思考的。而在消極的那面，則包含如何處理 Facebook 所引起的問題(如時間與資源的”過度”浪費、機密資料的外洩等)。 對絕大多數的企業而言，Facebook 不是一個要或不要的選擇題，而是要如何面對的申論題。此外，員工上班時間效率不彰，更不會是因為 Facebook 單一因素所造成，員工對於工作的投入程度不高或許才是主因。如果倒因為果，不但徒勞無功，甚至可能造成反效果。今天禁了 Facebook ，明天還有 Plurk (我個人認為經營 Plurk 所需花費的時間不會少於 Facebook )。就算能禁的都禁了，最終也無法禁止員工神遊。就像有人說過，你可以關住我的身體，但是關不住我的思想。如果把工作搞的像坐牢，限制再多也是無法提升工作效率。反之，如果公司能夠提供員工積極工作的動機，員工自然不會過度分心於工作之外的事物。更何況適當的休閒(包含工作中)，對於所有的工作者都是有其正面的意義。

說了這麼些看似不著邊際的話，只是期望各公私部門的主管單位能夠先改變 Facebook 就是萬惡罪魁的偏見。唯有如此，才有辦法真正面對問題，解決問題。

註：Facebook 在此可以看做是所有 Web 2.0 相關網站的代名詞，甚至可以看做所有傳統上非工作相關的資訊系統。

相關連結：

• 說私密、搞創意 社群網站更開心
• 學校禁facebook 被罵管太多
• How to Address Facebook in the Workplace
• Is Facebook good for the workplace?
• Facebook, YouTube at Work Make Better Employees: Study
• Facebook cuts workplace productivity – survey
• Pulling the Plug on Facebook

[個人意見] 從 MP3 播放器到 T-X 機器人

幾個月前我的 T 牌 MP3 撥放器壞了，因為還在保固期內，所以就送回原廠維修。維修完後去拿取的當下，我因為一時無聊，就問了客服人員故障的原因，他回答我說應該是"中毒"了！我聽了之後，還開玩笑的問他 MP3 播放器也會中毒喔？他給了肯定的答覆，還說有些歌曲會造成中毒的現象，不過很好處理，只要重置就可以恢復正常了。與其說是中毒，我倒更認為是因為設計不夠完善，所以造成在播放特定的歌曲時產生了機器的異常。當然，這是我自己心裡的想法，並沒有說出口。

不管說法是甚麼，MP3 播放器會因為撥放特定歌曲而失效是事實，這在以前的世界中是很難想像的。在數位化的世界裡，每種電子設備跟電腦一樣包含了硬體、韌體、軟體等元素，所以電腦會產生的問題，在這些設備身上也有可能發生。好在 MP3 播放器並不是什麼重要的設備，除非你是一天沒有音樂就會活不下去的人，不然對生活不會有任何負面的影響，頂多就是花錢再買一台就好了。更重要的是，失效的 MP3 播放器並不會攻擊你，所以就算你不想處理也沒關係。但是如果今天發生問題的是居家照顧的電子設備(如清潔或保全用的機器人)、甚至是看護病人用的電子設備，這就是人命關天的議題。尤其是功能越多的設備，如果再加上具備遠端連線的能力(透過無線網路、藍芽、紅外線等)，甚至有可能成為有心分子為惡的工具，成為最難防範的內應。從被動的監視/監聽，到主動的攻擊，都是有可能發生的情況。

這是杞人憂天嗎？機器人會不會產生智慧並進行對人類的反撲 (就像魔鬼終結者的劇情，T-X 即為第三集中出現的美女機器人)，我目前不得而知，但是人類會有危害他人的行為卻是由來已久。只要有利可圖，對有心分子而言沒有甚麼是不能做的，唯一的先決條件就是這樣的電子設備是否已經具備龐大的市場規模並可以衍生出相關的非法利益。很可惜的是，安全性通常不會是這類設備在設計之初的主要考量之一，所以只要時機成熟，問題一定會發生。身為資訊安全的從業份子也別太過灰心，甚至應該樂觀以對，畢竟這樣資訊安全的任務才更有挑戰性，不是嗎？當然，如果能夠讓廠商在設計之初，就把安全性的考量放進產品需求中，便可以大幅減少從錯誤中學習的痛苦。台灣以製造/設計電子設備能力見長，如果日後能夠強化產品的安全性，我相信在特定產品上會有更搶眼的表現。

[工具介紹] 上班不能偷菜很悶嗎？教你如何偷偷偷菜。

最近 Facebook 火紅的程度，不但在網路界引起關注，連一般使用者與政府官員都不得不加以談論一番。其中最主要的助力來自於一款叫做開心農場的遊戲。嚴格說來，開心農場只是眾多農場遊戲中的一支，而且既不是原創也不是最好玩的一支。或許是因為中文化的關係，所以在台灣成了最受歡迎的 Facebook 遊戲之一。不過也因為不少人玩得過火，再加上”偷菜”這種不道德的行為，所以引發了公私部門的反彈。因此有人因為”偷菜”而寫悔過書，更有人因為”偷菜”而偷了飯碗。不論上層的理由為何，限制上班時偷閒並種種菜，對許多基層員工來說可是天大的罪惡，今天我要介紹一個很簡單的辦法，可以突破一般的限制方法。

首先我們看在一般的情況下，我們連到 Facebook 開心農場時，瀏覽器會使用 http://apps.facebook.com/farmgame_tw/ 這個網址，這也是一般工具用來加以判斷或限制的依據。我們只要讓這個網址加以隱藏，就可以讓很多阻擋工具失效。使用的方法很簡單，只要透過一種叫做 Anonymous Proxy 的工具就可以隱藏你真正要進行連結的網址。

一般情形下連結開心農場所使用的網址

使用步驟如下：

1. 因為使用這類網站服務時，所有的資料都會流經該網站。因此強烈建議使用這類服務前先把密碼改掉，以免密碼被記錄下來並被濫用。
2. 連上 http://www.hidemyass.com/ (名稱不太好聽) ，在輸入框中打入 http://www.facebook.com/ 後點選 “Hide My Ass!” 的圖示。
3. 之後會出現廣告與 Facebook 的登入畫面。這類服務都會有廣告的出現，不過不會影響操作。打入帳號/密碼登入 Facebook。
4. 開啟開心農場，此時我們可以看到瀏覽器的網址是一堆亂碼，看不到任何有關 farmgame_tw 的字樣，甚至連 www.facebook.com 都沒有。
5. 除了 www.hidemyass.com 外，網路上還有很多這類匿名瀏覽的服務，只要利用 Google 查詢 “free anonymous proxy server” 就可以找到一堆。這類服務的介面大多大同小異，不過有些可能在連結某些網站時會有錯誤的情況，有些則提供微調的功能 (如關閉 JavaScript)。對於想要使用開心農場而言，並不需要這些微調的功能，只要能夠正常連線即可。

如果你對網路有些概念，可能會想到大多數匿名瀏覽服務遇到內嵌於網頁的應用程式時(像是ActiveX、Applet 或是 Flash)往往會失去匿名性。至於開心農場會不會遇到這個問題，我在此賣個關子，因為我本來就不適合也不想鼓吹這樣的行為。所以如果你這樣做之後可以使用開心農場，那就恭喜你。如果不行，不要問我該怎麼辦，我會直接請你找公司的資訊人員。

介紹這個工具當然不是鼓勵大家工作時摸魚打混，反而我是希望公私部門的高層們都能夠好好地面對這類問題才寫這篇文章。我所謂的面對問題也不是再導入其他非判斷網址的工具，因為這種官兵抓強盜的遊戲，永遠也玩不完。工作時”濫用”開心農場只是很多問題的呈現，不解決真正的問題而只想防堵，不但達不到效果更有可能讓問題加劇。撇開管理的角度，改以資訊安全的角度來看，除了防堵外，使用者的教育與明確的規範更形重要。否則，生命總會找到自己的出路。

[個人意見] 別再霧裡看雲端，越看眼越花

雲端運算 (Cloud Computing) 一詞延續之前的熱度，持續成為資訊業界一個大家朗朗上口的名詞。而且這樣的知名度，更因為一些新聞的報導，連非資訊人員也開始”了解”雲端運算強大的威力 (潛力)。

雲端運算於資訊安全的議題主要有兩個面向，一個是使用雲端運算所應該注意的安全議題 (請參考我的另外一篇文章 - 你準備好降落傘了嗎？ - 談雲端運算的安全議題)，另外一個議題則是如何利用雲端運算提供更好的安全性產品/服務。最先”炒”熱後者這個話題應屬趨勢科技這家公司，而現在包含賽門鐵克在內的眾多公司也都不斷強調在產品/服務之中導入雲端運算，而且一定還要同時提到是好多年前就已經開始著手進行。

儘管雲端運算一詞出現至今已經過了許多年，而且也有些大眾化，但是許多人對於何謂雲端運算似乎仍是認知有限，甚至可能有所誤解。網路上已經有一些不錯的說明文章，所以我在此就拾人牙慧，不多贅述，僅摘要一些重點項目以及我個人的補充。

• 雲端運算指的不是一種技術，更不是一種特定的商品，而是一項概念。
• 雲端運算可以算是分散式運算、網格運算的延伸，實際雲端運算的實現可能運用了這些不同型式的架構。如果真要區分，可以說雲端運算是利用 TCP/IP、SOAP(HTTP)、REST等各式各樣公開標準所形成的分散式運算架構。
• 舉例來說，SETI@home 剛開始大家都說是網格運算，但是現在又歸類成雲端運算，顯見之間的分隔其實並不是那麼明確。或者該說是這些定義是因時、因地、因人而會有所不同。因為 SETI@home 是架構在 TCP/IP 等公開標準上，所以現在被歸類為雲端運算也是再自然不過。
• 知名分析公司Gartner的分類方式，將「雲端運算」區分為兩大類，分別為「雲端服務」(Cloud Computing Services)與「雲端科技」(Cloud Computing Technologies)。「雲端服務」專注在於藉由網路連線從遠端取得服務，而「雲端科技」則是著眼於利用虛擬化以及自動化等技術來創造和普及電腦中的各種運算資源。
• 承上可知虛擬化是雲端運算的一種實現方式，但是並不是所有雲端運算都必須使用虛擬化的技術，同時也並非所有的虛擬化都可稱之為雲端運算。
• 雲端運算目前大概可以區分為三種商品模式，亦及 IaaS (Infrastructure as a Service)、PaaS (Platform as a Service) 與 Software as a Service (SaaS)。 在雲端運算的三種商品模式中，SaaS 是最為人所熟知的一種，也可能是目前擁有最多實例的模式。
• IaaS、PaaS 與 SaaS 可以說是雲端運算由下而上的三個層次 (layer)，每個層次目前都有相對應的產品/服務。 舉例來說，IaaS 有 Amazon Web Service，PaaS 有 Google App Engine，而 GMail 則屬於 SaaS。
• SaaS 其實可以說跟 Application Service Providers (ASP) 是同一個東西，甚至在網路泡沫化前不少人只聽過 ASP 這個名詞。只是在網路泡沫化後幾乎全部的 ASP 廠商都出局了，所以後來大家當然就不太想 (敢)繼續用 ASP 這個名詞。
• 成功度過網路泡沫化而且採用 SaaS/ASP 概念中的產品最為人所熟知的當屬 salesforce.com，而且可以說是第一個掛上雲端運算且獲得成功的商業化產品，也因此有不少人誤以為雲端運算就是指 SaaS。
• SaaS 不但僅是雲端運算的模式之一，甚至在底層的技術上也不一定會使用到像是虛擬化這類雲端技術。這樣模糊的定義讓廠商在行銷上有更多可以操作的空間，也造成一般大眾對於何謂雲端運算更加難以理解。
• SaaS 在資安業界還有另外一個意義，叫做 Security as a Service。基本上我個人認為是為了搭上順風車而產生的新名詞，並沒有甚麼特殊之處。當然，如果原本是賣軟體的廠商，勉強也可以算是 Software as a Service。但是如果原本就是做服務的廠商，這樣的 SaaS 跟原本雲端運算的 SaaS 的關係真的是很牽強。
• 就像所有的事物都有正反兩面，雲端運算也是優缺點並存，而實際的優缺點會跟使用的模式 (SaaS、PaaS 或 IaaS) 有所關聯。
• 除了技術上的優缺點，雲端運算在法律、政治、甚至於自由的議題上也有其爭議之處。但我個人認為所有的爭議最後終究會屈服在商業利益之下，也就是說有沒有商業利益才是其能否成功(或者說能夠獲得多大的成功)的唯一因素。
• 換另外一個角度來看，某項產品或服務到底是不是歸類為雲端運算，對大多數人來說根本也不重要。因為對大多數使用者而言，要的只是結果，至於叫什麼名字，讓廠商去傷腦筋就好了。

有一句話，我個人相當認同，也用這句話來當作這篇文章的結束。

Cloud computing 並不代表任何單一技術的突破或是革新，它代表的是分散式運算本身的一種成熟，就好像我們看到網路發展到一定程度了，就有人喊出了 Web 2.0，都是一樣的道理。

 

相關連結：

• 淺談雲端運算 (Cloud Computing) (國立台灣大學計算機及資訊網路中心電子報)
• Cloud Computing 雲端運算 (Mr./Ms. Days)
• Navigating the Layers of the Cloud Computing Pyramid
• Cloud Computing (英文 Wiki)
• 雲端運算 (中文 Wiki)

[工具介紹] Java程式檢測工具(三) – DoctorJ & JCSC

前面我們介紹過 PMD 與 FindBugs 這兩個用來檢視 Java 程式碼 (Source Code 或是 ByteCode) 是否有問題產生的工具，這次我要介紹的兩個工具則是著重在檢測註解本身 (JavaDoc) 是否符合要求。為什麼會有這樣的需求？或許長久以來對於程式註解要包含哪些東西以及要如何撰寫沒有統一的共識，但是對於良好註解的重要性我想幾乎沒有人會加以反駁。良好的註解至少包含兩個重點，一致的格式與清楚且有意義的內容。清楚且有意義的內容有些抽象，但是一致的格式卻是可以明確的加以定義，所以我們訂定的寫作規範通常也會包含註解的格式。只是規定訂定下去以後，是否所有開發人員都會確實遵守又是另外一回事。在Code Review的時候一併檢驗？Code Review應該是用來找尋必須人工檢驗的問題，對於符合格式這種可以自動化的工作，用人工來做可是吃力不討好。透過使用 DoctorJ 或 JCSC，我們可以把格式確認的工作交由程式自動化執行，除了快速方便外，更可以避免開發人員因為抱持心存僥倖的心態而沒有撰寫合乎規範的註解。

DoctorJ 與 JCSC 在使用上都相當簡單，主要是透過命令列的形式。JCSC 另外提供了一個 GUI 的工具可供修改檢測的規則，而 DoctorJ 則沒有辦法修改檢測規則。但是 DoctorJ 可以一次檢測目錄下所有的程式檔，而 JCSC 則一次僅能檢測一個程式檔。嚴格說來，這兩個工具在使用的方便性都嫌不足，而且兩個工具也已經沒有再更新，不過這似乎是使用社群開發軟體常會遇到的問題。也因此要不要使用這些軟體，只能自己先好好做個評估了。

DoctorJ

1. 下載軟體。
2. 解開下載的軟體。
3. 打開 Microsoft Windows 的命令列模式。
4. 在解開的目錄下，執行 ant install 指令進行安裝的動作。沒有安裝 ant 的系統需先進行 ant 的安裝。
5. 雖然最後出現錯誤訊息，但是那僅是要將 jar 檔案複製時使用了 *nix 的路徑表示法，所以造成在 Microsoft Windows 無法執行。我們直接找到產生的 jar 檔案就可以了，該檔案為 share\doctorj\doctorj.jar。
6. 使用 doctorj 很簡單，只要透過 java –jar doctorj.jar filename|path 就可以進行檢測。 不過因為 doctorj 會將結果顯示於畫面上，所以我們可以透過轉向機制將結果儲存於檔案中。
   
   檢測單一的檔案
   檢測整個目錄
7. 使用文字編輯器打開儲存檢測結果的檔案。

JCSC

1. 下載軟體。
2. 解開下載的軟體。
3. 打開 Microsoft Windows 的命令列模式。
4. 在解開的目錄下，執行 bin\ruleseditor.bat。此工具可用來修改檢測的規則，其中針對註解的檢測規則在 JavaDoc 頁籤下。如果不需要修改直接選擇 “Close” 按鈕，修改資料後請記得選擇 “Save” 按鈕。
5. 使用 JCSC 非常簡單，只要透過指令 jcsc filename 即可。同樣的，JCSC 會將檢測結果直接輸出在畫面上，所以我們再次利用轉向的機制。
6. 使用文字編輯器打開儲存檢測結果的檔案。因為使用了 *nix 的換行符號，所以用記事本查看將會無法正常閱讀。我們看到檢測結果除了一般的違規事件說明外，也包含一些指標 (Metrics)。只可惜一次僅能針對一個檔案，需要透過額外的步驟才能得到整個專案的指標。
7. 雖然 JCSC 也能檢測其他的項目，但是因為其使用方便性遠不如 PMD 與 FindBugs，所以我就不加以說明了。

結語

雖然 DoctorJ 與 JCSC 在功能與使用方便性上都有不足之處，不過善加利用這些工具 (或其他類似的工具)可以讓我們強制執行 Java 程式註解的撰寫，以減少後續維護上的一些困擾。如果使用者可以透過自行撰寫的 script 或 ant task 提高這些檢測工作自動化的程度，對於程式的品質管理絕對會有相當的助益。

[工具介紹] Java程式檢測工具 (二) - FindBugs

前言

FindBugs 同樣是用來檢測 Java 程式的工具，其檢測的對象是 Byte Code (class 或是 jar 檔)。儘管如此，FindBugs 依舊是屬於靜態分析的方式。FindBugs 如其名，主要是利用 Bug Patterns 的概念，找尋出程式中有問題 (Bugs) 的程式碼 。在其官方的網站中提到 Bug Patterns 的產生可能有下列因素：

• 程式語言本身不容易使用的功能 (Difficult language features)
• 被誤用的 API (Misunderstood API methods)
• 當程式碼在維護時，不變的條件被誤解了 (Misunderstood invariants when code is modified during maintenance)
• 其他常見的錯誤，例如打錯字、或是使用了錯誤的布林運算元 (Garden varieity mistakes: typos, use of the wrong boolean operator)

FindBugs 本身提供完整的 GUI 介面，讓使用者可以很方便地進行檢測的工作。因為 FindBugs 主要使用 Java 進行開發，所以可以運行於各種的作業系統上。雖然 FindBugs 是針對 ByteCode 進行掃描，但是在 GUI 中我們可以指定原始程式碼所在的目錄。如此一來， FindBugs 就會自動將發現問題的 ByteCode 與原始程式碼自動連結並加以顯示。

點選 Bug 後可以自動顯示出 Bug 所在的程式碼

除了 GUI 的操作方式外，FindBugs 也支援 Ant 的開發環境。而在與 IDE 整合方面，則僅提供 Eclipse 的 Plug-in。也因為 FindBugs 支援 Eclipse 的 Plug-in，接下來我會直接使用 Eclipse 的 Plug-in 作為範例說明。不過在此之前，我先提醒一下在使用 GUI 時有兩個需要特別注意的地方。第一個是如果在進行分析時進度忽然停滯不動，有可能是因為記憶體使用量已經超過限制，此時需要增加 JVM 記憶體的使用量 (-Xmx)。另外一個就是在 Microsoft Windows 下我一直沒有辦法正確的連結到原始程式碼。

安裝 Eclipse 的 Plug-in

1. 選取功能選單的 Help –> Install New Software。
2. 點選 “Add…” 按鈕，輸入下列資料後按下按鈕 “OK”。
3. 在 Work with 的下拉選單中選取 FindBugs – http://findbugs.cs.umd.edu/eclipse  ，點選後需要等待一段時間。
4. 點選 FindBugs 後按下按鈕 “Next >”，點選後需要等待一段時間。
5. 選取 FindBugs Feature 後按下按鈕 “Next >”。
6. 選取 I accept the terms of the license agreement 後按下按鈕 “Finish”。
7. 等待安裝畫面執行完畢。
8. 安裝完畢後按下 “Yes” 按鈕重開 Eclipse 以使 FindBugs Plug-in 生效。

使用 FindBugs 檢測 Struts 程式碼

1. 在程式碼 (或專案) 的目錄下使用滑鼠右鍵叫出功能選單，選取 Find Bugs –> Find Bugs。
2. 等候 Find Bugs 檢測完畢。
3. 檢測完畢後會跳出一個視窗詢問是否切換至 FindBugs 的 perspective，先選 Yes。
4. 在FindBugs perspective的左上角出現 Bug Explorer，將發現的問題依據不同的原因加以分類，可以很快的了解有哪些問題需要進一步處理。
5. 但是 FindBugs perspective 在操作上有些不順暢的地方，右邊的 view 也有被切掉的情形，因此我們切換回 Java perspective。
   
   利用右上方的按鈕切換回Java perspective
    
6. FindBugs 的檢測結果顯示於 Problems view。 
7. 在發現的 Bug 上點選右鍵叫出功能選單，選取 Properties 以顯示問題的詳細資訊。
8. Message 欄位顯示問題的描述。 
9. Category 欄位顯示 Bug 的分類 
10. 上述的資訊雖然很完整，但是卻過於分散不容易閱讀。我們可以利用在警告圖示點選右鍵的功能選單上，選取 Show Bug Details 以顯示 Bug 相關資訊。 
11. 雖然顯示的資訊較少，但是可以一眼看到 Bug 的類別與說明，方便了解問題與後續處理方式之判斷。 

設定 FindBugs 的檢測項目

我們可以利用專案的 Properites 設定畫面，進行 FindBugs 的相關設定。主要設定項目包含是否自動執行 FindBugs 檢測項目 (Run automatically)以及檢測項目的相關設定。雖然自動執行 FindBugs 檢測項目相當方便，但是因為 FindBugs 檢測需要一段不算短的時間，所以勾選時請加以三思。如果有必要，請記得讓 FindBugs 的檢測在背景執行，設定方式為在 FindBugs 的執行畫面選取 Always run in background。檢測項目設定部分可以指定哪些檢測項目需要執行，這樣的設計比 PMD 使用上來的更為方便。此外也可以設定報表與過濾器 (Filter) 相關之選項，過濾器主要是用來告知 FindBugs 那些項目 (如類別) 不需要統計在結果的報告中。

FindBugs 設定畫面 (專案的 Properties 畫面) 

當使用自動執行 FindBugs 時，請勾選 Always run in background 以免等待過長的時間。

Bugs 的處理

透過 FindBugs 找出問題後，我們同樣需要確認是否需要進行修正。如果我們認定不需要修正，那麼有下列幾個方法可以告知 FindBugs 不需要把這個問題放入警告中。

1. 利用過濾器的機制。使用方法為在特定的問題上點選滑鼠右鍵，然後執行 Toggle Filter –> This Specific Bug Pattern。再次點選可以讓此類問題再次被加以警告。實際上此操作方法將使得同一種類的問題都被加以忽視，而不是針對單一問題，所以使用上並不方便。過濾器除了可以透過此一介面加以設定外，也可以在專案設定畫面中指定外部的設定檔。此外部檔案除可同步用於 Ant 的環境下外，而且可做更細緻的設定，而非僅能針對同一類別下的所有問題。
2. 利用 Annotations 的機制，宣告哪些函式/類別/參數等不需要提出警告 (SuppressWarnings)。使用上除了無法透過 Eclipse Plugin 操作介面的指令直接產生外，同樣也無法針對單一的問題加以宣告。
   
   宣告 equals 函式不要產生警告訊息
3. 透過 GUI 提供的功能，我們可以將找到的問題加以分類，並且填上相關說明。在使用上最為方便，功能也最為完整。但是卻僅能操作於 GUI 的環境，而無法在 Eclipse Plug-in 加以使用。這些資訊可以連同檢測結果一併儲存下來，以便日後的檢視與分析。

報表

FindBugs 提供不同的分析能力，包含能夠將多個檢測結果加以整合 (union bugs)、統計多次的檢測結果 (compute bug history)、選取特定的問題 (filter bugs)、計算問題的密度 (defect density)等等。這些工作可以透過 Ant 加以執行，另外也提供命令列的執行方式 (for /bin/sh)。FindBugs 在這方面的能力優於 PMD 所提供的功能，尤其是統計多次檢測結果的能力，可以方便管理者做追蹤的動作。

Annotations

Annotations 除了可以用來告知 FindBugs 哪些項目不需要進行警告外 (SuppressWarnings)，還可以告知 FindBugs 那些項目應該做何檢視。我們用一個假想的例子加以說明。在範例程式中，首先我們宣告 print 函示的參數 (sb) 有可能是 null (CheckForNull)，所以 FindBugs 會發現到我們使用 sb 時並沒有先做是否為 null 的判斷，因此產生了警告的訊息。除此之外，我們也宣告呼叫 reverse 這個函數的回傳值需要被檢查 (CheckReturnValue)。同樣的，因為我們的程式在呼叫 reverse 時並沒有檢查回傳值，所以產生了警告的訊息。透過 Annotations 的機制，可以強制 FindBugs 進行我們所需的檢查項目，以避免一些將來可能發生的潛在問題。

結語

FindBugs 在進行檢測時所花費的時間比較多 (與 Eclipse 或 PMD 相較)，其檢測出來的問題數也相對較少。這並不代表 FindBugs 的效果較差，只能說是目的不同。我個人覺得最可惜的是在與 IDE 整合方面仍有很大的改進空間。唯一支援的 Eclipse Plug-in，在使用上連問題的處理都無法有效進行，倒是在資訊的呈現相當詳盡。既然官方網站也說 Eclipse Plug-in 還在測試階段，就讓我們對其日後的表現拭目以待。在此之前，使用 GUI 來進行檢測是一個折衷的辦法。此外，報表的功能可以做歷史記錄的追蹤，這點對於程式碼的管理有其一定的作用。同樣可惜的是必須透過 Ant (或命令列) 的形式才有辦法產生報表，在使用上的親和力同樣略嫌不足。