搜尋此網誌

2009年10月30日 星期五

[個人意見] 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、手機)、使用的媒介(有線網路、無線網路、電信網路)等等。

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

 

相關連結:

2009年10月29日 星期四

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

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

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

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

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

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

相關連結:

2009年10月27日 星期二

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

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

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

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

2009年10月14日 星期三

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

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

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

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

happy farm 001

使用步驟如下:

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

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

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

2009年10月2日 星期五

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

雲端運算 (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,都是一樣的道理。

 

相關連結:

2009年10月1日 星期四

[工具介紹] 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 的安裝。doctorj 001
  5. 雖然最後出現錯誤訊息,但是那僅是要將 jar 檔案複製時使用了 *nix 的路徑表示法,所以造成在 Microsoft Windows 無法執行。我們直接找到產生的 jar 檔案就可以了,該檔案為 share\doctorj\doctorj.jar。
  6. 使用 doctorj 很簡單,只要透過 java –jar doctorj.jar filename|path 就可以進行檢測。 不過因為 doctorj 會將結果顯示於畫面上,所以我們可以透過轉向機制將結果儲存於檔案中。

    檢測單一的檔案doctorj single file
    檢測整個目錄doctorj path
  7. 使用文字編輯器打開儲存檢測結果的檔案。doctorj result

JCSC

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

結語

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

About