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

    Posted 11 months ago
    by Henry Wu (Cho-Han)}

    編者：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　企業郵件防護實力大躍進

    Posted 11 months ago
    by Henry Wu (Cho-Han)}

    編者：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的操作體驗，不需反覆驗證，使用過程可謂親和友善。