• [資安小常識] 淺談公有雲和私有雲的資安考量

    編者:Cho-Han Wu


     

    01

    圖一、公有雲與私有雲之選擇  (圖片來源)

     

    近年來雲端運算已經相當成熟且蓬勃發展,在資源愈來愈充沛且資訊相對透明的情況下,無論各個產業的公司都想在雲端上尋找長遠的解決方案。然而雲端運算的種類眾多,企業需要好好地評估最適合的雲端服務種類才有辦法達到將成本效益最大化。本次資安小常識,將從公有雲和私有雲的資安考量做切入,提供您在選擇雲端服務上的指引。

     

    首先,先了解一下何謂公有雲以及私有雲:
    私有雲是企業自有或共有伺服器基礎架構,並利用虛擬化等方式來創造專屬企業本身的雲端服務。其資料僅能被企業本身管理,並能確保與其他企業區隔。

     

    公有雲是雲端服務提供商或第三方服務提供者所提出的雲端服務,公有並不一定代表免費,也不一定代表使用者的資料可供其他人任意取用。

     

    表一、公有雲與私有雲之優缺點比較  

     
    公有雲
    私有雲
    優點

    1.  可降低機房管理和硬體維護等成本。

    2.  享有任何時間隨付即用的功能。

     3.  服務選擇多樣,可快速取用資源。

    1.  企業可以自行客製化伺服器軟硬體。

    2.  可從底層自行設計防火牆以及機敏資料之存放機制。

    缺點

    1.  敏感性資料可能的隱私問題。

    2.  企業需承擔服務中斷的風險。

    1.  普遍來說維護成本較使用公有雲來得高。

     

    無論是使用哪一項服務,都必須注意資料的安全。將重要的資料自己保管的確會比較安心, 但是也需要考慮到本身是否有能力來架設全面的防護機制來阻擋可能的資安攻擊。而對於使用公有雲的企業來說,若是不清楚雲端服務供應商維護資料安全的能力,則發生問題時很有可能會得不到應有的保障造成損失。

     

    其實近年來公有雲也逐漸在加強認證以及加密服務,並強調資料的安全性。舉微軟推出的 Azure 公有雲服務為例,除了全天候管理以及監控異常的服務外,在防止 客戶資料外洩 的部份,也做了很好的控管。另外,Azure 也使用了相當好的 加密機制 來保障使用者金鑰的安全和資料的安全性。對於使用者帳戶管理的部份,Azure 也提供您 管理帳戶 的方法以增強您帳戶的安全性。

     

    02

    圖二、雲端服務的資安保障  (圖片來源)

     

    選擇雲端服務就像是選擇保險箱一樣:是要放在自己家裡保險箱安全呢? 還是放在銀行保險庫安全呢? 這些都是使用者要審慎考慮的問題,本篇資安小常識分析了公有雲和私有雲的優缺點,希望能夠幫助您選擇到最適合您的雲端服務。

     

     

    參考資料

     

     

  • 清查盤點加集中管控 確保機敏個資絕不落地

    編者:Cho-Han Wu


     

    圖一、 Share Point 2013  (來源)



    前言:
    依iThome進行的2013年CIO大調查,發現近六成台灣2000大企業的最高資訊主管,皆將個資法列為驅動資安投資的關鍵項目,但此事知易行難,普遍存在不知如何下��之嘆;當務之急,便是尋求一套有效方案,以嚴密保護機敏個資。

     


    新版個人資料保護法,已於前年(2012)底正式上路;儘管該法施行迄今,尚未出現驚天動地的求償訴訟案件,但援引日本前例,求償事件係於個資施行2~3年後到達高峰,由此推論,民國103~104年才正要進入台灣個資損害求償的高峰期,企業不可掉以輕心。

     

    「事實上,從近期若干金融機構遭到主管機關裁罰,即為個資損害求償效應發酵的前兆,」網路多媒體研究所資訊安全技術中心主任吳建興認為,展望今後,機敏個資之保護,勢將伴隨法規要求、以及市場需求的驅動,成為企業不容迴避的重要議題。

     

    在此前提下,資策會結合台灣微軟、安資捷等業界夥伴,共同發展新一代個資保護解決方案,內容涵蓋用戶端電腦個資的全面清查與盤點、盤點完畢後的個資敏感度分類、乃至最終的個資集中管理與防護,再輔以由微軟合作夥伴提供的個資保護諮詢顧問服務,足以匯聚為完整力量,協助企業建構內部第一個個資防護平台,滿足大多數保護個資檔案之基本需求。

     

     

    個資等同黃金鑽石 務求嚴加盤查看管

     

     

    安資捷執行長陳勇君指出,企業因應個資法務必要做的11件事,都列在該法第12條,而綜觀這11件大事,箇中最重要的五項,即是第二項的「界定個人資料之範圍」、第四項的「事故之預防、通報及應變機制」、第八項的「設備安全管理」、第九項的「資料安全稽核機制」,以及第十項的「使用紀錄、軌跡資料及證據保存」。

     

    著眼於此,不少企業主,或人事、法務等高階主管,都認為這五檔事與IT息息相關,故而要求IT部門扛起所有責任,其實並不正確。原因之一,這五件事項當中,僅第八到十項與IT直接相關,其餘皆需仰賴公司全員通力配合;原因之二,依單筆個資外洩的500~20,000元求償金額而論,個資對於企業的價值,應是「錢」而非「IT」,既然地位等同於黃金、鑽石,企業主豈可任由IT孤軍奮戰?

     

    當然,要想知道黃金或鑽石之所在,首先便是界定個資範圍,因此企業主必須通盤掌握個資分佈狀況,因為沒有老闆願意將價值數百萬元、甚至上億元寶藏,散佈四處任由員工任意保管,而擁有個資的同仁,也絕對無意承擔如此大的保管責任;將這些資產收歸國有,無疑是一種可行做法。

     

    但部分同仁基於業務職責,無可避免需要頻繁使用個資,此時又該如何是好?最佳解答就是「機敏不落地」,同仁可視實際需要存取或修改個資,但仍能確保個資不落在任何人的終端設備。

     

    唯今之計,企業必須針對檔案型個資的生命週期,從創建編輯、動儲存、掃瞄盤點、盤後應變一路到委外監督,施以嚴密安全管理程序,舉凡權限管控、稽核軌跡記錄乃至異常應變,皆需予以落實;而其中最關鍵的起手式,即是用以判定個資價值與風險之「個資盤點」程序,而安資捷提供的Privacy ID檔案型個資盤點工具,結合資策會的中文語意分析技術(因中文為特殊語言,採用外來工具,不易精確掃瞄姓名、地址…等個資項目),便肩負此一重大使命。

     

    唯今之計,企業必須針對檔案型個資的生命週期,從創建編輯、動儲存、掃瞄盤點、盤後應變一路到委外監督,施以嚴密安全管理程序,舉凡權限管控、稽核軌跡記錄乃至異常應變,皆需予以落實;而其中最關鍵的起手式,即是用以判定個資價值與風險之「個資盤點」程序,而安資捷提供的Privacy ID檔案型個資盤點工具,結合資策會的中文語意分析技術(因中文為特殊語言,採用外來工具,不易精確掃瞄姓名、地址…等個資項目),便肩負此一重大使命。

     

     

    檔案存取異常分析 及早防堵個資外洩

     

     

    所謂集中管理,旨在達到資訊不落地效果。此時可透過私有雲集中強化保護,以及遠端桌面、虛擬桌面或Office 365線上編輯,以實現「集中保護、線上編輯」;藉由定期掃瞄是否有個資不慎遺漏在Client端、落實集中保護政策,以實現「定期掃瞄、矯正預防」;再者可透過內容最小化/遮罩去識別化,配合DRM管控在外流通個資檔案,以實現「委外個資、監督稽核」。

     

    針對一些基於業務推展需要,必須分散處理的個資,也務求做到資訊不外洩,相關手段包括建構DLP機敏指紋特徵庫、若遇符合外洩特徵便立即阻擋/通報/核示/稽核,以實現「機敏指紋、防止外洩」;定期掃瞄、持續建構與維護更新機敏指紋資料庫,以實現「定期掃瞄、矯正預防」;再者同樣藉由內容最小化/遮罩去識別化,配合DRM管控在外流通個資檔案,以實現「委外個資、監督稽核」。

     

    有關盤後應變原則,陳勇君提出幾項實用建議。針對個人所掃瞄之個人檔案,如不再需要,便應進行個別或集體刪除;如屬於高風險/高價值,比方內含信用卡號、身分證字號超過500筆,即應進行集中搬移;如屬於高風險/高價值、但需隨身攜帶,即應進行本機加密。此外,針對同仁電腦定期進行個資掃瞄,協助檢測是否疏忽而不慎遺留在Client端、或並未加密保護。

     

    而企業在善盡鑑價分級、資訊不落地(授權編輯),並啟動檔案存取稽核軌跡之餘,亦應建立檔案存取異常分析機制,譬如連續登入失敗、機敏檔案頻率異常(如1秒內抓取數百筆個資檔案)、非上班時間存取、特定擔憂對象存取(如即將離職的員工),一經察覺隨即發出告警,並詳實記載來源(From)、誰(Who)、動作(What)、時間(When)及目的端(Where)等軌跡,在外洩事發之前及時遏阻,好過事後的懊悔、追蹤或究責。

     

     

    落實清查掃瞄 確保適法防護成效

     

     

    來自安資捷的資安顧問江嘉帆,以Privacy ID解決方案為軸心,闡述落實檔案個資清查掃瞄、確保個資適法防護成效之道。他指出,個資盤點存在諸多現實挑戰,對於主管或稽核(風控),亟欲快速得知個資散佈情況、風險最高之所在、盤點前後改善狀況;對於管理者,期望僅需必要的管理介入、隨時掌握盤點執行狀況、系統具彈性可與內部現有IT系統配合不衝突、盤點功能齊全且系統維護方便;對於使用者,希冀盤點流程簡單方便又可保有適當隱私、盤點時對日常作業影響降至最低、此後可直接對盤點結果進行處理。

     

    為此Privacy ID奉行「簡單、但又不簡單」原則,進行架構設計。所謂簡單,在於對盤點負責人而言,個資盤點流程即是「個資盤點任務設定」、「User下載Agent後執行自動盤點」、「User過濾清查結果與上傳至Server」、「盤點負責人執行分析與報表產出」等簡易步驟,且由系統自動進行內容解析、Pattern比對,得以最少人工或時間完成盤點任務;至於不簡單,意謂其具有層次性架構設計,可確保眾多個體彼此不干擾,因此企業不論走集中管理、分散處理模式,又或者同時間同步執行多項盤點任務,皆能有效支援。

     

    為此Privacy ID奉行「簡單、但又不簡單」原則,進行架構設計。所謂簡單,在於對盤點負責人而言,個資盤點流程即是「個資盤點任務設定」、「User下載Agent後執行自動盤點」、「User過濾清查結果與上傳至Server」、「盤點負責人執行分析與報表產出」等簡易步驟,且由系統自動進行內容解析、Pattern比對,得以最少人工或時間完成盤點任務;至於不簡單,意謂其具有層次性架構設計,可確保眾多個體彼此不干擾,因此企業不論走集中管理、分散處理模式,又或者同時間同步執行多項盤點任務,皆能有效支援。

     

    值得一提,Privacy ID提供ResultWizard盤後處理功能,可與微軟SharePoint無縫整合,可在盤後依風險將隱含個資的檔案,自動上傳至SharePoint伺服器,以落實資訊不落地原則,進一步針對檔案進行存取軌跡稽核。

     

    針對管理者,Privacy ID Center提供一目瞭然的儀表板,方便隨時查看目前進行中的盤點任務、進行中任務的盤點進度(%)、已完成(已盤/應盤)的User,及未完成(未盤/應盤)等細部資訊;而盤點人員可自AD匯入,藉由系統參數動態調整,輕易設定新增盤點任務,至於盤點任務的設定上,則支援23種檔案格式、7種識別類個資(含中文姓名、信用卡號、電子郵件、地址、身分證號、電話號碼、護照號碼)、自定機敏關鍵字、比對規則、盤點結果遮罩等彈性選項。

     

     

    個資之集中管控、稽核與防護

     

     

    台灣微軟技術經理俞為鈞不諱言指出,就現實情況,企業普遍充斥四處散落的檔案,不僅造成使用不便、無法隨處可用、難以輕鬆分享,且因缺乏完善內容管理,不易遵循個資法第27條「非公務機關保有個人資料檔案者,應採行適當之安全措施,防止個人資料被竊取、竄改、毀損、滅失. 或洩漏」,亟待加以改善。

     

    在上述情境下,一般檔案分享服務多面臨嚴峻挑戰,主要癥結未必是同仁蓄意外洩,而是因傳統存取權限管控不周延,未能對文件持續進行保護,導致在業務同仁分享檔案、或是因檔案太大被迫採用公有儲存服務之過程,無形中滋生漏洞。

     

    在上述情境下,一般檔案分享服務多面臨嚴峻挑戰,主要癥結未必是同仁蓄意外洩,而是因傳統存取權限管控不周延,未能對文件持續進行保護,導致在業務同仁分享檔案、或是因檔案太大被迫採用公有儲存服務之過程,無形中滋生漏洞。

     

    值此時刻,企業不妨藉由SharePoint作為雲端儲存的規範平台,一來藉由近乎檔案總管的熟悉界面,便於使用者拖曳上傳文件,輕易設置資料夾、進行文件分類與搜尋,二來使員工不受地點或裝置限制,便於存取權限授予的檔案。

     

    再者,SharePoint具有一目瞭然的授權機制,可讓企業落實個資集中管控,又不因而喪失檔案分享之便利,可謂實踐「機敏個資不落地」的絕佳途徑。舉例來說,針對一份機密檔案,僅放置於唯讀資訊區,A同仁被賦予讀取權限,B、C等其餘同仁則否,而A便只能瀏覽該文件,無法進行下載、列印、螢幕擷取或轉寄,絕不可能像從前一般,衍生A傳B、B傳C、C再下載至個人裝置攜出…等交叉授權亂象。沿用上述情境,B、C等毫無存取、讀取或唯讀權限的同仁,即使以該檔案相關的關鍵字進行搜尋,在搜尋結果中,也不會呈現此檔案訊息。

     

    更重要的,SharePoint不僅可完整記載上傳、下載或刪除機敏檔案的軌跡報告,且可一併作為SharePoint、Exchange或Lync的管控樞紐,將Exchange或Lync的通郵或交談所涉及之敏感資訊,予以在地保留,藉此滿足數位採證目的。

     

    但不可諱言,機敏個資一旦處在SharePoint管區,自然受到完善的權限管控、稽核軌跡留存,但這些檔案若被攜出文管中心,如何保護?台灣微軟技術副理蔡宗佑表示,此時企業便可借助Active Directory的RMS功能,直接將權限綁定在文件之上,則該文件不論藉由任何方式、傳遞至任何地方,都必須接受驗證,唯有被授權者才能進行特定存取操作。

     

    蔡宗佑並強調,文件擁有者欲對檔案執行加密保護,步驟很簡單,僅需開機登入、並由背景自動指向RMS伺服器索取識別憑證,接著透過逐筆手動勾選、直接套用範本,或與SharePoint、檔案伺服器進行整合,隨即完成授權發布,此後該文件便接受RMS保護並且加密;至於文件接收者,僅需朝向文件點擊右鍵兩次,便能輕易解密,依照既定權限來使用文件。

     

    另值得一提,現今使用者只需免費下載RMS App,無論裝置、作業平台為何,則可輕鬆存取受到RMS保護的檔案資料,也照樣無法從事逾越權限的使用行為,確保「機敏資訊不落地」一事,全無任何破口或死角。

     

     

  • [資安小常識] 密碼儲存要加”鹽”才夠安全

    編者:Cho-Han Wu


     

    01

    圖一、 ”鹽”是一個特定的字串用以增加密碼複雜度  (圖片來源)

     

    今年一月SplashData 公司公布了2013年最不安全的密碼排行榜,由「123456」取代「password」奪下最不安全密碼排行榜冠軍。其他不安全的密碼還包含了「qwerty」,「abc123」及「123456789」等等。在眾多網路平台興盛的時代,使用者往往必須記憶一組或多組密碼組合,而密碼的強度也是決定帳戶安全性的因素之一。

     

    此外,對於平台提供者而言,提供安全的後台系統來儲存使用者的密碼也是相當重要的因素。然而隨著駭客破解密碼的技巧日益高明,使用傳統的加密方法已經不足以妥善保護了,所以利用一些加密的小技巧來提升密碼儲存的安全是很重要的。本次資安小常識將介紹一些密碼加密的種類以及方法。

     

    02

    圖二、 2013年最不安全密碼排行榜  (圖片來源)

     

    網路平台提供者常見的儲存密碼的方法可大致分為下列幾種:

    1. 明碼

    儲存是將使用者輸入的密碼直接儲存於資料庫欄位之中,不經過任何修飾。利用這種方法儲存密碼是最不安全的,因為只要資料庫遭到入侵,使用者的密碼資訊即會被洩漏。

     

    2. 簡易雜湊法 (Pure Hash)

    簡易雜湊法是單只用一種雜湊演算法來保護明碼。
    在傳統的情況下,當密碼經過雜湊演算法 (如 MD5) 加密後是很難透過特定演算法推回原始值的,但如果透過大型的對照表,即有可能對照出原始的明碼,所以安全性仍不夠高。

     

    3. 加料式雜湊法 (Salted Hash)

    加料式雜湊法是將欲加密之明碼加上固定的一段字串 (又稱為鹽) ,再經過簡易雜湊法而成。
    例如:

    明碼 1234 經過 MD5 雜湊後的結果是
    81dc9bdb52d04dc20036dbd8313ed055

    這段雜湊可能會經由大量的對照表而還原,但若是加鹽之後
    例如:

    明碼 1234 + 鹽saltsaltsalt
    經過 MD5 雜湊後的結果是
    e80bdfdab3f83500d6330c6068eeeef4

    隨者鹽的複雜度增加,即使加了鹽後的原始密碼被破解,要得到真實密碼所需要的時間仍會大幅增加。

     

    4. 複合式雜湊法

    複合式雜湊法是利用兩種方法來增加雜湊的複雜度,利用這種方法即可以大幅提升密碼儲存的安全性。

    例如:

      • 雜湊兩次

    雜湊方法2 ( 雜湊方法1 ( 明碼 + 鹽 ) )

      • 加兩次鹽

    鹽 + ( 雜湊方法1 ( 明碼 +鹽 )

     

    隨著網路平台日益發達,本次資安小常識提供您在建構平台時,可以使用的安全地密碼儲存方法,以保障平台使用者的個資安全。此外,使用者在設計密碼時,也可以參考此篇文章來確保密碼強度的安全。

     

    參考資料

     

     

  • [資安小常識] 透過 Azure Rights Management 服務在雲端上安全地管理文件

    編者:Cho-Han Wu


     

    01

    圖一、 Windows Azure Rights Management 服務讓您更輕易地管理雲端文件  (圖片來源)

     

    Rights Management Services (RMS) 是一款提供企業在分享檔案和文件時,能夠同時保護機敏資訊安全的解決方案。最新的 RMS 讓企業組織能夠輕易的分享各種檔案類型的機敏性資料,同時也支援跨平台行動裝置的讀取。而新版 RMS 新增的 Azure RMS 功能,更簡化了舊版 RMS 繁瑣的分享步驟,讓使用者可以直接透過 Azure 雲端服務來進行權限的驗證,也讓 RMS 的建置成本大幅下降。本次的資安小常識,將提供您如何透過 Azure RMS 來管理雲端上的機敏文件。

     

    不管在資料庫管理和伺服器管理,撰寫系統記錄 (logging) 都是保護及監控系統安全最簡單的好方法。系統記錄會記錄下管理者的動作以及文件讀取的歷史紀錄。因此監控系統記錄可以達到以下三個目的:

    1. 監控資料是否被濫用

    建議的系統記錄時間應該小於15分鐘,這樣可以提供一個針對您的 RMS 資料的連續性監控。
    若某特定對象在非業務時間大量的存取機敏資料,或是在同一個時間區段內 (15分鐘) 從不同的 IP 登入,抑或是在沒有辦公據點的 IP 位置登入,那這些舉動即可能被視為資料的濫用。

    2. 分析資料讀取記錄,了解讀取背後的意義

    您可以藉由讀取記錄了解某特定使用者的資料讀取記錄,以及讀取的地點訊息等等,這些資源方便您了解使用者的行為。

    3. 當做事件發生的證物

    當資安事件發生時,管理者可以藉由系統記錄來查詢最後存取系統的使用者,並了解他所讀取的東西。這些訊息方便管理者對機敏資料流向得掌控。

     

     

    在開始設定之前

    在設定Azure RMS 的系統記錄之前,有三件事必須要先準備好:

    1. 您的企業必須是 Microsoft RMS 的訂戶
    使用免費的 RMS 個人帳戶將不提供系統記錄的功能。

    2. 您必須是 Windows Azure 的訂戶
    因為系統記錄必須存放在 Azure 之中,所以您必須是 Azure 的用戶,尚未擁有 Azure 帳戶的可在此申請, 目前 Azure 一個月免費試用

    3. 您的系統必須安裝 Windows PowerShell for right management
    因為在設定和管理的過程需要用到 PowerShell 來設定,所以您的系統必須安裝 PowerShell,下載網址

     

     

    設定 Azure 儲存空間

    開啟您的 Azure 入口網站,在左側的功能列表中點選 STORAGE -> NEW -> QUICK CREATE。

     

    02

    圖二、 在 Azure 中新增儲存空間  (圖片來源)

     

    創建完成後,選取剛新增的實例,並按下下方的 MANAGE ACCESS KEYS 按鈕,來管理您的儲存空間存取金鑰。

     

    03

    圖三、 選取新增的儲存空間實例  (圖片來源)

     

    04

    圖四、 複製存取金鑰  (圖片來源)

     

     

    設定儲存帳號和啟用系統記錄功能

    在安裝完 PowerShell 後,就要利用一些Command 來開啟系統記錄的功能。
    1. 匯入 Microsoft RMS 模組並連接至 Azure RMS

    PS C:\Windows\system32>Import-Module AADRM
    PS C:\Windows\system32>Connect-AadrmService -verbose

     

    2. 當系統跳出認證請求時,輸入管理者的帳號和密碼加以認證。

     

    3. 輸入 Command 告訴 Azure RMS 您的記錄在 Azure 上存放的位置,將剛剛的存取金鑰輸入在底下。

    PS C:\Windows\system32> $accesskey = ConvertTo-SecureString"wUjKVV14XXUCrdpuLsIa8yQ5IgUmLSOLmlgS/CcHNZXiurEORjTItdtPf4OpCaIwGNyijjMPxvDEOG21HRKR7A==" –asplaintext –force

    PS C:\Windows\System32>Set-AadrmUsageLogStorageAccount -StorageAccount RMSBILogs -AccessKey $accesskey

    RMSBILogs was set as the storage account for the usage log feature for the Rights management service.

    PS C:\Windows\system32>

     

    4. 開啟系統記錄的功能。

    PS C:\Windows\system32> Enable-AadrmUsageLogFeature

    The usage log feature is enabled for the Rights management service.

    PS C:\Windows\system32>

     

     

    如何使用和存取 RMS 系統記錄

    您可以用以下三種方法存取 RMS 的系統記錄

    1. 使用 Windows PowerShell Cmdlet
    使用Get-AadrmUsageLog cmdlet 能夠讓使用者下載每一筆區塊的資料到本機端。

    2. 使用 Windows Azure Storage SDK
    利用 Azure Storage SDK 讓您能夠更彈性地使用Get-AadrmUsageLog 所提供的功能,Windows Azure Storage SDK 的介紹如下

    3. 使用 Microsoft Power BI
    使用 Microsoft Power BI 讓您能夠將使用的記錄下載成 Excel 使用。

     

     

    如何解析 RMS 系統記錄

    RMS 的系統記錄範例如下:

    #Software: RMS
    #Version: 1.0
    #Fields: date time row-id request-type user-id result correlation-id content-id c-info c-ip

    2013-09-19 13:46:44 0d07036b-c66c-4e92-b887-f59ecd61dc96 AcquireLicense 'janet@corp-contoso.com' 'Success' ad18e935-bcf9-4b51-9d34-cf3391c451ef {9312A0DF-DA57-4854-9160- 603A1ED06CB3} 'MSIPC;version=1.0.622.36;AppName=WINWORD.EXE;AppVersion=15.0.4535.1000;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=x86' 94.245.87.113

     

    表一、RMS 系統記錄欄位對照表

    欄位名稱

    W3C 資料型態

    欄位描述

    範例

    Date

    Date

    UTC Date when the request was served. The source is the local clock on the server that served the request.

    2013-09-19

    Time

    Time

    UTC Time in 24H format when the request was served. The source is the local clock on the server that served the request.

    13:46:44

    row-id

    Text

    Unique GUID for this log record. This is useful for provenance when you aggregate logs or copy logs into another format.

    0d07036b-c66c-4e92-b887-f59ecd61dc96

    request-type

    Name

    Name of the RMS API that was requested

    AcquireLicense

    user-id

    String

    The user who made the request. The value is enclosed in single quotes. Some request types are anonymous, in which case this field is ‘’.

    'janet@corp-contoso.com'

    Result

    String

    ‘Success’ if the request was served successfully. The error type in single quotes if the request failed.

    ‘Success’

    correlation-id

    Text

    GUID that is common between RMS client log and server log for a given request. This helps in troubleshooting client issues.

    ad18e935-bcf9-4b51-9d34-cf3391c451ef

    content-id

    Text

    GUID, enclosed in curly braces, that identifies the protected content e.g. a document. This field has a value only if request-type is AcquireLicense, it is blank for all other request types.

    {9312A0DF-DA57-4854-9160-603A1ED06CB3}

    c-info

    String

    Information about the client platform making the request. The specific string varies depending on the application, OS, browser.

    'MSIPC;version=1.0.622.36;...OSArch=x86'

    c-ip

    Address

    IP address of the client making the request

    94.245.87.113

     

    表二、常見的請求對照表

    欄位名稱

    欄位描述

    AcquireLicense

    Client is requesting a license for a specific piece of content, from a Windows computer.

    FECreateEndUserLicenseV1

    This is similar to the AcquireLicence request. This endpoint is for mobile clients.

    Certify

    Client is requesting a certificate (which is later used to get a license) from a Windows computer.

    GetClientLicensorCert

    Client is requesting a publishing certificate (which is later used to protect content) from a Windows computer.

    FECreatePublishingLicenseV1

    This is the same as the previous two combined, from mobile clients.

    FindServiceLocationsForUser

    This is sometimes anonymous, and sometimes with authenticated. This is an innocuous request that queries for the URLs to certify and acquire license from.

    Decrypt

    You will see this only if you brought in your own key (BYOK, see whitepaper http://technet.microsoft.com/en-us/library/dn440580.aspx). The Microsoft Rights Management service logs this when your key is used for decrypt – typically once per AcquireLicense and Certify.

    Sign

    You will see this only if you brought in your own key (BYOK). RMS logs this when your key is used for signing – typically once per one time per AcquireLicence (or FECreateEndUserLicenseV1), Certify, and GetClientLicensorCert (or FECreatePublishingLicenseV1).

     

    透過 Azure RMS 的系統記錄功能,不但可以達到監控系統機敏文件存取記錄的功能,同時將記錄檔存放在雲端服務上,又可以減少企業維護系統的成本,可說是一舉數得。若您想要追蹤最新的RMS 技術,也歡迎到 RMS 的官方部落格 (英文) 來取得最新的資訊。

     

    參考資料

     

     

  • Exchange 搭配 RMS 企業郵件防護實力大躍進

    編者:Cho-Han Wu


     

    圖一、 Exchange 2013  (來源)



    前言:
    無論任何系統,一旦儲存使用者的文件或資訊,皆可能面臨個資洩漏問題,雲端系統也不例外;因此企業如何打造安全無虞的文件管控系統、電子郵件防護平台,藉以強化個資保全,無疑當務之急。

     


    面對個資法,經營 B2C 業務的企業如臨大敵,但某些從事 B2B 業務的公司,則相對無感;然台灣微軟技術經理常志誠認為,就個資法衍生的郵件或資訊安全議題,實與企業文件控管、智財權保護息息相關,因此不管業務型態是 B2C 或 B2B,可以肯定,都須善盡郵件風險管理。

    「因應個資法的第一步,即是做好11項安全維護措施,」常志誠說,這些措施,包括「配置管理之人員及相當資源」、「界定個人資料之範圍」、「個人資料之風險評估及管理機制」、「事故之預防、通報及應變機制」、「個人資料蒐集、處理及利用之內部管理程序」、「資料安全管理及人員管理」、「認知宣傳及教育訓練」、「設備安全管理」、「資料安全稽核機制」、「使用紀錄、軌跡資料及證據保存」,以及「個人資料安全維護之整體持續改善」。

    上述措施,從第四項的「事故之預防、通報及應變機制」開始算起直到最後,皆與IT部門密切相關,但僅是IT一己任務?其實不是,企業不但需要「全民皆兵」,且必須持貫徹始終,最起碼要做到,絕不會連累老闆因個資法訴訟而上法院。

     

    遵循個資法,優先做好郵件風險管理

    如何保護個資?常志誠表示,首要之務即是進行個資盤點,下一步即需面對結構化資料庫、非結構化機敏檔案的安控議題;尤其非結構化機敏檔案安控,可謂個資保護的關鍵所在,執行難度甚高。

    環顧非結構化機敏檔案,哪些可能肇因於內部洩漏,因而產生重大風險?根據 Forrester 統計,名列第一與第二者,分別為 PC/可攜式設備所傳送 Email、Web-based Email;由此可見,企業郵件安全管理的好與壞,關乎個資保全成效之高低,萬萬不可馬虎。

    從 2006 年起,微軟即針對安全展開強化措施,改寫所有產品 Source Code,並強調通信保護、法規遵循、簡化管理等三大原則,因此從 Exchange 2003 邁向下一版本 2007,正好跨越不同的安全與保護世代。

    常志誠指出,綜觀電子郵件市場現況,存在一些令人憂心的現象,包含大部份客戶仍使用 POP3 方式收信、系統儲存設備昂貴、系統資料備援解決方案不易建置,及使用者信箱大小受限。尤以 POP3 收信模式潛藏重大危機,只因現今駭客僅需利用 WiFi Sniffer,即可輕易竊據帳號及密碼。

    綜上所述,現行電子郵件系統急待解決的問題,無疑就是系統安全性、使用者信箱大小的限制、行動裝置的支援、郵件系統高可用性及異地備援,及個資法資料防護與保存的因應作為。

    微軟 Exchange 從 2003、2007 一路推進到如今 2013,不僅針對前述問題,展現愈趨強大的解決能力,更難能可貴的,部署彈性與簡易度卻反向提高。以新的模組部署模式而論,除允許彈性的網路與伺服器架構,建置用戶端存取伺服器 (CAS)、信箱伺服器 (MBX) 角色外,尚可降低成本、提高靈活與可擴展性與簡化負載平衡,減少Namespace與複雜性,兼能提供從小型及企業自建的規模、到託管的 Office 365。

     

    大容量信箱,低成本建置

    綜觀近 10 年來 Exchange 版本演進,最讓人驚艷者,無非就是儲存設備的變革!在硬體部分,自 2003 年以來,磁碟容量顯著增長,透過資料順序處理方式增加在單位密度線性基礎 (2010 SATA=~250 MB/sec),且隨機 I/O 效能預期不會有大幅改善 (15k RPM的上限);至於 Exchange 工作負載,首先即是信箱大小迅速增加,其次是完全滿足知識工作者的在線與即時搜尋需求,再者則是平均郵件大小的增加。

    「適用於較大、速度較慢的磁碟,對 Exchange 可說意義重大,」常志誠表示,意謂企業僅需憑藉最小化 I/O,即能以較低成本支持更大的信箱。若比較 Exchange 2003、Exchange 2013,後者 DB IOPS僅是前者 3% 不到,顯見 Exchange 歷經十年演進,前後效能大幅翻倍;IOPS的減少,代表 I/O 運作效能更順暢,也更能防範可能災害。

    值得一提,Exchage 2010 開始增加支援 SATA、JBOD 儲存裝置,意即企業可選擇各式儲存架構,而不會犧牲系統高可用度及穩定性,使「大容量信箱、低成本建置」願景得以實現,連帶衍生諸多優點,包括從所有的客戶端讀取所有的郵件(使用者體驗大幅優化)、花費更少時間管理郵箱配額、避免 PST 檔遺失或損壞狀況,及簡化電子郵件搜尋與保留管理。其結論就是,欲建立 Exchage 高可用性架構,再也不需動用可觀成本!

     

    挾著功能強化,克服郵件安全挑戰

    而論及電子郵件安全挑戰,無非就是快速發展的外部威脅、敏感性資料遺失的潛在風險,及維護電子郵件安全、同時避免影響使用者;對此,現今 Exchage 已提供十足保護功能,如「阻擋病毒及惡意軟體」,可藉由 Exchage Online Protection 在垃圾郵件及病毒進入網路前及早攔阻,或利用 Exchage Server 內建基本防惡意軟體機制;如「保護敏感性資料」,則包括掃瞄Exchage傳輸敏感性內容郵件及資料遺失防禦機制功能(含雲端及企業內部),及使用 RMS 對電子郵件進行嚴密控制。此外,透過「連線篩選」(含靜態 IP 允許/阻止清單、選擇加入微軟的信譽發件人列表)、「垃圾郵件分類」、「內容篩選運作」(含刪除、隔離、增加X-Header、修改主旨、重新指向),則可發揮反垃圾郵件成效。

    當然,上述安全功能的實現,僅需借助阻擋附件、輔以「健全、可客製化的通知」來簡易設置,使用戶可在合理控制權基礎上,對敏感郵件資訊做最大限度地控制,減少不必要的應用中斷。至於可供善用的手段,則包括傳輸規則的設定,借助 Exchange IRM 執行原則設定(如針對外寄信件加密、限制受信方不得轉寄或列印),或透過 Exchange DLP 機制施行深入的內容分析,以辨識、監控並保護敏感重要資料。

    綜觀 Exchange 2013 DLP 功能,主要特色在於具備 Outlook 2013 使用者經驗、可用於 Exchage Server 與 Office 365、內建 DLP 原則範本、預先定義敏感性資料內容類型、支援第三方定義的 DLP 原則範本,及豐富的報表資料。常志誠強調,有了 DLP 原則範本,意謂企業可針對敏感性資料類型預設規則,從而增強內容偵測,再搭配傳輸規則設定,有效落實法規遵循探索、採取行動執行政策之目的。

     

    有效防堵垃圾郵件,遠離社交工程危害

    透過電子郵件進行攻擊之常見手法,不外是假冒寄件者、使用與業務相關或令人感興趣的郵件內容、含有惡意程式的附件或連結,及利用應用程式之弱點(含零時差攻擊);要想防禦這些攻擊,其實單憑 Outlook 即可發揮相當功效。

     Outlook Express 是屬於 Windows XP 所附贈的軟體,功能簡單且安全性低,然 Office Outlook 屬於 Office 內建的軟體版本,可透過完整郵件規則發揮強大安全功能,顯然更適合辦公室的人採用。至於使用者端連線方式,微軟 Outlook MAPI 用戶端訴諸嚴謹加密,安全係數最高,企業宜予以採用,取代相對不安全的 POP3、IMAP 或 WEB Mail。

    至於如何防範病毒、垃圾郵件與網路釣魚?一方面可利用 Outlook「檔案」下的「垃圾郵件選項」選擇保護層級,例如將來自封鎖寄件者的郵件移至「垃圾郵件」資料夾,或僅依據安全的寄件者/收件者清單上的人員或網域所寄信件,允許傳送至收信匣;另一方面,透過相同的選項設定機制,亦可勾選「使用網路釣魚郵件中的連結與其它功能」、「當電子郵件地址中包含可疑網域時警告我」。

    針對可能暗藏風險的 VBA 巨集,使用者可憑藉 Outlook「檔案」下「信任中心」的巨集設定,選擇停用所有巨集、或僅顯示經數位簽章的巨集等方式趨吉避凶;另關於安全預覽或開啟郵件之道,也可藉由「信任中心」設定規範,允許僅能接收純文字模式、將超連結摒除在外。

    如今中小企業亦可訂閱 Exchange Online Protection 服務,變更 MX 記錄後即可快速執行,以排除各式威脅、維護公司 IP 位址的名譽(針對高風險郵件採用獨立的外寄傳遞集區)、享有五種具備費用折讓條款的 SLA,並獲得全年無休且毋需額外付費的IT電話支援,終至降低前期投資、確保電子郵件不漏失或遭退回,是善盡郵件風險管理的最短路徑。

    另一方面,台灣微軟技術經理蔡宗佑針對「如何遠離社交工程危害」,為企業用戶提出實用建議。他指出,社交工程攻擊模式,不外是駭客設計攻擊陷阱、將攻擊程式埋入電子郵件、寄發郵件給特定對象、受害者開啟郵件、啟動駭客設計的陷阱並植入後門程式等五大步驟,不少機關都對此展開演練,旨在測試同仁警覺心及對不明來源郵件之開啟與點閱情形。

    但現今駭客手法日益純熟,已能偽冒幾可亂真的郵件,令用戶防不勝防;因此蔡宗佑認為,企業機構務求建立良好的電子郵件使用習慣,使用郵件前應確認是否「取消預覽功能」,而收到郵件後,不要任意點閱郵件中超連結或網站、不要任意打開不明郵件的附加檔案,更應避免回覆或轉寄不明郵件。

    除此之外,企業欲求保護機敏資訊,必須先建立探索、保護及管控內部機敏資訊的能力,此時便需援引一個全方位的解決方案平台,藉此確保重要資訊無論傳遞至何處皆受持續不斷保護,並有 SDK 進行特定需求客製化開發,並確定唯有被授權的人,才可進行特定存取。

    此一平台,未必需要斥資引進 DLP 或 MDM 等外部工具,文件擁有者只需善用 Active Directory 新版 RMS 功能,指向伺服器識別憑證,即可憑藉手動、依據範本勾選、與其他系統整合 (如 SharePoint、Exchange Server 或檔案伺服器)等多種途徑,為文件進行加密,並將預設權限綁定於文件,後續無論藉由何等方式傳輸,收信方只要朝向文件按右鍵 Double Click,便能輕易解密,且按既定權限來使用文件,即使 OWA 環境也適用。

    蔡宗佑並強調,新版 RMS 支援範圍已超越微軟Office文件,對任何文件格式均不設限,且使用者借助免費下載的 RMS App,即可支援行動裝置存取;至於企業對企業之間的文件分享,僅需赴微軟 Windows Azure的RMS Online(RMSO) 註冊郵件地址,再配合 AAD 記載相關帳號與權限 (註:AAD 毋需與 AD 同步,絕無外洩資訊之虞),雙方即可安全分享文件,且拜自動執行 SSO 單一簽入所賜,使用者可承襲右鍵Double Click的操作體驗,不需反覆驗證,使用過程可謂親和友善。